Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
- From: John Garry <john.garry@xxxxxxxxxx>
- Date: Thu, 6 Jan 2022 17:41:00 +0000
- Cc: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Hans Verkuil <hverkuil-cisco@xxxxxxxxx>, Ettore Chimenti <ek5.chimenti@xxxxxxxxx>, "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxxxx>, Bjorn Helgaas <bhelgaas@xxxxxxxxxx>, Nick Hu <nickhu@xxxxxxxxxxxxx>, Greentime Hu <green.hu@xxxxxxxxx>, Vincent Chen <deanbo422@xxxxxxxxx>, "Paul Walmsley" <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, Albert Ou <aou@xxxxxxxxxxxxxxxxx>, Guo Ren <guoren@xxxxxxxxxx>, "Damien Le Moal" <damien.lemoal@xxxxxxxxxxxxxxxxxx>, Ian Abbott <abbotti@xxxxxxxxx>, "H Hartley Sweeten" <hsweeten@xxxxxxxxxxxxxxxxxxx>, Linus Walleij <linus.walleij@xxxxxxxxxx>, Bartosz Golaszewski <brgl@xxxxxxxx>, Jean Delvare <jdelvare@xxxxxxxx>, Guenter Roeck <linux@xxxxxxxxxxxx>, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>, Karsten Keil <isdn@xxxxxxxxxxxxxx>, "Sathya Prakash" <sathya.prakash@xxxxxxxxxxxx>, Sreekanth Reddy <sreekanth.reddy@xxxxxxxxxxxx>, Suganath Prabu Subramani <suganath-prabu.subramani@xxxxxxxxxxxx>, Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, "Jakub Kicinski" <kuba@xxxxxxxxxx>, Jesse Brandeburg <jesse.brandeburg@xxxxxxxxx>, Tony Nguyen <anthony.l.nguyen@xxxxxxxxx>, Kalle Valo <kvalo@xxxxxxxxxx>, Jouni Malinen <j@xxxxx>, "James E.J. Bottomley" <jejb@xxxxxxxxxxxxx>, "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>, Hannes Reinecke <hare@xxxxxxxx>, Kashyap Desai <kashyap.desai@xxxxxxxxxxxx>, Sumit Saxena <sumit.saxena@xxxxxxxxxxxx>, Shivasharan S <shivasharan.srikanteshwara@xxxxxxxxxxxx>, Nilesh Javali <njavali@xxxxxxxxxxx>, <GR-QLogic-Storage-Upstream@xxxxxxxxxxx>, Mark Brown <broonie@xxxxxxxxxx>, Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>, "Teddy Wang" <teddy.wang@xxxxxxxxxxxxxxxxx>, Forest Bond <forest@xxxxxxxxxxxxxxxxxxx>, Jiri Slaby <jirislaby@xxxxxxxxxx>, "Wim Van Sebroeck" <wim@xxxxxxxxxxxxxxxxxx>, Jaroslav Kysela <perex@xxxxxxxx>, "Takashi Iwai" <tiwai@xxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <linux-arch@xxxxxxxxxxxxxxx>, <linux-pci@xxxxxxxxxxxxxxx>, <linux-riscv@xxxxxxxxxxxxxxxxxxx>, <linux-csky@xxxxxxxxxxxxxxx>, <linux-ide@xxxxxxxxxxxxxxx>, <linux-gpio@xxxxxxxxxxxxxxx>, <linux-hwmon@xxxxxxxxxxxxxxx>, <linux-i2c@xxxxxxxxxxxxxxx>, <linux-input@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxxxxxx>, <linux-media@xxxxxxxxxxxxxxx>, <MPT-FusionLinux.pdl@xxxxxxxxxxxx>, <linux-scsi@xxxxxxxxxxxxxxx>, <intel-wired-lan@xxxxxxxxxxxxxxxx>, <linux-wireless@xxxxxxxxxxxxxxx>, <megaraidlinux.pdl@xxxxxxxxxxxx>, <linux-spi@xxxxxxxxxxxxxxx>, <linux-fbdev@xxxxxxxxxxxxxxx>, <linux-serial@xxxxxxxxxxxxxxx>, <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, <linux-watchdog@xxxxxxxxxxxxxxx>
- In-reply-to: <20220105194748.GA215560@bhelgaas>
- References: <20220105194748.GA215560@bhelgaas>
- User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
On 05/01/2022 19:47, Bjorn Helgaas wrote:
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.
There were some ifdefs added to the 8250 drivers in Arnd's original
patch [0], but it does not seem included here.
Niklas, what happened to the 8250 and the other driver changes?
[0]
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@xxxxxxxxxxxxxx/
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
That driver would prob not be used on systems which does not support
PIO, and so could have a HAS_IOPORT dependency. But it is not strictly
necessary.
Anyway, it would be good to have an idea of how much ifdeffery is
required in drivers.
Thanks,
John
[Index of Archives]
[Linux Kernel]
[Linux ARM (vger)]
[Linux ARM MSM]
[Linux Omap]
[Linux Arm]
[Linux Tegra]
[Fedora ARM]
[Linux for Samsung SOC]
[eCos]
[Linux Fastboot]
[Gcc Help]
[Git]
[DCCP]
[IETF Announce]
[Security]
[Linux MIPS]
[Yosemite Campsites]
|