All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Ettore Chimenti <ek5.chimenti@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Ian Abbott <abbotti@mev.co.uk>,
	H Hartley Sweeten <hsweeten@visionengravers.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Karsten Keil <isdn@linux-pingi.de>,
	Sathya Prakash <sathya.prakash@broadcom.com>,
	Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
	Suganath Prabu Subramani  <suganath-prabu.subramani@broadcom.com>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Kalle Valo <kvalo@kernel.org>, Jouni Malinen <j@w1.fi>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Hannes Reinecke <hare@suse.com>,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
	Nilesh Javali <njavali@marvell.com>,
	GR-QLogic-Storage-Upstream@marvell.com,
	Mark Brown <broonie@kernel.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Teddy Wang <teddy.wang@siliconmotion.com>,
	Forest Bond <forest@alittletooquiet.net>,
	Jiri Slaby <jirislaby@kernel.org>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-input@vger.kernel.org,
	netdev@vger.kernel.org, linux-media@vger.kernel.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-wireless@vger.kernel.org,
	megaraidlinux.pdl@broadcom.com, linux-spi@vger.kernel.org,
	linux-fbdev@vger.kernel.org, linux-serial@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-watchdog@vger.kernel.org
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
Date: Wed, 5 Jan 2022 13:47:48 -0600	[thread overview]
Message-ID: <20220105194748.GA215560@bhelgaas> (raw)
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>

On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com>  escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this.  For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors.  Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > > 
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > > 
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > > 
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option.  "Legacy" just
> > > means something old and out of favor; it doesn't say*what*  that
> > > something is.
> > > 
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI?  Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI?  This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.

I'd like to hear Arnd's opinion, too.  If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.

I must be missing something because I don't see what we gain from
this.  We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs.  I think we want to build drivers like that on
any arch that supports PCI.

If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.

But that same driver should still work with devices that have MEM
BARs.  If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly.  IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210

> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
> 
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
> 
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
> 
> Thanks,
> John

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: linux-fbdev@vger.kernel.org, linux-pci@vger.kernel.org,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	Ettore Chimenti <ek5.chimenti@gmail.com>,
	linux-ide@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
	Guo Ren <guoren@kernel.org>,
	linux-i2c@vger.kernel.org, linux-riscv@lists.infradead.org,
	Vincent Chen <deanbo422@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Hannes Reinecke <hare@suse.com>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	linux-scsi@vger.kernel.org,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Sathya Prakash <sathya.prakash@broadcom.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	linux-csky@vger.kernel.org,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Nilesh Javali <njavali@marvell.com>,
	intel-wired-lan@lists.osuosl.org, linux-serial@vger.kernel.org,
	GR-QLogic-Storage-Upstream@marvell.com,
	Jakub Kicinski <kuba@kernel.org>,
	MPT-FusionLinux.pdl@broadcom.com,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-media@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>,
	Jean Delvare <jdelvare@suse.com>,
	linux-watchdog@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Niklas Schnelle <schnelle@linux.ibm.com>, Jouni Malinen <j@w1.fi>,
	Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
	Kalle Valo <kvalo@kernel.org>,
	linux-input@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-gpio@vger.kernel.org, Ian Abbott <abbotti@mev.co.uk>,
	Mark Brown <broonie@kernel.org>,
	Greentime Hu <green.hu@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	megaraidlinux.pdl@broadcom.com,
	Teddy Wang <teddy.wang@siliconmotion.com>,
	linux-hwmon@vger.kernel.org, Arnd Bergmann <arnd@kernel.org>,
	Karsten Keil <isdn@linux-pingi.de>,
	Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Nick Hu <nickhu@andestech.com>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	dri-devel@lists.freedesktop.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-wireless@vger.kernel.org, Takashi Iwai <tiwai@suse.com>,
	"David S. Miller" <davem@davemloft.net>,
	H Hartley Sweeten <hsweeten@visionengravers.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Forest Bond <forest@alittletooquiet.net>,
	netdev@vger.kernel.org, Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
