lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aOAI5cfA1HmEc7Rv@tom-desktop>
Date: Fri, 3 Oct 2025 19:33:25 +0200
From: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>
To: Mark Brown <broonie@...nel.org>
Cc: tomm.merciai@...il.com, linux-renesas-soc@...r.kernel.org,
	biju.das.jz@...renesas.com,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>, linux-phy@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/18] regulator: devres: Disable exclusive regulator
 before releasing

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