From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Mark Brown <broonie@kernel.org>
Cc: tomm.merciai@gmail.com, linux-renesas-soc@vger.kernel.org,
biju.das.jz@bp.renesas.com,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/18] regulator: devres: Disable exclusive regulator before releasing
Date: Fri, 3 Oct 2025 19:33:25 +0200 [thread overview]
Message-ID: <aOAI5cfA1HmEc7Rv@tom-desktop> (raw)
In-Reply-To: <ae2701a5-8662-47d3-81fa-30e832600423@sirena.org.uk>
Hi Mark,
Thank you for your comments,
On Thu, Oct 02, 2025 at 05:29:19PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2025 at 11:26:51PM +0200, Tommaso Merciai wrote:
>
> You've not copied me on the rest of the series so I don't know what's
> going on with dependencies. When sending a patch series it is important
> to ensure that all the various maintainers understand what the
> relationship between the patches as the expecation is that there will be
> interdependencies. Either copy everyone on the whole series or at least
> copy them on the cover letter and explain what's going on. If there are
> no strong interdependencies then it's generally simplest to just send
> the patches separately to avoid any possible confusion.
Thanks for the explanation.
I made a mistake when I sent the series.
I only ran ./scripts/get_maintainer.pl on some patches, not all.
My fault, sorry for that.
>
> > Ensure that exclusive regulators are properly disabled when their reference
> > count drops to one before they are released. This prevents possible issues
> > where exclusive regulators may remain enabled unintentionally after being
> > put.
>
> The reason we don't normally drop references that devices hold is that
> we're allowing the driver to control if the suppy should be disabled on
> exit, powering off something that's critical for the system just because
> we're not managing it in software won't go well. Consider reloading a
> module during development for example.
>
> > static void devm_regulator_release(struct device *dev, void *res)
> > {
> > - regulator_put(*(struct regulator **)res);
> > + struct regulator *regulator = *(struct regulator **)res;
> > + struct regulator_dev *rdev = regulator->rdev;
> > +
> > + if (rdev->exclusive && regulator->enable_count == 1)
> > + regulator_disable(regulator);
> > +
> > + regulator_put(regulator);
> > }
>
> There's no reason that exclusive consumers don't use the refcounting
> support...
I will need to move the refcounting handlingfor the exclusive regulator
at USB driver lvl.
The drivers/phy/renesas/phy-rcar-gen3-usb2.c is using
regulator_hardware_enable() for some USB otg channel. I think this is
the reason why I need this patch to handle multiple unbind/bind.
Without this I'm getting some WARN_ON(regulator->enable_count) doing
multiple unbind/bind.
I'm going to investigate on that and I need to find a solution at usb driver lvl.
Thanks again for your feedback!
Regards,
Tommaso
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Mark Brown <broonie@kernel.org>
Cc: tomm.merciai@gmail.com, linux-renesas-soc@vger.kernel.org,
biju.das.jz@bp.renesas.com,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/18] regulator: devres: Disable exclusive regulator before releasing
Date: Fri, 3 Oct 2025 19:33:25 +0200 [thread overview]
Message-ID: <aOAI5cfA1HmEc7Rv@tom-desktop> (raw)
In-Reply-To: <ae2701a5-8662-47d3-81fa-30e832600423@sirena.org.uk>
Hi Mark,
Thank you for your comments,
On Thu, Oct 02, 2025 at 05:29:19PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2025 at 11:26:51PM +0200, Tommaso Merciai wrote:
>
> You've not copied me on the rest of the series so I don't know what's
> going on with dependencies. When sending a patch series it is important
> to ensure that all the various maintainers understand what the
> relationship between the patches as the expecation is that there will be
> interdependencies. Either copy everyone on the whole series or at least
> copy them on the cover letter and explain what's going on. If there are
> no strong interdependencies then it's generally simplest to just send
> the patches separately to avoid any possible confusion.
Thanks for the explanation.
I made a mistake when I sent the series.
I only ran ./scripts/get_maintainer.pl on some patches, not all.
My fault, sorry for that.
>
> > Ensure that exclusive regulators are properly disabled when their reference
> > count drops to one before they are released. This prevents possible issues
> > where exclusive regulators may remain enabled unintentionally after being
> > put.
>
> The reason we don't normally drop references that devices hold is that
> we're allowing the driver to control if the suppy should be disabled on
> exit, powering off something that's critical for the system just because
> we're not managing it in software won't go well. Consider reloading a
> module during development for example.
>
> > static void devm_regulator_release(struct device *dev, void *res)
> > {
> > - regulator_put(*(struct regulator **)res);
> > + struct regulator *regulator = *(struct regulator **)res;
> > + struct regulator_dev *rdev = regulator->rdev;
> > +
> > + if (rdev->exclusive && regulator->enable_count == 1)
> > + regulator_disable(regulator);
> > +
> > + regulator_put(regulator);
> > }
>
> There's no reason that exclusive consumers don't use the refcounting
> support...
I will need to move the refcounting handlingfor the exclusive regulator
at USB driver lvl.
The drivers/phy/renesas/phy-rcar-gen3-usb2.c is using
regulator_hardware_enable() for some USB otg channel. I think this is
the reason why I need this patch to handle multiple unbind/bind.
Without this I'm getting some WARN_ON(regulator->enable_count) doing
multiple unbind/bind.
I'm going to investigate on that and I need to find a solution at usb driver lvl.
Thanks again for your feedback!
Regards,
Tommaso
next prev parent reply other threads:[~2025-10-03 17:33 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 21:26 [PATCH 00/18] Add USB2.0 support for RZ/G3E Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 01/18] phy: renesas: rcar-gen3-usb2: Use devm_pm_runtime_enable() Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 02/18] phy: renesas: rcar-gen3-usb2: Factor out VBUS control logic Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 03/18] reset: rzv2h-usb2phy: Simplify pm_runtime driver handling Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-06 16:21 ` Philipp Zabel
2025-10-06 16:21 ` Philipp Zabel
2025-10-07 7:01 ` Tommaso Merciai
2025-10-07 7:01 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-06 16:31 ` Philipp Zabel
2025-10-06 16:31 ` Philipp Zabel
2025-10-07 4:02 ` Biju Das
2025-10-07 4:02 ` Biju Das
2025-10-07 9:44 ` Philipp Zabel
2025-10-07 9:44 ` Philipp Zabel
2025-10-07 11:04 ` Biju Das
2025-10-07 11:04 ` Biju Das
2025-10-07 14:13 ` Philipp Zabel
2025-10-07 14:13 ` Philipp Zabel
2025-10-07 15:20 ` Biju Das
2025-10-07 15:20 ` Biju Das
2025-10-01 21:26 ` [PATCH 05/18] dt-bindings: phy: renesas,usb2-phy: Document USB VBUS regulator Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 06/18] phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 07/18] regulator: devres: Disable exclusive regulator before releasing Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-02 16:29 ` Mark Brown
2025-10-02 16:29 ` Mark Brown
2025-10-03 17:33 ` Tommaso Merciai [this message]
2025-10-03 17:33 ` Tommaso Merciai
2025-10-06 11:52 ` Mark Brown
2025-10-06 11:52 ` Mark Brown
2025-10-06 12:53 ` Tommaso Merciai
2025-10-06 12:53 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 08/18] dt-bindings: clock: renesas,r9a09g047-cpg: Add USB2 PHY core clocks Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-09 13:48 ` Geert Uytterhoeven
2025-10-09 13:48 ` Geert Uytterhoeven
2025-10-01 21:26 ` [PATCH 09/18] clk: renesas: r9a09g047: Add clock and reset entries for USB2 Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-09 13:49 ` Geert Uytterhoeven
2025-10-09 13:49 ` Geert Uytterhoeven
2025-10-01 21:26 ` [PATCH 10/18] dt-bindings: usb: renesas,usbhs: Add RZ/G3E SoC support Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 11/18] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3E SoC Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 12/18] dt-bindings: reset: Document RZ/G3E USB2PHY reset Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 13/18] arm64: dts: renesas: r9a09g056: Add USB2.0 PHY VBUS internal regulator node Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 14/18] arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable USB2 PHY0 VBUS support Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 15/18] arm64: dts: renesas: r9a09g057: Add USB2.0 PHY VBUS internal regulator node Tommaso Merciai
2025-10-01 21:26 ` Tommaso Merciai
2025-10-01 21:27 ` [PATCH 16/18] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable USB2 PHY0 VBUS support Tommaso Merciai
2025-10-01 21:27 ` Tommaso Merciai
2025-10-01 21:27 ` [PATCH 17/18] arm64: dts: renesas: r9a09g047: Add USB2.0 support Tommaso Merciai
2025-10-01 21:27 ` Tommaso Merciai
2025-10-01 21:27 ` [PATCH 18/18] arm64: dts: renesas: r9a09g047e57-smarc: Enable " Tommaso Merciai
2025-10-01 21:27 ` Tommaso Merciai
2025-10-02 18:48 ` [PATCH 00/18] Add USB2.0 support for RZ/G3E Conor Dooley
2025-10-02 18:48 ` Conor Dooley
2025-10-03 10:03 ` Tommaso Merciai
2025-10-03 10:03 ` Tommaso Merciai
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=aOAI5cfA1HmEc7Rv@tom-desktop \
--to=tommaso.merciai.xr@bp.renesas.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=broonie@kernel.org \
--cc=geert+renesas@glider.be \
--cc=kishon@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=tomm.merciai@gmail.com \
--cc=vkoul@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.