[OpenWrt-Devel] Importing DTS Files from Future Kernel -- Best Practice?
chunkeey at gmail.com
Fri Feb 8 07:00:07 EST 2019
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:
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 can see a couple ways of doing this:
> * target/linux/ipq40xx/patches-4.14/ -- patch in the entire files
> * target/linux/ipq40xx/files-4.14/ -- add the files directly
> Which is the preference of the project, or is there another approach?
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
(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.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel