Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7 |
|
#
a769b05e |
| 17-Jan-2023 |
Khazhismel Kumykov <khazhy@chromium.org> |
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI var
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.
Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: stable <stable@kernel.org> Signed-off-by: Khazhismel Kumykov <khazhy@google.com> Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ade7fd90 |
| 17-Jan-2023 |
Johan Hovold <johan+linaro@kernel.org> |
efi: efivars: drop kobject from efivars_register()
Since commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs interface") and the removal of the sysfs interface there are no users of t
efi: efivars: drop kobject from efivars_register()
Since commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs interface") and the removal of the sysfs interface there are no users of the efivars kobject.
Drop the kobject argument from efivars_register() and add a new efivar_is_available() helper in favour of the old efivars_kobject().
Note that the new helper uses the prefix 'efivar' (i.e. without an 's') for consistency with efivar_supports_writes() and the rest of the interface (except the registration functions).
For the benefit of drivers with optional EFI support, also provide a dummy implementation of efivar_is_available().
Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
1179083f |
| 09-Sep-2022 |
Guilherme G. Piccoli <gpiccoli@igalia.com> |
firmware: google: test spinlock on panic path to avoid lockups
Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomi
firmware: google: test spinlock on panic path to avoid lockups
Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown.
With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang.
Link: https://lkml.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Reviewed-by: Evan Green <evgreen@chromium.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: David Gow <davidgow@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
3e081438 |
| 09-Sep-2022 |
Guilherme G. Piccoli <gpiccoli@igalia.com> |
firmware: google: Test spinlock on panic path to avoid lockups
Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic
firmware: google: Test spinlock on panic path to avoid lockups
Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown.
With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang.
Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: David Gow <davidgow@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Petr Mladek <pmladek@suse.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
a5dba093 |
| 09-Sep-2022 |
Guilherme G. Piccoli <gpiccoli@igalia.com> |
firmware: google: Test spinlock on panic path to avoid lockups
[ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]
Currently the gsmi driver registers a panic notifier as well as reboot an
firmware: google: Test spinlock on panic path to avoid lockups
[ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]
Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown.
With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang.
Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: David Gow <davidgow@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Petr Mladek <pmladek@suse.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
f39650de |
| 30-Jun-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
kernel.h: split out panic and oops helpers
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helper
kernel.h: split out panic and oops helpers
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helpers.
There are several purposes of doing this: - dropping dependency in bug.h - dropping a loop by moving out panic_notifier.h - unload kernel.h from something which has its own domain
At the same time convert users tree-wide to use new headers, although for the time being include new header back to kernel.h to avoid twisted indirected includes for existing users.
[akpm@linux-foundation.org: thread_info.h needs limits.h] [andriy.shevchenko@linux.intel.com: ia64 fix] Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com
Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Co-developed-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Corey Minyard <cminyard@mvista.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Wei Liu <wei.liu@kernel.org> Acked-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: Helge Deller <deller@gmx.de> # parisc Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
b0077b4b |
| 01-Apr-2021 |
Evan Green <evgreen@chromium.org> |
firmware: google: Enable s0ix logging by default
Many moons ago, support was added to the SMI handlers to log s0ix entry and exit. Early iterations of firmware on Apollo Lake correctly returned "uns
firmware: google: Enable s0ix logging by default
Many moons ago, support was added to the SMI handlers to log s0ix entry and exit. Early iterations of firmware on Apollo Lake correctly returned "unsupported" for this new command they did not recognize, but unfortunately also contained a quirk where this command would cause them to power down rather than resume from s0ix.
Fixes for this quirk were pushed out long ago, so all APL devices still in the field should have updated firmware. As such, we no longer need to have the s0ix_logging_enable be opt-in, where every new platform has to add this to their kernel commandline parameters. Change it to be on by default.
In theory we could remove the parameter altogether: updated versions of Chrome OS containing a kernel with this change would also be coupled with firmware that behaves properly with these commands. Eventually we should probably do that. For now, convert this to an opt-out parameter so there's an emergency valve for people who are deliberately running old firmware, or as an escape hatch in case of unforeseen regressions.
Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20210401140430.1.Ie141e6044d9b0d5aba72cb08857fdb43660c54d3@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17 |
|
#
17adb469 |
| 22-Oct-2020 |
Furquan Shaikh <furquan@google.com> |
firmware: gsmi: Drop the use of dma_pool_* API functions
GSMI driver uses dma_pool_* API functions for buffer allocation because it requires that the SMI buffers are allocated within 32-bit physical
firmware: gsmi: Drop the use of dma_pool_* API functions
GSMI driver uses dma_pool_* API functions for buffer allocation because it requires that the SMI buffers are allocated within 32-bit physical address space. However, this does not work well with IOMMU since there is no real device and hence no domain associated with the device.
Since this is not a real device, it does not require any device address(IOVA) for the buffer allocations. The only requirement is to ensure that the physical address allocated to the buffer is within 32-bit physical address space. This is because the buffers have nothing to do with DMA at all. It is required for communication with firmware executing in SMI mode which has access only to the bottom 4GiB of memory. Hence, this change switches to using a SLAB cache created with SLAB_CACHE_DMA32 that guarantees that the allocation happens from the DMA32 memory zone. All calls to dma_pool_* are replaced with kmem_cache_*.
In addition to that, all the code for managing the dma_pool for GSMI platform device is dropped.
Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20201022071550.1192947-1-furquan@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11 |
|
#
9846d860 |
| 23-Sep-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi: gsmi: fix false dependency on CONFIG_EFI_VARS
The gsmi code does not actually rely on CONFIG_EFI_VARS, since it only uses the efivars abstraction that is included unconditionally when CONFIG_EF
efi: gsmi: fix false dependency on CONFIG_EFI_VARS
The gsmi code does not actually rely on CONFIG_EFI_VARS, since it only uses the efivars abstraction that is included unconditionally when CONFIG_EFI is defined. CONFIG_EFI_VARS controls the inclusion of the code that exposes the sysfs entries, and which has been deprecated for some time.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12 |
|
#
e4924ee2 |
| 18-Nov-2019 |
Arthur Heymans <arthur@aheymans.xyz> |
firmware: google: Probe for a GSMI handler in firmware
Currently this driver is loaded if the DMI string matches coreboot and has a proper smi_command in the ACPI FADT table, but a GSMI handler in S
firmware: google: Probe for a GSMI handler in firmware
Currently this driver is loaded if the DMI string matches coreboot and has a proper smi_command in the ACPI FADT table, but a GSMI handler in SMM is an optional feature in coreboot.
So probe for a SMM GSMI handler before initializing the driver. If the smihandler leaves the calling argument in %eax in the SMM save state untouched that generally means the is no handler for GSMI.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20191118101934.22526-4-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c6e7af05 |
| 18-Nov-2019 |
Arthur Heymans <arthur@aheymans.xyz> |
firmware: google: Unregister driver_info on failure and exit in gsmi
Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit.
Signed-off
firmware: google: Unregister driver_info on failure and exit in gsmi
Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20191118101934.22526-3-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
09c434b8 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier for more missed files
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have MODULE_LICENCE("GPL*") inside which
treewide: Add SPDX license identifier for more missed files
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have MODULE_LICENCE("GPL*") inside which was used in the initial scan/conversion to ignore the file
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14 |
|
#
8942b2d5 |
| 12-Oct-2018 |
Furquan Shaikh <furquan@chromium.org> |
gsmi: Add GSMI commands to log S0ix info
Add new GSMI commands (GSMI_CMD_LOG_S0IX_SUSPEND = 0xa, GSMI_CMD_LOG_S0IX_RESUME = 0xb) that allow firmware to log any information during S0ix suspend/resume
gsmi: Add GSMI commands to log S0ix info
Add new GSMI commands (GSMI_CMD_LOG_S0IX_SUSPEND = 0xa, GSMI_CMD_LOG_S0IX_RESUME = 0xb) that allow firmware to log any information during S0ix suspend/resume paths.
Traditional ACPI suspend S3 involves BIOS both during the suspend and the resume paths. However, modern suspend type like S0ix does not involve firmware on either of the paths. This command gives the firmware an opportunity to log any required information about the suspend and resume operations e.g. wake sources.
Additionally, this change adds a module parameter to allow platforms to specifically enable S0ix logging if required. This prevents any other platforms from unnecessarily making a GSMI call which could have any side-effects.
Tested by verifying that wake sources are correctly logged in eventlog.
Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Rajat Jain <rajatja@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d31655ba |
| 12-Oct-2018 |
Duncan Laurie <dlaurie@chromium.org> |
gsmi: Remove autoselected dependency on EFI and EFI_VARS
Instead of selecting EFI and EFI_VARS automatically when GSMI is enabled let that portion of the driver be conditionally compiled if EFI and
gsmi: Remove autoselected dependency on EFI and EFI_VARS
Instead of selecting EFI and EFI_VARS automatically when GSMI is enabled let that portion of the driver be conditionally compiled if EFI and EFI_VARS are enabled.
This allows the rest of the driver (specifically event log) to be used if EFI_VARS is not enabled.
To test: 1) verify that EFI_VARS is not automatically selected when CONFIG_GOOGLE_GSMI is enabled 2) verify that the kernel boots on Link and that GSMI event log is still available and functional 3) specifically boot the kernel on Alex to ensure it does not try to load efivars and that gsmi also does not load because it is not in the supported DMI table
Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Ben Zhang <benzh@chromium.org> Signed-off-by: Filipe Brandenburger <filbranden@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
255d7447 |
| 12-Oct-2018 |
Duncan Laurie <dlaurie@chromium.org> |
gsmi: Add coreboot to list of matching BIOS vendors
In order to use this coreboot needs board support for: CONFIG_ELOG=y CONFIG_ELOG_GSMI=y
And the kernel driver needs enabled: CONFIG_GOOGLE_GSMI=y
gsmi: Add coreboot to list of matching BIOS vendors
In order to use this coreboot needs board support for: CONFIG_ELOG=y CONFIG_ELOG_GSMI=y
And the kernel driver needs enabled: CONFIG_GOOGLE_GSMI=y
To test, verify that clean shutdown event is added to the log:
> mosys eventlog list | grep 'Clean Shutdown' 11 | 2012-06-25 09:49:24 | Kernl Event | Clean Shutdown
Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Justin TerAvest <teravest@chromium.org> [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
655603de |
| 12-Oct-2018 |
Duncan Laurie <dlaurie@chromium.org> |
gsmi: Fix bug in append_to_eventlog sysfs handler
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 pa
gsmi: Fix bug in append_to_eventlog sysfs handler
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 <dlaurie@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Justin TerAvest <teravest@chromium.org> [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6 |
|
#
162aa53b |
| 03-Sep-2018 |
Colin Ian King <colin.king@canonical.com> |
firmware: google: make structure gsmi_dev static
The structure gsmi_dev is local to the source and does not need to be in global scope, so make it static.
Cleans up sparse warning: symbol 'gsmi_dev
firmware: google: make structure gsmi_dev static
The structure gsmi_dev is local to the source and does not need to be in global scope, so make it static.
Cleans up sparse warning: symbol 'gsmi_dev' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5 |
|
#
6faadbbb |
| 14-Sep-2017 |
Christoph Hellwig <hch@lst.de> |
dmi: Mark all struct dmi_system_id instances const
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build] [JD: add htcpen
dmi: Mark all struct dmi_system_id instances const
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it]
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
show more ...
|
Revision tags: v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7 |
|
#
d520dd1f |
| 24-Jul-2016 |
Markus Elfring <elfring@users.sourceforge.net> |
firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy"
The dma_pool_destroy() function tests whether its argument is NULL and then returns immediately. Thus the test
firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy"
The dma_pool_destroy() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Mike Waychison <mikew@google.com> Cc: Michel Lespinasse <walken@google.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
show more ...
|
Revision tags: openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1 |
|
#
b12b73f1 |
| 28-Jan-2014 |
Michel Lespinasse <walken@google.com> |
firmware: fix google/gsmi duplicate efivars_sysfs_init()
Starting in commit e14ab23dde12b80db4c94b684a2e485b72b16af3, efivars_sysfs_init() is called both by itself as an init function, and by driver
firmware: fix google/gsmi duplicate efivars_sysfs_init()
Starting in commit e14ab23dde12b80db4c94b684a2e485b72b16af3, efivars_sysfs_init() is called both by itself as an init function, and by drivers/firmware/google/gsmi.c gsmi_init().
This results in runtime warnings such as the following: [ 5.651330] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xbd/0xe0() [ 5.657699] sysfs: cannot create duplicate filename '/firmware/gsmi/vars'
Fixing this by removing the redundant efivars_sysfs_init() call in gsmi_init().
Tested: booted, checked that /firmware/gsmi/vars was still present and showed the expected contents.
Signed-off-by: Michel Lespinasse <walken@google.com> Acked-by: Matt Fleming <matt.fleming@intel.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1 |
|
#
536dc1eb |
| 01-Jul-2013 |
Russell King <rmk+kernel@arm.linux.org.uk> |
DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks
This driver doesn't need to directly access DMA masks if it uses the platform_device_register_full() API rather than platform_device
DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks
This driver doesn't need to directly access DMA masks if it uses the platform_device_register_full() API rather than platform_device_register_simple() - the former function can initialize the DMA mask appropriately.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
#
20d0e570 |
| 11-Sep-2013 |
Jingoo Han <jg1.han@samsung.com> |
drivers/firmware/google/gsmi.c: replace strict_strtoul() with kstrtoul()
The use of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used.
Signed
drivers/firmware/google/gsmi.c: replace strict_strtoul() with kstrtoul()
The use of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Tom Gundersen <teg@jklm.no> Cc: Mike Waychison <mikew@google.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7 |
|
#
e14ab23d |
| 03-Feb-2013 |
Matt Fleming <matt.fleming@intel.com> |
efivars: efivar_entry API
There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the gener
efivars: efivar_entry API
There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI.
Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code.
Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location.
Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built.
Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
show more ...
|
#
d5abc7c1 |
| 03-Feb-2013 |
Matt Fleming <matt.fleming@intel.com> |
efi: move utf16 string functions to efi.h
There are currently two implementations of the utf16 string functions. Somewhat confusingly, they've got different names.
Centralise the functions in efi.h
efi: move utf16 string functions to efi.h
There are currently two implementations of the utf16 string functions. Somewhat confusingly, they've got different names.
Centralise the functions in efi.h.
Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Reviewed-by: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
show more ...
|
Revision tags: v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4 |
|
#
d2554f50 |
| 30-Nov-2011 |
Maxin B. John <maxin.john@gmail.com> |
firmware: google: fix gsmi.c build warning
Use min_t() macro instead of min() to fix a build warning:
CC drivers/firmware/google/gsmi.o drivers/firmware/google/gsmi.c: In function ‘gsmi_get_
firmware: google: fix gsmi.c build warning
Use min_t() macro instead of min() to fix a build warning:
CC drivers/firmware/google/gsmi.o drivers/firmware/google/gsmi.c: In function ‘gsmi_get_variable’: drivers/firmware/google/gsmi.c:348: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: Maxin B. John <maxin.john@gmail.com> Acked-By: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
show more ...
|