[U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed

[Bin Meng]

Hi Marcus,

On Tue, Sep 10, 2019 at 4:52 AM Marcus Comstedt <marcus at mc.pp.se> wrote:
>
>
> Hi Bin,
>
> Bin Meng <bmeng.cn at gmail.com> writes:
>
> >> Yes, but in which Linux?  This whole thing started because U-Boot will
> >
> > The latest Linux kernel v5.3.
>
> Thanks.  I'll try it later.  As if to prove my point, the one from
> 5.2.11 (which is the Linux version I'm currently running) did not work
> (I got MMC but no ethernet)...

Maybe Anup could chime in for various SiFive kernel driver upstream
history. My memory was that before all these drivers were upstreamed,
we were using SiFive's out-of-tree kernel and drivers.

>
>
> > I checked kernel 4.14 and found it did not ship the SiFive Unleased
> > board DTS in the kernel tree. Are you sure it's 4.14?
>
> It's the one shipped with the H5U, which I'm pretty sure ran Linux
> 4.14 at the time (as part of the "Freedom U SDK") since 4.15 was not
> out yet.  It looks like SiFive never added the DTS to their own Linux
> tree (https://github.com/sifive/riscv-linux).
>

So 4.14 definitely was an out-of-tree kernel since I did not see the
SiFive DTS in the mainline kernel. For the DTS it was passed all the
way from FSBL to BBL to kernel.

>
> > I don't think Linux is to be blamed for this case. They have a policy
> > to maintain the the backward compatibility for the DT land. The issue
> > what you were facing here is an out of tree DTB (the vendors') is
> > incompatible with the kernel's. Once the kernel accepts a DTS,
> > bringing in any out-of-tree DT with changes reviewed to in-tree,
> > future compatibility will be assured.
>
> Isn't the reason that the DTS accepted by the kernel is different from
> the out-of-tree vendor one that the review process caused changes in
> the DTS then?  It seems unlikely that the vendor (SiFive) would
> deliberately submit an incompatible DTS for inclusion...

Well, that's the normal upstream process we have to live with. It's
nothing to do with whether that's a DT change, or a feature design
change. No one can guarantee an out-of-tree implementation will be
keeping compatible after it's accepted in-tree. Reviewers/maintainers
may have different view from the author on what's the best to be
included in the kernel mainline and this may require the author to
change the implementation and break something ...

Regards,
Bin