Re: [PATCH v2] arm64: dts: qcom: shikra-evk: Add GPIO expanders

[Komal Bajaj <komal.bajaj@oss.qualcomm.com>]

On 9/29/2026 2:14 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Low] dts: incorrect hardware compatible string for GPIO expanders
> - [Low] dts: devicetree schema violation for GPIO node names
> - [Low] dts: unsorted i2c child nodes
> --
>
> commit 9c266369a865f519d07da1f291fbd2938e091d86
> Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>
> arm64: dts: qcom: shikra-evk: Add GPIO expanders
>
> This commit adds the EVK GPIO expander definitions to the I2C3 bus for the
> shikra-evk board. It describes the TCA9538 and TCA9539 expanders used by
> the EVK boards.
>
> Link: https://lore.kernel.org/r/20260924-shikra-gpio-expander-v1-1-71929498ea44@oss.qualcomm.com
>
>> diff --git a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
>> index da484887110b0..ecc6301179400 100644
>> --- a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
>> @@ -11,6 +11,38 @@ &gpu_zap_shader {
>>   	firmware-name = "qcom/shikra/a704_zap.mbn";
>>   };
>>   
>> +&i2c3 {
>> +	status = "okay";
>> +
>> +	expander0: pca953x@38 {
> [Severity: Low]
> Should the child nodes of the i2c3 bus be sorted by unit address in
> ascending order? The node at unit address 38 currently precedes the nodes
> at unit addresses 20 and 21.

I will reorder child nodes by ascending unit address in next revision.

>
> [Severity: Low]
> Should this node be named gpio@38 instead of pca953x@38? The generic node
> name recommendation suggests using 'gpio', which helps avoid dt-schema
> validation warnings during dtbs_check.

Agree. I will rename it to gpio@38 in next revision.

>
>> +		compatible = "ti,tca9538";
>> +		reg = <0x38>;
> [Severity: Low]
> Does the TCA9538 hardware actually support the 0x38 I2C address? The 0x38
> address natively belongs to a TCA9554A or PCA9534A. While the gpio-pca953x
> driver abstracts these expanders using identical logic, should the
> devicetree accurately describe the physical hardware limitations?

The hardware configuration, including assigned I2C address, has been 
verified against board schematics. The address assignment in this design 
is intentional. Same applies for TCA9539 hardware.

>
>> +		#gpio-cells = <2>;
>> +		gpio-controller;
>> +	};
>> +
>> +	expander1: pca953x@3c {
>> +		compatible = "ti,tca9538";
>> +		reg = <0x3c>;
> [Severity: Low]
> Is this address physically possible for a TCA9538? Configuring an offset
> of +4 requires an A2 address pin, which the TCA9538 physically lacks.

This is correct, has been verified against board schematics.

Thanks
Komal

>
>> +		#gpio-cells = <2>;
>> +		gpio-controller;
>> +	};
>> +
>> +	expander2: pca953x@20 {
>> +		compatible = "ti,tca9539";
>> +		reg = <0x20>;
> [Severity: Low]
> Does this setup actually use a TCA9539, or might it be a TCA9535? The I2C
> address 0x20 natively belongs to a TCA9535, so this compatible string claims
> hardware at an address it cannot physically occupy.
>
>> +		#gpio-cells = <2>;
>> +		gpio-controller;
>> +	};
>> +
>> +	expander3: pca953x@21 {
>> +		compatible = "ti,tca9539";
>> +		reg = <0x21>;
> [Severity: Low]
> Similar to the node above, does this represent a TCA9535? Address 0x21
> is the hardware address for a TCA9535, not a TCA9539.
>
>> +		#gpio-cells = <2>;
>> +		gpio-controller;
>> +	};
>> +};
> [ ... ]
>