The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Peter Rosin <peda@lysator.liu.se>
Cc: tomm.merciai@gmail.com, prabhakar.mahadev-lad.rj@bp.renesas.com,
	peda@axentia.se, p.zabel@pengutronix.de, ulf.hansson@linaro.org,
	linux-renesas-soc@vger.kernel.org, biju.das.jz@bp.renesas.com,
	Ulf Hansson <ulfh@kernel.org>, Josua Mayer <josua@solid-run.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 1/1] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
Date: Fri, 7 Aug 2026 12:05:23 +0200	[thread overview]
Message-ID: <anWt48Y0yB_J_4Cv@tom-desktop> (raw)
In-Reply-To: <0ff405b3-31a2-4673-abb1-49293b137249@lysator.liu.se>

Hi Peter,
Thanks for your review.

On Fri, Aug 07, 2026 at 08:23:13AM +0200, Peter Rosin wrote:
> Hi!
> 
> Sorry for the late reply.
> 
> On 2026-07-15 12:12, Tommaso Merciai wrote:
> > As per the RZ/V2H(P) HW manual, VBUSEN can be controlled by the VBUS_SEL
> > bit of the VBENCTL Control Register. This register is mapped in the
> > reset framework. The reset driver expose this register as mux-controller
> > and instantiates this driver. The consumer will use the mux API to
> > control the VBUS_SEL bit.
> > 
> > Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > ---
> > v11->v12
> >  - No changes, just rebased on top of next-20260714
> > 
> > v10->v11:
> >  - No changes.
> > 
> > v9->v10:
> >  - No changes.
> > 
> > v8->v9:
> >  - Fixed driver comment year (2025 -> 2026)
> >  - Switch from devm_regmap_init_mmio() to dev_get_regmap().
> >  - Drop unnecessasry include bitops.h, of.h, property.h and
> >    drivers/reset/reset-rzv2h-usb2phy.h headers, driver is now based on regmap.
> >  - Collected PZabel tag.
> > 
> > v7->v8:
> >  - No changes.
> > 
> > v6->v7:
> >  - No changes.
> > 
> > v5->v6:
> >  - No changes.
> > 
> > v4->v5:
> >  - Changed file name to rzv2h-usb-vbenctl.c and Fixed
> >    Makefile, Kconfig, function names accordingly.
> >  - Changed driver .name to "vbenctl" and fix auxiliary_device_id name.
> >  - Updated commit msg.
> > 
> > v3->v4:
> >  - Removed mux_chip->dev.of_node not needed.
> > 
> > v2->v3:
> >  - Added mux_chip->dev.of_node = dev->of_node->child as the mux-controller
> >    is an internal node.
> >  - Fixed auxiliary_device_id name.
> >  - Get rdev using from platform_data.
> >  - Drop struct auxiliary_device adev from reset_rzv2h_usb2phy_adev
> >    as it is needed.
> >  - Drop to_reset_rzv2h_usb2phy_adev() as it is not needed.
> > 
> > v1->v2:
> >  - New patch
> > 
> >  drivers/mux/Kconfig             | 11 +++++
> >  drivers/mux/Makefile            |  2 +
> >  drivers/mux/rzv2h-usb-vbenctl.c | 85 +++++++++++++++++++++++++++++++++
> >  3 files changed, 98 insertions(+)
> >  create mode 100644 drivers/mux/rzv2h-usb-vbenctl.c
> > 
> > diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> > index 6d17dfa25dad..7f334540c189 100644
> > --- a/drivers/mux/Kconfig
> > +++ b/drivers/mux/Kconfig
> > @@ -70,6 +70,17 @@ config MUX_MMIO
> >  	  To compile the driver as a module, choose M here: the module will
> >  	  be called mux-mmio.
> >  
> > +config MUX_RZV2H_USB_VBENCTL
> 
> Do we really need such a long name? Can we skip at least some part
> of it, e.g. "USB_"? I see little in this driver that relates to
> USB. And then propagate the shorter name to the file name and
> various identifiers of course. Please?

Ok we can go with:

	MUX_RZV2H_VBENCTL

Then propagating:

	rzv2h-vbenctl.c

And functions prefix:

	mux_rzv2h_vbenctl_*


I will do this in v13.


> 
> > +	tristate "Renesas RZ/V2H USB VBENCTL VBUS_SEL mux driver"
> > +	depends on RESET_RZV2H_USB2PHY || COMPILE_TEST
> > +	depends on OF
> 
> Why OF?

Good catch, will drop this in v13.

> 
> > +	select REGMAP
> > +	select AUXILIARY_BUS
> > +	default RESET_RZV2H_USB2PHY
> > +	help
> > +	  Support for USB VBENCTL VBUS_SEL mux implemented on Renesas
> > +	  RZ/V2H SoCs.
> 
> All the other drivers have a boilerplate "module paragraph" here:
> 
> 	  To compile the driver as a module, choose M here: the module will
> 	  be called mux-<gazonk>.
> 
> I see no reason to exclude it here.

Will add this section in v13.

> 
> > +
> >  endmenu
> >  
> >  endif # MULTIPLEXER
> > diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
> > index 6e9fa47daf56..3bd9b3846835 100644
> > --- a/drivers/mux/Makefile
> > +++ b/drivers/mux/Makefile
> > @@ -8,9 +8,11 @@ mux-adg792a-objs		:= adg792a.o
> >  mux-adgs1408-objs		:= adgs1408.o
> >  mux-gpio-objs			:= gpio.o
> >  mux-mmio-objs			:= mmio.o
> > +mux-rzv2h-usb-vbenctl-objs	:= rzv2h-usb-vbenctl.o
> >  
> >  obj-$(CONFIG_MULTIPLEXER)	+= mux-core.o
> >  obj-$(CONFIG_MUX_ADG792A)	+= mux-adg792a.o
> >  obj-$(CONFIG_MUX_ADGS1408)	+= mux-adgs1408.o
> >  obj-$(CONFIG_MUX_GPIO)		+= mux-gpio.o
> >  obj-$(CONFIG_MUX_MMIO)		+= mux-mmio.o
> > +obj-$(CONFIG_MUX_RZV2H_USB_VBENCTL)	+= mux-rzv2h-usb-vbenctl.o
> > diff --git a/drivers/mux/rzv2h-usb-vbenctl.c b/drivers/mux/rzv2h-usb-vbenctl.c
> > new file mode 100644
> > index 000000000000..79197fddbf74
> > --- /dev/null
> > +++ b/drivers/mux/rzv2h-usb-vbenctl.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Renesas RZ/V2H(P) USB VBENCTL VBUS_SEL mux driver
> > + *
> > + * Copyright (C) 2026 Renesas Electronics Corp.
> > + */
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/err.h>
> > +#include <linux/module.h>
> > +#include <linux/mux/driver.h>
> > +#include <linux/regmap.h>
> > +
> > +#define RZV2H_VBENCTL		0xf0c
> > +
> > +struct mux_rzv2h_usb_vbenctl_priv {
> > +	struct regmap_field *field;
> > +};
> > +
> > +static int mux_rzv2h_usb_vbenctl_set(struct mux_control *mux, int state)
> > +{
> > +	struct mux_rzv2h_usb_vbenctl_priv *priv = mux_chip_priv(mux->chip);
> > +
> > +	return regmap_field_write(priv->field, state);
> > +}
> > +
> > +static const struct mux_control_ops mux_rzv2h_usb_vbenctl_ops = {
> > +	.set = mux_rzv2h_usb_vbenctl_set,
> > +};
> > +
> > +static int mux_rzv2h_usb_vbenctl_probe(struct auxiliary_device *adev,
> > +				       const struct auxiliary_device_id *id)
> > +{
> > +	struct mux_rzv2h_usb_vbenctl_priv *priv;
> > +	struct device *dev = &adev->dev;
> > +	struct mux_chip *mux_chip;
> > +	struct regmap *regmap;
> > +	struct reg_field reg_field = {
> > +		.reg = RZV2H_VBENCTL,
> > +		.lsb = 0,
> > +		.msb = 0,
> > +	};
> 
> Perhaps
> 
> 	struct reg_field reg_field = REG_FIELD(RZV2H_VBENCTL, 0, 0);

Ok will use this in v13.

> 
> > +	int ret;
> > +
> > +	regmap = dev_get_regmap(adev->dev.parent, NULL);
> 
> Perhaps
> 
> 	regmap = dev_get_regmap(dev->parent, NULL);

Ok, will use this in v13.


> 
> > +	if (!regmap)
> > +		return -ENODEV;
> > +
> > +	mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*priv));
> > +	if (IS_ERR(mux_chip))
> > +		return PTR_ERR(mux_chip);
> > +
> > +	priv = mux_chip_priv(mux_chip);
> > +
> > +	priv->field = devm_regmap_field_alloc(dev, regmap, reg_field);
> > +	if (IS_ERR(priv->field))
> > +		return PTR_ERR(priv->field);
> > +
> > +	mux_chip->ops = &mux_rzv2h_usb_vbenctl_ops;
> > +	mux_chip->mux[0].states = 2;
> > +	mux_chip->mux[0].idle_state = MUX_IDLE_AS_IS;
> > +
> > +	ret = devm_mux_chip_register(dev, mux_chip);
> > +	if (ret < 0)
> > +		return dev_err_probe(dev, ret, "Failed to register mux chip\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct auxiliary_device_id mux_rzv2h_usb_vbenctl_ids[] = {
> > +	{ .name = "rzv2h_usb2phy_reset.vbenctl" },
> > +	{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(auxiliary, mux_rzv2h_usb_vbenctl_ids);
> > +
> > +static struct auxiliary_driver mux_rzv2h_usb_vbenctl_driver = {
> > +	.name		= "vbenctl",
> > +	.probe		= mux_rzv2h_usb_vbenctl_probe,
> > +	.id_table	= mux_rzv2h_usb_vbenctl_ids,
> > +};
> > +module_auxiliary_driver(mux_rzv2h_usb_vbenctl_driver);
> > +
> 
> I'm not previously familiar with the auxiliary bus. When I read about
> it I find this:
> 
> 	"A key requirement for utilizing the auxiliary bus is that
> 	there is no dependency on a physical bus, device, register
> 	accesses or regmap support."
> 
> That seems to contradict this driver with its dependency on regmap,
> thus violating the above key requirement?

I'm seeing a very close pattern in [1]. clk-imx8ulp-sim-lpav.c create a
regmap for its auxiliary reset and mux driver. 

The parent driver is creating the axuiliary device in [2], this create
"clk_imx8ulp_sim_lpav.reset".

Then later reset-imx8mp-audiomix.c into
imx8mp_audiomix_reset_get_regmap() [3] take the rgmap from the parent.

Also reset-meson-aux.c [4] is aux device and is taking the regmap
from the parent.

IMHO the doc paragraph share why such a device can't be a platform
device or an MFD, matching on the auxiliary bus is a plain
string compare, so no register access is involved in match or bind.

[1] https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/clk/imx/clk-imx8ulp-sim-lpav.c#L95
[2] https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/clk/imx/clk-imx8ulp-sim-lpav.c#L123
[3] https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/reset/reset-imx8mp-audiomix.c#L162
[4] https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/reset/amlogic/reset-meson-aux.c#L65


Kind regards,
Tommaso

> 
> Cheers,
> Peter
> 
> > +MODULE_DESCRIPTION("RZ/V2H USB VBENCTL VBUS_SEL mux driver");
> > +MODULE_AUTHOR("Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>");
> > +MODULE_LICENSE("GPL");
> 

  reply	other threads:[~2026-08-07 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 10:12 [PATCH v12 0/1] Add USB2.0 VBUS mux driver for RZ/G3E Tommaso Merciai
2026-07-15 10:12 ` [PATCH v12 1/1] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux Tommaso Merciai
2026-07-15 13:53   ` Alvin Šipraga
2026-08-06 15:20   ` Lad, Prabhakar
2026-08-07  6:23   ` Peter Rosin
2026-08-07 10:05     ` Tommaso Merciai [this message]
2026-08-07 14:56       ` Peter Rosin

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=anWt48Y0yB_J_4Cv@tom-desktop \
    --to=tommaso.merciai.xr@bp.renesas.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=josua@solid-run.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=peda@axentia.se \
    --cc=peda@lysator.liu.se \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=tomm.merciai@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=ulfh@kernel.org \
    /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