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
> >
next prev parent 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).