[OpenWrt-Devel] Importing DTS Files from Future Kernel -- Best Practice?

[Jeff Kletsky]

On 2/8/19 4:00 AM, Christian Lamparter wrote:
> On Thursday, February 7, 2019 6:15:13 PM CET Jeff Kletsky wrote:
>> I'm working on a derivative of the qcom-ipq4019-ap.dk07.1-c1 that
>> is present in Kernel 4.19, but not in 4.14
>>
>> In the interest of "correctness" and future maintainability,
>> I'd like to import from Kernel 4.19 linux/arch/arm/boot/dts/
>>
>> * qcom-ipq4019-ap.dk07.1-c1.dts
>> * qcom-ipq4019-ap.dk07.1.dtsi
>>
>> and use the upstream sources as #include in the EA8300 DTS
>> rather than the monolithic approach used in a previously
>> declined patch set for the device.
> This is confusing. I hope you can help me there. I found two
> PRs on github for this device:
> https://github.com/openwrt/openwrt/pull/1216
>
> And later:
> https://github.com/openwrt/openwrt/pull/1229
>
> The last one got declined for other reason than the DTS namely:
> " * merge commits need to be removed
>    * each patch should contain only 1 change and have a clean
>      prefixed subject line and description body
>    * at first glance there were several white space errors (spaces vs tabs)
>    * why do you reintroduce the msm bus support patch ?"
>

I was familiar with #1229 and the repo behind it, but did not know
about #1216 (same requester).

The line about the "msm bus support patch" puzzled me, as the context
wasn't clear to me, at least from the aggregated diffs.

I've got the groundwork done, based on the current state of the
`master` branch and reusing utilities introduced by the structurally
similar `linksys,ea6350v3`, to start work on the DTS for OpenWrt.
Between the Bunkerschild work and the surprisingly complete GPL drop
from Linksys (Linux 3.14.77), I think I'm in pretty good shape. Part
of me wants to try to extract the DTB from the OEM firmware or OEM
/proc/device-tree, but the other part of me wants to get it up and
running and back to trying to find the cause of the 802.11s regression.



> My advice for including one of the reference board dts(i) is: "please don't".
>
> If you look in the openwrt.git, you'll find that I did this initially
> too. However, I came around because I wasn't aware that the upstream
> qcom-ipq40$x$y-ap.dk0$z.$v-c$w.dts and qcom-ipq40$x$y-ap.dk0$z.dtsi are
> pretty much out of your control. You can end up in constant conflict with
> other (un-)related devices that snuck in changes into the included
> device-tree sources that break your device.
>
> So if you want to start over, just do the minimum and include
> "qcom-ipq4019.dtsi". in the hopes that upstream will leave it
> mostly alone.
>
> (Though, this is not 100%. Because as a matter of fact upstream
> added board-specifc button and leds definition into the
> qcom-ipq8064.dtsi. This will be fun to deal with).
>
> Note: Adding includes for dt-bindings headers (like for platform,
> gpio or input codes) is totally fine.



Thanks for the advice to "go standalone" rather than trust the
stability of upstream DTS definitions.  I didn't know that they
changed significantly.

At least these "upstream" definitions that come as a result of #include
are overridden by later statements including /delete-property/ and
/delete-node/.  Big trick is *finding* those changes before they cause
ill-behaved systems or other breakage.



>
> Cheers,
> Christian
>

Thanks again!

Jeff


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel