Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rob Herring <robherring2@gmail.com>]

On Mon, Aug 3, 2015 at 2:42 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jul 31, 2015 at 6:18 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>> The WiFi side is actually in better shape than BT. With BT, we have
>> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
>> of examples of how not to do it[1]), and chip specific userspace
>> initialization (firmware loading, baudrate setup, power mgt).
>
> I was looking at it at one point and couldn't wrap my head around how
> the BT support was devised from a kernel point of view.
>
> It seems BT chips more often than not sit on a UART connection
> (often very high speed) and since there is no "uart bus" or "serial bus"
> akin to what we have for I2C or SPI, it is actually impossible to
> instantiate them properly in the driver model. Instead BT drivers
> are poked and peeked from userspace using the line discipline as
> if they were some kind of modem, just in-kernel.

Yes, but then there's always some side band signals for regulator
control, reset, clocks, wake-up, rf-kill, etc. that needs a glue
driver. There's been some work by Neil Brown to create a UART slave
bus[1] and I've gotten several other UART device bindings recently,
but they all suffer from being one off device bindings done in
different ways and I want to see something common here.

It also seems the BT folks are working on moving more of the setup
into the kernel and creating a proper subsystem. I'm not sure about
the details on that.

Rob

[1] https://lwn.net/Articles/643878/