From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Clément Léger" <clement.leger@bootlin.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Herve Codina" <herve.codina@bootlin.com>,
"Miquèl Raynal" <miquel.raynal@bootlin.com>,
"Milan Stevanovic" <milan.stevanovic@se.com>,
"Jimmy Lalande" <jimmy.lalande@se.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next 04/12] net: pcs: add Renesas MII converter driver
Date: Thu, 14 Apr 2022 13:49:08 +0100 [thread overview]
Message-ID: <YlgYRGVuHQCwp7FQ@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220414122250.158113-5-clement.leger@bootlin.com>
On Thu, Apr 14, 2022 at 02:22:42PM +0200, Clément Léger wrote:
> Add PCS driver for the MII converter that is present on Renesas RZ/N1
> SoC. This MII converter is reponsible of converting MII to RMII/RGMII
> or act as a MII passtrough. Exposing it as a PCS allows to reuse it
> in both the switch driver and the stmmac driver. Currently, this driver
> only allows the PCS to be used by the dual Cortex-A7 subsystem since
> the register locking system is not used.
Hi,
> +#define MIIC_CONVCTRL_CONV_MODE GENMASK(4, 0)
> +#define CONV_MODE_MII 0
> +#define CONV_MODE_RMII BIT(2)
> +#define CONV_MODE_RGMII BIT(3)
> +#define CONV_MODE_10MBPS 0
> +#define CONV_MODE_100MBPS BIT(0)
> +#define CONV_MODE_1000MBPS BIT(1)
Is this really a single 4-bit wide field? It looks like two 2-bit fields
to me.
> +#define phylink_pcs_to_miic_port(pcs) container_of((pcs), struct miic_port, pcs)
I prefer a helper function to a preprocessor macro for that, but I'm not
going to insist on that point.
> +static void miic_link_up(struct phylink_pcs *pcs, unsigned int mode,
> + phy_interface_t interface, int speed, int duplex)
> +{
> + struct miic_port *miic_port = phylink_pcs_to_miic_port(pcs);
> + struct miic *miic = miic_port->miic;
> + int port = miic_port->port;
> + u32 val = 0;
> +
> + if (duplex == DUPLEX_FULL)
> + val |= MIIC_CONVCTRL_FULLD;
> +
> + switch (interface) {
> + case PHY_INTERFACE_MODE_RMII:
> + val |= CONV_MODE_RMII;
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + val |= CONV_MODE_RGMII;
> + break;
> + case PHY_INTERFACE_MODE_MII:
> + val |= CONV_MODE_MII;
> + break;
> + default:
> + dev_err(miic->dev, "Unsupported interface %s\n",
> + phy_modes(interface));
> + return;
> + }
Why are you re-decoding the interface mode? The interface mode won't
change as a result of a call to link-up. Changing the interface mode
is a major configuration event that will always see a call to your
miic_config() function first.
> +
> + /* No speed in MII through-mode */
> + if (interface != PHY_INTERFACE_MODE_MII) {
> + switch (speed) {
> + case SPEED_1000:
> + val |= CONV_MODE_1000MBPS;
> + break;
> + case SPEED_100:
> + val |= CONV_MODE_100MBPS;
> + break;
> + case SPEED_10:
> + val |= CONV_MODE_10MBPS;
> + break;
> + case SPEED_UNKNOWN:
> + pr_err("Invalid speed\n");
> + /* Silently don't do anything */
> + return;
You shouldn't need to consider SPEED_UNKNOWN - if that's something we
really want to print a warning for, that should be done by phylink and
not by drivers.
> + default:
> + dev_err(miic->dev, "Invalid PCS speed %d\n", speed);
> + return;
> + }
> + }
> +
> + miic_reg_rmw(miic, MIIC_CONVCTRL(port),
> + (MIIC_CONVCTRL_CONV_MODE | MIIC_CONVCTRL_FULLD), val);
> +}
> +
> +static bool miic_mode_supported(phy_interface_t interface)
> +{
> + return (interface == PHY_INTERFACE_MODE_RGMII ||
> + interface == PHY_INTERFACE_MODE_RMII ||
> + interface == PHY_INTERFACE_MODE_MII);
> +}
> +
> +static int miic_validate(struct phylink_pcs *pcs, unsigned long *supported,
> + const struct phylink_link_state *state)
> +{
> + struct miic_port *miic_port = phylink_pcs_to_miic_port(pcs);
> + struct miic *miic = miic_port->miic;
> +
> + if (state->interface != PHY_INTERFACE_MODE_NA &&
PHY_INTERFACE_MODE_NA is no longer a "thing" with phylink with PCS
support, you no longer need to test for it.
> + !miic_mode_supported(state->interface)) {
> + dev_err(miic->dev, "phy mode %s is unsupported on port %d\n",
> + phy_modes(state->interface), miic_port->port);
Please don't print an error if the interface mode is not supported.
> + linkmode_zero(supported);
There is no need to zero the support mask if you return an error.
> + return -EOPNOTSUPP;
From the method documentation:
* Returns -EINVAL if the interface mode/autoneg mode is not supported.
* Returns non-zero positive if the link state can be supported.
Also, really, the MAC layer should ensure that the PCS isn't used for
interface modes that it doesn't support. I might introduce a bitmap of
interface modes for PCS later if there's a benefit to doing so.
> + }
> +
> + return 0;
> +}
> +
> +static const struct phylink_pcs_ops miic_phylink_ops = {
> + .pcs_config = miic_config,
> + .pcs_link_up = miic_link_up,
> + .pcs_validate = miic_validate,
I'd prefer to have them in the order that they are in the structure.
> +};
> +
> +struct phylink_pcs *miic_create(struct device_node *np)
> +{
> + struct platform_device *pdev;
> + struct miic_port *miic_port;
> + struct device_node *pcs_np;
> + u32 port;
> +
> + if (of_property_read_u32(np, "reg", &port))
> + return ERR_PTR(-EINVAL);
> +
> + if (port >= MIIC_MAX_NR_PORTS)
> + return ERR_PTR(-EINVAL);
> +
> + /* The PCS pdev is attached to the parent node */
> + pcs_np = of_get_parent(np);
> + if (!pcs_np)
> + return ERR_PTR(-EINVAL);
> +
> + pdev = of_find_device_by_node(pcs_np);
> + if (!pdev || !platform_get_drvdata(pdev))
> + return ERR_PTR(-EPROBE_DEFER);
It would be a good idea to have a comment in the probe function to say
that this relies on platform_set_drvdata() being the very last thing
after a point where initialisation is complete and we won't fail.
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2022-04-14 12:49 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 12:22 [PATCH net-next 00/12] add support for Renesas RZ/N1 ethernet subsystem devices Clément Léger
2022-04-14 12:22 ` [PATCH net-next 01/12] net: dsa: add support for Renesas RZ/N1 A5PSW switch tag code Clément Léger
2022-04-14 13:44 ` Vladimir Oltean
2022-04-14 12:22 ` [PATCH net-next 02/12] net: dsa: add Renesas RZ/N1 switch tag driver Clément Léger
2022-04-14 14:22 ` Vladimir Oltean
2022-04-14 14:35 ` Clément Léger
2022-04-14 15:11 ` Vladimir Oltean
2022-04-14 16:18 ` Clément Léger
2022-04-14 16:23 ` Russell King (Oracle)
2022-04-15 7:23 ` Clément Léger
2022-04-14 22:50 ` Andrew Lunn
2022-04-14 12:22 ` [PATCH net-next 03/12] dt-bindings: net: pcs: add bindings for Renesas RZ/N1 MII converter Clément Léger
2022-04-14 18:59 ` Rob Herring
2022-04-19 13:43 ` Rob Herring
2022-04-19 15:00 ` Clément Léger
2022-04-20 20:11 ` Rob Herring
2022-04-21 7:35 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 04/12] net: pcs: add Renesas MII converter driver Clément Léger
2022-04-14 12:49 ` Russell King (Oracle) [this message]
2022-04-14 15:14 ` Clément Léger
2022-04-20 13:25 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 05/12] dt-bindings: net: dsa: add bindings for Renesas RZ/N1 Advanced 5 port switch Clément Léger
2022-04-14 18:59 ` Rob Herring
2022-04-27 12:20 ` Geert Uytterhoeven
2022-04-27 12:56 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 06/12] net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver Clément Léger
2022-04-14 13:02 ` Russell King (Oracle)
2022-04-15 8:40 ` Clément Léger
2022-04-15 8:52 ` Russell King (Oracle)
2022-04-14 14:47 ` Vladimir Oltean
2022-04-14 17:51 ` Andrew Lunn
2022-04-15 9:34 ` Clément Léger
2022-04-15 10:55 ` Vladimir Oltean
2022-04-15 11:02 ` Russell King (Oracle)
2022-04-15 11:14 ` Vladimir Oltean
2022-04-15 11:23 ` Russell King (Oracle)
2022-04-15 12:01 ` Vladimir Oltean
2022-04-15 11:05 ` Vladimir Oltean
2022-04-15 12:31 ` Clément Léger
2022-04-15 12:28 ` Clément Léger
2022-04-15 12:41 ` Vladimir Oltean
2022-04-14 17:55 ` Andrew Lunn
2022-04-15 12:33 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 07/12] net: dsa: rzn1-a5psw: add statistics support Clément Léger
2022-04-14 17:34 ` Vladimir Oltean
2022-04-15 12:42 ` Clément Léger
2022-04-14 23:16 ` Andrew Lunn
2022-04-15 12:04 ` Clément Léger
2022-04-15 13:37 ` Andrew Lunn
2022-04-15 13:44 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 08/12] net: dsa: rzn1-a5psw: add FDB support Clément Léger
2022-04-14 17:51 ` Vladimir Oltean
2022-04-20 8:16 ` Clément Léger
2022-04-20 19:52 ` Vladimir Oltean
2022-04-21 7:38 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 09/12] ARM: dts: r9a06g032: describe MII converter Clément Léger
2022-04-14 23:22 ` Andrew Lunn
2022-04-15 8:24 ` Clément Léger
2022-04-15 14:16 ` Andrew Lunn
2022-04-15 14:38 ` Clément Léger
2022-04-15 15:12 ` Andrew Lunn
2022-04-15 15:29 ` Clément Léger
2022-04-15 16:19 ` Andrew Lunn
2022-04-15 16:45 ` Clément Léger
2022-04-16 13:48 ` Andrew Lunn
2022-04-19 9:03 ` Clément Léger
2022-04-19 12:57 ` Andrew Lunn
2022-04-20 20:16 ` Rob Herring
2022-04-14 12:22 ` [PATCH net-next 10/12] ARM: dts: r9a06g032: describe GMAC2 Clément Léger
2022-04-21 9:31 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 11/12] ARM: dts: r9a06g032: describe switch Clément Léger
2022-04-21 9:34 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 12/12] MAINTAINERS: add Renesas RZ/N1 switch related driver entry Clément Léger
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=YlgYRGVuHQCwp7FQ@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=clement.leger@bootlin.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=geert+renesas@glider.be \
--cc=herve.codina@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=jimmy.lalande@se.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=milan.stevanovic@se.com \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--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).