From: Arnd Bergmann <email@example.com>
To: John Garry <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, 3 Aug 2021 14:15:21 +0200 [thread overview]
Message-ID: <CAK8P3a3B4FCaPPHhzBdpkv0fsjE0jREwGFCdPeHEDHxxRBEjng@mail.gmail.com> (raw)
On Tue, Aug 3, 2021 at 1:23 PM John Garry <firstname.lastname@example.org> wrote:
> > so I'm just not building those drivers any more, and not
> > defining the inb()/outb() helpers either, causing a build failure when I'm
> > missing an option.
> > However it sounds like you are interested in a third option here, which
> > brings us to:
> > LEGACY_PCI: any PCI driver that uses inb()/outb() or is only available
> > on old-style PCI but not PCIe hardware without a bridge.
> > To be disabled for most architectures and possibly distros but can
> > be enabled for kernels that want to use those devices, as long as
> > CONFIG_HAS_IOPORT is set by the architecture.
> > HAS_IOPORT: not a legacy PCI device, but can only be built on
> > architectures that define inb()/outb(). To be disabled for s390
> > and any other machine that has no useful definition of those
> > functions.
> 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
No, that was a typo. Thanks for pointing this out.
> 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.
> I did notice that arm32 support CONFIG_ISA - not sure why.
This is for some of the earlier machines we support:
mach-footbridge has some on-board ISA components, while
SA1100, PXA25x and S3C2410 each have at least one machine
with a PC/104 connector using ISA signaling for add-on cards.
There are also a couple of platforms with PCMCIA or CF slots
using the same ISA style I/O signals, but those have separate
> > HARDCODED_IOPORT: (or another name you might think of,) Used by
> > drivers that unconditionally do inb()/outb() without checking the
> > validity of the address using firmware or other methods first.
> > depends on HAS_IOPORT and possibly architecture specific
> > settings.
> 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.
Maybe the name should reflect that these all use PC-style ISA/LPC
port numbers without the ISA connectors.
next prev parent reply other threads:[~2021-08-03 12:15 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 [this message]
2021-08-04 7:55 ` John Garry
2021-08-04 8:52 ` Arnd Bergmann
2021-08-10 9:19 ` John Garry
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.