Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, Sep 21, 2016 at 8:22 PM, Mark Brown <broonie@kernel.org> wrote:

> When I talk to people about this I tend to talk about doing upstream
> simultaneously rather than first, that is a lot more tractable.  Work on
> things, try to push your latest work upstream as you write it and
> incorporate review feedback from upstream into your product as you go
> but don't gate things on upstream.  Try to view anything that's still in
> review as a problem that needs to be fixed but acknowledge that there's
> also a need to actually get product out the door.

This is very similar to my experience working as main responsible for the
kernel at ST-Ericsson (until their sad demise).

The strategy I had was that of trying to minimize hamming distance on
anything already upstream, incorporate patches from upstream, and also
empasize that core infrastructure such as irqchips, clocks, regulators,
pins, GPIOs, dma, timers, UARTs etc need to go upstream first.

This way, whenever one of our developers patched any of these interna
drivers, that was likely on some lines that were identical to upstream, so
I could rebase the patch onto upstream, test it, sign it off and
mail off to the respective subsystem maintainer. Win-win!

Leaf drivers were then (in theory) be worked on in isolation.

The storage team (MMC/SD) where the current MMC/SD subsystem
maintainer Ulf Hansson was working, actually embraced an upstream
first strategy. This was achieved by backporting the whole set of
changes in drivers/mmc/* to the upstream until all the files in this
part of the kernel were identical to a much later kernel version. Luckily
that part of the kernel was so self-contained behind the block layer
API that this worked out pretty well. I think it was done solely for that
part of the kernel because it was the path of least resistance as
many advanced MMC/SD protocol features had to be squeezed in,
and upstream actually moved ahead much faster with this.

The big contention points to working upstream on Ux500 were
(for all of yours amusement):

- Missing frameworks: system PM and runtime PM especially.
  And even more the intersection between those two.
  The situation is still not very good when it comes to this. It
  is getting better.

- No working generic power domain. This is getting better.

- Huge out-of-tree drivers for on-chip power managment: the PRCMU.
  (Power-reset control management unit). We now have a better
  chance of handling that with syscon and also rpmsg and splitting
  it up per-subsystem after Björn Anderssons latest patches but it
  wasn't there some years ago.

- Missing UART bus for attaching Bluetooth: the thing that Rob
  Herring is now working on.

- Missing HCI transport for subdevices piggybacking HCI:
  FM radio and GPS was using this. Still there is no solution for
  this.

- Huge rewrites needed to move a former framebuffer driver to
  KMS/DRM. The organization was strongly unwilling to rewrite
  a working driver of that size.

- No proper sensor subsystem. We now have IIO.

- Third party GPUs (Mali). Even Intel had this problem when using
  PowerVR IIRC. More of a political problem than a technical one
  as it seems.

Yours,
Linus Walleij