Re: [PATCH v4 3/9] reset: rzg2l-usbphy-ctrl: Add RZ/G3L support

Philipp Zabel <[email protected]> Thu, 06 Aug 2026 09:56:29 +0200
Newsgroups org.kernel.vger.linux-renesas-soc,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mi, 2026-08-05 at 10:26 +0000, Biju Das wrote:
> Hi Philipp Zabel,
> 
> > -----Original Message-----
> > From: Biju <[email protected]>
> > Sent: 09 July 2026 09:31
> > Subject: [PATCH v4 3/9] reset: rzg2l-usbphy-ctrl: Add RZ/G3L support
> > 
> > From: Biju Das <[email protected]>
> > 
> > Add the renesas,r9a08g046-usbphy-ctrl compatible string to the OF match table for the RZ/G3L (r9a08g046)
> > SoC, using a dedicated rzg3l_info struct with pwrrdy set, similar to RZ/G3S.
> > 
> > The RZ/G3L SoC has 2 OTG controllers compared to one on RZ/G3S, so it uses a separate rzg3l-vbus-
> > regulator driver to handle the additional VBUSEN control for port 2. The regulator_driver_name field is
> > used as the platform device name passed to platform_device_alloc(), and must exactly match the name the
> > corresponding regulator driver registers via its id_table for platform bus matching to succeed.
> > 
> > Signed-off-by: Biju Das <[email protected]>
> > ---
> > v3->v4:
> >  * Updated the commit description.
> >  * Migrated to id_table match using driver_name and reduced the length
> >    < 24.
> > v2->v3:
> >  * No change.
> > v1->v2:
> >  * No change.
> > ---
> >  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > index 84e745e49240..0803195080bd 100644
> > --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> > @@ -42,6 +42,7 @@ struct rzg2l_usbphy_ctrl_priv {  };
> > 
> >  struct rzg2l_usbphy_ctrl_info {
> > +	const char *regulator_driver_name;
> >  	bool pwrrdy;
> >  };
> > 
> > @@ -110,15 +111,24 @@ static void rzg2l_usbphy_ctrl_init(struct rzg2l_usbphy_ctrl_priv *priv)
> >  	spin_unlock_irqrestore(&priv->lock, flags);  }
> > 
> > -static const struct rzg2l_usbphy_ctrl_info rzg2l_info = {};
> > +static const struct rzg2l_usbphy_ctrl_info rzg2l_info = {
> > +	.regulator_driver_name = "rzg2l-vbus-regulator", };
> > 
> >  static const struct rzg2l_usbphy_ctrl_info rzg3s_info = {
> > +	.regulator_driver_name = "rzg2l-vbus-regulator",
> > +	.pwrrdy = true,
> > +};
> > +
> > +static const struct rzg2l_usbphy_ctrl_info rzg3l_info = {
> > +	.regulator_driver_name = "rzg3l-vbus-regulator",
> >  	.pwrrdy = true,
> >  };
> > 
> >  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
> >  	{ .compatible = "renesas,rzg2l-usbphy-ctrl", .data = &rzg2l_info },
> >  	{ .compatible = "renesas,r9a08g045-usbphy-ctrl", .data = &rzg3s_info },
> > +	{ .compatible = "renesas,r9a08g046-usbphy-ctrl", .data = &rzg3l_info
> > +},
> >  	{ /* Sentinel */ }
> >  };
> >  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table); @@ -245,7 +255,7 @@ static int
> > rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
> >  	if (error)
> >  		goto err_pm_runtime_put;
> > 
> > -	vdev = platform_device_alloc("rzg2l-usb-vbus-regulator", pdev->id);
> > +	vdev = platform_device_alloc(info->regulator_driver_name, pdev->id);
> 
> Please let me know, should I send a patch to increase the length from 24->32 [1]
> So that there won't be any backward compatibility issues.
> 
> [1] https://elixir.bootlin.com/linux/v7.1.2/source/include/linux/mod_devicetable.h#L604

I'm not sure.

PLATFORM_NAME_SIZE was last extended in commit 655862865c97
("mod_devicetable: Enlarge the maximum platform_device_id name
length"), but only very conservatively. Whether it is relevant that
platform_device_id fits into 32-byte cache line size of some
architectures, I can't say. The _NAME_SIZEs of other buses (aux, i2c,
spi, ...) already vary between 20 and 40 chars.

You could either try that, or you could prepend a single patch that
does the "rzg2l-usb-vbus-regulator" -> "rzg2l-vbus-regulator" rename in
both regulator and reset drivers and that could be merged into both
trees.


regards
Philipp