aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2020-01-07firmware: qcom_scm-32: Add device argument to atomic callsElliot Berman4-14/+19
Add unused "device" parameter to reduce merge friction between SMCCC and legacy based conventions in an upcoming patch. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-32: Create common legacy atomic callElliot Berman1-38/+68
Per [1], legacy calling convention supports up to 5 arguments and 3 return values. Create one function to support this combination, and remove the original "atomic1" and "atomic2" variants for 1 and 2 arguments. This more closely aligns scm_legacy implementation with scm_smc implementation. [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/soc/qcom/scm.c?h=kernel.lnx.4.9.r28-rel#n1024 Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-32: Move SMCCC register filling to qcom_scm_callElliot Berman1-12/+24
Move SMCCC register filling to qcom_scm_call so that __scm_legacy_do only needs to concern itself with retry mechanism. qcom_scm_call then is responsible for translating qcom_scm_desc into the complete set of register arguments and passing onto qcom_scm_call_do. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-32: Use qcom_scm_desc in non-atomic callsElliot Berman1-149/+218
Use qcom_scm_desc in non-atomic calls to remove legacy convention details from every SCM wrapper function. Implementations were copied from qcom_scm-64 and are functionally equivalent when using the qcom_scm_desc and qcom_scm_res structs. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-32: Add funcnum IDsElliot Berman1-3/+5
Add SCM_LEGACY_FNID macro to qcom_scm-32. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-32: Use SMC arch wrappersElliot Berman2-55/+17
Use SMC arch wrappers instead of inline assembly. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-64: Improve SMC convention detectionElliot Berman1-14/+27
Improve the calling convention detection to use __qcom_scm_is_call_available() and not blindly assume 32-bit mode if the checks fails. BUG() if neither 32-bit or 64-bit mode works. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-64: Move SMC register filling to qcom_scm_call_smcccElliot Berman1-20/+34
qcom_scm_call_smccc should be responsible for converting qcom_scm_desc into arguments for smc call. Consolidate the dispersed logic to convert qcom_scm_desc into smc arguments inside qcom_scm_call_smccc. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-64: Add SCM results structElliot Berman1-43/+50
Remove knowledge of arm_smccc_res struct from client wrappers so that client wrappers only work QCOM SCM data structures. SCM calls may have up to 3 arguments, so qcom_scm_call_smccc is responsible now for filling those 3 arguments accordingly. This is necessary to support merging legacy and SMC conventions in an upcoming patch. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-64: Move svc/cmd/owner into qcom_scm_descElliot Berman1-74/+121
Service, command, and owner IDs are all part of qcom_scm_desc struct and have no special reason to be a function argument (or hard-coded in the case of owner [1]). Moving them to be part of qcom_scm_desc struct improves readability. [1]: Example of SCM function using owner vale other than hard-coded SIP value: https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/soc/qcom/smcinvoke.c?h=kernel.lnx.4.9.r28-rel#n35 Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm-64: Make SMC macros less magicalElliot Berman1-3/+3
Improve understandability of SMC macros by reversing the logic as they are all functions of how many arguments can be shoved in registers and how many SCM arguments are supported. There aren't 4 register arguments because are 7 arguments that go into a buffer - there are up to 7 arguments that are overflowed into a buffer because only 4 registers are allocated for arguments. Reviewed-by: Stephen Boyd <[email protected]> Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm: Remove unused qcom_scm_get_versionElliot Berman1-36/+0
Remove unused qcom_scm_get_version. Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm: Apply consistent naming scheme to command IDsElliot Berman4-72/+64
Create a consistent naming scheme for command IDs. The scheme is QCOM_SCM_##svc_##cmd. Remove unused macros QCOM_SCM_FLAG_HLOS, QCOM_SCM_FLAG_COLDBOOT_MC, QCOM_SCM_FLAG_WARMBOOT_MC, QCOM_SCM_CMD_CORE_HOTPLUGGED, and QCOM_SCM_BOOT_ADDR_MC. Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-07firmware: qcom_scm: Rename macros and structuresElliot Berman2-60/+64
Rename legacy-specific structures and macros with legacy prefix; rename smc-specific structures and macros with smc prefix. This should make it clearer which structures are generic to "SCM" and which are specfically for implementing the convention. Tested-by: Brian Masney <[email protected]> # arm32 Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-01-06firmware: tee_bnxt: Fix multiple call to tee_client_close_contextVikas Gupta1-1/+0
Fix calling multiple tee_client_close_context in case of shm allocation fails. Fixes: 246880958ac9 (“firmware: broadcom: add OP-TEE based BNXT f/w manager”) Signed-off-by: Vikas Gupta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-06Merge tag 'scmi-updates-5.6' of ↵Olof Johansson9-7/+146
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers ARM SCMI updates for v5.6 1. Addition of multiple device support per protocol to enable use of some procotols by multiple kernel subsystems simultaneously and corresponding updates to the existing scmi drivers 2. Addition of trace events around the scmi transfer code to measure any delays and capture anomalies that can also be used during investigation of some platform firmware related issues * tag 'scmi-updates-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: drivers: firmware: scmi: Extend SCMI transport layer by trace events include: trace: Add SCMI header with trace events reset: reset-scmi: Match scmi device by both name and protocol id hwmon: (scmi-hwmon) Match scmi device by both name and protocol id cpufreq: scmi: Match scmi device by both name and protocol id clk: scmi: Match scmi device by both name and protocol id firmware: arm_scmi: Skip protocol initialisation for additional devices firmware: arm_scmi: Stash version in protocol init functions firmware: arm_scmi: Match scmi device by both name and protocol id firmware: arm_scmi: Add versions and identifier attributes using dev_groups firmware: arm_scmi: Add names to scmi devices created firmware: arm_scmi: Skip scmi mbox channel setup for addtional devices firmware: arm_scmi: Add support for multiple device per protocol Link: https://lore.kernel.org/r/20191230182956.GA29349@bogus Signed-off-by: Olof Johansson <[email protected]>
2020-01-06remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig1-1/+1
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Arnd Bergmann <[email protected]>
2020-01-02firmware: psci: Export functions to manage the OSI modeUlf Hansson1-2/+16
To allow subsequent changes to implement support for OSI mode through the cpuidle-psci driver, export the existing psci_has_osi_support(). Export also a new function, psci_set_osi_mode(), that allows its caller to enable the OS-initiated CPU-suspend mode in the PSCI FW. To deal with backwards compatibility for a kernel started through a kexec call, default to set the CPU-suspend mode to the Platform Coordinated mode during boot. Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Sudeep Holla <[email protected]>
2019-12-30drivers: firmware: scmi: Extend SCMI transport layer by trace eventsLukasz Luba2-0/+20
The SCMI transport layer communicates via mailboxes and shared memory with firmware running on a microcontroller. It is platform specific how long it takes to pass a SCMI message. The most sensitive requests are coming from CPUFreq subsystem, which might be used by the scheduler. Thus, there is a need to measure these delays and capture anomalies. This change introduces trace events wrapped around transfer code. According to Jim's suggestion a unique transfer_id is to distinguish similar entries which might have the same message id, protocol id and sequence. This is a case then there are some timeouts in transfers. Suggested-by: Jim Quinlan <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-30Merge tag 'v5.5-rc4' into locking/kcsan, to resolve conflictsIngo Molnar39-241/+1049
Conflicts: init/main.c lib/Kconfig.debug Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Tidy up types and names of global cmdline variablesArd Biesheuvel3-22/+28
Drop leading underscores and use bool not int for true/false variables set on the command line. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Rename efi_call_early/_runtime macros to be more intuitiveArd Biesheuvel9-109/+90
The macros efi_call_early and efi_call_runtime are used to call EFI boot services and runtime services, respectively. However, the naming is confusing, given that the early vs runtime distinction may suggest that these are used for calling the same set of services either early or late (== at runtime), while in reality, the sets of services they can be used with are completely disjoint, and efi_call_runtime is also only usable in 'early' code. So do a global sweep to replace all occurrences with efi_bs_call or efi_rt_call, respectively, where BS and RT match the idiom used by the UEFI spec to refer to boot time or runtime services. While at it, use 'func' as the macro parameter name for the function pointers, which is less likely to collide and cause weird build errors. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop 'table' argument from efi_table_attr() macroArd Biesheuvel2-13/+7
None of the definitions of the efi_table_attr() still refer to their 'table' argument so let's get rid of it entirely. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop protocol argument from efi_call_proto() macroArd Biesheuvel3-14/+11
After refactoring the mixed mode support code, efi_call_proto() no longer uses its protocol argument in any of its implementation, so let's remove it altogether. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub/x86: Work around page freeing issue in mixed modeArd Biesheuvel1-1/+4
Mixed mode translates calls from the 64-bit kernel into the 32-bit firmware by wrapping them in a call to a thunking routine that pushes a 32-bit word onto the stack for each argument passed to the function, regardless of the argument type. This works surprisingly well for most services and protocols, with the exception of ones that take explicit 64-bit arguments. efi_free() invokes the FreePages() EFI boot service, which takes a efi_physical_addr_t as its address argument, and this is one of those 64-bit types. This means that the 32-bit firmware will interpret the (addr, size) pair as a single 64-bit quantity, and since it is guaranteed to have the high word set (as size > 0), it will always fail due to the fact that EFI memory allocations are always < 4 GB on 32-bit firmware. So let's fix this by giving the thunking code a little hand, and pass two values for the address, and a third one for the size. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Remove 'sys_table_arg' from all function prototypesArd Biesheuvel10-139/+111
We have a helper efi_system_table() that gives us the address of the EFI system table in memory, so there is no longer point in passing it around from each function to the next. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop sys_table_arg from printk routinesArd Biesheuvel8-61/+59
As a first step towards getting rid of the need to pass around a function parameter 'sys_table_arg' pointing to the EFI system table, remove the references to it in the printing code, which is represents the majority of the use cases. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Unify the efi_char16_printk implementationsArd Biesheuvel2-9/+9
Use a single implementation for efi_char16_printk() across all architectures. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Get rid of 'sys_table_arg' macro parameterArd Biesheuvel3-1/+14
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg' existing in the scope of the macro instantiation. Since this variable always points to the same data structure, let's create a global getter for it and use that instead. Note that the use of a global variable with external linkage is avoided, given the problems we had in the past with early processing of the GOT tables. While at it, drop the redundant casts in the efi_table_attr and efi_call_proto macros. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Avoid protocol wrapper for file I/O routinesArd Biesheuvel1-10/+7
The EFI file I/O routines built on top of the file I/O firmware services are incompatible with mixed mode, so there is no need to obfuscate them by using protocol wrappers whose only purpose is to hide the mixed mode handling. So let's switch to plain indirect calls instead. This also means we can drop the mixed_mode aliases from the various types involved. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Annotate firmware routines as __efiapiArd Biesheuvel1-4/+6
Annotate all the firmware routines (boot services, runtime services and protocol methods) called in the boot context as __efiapi, and make it expand to __attribute__((ms_abi)) on 64-bit x86. This allows us to use the compiler to generate the calls into firmware that use the MS calling convention instead of the SysV one. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Use stricter typing for firmware function pointersArd Biesheuvel2-4/+5
We will soon remove another level of pointer casting, so let's make sure all type handling involving firmware calls at boot time is correct. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Drop explicit 32/64-bit protocol definitionsArd Biesheuvel1-10/+0
Now that we have incorporated the mixed mode protocol definitions into the native ones using unions, we no longer need the separate 32/64 bit struct definitions, with the exception of the EFI system table definition and the boot services, runtime services and configuration table definitions. So drop the unused ones. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Distinguish between native/mixed not 32/64 bitArd Biesheuvel1-30/+15
Currently, we support mixed mode by casting all boot time firmware calls to 64-bit explicitly on native 64-bit systems, and to 32-bit on 32-bit systems or 64-bit systems running with 32-bit firmware. Due to this explicit awareness of the bitness in the code, we do a lot of casting even on generic code that is shared with other architectures, where mixed mode does not even exist. This casting leads to loss of coverage of type checking by the compiler, which we should try to avoid. So instead of distinguishing between 32-bit vs 64-bit, distinguish between native vs mixed, and limit all the nasty casting and pointer mangling to the code that actually deals with mixed mode. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Extend native protocol definitions with mixed_mode aliasesArd Biesheuvel2-10/+16
In preparation of moving to a native vs. mixed mode split rather than a 32 vs. 64 bit split when it comes to invoking EFI firmware services, update all the native protocol definitions and redefine them as unions containing an anonymous struct for the native view and a struct called 'mixed_mode' describing the 32-bit view of the protocol when called from 64-bit code. While at it, flesh out some PCI I/O member definitions that we will be needing shortly. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub: Use a helper to iterate over a EFI handle arrayArd Biesheuvel1-7/+2
Iterating over a EFI handle array is a bit finicky, since we have to take mixed mode into account, where handles are only 32-bit while the native efi_handle_t type is 64-bit. So introduce a helper, and replace the various occurrences of this pattern. Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/gop: Unify 32/64-bit functionsArvind Sankar1-116/+18
Use efi_table_attr macro to deal with 32/64-bit firmware using the same source code. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/gop: Convert GOP structures to typedef and clean up some typesArvind Sankar1-13/+13
Use typedef for the GOP structures, in anticipation of unifying 32/64-bit code. Also use more appropriate types in the non-bitness specific structures for the framebuffer address and pointers. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/libstub/random: Initialize pointer variables to zero for mixed modeHans de Goede1-3/+3
Commit: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") causes the drivers/efi/libstub/random.c code to get used on x86 for the first time. But this code was not written with EFI mixed mode in mind (running a 64 bit kernel on 32 bit EFI firmware), this causes the kernel to crash during early boot when running in mixed mode. The problem is that in mixed mode pointers are 64 bit, but when running on a 32 bit firmware, EFI calls which return a pointer value by reference only fill the lower 32 bits of the passed pointer, leaving the upper 32 bits uninitialized which leads to crashes. This commit fixes this by initializing pointers which are passed by reference to EFI calls to NULL before passing them, so that the upper 32 bits are initialized to 0. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-25efi/earlycon: Fix write-combine mapping on x86Arvind Sankar1-9/+7
On x86, until PAT is initialized, WC translates into UC-. Since we calculate and store pgprot_writecombine(PAGE_KERNEL) when earlycon is initialized, this means we actually use UC- mappings instead of WC mappings, which makes scrolling very slow. Instead store a boolean flag to indicate whether we want to use writeback or write-combine mappings, and recalculate the actual pgprot_t we need on every mapping. Once PAT is initialized, we will start using write-combine mappings, which speeds up the scrolling considerably. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-24firmware: arm_scmi: Skip protocol initialisation for additional devicesSudeep Holla1-0/+9
The scmi bus now supports adding multiple devices per protocol, and since scmi_protocol_init is called for each scmi device created, we must avoid allocating protocol private data and initialising the protocol itself if it is already initialised. In order to achieve the same, we can simple replace the idr pointer from protocol initialisation function to a dummy function. Suggested-by: Cristian Marussi <[email protected]> Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Stash version in protocol init functionsSudeep Holla5-0/+10
In order to avoid querying the individual protocol versions multiple time with more that one device created for each protocol, we can simple store the copy in the protocol specific private data and use them whenever required. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Match scmi device by both name and protocol idSudeep Holla1-1/+1
The scmi bus now has support to match the driver with devices not only based on their protocol id but also based on their device name if one is available. This was added to cater the need to support multiple devices and drivers for the same protocol. Let us add the name "genpd" to scmi_device_id table in the driver so that in matches only with device with the same name and protocol id SCMI_PROTOCOL_POWER. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Add versions and identifier attributes using dev_groupsSudeep Holla1-0/+47
Platform drivers now have the option to have the platform core create and remove any needed sysfs attribute files. Using the same, let's add the scmi firmware and protocol version attributes as well as vendor and sub-vendor identifiers to sysfs. It helps to identify the firmware details from the sysfs entries similar to ARM SCPI implementation. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Add names to scmi devices createdSudeep Holla1-1/+35
Now that scmi bus provides option to create named scmi device, let us create the default devices with names. This will help to add names for matching to respective drivers and eventually to add multiple devices and drivers per protocol. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Skip scmi mbox channel setup for addtional devicesSudeep Holla1-0/+5
Now that the scmi bus supports adding multiple devices per protocol, and since scmi_create_protocol_device calls scmi_mbox_chan_setup, we must avoid allocating and initialising the mbox channel if it is already initialised. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-24firmware: arm_scmi: Add support for multiple device per protocolSudeep Holla2-6/+20
Currently only one scmi device is created for each protocol enumerated. However, there is requirement to make use of some procotols by multiple kernel subsystems/frameworks. One such example is SCMI PERFORMANCE protocol which can be used by both cpufreq and devfreq drivers. Similarly, SENSOR protocol may be used by hwmon and iio subsystems, and POWER protocol may be used by genpd and regulator drivers. In order to achieve that, let us extend the scmi bus to match based not only protocol id but also the scmi device name if one is available. Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2019-12-17Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds4-63/+88
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "Protect presistent EFI memory reservations from kexec, fix EFIFB early console, EFI stub graphics output fixes and other misc fixes." * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Don't attempt to map RCI2 config table if it doesn't exist efi/earlycon: Remap entire framebuffer after page initialization efi: Fix efi_loaded_image_t::unload type efi/gop: Fix memory leak in __gop_query32/64() efi/gop: Return EFI_SUCCESS if a usable GOP was found efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs efi/memreserve: Register reservations as 'reserved' in /proc/iomem
2019-12-12drivers: firmware: xilinx: Add support for feature checkRavi Patel1-0/+43
Query for corresponding feature before calling EEMI API from the driver. Signed-off-by: Ravi Patel <[email protected]> Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Rajan Vaja <[email protected]>
2019-12-10efi: Don't attempt to map RCI2 config table if it doesn't existArd Biesheuvel1-0/+3
Commit: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs") ... added support for a Dell specific UEFI configuration table, but failed to take into account that mapping the table should not be attempted unless the table actually exists. If it doesn't exist, the code usually fails silently unless pr_debug() prints are enabled. However, on 32-bit PAE x86, the splat below is produced due to the attempt to map the placeholder value EFI_INVALID_TABLE_ADDR which we use for non-existing UEFI configuration tables, and which equals ULONG_MAX. memremap attempted on mixed range 0x00000000ffffffff size: 0x1e WARNING: CPU: 1 PID: 1 at kernel/iomem.c:81 memremap+0x1a3/0x1c0 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.2-smp-mine #1 Hardware name: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.61 03/05/2018 EIP: memremap+0x1a3/0x1c0 ... Call Trace: ? map_properties+0x473/0x473 ? efi_rci2_sysfs_init+0x2c/0x154 ? map_properties+0x473/0x473 ? do_one_initcall+0x49/0x1d4 ? parse_args+0x1e8/0x2a0 ? do_early_param+0x7a/0x7a ? kernel_init_freeable+0x139/0x1c2 ? rest_init+0x8e/0x8e ? kernel_init+0xd/0xf2 ? ret_from_fork+0x2e/0x38 Fix this by checking whether the table exists before attempting to map it. Reported-by: Richard Narron <[email protected]> Tested-by: Richard Narron <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: [email protected] Fixes: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.