Re: [PATCH v7 14/16] power: sequencing: pcie-m2: Split Bluetooth unit based on interface

Manivannan Sadhasivam <[email protected]>
Newsgroups org.infradead.lists.linux-mediatek,dev.linux.lists.driver-core,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-acpi,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm,org.kernel.vger.linux-usb
Message-ID <ns5zexfsbin4om3klprrh4v2xfvhhg5nztbbf5neakyuwq47bc@mckelf2d5x5f>
On Fri, Jul 24, 2026 at 04:43:23PM +0800, Chen-Yu Tsai wrote:
> Some UART / serdev based Bluetooth drivers need to be able to reset the
> hardware during initialization or recovery. This is not possible with
> the current power sequencing API if a unit is shared between USB and
> UART interfaces.
> 
> For now, split the Bluetooth unit into two, one for each interface.
> This allows either interface to independently toggle the power, with
> the last action prevailing, thereby unbreaking the Qualcomm Bluetooth
> serdev driver. This is also needed for the Realtek Bluetooth serdev
> driver (hci_h5).
> 
> Having independent control from either interface unfortunately means
> that userspace is able to shut down the controller from sysfs using
> the USB port's "disable" setting without the serdev driver knowing
> about it. On the USB side, independent control is also desired, as it
> allows the USB core to power cycle the port/device during faults, and
> for userspace to initiate reset and recovery using the aforementioned
> "disable" setting. However when USB is used, a serdev device is not
> created, and there is no conflicting usage, which allows the power
> sequencing to work even without the split unit.
> 
> Suggested-by: Wei Deng <[email protected]>
> Signed-off-by: Chen-Yu Tsai <[email protected]>
> ---
> Changes since v4:
> - New patch
> 
> This patch is _not_ squashed into the previous to provide clear context
> on the change, and the less than perfect nature of it.
> 
> I think what we need in this case is some sort of lockout. The serdev
> consumer would want "exclusive" access, locking out the USB consumer,
> which can tolerate "shared" access.
> 
> Something similar would be needed for the WiFi if we ever add support
> for SDIO for toggling the state of W_DISABLE#1. At least the SDIO and
> PCIe reset signals are separate.

I don't think PCIe/SDIO suffers from the same issue as USB/BT. But anyhow, I
think it is OK to have this patch as an interim solution, but we should try to
model the BT control in a proper manner. I'd fancy adding TODO instead of XXX in
the comments. But nevertheless,

Reviewed-by: Manivannan Sadhasivam <[email protected]>

- Mani

-- 
மணிவண்ணன் சதாசிவம்
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.