Thread (30 messages) 30 messages, 6 authors, 2021-12-21

Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

From: Arnd Bergmann <arnd@kernel.org>
Date: 2021-08-04 08:52:35
Also in: linux-pci, lkml

On Wed, Aug 4, 2021 at 9:55 AM John Garry [off-list ref] wrote:
On 03/08/2021 13:15, Arnd Bergmann wrote:
quoted
quoted
That seems reasonable. And asm-generic io.h should be ifdef'ed by
HAS_IOPORT. In your patch you had it under CONFIG_IOPORT - was that
intentional?
No, that was a typo. Thanks for pointing this out.
quoted
On another point, I noticed SCSI driver AHA152x depends on ISA, but is
not an isa driver - however it does use port IO. Would such dependencies
need to be changed to depend on HAS_IOPORT?
I'm not sure what you mean here. As far as I can tell, AHA152x is an ISA
driver in the sense that it is a driver for ISA add-on cards. However, it
is not a 'struct isa_driver' in the sense that AHA1542 is, AHA152x  is even
older and uses the linux-2.4 style initialization using a module_init()
function that does the probing.
ok, fine. So I just wonder what the ISA kconfig dependency gets us for
aha152x. I experimented by removing the kconfig dependency and enabling
for the arm64 (which does not have CONFIG_ISA) std defconfig and it
built fine.
The point of CONFIG_ISA is to only build drivers for ISA add-on cards
on architectures that can have such slots. For ISA drivers in particular,
we don't want them to be loaded on machines that don't have them
because of the various ways this can cause trouble with hardwired
port and irq numbers.
quoted
quoted
Yeah, that sounds the same as what I was thinking. Maybe IOPORT_NATIVE
could work as a name. I would think that only x86/ia64 would define it.
A concern though is that someone could argue that is a functional
dependency, rather than just a build dependency.
You can have those on a number of platforms, such as early
PowerPC CHRP or pSeries systems, a number of MIPS workstations
including recent Loongson machines, and many Alpha platforms.
hmmm... if some machines under an arch support "native" port IO and some
don't, then if we use a common multi-platform defconfig which defines
HARDCODED_IOPORT, then we still build for platforms without "native"
port IO, which is not ideal.
Correct, but that's not a problem I'm trying to solve at this point. The
machines that have those are extremely rare, so almost all configurations
that one would encounter in practice do not suffer from it, and solving it
reliably would be really hard.

       Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help