Hi,

On 19-10-17 18:15, Loic Poulain wrote:

Hi


            Hmm, I've never actually seen any hardware use an intel BT HCI connected
            to a serdev, but I guess people did not write that code for fun, so those
            do exist ?


        they are all ACPI based and could now start using serdev. Previously they were all driven by btattach.


    I understand, I was just wondering if anyone is aware of any hardware
    actually using Intel BT devices in this manner, because it is going
    to be tricky to do a similar series if we cannot test it.


Yeah this driver supports Lightning-Peak iBT 3.0 UART controller.
I remember this controller comes (at least) with Atom x3-c3440 / x3-c3445 SoCs.
However I don't have the hardware anymore.

Ah, those are the Rockchip manufactured Atom based SoCs which
come with Mali graphics, I don't think anyone is trying to run
mainline on those and not a whole lot of those have shipped to
begin with (the line has been canceled).

I've an Apollo Lake based laptop with Intel Bluetooth, I just
checked and that is simply using USB.

So I don't think we are actually going to break anything by
just moving forward as planned. This reminds me of the axp288
driver where Intel's "embedded" engineering team upstreamed
parts of the axp288 PMIC code, but in a way where the driver
could not work as it would not load with platform_data which
was never provided by the mainline kernel.

As such it might actually be good to break this and if no-one
complains we can just remove the hci_intel.c code altogether.

The alternative would be to revert 2 if the 3 patches of
my last series for making the BT on the GPD win / pocket
(and likely other devices) work in uart mode. Then someone
(me?) would need to do a completely untested series for
hci_intel.c, and get that + reverts of the reverts into 4.16,
which is not the best way forward IMHO.

Regards,

Hans