Re: [PATCH v2 9/9] Bluetooth: hci_qca: Set 'bt_en_available' based on W_DISABLE2# presence in M.2 connector

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Architecture/Layering Violation: Bluetooth driver inspects internal DT properties of the power sequencer provider.
--

commit 30256477703156517ef407c26086261c2d43650f
Author: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Bluetooth: hci_qca: Set 'bt_en_available' based on W_DISABLE2# presence in M.2 connector

This commit checks if the M.2 connector supports the W_DISABLE2# property
by querying the power sequencer provider's device node. If unavailable, it
sets the 'bt_en_available' flag to false, which is used to set the
HCI_QUIRK_NON_PERSISTENT_SETUP quirk.

> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
[ ... ]
> @@ -2449,10 +2449,17 @@ static int qca_serdev_probe(struct serdev_device *serdev)
>  		 * the M.2 Key E connector.
>  		 */
>  		if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> +			struct device *dev;
> +
>  			qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
>  								   "uart");
>  			if (IS_ERR(qcadev->bt_power->pwrseq))
>  				return PTR_ERR(qcadev->bt_power->pwrseq);
> +
> +			dev = pwrseq_to_device(qcadev->bt_power->pwrseq);
> +			if (!device_property_present(dev, "w-disable2-gpios"))
> +				bt_en_available = false;

Does inspecting the internal properties of the power sequencer provider
break the pwrseq abstraction model?

By extracting the provider's device with pwrseq_to_device() and directly
querying the "w-disable2-gpios" property, the consumer (Bluetooth driver)
becomes tightly coupled to the internal hardware details of the power
sequencer.

Could this cause silent failures on platforms using ACPI, or if a different
power sequencer is used that handles resets without the "w-disable2-gpios"
property?

Would it be more robust if the pwrseq framework exposed a generic capability
query API rather than forcing consumers to parse the provider's device
properties?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260507-pwrseq-m2-bt-v2-0-1740bd478539@oss.qualcomm.com?part=9