diff mbox

ACPI: Execute the _PTS method when system reboot

Message ID 1462772495-71113-1-git-send-email-hehy1@lenovo.com (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Ocean HY1 He May 9, 2016, 5:50 a.m. UTC
The _PTS control method is defined in the section 7.4.1 of acpi 6.0
spec. The _PTS control method is executed by the OS during the sleep
transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
soft-off state) is passed to the _PTS control method. This method
is called after OSPM has notified native device drivers of the sleep
state transition and before the OSPM has had a chance to fully
prepare the system for a sleep state transition.

The _PTS control method provides the BIOS a mechanism for performing
some housekeeping, such as writing the sleep type value to the embedded
controller, before entering the system sleeping state.

According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.

Thus, a _PTS block notifier is added to the reboot notifier list so that
the _PTS object will also be evaluated when the system reboot.

Signed-off-by: Ocean He <hehy1@lenovo.com>
Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>
---
 drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

Comments

Rafael J. Wysocki June 21, 2016, 11:56 p.m. UTC | #1
On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:
> The _PTS control method is defined in the section 7.4.1 of acpi 6.0
> spec. The _PTS control method is executed by the OS during the sleep
> transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
> The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
> soft-off state) is passed to the _PTS control method. This method
> is called after OSPM has notified native device drivers of the sleep
> state transition and before the OSPM has had a chance to fully
> prepare the system for a sleep state transition.
> 
> The _PTS control method provides the BIOS a mechanism for performing
> some housekeeping, such as writing the sleep type value to the embedded
> controller, before entering the system sleeping state.
> 
> According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
> 
> Thus, a _PTS block notifier is added to the reboot notifier list so that
> the _PTS object will also be evaluated when the system reboot.

So I understand why it may be necessary to evaluate _PTS before entering S5,
but I'm totally unsure about reboot.

What does reboot have to do with S5?

> Signed-off-by: Ocean He <hehy1@lenovo.com>
> Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>
> ---
>  drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index 2a8b596..8b290fb 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {
>  	.priority	= 0,
>  };
>  
> +static int pts_notify_reboot(struct notifier_block *this,
> +			unsigned long code, void *x)
> +{
> +	acpi_status status;
> +
> +	status = acpi_execute_simple_method(NULL, "\\_PTS", ACPI_STATE_S5);
> +	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> +		/* It won't break anything. */
> +		printk(KERN_NOTICE "Failure in evaluating _PTS object\n");
> +	}
> +
> +	return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block pts_notifier = {
> +	.notifier_call	= pts_notify_reboot,
> +	.next		= NULL,
> +	.priority	= 0,
> +};
> +
>  static int acpi_sleep_prepare(u32 acpi_state)
>  {
>  #ifdef CONFIG_ACPI_SLEEP
> @@ -896,5 +916,12 @@ int __init acpi_sleep_init(void)
>  	 * object can also be evaluated when the system enters S5.
>  	 */
>  	register_reboot_notifier(&tts_notifier);
> +
> +	/*
> +	 * According to section 7.5 of acpi 6.0 spec, _PTS should run after
> +	 * _TTS when the system enters S5.
> +	 */
> +	register_reboot_notifier(&pts_notifier);

Why do you have to add a second notifier?

Why can't _TTS and _PTS be evaluated from one notifier?

> +
>  	return 0;
>  }
> 

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ocean HY1 He June 23, 2016, 12:55 p.m. UTC | #2
Hi Rafael,
Please see my reply in below.

Regards,
Ocean He
SW Development Dept. 
Beijing Design Center
Enterprise Product Group
Mobile: 18911778926
E-mail: hehy1@lenovo.com
No.6 Chuang Ye Road, Haidian District, Beijing, China 100085

> -----Original Message-----

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]

> Sent: Wednesday, June 22, 2016 7:56 AM

> To: Ocean HY1 He

> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;

> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar

> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system reboot

> 

> On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:

> > The _PTS control method is defined in the section 7.4.1 of acpi 6.0

> > spec. The _PTS control method is executed by the OS during the sleep

> > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.

> > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5

> > soft-off state) is passed to the _PTS control method. This method

> > is called after OSPM has notified native device drivers of the sleep

> > state transition and before the OSPM has had a chance to fully

> > prepare the system for a sleep state transition.

> >

> > The _PTS control method provides the BIOS a mechanism for performing

> > some housekeeping, such as writing the sleep type value to the

> embedded

> > controller, before entering the system sleeping state.

> >

> > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.

> >

> > Thus, a _PTS block notifier is added to the reboot notifier list so that

> > the _PTS object will also be evaluated when the system reboot.

> 

> So I understand why it may be necessary to evaluate _PTS before entering

> S5,

> but I'm totally unsure about reboot.

> 

> What does reboot have to do with S5?

> 

In ACPI spec, there is no explicit words saying _PTS should be 
executed when reboot. But reboot could be equal to the 
process S0->S5->S0. Thus _PTS should be executed when reboot.

I am thinking this is the same as _TTS. In ACPI spec, there is also
no explicit words saying _TTS should be executed when reboot.
But kernel executes _TTS when reboot indeed.

> > Signed-off-by: Ocean He <hehy1@lenovo.com>

> > Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>

> > ---

> >  drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++

> >  1 file changed, 27 insertions(+)

> >

> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c

> > index 2a8b596..8b290fb 100644

> > --- a/drivers/acpi/sleep.c

> > +++ b/drivers/acpi/sleep.c

> > @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {

> >  	.priority	= 0,

> >  };

> >

> > +static int pts_notify_reboot(struct notifier_block *this,

> > +			unsigned long code, void *x)

> > +{

> > +	acpi_status status;

> > +

> > +	status = acpi_execute_simple_method(NULL, "\\_PTS",

> ACPI_STATE_S5);

> > +	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {

> > +		/* It won't break anything. */

> > +		printk(KERN_NOTICE "Failure in evaluating _PTS object\n");

> > +	}

> > +

> > +	return NOTIFY_DONE;

> > +}

