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]
Date:	Sat, 5 May 2012 13:15:56 +0800
From:	huang ying <huang.ying.caritas@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Huang Ying <ying.huang@...el.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, ming.m.lin@...el.com,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Zheng Yan <zheng.z.yan@...el.com>
Subject: Re: [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag

On Sat, May 5, 2012 at 3:37 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Friday, May 04, 2012, Huang Ying wrote:
>> The extreme way to save device power in runtime is to turn off power
>> of device.  For example, D3cold for PCIe bus and ZPODD (Zero Power
>> Optical Disk Drive) for SATA bus will do that.
>>
>> But sometimes power off is not expected, some possible reason is as
>> follow
>>
>> - power off device usually incurs longer resume latency, if it exceeds
>>   power QoS requirement, power off should be disabled.
>>
>> - For some buses, device in power off state can not support remote
>>   wakeup.  If remote wakeup is desired, power off should be disabled.
>>
>> In general, whether to put a device into power off state should be
>> decided by the driver of the device, but for some buses, whether to
>> put a device into power off state may be done by the parent of the
>> device.  For example, a PCIe end point device may be put into power
>> off state by the PCIe port connected to it.
>>
>> So a flag is introduced for the children devices to tell the parent
>> device, whether it should be put into power off state.
>>
>> This flag is also used for device driver to tell bus layer whether it
>> is OK to be powered off.
>>
>> Signed-off-by: Huang Ying <ying.huang@...el.com>
>
> I would be almost fine with this patch, if [2/5] were not present.
>
> However, if you introduce a flag like this, you need to put checks
> against it into all places where power may be removed from devices,
> like the generic PM domains framework (but not only there).

Yes.  At least this flag will be needed by other buses, like ZPODD
support from Lin Ming:

https://lkml.org/lkml/2012/3/28/23

So my original plan is to introduce this flag firstly, then to add
checking for this flag in various places need it.  Do you suggest to
put PCIe D3cold support, ZPODD support, power domain related checking
into one patchset.

Best Regards,
Huang Ying
--
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