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 546A1C433EF for ; Fri, 6 May 2022 14:04:31 +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:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2OwjRBTFdpRf5PQyUpyVqZZ4f+AYraCYv0CAL562Bvc=; b=ZPpHtIttZbgyWq GKfeK/KhWWfXh3u27FdsprnXS8+bPCThe299K3QvMpb2dh4WjVj0QqJy5ekIaNE4A+BdZxp5Tgljl Wu/fTaeWwPunRsD8uXklOFRIbc2VCVg9xhXZwH5JgYL35d/uV754+x6VwzgvE0EaW4mkCuI7puvKV BI3vf1/IncwZWpfKqHjagtGqvC5IUGGAhrbfCm1H2qirsd+rtBI4wro28RhMMuty3Bz8Gjh5WKmME k3w5spjH4IYraOWK3N911LoAesYMFxSeHvOSpXx3wwwDEKSyGLfHSU4iGctHHU3kO1jHcCxWzWIVp VMYUmAiTODTxFnmbKWSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmyYI-003ds7-ON; Fri, 06 May 2022 14:03:26 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmyYD-003dpb-Le for linux-arm-kernel@lists.infradead.org; Fri, 06 May 2022 14:03:23 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-195-nik8eVn6MbSMYKVVi8RBBA-1; Fri, 06 May 2022 15:03:17 +0100 X-MC-Unique: nik8eVn6MbSMYKVVi8RBBA-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 6 May 2022 15:03:15 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.033; Fri, 6 May 2022 15:03:15 +0100 From: David Laight To: 'Geert Uytterhoeven' CC: "Maciej W. Rozycki" , Arnd Bergmann , Rich Felker , "open list:IA64 (Itanium) PLATFORM" , "open list:SUPERH" , Catalin Marinas , Dave Hansen , "open list:MIPS" , "James E.J. Bottomley" , "open list:SPARC + UltraSPARC (sparc/sparc64)" , "open list:RISC-V ARCHITECTURE" , Will Deacon , linux-arch , Yoshinori Sato , Helge Deller , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Russell King , Ingo Molnar , linux-pci , Bjorn Helgaas , Matt Turner , Albert Ou , Arnd Bergmann , Niklas Schnelle , "open list:M68K ARCHITECTURE" , Ivan Kokshaysky , Paul Walmsley , "Thomas Gleixner" , "moderated list:ARM PORT" , Richard Henderson , Michal Simek , Thomas Bogendoerfer , "open list:PARISC ARCHITECTURE" , Greg Kroah-Hartman , Linux Kernel Mailing List , Palmer Dabbelt , "open list:ALPHA PORT" , Borislav Petkov , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "David S. Miller" Subject: RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Thread-Topic: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Thread-Index: AQHYYUSwX3QwDKjE7kKG/gGNt1cnA60Rx6Pg///55gCAABIk4A== Date: Fri, 6 May 2022 14:03:15 +0000 Message-ID: <62c1bf6687ac4abc98d4015852930241@AcuMS.aculab.com> References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_070322_045992_B4E7946A X-CRM114-Status: GOOD ( 18.98 ) X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Geert Uytterhoeven > Sent: 06 May 2022 14:09 ... > > The same is really true for other bus type - including ISA and EISA. > > (Ignoring the horrid of probing ISI bus devices - hopefully they > > are in the ACPI tables??_ > > If a driver is probed on a ISA bus there ought to be functions > > equivalent to pci_ioremap() (for both memory and IO addresses) > > that return tokens appropriate for the specific bus. > > > > That is all a different load of churn. > > A loooong time ago, it was suggested to add register accessor > functions to struct device, so e.g. readl(dev, offset) would call > into these accessors, which would implement the bus-specific behavior. > No more worries about readl(), __raw_readl(), ioread32b(), or whatever > quirk is needed, at the (small on nowadays' machines) expense of > some indirection... I was just thinking that the access functions might need a 'device'. Although you also need the BAR (or equivalent). So readl(dev, bar_token, offset) or readl(dev, bar_token + offset). Clearly the 'dev' parameter could be compiled out for non-DEBUG build on x86 - leaving the current(ish) object code. You don't want an indirect call (this year), but maybe real function call and a few tests won't make that much difference. They might affect PCIe writes, but PCIe reads are so slow you need to avoid them whenever possible. I've not timed reads into something like an ethernet chip, but into our fpga they are probably 1000 clocks+. OTOH I wouldn't want any overhead on the PIO fifo reads on one of our small ppc devices. We push a lot of data though that fifo and anything extra would kill performance. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel