user/sven/linux.git/drivers/firmware, branch v6.6.7

firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode

2023-12-13T17:45:15Z

[ Upstream commit 77f5032e94f244ba08db51e17ca8f37bd7ff9acb ] The multiplier is already promoted to unsigned long, however the frequency calculations done when using level indexing mode doesn't use the multiplier computed. It instead hardcodes the multiplier value of 1000 at all the usage sites. Clean that up by assigning the multiplier value of 1000 when using the perf level indexing mode and update the frequency calculations to use the multiplier instead. It should fix the possible frequency truncation for all the values greater than or equal to 4GHz on 64-bit machines. Fixes: 31c7c1397a33 ("firmware: arm_scmi: Add v3.2 perf level indexing mode support") Reported-by: Sibi Sankar Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi Link: https://lore.kernel.org/r/20231130204343.503076-2-sudeep.holla@arm.com Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Simplify error path in scmi_dvfs_device_opps_add()

2023-12-13T17:45:15Z

[ Upstream commit 033ca4de129646e9969a6838b44cca0fac38e219 ] 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 Link: https://lore.kernel.org/r/20230925131715.138411-8-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla Stable-dep-of: 77f5032e94f2 ("firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode") Signed-off-by: Sasha Levin

firmware: arm_scmi: Fix frequency truncation by promoting multiplier type

2023-12-13T17:45:15Z

[ Upstream commit 8e3c98d9187e09274fc000a7d1a77b070a42d259 ] Fix the possible frequency truncation for all values equal to or greater 4GHz on 64bit machines by updating the multiplier 'mult_factor' to 'unsigned long' type. It is also possible that the multiplier itself can be greater than or equal to 2^32. So we need to also fix the equation computing the value of the multiplier. Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") Reported-by: Sibi Sankar Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi Link: https://lore.kernel.org/r/20231130204343.503076-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Extend perf protocol ops to get information of a domain

2023-12-13T17:45:15Z

[ Upstream commit 3d99ed60721bf2e108c8fc660775766057689a92 ] 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 Link: https://lore.kernel.org/r/20230825112633.236607-3-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla Stable-dep-of: 8e3c98d9187e ("firmware: arm_scmi: Fix frequency truncation by promoting multiplier type") Signed-off-by: Sasha Levin

firmware: arm_scmi: Extend perf protocol ops to get number of domains

2023-12-13T17:45:15Z

[ Upstream commit e9090e70e618cd62ab7bf2914511e5eea31a2535 ] 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 Link: https://lore.kernel.org/r/20230825112633.236607-2-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla Stable-dep-of: 8e3c98d9187e ("firmware: arm_scmi: Fix frequency truncation by promoting multiplier type") Signed-off-by: Sasha Levin

efi/unaccepted: Fix off-by-one when checking for overlapping ranges

2023-12-08T07:52:23Z

[ Upstream commit 01b1e3ca0e5ce47bbae8217d47376ad01b331b07 ] When a task needs to accept memory it will scan the accepting_list to see if any ranges already being processed by other tasks overlap with its range. Due to an off-by-one in the range comparisons, a task might falsely determine that an overlapping range is being accepted, leading to an unnecessary delay before it begins processing the range. Fix the off-by-one in the range comparison to prevent this and slightly improve performance. Fixes: 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance") Link: https://lore.kernel.org/linux-mm/20231101004523.vseyi5bezgfaht5i@amd.com/T/#me2eceb9906fcae5fe958b3fe88e41f920f8335b6 Reviewed-by: Kirill A. Shutemov Signed-off-by: Michael Roth Acked-by: Vlastimil Babka Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

firmware: qcom_scm: use 64-bit calling convention only when client is 64-bit

2023-11-28T17:20:03Z

commit 3337a6fea25370d3d244ec6bb38c71ee86fcf837 upstream. 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 Signed-off-by: Kathiravan Thirumoorthy Link: https://lore.kernel.org/r/20230925-scm-v3-1-8790dff6a749@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

firmware: tegra: Add suspend hook and reset BPMP IPC early on resume

2023-11-20T10:59:16Z

[ Upstream commit ea608a01d4ee66f8b51070e623f9adb8684c0dd4 ] Add suspend hook and a 'suspended' field in the 'struct tegra_bpmp' to mark if BPMP is suspended. Also, add a 'flags' field in the 'struct tegra_bpmp_message' whose 'TEGRA_BPMP_MESSAGE_RESET' bit can be set from the Tegra MC driver to signal that the reset of BPMP IPC channels is required before sending MRQ to the BPMP FW. Together both the fields allow us to handle any requests that might be sent too soon as they can cause hang during system resume. One case where we see BPMP requests being sent before the BPMP driver has resumed is the memory bandwidth requests which are triggered by onlining the CPUs during system resume. The CPUs are onlined before the BPMP has resumed and we need to reset the BPMP IPC channels to handle these requests. The additional check for 'flags' is done to avoid any un-intended BPMP IPC reset if the tegra_bpmp_transfer*() API gets called during suspend sequence after the BPMP driver is suspended. Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Co-developed-by: Thierry Reding Signed-off-by: Sumit Gupta Acked-by: Thierry Reding Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messaging

2023-11-20T10:59:16Z

[ Upstream commit 2d698e8b4fd22374dac0a2d5150ab24d57a222ab ] 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 Signed-off-by: Sasha Levin

firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA device

2023-11-20T10:59:16Z

[ Upstream commit 7d0bc6360f17ea323ab25939a34857123d7d87e5 ] 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 Signed-off-by: Sasha Levin