From: Vladimir Oltean <olteanv@gmail.com>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Russell King" <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v5 03/11] net: dsa: realtek: convert variants into real drivers
Date: Thu, 1 Feb 2024 13:30:48 +0200 [thread overview]
Message-ID: <20240201113048.67td36b6bfufb2gk@skbuf> (raw)
In-Reply-To: <20240130-realtek_reverse-v5-3-ecafd9283a07@gmail.com>
On Tue, Jan 30, 2024 at 08:13:22PM -0300, Luiz Angelo Daros de Luca wrote:
> Previously, the interface modules realtek-smi and realtek-mdio served as
> a platform and an MDIO driver, respectively. Each interface module
> redundantly specified the same compatible strings for both variants and
> referenced symbols from the variants.
>
> Now, each variant module has been transformed into a unified driver
> serving both as a platform and an MDIO driver. This modification
> reverses the relationship between the interface and variant modules,
> with the variant module now utilizing symbols from the interface
> modules.
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> ---
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Some minor non-functional comments below which you might decide not to
address now, depending on what else is pointed out during review.
> diff --git a/drivers/net/dsa/realtek/realtek-mdio.c b/drivers/net/dsa/realtek/realtek-mdio.c
> index c2572463679f..3433f64fb0d7 100644
> --- a/drivers/net/dsa/realtek/realtek-mdio.c
> +++ b/drivers/net/dsa/realtek/realtek-mdio.c
> @@ -140,7 +141,19 @@ static const struct regmap_config realtek_mdio_nolock_regmap_config = {
> .disable_locking = true,
> };
>
> -static int realtek_mdio_probe(struct mdio_device *mdiodev)
> +/**
> + * realtek_mdio_probe() - Probe a platform device for an MDIO-connected switch
> + * @mdiodev: mdio_device to probe on.
> + *
> + * This function should be used as the .probe in an mdio_driver. It
> + * initializes realtek_priv and read data from the device-tree node. The switch
> + * is hard resetted if a method is provided. It checks the switch chip ID and,
nitpick: participle of 'reset' is 'reset'. Same comment for realtek_smi_probe().
> + * finally, a DSA switch is registered.
> + *
> + * Context: Can sleep. Takes and releases priv->map_lock.
> + * Return: Returns 0 on success, a negative error on failure.
> + */
> +int realtek_mdio_probe(struct mdio_device *mdiodev)
> {
> struct realtek_priv *priv;
> struct device *dev = &mdiodev->dev;
> diff --git a/drivers/net/dsa/realtek/realtek-smi.c b/drivers/net/dsa/realtek/realtek-smi.c
> index 668336515119..d8a9a6a6b5bc 100644
> --- a/drivers/net/dsa/realtek/realtek-smi.c
> +++ b/drivers/net/dsa/realtek/realtek-smi.c
> @@ -505,8 +518,20 @@ static int realtek_smi_probe(struct platform_device *pdev)
> }
> return 0;
> }
> +EXPORT_SYMBOL_NS_GPL(realtek_smi_probe, REALTEK_DSA);
>
> -static void realtek_smi_remove(struct platform_device *pdev)
> +/**
> + * realtek_smi_remove() - Remove the driver of a SMI-connected switch
> + * @pdev: platform_device to be removed.
> + *
> + * This function should be used as the .remove_new in a platform_driver. First
> + * it unregisters the DSA switch and cleans internal data. If a method is
> + * provided, the hard reset is asserted to avoid traffic leakage.
FWIW, removing the driver unregisters the net devices, which disables
the ports and performs an orderly shutdown of any upper virtual net
devices as well, like bridges. So ports automatically roll back to
standalone operation before this callback is even issued.
Traffic leakage is prevented, and the switch is hard reset, but I don't
think there is any causal relationship between the two.
> + *
> + * Context: Can sleep.
> + * Return: Nothing.
> + */
> +void realtek_smi_remove(struct platform_device *pdev)
> {
> struct realtek_priv *priv = platform_get_drvdata(pdev);
>
next prev parent reply other threads:[~2024-02-01 11:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 23:13 [PATCH net-next v5 00/11] net: dsa: realtek: variants to drivers, interfaces to a common module Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 01/11] net: dsa: realtek: drop cleanup from realtek_ops Luiz Angelo Daros de Luca
2024-02-01 0:40 ` Vladimir Oltean
2024-01-30 23:13 ` [PATCH net-next v5 02/11] net: dsa: realtek: introduce REALTEK_DSA namespace Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 03/11] net: dsa: realtek: convert variants into real drivers Luiz Angelo Daros de Luca
2024-02-01 11:30 ` Vladimir Oltean [this message]
2024-01-30 23:13 ` [PATCH net-next v5 04/11] net: dsa: realtek: keep variant reference in realtek_priv Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 05/11] net: dsa: realtek: common rtl83xx module Luiz Angelo Daros de Luca
2024-02-01 18:23 ` Vladimir Oltean
2024-01-30 23:13 ` [PATCH net-next v5 06/11] net: dsa: realtek: merge rtl83xx and interface modules into realtek-dsa Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 07/11] net: dsa: realtek: get internal MDIO node by name Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 08/11] net: dsa: realtek: clean user_mii_bus setup Luiz Angelo Daros de Luca
2024-02-01 22:33 ` Vladimir Oltean
2024-01-30 23:13 ` [PATCH net-next v5 09/11] net: dsa: realtek: migrate user_mii_bus setup to realtek-dsa Luiz Angelo Daros de Luca
2024-02-01 22:45 ` Vladimir Oltean
2024-02-05 22:43 ` Luiz Angelo Daros de Luca
2024-01-30 23:13 ` [PATCH net-next v5 10/11] net: dsa: realtek: use the same mii bus driver for both interfaces Luiz Angelo Daros de Luca
2024-02-01 22:48 ` Vladimir Oltean
2024-01-30 23:13 ` [PATCH net-next v5 11/11] net: dsa: realtek: embed dsa_switch into realtek_priv Luiz Angelo Daros de Luca
2024-02-01 22:58 ` Vladimir Oltean
2024-02-05 21:49 ` Luiz Angelo Daros de Luca
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=20240201113048.67td36b6bfufb2gk@skbuf \
--to=olteanv@gmail.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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