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 2374DC43219 for ; Fri, 6 May 2022 12:54:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392192AbiEFM6T (ORCPT ); Fri, 6 May 2022 08:58:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1392173AbiEFM6A (ORCPT ); Fri, 6 May 2022 08:58:00 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A4B3606C3; Fri, 6 May 2022 05:54:11 -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 B1EB3B8350D; Fri, 6 May 2022 12:54:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6736FC385C0; Fri, 6 May 2022 12:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841648; bh=YEsptMS5NZ5sU5R8sBoFFmT8HhhJmSMOqqqMD1wS+1Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=alicQ+HfzBRpAkO4B96ZoI58feV30vwikm/SJGBtuePZM0wfyrCA+j9vGNYsOCzoo HP/4IJb9wWEnTHbo9/27qz1+kGraLpz6DXj61WtLS1JeZqg546So3OIWfjv3BbABpV 8dQUZ6ELhNVBSLsA390sbMzGuZMUij6tnXvZEXj4WfMWsq7AU0N7RHHCSWZaOfNg1L M/C9dzbWlAmjAIW5r+qqkvwipyU1At3FZ+hwk5GIWHPOdlH3+dt+Jqf3arEnPHd8Hc FOmJ1tfP+Djie6UmpJK4r2UngjgPTwpiLnjtpMMaN0N0MgVh+7XIR4gMMh9OB4ZWnh NQ7q+PXPPTZTw== Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-2f7ca2ce255so80026007b3.7; Fri, 06 May 2022 05:54:08 -0700 (PDT) X-Gm-Message-State: AOAM530XRFkVTU53dh/Xqfh6fB+5JBeiq+bqnJ9Tx1SDjl8DTLQxcQCh 6vpcEal1iz2dkLJ0OTBfBCvuWUa6+WVCt1brahc= X-Google-Smtp-Source: ABdhPJxL4gNLQQDFM+BNVTidCF+FJnD2lH7XZl8gBNCvdOYlAoSJ9hsbhzdM2mtB2NzLIM7z6wH6YyxJ1/r4G1eT6xU= X-Received: by 2002:a81:9213:0:b0:2f6:eaae:d22f with SMTP id j19-20020a819213000000b002f6eaaed22fmr2535695ywg.249.1651841647017; Fri, 06 May 2022 05:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: From: Arnd Bergmann Date: Fri, 6 May 2022 14:53:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: "Maciej W. Rozycki" Cc: Bjorn Helgaas , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd 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 DC835C433F5 for ; Fri, 6 May 2022 12:54:43 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wWAzGX7KR0RKXdAzDuKtOnEjIrMXHGWQRAuYkLL7xbQ=; b=45IqcnpDExlDM5 JyFwgbMa0L6O8eUHaylNj/3hboUTqQU3d6RCM5IWfVU8C94SOXqggyzTkRqeIqC7uvZKxqIM8be1Z 6126AkbC9euqOJYnG6jr/Gzh64FYQaoxHrA9HedgQwKbQnb/8+QR46eyUAooQ5avci3JT1AMf7SQf voardnN52pieLJJAiYvemCTglF6JGpQWkN+iUJlUMVIGHF/jYfKKDWDi1CMeHcXmAxyjmCOeiIp6w qVcnUFyTln+I3fAShxjVsfn/dxOmgpI/xalvRva/ydKe3P0EA2aQz8+CxomsT7x1neBd0kwb9ctwT Sy5Jpd1mF6qDySjk349A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxTf-003Jae-LH; Fri, 06 May 2022 12:54:35 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxTR-003JWD-Fz; Fri, 06 May 2022 12:54:23 +0000 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 16295B835B9; Fri, 6 May 2022 12:54:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CCAFC385B5; Fri, 6 May 2022 12:54:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841658; bh=YEsptMS5NZ5sU5R8sBoFFmT8HhhJmSMOqqqMD1wS+1Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=maE6/GoVFXRZNf7dfZPTVoMAWc6wGTVVX44qiwcwuwtsWpQr1FqM/jmMrvvkc1w0m /fdrsFTDKxwRvNHNK/1DjgM5J06h70STrSIQAvZkM2OfQAHM0wNC1NP2CMvk75VZVN fLTHzZWHgk6Ekdl8uTqjvomjFVgaGddUTcd5lXXPSGhuZCW4nb8nI7JlnC3De74LHw WbtQuRK6IFfQaU8R1z+FNZAwJdGy2thD1f0VJD8T7C7xV2945L8kQS1Sga76wR3MHB DhKSaRYVUK6746o5RiRAERN5HNbHvcEPu7PKSGLVz3w/nrBuDtObHLXaQUIxo+NIPv Ke+TQ+7Lj2NdQ== Received: by mail-ot1-f52.google.com with SMTP id m6-20020a05683023a600b0060612720715so4844634ots.10; Fri, 06 May 2022 05:54:18 -0700 (PDT) X-Gm-Message-State: AOAM5317QkjAXS1n25UI9hkwJOF7Hp4Fjd/UXKeD3VuwbQeTQ2UcuGYt jmnV+wEZipwUgJaGWbiBmxaF5fNjztV5pxLpQAA= X-Google-Smtp-Source: ABdhPJxL4gNLQQDFM+BNVTidCF+FJnD2lH7XZl8gBNCvdOYlAoSJ9hsbhzdM2mtB2NzLIM7z6wH6YyxJ1/r4G1eT6xU= X-Received: by 2002:a81:9213:0:b0:2f6:eaae:d22f with SMTP id j19-20020a819213000000b002f6eaaed22fmr2535695ywg.249.1651841647017; Fri, 06 May 2022 05:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: From: Arnd Bergmann Date: Fri, 6 May 2022 14:53:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: "Maciej W. Rozycki" Cc: Bjorn Helgaas , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_055421_902985_14ECCFF9 X-CRM114-Status: GOOD ( 23.95 ) 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 Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd _______________________________________________ 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 6B394C433F5 for ; Fri, 6 May 2022 12:55:02 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KvrBX6Rdbz3cDp for ; Fri, 6 May 2022 22:55:00 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=maE6/GoV; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=arnd@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=maE6/GoV; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Kvr9p63Hnz2xgY for ; Fri, 6 May 2022 22:54:22 +1000 (AEST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6030762039 for ; Fri, 6 May 2022 12:54:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F8C9C385B3 for ; Fri, 6 May 2022 12:54:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841658; bh=YEsptMS5NZ5sU5R8sBoFFmT8HhhJmSMOqqqMD1wS+1Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=maE6/GoVFXRZNf7dfZPTVoMAWc6wGTVVX44qiwcwuwtsWpQr1FqM/jmMrvvkc1w0m /fdrsFTDKxwRvNHNK/1DjgM5J06h70STrSIQAvZkM2OfQAHM0wNC1NP2CMvk75VZVN fLTHzZWHgk6Ekdl8uTqjvomjFVgaGddUTcd5lXXPSGhuZCW4nb8nI7JlnC3De74LHw WbtQuRK6IFfQaU8R1z+FNZAwJdGy2thD1f0VJD8T7C7xV2945L8kQS1Sga76wR3MHB DhKSaRYVUK6746o5RiRAERN5HNbHvcEPu7PKSGLVz3w/nrBuDtObHLXaQUIxo+NIPv Ke+TQ+7Lj2NdQ== Received: by mail-ot1-f48.google.com with SMTP id i25-20020a9d6259000000b00605df9afea7so4861087otk.1 for ; Fri, 06 May 2022 05:54:18 -0700 (PDT) X-Gm-Message-State: AOAM530mDZLjWrx2+GYn2SWDdjRRi8/hXYraTHMivPBK+k7WJtTB5/6z LfBLqLoN8chKGZWpG3ti6UsGbxQ8x/vg6OkwiTI= X-Google-Smtp-Source: ABdhPJxL4gNLQQDFM+BNVTidCF+FJnD2lH7XZl8gBNCvdOYlAoSJ9hsbhzdM2mtB2NzLIM7z6wH6YyxJ1/r4G1eT6xU= X-Received: by 2002:a81:9213:0:b0:2f6:eaae:d22f with SMTP id j19-20020a819213000000b002f6eaaed22fmr2535695ywg.249.1651841647017; Fri, 06 May 2022 05:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: From: Arnd Bergmann Date: Fri, 6 May 2022 14:53:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: "Maciej W. Rozycki" Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 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 , Geert Uytterhoeven , 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" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd 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 32A27C433F5 for ; Fri, 6 May 2022 12:55:28 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B6PUP4QPp/7JAuPIUbYUSub1XhMXir1e0YoASBgxigI=; b=wSqafzXDVqjB0l IPLLus+kHZHs97AETk1cYhwrqMycFlki/7saU1JEOxm0Gmiz9FIbAA+X/NnFq+mYqKFsg8UYY7eai Vn4mXysesH1FaQRjCeMWSmGOKRJCSstYgALrnlyR3xZCsqTE1cRtUS+MGsG/BurE3fvqQF7/hCdOo msJKCZWwiGDhxsTx6YlB2WIDZbZlVbv8Mo+FP3sSGZ8q6HI8Hze9jdYYTFoufTTYt9ppsDqGJTgcx kaOIpSAq8vD5jOqyVkXY55ezDpA9cyiUvzmR2rl9a6Xr3XZSVfzxD5+hK7N2L1uvfidthW/pc5WJq LU5TmhOVvk66o3wVrkfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxTU-003JXT-KC; Fri, 06 May 2022 12:54:24 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxTR-003JWD-Fz; Fri, 06 May 2022 12:54:23 +0000 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 16295B835B9; Fri, 6 May 2022 12:54:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CCAFC385B5; Fri, 6 May 2022 12:54:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841658; bh=YEsptMS5NZ5sU5R8sBoFFmT8HhhJmSMOqqqMD1wS+1Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=maE6/GoVFXRZNf7dfZPTVoMAWc6wGTVVX44qiwcwuwtsWpQr1FqM/jmMrvvkc1w0m /fdrsFTDKxwRvNHNK/1DjgM5J06h70STrSIQAvZkM2OfQAHM0wNC1NP2CMvk75VZVN fLTHzZWHgk6Ekdl8uTqjvomjFVgaGddUTcd5lXXPSGhuZCW4nb8nI7JlnC3De74LHw WbtQuRK6IFfQaU8R1z+FNZAwJdGy2thD1f0VJD8T7C7xV2945L8kQS1Sga76wR3MHB DhKSaRYVUK6746o5RiRAERN5HNbHvcEPu7PKSGLVz3w/nrBuDtObHLXaQUIxo+NIPv Ke+TQ+7Lj2NdQ== Received: by mail-ot1-f52.google.com with SMTP id m6-20020a05683023a600b0060612720715so4844634ots.10; Fri, 06 May 2022 05:54:18 -0700 (PDT) X-Gm-Message-State: AOAM5317QkjAXS1n25UI9hkwJOF7Hp4Fjd/UXKeD3VuwbQeTQ2UcuGYt jmnV+wEZipwUgJaGWbiBmxaF5fNjztV5pxLpQAA= X-Google-Smtp-Source: ABdhPJxL4gNLQQDFM+BNVTidCF+FJnD2lH7XZl8gBNCvdOYlAoSJ9hsbhzdM2mtB2NzLIM7z6wH6YyxJ1/r4G1eT6xU= X-Received: by 2002:a81:9213:0:b0:2f6:eaae:d22f with SMTP id j19-20020a819213000000b002f6eaaed22fmr2535695ywg.249.1651841647017; Fri, 06 May 2022 05:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: From: Arnd Bergmann Date: Fri, 6 May 2022 14:53:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: "Maciej W. Rozycki" Cc: Bjorn Helgaas , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_055421_902985_14ECCFF9 X-CRM114-Status: GOOD ( 23.95 ) 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 On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Fri, 06 May 2022 12:53:49 +0000 Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Message-Id: List-Id: References: <20220505161028.GA492600@bhelgaas> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Maciej W. Rozycki" Cc: Bjorn Helgaas , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Date: Fri, 6 May 2022 14:53:49 +0200 Message-ID: References: <20220505161028.GA492600@bhelgaas> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wWAzGX7KR0RKXdAzDuKtOnEjIrMXHGWQRAuYkLL7xbQ=; b=45IqcnpDExlDM5 JyFwgbMa0L6O8eUHaylNj/3hboUTqQU3d6RCM5IWfVU8C94SOXqggyzTkRqeIqC7uvZKxqIM8be1Z 6126AkbC9euqOJYnG6jr/Gzh64FYQaoxHrA9HedgQwKbQnb/8+QR46eyUAooQ5avci3JT1AMf7SQf voardnN52pieLJJAiYvemCTglF6JGpQWkN+iUJlUMVIGHF/jYfKKDWDi1CMeHcXmAxyjmCOeiIp6w qVcnUFyTln+I3fAShxjVsfn/dxOmgpI/xalvRva/ydKe3P0EA2aQz8+CxomsT7x1neBd0kwb9ctwT Sy5Jpd1mF6qDySjk349A==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651841658; bh=YEsptMS5NZ5sU5R8sBoFFmT8HhhJmSMOqqqMD1wS+1Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=maE6/GoVFXRZNf7dfZPTVoMAWc6wGTVVX44qiwcwuwtsWpQr1FqM/jmMrvvkc1w0m /fdrsFTDKxwRvNHNK/1DjgM5J06h70STrSIQAvZkM2OfQAHM0wNC1NP2CMvk75VZVN fLTHzZWHgk6Ekdl8uTqjvomjFVgaGddUTcd5lXXPSGhuZCW4nb8nI7JlnC3De74LHw WbtQuRK6IFfQaU8R1z+FNZAwJdGy2thD1f0VJD8T7C7xV2945L8kQS1Sga76wR3MHB DhKSaRYVUK6746o5RiRAERN5HNbHvcEPu7PKSGLVz3w/nrBuDtObHLXaQUIxo+NIPv Ke+TQ+7Lj2NdQ== In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+glpr-linux-riscv=m.gmane-mx.org@lists.infradead.org To: "Maciej W. Rozycki" Cc: Bjorn Helgaas , Niklas Schnelle , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou <> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote: > > On Fri, 6 May 2022, Arnd Bergmann wrote: > > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit > > > pattern put on the bus/in the TLP in the address phase. So what is there > > > inherent to the s390 architecture that prevents that different bit pattern > > > from being used? > > > > The hardware design for PCI on s390 is very different from any other > > architecture, and more abstract. Rather than implementing MMIO register > > access as pointer dereference, this is a separate CPU instruction that > > takes a device/bar plus offset as arguments rather than a pointer, and > > Linux encodes this back into a fake __iomem token. > > OK, that seems to me like a reasonable and quite a clean design (on the > hardware side). > > So what happens if the instruction is given an I/O rather than memory BAR > as the relevant argument? Is the address space indicator bit (bit #0) > simply ignored or what? Not sure. My best guess is that it would actually work as you'd expect, but is deliberately left out of the architecture specification so they don't have to to validate the correctness. Note that only a small number of PCIe cards are actually supported by IBM, and I think the firmware only passes devices to the OS if they are whitelisted. Arnd