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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 07-10-17 16:26, Johan Hovold wrote:
> 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@redhat.com>
>>>>> ---
>>>>> 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?

It seems that this was answered already in further discussions and
your recent patch to add a default y to SERIAL_DEV_CTRL_TTYPORT fixes
this, right ?

Regards,

Hans