linux-kernel - Re: [PATCH v4 1/4] dt-bindings: net: Add Realtek MDIO controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <95923d9b-bf37-4256-a342-f71f4d814383@lunn.ch>
Date: Thu, 23 Jan 2025 23:08:52 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	"lee@...nel.org" <lee@...nel.org>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
	"hkallweit1@...il.com" <hkallweit1@...il.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>,
	"sander@...nheule.net" <sander@...nheule.net>,
	"markus.stockhausen@....de" <markus.stockhausen@....de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>
Subject: Re: [PATCH v4 1/4] dt-bindings: net: Add Realtek MDIO controller

> >> +        properties:
> >> +          realtek,port:
> >> +            $ref: /schemas/types.yaml#/definitions/uint32
> >> +            description:
> >> +              The MDIO communication on the RTL9300 is abstracted by the switch. At
> >> +              the software level communication uses the switch port to address the
> >> +              PHY with the actual MDIO bus and address having been setup via the
> >> +              parent mdio-bus and reg property.
> > I don't quite get why this cannot be the 'reg' property. I understood that
> > 'reg' of this node is not really used? Or you meant here this 'reg', not
> > parent's 'reg'?
> 
> It's is a bit confusing (any suggestions for improving the description 
> and/or commit message are welcome).

I don't know if it will actually help, but....

We have two entangled configurations here.

1) You have 4 MDIO busses which you need to describe using mdio.yaml
   In this binding, reg is the address of the device on the bus, in
   the range 0-31.

2) The hardware was a pool of PHYs which you can map to address on the
   MDIO busses.

Rather than combining them, maybe it would be better to keep them
separate. It is probably more error prone, but simpler to
understand. And hopefully errors result in PHYs not being found during
probe, so the problems are obvious.

Maybe you can actually use phandles. You have the usual MDIO bus
nodes:

    mdio@...30000 {
        #address-cells = <1>;
        #size-cells = <0>;

        ethphy0: ethernet-phy@1 {
            reg = <1>;
        };

        ethphy1: ethernet-phy@3 {
            reg = <3>;
        };
    };

    mdio@...40000 {
        #address-cells = <1>;
        #size-cells = <0>;

        ethphy2: ethernet-phy@1 {
            reg = <1>;
        };

        ethphy3: ethernet-phy@3 {
            reg = <3>;
        };
    };

    mdio@...50000 {
       ...
    }

    mdio@...60000 {
       ...
    }

    And then a node which is a list of PHY phandles:

    [&ethphy0, &ethphy1, &ethphy2, &ethphy3, ....]

The 0th entry in the list tells you have to map the 0th PHY in the
pool to an MDIO bus and address. Follow the phandle to get the MDIO
bus and the address on the bus.

	Andrew