From nobody Sun May 10 17:54:32 2026 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 E574BC433EF for ; Wed, 27 Apr 2022 22:16:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234185AbiD0WTQ (ORCPT ); Wed, 27 Apr 2022 18:19:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237989AbiD0WTC (ORCPT ); Wed, 27 Apr 2022 18:19:02 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ECFAC13F21 for ; Wed, 27 Apr 2022 15:15:48 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 4E5C192009C; Thu, 28 Apr 2022 00:15:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 480CF92009B; Wed, 27 Apr 2022 23:15:47 +0100 (BST) Date: Wed, 27 Apr 2022 23:15:47 +0100 (BST) From: "Maciej W. Rozycki" To: Paul Walmsley , Palmer Dabbelt , Albert Ou cc: Bjorn Helgaas , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH] RISC-V: PCI: Avoid handing out address 0 to devices Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For RISC-V platforms we permit assigning addresses from 0 to PCI devices, both in the memory and the I/O bus space, and we happily do so if there=20 is no conflict, e.g.: pci 0000:07:00.0: BAR 0: assigned [io 0x0000-0x0007] pci 0000:07:00.1: BAR 0: assigned [io 0x0008-0x000f] pci 0000:06:01.0: PCI bridge to [bus 07] pci 0000:06:01.0: bridge window [io 0x0000-0x0fff] (with the SiFive HiFive Unmatched RISC-V board and a dual serial port=20 option card based on the OxSemi OXPCIe952 device wired for the legacy=20 UART mode). Address 0 is treated specially however in many places, for example in=20 `pci_iomap_range' and `pci_iomap_wc_range' we require that the start=20 address is non-zero, and even if we let such an address through, then=20 individual device drivers could reject a request to handle a device at=20 such an address, such as in `uart_configure_port'. Consequently given devices configured as shown above only one is actually usable: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:07:00.0: enabling device (0000 -> 0001) serial: probe of 0000:07:00.0 failed with error -12 serial 0000:07:00.1: enabling device (0000 -> 0001) serial 0000:07:00.1: detected caps 00000700 should be 00000500 0000:07:00.1: ttyS0 at I/O 0x8 (irq =3D 39, base_baud =3D 15625000) is a 16= C950/954 Therefore avoid handing out address 0, by bumping the lowest address=20 available to PCI via PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM up by 4 and 16=20 respectively, which is the minimum allocation size for I/O and memory=20 BARs. With this in place the system in question we have: pci 0000:07:00.0: BAR 0: assigned [io 0x1000-0x1007] pci 0000:07:00.1: BAR 0: assigned [io 0x1008-0x100f] pci 0000:06:01.0: PCI bridge to [bus 07] pci 0000:06:01.0: bridge window [io 0x1000-0x1fff] and then devices work correctly: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:07:00.0: enabling device (0000 -> 0001) serial 0000:07:00.0: detected caps 00000700 should be 00000500 0000:07:00.0: ttyS0 at I/O 0x1000 (irq =3D 38, base_baud =3D 15625000) is a= 16C950/954 serial 0000:07:00.1: enabling device (0000 -> 0001) serial 0000:07:00.1: detected caps 00000700 should be 00000500 0000:07:00.1: ttyS1 at I/O 0x1008 (irq =3D 39, base_baud =3D 15625000) is a= 16C950/954 Especially I/O space ranges are particularly valuable, because bridges=20 only decode bits from 12 up and consequently where 16-bit addressing is=20 in effect, as few as 16 separate ranges can be assigned to individual=20 buses only, however a generic change to avoid handing out address 0 only=20 has turned out controversial as per the discussion referred via the link=20 below. Conversely sorting this out in platform code has been standard practice=20 since forever to avoid a clash with legacy devices subtractively decoded=20 by the southbridge where present. This can be revised should a generic=20 solution be adopted sometime. Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202260044180.25061@angie.o= rcam.me.uk --- Hi, NB I have an OxSemi OXPCIe952 based card that can be wired to either the=20 native or the legacy mode via a jumper block and I am so glad that I have=20 checked whether it works in the legacy mode as well. I guess there are so=20 few legacy-free platforms still for nobody else to notice this issue yet. Maciej --- arch/riscv/include/asm/pci.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) linux-riscv-pcibios-min.diff Index: linux-macro/arch/riscv/include/asm/pci.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- linux-macro.orig/arch/riscv/include/asm/pci.h +++ linux-macro/arch/riscv/include/asm/pci.h @@ -12,8 +12,8 @@ =20 #include =20 -#define PCIBIOS_MIN_IO 0 -#define PCIBIOS_MIN_MEM 0 +#define PCIBIOS_MIN_IO 4 +#define PCIBIOS_MIN_MEM 16 =20 /* RISC-V shim does not initialize PCI bus */ #define pcibios_assign_all_busses() 1