linux-kernel - Re: [PATCH] driver-core: platform: automatically mark wakeup devices

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:	Mon, 18 Jan 2016 18:09:40 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Sudeep Holla <sudeep.holla@....com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	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 Mon, Jan 18, 2016 at 4:58 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>
>
> 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.

That plus PM on HW-reduced ACPI platforms where GPIOs can be used for
system wakeup in principle (although admittedly I have no experience
with such platforms, so this is just a theory).

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

We actually don't use _SxW to determine whether or not devices are
wakeup-capable.  We look at _PRW and we set "wakeup-capable" if it is
present and the contents is valid.

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

That said I'm actually quite unsure about the property suggested by
Dmitry, but let me reply to him on that. :-)

Thanks,
Rafael