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

[Manivannan Sadhasivam]

On Wed, Jul 15, 2026 at 04:46:22PM +0530, Wei Deng wrote:
> 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@xxxxxxxxxxxx/
> > > 
> > > 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@xxxxxxxxxxxx/
> 
> The series still needs review from you and other maintainers.
> 

Cool, thanks for staying on top.

- Mani

-- 
மணிவண்ணன் சதாசிவம்