On Tue, Nov 01, 2016 at 08:38:08PM +0300, Eugene Korenevsky wrote:
> *e820ext is always NULL in 'alloc_e820ext()' (see the code of 'exit_boot()').
> Therefore the 'if' condition is always false and the entire 'if' statement is
> pointless. Remove it.
>
> ---
> arch/x86/boot/compressed/eboot.c |
On Tue, Nov 01, 2016 at 08:38:08PM +0300, Eugene Korenevsky wrote:
> *e820ext is always NULL in 'alloc_e820ext()' (see the code of 'exit_boot()').
> Therefore the 'if' condition is always false and the entire 'if' statement is
> pointless. Remove it.
>
> ---
> arch/x86/boot/compressed/eboot.c |
Commit-ID: 30d7bf034c034995f34dae265d96247f7f12044e
Gitweb: http://git.kernel.org/tip/30d7bf034c034995f34dae265d96247f7f12044e
Author: Linn Crosetto <l...@hpe.com>
AuthorDate: Mon, 25 Apr 2016 21:06:37 +0100
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 28 Apr 2
Commit-ID: 30d7bf034c034995f34dae265d96247f7f12044e
Gitweb: http://git.kernel.org/tip/30d7bf034c034995f34dae265d96247f7f12044e
Author: Linn Crosetto
AuthorDate: Mon, 25 Apr 2016 21:06:37 +0100
Committer: Ingo Molnar
CommitDate: Thu, 28 Apr 2016 11:33:49 +0200
efi/arm64: Check
Commit-ID: 73a6492589c87cd56707c8ac19eec78236c2d576
Gitweb: http://git.kernel.org/tip/73a6492589c87cd56707c8ac19eec78236c2d576
Author: Linn Crosetto <l...@hpe.com>
AuthorDate: Mon, 25 Apr 2016 21:06:36 +0100
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 28 Apr 2
Commit-ID: 73a6492589c87cd56707c8ac19eec78236c2d576
Gitweb: http://git.kernel.org/tip/73a6492589c87cd56707c8ac19eec78236c2d576
Author: Linn Crosetto
AuthorDate: Mon, 25 Apr 2016 21:06:36 +0100
Committer: Ingo Molnar
CommitDate: Thu, 28 Apr 2016 11:33:48 +0200
efi/arm64: Report
.
If an unexpected error is returned from GetVariable() when querying the
status of UEFI Secure Boot, return an error to the caller. This allows the
caller to determine the definite state, and to take appropriate action if
an expected error is returned.
Signed-off-by: Linn Crosetto <l...@hpe.com>
.
If an unexpected error is returned from GetVariable() when querying the
status of UEFI Secure Boot, return an error to the caller. This allows the
caller to determine the definite state, and to take appropriate action if
an expected error is returned.
Signed-off-by: Linn Crosetto
---
v2:
- Maintain existing
is set to 1.
Check the value of the SetupMode variable when determining the state of
Secure Boot. Minor cleanup, change sizeof to match kernel style guidelines.
Signed-off-by: Linn Crosetto <l...@hpe.com>
---
v2:
- Reformat quote from UEFI specification and note cleanup (Mark R
is set to 1.
Check the value of the SetupMode variable when determining the state of
Secure Boot. Minor cleanup, change sizeof to match kernel style guidelines.
Signed-off-by: Linn Crosetto
---
v2:
- Reformat quote from UEFI specification and note cleanup (Mark Rutland)
- Restructure code
for unexpected errors
- Split changes into two patches
v3:
- Add more verbosity with additional prints
Linn Crosetto (2):
arm64/efi: report unexpected errors when determining Secure Boot status
arm64/efi: check SetupMode when determining Secure Boot status
drivers/firmware/efi/libstub/arm-stub.c | 54
for unexpected errors
- Split changes into two patches
v3:
- Add more verbosity with additional prints
Linn Crosetto (2):
arm64/efi: report unexpected errors when determining Secure Boot status
arm64/efi: check SetupMode when determining Secure Boot status
drivers/firmware/efi/libstub/arm-stub.c | 54
is set to 1.
Check the value of the SetupMode variable when determining the state of
Secure Boot. Minor cleanup, change sizeof to match kernel style guidelines.
Signed-off-by: Linn Crosetto <l...@hpe.com>
---
v2:
- Reformat quote from UEFI specification and note cleanup (Mark R
is set to 1.
Check the value of the SetupMode variable when determining the state of
Secure Boot. Minor cleanup, change sizeof to match kernel style guidelines.
Signed-off-by: Linn Crosetto
---
v2:
- Reformat quote from UEFI specification and note cleanup (Mark Rutland)
- Restructure code
for unexpected errors
- Split changes into two patches
Linn Crosetto (2):
arm64/efi: report unexpected errors when determining Secure Boot status
arm64/efi: check SetupMode when determining Secure Boot status
drivers/firmware/efi/libstub/arm-stub.c | 49 +
1 file changed
.
If an unexpected error is returned from GetVariable when querying the
status of UEFI Secure Boot, return an error to the caller. This allows the
caller to determine the definite state, and to take appropriate action if
an expected error is returned.
Signed-off-by: Linn Crosetto <l...@hpe.com>
---
New patch
for unexpected errors
- Split changes into two patches
Linn Crosetto (2):
arm64/efi: report unexpected errors when determining Secure Boot status
arm64/efi: check SetupMode when determining Secure Boot status
drivers/firmware/efi/libstub/arm-stub.c | 49 +
1 file changed
.
If an unexpected error is returned from GetVariable when querying the
status of UEFI Secure Boot, return an error to the caller. This allows the
caller to determine the definite state, and to take appropriate action if
an expected error is returned.
Signed-off-by: Linn Crosetto
---
New patch in v2 based
According to the UEFI specification, the platform is operating in secure
boot mode if SetupMode is 0 and SecureBoot is 1, and cannot operate in
secure boot mode if SetupMode is set to 1. Check the value of SetupMode
when determining the state of Secure Boot.
Signed-off-by: Linn Crosetto &l
According to the UEFI specification, the platform is operating in secure
boot mode if SetupMode is 0 and SecureBoot is 1, and cannot operate in
secure boot mode if SetupMode is set to 1. Check the value of SetupMode
when determining the state of Secure Boot.
Signed-off-by: Linn Crosetto
On Wed, Mar 26, 2014 at 10:04:52AM -0700, Yinghai Lu wrote:
> On Wed, Mar 26, 2014 at 9:50 AM, Linn Crosetto wrote:
> > On Tue, Mar 25, 2014 at 05:18:53PM -0700, Yinghai Lu wrote:
> >
> > Just noting that not all bits above first_system_vector are set in the
> > bitmap
On Tue, Mar 25, 2014 at 05:18:53PM -0700, Yinghai Lu wrote:
> On Tue, Mar 25, 2014 at 1:03 PM, Linn Crosetto wrote:
> > Thanks for the patch.
> >
> > On Tue, Jan 28, 2014 at 01:54:05PM -0800, Yinghai Lu wrote:
> >> used_vectors is a bitmap for vectors t
On Tue, Mar 25, 2014 at 05:18:53PM -0700, Yinghai Lu wrote:
On Tue, Mar 25, 2014 at 1:03 PM, Linn Crosetto l...@hp.com wrote:
Thanks for the patch.
On Tue, Jan 28, 2014 at 01:54:05PM -0800, Yinghai Lu wrote:
used_vectors is a bitmap for vectors that are not tracked in per_cpu
vector_irq
On Wed, Mar 26, 2014 at 10:04:52AM -0700, Yinghai Lu wrote:
On Wed, Mar 26, 2014 at 9:50 AM, Linn Crosetto l...@hp.com wrote:
On Tue, Mar 25, 2014 at 05:18:53PM -0700, Yinghai Lu wrote:
Just noting that not all bits above first_system_vector are set in the
bitmap,
so the comment in asm
Thanks for the patch.
On Tue, Jan 28, 2014 at 01:54:05PM -0800, Yinghai Lu wrote:
> used_vectors is a bitmap for vectors that are not tracked in per_cpu
> vector_irq.
I feel like this comment (also in the code) could be misleading because vectors
above first_system_vector are effectively not
Thanks for the patch.
On Tue, Jan 28, 2014 at 01:54:05PM -0800, Yinghai Lu wrote:
used_vectors is a bitmap for vectors that are not tracked in per_cpu
vector_irq.
I feel like this comment (also in the code) could be misleading because vectors
above first_system_vector are effectively not
On Fri, Mar 14, 2014 at 08:26:15AM +, Matt Fleming wrote:
> On Fri, 14 Mar, at 10:47:26AM, Dave Young wrote:
> >
> > Can you test with matt's tree to see if it works?
> > If it still happens please post the full log.
>
> So that'd be the 'next' branch at,
>
>
On Fri, Mar 14, 2014 at 08:26:15AM +, Matt Fleming wrote:
On Fri, 14 Mar, at 10:47:26AM, Dave Young wrote:
Can you test with matt's tree to see if it works?
If it still happens please post the full log.
So that'd be the 'next' branch at,
On Thu, Sep 26, 2013 at 12:34:00PM +0100, Matt Fleming wrote:
> > I might add the following to your merge for semantic reasons:
> >
> > diff --git a/arch/x86/boot/compressed/eboot.c
> > b/arch/x86/boot/compressed/eboot.c
> > index 04b228d..a7677ba 100644
> > ---
On Thu, Sep 26, 2013 at 12:34:00PM +0100, Matt Fleming wrote:
I might add the following to your merge for semantic reasons:
diff --git a/arch/x86/boot/compressed/eboot.c
b/arch/x86/boot/compressed/eboot.c
index 04b228d..a7677ba 100644
--- a/arch/x86/boot/compressed/eboot.c
+++
On Wed, Sep 25, 2013 at 01:58:40PM +0100, Matt Fleming wrote:
> On Sun, 22 Sep, at 07:59:08PM, Linn Crosetto wrote:
> > This patch fixes a problem with EFI memory maps larger than 128 entries
> > when booting using the EFI stub, which results in overflowing e820_map
>
On Wed, Sep 25, 2013 at 01:58:40PM +0100, Matt Fleming wrote:
On Sun, 22 Sep, at 07:59:08PM, Linn Crosetto wrote:
This patch fixes a problem with EFI memory maps larger than 128 entries
when booting using the EFI stub, which results in overflowing e820_map
in boot_params and an eventual
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto
---
Changes from v2:
* Removed unnecessary optimization in alloc_e820ext() (Matt Fleming
On Tue, Sep 17, 2013 at 09:14:52PM +0100, Matt Fleming wrote:
> > +static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
> > + u32 *e820ext_size)
> > +{
> > + efi_status_t status;
> > + unsigned long size;
> > +
> > + size = sizeof(struct
On Tue, Sep 17, 2013 at 09:14:52PM +0100, Matt Fleming wrote:
+static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
+ u32 *e820ext_size)
+{
+ efi_status_t status;
+ unsigned long size;
+
+ size = sizeof(struct setup_data) +
+
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto l...@hp.com
---
Changes from v2:
* Removed unnecessary optimization in alloc_e820ext() (Matt
Replace the call to early_iounmap() with early_memunmap() to eliminate
the following sparse warning:
arch/x86/kernel/e820.c:672:23: sparse: incorrect type in argument 1 (different
address spaces)
Signed-off-by: Linn Crosetto
---
arch/x86/kernel/e820.c | 2 +-
1 file changed, 1 insertion(+), 1
in argument 1
(different address spaces)
arch/x86/kernel/setup.c:470:31: warning: incorrect type in argument 1
(different address spaces)
arch/x86/kernel/setup.c:491:31: warning: incorrect type in argument 1
(different address spaces)
Signed-off-by: Linn Crosetto
---
arch/x86/kernel/setup.c | 8
address spaces)
Signed-off-by: Linn Crosetto
---
arch/x86/include/asm/io.h | 4 ++--
arch/x86/mm/ioremap.c | 9 +++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..ae1ef3e 100644
--- a/arch/x86/include/asm
1
(different address spaces)
arch/x86/kernel/e820.c:667:15: warning: incorrect type in assignment (different
address spaces)
arch/x86/kernel/e820.c:672:23: warning: incorrect type in argument 1 (different
address spaces)
Linn Crosetto (3):
x86/mm: fix sparse warnings from early_memremap
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto
---
Changes in v2:
* Free memory when error is returned from alloc_e820ext() as suggested by Matt
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto l...@hp.com
---
Changes in v2:
* Free memory when error is returned from alloc_e820ext
1
(different address spaces)
arch/x86/kernel/e820.c:667:15: warning: incorrect type in assignment (different
address spaces)
arch/x86/kernel/e820.c:672:23: warning: incorrect type in argument 1 (different
address spaces)
Linn Crosetto (3):
x86/mm: fix sparse warnings from early_memremap
address spaces)
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/include/asm/io.h | 4 ++--
arch/x86/mm/ioremap.c | 9 +++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..ae1ef3e 100644
--- a/arch/x86
Replace the call to early_iounmap() with early_memunmap() to eliminate
the following sparse warning:
arch/x86/kernel/e820.c:672:23: sparse: incorrect type in argument 1 (different
address spaces)
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/kernel/e820.c | 2 +-
1 file changed, 1
in argument 1
(different address spaces)
arch/x86/kernel/setup.c:470:31: warning: incorrect type in argument 1
(different address spaces)
arch/x86/kernel/setup.c:491:31: warning: incorrect type in argument 1
(different address spaces)
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/kernel
Commit-ID: 30e46b574a1db7d14404e52dca8e1aa5f5155fd2
Gitweb: http://git.kernel.org/tip/30e46b574a1db7d14404e52dca8e1aa5f5155fd2
Author: Linn Crosetto
AuthorDate: Tue, 13 Aug 2013 15:46:41 -0600
Committer: H. Peter Anvin
CommitDate: Tue, 13 Aug 2013 23:29:19 -0700
x86: avoid remapping
Commit-ID: 30e46b574a1db7d14404e52dca8e1aa5f5155fd2
Gitweb: http://git.kernel.org/tip/30e46b574a1db7d14404e52dca8e1aa5f5155fd2
Author: Linn Crosetto l...@hp.com
AuthorDate: Tue, 13 Aug 2013 15:46:41 -0600
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 13 Aug 2013 23:29
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto
---
arch/x86/boot/compressed/eboot.c | 220 ---
1 file
in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/boot/compressed/eboot.c | 220 ---
1
On Mon, Aug 19, 2013 at 01:47:41PM -0700, Yinghai Lu wrote:
> On Mon, Aug 19, 2013 at 1:06 PM, H. Peter Anvin wrote:
> > I would strongly disagree that option 2 is the cleaner solution.
>
> Agreed.
>
> >
> > Linn Crosetto wrote:
> >>I realize the
() and the boot loader identifier), and that there is no
e820 map already provided.
Signed-off-by: Linn Crosetto
---
arch/x86/platform/efi/efi.c | 7 +++
include/linux/efi.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index
a memory_setup hook.
The EFI memory map may also be added in efi_init() if the command line
parameter "add_efi_memmap" is specified. This is left intact to allow
the command line parameter to remain effective.
Signed-off-by: Linn Crosetto
---
arch/x86/boot/compressed/eb
entries.
2. Create a memory_setup function to be enabled when the EFI memory map is
needed.
Option 2 appeared to be the cleaner solution, reducing duplication with
existing code, given a reasonable mechanism for determining when to
replace the default memory_setup function.
Linn Crosetto (4
called to avoid doing the
initialization more than once.
Signed-off-by: Linn Crosetto
---
arch/x86/platform/efi/efi.c | 44 ++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index
Adding efi_memory_setup() to be used to override the default
memory_setup function when the EFI memory map should be used instead of
a BIOS provided e820 map.
Signed-off-by: Linn Crosetto
---
arch/x86/platform/efi/efi.c | 8
include/linux/efi.h | 1 +
2 files changed, 9
Adding efi_memory_setup() to be used to override the default
memory_setup function when the EFI memory map should be used instead of
a BIOS provided e820 map.
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/platform/efi/efi.c | 8
include/linux/efi.h | 1 +
2 files changed
called to avoid doing the
initialization more than once.
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/platform/efi/efi.c | 44 ++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi
entries.
2. Create a memory_setup function to be enabled when the EFI memory map is
needed.
Option 2 appeared to be the cleaner solution, reducing duplication with
existing code, given a reasonable mechanism for determining when to
replace the default memory_setup function.
Linn Crosetto (4
a memory_setup hook.
The EFI memory map may also be added in efi_init() if the command line
parameter add_efi_memmap is specified. This is left intact to allow
the command line parameter to remain effective.
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/boot/compressed/eboot.c | 64
() and the boot loader identifier), and that there is no
e820 map already provided.
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/platform/efi/efi.c | 7 +++
include/linux/efi.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
On Mon, Aug 19, 2013 at 01:47:41PM -0700, Yinghai Lu wrote:
On Mon, Aug 19, 2013 at 1:06 PM, H. Peter Anvin h...@zytor.com wrote:
I would strongly disagree that option 2 is the cleaner solution.
Agreed.
Linn Crosetto l...@hp.com wrote:
I realize the EFI stub for ARM patches
for individual types to handle their own data remapping.
Signed-off-by: Linn Crosetto
---
v3: Remove data remapping code from parse_setup_data() and add it to
parse_e820_ext().
arch/x86/include/asm/e820.h | 2 +-
arch/x86/kernel/e820.c | 5 -
arch/x86/kernel/setup.c | 19
for individual types to handle their own data remapping.
Signed-off-by: Linn Crosetto l...@hp.com
---
v3: Remove data remapping code from parse_setup_data() and add it to
parse_e820_ext().
arch/x86/include/asm/e820.h | 2 +-
arch/x86/kernel/e820.c | 5 -
arch/x86/kernel/setup.c | 19
for types actually parsed in parse_setup_data(). Type SETUP_PCI is
handled later by pcibios_add_device(), when ioremap() is available.
Signed-off-by: Linn Crosetto
---
v2: add more detail to the explanation as requested by hpa
---
arch/x86/kernel/setup.c | 19 ++-
1 file changed, 14
PCI devices may advertise a ROM size larger than early_memremap() is
able to handle. If this occurs it leads to a NULL dereference in
parse_setup_data(). Avoid this by remapping the data only when
necessary.
Signed-off-by: Linn Crosetto
---
arch/x86/kernel/setup.c | 19 ++-
1
PCI devices may advertise a ROM size larger than early_memremap() is
able to handle. If this occurs it leads to a NULL dereference in
parse_setup_data(). Avoid this by remapping the data only when
necessary.
Signed-off-by: Linn Crosetto l...@hp.com
---
arch/x86/kernel/setup.c | 19
for types actually parsed in parse_setup_data(). Type SETUP_PCI is
handled later by pcibios_add_device(), when ioremap() is available.
Signed-off-by: Linn Crosetto l...@hp.com
---
v2: add more detail to the explanation as requested by hpa
---
arch/x86/kernel/setup.c | 19 ++-
1 file
Commit-ID: 13f72756da86f155898e2c2022f7b3a106c3742e
Gitweb: http://git.kernel.org/tip/13f72756da86f155898e2c2022f7b3a106c3742e
Author: Linn Crosetto
AuthorDate: Tue, 23 Apr 2013 12:26:45 -0600
Committer: Ingo Molnar
CommitDate: Wed, 24 Apr 2013 08:45:47 +0200
x86/iommu/dmar: Remove
Commit-ID: 13f72756da86f155898e2c2022f7b3a106c3742e
Gitweb: http://git.kernel.org/tip/13f72756da86f155898e2c2022f7b3a106c3742e
Author: Linn Crosetto l...@hp.com
AuthorDate: Tue, 23 Apr 2013 12:26:45 -0600
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 24 Apr 2013 08:45:47 +0200
ACPI_DMAR_SCOPE_TYPE_HPET is parsed by ir_parse_ioapic_hpet_scope() and
should not be flagged as an unsupported type.
Signed-off-by: Linn Crosetto
---
drivers/iommu/dmar.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index
ACPI_DMAR_SCOPE_TYPE_HPET is parsed by ir_parse_ioapic_hpet_scope() and
should not be flagged as an unsupported type.
Signed-off-by: Linn Crosetto l...@hp.com
---
drivers/iommu/dmar.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu
On Fri, Mar 15, 2013 at 08:50:45PM +, Moore, Robert wrote:
> Can you explain in a bit more detail what brings this up?
>
> I'm aware of the limitation of the generic address structure, but we are
> forced by the (current) ACPI specification to use it if it is present for a
> given register.
than 255 bits.
Signed-off-by: Linn Crosetto
---
drivers/acpi/acpica/tbfadt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 74181bf..e87abcd 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -561,6
than 255 bits.
Signed-off-by: Linn Crosetto l...@hp.com
---
drivers/acpi/acpica/tbfadt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 74181bf..e87abcd 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica
On Fri, Mar 15, 2013 at 08:50:45PM +, Moore, Robert wrote:
Can you explain in a bit more detail what brings this up?
I'm aware of the limitation of the generic address structure, but we are
forced by the (current) ACPI specification to use it if it is present for a
given register.
A
76 matches
Mail list logo
