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

[Bin Meng]

Hi Marcus,

On Tue, Sep 10, 2019 at 11:53 PM Marcus Comstedt <marcus at mc.pp.se> wrote:
>
>
> Hi Bin,
>
> Bin Meng <bmeng.cn at gmail.com> writes:
>
> > So 4.14 definitely was an out-of-tree kernel
>
> Everything before 5.2 was out-of-tree.
>
>
> > No one can guarantee an out-of-tree implementation will be
> > keeping compatible after it's accepted in-tree.
>
> Reviewers/maintainers can guarantee compatibility with existing
> hardware and DT by not instisting on breaking changes.
>
> It's not really about keeping in-tree and out-of-tree compatible with
> each other, but about keeping both of them compatible with the actual
> hardware and DT of the system the OS is supposed to run on.
>

Per my understanding kernel reviewers/maintainers want to have a clean
implementation from the start. That's why it's being done this way.

>
> > Reviewers/maintainers
> > may have different view from the author on what's the best
>
> A reviewer/maintainer could for example have the view that a certain
> register in a piece of hardware should really be two registers with
> the bits divided between them based on some logical partitioning.  And
> they might be right.  But the hardware is what it is, and if they
> insist that the driver access two different registers the driver will
> not work the hardware.  You'll have a nice driver that works on
> nothing (at least until the vendor makes a new spin of the hardware
> with the two registers).

The original hardware vendor's DT may be written in a way that
violates the DT specs. Hence I believe it's really hard to keep the
comparability for both.

For this specific FU540 ethernet, what you did in this patch does not
completely bring back the compatibility. Things were changed a lot in
the upstream kernel.

For example, the U-Boot GEM GXL-MGMT driver was needed to work with SiFive's DT
https://lists.denx.de/pipermail/u-boot/2019-May/369577.html

But later, it was dropped due to kernel mainline DT
reviewers/maintainers thought it was a misuse of clock node and the
GXL-MGMT module should be part of the GEM spec.
https://lists.denx.de/pipermail/u-boot/2019-June/373306.html

>
> My opinion is that the DT should be treated the same way.  It is part
> of the hardware (sort of the "metadata" for the hardware).  Sure you
> can have some idea of how things could be expressed better and add
> support for that, but you need to also keep compat with the actual
> hardware platform that the driver is there to interface against,
> otherwise the driver won't work.
>

While I agree with you to some extent that, that's now how things are
done with current kernel practice.

Regards,
Bin