Date:   Thu, 6 Jan 2022 17:41:00 +0000
From:   John Garry <john.garry@...wei.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
CC:     Niklas Schnelle <schnelle@...ux.ibm.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Ettore Chimenti <ek5.chimenti@...il.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.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>,
        "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-serial@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linux-watchdog@...r.kernel.org>
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

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@mail.gmail.com/

> 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

Powered by blists - more mailing lists