Re: [PATCH net-next v2 2/4] dt-bindings: net: dsa: Add SoC-e SWIP switch

[Vasilij Strassheim <v.strassheim@linutronix.de>]

On Mon, 2026-09-07 at 11:21 +0200, Krzysztof Kozlowski wrote:
> On Thu, Sep 03, 2026 at 08:10:59PM +0200, Vasilij Strassheim wrote:
> > Add a binding for SoC-e FPGA-based Ethernet switch IP cores.
> > 
> > The compatible identifies a register layout characterized by the core
> > and feature identification registers at the encoded offsets. The
> > concrete synthesis-time configuration is then autodetected from these
> > registers.
> > 
> > Signed-off-by: Vasilij Strassheim <v.strassheim@linutronix.de>
> > ---
> >  .../devicetree/bindings/net/dsa/soce,swip.yaml     | 161 +++++++++++++++++++++
> >  1 file changed, 161 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/soce,swip.yaml b/Documentation/devicetree/bindings/net/dsa/soce,swip.yaml
> > new file mode 100644
> > index 000000000000..508e444e10da
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/soce,swip.yaml
> > @@ -0,0 +1,161 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/soce,swip.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: SoC-e ethernet switch IP core for FPGAs
> > +
> > +maintainers:
> > +  - Vasilij Strassheim <v.strassheim@linutronix.de>
> > +
> > +description:
> > +  SoC-e Ethernet switch IP cores are FPGA-based switches whose features
> > +  and number of ports are selected at synthesis time. Ports can connect
> > +  to CPUs, external PHYs, FPGA logic, or other switch cores. The
> > +  integrated MDIO controller provides multiple independently selectable
> > +  external outputs.
> > +
> > +$ref: dsa.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: soce,swip-00-04-0c-10
> > +    description:
> > +      Register layout with the core version register at offset 0x00 and
> > +      feature identification registers at offsets 0x04, 0x0c, and 0x10.
> > +      Switch instances using this register layout are autodetected from
> > +      these registers and use this compatible regardless of their
> > +      synthesis-time feature and port configuration.
> 
> There is no traceable and documented version or model name?
> 

tl;dr
There are too many, but they are not specific enough. I think it is not
useful to use this information to define a specific compatible. Using a
set of known registers, the driver can check the active features and
capabilities and adapt accordingly, regardless of marketing names.

SoC-e shows different variants of their IP cores on their website:
https://soc-e.com/soctek-ip-cores/
SocTek is product line that covers different types of IP cores. Ethernet
switches, Timing controllers, and SpaceWire.
For Ethernet switches, there are different variants listed like Managed
Ethernet Switch (MES), Managed Redundant Switch (MRS) and some others.
Most of the variants are build of other variants e.g. MRS = MES+HPS
Think of it as name of a base collection of IP functionality. On top of
it you can license additional features. This do not result in a
different name. If you start with MES and buy HPS later on, you may or
may not end up with MRS.
Additionally, the actual switch is synthesized in FPGA, so the final
implementation can vary even if the same IP core is used e.g. port
number, deactivated features, etc.
This is used to bring down product costs: You can buy the same hardware,
really the same hardware - here a PLC - with a different bitstream.
Depending on the enabled features you have to pay more money for it.


> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  mdios:
> > +    type: object
> > +    additionalProperties: false
> > +    description:
> > +      External MDIO buses provided by the integrated MDIO controller.
> > +      Each child bus selects one controller output.
> > +
> > +    properties:
> > +      '#address-cells':
> > +        const: 1
> > +      '#size-cells':
> > +        const: 0
> > +
> > +    patternProperties:
> > +      '^mdio@[0-9a-f]+$':
> > +        $ref: /schemas/net/mdio.yaml#
> > +        unevaluatedProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            maximum: 30
> > +            description:
> > +              MDIO controller output index, which must be lower than the
> > +              number of implemented switch ports.
> > +
> > +        required:
> > +          - reg
> > +
> > +    required:
> > +      - '#address-cells'
> > +      - '#size-cells'
> > +
> > +patternProperties:
> > +  '^(ethernet-)?ports$':
> 
> ethernet-ports
> 
> > +    patternProperties:
> > +      '^(ethernet-)?port@[0-9a-f]+$':
> 
> ethernet-port
> 

Is there a reason for such a restriction?
The pattern intentionally follows the generic DSA binding in dsa.yaml,
which permits both ports/port@N and ethernet-ports/ethernet-port@N. The
device-specific pattern is needed here to apply the SoC-e port
constraints to both accepted node naming variants.

> > +        $ref: dsa-port.yaml#
> > +        unevaluatedProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            maximum: 30
> > +            description:
> > +              Switch port index. Supported switch configurations have
> > +              up to 31 ports, numbered from 0 through 30.

Thanks,
Vasilij