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

[Rob Herring <robherring2@gmail.com>]

On Tue, Jul 28, 2015 at 6:07 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> On Tue 28 Jul 15:09 PDT 2015, Tim Bird wrote:
>
>> On 07/23/2015 08:40 AM, Mark Brown wrote:
>> > On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
>> >
>> >> Although is this something to be a core topic or a tech topic? Does
>> >> this affect all subsystems, or just a set of drivers? Note, a core
>> >> topic wont get as much time for discussion as a tech topic would.
>> >
>> > It's basically all subsystems that get impacted, at the minute I'd say
>> > it's more a plan of action and process discussion than a technical one
>> > though in the context of KS planning that's quite probably the same
>> > thing.
>> >
>> >> Also, what is expected to be solved at KS?
>> >
>> > Tim Bird (Cced) has been running some sessions at other conferences
>> > scoping the problem and discussing ways to move forward on this, another
>> > similar session might be useful.
>>
> [..]
>> In particular it has a table showing certain areas that tend to have
>> a lot of out-of-tree code (e.g. most phones have between 80K to
>> 100K of lines of wireless driver support out-of-mainline)

Practically every vendor BSP I've looked at has Broadcom vendor driver
copied in.

> In the Xperia Z3 we have a bcm4339 and I managed to get that up and
> running with the brcmf driver on mainline last week - pending Qualcomm
> regulator support and 1 pending patch in mmc.

That's no small feat, but the real problem here are the feature gaps
with mainline. Things I've heard about are switching between AP and
client modes, P2P support, Android specific power optimized firmware,
etc. We do have to start somewhere, but as long as vendors are putting
new features in their vendor drivers first and not getting pushback
from customers to have mainline (or mainline + feature X) drivers it
is going to be a loosing battle.

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).

NFC is even worse. What's in the kernel for NFC is generally not used
by Android AFAIK.

Rob

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg937944.html