[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ycr8ooFX+w9RGu1M@kroah.com>
Date: Tue, 28 Dec 2021 13:01:38 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Niklas Schnelle <schnelle@...ux.ibm.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Arnd Bergmann <arnd@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
John Garry <john.garry@...wei.com>,
Nick Hu <nickhu@...estech.com>,
Greentime Hu <green.hu@...il.com>,
Vincent Chen <deanbo422@...il.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Guo Ren <guoren@...nel.org>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Ian Abbott <abbotti@....co.uk>,
H Hartley Sweeten <hsweeten@...ionengravers.com>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Karsten Keil <isdn@...ux-pingi.de>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Sathya Prakash <sathya.prakash@...adcom.com>,
Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
Suganath Prabu Subramani
<suganath-prabu.subramani@...adcom.com>,
Michael Grzeschik <m.grzeschik@...gutronix.de>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Kalle Valo <kvalo@...nel.org>, Jouni Malinen <j@...fi>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Hannes Reinecke <hare@...e.com>,
Kashyap Desai <kashyap.desai@...adcom.com>,
Sumit Saxena <sumit.saxena@...adcom.com>,
Shivasharan S <shivasharan.srikanteshwara@...adcom.com>,
Nilesh Javali <njavali@...vell.com>,
GR-QLogic-Storage-Upstream@...vell.com,
Mark Brown <broonie@...nel.org>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Teddy Wang <teddy.wang@...iconmotion.com>,
Forest Bond <forest@...ttletooquiet.net>,
Jiri Slaby <jirislaby@...nel.org>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, linux-pci@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-csky@...r.kernel.org,
linux-ide@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-hwmon@...r.kernel.org, linux-i2c@...r.kernel.org,
linux-input@...r.kernel.org, netdev@...r.kernel.org,
linux-media@...r.kernel.org, MPT-FusionLinux.pdl@...adcom.com,
linux-scsi@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
linux-wireless@...r.kernel.org, megaraidlinux.pdl@...adcom.com,
linux-spi@...r.kernel.org, linux-fbdev@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-serial@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-watchdog@...r.kernel.org,
alsa-devel@...a-project.org
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
Powered by blists - more mailing lists