coreboot-kgpe-d16/src/vendorcode/google/chromeos/sar.c
Julius Werner 834b3ecd7c cbfs: Simplify load/map API names, remove type arguments
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).

cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.

Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-02 22:13:17 +00:00

116 lines
3.4 KiB
C
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

/* SPDX-License-Identifier: GPL-2.0-only */
#include <cbfs.h>
#include <console/console.h>
#include <lib.h>
#include <types.h>
#include <string.h>
#include <sar.h>
#include <drivers/vpd/vpd.h>
#define WIFI_SAR_CBFS_FILENAME "wifi_sar_defaults.hex"
#define CROS_VPD_WIFI_SAR_NAME "wifi_sar"
static int load_sar_file_from_cbfs(void *buf, size_t buffer_size)
{
const char *filename = get_wifi_sar_cbfs_filename();
if (filename == NULL)
filename = WIFI_SAR_CBFS_FILENAME;
return cbfs_load(filename, buf, buffer_size);
}
/* Retrieve the wifi SAR limits data from VPD and decode it
For VPD: key,value pair is in this format
"wifi_sar"=[<WRDD><EWRD>][WGDS]
WIFI SAR data in CBFS file is expected in same format: [<WRDD><EWRD>][WGDS]
[<WRDD><EWRD>] = NUM_SAR_LIMITS * BYTES_PER_SAR_LIMIT bytes.
[WGDS]=[WGDS_VERSION][WGDS_DATA]
For [WGDS_VERSION] 0x00,
[WGDS_DATA] = [GROUP#0][GROUP#1][GROUP#2]
[GROUP#<i>] =
[2.4Ghz Max Allowed][2.4Ghz Chain A Offset]
[2.4Ghz Chain B Offset][5Ghz Max Allowed]
[5Ghz Chain A Offset][5Ghz Chain B Offset]
[GROUP#0] is for FCC
[GROUP#1] is for Europe/Japan
[GROUP#2] is for ROW
*/
int get_wifi_sar_limits(struct wifi_sar_limits *sar_limits)
{
const char *wifi_sar_limit_key = CROS_VPD_WIFI_SAR_NAME;
/* vpd_gets() reads in one less than size characters from the VPD
* with a terminating null byte ('\0') stored as the last character into
* the buffer, thus the increasing by 1 for the buffer size. */
char wifi_sar_limit_str[2 * sizeof(struct wifi_sar_limits) + 1];
uint8_t bin_buffer[sizeof(struct wifi_sar_limits)];
const size_t buffer_size = ARRAY_SIZE(wifi_sar_limit_str);
size_t sar_cbfs_len, sar_expected_len, bin_buff_adjusted_size;
/* keep it backward compatible. Some older platform are shipping
without GEO SAR and so older wifi_sar VPD key */
sar_expected_len = buffer_size;
bin_buff_adjusted_size = sizeof(struct wifi_sar_limits);
if (!CONFIG(GEO_SAR_ENABLE)) {
sar_expected_len = buffer_size -
sizeof(struct wifi_sar_delta_table) *
sizeof(uint8_t) * 2;
bin_buff_adjusted_size = sizeof(struct wifi_sar_limits) -
sizeof(struct wifi_sar_delta_table);
}
/* Try to read the SAR limit entry from VPD */
if (!vpd_gets(wifi_sar_limit_key, wifi_sar_limit_str,
buffer_size, VPD_RO_THEN_RW)) {
printk(BIOS_DEBUG, "Could not locate '%s' in VPD.\n",
wifi_sar_limit_key);
if (!CONFIG(WIFI_SAR_CBFS))
return -1;
printk(BIOS_DEBUG, "Checking CBFS for default SAR values\n");
sar_cbfs_len = load_sar_file_from_cbfs(
(void *) wifi_sar_limit_str,
sar_expected_len);
if (sar_cbfs_len != sar_expected_len) {
printk(BIOS_ERR, "%s has bad len in CBFS\n",
WIFI_SAR_CBFS_FILENAME);
return -1;
}
} else {
/* VPD key "wifi_sar" found. strlen is checked with addition of
* 1 as we have created buffer size 1 char larger for the reason
* mentioned at start of this function itself */
if (strlen(wifi_sar_limit_str) + 1 != sar_expected_len) {
printk(BIOS_ERR, "WIFI SAR key has bad len in VPD\n");
return -1;
}
}
/* Decode the heximal encoded string to binary values */
if (hexstrtobin(wifi_sar_limit_str, bin_buffer, bin_buff_adjusted_size)
< bin_buff_adjusted_size) {
printk(BIOS_ERR, "Error: wifi_sar contains non-hex value!\n");
return -1;
}
memset(sar_limits, 0, sizeof(*sar_limits));
memcpy(sar_limits, bin_buffer, bin_buff_adjusted_size);
return 0;
}
__weak
const char *get_wifi_sar_cbfs_filename(void)
{
return WIFI_SAR_CBFS_FILENAME;
}