Linux Kernel Upstream Engineer

Linux Kernel Engineer – Upstream / SoC Development | Fully Remote

I’m looking for an experienced Linux Kernel Engineer with genuine upstream experience for a fully remote role working directly on ARM SoCs and new silicon enablement .

I’m keeping the company anonymous for now, but this is with a major semiconductor organisation and the work is genuinely close to the hardware.

What makes the role interesting

This isn't primarily about maintaining an existing BSP or making small changes to an established driver.

You'll be working on new SoC functionality , with responsibility that can span from the hardware description all the way through to upstream Linux.

The work includes:

• PCIe host-controller support, including link up/down and hotplug
• DMA and interrupt routing , including SoC-specific ICU integration
• ASoC / audio controller and codec integration
• Pinctrl and pin-function support
• SPI controller enablement and fixes
• Ethernet / PHY integration
• Thermal sensor drivers
• Device Tree development
• Board bring-up and low-level hardware debugging
• Upstreaming changes and working directly through review with Linux subsystem maintainers

The technical challenge

The work sits right at the boundary between silicon and Linux .

You might start with a hardware reference manual and need to work through:

Registers → hardware sequencing → Device Tree → driver → IRQ/DMA → Linux subsystem → hardware validation → upstream

For example, understanding a path such as:

Peripheral → DMA → ICU → GIC → Linux IRQ → driver

and determining whether a problem is caused by the hardware configuration, interrupt routing, Device Tree, IRQ configuration, status register handling or the driver.

Or debugging a PCIe endpoint that won't enumerate by working across the PHY, clocks, resets, link training, controller and Linux PCI subsystem .

There is also interesting work around supporting multiple SoC variants — sharing common IP while dealing with different registers, interrupts and hardware quirks without creating a collection of duplicated drivers.

I'm specifically looking for upstream experience

This is important.

I'm looking for someone who has actually contributed to upstream Linux , not just worked on a vendor kernel or modified a BSP internally.

You should ideally have experience with:

• Submitting Linux kernel patches
• Working with subsystem maintainers
• Responding to review and revising patches
• Patch series and dependencies
• Kernel commit conventions
• Taking changes through the upstream review process

You don't need to be an expert in every subsystem listed above.

Strong C / Linux kernel fundamentals, ARM/SoC experience, hardware debugging and a proven upstream track record are more important than having a long list of specific drivers on your CV.

A good fit if...

You enjoy the kind of engineering where the question isn't just:

"Which API do I call?"

but:

"What is the hardware actually doing, how is Linux representing it, and where is the mismatch?"

And you're comfortable getting from that question to a working implementation, testing it on real hardware and defending the design during upstream review.

The practical bits

🌍 Fully remote (work from anywhere in Europe)

💰 Highly competitive day rate (OUTSIDE IR35) Long term 2+ years

🔧 Real silicon and low-level kernel development

🌐 Genuine upstream Linux work

🧑 💻 Experienced technical team

📚 Broad exposure across multiple kernel subsystems

If you're already working in Linux kernel, Embedded Linux, BSP or SoC development and have upstream contributions behind you, I'd be interested in speaking.

I'm keeping the company name private on the post, but happy to share the details directly.

Feel free to DM me, or tag someone who you think would be a good fit.

#LinuxKernel #UpstreamLinux #EmbeddedLinux #ARM #SoC #DeviceTree #KernelDevelopment #Linux #PCIe #DMA #Firmware #OpenSource #EmbeddedSystems