linux-kernel - Re: [PATCH] regulator: core: Fix resolve supply

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZzTOWoTT2to6aW5g@finisterre.sirena.org.uk>
Date: Wed, 13 Nov 2024 16:05:46 +0000
From: Mark Brown <broonie@...nel.org>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: Bjorn Andersson <andersson@...nel.org>, linux-kernel@...r.kernel.org,
	thomas.petazzoni@...tlin.com, Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH] regulator: core: Fix resolve supply

On Wed, Nov 13, 2024 at 04:36:14PM +0100, Kory Maincent wrote:

> The regulator should not use the device parent to resolve the regulator
> supply. It fails to resolve the correct supply when the of_node
> variable in the regulator_config structure is not within the parent
> node.

I can't understand what you are saying here at all.  What is "it", why
and in what way does it fail and why would we expect it to succeed?  How
does your proposed change fix whatever the issue is?  The DT binding is
against the actual device, not the virtual device.  Please describe both
the problem and the fix more specifically.

> Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")

>  static int regulator_resolve_supply(struct regulator_dev *rdev)
>  {
>  	struct regulator_dev *r;
> -	struct device *dev = rdev->dev.parent;
> +	struct device *dev = &rdev->dev;

The rdev is a virtual device, it's not going to have any OF
configuration, and given that prior to the refactoring in the commit
you're referencing in the Fixes: we were using the struct device passed
into regulator_register() which should be the same device as we're using
here so if there is an issue it doesn't look like it was introduced in
the refactoring.  What makes you believe that there is an issue in htat
commit?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)