Re: [PATCH 5/8] arm64: dts: qcom: sm6350-lena: Enable Bluetooth

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: silent pinctrl override failures on UART pins due to missing /delete-property/
--

commit bed8cbd842a7138947e9a27eb01373050b147335
Author: erebion <erebion@erebion.eu>

arm64: dts: qcom: sm6350-lena: Enable Bluetooth
    
Configure the required regulators for Bluetooth and enable it on the
Xperia 10 III.

> diff --git a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> index 146c7c5c45ea2..cb749cc121abf 100644
> --- a/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6350-sony-xperia-lena-pdx213.dts
[ ... ]
> @@ -392,6 +396,40 @@ &qupv3_id_1 {
>  	status = "okay";
>  };
>  
> +/* UART1: HS UART for Bluetooth */
> +&qup_uart1_cts {
> +	/*
> +	 * Configure a bias-bus-hold on CTS to lower power
> +	 * usage when Bluetooth is turned off. Bus hold will
> +	 * maintain a low power state regardless of whether
> +	 * the Bluetooth module drives the pin in either
> +	 * direction or leaves the pin fully unpowered.
> +	 */
> +	bias-bus-hold;
> +};

[Severity: Medium]
Since device tree overlays merge boolean properties rather than replacing them,
both the new and inherited properties will be present in the node.

The generic pinctrl parser evaluates properties in a fixed order, which causes
the inherited bias-disable to be evaluated after bias-bus-hold. Does this need
an explicit /delete-property/ bias-disable; to prevent the bus-hold from
being silently ignored and causing power leakage?

> +
> +&qup_uart1_rts {
> +	/* We'll drive RTS, so no pull */
> +	drive-strength = <2>;
> +	bias-disable;
> +};

[Severity: Medium]
Will this silently leave the pull-down enabled?

Similar to the CTS pin above, if the base node has bias-pull-down, merging
bias-disable doesn't remove it. The parser will evaluate the inherited
bias-pull-down after bias-disable, causing the pull to remain active. 
Should this include /delete-property/ bias-pull-down; to ensure the bias
is actually disabled?

> +
> +&qup_uart1_rx {
> +	/*
> +	 * Configure a pull-up on RX. This is needed to avoid
> +	 * garbage data when the TX pin of the Bluetooth module is
> +	 * in tri-state (module powered off or not driving the
> +	 * signal yet).
> +	 */
> +	bias-pull-up;
> +};
> +
> +&qup_uart1_tx {
> +	/* We'll drive TX, so no pull */
> +	drive-strength = <2>;
> +	bias-disable;
> +};

[Severity: Medium]
Does this face the same property merging issue with the inherited pull-up?

If the base node defines bias-pull-up, it will be evaluated after bias-disable,
silently overriding it. Should this include /delete-property/ bias-pull-up;
to ensure the pin bias is disabled as intended?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-pdx213-upstream-3-v1-0-1609c18b5c1d@erebion.eu?part=5