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 AA37CC4332F for ; Thu, 5 May 2022 17:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382769AbiEERoE (ORCPT ); Thu, 5 May 2022 13:44:04 -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-arch@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