> > +

> > +static struct notifier_block pts_notifier = {

> > +	.notifier_call	= pts_notify_reboot,

> > +	.next		= NULL,

> > +	.priority	= 0,

> > +};

> > +

> >  static int acpi_sleep_prepare(u32 acpi_state)

> >  {

> >  #ifdef CONFIG_ACPI_SLEEP

> > @@ -896,5 +916,12 @@ int __init acpi_sleep_init(void)

> >  	 * object can also be evaluated when the system enters S5.

> >  	 */

> >  	register_reboot_notifier(&tts_notifier);

> > +

> > +	/*

> > +	 * According to section 7.5 of acpi 6.0 spec, _PTS should run after

> > +	 * _TTS when the system enters S5.

> > +	 */

> > +	register_reboot_notifier(&pts_notifier);

> 

> Why do you have to add a second notifier?

> 

> Why can't _TTS and _PTS be evaluated from one notifier?

> 

If execute _PTS method in tts_notify_reboot(), then it would break
definition of tts_notify_reboot(). My intention is to keep new codes 
has limited impact on existed codes.
Of course, it's possible to merge _TTS and _PTS into one unified notifier.
The advantage is more actions could be added into the unified notifier in future.
Which way you prefer?
> > +

> >  	return 0;

> >  }

> >

> 

> Thanks,

> Rafael
Rafael J. Wysocki June 23, 2016, 1:12 p.m. UTC | #3
On Thu, Jun 23, 2016 at 2:55 PM, Ocean HY1 He <hehy1@lenovo.com> wrote:
> Hi Rafael,
> Please see my reply in below.
>
> Regards,
> Ocean He
> SW Development Dept.
> Beijing Design Center
> Enterprise Product Group
> Mobile: 18911778926
> E-mail: hehy1@lenovo.com
> No.6 Chuang Ye Road, Haidian District, Beijing, China 100085
>
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
>> Sent: Wednesday, June 22, 2016 7:56 AM
>> To: Ocean HY1 He
>> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;
>> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar
>> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system reboot
>>
>> On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:
>> > The _PTS control method is defined in the section 7.4.1 of acpi 6.0
>> > spec. The _PTS control method is executed by the OS during the sleep
>> > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
>> > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
>> > soft-off state) is passed to the _PTS control method. This method
>> > is called after OSPM has notified native device drivers of the sleep
>> > state transition and before the OSPM has had a chance to fully
>> > prepare the system for a sleep state transition.
>> >
>> > The _PTS control method provides the BIOS a mechanism for performing
>> > some housekeeping, such as writing the sleep type value to the
>> embedded
>> > controller, before entering the system sleeping state.
>> >
>> > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
>> >
>> > Thus, a _PTS block notifier is added to the reboot notifier list so that
>> > the _PTS object will also be evaluated when the system reboot.
>>
>> So I understand why it may be necessary to evaluate _PTS before entering
>> S5,
>> but I'm totally unsure about reboot.
>>
>> What does reboot have to do with S5?
>>
> In ACPI spec, there is no explicit words saying _PTS should be
> executed when reboot. But reboot could be equal to the
> process S0->S5->S0.

Not in general.

In particular, wakeup devices that would be set up for S5 need not be
set up for that.  Also the mechanism by which transitions to S5 are
entered is different from the reboot one, at least from the OS
perspective.

> Thus _PTS should be executed when reboot.

No, it doesn't follow.

> I am thinking this is the same as _TTS. In ACPI spec, there is also
> no explicit words saying _TTS should be executed when reboot.
> But kernel executes _TTS when reboot indeed.

Yes, it does.  Maybe it shouldn't?

It may not hurt to call _PTS before reboot too, but is it guaranteed
to work across the board on all systems everywhere?

