On Wed, 4 May 2022, David Laight wrote: > > 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. Sure, you can encode address spaces however you like (there are no special machine instructions either for PCI/e configuration space access that I would know of in any CPU architecture), but the host bridge must be willing to issue those PCI/e I/O cycles in the first place (see my other message on POWER9 in this thread). > 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. Yes, probably. > It is really the attachment of the driver that can't succeed, not the > compilation. Except it makes no sense to offer those drivers for platforms known not to provide for port I/O on PCI/e. Maciej
