+devicetree On Wed, Sep 11, 2019 at 2:25 PM Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > > On Wed, Sep 11, 2019 at 7:28 AM Bin Meng <bmeng.cn@xxxxxxxxx> wrote: > > > > Hi Marcus, > > > > On Tue, Sep 10, 2019 at 11:53 PM Marcus Comstedt <marcus@xxxxxxxx> wrote: > > > > > > > > > Hi Bin, > > > > > > Bin Meng <bmeng.cn@xxxxxxxxx> 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 The question is when we can call that "very early"? Normally SoC vendors will ship their own software stack (bootloaders, kernels, dtb) on their evaluation board and provided forked git repos of these software for their customers, aka SDK. If we expect bringing DT bindings in a very early phase to fix such compatibility problem, that means SoC vendors cannot ship their SDK to their customers before every DT bindings used in their SoC get reviewed and approved. That sounds unrealistic. > 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 ??? I vaguely remember a similar proposal was once discussed in the LKML. If we manage to go with that direction, I think we should also request all DTS files to be dual licensed with one BSD-style permissive license model for other projects to use. > For now, we can insist SOC vendors to get DT bindings reviewed/froozen > in LKML before sending U-Boot driver patches. Suggestions ?? > So U-Boot upstream drivers always work with upstream DT in Linux kernel. Sounds good to me. But again this does not help with the out-of-tree U-Boot fork provided by the SoC vendor to their customers ... Regards, Bin