Date: Wed, 5 Jan 2022 13:47:48 -0600	[thread overview]
Message-ID: <20220105194748.GA215560@bhelgaas> (raw)
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>

On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com>  escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this.  For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors.  Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > > 
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > > 
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > > 
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option.  "Legacy" just
> > > means something old and out of favor; it doesn't say*what*  that
> > > something is.
> > > 
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI?  Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI?  This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.

I'd like to hear Arnd's opinion, too.  If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.

I must be missing something because I don't see what we gain from
this.  We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs.  I think we want to build drivers like that on
any arch that supports PCI.

If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.

But that same driver should still work with devices that have MEM
BARs.  If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly.  IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210

> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
> 
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
> 
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
> 
> Thanks,
> John

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Ettore Chimenti <ek5.chimenti@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Ian Abbott <abbotti@mev.co.uk>,
	H Hartley Sweeten <hsweeten@visionengravers.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Karsten Keil <isdn@linux-pingi.de>,
	Sathya Prakash <sathya.prakash@broadcom.com>,
	Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
	Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Kalle Valo <kvalo@kernel.org>, Jouni Malinen <j@w1.fi>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Hannes Reinecke <hare@suse.com>,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
	Nilesh Javali <njavali@marvell.com>,
	GR-QLogic-Storage-Upstream@marvell.com,
	Mark Brown <broonie@kernel.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Teddy Wang <teddy.wang@siliconmotion.com>,
	Forest Bond <forest@alittletooquiet.net>,
	Jiri Slaby <jirislaby@kernel.org>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-input@vger.kernel.org,
	netdev@vger.kernel.org, linux-media@vger.kernel.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-wireless@vger.kernel.org,
	megaraidlinux.pdl@broadcom.com, linux-spi@vger.kernel.org,
	linux-fbdev@vger.kernel.org, linux-serial@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-watchdog@vger.kernel.org
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
Date: Wed, 5 Jan 2022 13:47:48 -0600	[thread overview]
Message-ID: <20220105194748.GA215560@bhelgaas> (raw)
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>

On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com>  escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this.  For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors.  Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > > 
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > > 
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > > 
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option.  "Legacy" just
> > > means something old and out of favor; it doesn't say*what*  that
> > > something is.
> > > 
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI?  Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI?  This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.

I'd like to hear Arnd's opinion, too.  If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.

I must be missing something because I don't see what we gain from
this.  We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs.  I think we want to build drivers like that on
any arch that supports PCI.

If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.

But that same driver should still work with devices that have MEM
BARs.  If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly.  IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210

> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
> 
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
> 
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
> 
> Thanks,
> John

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
Date: Wed, 5 Jan 2022 13:47:48 -0600	[thread overview]
Message-ID: <20220105194748.GA215560@bhelgaas> (raw)
In-Reply-To: <3f39d8a2-2e57-a671-2926-eb4f2bf20c76@huawei.com>

On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com>  escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this.  For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors.  Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > > 
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > > 
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > > 
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option.  "Legacy" just
> > > means something old and out of favor; it doesn't say*what*  that
> > > something is.
> > > 
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI?  Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI?  This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.

I'd like to hear Arnd's opinion, too.  If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.

I must be missing something because I don't see what we gain from
this.  We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs.  I think we want to build drivers like that on
any arch that supports PCI.

If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.

But that same driver should still work with devices that have MEM
BARs.  If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly.  IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210

> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
> 
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
> 
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
> 
> Thanks,
> John

  reply	other threads:[~2022-01-05 19:48 UTC|newest]

