From: John Garry <email@example.com>
To: Arnd Bergmann <firstname.lastname@example.org>
Cc: Linus Torvalds <email@example.com>,
"Linux Kernel Mailing List" <firstname.lastname@example.org>,
Niklas Schnelle <email@example.com>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access
Date: Tue, 10 Aug 2021 10:19:12 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 04/08/2021 09:52, Arnd Bergmann wrote:
>>>> 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.
>>>> 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.
This seems a reasonable approach. Do you have a plan for this work? Or
still waiting for the green light?
I have noticed the kernel test robot reporting the following to me,
which seems to be the same issue which was addressed in this series
config: s390-randconfig-r032-20210802 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
All errors (new ones prefixed by >>):
In file included from drivers/block/null_blk/main.c:12:
In file included from drivers/block/null_blk/null_blk.h:8:
In file included from include/linux/blkdev.h:25:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:75:
include/asm-generic/io.h:464:31: warning: performing pointer
arithmetic on a null pointer has undefined behavior
val = __raw_readb(PCI_IOBASE + addr);
So I imagine lots of people are seeing these.
next prev parent reply other threads:[~2021-08-10 9:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 13:47 [GIT PULL 1/2] asm-generic: rework PCI I/O space access Arnd Bergmann
2021-07-02 13:49 ` [GIT PULL 2/2] asm-generic: Unify asm/unaligned.h around struct helper Arnd Bergmann
2021-07-02 20:13 ` pr-tracker-bot
2021-07-02 19:42 ` [GIT PULL 1/2] asm-generic: rework PCI I/O space access Linus Torvalds
2021-07-03 12:12 ` Arnd Bergmann
2021-07-05 10:06 ` Arnd Bergmann
2021-08-03 9:46 ` John Garry
2021-08-03 10:06 ` Arnd Bergmann
2021-08-03 11:23 ` John Garry
2021-08-03 12:15 ` Arnd Bergmann
2021-08-04 7:55 ` John Garry
2021-08-04 8:52 ` Arnd Bergmann
2021-08-10 9:19 ` John Garry [this message]
2021-08-10 11:33 ` Arnd Bergmann
2021-09-03 8:31 ` Niklas Schnelle
2021-12-17 13:19 ` Niklas Schnelle
2021-12-17 13:32 ` Arnd Bergmann
2021-12-17 13:52 ` Niklas Schnelle
2021-12-17 14:05 ` Arnd Bergmann
2021-12-17 14:27 ` John Garry
2021-12-17 14:32 ` Arnd Bergmann
2021-12-17 15:27 ` John Garry
2021-12-17 15:55 ` Arnd Bergmann
2021-12-17 16:30 ` John Garry
2021-12-20 9:27 ` Niklas Schnelle
2021-12-21 16:48 ` John Garry
2021-12-21 16:57 ` Niklas Schnelle
2021-12-19 14:23 ` David Laight
2021-12-21 16:21 ` John Garry
2021-07-05 12:40 ` Niklas Schnelle
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.