#
8a0a6294 |
|
12-Feb-2024 |
NĂcolas F. R. A. Prado <nfraprado@collabora.com> |
firmware: coreboot: Replace tag with id table in driver struct Switch the plain 'tag' field in struct coreboot_driver for the newly created coreboot_device_id struct, which also contains a tag field and has the benefit of allowing modalias generation, and update all coreboot drivers accordingly. While at it, also add the id table for each driver to the module device table to allow automatically loading the module. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: NĂcolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-3-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
#
fa1ba41c |
|
15-Nov-2022 |
Peng Wu <wupeng58@huawei.com> |
firmware: google: fix a NULL vs IS_ERR() check in cbmem_entry_probe() The devm_memremap() function returns error pointers on error, it doesn't return NULL. Fixes: 19d54020883c ("firmware: google: Implement cbmem in sysfs driver") Signed-off-by: Peng Wu <wupeng58@huawei.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20221115091138.51614-1-wupeng58@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
19d54020 |
|
04-Nov-2022 |
Jack Rosenthal <jrosenth@chromium.org> |
firmware: google: Implement cbmem in sysfs driver The CBMEM area is a downward-growing memory region used by coreboot to dynamically allocate tagged data structures ("CBMEM entries") that remain resident during boot. This implements a driver which exports access to the CBMEM entries via sysfs under /sys/bus/coreboot/devices/cbmem-<id>. This implementation is quite versatile. Examples of how it could be used are given below: * Tools like util/cbmem from the coreboot tree could use this driver instead of finding CBMEM in /dev/mem directly. Alternatively, firmware developers debugging an issue may find the sysfs interface more ergonomic than the cbmem tool and choose to use it directly. * The crossystem tool, which exposes verified boot variables, can use this driver to read the vboot work buffer. * Tools which read the BIOS SPI flash (e.g., flashrom) can find the flash layout in CBMEM directly, which is significantly faster than searching the flash directly. Write access is provided to all CBMEM regions via /sys/bus/coreboot/devices/cbmem-<id>/mem, as the existing cbmem tooling updates this memory region, and envisioned use cases with crossystem can benefit from updating memory regions. Link: https://issuetracker.google.com/239604743 Cc: Stephen Boyd <swboyd@chromium.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: Jack Rosenthal <jrosenth@chromium.org> Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20221104161528.531248-1-jrosenth@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|