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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
