devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: andrew@lunn.ch, vivien.didelot@gmail.com, f.fainelli@gmail.com,
	davem@davemloft.net, kuba@kernel.org, robh+dt@kernel.org,
	claudiu.manoil@nxp.com, alexandre.belloni@bootlin.com,
	UNGLinuxDriver@microchip.com, linux@armlinux.org.uk,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 net-next 8/8] Update documentation for the VSC7512 SPI device
Date: Sun, 11 Jul 2021 09:58:05 -0700	[thread overview]
Message-ID: <20210711165805.GF2219684@euler> (raw)
In-Reply-To: <20210710203411.nahqkyy4umqbtfwm@skbuf>

On Sat, Jul 10, 2021 at 11:34:11PM +0300, Vladimir Oltean wrote:
> On Sat, Jul 10, 2021 at 12:26:02PM -0700, Colin Foster wrote:
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  .../devicetree/bindings/net/dsa/ocelot.txt    | 68 +++++++++++++++++++
> >  1 file changed, 68 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/ocelot.txt b/Documentation/devicetree/bindings/net/dsa/ocelot.txt
> > index 7a271d070b72..f5d05bf8b093 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/ocelot.txt
> > +++ b/Documentation/devicetree/bindings/net/dsa/ocelot.txt
> > @@ -8,6 +8,7 @@ Currently the switches supported by the felix driver are:
> >  
> >  - VSC9959 (Felix)
> >  - VSC9953 (Seville)
> > +- VSC7511, VSC7512, VSC7513, VSC7514 via SPI
> >  
> >  The VSC9959 switch is found in the NXP LS1028A. It is a PCI device, part of the
> >  larger ENETC root complex. As a result, the ethernet-switch node is a sub-node
> > @@ -211,3 +212,70 @@ Example:
> >  		};
> >  	};
> >  };
> > +
> > +The VSC7513 and VSC7514 switches can be controlled internally via the MIPS
> > +processor. The VSC7511 and VSC7512 don't have this internal processor, but all
> > +four chips can be controlled externally through SPI with the following required
> > +properties:
> > +
> > +- compatible:
> > +	Can be "mscc,vsc7511", "mscc,vsc7512", "mscc,vsc7513", or
> > +	"mscc,vsc7514".
> > +
> > +Supported phy modes for all chips are:
> > +
> > +* phy_mode = "internal": on ports 0, 1, 2, 3
> > +
> > +Additionally, the VSC7512 and VSC7514 support SGMII and QSGMII on various ports,
> > +though that is currently untested.
> > +
> > +Example for control from a BeagleBone Black
> > +
> > +&spi0 {
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +	status = "okay";
> > +
> > +	vsc7512: vsc7512@0 {
> 
> ethernet-switch@0
> 
> > +		compatible = "mscc,vsc7512";
> > +		spi-max-frequency = <250000>;
> > +		reg = <0>;
> > +
> > +		ports {
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +
> > +			port@0 {
> > +				reg = <0>;
> > +				ethernet = <&mac>;
> > +				phy-mode = "internal";
> > +
> > +				fixed-link {
> > +					speed = <100>;
> > +					full-duplex;
> > +				};
> > +			};
> > +
> > +			port@1 {
> > +				reg = <1>;
> > +				label = "swp1";
> > +				status = "okay";
> 
> I am not convinced that the status = "okay" lines are useful in the
> example.

Fair enough

> 
> > +				phy-mode = "internal";
> 
> This syntax is ambiguous and does not obviously mean that the port has
> an internal copper PHY. Please see this discussion for other meanings of
> no 'phy-handle' and no 'fixed-link'.
> 
> https://www.mail-archive.com/u-boot@lists.denx.de/msg409571.html
> 
> I think it would be in the best interest of everyone to go through
> phylink_of_phy_connect() instead of phylink_connect_phy(), aka use the
> standard phy-handle property and create an mdio node under
> ethernet-switch@0 where the internal PHY OF nodes are defined.
> 
> I don't know if this is true for VSC7512 or not, but for example on
> NXP SJA1110, the internal PHYs can be accessed in 2 modes:
> (a) through SPI transfers
> (b) through an MDIO slave access point exposed by the switch chip, which
>     can be connected to an external MDIO controller
> 
> Some boards will use method (a), and others will use method (b).
> 
> Requiring a phy-handle under the port property is an absolutely generic
> way to seamlessly deal with both cases. In case (a), the phy-handle
> points to a child of an MDIO bus provided by the ocelot driver, in case
> (b) the phy-handle points to a child provided by some other MDIO
> controller driver.
> 

Yes, the Ocelot chips have the same functionality with the indirect /
direct access. It seems like this would be coupled with the other
discussion of updating mdio-mscc-miim.c so that the MDIO bus can be
defined.

And thank you for pointing out some examples. Having some starting
points really helps!

> > +			};
> > +
> > +			port@2 {
> > +				reg = <2>;
> > +				label = "swp2";
> > +				status = "okay";
> > +				phy-mode = "internal";
> > +			};
> > +
> > +			port@3 {
> > +				reg = <3>;
> > +				label = "swp3";
> > +				status = "okay";
> > +				phy-mode = "internal";
> > +			};
> > +		};
> > +	};
> > +};
> > -- 
> > 2.25.1
> > 

  reply	other threads:[~2021-07-11 16:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10 19:25 [RFC PATCH v2 net-next 0/8] Add support for VSC7511-7514 chips over SPI Colin Foster
2021-07-10 19:25 ` [RFC PATCH v2 net-next 1/8] net: dsa: ocelot: remove unnecessary pci_bar variables Colin Foster
2021-07-10 19:53   ` Vladimir Oltean
2021-07-11 16:36     ` Colin Foster
2021-07-10 19:25 ` [RFC PATCH v2 net-next 2/8] net: dsa: ocelot: felix: move MDIO access to a common location Colin Foster
2021-07-10 19:59   ` Vladimir Oltean
2021-07-10 20:02     ` Alexandre Belloni
2021-07-11 16:41     ` Colin Foster
2021-07-10 19:25 ` [RFC PATCH v2 net-next 3/8] net: dsa: ocelot: felix: NULL check on variable Colin Foster
2021-07-10 20:06   ` Vladimir Oltean
2021-07-11 16:47     ` Colin Foster
2021-07-10 19:25 ` [RFC PATCH v2 net-next 4/8] net: dsa: ocelot: felix: add interface for custom regmaps Colin Foster
2021-07-10 19:25 ` [RFC PATCH v2 net-next 5/8] net: mscc: ocelot: split register definitions to a separate file Colin Foster
2021-07-10 19:26 ` [RFC PATCH v2 net-next 6/8] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2021-07-10 20:36   ` Vladimir Oltean
2021-07-10 19:26 ` [RFC PATCH v2 net-next 7/8] net: dsa: ocelot: felix: add support for VSC75XX control over SPI Colin Foster
2021-07-10 20:52   ` Vladimir Oltean
2021-07-11 17:09     ` Colin Foster
2021-07-11 22:13       ` Alexandre Belloni
2021-07-10 19:26 ` [RFC PATCH v2 net-next 8/8] Update documentation for the VSC7512 SPI device Colin Foster
2021-07-10 20:34   ` Vladimir Oltean
2021-07-11 16:58     ` Colin Foster [this message]
2021-07-10 19:47 ` [RFC PATCH v2 net-next 0/8] Add support for VSC7511-7514 chips over SPI Vladimir Oltean
2021-07-11 16:32   ` Colin Foster
2021-07-10 20:01 ` Alexandre Belloni
2021-07-11 16:44   ` Colin Foster

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=20210711165805.GF2219684@euler \
    --to=colin.foster@in-advantage.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).