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 B1FC2C433EF for ; Wed, 4 May 2022 21:31:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354421AbiEDVf1 (ORCPT ); Wed, 4 May 2022 17:35:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347126AbiEDVf0 (ORCPT ); Wed, 4 May 2022 17:35:26 -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 2BFB84838E; Wed, 4 May 2022 14:31:49 -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 CAD48B829E8; Wed, 4 May 2022 21:31:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80D62C385BF; Wed, 4 May 2022 21:31:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651699906; bh=zFvzT8pCm+1ful8W/hZ4LOb35c/AZPHiTAR5f5uq/tc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=psHr6IyS0tCkPqNjtn0h6gBlwY40lOhbh/uw16bstSHWVYnmtHqEoZ532Dc9rtOal DUtXfgn3DdLZgWPENyY+MDgzz08W+auqjcYPklLCUJDhHdzEXeeuxWe7LpvbPQY9kJ FOxNi34XKyPTNO9nguLWvf12if7tv0axSjj5zB31OByn/knBsjbgNK9SEZoOb9mk2H 8Mi5Plsbv3ClcTw6udErx8u6A9v1Ng1bHEjpGoMpucB2QcZFN6TMAvSYQ6IMdui25o P6nUGl1dzSr93wmpQQ9rPDjMiV7wf6pGhiZS8ljqSo0VQ8Lm9E+/x0iZSoSI081EGu qotf+DUD3i/vA== Received: by mail-wr1-f51.google.com with SMTP id k2so3657498wrd.5; Wed, 04 May 2022 14:31:46 -0700 (PDT) X-Gm-Message-State: AOAM530m3z7+Lq1wthZl3Ou4DDusfe+YzKGwkK3E99iNDWFIQi4smzAh db83aG6SCEY16rFZw+Bo71+iWvSUabbsMWpWX3Y= X-Google-Smtp-Source: ABdhPJxAVZcK+UbsrIHV3UqhufeJ7C2MWsg9y8caQR3XP4mze6wyb/qHpchpXkh4iCCt0pJlSodAlnXDA871Nj1pC0U= X-Received: by 2002:adf:e106:0:b0:20a:b31b:213d with SMTP id t6-20020adfe106000000b0020ab31b213dmr17558428wrz.219.1651699904306; Wed, 04 May 2022 14:31:44 -0700 (PDT) MIME-Version: 1.0 References: <20220429135108.2781579-2-schnelle@linux.ibm.com> <20220504210840.GA469916@bhelgaas> In-Reply-To: <20220504210840.GA469916@bhelgaas> From: Arnd Bergmann Date: Wed, 4 May 2022 23:31:28 +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 Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas wrote: > > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote: > > We introduce a new HAS_IOPORT Kconfig option to indicate support for > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation > > of the I/O accessor functions inb()/outb() and friends on architectures > > which can not meaningfully support legacy I/O spaces such as s390 or > > where such support is optional. > > So you plan to drop inb()/outb() on architectures where I/O port space > is optional? So even platforms that have I/O port space may not be > able to use it? > > This feels like a lot of work where the main benefit is to keep > Kconfig from offering drivers that aren't of interest on s390. > > Granted, there may be issues where inb()/outb() does the wrong thing > such as dereferencing null pointers when I/O port space isn't > implemented. I think that's a defect in inb()/outb() and could be > fixed there. The current implementation in asm-generic/io.h implements inb()/outb() using readb()/writeb() with a fixed architecture specific offset. There are three possible things that can happen here: a) there is a host bridge driver that maps its I/O ports to this window, and everything works b) the address range is reserved and accessible but no host bridge driver has mapped its registers there, so an access causes a page fault c) the architecture does not define an offset, and accessing low I/O ports ends up as a NULL pointer dereference 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. Arnd