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: <4FF5BAEE.3020403@wwwdotorg.org>
Date:	Thu, 05 Jul 2012 10:03:58 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Alex Courbot <acourbot@...dia.com>
CC:	Thierry Reding <thierry.reding@...onic-design.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"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 07/05/2012 02:12 AM, Alex Courbot wrote:
> On 07/05/2012 04:57 PM, Thierry Reding wrote:
>> I agree. Non-DT platforms have always used the callbacks to execute this
>> kind of code. As you've said before there are situations where it isn't
>> just about setting a GPIO or enabling a regulator but it also requires a
>> specific timing. Representing this in the platform data would become
>> tedious.
> 
> That will settle the whole issue then.
> 
>> So I think for the DT case you can parse the power-on and power-off
>> sequences directly and execute code based on it, while in non-DT cases
>> the init and exit callbacks should be used instead. I think it even
>> makes sense to reuse the platform data's init and exit functions in the
>> DT case and implement the parser/interpreter within those.
> 
> It totally makes sense indeed.

I don't agree here. It'd be best if non-DT and DT cases worked as
similarly as possible. Relying on callbacks in one case and
data-parsed-from-DT in the other isn't consistent with that. After all,
in the DT case, you parse some data out of the DT and into some data
structure. In the non-DT case, you can have that data structure passed
in directly using platform data. Now, there's certainly a need to
continue to support callbacks for backwards compatibility, at the very
least temporarily before all clients are converted to the new model, but
requiring different models rather than simply allowing it seems like a
bad idea to me.


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