linux-kernel - Re: Expose regulator:set_consumer_device

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: <BANLkTimmpx5ZThXj705Yn_wRQ6bF7VzwPw@mail.gmail.com>
Date:	Tue, 26 Apr 2011 10:33:29 -0500
From:	Bill Gatliff <bgat@...lgatliff.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-embedded@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Expose regulator:set_consumer_device_supply()?

Mark:

Thanks for the response.  But now I'm even more confused than I was before!

On Tue, Apr 26, 2011 at 3:33 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:

> You can specify the device by either dev_name() or a dev pointer.  You
> can use dev_name() at any time without the device having been
> instantiated, it would be unusal to use a struct device.

When a consumer e.g. i2c chip driver is trying to get a handle for its
own regulator, the only function I see is:

struct regulator* regulator_get(struct device *dev, const char *id)

My understanding, even after looking at the implementation of
regulator_get(), is that the dev pointer refers to the device
structure of the consumer itself.  The regulator returned is one that
matches the combination of that device structure pointer plus the name
of the regulator.  In other words, I get back the regulator that is
unambiguously associated with the consumer.

In order for there to be a regulator with a matching device:id
combination, someone must have previously provided a struct
regulator_consumer_supply with the identical device pointer to
regulator_register().  That means that I have to call
regulator_register() AFTER I register the i2c chip driver, so that I
have a struct device pointer to place in the regulator_consumer_supply
list.  Right?

The alternative is to not indicate any regulator_consumer_supply
devices when I register a regulator, and then do the regulator_get()
by matching on name alone.  But then I have to pass the regulator name
as platform data to the i2c chip driver, because that regulator's name
is bound to change across boards.  And I also lose the strong
relationship between regulators and their downstream devices that
regulator_consumer_supply offers.  If I can keep that association,
then consumers need only ask for "the regulator tied to my VCC pin,
whatever regulator that is".

Maybe I'm misunderstanding the utility of the dev pointer in regulator_get()?

>> Any reason why we couldn't expose set_consumer_device_supply(), so
>> that I can add a device as a regulator consumer after a regulator is
>> already registered?
>
> This would facilitate abuse of the API, we already have enough problems
> with people trying to pass regulators as platform data.

But I think you'll agree that regulators are pretty important platform data, no?

What specifically is the breakage that comes from allowing consumers
to add themselves to regulator consumer lists at a time after
regulator_register() is complete?  Why is passing a regulator pointer
as platform data such a problem?

Confused,

b.g.
-- 
Bill Gatliff
bgat@...lgatliff.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/