linux-toradex.git/arch/x86/kernel/acpi/boot.c, branch v4.19

x86/acpi: Prevent X2APIC id 0xffffffff from being accounted

2018-04-17T09:56:31+00:00

RongQing reported that there are some X2APIC id 0xffffffff in his machine's
ACPI MADT table, which makes the number of possible CPU inaccurate.

The reason is that the ACPI X2APIC parser has no sanity check for APIC ID
0xffffffff, which is an invalid id in all APIC types. See "Intel® 64
Architecture x2APIC Specification", Chapter 2.4.1.

Add a sanity check to acpi_parse_x2apic() which ignores the invalid id.

Reported-by: Li RongQing 
Signed-off-by: Dou Liyang 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Cc: len.brown@intel.com
Cc: rjw@rjwysocki.net
Cc: hpa@zytor.com
Link: https://lkml.kernel.org/r/20180412014052.25186-1-douly.fnst@cn.fujitsu.com

Merge branch 'WIP.x86/asm' into x86/urgent, because the topic is ready

2018-04-12T07:42:34+00:00

Signed-off-by: Ingo Molnar

x86/apic: Fix signedness bug in APIC ID validity checks

2018-04-10T14:46:39+00:00

The APIC ID as parsed from ACPI MADT is validity checked with the
apic->apic_id_valid() callback, which depends on the selected APIC type.

For non X2APIC types APIC IDs >= 0xFF are invalid, but values > 0x7FFFFFFF
are detected as valid. This happens because the 'apicid' argument of the
apic_id_valid() callback is type 'int'. So the resulting comparison

   apicid < 0xFF

evaluates to true for all unsigned int values > 0x7FFFFFFF which are handed
to default_apic_id_valid(). As a consequence, invalid APIC IDs in !X2APIC
mode are considered valid and accounted as possible CPUs.

Change the apicid argument type of the apic_id_valid() callback to u32 so
the evaluation is unsigned and returns the correct result.

[ tglx: Massaged changelog ]

Signed-off-by: Li RongQing 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Cc: jgross@suse.com
Cc: Dou Liyang 
Cc: Peter Zijlstra 
Cc: hpa@zytor.com
Link: https://lkml.kernel.org/r/1523322966-10296-1-git-send-email-lirongqing@baidu.com

ACPI, x86/boot: Introduce the ->reduced_hw_early_init() ACPI callback

2018-03-12T11:32:57+00:00

Some ACPI hardware reduced platforms need to initialize certain devices
defined by the ACPI hardware specification even though in principle
those devices should not be present in an ACPI hardware reduced platform.

To allow that to happen, make it possible to override the generic
x86_init callbacks and provide a custom legacy_pic value, add a new
->reduced_hw_early_init() callback to struct x86_init_acpi and make
acpi_reduced_hw_init() use it.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Rafael J. Wysocki 
Cc: Eric Biederman 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J . Wysocki 
Cc: Thomas Gleixner 
Cc: linux-acpi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180220180506.65523-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar

ACPI, x86/boot: Split out acpi_generic_reduce_hw_init() and export

2018-03-12T11:32:57+00:00

This is a preparation patch to allow override the hardware reduced
initialization on ACPI enabled platforms.

No functional change intended.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Rafael J. Wysocki 
Cc: Eric Biederman 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J . Wysocki 
Cc: Thomas Gleixner 
Cc: linux-acpi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180220180506.65523-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar

ACPI: SPCR: Make SPCR available to x86

2018-02-07T10:39:58+00:00

SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup
an early console.

General fixes include updating Documentation & Kconfig (for x86),
updating comments, and changing parse_spcr() to acpi_parse_spcr(),
and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be
more descriptive.

On x86, many systems have a valid SPCR table but the table version is
not 2 so the table version check must be a warning.

On ARM64 when the kernel parameter earlycon is used both the early console
and console are enabled.  On x86, only the earlycon should be enabled by
by default.  Modify acpi_parse_spcr() to allow options for initializing
the early console and console separately.

Signed-off-by: Prarit Bhargava 
Acked-by: Ingo Molnar 
Reviewed-by: Mark Salter 
Tested-by: Mark Salter 
Signed-off-by: Rafael J. Wysocki

ACPI / x86: boot: Propagate error code in acpi_gsi_to_irq()

2018-01-05T13:10:24+00:00

acpi_get_override_irq() followed by acpi_register_gsi() returns negative
error code on failure.

Propagate it from acpi_gsi_to_irq() to callers.

Signed-off-by: Andy Shevchenko 
[ rjw : Subject/changelog ]
Signed-off-by: Rafael J. Wysocki

ACPI / x86: boot: Don't setup SCI on HW-reduced platforms

2017-12-28T11:36:46+00:00

As per note in 5.2.9 Fixed ACPI Description Table (FADT) chapter of ACPI
specification, on HW-reduced platforma OSPM should ignore fields related
to the ACPI HW register interface, one of which is SCI_INT.

Follow the spec and ignore any configuration done for interrupt line
defined by SCI_INT if FADT specifies a HW-reduced platform.

HW-reduced platforms will still be able to use SCI in case it provides
an override record in MADT table.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI / x86: boot: Use INVALID_ACPI_IRQ instead of 0 for acpi_sci_override_gsi

2017-12-28T11:36:46+00:00

0 is valid hardware interrupt which might be in some cases overridden.
Due to this, switch to INVALID_ACPI_IRQ to mark SCI override not set.

While here, change the type of the variable from int to u32 to match
the GSI type used in the rest of the code.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI / x86: boot: Get rid of ACPI_INVALID_GSI

2017-12-28T11:36:46+00:00

Commit 49e4b84333f3 (ACPI: Use correct IRQ when uninstalling ACPI
interrupt handler) brings a new definition for invalid ACPI IRQ,
i.e. INVALID_ACPI_IRQ, which is defined to 0xffffffff (or -1 for
unsigned value).

Get rid of a former one, which was brought in by commit 2c0a6894df19
(x86, ACPI, irq: Enhance error handling in function acpi_register_gsi()),
in favour of latter.

To clarify the rationale of changing from INT_MIN to ((unsigned)-1)
definition consider the following:
- IRQ 0 is valid one in hardware, so, better not to use it everywhere
  (Linux uses 0 as NO IRQ, though it's another story)
- INT_MIN splits the range into two, while 0xffffffff reserves only the
  last item
- when type casting is done in most cases 0xff, 0xffff is naturally used
  as a marker of invalid HW IRQ: for example PCI INT line 0xff means
  no IRQ assigned by BIOS

Signed-off-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki