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 8358CC43217 for ; Fri, 6 May 2022 14:57:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442535AbiEFPA5 (ORCPT ); Fri, 6 May 2022 11:00:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347797AbiEFPAy (ORCPT ); Fri, 6 May 2022 11:00:54 -0400 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E6855D66D; Fri, 6 May 2022 07:57:11 -0700 (PDT) Received: by mail-qt1-f180.google.com with SMTP id o18so6148249qtk.7; Fri, 06 May 2022 07:57:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFKDqxAl8kAhgchSspFlV1jC/a94gKje1e9uHi6vXps=; b=Sxg80agDa7tTqUp3W7rKa3hzSGeUm0htCDCMpdxBfSW0Sl6vkmAldg8nkZeY+t+3Qw Td/DgDcz6zLCnOJd0yh8vgClck/yq5IggwtZvuTvHDZ47dC27m5GSKZichMdjR7TxiGd 1ukA5wVzWnyDoJ+4gput1p1ZUfzV92SaHyMhBQf0TiFt73clt/7q3vj0Olv4dPaoAHej r80vHBT02YVWB6Wie5tECcwOp7jfuHkvszD4FdwE9KPSd+VEVZTgLob5zt5NWUktU3O9 GpHRbAy9ot+bdATuL/Cgb378IejVLTVfZNkDjRgB2IvwQdY3Pfb2EoR9FWtH2SSLRYGp TMKA== X-Gm-Message-State: AOAM530FkhTo3eQXUQwXcQTBWzoZecZ2RoLv3DUj68jTR7w5GJPhkh4m k/Y+jnv1uvtXHxZWFxHacveZfP6ig/XtWQ== X-Google-Smtp-Source: ABdhPJyl9inILtiiUaqhn5+Zn+N7rFGA5s6hayF71VOrk/V+P992tPXwAN2jICQyiuOzEoI1mGTdcQ== X-Received: by 2002:a05:622a:3c8:b0:2f3:7231:913e with SMTP id k8-20020a05622a03c800b002f37231913emr3168671qtx.212.1651849030333; Fri, 06 May 2022 07:57:10 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id h4-20020ac87764000000b002f39b99f6a2sm2504428qtu.60.2022.05.06.07.57.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 07:57:09 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id w17so13293397ybh.9; Fri, 06 May 2022 07:57:08 -0700 (PDT) X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr2500583ybs.365.1651849027963; Fri, 06 May 2022 07:57:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 6 May 2022 16:56:56 +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: David Laight , Arnd Bergmann , 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 , 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" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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 A1714C433EF for ; Fri, 6 May 2022 14:57:22 +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=lLs9Q/GXSSeJ9Y1omcI1ufexe/Zpv05YMBSI2hVPDpw=; b=Ac2YJcrq455QjP gu5NCEv45IWR8mKppKuERZeR+CkGSa5AOO0a23WT4fnJPcRHeE3tn23haJ/So+RN0u4XcQotTwLpJ 1FttCkAtp1QJNy5iEes1GwvSX61RU4Ws59dgNc0AAnir2Ckks+HUVVCRZmCrVoCjQcp3qF1/rFjDn n+Nqk6HuhiU7qctGQlzHW1iV1LmpIDH4j0xd89Vo50QFONYKc2V00TZAHzLxvU8vlxnt5kw17cPcy M9qkB2g5ygpSvnY0dcGfMhP/UrpoeRhgGi+xFvlTg/djH02/wDG6hjWJz+6K94ZQzamB2yrbTKrsL pYJkTmGkgAG1Dk+OTmhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmzOM-003uro-1A; Fri, 06 May 2022 14:57:14 +0000 Received: from mail-qv1-f49.google.com ([209.85.219.49]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmzOJ-003uqu-Us; Fri, 06 May 2022 14:57:13 +0000 Received: by mail-qv1-f49.google.com with SMTP id js14so5574201qvb.12; Fri, 06 May 2022 07:57:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFKDqxAl8kAhgchSspFlV1jC/a94gKje1e9uHi6vXps=; b=PeNKBKJmNkHXBxAv8lBfJpGekyHvIoLdJ2Yr/cdvqrIX8V0J0et/WbhV6oMrNsRUuG Ih15/6vqEtgw6BIK5J+PtpyuDY0APmNFzzhmgaMPI6PK5tGavJKZ9TZoUUg2HEVSXwh3 2RjUiR/BUZscEbeNmVK9FWIM/UvEVgisPzEMTmykmVOLbMkD5zJivuqdeuICVcx+wcQC zLvnq6xBhv0TJtITvNsi/uZMUStmC8nC0nmrcBgY2yWdK/Bdn6PjV+sBFNXgZoqXb33O gkcMVa0GAq9nOs8n5qrVDndntn5Xu4F7TOPez7/xmUcSh/KWwi92OQl3WY3iQYdJ3HmP 0IDg== X-Gm-Message-State: AOAM533LwiOblnb5lPcqqKKlkwz/Tqauq0Niar2J2I2253mwnDas8ac6 BPiUOxuueGY33Q2MipCslBCNnix4fMjbEA== X-Google-Smtp-Source: ABdhPJxWcYnjeVejrC7KpomPEgH4gEYBtxItbxpbM8PUAsHZB3HuJRi2jShvqAfUmmgglum6qLxGVw== X-Received: by 2002:ad4:5c6c:0:b0:45a:c466:6bca with SMTP id i12-20020ad45c6c000000b0045ac4666bcamr3116366qvh.43.1651849029327; Fri, 06 May 2022 07:57:09 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com. [209.85.219.176]) by smtp.gmail.com with ESMTPSA id n1-20020ac81e01000000b002f39b99f679sm2665525qtl.19.2022.05.06.07.57.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 07:57:08 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id m190so1767929ybf.4; Fri, 06 May 2022 07:57:08 -0700 (PDT) X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr2500583ybs.365.1651849027963; Fri, 06 May 2022 07:57:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 6 May 2022 16:56:56 +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: David Laight , Arnd Bergmann , 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 , 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" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_075712_033159_DF1D3058 X-CRM114-Status: GOOD ( 30.50 ) 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 Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ 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 9D59FC433EF for ; Fri, 6 May 2022 14:57:48 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KvtwB6zq7z3cDK for ; Sat, 7 May 2022 00:57:46 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=209.85.160.173; helo=mail-qt1-f173.google.com; envelope-from=geert.uytterhoeven@gmail.com; receiver=) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Kvtvl3Zrbz2yHZ for ; Sat, 7 May 2022 00:57:22 +1000 (AEST) Received: by mail-qt1-f173.google.com with SMTP id t16so6139201qtr.9 for ; Fri, 06 May 2022 07:57:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFKDqxAl8kAhgchSspFlV1jC/a94gKje1e9uHi6vXps=; b=tDNEoB109PiNGPZcrC3At4w1E8m7uelTXkpvxmFm5naS/08TnQutJjFW+nsFAZWV+4 WZUhV4ixG/yKT8GqJG5tbqgQYcDLLgmNeNql0ysgVZUdIbmqhheRXjHg97rXnyCKeNrJ muntDYUNxdUPLICXM68hcYzmrMJFyay8cXm6DID5B9w2mA/7oa7RsrFTVddiqbvpYAw9 x4aChqP/0iPnZLUSuroNeu35+bhoAhKQz59O1C9Tyqb0lddckf9pbhqglCi3C4FtSW7M iW+vo/cWPM2VaaVELxXhaFa56gFv2TL+qYP/fabVHBDWiWNqyCdHPDcHrdeCehYZxbsx rLRQ== X-Gm-Message-State: AOAM530rtiVDiK3ah+sKDj7nkAk687tZeJhNYdULOp17eZkZvilPjevt ASqqYjCgvUoKj/DeF1TpSSChKJ86+hWrmg== X-Google-Smtp-Source: ABdhPJzn9gNmm8JxTuobbmScvU7tFQv77IsYfj2Odeqap/A8fotTkpDv+7hhOOwTIspJqCSi2PxBzA== X-Received: by 2002:a05:622a:510:b0:2f3:81aa:cac2 with SMTP id l16-20020a05622a051000b002f381aacac2mr3078982qtx.679.1651849039836; Fri, 06 May 2022 07:57:19 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id a26-20020ac84d9a000000b002f39b99f676sm2611065qtw.16.2022.05.06.07.57.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 07:57:19 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id y76so13335183ybe.1 for ; Fri, 06 May 2022 07:57:18 -0700 (PDT) X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr2500583ybs.365.1651849027963; Fri, 06 May 2022 07:57:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 6 May 2022 16:56:56 +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 , Linux Kernel Mailing List , "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 , Bjorn Helgaas , 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 , Arnd Bergmann , Michal Simek , Thomas Bogendoerfer , "open list:PARISC ARCHITECTURE" , Greg Kroah-Hartman , "open list:MIPS" , David Laight , 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" Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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 35160C433EF for ; Fri, 6 May 2022 14:58:24 +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=YYSUceKIhiiKefDQLbc5PTjMGLVj0lo5gatszTWhPjA=; b=F7oUQ29T8wIRVq 1AGKxzI1Pr56pFXF/fD8dyawxYtLk679Mj4yrWo2sm9bDrSAsmIJhA6s23oFedvHQwCFTq9dDpTA6 Wob3I4Iy4ymwmBCjCb70XRUNGxoTsSGUm0Jt3BDL8YyX6VeMCH4Dyn0EItCy+jpuRPAbzMDyOs/hV DBHCSjOxuFcA2pHEnaJ+CPeKLZtAGxaIbb1YGtZdDahtVuIx8PTC32PXKX04R5StgoGDByNm+4Uj2 zCZlUn/NQso2RoigGIyI0vvgrWqIfEI/981up+xFDk6+NfuL8iU5BNTVpdqQD4TvwC2yFJCVvuXId +VBqAwoNsb2N2wQFHPsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmzON-003usL-Ro; Fri, 06 May 2022 14:57:15 +0000 Received: from mail-qv1-f49.google.com ([209.85.219.49]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmzOJ-003uqu-Us; Fri, 06 May 2022 14:57:13 +0000 Received: by mail-qv1-f49.google.com with SMTP id js14so5574201qvb.12; Fri, 06 May 2022 07:57:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFKDqxAl8kAhgchSspFlV1jC/a94gKje1e9uHi6vXps=; b=PeNKBKJmNkHXBxAv8lBfJpGekyHvIoLdJ2Yr/cdvqrIX8V0J0et/WbhV6oMrNsRUuG Ih15/6vqEtgw6BIK5J+PtpyuDY0APmNFzzhmgaMPI6PK5tGavJKZ9TZoUUg2HEVSXwh3 2RjUiR/BUZscEbeNmVK9FWIM/UvEVgisPzEMTmykmVOLbMkD5zJivuqdeuICVcx+wcQC zLvnq6xBhv0TJtITvNsi/uZMUStmC8nC0nmrcBgY2yWdK/Bdn6PjV+sBFNXgZoqXb33O gkcMVa0GAq9nOs8n5qrVDndntn5Xu4F7TOPez7/xmUcSh/KWwi92OQl3WY3iQYdJ3HmP 0IDg== X-Gm-Message-State: AOAM533LwiOblnb5lPcqqKKlkwz/Tqauq0Niar2J2I2253mwnDas8ac6 BPiUOxuueGY33Q2MipCslBCNnix4fMjbEA== X-Google-Smtp-Source: ABdhPJxWcYnjeVejrC7KpomPEgH4gEYBtxItbxpbM8PUAsHZB3HuJRi2jShvqAfUmmgglum6qLxGVw== X-Received: by 2002:ad4:5c6c:0:b0:45a:c466:6bca with SMTP id i12-20020ad45c6c000000b0045ac4666bcamr3116366qvh.43.1651849029327; Fri, 06 May 2022 07:57:09 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com. [209.85.219.176]) by smtp.gmail.com with ESMTPSA id n1-20020ac81e01000000b002f39b99f679sm2665525qtl.19.2022.05.06.07.57.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 07:57:08 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id m190so1767929ybf.4; Fri, 06 May 2022 07:57:08 -0700 (PDT) X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr2500583ybs.365.1651849027963; Fri, 06 May 2022 07:57:07 -0700 (PDT) MIME-Version: 1.0 References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 6 May 2022 16:56:56 +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: David Laight , Arnd Bergmann , 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 , 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" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_075712_033159_DF1D3058 X-CRM114-Status: GOOD ( 30.50 ) 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 Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ 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: Geert Uytterhoeven Date: Fri, 06 May 2022 14:56:56 +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> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Maciej W. Rozycki" Cc: David Laight , Arnd Bergmann , 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 , 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" Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Date: Fri, 6 May 2022 16:56:56 +0200 Message-ID: References: <20220505161028.GA492600@bhelgaas> <5239892986c94239a122ab2f7a18a7a5@AcuMS.aculab.com> <3669a28a055344a792b51439c953fd30@AcuMS.aculab.com> 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=lLs9Q/GXSSeJ9Y1omcI1ufexe/Zpv05YMBSI2hVPDpw=; b=Ac2YJcrq455QjP gu5NCEv45IWR8mKppKuERZeR+CkGSa5AOO0a23WT4fnJPcRHeE3tn23haJ/So+RN0u4XcQotTwLpJ 1FttCkAtp1QJNy5iEes1GwvSX61RU4Ws59dgNc0AAnir2Ckks+HUVVCRZmCrVoCjQcp3qF1/rFjDn n+Nqk6HuhiU7qctGQlzHW1iV1LmpIDH4j0xd89Vo50QFONYKc2V00TZAHzLxvU8vlxnt5kw17cPcy M9qkB2g5ygpSvnY0dcGfMhP/UrpoeRhgGi+xFvlTg/djH02/wDG6hjWJz+6K94ZQzamB2yrbTKrsL pYJkTmGkgAG1Dk+OTmhg==; 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: David Laight , Arnd Bergmann , 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 , linux-pci Hi Maciej, On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote: > On Fri, 6 May 2022, David Laight wrote: > > > It was retrofitted in that x86 systems already existed for ~15 years when > > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have > > > envisaged the need for config access instructions like they did for memory > > > and port access. > > > > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles. > > #2 is probably the first one and maps all of PCI config space into > > 4k of IO space (PCI bridges aren't supported). > > This one is even more horrid than #1 in that it requires two separate > preparatory I/O writes rather than just one, one to the Forward Register > (at 0xcfa) to set the bus number, and another to the Configuration Space > Enable Register (at 0xcf8) to set the function number, before you can > issue a configuration read or write to a device. So you need MP locking > too. > > NB only peer bridges aren't supported with this mechanism, normal PCI-PCI > bridges are, via the Forward Register. > > > #1 requires a pair of accesses (and SMP locking). > > > > Neither is really horrid. > > Both are. First neither is MP-safe and second both are indirect in that > you need to poke at some chipset registers before you can issue the actual > read or write. > > Sane access would require a single CPU instruction to read or write from > the configuration space. To access the conventional PCI configuration > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of > address space. Such amount of address space seems affordable even with > 32-bit systems. Won't have fit in the legacy 1 MiB space ("640 KiB..."). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds