Re: [PATCH 1/2] dt-bindings: crypto: update ccree optional params

[Gilad Ben-Yossef]

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!