linux-kernel - RE: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3)

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:	Wed, 29 Aug 2007 09:54:43 -0700
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"ACPI Devel Maling List" <linux-acpi@...r.kernel.org>,
	"Len Brown" <lenb@...nel.org>,
	"LKML" <linux-kernel@...r.kernel.org>,
	"Pavel Machek" <pavel@....cz>,
	"pm list" <linux-pm@...ts.linux-foundation.org>
Subject: RE: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3)

No, it's not safe to run the AML interpreter with interrupts disabled.

I don't have any problem with introducing finer granularity enter/exit
sleep interfaces if they are required.

I would suggest that we rename things a bit however.

Currently:
acpi_enter_sleep_state_prep
acpi_enter_sleep_state_prep_late
acpi_enter_sleep_state

acpi_leave_sleep_state_prep
acpi_leave_sleep_state

I think we can truncate and clarify:

acpi_sleep_setup1
acpi_sleep_setup2
acpi_sleep

acpi_wake_setup1
acpi_wake

acpi_set_sleep_state_indicator:

I'm not sure if we have any external interfaces that simply execute a
control method, seems like overkill.

Please give me more information as to why _SSI needs to be moved (other
than executing it after _BFS)

Thanks,
Bob

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@...k.pl] 
Sent: Tuesday, August 28, 2007 3:05 PM
To: Moore, Robert
Cc: Andrew Morton; ACPI Devel Maling List; Len Brown; LKML; Pavel
Machek; pm list
Subject: Re: [PATCH -mm 3/3] PM: Improve handling of ACPI system state
indicator (rev. 3)

On Tuesday, 28 August 2007 21:57, Moore, Robert wrote:
> Since these changes appear to affect the ACPICA core in a fairly big
> way, I would like to see a short, concise description of each change
and
> why it is necessary.

All right.  I'll describe the changes made by the current version of the
patches, but please note that if it's safe to run the AML interpreter
with
IRQs disabled, it's better to do some of them in a different way.

1. Remove the execution of _GTS from acpi_enter_sleep_state_prep()

	acpi_enter_sleep_state_prep() is called before disabling the
nonboot
	CPUs and _GTS should be executed after that, according to the
spec.

2. Introduce acpi_enter_sleep_state_prep_late() that will execute _GTS

	Necessary because of 1.

3. Split acpi_leave_sleep_state() into two functions:
   acpi_leave_sleep_state_prep() and acpi_leave_sleep_state().

	acpi_leave_sleep_state_prep() contains the code that should be
executed
	before enabling the nonboot CPUs, most importantly the execution
of
	_BFS, and acpi_leave_sleep_state() contains the remaining code
(the
	enabling of GPEs, the execution of _WAK and the enabling of
power
	buttons)

4. Change the code ordering in acpi_leave_sleep_state_prep() (introduced
   in 3.) so that _SST is executed after _BFS

	According to the spec, _BFS should be the first ACPI method
executed
	after leaving a sleep state

5. Introduce acpi_set_sleep_state_indicator() that will execute _SST for
given
   ACPI sleep state

	Needed so that we can set the state indicator independently of
the
	other lower-level operations.

6. Remove the execution of _SST from acpi_leave_sleep_state()

	No longer needed, because we can use
acpi_set_sleep_state_indicator()
	to set the state indicator appropriately from higher level
routines.

The other changes affect only drivers/acpi/sleep/main.c and the files in
kernel/power .

Greetings,
Rafael
-
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/