Date
1 - 2 of 2
How to add my own patches to linux-fslc-imx
|
Jan Claussen
Hi,
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
linux-fslc.inc, but during the compilation the defonfig is not found.
So can I only patch the original branch 5.10.2.1.x-imx or why doesn't this work?
Cheers, Jan 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: www.eppendorf.com/gdpr
|
|
|
|
Andrey Zhizhikin
Hello Jan,
On Thu, Jan 20, 2022 at 9:44 AM Jan Claussen via lists.yoctoproject.org <claussen.j=eppendorf.de@...> wrote: 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 [5.10.2.1.x-imx]. 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. 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. Link: [1]: https://github.com/Freescale/linux-fslc Link: [2]: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html -- Regards, Andrey.
|
|
|