Re: How to add my own patches to linux-fslc-imx

Andrey Zhizhikin

Hello Jan,

On Thu, Jan 20, 2022 at 9:44 AM Jan Claussen via
<> wrote:


I am currently working on adding our custom patches to linux-fslc-imx on honister. Previously, we had patched linux-imx on Gatesgarth but there seems to have changed a lot. Seems like this kernel is a merged version of linux-imx and linux-fslc. In the description "for upgraders" it says to add patches to the linux-fslc in the "corresponding branch". Usually I would create our own branch and add our patches to that one. I have tried to set our branch as KBRANCH and specify our custom_defconfig as KBUILD_DEFCONFIG in, but during the compilation the defonfig is not found.
There are 3 points to be considered here, namely:

1) If those patches do fix the issue in the NXP downstream kernel,
then you can open a PR in [1] against the _corresponding branch_,
which in this case is []. This gives a chance for those
who use the combined "NXP + Latest LTS" kernel (which `linux-fslc-imx`
is) a chance to review and provide comments on your patches.

2) If those patches are fixing issues in upstream, then you should
report then upstream first and they will eventually land in
linux-fslc-imx kernel via stable upgrade, provided they do qualify for
linux-stable, see [2] for this.

3) If those patches do something that only you need, you are
effectively creating your own "downstream" fork of linux-fslc-imx
repository, hence you need to create your own kernel provider.

The comment in recipe says exactly what it means: one should not
submit Kernel patches as patch files and add them to the layer (with
appending those to SRC_URI), but rather push them into [1] via PR
mechanism. Corresponding branch in this context means: the branch that
is currently set in the recipe. Since branch changes during Kernel
upgrades, there is no way to explicitly mention against which branch
you should submit your PR, hence the term "corresponding branch" is
used here.

So can I only patch the original branch or why doesn't this work?
Depends on the way you choose to proceed from above, you either would
"patch" the branch (via PR), or you need to switch the Kernel provider
to your own fork.



This email including its attachments is intended for the person or entity only to which it is addressed. It may contain confidential and/or privileged material. Any review, forwarding, dissemination, other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material from any computer system.

Eppendorf SE, Hamburg, Barkhausenweg 1, 22339 Hamburg, Amtsgericht Hamburg HRB 171526
Vors. des Aufsichtsrats: Philipp von Loeper
Vorstand: Eva van Pelt (Co-Vorsitzende), Dr. Peter Fruhstorfer (Co-Vorsitzender), Axel Jaeger und Dr. Wilhelm Plüster

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Dr. Bernd Petersen und Dr. Alexander Papra

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Dietmar Stadler

According to the general high quality approach of Eppendorf, we apply to our mail traffic the latest protection technologies and methods, including extensive scanning and DMARC, to help our communication partners in protecting their IT environment.
Privacy information according to Articles 13 and 14 GDPR can be found here:
Link: [1]:
Link: [2]:

Join to automatically receive all group messages.