From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66AE3C433FE for ; Wed, 29 Dec 2021 16:04:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237303AbhL2QDZ (ORCPT ); Wed, 29 Dec 2021 11:03:25 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:54328 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229528AbhL2QDU (ORCPT ); Wed, 29 Dec 2021 11:03:20 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C75F16151F; Wed, 29 Dec 2021 16:03:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8504C36AE7; Wed, 29 Dec 2021 16:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640793799; bh=JjpeFlX1D08ft528esGQ/Dmp3d8gak2dGxLVU5277kI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=JpP2t1WEsiIyRq1md3yeDJqKD5b+v6vPK3dQL5KYtPRU6IzcCE2hfeoejuHeG11gd lC8IFpViEh+GNBkNBx4n5nW244Tql53dIjOETTsQ8i+5UfJvW9Ilc8EhjCT4Q4lOA4 QM42sYWxI3kXC/do4dsN3O/F/5QTnKyWIH4D+TjWyd3Qv8ZelIjD6sZhRig841ypqR mTWsO71n3E7t2fJyuxqamjyrcVx+C0YBZwG9aCQStF11NC5RlZEPgKB5Mk28JwNuWp wwR/on9msDkJi5KBJfEq5mX9Wm2DfRpIzk3oUTTCtQJyiHOzO2W6s1m8x+iPToCIeX pL3LlEJMF3ouw== Date: Wed, 29 Dec 2021 10:03:17 -0600 From: Bjorn Helgaas To: Mauro Carvalho Chehab Cc: Niklas Schnelle , Hans Verkuil , Ettore Chimenti , Greg Kroah-Hartman , Arnd Bergmann , Bjorn Helgaas , John Garry , Nick Hu , Greentime Hu , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Albert Ou , Guo Ren , Damien Le Moal , Ian Abbott , H Hartley Sweeten , Linus Walleij , Bartosz Golaszewski , Jean Delvare , Guenter Roeck , Dmitry Torokhov , Karsten Keil , Sathya Prakash , Sreekanth Reddy , Suganath Prabu Subramani , Michael Grzeschik , "David S. Miller" , Jakub Kicinski , Jesse Brandeburg , Tony Nguyen , Kalle Valo , Jouni Malinen , "James E.J. Bottomley" , "Martin K. Petersen" , Hannes Reinecke , Kashyap Desai , Sumit Saxena , Shivasharan S , Nilesh Javali , GR-QLogic-Storage-Upstream@marvell.com, Mark Brown , Sudip Mukherjee , Teddy Wang , Forest Bond , Jiri Slaby , Wim Van Sebroeck , Jaroslav Kysela , Takashi Iwai , 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 Message-ID: <20211229160317.GA1681139@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211229131207.1ac25424@coco.lan> Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1075CC433F5 for ; Wed, 29 Dec 2021 16:03:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=RzoP9KHLCmh7LXfb8UhAKIVktOB/YWnnIAxAnQbpHBk=; b=tb3G/rzsCwFrRk YbnsHYiMp+Wwl16Pw+/yedfNmoef9NvK6bBJl8sMXY+QgOv/e/MheiqFZqvsqajW2Eef4cdaQoJms 6o6rZkFmDmqA2qZqoVNItLqN/U0r5jKRHpX72KKOdzLPvhGm6KKSBMiG9WjZ5swFY0YryieXziVvu +Tu9Qju5MZvG8qmyvMaK+2T4ViphcXI2Tt8paNs8vf/tr3glBsvs443lRn/B0ktdPjb8omjRGVMOm unGP9SfIg+Y4PnSL+Of5X5ScUb1vIs9AV+dMffck32CBEtIogU9+9a/Q0GmrFTRa25KqVShmpBlKf CLh4FfkpyR9l+G3HZ0Kw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2bQB-0035aJ-OX; Wed, 29 Dec 2021 16:03:23 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2bQ9-0035ZX-7P for linux-riscv@lists.infradead.org; Wed, 29 Dec 2021 16:03:22 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C5F876150C; Wed, 29 Dec 2021 16:03:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8504C36AE7; Wed, 29 Dec 2021 16:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640793799; bh=JjpeFlX1D08ft528esGQ/Dmp3d8gak2dGxLVU5277kI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=JpP2t1WEsiIyRq1md3yeDJqKD5b+v6vPK3dQL5KYtPRU6IzcCE2hfeoejuHeG11gd lC8IFpViEh+GNBkNBx4n5nW244Tql53dIjOETTsQ8i+5UfJvW9Ilc8EhjCT4Q4lOA4 QM42sYWxI3kXC/do4dsN3O/F/5QTnKyWIH4D+TjWyd3Qv8ZelIjD6sZhRig841ypqR mTWsO71n3E7t2fJyuxqamjyrcVx+C0YBZwG9aCQStF11NC5RlZEPgKB5Mk28JwNuWp wwR/on9msDkJi5KBJfEq5mX9Wm2DfRpIzk3oUTTCtQJyiHOzO2W6s1m8x+iPToCIeX pL3LlEJMF3ouw== Date: Wed, 29 Dec 2021 10:03:17 -0600 From: Bjorn Helgaas To: Mauro Carvalho Chehab Cc: Niklas Schnelle , Hans Verkuil , Ettore Chimenti , Greg Kroah-Hartman , Arnd Bergmann , Bjorn Helgaas , John Garry , Nick Hu , Greentime Hu , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Albert Ou , Guo Ren , Damien Le Moal , Ian Abbott , H Hartley Sweeten , Linus Walleij , Bartosz Golaszewski , Jean Delvare , Guenter Roeck , Dmitry Torokhov , Karsten Keil , Sathya Prakash , Sreekanth Reddy , Suganath Prabu Subramani , Michael Grzeschik , "David S. Miller" , Jakub Kicinski , Jesse Brandeburg , Tony Nguyen , Kalle Valo , Jouni Malinen , "James E.J. Bottomley" , "Martin K. Petersen" , Hannes Reinecke , Kashyap Desai , Sumit Saxena , Shivasharan S , Nilesh Javali , GR-QLogic-Storage-Upstream@marvell.com, Mark Brown , Sudip Mukherjee , Teddy Wang , Forest Bond , Jiri Slaby , Wim Van Sebroeck , Jaroslav Kysela , Takashi Iwai , 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 Message-ID: <20211229160317.GA1681139@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211229131207.1ac25424@coco.lan> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211229_080321_391339_25DEE291 X-CRM114-Status: GOOD ( 25.00 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 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/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7E0B4C433F5 for ; Wed, 29 Dec 2021 16:03:22 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C1BC910E1DF; Wed, 29 Dec 2021 16:03:21 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 830D810E1DF for ; Wed, 29 Dec 2021 16:03:20 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C5F876150C; Wed, 29 Dec 2021 16:03:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8504C36AE7; Wed, 29 Dec 2021 16:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640793799; bh=JjpeFlX1D08ft528esGQ/Dmp3d8gak2dGxLVU5277kI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=JpP2t1WEsiIyRq1md3yeDJqKD5b+v6vPK3dQL5KYtPRU6IzcCE2hfeoejuHeG11gd lC8IFpViEh+GNBkNBx4n5nW244Tql53dIjOETTsQ8i+5UfJvW9Ilc8EhjCT4Q4lOA4 QM42sYWxI3kXC/do4dsN3O/F/5QTnKyWIH4D+TjWyd3Qv8ZelIjD6sZhRig841ypqR mTWsO71n3E7t2fJyuxqamjyrcVx+C0YBZwG9aCQStF11NC5RlZEPgKB5Mk28JwNuWp wwR/on9msDkJi5KBJfEq5mX9Wm2DfRpIzk3oUTTCtQJyiHOzO2W6s1m8x+iPToCIeX pL3LlEJMF3ouw== Date: Wed, 29 Dec 2021 10:03:17 -0600 From: Bjorn Helgaas To: Mauro Carvalho Chehab Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI Message-ID: <20211229160317.GA1681139@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211229131207.1ac25424@coco.lan> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fbdev@vger.kernel.org, linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org, Ettore Chimenti , linux-ide@vger.kernel.org, Albert Ou , Guo Ren , linux-i2c@vger.kernel.org, linux-riscv@lists.infradead.org, Vincent Chen , Jiri Slaby , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Hannes Reinecke , Michael Grzeschik , linux-scsi@vger.kernel.org, Sumit Saxena , Damien Le Moal , Sathya Prakash , Jesse Brandeburg , linux-csky@vger.kernel.org, Kashyap Desai , Nilesh Javali , intel-wired-lan@lists.osuosl.org, linux-serial@vger.kernel.org, GR-QLogic-Storage-Upstream@marvell.com, Jakub Kicinski , MPT-FusionLinux.pdl@broadcom.com, "James E.J. Bottomley" , Guenter Roeck , linux-media@vger.kernel.org, linux-input@vger.kernel.org, Jaroslav Kysela , Jean Delvare , linux-watchdog@vger.kernel.org, Niklas Schnelle , Jouni Malinen , Suganath Prabu Subramani , Kalle Valo , John Garry , linux-spi@vger.kernel.org, linux-gpio@vger.kernel.org, Ian Abbott , Mark Brown , Greentime Hu , Paul Walmsley , Bjorn Helgaas , Wim Van Sebroeck , megaraidlinux.pdl@broadcom.com, Teddy Wang , linux-hwmon@vger.kernel.org, Arnd Bergmann , Karsten Keil , Sreekanth Reddy , "Martin K. Petersen" , Nick Hu , Sudip Mukherjee , Shivasharan S , Greg Kroah-Hartman , Dmitry Torokhov , linux-wireless@vger.kernel.org, Takashi Iwai , "David S. Miller" , H Hartley Sweeten , Palmer Dabbelt , Forest Bond , netdev@vger.kernel.org, Hans Verkuil , Tony Nguyen , Bartosz Golaszewski Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Date: Wed, 29 Dec 2021 10:03:17 -0600 Subject: [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI In-Reply-To: <20211229131207.1ac25424@coco.lan> Message-ID: <20211229160317.GA1681139@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: 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 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 at mail.gmail.com/