>> > Signed-off-by: Ocean He <hehy1@lenovo.com>
>> > Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>
>> > ---
>> >  drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++
>> >  1 file changed, 27 insertions(+)
>> >
>> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> > index 2a8b596..8b290fb 100644
>> > --- a/drivers/acpi/sleep.c
>> > +++ b/drivers/acpi/sleep.c
>> > @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {
>> >     .priority       = 0,
>> >  };
>> >
>> > +static int pts_notify_reboot(struct notifier_block *this,
>> > +                   unsigned long code, void *x)
>> > +{
>> > +   acpi_status status;
>> > +
>> > +   status = acpi_execute_simple_method(NULL, "\\_PTS",
>> ACPI_STATE_S5);
>> > +   if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
>> > +           /* It won't break anything. */
>> > +           printk(KERN_NOTICE "Failure in evaluating _PTS object\n");
>> > +   }
>> > +
>> > +   return NOTIFY_DONE;
>> > +}
>> > +
>> > +static struct notifier_block pts_notifier = {
>> > +   .notifier_call  = pts_notify_reboot,
>> > +   .next           = NULL,
>> > +   .priority       = 0,
>> > +};
>> > +
>> >  static int acpi_sleep_prepare(u32 acpi_state)
>> >  {
>> >  #ifdef CONFIG_ACPI_SLEEP
>> > @@ -896,5 +916,12 @@ int __init acpi_sleep_init(void)
>> >      * object can also be evaluated when the system enters S5.
>> >      */
>> >     register_reboot_notifier(&tts_notifier);
>> > +
>> > +   /*
>> > +    * According to section 7.5 of acpi 6.0 spec, _PTS should run after
>> > +    * _TTS when the system enters S5.
>> > +    */
>> > +   register_reboot_notifier(&pts_notifier);
>>
>> Why do you have to add a second notifier?
>>
>> Why can't _TTS and _PTS be evaluated from one notifier?
>>
> If execute _PTS method in tts_notify_reboot(), then it would break
> definition of tts_notify_reboot().

What exactly would it break?

> My intention is to keep new codes
> has limited impact on existed codes.

Even if that makes a little sense?

> Of course, it's possible to merge _TTS and _PTS into one unified notifier.
> The advantage is more actions could be added into the unified notifier in future.
> Which way you prefer?

I would just use one notifier.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lv Zheng June 24, 2016, 12:30 a.m. UTC | #4
SGksDQoNCj4gRnJvbTogbGludXgtYWNwaS1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzps
aW51eC1hY3BpLQ0KPiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBPY2VhbiBI
WTEgSGUNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gQUNQSTogRXhlY3V0ZSB0aGUgX1BUUyBtZXRo
b2Qgd2hlbiBzeXN0ZW0gcmVib290DQo+IA0KPiBIaSBSYWZhZWwsDQo+IFBsZWFzZSBzZWUgbXkg
cmVwbHkgaW4gYmVsb3cuDQo+IA0KPiBSZWdhcmRzLA0KPiBPY2VhbiBIZQ0KPiBTVyBEZXZlbG9w
bWVudCBEZXB0Lg0KPiBCZWlqaW5nIERlc2lnbiBDZW50ZXINCj4gRW50ZXJwcmlzZSBQcm9kdWN0
IEdyb3VwDQo+IE1vYmlsZTogMTg5MTE3Nzg5MjYNCj4gRS1tYWlsOiBoZWh5MUBsZW5vdm8uY29t
DQo+IE5vLjYgQ2h1YW5nIFllIFJvYWQsIEhhaWRpYW4gRGlzdHJpY3QsIEJlaWppbmcsIENoaW5h
IDEwMDA4NQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJh
ZmFlbCBKLiBXeXNvY2tpIFttYWlsdG86cmp3QHJqd3lzb2NraS5uZXRdDQo+ID4gU2VudDogV2Vk
bmVzZGF5LCBKdW5lIDIyLCAyMDE2IDc6NTYgQU0NCj4gPiBUbzogT2NlYW4gSFkxIEhlDQo+ID4g
Q2M6IGxlbmJAa2VybmVsLm9yZzsgbGludXgtYWNwaUB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gbGlu
dXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgRGF2aWQgVGFuYWthOyBOYWdhbmFuZGEgQ2h1bWJh
bGthcg0KPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIEFDUEk6IEV4ZWN1dGUgdGhlIF9QVFMgbWV0
aG9kIHdoZW4gc3lzdGVtDQo+IHJlYm9vdA0KPiA+DQo+ID4gT24gTW9uZGF5LCBNYXkgMDksIDIw
MTYgMDU6NTA6MTEgQU0gT2NlYW4gSFkxIEhlIHdyb3RlOg0KPiA+ID4gVGhlIF9QVFMgY29udHJv
bCBtZXRob2QgaXMgZGVmaW5lZCBpbiB0aGUgc2VjdGlvbiA3LjQuMSBvZiBhY3BpIDYuMA0KPiA+
ID4gc3BlYy4gVGhlIF9QVFMgY29udHJvbCBtZXRob2QgaXMgZXhlY3V0ZWQgYnkgdGhlIE9TIGR1
cmluZyB0aGUgc2xlZXANCj4gPiA+IHRyYW5zaXRpb24gcHJvY2VzcyBmb3IgUzEsIFMyLCBTMywg
UzQsIGFuZCBmb3Igb3JkZXJseSBTNSBzaHV0ZG93bi4NCj4gPiA+IFRoZSBzbGVlcGluZyBzdGF0
ZSB2YWx1ZSAoRm9yIGV4YW1wbGUsIDEsIDIsIDMsIDQgb3IgNSBmb3IgdGhlIFM1DQo+ID4gPiBz
b2Z0LW9mZiBzdGF0ZSkgaXMgcGFzc2VkIHRvIHRoZSBfUFRTIGNvbnRyb2wgbWV0aG9kLiBUaGlz
IG1ldGhvZA0KPiA+ID4gaXMgY2FsbGVkIGFmdGVyIE9TUE0gaGFzIG5vdGlmaWVkIG5hdGl2ZSBk
ZXZpY2UgZHJpdmVycyBvZiB0aGUgc2xlZXANCj4gPiA+IHN0YXRlIHRyYW5zaXRpb24gYW5kIGJl
Zm9yZSB0aGUgT1NQTSBoYXMgaGFkIGEgY2hhbmNlIHRvIGZ1bGx5DQo+ID4gPiBwcmVwYXJlIHRo
ZSBzeXN0ZW0gZm9yIGEgc2xlZXAgc3RhdGUgdHJhbnNpdGlvbi4NCj4gPiA+DQo+ID4gPiBUaGUg
X1BUUyBjb250cm9sIG1ldGhvZCBwcm92aWRlcyB0aGUgQklPUyBhIG1lY2hhbmlzbSBmb3INCj4g
cGVyZm9ybWluZw0KPiA+ID4gc29tZSBob3VzZWtlZXBpbmcsIHN1Y2ggYXMgd3JpdGluZyB0aGUg
c2xlZXAgdHlwZSB2YWx1ZSB0byB0aGUNCj4gPiBlbWJlZGRlZA0KPiA+ID4gY29udHJvbGxlciwg
YmVmb3JlIGVudGVyaW5nIHRoZSBzeXN0ZW0gc2xlZXBpbmcgc3RhdGUuDQo+ID4gPg0KPiA+ID4g
QWNjb3JkaW5nIHRvIHNlY3Rpb24gNy41IG9mIGFjcGkgNi4wIHNwZWMsIF9QVFMgc2hvdWxkIHJ1
biBhZnRlciBfVFRTLg0KPiA+ID4NCj4gPiA+IFRodXMsIGEgX1BUUyBibG9jayBub3RpZmllciBp
cyBhZGRlZCB0byB0aGUgcmVib290IG5vdGlmaWVyIGxpc3Qgc28gdGhhdA0KPiA+ID4gdGhlIF9Q
VFMgb2JqZWN0IHdpbGwgYWxzbyBiZSBldmFsdWF0ZWQgd2hlbiB0aGUgc3lzdGVtIHJlYm9vdC4N
Cj4gPg0KPiA+IFNvIEkgdW5kZXJzdGFuZCB3aHkgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBldmFs
dWF0ZSBfUFRTIGJlZm9yZQ0KPiBlbnRlcmluZw0KPiA+IFM1LA0KPiA+IGJ1dCBJJ20gdG90YWxs
eSB1bnN1cmUgYWJvdXQgcmVib290Lg0KPiA+DQo+ID4gV2hhdCBkb2VzIHJlYm9vdCBoYXZlIHRv
IGRvIHdpdGggUzU/DQo+ID4NCj4gSW4gQUNQSSBzcGVjLCB0aGVyZSBpcyBubyBleHBsaWNpdCB3
b3JkcyBzYXlpbmcgX1BUUyBzaG91bGQgYmUNCj4gZXhlY3V0ZWQgd2hlbiByZWJvb3QuIEJ1dCBy
ZWJvb3QgY291bGQgYmUgZXF1YWwgdG8gdGhlDQo+IHByb2Nlc3MgUzAtPlM1LT5TMC4gVGh1cyBf
UFRTIHNob3VsZCBiZSBleGVjdXRlZCB3aGVuIHJlYm9vdC4NCj4gDQo+IEkgYW0gdGhpbmtpbmcg
dGhpcyBpcyB0aGUgc2FtZSBhcyBfVFRTLiBJbiBBQ1BJIHNwZWMsIHRoZXJlIGlzIGFsc28NCj4g
bm8gZXhwbGljaXQgd29yZHMgc2F5aW5nIF9UVFMgc2hvdWxkIGJlIGV4ZWN1dGVkIHdoZW4gcmVi
b290Lg0KPiBCdXQga2VybmVsIGV4ZWN1dGVzIF9UVFMgd2hlbiByZWJvb3QgaW5kZWVkLg0KW0x2
IFpoZW5nXSANCldoYXQncyB0aGUgZGUtZmFjdG8gc3RhbmRhcmQgYmVoYXZpb3IgaGVyZT8NCkxl
bm92byBzaG91bGQgYmUgYWJsZSB0byBtb2RpZnkgQklPUywgc2hvdWxkIHlvdSB0cnkgdG8gYm9v
dCBkaWZmZXJlbnQgV2luZG93cyBjbG9uZXMgdG8gY29uZmlybSB0aGUgbmVjZXNzaXR5IG9mIGRv
aW5nIHRoaXM/DQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzDQotTHYNCg0KPiANCj4gPiA+IFNp
Z25lZC1vZmYtYnk6IE9jZWFuIEhlIDxoZWh5MUBsZW5vdm8uY29tPg0KPiA+ID4gU2lnbmVkLW9m
Zi1ieTogTmFnYW5hbmRhIENodW1iYWxrYXIgPG5jaHVtYmFsa2FyQGxlbm92by5jb20+DQo+ID4g
PiAtLS0NCj4gPiA+ICBkcml2ZXJzL2FjcGkvc2xlZXAuYyB8IDI3ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKw0KPiA+ID4gIDEgZmlsZSBjaGFuZ2VkLCAyNyBpbnNlcnRpb25zKCspDQo+ID4g
Pg0KPiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9zbGVlcC5jIGIvZHJpdmVycy9hY3Bp
L3NsZWVwLmMNCj4gPiA+IGluZGV4IDJhOGI1OTYuLjhiMjkwZmIgMTAwNjQ0DQo+ID4gPiAtLS0g
YS9kcml2ZXJzL2FjcGkvc2xlZXAuYw0KPiA+ID4gKysrIGIvZHJpdmVycy9hY3BpL3NsZWVwLmMN
Cj4gPiA+IEBAIC01NSw2ICs1NSwyNiBAQCBzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrIHR0
c19ub3RpZmllciA9IHsNCj4gPiA+ICAJLnByaW9yaXR5CT0gMCwNCj4gPiA+ICB9Ow0KPiA+ID4N
Cj4gPiA+ICtzdGF0aWMgaW50IHB0c19ub3RpZnlfcmVib290KHN0cnVjdCBub3RpZmllcl9ibG9j
ayAqdGhpcywNCj4gPiA+ICsJCQl1bnNpZ25lZCBsb25nIGNvZGUsIHZvaWQgKngpDQo+ID4gPiAr
ew0KPiA+ID4gKwlhY3BpX3N0YXR1cyBzdGF0dXM7DQo+ID4gPiArDQo+ID4gPiArCXN0YXR1cyA9
IGFjcGlfZXhlY3V0ZV9zaW1wbGVfbWV0aG9kKE5VTEwsICJcXF9QVFMiLA0KPiA+IEFDUElfU1RB
VEVfUzUpOw0KPiA+ID4gKwlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykgJiYgc3RhdHVzICE9IEFF
X05PVF9GT1VORCkgew0KPiA+ID4gKwkJLyogSXQgd29uJ3QgYnJlYWsgYW55dGhpbmcuICovDQo+
ID4gPiArCQlwcmludGsoS0VSTl9OT1RJQ0UgIkZhaWx1cmUgaW4gZXZhbHVhdGluZyBfUFRTIG9i
amVjdFxuIik7DQo+ID4gPiArCX0NCj4gPiA+ICsNCj4gPiA+ICsJcmV0dXJuIE5PVElGWV9ET05F
Ow0KPiA+ID4gK30NCj4gPiA+ICsNCj4gPiA+ICtzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2Nr
IHB0c19ub3RpZmllciA9IHsNCj4gPiA+ICsJLm5vdGlmaWVyX2NhbGwJPSBwdHNfbm90aWZ5X3Jl
Ym9vdCwNCj4gPiA+ICsJLm5leHQJCT0gTlVMTCwNCj4gPiA+ICsJLnByaW9yaXR5CT0gMCwNCj4g
PiA+ICt9Ow0KPiA+ID4gKw0KPiA+ID4gIHN0YXRpYyBpbnQgYWNwaV9zbGVlcF9wcmVwYXJlKHUz
MiBhY3BpX3N0YXRlKQ0KPiA+ID4gIHsNCj4gPiA+ICAjaWZkZWYgQ09ORklHX0FDUElfU0xFRVAN
Cj4gPiA+IEBAIC04OTYsNSArOTE2LDEyIEBAIGludCBfX2luaXQgYWNwaV9zbGVlcF9pbml0KHZv
aWQpDQo+ID4gPiAgCSAqIG9iamVjdCBjYW4gYWxzbyBiZSBldmFsdWF0ZWQgd2hlbiB0aGUgc3lz
dGVtIGVudGVycyBTNS4NCj4gPiA+ICAJICovDQo+ID4gPiAgCXJlZ2lzdGVyX3JlYm9vdF9ub3Rp
ZmllcigmdHRzX25vdGlmaWVyKTsNCj4gPiA+ICsNCj4gPiA+ICsJLyoNCj4gPiA+ICsJICogQWNj
b3JkaW5nIHRvIHNlY3Rpb24gNy41IG9mIGFjcGkgNi4wIHNwZWMsIF9QVFMgc2hvdWxkIHJ1biBh
ZnRlcg0KPiA+ID4gKwkgKiBfVFRTIHdoZW4gdGhlIHN5c3RlbSBlbnRlcnMgUzUuDQo+ID4gPiAr
CSAqLw0KPiA+ID4gKwlyZWdpc3Rlcl9yZWJvb3Rfbm90aWZpZXIoJnB0c19ub3RpZmllcik7DQo+
ID4NCj4gPiBXaHkgZG8geW91IGhhdmUgdG8gYWRkIGEgc2Vjb25kIG5vdGlmaWVyPw0KPiA+DQo+
ID4gV2h5IGNhbid0IF9UVFMgYW5kIF9QVFMgYmUgZXZhbHVhdGVkIGZyb20gb25lIG5vdGlmaWVy
Pw0KPiA+DQo+IElmIGV4ZWN1dGUgX1BUUyBtZXRob2QgaW4gdHRzX25vdGlmeV9yZWJvb3QoKSwg
dGhlbiBpdCB3b3VsZCBicmVhaw0KPiBkZWZpbml0aW9uIG9mIHR0c19ub3RpZnlfcmVib290KCku
IE15IGludGVudGlvbiBpcyB0byBrZWVwIG5ldyBjb2Rlcw0KPiBoYXMgbGltaXRlZCBpbXBhY3Qg
b24gZXhpc3RlZCBjb2Rlcy4NCj4gT2YgY291cnNlLCBpdCdzIHBvc3NpYmxlIHRvIG1lcmdlIF9U
VFMgYW5kIF9QVFMgaW50byBvbmUgdW5pZmllZCBub3RpZmllci4NCj4gVGhlIGFkdmFudGFnZSBp
cyBtb3JlIGFjdGlvbnMgY291bGQgYmUgYWRkZWQgaW50byB0aGUgdW5pZmllZCBub3RpZmllciBp
bg0KPiBmdXR1cmUuDQo+IFdoaWNoIHdheSB5b3UgcHJlZmVyPw0KPiA+ID4gKw0KPiA+ID4gIAly
ZXR1cm4gMDsNCj4gPiA+ICB9DQo+ID4gPg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFJhZmFlbA0K
PiANCj4gE++/ve+/vey5uxzvv70m77+9fu+/vSbvv70Y77+977+9Ky0NCj4g77+977+93bYX77+9
77+9d++/ve+/vcub77+977+977+9be+/vWLvv73vv71acu+/ve+/ve+/ve+/vV5u77+9cu+/ve+/
ve+/vXrvv70a77+977+9aO+/ve+/ve+/ve+/vSbvv73vv70e77+9R++/ve+/ve+/vWjvv70DKO+/
vemajg0KPiDvv73domoi77+977+9Gu+/vRtt77+977+977+977+977+9eu+/vd6W77+977+977+9
Zu+/ve+/ve+/vWjvv73vv73vv71+77+9be+/vQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ocean HY1 He June 24, 2016, 2:06 a.m. UTC | #5
Regards,
Ocean He
SW Development Dept. 
Beijing Design Center
Enterprise Product Group
Mobile: 18911778926
E-mail: hehy1@lenovo.com
No.6 Chuang Ye Road, Haidian District, Beijing, China 100085

> -----Original Message-----

> From: Zheng, Lv [mailto:lv.zheng@intel.com]

> Sent: Friday, June 24, 2016 8:30 AM

> To: Ocean HY1 He; Rafael J. Wysocki

> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;

> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar

> Subject: RE: [PATCH] ACPI: Execute the _PTS method when system reboot

> 

> Hi,

> 

> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-

> > owner@vger.kernel.org] On Behalf Of Ocean HY1 He

