mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>, Eric Dumazet <edumazet@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	Arun Ramadoss <arun.ramadoss@microchip.com>,
	Conor Dooley <conor+dt@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
	"Russell King (Oracle)" <linux@armlinux.org.uk>,
	devicetree@vger.kernel.org, Marek Vasut <marex@denx.de>
Subject: Re: [PATCH net-next v2 2/5] dt-bindings: net: dsa: ksz: add mdio-parent-bus property for internal MDIO
Date: Tue, 29 Oct 2024 14:31:07 +0200	[thread overview]
Message-ID: <20241029123107.ssvggsn2b5w3ehoy@skbuf> (raw)
In-Reply-To: <20241029110732.1977064-3-o.rempel@pengutronix.de>

On Tue, Oct 29, 2024 at 12:07:29PM +0100, Oleksij Rempel wrote:
> Introduce `mdio-parent-bus` property in the ksz DSA bindings to
> reference the parent MDIO bus when the internal MDIO bus is attached to
> it, bypassing the main management interface.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  .../devicetree/bindings/net/dsa/microchip,ksz.yaml       | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> index a4e463819d4d7..121a4bbd147be 100644
> --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> @@ -84,6 +84,15 @@ properties:
>    mdio:
>      $ref: /schemas/net/mdio.yaml#
>      unevaluatedProperties: false
> +    properties:
> +      mdio-parent-bus:
> +        $ref: /schemas/types.yaml#/definitions/phandle
> +        description:
> +          Phandle pointing to the MDIO bus controller connected to the
> +          secondary MDIO interface. This property should be used when
> +          the internal MDIO bus is accessed via a secondary MDIO
> +          interface rather than the primary management interface.
> +
>      patternProperties:
>        "^ethernet-phy@[0-9a-f]$":
>          type: object
> -- 
> 2.39.5
> 

I'm not saying whether this is good or bad, I'm just worried about
mixing quantities having different measurement units into the same
address space.

Just like in the case of an mdio-mux, there is no address space isolation
between the parent bus and the child bus. AKA you can't have this,
because there would be clashes:

	host_bus: mdio@abcd {
		ethernet-phy@2 {
			reg = <2>;
		};
	};

	child_bus: mdio@efgh {
		mdio-parent-bus = <&host_bus>;

		ethernet-phy@2 {
			reg = <2>;
		};
	};

But there is a big difference. With an mdio-mux, you could statically
detect address space clashes by inspecting the PHY addresses on the 2
buses. But with the lan937x child MDIO bus, in this design, you can't,
because the "reg" values don't represent MDIO addresses, but switch port
numbers (this is kind of important, but I don't see it mentioned in the
dt-binding). These are translated by lan937x_create_phy_addr_map() using
the CASCADE_ID/VPHY_ADD pin strapping information read over SPI.
I.e. with the same device tree, you may or may not have address space
clashes depending on pin strapping. No way to tell.

Have you considered putting the switch's internal PHYs directly under
the host MDIO bus node, with their 'real' MDIO bus computed statically
by the DT writer based on the pin straps? Yes, I'm aware that this means
different pin straps mean different device trees.

Under certain circumstances I could understand this dt-binding design
with an mdio-parent-bus, like for example if the MDIO addresses at which
the internal PHYs respond would be configurable over SPI, from the switch
registers. But I'm not led to believe that here, this is the case.

  reply	other threads:[~2024-10-29 12:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 11:07 [PATCH net-next v2 0/5] Side MDIO Support for LAN937x Switches Oleksij Rempel
2024-10-29 11:07 ` [PATCH net-next v2 1/5] dt-bindings: net: dsa: ksz: add internal MDIO bus description Oleksij Rempel
2024-10-29 11:07 ` [PATCH net-next v2 2/5] dt-bindings: net: dsa: ksz: add mdio-parent-bus property for internal MDIO Oleksij Rempel
2024-10-29 12:31   ` Vladimir Oltean [this message]
2024-10-29 13:11     ` Oleksij Rempel
2024-10-29 20:35       ` Andrew Lunn
2024-10-30  5:37         ` Oleksij Rempel
2024-10-30 12:31           ` Andrew Lunn
2024-10-29 11:07 ` [PATCH net-next v2 3/5] net: dsa: microchip: Refactor MDIO handling for side MDIO access Oleksij Rempel
2024-10-29 11:07 ` [PATCH net-next v2 4/5] net: dsa: microchip: cleanup error handling in ksz_mdio_register Oleksij Rempel
2024-10-29 11:07 ` [PATCH net-next v2 5/5] net: dsa: microchip: add support for side MDIO interface in LAN937x Oleksij Rempel

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=20241029123107.ssvggsn2b5w3ehoy@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=arun.ramadoss@microchip.com \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marex@denx.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=woojung.huh@microchip.com \
    /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

all inboxes | Powered by JetHome®