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 AD5B5C433EF for ; Thu, 6 Jan 2022 17:41:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242047AbiAFRlY (ORCPT ); Thu, 6 Jan 2022 12:41:24 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]:4360 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241966AbiAFRlY (ORCPT ); Thu, 6 Jan 2022 12:41:24 -0500 Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JVD6c3dG6z67wb3; Fri, 7 Jan 2022 01:36:24 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 6 Jan 2022 18:41:19 +0100 Received: from [10.47.27.56] (10.47.27.56) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 6 Jan 2022 17:41:15 +0000 Subject: Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI To: Bjorn Helgaas CC: Niklas Schnelle , Mauro Carvalho Chehab , Arnd Bergmann , Hans Verkuil , Ettore Chimenti , "Greg Kroah-Hartman" , Arnd Bergmann , Bjorn Helgaas , 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 , , Mark Brown , Sudip Mukherjee , "Teddy Wang" , Forest Bond , Jiri Slaby , "Wim Van Sebroeck" , Jaroslav Kysela , "Takashi Iwai" , , , , , , , , , , , , , , , , , , , , , , References: <20220105194748.GA215560@bhelgaas> From: John Garry Message-ID: <74bf4fde-3972-1c36-ca04-58089da0d82b@huawei.com> Date: Thu, 6 Jan 2022 17:41:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20220105194748.GA215560@bhelgaas> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.27.56] X-ClientProxiedBy: lhreml736-chm.china.huawei.com (10.201.108.87) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org 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