Speaking of updates

I can't speak from a maintainer's point of view, just of that from someone who does run mainline linux on my embedded devices, and makes mainline Linux run on them by porting downstream code.

> But suppose the BSP is being written for a piece of custom hardware that has a FPGA that implements a custom peripheral. Should the driver for something that only exists in a few devices in the world be upstreamed?

I think the usual cutoff is that if there is at least one user of the driver in the mainline Linux tree, it stays. If you are a business selling very expensive low volume scientific equipment with custom FPGA peripherals to select businesses, you'll probably sell that with software support as a whole service package, so users of said devices are unlikely to be running mainline Linux even if it were possible. In that case I agree, upstreaming such a driver (or even submitting it to mainline, as opposed to just code dumping it somewhere) would be counter-productive and a waste of time on everyone's part.

However, asking the question of "how could this be useful for mainline" usually already leads down the path of refactoring code to be more generic and in turn better. As an example, I recently came across an out-of-tree vendor driver for a DCF-77 time signal receiver card that implements a vendor specific userspace interface. I wondered how this could be made generic across vendors, and discovered that there currently (to my knowledge) was no Linux kernel uapi for authoritative time keeping sources such as atomic clocks or time keeping radio signal receivers, because apparently everyone who makes these never actually tried to upstream their work. It's a niche product, but the kernel would still be better off if there was a generic way to support these niche devices.

> Similarly for the DTS files that pull it all togther, do we really want all the DTS files for every embedded Linux system in the world in the upstream kernel?

In my opinion, yes. Naturally if it's a device that's never brought to market, it doesn't make sense, but erring on the side of "too many" is better in my opinion. Chances are most of your device tree's interesting parts will be in the SoC's dtsi, which is useful for every other device that uses the same SoC and may also want to be upstream. A lot of the DT review process is also already automated with tooling that can generate useful (and sometimes not so useful) warnings about common pitfalls.

Maintainers may of course disagree with me here as they'd rather get fewer submissions as to ease their workload. But I for one would love if my now 6 year old phone had an upstreamed DT written against mainline bindings even if nobody would've run mainline Linux on it when it came out (but they might want to now with that becoming a thing). I also wouldn't mind a device tree for my parents' laundry machine that inexplicably runs FreeBSD; device trees are conceptually independent of kernels after all, and the motor in that thing will probably outlast the official software support for its solid state electronics.

So I guess I should rephrase my statement: If you are a SoC vendor or have been hired to work for one, please don't stop at board support packages; at least upstream the SoC parts.