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

Date:	Tue, 26 Apr 2011 16:15:23 -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:

On Tue, Apr 26, 2011 at 11:15 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
>
> No.  As I said in the text you've quoted above you can also specify the
> device mapping using the dev_name() of the device.

Aah!  I see it now--- the regulator_consumer_supply structure will
take either the consumer's struct device pointer, or the device name
of the consumer's struct device.  The device name can easily be
predicted (controlled, in fact) before the consumer itself is
registered; in the case of i2c devices, it's the bus-id, i.e.
"0-0038".

Now it all fits together for me.  Thanks for your patience!

> It means you get reams of code in drivers conditionally using the
> regulator API, all of which adds needless complexity all over the tree
> as people invariably make everything conditional on the regulator not
> being there when they shouldn't.  This then means you also end up with
> no meaningful error handling, all errors just get silently eaten.

Now I think I see your point: better to have drivers check the result
of regulator_get() themselves, rather than test a pointer coming in
with the platform data.  And since regulators are often registered as
platform devices themselves, there is no way to get a valid result
from regulator_get() in early-init board code anyway.

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/