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 094A3C433EF for ; Wed, 4 May 2022 18:03:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376341AbiEDSGl (ORCPT ); Wed, 4 May 2022 14:06:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359845AbiEDSGN (ORCPT ); Wed, 4 May 2022 14:06:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D051F50453; Wed, 4 May 2022 10:22:06 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id 8BC6CB8279D; Wed, 4 May 2022 17:22:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9272C385A5; Wed, 4 May 2022 17:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651684924; bh=7ebi4yCgI8D7GOL1tZDTxmOW2rgVmfcl5Te5keZEMNU=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=JfwHZ5SOCyIL8P/OP1RJofkC9XAomZekXM4qGdrXC5F2aPwsjJp7se1LV9ou9hNg4 4RCEWR+VpxXCfohJ0xC9VpOyUDih3avDDkGqjtM0UfT6QCb5LEMx7+mNUWhqw1LRFr mxiYwNx4tsZ3TJmett6XaF+dRwVbvmTBj3LOu3bgPGz1Xy4Pn8KTUmyB1zQ6/GVfw/ PcxBW90bAJYgLMdCVEINGl+WrO6UpvanuOeTW30/73DKgxHOK5azQnDeS6BYB9PNXx eUpeQ4wQcOKt/jwspavfT1+dDqKe4zFl0CYVjtE1WlVET9oTaQV913dMk6mqwxgUtM rw/Hsz2jFhhmw== Date: Wed, 4 May 2022 12:22:01 -0500 From: Bjorn Helgaas To: "Maciej W. Rozycki" Cc: Arnd Bergmann , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Dominik Brodowski Subject: Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies Message-ID: <20220504172201.GA454911@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 04, 2022 at 03:24:39PM +0100, Maciej W. Rozycki wrote: > On Wed, 4 May 2022, Arnd Bergmann wrote: > > > > POWER9 is another architecture with no port I/O space[1]: > > > > POWER9 is just an implementation of the power architecture > > that has a particular PCI host bridge. I would assume that > > arch/powerpc/ would continue to set HAS_IOPORT because > > it knows how to access I/O ports at compile-time. > > Well, yes, except I would expect POWER9_CPU (and any higher versions we > eventually get) to clear HAS_IOPORT. Generic configurations (GENERIC_CPU) > would set HAS_IOPORT of course, as would any lower architecture variants > that do or may support port I/O (it's not clear to me if there are any > that do not). Ideally a generic configuration would not issue accesses to > random MMIO locations for port I/O accesses via `inb'/`outb', etc. for > systems that do not support port I/O (which it now does, or at least used > to until recently). It would seem weird to me that a module would build and run on a generic kernel running on POWER9 (with some safe way of handling inb/outb that don't actually work), but not on a kernel built specifically for POWER9_CPU. It sounds like inb/outb in a generic kernel on POWER9 may not currently do something sensible, but that's fixable, e.g., make inb() return 0xff and outb() a no-op. I would naively expect the same behavior in a POWER9_CPU kernel. Bjorn