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. > 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. Regards Marcel -- 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
