Re: [PATCH v4 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

[Alex Elder <elder@riscstar.com>]

On 9/18/26 10:39 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] pci: MMIO translation failure due to static dummy ranges bypassing dynamic update

The same Sashiko report was made in version 2 of this series.
  
https://lore.kernel.org/sashiko-reviews/ed783639-05ed-4ad9-b881-d1689a8b2418@riscstar.com/

(I repeat and reword my explanation below.)

If I knew how to make Sashiko take into account the prerequisite
series I would gladly do so:
   https://lore.kernel.org/lkml/20260910021919.3421449-1-elder@riscstar.com/


> --
> 
> commit 07e53b54e0b29671e1a08f764661a81fe5484062
> Author: Alex Elder <elder@riscstar.com>
> 
> arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses
> 
> This commit adds devicetree nodes for a PCIe endpoint and its peripheral
> buses on the QCS6490 RB3gen2 platform. It also defines static ranges for
> the endpoint BARs, with the expectation that these will be updated
> dynamically.
> 
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index 3bb5fca8e2b13..5b7f5292a8864 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -955,11 +955,41 @@ pcie@3,0 {
>>   			bus-range = <0x5 0xff>;
>>   
>>   			dev@0,0 {
>> +				compatible = "pci1179,0220";
>>   				reg = <0x50000 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				/* Ranges will be updated dynamically */
>> +				ranges = <0x0 0x0 0x0  0x83050000 0x0 0x0  0x0 0x4000>,
> 
> [Severity: High]
> Does defining these dummy ranges statically bypass the dynamic update?
> 
> During PCI enumeration, pci_set_of_node() binds existing nodes like dev@0,0
> to the corresponding pci_dev. Later, when the PCI quirk calls
> of_pci_make_dev_node() to dynamically update the ranges,
> of_pci_make_dev_node() checks if (pci_device_to_OF_node(pdev)) and returns
> immediately without calling of_pci_add_properties().

The series mentioned above changes this code so that, rather
than returning immediately in this exact case, it updates the
ranges property to incorporate the BAR addresses assigned
during PCI enumeration.

> As a result, the dummy ranges are left intact, which causes child devices
> on the PCI endpoint bus to use these static ranges instead of the actual
> BAR addresses assigned by the PCI core. Will this lead to invalid memory
> accesses or driver probe failures?

And with the above series in place, the ranges are *not* left intact.

					-Alex

>> +					 <0x2 0x0 0x0  0x83050000 0x0 0x4000  0x0 0x80000>,
>> +					 <0x4 0x0 0x0  0x83050000 0x0 0x84000  0x0 0x200000>;
>> +
>> +				pci-ep-bus@4 {
>> +					compatible = "simple-bus";
>> +					#address-cells = <1>;
>> +					#size-cells = <1>;
>> +					/* Map 0x0-0x1fffff to BAR 4 */
>> +					ranges = <0x0  0x4 0x0 0x0  0x200000>;
>> +				};
>>   			};
>>   
>>   			dev@0,1 {
>> +				compatible = "pci1179,0220";
>>   				reg = <0x50100 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				/* Ranges will be updated dynamically */
>> +				ranges = <0x0 0x0 0x0  0x83050100 0x0 0x0  0x0 0x4000>,
> 
> [Severity: High]
> This appears to have the same issue. Because the dev@0,1 node is already
> present, the dynamic update logic in of_pci_make_dev_node() will bypass it.
> 
> Child devices under this node will then attempt to translate MMIO addresses
> using these static dummy ranges instead of the actual BAR addresses assigned
> by the PCI core.
>