Re: [Devel] [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
by Zheng, Lv
Hi,
> From: Yisheng Xie [mailto:xieyisheng1@huawei.com]
> Sent: Tuesday, October 18, 2016 4:47 AM
> To: Zheng, Lv <lv.zheng(a)intel.com>; Moore, Robert <robert.moore(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>; lenb(a)kernel.org; wmiles(a)sgl.com
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; guohanjun(a)huawei.com;
> wangxiongfeng2(a)huawei.com
> Subject: Re: [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
>
> Hi, Lv
>
> On 2016/10/18 6:26, Zheng, Lv wrote:
> > Hi, Yisheng
> >
> >> From: Yisheng Xie [mailto:xieyisheng1@huawei.com]
> >> Subject: [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
> >>
> >> when try to cross compile acpi tool in dir kernel/tools
> >> for arm64 use command:
> >> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- acpi
> >> it failed with the following log:
> >> In file included
> >> from ../../../../../include/acpi/acpi.h:58:0,
> >> from ../../../../../drivers/acpi/acpica/utstring.c:44:
> >> ../../../../../include/acpi/actypes.h:130:34: error: conflicting types for 's64'
> >> typedef signed long long s64;
> >> ^
> >> In file included
> >> from /opt/aarch64-linux-gnu/libc/usr/include/asm-generic/types.h:6:0
> >> from /opt/aarch64-linux-gnu/libc/usr/include/asm/types.h:1,
> >> from ../../../../../include/uapi/linux/types.h:4,
> >> from ../../../../../include/linux/types.h:5,
> >> from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19,
> >> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> >> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> >> from ../../../../../include/acpi/platform/acenv.h:365,
> >> from ../../../../../include/acpi/acpi.h:56,
> >> from ./acpidump.h:55,
> >> from ../../os_specific/service_layers/oslinuxtbl.c:44:
> >> ../../../../../include/asm-generic/int-ll64.h:24:26: note: previous declaration of 's64' was here
> >> typedef signed long long s64;
> >> ^
> >> Fix this compile problem.
> >
> > This looks like a conflict between asm-generic/int-ll64.h and actypes.h.
> >
> > When a build environment actually has s64 definition.
> > ACPICA shouldn't define it.
> > ACPICA should define ACPI_USE_SYSTEM_INTTYPES instead.
> >
> > However it is not clear if a Linux userspace should be aware of s64.
> > We couldn't see this issue in other arch builds.
> > So I wonder if this is just a missing "#ifdef __KERNEL__" in asm-generic/int-ll64.h.
> >
> > If Linux should be aware of s64.
> > Then ACPICA definition of s64 should be disabled by defining ACPI_USE_SYSTEM_INTTYPES.
> > Since this is a post-ACPICA-release issue.
> > You should only fix it in tools/power/acpi/Makefile*.
> >
> > So I think this patch is not a right fix, but a wrong workaround.
> > It can easily cause regressions in other ACPICA builds.
> >
> Thank you for your reply.
> You are right that the ACPI_USE_SYSTEM_INTTYPES in Makefile can fixed compile error,
I'm not sure what you mean.
I mean you need ACPI_USE_SYSTEM_INTTYPES in case s64 has already been defined in that environment.
Are you sure s64 should be defined for your environment?
IMO, s64 is kernel space specific, while you are compiling user space tools.
It looks to me like there is something wrong with ARM kernel's asm/types.h.
> I listed in change log. And I also have tried that way.
> However, it still have many other errors.(I am sorry to not have listed all of them.)
>
> From the following log, you can see, all of the conflict type is from signal.h.
> And maybe this patch is a better way to fix these compile error, without too much
> change of code.
>
> Are you sure that it will cause order problem when build ACPICA on other build
> environment, for it only effect aarch64.
>
> Thanks
> Yisheng.
>
> ----------detail compile error log---------
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:14:26: error: conflicting types for 'fd_set'
> typedef __kernel_fd_set fd_set;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:219:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/select.h:75:5: note: previous declaration of 'fd_set' was
> here
> } fd_set;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:15:25: error: conflicting types for 'dev_t'
> typedef __kernel_dev_t dev_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314:0,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:60:17: note: previous declaration of 'dev_t' was
> here
> typedef __dev_t dev_t;
> ^
> ...
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:25:26: error: conflicting types for 'timer_t'
> typedef __kernel_timer_t timer_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:132:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/time.h:103:19: note: previous declaration of 'timer_t' was
> here
> typedef __timer_t timer_t;
> ^
> ...
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:45:26: error: conflicting types for 'loff_t'
> typedef __kernel_loff_t loff_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314:0,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:44:18: note: previous declaration of 'loff_t' was
> here
> typedef __loff_t loff_t;
> ^
> ...
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:112:17: error: conflicting types for 'u_int64_t'
> typedef __u64 u_int64_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314:0,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:203:1: note: previous declaration of 'u_int64_t'
> was here
> __u_intN_t (64, __DI__);
> ^
> ...
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:113:17: error: conflicting types for 'int64_t'
> typedef __s64 int64_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314:0,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:197:1: note: previous declaration of 'int64_t' was
> here
> __intN_t (64, __DI__);
> ^
> ...
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> ../../../../../include/linux/types.h:134:23: error: conflicting types for 'blkcnt_t'
> typedef unsigned long blkcnt_t;
> ^
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314:0,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/tbprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:235:20: note: previous declaration of 'blkcnt_t'
> was here
> typedef __blkcnt_t blkcnt_t; /* Type to count number of disk blocks. */
> ^
>
>
>
>
> In file included from /opt/aarch64-linux-gnu/libc/usr/include/sys/types.h:219:0,
> from /opt/aarch64-linux-gnu/libc/usr/include/stdlib.h:314,
> from ../../../../../include/acpi/platform/acenv.h:357,
> from ../../../../../include/acpi/acpi.h:56,
> from acpidbg.c:12:
> acpidbg.c: In function 'acpi_aml_set_fd':
> ../../../../../drivers/acpi/acpica/utprint.c:352:5: error: conflicting types for 'vsnprintf'
> int vsnprintf(char *string, acpi_size size, const char *format, va_list args)
> ^
> ...
> In file included from ../../../../../include/acpi/platform/acenv.h:361:0,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/utprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/stdio.h:390:12: note: previous declaration of 'vsnprintf' was
> here
> extern int vsnprintf (char *__restrict __s, size_t __maxlen,
> ^
> ....
> ../../../../../drivers/acpi/acpica/utprint.c:599:5: error: conflicting types for 'snprintf'
> int snprintf(char *string, acpi_size size, const char *format, ...)
> ^
>
> In file included from ../../../../../include/acpi/platform/acenv.h:361:0,
> from ../../../../../include/acpi/acpi.h:56,
> from ../../../../../drivers/acpi/acpica/utprint.c:44:
> /opt/aarch64-linux-gnu/libc/usr/include/stdio.h:386:12: note: previous declaration of 'snprintf' was
> here
> extern int snprintf (char *__restrict __s, size_t __maxlen,
> ^
> ...
> acpidbg.c:303:25: warning: passing argument 2 of 'select' from incompatible pointer type [-
> Wincompatible-pointer-types]
> ret = select(maxfd+1, &rfds, &wfds, NULL, &tv);
> ^
> ....
> acpidbg.c:309:8: error: 'fd_set {aka struct <anonymous>}' has no member named '__fds_bits'
> if (FD_ISSET(STDIN_FILENO, &rfds))
> ^
> make[2]: *** [utprint.o] Error 1
> acpidbg.c:311:8: error: 'fd_set {aka struct <anonymous>}' has no member named '__fds_bits'
> if (FD_ISSET(fd, &wfds)) {
> ^
> acpidbg.c:317:8: error: 'fd_set {aka struct <anonymous>}' has no member named '__fds_bits'
> if (FD_ISSET(fd, &rfds)) {
> ^
> acpidbg.c:323:8: error: 'fd_set {aka struct <anonymous>}' has no member named '__fds_bits'
> if (FD_ISSET(STDOUT_FILENO, &wfds)) {
> ^
I'm not sure what this is.
How did you get this?
Were you compiling kernel acpi tools or compiling the kernel itself?
For tool compilation, are you sure you have correctly configured your cross-compilation environment?
Will you see problems in compiling ACPICA applications from:
https://github.com/acpica/acpica
Thanks
Lv
5 years, 9 months
Re: [Devel] [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
by Hanjun Guo
On 2016/10/8 5:31, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchrounous External
> Abort) notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into the SEA exception handler. That way GHES will parse and report
> SEA exceptions when they occur.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang(a)codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar(a)codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje(a)codeaurora.org>
> ---
> arch/arm64/Kconfig | 1 +
> drivers/acpi/apei/Kconfig | 15 +++++++++
> drivers/acpi/apei/ghes.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 99 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b380c87..ae34349 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -53,6 +53,7 @@ config ARM64
> select HANDLE_DOMAIN_IRQ
> select HARDIRQS_SW_RESEND
> select HAVE_ACPI_APEI if (ACPI && EFI)
> + select HAVE_ACPI_APEI_SEA if (ACPI && EFI)
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
> index b0140c8..fb99c1c 100644
> --- a/drivers/acpi/apei/Kconfig
> +++ b/drivers/acpi/apei/Kconfig
> @@ -4,6 +4,21 @@ config HAVE_ACPI_APEI
> config HAVE_ACPI_APEI_NMI
> bool
>
> +config HAVE_ACPI_APEI_SEA
> + bool "APEI Synchronous External Abort logging/recovering support"
> + depends on ARM64
> + help
> + This option should be enabled if the system supports
> + firmware first handling of SEA (Synchronous External Abort).
> + SEA happens with certain faults of data abort or instruction
> + abort synchronous exceptions on ARMv8 systems. If a system
> + supports firmware first handling of SEA, the platform analyzes
> + and handles hardware error notifications with SEA, and it may then
> + form a HW error record for the OS to parse and handle. This
> + option allows the OS to look for such HW error record, and
> + take appropriate action.
OK, I can see that it's firmware first handling, so it's triggered
by firmware to me, correct me if I'm wrong.
[...]
> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
> /*
> * printk is not safe in NMI context. So in NMI handler, we allocate
> @@ -1023,6 +1083,14 @@ static int ghes_probe(struct platform_device *ghes_dev)
> case ACPI_HEST_NOTIFY_EXTERNAL:
> case ACPI_HEST_NOTIFY_SCI:
> break;
> + case ACPI_HEST_NOTIFY_SEA:
> + if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_SEA)) {
> + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
> + generic->header.source_id);
> + rc = -ENOTSUPP;
> + goto err;
> + }
> + break;
> case ACPI_HEST_NOTIFY_NMI:
> if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
> pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
> @@ -1034,6 +1102,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
> pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
> generic->header.source_id);
> goto err;
> + case ACPI_HEST_NOTIFY_GPIO:
> + case ACPI_HEST_NOTIFY_SEI:
> + case ACPI_HEST_NOTIFY_GSIV:
> + pr_warn(GHES_PFX "Generic hardware error source: %d notified via notification type %u is not supported\n",
> + generic->header.source_id, generic->header.source_id);
Hmm, some platform may trigger a interrupt to OS for firmware handling
and it's in the ACPI 6.1 spec, is it a limitation now, or we need to
add code later to support it?
Thanks
Hanjun
5 years, 9 months
Re: [Devel] [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
by Hanjun Guo
Hi Tyler,
On 2016/10/8 5:31, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchrounous External
> Abort) notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into the SEA exception handler. That way GHES will parse and report
> SEA exceptions when they occur.
Does this SEA is replayed by the firmware (firmware first handling)
or directly triggered by the hardware when error is happened?
Thanks
Hanjun
5 years, 9 months
Re: [Devel] [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
by Zheng, Lv
Hi, Yisheng
> From: Yisheng Xie [mailto:xieyisheng1@huawei.com]
> Subject: [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
>
> when try to cross compile acpi tool in dir kernel/tools
> for arm64 use command:
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- acpi
> it failed with the following log:
> In file included
> from ../../../../../include/acpi/acpi.h:58:0,
> from ../../../../../drivers/acpi/acpica/utstring.c:44:
> ../../../../../include/acpi/actypes.h:130:34: error: conflicting types for 's64'
> typedef signed long long s64;
> ^
> In file included
> from /opt/aarch64-linux-gnu/libc/usr/include/asm-generic/types.h:6:0
> from /opt/aarch64-linux-gnu/libc/usr/include/asm/types.h:1,
> from ../../../../../include/uapi/linux/types.h:4,
> from ../../../../../include/linux/types.h:5,
> from /opt/aarch64-linux-gnu/libc/usr/include/asm/sigcontext.h:19,
> from /opt/aarch64-linux-gnu/libc/usr/include/bits/sigcontext.h:27,
> from /opt/aarch64-linux-gnu/libc/usr/include/signal.h:308,
> from ../../../../../include/acpi/platform/acenv.h:365,
> from ../../../../../include/acpi/acpi.h:56,
> from ./acpidump.h:55,
> from ../../os_specific/service_layers/oslinuxtbl.c:44:
> ../../../../../include/asm-generic/int-ll64.h:24:26: note: previous declaration of 's64' was here
> typedef signed long long s64;
> ^
> Fix this compile problem.
This looks like a conflict between asm-generic/int-ll64.h and actypes.h.
When a build environment actually has s64 definition.
ACPICA shouldn't define it.
ACPICA should define ACPI_USE_SYSTEM_INTTYPES instead.
However it is not clear if a Linux userspace should be aware of s64.
We couldn't see this issue in other arch builds.
So I wonder if this is just a missing "#ifdef __KERNEL__" in asm-generic/int-ll64.h.
If Linux should be aware of s64.
Then ACPICA definition of s64 should be disabled by defining ACPI_USE_SYSTEM_INTTYPES.
Since this is a post-ACPICA-release issue.
You should only fix it in tools/power/acpi/Makefile*.
So I think this patch is not a right fix, but a wrong workaround.
It can easily cause regressions in other ACPICA builds.
>
> Fixes: e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h> inclusion order issue")
> Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
> ---
> include/acpi/platform/acenv.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
> index 34cce72..0089fa0 100644
> --- a/include/acpi/platform/acenv.h
> +++ b/include/acpi/platform/acenv.h
> @@ -361,9 +361,13 @@
> #include <stdio.h>
> #include <fcntl.h>
> #include <errno.h>
> +#ifdef __aarch64__
> +#include <sys/stat.h>
> +#else
> #include <time.h>
> #include <signal.h>
> #endif
> +#endif
>
> #endif /* ACPI_USE_STANDARD_HEADERS */
We shouldn't rely on inclusion orders to fix this issue.
It can easily cause order problem on other ACPICA build environment.
Thanks
Lv
5 years, 9 months
Re: [Devel] [PATCH] ACPICA: Avoid return Access Size error with PCC Register
by Moore, Robert
Things sometimes take a bit of time for testing/validation before we make commits.
That said, your patch is now committed.
Thanks,
Bob
From: Hoan Tran [mailto:hotran@apm.com]
Sent: Monday, October 10, 2016 10:42 AM
To: Moore, Robert <robert.moore(a)intel.com>
Cc: devel(a)acpica.org; Loc Ho <lho(a)apm.com>
Subject: Re: [PATCH] ACPICA: Avoid return Access Size error with PCC Register
Hi Moore,
I would like to check the status of my patch as I haven't seen it on https://github.com/acpica/acpica/commits/master yet.
Thanks and Regards
Hoan
On Wed, Oct 5, 2016 at 7:10 AM, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
This looks OK. We'll integrate it for the next release of ACPICA later this month. I'll commit it today.
Thanks,
Bob
> -----Original Message-----
> From: Hoan Tran [mailto:hotran@apm.com<mailto:hotran@apm.com>]
> Sent: Monday, October 3, 2016 1:39 PM
> To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>; devel(a)acpica.org<mailto:devel@acpica.org>
> Cc: Loc Ho <lho(a)apm.com<mailto:lho@apm.com>>; Hoan Tran <hotran(a)apm.com<mailto:hotran@apm.com>>
> Subject: Re: [PATCH] ACPICA: Avoid return Access Size error with PCC
> Register
>
> Correct devel acpica email (devel(a)acpica.org<mailto:devel@acpica.org>)
>
> Thanks
> Hoan
>
> On Mon, Oct 3, 2016 at 10:59 AM, Hoan Tran <hotran(a)apm.com<mailto:hotran@apm.com>> wrote:
> > Based on section "14.5 Referencing the PCC address space" of ACPI
> > 6.1 specification, an individual register may be referenced in a
> > Generic Register Descriptor by using the Address Space ID PCC (0xA).
> > When using the PCC address space, the Access Size field is redefined
> > to PCC Subspace ID.
> >
> > This patch avoids iasl return Access Size error with PCC register when
> > its value is over 4.
> >
> > Signed-off-by: Hoan Tran <hotran(a)apm.com<mailto:hotran@apm.com>>
> > ---
> > source/compiler/aslrestype2.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/source/compiler/aslrestype2.c
> > b/source/compiler/aslrestype2.c index 9fc77b0..cbec1b3 100644
> > --- a/source/compiler/aslrestype2.c
> > +++ b/source/compiler/aslrestype2.c
> > @@ -199,6 +199,11 @@ RsDoGeneralRegisterDescriptor (
> > RsCreateByteField (InitializerOp, ACPI_RESTAG_ACCESSSIZE,
> > CurrentByteOffset + ASL_RESDESC_OFFSET
> > (GenericReg.AccessSize));
> >
> > + if (Descriptor->GenericReg.AddressSpaceId ==
> ACPI_ADR_SPACE_PLATFORM_COMM)
> > + {
> > + break;
> > + }
> > +
> > if (Descriptor->GenericReg.AccessSize >
> AML_FIELD_ACCESS_QWORD)
> > {
> > AslError (ASL_ERROR, ASL_MSG_INVALID_ACCESS_SIZE,
> > --
> > 1.9.1
> >
5 years, 9 months
Re: [Devel] [PATCH] ACPICA: Avoid return Access Size error with PCC Register
by Moore, Robert
This looks OK. We'll integrate it for the next release of ACPICA later this month. I'll commit it today.
Thanks,
Bob
> -----Original Message-----
> From: Hoan Tran [mailto:hotran@apm.com]
> Sent: Monday, October 3, 2016 1:39 PM
> To: Moore, Robert <robert.moore(a)intel.com>; devel(a)acpica.org
> Cc: Loc Ho <lho(a)apm.com>; Hoan Tran <hotran(a)apm.com>
> Subject: Re: [PATCH] ACPICA: Avoid return Access Size error with PCC
> Register
>
> Correct devel acpica email (devel(a)acpica.org)
>
> Thanks
> Hoan
>
> On Mon, Oct 3, 2016 at 10:59 AM, Hoan Tran <hotran(a)apm.com> wrote:
> > Based on section "14.5 Referencing the PCC address space" of ACPI
> > 6.1 specification, an individual register may be referenced in a
> > Generic Register Descriptor by using the Address Space ID PCC (0xA).
> > When using the PCC address space, the Access Size field is redefined
> > to PCC Subspace ID.
> >
> > This patch avoids iasl return Access Size error with PCC register when
> > its value is over 4.
> >
> > Signed-off-by: Hoan Tran <hotran(a)apm.com>
> > ---
> > source/compiler/aslrestype2.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/source/compiler/aslrestype2.c
> > b/source/compiler/aslrestype2.c index 9fc77b0..cbec1b3 100644
> > --- a/source/compiler/aslrestype2.c
> > +++ b/source/compiler/aslrestype2.c
> > @@ -199,6 +199,11 @@ RsDoGeneralRegisterDescriptor (
> > RsCreateByteField (InitializerOp, ACPI_RESTAG_ACCESSSIZE,
> > CurrentByteOffset + ASL_RESDESC_OFFSET
> > (GenericReg.AccessSize));
> >
> > + if (Descriptor->GenericReg.AddressSpaceId ==
> ACPI_ADR_SPACE_PLATFORM_COMM)
> > + {
> > + break;
> > + }
> > +
> > if (Descriptor->GenericReg.AccessSize >
> AML_FIELD_ACCESS_QWORD)
> > {
> > AslError (ASL_ERROR, ASL_MSG_INVALID_ACCESS_SIZE,
> > --
> > 1.9.1
> >
5 years, 10 months