,
we can get ACPI tables from BIOS on ARM64 now.
Signed-off-by: Al Stone al.st...@linaro.org
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
Signed-off-by: Hanjun Guo hanjun@linaro.org
---
arch/arm64/include/asm/acpi.h | 57 +++
arch/arm64/kernel/setup.c |8
/specifications
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
know what's being described but a specific example would really
help me understand better.
Thanks.
[0] http://www.uefi.org/join
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from
(unsigned long pio);
extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
struct device_node *node);
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
it.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
Hi Al,
On Thursday, January 22, 2015 05:44:37 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new
On 02/04/2015 11:12 AM, Mark Brown wrote:
On Tue, Feb 03, 2015 at 05:40:20PM -0700, Al Stone wrote:
Much removed to cut down the size on this and to highlight a couple of
specific sections pertinent to the ACPI on ARMv8 TODO List.
This is of course good practice when replying to anything
On 02/04/2015 04:21 PM, Rafael J. Wysocki wrote:
On Wednesday, February 04, 2015 03:44:50 PM Al Stone wrote:
On 02/04/2015 06:50 AM, Rafael J. Wysocki wrote:
On Tuesday, February 03, 2015 05:21:40 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In order to deprecate the use
On 02/04/2015 07:03 AM, Rafael J. Wysocki wrote:
On Wednesday, February 04, 2015 03:00:15 PM Rafael J. Wysocki wrote:
On Tuesday, February 03, 2015 05:21:42 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
Now that all of the _OSI functionality has been separated out, we can
On 02/04/2015 06:50 AM, Rafael J. Wysocki wrote:
On Tuesday, February 03, 2015 05:21:40 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change
by Grant, and recommendations and prohibitions on the use of the numerous
ACPI tables and objects by Al Stone.
- Add two patches which is need to map acpi tables after
acpi_gbl_permanent_mmap
is set
- Add another patch dt / chosen: Add linux,uefi-stub-generated-dtb
property
On 02/05/2015 10:49 AM, Lorenzo Pieralisi wrote:
Hi Al,
Howdy, Lorenzo.
On Thu, Feb 05, 2015 at 05:11:31PM +, Al Stone wrote:
On 02/04/2015 09:43 AM, Lorenzo Pieralisi wrote:
On Mon, Feb 02, 2015 at 12:45:39PM +, Hanjun Guo wrote:
From: Graeme Gregory graeme.greg...@linaro.org
are they will, but it's not mandatory).
I've probably just missed a part of a thread somewhere; could you point
me to where the inconsistency lies? I'm just not understanding right this
second
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st
is RAM)?
___
Linaro-acpi mailing list
linaro-a...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-acpi
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
From: Al Stone al.st...@linaro.org
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Al Stone al.st...@linaro.org
Set the defaults for the arm64 kernel so that the arch-specific _OSI
method and blacklist are always used for ACPI.
Signed-off-by: Al Stone al.st...@linaro.org
---
arch/arm64/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/Kconfig b
From: Al Stone al.st...@linaro.org
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi/osl.c to drivers/acpi/osi.c, we now move all the
remaining _OSI support functions to osi.c.
This patch is much larger than I had wanted it to be; several of the
functions
Much removed to cut down the size on this and to highlight a couple of specific
sections pertinent to the ACPI on ARMv8 TODO List.
On 02/02/2015 05:45 AM, Hanjun Guo wrote:
From: Al Stone al.st...@linaro.org
Two more documentation files are also being added:
(1) A verbatim copy
From: Al Stone al.st...@linaro.org
Now that all of the _OSI functionality has been separated out, we can
provide arch-specific functionality for it. This also allows us to do
the same for the acpi_blacklisted() function.
Whether arch-specific functions are used or not now depends on the config
From: Al Stone al.st...@linaro.org
ACPI_OS_NAME is globally defined as Microsoft Windows NT for now.
That doesn't make much sense in the ARM context, so set it to Linux
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the default
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use
precise of languages and I would prefer not to misinterpret.
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
://lkml.org/lkml/2014/9/15/1308
[1] https://git.fedorahosted.org/git/kernel-arm64 -- this is
what I run on an AMD Seattle daily driver, btw, and is used
in Fedora 21 as well.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
On 01/16/2015 03:20 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 09:31:53PM +, Al Stone wrote:
On 01/15/2015 11:23 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wrote:
On Wed, Jan 14, 2015 at 3:04 PM, Hanjun Guo hanjun@linaro.org wrote
On 01/16/2015 08:17 AM, Al Stone wrote:
On 01/16/2015 03:20 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 09:31:53PM +, Al Stone wrote:
On 01/15/2015 11:23 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wrote:
On Wed, Jan 14, 2015 at 3:04 PM, Hanjun
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
On 01/22/2015 05:44 PM, al.st...@linaro.org wrote:
From: Al Stone a...@redhat.com
[snip]
While I was assuming a couple more passes would be needed, I
didn't expect quite so soon. My apologies, I thought I had
corrected the From lines to say Al Stone al.st...@linaro.org
but I had
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use
From: Al Stone a...@redhat.com
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/ia64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
From: Al Stone a...@redhat.com
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/arm64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
From: Al Stone a...@redhat.com
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi to arch-dependent locations, we now move all the
remaining _OSI support functions to arch-dependent files.
This patch is much larger than I had wanted it to be; several of the
functions
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Hanjun Guo hanjun@linaro.org
ACPI_OS_NAME is globally defined as Microsoft Windows NT for now.
That doesn't make much sense in the ARM context, so set it to Linux
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the
to be that there should be some consequences to the vendors when
they do things like this, and while I'm not that keen to break existing things,
maybe that's what needs to happen to make the point.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
(processor);
+ return 0;
}
/* Parse GIC cpu interface entries in MADT for SMP init */
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send
/acpi-blacklist.c
@@ -0,0 +1,20 @@
+/*
+ * ARM64 Specific ACPI Blacklist Support
+ *
+ * Copyright (C) 2015, Linaro Ltd.
+ * Author: Al Stone al.st...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public
On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up the errors reported by checkpatch.pl. They fell
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later
On 02/25/2015 05:55 AM, Hanjun Guo wrote:
On 2015年02月25日 08:36, al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clear up all the warnings reported by checkpatch.pl where pr_* should
be used
On 02/25/2015 06:08 AM, Hanjun Guo wrote:
On 2015年02月25日 08:36, al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up some warnings from checkpatch that fall into more semantic
issues; none
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use
From: Al Stone al.st...@linaro.org
Whether arch-specific functions are used or not now depends on the config
option CONFIG_ARCH_SPECIFIC_ACPI_OSI. By default, this is set false which
causes the x86/ia64 versions to be used, just as is done today. Setting
this option true causes architecture
From: Al Stone al.st...@linaro.org
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi/osl.c to drivers/acpi/osi.c, we now move all the
remaining _OSI support functions to osi.c.
This patch is much larger than I had wanted it to be; several of the
functions
From: Al Stone al.st...@linaro.org
ACPI_OS_NAME is globally defined as Microsoft Windows NT for now.
That doesn't make much sense in the ARM context, so set it to Linux
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the default
From: Al Stone al.st...@linaro.org
Now that all of the _OSI functionality has been separated out, we can
provide arch-specific functionality for it. This also allows us to do
the same for the acpi_blacklisted() function. We also make sure the
defaults for the arm64 kernel are set so
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up some warnings from checkpatch that fall into more semantic
issues; none of these should change functionality, but they do touch lines
of code with semantic significance
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up a bunch of warnings for odd bits of syntax:
-- remove CVS keyword markers
-- remove a space from between a function name and an opening parenthesis
-- clean up
From: Al Stone al.st...@linaro.org
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up the errors reported by checkpatch.pl. They fell into these
classes:
-- remove the FSF address from the GPL notice
-- foo * bar should be foo *bar
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clear up all the warnings reported by checkpatch.pl where pr_* should
be used instead of printk(KERN_* ...).
Signed-off-by: Al Stone al.st...@linaro.org
---
drivers/acpi/osl.c
and why it was specified that way.
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 04/15/2015 08:53 AM, Catalin Marinas wrote:
On Wed, Apr 15, 2015 at 10:04:25AM +0100, Mark Rutland wrote:
On Tue, Apr 14, 2015 at 11:52:39PM +0100, Al Stone wrote:
On 04/14/2015 10:29 AM, Mark Rutland wrote:
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
++
drivers/acpi/resource.c |9 +-
include/linux/ioport.h|1 +
include/linux/pci-acpi.h | 23 +++
11 files changed, 432 insertions(+), 494 deletions(-)
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc
On 06/19/2015 04:49 AM, Hanjun Guo wrote:
On 06/19/2015 06:36 AM, Al Stone wrote:
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long
On 06/19/2015 04:49 AM, Hanjun Guo wrote:
On 06/19/2015 06:36 AM, Al Stone wrote:
Add the ACPI_SPEC_VERSION() macro to build a proper version number from
a major and minor revision number. Add also the ACPI_FADT_SPEC_VERSION
that constructs a proper version number from the entries
On 06/19/2015 03:46 AM, Will Deacon wrote:
On Thu, Jun 18, 2015 at 11:36:08PM +0100, Al Stone wrote:
For those parts of the arm64 ACPI code that need to check GICC subtables
in the MADT, use the new BAD_MADT_GICC_ENTRY macro instead of the previous
BAD_MADT_ENTRY. The new macro takes
On 06/19/2015 04:54 AM, Hanjun Guo wrote:
On 06/19/2015 06:36 AM, Al Stone wrote:
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long. But, there is only one
number.
Signed-off-by: Al Stone al.st...@linaro.org
---
include/linux/acpi.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index a4acb55..33ed313 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -48,6 +48,11 @@
#include acpi
only, accounting for the difference in specification versions that are
possible. The BAD_MADT_ENTRY() will continue to work as is for all other
MADT subtables.
Signed-off-by: Al Stone al.st...@linaro.org
---
include/linux/acpi.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
syntax clean-up noted by checkpatch
-- Send out CCs properly this time
-- Minor clean-up of the paragraphs in this cover letter
Al Stone (3):
ACPI : introduce macros for using the ACPI specification version
ACPI: add BAD_MADT_GICC_ENTRY() macro
ACPI / ARM64 : use the new
though the subtable entries are valid.
Signed-off-by: Al Stone al.st...@linaro.org
---
arch/arm64/kernel/smp.c | 2 +-
drivers/irqchip/irq-gic.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 4b2121b..80d5984 100644
the spec?
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 06/12/2015 08:52 AM, Lorenzo Pieralisi wrote:
On Thu, Jun 11, 2015 at 08:45:10PM +0100, al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct
On 07/02/2015 11:16 PM, Hanjun Guo wrote:
Hi Al,
On 2015/7/3 7:48, Al Stone wrote:
Add the __ACPI_FADT_SPEC_VERSION() helper macro to build a proper version
number from a major and minor revision number. Add also macros that use
the helper to construct the current version from the values
On 07/02/2015 11:23 PM, Hanjun Guo wrote:
Hi Rafael,
On 2015/7/3 8:21, Rafael J. Wysocki wrote:
On Thursday, July 02, 2015 05:48:34 PM Al Stone wrote:
Add the __ACPI_FADT_SPEC_VERSION() helper macro to build a proper version
number from a major and minor revision number. Add also macros
On 07/03/2015 08:06 AM, Catalin Marinas wrote:
On Thu, Jul 02, 2015 at 05:48:35PM -0600, Al Stone wrote:
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 39248d3..a3c26a4 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -19,6
though the subtable entries are valid.
Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
Signed-off-by: Al Stone al.st...@linaro.org
Reviewed-by: Hanjun Guo hanjun@linaro.org
Acked-by: Will Deacon will.dea...@arm.com
---
arch/arm64/kernel/smp.c | 2 +-
drivers/irqchip/irq
. As a GIC is
specific to ARM, it is also unlikely the subtable will be used elsewhere.
Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
Signed-off-by: Al Stone al.st...@linaro.org
---
arch/arm64/include/asm/acpi.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch
in this cover letter
Al Stone (3):
ACPI : introduce macros for using the ACPI specification version
ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro
ACPI / ARM64 : use the new BAD_MADT_GICC_ENTRY macro
arch/arm64/include/asm/acpi.h | 11 +++
arch/arm64/kernel/smp.c | 2 +-
drivers
changed with recent versions but can only be tracked by spec version
number.
Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
Signed-off-by: Al Stone al.st...@linaro.org
---
include/linux/acpi.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/acpi.h b
On 07/03/2015 05:54 PM, Rafael J. Wysocki wrote:
On Friday, July 03, 2015 01:51:36 PM Al Stone wrote:
On 07/03/2015 08:06 AM, Catalin Marinas wrote:
On Thu, Jul 02, 2015 at 05:48:35PM -0600, Al Stone wrote:
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index
-- Send out CCs properly this time
-- Minor clean-up of the paragraphs in this cover letter
Al Stone (2):
ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro
ACPI / ARM64 : use the new BAD_MADT_GICC_ENTRY macro
arch/arm64/include/asm/acpi.h | 8
though the subtable entries are valid.
Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
Signed-off-by: Al Stone al.st...@linaro.org
Reviewed-by: Hanjun Guo hanjun@linaro.org
Acked-by: Will Deacon will.dea...@arm.com
---
arch/arm64/kernel/smp.c | 2 +-
drivers/irqchip/irq
From: Al Stone al.st...@.linaro.org
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long
On 07/06/2015 05:20 PM, Rafael J. Wysocki wrote:
Hi Al,
On Tue, Jul 7, 2015 at 1:16 AM, Al Stone al.st...@linaro.org wrote:
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in
ACPI 6.0, the struct is 80
On 07/03/2015 05:50 PM, Rafael J. Wysocki wrote:
On Friday, July 03, 2015 01:22:13 PM Al Stone wrote:
On 07/02/2015 11:23 PM, Hanjun Guo wrote:
Hi Rafael,
On 2015/7/3 8:21, Rafael J. Wysocki wrote:
On Thursday, July 02, 2015 05:48:34 PM Al Stone wrote:
Add the __ACPI_FADT_SPEC_VERSION
On 06/30/2015 08:06 PM, Hanjun Guo wrote:
On 2015/7/1 2:35, Rafael J. Wysocki wrote:
On Tue, Jun 30, 2015 at 8:25 PM, Rafael J. Wysocki raf...@kernel.org wrote:
Hi Al,
On Tue, Jun 30, 2015 at 7:29 PM, Al Stone a...@redhat.com wrote:
On 06/30/2015 11:07 AM, Sudeep Holla wrote:
Hi Al,
On 18
From: Al Stone al.st...@linaro.org
Add the ACPI_SPEC_VERSION() macro to build a proper version number from
a major and minor revision number. Add also the ACPI_FADT_SPEC_VERSION
that constructs a proper version number from the entries in the current
FADT.
These macros are added in order
From: Al Stone al.st...@linaro.org
For those parts of the arm64 ACPI code that need to check GICC subtables
in the MADT, use the new BAD_MADT_GICC_ENTRY macro instead of the previous
BAD_MADT_ENTRY. The new macro takes into account differences in the size
of the GICC subtable that the old macro
From: Al Stone al.st...@linaro.org
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long
From: Al Stone al.st...@linaro.org
In the ACPI 5.1 version of the spec, the struct for the GICC subtable (struct
acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in ACPI 6.0, the
struct is 80 bytes long. But, there is only one definition in ACPICA for
this struct -- and that is the 6.0
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone al.st...@linaro.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
of arm64, the BAD_MADT_GICC_ENTRY, too.
Signed-off-by: Al Stone al.st...@linaro.org
Acked
to
work there. They have also been cross-compiled for x86 and ia64 with no
known failures.
Changes for v2:
-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM
-- Correct faulty end of loop test found by Timur Tabi
Al Stone (5):
ACPI: add in a bad_madt_entry() function
from now on.
Signed-off-by: Al Stone al.st...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown l...@kernel.org
---
drivers/acpi/tables.c | 241 ++
1 file changed, 241 insertions(+)
diff --git a/drivers/acpi/tables.c b/drivers/acpi
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone al.st...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown len.br
Now that we have introduced to bad_madt_entry(), and we have removed
all the usages of the BAD_MADT_ENTRY macro from all of the various
architectures that use it (arm64, ia64, x86), we can remove the macro
definition since it is no longer used.
Signed-off-by: Al Stone al.st...@linaro.org
Cc
On 08/20/2015 04:13 AM, Will Deacon wrote:
Hi Al,
On Wed, Aug 19, 2015 at 11:07:25PM +0100, Al Stone wrote:
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY
On 06/30/2015 11:07 AM, Sudeep Holla wrote:
Hi Al,
On 18/06/15 23:36, Al Stone wrote:
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long. But, there is only one
On 06/30/2015 12:25 PM, Rafael J. Wysocki wrote:
Hi Al,
On Tue, Jun 30, 2015 at 7:29 PM, Al Stone a...@redhat.com wrote:
On 06/30/2015 11:07 AM, Sudeep Holla wrote:
Hi Al,
On 18/06/15 23:36, Al Stone wrote:
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct
On 06/30/2015 01:05 PM, Rafael J. Wysocki wrote:
Hi Al,
On Tue, Jun 30, 2015 at 8:39 PM, Al Stone a...@redhat.com wrote:
On 06/30/2015 12:25 PM, Rafael J. Wysocki wrote:
Hi Al,
On Tue, Jun 30, 2015 at 7:29 PM, Al Stone a...@redhat.com wrote:
On 06/30/2015 11:07 AM, Sudeep Holla wrote:
Hi
On 06/30/2015 12:25 PM, Rafael J. Wysocki wrote:
Hi Al,
On Tue, Jun 30, 2015 at 7:29 PM, Al Stone a...@redhat.com wrote:
On 06/30/2015 11:07 AM, Sudeep Holla wrote:
Hi Al,
On 18/06/15 23:36, Al Stone wrote:
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct
On 06/30/2015 02:12 PM, Rafael J. Wysocki wrote:
Hi Al,
On Fri, Jun 19, 2015 at 12:36 AM, Al Stone al.st...@linaro.org wrote:
Add the ACPI_SPEC_VERSION() macro to build a proper version number from
a major and minor revision number. Add also the ACPI_FADT_SPEC_VERSION
that constructs
). Should there be a bug in
table mapping or ACPI startup, this info might help.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
to
work there. They have also been cross-compiled for x86 and ia64 with no
known failures.
Al Stone (5):
ACPI: add in a bad_madt_entry() function to eventually replace the
macro
ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
ACPI / IA64: remove usage of BAD_MADT_ENTRY
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
of arm64, the BAD_MADT_GICC_ENTRY, too.
Signed-off-by: Al Stone al.st...@linaro.org
Cc
from now on.
Signed-off-by: Al Stone al.st...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown l...@kernel.org
---
drivers/acpi/tables.c | 241 ++
1 file changed, 241 insertions(+)
diff --git a/drivers/acpi/tables.c b/drivers/acpi
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone al.st...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown len.br
1 - 100 of 552 matches
Mail list logo
