Re: [PATCH v7 3/3] arm: dts: altera: add Draeger M48 CPU Module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: out-of-bounds IO read in gpio3/4 due to truncated reg size
--

commit 3110a5bc839de956f70473c018ac9b733616c145
Author: Petko Manolov <petko.manolov@konsulko.com>

arm: dts: altera: add Draeger M48 CPU Module
    
M48 is a heterogeneous board made by Draeger that is based on two
independent cpus, that are monitoring each other. One of them is
imx6, the other is Altera SoCFPGA Cyclone 5. The latter is booting
independently off qspi.

> diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_draeger_m48.dts b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_draeger_m48.dts
> new file mode 100644
> index 0000000000000..dae809c02adb8
> --- /dev/null
> +++ b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_draeger_m48.dts
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+

[ ... ]

> +	soc {
> +		gpio3: gpio@ff202000 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "snps,dw-apb-gpio";
> +			reg = <0xff202000 0x20>;

[Severity: High]
Does mapping a 0x20 byte resource window for the snps,dw-apb-gpio driver
trigger an out-of-bounds IO memory access on boot?

During probe in drivers/gpio/gpio-dwapb.c, dwapb_gpio_probe() calls
dwapb_gpio_add_port(), which passes gpio->regs + 0x50 (GPIO_EXT_PORTA)
to gpio_generic_chip_init(). This results in an unconditional read from
offset 0x50, which is outside the mapped 0x20 byte window.

On the Altera SoCFPGA's lightweight HPS-to-FPGA bridge, reading unmapped
addresses typically triggers an AXI bus error, leading to a synchronous
external abort and a kernel panic.

Is it possible the hardware here is actually an Altera PIO core
(altr,pio-1.0) given the 0x20 byte size?

> +
> +			portd: gpio-controller@0 {
> +				compatible = "snps,dw-apb-gpio-port";
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +				snps,nr-gpios = <2>;
> +				reg = <0>;
> +			};
> +		};
> +
> +		gpio4: gpio@ff202020 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "snps,dw-apb-gpio";
> +			reg = <0xff202020 0x20>;

[Severity: High]
Similarly, does mapping a 0x20 byte window for gpio4 at 0xff202020 cause
the same out-of-bounds IO read from offset 0x50 into unmapped MMIO space
during dwapb_gpio_add_port()?

> +
> +			porte: gpio-controller@0 {
> +				compatible = "snps,dw-apb-gpio-port";
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +				snps,nr-gpios = <2>;
> +				reg = <0>;
> +			};
> +		};
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921090735.3174292-1-petko.manolov@konsulko.com?part=3