> > Subject: RE: [PATCH] ACPI: Execute the _PTS method when system

> reboot

> >

> > Hi Rafael,

> > Please see my reply in below.

> >

> > Regards,

> > Ocean He

> > SW Development Dept.

> > Beijing Design Center

> > Enterprise Product Group

> > Mobile: 18911778926

> > E-mail: hehy1@lenovo.com

> > No.6 Chuang Ye Road, Haidian District, Beijing, China 100085

> >

> > > -----Original Message-----

> > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]

> > > Sent: Wednesday, June 22, 2016 7:56 AM

> > > To: Ocean HY1 He

> > > Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;

> > > linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar

> > > Subject: Re: [PATCH] ACPI: Execute the _PTS method when system

> > reboot

> > >

> > > On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:

> > > > The _PTS control method is defined in the section 7.4.1 of acpi 6.0

> > > > spec. The _PTS control method is executed by the OS during the

> sleep

> > > > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.

> > > > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5

> > > > soft-off state) is passed to the _PTS control method. This method

> > > > is called after OSPM has notified native device drivers of the sleep

> > > > state transition and before the OSPM has had a chance to fully

> > > > prepare the system for a sleep state transition.

> > > >

> > > > The _PTS control method provides the BIOS a mechanism for

> > performing

> > > > some housekeeping, such as writing the sleep type value to the

