From: Linus Walleij > Sent: 01 May 2022 22:56 > > On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray > <william.gray@xxxxxxxxxx> 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)
