linux-kernel - Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences

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: <1347518544.7471.36.camel@lappyti>
Date:	Thu, 13 Sep 2012 09:42:24 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Alex Courbot <acourbot@...dia.com>
Cc:	Stephen Warren <swarren@...dia.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Simon Glass <sjg@...omium.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Anton Vorontsov <cbou@...l.ru>,
	David Woodhouse <dwmw2@...radead.org>,
	Arnd Bergmann <arnd@...db.de>,
	Leela Krishna Amudala <l.krishna@...sung.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>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences

On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote:

> > I want to reiterate my opinion that I think power sequences in DT data
> > is the wrong way to go. Powering sequences are device specific issues
> > and should be handled in the device driver. But I also think that power
> > sequences inside the drivers would probably be useful.
> 
> I understand the logic behind handling powering sequences in the device 
> driver, but as we discussed for some classes of devices this might just not 
> scale. I don't know how many different panels (each with different powering 
> sequences) are relying on pwm_backlight, but the alternative of embedding 
> support for all of them into the kernel (and bloating the kernel image) or 
> having a 3 kilometers list in the kernel configuration to individually chose 
> which panel to support (which would be cumbersome and make the kernel less 
> portable across boards) does not look much appealing to me. With power 
> sequences encoded in the DT, we could have one .dtsi file per panel that would 
> be included from the board's .dts file - no bloat, no drivers explosion, 
> portability preserved.

Yes, I see that side of the argument also. And to be honest, I don't
know what kind of data is DT supposed to contain (or if there even is a
strict definition for that).

I have my opinion because I think that's how things should be: DT tells
us what devices there are and how they connect, and the driver handles
the rest. I may be a perfectionist, though, which is not good =).

As for the kernel bloat, it's a valid issue, but I wonder if it would be
an issue in practice. I don't know how many different supported devices
we'd have, and how many bytes the data for each device would consume.
I'm not even sure what amount of bytes would be acceptable.

But I'm guessing that we wouldn't have very many devices, and if the per
device data is made compact there wouldn't be that many bytes per
device. And with non-hotpluggable platform devices the unused device
data could be discarded after init.

Anyway, having the power sequences doesn't affect me if I don't use
them, so I have nothing against them =).

> DT support is actually the main point of power sequences, as outside of the DT 
> we can always work the old way and use callbacks. If we were to remove DT 
> support, I am not sure this work would still be worth being merged.

We can't use board callbacks when running with a DT enabled kernel. What
I meant is that the driver could contain a power sequence for the device
(or multiple supported devices). So it'd essentially be the same as
getting the power sequence from the DT data.

But I haven't looked at the power sequence data structures, so I'm not
sure if they are geared for DT use. If so, they would probably need
tuning to be good for in-kernel use.

 Tomi

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