user/sven/linux.git/include/linux/efi.h, branch v3.2.65

x86, efivars: firmware bug workarounds should be in platform code

2013-05-30T13:35:10Z

commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream. Let's not burden ia64 with checks in the common efivars code that we're not writing too much data to the variable store. That kind of thing is an x86 firmware bug, plain and simple. efi_query_variable_store() provides platforms with a wrapper in which they can perform checks and workarounds for EFI variable storage bugs. Cc: H. Peter Anvin Cc: Matthew Garrett Signed-off-by: Matt Fleming [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

efi_pstore: Introducing workqueue updating sysfs

2013-03-27T02:41:20Z

commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream. [Problem] efi_pstore creates sysfs entries, which enable users to access to NVRAM, in a write callback. If a kernel panic happens in an interrupt context, it may fail because it could sleep due to dynamic memory allocations during creating sysfs entries. [Patch Description] This patch removes sysfs operations from a write callback by introducing a workqueue updating sysfs entries which is scheduled after the write callback is called. Also, the workqueue is kicked in a just oops case. A system will go down in other cases such as panic, clean shutdown and emergency restart. And we don't need to create sysfs entries because there is no chance for users to access to them. efi_pstore will be robust against a kernel panic in an interrupt context with this patch. Signed-off-by: Seiji Aguchi Acked-by: Matt Fleming Signed-off-by: Tony Luck [bwh: Backported to 3.2: - Adjust contest - Don't check reason in efi_pstore_write(), as it is not given as a parameter - Move up declaration of __efivars] Signed-off-by: Ben Hutchings

efi: be more paranoid about available space when creating variables

2013-03-20T15:03:28Z

commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream. UEFI variables are typically stored in flash. For various reasons, avaiable space is typically not reclaimed immediately upon the deletion of a variable - instead, the system will garbage collect during initialisation after a reboot. Some systems appear to handle this garbage collection extremely poorly, failing if more than 50% of the system flash is in use. This can result in the machine refusing to boot. The safest thing to do for the moment is to forbid writes if they'd end up using more than half of the storage space. We can make this more finegrained later if we come up with a method for identifying the broken machines. Signed-off-by: Matthew Garrett Signed-off-by: Matt Fleming [bwh: Backported to 3.2: - Drop efivarfs changes and unused check_var_size() - Add error codes to include/linux/efi.h, added upstream by commit 5d9db883761a ('efi: Add support for a UEFI variable filesystem') - Add efi_status_to_err(), added upstream by commit 7253eaba7b17 ('efivarfs: Return an error if we fail to read a variable')] Signed-off-by: Ben Hutchings

efi_pstore: Check remaining space with QueryVariableInfo() before writing data

2013-03-20T15:03:27Z

commit d80a361d779a9f19498943d1ca84243209cd5647 upstream. [Issue] As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario. And we wouldn't expect all firmware to handle it gracefully. http://marc.info/?l=linux-kernel&m=134305325801789&w=2 On the other hand, current efi_pstore doesn't check a remaining space of storage at writing time. Therefore, efi_pstore may not work if it tries to write a large amount of data. [Patch Description] To avoid handling the situation above, this patch checks if there is a space enough to log with QueryVariableInfo() before writing data. Signed-off-by: Seiji Aguchi Acked-by: Mike Waychison Signed-off-by: Tony Luck Signed-off-by: Ben Hutchings

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-06T04:33:50Z

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream. Originally 'efi_enabled' indicated whether a kernel was booted from EFI firmware. Over time its semantics have changed, and it now indicates whether or not we are booted on an EFI machine with bit-native firmware, e.g. 64-bit kernel with 64-bit firmware. The immediate motivation for this patch is the bug report at, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 which details how running a platform driver on an EFI machine that is designed to run under BIOS can cause the machine to become bricked. Also, the following report, https://bugzilla.kernel.org/show_bug.cgi?id=47121 details how running said driver can also cause Machine Check Exceptions. Drivers need a new means of detecting whether they're running on an EFI machine, as sadly the expression, if (!efi_enabled) hasn't been a sufficient condition for quite some time. Users actually want to query 'efi_enabled' for different reasons - what they really want access to is the list of available EFI facilities. For instance, the x86 reboot code needs to know whether it can invoke the ResetSystem() function provided by the EFI runtime services, while the ACPI OSL code wants to know whether the EFI config tables were mapped successfully. There are also checks in some of the platform driver code to simply see if they're running on an EFI machine (which would make it a bad idea to do BIOS-y things). This patch is a prereq for the samsung-laptop fix patch. Cc: David Airlie Cc: Corentin Chary Cc: Matthew Garrett Cc: Dave Jiang Cc: Olof Johansson Cc: Peter Jones Cc: Colin Ian King Cc: Steve Langasek Cc: Tony Luck Cc: Konrad Rzeszutek Wilk Cc: Rafael J. Wysocki Signed-off-by: Matt Fleming Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: - Adjust context (a lot) - Add efi_is_native() function from commit 5189c2a7c776 ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel') - Make efi_init() bail out when booted non-native, as it would previously not be called in this case - Drop inapplicable changes to start_kernel()] Signed-off-by: Ben Hutchings

efi: Add new variable attributes

2012-05-11T12:14:47Z

commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream. More recent versions of the UEFI spec have added new attributes for variables. Add them. Signed-off-by: Matthew Garrett Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

Merge branch 'pstore-efi' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6

2011-08-01T23:40:51Z

* 'pstore-efi' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: efivars: Introduce PSTORE_EFI_ATTRIBUTES efivars: Use string functions in pstore_write efivars: introduce utf16_strncmp efivars: String functions efi: Add support for using efivars as a pstore backend pstore: Allow the user to explicitly choose a backend pstore: Make "part" unsigned pstore: Add extra context for writes and erases pstore: Extend API for more flexibility in new backends

efi: Add support for using efivars as a pstore backend

2011-07-22T23:15:04Z

EFI provides an area of nonvolatile storage managed by the firmware. We can use this as a pstore backend to maintain copies of oopses, aiding diagnosis. Signed-off-by: Matthew Garrett Signed-off-by: Tony Luck

x86, efi: Add infrastructure for UEFI 2.0 runtime services

2011-06-06T20:30:30Z

We're currently missing support for any of the runtime service calls introduced with the UEFI 2.0 spec in 2006. Add the infrastructure for supporting them. Signed-off-by: Matthew Garrett Link: http://lkml.kernel.org/r/1307388985-7852-2-git-send-email-mjg@redhat.com Signed-off-by: H. Peter Anvin

x86, efi: Fix argument types for SetVariable()

2011-06-06T20:30:27Z

The spec says this takes uint32 for attributes, not uintn. Signed-off-by: Matthew Garrett Link: http://lkml.kernel.org/r/1307388985-7852-1-git-send-email-mjg@redhat.com Signed-off-by: H. Peter Anvin