Apply Linux Kernel Patches from LKML

Linux kernel work can call for you to test out a patch set that someone has posted to the Linux Kernel Mailing List (LKML). If the patch sets are sufficiently long enough, you want to apply them all together, and not have to down load them individually. I recently worked through this, and here’s how I got things to work.

For example, picking the top one (today) from LKML: [PATCH 0/8] MediaTek watchdog: Convert mtk-wdt.txt to dt-schema. I actually don’t care about this particular patch, but the process is the same.There is a link to this on the Webpage.

Note that this title bar implies there are 8 patches (labeled 1 to 8) inside it, and a Patch labeled 0 which serves as the header to the whole patch set. When you try to apply the patch using git -am it is going to complain about that first one, but this is not a problem.

If, like me, you tend to do development work on a system that is not your primary email client, you will want a way to download the patches directly to the target machine. I am going to use wget to fetch a patchset in its mailbox format using gzip compression. There is a link to the gz file at the bottom of the page. Scroll to the section that shows the thread. There is a line that reads:

“Thread Overview: 28+ messages (download: mbox.gz /follow: Atom feed)

The mbox.gz text is a hyperlink, and that is what you want to download. I copy this to my clipboard and use wget:


Now, all of these files are going to be called t.mbox.gz. I’d recommend renaming this one, either now, or immediately after unzipping , depending on whether you plan on keeping the zipped version around.

root@eng07sys-r117:~/lkml# gunzip t.mbox.gz 
root@eng07sys-r117:~/lkml# mv t.mbox mediatek-watchdog.mbox

This is documented as applying on top of next-20221006. This tag as such does not exit on my tree (cloned from Torvalds) but I am going to assume that it will apply on the latest RC. And I am going to test that assumption. Checkout based on the RC7 tag and create a new local branch

git checkout v6.0-rc7
git checkout -b local-mediatek-watchdog-rc7

And it turns out this patch does not apply:

Applying: arm64: dts: mediatek: mt8186: Fix watchdog compatible
error: arch/arm64/boot/dts/mediatek/mt8186.dtsi: does not exist in index
Patch failed at 0001 arm64: dts: mediatek: mt8186: Fix watchdog compatible
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am -i --continue".
If you prefer to skip this patch, run "git am -i --skip" instead.
To restore the original branch and stop patching, run "git am -i --abort".
#let's cleanup
# git am --abort

I probably used the wrong starting point. Let’s see if it works with linux-next. I needed to add the “enxt” remote and fetch from it.

git remote add next
git fetch next
git checkout next-20221006
git checkout -b local-mediatek-watchdog-next-20221006

The git am command will attempt to apply commits based on each message in the mbox file, as they will all start with [PATCH. While this is what we want for the top level patch, we do not want the responses. Probably the easiest way to deal with them is to try to apply them, let git am fail, and then tell it to skip:

# git am ~/lkml/mediatek-watchdog.mbox -i 
Commit Body is:
arm64: dts: mediatek: mt8186: Fix watchdog compatible
MT8186's watchdog embeds a reset controller and needs only the
mediatek,mt8186-wdt compatible string as the MT6589 one is there
for watchdogs that don't have any reset controller capability.
Fixes: 2e78620b1350 ("arm64: dts: Add MediaTek MT8186 dts and evaluation board and Makefile")
Signed-off-by: AngeloGioacchino Del Regno <>
Co-developed-by: Allen-KH Cheng <>
Signed-off-by: Allen-KH Cheng <>
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all: a
Applying: arm64: dts: mediatek: mt8186: Fix watchdog compatible
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
root@eng07sys-r117:~/tiny-ramdisk_dev/linux-buildroot# git am -i --skip

When you are done, confirm that the number of patches matches what you would expect from the LKML messages. I use the –oneline option to git log for this:

# git log  --oneline
63ea66f8e43c (HEAD -&gt; local-mediatek-watchdog-next-20221006) arm64: dts: mediatek: mt7986: Fix watchdog compatible
31ddd9f6e4b2 dt-bindings: watchdog: mediatek,mtk-wdt: Add compatible for MT8173
77a4ff644c59 watchdog: mtk_wdt: Add support for MT6795 Helio X10 watchdog and toprgu
6e98695590cd arm64: dts: mediatek: mt8516: Fix the watchdog node name
037cd6d3a7a9 dt-bindings: watchdog: mediatek,mtk-wdt: Add compatible for MT6795
310f3f7d3831 arm64: dts: mediatek: mt8195: Fix watchdog compatible
8cc9decc9137 dt-bindings: watchdog: mediatek: Convert mtk-wdt to json-schema
dc3cd8c843b5 arm64: dts: mediatek: mt8186: Fix watchdog compatible
7da9fed0474b (tag: next-20221006, next/master) Add linux-next specific files for 20221006

I have 8 patches, and I expected 8 from the message title, so it passes the first sniff test. I’d actually go further and check the author etc. I’ve seen cases where empty patches to do get applied, and the patch message contains the nested conversation from email, so those need to be removed.

There are other techniques which pull the patches into the file system and allow you to apply from there, but I have not needed that. Yet.

If you work with LKML regularly, what would you suggest as improvements to this process?

EDIT: Two of my coworkers, upon reading this post, pointed me at the b-4 project.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.