[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z5xvRlKQiQ5cm0gl@makrotopia.org>
Date: Fri, 31 Jan 2025 06:35:50 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: lee@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
tsbogend@...ha.franken.de, hkallweit1@...il.com,
linux@...linux.org.uk, sander@...nheule.net,
markus.stockhausen@....de, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-mips@...r.kernel.org
Subject: Re: [PATCH v5 2/4] dt-bindings: mfd: Add MDIO interface to
rtl9301-switch
Hi Chris,
afaik net-next is still closed right now, but lets discuss the series as RFC
in the meantime maybe, right?
On Fri, Jan 31, 2025 at 02:01:49PM +1300, Chris Packham wrote:
> The MDIO controller is part of the switch on the RTL9300 family of
> devices. Add a $ref to the mfd binding for these devices.
>
> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> ---
>
> Notes:
> This patch is dependent on "dt-bindings: net: Add Realtek MDIO
> controller" which adds the realtek,rtl9301-mdio.yaml binding.
>
> Changes in v5:
> - Note dependency on realtek,rtl9301-mdio.yaml patch
> - Add back reg property to the mdio-controller node.
> Changes in v4:
> - There is a single MDIO controller that has MDIO buses as children
> Changes in v3:
> - None
> Changes in v2:
> - None
>
> .../bindings/mfd/realtek,rtl9301-switch.yaml | 29 +++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml b/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml
> index f053303ab1e6..89e10213a4ee 100644
> --- a/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml
> +++ b/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml
> @@ -28,6 +28,9 @@ properties:
> reg:
> maxItems: 1
>
> + mdio-controller:
> + $ref: /schemas/net/realtek,rtl9301-mdio.yaml#
> +
> '#address-cells':
> const: 1
>
> @@ -41,6 +44,10 @@ patternProperties:
> 'i2c@[0-9a-f]+$':
> $ref: /schemas/i2c/realtek,rtl9301-i2c.yaml#
>
> + 'mdio-controller@[0-9a-f]+$':
> + $ref: /schemas/net/realtek,rtl9301-mdio.yaml#
> +
> +
> required:
> - compatible
> - reg
> @@ -110,5 +117,27 @@ examples:
> };
> };
> };
> +
> + mdio-controller@...0 {
> + compatible = "realtek,rtl9301-mdio";
> + reg = <0xca00 0x200>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio-bus@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy@0 {
> + reg = <0>;
> + realtek,port = <1>;
Aren't all those PHYs referenced as phandles by DSA switch ports?
Imho it would be better to not introduce a new property but instead
let the driver of the mdio-controller parse the DSA switch description
and follow the existing 'phy-handle' properties in order to infer the
mapping of all ports to all PHYs, and by that then be able to also
know the reverse mapping.
You could reference the switch node in the mdio-controller node.
That would avoid redundant information in the device tree, as we
would then only have one mapping instead of having it two times
(once by the usual 'phy-handle' property of the DSA user port and
another time reverse using your newly introduce 'realtek,port'
property of each ethernet-phy).
> + };
> + ethernet-phy@1 {
> + reg = <1>;
> + realtek,port = <0>;
> + };
> + };
> + };
> };
>
> --
> 2.48.1
>
>
Powered by blists - more mailing lists