Re: [PATCH 2/4] dt-bindings: net: dsa: Add SoC-e switch IP and DSA bindings
Andrew Lunn <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Aug 05, 2026 at 03:32:20PM +0200, Benedikt Spranger wrote: > On Mon, 3 Aug 2026 18:43:23 +0200 > Andrew Lunn <[email protected]> wrote: > > > If it is not compatible, it needs a different compatible. > This is quite tricky here - namewise. Yep. > > > 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? > > SOC-E sells quite a bunch of switch IPs (MES, MRS, NTS to name some). > As far as we know for now, these different IP cores can be determined > by reading specific registers, which seem to be on the same spot across > different IPs. You may wonder about "It seems". Since we have only a > limited access for information about different IPs, we have examined the > vendor linux DSA driver and the surrounding configuration software. Take a look at the mv88e6xxx driver. Marvell switches have an ID register. But Marvell keep moving it around. So the compatible is just about where to find the ID register. However, that is silicon. For licensed IP, you are not driving just the licensed IP, but also what has been put around it for integration into the system as a whole. Regulator, clocks, etc. The stmmac driver is an example of that, the driver has a core which covers the licensed IP, and then a number of glue drivers which extend that to cover all the integration logic. Another example i've worked on is the Open Cores I2C driver, i2c-ocores.c. It has a generic compatible "opencores,i2c-ocores", plus some integration specific compatibles, "aeroflexgaisler,i2cmst", "sifive,fu540-c000-i2c", "sifive,i2c0". So i suspect you will need to support integration specific compatibles. One way to consider this. Look at your FPGA design. Delete the licensed core. What do you have left? Does it need software to drive it? Andrew