The Kconfig lint tool checks for cases of the code using BOOL type Kconfig options directly instead of with CONFIG() and will print out warnings about it. It gets confused by these references in comments and strings. To fix it so that it can find the real issues, just update these as we would with real issues. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
26 lines
909 B
C
26 lines
909 B
C
/* SPDX-License-Identifier: GPL-2.0-only */
|
|
|
|
#include <arch/bootblock.h>
|
|
#include <device/pci_ops.h>
|
|
#include "haswell.h"
|
|
|
|
void bootblock_early_northbridge_init(void)
|
|
{
|
|
uint32_t reg;
|
|
|
|
/*
|
|
* The "io" variant of the config access is explicitly used to setup the PCIEXBAR
|
|
* because CONFIG(MMCONF_SUPPORT) is set to true. That way, all subsequent
|
|
* non-explicit config accesses use MCFG. This code also assumes that
|
|
* bootblock_northbridge_init() is the first thing called in the non-asm
|
|
* boot block code. The final assumption is that no assembly code is using
|
|
* the CONFIG(MMCONF_SUPPORT) option to do PCI config acceses.
|
|
*
|
|
* The PCIEXBAR is assumed to live in the memory mapped IO space under 4GiB.
|
|
*/
|
|
reg = 0;
|
|
pci_io_write_config32(HOST_BRIDGE, PCIEXBAR + 4, reg);
|
|
reg = CONFIG_MMCONF_BASE_ADDRESS | 4 | 1; /* 64MiB - 0-63 buses. */
|
|
pci_io_write_config32(HOST_BRIDGE, PCIEXBAR, reg);
|
|
}
|