OSS + ELC EU 2026

NXP has historically maintained a large number of i.MX-specific patches in downstream Linux trees, increasing maintenance effort and limiting community adoption.

This talk presents NXP's updated upstreaming strategy and the progress made across i.MX SoCs. We will review the current upstream status of key drivers, lessons learned from recent upstreaming efforts and the processes introduced to improve patch quality and acceptance rates.

We will also cover NXP's efforts to strengthen community engagement, work on testing infrastructure and plans for the remaining internal patches.

Booting mainline Linux on a Snapdragon SoC is a great step, but it is very different from shipping a product. In standard vendor BSPs, power and performance tuning is often hidden behind blobs and downstream hacks. When you build a commercial device entirely on upstream Linux and U-Boot, you lose those vendor shortcuts. You have to understand the hardware deeply to balance battery life and processing power.

In this talk, we will share our war story of shipping a real-world consumer product based on Snapdragon SoC using mainline Linux & U-Boot. We will guide you through our optimization journey, starting from the initial dev kit. We will see how we used the Linaro DebugBoard to profile and tune power consumption across different sleep states and active workloads. We will talk about leveraging standard kernel power management frameworks instead of relying on downstream workarounds, which helps keep the system easily maintainable.

We will explain how we identified power regressions and traced performance bottlenecks using upstream tools. Finally, we will look at the practical trade-offs we had to make to deliver a highly responsive, low-power device while staying close to mainline

Upstreaming initial support for a new RISC-V SoC is becoming more common, but keeping that support useful, reviewable, and maintainable is still difficult. As more application-class SoCs land, a one-vendor model stops scaling.

This talk uses SpacemiT K3, the first mass-produced RVA23-compatible SoC, as a case study. It's not about what we support, but about the upstream work we did, what tripped me up, and how we got past it.

We'll walk through in-house K3 enablement work on DMA, audio I2S, bindings, and DTS. The interesting patches aren't the ones that applied cleanly; they're the ones that didn't. We'll look at where to split bindings, drivers, and DTS; how K3 hardware constraints had to be modeled in upstream terms; and how review rounds reshaped the design.

The second part focuses on working with community developers outside SpacemiT: making boards available, keeping test images reproducible, pre-reviewing patches, turning regression around quickly, and keeping the internal tree close to mainline.

We’ll share lessons practical for making new RISC-V platforms not only upstreamed once, but easier for vendors and community contributors to review, test, debug, and maintain.

Support for Allwinner SoC chips in mainine projects like Linux, U-Boot and TrustedFirmware-A has been thriving for over a decade, enabling a large number of use cases and applications. This ongoing effort is lead by the linux-sunxi community and supported by various companies and individuals.

This talk presents an overview of the current status of support on the boot, firmware and kernel sides, along with a comprehensive list of the supported chips with specific information for each aspect. This includes advanced topics like power management, multimedia, graphics and accelerators. The latest developments and ongoing chip support efforts is also highlighted.

Context and history regarding Allwinner and the linux-sunxi community is also presented, as well as related tools and resources.

Since v4.15 the kernel has support for the second version of the Raster Graphic Acceleration (RGA) IP core of Rockchip SoCs.
The newer RK3588 SoC additionally ships two RGA cores with version 3 and so I was tasked to extend the driver to support them.

7 months and 7 patch series versions later the driver was merged in Linux v7.2.

The talk walks through my journey to getting my first driver upstream. It shows where I had understood things the wrong way, where I've tried to do too much and where I've had to invest more work. Spiced up with some anecdotes about erroneous manuals, erratic hardware behavior and errors which only arise under load.

The talk is intended for beginners who are interested in doing mainline work. Besides showing the effort required and the frustrating moments, I want to encourage putting in the effort and showcase some of the nice solutions it has produced.

Most silicon vendors claim to support upstream Linux. Few show what it actually takes to sustain that when customer deadlines and upstream changes compete for limited engineering resources. Espressif Systems, the company behind the ESP32 wireless MCUs and open-source ecosystems around them, is debuting in embedded Linux, but no stranger to open source communities: ESP-IDF is widely supported, and its engineers are active contributors to Zephyr RTOS, including a member on the TSC. This is a candid look at how a newcomer builds its development process with the community in mind.

We walk through the concrete processes we established: a branching strategy and sync cadence that track each stable kernel release, a pipeline for preparing and submitting patches to mainline, and immutable, reproducible release branches. We also cover the organizational model, a chip verification team that confirms silicon works quickly and a separate upstreaming team that refactors drivers to upstream standards, collaborating continuously to shrink the porting gap. The supporting infrastructure rounds this out with CI across multiple build systems, a LAVA CI board farm, and QEMU for pre-hardware testing.

Network interfaces are a common thing on embedded devices, so it's no surprise that getting a device supported upstream involves interacting with the netdev community on mailing lists.

The netdev list is a very busy place, and like other subsystems, has its own sets of written and non-written rules. Recently, it's been busier than ever, partly due to new tooling making it more accessible to make first contributions, or finding bugs. This means the netdev community has had to adapt and put new tools, processes and rules in place to deal with this heavy influx of contributions.

This talk will discuss what the upstream process for network-related patches currently looks like. We'll discuss the common pitfalls when upstreaming patches, either due to common technical mistakes or traps when following the netdev process. This may also be a chance for other subsystems to take a peek at how netdev deals with the recent surge of new contributors.

We'll see how reviews are being promoted, what the recently created Netdev Foundation has been setting-up to ease the testing and CI effort, and how as a developer you can help this community and get your patches accepted in a smoother manner.

Modern IOMMUs are deployed across wildly different environments. In enterprise servers, they require massive scalability, heavy virtualization support, and a zero-tolerance policy for lock contention. On the other hand, as these high-performance IOMMUs increasingly find their way into mobile, automotive, and edge SoCs, aggressive dynamic power management becomes mandatory.

Using arm-smmu-v3 as a case study, this talk explores the design challenges in integrating the Linux Runtime Power Management (RPM) framework into high-performance IOMMU drivers. Modern IOMMU drivers operate primarily with in-memory data structures, rely on HW-shared queues and are designed for lockless, concurrent access, often from strictly atomic contexts.

The RPM framework’s reliance on locks fundamentally clashes with this lockless architecture and atomic execution constraints. This session walks through the design choices evaluated while implementing runtime power management for a modern IOMMU driver, without sacrificing its lockless, concurrent, and efficient behavior.

The talk is backed by the arm-smmu-v3 RPM Series upstream: lore.kernel.org/all/[email protected]/