linux-kernel - Re: [PATCH] regulator: core: use correct device for device supply lookup

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]

Date:	Sat, 19 May 2012 19:26:59 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	"lrg@...com" <lrg@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: core: use correct device for device supply
 lookup

On Sat, May 19, 2012 at 11:26:00PM +0530, Laxman Dewangan wrote:

> At the time of registration,  as becasue there is valid
> reg_desc->supply_name and hence it tries to lookup the entry for
> <name>-supply i.e. v2-supply in this case for getting regulator_dev.
> regulator_register() {

> static struct regulator_dev *regulator_dev_lookup(struct device *dev,
>                                                   const char *supply,
>                                                   int *ret)
> {
>         /* first do a dt based lookup */
> ----> Checked here, dev is not null but dev->of_node is null.
>         if (dev && dev->of_node) {
> 
> ------------>The issue is that I am not getting here as dev->node is
> null here.

But how is this related your patch?  What your patch does is change
things so that instead of trying to look up the supply in the context of
whatever device was passed in by the driver we try to look it up in the
context of the class device we create.  I can't think of any situation
where I'd expect that to make matters any better - the class device
should certainly never appear in the device tree and isn't going to have
a stable name for non-DT systems either.

I'm just not seeing any problem in the core here.  It sounds to me like
the problem might be either with the regulator driver doing something
odd with the struct device it specifies when registering the regulator
(though I'm guessing that it's the tps65910 which looks to be doing
something sensible currently) or the device tree for the board being
odd.  Looking at the changes you posted to tps65910 I suspect the issue
is that you've changed the driver to pass in the platform device for the
regulators as their device rather than the I2C device but it's the I2C
device which appears in the device tree bindings.

If there is a change needed in the core you need to explain what you
believe that change will do.

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