Occasionally, I will forget to link something from the mailing list in this post. To see my full mailing list activity (patches, reviews, and reports), you can view it on lore.kernel.org.

Linux kernel patches

  • Stable patches: The stable trees are the trees that most users consume so keeping them building and as warning and issue free as reasonable is important.

    • [PATCH 5.4] Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40 (v1)
    • [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ (v1)
    • [PATCH 4.4,4.9] power: reset: ltc2952: Fix use of floating point literals (v1)
    • Patches for clang and CONFIG_WERROR (arm64/x86_64)

  • -Wpointer-bool-conversion: This warning is usually harmless, as it is typically just a developer checking if an array in the middle of a structure is NULL, which is not possible if the structure is not NULL, which would likely cause issues further up a call chain. In this one case, the fix was just to remove the check.

    • clk: visconti: Remove pointless NULL check in visconti_pll_add_lookup() (v1)

  • Other fixes: Yet another instance of an unsupported compiler flag causing issues with cc-option… I hope that we can get all instances of these cleaned up and have a flag turned on that will prevent these weird failures but that will probably be a release or two out.

    • MIPS: Loongson64: Clean up use of cc-ifversion, MIPS: Loongson64: Wrap -mno-branch-likely with cc-option (v1, v2)

LLVM patches

Patch review and input

For the next sections, I link directly to my first response in the thread when possible but there are times where the link is to the main post. My responses can be seen inline by going to the bottom of the thread and clicking on my name.

Reviewing patches that are submitted is incredibly important, as it helps ensure good code quality due to catching mistakes before the patches get accepted and it can help get patches accepted faster, as some maintainers will blindly pick up patches that have been reviewed by someone that they trust.

Issue triage and reporting

The unfortunate thing about working at the intersection of two projects is we will often find bugs that are not strictly related to the project, which require some triage and reporting back to the original author of the breakage so that they can be fixed and not impact our own testing. Some of these bugs fall into that category while others are issues strictly related to this project.

Tooling improvements

Behind the scenes

  • Every day that there is a new linux-next release, I rebase and build a few different kernel trees then boot and runtime test them on several different machines, including a Raspberry Pi 3 and 4, HP desktop, ASUS laptop, and Hyper-V and VMware platforms on my workstation. This is not always visible because I do not report anything unless there is something broken but it can take up to a few hours each day, depending on the amount of churn and issues uncovered.

Special thanks to: