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 32ACBCFB424 for ; Sun, 6 Oct 2024 11:22:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Type:MIME-Version:References:Message-ID:Subject:To:Date:From:Reply-To :Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rPsiLERRYU7D4j4sUXncuZrtdOCgoc8Hb9DOFm6I+ts=; b=yelw1zugKr4AfSEEdwyD+5+Yyl VgjbaArYPTsUrOl7p/ns+grR8zB/HrcOaQdKFhIQedzdG5JErf2o9S9+NjQMQ/HXfhh4ke7YEnPCN OOFGigpCuPi/G0i3/CFyt3cSvFv+OuMnoPBqhvPuv5B4i5A/LUqy1q9Iqs/819yIiHZl5n32tO9N4 1JFT1zyub8OIlaf6e2fJ/A8c8X3mDsG7uLPXjnX8FfDM34nkD8mtQRCbh5c1ZnqIPk/3qCvq7sar3 pzgCnQ5MlrvRcPWGeTN3fvvzFjGwjZNEv+rU4aS8d/AhEpAkzt3KH9D/xilQOKa3nSy8HJxekLoPi bxh5lbZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxPKp-0000000Ha7C-36Qo; Sun, 06 Oct 2024 11:21:59 +0000 Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sxPJW-0000000HZwz-1n7x for linux-arm-kernel@lists.infradead.org; Sun, 06 Oct 2024 11:20:40 +0000 Received: by mail-ej1-x641.google.com with SMTP id a640c23a62f3a-a7aa086b077so409471266b.0 for ; Sun, 06 Oct 2024 04:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1728213636; x=1728818436; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=rPsiLERRYU7D4j4sUXncuZrtdOCgoc8Hb9DOFm6I+ts=; b=FRR1C1xlrUwDrUDqpD5Ms5rfWSaBZ0vy44Xx27Rvi83FrcHBm2cTGiP8mc5CVUTWXu kaYh/I0eWXZIi0BnMy4GrYic+5ck5emefWg4/b69aF+gTYcnR4H360AzD8hcNTn/0sWV Gek7MLh2kl3dusvpIpJOEQ1jSU8MbnNp/YZ4kJBUxuHn2bOyjUbThYNwl+2ULAggVxgh qShW8ws8KM+huidSwAA7zprzEpuRp69FVR6fapicWoDEGPi798ijKmxgslpe6AUafofV s0pSgZ6JX18EiJ6lQFNFFmaIr2Bqa7t7adxmx+iP/OkxstHA4+8BDqvUlnfUI+5zwjLJ I0Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728213636; x=1728818436; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rPsiLERRYU7D4j4sUXncuZrtdOCgoc8Hb9DOFm6I+ts=; b=OIZlg0Zuz91RBa1FWJVDYVctXy+laPXu6rKDAVtAQoAJZcamxNtEP+hobEQRPz9hmz IECT+vmv9MwZZjRE08OOylRtR3p/2BcuERzXWsnYKGy4mUWS9YacZtnoz65D3k/y0nw6 u78WOhh/WgNdsodF0AG34fnH4IxW2R5UJIhEEuNlep3FxhJYFiBwFkRU+ECc3D1FS/lK 1c3ZQ4Zl+TQJSAxXNV248H8N41FHh/zv/zwXfbbRSl1mQ2PrbuQElDJ5F5sPUJGFqeqb qFX7sMkRorvG0npb8T8vkPNapPRO8vdg96/Qq73TYrw1N3bB6MEchh60SU35pe301gXP tWAQ== X-Forwarded-Encrypted: i=1; AJvYcCUDW5ZcDnQ81skG50NG+tc2WzUP1OVD56qx16cP1msRHelqUruCI1MOuHN8PbvyojmnPBpCRTBX0Hp5kOixFcr7@lists.infradead.org X-Gm-Message-State: AOJu0YyhfAQZ6t98nboDdj6acYE4AKxG/AuSjrrrXtC2ECDSs3Xai0xc sAZIu8xhUH9GjexW6JP4sv1PZznYLsYJYhBxtdm7Vin7jLX7eqG0bA2rtl3t0aU= X-Google-Smtp-Source: AGHT+IG48id+lRY4xtL1ujqx4VpcR8QxySGV9q44wlS56hapCTBDQPNEacp1RsUNT7MPHUN2ohWifQ== X-Received: by 2002:a17:907:7f89:b0:a99:435c:89f2 with SMTP id a640c23a62f3a-a99435c8ce0mr357354766b.63.1728213635990; Sun, 06 Oct 2024 04:20:35 -0700 (PDT) Received: from localhost (host-79-32-222-228.retail.telecomitalia.it. [79.32.222.228]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a993d92ed5dsm185689766b.63.2024.10.06.04.20.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Oct 2024 04:20:35 -0700 (PDT) From: Andrea della Porta X-Google-Original-From: Andrea della Porta Date: Sun, 6 Oct 2024 13:20:51 +0200 To: Bjorn Helgaas Subject: Re: [PATCH 03/11] PCI: of_property: Sanitize 32 bit PCI address parsed from DT Message-ID: References: <20240928201717.GA99402@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240928201717.GA99402@bhelgaas> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241006_042038_514702_88939101 X-CRM114-Status: GOOD ( 39.94 ) 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: , Cc: Andrew Lunn , Catalin Marinas , Michael Turquette , Claudiu Beznea , Lizhi Hou , Eric Dumazet , Dragan Cvetic , Will Deacon , linux-clk@vger.kernel.org, linux-arch@vger.kernel.org, Rob Herring , Florian Fainelli , Lee Jones , Saravana Kannan , Broadcom internal kernel review list , linux-pci@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Linus Walleij , devicetree@vger.kernel.org, Conor Dooley , Arnd Bergmann , linux-gpio@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, Bjorn Helgaas , Andrea della Porta , linux-arm-kernel@lists.infradead.org, Derek Kiernan , Stephen Boyd , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Stefan Wahren , netdev@vger.kernel.org, Krzysztof Kozlowski , "David S. Miller" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Bjorn, On 15:17 Sat 28 Sep , Bjorn Helgaas wrote: ... > From your earlier email > (https://lore.kernel.org/r/Zszcps6bnCcdFa54@apocalypse): > > > Without this patch the range translation chain is broken, like this: > > > pcie@120000: <0x2000000 0x00 0x00 0x1f 0x00 0x00 0xfffffffc>; > > ~~~ chain breaks here ~~~ > > pci@0 : <0x82000000 0x1f 0x00 0x82000000 0x1f 0x00 0x00 0x600000>; > > dev@0,0 : <0x01 0x00 0x00 0x82010000 0x1f 0x00 0x00 0x400000>; > > rp1@0 : <0xc0 0x40000000 0x01 0x00 0x00 0x00 0x400000>; > > The cover letter said "RP1 is an MFD chipset that acts as a > south-bridge PCIe endpoint .. the RP1 as an endpoint itself is > discoverable via usual PCI enumeration". > > I assume pcie@120000 is the PCI host bridge and is already in the > original DT describing the platform. I assume pci@0 is a Root Port > and dev@0,0 is the RP1 Endpoint, and the existing code already adds > them as they are enumerated when pci_bus_add_device() calls > of_pci_make_dev_node(), and I think this series adds the rp1@0 > description. Correct. > > And the "ranges" properties are built when of_pci_make_dev_node() > eventually calls of_pci_prop_ranges(). With reference to sec 2.2.1.1 > of https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf > and > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#ranges, > I *think* your example says: > > pcie@120000 has: > child phys.hi 0x02000000 n=0 p=0 t=0 ss=10b > child phys.mid,lo 0x00000000_00000000 > parent phys.hi,lo 0x0000001f_00000000 > length hi,lo 0x00000000_fffffffc > > which would make it a bridge where the child (PCI) address space is > relocatable non-prefetchable 32-bit memory space at > 0x00000000-0xfffffffc, and the corresponding parent address space is > 0x1f_00000000-0x1f_fffffffc. That means the host bridge applies an > address translation of "child_addr = parent_addr - 0x1f_00000000". > > pci@0 has: > child phys.hi 0x82000000 n=1 p=0 t=0 ss=10b > child phys.mid,lo 0x0000001f_00000000 > parent phys.hi 0x82000000 n=1 p=0 t=0 ss=10b > parent phys.mid,lo 0x0000001f_00000000 > length hi,lo 0x00000000_00600000 > > which would make it a PCI-to-PCI bridge (I assume a PCIe Root Port), > where the child (secondary bus) address space is the non-relocatable > non-prefetchable 32-bit memory space 0x1f_00000000-0x1f_005fffff and > the parent (primary bus) address space is also non-relocatable > non-prefetchable 32-bit memory space at 0x1f_00000000-0x1f_005fffff. > > This looks wrong to me because the pci@0 parent address space > (0x1f_00000000-0x1f_005fffff) should be inside the pcie@120000 child > address space (0x00000000-0xfffffffc), but it's not. Exactly, that example refers to the 'uncorrected' case, i.e. without the patch applied. > > IIUC, this patch clears the upper 32 bits in the pci@0 parent address > space. That would make things work correctly in this case because > that happens to be the exact translation of pcie@120000, so it results > in pci@0 parent address space of 0x00000000-0x005fffff. Right. I think we sould split it into two issues: [1] RP1 acknowledges a 32 bit BAR address from its config space while the device must be accessed using a 64 bit address (that is cpu address 0x1f_00000000), which sounds strange to me but I guess that is how the hw interconnect has been designed, so we need to cope with it. [2] I still think that the of_pci_set_address() function should be amended to avoid generating invalid 64 address when 32 bit flag is set. As you noted, fixing [2] will incidentally also let [1] work: I think we can try to solve [1] the proper way and maybe defer [2] for a separate patch. To solve [1] I've dropped this patch and tried to solve it from devicetree, modifying the following mapping: pcie@120000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>; so we now have a 1:1 64 bit mapping from 0x1f_00000000 to 0x1f_00000000. I thought it would result in something like this: pcie@120000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>; pci@0 : <0x82000000 0x1f 0x00 0x82000000 0x1f 0x00 0x00 0x600000>; dev@0,0 : <0x01 0x00 0x00 0x82010000 0x1f 0x00 0x00 0x400000>; rp1@0 : <0xc0 0x40000000 0x01 0x00 0x00 0x00 0x400000>; but it fails instead (err: "can't assign; no space") in pci_assign_resource() function trying to match the size using pci_clip_resource_to_region(). It turned out that the clipping is done against 32 bit memory region 'pci_32_bit',and this is failing because the original region addresses to be clipped wxxiereas 64 bit wide. The 'culprit' seems to be the function devm_of_pci_get_host_bridge_resources() dropping IORESOURCE_MEM_64 on any memory resource, which seems to be a change somewhat specific to a RK3399 case (see commit 3bd6b8271ee66), but I'm not sure whether it can be considered generic. So, I'm actually at an empasse here. Also, while taking a look at the resulting devicetree, I'm a bit confused by the fact that the parent address generated by of_pci_prop_ranges() for the pci@0,0 bridge seems to be taken from the parent address of the pcie@120000 node. Shouldn't it be taken from the child address of pcie@120000, instead? > > But I don't think it works in general because there's no requirement > that the host bridge address translation be that simple. For example, > if we have two host bridges, and we want each to have 2GB of 32-bit > PCI address space starting at 0x0, it might look like this: > > 0x00000002_00000000 -> PCI 0x00000000 (subtract 0x00000002_00000000) > 0x00000002_80000000 -> PCI 0x00000000 (subtract 0x00000002_80000000) > > In this case simply ignoring the high 32 bits of the CPU address isn't > the correct translation for the second host bridge. I think we should > look at each host bridge's "ranges", find the difference between its > parent and child addresses, and apply the same difference to > everything below that bridge. Not sure I've got this scenario straight: can you please provide the topology and the bit setting (32/64 bit) for those ranges? Also, is this scenario coming from a real use case or is it hypothetical? Many thanks, Andrea ...