linux-kernel - RE: [PATCH RFT 1/2] arm64: dts: toshiba: Update SoC and PCIe ranges to reflect hardware behavior

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <TY7PR01MB1481875AD0293961D0DB8738E925AA@TY7PR01MB14818.jpnprd01.prod.outlook.com>
Date: Mon, 28 Jul 2025 05:38:25 +0000
From: <nobuhiro1.iwamatsu@...hiba.co.jp>
To: <Frank.Li@....com>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <lpieralisi@...nel.org>,
        <kwilczynski@...nel.org>, <mani@...nel.org>, <bhelgaas@...gle.com>
CC: <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>
Subject: RE: [PATCH RFT 1/2] arm64: dts: toshiba: Update SoC and PCIe ranges
 to reflect hardware behavior

Hi Frank,

Thanks for your patch, and sorry reply was too late.

> -----Original Message-----
> From: Frank Li <Frank.Li@....com>
> Sent: Saturday, June 14, 2025 6:33 AM
> To: iwamatsu nobuhiro(岩松 信洋 □ＤＩＴＣ○ＣＰＴ)
> <nobuhiro1.iwamatsu@...hiba.co.jp>; Rob Herring <robh@...nel.org>;
> Krzysztof Kozlowski <krzk+dt@...nel.org>; Conor Dooley
> <conor+dt@...nel.org>; Lorenzo Pieralisi <lpieralisi@...nel.org>; Krzysztof
> Wilczyński <kwilczynski@...nel.org>; Manivannan Sadhasivam
> <mani@...nel.org>; Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: linux-arm-kernel@...ts.infradead.org; devicetree@...r.kernel.org;
> linux-kernel@...r.kernel.org; linux-pci@...r.kernel.org; Frank Li
> <Frank.Li@....com>
> Subject: [PATCH RFT 1/2] arm64: dts: toshiba: Update SoC and PCIe ranges to
> reflect hardware behavior
> 
> tmpv7708 trim address bit[31:30] in tmpv7708 before passing to the PCIe
> controller. So add a 'ranges' entry under the parent bus 'soc' to map address 0x0
> to 0x40000000.
> 
> Update the PCIe node's 'config' and 'ranges' properties to use the real upstream
> bus address.
> 
> Ensure there is no functional impact on the final address translation result.
> 
> Prepare for the removal of the driver’s cpu_addr_fixup().
> 
> Signed-off-by: Frank Li <Frank.Li@....com>
> ---
>  arch/arm64/boot/dts/toshiba/tmpv7708.dtsi | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
> b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
> index 39806f0ae5133..2a18aa93d4723 100644
> --- a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
> +++ b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
> @@ -147,7 +147,15 @@ soc {
>  		#size-cells = <2>;
>  		compatible = "simple-bus";
>  		interrupt-parent = <&gic>;
> -		ranges;
> +		ranges = /* register 1:1 map */
> +			 <0x0 0x24000000 0x0 0x24000000 0x0 0x10000000>,
> +			 /*
> +			  * bus fabric mask address bit 30 and 31 to 0
> +			  * before send to PCIe controller.
> +			  *
> +			  * PCIe map address 0 to cpu's 0x40000000
> +			  */
> +			 <0x0 0x00000000 0x0 0x40000000 0x0 0x40000000>;
> 
>  		gic: interrupt-controller@...01000 {
>  			compatible = "arm,gic-400";
> @@ -481,7 +489,7 @@ pwm: pwm@...c0000 {
>  		pcie: pcie@...00000 {
>  			compatible = "toshiba,visconti-pcie";
>  			reg = <0x0 0x28400000 0x0 0x00400000>,
> -			      <0x0 0x70000000 0x0 0x10000000>,
> +			      <0x0 0x30000000 0x0 0x10000000>,

If my understanding is correct, this setting conflicts with the address space this patch changed
ranges above. Therefore, it does not work.

0x24000000 + 0x10000000 > 0x30000000

By reducing 0x10000000 to 0xc000000, it will fit within the 0x30000000 range.  
And by adding the following to the driver:
```  
pci->use_parent_dt_ranges = true;  
```

the PCIe will work, but this setting prevents access to devices located after 0x30000000.
Is there any other DT method to avoid this?

Best regards,
  Nobuhiro