Received-SPF: pass (google.com: domain of linux-kernel+bounces-48015-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 1 Feb 2024 13:30:48 +0200
From: Vladimir Oltean <olteanv@gmail.com>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Alvin =?utf-8?Q?=C5=A0ipraga?= <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
Message-ID: <20240201113048.67td36b6bfufb2gk@skbuf>
References: <20240130-realtek_reverse-v5-0-ecafd9283a07@gmail.com>
 <20240130-realtek_reverse-v5-3-ecafd9283a07@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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);
>