On Thu, Oct 19, 2017 at 09:00:25PM +0200, Marcel Holtmann wrote:

Hi Hans,

quoted

quoted

           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.

I think we can go forward with what we have. I am not going to remove
hci_intel.c since the firmware loading code etc. is pretty generic to
all Intel UART based chips. However we just take the PM pieces out or
maybe someone is going to fix them.

Note that hci_intel used the platform hack for the reset line and host
wake-up irq. And as the reset line appears to be required when using
ACPI, we'd definitely find out eventually if anyone is using such
devices as they would fail to even power on.

quoted

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.

I am not doing that. We have to make progress towards serdev. So if
things really turn out badly, then we have to deal with it, but that
should not hold up getting things in the direction this needs to go.

As long as we know what we are breaking.

Johan