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

  • Build errors: These are patches to fix various build errors that I found through testing different configurations with LLVM or were exposed by our continuous integration setup. The kernel needs to build in order to be run :)

    • cxl: Include range.h in cxl.h (v1)
    • riscv: Only allow LTO with CMODEL_MEDANY (v1)
    • iio: adc: ad_sigma_delta: Select IIO_BUFFER_DMAENGINE and SPI_OFFLOAD (v1)

  • Miscellaneous fixes and improvements: These are fixes and improvements that don’t fit into a particular category but are important to ClangBuiltLinux.

    • ARM: Fix allowing linker DCE with binutils < 2.36 (v1)

  • Stable backports and fixes: It is important to make sure that the stable trees are as free from issues as possible, as those are the trees that devices and users use; for example, Android and Chrome OS regularly merge from stable, so if there is a problem that will impact those trees that we fixed in mainline, it should be backported.

  • Warning fixes: These are patches to fix various warnings that appear with LLVM. I used to go into detail about the different warnings and what they mean, but the important takeaway for this section is that the kernel should build warning free, as all developers should be using CONFIG_WERROR, which will turn these all into failures. Maybe these should be in the build failures section…

    • panic: Add __maybe_unused to sys_info_avail (v1)
    • firmware: arm_scmi: Use modern PM ops (v1)
    • platform/x86/intel/pmt/discovery: Fix size_t specifiers for 32-bit (v1)
    • mm/ksm: Fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show() (v1)
    • usb: atm: cxacru: Merge cxacru_upload_firmware() into cxacru_heavy_init() (v1, v2)
    • media: s5p-mfc: Always pass NULL to s5p_mfc_cmd_host2risc_v6() (v1)
    • wifi: mt76: mt7996: Initialize hdr before passing to skb_put_data() (v1)
    • memstick: core: Zero initialize id_reg in h_memstick_read_dev_id() (v1)
    • phonet/pep: Move call to pn_skb_get_dst_sockaddr() earlier in pep_sock_accept() (v1)
    • drm/msm/dpu: Initialize crtc_state to NULL in dpu_plane_virtual_atomic_check() (v1)
    • drm/amdgpu: Initialize data to NULL in imu_v12_0_program_rlc_ram() (v1)
    • wifi: brcmsmac: Remove const from tbl_ptr parameter in wlc_lcnphy_common_read_table() (v1)
    • riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheck (v1)
    • tracing/probes: Avoid using params uninitialized in parse_btf_arg() (v1)
    • ASoC: SDCA: Fix uninitialized use of name in sdca_irq_populate() (v1)

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, input, 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

These are changes to various tools that we use, such as our continuous integration setup, booting utilities, toolchain building scripts, or other closely related projects such as AOSP’s distribution of LLVM and TuxMake.

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 4, a Raspberry Pi 3, a SolidRun Honeycomb LX2, an Ampere Altra Developer Platform, two Intel-based desktops, an AMD-based desktop, and an Intel-based laptop. 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.

  • I continue to upload prebuilt, fast versions of LLVM for kernel developers and our continuous integration to use.

Special thanks

Special thanks to Google and the Linux Foundation for sponsoring my work.