Hi,
On 19-10-17 21:00, Marcel Holtmann wrote:
Hi Hans,
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.
Ok.
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.
Sounds good to me.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