> > > embedded

> > > > controller, before entering the system sleeping state.

> > > >

> > > > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.

> > > >

> > > > Thus, a _PTS block notifier is added to the reboot notifier list so that

> > > > the _PTS object will also be evaluated when the system reboot.

> > >

> > > So I understand why it may be necessary to evaluate _PTS before

> > entering

> > > S5,

> > > but I'm totally unsure about reboot.

> > >

> > > What does reboot have to do with S5?

> > >

> > In ACPI spec, there is no explicit words saying _PTS should be

> > executed when reboot. But reboot could be equal to the

> > process S0->S5->S0. Thus _PTS should be executed when reboot.

> >

> > I am thinking this is the same as _TTS. In ACPI spec, there is also

> > no explicit words saying _TTS should be executed when reboot.

> > But kernel executes _TTS when reboot indeed.

> [Lv Zheng]

> What's the de-facto standard behavior here?

> Lenovo should be able to modify BIOS, should you try to boot different

> Windows clones to confirm the necessity of doing this?

> 

> Thanks and best regards

> -Lv

> 

I have consulted Lenovo UEFI/BIOS archtect, David Tanaka. He says
the de-facto standard behavior is that _PTS should be executed when reboot,
at least for Windows. Windows does not differentiate OS reboot and shutdown.

