[PATCH] octeon: fix unstable eMMC on ER-8
yuzhao at google.com
Fri Sep 2 22:44:13 PDT 2022
On Fri, Sep 2, 2022 at 6:37 PM Brian Norris <computersforpeace at gmail.com> wrote:
> Hi Yu,
> On Fri, Sep 02, 2022 at 05:34:21PM -0600, Yu Zhao wrote:
> > On Thu, Sep 1, 2022 at 12:54 AM Brian Norris
> > <computersforpeace at gmail.com> wrote:
> > > On Mon, Aug 01, 2022 at 01:50:36AM -0600, Yu Zhao via openwrt-devel wrote:
> > > > This patch adds the DTS  from the stock firmware , and makes
> > > > ER-8 use it. Interestingly, the only change in the device tree after
> > > > this patch is the eMMC clock speed .
> > >
> > > This usually means it'd be a better idea to share the DTS source
> > > (probably as a DTSI) and only override a single property.
> > >
> > > I haven't built a full octeon image yet nor grokked this target's
> > > Makefile device definitions; what DTS are you replacing, anyway?
> > Currently the kernel uses DTS passed in from the bootloader. Please
> > read the whole commit message :)
> Sorry, I did miss that. So that means we don't necessarily have a good
> starting point (like a per-SoC DTSI file).
> > > Seems
> > > very likely that you're repeating too much. At a minimum, I bet a large
> > > chunk of this file can be replaced with just:
> > >
> > > #include "cn71xx.dtsi"
> > One of the reasons is that cn61xx is too different from cn71xx.
> OK, I didn't do a proper diff -- in part because this DTS isn't really
> in a readable form. If it's truly not related to SoCs for which we
> already have DTSI files, then maybe the '#include' comments can be
> I still would recommend looking at the other comments about phandles and
> DTS style.
> > > > # dtc -I fs -O dts /proc/device-tree/ -o ubnt_e200.dts
> > The second reason is that I consider this new DTS file "auto
> > generated". IOW, it's not supposed to be edited.
> What about the next person who finds a problem they need to fix?
Good question. *If* that happens, that person should make this file
DTSI and then apply additional changes.
And I don't think it will happen: I suspect the eMMC never worked
properly since the ER-8 support was added in 2014.
> > I see no need to study the DTS as long as it works.
> This sounds like you're suggesting that decompiled assembly files are
> also acceptable source material to merge into OpenWrt.
I double and triple checked the doc, and I don't see why not.
This DTS was ripped off the stock firmware by a tool. IMO, it's more
like data (not code) and should be preserved that way (tool friendly).
More information about the openwrt-devel