From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B8F129CA for ; Tue, 28 Dec 2021 15:07:06 +0000 (UTC) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BSECJcm008197; Tue, 28 Dec 2021 15:06:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=kv/9MsxzrAL1HOwlhXTckibLYzdBhACAK/Lo6rhPS2g=; b=PEd05NFKBSQTMV+eMuNK5qNKFOQLlVaOGS0uOgw+PkR79Ycv8KvCBupVjjeuhIj+6iJb B4MH8Jl/byKU9XowseLvavfqkbEDmBTwi5YSyt9pg6Ss/fcnfnlfhMtsh8vcROBZn0C8 oxYwtUNOwqfMNCRDsaE41ahvdUk6Oi++JPslOWelyO89X4O2kgqhdwRJvJ1YN/eyjMDi KEEFu48kqVxId1kYYRT6Pz2iK0+g9iXiKBY24iESH4osAWFpuPqGqYJA8yz+xDVi8A4v P/h3j8r9CMTkzsTl30kkqUJge08IU4ZgCocxxF/Xyg/E4HcMQ7wvAUO7gGDt++kqqgyO wQ== Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com with ESMTP id 3d844q101h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:53 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1BSF2Mqm006196; Tue, 28 Dec 2021 15:06:51 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 3d5tjjh632-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:51 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1BSF6nFq31130018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Dec 2021 15:06:49 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0EE8A404D; Tue, 28 Dec 2021 15:06:48 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5F37A4040; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Received: from sig-9-145-12-118.uk.ibm.com (unknown [9.145.12.118]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Message-ID: <4b630b7b87bd983291f628c42a1394fc0d2d86bd.camel@linux.ibm.com> Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI From: Niklas Schnelle To: Mauro Carvalho Chehab , Bjorn Helgaas Cc: 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 , Hans Verkuil , 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-staging@lists.linux.dev, linux-serial@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-watchdog@vger.kernel.org, alsa-devel@alsa-project.org Date: Tue, 28 Dec 2021 16:06:44 +0100 In-Reply-To: <20211228135425.0a69168c@coco.lan> References: <20211227164317.4146918-1-schnelle@linux.ibm.com> <20211227164317.4146918-2-schnelle@linux.ibm.com> <20211228101435.3a55b983@coco.lan> <20211228135425.0a69168c@coco.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg X-Proofpoint-ORIG-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-28_08,2021-12-28_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 suspectscore=0 impostorscore=0 malwarescore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280069 On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote: > ---8<--- > > > > > All you really care about is the "legacy" I/O spaces here, this isn't > > > > tied to PCI specifically at all, right? > > > > > > > > So why not just have a OLD_STYLE_IO config option or something like > > > > that, to show that it's the i/o functions we care about here, not PCI at > > > > all? > > > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward, > > > > just describe it as it is, "DIRECT_IO"? > > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate > > > name for it. > > > > > > Thanks, > > > Mauro > > > > Hmm, I might be missing something here but that sounds a lot like the > > HAS_IOPORT option added in patch 02. > > > > 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. > > I didn't look at the other patches on this series, but why it is needed > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y > where LEGACY_PCI shall be "n"? In the current patch set LEGACY_PCI is not currently selected by architectures, though of course it could be if we know that an architecture requires it. We should probably also set it in any defconfig that has devices depending on it so as not to break these. Other than that it would be set during kernel configuration if one wants/needs support for legacy PCI devices. For testing I ran with HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X based workstation and Raspberry Pi 4 (DT). I guess at the moment it would make most sense for special configs such as those tailored for vitualization guets but in the end that would be something for distributions to decide. Arnd described the options here: https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/ > > > 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." > > I would still avoid calling it LEGACY_PCI, as this sounds too generic. > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more > features that were/will be deprecated on PCI specs as time goes by. > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy" > means. Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like LEGACY_PCI is pretty clear since most devices are either pre-PCIe devices or a compatibility feature allowing drivers for a pre-PCIe device to work with a PCIe device. > > > These two separate config options allow us to compile without support > > for these legacy PCI devices even on a system where inb()/outb() and > > friends are required for some PC style devices and for example ACPI. > > Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI? > > > @@ -172,6 +177,7 @@ config SND_AZT3328 > > > > config SND_BT87X > > tristate "Bt87x Audio Capture" > > + depends on LEGACY_PCI > > select SND_PCM > > help > > If you want to record audio from TV cards based on > > I couldn't find any usage of inb/outb & friends on it: > > $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c > > It uses, instead, readl/writel: > > static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg) > { > return readl(chip->mmio + reg); > } > > static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value) > { > writel(value, chip->mmio + reg); > } > > I failed to see what makes it different from VIDEO_BT848 and > DVB_BT8XX drivers. They all support exactly the same chipset: > Brooktree/Conexant BT8xx. On those devices, depending on the exact > model, up to three separate interfaces are provided, each one with > its own Kconfig var: > > - audio I/O (SND_BT87X); > - video I/O (VIDEO_BT848); > - MPEG-TS I/O (DVB_BT8XX). > > Thanks, > Mauro You're right, that makes no sense this doesn't seem to require LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on PCI" which could have caused issues with HAVE_PCI=n rand configs. 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 924FBC433EF for ; Tue, 28 Dec 2021 15:15:02 +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:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eGNYYP7G3hRkl0Hnvo89bRuwLolkzJDO+ilScZO3F0w=; b=dLYwSkBvbZufAW b3dno19jQw7D4WfQbM9WookCForM7zG4odgfveU+fkkbjVGmlyHPJN9qrnTCT7HTKCIlVrt29kmmk dxOj11gcHaidEc2EfD/o6Vt5zqUaRHxQUi3GAtnRNvtRE7mjJnIyMNGjItJtQBN1An7yctwbc8VrP 7TfSKsPO3p9eKLSNGapCLK18w6g2wgdzsuj1X3x9d0Kfn811Of0wLl4DXtpcuCHieAaeLa5BaO+fE exlTutfk5KzQ11XBXvAb8MLy3HmegwxqAgkXgFbXCVfJOBPfU74gg0/sPsE8L8atFIaTIFMRP49RK EDN8UJXcl0k/IVf8yAzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2EBh-001Odw-Bv; Tue, 28 Dec 2021 15:14:53 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2E47-001KqO-Tt for linux-riscv@lists.infradead.org; Tue, 28 Dec 2021 15:07:05 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BSECJcm008197; Tue, 28 Dec 2021 15:06:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=kv/9MsxzrAL1HOwlhXTckibLYzdBhACAK/Lo6rhPS2g=; b=PEd05NFKBSQTMV+eMuNK5qNKFOQLlVaOGS0uOgw+PkR79Ycv8KvCBupVjjeuhIj+6iJb B4MH8Jl/byKU9XowseLvavfqkbEDmBTwi5YSyt9pg6Ss/fcnfnlfhMtsh8vcROBZn0C8 oxYwtUNOwqfMNCRDsaE41ahvdUk6Oi++JPslOWelyO89X4O2kgqhdwRJvJ1YN/eyjMDi KEEFu48kqVxId1kYYRT6Pz2iK0+g9iXiKBY24iESH4osAWFpuPqGqYJA8yz+xDVi8A4v P/h3j8r9CMTkzsTl30kkqUJge08IU4ZgCocxxF/Xyg/E4HcMQ7wvAUO7gGDt++kqqgyO wQ== Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com with ESMTP id 3d844q101h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:53 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1BSF2Mqm006196; Tue, 28 Dec 2021 15:06:51 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 3d5tjjh632-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:51 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1BSF6nFq31130018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Dec 2021 15:06:49 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0EE8A404D; Tue, 28 Dec 2021 15:06:48 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5F37A4040; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Received: from sig-9-145-12-118.uk.ibm.com (unknown [9.145.12.118]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Message-ID: <4b630b7b87bd983291f628c42a1394fc0d2d86bd.camel@linux.ibm.com> Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI From: Niklas Schnelle To: Mauro Carvalho Chehab , Bjorn Helgaas Cc: 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 , Hans Verkuil , 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-staging@lists.linux.dev, linux-serial@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-watchdog@vger.kernel.org, alsa-devel@alsa-project.org Date: Tue, 28 Dec 2021 16:06:44 +0100 In-Reply-To: <20211228135425.0a69168c@coco.lan> References: <20211227164317.4146918-1-schnelle@linux.ibm.com> <20211227164317.4146918-2-schnelle@linux.ibm.com> <20211228101435.3a55b983@coco.lan> <20211228135425.0a69168c@coco.lan> X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg X-Proofpoint-ORIG-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-28_08,2021-12-28_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 suspectscore=0 impostorscore=0 malwarescore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280069 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211228_070704_115421_4C7DF8CC X-CRM114-Status: GOOD ( 52.44 ) 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 Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote: > ---8<--- > > > > > All you really care about is the "legacy" I/O spaces here, this isn't > > > > tied to PCI specifically at all, right? > > > > > > > > So why not just have a OLD_STYLE_IO config option or something like > > > > that, to show that it's the i/o functions we care about here, not PCI at > > > > all? > > > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward, > > > > just describe it as it is, "DIRECT_IO"? > > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate > > > name for it. > > > > > > Thanks, > > > Mauro > > > > Hmm, I might be missing something here but that sounds a lot like the > > HAS_IOPORT option added in patch 02. > > > > 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. > > I didn't look at the other patches on this series, but why it is needed > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y > where LEGACY_PCI shall be "n"? In the current patch set LEGACY_PCI is not currently selected by architectures, though of course it could be if we know that an architecture requires it. We should probably also set it in any defconfig that has devices depending on it so as not to break these. Other than that it would be set during kernel configuration if one wants/needs support for legacy PCI devices. For testing I ran with HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X based workstation and Raspberry Pi 4 (DT). I guess at the moment it would make most sense for special configs such as those tailored for vitualization guets but in the end that would be something for distributions to decide. Arnd described the options here: https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/ > > > 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." > > I would still avoid calling it LEGACY_PCI, as this sounds too generic. > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more > features that were/will be deprecated on PCI specs as time goes by. > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy" > means. Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like LEGACY_PCI is pretty clear since most devices are either pre-PCIe devices or a compatibility feature allowing drivers for a pre-PCIe device to work with a PCIe device. > > > These two separate config options allow us to compile without support > > for these legacy PCI devices even on a system where inb()/outb() and > > friends are required for some PC style devices and for example ACPI. > > Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI? > > > @@ -172,6 +177,7 @@ config SND_AZT3328 > > > > config SND_BT87X > > tristate "Bt87x Audio Capture" > > + depends on LEGACY_PCI > > select SND_PCM > > help > > If you want to record audio from TV cards based on > > I couldn't find any usage of inb/outb & friends on it: > > $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c > > It uses, instead, readl/writel: > > static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg) > { > return readl(chip->mmio + reg); > } > > static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value) > { > writel(value, chip->mmio + reg); > } > > I failed to see what makes it different from VIDEO_BT848 and > DVB_BT8XX drivers. They all support exactly the same chipset: > Brooktree/Conexant BT8xx. On those devices, depending on the exact > model, up to three separate interfaces are provided, each one with > its own Kconfig var: > > - audio I/O (SND_BT87X); > - video I/O (VIDEO_BT848); > - MPEG-TS I/O (DVB_BT8XX). > > Thanks, > Mauro You're right, that makes no sense this doesn't seem to require LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on PCI" which could have caused issues with HAVE_PCI=n rand configs. _______________________________________________ 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 EFC65C433F5 for ; Wed, 29 Dec 2021 14:24:22 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 4090617E3; Wed, 29 Dec 2021 15:23:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4090617E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1640787861; bh=2zb2AHtKTENNiuM/WzjnWK1mLlZjEoDIneMaA9QLpkI=; h=Subject:From:To:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=HSjHgt/l/p/RiKVdU6LaFG11wjQbQBd6mQehtfCVe5hbsEiWZtL6V6ZjqnEpuy8cp fXZQV9lJXJJYs9LbNmdAxNUn5BYHbxuJzBo0UqYuSWszEnuz05KAYTmmHmc/ezWtYo Ln7wkZYlDka/iMM/3cx1XmwDpTlsCu+R4ezfFSN0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 8CD24F80529; Wed, 29 Dec 2021 15:20:51 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 63FA6F80224; Tue, 28 Dec 2021 16:07:01 +0100 (CET) Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6009DF800E9 for ; Tue, 28 Dec 2021 16:06:57 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6009DF800E9 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="PEd05NFK" Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BSET01H028158; Tue, 28 Dec 2021 15:06:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=kv/9MsxzrAL1HOwlhXTckibLYzdBhACAK/Lo6rhPS2g=; b=PEd05NFKBSQTMV+eMuNK5qNKFOQLlVaOGS0uOgw+PkR79Ycv8KvCBupVjjeuhIj+6iJb B4MH8Jl/byKU9XowseLvavfqkbEDmBTwi5YSyt9pg6Ss/fcnfnlfhMtsh8vcROBZn0C8 oxYwtUNOwqfMNCRDsaE41ahvdUk6Oi++JPslOWelyO89X4O2kgqhdwRJvJ1YN/eyjMDi KEEFu48kqVxId1kYYRT6Pz2iK0+g9iXiKBY24iESH4osAWFpuPqGqYJA8yz+xDVi8A4v P/h3j8r9CMTkzsTl30kkqUJge08IU4ZgCocxxF/Xyg/E4HcMQ7wvAUO7gGDt++kqqgyO wQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3d80wrw8tn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:54 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1BSExtnS030538; Tue, 28 Dec 2021 15:06:53 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 3d80wrw8st-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:53 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1BSF2Mqm006196; Tue, 28 Dec 2021 15:06:51 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 3d5tjjh632-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:51 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1BSF6nFq31130018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Dec 2021 15:06:49 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0EE8A404D; Tue, 28 Dec 2021 15:06:48 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5F37A4040; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Received: from sig-9-145-12-118.uk.ibm.com (unknown [9.145.12.118]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Message-ID: <4b630b7b87bd983291f628c42a1394fc0d2d86bd.camel@linux.ibm.com> Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI From: Niklas Schnelle To: Mauro Carvalho Chehab , Bjorn Helgaas Date: Tue, 28 Dec 2021 16:06:44 +0100 In-Reply-To: <20211228135425.0a69168c@coco.lan> References: <20211227164317.4146918-1-schnelle@linux.ibm.com> <20211227164317.4146918-2-schnelle@linux.ibm.com> <20211228101435.3a55b983@coco.lan> <20211228135425.0a69168c@coco.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: -eqd8vE8YN332zOYBmRbK_MyClnDr0rZ X-Proofpoint-GUID: a5zZ8HmeOUhjPYaiN5aQw9hqORDsOmdt Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-28_08,2021-12-28_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 malwarescore=0 adultscore=0 bulkscore=0 spamscore=0 phishscore=0 suspectscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280069 X-Mailman-Approved-At: Wed, 29 Dec 2021 15:20:41 +0100 Cc: linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev, linux-pci@vger.kernel.org, Linus Walleij , alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org, linux-ide@vger.kernel.org, Jean Delvare , 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, Albert Ou , linux-watchdog@vger.kernel.org, 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 X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote: > ---8<--- > > > > > All you really care about is the "legacy" I/O spaces here, this isn't > > > > tied to PCI specifically at all, right? > > > > > > > > So why not just have a OLD_STYLE_IO config option or something like > > > > that, to show that it's the i/o functions we care about here, not PCI at > > > > all? > > > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward, > > > > just describe it as it is, "DIRECT_IO"? > > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate > > > name for it. > > > > > > Thanks, > > > Mauro > > > > Hmm, I might be missing something here but that sounds a lot like the > > HAS_IOPORT option added in patch 02. > > > > 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. > > I didn't look at the other patches on this series, but why it is needed > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y > where LEGACY_PCI shall be "n"? In the current patch set LEGACY_PCI is not currently selected by architectures, though of course it could be if we know that an architecture requires it. We should probably also set it in any defconfig that has devices depending on it so as not to break these. Other than that it would be set during kernel configuration if one wants/needs support for legacy PCI devices. For testing I ran with HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X based workstation and Raspberry Pi 4 (DT). I guess at the moment it would make most sense for special configs such as those tailored for vitualization guets but in the end that would be something for distributions to decide. Arnd described the options here: https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/ > > > 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." > > I would still avoid calling it LEGACY_PCI, as this sounds too generic. > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more > features that were/will be deprecated on PCI specs as time goes by. > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy" > means. Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like LEGACY_PCI is pretty clear since most devices are either pre-PCIe devices or a compatibility feature allowing drivers for a pre-PCIe device to work with a PCIe device. > > > These two separate config options allow us to compile without support > > for these legacy PCI devices even on a system where inb()/outb() and > > friends are required for some PC style devices and for example ACPI. > > Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI? > > > @@ -172,6 +177,7 @@ config SND_AZT3328 > > > > config SND_BT87X > > tristate "Bt87x Audio Capture" > > + depends on LEGACY_PCI > > select SND_PCM > > help > > If you want to record audio from TV cards based on > > I couldn't find any usage of inb/outb & friends on it: > > $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c > > It uses, instead, readl/writel: > > static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg) > { > return readl(chip->mmio + reg); > } > > static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value) > { > writel(value, chip->mmio + reg); > } > > I failed to see what makes it different from VIDEO_BT848 and > DVB_BT8XX drivers. They all support exactly the same chipset: > Brooktree/Conexant BT8xx. On those devices, depending on the exact > model, up to three separate interfaces are provided, each one with > its own Kconfig var: > > - audio I/O (SND_BT87X); > - video I/O (VIDEO_BT848); > - MPEG-TS I/O (DVB_BT8XX). > > Thanks, > Mauro You're right, that makes no sense this doesn't seem to require LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on PCI" which could have caused issues with HAVE_PCI=n rand configs. 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 E5FF9C433F5 for ; Thu, 30 Dec 2021 17:17:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3542810E203; Thu, 30 Dec 2021 17:17:02 +0000 (UTC) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0447B10EC36 for ; Tue, 28 Dec 2021 15:07:02 +0000 (UTC) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BSECJcm008197; Tue, 28 Dec 2021 15:06:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=kv/9MsxzrAL1HOwlhXTckibLYzdBhACAK/Lo6rhPS2g=; b=PEd05NFKBSQTMV+eMuNK5qNKFOQLlVaOGS0uOgw+PkR79Ycv8KvCBupVjjeuhIj+6iJb B4MH8Jl/byKU9XowseLvavfqkbEDmBTwi5YSyt9pg6Ss/fcnfnlfhMtsh8vcROBZn0C8 oxYwtUNOwqfMNCRDsaE41ahvdUk6Oi++JPslOWelyO89X4O2kgqhdwRJvJ1YN/eyjMDi KEEFu48kqVxId1kYYRT6Pz2iK0+g9iXiKBY24iESH4osAWFpuPqGqYJA8yz+xDVi8A4v P/h3j8r9CMTkzsTl30kkqUJge08IU4ZgCocxxF/Xyg/E4HcMQ7wvAUO7gGDt++kqqgyO wQ== Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com with ESMTP id 3d844q101h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:53 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1BSF2Mqm006196; Tue, 28 Dec 2021 15:06:51 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 3d5tjjh632-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:06:51 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1BSF6nFq31130018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Dec 2021 15:06:49 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0EE8A404D; Tue, 28 Dec 2021 15:06:48 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5F37A4040; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Received: from sig-9-145-12-118.uk.ibm.com (unknown [9.145.12.118]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 28 Dec 2021 15:06:44 +0000 (GMT) Message-ID: <4b630b7b87bd983291f628c42a1394fc0d2d86bd.camel@linux.ibm.com> Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI From: Niklas Schnelle To: Mauro Carvalho Chehab , Bjorn Helgaas Date: Tue, 28 Dec 2021 16:06:44 +0100 In-Reply-To: <20211228135425.0a69168c@coco.lan> References: <20211227164317.4146918-1-schnelle@linux.ibm.com> <20211227164317.4146918-2-schnelle@linux.ibm.com> <20211228101435.3a55b983@coco.lan> <20211228135425.0a69168c@coco.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg X-Proofpoint-ORIG-GUID: aDtjwJ0yJYgJhEo1m1A3tQqPr1E90Ptg Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-28_08,2021-12-28_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 suspectscore=0 impostorscore=0 malwarescore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280069 X-Mailman-Approved-At: Thu, 30 Dec 2021 17:17:01 +0000 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-staging@lists.linux.dev, linux-pci@vger.kernel.org, alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org, Jaroslav Kysela , linux-ide@vger.kernel.org, Jean Delvare , 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, Albert Ou , linux-watchdog@vger.kernel.org, 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 Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote: > ---8<--- > > > > > All you really care about is the "legacy" I/O spaces here, this isn't > > > > tied to PCI specifically at all, right? > > > > > > > > So why not just have a OLD_STYLE_IO config option or something like > > > > that, to show that it's the i/o functions we care about here, not PCI at > > > > all? > > > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward, > > > > just describe it as it is, "DIRECT_IO"? > > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate > > > name for it. > > > > > > Thanks, > > > Mauro > > > > Hmm, I might be missing something here but that sounds a lot like the > > HAS_IOPORT option added in patch 02. > > > > 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. > > I didn't look at the other patches on this series, but why it is needed > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y > where LEGACY_PCI shall be "n"? In the current patch set LEGACY_PCI is not currently selected by architectures, though of course it could be if we know that an architecture requires it. We should probably also set it in any defconfig that has devices depending on it so as not to break these. Other than that it would be set during kernel configuration if one wants/needs support for legacy PCI devices. For testing I ran with HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X based workstation and Raspberry Pi 4 (DT). I guess at the moment it would make most sense for special configs such as those tailored for vitualization guets but in the end that would be something for distributions to decide. Arnd described the options here: https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/ > > > 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." > > I would still avoid calling it LEGACY_PCI, as this sounds too generic. > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more > features that were/will be deprecated on PCI specs as time goes by. > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy" > means. Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like LEGACY_PCI is pretty clear since most devices are either pre-PCIe devices or a compatibility feature allowing drivers for a pre-PCIe device to work with a PCIe device. > > > These two separate config options allow us to compile without support > > for these legacy PCI devices even on a system where inb()/outb() and > > friends are required for some PC style devices and for example ACPI. > > Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI? > > > @@ -172,6 +177,7 @@ config SND_AZT3328 > > > > config SND_BT87X > > tristate "Bt87x Audio Capture" > > + depends on LEGACY_PCI > > select SND_PCM > > help > > If you want to record audio from TV cards based on > > I couldn't find any usage of inb/outb & friends on it: > > $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c > > It uses, instead, readl/writel: > > static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg) > { > return readl(chip->mmio + reg); > } > > static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value) > { > writel(value, chip->mmio + reg); > } > > I failed to see what makes it different from VIDEO_BT848 and > DVB_BT8XX drivers. They all support exactly the same chipset: > Brooktree/Conexant BT8xx. On those devices, depending on the exact > model, up to three separate interfaces are provided, each one with > its own Kconfig var: > > - audio I/O (SND_BT87X); > - video I/O (VIDEO_BT848); > - MPEG-TS I/O (DVB_BT8XX). > > Thanks, > Mauro You're right, that makes no sense this doesn't seem to require LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on PCI" which could have caused issues with HAVE_PCI=n rand configs. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Niklas Schnelle Date: Tue, 28 Dec 2021 16:06:44 +0100 Subject: [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI In-Reply-To: <20211228135425.0a69168c@coco.lan> References: <20211227164317.4146918-1-schnelle@linux.ibm.com> <20211227164317.4146918-2-schnelle@linux.ibm.com> <20211228101435.3a55b983@coco.lan> <20211228135425.0a69168c@coco.lan> Message-ID: <4b630b7b87bd983291f628c42a1394fc0d2d86bd.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote: > ---8<--- > > > > > All you really care about is the "legacy" I/O spaces here, this isn't > > > > tied to PCI specifically at all, right? > > > > > > > > So why not just have a OLD_STYLE_IO config option or something like > > > > that, to show that it's the i/o functions we care about here, not PCI at > > > > all? > > > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward, > > > > just describe it as it is, "DIRECT_IO"? > > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate > > > name for it. > > > > > > Thanks, > > > Mauro > > > > Hmm, I might be missing something here but that sounds a lot like the > > HAS_IOPORT option added in patch 02. > > > > 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. > > I didn't look at the other patches on this series, but why it is needed > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y > where LEGACY_PCI shall be "n"? In the current patch set LEGACY_PCI is not currently selected by architectures, though of course it could be if we know that an architecture requires it. We should probably also set it in any defconfig that has devices depending on it so as not to break these. Other than that it would be set during kernel configuration if one wants/needs support for legacy PCI devices. For testing I ran with HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X based workstation and Raspberry Pi 4 (DT). I guess at the moment it would make most sense for special configs such as those tailored for vitualization guets but in the end that would be something for distributions to decide. Arnd described the options here: https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q at mail.gmail.com/ > > > 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." > > I would still avoid calling it LEGACY_PCI, as this sounds too generic. > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more > features that were/will be deprecated on PCI specs as time goes by. > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy" > means. Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like LEGACY_PCI is pretty clear since most devices are either pre-PCIe devices or a compatibility feature allowing drivers for a pre-PCIe device to work with a PCIe device. > > > These two separate config options allow us to compile without support > > for these legacy PCI devices even on a system where inb()/outb() and > > friends are required for some PC style devices and for example ACPI. > > Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI? > > > @@ -172,6 +177,7 @@ config SND_AZT3328 > > > > config SND_BT87X > > tristate "Bt87x Audio Capture" > > + depends on LEGACY_PCI > > select SND_PCM > > help > > If you want to record audio from TV cards based on > > I couldn't find any usage of inb/outb & friends on it: > > $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c > > It uses, instead, readl/writel: > > static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg) > { > return readl(chip->mmio + reg); > } > > static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value) > { > writel(value, chip->mmio + reg); > } > > I failed to see what makes it different from VIDEO_BT848 and > DVB_BT8XX drivers. They all support exactly the same chipset: > Brooktree/Conexant BT8xx. On those devices, depending on the exact > model, up to three separate interfaces are provided, each one with > its own Kconfig var: > > - audio I/O (SND_BT87X); > - video I/O (VIDEO_BT848); > - MPEG-TS I/O (DVB_BT8XX). > > Thanks, > Mauro You're right, that makes no sense this doesn't seem to require LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on PCI" which could have caused issues with HAVE_PCI=n rand configs.