[PATCH V2 3/8] arm64: tegra: Enable XUSB host function on Jetson AGX Thor

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect use of the GIC_SPI macro for GICv3 Extended SPIs (ESPIs), leading to invalid hardware IRQ mapping and kernel warnings at boot.
--

commit 25f7b692b008d6ac4dd9bcab2f8ae074b1c59801
Author: Wayne Chang <waynec at nvidia.com>

arm64: tegra: Enable XUSB host function on Jetson AGX Thor
    
Enable XUSB host and pad controller on Jetson AGX Thor.

> diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> index 013228a817237..e59b1b0a5b925 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> @@ -4147,6 +4147,160 @@ pci at 8480000 {
>  			nvidia,bpmp = <&bpmp 5>;
>  			status = "disabled";
>  		};
> +
> +		xusb_padctl: padctl at 8680000 {
> +			compatible = "nvidia,tegra264-xusb-padctl";
> +			reg = <0x00 0x8680000 0x00 0x20000>,
> +			      <0x00 0x86a0000 0x00 0x10000>;
> +			reg-names = "padctl", "ao";
> +			interrupts = <GIC_SPI 4101 IRQ_TYPE_LEVEL_HIGH>;

[Severity: Medium]
Does this use of GIC_SPI for INTID 4101 lead to an incorrect hardware IRQ
mapping?

The GICv3 DT bindings limit GIC_SPI indices to 0-987. During system boot,
when parsing the device tree to set up interrupts for padctl at 8680000, indices
greater than 987 emit a warning and map to index + 32, which would compute to
4133 instead of 4101.

Should this use the GIC_ESPI macro with a 0-based index (e.g., GIC_ESPI 5) to
correctly specify the ESPI?

[ ... ]

> +		usb at aa10000 {
> +			compatible = "nvidia,tegra264-xusb";
> +			reg = <0x00 0xaa10000 0x00 0x40000>,
> +			      <0x00 0xaa00000 0x00 0x10000>,
> +			      <0x00 0xaa50000 0x00 0x10000>;
> +			reg-names = "hcd", "fpci", "bar2";
> +
> +			interrupts-extended = <&gic GIC_SPI 952 IRQ_TYPE_LEVEL_HIGH>,
> +						  <&gic GIC_SPI 4096 IRQ_TYPE_LEVEL_HIGH>,

[Severity: Medium]
Similarly, does this map to the wrong hardware interrupt (4128 instead of
4096) due to the use of GIC_SPI for an ESPI?

This will likely trigger a "SPI 4096 out of range (use ESPI?)" warning during
boot when parsing the usb at aa10000 node, and could break USB functionality.

Should this use GIC_ESPI 0 instead?

> +						  <&pmc 79 IRQ_TYPE_LEVEL_HIGH>,
> +						  <&pmc 80 IRQ_TYPE_LEVEL_HIGH>,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831185835.3732707-1-waynec@nvidia.com?part=3