On 2 January 2018 at 12:43, Rafael J. Wysocki wrote:
> On Tuesday, January 2, 2018 12:36:55 PM CET Ulf Hansson wrote:
>> On 30 December 2017 at 01:44, Rafael J. Wysocki wrote:
>> > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson
>> > wrote:
>> >> The PM core in the device_prepare() phase, resets
On Tuesday, January 2, 2018 12:36:55 PM CET Ulf Hansson wrote:
> On 30 December 2017 at 01:44, Rafael J. Wysocki wrote:
> > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson
> > wrote:
> >> The PM core in the device_prepare() phase, resets the wakeup_path status
> >> flag to the value of device_may_
On 30 December 2017 at 01:44, Rafael J. Wysocki wrote:
> On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson wrote:
>> The PM core in the device_prepare() phase, resets the wakeup_path status
>> flag to the value of device_may_wakeup(). This means if a ->prepare() or a
>> ->suspend() callback for the d
On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson wrote:
> The PM core in the device_prepare() phase, resets the wakeup_path status
> flag to the value of device_may_wakeup(). This means if a ->prepare() or a
> ->suspend() callback for the device would update the device's wakeup
> setting, this doesn'
The PM core in the device_prepare() phase, resets the wakeup_path status
flag to the value of device_may_wakeup(). This means if a ->prepare() or a
->suspend() callback for the device would update the device's wakeup
setting, this doesn't become reflected in the wakeup_path status flag.
In general
