This allows boards to specify which PSPP policy (basically a dynamic
trade-off between power consumption and PCIe link speed) should be used
and also makes sure that the boards are using the expected PSPP policy
and not just the UPD default from the FSP binary that has already
changed once during the development.
BUG=b:188793754
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1b6459b2984711e72b79f5d4d90e04cb4b78d512
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54930
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TBT PowerResource _ON/_OFF methods are currently invoked by _PS0 and
_PS3 respectively. It is defined for ACPI driver to call _ON and _OFF
methods. This change drops the _PS0 and _PS3 call for _ON/_OFF and
returns TBT PowerResource declaration in the _PR0 and _PR3, then ACPI
driver will call the TBT PowerResource _ON and _OFF methods.
BUG=b:188891878
TEST=Traced both of TBT _ON and _OFF methods invocation and execution
at run time. Verified TBT's power_state to be D3Cold.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I398b3f58ec89f98673cbbe633149d31188ec3351
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There is a function to fetch the fit table at both the regular address
and the TS address. So reuse that function instead of attempting to
find the TS fit using some pointer aritmetics that is incorrect.
Change-Id: I9114f5439202ede7e01cd0fcbb1e3c4cdb8698b0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54680
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generic Initiator Affinity structure is introdcued in ACPI spec 6.3.
This structure is used to define NUMA affinity domain which is
established by generic initiator (such as by CXL device).
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ic6ef01c59e02f30dc290f27e741027e16f5d8359
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
No board currently uses AMD PI 00630F01 so remove it.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If270c2a979346029748230952caba78a5e763d75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
No board uses AMD PI 00630F01, so drop it. And drop a single reference
to the now-removed `NORTHBRIDGE_AMD_PI_00630F01` Kconfig option inside
the `drivers/amd/agesa/acpi_tables.c` file.
Change-Id: Ibc45a4a6041220ed22273c1d41f9b796e1acb901
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54897
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Microcode header supports advertising support for only one CPU
signature and processor flags. If there are multiple processor
families supported by this microcode blob, they are mentioned in
the extended signature table.
Add support to parse the extended processor signature table to
determine if the microcode blob supports the currently running CPU.
BUG=b:182234962
TEST=Booted ADL brya system with a processor whose signature/pf are
in the extended signature table of a microcode patch. Was able to
match and load the patch appropriately.
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Change-Id: I1466caf4a4ba1f9a0214bdde19cce57dd65dacbd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch also adds the additional 10 MCAX registers to the BERT MSR
error record.
BUG=b:186038401
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I31912d3b3e77e905f64b6143042f5e7f73db7407
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch includes changes to update the soundwire master count.
Change-Id: Iffaf90569c19fb5ca3ce4775cc6dc6f8093f7c52
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change implements the valid_tbt_auth
function. Thunderbolt DSD and its corresponding IMR_VAID will be
present to kernel only if its authentication is successful.
BUG=b:188695995
TEST=Validated TGL TBT firmware authentication and its IMR_VALID
into SSDT which is properly present to kernel.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I3c9dda341ae6f19a2a8c85f92edda3dfa08c917a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change adds the TBT firmware IMR
status register offset and its authentication valid bit for
valid_tbt_auth function usage.
BUG=b:188695995
TEST=Built coreboot image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I742a00b6b58c45c1261f06b06a94346ad0a74829
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54888
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After Thunderbolt firmware is downloaded to IMR, its authentication
validity needs to be checked. This change adds the TBT firmware IMR
status register offset and its authentication valid bit for
valid_tbt_auth function usage.
BUG=b:188695995
TEST=Built Voxel coreboot image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ia25827f18a10bf4d2dcabfe81565ac326851af3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54709
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All relevant USB phy settings can now be controlled via devicetree.
The given values are the AMD default ones.
For proper tuning procedure and values contact AMD.
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Change-Id: Ie8d08bde54f8c0cb8202ba111b9c7a9bd33fa03e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The AMD FSP is using a new structure for USB and USB C phy settings.
This patch removes old, unused structures, adds the new one and
enables the devicetree interface for it.
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Change-Id: I011ca40a334e4fd26778ca7f18b653298b14019b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Building google/sarien with a 64-bit compiler (x86_64-linux-gnu) fails
with the error below.
src/ec/google/wilco/mailbox.c: In function 'wilco_ec_transfer':
src/ec/google/wilco/mailbox.c:184:43: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
184 | printk(BIOS_ERR, "%s: data too short (%lu bytes, expected %zu)",
| ~~^
| |
| long unsigned int
| %u
185 | __func__, rs.data_size - skip_size, msg->response_size);
| ~~~~~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
`data_size` has type `uint16_t`, and `skip_size` has type `size_t`,
whose size differs in 32-bit (unsigned int) and 64-bit (unsigned long).
So use the length modifier `z` for a `size_t` argument.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Change-Id: Ida27323daeed9b8ff487302d0f3d6fcce0bbb705
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie
The FSP-M/S/T related headers added are generated as per FSP v3162.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ie6e6db704bcf86034fc9a3423101f0391ba2327e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54869
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Remove the extra UAB devices in xhci.asl
2. Update SD controller ADR in scs.asl
3. Remove the unused SCS PID
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I1906fb4e6893dc5e2b0bc8d85f4a7b2efc85c3a4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54867
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update SA & IGD DIDs table as per latest EDS (Doc no: 601458).
Add extra SKUs and fix the mismatched SKU numbers accordingly.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I62fd9e6a7cf0fc6f541f3d6d9edd31d41db7279f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Coverity found resource leak in test setup function in error block.
Add malloc result check and free in error handling to silence Coverity.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Found-by: Coverity CID 1446760
Change-Id: Icf746df27167047fa3cf8f5df09fced20863f76d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Configure GPIO CAM_PDN5 (AP_XHCI_INIT_DONE) as output, so that
payloads (for example depthcharge) can assert it to notify EC to enable
USB VBUS.
BUG=b:187149602
TEST=emerge-asurada coreboot
BRANCH=asurada
Change-Id: I3bf63f91b8057e35be2780024a8b398c3044729b
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54902
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Incorrect size of the einj structure was being used, which created an
invalid checksum message by the OS. This patch fixes the issue.
Test=Booted to Linux on Deltalake mainboard and verified invalid checksum
message is not logged in syslog. Exact message -> 'ACPI BIOS Warning
(bug): Incorrect checksum in table [EINJ] - 0xDA, should be 0xD9'
Change-Id: I2b1722d6960d4a62d14fb02ac5e8838397e12f92
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54787
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prepare to allow using other backends to store options.
Change-Id: I3f838d27bf476207c6dc8f2c1f15c3fa9ae47d87
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 88dcb3179b (src: Retype option API to use unsigned integers)
changed the option API to use unsigned integers, but missed this.
Change-Id: I5deb17157db41c40cc72078e2af9cf65bdbe0581
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
scan-build found a dead assignment, that the value stored to `res` is
never read. Use `pci_dev_read_resources()` instead, as done in
`sb/intel/common/smbus_ops.c` since commit 5f734327
(sb/intel/common/smbus_ops.c: Clean up read resources) avoiding the
assignment.
Change-Id: Ic59063b05a45dca411bf5b56c1abf3dd66ff0437
Found-by: scan-build (coreboot toolchain v0ad5fbd48d 2020-12-24 - clang version 11.0.0)
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Build of the entire smm-class is skipped if we have
HAVE_SMI_HANDLER=n.
Change-Id: I64bdcb28a996609111861ebafe172493b0650354
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54852
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Rocky Phagura
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
haboki/habokay is the same design as drawlat/drawcia, and differs only
in replacing Cr50 with discrete TPM.
BUG=b:187094464
TEST=FW_NAME=haboki emerge-keeby coreboot
Cq-Depend: chrome-internal:3850094
Change-Id: Id866927b7041c5bf1c73fb4f0c03798eb61efa79
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54755
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ESPI_SLAVE_CHANNEL_READY is a read-only bit from the host perspective.
It is set when the eSPI peripheral has configured the channel.
We actually want to set the ESPI_SLAVE_CHANNEL_ENABLE flag. This never
caused an issue before because the peripheral channel is enabled by
default after PLTRST# is deasserted. This does fix the case where
periph_ch_en == 0. It now properly clears the enable flag.
BUG=b:188188172, b:188935533
TEST=Boot guybrush to OS, perform warm reset
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I24e0734d5652601ae9c967da528fec5e3f780991
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add new memory MT53E512M32D1NP-046 WT:B in the mem_parts_used.txt and
generate the SPD ID for the parts.
BUG=b:183057749
BRANCH=dedede
TEST=Build the cret board.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Ib797af858e8f7ea275291e552102db74f4724aad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54747
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromeEC might take longer than 1ms for the peripheral channel to be
enabled. The PLTRST# interrupt handler takes about ~539us.
This doesn't account for the time it takes for the interrupt handler
to be scheduled. Increasing the timeout to 10ms gives ample time.
BUG=b:188188172, b:188935533
TEST=Boot guybrush and no longer see channel enable errors
Suggested-by: Rob Barnes <robbarnes@google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib6db577bf06175ceb17b446af706ad8c9f891481
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54788
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The set_ts_fit_ptr makefile target was never a dependency of another
target and therefore not used.
Change-Id: Ie6b20164fce0dc406a28b4c1b9f41a79c68c27d7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
'-t' is not needed when setting the FIT pointer and breaks
it as '-t' needs an argument so the $(TS_OPTIONS) is not properly
decoded.
Change-Id: I61a3ac1eda42e04152a7d10953bfb8407813d0f3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54679
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Make sure the fit pointer is set up before entries are added.
Change-Id: I285fbb830a52e43cde5e8db9569a64dafb4408df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
This reverts commit 2f8a7046bb.
Reason for revert: CB:54752 makes this unnecessary
Change-Id: I3ad0bcafe50e3eafb9a106720c6c9ea5cb0efc4f
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54789
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the introduction of fw_config support in coreboot, it is possible
for mainboards to control the state of a device (on/off) in ramstage
using fw_config probe conditions. However, the device tree in
immutable in all other stages and hence `is_dev_enabled()` does not
really reflect the true state as in ramstage.
This change adds a call to `fw_config_probe_dev()` in
`is_dev_enabled()` when device tree is immutable (by checking
DEVTREE_EARLY) to first check if device is disabled because of device
probe conditions. If so, then it reports device as being
disabled. Else, dev->enabled is used to report the device state.
This allows early stages (bootblock, romstage) to use
`is_dev_enabled()` to get the true state of the device by taking probe
conditions into account and eliminates the need for each caller to
perform their own separate probing.
Change-Id: Ifede6775bda245cba199d3419aebd782dc690f2c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54752
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`probe_list` member in `struct device` is present in all stages,
however, util/sconfig emits the list only when !DEVTREE_EARLY. This
change ensures that `probe_list` is emitted in all stages. In follow
up changes, this is used to get the correct device state using probe
conditions.
Change-Id: I61f7e909d48b616ac2127a5a9f36bdf4817a5165
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
fw_config is unprovisioned in the factory for the first boot. This is
the only case where fw_config is left unprovisioned. On first boot in
factory, fw_config gets correctly provisioned by the factory
toolkit. When fw_config is unprovisioned, it is not always possible to
make a guess which device to enable/disable since there can be certain
conflicting devices which can never be enabled at the same time. That
is the reason the original implementation of fw_config library kept
fw_config as 0 when it was unprovisioned.
CB:47956 ("fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisioned")
added support for a special unprovisioned value to allow any callers
to identify this factory boot condition and take any appropriate
action required for this boot (Ideally, this would just involve
configuring any boot devices essential to getting to OS. All other
non-essential devices can be kept disabled until fw_config is properly
provisioned). However, CB:47956 missed handling the
`fw_config_probe()` function and resulted in silent change in behavior.
This change fixes the regression introduced by CB:47956 and returns
`false` in `fw_config_probe()` if fw_config is not provisioned yet.
Change-Id: Ic22cd650d3eb3a6016fa2e2775ea8272405ee23b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54750
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Felix Held