[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3a3cdd99d4645e2bbbe082808cbb2a5@AcuMS.aculab.com>
Date: Tue, 3 May 2022 13:08:04 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Walleij' <linus.walleij@...aro.org>,
William Breathitt Gray <william.gray@...aro.org>
CC: Niklas Schnelle <schnelle@...ux.ibm.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Arnd Bergmann <arnd@...nel.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
From: Linus Walleij
> Sent: 01 May 2022 22:56
>
> On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray
> <william.gray@...aro.org> wrote:
> > On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:
>
> > > Good question. As far as I can see most (all?) of these have "select
> > > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > > currently be repeated in architectures and doesn't have an explicit
> > > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > > sense on architectures with HAS_IOPORT set.
> >
> > There is such a thing as ISA DMA, but you'll still need to initialize
> > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > "config ISA" is the right thing to do: all ISA devices are expected to
> > communicate in some way via ioport.
>
> Adding that dependency seems like the right solution to me.
I think it all depends on what HAS_IOPORT is meant to mean and
how portable kernel binaries need to be.
x86 is (probably) the only architecture that actually has 'in'
and 'out' instructions - but that doesn't mean that some other
cpu (and I mean cpu+pcb not architecture) have the ability to
generate 'IO' bus cycles on a specific physical bus.
While the obvious case is a physical address window that generates
PCI(e) IO cycles from normal memory cycles it isn't the only one.
I've used sparc cpu systems that have pcmcia card slots.
These are pretty much ISA and the drivers might expect to
access port 0x300 (etc) - certainly that would be right on x86.
In this case is isn't so much that the ISA_BUS depends on support
for in/out but that presence of the ISA bus provides the required
in/out support.
Now, maybe, the drivers should be using some ioremap variant and
then calling ioread8() rather than directly calling inb().
But that seems orthogonal to this changeset.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists