kernel/linux.git/drivers/firmware/google/coreboot_table.h, branch v6.18.21

firmware: coreboot: store owner from modules with coreboot_driver_register()

2024-04-03T07:09:26+00:00

Modules registering driver with coreboot_driver_register() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Moving the .owner setting code to the core this effectively fixes missing .owner in framebuffer-coreboot, memconsole-coreboot and vpd drivers. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240330-module-owner-coreboot-v1-1-ddba098b6dcf@linaro.org Signed-off-by: Tzung-Bi Shih

firmware: coreboot: Replace tag with id table in driver struct

2024-02-17T00:53:06+00:00

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 Reviewed-by: Brian Norris Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-3-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih

firmware: coreboot: Check size of table entry and use flex-array

2023-01-13T23:22:03+00:00

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 Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/ Cc: Jack Rosenthal Cc: Guenter Roeck Cc: Julius Werner Cc: Brian Norris Cc: Stephen Boyd Cc: Greg Kroah-Hartman Signed-off-by: Kees Cook Reviewed-by: Julius Werner Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org Reviewed-by: Stephen Boyd Reviewed-by: Jack Rosenthal Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org

firmware: google: Implement cbmem in sysfs driver

2022-11-10T17:51:56+00:00

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-. 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-/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 Cc: Tzung-Bi Shih Reviewed-by: Guenter Roeck Reviewed-by: Julius Werner Tested-by: Jack Rosenthal Signed-off-by: Jack Rosenthal Link: https://lore.kernel.org/r/20221104161528.531248-1-jrosenth@chromium.org Signed-off-by: Greg Kroah-Hartman

firmware: google: make coreboot driver's remove callback return void

2021-02-09T11:12:43+00:00

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 Link: https://lore.kernel.org/r/20210126215339.706021-1-uwe@kleine-koenig.org Signed-off-by: Greg Kroah-Hartman

Merge 5.2-rc4 into char-misc-next

2019-06-09T07:11:21+00:00

We want the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 287

2019-06-05T15:36:37+00:00

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 Reviewed-by: Alexios Zavras Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.115786599@linutronix.de Signed-off-by: Greg Kroah-Hartman

firmware: google: coreboot: Drop unnecessary headers

2019-05-24T18:55:04+00:00

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 Cc: Julius Werner Cc: Brian Norris Cc: Samuel Holland Cc: Guenter Roeck Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Reviewed-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman

firmware: google: Add a module_coreboot_driver() macro and use it

2019-05-24T18:55:04+00:00

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 Cc: Julius Werner Cc: Brian Norris Cc: Samuel Holland Cc: Guenter Roeck Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Reviewed-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Collapse platform drivers into bus core

2018-09-14T13:37:23+00:00

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 Cc: Julius Werner Cc: Brian Norris Cc: Samuel Holland Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Signed-off-by: Greg Kroah-Hartman