From: John Garry <john.garry@huawei.com>
To: Alexander Graf <agraf@suse.de>,
"zhichang.yuan" <yuanzhichang@hisilicon.com>,
<catalin.marinas@arm.com>, <will.deacon@arm.com>,
<robh+dt@kernel.org>, <frowand.list@gmail.com>,
<bhelgaas@google.com>, <rafael@kernel.org>,
<mark.rutland@arm.com>, <brian.starkey@arm.com>, <olof@lixom.net>,
<arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: <lorenzo.pieralisi@arm.com>, <benh@kernel.crashing.org>,
<linux-kernel@vger.kernel.org>, <linuxarm@huawei.com>,
<devicetree@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linux-serial@vger.kernel.org>, <minyard@acm.org>,
<liviu.dudau@arm.com>, <zourongrong@gmail.com>,
<gabriele.paoloni@huawei.com>, <zhichang.yuan02@gmail.com>,
<kantyzc@163.com>, <xuwei5@hisilicon.com>
Subject: Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07
Date: Tue, 31 Jan 2017 11:49:56 +0000 [thread overview]
Message-ID: <74208c0c-3ac4-58ea-9cf0-62e68e49557c@huawei.com> (raw)
In-Reply-To: <2890e438-6149-c8f0-8ec7-9036a8d5cca5@suse.de>
>>>> + * The port size of legacy I/O devices is normally less than 0x400.
>>>> + * Defining the I/O range size as 0x400 here should be sufficient for
>>>> + * all peripherals under one bus.
>>>> + */
>>>
>>> This comment doesn't make a lot of sense. What is the limit? Is there a
>>> hardware limit?
>>>
>>> We don't dynamically allocate devices on the lpc bus, so why imply a
>>> limit at all?
>>>
>>
>> IIRC from previously asking Zhichang this before, this is the upper
>> range we can address devices on the LPC bus. But the value was 0x1000
>> then.
>
> Well, all devices that we want to address are defined by firmware (via
> device tree or dsdt). So I'm not quite sure what this arbitrary limit
> buys us.
>
Will check with Zhichang.
>>
>>>> +#define LPC_BUS_IO_SIZE 0x400
>>>> +
<snip>
>>>> + ret = 0;
>>>> + cnt_per_trans = (para->csize == 1) ? opcnt : para->csize;
>>>> + for (; opcnt && !ret; cnt_per_trans = para->csize) {
>>>> + unsigned long flags;
>>>> +
>>>> + /* whole operation must be atomic */
>>>> + spin_lock_irqsave(&lpcdev->cycle_lock, flags);
>>>
>>> Ouch. This is going to kill your RT jitter. Is there no better way?
>>>
>>
>> Obviously the bus register driving is non-atomic, so we need some way to
>> lock out.
>>
>> I think that it is not so critical for low-speed/infrequent-access bus.
>>
>> If we were going to use virtual UART in the BMC on the LPC bus then we
>> could consider more.
>
> Well, it basically means that an arbitrary daemon running in user space
> that checks your temperature readings via the ipmi interface could
> create a lot of jitter. That could be very critical if you want to use
> this hardware for real time critical applications, such as telecom.
>
> I bet that if you leave it like that and postpone the decision to fix it
> to "later", in 1 or 2 years you will cause someone weeks of debugging to
> track down why their voip gateway loses packets from time to time.
>
>>
We need to consider this more. There may a way to access the registers
and drive the bus without requiring a lock, but I doubt it.
Note: I think that we could make some readl/writel relaxed, which would
help.
>>>> +
>>>> + writel(cnt_per_trans, lpcdev->membase + LPC_REG_OP_LEN);
>>>> +
>>>> + writel(cmd_word, lpcdev->membase + LPC_REG_CMD);
>>>> +
>>>> + writel(ptaddr, lpcdev->membase + LPC_REG_ADDR);
>>>> +
>>>> + writel(START_WORK, lpcdev->membase + LPC_REG_START);
>>>> +
>>>> + /* whether the operation is finished */
>>>> + ret = wait_lpc_idle(lpcdev->membase, waitcnt);
>>>> + if (!ret) {
>>>> + opcnt -= cnt_per_trans;
>>>> + for (; cnt_per_trans--; buf++)
>>>> + *buf = readl(lpcdev->membase + LPC_REG_RDATA);
>>>> + }
>>>> +
>>>> + spin_unlock_irqrestore(&lpcdev->cycle_lock, flags);
>>>> + }
>>>> +
>>>> + return ret;
>>>> +}
<snip>
>>>> + * hisilpc_comm_in - read/input the data from the I/O peripheral
>>>> + * through LPC.
>>>> + * @devobj: pointer to the device information relevant to LPC
>>>> controller.
>>>> + * @pio: the target I/O port address.
>>>> + * @dlen: the data length required to read from the target I/O port.
>>>> + *
>>>> + * when succeed, the data read back is stored in buffer pointed by
>>>> inbuf.
>>>> + * For inb, return the data read from I/O or -1 when error occur.
>>>> + */
>>>> +static u64 hisilpc_comm_in(void *devobj, unsigned long pio, size_t
>>>> dlen)
>>>> +{
>>>> + struct hisilpc_dev *lpcdev = devobj;
>>>> + struct lpc_cycle_para iopara;
>>>> + u32 rd_data;
>>>
>>> rd_data needs to be initialized to 0. Otherwise it may contain stale
>>> stack contents and corrupt non-32bit dlen returns.
>>>
>>
>> I think so, since we read into this value byte-by-byte. We also seem to
>> return a 32b value but should return 64b value according to the
>> prototype.
>
> IIRC LPC (well, PIO) doesn't support bigger requests than 32bit. At
> least I can't think of an x86 instruction that would allow bigger
> transactions. So there's no need to make it 64bit. However, the question
> is why the prototype is 64bit then. Hm. :)
>
> Maybe the prototype should be only 32bit.
>
Will check with Zhichang.
>>
>>>> + unsigned char *newbuf;
>>>> + int ret = 0;
>>>> + unsigned long ptaddr;
>>>> +
>>>> + if (!lpcdev || !dlen || dlen > LPC_MAX_DULEN || (dlen & (dlen
>>>> - 1)))
>>>> + return -1;
>>>
>>> Isn't this -EINVAL?
>>
>> Not sure. This value is returned directly to the inb/outb caller, which
>> would not check this value for error.
>>
>> It could be argued that the checking is paranoia. If not, we should
>> treat the failure as a more severe event.
>
> Oh, I see. In that case -1 makes a lot of sense since it's the default
> read value on x86 for unallocated space.
>
> This probably deserves a comment (and/or maybe a #define)
>
We can add a comment
>
> Alex
>
> .
>
next prev parent reply other threads:[~2017-01-31 11:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 7:05 [PATCH V6 0/5] LPC: legacy ISA I/O support zhichang.yuan
2017-01-24 7:05 ` [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced zhichang.yuan
2017-01-30 17:12 ` Alexander Graf
2017-01-31 13:32 ` John Garry
2017-01-31 19:37 ` Alexander Graf
2017-02-01 12:29 ` Gabriele Paoloni
2017-02-13 14:17 ` zhichang.yuan
2017-02-14 13:17 ` Alexander Graf
2017-02-13 14:05 ` zhichang.yuan
2017-02-14 13:15 ` Alexander Graf
2017-01-31 0:09 ` Bjorn Helgaas
2017-01-31 13:34 ` John Garry
2017-01-24 7:05 ` [PATCH V6 2/5] PCI: Adapt pci_register_io_range() for indirect-IO and PCI I/O translation zhichang.yuan
2017-01-31 0:10 ` Bjorn Helgaas
2017-01-31 13:39 ` John Garry
2017-01-31 0:15 ` Bjorn Helgaas
2017-02-04 12:59 ` John Garry
2017-02-02 17:36 ` John Garry
2017-02-02 23:00 ` Rafael J. Wysocki
2017-01-24 7:05 ` [PATCH V6 3/5] OF: Add missing I/O range exception for indirect-IO devices zhichang.yuan
2017-01-27 22:03 ` Rob Herring
2017-01-30 8:57 ` John Garry
2017-01-30 10:08 ` Arnd Bergmann
2017-01-24 7:05 ` [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07 zhichang.yuan
2017-01-27 22:12 ` Rob Herring
2017-01-30 20:08 ` Alexander Graf
2017-01-31 10:07 ` John Garry
2017-01-31 11:03 ` Alexander Graf
2017-01-31 11:49 ` John Garry [this message]
2017-01-31 11:51 ` Gabriele Paoloni
2017-02-13 14:39 ` zhichang.yuan
2017-02-14 13:29 ` Alexander Graf
2017-02-15 11:35 ` zhichang.yuan
2017-02-15 11:53 ` Alexander Graf
2017-02-16 8:59 ` zhichang.yuan
2017-01-24 7:05 ` [PATCH V5 5/5] LPC: Add the ACPI LPC support zhichang.yuan
2017-02-04 13:20 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74208c0c-3ac4-58ea-9cf0-62e68e49557c@huawei.com \
--to=john.garry@huawei.com \
--cc=agraf@suse.de \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=brian.starkey@arm.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gabriele.paoloni@huawei.com \
--cc=kantyzc@163.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=minyard@acm.org \
--cc=olof@lixom.net \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.com \
--cc=yuanzhichang@hisilicon.com \
--cc=zhichang.yuan02@gmail.com \
--cc=zourongrong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).