On Fri, 6 May 2022, Niklas Schnelle wrote:

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:

quoted

On Thu, 5 May 2022, Bjorn Helgaas wrote:

quoted

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:

quoted

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas [off-list ref] wrote:

quoted

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:

quoted

The main goal is to avoid c), which is what happens on s390, 
but can also happen elsewhere. Catching b) would be nice as 
well, but is much harder to do from generic code as you'd need 
an architecture specific inline asm statement to insert a 
ex_table fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on 
machines that have I/O port space and those that don't.  That 
makes me think s390 could do something similar.

No, this is actually the current situation, and it makes 
absolutely no sense. s390 has no way of implementing inb()/outb() 
because there are no instructions for it and it cannot tunnel them 
through a virtual address mapping like on most of the other 
architectures. (it has special instructions for accessing memory 
space, which is not the same as a pointer dereference here).

The existing implementation gets flagged as a NULL pointer 
dereference by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
pointer dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's 
what happens on most arches when there's no device to respond to the 
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
drivers that use I/O ports in some cases but not others.  But maybe 
it's the most practical way.

Do you mean, "the most practical way to avoid a compiler warning on 
s390"? What about "#pragma GCC diagnostic ignored"?

This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

Apart from that, I think this would also fall under the same argument as 
the original patch Linus unpulled. We would just paint over someting 
that we know at compile time won't work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ (local)

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?