Xen devel - Jun 2013 - [PATCH v3 2/3] x86/tboot: Fail extended mode reduced hardware sleep

As tboot currently does not support the reduced hardware sleep
interface, fail this extended call.

Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: tboot-devel@lists.sourceforge.net
Cc: Gang Wei <gang.wei@intel.com>
---
 arch/x86/kernel/tboot.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index f84fe00..016fbb8 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct acpi_table_fadt
*fadt)
 		offsetof(struct acpi_table_facs, firmware_waking_vector);
 }
 
-static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
+static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control,
+		       u8 extended)
 {
 	static u32 acpi_shutdown_map[ACPI_S_STATE_COUNT] = {
 		/* S0,1,2: */ -1, -1, -1,
@@ -284,6 +285,9 @@ static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32
pm1b_control)
 	if (!tboot_enabled())
 		return 0;
 
+	if (extended)
+		return -1;
+
 	tboot_copy_fadt(&acpi_gbl_FADT);
 	tboot->acpi_sinfo.pm1a_cnt_val = pm1a_control;
 	tboot->acpi_sinfo.pm1b_cnt_val = pm1b_control;
-- 
1.7.9.5

>>> On 26.06.13 at 16:06, Ben Guthro <benjamin.guthro@citrix.com>
wrote:
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct
acpi_table_fadt *fadt)
>  		offsetof(struct acpi_table_facs, firmware_waking_vector);
>  }
>  
> -static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
> +static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control,
> +		       u8 extended)
I don''t see why this couldn''t remain "bool" - the
only complain was
that ACPI CA shouldn''t use it.

Jan

On Wed, Jun 26, 2013 at 10:44 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>> On 26.06.13 at 16:06, Ben Guthro
<benjamin.guthro@citrix.com> wrote:
>> --- a/arch/x86/kernel/tboot.c
>> +++ b/arch/x86/kernel/tboot.c
>> @@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct
acpi_table_fadt *fadt)
>>               offsetof(struct acpi_table_facs, firmware_waking_vector);
>>  }
>>
>> -static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32
pm1b_control)
>> +static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32
pm1b_control,
>> +                    u8 extended)
>
> I don''t see why this couldn''t remain "bool" -
the only complain was
> that ACPI CA shouldn''t use it.
>
> Jan
I changed it, in order to keep the prototypes consistent.
Having the function pointer be defined with one signature in the
acpica code, and another in the os implementation seems like a
maintenance problem.

Ben
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

>>> On 26.06.13 at 16:55, Ben Guthro <benjamin.guthro@citrix.com>
wrote:
> On Wed, Jun 26, 2013 at 10:44 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>>> On 26.06.13 at 16:06, Ben Guthro
<benjamin.guthro@citrix.com> wrote:
>>> --- a/arch/x86/kernel/tboot.c
>>> +++ b/arch/x86/kernel/tboot.c
>>> @@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct
acpi_table_fadt
> *fadt)
>>>               offsetof(struct acpi_table_facs,
firmware_waking_vector);
>>>  }
>>>
>>> -static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32
pm1b_control)
>>> +static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32
pm1b_control,
>>> +                    u8 extended)
>>
>> I don''t see why this couldn''t remain "bool"
- the only complain was
>> that ACPI CA shouldn''t use it.
> 
> I changed it, in order to keep the prototypes consistent.
> Having the function pointer be defined with one signature in the
> acpica code, and another in the os implementation seems like a
> maintenance problem.
Of course the first patch would need adjustments too: The function
pointer would also want to use bool then. Again - it''s only the ACPI
CA code that wants to get away without using bool/true/false.

Jan