Re: [PATCH 10/11] arm64: dts: apple: Initial T603[124] (M3 Max and Ultra) device trees

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Duplicate MPIDR in `cpu_p25` `reg` property.
- [Medium] Use of deprecated `label` property in `led-0` node.
- [Low] Device Tree node name unit-address mismatch for `i2c6`.
- [Low] Redundant inline `aic` node definition in `die0`.
--

--- Patch [10]: [PATCH 10/11] arm64: dts: apple: Initial T603[124] (M3 Max and Ultra) device trees ---
commit afdb3bddf1523598fd74d4dfc1254a53801825fd
Author: Janne Grunau <[email protected]>

arm64: dts: apple: Initial T603[124] (M3 Max and Ultra) device trees

Contains minimal device trees for all M3 Max and Ultra Apple silicon
devices. Those are 14-inch and 16-inch MacBook Pros with M3 Max released
in November 2023 and Mac Studio with M3 Ultra released in 2025.

> diff --git a/arch/arm64/boot/dts/apple/t6031-die0.dtsi b/arch/arm64/boot/dts/apple/t6031-die0.dtsi
> index 0000000000000..73f079312a538
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t6031-die0.dtsi

[ ... ]

> +	i2c6: i2c@39102c800 {
> +		compatible = "apple,t6031-i2c", "apple,t8103-i2c";
> +		reg = <0x3 0x91028000 0x0 0x4000>;

[Severity: Low]
Is there a typo in this node's unit address? The node name i2c@39102c800
does not match the reg property address of 0x91028000, which translates to
physical address 0x391028000. This mismatch causes a DTC compiler warning.

[ ... ]

> diff --git a/arch/arm64/boot/dts/apple/t6032.dtsi b/arch/arm64/boot/dts/apple/t6032.dtsi
> index 0000000000000..529e825c8da02
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t6032.dtsi

[ ... ]

> +		cpu_p25: cpu@10905 {
> +			compatible = "apple,everest";
> +			device_type = "cpu";
> +			reg = <0x0 0x10105>;

[Severity: High]
Does this reg property accidentally duplicate the MPIDR of cpu_p05? The
node name indicates 10905, but the reg address is 10105. This hardware
description mismatch might cause kernel CPU enumeration to fail or behave
incorrectly for the 6th core of cluster 4.

[ ... ]

> +	die0: soc@200000000 {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;

[ ... ]

> +		aic: interrupt-controller@292400000 {
> +			compatible = "apple,t8122-aic3";
> +			#interrupt-cells = <4>;
> +			interrupt-controller;
> +
> +			/*
> +			 * reg[0]: Main MMIO range (approx 1.8 MB)
> +			 * reg[1]: CPU Event/IACK register page (Base + 0x40000)
> +			 */
> +			reg = <0x00000002 0x92400000 0x00000000 0x1cc000>,
> +				<0x00000002 0x92440000 0x00000000 0x4000>;
> +		};
> +	};

[Severity: Low]
Is it necessary to define the aic node inline here? It looks like this
gets merged with and largely overwritten by the inclusion of
t6031-die0.dtsi further down in the file, which defines the same node
more completely including power-domains and reg-names.

[ ... ]

> diff --git a/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi b/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi
> index 0000000000000..467d95cdaf6be
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi

[ ... ]

> +	led-controller {
> +		compatible = "pwm-leds";
> +		led-0 {
> +			pwms = <&fpwm0 0 40000>;
> +			label = "kbd_backlight";
> +			function = LED_FUNCTION_KBD_BACKLIGHT;

[Severity: Medium]
Should this avoid using the deprecated label property? Modern user-space
LED managers rely on standard sysfs directories named color:function.
Using the label property overrides standard naming and prevents user-space
from correctly identifying the LED's hardware role.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-apple-t603x-initial-devices-v1-0-55b305833123@jannau.net?part=10