[PATCH] octeon: fix unstable eMMC on ER-8

[Yu Zhao]

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 [8] from the stock firmware [2], and makes
> > > > ER-8 use it. Interestingly, the only change in the device tree after
> > > > this patch is the eMMC clock speed [9].
> > >
> > > 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
> ignored.
>
> 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.

https://openwrt.org/docs/guide-developer/defining-firmware-partitions

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).

Thanks.