summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2020-01-07firmware: qcom_scm-64: Add SCM results structElliot Berman
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 <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-7-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-07firmware: qcom_scm-64: Move svc/cmd/owner into qcom_scm_descElliot Berman
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 <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-6-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-07firmware: qcom_scm-64: Make SMC macros less magicalElliot Berman
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 <swboyd@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-5-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-07firmware: qcom_scm: Remove unused qcom_scm_get_versionElliot Berman
Remove unused qcom_scm_get_version. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-4-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-07firmware: qcom_scm: Apply consistent naming scheme to command IDsElliot Berman
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 <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-3-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-07firmware: qcom_scm: Rename macros and structuresElliot Berman
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 <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-2-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-01-06firmware: tee_bnxt: Fix multiple call to tee_client_close_contextVikas Gupta
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 <vikas.gupta@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-06Merge tag 'scmi-updates-5.6' of ↵Olof Johansson
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 <olof@lixom.net>
2020-01-06remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig
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 <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
2020-01-02firmware: psci: Export functions to manage the OSI modeUlf Hansson
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 <ulf.hansson@linaro.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-30drivers: firmware: scmi: Extend SCMI transport layer by trace eventsLukasz Luba
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 <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-25efi/libstub: Tidy up types and names of global cmdline variablesArd Biesheuvel
Drop leading underscores and use bool not int for true/false variables set on the command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-25-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Rename efi_call_early/_runtime macros to be more intuitiveArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop 'table' argument from efi_table_attr() macroArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-23-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop protocol argument from efi_call_proto() macroArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-22-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub/x86: Work around page freeing issue in mixed modeArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-21-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Remove 'sys_table_arg' from all function prototypesArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop sys_table_arg from printk routinesArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-19-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Unify the efi_char16_printk implementationsArd Biesheuvel
Use a single implementation for efi_char16_printk() across all architectures. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-17-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Get rid of 'sys_table_arg' macro parameterArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-16-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Avoid protocol wrapper for file I/O routinesArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-15-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Annotate firmware routines as __efiapiArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-13-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Use stricter typing for firmware function pointersArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-12-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop explicit 32/64-bit protocol definitionsArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-11-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Distinguish between native/mixed not 32/64 bitArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-10-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Extend native protocol definitions with mixed_mode aliasesArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-9-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Use a helper to iterate over a EFI handle arrayArd Biesheuvel
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 <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-8-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/gop: Unify 32/64-bit functionsArvind Sankar
Use efi_table_attr macro to deal with 32/64-bit firmware using the same source code. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-5-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/gop: Convert GOP structures to typedef and clean up some typesArvind Sankar
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 <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-4-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub/random: Initialize pointer variables to zero for mixed modeHans de Goede
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 <hdegoede@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") Link: https://lkml.kernel.org/r/20191224132909.102540-3-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/earlycon: Fix write-combine mapping on x86Arvind Sankar
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 <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/20191224132909.102540-2-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-24firmware: arm_scmi: Skip protocol initialisation for additional devicesSudeep Holla
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 <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Stash version in protocol init functionsSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Match scmi device by both name and protocol idSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Add versions and identifier attributes using dev_groupsSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Add names to scmi devices createdSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Skip scmi mbox channel setup for addtional devicesSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24firmware: arm_scmi: Add support for multiple device per protocolSudeep Holla
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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds
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 Patel
Query for corresponding feature before calling EEMI API from the driver. Signed-off-by: Ravi Patel <ravi.patel@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
2019-12-10efi: Don't attempt to map RCI2 config table if it doesn't existArd Biesheuvel
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 <comet.berkeley@gmail.com> Tested-by: Richard Narron <comet.berkeley@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org Fixes: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs") Link: https://lkml.kernel.org/r/20191210090945.11501-2-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-10efi/capsule-loader: Explicitly include linux/io.h for page_to_phys()Sean Christopherson
Through a labyrinthian sequence of includes, usage of page_to_phys() is dependent on the include of asm/io.h in x86's asm/realmode.h, which is included in x86's asm/acpi.h and thus by linux/acpi.h. Explicitly include linux/io.h to break the dependency on realmode.h so that a future patch can remove the realmode.h include from acpi.h without breaking the build. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Link: https://lkml.kernel.org/r/20191126165417.22423-7-sean.j.christopherson@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-09treewide: Use sizeof_field() macroPankaj Bharadiya
Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except at places where these are defined. Later patches will remove the unused definition of FIELD_SIZEOF(). This patch is generated using following script: EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h" git grep -l -e "\bFIELD_SIZEOF\b" | while read file; do if [[ "$file" =~ $EXCLUDE_FILES ]]; then continue fi sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file; done Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: David Miller <davem@davemloft.net> # for net
2019-12-08efi/earlycon: Remap entire framebuffer after page initializationAndy Shevchenko
When commit: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") moved the x86 specific EFI earlyprintk implementation to a shared location, it also tweaked the behaviour. In particular, it dropped a trick with full framebuffer remapping after page initialization, leading to two regressions: 1) very slow scrolling after page initialization, 2) kernel hang when the 'keep_bootcon' command line argument is passed. Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow behavior to the early boot stages, presumably due to eliminating heavy map()/unmap() operations per each pixel line on the screen. [ ardb: ensure efifb is unmapped again unless keep_bootcon is in effect. ] [ mingo: speling fixes. ] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: linux-efi@vger.kernel.org Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/20191206165542.31469-7-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-08efi/gop: Fix memory leak in __gop_query32/64()Arvind Sankar
efi_graphics_output_protocol::query_mode() returns info in callee-allocated memory which must be freed by the caller, which we aren't doing. We don't actually need to call query_mode() in order to obtain the info for the current graphics mode, which is already there in gop->mode->info, so just access it directly in the setup_gop32/64() functions. Also nothing uses the size of the info structure, so don't update the passed-in size (which is the size of the gop_handle table in bytes) unnecessarily. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-5-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-08efi/gop: Return EFI_SUCCESS if a usable GOP was foundArvind Sankar
If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-08efi/gop: Return EFI_NOT_FOUND if there are no usable GOPsArvind Sankar
If we don't find a usable instance of the Graphics Output Protocol (GOP) because none of them have a framebuffer (i.e. they were all PIXEL_BLT_ONLY), but all the EFI calls succeeded, we will return EFI_SUCCESS even though we didn't find a usable GOP. Fix this by explicitly returning EFI_NOT_FOUND if no usable GOPs are found, allowing the caller to probe for UGA instead. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-3-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-08efi/memreserve: Register reservations as 'reserved' in /proc/iomemArd Biesheuvel
Memory regions that are reserved using efi_mem_reserve_persistent() are recorded in a special EFI config table which survives kexec, allowing the incoming kernel to honour them as well. However, such reservations are not visible in /proc/iomem, and so the kexec tools that load the incoming kernel and its initrd into memory may overwrite these reserved regions before the incoming kernel has a chance to reserve them from further use. Address this problem by adding these reservations to /proc/iomem as they are created. Note that reservations that are inherited from a previous kernel are memblock_reserve()'d early on, so they are already visible in /proc/iomem. Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Cc: <stable@vger.kernel.org> # v5.4+ Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-2-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-06Merge tag 'armsoc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A set of fixes that we've merged late, but for the most part that have been sitting in -next for a while through platform maintainer trees: - Fixes to suspend/resume on Tegra, caused by the added features this merge window - Cleanups and minor fixes to TI additions this merge window - Tee fixes queued up late before the merge window, included here. - A handful of other fixlets There's also a refresh of the shareed config files (multi_v* on 32-bit, and defconfig on 64-bit), to avoid conflicts when we get new contributions" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits) ARM: multi_v7_defconfig: Restore debugfs support ARM: defconfig: re-run savedefconfig on multi_v* configs arm64: defconfig: re-run savedefconfig ARM: pxa: Fix resource properties soc: mediatek: cmdq: fixup wrong input order of write api soc: aspeed: Fix snoop_file_poll()'s return type MAINTAINERS: Switch to Marvell addresses MAINTAINERS: update Cavium ThunderX drivers Revert "arm64: dts: juno: add dma-ranges property" MAINTAINERS: Make Nicolas Saenz Julienne the new bcm2835 maintainer firmware: arm_scmi: Avoid double free in error flow arm64: dts: juno: Fix UART frequency ARM: dts: Fix sgx sysconfig register for omap4 arm: socfpga: execute cold reboot by default ARM: dts: Fix vcsi regulator to be always-on for droid4 to prevent hangs ARM: dts: dra7: fix cpsw mdio fck clock ARM: dts: am57xx-beagle-x15: Update pinmux name to ddr_3_3v ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity soc/tegra: pmc: Add reset sources and levels on Tegra194 soc/tegra: pmc: Add missing IRQ callbacks on Tegra194 ...
2019-12-06Merge tag 'drm-next-2019-12-06' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull more drm updates from Dave Airlie: "Rob pointed out I missed his pull request for msm-next, it's been in next for a while outside of my tree so shouldn't cause any unexpected issues, it has some OCMEM support in drivers/soc that is acked by other maintainers as it's outside my tree. Otherwise it's a usual fixes pull, i915, amdgpu, the main ones, with some tegra, omap, mgag200 and one core fix. Summary: msm-next: - OCMEM support for a3xx and a4xx GPUs. - a510 support + display support core: - mst payload deletion fix i915: - uapi alignment fix - fix for power usage regression due to security fixes - change default preemption timeout to 640ms from 100ms - EHL voltage level display fixes - TGL DGL PHY fix - gvt - MI_ATOMIC cmd parser fix, CFL non-priv warning - CI spotted deadlock fix - EHL port D programming fix amdgpu: - VRAM lost fixes on BACO for CI/VI - navi14 DC fixes - misc SR-IOV, gfx10 fixes - XGMI fixes for arcturus - SRIOV fixes amdkfd: - KFD on ppc64le enabled - page table optimisations radeon: - fix for r1xx/2xx register checker. tegra: - displayport regression fixes - DMA API regression fixes mgag200: - fix devices that can't scanout except at 0 addr omap: - fix dma_addr refcounting" * tag 'drm-next-2019-12-06' of git://anongit.freedesktop.org/drm/drm: (100 commits) drm/dp_mst: Correct the bug in drm_dp_update_payload_part1() drm/omap: fix dma_addr refcounting drm/tegra: Run hub cleanup on ->remove() drm/tegra: sor: Make the +5V HDMI supply optional drm/tegra: Silence expected errors on IOMMU attach drm/tegra: vic: Export module device table drm/tegra: sor: Implement system suspend/resume drm/tegra: Use proper IOVA address for cursor image drm/tegra: gem: Remove premature import restrictions drm/tegra: gem: Properly pin imported buffers drm/tegra: hub: Remove bogus connection mutex check ia64: agp: Replace empty define with do while agp: Add bridge parameter documentation agp: remove unused variable num_segments agp: move AGPGART_MINOR to include/linux/miscdevice.h agp: remove unused variable size in agp_generic_create_gatt_table drm/dp_mst: Fix build on systems with STACKTRACE_SUPPORT=n drm/radeon: fix r1xx/r2xx register checker for POT textures drm/amdgpu: fix GFX10 missing CSIB set(v3) drm/amdgpu: should stop GFX ring in hw_fini ...
generated by cgit (git 2.34.1) at 2024-06-13 13:01:10 +0000