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 C173DC433EF for ; Fri, 22 Jul 2022 19:24:13 +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:MIME-Version:References:Message-ID: In-Reply-To:Subject:cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6eRq2Tr9/tDUdh2tZ2jSJ43+XiekLujgLXKje6cxc6c=; b=gA6lS4VD/VDaXf dO0TLKnOavRoabg7NbuocK46G/TOgbc8k0l2LzLDLMsu3yEyBSa2clLuBt0KTgKldXRi9a1fG3g0J SuAOU/TybGcM7hVFBN6lVlKu6GpcIXHh++6Wgv6wPF9yK+wZ73dnv5Mqc3Isw7H+UC3EsmTNXU9S7 9UF/Wm1BJeDVWuVOod/xhcAPzEj2S5vj1UD+0v1bULy8PRnbYRW9PeRJTVbWP4/53M6bef57lgbZa 8lfluI9d8tnF8Wq7eYSlUh6EFccvA7YkIvWBhtY/UhxZgcvEnzKo0q82z97isV69vAzFyPt+rYefA Hi2Yz2gMdO9PegmNac0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEyFk-009LJ7-8k; Fri, 22 Jul 2022 19:24:00 +0000 Received: from angie.orcam.me.uk ([2001:4190:8020::34]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEyFW-009L84-Cd; Fri, 22 Jul 2022 19:23:48 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220722_122346_628385_0CC19875 X-CRM114-Status: GOOD ( 19.14 ) 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 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv