How to back-port upstream BSP patches to CIP kernel

Jan Kiszka

Hi Ben,

after getting basically all patches for our Quark-based IOT2000 device
into upstream, I did the exercise of constructing a corresponding CIP
queue from that. The result is an almost 60 patches long series. Now I
was wondering if that is palatable for the CIP kernel and if I'm using
the right back-port approaches in all cases. Here is queue, first of all:
(just ignore the "iot2000-hack" tip)

There are a number of (presumably) non-brainer patches. But then there
are also more invasive back-ports that pulled some refactorings, such as

- serial exar split-out
- support for platform device properties
- GPIO API extension (converts gpiochip_add into a static inline wrapper
around gpiochip_add_data -> module ABI change)
- the whole series of EFI capsule changes

Besides looking at the concrete case of this queue, I was wondering if
some general guidelines for back-porting changes from upstream could be
derived from that.

Thanks in advance,

PS: I can send the series, likely in chunks, in a couple of weeks, once
I had a chance to test the stuff on real hw (out of reach right now).

Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Join to automatically receive all group messages.