Re: [PATCH 1/2] Bluetooth: hci_bcm: Remove platform_device support

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, 2018-01-22 at 09:23 +0100, Hans de Goede wrote:
> Hi,
> 
> On 22-01-18 03:24, Marcel Holtmann wrote:
> > Hi Hans,
> > 
> > > Now that ACPI and DT devices are both enumerated as serdevs, we
> > > can
> > > remove platform_device support and the bcm_device_list lookup
> > > hack.
> > > 
> > > This also removes any races between suspend/resume and hci-uart
> > > binding,
> > > also making the suspend/resume code a lot simpler.
> > > 
> > > This commit leaves manually binding to an uart using btattach
> > > supported
> > > (without irq/gpio and thus suspend/resume support, as before).
> > > 
> > > Cc: Lukas Wunner <lukas@wunner.de>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > drivers/bluetooth/hci_bcm.c | 260 +++++---------------------------
> > > ------------
> > > 1 file changed, 28 insertions(+), 232 deletions(-)
> > 
> > so I was under the assumption platforms like Intel Edison still only
> > do platform data. See commit
> > 212d71833315c65644efc46223db61dee7b3c68e. Has that changed?

Yes and no.

So, we need that support to satisfy users with classical Edison
firmware.

> Ugh, I was not aware of that and the whole code to match the tty with
> the platform_device on btattach is such a mess and I was actually
> quite
> happy to be able to delete this.

Good idea.

> Andy, I see that you added support for bcm bluetooth over a tty using
> platform_data instead of ACPI enumeration. Can you change the code
> instantiating the device to instead instantiate a serdev, so that we
> kill the platform device support in hci_bcm.c and so that users don't
> need to do a btattach, but instead the kernel will do the attach
> itself
> and things will just work ?

I'm sorry, I can't do this soon, other more priority tasks in a pocket.

The instantiation of the driver is happened in arch/x86/platform/intel-
mid/device_libs/platform_bt.c

I would help with review of any patches till I would able to look at it
myself.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy