All of lore.kernel.org
 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: 28+ 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 21:05   ` kernel test robot
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 21:51   ` kernel test robot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.