Thread overview: 323+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 16:42 [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options Niklas Schnelle
2021-12-27 16:42 ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI Niklas Schnelle
2021-12-27 16:42   ` [Intel-wired-lan] " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 17:48   ` Guenter Roeck
2021-12-27 17:48     ` [Intel-wired-lan] " Guenter Roeck
2021-12-27 17:48     ` Guenter Roeck
2021-12-27 17:48     ` Guenter Roeck
2021-12-28  2:09   ` Mauro Carvalho Chehab
2021-12-28  2:09     ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  8:21   ` Greg Kroah-Hartman
2021-12-28  8:21     ` [Intel-wired-lan] " Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  9:15     ` Mauro Carvalho Chehab
2021-12-28  9:15       ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28 10:58       ` Niklas Schnelle
2021-12-28 10:58         ` [Intel-wired-lan] " Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 12:01         ` Greg Kroah-Hartman
2021-12-28 12:01           ` [Intel-wired-lan] " Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:54         ` Mauro Carvalho Chehab
2021-12-28 12:54           ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 15:06           ` Niklas Schnelle
2021-12-28 15:06             ` [Intel-wired-lan] " Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 17:12             ` Mauro Carvalho Chehab
2021-12-28 17:12               ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-29 11:45               ` Niklas Schnelle
2021-12-29 11:45                 ` [Intel-wired-lan] " Niklas Schnelle
2021-12-29 11:45                 ` Niklas Schnelle
2021-12-29 11:45                 ` Niklas Schnelle
2021-12-29 12:12                 ` Mauro Carvalho Chehab
2021-12-29 12:12                   ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-29 12:12                   ` Mauro Carvalho Chehab
2021-12-29 12:12                   ` Mauro Carvalho Chehab
2021-12-29 16:03                   ` Bjorn Helgaas
2021-12-29 16:03                     ` [Intel-wired-lan] " Bjorn Helgaas
2021-12-29 16:03                     ` Bjorn Helgaas
2021-12-29 16:03                     ` Bjorn Helgaas
2021-12-29 16:55                     ` Niklas Schnelle
2021-12-29 16:55                       ` [Intel-wired-lan] " Niklas Schnelle
2021-12-29 16:55                       ` Niklas Schnelle
2021-12-29 16:55                       ` Niklas Schnelle
2022-01-05 17:42                       ` John Garry
2022-01-05 17:42                         ` [Intel-wired-lan] " John Garry
2022-01-05 17:42                         ` John Garry
2022-01-05 17:42                         ` John Garry
2022-01-05 19:47                         ` Bjorn Helgaas [this message]
2022-01-05 19:47                           ` [Intel-wired-lan] " Bjorn Helgaas
2022-01-05 19:47                           ` Bjorn Helgaas
2022-01-05 19:47                           ` Bjorn Helgaas
2022-01-06 17:41                           ` John Garry
2022-01-06 17:41                             ` [Intel-wired-lan] " John Garry
2022-01-06 17:41                             ` John Garry
2022-01-06 18:14                             ` Bjorn Helgaas
2022-01-06 18:14                               ` [Intel-wired-lan] " Bjorn Helgaas
2022-01-06 18:14                               ` Bjorn Helgaas
2022-01-06 18:14                               ` Bjorn Helgaas
2022-01-07 17:16                               ` John Garry
2022-01-07 17:16                                 ` [Intel-wired-lan] " John Garry
2022-01-07 17:16                                 ` John Garry
2022-01-07 17:16                                 ` John Garry
2022-01-10  9:34                             ` Niklas Schnelle
2022-01-10  9:34                               ` [Intel-wired-lan] " Niklas Schnelle
2022-01-10  9:34                               ` Niklas Schnelle
2022-01-10  9:34                               ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` [OpenRISC] " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:08   ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` [OpenRISC] " Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-29  1:20     ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` [OpenRISC] " Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  3:41       ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` [OpenRISC] " Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  4:15         ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` [OpenRISC] " Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-30  1:48           ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` [OpenRISC] " Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  3:44             ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` [OpenRISC] " Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-31 11:28               ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` [OpenRISC] " Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 16:04               ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` [OpenRISC] " Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 21:55                 ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` [OpenRISC] " Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-28 16:32   ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` [OpenRISC] " Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-27 16:42 ` [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:47   ` Rafael J. Wysocki
2021-12-27 16:47     ` Rafael J. Wysocki
2021-12-27 17:02     ` Niklas Schnelle
2021-12-27 17:02       ` Niklas Schnelle
2021-12-27 17:12       ` Rafael J. Wysocki
2021-12-27 17:12         ` Rafael J. Wysocki
2021-12-27 17:15         ` Rafael J. Wysocki
2021-12-27 17:15           ` Rafael J. Wysocki
2021-12-27 17:43           ` Niklas Schnelle
2021-12-27 17:43             ` Niklas Schnelle
2021-12-28 15:20             ` Rafael J. Wysocki
2021-12-28 15:20               ` Rafael J. Wysocki
2021-12-28 16:31               ` Niklas Schnelle
2021-12-28 16:31                 ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 04/32] parport: PC style parport depends on HAS_IOPORT Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:14   ` Geert Uytterhoeven
2021-12-28 10:14     ` Geert Uytterhoeven
2021-12-28 14:21     ` Niklas Schnelle
2021-12-28 14:21       ` Niklas Schnelle
2021-12-29  2:58     ` Arnd Bergmann
2021-12-29  2:58       ` Arnd Bergmann
2021-12-27 16:42 ` [RFC 05/32] char: impi, tpm: depend " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:17   ` Geert Uytterhoeven
2021-12-28 10:17     ` Geert Uytterhoeven
2021-12-28 12:13     ` Niklas Schnelle
2021-12-28 12:13       ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 17:52   ` Samuel Thibault
2021-12-27 17:52     ` Samuel Thibault
2021-12-27 16:42 ` [RFC 07/32] Input: gameport: add ISA and " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 08/32] comedi: Kconfig: add " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 09/32] sound: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 10/32] i2c: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:21   ` Geert Uytterhoeven
2021-12-28 10:21     ` Geert Uytterhoeven
2021-12-28 12:13     ` Niklas Schnelle
2021-12-28 12:13       ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 11/32] Input: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:23   ` Geert Uytterhoeven
2021-12-28 10:23     ` Geert Uytterhoeven
2021-12-27 16:42 ` [RFC 12/32] iio: adc: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:32   ` Geert Uytterhoeven
2021-12-28 10:32     ` Geert Uytterhoeven
2021-12-28 12:50     ` Niklas Schnelle
2021-12-28 12:50       ` Niklas Schnelle
2021-12-28 17:01       ` Jonathan Cameron
2021-12-28 17:01         ` Jonathan Cameron
2022-01-30 15:05         ` Jonathan Cameron
2022-01-30 15:05           ` Jonathan Cameron
2021-12-27 16:42 ` [RFC 13/32] hwmon: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 18:07   ` Guenter Roeck
2021-12-27 18:07     ` Guenter Roeck
2021-12-27 16:42 ` [RFC 14/32] leds: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 15/32] media: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 16/32] misc: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28  8:15   ` Greg Kroah-Hartman
2021-12-28  8:15     ` Greg Kroah-Hartman
2021-12-27 16:43 ` [RFC 17/32] net: Kconfig: add " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 17:28   ` Marc Kleine-Budde
2021-12-27 17:28     ` Marc Kleine-Budde
2021-12-27 16:43 ` [RFC 18/32] pcmcia: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 18:41   ` Dominik Brodowski
2021-12-27 18:41     ` Dominik Brodowski
2021-12-27 16:43 ` [RFC 19/32] platform: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 20/32] pnp: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 21/32] power: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 22/32] video: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 23/32] rtc: Kconfig: add " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 24/32] scsi: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28 10:40   ` Geert Uytterhoeven
2021-12-28 10:40     ` Geert Uytterhoeven
2021-12-27 16:43 ` [RFC 25/32] watchdog: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 18:03   ` Guenter Roeck
2021-12-27 18:03     ` Guenter Roeck
2021-12-28  9:58     ` Niklas Schnelle
2021-12-28  9:58       ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 26/32] drm: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2022-01-03  6:11   ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2021-12-27 16:43 ` [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 22:04   ` Bjorn Helgaas
2021-12-27 22:04     ` Bjorn Helgaas
2021-12-27 16:43 ` [RFC 28/32] PCI: make quirk using inw() " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 22:33   ` Bjorn Helgaas
2021-12-27 22:33     ` Bjorn Helgaas
2021-12-28 15:25     ` Niklas Schnelle
2021-12-28 15:25       ` Niklas Schnelle
2021-12-28 16:35       ` Bjorn Helgaas
2021-12-28 16:35         ` Bjorn Helgaas
2021-12-28 16:52         ` Niklas Schnelle
2021-12-28 16:52           ` Niklas Schnelle
2021-12-28 17:28           ` Bjorn Helgaas
2021-12-28 17:28             ` Bjorn Helgaas
2021-12-27 16:43 ` [RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28  8:17   ` Greg Kroah-Hartman
2021-12-28  8:17     ` Greg Kroah-Hartman
2021-12-29 10:25     ` Niklas Schnelle
2021-12-29 10:25       ` Niklas Schnelle
2021-12-29 10:38       ` Greg Kroah-Hartman
2021-12-29 10:38         ` Greg Kroah-Hartman
2021-12-30 16:19         ` Arnd Bergmann
2021-12-30 16:19           ` Arnd Bergmann
2021-12-27 16:43 ` [RFC 31/32] usb: handle HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 20:36   ` Alan Stern
2021-12-27 20:36     ` Alan Stern
2021-12-31 11:06     ` Niklas Schnelle
2021-12-31 11:06       ` Niklas Schnelle
2021-12-31 17:15       ` Alan Stern
2021-12-31 17:15         ` Alan Stern
2022-01-03 11:35         ` Niklas Schnelle
2022-01-03 11:35           ` Niklas Schnelle
2022-01-03 16:15           ` Alan Stern
2022-01-03 16:15             ` Alan Stern
2021-12-27 16:43 ` [RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2022-01-06 17:45 ` [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options John Garry
2022-01-06 17:45   ` John Garry
2022-01-07  7:21   ` Niklas Schnelle
2022-01-07  7:21     ` Niklas Schnelle
2022-01-07 16:57     ` John Garry
2022-01-07 16:57       ` John Garry

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220105194748.GA215560@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=GR-QLogic-Storage-Upstream@marvell.com \
    --cc=MPT-FusionLinux.pdl@broadcom.com \
    --cc=abbotti@mev.co.uk \
    --cc=anthony.l.nguyen@intel.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=davem@davemloft.net \
    --cc=deanbo422@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ek5.chimenti@gmail.com \
    --cc=forest@alittletooquiet.net \
    --cc=green.hu@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guoren@kernel.org \
    --cc=hare@suse.com \
    --cc=hsweeten@visionengravers.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=isdn@linux-pingi.de \
    --cc=j@w1.fi \
    --cc=jdelvare@suse.com \
    --cc=jejb@linux.ibm.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jirislaby@kernel.org \
    --cc=john.garry@huawei.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=m.grzeschik@pengutronix.de \
    --cc=martin.petersen@oracle.com \
    --cc=mchehab@kernel.org \
    --cc=megaraidlinux.pdl@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=nickhu@andestech.com \
    --cc=njavali@marvell.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=perex@perex.cz \
    --cc=sathya.prakash@broadcom.com \
    --cc=schnelle@linux.ibm.com \
    --cc=shivasharan.srikanteshwara@broadcom.com \
    --cc=sreekanth.reddy@broadcom.com \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=suganath-prabu.subramani@broadcom.com \
    --cc=sumit.saxena@broadcom.com \
    --cc=teddy.wang@siliconmotion.com \
    --cc=tiwai@suse.com \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.