#
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>
|
#
3b293487 |
|
12-Jan-2023 |
Kees Cook <keescook@chromium.org> |
firmware: coreboot: Check size of table entry and use flex-array The memcpy() of the data following a coreboot_table_entry couldn't be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it easier to reason about, add an explicit flexible array member to struct coreboot_device so the entire entry can be copied at once. Additionally, validate the sizes before copying. Avoids this run-time false positive warning: memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8) Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/ Cc: Jack Rosenthal <jrosenth@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.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>
|
#
5f680532 |
|
26-Jan-2021 |
Uwe Kleine-König <uwe@kleine-koenig.org> |
firmware: google: make coreboot driver's remove callback return void All coreboot drivers return 0 unconditionally in their remove callback. Also the device core ignores the return value of the struct bus_type::remove(), so make the coreboot remove callback return void instead of giving driver authors the illusion they could return an error code here. All drivers are adapted accordingly. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210126215339.706021-1-uwe@kleine-koenig.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d9523678 |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 287 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license v2 0 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 23 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.115786599@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
381e9760 |
|
10-May-2019 |
Stephen Boyd <swboyd@chromium.org> |
firmware: google: coreboot: Drop unnecessary headers These headers aren't used by the files they're included in, so drop them. The memconsole file uses memremap() though, so include io.h there so that the include is explicit. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Cc: Guenter Roeck <groeck@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
35463503 |
|
10-May-2019 |
Stephen Boyd <swboyd@chromium.org> |
firmware: google: Add a module_coreboot_driver() macro and use it Remove some boiler plate code we have in three drivers with a single line each time. This also gets us a free assignment of the driver .owner field, making these drivers work better as modules. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Cc: Guenter Roeck <groeck@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a28aad66 |
|
15-Aug-2018 |
Stephen Boyd <swboyd@chromium.org> |
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
851b4c14 |
|
24-Jan-2018 |
Samuel Holland <samuel@sholland.org> |
firmware: coreboot: Add coreboot framebuffer driver Register a simplefb framebuffer when the coreboot table contains a framebuffer entry. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b616cf53 |
|
24-Jan-2018 |
Samuel Holland <samuel@sholland.org> |
firmware: coreboot: Remove unused coreboot_table_find Now that all users of the coreboot_table_find function have been updated to hang off the coreboot table bus instead, remove it. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
570d30c2 |
|
24-Jan-2018 |
Samuel Holland <samuel@sholland.org> |
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d384d6f4 |
|
28-Mar-2017 |
Thierry Escande <thierry.escande@collabora.com> |
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|