Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: lee@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	tsbogend@alpha.franken.de, hkallweit1@gmail.com,
	linux@armlinux.org.uk, sander@svanheule.net,
	markus.stockhausen@gmx.de, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-mips@vger.kernel.org
Subject: Re: [PATCH v5 2/4] dt-bindings: mfd: Add MDIO interface to rtl9301-switch
Date: Fri, 31 Jan 2025 06:35:50 +0000	[thread overview]
Message-ID: <Z5xvRlKQiQ5cm0gl@makrotopia.org> (raw)
In-Reply-To: <20250131010151.2527688-3-chris.packham@alliedtelesis.co.nz>

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@alliedtelesis.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@ca00 {
> +        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
> 
> 

  reply	other threads:[~2025-01-31  7:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31  1:01 [PATCH v5 0/4] RTL9300 MDIO driver Chris Packham
2025-01-31  1:01 ` [PATCH v5 1/4] dt-bindings: net: Add Realtek MDIO controller Chris Packham
2025-01-31  7:31   ` Krzysztof Kozlowski
2025-01-31  1:01 ` [PATCH v5 2/4] dt-bindings: mfd: Add MDIO interface to rtl9301-switch Chris Packham
2025-01-31  6:35   ` Daniel Golle [this message]
2025-02-02 20:14     ` Chris Packham
2025-01-31  7:33   ` Krzysztof Kozlowski
2025-01-31  1:01 ` [PATCH v5 3/4] mips: dts: realtek: Add MDIO controller Chris Packham
2025-01-31  1:01 ` [PATCH v5 4/4] net: mdio: Add RTL9300 MDIO driver Chris Packham
2025-01-31  1:16   ` Chris Packham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5xvRlKQiQ5cm0gl@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=markus.stockhausen@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --cc=sander@svanheule.net \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox