Re: [PATCH net-next v4 4/8] dt-bindings: mfd: Add SoC-e SWIP parent

[Vasilij Strassheim]

On Tue, 2026-11-10 at 13:21 -0600, Rob Herring wrote:
> On Tue, Nov 10, 2026 at 05:10:15PM +0100, Vasilij Strassheim wrote:
> > On Fri, 2026-11-06 at 22:51 +0100, Vasilij Strassheim wrote:
> > > On Fri, 2026-11-06 at 12:13 +0100, Krzysztof Kozlowski wrote:
> > > > On Thu, Nov 05, 2026 at 03:16:48PM +0100, Vasilij Strassheim wrote:
> > > > > Add a binding for the SoC-e SWIP multifunction FPGA IP core.
> > > > > 
> > > > > Describe the shared MMIO address space and address translation for
> > > > > the required Ethernet switch child and the optional integrated MDIO
> > > > > controller and MMIO-controlled MDIO multiplexer.
> > > > > 
> > > > > Signed-off-by: Vasilij Strassheim <v.strassheim@xxxxxxxxxxxxx>
> > > > > ---
> > > > >  .../devicetree/bindings/mfd/soce,swip.yaml         | 137 +++++++++++++++++++++
> > > > >  1 file changed, 137 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/mfd/soce,swip.yaml b/Documentation/devicetree/bindings/mfd/soce,swip.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..625be299e262
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/mfd/soce,swip.yaml
> > > > > @@ -0,0 +1,137 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/mfd/soce,swip.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: SoC-e SWIP multifunction Ethernet switch FPGA IP core
> > > > > +
> > > > > +maintainers:
> > > > > +  - Vasilij Strassheim <v.strassheim@xxxxxxxxxxxxx>
> > > > > +
> > > > > +description:
> > > > > +  SoC-e Switch IP (SWIP) cores integrate Ethernet switching logic, an
> > > > > +  MDIO controller, and an MDIO bus multiplexer in one memory-mapped device.
> > > > > +  The MDIO bus multiplexer is wired to the integrated MDIO controller.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: soce,swip
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  '#address-cells':
> > > > > +    const: 1
> > > > > +
> > > > > +  '#size-cells':
> > > > > +    const: 1
> > > > > +
> > > > > +  ranges: true
> > > > > +
> > > > > +  mdio@204:
> > > > > +    $ref: /schemas/net/soce,swip-mdio.yaml#
> > > > > +    unevaluatedProperties: false
> > > > > +
> > > > > +  mdio-mux@202:
> > > > > +    $ref: /schemas/net/mdio-mux-mmioreg.yaml#
> > > > > +    unevaluatedProperties: false
> 
> Given the MDIO bus and mux registers are adjacent, I don't know that 
> putting the mux into its own node and driver really buys you anything. 
> Can't your MDIO driver handle the muxing directly? mdio-mux-mmioreg was 
> created for when you have mux registers in some completely unrelated 
> block.
> 

What it buys me is less custom code to maintain for bus selection and
selector-value validation.

The MDIO controller and mux were combined in a previous version.
Following Andrew's suggestion [1], I moved the controller into its own
driver and stacked mdio-mux-mmioreg on top of it.
Sure, the selector is part of the same MDIO control register. But the
generic driver already provides the masked register update and
selector-value checks. My preference is to keep the current approach
to reuse existing code, even if it requires some integration and
documentation efforts.

I don't mind changing to a combined MDIO controller and mux, as done
in mdio-mux-bcm6368.c, while still using the generic MDIO mux core.

Could we agree on the preferred approach so that the binding and
driver changes stay aligned?

> > > > > +
> > > > > +  ethernet-switch:
> > > > 
> > > > Why are you mixing children with and without bus addresses? This is
> > > > discouraged and shows that device is not correctly represented, e.g. if
> > > > the ethernet-switch does not have resources, then THIS device is the
> > > > ethernet switch.
> > > > 
> > > 
> > > There is no hardware reason for leaving the switch child unaddressed.
> > > Just an error that occurred while converting the binding to the MFD
> > > model.
> > > I will describe the switch function as an ethernet-switch@0 child node
> > > with a reg property for it's register resources, like the ocelot MFD
> > > binding.
> > 
> > It looks like I need a different name for the MFD parent to avoid a
> > naming collision with the ethernet-switch@0 child. I checked other
> > bindings but could not find a suitable example.
> > 
> > I would appreciate any suggestions for a suitable name for the parent
> > node representing the FPGA IP core. It mainly acts as a container for
> > its child devices. I am considering "bus", "ip-core" or "shell".
> 
> Krzysztof's point was combine the child and parent nodes into the 
> parent. This is not really an MFD. Almost every ethernet MAC has an MDIO 
> controller in it and none of those bindings are MFDs.

The suggestion to consider an MFD also came from Andrew in an earlier
discussion [2]. Since this FPGA design contains several functional
blocks, I liked the approach of grouping them under a common parent.

The IP core can also include an I2C master for accessing external
devices as a synthesis option. It also supports synchronization with
external PPS and 10 MHz reference signals. I had future Linux support
for these functions in mind. Ocelot is another switch described as an
MFD, with additional functions such as GPIO and pin control.

I am open to either approach. Could we agree on the preferred hardware
model before I update the binding and driver?

I can also provide more information if any hardware details are still
unclear.

> 
> Rob

Thanks,
Vasilij