Re: [PATCH 3/3] power: sequencing: pcie-m2: Deassert W_DISABLE2# when no UART serdev is created

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

On Tue, 14 Jul 2026, Manivannan Sadhasivam wrote:
> On Mon, Jul 13, 2026 at 02:46:16PM +0530, Wei Deng wrote:
> > On Thu, 9 Jul 2026, Dmitry Baryshkov wrote:
> > > On Thu, Jul 09, 2026 at 12:59:42PM +0530, Wei Deng wrote:
> > > > The pwrseq_m2_pci_ids[] table lists PCIe BT devices that use UART as the
> > > > BT transport and need a UART serdev created by the driver. When a PCIe
> > > > device under the M.2 connector does not match any entry in this table,
> > > > no UART serdev is created.
> > > > 
> > > > However, the BT subsystem of such a device may still require W_DISABLE2#
> > > > to be deasserted to power up. Rather than adding every possible non-UART
> > > > BT device ID to the table, add an else branch that deasserts W_DISABLE2#
> > > > whenever a PCIe device is detected under the connector but does not match
> > > > a UART BT entry. This allows any BT interface on the card (USB or other)
> > > > to enumerate without requiring explicit knowledge of its device ID.
> > > > 
> > > > The primary use case is USB BT variants of combo chips that share the
> > > > same PCIe device ID as their UART counterpart (e.g. WCN7851 NCM865 USB,
> > > > sub 0x3378, vs NCM865A UART, sub 0x337c): no UART serdev is needed, but
> > > > W_DISABLE2# must be deasserted so the USB BT device can enumerate.
> > > 
> > > Instead of forcibly toggling it, would it be more sensible to tie pwrseq
> > > into the USB too? The onboard-usb-dev implements the same idea (of
> > > powering up the USB device), but it predates pwrseq.
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> > > 
> > 
> > Hi Dmitry,
> > 
> > There is a patch series from Chen-Yu Tsai that appears to implement what
> > you suggested:
> > 
> >   [PATCH v4 00/14] arm64: mediatek: Add M.2 E-key slot on Chromebooks
> >   https://lore.kernel.org/all/20260709095726.704448-1-wenst@chromium.org/
> > 
> > We have been testing this on the Qualcomm Hamoa IoT EVK with both UART BT
> > and USB BT M.2 cards.  Is this the direction you had in mind?
> > 
> 
> IMO, we should move towards Chen's series.
> 
> - Mani

Agreed.

While testing Chen-Yu's v4 on the Qualcomm Hamoa IoT EVK with a board
that needs to support both USB and UART BT cards, we found that the USB
hub holds a reference to the "usb" pwrseq target permanently (acquired
in hub_activate() and never released). When the UART BT driver later
calls pwrseq_power_off(), the bt_unit enable_count only drops to 1 and
bt_disable() is never invoked, leaving W_DISABLE2# deasserted. This
prevents the BT chip from being properly reset, causing the next
btmgmt power on to fail.

This issue is addressed in v5 Patch 14 by splitting the Bluetooth
pwrseq unit into independent uart and usb units, each with their own
reference count:

  [PATCH v5 00/16] arm64: mediatek: Add M.2 E-key slot on Chromebooks
  https://lore.kernel.org/all/20260715085348.3457359-1-wenst@chromium.org/

The series still needs review from you and other maintainers.

-- 
Best Regards,
Wei Deng