Re: [PATCH v7 14/16] power: sequencing: pcie-m2: Split Bluetooth unit based on interface
Manivannan Sadhasivam <[email protected]> Mon, 10 Aug 2026 19:12:06 +0200
| Newsgroups | gmane.linux.acpi.devel,gmane.linux.power-management.general,gmane.linux.usb.general,gmane.linux.drivers.devicetree,gmane.linux.ports.arm.mediatek,gmane.linux.ports.arm.kernel,gmane.linux.kernel |
|---|---|
| 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 -- மணிவண்ணன் சதாசிவம்