From: zhichang <zhichang.yuan02@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
"zhichang.yuan" <yuanzhichang@hisilicon.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com,
devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
benh@kernel.crashing.org, minyard@acm.org,
linux-pci@vger.kernel.org, gabriele.paoloni@huawei.com,
john.garry@huawei.com, will.deacon@arm.com, xuwei5@hisilicon.com,
linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
zourongrong@gmail.com, liviu.dudau@arm.com, kantyzc@163.com
Subject: Re: [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced
Date: Wed, 21 Sep 2016 17:26:06 +0800 [thread overview]
Message-ID: <c6fe6d43-5e8b-ee88-a328-83d998b51c5a@gmail.com> (raw)
In-Reply-To: <5264074.nuyDhEuOR4@wuerfel>
Hi, Arnd,
On 2016年09月14日 22:23, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote:
>>>
>>> No need to guard includes with an #ifdef.
>> If remove #ifdef here, extio.h should not contain any function external declarations whose definitions are in
>> extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is yes.
>
> There is no problem with making declarations visible for functions that
> are not part of the kernel, we do that all the time.
>
>>>> +#define BUILDS_RW(bwl, type) \
>>>> +static inline void reads##bwl(const volatile void __iomem *addr, \
>>>> + void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + type x = __raw_read##bwl(addr); \
>>>> + *buf++ = x; \
>>>> + } while (--count); \
>>>> + } \
>>>> +} \
>>>> + \
>>>> +static inline void writes##bwl(volatile void __iomem *addr, \
>>>> + const void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + const type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + __raw_write##bwl(*buf++, addr); \
>>>> + } while (--count); \
>>>> + } \
>>>> +}
>>>> +
>>>> +BUILDS_RW(b, u8)
>>>
>>> Why is this in here?
>> the readsb/writesb are defined in asm-generic/io.h which is included later, but the redefined insb/outsb need
>> to call them. Without these readsb/writesb definition before insb/outsb redefined, compile error occur.
>>
>> It seems that copy all the definitions of "asm-generic/io.h" is not a good idea, so I move the definitions of
>> those function needed here....
>>
>> Ok. I think your idea below defining in(s)/out(s) in a c file can solve this issue.
>>
>> #ifdef CONFIG_ARM64_INDIRECT_PIO
>> #define inb inb
>> extern u8 inb(unsigned long addr);
>>
>> #define outb outb
>> extern void outb(u8 value, unsigned long addr);
>>
>> #define insb insb
>> extern void insb(unsigned long addr, void *buffer, unsigned int count);
>>
>> #define outsb outsb
>> extern void outsb(unsigned long addr, const void *buffer, unsigned int count);
>> #endif
>>
>> and definitions of all these functions are in extio.c :
>>
>> u8 inb(unsigned long addr)
>> {
>> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
>> arm64_extio_ops->end < addr)
>> return readb(PCI_IOBASE + addr);
>> else
>> return arm64_extio_ops->pfin ?
>> arm64_extio_ops->pfin(arm64_extio_ops->devpara,
>> addr + arm64_extio_ops->ptoffset, NULL,
>> sizeof(u8), 1) : -1;
>> }
>> .....
>
> Yes, sounds good.
>
>>>> @@ -149,6 +185,60 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>>>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>>>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>>>
>>>> +
>>>> +/*
>>>> + * redefine the in(s)b/out(s)b for indirect-IO.
>>>> + */
>>>> +#define inb inb
>>>> +static inline u8 inb(unsigned long addr)
>>>> +{
>>>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>>>> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
>>>> + addr <= arm64_extio_ops->end)
>>>> + return extio_inb(addr);
>>>> +#endif
>>>> + return readb(PCI_IOBASE + addr);
>>>> +}
>>>> +
>>>
>>> Looks ok, but you only seem to do this for the 8-bit
>>> accessors, when it should be done for 16-bit and 32-bit
>>> ones as well for consistency.
>> Hip06 LPC only support 8-bit I/O operations on the designated port.
>
> That is an interesting limitation. Maybe still call the extio operations
> and have them do WARN_ON_ONCE() instead?
>
> If you get a driver that calls inw/outw on the range that is owned
> by the LPC bus, you otherwise get an unhandled page fault in kernel
> space, which is not as nice.
As for this issue, I provided a wrong reply in the last email.
After double-checking with SoC guys, the inw(l)/outw(l) are OK with multiple 8-bit transfers to consecutive
I/O addresses.
Sorry for the wrong information!
Will support inw(l)/outw(l) in V4.
Best,
Zhichang
>
>>>> diff --git a/drivers/bus/extio.c b/drivers/bus/extio.c
>>>> new file mode 100644
>>>> index 0000000..1e7a9c5
>>>> --- /dev/null
>>>> +++ b/drivers/bus/extio.c
>>>> @@ -0,0 +1,66 @@
>>>
>>> This is in a globally visible directory
>>>
>>>> +
>>>> +struct extio_ops *arm64_extio_ops;
>>>
>>> But the identifier uses an architecture specific prefix. Either
>>> move the whole file into arch/arm64, or make the naming so that
>>> it can be used for everything.
>>
>> I perfer to move the whole file into arch/arm64, extio.h will be moved to arch/arm64/include/asm;
>
> Ok, that simplifies it a lot, you can just do everything in asm/io.h then.
>
> Arnd
>
next prev parent reply other threads:[~2016-09-21 9:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 12:15 [PATCH V3 0/4] ARM64 LPC: legacy ISA I/O support Zhichang Yuan
2016-09-14 12:15 ` [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced Zhichang Yuan
2016-09-14 12:24 ` Arnd Bergmann
2016-09-14 14:16 ` zhichang.yuan
[not found] ` <57D95BBC.9030405-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
2016-09-14 14:23 ` Arnd Bergmann
2016-09-18 3:38 ` zhichang
2016-09-21 9:26 ` zhichang [this message]
2016-09-14 12:15 ` [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 Zhichang Yuan
2016-09-14 12:33 ` Arnd Bergmann
2016-09-14 14:50 ` zhichang.yuan
2016-09-14 21:32 ` Arnd Bergmann
2016-09-15 8:02 ` Gabriele Paoloni
2016-09-15 8:22 ` Arnd Bergmann
2016-09-15 12:05 ` Gabriele Paoloni
2016-09-15 12:24 ` Arnd Bergmann
2016-09-15 14:28 ` Gabriele Paoloni
2016-09-21 10:09 ` zhichang
2016-09-21 16:20 ` Gabriele Paoloni
2016-09-21 20:18 ` Arnd Bergmann
2016-09-22 11:55 ` Gabriele Paoloni
2016-09-22 12:14 ` Arnd Bergmann
2016-09-22 14:47 ` Gabriele Paoloni
2016-09-22 14:59 ` Arnd Bergmann
2016-09-22 15:20 ` Gabriele Paoloni
2016-09-22 15:46 ` zhichang.yuan
2016-09-22 16:27 ` zhichang.yuan
[not found] ` <57E40665.8080005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-09-23 9:51 ` Arnd Bergmann
2016-09-23 10:23 ` Gabriele Paoloni
2016-09-23 13:42 ` Arnd Bergmann
2016-09-23 14:59 ` Gabriele Paoloni
2016-09-23 15:55 ` Arnd Bergmann
2016-09-24 8:14 ` zhichang
[not found] ` <05a573de-e963-6590-6ed3-55af97067d7a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-09-24 21:00 ` Arnd Bergmann
2016-09-26 13:21 ` Gabriele Paoloni
2016-09-24 8:00 ` zhichang
2016-10-02 22:03 ` Jon Masters
[not found] ` <2af4f2d8-e3a4-fa00-e700-60af70bf4560-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>
2016-10-04 12:02 ` John Garry
2016-10-06 0:18 ` Benjamin Herrenschmidt
2016-10-06 13:31 ` John Garry
[not found] ` <1473855354-150093-3-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
2016-09-14 14:09 ` kbuild test robot
2016-09-14 12:15 ` [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count Zhichang Yuan
[not found] ` <1473855354-150093-4-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
2016-09-14 12:25 ` Arnd Bergmann
2016-09-14 15:04 ` zhichang.yuan
2016-09-14 21:33 ` Arnd Bergmann
2016-09-21 10:12 ` zhichang
2016-09-21 19:29 ` Arnd Bergmann
2016-09-14 12:15 ` [PATCH V3 4/4] ARM64 LPC: support earlycon for UART connected to LPC Zhichang Yuan
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=c6fe6d43-5e8b-ee88-a328-83d998b51c5a@gmail.com \
--to=zhichang.yuan02@gmail.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=gabriele.paoloni@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.garry@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=minyard@acm.org \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.com \
--cc=yuanzhichang@hisilicon.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).