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

[Anup Patel]

On Wed, Sep 11, 2019 at 7:28 AM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> 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.

Sorry for the slow response...

The DT bindings for most of the Linux drivers accepted upstream have
changed in a backward in-compatible way for SiFive Unleashed. The
Linux clock driver implementation also changed quite a bit.

Most of the recent U-Boot changes for SiFive Unleashed were to sync-up
DT bindings followed by U-Boot drivers with SiFive Unleashed drivers
accepted in Linux. The built-in DTB passed by FSBL to OpenSBI + U-Boot
is totally out-of-date. Going forward SiFive folks will use upstreamed Linux
DT bindings for newer platforms so it made sense to update U-Boot drivers.

The root of the problem is delay in freezing DT bindings by SOC vendors.

I think the SOC vendors should get DT bindings reviewed very early before
sending patches to Linux or U-Boot. The Linux kernel is still a central place
for all DT bindings documentation across architectures.

May be things would be different if DT bindings documentation was
maintained as separate project ???

For now, we can insist SOC vendors to get DT bindings reviewed/froozen
in LKML before sending U-Boot driver patches. Suggestions ??

Regards,
Anup

>
> Regards,
> Bin
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot