Re: [PATCH v5 2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The property `microchip,spi-present-mask` is incorrectly defined as an 8-bit integer, which will cause a probe failure.
- [Medium] Missing `serial0` alias and namespace collision with `gpio2`.
- [Low] Alphabetical sorting violation in the TI device tree Makefile.
--

commit ac1670e1647cc8bb2691b4ba5ca55b12fd24da41
Author: Judith Mendez <jm@ti.com>

arm64: dts: ti: Add k3-am62l3-beaglebadge

This commit adds the device tree for the BeagleBoard.org BeagleBadge,
which is based on the AM62L3 SoC. It includes configurations for GPIO keys,
LEDs, PWM beepers, regulators, PMIC, and several I2C and SPI peripherals.

> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 5269c9619b65c..4e377ca011cd8 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62d2-evm.dtb
>  
>  # Boards with AM62Lx SoCs
>  dtb-$(CONFIG_ARCH_K3) += k3-am62l3-evm.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am62l3-beaglebadge.dtb

[Severity: Low]
This isn't a bug, but should this be sorted alphabetically? The other entries
in this Makefile usually follow alphabetical order, so k3-am62l3-beaglebadge.dtb
would normally be placed before k3-am62l3-evm.dtb.

[ ... ]

> diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
> new file mode 100644
> index 0000000000000..8e816d21a586f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
> @@ -0,0 +1,658 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * https://www.beagleboard.org/boards/beaglebadge
> + *
> + * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include "k3-am62l3.dtsi"
> +#include "k3-pinctrl.h"
> +
> +/ {
> +	compatible = "beagle,am62l3-beaglebadge", "ti,am62l3";
> +	model = "BeagleBoard.org BeagleBadge";
> +
> +	chosen {
> +		stdout-path = &uart0;
> +	};
> +
> +	aliases {
> +		gpio0 = &gpio0;
> +		gpio2 = &wkup_gpio0;

[Severity: Medium]
Will aliasing wkup_gpio0 to gpio2 cause an enumeration collision? 

The base k3-am62l-main.dtsi already defines a physical gpio2 controller, so
using ID 2 for wkup_gpio0 might conflict if the real gpio2 is ever enabled.

Also, since stdout-path uses uart0 and serial3 is aliased below, should there
be a serial0 alias for uart0 to ensure predictable /dev/ttyS* numbering?

> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c4 = &wkup_i2c0;
> +		mmc1 = &sdhci1;
> +		serial3 = &uart1;
> +	};

[ ... ]

> +&spi1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi1_pins_default>;
> +	status = "okay";
> +
> +	mcp23s18: gpio@0 {
> +		compatible = "microchip,mcp23s18";
> +		reg = <0>;
> +		spi-max-frequency = <10000000>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		reset-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&mcp23s18_reset_pins_default>;
> +		microchip,spi-present-mask = /bits/ 8 <0x01>;

[Severity: High]
Can this cause a probe failure?

The mcp23s08 pinctrl driver reads the microchip,spi-present-mask property
using device_property_read_u32().

By defining the property as an 8-bit integer, the property length in the
device tree is 1 byte instead of the 4 bytes required by
device_property_read_u32().

This could lead to of_property_read_variable_u32_array() returning
-EOVERFLOW, which would cause the mcp23s18 driver probe to fail and leave
the 7-segment displays non-functional.

> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526235417.1326187-1-jm@ti.com?part=2