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: <569D0BC2.8050602@arm.com>
Date:	Mon, 18 Jan 2016 15:58:58 +0000
From:	Sudeep Holla <sudeep.holla@....com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Sudeep Holla <sudeep.holla@....com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <robh@...nel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Thierry Reding <treding@...dia.com>,
	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
	open list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] driver-core: platform: automatically mark wakeup devices



On 18/01/16 15:41, Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 03:23:18 PM Sudeep Holla wrote:
>> On Mon, Jan 18, 2016 at 2:47 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>> On Sunday, January 17, 2016 06:11:38 PM Dmitry Torokhov wrote:
>>>> When probing platform drivers let's check if corresponding devices have
>>>> "wakeup-source" property defined (either in device tree, ACPI, or static
>>>> platform properties) and automatically enable such devices as wakeup
>>>> sources for the system. This will help us standardize on the name for this
>>>> property and reduce amount of boilerplate code in the drivers.
>>>
>>> ACPI has other ways of telling the OS that the device is wakeup-capable,
>>> but I guess the property in question can be used too (as long as it is
>>> consistent with the other methods).
>>>
>>
>> Just curious to know what you mean when you say this property can also
>> be used with ACPI. Do you mean we could use "wakeup-source" DSD ?
>
> Yes.
>
>> If so, won't that go against rule for DSD (i.e we *should not* bypass the
>> existing mechanisms defined by the ACPI, e.g. _SxW in this case)
>
> Not necessarily.
>
> What if the device doesn't use ACPI PM and still can wake up the system?
>

May be I don't understand the exact configuration you are referring, but
if you don't use ACPI PM, how will that system enter sleep states ?
IIUC you are referring suspend-to-idle case only here which doesn't
require any ACPI _Sx methods, which make sense.

But still I don't see a strong reason to provide an alternate method to
specify the same information. Firmware responsible for ACPI tables have
to specify this DSD in question, instead it can use the existing
mechanism in ACPI.

Let me know if I am missing some information about the systems you are
referring ?

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