And, our test on Windows shows _PTS is executed when reboot actually.

I try to find the difference between OS reboot and shutdown(S5) in ACPI spec,
but I cann't find the answer. So, in my mind I consider reboot equals S0->S5->S0.
Maybe you have evidence shows they are different, please let me know. It would
help me a lot. Thanks.

Ocean.
> >

> > > > Signed-off-by: Ocean He <hehy1@lenovo.com>

> > > > Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>

> > > > ---

> > > >  drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++

> > > >  1 file changed, 27 insertions(+)

> > > >

> > > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c

> > > > index 2a8b596..8b290fb 100644

> > > > --- a/drivers/acpi/sleep.c

> > > > +++ b/drivers/acpi/sleep.c

> > > > @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {

> > > >  	.priority	= 0,

> > > >  };

> > > >

> > > > +static int pts_notify_reboot(struct notifier_block *this,

> > > > +			unsigned long code, void *x)

> > > > +{

> > > > +	acpi_status status;

> > > > +

> > > > +	status = acpi_execute_simple_method(NULL, "\\_PTS",

> > > ACPI_STATE_S5);

> > > > +	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {

> > > > +		/* It won't break anything. */

> > > > +		printk(KERN_NOTICE "Failure in evaluating _PTS object\n");

> > > > +	}

> > > > +

> > > > +	return NOTIFY_DONE;

> > > > +}

> > > > +

> > > > +static struct notifier_block pts_notifier = {

> > > > +	.notifier_call	= pts_notify_reboot,

> > > > +	.next		= NULL,

> > > > +	.priority	= 0,

> > > > +};

> > > > +

> > > >  static int acpi_sleep_prepare(u32 acpi_state)

> > > >  {

> > > >  #ifdef CONFIG_ACPI_SLEEP

> > > > @@ -896,5 +916,12 @@ int __init acpi_sleep_init(void)

> > > >  	 * object can also be evaluated when the system enters S5.

> > > >  	 */

> > > >  	register_reboot_notifier(&tts_notifier);

> > > > +

> > > > +	/*

> > > > +	 * According to section 7.5 of acpi 6.0 spec, _PTS should run after

> > > > +	 * _TTS when the system enters S5.

> > > > +	 */

> > > > +	register_reboot_notifier(&pts_notifier);

> > >

> > > Why do you have to add a second notifier?

> > >

> > > Why can't _TTS and _PTS be evaluated from one notifier?

> > >

> > If execute _PTS method in tts_notify_reboot(), then it would break

> > definition of tts_notify_reboot(). My intention is to keep new codes

> > has limited impact on existed codes.

> > Of course, it's possible to merge _TTS and _PTS into one unified notifier.

> > The advantage is more actions could be added into the unified notifier

> in

> > future.

> > Which way you prefer?

> > > > +

> > > >  	return 0;

> > > >  }

> > > >

> > >

> > > Thanks,

> > > Rafael

> >

> > ��칻�&�~�&���+-

> >

> ��ݶ��w��˛���m�b��Zr����^n�r���z���h����&���G���h�(�

> 階

> > �ݢj"���m�����z�ޖ���f���h���~�m�
Ocean HY1 He June 24, 2016, 2:59 a.m. UTC | #6
Regards,
Ocean He
SW Development Dept. 
Beijing Design Center
Enterprise Product Group
Mobile: 18911778926
E-mail: hehy1@lenovo.com
No.6 Chuang Ye Road, Haidian District, Beijing, China 100085


> -----Original Message-----

> From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of

> Rafael J. Wysocki

> Sent: Thursday, June 23, 2016 9:13 PM

> To: Ocean HY1 He

> Cc: Rafael J. Wysocki; lenb@kernel.org; linux-acpi@vger.kernel.org;

> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar

> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system reboot

> 

> On Thu, Jun 23, 2016 at 2:55 PM, Ocean HY1 He <hehy1@lenovo.com>

> wrote:

> > Hi Rafael,

> > Please see my reply in below.

> >

> > Regards,

> > Ocean He

> > SW Development Dept.

> > Beijing Design Center

> > Enterprise Product Group

> > Mobile: 18911778926

> > E-mail: hehy1@lenovo.com

> > No.6 Chuang Ye Road, Haidian District, Beijing, China 100085

> >

> >> -----Original Message-----

> >> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]

