Re: [PATCH v4 12/14] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector

[Wei Deng <wei.deng@oss.qualcomm.com>]

On Thu, 9 Jul 2026, Chen-Yu Tsai wrote:
> The M.2 E-key connector allows either PCIe or SDIO for WiFi and USB or
> UART for BT. Currently the driver only supports PCIe and UART.
> 
> Add power sequencing targets for SDIO and USB. To avoid adding a
> complicated dependency tree, rename the existing power sequencing units
> "pcie" and "uart" to "wifi" and "bt". The existing target names are left
> untouched. The new "sdio" and "usb" targets just point to the renamed
> "wifi" and "bt" units.
> 
> The "unit" names are internal to the power sequencing framework, and
> should be confined to a single provider. The names are only
> informational. Dependencies are tracked with pointers to other units.
> 
> The "target" names are the strings that the consumer uses to acquire a
> descriptor with. As these remain the same, existing users will continue
> to work.
> 
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Expand commit message
> ---
>  drivers/power/sequencing/pwrseq-pcie-m2.c | 41 +++++++++++++++--------
>  1 file changed, 27 insertions(+), 14 deletions(-)
> 

Hi Chen-Yu,

We tested this series on the Qualcomm Hamoa IoT EVK with both USB BT
and UART BT M.2 cards and found an issue with UART BT power cycling
when the USB hub is active.

The "uart" and "usb" targets in this patch share the same bt_unit_data.
The USB hub acquires the "usb" target in hub_activate() and never releases
it, so the bt_unit enable_count never reaches zero when hci_qca calls
pwrseq_power_off("uart"). As a result bt_disable() is never called,
W_DISABLE2# stays deasserted, and the BT chip cannot be properly reset.

Observed on Hamoa with a UART BT card (WCN6855, sub 0xe105):

  With your patches:
    lsmod: pwrseq_pcie_m2 ... 3   (provider + uart + usb)
    btmgmt power off -> GPIO116 stays HIGH (bt_unit ref 2->1, no callback)
    btmgmt power on  -> "hci0: command 0xfc00 tx timeout" -> failed

  Without your patches:
    lsmod: pwrseq_pcie_m2 ... 2   (provider + uart only)
    btmgmt power off -> GPIO116 goes LOW  ✓
    btmgmt power on  -> hci0 UP RUNNING  ✓

USB BT card (WCN6855, sub 0x3374) tested separately works correctly with
your patches.

The testing was done with the following Hamoa-specific patches on top of
this series:
  [PATCH 1/3] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector
    https://lore.kernel.org/all/20260709-fix-hamoa-m2-w-disable2-v1-1-5e725091266a@oss.qualcomm.com/
  [PATCH 2/3] power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID
    https://lore.kernel.org/all/20260709-fix-hamoa-m2-w-disable2-v1-2-5e725091266a@oss.qualcomm.com/

The fix we verified is to give "usb" its own independent unit so its
enable_count is tracked separately from "uart":

  static const struct pwrseq_unit_data pwrseq_pcie_m2_e_usb_bt_unit_data = {
  	.name = "usb-bt-enable",
  	.deps = pwrseq_pcie_m2_unit_deps,
  	.enable = pwrseq_pci_m2_e_bt_enable,
  	.disable = pwrseq_pci_m2_e_bt_disable,
  };

  /* change usb target to point to the independent unit */
  static const struct pwrseq_target_data pwrseq_pcie_m2_e_usb_target_data = {
  	.name = "usb",
  	.unit = &pwrseq_pcie_m2_e_usb_bt_unit_data,
  };

With this change, uart_bt_unit reaches ref=0 on UART BT power_off and
bt_disable() is called correctly. Since a M.2 slot can only carry one
card variant at a time, the two units do not interfere in practice.

Would this be an acceptable fix, or do you have a better approach in mind?

-- 
Best Regards,
Wei Deng