Re: [PATCH v2 9/9] Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 05, 2017 at 05:15:05PM +0200, Marcel Holtmann wrote:
> Hi Hans,
> 
> >>> Make the serdev driver use struct bcm_device as its driver data and share
> >>> all the pm / GPIO / IRQ related code paths with the platform driver.
> >>> 
> >>> After this commit the 2 drivers are in essence the same and the serdev
> >>> driver interface can be used for all ACPI enumerated HCI UARTs.
> >>> 
> >>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >>> ---
> >>> drivers/bluetooth/hci_bcm.c | 118 +++++++++++++++++++++++++-------------------
> >>> 1 file changed, 68 insertions(+), 50 deletions(-)
> >> all 9 patches have been applied to bluetooth-next tree.
> > 
> > Excellent, thank you!

Nice work here, Hans, allowing serdev to coexist with the
platform-device hacks until the transition is complete and those hacks
can finally be removed.

> > So I guess this means we can also move forward with getting
> > the 2 patches from Frédéric Danis merged ? There is a bit
> > of a bisect-ability problem there, if the acpi pull-req
> > gets merged first then uart attached bcm bt will stop
> > working until the bluetooth subsys is also merged.
> > 
> > But I don't think this will impact a lot of users
> > (also given the need for a manual btattach so far),
> > so I don't think this is a big problem... ?
> 
> I wonder if we should just do this as all-in-one change for 4.15
> kernel. We surely can get the ACPI changes into 4.15 and the Bluetooth
> changes as well. Then it should just work.

However, there are of course a couple of caveats. Once Frederic's ACPI
patches land, there will be no more platform child devices. Unless
serdev support is then compiled in, this means that PM will break
(silently). And if serdev is enabled, of course the tty class device is
gone and hciattach (btattach) will fail, but I guess everyone is aware
of that issue by now.

Should BT_HCIUART_BCM start depending on SERIAL_DEV_CTRL_TTYPORT (when
ACPI is enabled) to avoid such silent breakage once ACPI-support is
merged?

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux