I'm asking why the dts in openwt are not pushed to the kernel upstream. License problem? They would be rejected?
Can i try to push the ipq806x dtsi for example?
What makes you think that they are not?
License is not an issue as its gotta be GPLv2 compatible anyway.
so it's just laziness/not interest ?
In most cases it's probably a mixture of too many out-of-tree patches required (e.g. ath79 is probably still in a dilemma, with ag71xx (and more) not quite being ready), combined with a combination of inertia and probably an inability to properly test it outside of the OpenWrt eco-system.
2 Likes
Naturally you can try.
But like @slh said, there are lots of OpenWrt specific patches, like for ipq806x:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x/patches-5.4;h=2125612568b73843e7a7c3b93ba7dae1e2294ee5;hb=HEAD
If you push DTS upstream, you should naturally push DTS that looks ok from the upstream perspective, without using features created/modified in unpushed OpenWrt patches. (tsens driver, etc.), unless you push them first 
Naturally it would be really great to have as much in upstream as possible.
What about the LED aliases that are OpenWrt specific?
eg https://github.com/openwrt/openwrt/pull/2925/files
Is there an alternative way to do this that doesn't involve modifying the dts, or would we need to patch them in?
Well its usually due to a lot of OpenWrt specific stuff.
Usually DTSI-es are kept as close to mainline and/or upstreamed.
Per device DTS files are hard to upstream as you need to have patches for each one again, so its easier to keep them as files
1 Like
So for example the ipq8065 dtsi should be pushable since all the changes in there are supported upstream (pci fixed and usb driver supported)
1 Like
Yeah, thats what I mean.
Practice is to push changes upstream as well as DTSI, then its really not hard to maintain local DTS files.
Its just thst you need to push every change individually.