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 1FA22C433EF for ; Fri, 22 Jul 2022 19:23:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232272AbiGVTXk (ORCPT ); Fri, 22 Jul 2022 15:23:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbiGVTXj (ORCPT ); Fri, 22 Jul 2022 15:23:39 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A35EE5F13D; Fri, 22 Jul 2022 12:23:38 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 94A7192009C; Fri, 22 Jul 2022 21:23:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 8971D92009B; Fri, 22 Jul 2022 20:23:36 +0100 (BST) Date: Fri, 22 Jul 2022 20:23:36 +0100 (BST) From: "Maciej W. Rozycki" To: Rob Herring cc: Palmer Dabbelt , Bjorn Helgaas , Stafford Horne , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Catalin Marinas , Will Deacon , Guo Ren , Paul Walmsley , Albert Ou , Richard Weinberger , Anton Ivanov , Johannes Berg , linux-arm-kernel , linux-csky@vger.kernel.org, linux-riscv , linux-um@lists.infradead.org, PCI , "open list:GENERIC INCLUDE/ASM HEADER FILES" Subject: Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Fri, 22 Jul 2022, Rob Herring wrote: > > Maybe the right thing to do here is actually to make the default > > definitions of these macros non-zero, or to add some sort of ARCH_ > > flavor of them and move that non-zero requirement closer to where it > > comes from? From the look of it any port that uses the generic port I/O > > functions and has 0 for these will be broken in the same way. > > > > That said, I'm not really a PCI guy so maybe Bjorn or Maciej has a > > better idea? > > >From fu740: > ranges = <0x81000000 0x0 0x60080000 0x0 > 0x60080000 0x0 0x10000>, /* I/O */ > <0x82000000 0x0 0x60090000 0x0 > 0x60090000 0x0 0xff70000>, /* mem */ > <0x82000000 0x0 0x70000000 0x0 > 0x70000000 0x0 0x1000000>, /* mem */ > <0xc3000000 0x20 0x00000000 0x20 > 0x00000000 0x20 0x00000000>; /* mem prefetchable */ > > So again, how does one get a 0 address handed out when that's not even > a valid region according to DT? Is there some legacy stuff that > ignores the bridge windows? It doesn't matter as just sets it as a generic parameter for the platform, reflecting the limitation of PCI core, which in the course of the discussion referred was found rather infeasible to remove. The FU740 does not decode to PCI at 0, but another RISC-V device could. And I think that DT should faithfully describe hardware and not our software limitations. Mind that PCI has originated from the x86 world where decoding low 24-bit memory space to ISA has been implied (implicitly decoded on PCI systems by the southbridge) for areas not decoded to DRAM by the memory controller. So the inability of our PCI core to handle MMIO at 0 did not matter at the time it was introduced as the value of 0 would never be used for a memory BAR. Maciej