summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2024-03-12Merge tag 'soc-drivers-6.9' of ↵Linus Torvalds17-74/+618
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "This is the usual mix of updates for drivers that are used on (mostly ARM) SoCs with no other top-level subsystem tree, including: - The SCMI firmware subsystem gains support for version 3.2 of the specification and updates to the notification code - Feature updates for Tegra and Qualcomm platforms for added hardware support - A number of platforms get soc_device additions for identifying newly added chips from Renesas, Qualcomm, Mediatek and Google - Trivial improvements for firmware and memory drivers amongst others, in particular 'const' annotations throughout multiple subsystems" * tag 'soc-drivers-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (96 commits) tee: make tee_bus_type const soc: qcom: aoss: add missing kerneldoc for qmp members soc: qcom: geni-se: drop unused kerneldoc struct geni_wrapper param soc: qcom: spm: fix building with CONFIG_REGULATOR=n bus: ti-sysc: constify the struct device_type usage memory: stm32-fmc2-ebi: keep power domain on memory: stm32-fmc2-ebi: add MP25 RIF support memory: stm32-fmc2-ebi: add MP25 support memory: stm32-fmc2-ebi: check regmap_read return value dt-bindings: memory-controller: st,stm32: add MP25 support dt-bindings: bus: imx-weim: convert to YAML watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for PMU regs soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs MAINTAINERS: Update SCMI entry with HWMON driver MAINTAINERS: samsung: gs101: match patches touching Google Tensor SoC memory: tegra: Fix indentation memory: tegra: Add BPMP and ICC info for DLA clients memory: tegra: Correct DLA client names dt-bindings: memory: renesas,rpc-if: Document R-Car V4M support firmware: arm_scmi: Update the supported clock protocol version ...
2024-03-12Merge branch 'linus' into x86/boot, to resolve conflictIngo Molnar2-2/+3
There's a new conflict with Linus's upstream tree, because in the following merge conflict resolution in <asm/coco.h>: 38b334fc767e Merge tag 'x86_sev_for_v6.9_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Linus has resolved the conflicting placement of 'cc_mask' better than the original commit: 1c811d403afd x86/sev: Fix position dependent variable references in startup code ... which was also done by an internal merge resolution: 2e5fc4786b7a Merge branch 'x86/sev' into x86/boot, to resolve conflicts and to pick up dependent tree But Linus is right in 38b334fc767e, the 'cc_mask' declaration is sufficient within the #ifdef CONFIG_ARCH_HAS_CC_PLATFORM block. So instead of forcing Linus to do the same resolution again, merge in Linus's tree and follow his conflict resolution. Conflicts: arch/x86/include/asm/coco.h Signed-off-by: Ingo Molnar <mingo@kernel.org>
2024-03-06Merge tag 'riscv-firmware-for-v6.9' of ↵Arnd Bergmann1-1/+2
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V firmware drivers for v6.9 A single minor fix for an oversized allocation due to sizeof() misuse by yours truly that came in since I sent my last fixes PR. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-firmware-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: Fix over-requested allocation size Link: https://lore.kernel.org/r/20240305-vicinity-dumpling-8943ef26f004@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-03-04firmware: microchip: Fix over-requested allocation sizeDawei Li1-1/+2
cocci warnings: (new ones prefixed by >>) >> drivers/firmware/microchip/mpfs-auto-update.c:387:72-78: ERROR: application of sizeof to pointer drivers/firmware/microchip/mpfs-auto-update.c:170:72-78: ERROR: application of sizeof to pointer response_msg is a pointer to u32, so the size of element it points to is supposed to be a multiple of sizeof(u32), rather than sizeof(u32 *). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403040516.CYxoWTXw-lkp@intel.com/ Signed-off-by: Dawei Li <dawei.li@shingroup.cn> Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-03-04x86/boot: Move mem_encrypt= parsing to the decompressorArd Biesheuvel1-0/+3
The early SME/SEV code parses the command line very early, in order to decide whether or not memory encryption should be enabled, which needs to occur even before the initial page tables are created. This is problematic for a number of reasons: - this early code runs from the 1:1 mapping provided by the decompressor or firmware, which uses a different translation than the one assumed by the linker, and so the code needs to be built in a special way; - parsing external input while the entire kernel image is still mapped writable is a bad idea in general, and really does not belong in security minded code; - the current code ignores the built-in command line entirely (although this appears to be the case for the entire decompressor) Given that the decompressor/EFI stub is an intrinsic part of the x86 bootable kernel image, move the command line parsing there and out of the core kernel. This removes the need to build lib/cmdline.o in a special way, or to use RIP-relative LEA instructions in inline asm blocks. This involves a new xloadflag in the setup header to indicate that mem_encrypt=on appeared on the kernel command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20240227151907.387873-17-ardb+git@google.com
2024-03-04efi/libstub: Add generic support for parsing mem_encrypt=Ard Biesheuvel2-1/+9
Parse the mem_encrypt= command line parameter from the EFI stub if CONFIG_ARCH_HAS_MEM_ENCRYPT=y, so that it can be passed to the early boot code by the arch code in the stub. This avoids the need for the core kernel to do any string parsing very early in the boot. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20240227151907.387873-16-ardb+git@google.com
2024-03-04Merge tag 'tegra-for-6.9-firmware' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers firmware: tegra: Changes for v6.9-rc1 Contains a fix that makes sure we don't unnecessarily call kfree(). * tag 'tegra-for-6.9-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: firmware: tegra: bpmp: Return directly after a failed kzalloc() in get_filename() Link: https://lore.kernel.org/r/20240223174849.1509465-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-03-04Merge tag 'scmi-updates-6.9' of ↵Arnd Bergmann18-76/+657
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI updates for v6.9 Quite a few changes to extend support to SCMI v3.2 specification, to enhance notification handling and other miscellaneous updates. 1. Enhancements to notification handling Until now, trying to register a notifier for an unsuppported notification returned an error genrating unneeded message exchanges with the SCMI platform. This can be avoided by looking up in advance the specific protocol and resources available. With these changes SCMI driver user will fail to register a notifier if the related command or resource is not supported (like before) without the need of exchanging any message. Perf notifications are also extended to provide the pre-calculated frequencies corresponding to the level or index carried by the 2. More SCMI v3.2 related updates One of the main addition includes a centralized support to the SCMI core to handle v3.2 optional protocol version negotiation, so that at protocol initialization time, if the platform advertised version is newer than supported by the kernel and protocol version negotiation is supported, the SCMI core will attempt to negotiate an older protocol version. It also includes the clock get permissions which indicates if any of the clock operations are forbidden by the platform for the OSPM agent. It can be used in the clock driver to avoid unnecessary message exchanges between the kernel and the platform which will always end up with the failure. It also includes other missing bits of clock v3.2 protocol so that the supported protocol version can be bumped to 0x30000 (v3.2). 3. Miscellaneous updates This includes addition of warning if the domain frequency multiplier is 0 or rounded off to indicate the actual frequencies are either wrong ot rounded off, hardening of clock domain info lookups, addition of multiple protocols registration support within a SCMI driver, update to SCMI entry in MAINTAINERS to include HWMON driver and constifying the scmi_bus_type structure. This also includes couple for fixes to minor issues: double free in SMC transport cleanup path and struct kernel-doc warnings in optee transport. * tag 'scmi-updates-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (29 commits) MAINTAINERS: Update SCMI entry with HWMON driver firmware: arm_scmi: Update the supported clock protocol version firmware: arm_scmi: Add standard clock OEM definitions firmware: arm_scmi: Add clock check for extended config support firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSION firmware: arm_scmi: Fix struct kernel-doc warnings in optee transport firmware: arm_scmi: Report frequencies in the perf notifications firmware: arm_scmi: Use opps_by_lvl to store opps firmware: arm_scmi: Implement is_notify_supported callback in powercap protocol firmware: arm_scmi: Implement is_notify_supported callback in reset protocol firmware: arm_scmi: Implement is_notify_supported callback in sensor protocol firmware: arm_scmi: Implement is_notify_supported callback in clock protocol firmware: arm_scmi: Implement is_notify_supported callback in system power protocol firmware: arm_scmi: Implement is_notify_supported callback in power protocol firmware: arm_scmi: Implement is_notify_supported callback in perf protocol firmware: arm_scmi: Add a common helper to check if a message is supported firmware: arm_scmi: Check for notification support firmware: arm_scmi: Make scmi_bus_type const firmware: arm_scmi: Fix double free in SMC transport cleanup path firmware: arm_scmi: Implement clock get permissions ... Link: https://lore.kernel.org/r/20240223033435.118028-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-03-01Merge tag 'efi-fixes-for-v6.8-2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Only the EFI variable name size change is significant, and will be backported once it lands. The others are cleanup. - Fix phys_addr_t size confusion in 32-bit capsule loader - Reduce maximum EFI variable name size to 512 to work around buggy firmware - Drop some redundant code from efivarfs while at it" * tag 'efi-fixes-for-v6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efivarfs: Drop 'duplicates' bool parameter on efivar_init() efivarfs: Drop redundant cleanup on fill_super() failure efivarfs: Request at most 512 bytes for variable names efi/capsule-loader: fix incorrect allocation size
2024-02-23Merge tag 'riscv-firmware-fixes-for-v6.8-rc6' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes Microchip firmware driver fixes for v6.8-rc6 A single fix for me incorrectly using sizeof(). Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-firmware-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: fix wrong sizeof argument Link: https://lore.kernel.org/r/20240221-recognize-dust-4bb575f4e67b@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-22firmware: arm_scmi: Update the supported clock protocol versionCristian Marussi1-1/+1
And finally update the supported clock protocol version to v3.2(0x30000). Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add standard clock OEM definitionsCristian Marussi1-13/+19
Add a common enum to define the standard clock OEM types defined by the SCMI specification, so as to enable the configuration of such extended configuration properties with the existent clock protocol operations. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add clock check for extended config supportCristian Marussi1-6/+27
SCMI v3.2 added support to set/get clock custom OEM types; such support is conditionally present, though, depending on an extended config attribute bit possibly advertised by the platform server on a per-domain base. Add a check to verify if OEM types are supported before allowing any kind of OEM-specific get/set operation. Also add a check around all the new v3.2 clock features. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSIONCristian Marussi2-5/+61
Freshly introduced NEGOTIATE_PROTOCOL_VERSION allows the agent to ascertain upfront if a specific protocol(usually older) version is supported by the platform. It is used by the agent in case the platform has advertised the support of a newer protocol version than the latest version supported by the agent, since backward compatibility cannot be automatically assumed. Emit a warning about possible incompatibility when negotiation was not possible or just print the successfully negotiated protocol. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Fix struct kernel-doc warnings in optee transportRandy Dunlap1-2/+4
Fix the kernel-doc notation for the nested union in struct scmi_optee_channel to eliminate kernel-doc warnings: | optee.c:130: warning: Excess struct member 'shmem' description | in 'scmi_optee_channel' | optee.c:131: warning: Function parameter or struct member 'req' | not described in 'scmi_optee_channel' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240221062157.8694-1-rdunlap@infradead.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-21firmware: tegra: bpmp: Return directly after a failed kzalloc() in ↵Markus Elfring1-1/+1
get_filename() The kfree() function was called in one case by the get_filename() function during error handling even if the passed variable contained a null pointer. This issue was detected by using the Coccinelle software. Thus return directly after a call of the function “kzalloc” failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Thierry Reding <treding@nvidia.com>
2024-02-20firmware: arm_scmi: Report frequencies in the perf notificationsCristian Marussi1-0/+69
Extend the perf notification report to include pre-calculated frequencies corresponding to the reported limits/levels event; such frequencies are properly computed based on the stored known OPPs information taking into consideration if the current operating mode is level indexed or not. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-12-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Use opps_by_lvl to store oppsCristian Marussi1-11/+19
Store all the discovered OPPs into the XArray opps_by_lvl even when level_indexing mode is not used, since it comes handy to easily retrieve OPPs by level. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-11-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in powercap protocolCristian Marussi1-4/+41
Add a preliminary check to verify if the powercap protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-10-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in reset protocolCristian Marussi1-8/+29
Add a preliminary check to verify if the reset protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in sensor protocolCristian Marussi1-1/+36
Add a preliminary check to verify if the sensor protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in clock protocolCristian Marussi1-4/+43
Add a preliminary check to verify if the clock protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_ffa: Make ffa_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the ffa_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240211-bus_cleanup-firmware2-v1-1-1851c92c7be7@marliere.net Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in system power ↵Cristian Marussi1-0/+16
protocol Add a preliminary check to verify if the system power protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in power protocolCristian Marussi1-3/+27
Add a preliminary check to verify if the power related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in perf protocolCristian Marussi1-3/+42
Add a preliminary check to verify if the performance related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Add a common helper to check if a message is supportedCristian Marussi2-0/+38
A common helper is provided to check if a specific protocol message is supported or not. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Check for notification supportCristian Marussi2-1/+20
When registering protocol events, use the optional .is_notify_supported callback provided by the protocol to check if that specific notification type is available for that particular resource on the running system, marking it as unsupported otherwise. Then, when a notification enable request is received, return an error if it was previously marked as unsuppported, so avoiding to send a needless notification enable command and check the returned value for failure. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Make scmi_bus_type constRicardo B. Marliere2-2/+2
Now that the driver core can properly handle constant struct bus_type, move the scmi_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240211-bus_cleanup-firmware2-v1-2-1851c92c7be7@marliere.net Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Fix double free in SMC transport cleanup pathAndre Przywara1-0/+7
When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240126122325.2039669-1-andre.przywara@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement clock get permissionsPeng Fan1-0/+64
ARM SCMI v3.2 introduces clock get permission command. To implement the same let us stash the values of those permissions in the scmi_clock_info. They indicate if the operation is forbidden or not. If the CLOCK_GET_PERMISSIONS command is not supported, the default permissions are set to allow the operations, otherwise they will be set according to the response of CLOCK_GET_PERMISSIONS from the SCMI platform firmware. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20240121110901.1414856-1-peng.fan@oss.nxp.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Add multiple protocols registration supportCristian Marussi1-2/+22
Add the capability for a SCMI driver to register to the core SCMI stack with multiple SCMI protocols. In such a case the SCMI driver probe function will end up being called once for each registered protocol which have been also found as implemented on the platform. This is especially useful in testing scenarios. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231221151129.325749-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Rework clock domain info lookupsCristian Marussi1-6/+14
Accessing clock domains descriptors by the index from the SCMI drivers can potentially lead to out-of-bound violations if the SCMI drivers misbehaves. Use a common helper to check the consistency of such accesses. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240110120916.2482603-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Warn if domain frequency multiplier is 0 or rounded offSudeep Holla1-2/+17
When (sustained_freq_khz * 1000) is less than sustained_perf_level, the multiplier will be less than 1 and hence rounded down as 0. Similarly if it is not multiple of sustained_perf_level the dom_info->mult_factor will contain rounded down value and will end up impacting all the frequency calculations done using it. Add warning if and when the domain frequency multiplier is 0 or rounded down so that it gives a clue to get the firmware tables fixed. Suggested-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240119152338.3047620-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-13efi/capsule-loader: fix incorrect allocation sizeArnd Bergmann1-1/+1
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-02-09Merge tag 'efi-fixes-for-v6.8-1' of ↵Linus Torvalds12-33/+62
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "The only notable change here is the patch that changes the way we deal with spurious errors from the EFI memory attribute protocol. This will be backported to v6.6, and is intended to ensure that we will not paint ourselves into a corner when we tighten this further in order to comply with MS requirements on signed EFI code. Note that this protocol does not currently exist in x86 production systems in the field, only in Microsoft's fork of OVMF, but it will be mandatory for Windows logo certification for x86 PCs in the future. - Tighten ELF relocation checks on the RISC-V EFI stub - Give up if the new EFI memory attributes protocol fails spuriously on x86 - Take care not to place the kernel in the lowest 16 MB of DRAM on x86 - Omit special purpose EFI memory from memblock - Some fixes for the CXL CPER reporting code - Make the PE/COFF layout of mixed-mode capable images comply with a strict interpretation of the spec" * tag 'efi-fixes-for-v6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section cxl/trace: Remove unnecessary memcpy's cxl/cper: Fix errant CPER prints for CXL events efi: Don't add memblocks for soft-reserved memory efi: runtime: Fix potential overflow of soft-reserved region size efi/libstub: Add one kernel-doc comment x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR x86/efistub: Give up if memory attribute protocol returns an error riscv/efistub: Tighten ELF relocation check riscv/efistub: Ensure GP-relative addressing is not used
2024-02-03cxl/cper: Fix errant CPER prints for CXL eventsIra Weiny1-0/+19
Jonathan reports that CXL CPER events dump an extra generic error message. {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 {1}[Hardware Error]: event severity: recoverable {1}[Hardware Error]: Error 0, type: recoverable {1}[Hardware Error]: section type: unknown, fbcd0a77-c260-417f-85a9-088b1621eba6 {1}[Hardware Error]: section length: 0x90 {1}[Hardware Error]: 00000000: 00000090 00000007 00000000 0d938086 ................ {1}[Hardware Error]: 00000010: 00100000 00000000 00040000 00000000 ................ ... CXL events were rerouted though the CXL subsystem for additional processing. However, when that work was done it was missed that cper_estatus_print_section() continued with a generic error message which is confusing. Teach CPER print code to ignore printing details of some section types. Assign the CXL event GUIDs to this set to prevent confusing unknown prints. Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-02-02efi: Don't add memblocks for soft-reserved memoryAndrew Bresticker1-9/+10
Adding memblocks for soft-reserved regions prevents them from later being hotplugged in by dax_kmem. Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-02-02efi: runtime: Fix potential overflow of soft-reserved region sizeAndrew Bresticker2-2/+2
md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region. Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-30efi/libstub: Add one kernel-doc commentYang Li1-0/+1
Add the description of @memory_type to silence the warning: drivers/firmware/efi/libstub/alignedmem.c:27: warning: Function parameter or struct member 'memory_type' not described in 'efi_allocate_pages_aligned' Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> [ardb: tweak comment] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-30x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDRArd Biesheuvel5-8/+12
The EFI stub's kernel placement logic randomizes the physical placement of the kernel by taking all available memory into account, and picking a region at random, based on a random seed. When KASLR is disabled, this seed is set to 0x0, and this results in the lowest available region of memory to be selected for loading the kernel, even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is typically reserved for the GFP_DMA region, to accommodate masters that can only access the first 16 MiB of system memory. Even if such devices are rare these days, we may still end up with a warning in the kernel log, as reported by Tom: swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 Fix this by tweaking the random allocation logic to accept a low bound on the placement, and set it to LOAD_PHYSICAL_ADDR. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Reported-by: Tom Englund <tomenglund26@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404 Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-29firmware: microchip: fix wrong sizeof argumentSamasth Norway Ananda1-1/+1
response_msg is a pointer to an unsigned int (u32). So passing just response_msg to sizeof would not print the size of the variable. To get the size of response_msg we need to pass it as a pointer variable. Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-01-27Merge tag 'drm-fixes-2024-01-27' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-1/+1
Pull drm fixes from Dave Airlie: "Lots going on for rc2, ivpu has a bunch of stabilisation and debugging work, then amdgpu and xe are the main fixes. i915, exynos have a few, then some misc panel and bridge fixes. Worth mentioning are three regressions. One of the nouveau fixes in 6.7 for a serious deadlock had side effects, so I guess we will bring back the deadlock until I can figure out what should be done properly. There was a scheduler regression vs amdgpu which was reported in a few places and is now fixed. There was an i915 vs simpledrm problem resulting in black screens, that is reverted also. I'll be working on a proper nouveau fix, it kinda looks like one of those cases where someone tried to use an atomic where they should have probably used a lock, but I'll see. fb: - fix simpledrm/i915 regression by reverting change scheduler: - fix regression affecting amdgpu users due to sched draining nouveau: - revert 6.7 deadlock fix as it has side effects dp: - fix documentation warning ttm: - fix dummy page read on some platforms bridge: - anx7625 suspend fix - sii902x: fix probing and audio registration - parade-ps8640: fix suspend of bridge, aux fixes - samsung-dsim: avoid using FORCE_STOP_STATE panel: - simple add missing bus flags - fix samsung-s6d7aa0 flags amdgpu: - AC/DC power supply tracking fix - Don't show invalid vram vendor data - SMU 13.0.x fixes - GART fix for umr on systems without VRAM - GFX 10/11 UNORD_DISPATCH fixes - IPS display fixes (required for S0ix on some platforms) - Misc fixes i915: - DSI sequence revert to fix GitLab #10071 and DP test-pattern fix - Drop -Wstringop-overflow (broken on GCC11) ivpu: - fix recovery/reset support - improve submit ioctl stability - fix dev open/close races on unbind - PLL disable reset fix - deprecate context priority param - improve debug buffer logging - disable buffer sharing across VPU contexts - free buffer sgt on unbind - fix missing lock around shmem vmap - add better boot diagnostics - add more debug prints around mapping - dump MMU events in case of timeout v3d: - NULL ptr dereference fix exynos: - fix stack usage - fix incorrect type - fix dt typo - fix gsc runtime resume xe: - Make an ops struct static - Fix an implicit 0 to NULL conversion - A couple of 32-bit fixes - A migration coherency fix for Lunar Lake. - An error path vm id leak fix - Remove PVC references in kunit tests" * tag 'drm-fixes-2024-01-27' of git://anongit.freedesktop.org/drm/drm: (66 commits) Revert "nouveau: push event block/allowing out of the fence context" drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE drm/sched: Drain all entities in DRM sched run job worker drm/amd/display: "Enable IPS by default" drm/amd: Add a DC debug mask for IPS drm/amd/display: Disable ips before dc interrupt setting drm/amd/display: Replay + IPS + ABM in Full Screen VPB drm/amd/display: Add IPS checks before dcn register access drm/amd/display: Add Replay IPS register for DMUB command table drm/amd/display: Allow IPS2 during Replay drm/amdgpu/gfx11: set UNORD_DISPATCH in compute MQDs drm/amdgpu/gfx10: set UNORD_DISPATCH in compute MQDs drm/amd/amdgpu: Assign GART pages to AMD device mapping drm/amd/pm: Fetch current power limit from FW drm/amdgpu: Fix null pointer dereference drm/amdgpu: Show vram vendor only if available drm/amd/pm: update the power cap setting drm/amdgpu: Avoid fetching vram vendor information drm/amdgpu/pm: Fix the power source flag error drm/amd/display: Fix uninitialized variable usage in core_link_ 'read_dpcd() & write_dpcd()' functions ...
2024-01-26x86/efistub: Give up if memory attribute protocol returns an errorArd Biesheuvel2-12/+16
The recently introduced EFI memory attributes protocol should be used if it exists to ensure that the memory allocation created for the kernel permits execution. This is needed for compatibility with tightened requirements related to Windows logo certification for x86 PCs. Currently, we simply strip the execute protect (XP) attribute from the entire range, but this might be rejected under some firmware security policies, and so in a subsequent patch, this will be changed to only strip XP from the executable region that runs early, and make it read-only (RO) as well. In order to catch any issues early, ensure that the memory attribute protocol works as intended, and give up if it produces spurious errors. Note that the DXE services based fallback was always based on best effort, so don't propagate any errors returned by that API. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-25Merge tag 'ffa-fixes-6.8' of ↵Arnd Bergmann1-28/+57
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm FF-A fixes for v6.8 Quite a few fixes addressing issues around missing RW lock initialisation in ffa_setup_partitions(), missing check for xa_load() return value, use of xa_insert instead of xa_store to flag case of duplicate insertion. It also simplifies ffa_partitions_cleanup() with xa_for_each() and xa_erase() instead of xa_extract() and kfree(). Finally it includes fixes around handling of partitions setup failures during initialisation. * tag 'ffa-fixes-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Handle partitions setup failures firmware: arm_ffa: Use xa_insert() and check for result firmware: arm_ffa: Simplify ffa_partitions_cleanup() firmware: arm_ffa: Check xa_load() return value firmware: arm_ffa: Add missing rwlock_init() for the driver partition firmware: arm_ffa: Add missing rwlock_init() in ffa_setup_partitions() Link: https://lore.kernel.org/r/20240122161652.3551159-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-01-24Revert "drivers/firmware: Move sysfb_init() from device_initcall to ↵Thomas Zimmermann1-1/+1
subsys_initcall_sync" This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4. Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync") messes up initialization order of the graphics drivers and leads to blank displays on some systems. So revert the commit. To make the display drivers fully independent from initialization order requires to track framebuffer memory by device and independently from the loaded drivers. The kernel currently lacks the infrastructure to do so. Reported-by: Jaak Ristioja <jaak@ristioja.ee> Closes: https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#t Reported-by: Huacai Chen <chenhuacai@loongson.cn> Closes: https://lore.kernel.org/dri-devel/20231108024613.2898921-1-chenhuacai@loongson.cn/ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10133 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: stable@vger.kernel.org # v6.5+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240123120937.27736-1-tzimmermann@suse.de
2024-01-23riscv/efistub: Tighten ELF relocation checkArd Biesheuvel1-1/+1
The EFI stub makefile contains logic to ensure that the objects that make up the stub do not contain relocations that require runtime fixups (typically to account for the runtime load address of the executable) On RISC-V, we also avoid GP based relocations, as they require that GP is assigned the correct base in the startup code, which is not implemented in the EFI stub. So add these relocation types to the grep expression that is used to carry out this check. Link: https://lkml.kernel.org/r/42c63cb9-87d0-49db-9af8-95771b186684%40siemens.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-23riscv/efistub: Ensure GP-relative addressing is not usedJan Kiszka1-1/+1
The cflags for the RISC-V efistub were missing -mno-relax, thus were under the risk that the compiler could use GP-relative addressing. That happened for _edata with binutils-2.41 and kernel 6.1, causing the relocation to fail due to an invalid kernel_size in handle_kernel_image. It was not yet observed with newer versions, but that may just be luck. Cc: <stable@vger.kernel.org> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-01-22firmware: arm_ffa: Handle partitions setup failuresCristian Marussi1-5/+23
Make ffa_setup_partitions() fail, cleanup and return an error when the Host partition setup fails: in such a case ffa_init() itself will fail. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-6-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_ffa: Use xa_insert() and check for resultCristian Marussi1-3/+16
While adding new partitions descriptors to the XArray the outcome of the stores should be checked and, in particular, it has also to be ensured that an existing entry with the same index was not already present, since partitions IDs are expected to be unique. Use xa_insert() instead of xa_store() since it returns -EBUSY when the index is already in use and log an error when that happens. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-5-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-31 08:26:49 +0300