kernel/linux.git/drivers/firmware/google, branch v4.19.112

firmware: coreboot: Let OF core populate platform device

2020-01-27T13:49:55+00:00

[ Upstream commit 09ed061a4f56d50758851ca3997510f27115f81b ] Now that the /firmware/coreboot node in DT is populated by the core DT platform code with commit 3aa0582fdb82 ("of: platform: populate /firmware/ node from of_platform_default_populate_init()") we should and can remove the platform device creation here. Otherwise, the of_platform_device_create() call will fail, the coreboot of driver won't be registered, and this driver will never bind. At the same time, we should move this driver to use MODULE_DEVICE_TABLE so that module auto-load works properly when the coreboot device is auto-populated and we should drop the of_node handling that was presumably placed here to hold a reference to the DT node created during module init that no longer happens. Cc: Wei-Ning Huang Cc: Julius Werner Reviewed-by: Brian Norris Cc: Samuel Holland Reviewed-by: Sudeep Holla Fixes: 3aa0582fdb82 ("of: platform: populate /firmware/ node from of_platform_default_populate_init()") Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

gsmi: Fix bug in append_to_eventlog sysfs handler

2019-12-01T08:16:22+00:00

[ Upstream commit 655603de68469adaff16842ac17a5aec9c9ce89b ] The sysfs handler should return the number of bytes consumed, which in the case of a successful write is the entire buffer. Also fix a bug where param.data_len was being set to (count - (2 * sizeof(u32))) instead of just (count - sizeof(u32)). The latter is correct because we skip over the leading u32 which is our param.type, but we were also incorrectly subtracting sizeof(u32) on the line where we were actually setting param.data_len: param.data_len = count - sizeof(u32); This meant that for our example event.kernel_software_watchdog with total length 10 bytes, param.data_len was just 2 prior to this change. To test, successfully append an event to the log with gsmi sysfs. This sample event is for a "Kernel Software Watchdog" > xxd -g 1 event.kernel_software_watchdog 0000000: 01 00 00 00 ad de 06 00 00 00 > cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog > mosys eventlog list | tail -1 14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog Signed-off-by: Duncan Laurie Reviewed-by: Vadim Bendebury Reviewed-by: Stefan Reinauer Signed-off-by: Furquan Shaikh Tested-by: Furquan Shaikh Reviewed-by: Aaron Durbin Reviewed-by: Justin TerAvest [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by: Ross Zwisler Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

firmware: google: increment VPD key_len properly

2019-10-17T20:45:20+00:00

[ Upstream commit 442f1e746e8187b9deb1590176f6b0ff19686b11 ] Commit 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data") adds length checks, but the new vpd_decode_entry() function botched the logic -- it adds the key length twice, instead of adding the key and value lengths separately. On my local system, this means vpd.c's vpd_section_create_attribs() hits an error case after the first attribute it parses, since it's no longer looking at the correct offset. With this patch, I'm back to seeing all the correct attributes in /sys/firmware/vpd/... Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data") Cc: Cc: Hung-Te Lin Signed-off-by: Brian Norris Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20190930214522.240680-1-briannorris@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

firmware: google: check if size is valid when decoding VPD data

2019-09-21T05:16:44+00:00

commit 4b708b7b1a2c09fbdfff6b942ebe3a160213aacd upstream. The VPD implementation from Chromium Vital Product Data project used to parse data from untrusted input without checking if the meta data is invalid or corrupted. For example, the size from decoded content may be negative value, or larger than whole input buffer. Such invalid data may cause buffer overflow. To fix that, the size parameters passed to vpd_decode functions should be changed to unsigned integer (u32) type, and the parsing of entry header should be refactored so every size field is correctly verified before starting to decode. Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files") Signed-off-by: Hung-Te Lin Cc: stable Reviewed-by: Guenter Roeck Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Unmap ioregion after device population

2018-11-13T19:08:37+00:00

[ Upstream commit 20edec388277b62ddfddb8b2b376a937a2cd6d1b ] Both callers of coreboot_table_init() ioremap the pointer that comes in but they don't unmap the memory on failure. Both of them also fail probe immediately with the return value of coreboot_table_init(), leaking a mapping when it fails. The mapping isn't necessary at all after devices are populated either, so we can just drop the mapping here when we exit the function. Let's do that to simplify the code a bit and plug the leak. Cc: Wei-Ning Huang Cc: Julius Werner Cc: Brian Norris Cc: Samuel Holland Fixes: 570d30c2823f ("firmware: coreboot: Expose the coreboot table as a bus") Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Fix section enabled flag on vpd_section_destroy

2018-08-02T08:34:12+00:00

static struct ro_vpd and rw_vpd are initialized by vpd_sections_init() in vpd_probe() based on header's ro and rw sizes. In vpd_remove() vpd_section_destroy() performs deinitialization based on enabled flag, which is set to true by vpd_sections_init(). This leads to call of vpd_section_destroy() on already destroyed section for probe-release-probe-release sequence if first probe performs ro_vpd initialization and second probe does not initialize it. The patch adds changing enabled flag on vpd_section_destroy and adds cleanup on the error path of vpd_sections_init. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Add coreboot framebuffer driver

2018-04-23T11:37:19+00:00

Register a simplefb framebuffer when the coreboot table contains a framebuffer entry. Signed-off-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Remove unused coreboot_table_find

2018-04-23T11:37:19+00:00

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 Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Probe via coreboot bus

2018-04-23T11:37:19+00:00

Remove the ad-hoc coreboot table search. Now the driver will only be probed when the necessary coreboot table entry has already been found. Furthermore, since the coreboot bus takes care of creating the device, a separate platform device is no longer needed. Signed-off-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman

firmware: memconsole: Probe via coreboot bus

2018-04-23T11:37:19+00:00

Remove the ad-hoc coreboot table search. Now the driver will only be probed when the necessary coreboot table entry has already been found. Signed-off-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman