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 31CC6C43217 for ; Thu, 5 May 2022 17:40:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382795AbiEERoF (ORCPT ); Thu, 5 May 2022 13:44:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1382758AbiEERnw (ORCPT ); Thu, 5 May 2022 13:43:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDDEB5BD2C; Thu, 5 May 2022 10:40:03 -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 70DA7B82E13; Thu, 5 May 2022 17:40:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EA1EC385C1; Thu, 5 May 2022 17:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651772401; bh=2IoE4BfEuAg77WmuhMuImyNDvTFHhyYDFxiBCowXMW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jjkpXAHdVdaGYPRA/+3MWK8YySttWTFzcYC1keAu8erj/0Qv22sl3zrDQYguGunS5 EYa5oM+lHkIE7YTdldWLi0OWY/DsNHWma+k3zqfE22SXyjFuALh5riYHbPe1kbAc44 9KAWXnmbdCqw/9NbiY+BaqDNCtIn7quRedBG1XfiA99nj6AB8gym8fHYhho7MeeQF1 l9XXlvvZnqwjxE3vlzhp6PnrE7j4IrFhVl0Qex8zon67fDEF5nEZv2gZ3ktfM3q+fs 7pbwFrQBZZkl4jB1bUVpER7HBPy1pVzyBaA4EK56UQiDwNHTAidoXgBZp7AUZ4Ox2c dWIFDXtyn6eAA== Received: by mail-wm1-f47.google.com with SMTP id l62-20020a1c2541000000b0038e4570af2fso3057496wml.5; Thu, 05 May 2022 10:40:00 -0700 (PDT) X-Gm-Message-State: AOAM530yTQ0JfV7UcZJ2sGdAUtPmpZUHjzeVwfywFlcrhtcN+zBTpQ3E I54ikdPAfAKxu/CEiGl5fe/z60RnqY9ehyeeKhM= X-Google-Smtp-Source: ABdhPJxtMhUha7a+dwpeZyyg5w+ON9JC8vKB6RB8veyDWjdr1D7VRDLkqvJBk615pYcXmnWu5kgj+KPCSrbSxhVU2uo= X-Received: by 2002:a7b:cc93:0:b0:394:2622:fcd9 with SMTP id p19-20020a7bcc93000000b003942622fcd9mr6321312wma.20.1651772399229; Thu, 05 May 2022 10:39:59 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: <20220505161028.GA492600@bhelgaas> From: Arnd Bergmann Date: Thu, 5 May 2022 19:39:42 +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: Bjorn Helgaas Cc: 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 Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. 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 E1954C433F5 for ; Thu, 5 May 2022 17:40:38 +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=3yjopV1TpNV17T/KhNRUhsT6y4VoHe2ibVRf3Wiydjk=; b=M+d26hoBoKbnAk qGdklkoV75fp4nWG9PFCS56eRgpX5iZ8DkqLZnuhuLwwY3E5qPHTL+kjpxyYZRg5lVGKp2YUougUo ZyHFmR0iB1DEIsgGJsMarvGhzkb/UpcS2TAv+UilmiJ/aplz2c8Ut89gjz0ltA+muzYu1cSamHVqB hwrMksm/S3sLiQ1UYVH5B2yW7pJblZvikOIZEfAPnOsffDv1AbsjlwYiOX52JYfN9OoQPf9/wNPRh 5h0w4f1+2ZpQBT04dh34mijz/h+/si42gamxMANzYRVmuUD54QVHqVCFNInGbzWtC+0fvZHIdD5LP yQPLyEPTP7/8makth+rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmfSi-00H4aR-No; Thu, 05 May 2022 17:40:24 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmfSW-00H4VP-Ja; Thu, 05 May 2022 17:40:14 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 22D7B61F09; Thu, 5 May 2022 17:40:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E940BC385A4; Thu, 5 May 2022 17:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651772411; bh=2IoE4BfEuAg77WmuhMuImyNDvTFHhyYDFxiBCowXMW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gDuRGk4UTOFgyiPRSSXBtXdg7RapyCYPQMe3RDG1agV2g91eoA8Rc96OoXhcxZktS iUqVfHohjgqHBdDDtxw5t6xJ9Nhm9sSAdlyGvUTs6m+xZUhtZqKl1GSzm0PLJcqji6 Zwu22sg5c8SYB8EGXGM0c7T9GFi09LU2w9lyRv2qYfUyzADinYvcwB9oYxIjNKRSXB rJbPM+FqCEOPUai83HD9yI1FPF1fml1W/bN4kUJP38WtlPPBBIi5VUu91BjitmDOp7 5K3I4ZAYpbF0sj+30Pw4r5dr3PVF7qz49AwnJbcV/PZGH4xcfoqBLRAey6ism0Mvsj /lk9y6IRiCqfg== Received: by mail-wm1-f43.google.com with SMTP id 125-20020a1c1983000000b003941f354c62so3077622wmz.0; Thu, 05 May 2022 10:40:11 -0700 (PDT) X-Gm-Message-State: AOAM5304P8nEmkwB5RhZwUHcu551e2uzsE2IT39STCk6BcuBdIPxTWOO OrO5ZJHFNrlnRYuXabbTW7bWwnMf59MkVqYYkrE= X-Google-Smtp-Source: ABdhPJxtMhUha7a+dwpeZyyg5w+ON9JC8vKB6RB8veyDWjdr1D7VRDLkqvJBk615pYcXmnWu5kgj+KPCSrbSxhVU2uo= X-Received: by 2002:a7b:cc93:0:b0:394:2622:fcd9 with SMTP id p19-20020a7bcc93000000b003942622fcd9mr6321312wma.20.1651772399229; Thu, 05 May 2022 10:39:59 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: <20220505161028.GA492600@bhelgaas> From: Arnd Bergmann Date: Thu, 5 May 2022 19:39:42 +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: Bjorn Helgaas Cc: 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-20220505_104012_750016_65E08ABE X-CRM114-Status: GOOD ( 24.61 ) 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 Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. 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 2B660C433F5 for ; Thu, 5 May 2022 17:40:54 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KvLZr5CQjz3byS for ; Fri, 6 May 2022 03:40:52 +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=gDuRGk4U; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; 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=gDuRGk4U; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (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 4KvLZ73dlRz2y7K for ; Fri, 6 May 2022 03:40:15 +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 0741B61F04 for ; Thu, 5 May 2022 17:40:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD6F0C385B0 for ; Thu, 5 May 2022 17:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651772411; bh=2IoE4BfEuAg77WmuhMuImyNDvTFHhyYDFxiBCowXMW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gDuRGk4UTOFgyiPRSSXBtXdg7RapyCYPQMe3RDG1agV2g91eoA8Rc96OoXhcxZktS iUqVfHohjgqHBdDDtxw5t6xJ9Nhm9sSAdlyGvUTs6m+xZUhtZqKl1GSzm0PLJcqji6 Zwu22sg5c8SYB8EGXGM0c7T9GFi09LU2w9lyRv2qYfUyzADinYvcwB9oYxIjNKRSXB rJbPM+FqCEOPUai83HD9yI1FPF1fml1W/bN4kUJP38WtlPPBBIi5VUu91BjitmDOp7 5K3I4ZAYpbF0sj+30Pw4r5dr3PVF7qz49AwnJbcV/PZGH4xcfoqBLRAey6ism0Mvsj /lk9y6IRiCqfg== Received: by mail-wm1-f50.google.com with SMTP id k126-20020a1ca184000000b003943fd07180so3062203wme.3 for ; Thu, 05 May 2022 10:40:11 -0700 (PDT) X-Gm-Message-State: AOAM531NtdnPGDmB42cUEDaHM0K1AjT358Z4TUFgILCspwodJvoy3mag 5wVj4oloh2OgjXL6I73QvsX9CkqQ9mUIUbKMZ2s= X-Google-Smtp-Source: ABdhPJxtMhUha7a+dwpeZyyg5w+ON9JC8vKB6RB8veyDWjdr1D7VRDLkqvJBk615pYcXmnWu5kgj+KPCSrbSxhVU2uo= X-Received: by 2002:a7b:cc93:0:b0:394:2622:fcd9 with SMTP id p19-20020a7bcc93000000b003942622fcd9mr6321312wma.20.1651772399229; Thu, 05 May 2022 10:39:59 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: <20220505161028.GA492600@bhelgaas> From: Arnd Bergmann Date: Thu, 5 May 2022 19:39:42 +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: Bjorn Helgaas 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 , 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 Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. 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 7667EC433F5 for ; Thu, 5 May 2022 17:41:21 +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=kAP7shFDZEMmIyhvm9dKfVnSZlM+StQamPOiNPv831k=; b=rhtXUIieAYvBMF VIrz2OU85ETTpJvpTsW9tVfQzEU7iD4Ihz0LNMmx1/eMhN19e5PGt+u5eK5HxmwiuRD8ehofKaOLc GZgWrk4Kl/3K/ms3MJ2CayyH04HjuI7/88k06hIh/nokeDCa+z3Wp59OlNtzOMAigJjhFC3PjaVI5 lFm0ZkbwJYn+e9dLLZL6iT0dJ5Z4CRgm6lzOha2IwS2YIy5MKb8usLIsvryN+RhTIhXTfjaQRHt2B pkmxv4Cy/viGaWTUdgBG0QPF+ntmzgLhkHjXQdjuHW6v2WynyxvLlxx+FU7dXg0zEZBesXDyXw5f5 aHRamwQLct2M/+OmhAQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmfSa-00H4XI-81; Thu, 05 May 2022 17:40:16 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmfSW-00H4VP-Ja; Thu, 05 May 2022 17:40:14 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 22D7B61F09; Thu, 5 May 2022 17:40:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E940BC385A4; Thu, 5 May 2022 17:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651772411; bh=2IoE4BfEuAg77WmuhMuImyNDvTFHhyYDFxiBCowXMW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gDuRGk4UTOFgyiPRSSXBtXdg7RapyCYPQMe3RDG1agV2g91eoA8Rc96OoXhcxZktS iUqVfHohjgqHBdDDtxw5t6xJ9Nhm9sSAdlyGvUTs6m+xZUhtZqKl1GSzm0PLJcqji6 Zwu22sg5c8SYB8EGXGM0c7T9GFi09LU2w9lyRv2qYfUyzADinYvcwB9oYxIjNKRSXB rJbPM+FqCEOPUai83HD9yI1FPF1fml1W/bN4kUJP38WtlPPBBIi5VUu91BjitmDOp7 5K3I4ZAYpbF0sj+30Pw4r5dr3PVF7qz49AwnJbcV/PZGH4xcfoqBLRAey6ism0Mvsj /lk9y6IRiCqfg== Received: by mail-wm1-f43.google.com with SMTP id 125-20020a1c1983000000b003941f354c62so3077622wmz.0; Thu, 05 May 2022 10:40:11 -0700 (PDT) X-Gm-Message-State: AOAM5304P8nEmkwB5RhZwUHcu551e2uzsE2IT39STCk6BcuBdIPxTWOO OrO5ZJHFNrlnRYuXabbTW7bWwnMf59MkVqYYkrE= X-Google-Smtp-Source: ABdhPJxtMhUha7a+dwpeZyyg5w+ON9JC8vKB6RB8veyDWjdr1D7VRDLkqvJBk615pYcXmnWu5kgj+KPCSrbSxhVU2uo= X-Received: by 2002:a7b:cc93:0:b0:394:2622:fcd9 with SMTP id p19-20020a7bcc93000000b003942622fcd9mr6321312wma.20.1651772399229; Thu, 05 May 2022 10:39:59 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> In-Reply-To: <20220505161028.GA492600@bhelgaas> From: Arnd Bergmann Date: Thu, 5 May 2022 19:39:42 +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: Bjorn Helgaas Cc: 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-20220505_104012_750016_65E08ABE X-CRM114-Status: GOOD ( 24.61 ) 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 Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. 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: Thu, 05 May 2022 17:39:42 +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: <20220505161028.GA492600@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bjorn Helgaas Cc: 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 Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. 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: Thu, 5 May 2022 19:39:42 +0200 Message-ID: References: <20220505161028.GA492600@bhelgaas> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651772401; bh=2IoE4BfEuAg77WmuhMuImyNDvTFHhyYDFxiBCowXMW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jjkpXAHdVdaGYPRA/+3MWK8YySttWTFzcYC1keAu8erj/0Qv22sl3zrDQYguGunS5 EYa5oM+lHkIE7YTdldWLi0OWY/DsNHWma+k3zqfE22SXyjFuALh5riYHbPe1kbAc44 9KAWXnmbdCqw/9NbiY+BaqDNCtIn7quRedBG1XfiA99nj6AB8gym8fHYhho7MeeQF1 l9XXlvvZnqwjxE3vlzhp6PnrE7j4IrFhVl0Qex8zon67fDEF5nEZv2gZ3ktfM3q+fs 7pbwFrQBZZkl4jB1bUVpER7HBPy1pVzyBaA4EK56UQiDwNHTAidoXgBZp7AUZ4Ox2c dWIFDXtyn6eAA== In-Reply-To: <20220505161028.GA492600@bhelgaas> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bjorn Helgaas Cc: 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 On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote: > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote: > > > > The main goal is to avoid c), which is what happens on s390, but > > can also happen elsewhere. Catching b) would be nice as well, > > but is much harder to do from generic code as you'd need an > > architecture specific inline asm statement to insert a ex_table > > fixup, or a runtime conditional on each access. > > Or s390 could implement its own inb(). > > I'm hearing that generic powerpc kernels have to run both on machines > that have I/O port space and those that don't. That makes me think > s390 could do something similar. No, this is actually the current situation, and it makes absolutely no sense. s390 has no way of implementing inb()/outb() because there are no instructions for it and it cannot tunnel them through a virtual address mapping like on most of the other architectures. (it has special instructions for accessing memory space, which is not the same as a pointer dereference here). The existing implementation gets flagged as a NULL pointer dereference by a compiler warning because it effectively is. powerpc kernels generally map the I/O space into a section of the physical address space, where it gets mapped into a fixed virtual address and accessed through pointer dereference. This works on any powerpc CPU as long as it is implemented in the PCI host bridge in the usual way. The only difference between powerpc and arm here is that there are fewer implementations, so one can make assumptions about which PCI host bridge is used based on a CPU core. Arnd