linux-kernel - Re: [PATCH] pwm-backlight: add regulator and GPIO support

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: <20120705103922.GO4111@opensource.wolfsonmicro.com>
Date:	Thu, 5 Jul 2012 11:39:22 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alex Courbot <acourbot@...dia.com>
Cc:	Sascha Hauer <s.hauer@...gutronix.de>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH] pwm-backlight: add regulator and GPIO support

On Thu, Jul 05, 2012 at 04:43:27PM +0900, Alex Courbot wrote:

> One could actually question whether the whole regulator/gpio thing
> should be supported at all with platform data. The platform
> interface can use the function hooks in order to implement whatever
> behavior it wants when the light needs to be powered on and off. The
> reason for introducing optional regulator/gpio parameters is because
> the DT cannot use these. Since I have no plan to remove these
> function hooks, making the regulator/gpio option available in
> platform data might be redundant. Any thought about this?

Well, no - it's also done because even if you're not using device tree
(as on most of the architectures we support...) it's not good to have to
cut'n'paste code everywhere.  This means that we want to be able to
provide things like GPIOs and regulators via data which means we have
exactly the same situation as we do with device tree.

> >Right now the regulator core will just return -EPROBE_DEFER in both
> >cases. This could easily be changed in the regulator core.

> Could this be because the regulator core cannot make the difference
> between a not-yet-available regulator and a missing one?

Yes.

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