linux-kernel - RE: [RFC v2 10/39] gpio: add HAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7bb4d0286f44462581d96320cfe105d6@AcuMS.aculab.com>
Date:   Wed, 4 May 2022 12:45:58 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'Maciej W. Rozycki'" <macro@...am.me.uk>
CC:     'Linus Walleij' <linus.walleij@...aro.org>,
        William Breathitt Gray <william.gray@...aro.org>,
        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: Maciej W. Rozycki
> Sent: 04 May 2022 12:47
> 
> On Tue, 3 May 2022, David Laight wrote:
> 
> > > > 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.
> 
>  I am fairly sure IA-64 has some form of IN/OUT machine instructions too.
> 
> > 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.
> 
>  Well, one can implement a pluggable PCI/e expansion card with a PCI-ISA
> bridge on it and a backplane to plug ISA cards into.  Without support for
> issuing I/O cycles to PCI from the host however you won't be able to make
> use of the ISA backplane except maybe for some ancient ISA memory cards.
> So logically I think CONFIG_ISA should depend on CONFIG_HAS_IOPORT and
> CONFIG_HAS_IOPORT ought to be selected by platform configurations.

But generating a PCI(e) I/O cycle doesn't need the cpu to be able to
generate an I/O cycle on its local bus interface.
All that required is for the PCI(e) host bridge to determine that it
needs to relevant kind of cycle on the target bus.
This can easily be based on the physical address.

Many years ago I used a system with the strongarm SA1100/1101 pair.
(Not running Linux, but I think that it could have - slowly.)
Two (adjacent?) areas of the physical address map generated memory
and I/O cycles to a pair of pcmcia slots.
What you end up with is definitely ISA, but ARM definitely doesn't
have in/out instructions.

Now, while this is rather hypothetical, a 'generic' arm kernel running
on that hardware would be able to support drivers that expect an ISA bus.
But on different hardware the same generic kernel would have nowhere
to 'attach' the same drivers - but they could still be part of the kernel
(maybe as modules).

What you should probably be doing is (outside of 'platform' code)
change the drivers to use ioread8() instead of inb().
Then adding in the required calls to get the correct 'token' to
pass to ioread8() to perform an I/O cycle on the correct target bus.

It is really the attachment of the driver that can't succeed, not the
compilation.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)