Re: [PATCH v1 07/11] ARM: dts: imx6ul: Reuse Variscite DTSI files for Concerto

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Devicetree ABI breakage: removal of Wi-Fi pwrseq and Bluetooth nodes
- [High] Hardware regression: missing no-1-8-v and non-removable on Wi-Fi SDIO
--

commit c9f442e674490d5de5d44643de9d80e88f35d5fe
Author: Stefano Radaelli <stefano.r@variscite.com>

ARM: dts: imx6ul: Reuse Variscite DTSI files for Concerto

This commit converts the i.MX6UL and i.MX6ULL Concerto boards to use shared
module and carrier DTSI files. It removes the old LVDS graph and drops the
kernel-managed Wi-Fi and Bluetooth nodes in favor of userspace control.

> The old Wi-Fi power sequence and Bluetooth nodes modeled enable and
> reset control in the kernel. On these SoMs those controls are handled
> in userspace, so use the shared Broadcom Wi-Fi description without the
> old kernel-managed nodes.

[Severity: High]
Does removing the hardware description of the Wi-Fi power sequence and
Bluetooth nodes break devicetree ABI compatibility?

Devicetree is meant to describe the physical hardware wiring (e.g., reset and
enable GPIOs), rather than userspace software policy. Without these nodes,
will standard upstream kernel drivers like mmc-pwrseq-simple and hci_uart
fail to probe and manage the hardware for users relying on a standard
mainline kernel?

[ ... ]

> diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi
> deleted file mode 100644
> index 6d16ff7909dab..0000000000000
> --- a/arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi
> +++ /dev/null

[ ... ]

> -&usdhc1 {
> -	#address-cells = <1>;
> -	#size-cells = <0>;
> -	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> -	pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_32k_clk>;
> -	pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_32k_clk>;
> -	pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_32k_clk>;
> -	no-1-8-v;
> -	non-removable;

[Severity: High]
Does the new imx6ul-imx6ull-var-som-wifi-brcm.dtsi file missing these
no-1-8-v and non-removable properties cause a hardware regression?

Without no-1-8-v, if the Wi-Fi chip advertises UHS support, the MMC core
will attempt to switch the bus to 1.8V, which will fail if there is no 1.8V
regulator configured.

Additionally, without non-removable and a cd-gpios property, will the MMC
core treat the soldered chip as a removable card and fall back to
continuously polling it, repeatedly waking the CPU?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790344389.git.stefano.r@variscite.com?part=7