Re: [PATCH 2/4] dt-bindings: net: dsa: Add SoC-e switch IP and DSA bindings

[Vasilij Strassheim]

On Wed, 2026-08-05 at 14:53 +0200, Andrew Lunn wrote:
> On Wed, Aug 05, 2026 at 02:40:53PM +0200, Vasilij Strassheim wrote:
> > On Mon, 2026-08-03 at 18:43 +0200, Andrew Lunn wrote:
> > > > > > +  compatible:
> > > > > > +    const: soce,switch-dsa
> > > > > 
> > > > > Way too generic. I understand that SoCe will NEVER - and you certify
> > > > > that - develop a second, different "switch-dsa" model and they call this
> > > > > one like this?
> > > > 
> > > > It is intentionally generic to cover the common basics of all variants and
> > > > configurations of the synthesized switch in DSA.
> > > > I'm not sure what kind of guarantee I'm supposed to provide here regarding
> > > > SoCe. If switch-dsa is already mainline in the future, then a different
> > > > compatible will be needed for incompatible new models.
> > > 
> > > If it is not compatible, it needs a different compatible.
> > > 
> > > It gets interesting with something you synthesizer, something where
> > > there are a number of different synthesise options. How do you define
> > > compatible? You might want a very specific compatible, for your
> > > synthesise configuration, and a more generic compatible which might
> > > work for other synthesise configurations, but maybe not?
> > > 
> > Yes, that's not really satisfying.
> 
> That is the problem with FPGAs and jellyware.
> 
> > I will tweak the driver so that it reads as much as possible from
> > registers. Currently, I'm considering adopting SoC-e IP Core families as
> > the compatible option.
> 
> I would probably make that the fallback.
> 
> Maybe look around at how IP licensed from Synopsys and other vendors
> of IP cores work. It is slightly different use case in that these are
> generally integrated into silicon, so are fixed, but the chip vendor
> often puts logic around the licensed core which needs driving, and
> they sometimes integrate the core wrongly, so need workarounds. So you
> often have a compatible for the specific vendors overall integration,
> and a fallback compatible for the IP core version.
> 
> I would suggest something similar here, compatibles for each SoC-e IP
> core version, plus a compatible for your specific device.

I've seen something similar on Cadence macb as well. “cdns,gem” is
commented as #Generic there, but I wasn't sure where that came from. In
this case, it must be such a fallback. Thanks for the explanation, I
will take that into account for the new version.


Vasilij