Hi Rob, On Tue, Jan 16, 2018 at 4:08 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > On Tue, Jan 16, 2018 at 2:56 AM, Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: >> On Mon, Jan 15, 2018 at 7:01 PM, Laurent Pinchart >> <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >>> On Monday, 15 January 2018 19:09:53 EET Rob Herring wrote: >>>> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote: >>>> > The internal LVDS encoders now have their own DT bindings. Before >>>> > switching the driver infrastructure to those new bindings, implement >>>> > backward-compatibility through live DT patching. >>>> >>>> Uhh, we just got rid of TI's patching and now adding this one. I guess >>>> it's necessary, but I'd like to know how long we need to keep this? >>> >>> That's a good question. How long are we supposed to keep DT backward >>> compatibility for ? I don't think there's a one-size-fits-them-all answer to >>> this question. Geert, any opinion ? How long do you plan to keep the CPG >>> (clocks) DT backward compatibility for instance ? >> >> Good question indeed... >> >> It's not just CPG/MSSR. Over the years we also added or changed APMU (SMP), >> SYSC (power domains), RST (mode pins), CMT (timers), ..., all of which have >> some sort of compatibility support in the kernel. >> >> Hence to avoid having to remember the kernel versions that dropped backwards >> compatibility for each of the above components, I was thinking about an >> R-Car Gen2 DT Flag Day. > > There's probably also DT changes that enable new features folks would > want/need? Or maybe carrying for some number of LTS releases is > enough. Sure. If you want new features, you have to upgrade the DTB anyway. Backwards compatibility is about keeping features without updating DTB. >> However, that was before I learned about your plans for LVDS (it seems every >> kernel release we learn about something new, postponing the flag day ;-). >> And now I'm quite sure we'll have another change in the future (DU per >> channel device nodes)... >> >> About using DT fixups to implement backwards compatibility: I did my share >> of thinking and experimenting with DT fixups (see e.g. "[PATCH/RFC 0/1] >> soc: renesas: Add DT fixup code for backwards compatibility" >> (https://www.spinics.net/lists/linux-renesas-soc/msg04305.html). >> DT fixups are hard to implement right, and not everything can be done >> that way. Hence in the end, none of this was ever used upstream, and >> everything was handled in C... > > In an ideal world, we would have some tool: > > dt-diff-to-overlay old.dts new.dts > my-fixup-overlay.dts > > And then in the kernel have infrastructure such you just declare match > tables with overlays to apply: > > struct of_device_id dt_match[] = { > { > .compatible = "vendor,board", > }, > {}, > }; > DT_FIXUP(dt_match, my-fixup-overlay.dtbo); > > But maybe I'm dreaming... Really? We might as well include the latest DTB in the kernel, and use that if machine_is_compatible("vendor,board")? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
