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: <526A0E71.100@nvidia.com>
Date:	Fri, 25 Oct 2013 15:23:45 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	NeilBrown <neilb@...e.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thierry Reding <thierry.reding@...onic-design.de>
Subject: Re: Any news on Runtime Interpreted Power Sequences

Hi Neil,

On 10/25/2013 09:22 AM, NeilBrown wrote:
>   I'm wondering if there was any news on the Runtime Interpreted Power
> Sequences?
> The most recent news I can find is
>    https://lkml.org/lkml/2013/4/27/73
> where you say they might be ready for 3.11.  Clearly that didn't work
> (predictions being hard, especially about the future).
>
> I'm really keen to see them turning into a reality and I gather others are
> too. So ... can we hope?

A prerequisite of power sequences was to merge the gpiod interface, and 
this is finally happening. It took much longer than I wanted, sorry 
about that.

Logically speaking nothing should now stand in the way of a new version 
of the power sequences. Expected maybe my own skepticism about them.

The first version of the power seqs is mainly the result of my 
misunderstanding of the device tree. Reconsidering it now, if we strip 
the DT support away power seqs would just become a simplified way to 
describe how to power a device up and down. In other words, it would be 
another way to express what can be expressed with C code and would not 
bring any additional flexibility that DT-described power seqs would have 
(and I say this totally convinced now that power sequences in the device 
tree were a bad idea).

The advantage I could see is that using power sequences we could get rid 
of the cumbersome and mistake-prone error checking code which is 
basically the same for most devices. You would just need to describe 
what you want to activate, and in which order, and the power seqs 
framework would catch and report any error.

I'm not sure if this is a sufficient reason to introduce another 
framework into the kernel, but if this is deemed a good reason by more 
experienced people then I'm ok to give it a shot. If you have other 
motivations for this, please also state them so I can get the whole 
picture. Maybe I just need to be a little bit more motivated about this 
idea myself. :)

Thanks,
Alex.

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