From: zhichang <zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
"zhichang.yuan"
<yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
liviu.dudau-5wv7dgnIgG8@public.gmane.org,
kantyzc-9Onoh4P/yGk@public.gmane.org
Subject: Re: [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced
Date: Sun, 18 Sep 2016 11:38:45 +0800 [thread overview]
Message-ID: <9ffcda2a-9a2b-7151-dfd9-e2bf6594c842@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.
>
Yes. It probably cause kernel panic.
Will define the extio operations for other IO length and add the corresponding WARNINGS.
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
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-09-18 3:38 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 [this message]
2016-09-21 9:26 ` zhichang
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=9ffcda2a-9a2b-7151-dfd9-e2bf6594c842@gmail.com \
--to=zhichang.yuan02-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=kantyzc-9Onoh4P/yGk@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=liviu.dudau-5wv7dgnIgG8@public.gmane.org \
--cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
--cc=minyard-HInyCGIudOg@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
--cc=xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org \
--cc=yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org \
--cc=zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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).