Architecting Mainline-Friendly Products

Mainline-friendly products are designed so their board support lives in upstream Linux, U-Boot, and standard build systems instead of a vendor fork. The decision is architectural, not aspirational: it is made when you choose the SoC, design the add-on connectors, and write the device tree — not when the product is already shipping. This article gives the strategic case, the product design rules that follow from current kernel work on hot-pluggable add-on boards, a vendor checklist for tech leads, and the concrete steps to upstream your own board support. We have covered why silicon vendors are moving to upstream-first BSPs . This article covers the product team's side of that shift: what you should do about it. Building mainline-friendly products means making a set of design decisions — SoC selection, connector design, device tree structure, and an upstreaming plan — so that mainline Linux and U-Boot treat your board as a normally supported board rather than as a permanent private port. Each section below turns one of those decisions into rules you can apply on your next board. Why mainline-friendly products are a strategic decision The cost of a vendor-fork BSP is not paid at bring-up; it is paid for the life of the product. Every kernel upgrade becomes a forward-port of private patches. Every security fix arrives on the vendor's schedule, not the kernel's — and for devices in scope of regulations such as the EU Cyber Resilience Act, patch latency is now a compliance question, not just an engineering one. Hiring is harder, because engineers must learn your fork before they can touch it, and the knowledge they build does not transfer in either direction. Board support that lives in mainline inverts each of these. New kernels are more likely to boot your board without forward-porting private support patches, because your board is part of the kernel's own build-and-test surface; LTS security fixes are easier to consume because the code paths you depend on are already