Hi Niklas, > With 2 more HAS_IOPORT patches having gone into v6.12-rc1 I'm looking > at what's left and we're down to 4 prerequisite patches[0] before being > able to compile-time disable inb()/outb()/…. This one being by far the > largest of these. Looking at your suggestion it seems that to compile > 8250_pci.c without HAS_IOPORT I'll have to add #ifdef CONFIG_HAS_IOPORT > around the MOXI section as that uses I/O ports unconditionally. The > rest seems fine and I guess would theoretically work on a system with > !HAS_IOPORT. I'll send a v2 with that included. I've skimmed over and I agree, though I'd place some of the #ifdefs differently, e.g. above #define QPCR_TEST_FOR1. Overall I think it would make sense to reorder code and group stuff that depends on port I/O such as to minimise the number of #ifdefs. Ideally we could come with a slightly user-friendlier change that would report the inability to handle port I/O devices as they are discovered rather than just silently ignoring them. > Note however that even though your POWER9 system does not have I/O port > support in hardware we still have HAS_IOPORT enabled for arch/powerpc > if PCI is enabed so even with this patch as is your POWER9 system > should not be affected. I think we need to get this right regardless. And also while I run a generic distribution kernel on my POWER9 as a production system, I'd love to see an option to build a tailored configuration that would indeed remove support for port I/O from the kernel side for systems like mine that have no provision for port I/O in hardware, knowing that such a kernel will only ever run on such hardware and discarding compiled code that won't ever be used. Maciej
