On Tue, Nov 17, 2020 at 4:58 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > >> > These could also just be implied by the compatible string (and requiring > > > >> > an SoC specific one). > > > >> > > > >> hm... we could do it but this will require us to know (and publicly > > > >> acknowledge) of every SoC making use of this piece of hardware design. > > > > > > That's already a requirement in general. Sometimes we can avoid it, > > > but that's cases of getting lucky. > > > > > > >> There is currently no other part of the driver that needs this. > > > > > > If your DT is part of firmware, then waiting until adding some driver > > > feature or quirk based on a new DT property is too late. Whereas with > > > a SoC specific compatible, you can handle any new feature or quirk > > > without a DT change (e.g. just a stable kernel update). Some platforms > > > may not care about that model, but in general that's the policy we > > > follow. Not doing that, we end up with the DWC3 binding. > > > > > > A fallback compatible is how we avoid updating drivers for every > > > single SoC unless needed. > > > > OK, I now better understand what you meant and that does make some > > sense and I will defer to your better judgment about the proper way > > to do this. > > > > Having said that, there is still something that bugs me about this, > > even just at the level of better understanding why we do things: > > > > Way back when, before DT, we had SoC specific code that identified the > > SoC somehow and set things up in a SoC specific way. > > Then we introduced DT as a way to say - "hey look, this is how my > > busses looks like, these are the devices I have, deal with it" and I > > always assumed that this was meant as a way to release us from having > > SoC specific setup code. > > Yes, but in the end it's a judgement call as to what the boundary is. > Take clocks for example, in the beginning we were trying to describe > clocks on a mux/divider/gate level in DT. We realized this would > result in hundreds to thousands of DT nodes and it would never be > completely correct. So we model only the leaf clocks for the most part > and there's lots of SoC code for clock controller blocks still. > > The questions for having properties or not to ask is: > > Is this board specific? Yes, then use a property. > > Who needs to change this and when? Should/would you want to control > this in your PC BIOS or via a BIOS update? > > > Zero SoC code was never a goal. It was about a standard way to define > SoCs and having common frameworks (we have a common clock api, but not > implementation at the time). We have *way* less SoC code per SoC than > we used to. At the start of the DT conversion for Arm, we had ~400 > boards and now we're at ~1400 last I checked. > > > It seems now potentially every SoC vendor needs to modify not just the > > device tree source (which makes sense of course) but also the driver > > supporting their platform. > > It now looks like we've come a full circle to me :-) > > As I said, if the h/w is 'exactly the same' (hint: it rarely is), then > use a fallback compatible. Then the new SoC specific compatible is > there just in case. > > Think of compatible just as a VID/PID in PCI and USB land (though the > closest thing to a fallback there is class codes). They are the only > way we can uniquely identify h/w. Thanks Rob, this makes sense. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
