linux-kernel - Re: [RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm

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]

Message-ID: <529F4ED4.20500@linaro.org>
Date:	Wed, 04 Dec 2013 23:48:36 +0800
From:	Hanjun Guo <hanjun.guo@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Olof Johansson <olof@...om.net>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Jon Masters <jonathan@...masters.org>,
	"patches@...aro.org" <patches@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Al Stone <al.stone@...aro.org>,
	Graeme Gregory <graeme.gregory@...aro.org>,
	"Zheng, Lv" <lv.zheng@...el.com>
Subject: Re: [RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and
 its related head file

+CC Lv Zheng

On 2013年12月04日 02:03, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:36:49PM +0000, Hanjun Guo wrote:
>> introduce arm_core.c and its related head file, after this patch,
>> we can get ACPI tables from BIOS on ARM64 now.
>>
>> Signed-off-by: Al Stone <al.stone@...aro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@...aro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   57 +++++++++++
>>   arch/arm64/kernel/setup.c     |    8 ++
>>   drivers/acpi/Makefile         |    2 +
>>   drivers/acpi/plat/Makefile    |    1 +
>>   drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>>   5 files changed, 287 insertions(+)
>>   create mode 100644 drivers/acpi/plat/Makefile
>>   create mode 100644 drivers/acpi/plat/arm-core.c
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index c186f5b..e9444e4 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,43 @@
>>   #ifndef _ASM_ARM_ACPI_H
>>   #define _ASM_ARM_ACPI_H
>>   
>> +#include <asm/cacheflush.h>
>> +
>> +#include <linux/init.h>
>> +
>> +#define COMPILER_DEPENDENT_INT64	long long
>> +#define COMPILER_DEPENDENT_UINT64	unsigned long long
> Given we've already pulled in linux/init.h, which has pulled in
> linux/types.h, is there any reason we can't use s64 and u64 here?
>
> If we can, then why don't we unify this further up so each arch doesn't
> have to define this redundantly?

It make sense to me, I didn't notice that before, Lv, any comments about it?

>> +
>> +/*
>> + * Calling conventions:
>> + *
>> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
>> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
>> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
>> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
>> + */
>> +#define ACPI_SYSTEM_XFACE
>> +#define ACPI_EXTERNAL_XFACE
>> +#define ACPI_INTERNAL_XFACE
>> +#define ACPI_INTERNAL_VAR_XFACE
>> +
>> +/* Asm macros */
>> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> Can you elaborate on when ACPI needs to use this?

Mainly used in two cases:

1) system sleep, there are sleep states defined
in ACPI, such as S0, S1, S2, S3 and etc.
when system enter sleep states, flush cache is needed.

2) When CPU enter idle states deeper than C3.

Thanks
hanjun
--
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/