summaryrefslogtreecommitdiff
path: root/src/mainboard/lenovo/t530/cmos.layout
diff options
context:
space:
mode:
authorFelix Held <felix-coreboot@felixheld.de>2024-02-02 11:02:40 +0100
committerFelix Held <felix-coreboot@felixheld.de>2024-02-06 16:28:42 +0000
commitb5d244ccf2159f5dc580ab6faebbd13d8a9ebc1c (patch)
tree5f193c0923b404b7fab7fd2026c3969eeb30ac44 /src/mainboard/lenovo/t530/cmos.layout
parent7a593ab0bb6ad33db39d49745a07b382996cc4e9 (diff)
arch/x86/ioapic: always write IOAPIC ID in set_ioapic_id
Back in the days of the APIC bus, the IOAPIC IDs mustn't overlap with the LAPIC IDs (0 to CONFIG_MAX_CPUS - 1), but since the IOAPIC and LAPIC nowadays talk to each other via the system bus, an IOAPIC ID of 0 is valid. When set_ioapic_id gets called with an IOAPIC ID of 0, it skipped writing the IOAPIC ID to the corresponding IOAPIC register, so the code was relying of the register having the expected default value of the IOAPIC IO 0 for things to work as expected. The case of the IOAPIC ID being 0 is the most common case in coreboot, since that's what register_new_ioapic_gsi0 will end up doing. Fix this issue by not making the io_apic_write call conditional on ioapic_id being non-zero. The only southbridge that doesn't call register_new_ioapic_gsi0, calls set_ioapic_id with the IOAPIC ID 2 for which this won't cause any changes in behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic8538f82a6b10f16eeb228669db197dc8e326ffd Reviewed-on: https://review.coreboot.org/c/coreboot/+/80330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Diffstat (limited to 'src/mainboard/lenovo/t530/cmos.layout')
0 files changed, 0 insertions, 0 deletions