Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 1 Apr 2023 16:41:29 +0300
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc:     Mark Brown <broonie@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        rafael@kernel.org, Colin Foster <colin.foster@in-advantage.com>,
        Lee Jones <lee@kernel.org>, davem@davemloft.net,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        thomas.petazzoni@bootlin.com
Subject: Re: [RFC 5/7] net: mdio: Introduce a regmap-based mdio driver
Message-ID: <20230401134129.txnxhl4sckkmziz7@skbuf>
References: <20230324093644.464704-1-maxime.chevallier@bootlin.com>
 <20230324093644.464704-6-maxime.chevallier@bootlin.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230324093644.464704-6-maxime.chevallier@bootlin.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?JXuKC5vk61z6ALN6nvVYrt+P7XVTVU01bmviBCmKrX7f3or8VtUtXRB6lPF1?=
 =?us-ascii?Q?eF3H40bypEde04olfzqIWBh7ACI9ixloglm+U2+QnGVkdT2b3+sqbgqJY500?=
 =?us-ascii?Q?f6+PPT2QegntFMy6H6EVRViD/7KKDQ+ysH537AXFjmKTiyA4E9f3NXGHTQJ0?=
 =?us-ascii?Q?ZpEasRiHZytVHKcMX0yTx8NuVSlgaaOoswNfrhZdgV6HoLHQRl8YZZ8MecYx?=
 =?us-ascii?Q?6M1NcUrpa8PeagSMk749Vozq9qDzM/902F8seM1kCw421tNPSu3T0mVn71B4?=
 =?us-ascii?Q?8N2MZW81VmuedpcjznfeIq9eQvxuIhnXWmxSlX6+TtQ1+h6q6YgV66ltBOCq?=
 =?us-ascii?Q?MCMugM7BN4GynynW+300tbfr/JRvemRmln0o3wXqzU6nUjguX5r8cxm9D3rb?=
 =?us-ascii?Q?gNoHJVbIOTRQQzkSap4Y1dRp6d+zBuPu6u2vD9LvUlDUuhixtx2K15kMNerg?=
 =?us-ascii?Q?+eZb/mmt22UwkwNBZPaXyyTiZVfJAR1ybNnfx55OHiR+EahUq6moSkIH9dQi?=
 =?us-ascii?Q?GKs163KusJvNQik5d4jLIKOe0RZ1Ci/Bk1fqYcNTKCu0Hlvfci6/9/GzZ8fn?=
 =?us-ascii?Q?P+n7cqxug+36EngRoX0ttCmcImv9DMg85nttbWsvgeQWLHj57egchYw62QS3?=
 =?us-ascii?Q?qCdkxGfo8g4gx8RdrXzuKj0+0/nyagQDJeGvpOkUM/40CoyWw0iZHBwn5ywl?=
 =?us-ascii?Q?5Xu2bq/U9Vklg68HEH+ByonjUcJysRqFYL52MkyiouTtDDN312uP+SeeD2qa?=
 =?us-ascii?Q?53p8AE4Gi5SfI14UFCT0/jldqWbQ9G113T103uXYa5l5mixT6ZI9bGtFs5i1?=
 =?us-ascii?Q?v7xaqLeIMNwirjvZ4e5milP1/uzQ7+/FCPYZboTRg2odRcXAGaqh429cazFz?=
 =?us-ascii?Q?5WSHNgedn5PLUXsGQ1m8B+qqkSOiI+hNdVGo9a+chG4zfviSFdAyViW5M45Z?=
 =?us-ascii?Q?k9YJT+DKHeF1hLrw0jlLJ0Z41Y7Ifeg6Kyh7IBf7sCz8v+78LQAutNkomr3g?=
 =?us-ascii?Q?PeDgCzhsdEdWcodDN82ndR+CzVEipHVRPMxh53LQKTfe6oWlzPA4MvC3uU50?=
 =?us-ascii?Q?tzv82dr9S6yZah89Kgckp9vAOtgNsUDTCrz5nZ6/HxZSx2xVssGe4kiD55ch?=
 =?us-ascii?Q?yMj7QhoAw98cK36JFpqmsWsqPpr4HsSNQwvnrWwQXJS5gCSCm0MfAF1aCfYK?=
 =?us-ascii?Q?t1keWVuK4DrmJDoh32sY6+OxS5pFnljsjh2T74t82k6QECpbPLYDyJTpc0QK?=
 =?us-ascii?Q?CQJrTYJggO0J7h3bg0vph2DyXbutL3+4ZbEIIPftp/Ofd5SZ40kuJNemIgsx?=
 =?us-ascii?Q?uTmlfQAyB84LsZ4WT5E1ZqdPa2QAE6ITRkzyQ8vUWyfThBo86sfw6ZqhUKH+?=
 =?us-ascii?Q?/3T3f9sXWLMa6ZApsMe7pPE7Y2hgZS3KU5hCiaxUZcVEKZd6YQqjwa/L1Gls?=
 =?us-ascii?Q?Idv/0GHuJvoIdmCk3iVa72LJfDfXr7RTisNS0OGKwo/6V68O9NCrmqXV0/8h?=
 =?us-ascii?Q?zSrbuqjFf6QcT4PMK9NKIdrNA/xojOYnOVZrYjtxDuWEfKEov7uGiDuToa8O?=
 =?us-ascii?Q?tHfV+d89yRg4O/BQg6PU21jNteOLaMF6UIZfuVkLcoNXUkT6/rJW5dKZth2Z?=
 =?us-ascii?Q?iw=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 28ea11f6-0ba6-48a3-77f8-08db32b6cedf
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2023 13:41:34.1725
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SIj/JkErVTe8v1R0ypYaIjFvIBjDZ5glB/NT9bsew36/HtSFKN9d2sNNomxZsINvc7Z9aO7ehTyd9Wez5dNIfA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB9488
X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
        DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
        SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Maxime,

On Fri, Mar 24, 2023 at 10:36:42AM +0100, Maxime Chevallier wrote:
> There exists several examples today of devices that embed an ethernet
> PHY or PCS directly inside an SoC. In this situation, either the device
> is controlled through a vendor-specific register set, or sometimes
> exposes the standard 802.3 registers that are typically accessed over
> MDIO.
> 
> As phylib and phylink are designed to use mdiodevices, this driver
> allows creating a virtual MDIO bus, that translates mdiodev register
> accesses to regmap accesses.
> 
> The reason we use regmap is because there are at least 3 such devices
> known today, 2 of them are Altera TSE PCS's, memory-mapped, exposed
> with a 4-byte stride in stmmac's dwmac-socfpga variant, and a 2-byte
> stride in altera-tse. The other one (nxp,sja1110-base-tx-mdio) is
> exposed over SPI.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>  MAINTAINERS                      |  7 +++
>  drivers/net/mdio/Kconfig         | 11 +++++
>  drivers/net/mdio/Makefile        |  1 +
>  drivers/net/mdio/mdio-regmap.c   | 85 ++++++++++++++++++++++++++++++++
>  include/linux/mdio/mdio-regmap.h | 25 ++++++++++
>  5 files changed, 129 insertions(+)
>  create mode 100644 drivers/net/mdio/mdio-regmap.c
>  create mode 100644 include/linux/mdio/mdio-regmap.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8d5bc223f305..10b3a1800e0d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12751,6 +12751,13 @@ F:	Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt
>  F:	drivers/net/ieee802154/mcr20a.c
>  F:	drivers/net/ieee802154/mcr20a.h
>  
> +MDIO REGMAP DRIVER
> +M:	Maxime Chevallier <maxime.chevallier@bootlin.com>
> +L:	netdev@vger.kernel.org
> +S:	Maintained
> +F:	drivers/net/mdio/mdio-regmap.c
> +F:	include/linux/mdio/mdio-regmap.h
> +
>  MEASUREMENT COMPUTING CIO-DAC IIO DRIVER
>  M:	William Breathitt Gray <william.gray@linaro.org>
>  L:	linux-iio@vger.kernel.org
> diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
> index 90309980686e..671e4bb82e3e 100644
> --- a/drivers/net/mdio/Kconfig
> +++ b/drivers/net/mdio/Kconfig
> @@ -182,6 +182,17 @@ config MDIO_IPQ8064
>  	  This driver supports the MDIO interface found in the network
>  	  interface units of the IPQ8064 SoC
>  
> +config MDIO_REGMAP
> +	tristate "Regmap-based virtual MDIO bus driver"

IMO this shouldn't have the text visible to the Kconfig user (just
"tristate"); it should only be selectable by the driver which makes use
of the exported symbol.

AFAIK, Kconfig options which are selectable should not depend on
anything. The dependency should transfer to the options which selects
it (here REGMAP). Optionally there can be a comment specifying that the

