dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-fbdev@vger.kernel.org, linux-pci@vger.kernel.org,
	dri-devel@lists.freedesktop.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>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	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, linux-input@vger.kernel.org,
	Jaroslav Kysela <perex@perex.cz>,
	Jean Delvare <jdelvare@suse.com>,
	linux-watchdog@vger.kernel.org,
	Niklas Schnelle <schnelle@linux.ibm.com>, Jouni Malinen <j@w1.fi>,
	Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
	Kalle Valo <kvalo@kernel.org>, John Garry <john.garry@huawei.com>,
	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>,
	Wim Van Sebroeck <wim@linux-watchdog.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>,
	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>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
Date: Wed, 29 Dec 2021 10:03:17 -0600	[thread overview]
Message-ID: <20211229160317.GA1681139@bhelgaas> (raw)
In-Reply-To: <20211229131207.1ac25424@coco.lan>

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.

What if you used the approach from [1] but just dropped the warning?
The inb() would return ~0 if the platform doesn't support I/O port
space.  Drivers should be prepared to handle that because that's what
happens if the device doesn't exist.  

HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
avoids building drivers that aren't useful on s390.  I'm not sure the
benefit outweighs the complication.

Bjorn

[1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/


  reply	other threads:[~2021-12-29 16:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20211227164317.4146918-1-schnelle@linux.ibm.com>
2021-12-27 16:42 ` [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI Niklas Schnelle
2021-12-27 17:48   ` Guenter Roeck
2021-12-28  2:09   ` Mauro Carvalho Chehab
2021-12-28  8:21   ` Greg Kroah-Hartman
2021-12-28  9:15     ` Mauro Carvalho Chehab
2021-12-28 10:58       ` Niklas Schnelle
2021-12-28 12:01         ` Greg Kroah-Hartman
2021-12-28 12:54         ` Mauro Carvalho Chehab
2021-12-28 15:06           ` Niklas Schnelle
2021-12-28 17:12             ` Mauro Carvalho Chehab
2021-12-29 11:45               ` Niklas Schnelle
2021-12-29 12:12                 ` Mauro Carvalho Chehab
2021-12-29 16:03                   ` Bjorn Helgaas [this message]
2021-12-29 16:55                     ` Niklas Schnelle
2022-01-05 17:42                       ` John Garry
2022-01-05 19:47                         ` Bjorn Helgaas
     [not found]                           ` <74bf4fde-3972-1c36-ca04-58089da0d82b@huawei.com>
2022-01-06 18:14                             ` Bjorn Helgaas
2022-01-07 17:16                               ` John Garry
2022-01-10  9:34                             ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 22/32] video: handle HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:43 ` [RFC 26/32] drm: " Niklas Schnelle
2022-01-03  6:11   ` Gerd Hoffmann

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=20211229160317.GA1681139@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@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).