> >> Sent: Wednesday, June 22, 2016 7:56 AM

> >> To: Ocean HY1 He

> >> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;

> >> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar

> >> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system

> reboot

> >>

> >> On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:

> >> > The _PTS control method is defined in the section 7.4.1 of acpi 6.0

> >> > spec. The _PTS control method is executed by the OS during the sleep

> >> > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.

> >> > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5

> >> > soft-off state) is passed to the _PTS control method. This method

> >> > is called after OSPM has notified native device drivers of the sleep

> >> > state transition and before the OSPM has had a chance to fully

> >> > prepare the system for a sleep state transition.

> >> >

> >> > The _PTS control method provides the BIOS a mechanism for

> performing

> >> > some housekeeping, such as writing the sleep type value to the

> >> embedded

> >> > controller, before entering the system sleeping state.

> >> >

> >> > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.

> >> >

> >> > Thus, a _PTS block notifier is added to the reboot notifier list so that

> >> > the _PTS object will also be evaluated when the system reboot.

> >>

> >> So I understand why it may be necessary to evaluate _PTS before

> entering

> >> S5,

> >> but I'm totally unsure about reboot.

> >>

> >> What does reboot have to do with S5?

> >>

> > In ACPI spec, there is no explicit words saying _PTS should be

> > executed when reboot. But reboot could be equal to the

> > process S0->S5->S0.

> 

> Not in general.

> 

> In particular, wakeup devices that would be set up for S5 need not be

> set up for that.  Also the mechanism by which transitions to S5 are

> entered is different from the reboot one, at least from the OS

> perspective.

> 

> > Thus _PTS should be executed when reboot.

> 

> No, it doesn't follow.

> 

> > I am thinking this is the same as _TTS. In ACPI spec, there is also

> > no explicit words saying _TTS should be executed when reboot.

> > But kernel executes _TTS when reboot indeed.

> 

> Yes, it does.  Maybe it shouldn't?

> 

> It may not hurt to call _PTS before reboot too, but is it guaranteed

> to work across the board on all systems everywhere?

> 

I try to clarify the key point of this case: does devices should go to S5(shutdown) when reboot?

I think the answer is yes. 
And It has no hurt to let devices go to S5 before reboot is invoked, here is the reasons:
#1 The new _PTS codes block nothing thus reboot can be guaranteed to be invoked eventually.
#2. Devices are mandatory to support S5 state, this means go to S5 could be a safe trip.
#3 Reboot would cause devices re-initialization from the scratch.

What's your decision then? ;-)

Regards,
Ocean.

> >> > Signed-off-by: Ocean He <hehy1@lenovo.com>

> >> > Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>

> >> > ---

> >> >  drivers/acpi/sleep.c | 27 +++++++++++++++++++++++++++

> >> >  1 file changed, 27 insertions(+)

> >> >

> >> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c

> >> > index 2a8b596..8b290fb 100644

> >> > --- a/drivers/acpi/sleep.c

> >> > +++ b/drivers/acpi/sleep.c

> >> > @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {

> >> >     .priority       = 0,

> >> >  };

> >> >

> >> > +static int pts_notify_reboot(struct notifier_block *this,

> >> > +                   unsigned long code, void *x)