> +	depends on REGMAP
> +	help
> +	  This driver allows using MDIO devices that are not sitting on a
> +	  regular MDIO bus, but still exposes the standard 802.3 register
> +	  layout. It's regmap-based so that it can be used on integrated,
> +	  memory-mapped PHYs, SPI PHYs and so on. A new virtual MDIO bus is
> +	  created, and its read/write operations are mapped to the underlying
> +	  regmap.
> +
>  config MDIO_THUNDER
>  	tristate "ThunderX SOCs MDIO buses"
>  	depends on 64BIT
> diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile
> index 7d4cb4c11e4e..1015f0db4531 100644
> --- a/drivers/net/mdio/Makefile
> +++ b/drivers/net/mdio/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_MDIO_MOXART)		+= mdio-moxart.o
>  obj-$(CONFIG_MDIO_MSCC_MIIM)		+= mdio-mscc-miim.o
>  obj-$(CONFIG_MDIO_MVUSB)		+= mdio-mvusb.o
>  obj-$(CONFIG_MDIO_OCTEON)		+= mdio-octeon.o
> +obj-$(CONFIG_MDIO_REGMAP)		+= mdio-regmap.o
>  obj-$(CONFIG_MDIO_SUN4I)		+= mdio-sun4i.o
>  obj-$(CONFIG_MDIO_THUNDER)		+= mdio-thunder.o
>  obj-$(CONFIG_MDIO_XGENE)		+= mdio-xgene.o
> diff --git a/drivers/net/mdio/mdio-regmap.c b/drivers/net/mdio/mdio-regmap.c
> new file mode 100644
> index 000000000000..c85d62c2f55c
> --- /dev/null
> +++ b/drivers/net/mdio/mdio-regmap.c
> @@ -0,0 +1,85 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* Driver for MMIO-Mapped MDIO devices. Some IPs expose internal PHYs or PCS
> + * within the MMIO-mapped area
> + *
> + * Copyright (C) 2023 Maxime Chevallier <maxime.chevallier@bootlin.com>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/delay.h>
> +#include <linux/mdio.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_mdio.h>
> +#include <linux/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mdio/mdio-regmap.h>
> +
> +#define DRV_NAME "mdio-regmap"
> +
> +static int mdio_regmap_read_c22(struct mii_bus *bus, int addr, int regnum)
> +{
> +	struct mdio_regmap_config *ctx = bus->priv;
> +	unsigned int val;
> +	int ret;
> +
> +	if (!(ctx->valid_addr & BIT(addr)))
> +		return -ENODEV;
> +
> +	ret = regmap_read(ctx->regmap, regnum, &val);
> +	if (ret < 0)
> +		return ret;
> +
> +	return val;
> +}
> +
> +static int mdio_regmap_write_c22(struct mii_bus *bus, int addr, int regnum,
> +				 u16 val)
> +{
> +	struct mdio_regmap_config *ctx = bus->priv;
> +
> +	if (!(ctx->valid_addr & BIT(addr)))
> +		return -ENODEV;
> +
> +	return regmap_write(ctx->regmap, regnum, val);
> +}
> +
> +struct mii_bus *devm_mdio_regmap_register(struct device *dev,
> +					  const struct mdio_regmap_config *config)
> +{
> +	struct mdio_regmap_config *mrc;
> +	struct mii_bus *mii;
> +	int rc;
> +
> +	if (!config->parent)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!config->valid_addr)
> +		return ERR_PTR(-EINVAL);
> +
> +	mii = devm_mdiobus_alloc_size(config->parent, sizeof(*mrc));
> +	if (!mii)
> +		return ERR_PTR(-ENOMEM);
> +
> +	mrc = mii->priv;
> +	memcpy(mrc, config, sizeof(*mrc));
> +
> +	mrc->regmap = config->regmap;
> +	mrc->parent = config->parent;

mrc->parent doesn't seem to be used

> +	mrc->valid_addr = config->valid_addr;
> +
> +	mii->name = DRV_NAME;
> +	strncpy(mii->id, config->name, MII_BUS_ID_SIZE);
> +	mii->parent = config->parent;
> +	mii->read = mdio_regmap_read_c22;
> +	mii->write = mdio_regmap_write_c22;
> +
> +	rc = devm_mdiobus_register(dev, mii);
> +	if (rc) {
> +		dev_err(config->parent, "Cannot register MDIO bus![%s] (%d)\n", mii->id, rc);
> +		return ERR_PTR(rc);
> +	}
> +
> +	return mii;
> +}
> +
> diff --git a/include/linux/mdio/mdio-regmap.h b/include/linux/mdio/mdio-regmap.h
> new file mode 100644
> index 000000000000..ea428e5a2913
> --- /dev/null
> +++ b/include/linux/mdio/mdio-regmap.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Driver for MMIO-Mapped MDIO devices. Some IPs expose internal PHYs or PCS
> + * within the MMIO-mapped area
> + *
> + * Copyright (C) 2023 Maxime Chevallier <maxime.chevallier@bootlin.com>
> + */
> +#ifndef MDIO_REGMAP_H
> +#define MDIO_REGMAP_H
> +
> +#define MDIO_REGMAP_NAME 63

hmm.. NAME_LEN would be less confusing for a name. Although... why not
MII_BUS_ID_SIZE directly, seeing that this is how it is actually used?

> +
> +struct device;
> +struct regmap;
> +
> +struct mdio_regmap_config {
> +	struct device *parent;
> +	struct regmap *regmap;
> +	char name[MDIO_REGMAP_NAME];
> +	u32 valid_addr;

Would it be better to name this valid_addr_mask, since that is how it is
used? Or is the "ctx->valid_addr & BIT(addr)" check wrong (should have
been "ctx->valid_addr == addr")? How is the driver supposed to work with
multiple valid addresses?

> +};
> +
> +struct mii_bus *devm_mdio_regmap_register(struct device *dev,
> +					  const struct mdio_regmap_config *config);
> +
> +#endif
> -- 
> 2.39.2
>