Re: [PATCH 0/4] net: dsa: Add SoC-e DSA driver

[Vasilij Strassheim]

On Mon, 2026-08-03 at 18:32 +0200, Andrew Lunn wrote:
> On Mon, Aug 03, 2026 at 05:22:35PM +0200, Vasilij Strassheim wrote:
> > On Wed, 2026-07-29 at 18:56 +0200, Andrew Lunn wrote:
> > > On Wed, Jul 29, 2026 at 06:36:53PM +0200, Vasilij Strassheim wrote:
> > > > Add initial support for the DSA driver for SoC-e FPGA-based (IP core)
> > > > Ethernet switches.
> > > 
> > > Let me start with a dumb question. Is this a true soft core switch,
> > > which is synthesised and running in the FPGA? Or is it hardware at the
> > > edge of the FPGA SoC?
> > 
> > I should have made that clearer right away. This is a true soft-core
> > switch that is synthesized and runs in AMD FPGAs.
> 
> Only AMD FPGAs? Or you have only used it with AMD FPGS?

That's what the documentation says. However the webpage says: 
	AMD/Xilinx and Microchip supported. Other vendors to be
	supported in the future.
I don't know any more details than that.

> 
> > I have a version in which both the MAC and the switch are synthesized
> > in FPGA, and two hardware PHYs are connected to the switch. The switch
> > provides an MDIO bus for the PHYs.
> > 
> > > 
> > > If it is synthesised, do we have to deal with different synthesis
> > > options? Are there registers which indicate what these options are?
> > 
> > While setting up the switch, users will need to explore various
> > synthesis options. Once it's up and running, it should be possible to
> > load a preconfigured bitstream into the FPGA without having to deal with
> > these options in the DSA driver. The device Tree should then match the
> > configuration.
> 
> This is where we often run into issues. The driver sometimes makes
> assumptions about how the device has been synthesised. Somebody
> synthesise it differently, it breaks, and the driver has to be changed
> without breaking backwards compatibility.
> 
> If the hardware actually enumerates itself, tells us how it has been
> configured for synthesis, and the driver looks at these registers, you
> tend to have less assumptions and so less issues later.
> 
> This is also one area what DT is not so great. You are not actually
> describing hardware. Clearly, it is not software, but it is malleable,
> jellyware. The less you put in DT, the more you get from the jellywere
> itself, the better.
> 

Yes, that makes sense. With this v1, I had to work around a few
non-technical limitations. I will try to resolve these and come up with
a new version where as much as necessary is read out from the jellyware.

With further adjustments, the dt-bindings should then contain only the
bare essentials. Not more that any other DSA driver would need.

> 	Andrew

Thanks,
Vasilij