aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2023-10-06firmware: arm_ffa: Add notification handling mechanismSudeep Holla1-1/+66
With all the necessary plumbing in place, let us add handling the notifications as part of schedule receiver interrupt handler. In order to do so, we need to just register scheduling callback on behalf of the driver partition. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-12-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Add interface to send a notification to a given partitionSudeep Holla1-0/+13
The framework provides an interface to the sender endpoint to specify the notification to signal to the receiver endpoint. A sender signals a notification by requesting its partition manager to set the corresponding bit in the notifications bitmap of the receiver. Expose the ability to send a notification to another partition. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-11-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Add interfaces to request notification callbacksSudeep Holla1-0/+145
Add interface to the FFA driver to allow for client drivers to request and relinquish a notification as well as provide a callback for the notification. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-10-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Add schedule receiver callback mechanismSudeep Holla1-3/+100
Enable client drivers to register a callback function that will be called when one or more notifications are pending for a target partition as part of schedule receiver interrupt handling. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-9-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Initial support for scheduler receiver interruptSudeep Holla1-10/+176
The Framework uses the schedule receiver interrupt to inform the receiver’s scheduler that the receiver must be run to handle a pending notification. A receiver’s scheduler can obtain the description of the schedule receiver interrupt by invoking the FFA_FEATURES interface. The delivery of the physical schedule receiver interrupt from the secure state to the non-secure state depends upon the state of the interrupt controller as configured by the hypervisor. The schedule seceiver interrupt is assumed to be a SGI. The Arm GIC specification defines 16 SGIs. It recommends that they are equally divided between the non-secure and secure states. OS like Linux kernel in the non-secure state typically do not have SGIs to spare. The usage of SGIs in the secure state is however limited. It is more likely that software in the Secure world does not use all the SGIs allocated to it. It is recommended that the secure world software donates an unused SGI to the normal world for use as the schedule receiver interrupt. This implies that secure world software must configure the SGI in the GIC as a non-secure interrupt before presenting it to the normal world. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-8-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interfaceSudeep Holla1-0/+73
The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface to retrieve the list of endpoints that have pending notifications and must be run. A notification could be signaled by a sender in the secure world to a VM. The Hypervisor needs to determine which VM and vCPU (in case a per-vCPU notification is signaled) has a pending notification in this scenario. It must obtain this information through an invocation of the FFA_NOTIFICATION_INFO_GET. Add the implementation of the NOTIFICATION_INFO_GET interface and prepare to use this to handle the schedule receiver interrupt. Implementation of handling notifications will be added later. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-7-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interfaceSudeep Holla1-0/+37
The framework provides an interface to the receiver to determine the identity of the notification. A receiver endpoint must use the FFA_NOTIFICATION_GET interface to retrieve its pending notifications and handle them. Add the support for FFA_NOTIFICATION_GET to allow the caller(receiver) to fetch its pending notifications from other partitions in the system. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-6-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interfaceSudeep Holla1-0/+20
The framework provides an interface to the sender to specify the notification to signal to the receiver. A sender signals a notification by requesting its partition manager to set the corresponding bit in the notifications bitmap of the receiver invoking FFA_NOTIFICATION_SET. Implement the FFA_NOTIFICATION_SET to enable the caller(sender) to send the notifications for any other partitions in the system. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-5-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement the FFA_RUN interfaceSudeep Holla1-0/+22
FFA_RUN is used by a scheduler to allocate CPU cycles to a target endpoint execution context specified in the target information parameter. If the endpoint execution context is in the waiting/blocked state, it transitions to the running state. Expose the ability to call FFA_RUN in order to give any partition in the system cpu cycles to perform IMPDEF functionality. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-4-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement the notification bind and unbind interfaceSudeep Holla1-0/+29
A receiver endpoint must bind a notification to any sender endpoint before the latter can signal the notification to the former. The receiver assigns one or more doorbells to a specific sender. Only the sender can ring these doorbells. A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more notifications to the sender. A receiver un-binds a notification from a sender endpoint to stop the notification from being signaled. It uses the FFA_NOTIFICATION_UNBIND interface to do this. Allow the FF-A driver to be able to bind and unbind a given notification ID to a specific partition ID. This will be used to register and unregister notification callbacks from the FF-A client drivers. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-3-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Implement notification bitmap create and destroy interfacesSudeep Holla1-1/+62
On systems without a hypervisor the responsibility of requesting the creation of the notification bitmaps in the SPM falls to the FF-A driver. We use FFA features to determine if the ABI is supported, if it is not we can assume there is a hypervisor present and will take care of ensure the relevant notifications bitmaps are created on this partitions behalf. An endpoint’s notification bitmaps needs to be setup before it configures its notifications and before other endpoints and partition managers can start signaling these notifications. Add interface to create and destroy the notification bitmaps and use the same to do the necessary setup during the initialisation and cleanup during the module exit. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-2-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Update the FF-A command list with v1.1 additionsSudeep Holla1-0/+1
Arm Firmware Framework for A-profile(FFA) v1.1 introduces notifications and indirect messaging based upon notifications support and extends some of the memory interfaces. Let us add all the newly supported FF-A function IDs in the spec. Also update to the error values and associated handling. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-1-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Emit modalias for FF-A devicesSudeep Holla1-1/+14
In order to enable libkmod lookups for FF-A device objects to their corresponding module, add 'modalias' to the base attribute of FF-A devices. Tested-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Link: https://lore.kernel.org/r/20231005175640.379631-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messagingSudeep Holla1-10/+2
An FF-A ABI could support both the SMC32 and SMC64 conventions. A callee that runs in the AArch64 execution state and implements such an ABI must implement both SMC32 and SMC64 conventions of the ABI. So the FF-A drivers will need the option to choose the mode irrespective of FF-A version and the partition execution mode flag in the partition information. Let us remove the check on the FF-A version for allowing the selection of 32bit mode of messaging. The driver will continue to set the 32-bit mode if the partition execution mode flag specified that the partition supports only 32-bit execution. Fixes: 106b11b1ccd5 ("firmware: arm_ffa: Set up 32bit execution mode flag using partiion property") Link: https://lore.kernel.org/r/20231005142823.278121-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA deviceSudeep Holla1-0/+1
Commit 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions") added an ID to the FFA device using ida_alloc() and append the same to "arm-ffa" to make up a unique device name. However it missed to stash the id value in ffa_dev to help freeing the ID later when the device is destroyed. Due to the missing/unassigned ID in FFA device, we get the following warning when the FF-A device is unregistered. | ida_free called for id=0 which is not allocated. | WARNING: CPU: 7 PID: 1 at lib/idr.c:525 ida_free+0x114/0x164 | CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4 #209 | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : ida_free+0x114/0x164 | lr : ida_free+0x114/0x164 | Call trace: | ida_free+0x114/0x164 | ffa_release_device+0x24/0x3c | device_release+0x34/0x8c | kobject_put+0x94/0xf8 | put_device+0x18/0x24 | klist_devices_put+0x14/0x20 | klist_next+0xc8/0x114 | bus_for_each_dev+0xd8/0x144 | arm_ffa_bus_exit+0x30/0x54 | ffa_init+0x68/0x330 | do_one_initcall+0xdc/0x250 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x104/0x170 | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 Fix the same by actually assigning the ID in the FFA device this time for real. Fixes: 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions") Link: https://lore.kernel.org/r/20231003085932.3553985-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_scmi: Specify the performance level when adding an OPPUlf Hansson1-1/+5
To enable the performance level to be used for OPPs, let's convert into using the dev_pm_opp_add_dynamic() API when creating them. This will be particularly useful for the SCMI performance domain, as shown through subsequent changes. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230925131715.138411-9-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-06firmware: arm_scmi: Simplify error path in scmi_dvfs_device_opps_add()Ulf Hansson1-12/+4
Let's simplify the code in scmi_dvfs_device_opps_add() by using dev_pm_opp_remove_all_dynamic() in the error path. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230925131715.138411-8-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-10-04pmdomain: imx: Move Kconfig options to the pmdomain subsystemUlf Hansson1-6/+0
The Kconfig options belongs closer to the corresponding implementations, hence let's move them from the soc- and firmware subsystem to the pmdomain subsystem. Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: <kernel@pengutronix.de> Cc: <linux-imx@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-10-04efi/unaccepted: do not let /proc/vmcore try to access unaccepted memoryAdrian Hunter1-0/+20
Patch series "Do not try to access unaccepted memory", v2. Support for unaccepted memory was added recently, refer commit dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby a virtual machine may need to accept memory before it can be used. Plug a few gaps where RAM is exposed without checking if it is unaccepted memory. This patch (of 2): Support for unaccepted memory was added recently, refer commit dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby a virtual machine may need to accept memory before it can be used. Do not let /proc/vmcore try to access unaccepted memory because it can cause the guest to fail. For /proc/vmcore, which is read-only, this means a read or mmap of unaccepted memory will return zeros. Link: https://lkml.kernel.org/r/20230911112114.91323-1-adrian.hunter@intel.com Link: https://lkml.kernel.org/r/20230911112114.91323-2-adrian.hunter@intel.com Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Dave Young <dyoung@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-10-02firmware: ti_sci: Mark driver as non removableDhruva Gole1-45/+1
The TI-SCI message protocol provides a way to communicate between various compute processors with a central system controller entity. It provides the fundamental device management capability and clock control in the SOCs that it's used in. The remove function failed to do all the necessary cleanup if there are registered users. Some things are freed however which likely results in an oops later on. Ensure that the driver isn't unbound by suppressing its bind and unbind sysfs attributes. As the driver is built-in there is no way to remove device once bound. We can also remove the ti_sci_remove call along with the ti_sci_debugfs_destroy as there are no callers for it any longer. Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Closes: https://lore.kernel.org/linux-arm-kernel/20230216083908.mvmydic5lpi3ogo7@pengutronix.de/ Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230921091025.133130-1-d-gole@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-09-30Merge tag 'soc-fixes-6.6' of ↵Linus Torvalds3-4/+17
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "These are the latest bug fixes that have come up in the soc tree. Most of these are fairly minor. Most notably, the majority of changes this time are not for dts files as usual. - Updates to the addresses of the broadcom and aspeed entries in the MAINTAINERS file. - Defconfig updates to address a regression on samsung and a build warning from an unknown Kconfig symbol - Build fixes for the StrongARM and Uniphier platforms - Code fixes for SCMI and FF-A firmware drivers, both of which had a simple bug that resulted in invalid data, and a lesser fix for the optee firmware driver - Multiple fixes for the recently added loongson/loongarch "guts" soc driver - Devicetree fixes for RISC-V on the startfive platform, addressing issues with NOR flash, usb and uart. - Multiple fixes for NXP i.MX8/i.MX9 dts files, fixing problems with clock, gpio, hdmi settings and the Makefile - Bug fixes for i.MX firmware code and the OCOTP soc driver - Multiple fixes for the TI sysc bus driver - Minor dts updates for TI omap dts files, to address boot time warnings and errors" * tag 'soc-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (35 commits) MAINTAINERS: Fix Florian Fainelli's email address arm64: defconfig: enable syscon-poweroff driver ARM: locomo: fix locomolcd_power declaration soc: loongson: loongson2_guts: Remove unneeded semicolon soc: loongson: loongson2_guts: Convert to devm_platform_ioremap_resource() soc: loongson: loongson_pm2: Populate children syscon nodes dt-bindings: soc: loongson,ls2k-pmc: Allow syscon-reboot/syscon-poweroff as child soc: loongson: loongson_pm2: Drop useless of_device_id compatible dt-bindings: soc: loongson,ls2k-pmc: Use fallbacks for ls2k-pmc compatible soc: loongson: loongson_pm2: Add dependency for INPUT arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y ARM: uniphier: fix cache kernel-doc warnings MAINTAINERS: aspeed: Update Andrew's email address MAINTAINERS: aspeed: Update git tree URL firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND arm64: dts: imx: Add imx8mm-prt8mm.dtb to build arm64: dts: imx8mm-evk: Fix hdmi@3d node soc: imx8m: Enable OCOTP clock for imx8mm before reading registers arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock arm64: dts: imx8mp: Fix SDMA2/3 clocks ...
2023-09-29firmware: tegra: bpmp: Replace deprecated strncpy() with strscpy_pad()Justin Stitt1-2/+2
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. It seems like the filename stored at `namevirt` is expected to be NUL-terminated. A suitable replacement is `strscpy_pad` due to the fact that it guarantees NUL-termination on the destination buffer whilst maintaining the NUL-padding behavior that strncpy provides. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230913-strncpy-drivers-firmware-tegra-bpmp-debugfs-c-v1-1-828b0a8914b5@google.com Signed-off-by: Kees Cook <keescook@chromium.org>
2023-09-28Merge tag 'scmi-fix-6.6' of ↵Arnd Bergmann1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI fix for v6.6 A single fix to address scmi_perf_attributes_get() using the protocol version even before it was populated and ending up with unexpected bogowatts power scale. * tag 'scmi-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fixup perf power-cost/microwatt support Link: https://lore.kernel.org/r/20230927121604.158645-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-09-28Merge tag 'ffa-fix-6.6' of ↵Arnd Bergmann1-2/+14
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm FF-A fix for v6.6 It has been reported that the driver sets the memory region attributes for MEM_LEND operation when the specification clearly states not to. The fix here addresses the issue by ensuring the memory region attributes are cleared for the memory lending operation. * tag 'ffa-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND Link: https://lore.kernel.org/r/20230927121555.158619-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-09-27firmware: qcom_scm: use 64-bit calling convention only when client is 64-bitKathiravan Thirumoorthy1-0/+7
Per the "SMC calling convention specification", the 64-bit calling convention can only be used when the client is 64-bit. Whereas the 32-bit calling convention can be used by either a 32-bit or a 64-bit client. Currently during SCM probe, irrespective of the client, 64-bit calling convention is made, which is incorrect and may lead to the undefined behaviour when the client is 32-bit. Let's fix it. Cc: stable@vger.kernel.org Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Reviewed-By: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Link: https://lore.kernel.org/r/20230925-scm-v3-1-8790dff6a749@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-27firmware: arm_scmi: Rename scmi_{msg_,}clock_config_{get,set}_{2,21}Sudeep Holla1-19/+22
It is very confusing to use *_v2 for everything applicable until SCMI clock protocol version v2.0 including v1.0 for example. So let us rename such that *_v2 is used only for SCMI clock protocol v2.1 onwards. Also add comment to indicate the same explicitly. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230925101557.3839860-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-27firmware: arm_scmi: Do not use !! on boolean when setting msg->flagsSudeep Holla1-2/+2
Both pc->async_powercap_cap_set and ignore_dresp are already boolean. Use of !! on them is obviously dubious. Sparse reports: drivers/firmware/arm_scmi/powercap.c:363:17: warning: dubious: x & !y drivers/firmware/arm_scmi/powercap.c:363:17: warning: dubious: x & !y Remove the unnecessary !! and get rid of the warning. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230921085257.3125744-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-25firmware: arm_ffa: Don't set the memory region attributes for MEM_LENDSudeep Holla1-2/+14
As per the FF-A specification: section "Usage of other memory region attributes", in a transaction to donate memory or lend memory to a single borrower, if the receiver is a PE or Proxy endpoint, the owner must not specify the attributes and the relayer will return INVALID_PARAMETERS if the attributes are set. Let us not set the memory region attributes for MEM_LEND. Fixes: 82a8daaecfd9 ("firmware: arm_ffa: Add support for MEM_LEND") Reported-by: Joao Alves <joao.alves@arm.com> Reported-by: Olivier Deprez <olivier.deprez@arm.com> Link: https://lore.kernel.org/r/20230919-ffa_v1-1_notif-v2-13-6f3a3ca3923c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-22Merge tag 'efi-fixes-for-v6.6-2' of ↵Linus Torvalds1-3/+29
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fix from Ard Biesheuvel: "Follow-up fix for the unaccepted memory fix merged last week as part of the first EFI fixes batch. The unaccepted memory table needs to be accessible very early, even in cases (such as crashkernels) where the direct map does not cover all of DRAM, and so it is added to memblock explicitly, and subsequently memblock_reserve()'d as before" * tag 'efi-fixes-for-v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/unaccepted: Make sure unaccepted table is mapped
2023-09-21firmware: arm_scmi: Move power-domain driver to the pmdomain dirSudeep Holla2-154/+0
To simplify with maintenance let's move the Arm SCMI power-domain driver to the new pmdomain directory. Link: https://lore.kernel.org/all/20230921113328.3208651-1-sudeep.holla@arm.com Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21pmdomain: arm: Add the SCMI performance domainUlf Hansson1-0/+12
To enable support for performance scaling (DVFS) for generic devices with the SCMI performance protocol, let's add an SCMI performance domain. This is being modelled as a genpd provider, with support for performance scaling through genpd's ->set_performance_state() callback. Note that, this adds the initial support that allows consumer drivers for attached devices, to vote for a new performance state via calling the dev_pm_genpd_set_performance_state(). However, this should be avoided as it's in most cases preferred to use the OPP library to vote for a new OPP instead. The support using the OPP library isn't part of this change, but needs to be implemented from subsequent changes. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230919121605.7304-1-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21firmware: arm_scmi: Drop redundant ->device_domain_id() from perf opsUlf Hansson1-13/+0
There are no longer any users of the ->device_domain_id() ops in the scmi_perf_proto_ops, therefore let's remove it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-6-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21firmware: arm_scmi: Align perf ops to use domain-id as in-parameterUlf Hansson1-18/+4
Most scmi_perf_proto_ops are already using an "u32 domain" as an in-parameter to indicate what performance domain we shall operate upon. However, some of the ops are using a "struct device *dev", which means that an additional OF parsing is needed each time the perf ops gets called, to find the corresponding domain-id. To avoid the above, but also to make the code more consistent, let's replace the in-parameter "struct device *dev" with an "u32 domain". Note that, this requires us to make some corresponding changes to the scmi cpufreq driver, so let's do that too. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-5-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21firmware: arm_scmi: Extend perf protocol ops to get information of a domainUlf Hansson1-17/+30
Similar to other protocol ops, it's useful for an scmi module driver to get some generic information of a performance domain. Therefore, let's add a new callback to provide this information. The information is currently limited to the name of the performance domain and whether the set-level operation is supported, although this can easily be extended if we find the need for it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-3-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21firmware: arm_scmi: Extend perf protocol ops to get number of domainsUlf Hansson1-0/+8
Similar to other protocol ops, it's useful for an scmi module driver to get the number of supported performance domains, hence let's make this available by adding a new perf protocol callback. Note that, a user is being added from subsequent changes. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-2-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-21Merge tag 'sound-6.6-rc3' of ↵Linus Torvalds1-17/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A large collection of fixes around this time. All small and mostly trivial fixes. - Lots of fixes for the new -Wformat-truncation warnings - A fix in ALSA rawmidi core regression and UMP handling - Series of Cirrus codec fixes - ASoC Intel and Realtek codec fixes - Usual HD- and USB-audio quirks and AMD ASoC quirks" * tag 'sound-6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (64 commits) ALSA: hda/realtek - ALC287 Realtek I2S speaker platform support ALSA: hda: cs35l56: Use the new RUNTIME_PM_OPS() macro ALSA: usb-audio: scarlett_gen2: Fix another -Wformat-truncation warning ALSA: rawmidi: Fix NULL dereference at proc read ASoC: SOF: core: Only call sof_ops_free() on remove if the probe was successful ASoC: SOF: Intel: MTL: Reduce the DSP init timeout ASoC: cs42l43: Add shared IRQ flag for shutters ASoC: imx-audmix: Fix return error with devm_clk_get() ASoC: hdaudio.c: Add missing check for devm_kstrdup ALSA: riptide: Fix -Wformat-truncation warning for longname string ALSA: cs4231: Fix -Wformat-truncation warning for longname string ALSA: ad1848: Fix -Wformat-truncation warning for longname string ALSA: hda: generic: Check potential mixer name string truncation ALSA: cmipci: Fix -Wformat-truncation warning ALSA: firewire: Fix -Wformat-truncation warning for MIDI stream names ALSA: firewire: Fix -Wformat-truncation warning for longname string ALSA: xen: Fix -Wformat-truncation warning ALSA: opti9x: Fix -Wformat-truncation warning ALSA: es1688: Fix -Wformat-truncation warning ALSA: cs4236: Fix -Wformat-truncation warning ...
2023-09-20firmware: qcom_scm: disable SDI if requiredRobert Marko2-0/+31
IPQ5018 has SDI (Secure Debug Image) enabled by TZ by default, and that means that WDT being asserted or just trying to reboot will hang the board in the debug mode and only pulling the power and repowering will help. Some IPQ4019 boards like Google WiFI have it enabled as well. Luckily, SDI can be disabled via an SCM call. So, lets use the boolean DT property to identify boards that have SDI enabled by default and use the SCM call to disable SDI during SCM probe. It is important to disable it as soon as possible as we might have a WDT assertion at any time which would then leave the board in debug mode, thus disabling it during SCM removal is not enough. Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Link: https://lore.kernel.org/r/20230816164641.3371878-2-robimarko@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-20firmware: arm_scmi: Add clock OEM config clock operationsCristian Marussi1-0/+22
Expose a couple of new SCMI clock operations to get and set OEM specific clock configurations when talking to an SCMI v3.2 compliant. Issuing such requests against an SCMI platform server not supporting v3.2 extension for OEM specific clock configurations will fail. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230826125308.462328-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-20firmware: arm_scmi: Add clock .state_get support to pre-v3.2Cristian Marussi1-7/+45
Support clock .state_get operation against SCMI platform servers that do not support v3.2 CONFIG_GET dedicated command: while talking with these platforms the command CLOCK_ATTRIBUTES can be used to gather the current clock states. Note that, in case of shared resources, the retrieved clock state 'flavour' (virtual vs physical) depends on the backend SCMI platform server specific kind of implementation. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230826125308.462328-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-20firmware: arm_scmi: Add v3.2 clock CONFIG_GET supportCristian Marussi1-0/+64
Add support for v3.2 clock CONFIG_GET command and related new clock protocol operation state_get() to retrieve the status of a clock. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230826125308.462328-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-20firmware: arm_scmi: Add clock v3.2 CONFIG_SET supportCristian Marussi1-8/+80
SCMI v3.2 introduces a new clock CONFIG_SET message format that can optionally carry also OEM specific configuration values beside the usual clock enable/disable requests. Refactor internal helpers and add support to use such new format when talking to a v3.2 compliant SCMI platform. Support existing enable/disable operations across different clock protocol versions: this patch still does not add protocol operations to support the new OEM specific optional configuration capabilities. No functional change for the SCMI drivers users of the related enable and disable clock operations. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230826125308.462328-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-20firmware: arm_scmi: Simplify enable/disable clock operationsCristian Marussi1-18/+6
SCMI clock enable/disable operations come in 2 different flavours which simply just differ in how the underlying SCMI transactions is carried on: atomic or not. Currently we expose such SCMI operations through 2 distinctly named wrappers, that, in turn, are wrapped into another couple of similarly and distinctly named callbacks inside SCMI clock driver user. Reduce the churn of duplicated wrappers by adding a param to SCMI clock enable/disable operations to ask for atomic operation while removing the _atomic version of such operations. No functional change. CC: Michael Turquette <mturquette@baylibre.com> CC: Stephen Boyd <sboyd@kernel.org> CC: linux-clk@vger.kernel.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230826125308.462328-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-09-20firmware: ti_sci: refactor deprecated strncpyJustin Stitt1-1/+1
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer. It does not seem like `ver->firmware_description` requires NUL-padding (which is a behavior that strncpy provides) but if it does let's opt for `strscpy_pad()`. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230913-strncpy-drivers-firmware-ti_sci-c-v1-1-740db471110d@google.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-09-20firmware: ti_sci: Use list_for_each_entry() helperJinjie Ruan1-6/+2
Convert list_for_each() to list_for_each_entry() so that the p list_head pointer and list_entry() call are no longer needed, which can reduce a few lines of code. No functional changed. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230830090344.528818-1-ruanjinjie@huawei.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-09-19efi/unaccepted: Make sure unaccepted table is mappedKirill A. Shutemov1-3/+29
Unaccepted table is now allocated from EFI_ACPI_RECLAIM_MEMORY. It translates into E820_TYPE_ACPI, which is not added to memblock and therefore not mapped in the direct mapping. This causes a crash on the first touch of the table. Use memblock_add() to make sure that the table is mapped in direct mapping. Align the range to the nearest page borders. Ranges smaller than page size are not mapped. Fixes: e7761d827e99 ("efi/unaccepted: Use ACPI reclaim memory for unaccepted memory table") Reported-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-09-19firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()Christophe JAILLET1-0/+1
If mbox_request_channel_byname() fails, the memory allocated a few lines above still need to be freed before going to the error handling path. Fixes: 046326989a18 ("firmware: imx: Save channel name for further use") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-09-15firmware: qcom: qseecom: Add missing AUXILIARY_BUS dependencyBjorn Andersson1-0/+1
The newly introduced QSEECOM driver fail to link if the system is built without CONFIG_AUXILIARY_BUS, make sure it is selected. Fixes: 00b1248606ba ("firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface") Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/r/9f156fa6-e5aa-4cb2-ab2b-b67fd8fc4840%40infradead.org Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230915-qseecom-auxiliary-fix-v1-1-38a46cfbfdb0@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-09-15x86/efi: Disregard setup header of loaded imageArd Biesheuvel1-40/+6
The native EFI entrypoint does not take a struct boot_params from the loader, but instead, it constructs one from scratch, using the setup header data placed at the start of the image. This setup header is placed in a way that permits legacy loaders to manipulate the contents (i.e., to pass the kernel command line or the address and size of an initial ramdisk), but EFI boot does not use it in that way - it only copies the contents that were placed there at build time, but EFI loaders will not (and should not) manipulate the setup header to configure the boot. (Commit 63bf28ceb3ebbe76 "efi: x86: Wipe setup_data on pure EFI boot" deals with some of the fallout of using setup_data in a way that breaks EFI boot.) Given that none of the non-zero values that are copied from the setup header into the EFI stub's struct boot_params are relevant to the boot now that the EFI stub no longer enters via the legacy decompressor, the copy can be omitted altogether. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-19-ardb@google.com
2023-09-15x86/efi: Drop EFI stub .bss from .data sectionArd Biesheuvel1-7/+0
Now that the EFI stub always zero inits its BSS section upon entry, there is no longer a need to place the BSS symbols carried by the stub into the .data section. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230912090051.4014114-18-ardb@google.com
2023-09-14firmware: qcom-scm: order includes alphabeticallyBartosz Golaszewski1-8/+9
For easier maintenance order the included headers in qcom_scm.c alphabetically. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230913192826.36187-2-bartosz.golaszewski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Powered by cgit, Gruvboxed by Blaster4385.