Changes in Makefile

19d54020 - firmware: google: Implement cbmem in sysfs driver

Fri, 04 Nov 2022 16:15:28 +0000

firmware: google: Implement cbmem in sysfs driverThe CBMEM area is a downward-growing memory region used by coreboot todynamically allocate tagged data structures ("CBMEM entries") thatremain resident during boot.This implements a driver which exports access to the CBMEM entriesvia sysfs under /sys/bus/coreboot/devices/cbmem-.This implementation is quite versatile. Examples of how it could beused 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 cbmemtooling updates this memory region, and envisioned use cases withcrossystem can benefit from updating memory regions.Link: https://issuetracker.google.com/239604743Cc: 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.orgSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

a28aad66 - firmware: coreboot: Collapse platform drivers into bus core

Wed, 15 Aug 2018 20:37:06 +0000

firmware: coreboot: Collapse platform drivers into bus coreThe DT based and ACPI based platform drivers here do the same thing; mapsome 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 thecoreboot table header to figure out how large of a region to map for thewhole coreboot table and it uses of_iomap() instead of ioremap_cache().A cached or non-cached mapping shouldn't matter here and mapping somesmaller region first before mapping the whole table is just more workbut should be OK. In the end, we can remove two files and combine thecode all in one place making it easier to reason about things.We leave the old Kconfigs in place for a little while longer but makethem hidden and select the previously hidden config option. This wayusers can upgrade without having to know to reselect this config in thefuture. 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 List of files: /linux-6.15/drivers/firmware/google/Makefile

851b4c14 - firmware: coreboot: Add coreboot framebuffer driver

Thu, 25 Jan 2018 01:41:20 +0000

firmware: coreboot: Add coreboot framebuffer driverRegister a simplefb framebuffer when the coreboot table contains aframebuffer entry.Signed-off-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

049a59db - firmware: Google VPD sysfs driver

Wed, 12 Apr 2017 16:56:19 +0000

firmware: Google VPD sysfs driverThis patch introduces the Google Vital Product Data driver.This driver reads Vital Product Data from coreboot tables and thencreates the corresponding sysfs entries under /sys/firmware/vpd toprovide easy access for userspace programs (does not require flashrom).The sysfs is structured as follow: /sys/firmware/vpd |-- ro | |-- key1 | `-- key2 |-- ro_raw |-- rw | `-- key1 `-- rw_rawWhere ro_raw and rw_raw contain the raw VPD partition. The files underro and rw correspond to the key name in the VPD and the the file contentis the value for the key.Signed-off-by: Wei-Ning Huang Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

a1d6f9cf - firmware: google memconsole: Add ARM/ARM64 support

Tue, 28 Mar 2017 16:11:29 +0000

firmware: google memconsole: Add ARM/ARM64 supportThis patch expands the Google firmware memory console driver to alsowork on certain tree based platforms running coreboot, such as ARM/ARM64Chromebooks. This patch now adds another path to find the coreboot tablethrough the device tree. In order to find that, a second levelbootloader must have installed the 'coreboot' compatible device treenode that describes its base address and size.This patch is a rework/split/merge of patches from the chromeos v4.4kernel tree originally authored by: Wei-Ning Huang Julius Werner Brian Norris Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

d384d6f4 - firmware: google memconsole: Add coreboot support

Tue, 28 Mar 2017 16:11:27 +0000

firmware: google memconsole: Add coreboot supportCoreboot (http://www.coreboot.org) allows to save the firmware consoleoutput in a memory buffer. With this patch, the address of this memorybuffer is obtained from coreboot tables on x86 chromebook devicesdeclaring 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 thememconsole sysfs entries.The coreboot_table-acpi driver is responsible for setting the address ofthe coreboot table header when probed. If this address is not yet setwhen memconsole-coreboot is probed, then the probe is deferred byreturning -EPROBE_DEFER.This patch is a rework/split/merge of patches from the chromeos v4.4kernel tree originally authored by: Vadim Bendebury Wei-Ning Huang Yuji Sasaki Duncan Laurie Julius Werner Brian Norris Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

afe9dba4 - firmware: google memconsole: Move specific EBDA parts

Tue, 28 Mar 2017 16:11:26 +0000

firmware: google memconsole: Move specific EBDA partsThis patch splits memconsole.c in 2 parts. One containing thearchitecture-independent part and the other one containing the EBDAspecific part. This prepares the integration of coreboot support for thememconsole.The memconsole driver is now named as memconsole-x86-legacy.Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

e561bc45 - driver: Google Memory Console

Sat, 30 Apr 2011 00:39:25 +0000

driver: Google Memory ConsoleThis patch introduces the 'memconsole' driver.Our firmware gives us access to an in-memory log of the firmware'soutput. This gives us visibility in a data-center of headless machinesas to what the firmware is doing.The memory console is found by the driver by finding a header block inthe EBDA. The buffer is then copied out, and is exported to userland inthe file /sys/firmware/log.Signed-off-by: San Mehat Signed-off-by: Mike Waychison Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile

74c5b31c - driver: Google EFI SMI

Sat, 30 Apr 2011 00:39:19 +0000

driver: Google EFI SMIThe "gsmi" driver bridges userland with firmware specific routines foraccessing hardware.Currently, this driver only supports NVRAM and eventlog information.Deprecated functions have been removed from the driver, though theirop-codes are left in place so that they are not re-used.This driver works by trampolining into the firmware via the smi_commandoutlined in the FADT table. Three protocols are used due to variouslimitations over time, but all are included herein.This driver should only ever load on Google boards, identified by eithera "Google, Inc." board vendor string in DMI, or "GOOGLE" in the OEMstrings of the FADT ACPI table. This logic happens ingsmi_system_valid().Signed-off-by: Duncan Laurie Signed-off-by: Aaron Durbin Signed-off-by: Mike Waychison Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/firmware/google/Makefile