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 4A903C433EF for ; Wed, 4 May 2022 11:46:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232667AbiEDLuV (ORCPT ); Wed, 4 May 2022 07:50:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237744AbiEDLuT (ORCPT ); Wed, 4 May 2022 07:50:19 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 136131F623; Wed, 4 May 2022 04:46:43 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id A4B0A92009C; Wed, 4 May 2022 13:46:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9DFED92009B; Wed, 4 May 2022 12:46:41 +0100 (BST) Date: Wed, 4 May 2022 12:46:41 +0100 (BST) From: "Maciej W. Rozycki" To: David Laight cc: 'Linus Walleij' , William Breathitt Gray , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-pci@vger.kernel.org" , Arnd Bergmann , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" Subject: RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies In-Reply-To: Message-ID: References: <20220429135108.2781579-1-schnelle@linux.ibm.com> <20220429135108.2781579-19-schnelle@linux.ibm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, 3 May 2022, David Laight wrote: > > > There is such a thing as ISA DMA, but you'll still need to initialize > > > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for > > > "config ISA" is the right thing to do: all ISA devices are expected to > > > communicate in some way via ioport. > > > > Adding that dependency seems like the right solution to me. > > I think it all depends on what HAS_IOPORT is meant to mean and > how portable kernel binaries need to be. > > x86 is (probably) the only architecture that actually has 'in' > and 'out' instructions - but that doesn't mean that some other > cpu (and I mean cpu+pcb not architecture) have the ability to > generate 'IO' bus cycles on a specific physical bus. I am fairly sure IA-64 has some form of IN/OUT machine instructions too. > While the obvious case is a physical address window that generates > PCI(e) IO cycles from normal memory cycles it isn't the only one. > > I've used sparc cpu systems that have pcmcia card slots. > These are pretty much ISA and the drivers might expect to > access port 0x300 (etc) - certainly that would be right on x86. > > In this case is isn't so much that the ISA_BUS depends on support > for in/out but that presence of the ISA bus provides the required > in/out support. Well, one can implement a pluggable PCI/e expansion card with a PCI-ISA bridge on it and a backplane to plug ISA cards into. Without support for issuing I/O cycles to PCI from the host however you won't be able to make use of the ISA backplane except maybe for some ancient ISA memory cards. So logically I think CONFIG_ISA should depend on CONFIG_HAS_IOPORT and CONFIG_HAS_IOPORT ought to be selected by platform configurations. ISTR there was a company that manufactured a USB-ISA option (providing an external ISA backplane). We never supported it, but in principle if we wanted to, then it would be the USB-ISA device's driver config option that CONFIG_ISA would additionally depend on as an alternative. That wouldn't enable CONFIG_HAS_IOPORT though because the presence of this particular USB-ISA device would not itself permit the use of I/O cycles with any PCI/e buses a machine might independently have, so devices for PCI/e options that require port I/O shouldn't be made available at the same time. I think that company might have actually manufactured a similar PCI-ISA option as well, but that I suppose did rely on support for I/O cycles on PCI. Early 2000s BTW. Maciej