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. ISTR there was a company that manufactured a USB-ISA option (providing an external ISA backplane). We never supported it, but in principle if we wanted to, then it would be the USB-ISA device's driver config option that CONFIG_ISA would additionally depend on as an alternative. That wouldn't enable CONFIG_HAS_IOPORT though because the presence of this particular USB-ISA device would not itself permit the use of I/O cycles with any PCI/e buses a machine might independently have, so devices for PCI/e options that require port I/O shouldn't be made available at the same time. I think that company might have actually manufactured a similar PCI-ISA option as well, but that I suppose did rely on support for I/O cycles on PCI. Early 2000s BTW. Maciej