> >> > +{

> >> > +   acpi_status status;

> >> > +

> >> > +   status = acpi_execute_simple_method(NULL, "\\_PTS",

> >> ACPI_STATE_S5);

> >> > +   if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {

> >> > +           /* It won't break anything. */

> >> > +           printk(KERN_NOTICE "Failure in evaluating _PTS

> object\n");

> >> > +   }

> >> > +

> >> > +   return NOTIFY_DONE;

> >> > +}

> >> > +

> >> > +static struct notifier_block pts_notifier = {

> >> > +   .notifier_call  = pts_notify_reboot,

> >> > +   .next           = NULL,

> >> > +   .priority       = 0,

> >> > +};

> >> > +

> >> >  static int acpi_sleep_prepare(u32 acpi_state)

> >> >  {

> >> >  #ifdef CONFIG_ACPI_SLEEP

> >> > @@ -896,5 +916,12 @@ int __init acpi_sleep_init(void)

> >> >      * object can also be evaluated when the system enters S5.

> >> >      */

> >> >     register_reboot_notifier(&tts_notifier);

> >> > +

> >> > +   /*

> >> > +    * According to section 7.5 of acpi 6.0 spec, _PTS should run

> after

> >> > +    * _TTS when the system enters S5.

> >> > +    */

> >> > +   register_reboot_notifier(&pts_notifier);

> >>

> >> Why do you have to add a second notifier?

> >>

> >> Why can't _TTS and _PTS be evaluated from one notifier?

> >>

> > If execute _PTS method in tts_notify_reboot(), then it would break

> > definition of tts_notify_reboot().

> 

> What exactly would it break?

> 

> > My intention is to keep new codes

> > has limited impact on existed codes.

> 

> Even if that makes a little sense?

> 

> > Of course, it's possible to merge _TTS and _PTS into one unified notifier.

> > The advantage is more actions could be added into the unified notifier

> in future.

> > Which way you prefer?

> 

> I would just use one notifier.

I follow you.
> 

> Thanks,

> Rafael
Rafael J. Wysocki June 24, 2016, 12:36 p.m. UTC | #7
On Friday, June 24, 2016 02:59:24 AM Ocean HY1 He wrote:
> 
> Regards,
> Ocean He
> SW Development Dept. 
> Beijing Design Center
> Enterprise Product Group
> Mobile: 18911778926
> E-mail: hehy1@lenovo.com
> No.6 Chuang Ye Road, Haidian District, Beijing, China 100085
> 
> 
> > -----Original Message-----
> > From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of
> > Rafael J. Wysocki
> > Sent: Thursday, June 23, 2016 9:13 PM
> > To: Ocean HY1 He
> > Cc: Rafael J. Wysocki; lenb@kernel.org; linux-acpi@vger.kernel.org;
> > linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar
> > Subject: Re: [PATCH] ACPI: Execute the _PTS method when system reboot
> > 
> > On Thu, Jun 23, 2016 at 2:55 PM, Ocean HY1 He <hehy1@lenovo.com>
> > wrote:
> > > Hi Rafael,
> > > Please see my reply in below.
> > >
> > > Regards,
> > > Ocean He
> > > SW Development Dept.
> > > Beijing Design Center
> > > Enterprise Product Group
> > > Mobile: 18911778926
> > > E-mail: hehy1@lenovo.com
> > > No.6 Chuang Ye Road, Haidian District, Beijing, China 100085
> > >
> > >> -----Original Message-----
> > >> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > >> Sent: Wednesday, June 22, 2016 7:56 AM
> > >> To: Ocean HY1 He
> > >> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org;
> > >> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar
> > >> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system
> > reboot
> > >>
> > >> On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:
> > >> > The _PTS control method is defined in the section 7.4.1 of acpi 6.0
> > >> > spec. The _PTS control method is executed by the OS during the sleep
> > >> > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
> > >> > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
> > >> > soft-off state) is passed to the _PTS control method. This method
> > >> > is called after OSPM has notified native device drivers of the sleep
> > >> > state transition and before the OSPM has had a chance to fully
> > >> > prepare the system for a sleep state transition.
> > >> >
> > >> > The _PTS control method provides the BIOS a mechanism for
> > performing
> > >> > some housekeeping, such as writing the sleep type value to the
> > >> embedded
> > >> > controller, before entering the system sleeping state.
> > >> >
> > >> > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
> > >> >
> > >> > Thus, a _PTS block notifier is added to the reboot notifier list so that
> > >> > the _PTS object will also be evaluated when the system reboot.
> > >>
> > >> So I understand why it may be necessary to evaluate _PTS before
> > entering
> > >> S5,
> > >> but I'm totally unsure about reboot.
> > >>
> > >> What does reboot have to do with S5?
> > >>
> > > In ACPI spec, there is no explicit words saying _PTS should be
> > > executed when reboot. But reboot could be equal to the
> > > process S0->S5->S0.
> > 
> > Not in general.
> > 
> > In particular, wakeup devices that would be set up for S5 need not be
> > set up for that.  Also the mechanism by which transitions to S5 are
> > entered is different from the reboot one, at least from the OS
> > perspective.
> > 
> > > Thus _PTS should be executed when reboot.
> > 
> > No, it doesn't follow.
> > 
> > > I am thinking this is the same as _TTS. In ACPI spec, there is also
> > > no explicit words saying _TTS should be executed when reboot.
> > > But kernel executes _TTS when reboot indeed.
> > 
> > Yes, it does.  Maybe it shouldn't?
> > 
> > It may not hurt to call _PTS before reboot too, but is it guaranteed
> > to work across the board on all systems everywhere?
> > 
> I try to clarify the key point of this case: does devices should go to S5(shutdown) when reboot?
> 
> I think the answer is yes. 
> And It has no hurt to let devices go to S5 before reboot is invoked, here is the reasons:

S5 is a platform (system) state, not a device state.

You seem to be confusing platforms with devices.

> #1 The new _PTS codes block nothing thus reboot can be guaranteed to be invoked eventually.
> #2. Devices are mandatory to support S5 state, this means go to S5 could be a safe trip.
> #3 Reboot would cause devices re-initialization from the scratch.
> 
> What's your decision then? ;-)

I guess you can argue that since _TTS is already executed in the reboot
path, it might be good to execute _PTS in that path too and that might help
to avoid issues in some cases.

That is a reasonable argument, but then there still is the question if that
is not going to break anything.

I guess that cannot be answered without trying, so the simplest patch would
be to add a _PTS evaulation to the existing notifier (and maybe change the
notifiers name to reflect the fact that it's not for _TTS ony any more).

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 2a8b596..8b290fb 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -55,6 +55,26 @@  static struct notifier_block tts_notifier = {
 	.priority	= 0,
 };
 
+static int pts_notify_reboot(struct notifier_block *this,
+			unsigned long code, void *x)
+{
+	acpi_status status;
+
+	status = acpi_execute_simple_method(NULL, "\\_PTS", ACPI_STATE_S5);
+	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+		/* It won't break anything. */
+		printk(KERN_NOTICE "Failure in evaluating _PTS object\n");
+	}
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block pts_notifier = {
+	.notifier_call	= pts_notify_reboot,
+	.next		= NULL,
+	.priority	= 0,
+};
+
 static int acpi_sleep_prepare(u32 acpi_state)
 {
 #ifdef CONFIG_ACPI_SLEEP
@@ -896,5 +916,12 @@  int __init acpi_sleep_init(void)
 	 * object can also be evaluated when the system enters S5.
 	 */
 	register_reboot_notifier(&tts_notifier);
+
+	/*
+	 * According to section 7.5 of acpi 6.0 spec, _PTS should run after
+	 * _TTS when the system enters S5.
+	 */
+	register_reboot_notifier(&pts_notifier);
+
 	return 0;
 }