summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2024-11-01Merge tag 'tegra-for-6.13-firmware' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers firmware: tegra: Changes for v6.13-rc1 This contains a revert for a patch that I had modified before applying and the author didn't agree with the change. * tag 'tegra-for-6.13-firmware' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: Revert "firmware: tegra: bpmp: Use scoped device node handling to simplify error paths" Link: https://lore.kernel.org/r/20241025150555.2558582-1-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-01Merge tag 'scmi-fixes-6.12-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into HEAD Arm SCMI fixes for v6.12(part 2) Couple of fixes to address slab-use-after-free in scmi_bus_notifier() via scmi_dev->name and possible incorrect clear channel transport operation on A2P channel if some sort of P2A only messages are initiated on A2P channel(occurs when stress tested passing /dev/random to the channel). Apart from this, there are fixes to address missing "arm" prefix in the recently added property max-rx-timeout-ms which was missed in the review but was identified when further additions to the same binding were getting reviewed. * tag 'scmi-fixes-6.12-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Use vendor string in max-rx-timeout-ms dt-bindings: firmware: arm,scmi: Add missing vendor string firmware: arm_scmi: Reject clear channel request on A2P firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() Link: https://lore.kernel.org/r/20241031172734.3109140-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-01Merge tag 'riscv-soc-fixes-for-v6.12-rc6' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into HEAD RISC-V soc fixes for v6.12-rc6 StarFive: Two minor dts fixes, one setting the correct eth phy delay parameters and one disabling unused nodes that caused warnings at probe time. Firmware: Fix the poll_complete() implementation in the auto-update driver so that it behaves as the framework expects. Misc: Update the maintainer pattern for my dts entry, so that it covers the specific platforms listed , rather than including all riscv platforms with the list platforms excluded. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-soc-fixes-for-v6.12-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: MAINTAINERS: invert Misc RISC-V SoC Support's pattern riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64 riscv: dts: starfive: disable unused csi/camss nodes firmware: microchip: auto-update: fix poll_complete() to not report spurious timeout errors Link: https://lore.kernel.org/r/20241031-colossal-cassette-617817c9bec3@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-10-31arm64: Use SYSTEM_OFF2 PSCI call to power off for hibernateDavid Woodhouse
The PSCI v1.3 specification adds support for a SYSTEM_OFF2 function which is analogous to ACPI S4 state. This will allow hosting environments to determine that a guest is hibernated rather than just powered off, and handle that state appropriately on subsequent launches. Since commit 60c0d45a7f7a ("efi/arm64: use UEFI for system reset and poweroff") the EFI shutdown method is deliberately preferred over PSCI or other methods. So register a SYS_OFF_MODE_POWER_OFF handler which *only* handles the hibernation, leaving the original PSCI SYSTEM_OFF as a last resort via the legacy pm_power_off function pointer. The hibernation code already exports a system_entering_hibernation() function which is be used by the higher-priority handler to check for hibernation. That existing function just returns the value of a static boolean variable from hibernate.c, which was previously only set in the hibernation_platform_enter() code path. Set the same flag in the simpler code path around the call to kernel_power_off() too. An alternative way to hook SYSTEM_OFF2 into the hibernation code would be to register a platform_hibernation_ops structure with an ->enter() method which makes the new SYSTEM_OFF2 call. But that would have the unwanted side-effect of making hibernation take a completely different code path in hibernation_platform_enter(), invoking a lot of special dpm callbacks. Another option might be to add a new SYS_OFF_MODE_HIBERNATE mode, with fallback to SYS_OFF_MODE_POWER_OFF. Or to use the sys_off_data to indicate whether the power off is for hibernation. But this version works and is relatively simple. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20241019172459.2241939-7-dwmw2@infradead.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-10-28firmware: arm_scmi: Relocate atomic_threshold to scmi_descCristian Marussi
Relocate the atomic_threshold field to scmi_desc and move the related code to scmi_transport_setup. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241028120151.1301177-6-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-28firmware: arm_scmi: Use max_msg and max_msg_size devicetree propertiesCristian Marussi
Override the default built-in max_msg and max_msg_size transport properties when the corresponding properties were found to be described in the devicetree. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241028120151.1301177-5-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-28firmware: arm_scmi: Calculate virtio PDU max size dynamicallyCristian Marussi
SCMI virtio transport maximum PDU size is currently hardcoded at build time; this will not play well with the possibile retrieval of a different size at run-time. Make the virtio transport derive the maximum PDU size from the max_msg_size provided by the SCMI core. No functional change. Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241028120151.1301177-3-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-28firmware: arm_scmi: Account for SHMEM memory overheadCristian Marussi
Transports using shared memory have to consider the overhead due to the layout area when determining the area effectively available for messages. Till now, such definitions were ambiguos across the SCMI stack and the overhead layout area was not considered at all. Add proper checks in the shmem layer to validate the provided max_msg_size against the effectively available memory area, less the layout. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241028120151.1301177-2-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-28firmware: arm_scmi: Support 'reg-io-width' property for shared memoryFlorian Fainelli
Some shared memory areas might only support a certain access width, such as 32-bit, which memcpy_{from,to}_io() does not adhere to at least on ARM64 by making both 8-bit and 64-bit accesses to such memory. Update the shmem layer to support reading from and writing to such shared memory area using the specified I/O width in the Device Tree. The various transport layers making use of the shmem.c code are updated accordingly to pass the I/O accessors that they store. Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Message-Id: <20240827182450.3608307-3-florian.fainelli@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-28firmware: arm_scmi: Use vendor string in max-rx-timeout-msCristian Marussi
The original optional property was missing a vendor string prefix; this has been rectified. Fix the naming of such optional property in code too. Cc: Peng Fan <peng.fan@nxp.com> Fixes: 1780e411ef94 ("firmware: arm_scmi: Use max-rx-timeout-ms from devicetree") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241028120151.1301177-8-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-25firmware: ti_sci: Remove use of of_match_ptr() helperAndrew Davis
When OF support is disabled the of_device_id struct match table can be conditionally compiled out, this helper allows the assignment to also be turned into a NULL conditionally. When the of_device_id struct is not conditionally defined based on OF then the table will be unused causing a warning. The two options are to either set the table as _maybe_unused, or to just remove this helper since the table will always be defined. Do the latter here. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241015213322.2649011-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-10-25firmware: ti_sci: add CPU latency constraint managementKevin Hilman
During system-wide suspend, check if any of the CPUs have PM QoS resume latency constraints set. If so, set TI SCI constraint. TI SCI has a single system-wide latency constraint, so use the max of any of the CPU latencies as the system-wide value. Note: DM firmware clears all constraints at resume time, so constraints need to be checked/updated/sent at each system suspend. Co-developed-by: Vibhore Vardhan <vibhore@ti.com> Signed-off-by: Vibhore Vardhan <vibhore@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-5-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-10-25firmware: ti_sci: Introduce Power Management OpsDave Gerlach
Introduce power management ops supported by the TISCI Low Power Mode API [1]. 1) TISCI_MSG_LPM_WAKE_REASON Get which wake up source woke the SoC from Low Power Mode. The wake up source IDs will be common for all K3 platforms. 2) TISCI_MSG_LPM_SET_DEVICE_CONSTRAINT Set LPM constraint on behalf of a device. By setting a constraint, the device ensures that it will not be powered off or reset in the selected mode. 3) TISCI_MSG_LPM_SET_LATENCY_CONSTRAINT Set LPM resume latency constraint. By setting a constraint, the host ensures that the resume time from selected mode will be less than the constraint value. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html Signed-off-by: Dave Gerlach <d-gerlach@ti.com> [g-vlaev@ti.com: LPM_WAKE_REASON and IO_ISOLATION support] Signed-off-by: Georgi Vlaev <g-vlaev@ti.com> [a-kaur@ti.com: SET_DEVICE_CONSTRAINT support] Signed-off-by: Akashdeep Kaur <a-kaur@ti.com> [vibhore@ti.com: SET_LATENCY_CONSTRAINT support] Signed-off-by: Vibhore Vardhan <vibhore@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Akashdeep Kaur <a-kaur@ti.com> Tested-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Roger Quadros <rogerq@kernel.org> Acked-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-4-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-10-25firmware: ti_sci: Add system suspend and resume callVibhore Vardhan
Introduce system suspend call that enables the ti_sci driver to support low power mode when the user space issues a suspend to mem. The following power management operations defined in the TISCI Low Power Mode API [1] are implemented to support suspend and resume: 1) TISCI_MSG_PREPARE_SLEEP Prepare the SOC for entering into a low power mode and provide details to firmware about the state being entered. 2) TISCI_MSG_SET_IO_ISOLATION Control the IO isolation for Low Power Mode. Also, write a ti_sci_prepare_system_suspend call to be used in the driver suspend handler to allow the system to identify the low power mode being entered and if necessary, send TISCI_MSG_PREPARE_SLEEP with information about the mode being entered. Sysfw version >= 10.00.04 support LPM_DM_MANAGED capability [2], where Device Mgr firmware now manages which low power mode is chosen. Going forward, this is the default configuration supported for TI AM62 family of devices. The state chosen by the DM can be influenced by sending constraints using the new LPM constraint APIs. In case the firmware does not support LPM_DM_MANAGED mode, the mode selection logic can be extended as needed. If no suspend-to-RAM modes are supported, return without taking any action. We're using "pm_suspend_target_state" to map the kernel's target suspend state to SysFW low power mode. Make sure this is available only when CONFIG_SUSPEND is enabled. Suspend has to be split into two parts, ti_sci_suspend() will send the prepare sleep message to prepare suspend. ti_sci_suspend_noirq() sets IO isolation which needs to be done as late as possible to avoid any issues. On resume this has to be done as early as possible. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html Co-developed-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Georgi Vlaev <g-vlaev@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Vibhore Vardhan <vibhore@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Tested-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-3-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-10-25firmware: ti_sci: Add support for querying the firmware capsGeorgi Vlaev
Add support for the TISCI_MSG_QUERY_FW_CAPS message, used to retrieve the firmware capabilities of the currently running system firmware. The message belongs to the TISCI general core message API [1] and is available in SysFW version 08.04.03 and above. Currently, the message is supported on devices with split architecture of the system firmware (DM + TIFS) like AM62x. Old revisions or not yet supported platforms will NACK this request. We're using this message locally in ti_sci.c to get the low power features of the FW/SoC. As there's no other kernel consumers yet, this is not added to struct ti_sci_core_ops. Sysfw version >= 10.00.04 support LPM_DM_MANAGED capability [2], where Device Mgr firmware now manages which low power mode is chosen. Going forward, this is the default configuration supported for TI AM62 family of devices. The state chosen by the DM can be influenced by sending constraints using the new LPM constraint APIs. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html [2] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps Signed-off-by: Georgi Vlaev <g-vlaev@ti.com> [vibhore@ti.com: Support for LPM_DM_MANAGED mode] Signed-off-by: Vibhore Vardhan <vibhore@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Roger Quadros <rogerq@kernel.org> Acked-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-2-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-10-24Revert "firmware: tegra: bpmp: Use scoped device node handling to simplify ↵Krzysztof Kozlowski
error paths" This reverts commit 8812b8689ee6 ("firmware: tegra: bpmp: Use scoped device node handling to simplify error paths") because it was silently modified by committer during commit process, by moving declaration of 'struct device_node *np' above the initializer/constructor. Such code was not intention of the author, is not conforming to cleanup.h code style and decreases the code readability. I did not write such code and I did not agree to put my name with such commit. Original patch: https://lore.kernel.org/all/20240816135722.105945-2-krzysztof.kozlowski@linaro.org/ Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [treding@nvidia.com: shorten subject line] Signed-off-by: Thierry Reding <treding@nvidia.com>
2024-10-23firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()Xiongfeng Wang
In sdei_device_freeze(), the input parameter of cpuhp_remove_state() is passed as 'sdei_entry_point' by mistake. Change it to 'sdei_hp_state'. Fixes: d2c48b2387eb ("firmware: arm_sdei: Fix sleep from invalid context BUG") Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20241016084740.183353-1-wangxiongfeng2@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-10-22firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enablingQingqing Zhou
When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to qcom_scm for unsupported platforms. Currently, tzmem interprets this as an unknown error rather than recognizing it as an unsupported platform. Error log: [ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator [ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4 To address this, modify the function call qcom_scm_shm_bridge_enable() to remap result to indicate an unsupported error. This way, tzmem will correctly identify it as an unsupported platform case instead of reporting it as an error. Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations") Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com> Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-22firmware: arm_scmi: Reject clear channel request on A2PCristian Marussi
The clear channel transport operation is supposed to be called exclusively on the P2A channel from the agent, since it relinquishes the ownership of the channel to the platform, after this latter has initiated some sort of P2A communication. Make sure that, if it is ever called on a A2P, is logged and ignored. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Message-Id: <20241021171544.2579551-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-22firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()Xinqi Zhang
The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 Fixes: ee7a9c9f67c5 ("firmware: arm_scmi: Add support for multiple device per protocol") Signed-off-by: Xinqi Zhang <quic_xinqzhan@quicinc.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Message-Id: <20241016-fix-arm-scmi-slab-use-after-free-v2-1-1783685ef90d@quicinc.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-21Merge 6.12-rc4 into char-misc-nextGreg Kroah-Hartman
We need the iio fixes from 6.12-rc4 in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-17firmware: microchip: auto-update: fix poll_complete() to not report spurious ↵Conor Dooley
timeout errors fw_upload's poll_complete() is really intended for use with asynchronous write() implementations - or at least those where the write() loop may terminate without the kernel yet being aware of whether or not the firmware upload has succeeded. For auto-update, write() is only ever called once and will only return when uploading has completed, be that by passing or failing. The core fw_upload code only calls poll_complete() after the final call to write() has returned. However, the poll_complete() implementation in the auto-update driver was written to expect poll_complete() to be called from another context, and it waits for a completion signalled from write(). Since poll_complete() is actually called from the same context, after the write() loop has terminated, wait_for_completion() never sees the completion get signalled and always times out, causing programming to always report a failing. Since write() is full synchronous, and its return value will indicate whether or not programming passed or failed, poll_complete() serves no purpose and can be cut down to simply return FW_UPLOAD_ERR_NONE. Cc: stable@vger.kernel.org Fixes: ec5b0f1193ad4 ("firmware: microchip: add PolarFire SoC Auto Update support") Reported-by: Jamie Gibbons <jamie.gibbons@microchip.com> Tested-by: Jamie Gibbons <jamie.gibbons@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-10-15firmware: google: Unregister driver_info on failureYuan Can
When platform_device_register_full() returns error, the gsmi_init() returns without unregister gsmi_driver_info, fix by add missing platform_driver_unregister() when platform_device_register_full() failed. Fixes: 8942b2d5094b ("gsmi: Add GSMI commands to log S0ix info") Signed-off-by: Yuan Can <yuancan@huawei.com> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20241015131344.20272-1-yuancan@huawei.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-10-15Merge tag 'scmi-fixes-6.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI fixes for v6.12 Couple of fixes to address the issues found and reported on Broadcom STB platforms following the recent refactor of all the SCMI transports as standalone drivers. One of the issue is that the effective timeout value is much less than the intended value due to the way mailbox messages are queues in the mailbox framework. Since we block or serialise the shmem access anyway, there is no point in utilizing mailbox queues. The issue is fixed with exclusive lock on the channel when sending the message. The other issues is actually non-issue for upstream, but the workaround is just changing the link order of the transport drivers which enables Broadcom STB platforms to run both upstream and custom downstream kernel without any device tree changes. So pushing this to help them test upstream seamlessly as it has no practical or theoretical impact for others. There is also a fix to address possible double freeing of the name string in scmi_debugfs_common_cleanup() when devm_add_action_or_reset() fails. * tag 'scmi-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Queue in scmi layer for mailbox implementation firmware: arm_scmi: Give SMC transport precedence over mailbox firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() Link: https://lore.kernel.org/r/20241015185128.1000604-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-10-15Merge tag 'ffa-fixes-6.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm FF-A fixes for v6.12 Couple of fixes to avoid string-fortify warnings in export_uuid() and memcpy() from the recently added functions to support FFA_MSG_SEND_DIRECT_REQ2 and FFA_MSG_SEND_DIRECT_RESP2. * tag 'ffa-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Avoid string-fortify warning caused by memcpy() firmware: arm_ffa: Avoid string-fortify warning in export_uuid() Link: https://lore.kernel.org/r/20241015185037.1000435-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-10-15libstub,tpm: do not ignore failure case when reading final event logGregory Price
Current code fails to check for an error case when reading events from final event log to calculate offsets. Check the error case, and break early because all subsequent calls will also fail. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15tpm: fix unsigned/signed mismatch errors related to __calc_tpm2_event_sizeGregory Price
__calc_tpm2_event_size returns 0 or a positive length, but return values are often interpreted as ints. Convert everything over to u32 to avoid signed/unsigned logic errors. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15tpm: do not ignore memblock_reserve return valueGregory Price
tpm code currently ignores a relevant failure case silently. Add an error to make this failure non-silent. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15tpm: fix signed/unsigned bug when checking event logsGregory Price
A prior bugfix that fixes a signed/unsigned error causes another signed unsigned error. A situation where log_tbl->size is invalid can cause the size passed to memblock_reserve to become negative. log_size from the main event log is an unsigned int, and the code reduces to the following u64 value = (int)unsigned_value; This results in sign extension, and the value sent to memblock_reserve becomes effectively negative. Fixes: be59d57f9806 ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero") Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15efi/libstub: measure initrd to PCR9 independent of sourceJeremy Linton
Currently the initrd is only measured if it can be loaded using the INITRD_MEDIA_GUID, if we are loading it from a path provided via the command line it is never measured. Lets move the check down a couple lines so the measurement happens independent of the source. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15efi/libstub: remove unnecessary cmd_line_len from efi_convert_cmdline()Jonathan Marek
efi_convert_cmdline() always sets cmdline_size to at least 1 on success, so the "cmdline_size > 0" does nothing and can be removed (the intent was to avoid parsing an empty string, but there is nothing wrong with parsing an empty string, it is only making boot negligibly slower). Then the cmd_line_len argument to efi_convert_cmdline can be removed because there is nothing left using it. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15efi/libstub: fix efi_parse_options() ignoring the default command lineJonathan Marek
efi_convert_cmdline() always returns a size of at least 1 because it counts the NUL terminator, so the "cmdline_size == 0" condition is never satisfied. Change it to check if the string starts with a NUL character to get the intended behavior: to use CONFIG_CMDLINE when load_options_size == 0. Fixes: 60f38de7a8d4 ("efi/libstub: Unify command line param parsing") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-10-15firmware: arm_ffa: Avoid string-fortify warning caused by memcpy()Gavin Shan
Copying from a 144 byte structure arm_smccc_1_2_regs at an offset of 32 into an 112 byte struct ffa_send_direct_data2 causes a compile-time warning: | In file included from drivers/firmware/arm_ffa/driver.c:25: | In function 'fortify_memcpy_chk', | inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:504:3: | include/linux/fortify-string.h:580:4: warning: call to '__read_overflow2_field' | declared with 'warning' attribute: detected read beyond size of field | (2nd parameter); maybe use struct_group()? [-Wattribute-warning] | __read_overflow2_field(q_size_field, size); Fix it by not passing a plain buffer to memcpy() to avoid the overflow warning. Fixes: aaef3bc98129 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2") Signed-off-by: Gavin Shan <gshan@redhat.com> Message-Id: <20241014004724.991353-1-gshan@redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-14firmware: qcom: scm: Allow QSEECOM on Dell XPS 13 9345Aleksandrs Vinarskis
Allow particular machine accessing eg. efivars. Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> Link: https://lore.kernel.org/r/20241003211139.9296-3-alex.vinarskis@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-14firmware: arm_scmi: Queue in scmi layer for mailbox implementationJustin Chen
send_message() does not block in the MBOX implementation. This is because the mailbox layer has its own queue. However, this confuses the per xfer timeouts as they all start their timeout ticks in parallel. Consider a case where the xfer timeout is 30ms and a SCMI transaction takes 25ms: | 0ms: Message #0 is queued in mailbox layer and sent out, then sits | at scmi_wait_for_message_response() with a timeout of 30ms | 1ms: Message #1 is queued in mailbox layer but not sent out yet. | Since send_message() doesn't block, it also sits at | scmi_wait_for_message_response() with a timeout of 30ms | ... | 25ms: Message #0 is completed, txdone is called and message #1 is sent | 31ms: Message #1 times out since the count started at 1ms. Even though | it has only been inflight for 6ms. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Message-Id: <20241014160717.1678953-1-justin.chen@broadcom.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-14firmware: arm_ffa: Avoid string-fortify warning in export_uuid()Arnd Bergmann
Copying to a 16 byte structure into an 8-byte struct member causes a compile-time warning: | In file included from drivers/firmware/arm_ffa/driver.c:25: | In function 'fortify_memcpy_chk', | inlined from 'export_uuid' at include/linux/uuid.h:88:2, | inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:488:2: | include/linux/fortify-string.h:571:25: error: call to '__write_overflow_field' | declared with attribute warning: detected write beyond size of field | (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] | __write_overflow_field(p_size_field, size); Use a union for the conversion instead and make sure the byte order is fixed in the process. Fixes: aaef3bc98129 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Message-Id: <20240909110938.247976-1-arnd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-13firmware: memmap: Constify memmap_ktypeKunwu Chan
This 'memmap_ktype' is not modified. It is only used in firmware_map_add_entry(). Constifying this structure and moving it to a read-only section, and this can increase over all security. ``` [Before] text data bss dec hex filename 4345 596 12 4953 1359 drivers/firmware/memmap.o [After] text data bss dec hex filename 4393 548 12 4953 1359 drivers/firmware/memmap.o ``` Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Link: https://lore.kernel.org/r/20240924030533.34407-1-chentao@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-13firmware: mtk-adsp-ipc: Switch to using dev_err_probe()AngeloGioacchino Del Regno
There is an error path that checks whether the return value is -EPROBE_DEFER to decide whether to print the error message: that is exactly open-coding dev_err_probe(), so, switch to that. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240919120208.152987-1-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-11firmware: arm_scmi: Give SMC transport precedence over mailboxFlorian Fainelli
Broadcom STB platforms have for historical reasons included both "arm,scmi-smc" and "arm,scmi" in their SCMI Device Tree node compatible string, in that order. After the commit b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver") and with a kernel configuration that enables both the SMC and the mailbox transports, we would probe the mailbox transport, but fail to complete since we would not have a mailbox driver available. With each SCMI transport being a platform driver with its own set of compatible strings to match, rather than an unique platform driver entry point, we no longer match from most specific to least specific. There is also no simple way for the mailbox driver to return -ENODEV and let another platform driver attempt probing. This leads to a platform with no SCMI provider, therefore all drivers depending upon SCMI resources are put on deferred probe forever. By keeping the SMC transport objects linked first, we can let the platform driver match the compatible string and probe successfully with no adverse effects on platforms using the mailbox transport. This is just the workaround to the issue observed which doesn't have any impact on the other platforms. Fixes: b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Message-Id: <20241007235413.507860-1-florian.fainelli@broadcom.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-11firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()Su Hui
Clang static checker(scan-build) throws below warning： | drivers/firmware/arm_scmi/driver.c:line 2915, column 2 | Attempt to free released memory. When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup() will run twice which causes double free of 'dbg->name'. Remove the redundant scmi_debugfs_common_cleanup() to fix this problem. Fixes: c3d4aed763ce ("firmware: arm_scmi: Populate a common SCMI debugfs root") Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20241011104001.1546476-1-suhui@nfschina.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-10-05firmware: qcom: scm: Allow QSEECOM on Microsoft Surface Pro 9 5GJérôme de Bretagne
Add the SC8280XP-based Microsoft Surface Pro 9 5G to the allowlist. Reviewed-by: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20240908223505.21011-3-jerome.debretagne@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-05firmware: qcom: scm: fix a NULL-pointer dereferenceBartosz Golaszewski
Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer. Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator") Reported-by: Rudraksha Gupta <guptarud@gmail.com> Closes: https://lore.kernel.org/lkml/692cfe9a-8c05-4ce4-813e-82b3f310019a@gmail.com/ Reviewed-by: Konrad Dybcio <konradybcio@kernel.org> Tested-by: Rudraksha Gupta <guptarud@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Link: https://lore.kernel.org/r/20240930083328.17904-1-brgl@bgdev.pl Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-05firmware: qcom: scm: suppress download mode errorJohan Hovold
Stop spamming the logs with errors about missing mechanism for setting the so called download (or dump) mode for users that have not requested that feature to be enabled in the first place. This avoids the follow error being logged on boot as well as on shutdown when the feature it not available and download mode has not been enabled on the kernel command line: qcom_scm firmware:scm: No available mechanism for setting download mode Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode") Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot") Cc: Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org # 6.4 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241002100122.18809-2-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-05firmware: qcom: scm: Allow QSEECOM on Lenovo Yoga Slim 7xMaya Matuszczyk
Allow QSEECOM on Lenovo Yoga Slim 7x, to enable accessing EFI variables. Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240919134421.112643-2-maccraft123mc@gmail.com [bjorn: Rewrote commit message] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-10-04Merge tag 'drm-fixes-2024-10-04' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly fixes, xe and amdgpu lead the way, with panthor, and few core components getting various fixes. Nothing seems too out of the ordinary. atomic: - Use correct type when reading damage rectangles display: - Fix kernel docs dp-mst: - Fix DSC decompression detection hdmi: - Fix infoframe size sched: - Update maintainers - Fix race condition whne queueing up jobs - Fix locking in drm_sched_entity_modify_sched() - Fix pointer deref if entity queue changes sysfb: - Disable sysfb if framebuffer parent device is unknown amdgpu: - DML2 fix - DSC fix - Dispclk fix - eDP HDR fix - IPS fix - TBT fix i915: - One fix for bitwise and logical "and" mixup in PM code xe: - Restore pci state on resume - Fix locking on submission, queue and vm - Fix UAF on queue destruction - Fix resource release on freq init error path - Use rw_semaphore to reduce contention on ASID->VM lookup - Fix steering for media on Xe2_HPM - Tuning updates to Xe2 - Resume TDR after GT reset to prevent jobs running forever - Move id allocation to avoid userspace using a guessed number to trigger UAF - Fix OA stream close preventing pbatch buffers to complete - Fix NPD when migrating memory on LNL - Fix memory leak when aborting binds panthor: - Fix locking - Set FOP_UNSIGNED_OFFSET in fops instance - Acquire lock in panthor_vm_prepare_map_op_ctx() - Avoid uninitialized variable in tick_ctx_cleanup() - Do not block scheduler queue if work is pending - Do not add write fences to the shared BOs vbox: - Fix VLA handling" * tag 'drm-fixes-2024-10-04' of https://gitlab.freedesktop.org/drm/kernel: (41 commits) drm/xe: Fix memory leak when aborting binds drm/xe: Prevent null pointer access in xe_migrate_copy drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close drm/xe/queue: move xa_alloc to prevent UAF drm/xe/vm: move xa_alloc to prevent UAF drm/xe: Clean up VM / exec queue file lock usage. drm/xe: Resume TDR after GT reset drm/xe/xe2: Add performance tuning for L3 cache flushing drm/xe/xe2: Extend performance tuning to media GT drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM drm/xe: Use helper for ASID -> VM in GPU faults and access counters drm/xe: Convert to USM lock to rwsem drm/xe: use devm_add_action_or_reset() helper drm/xe: fix UAF around queue destruction drm/xe/guc_submit: add missing locking in wedged_fini drm/xe: Restore pci state upon resume drm/amd/display: Fix system hang while resume with TBT monitor drm/amd/display: Enable idle workqueue for more IPS modes drm/amd/display: Add HDR workaround for specific eDP drm/amd/display: avoid set dispclk to 0 ...
2024-10-02move asm/unaligned.h to linux/unaligned.hAl Viro
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
2024-10-02firmware: xilinx: fix feature check logic for TF-A specific APIsRonak Jain
Currently, Linux is passing only API ID for feature of TF-A specific APIs but for feature check of TF-A specific APIs, TF-A is checking for Module ID + API ID as a result incorrect version is received for all TF-A specific APIs. So, fix feature check logic to pass valid arguments to get correct version. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20240920055546.2658783-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02firmware: xilinx: add support for new SMC call formatRonak Jain
Added zynqmp_pm_invoke_fw_fn() to use new SMC format in which lower 12 bits of SMC id are fixed and firmware header is moved to subsequent SMC arguments. The new SMC format supports full request and response buffers. Added zynqmp_pm_get_sip_svc_version() to get SiP SVC version number to check if TF-A is newer or older and use the SMC format accordingly to handle backward compatibility. Used new SMC format for PM_QUERY_DATA API as more response values are required in it. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20240920055501.2658642-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02firmware: xilinx: add a warning print for unsupported featureRonak Jain
As per the current code base, feature check API is used to check the version in zynqmp_pm_pinctrl_set_config() before requesting the firmware, and if the expected version is not found then it will return an error. So now when the latest kernel tries to access the tri-state functionality with older firmware, observe failure prints during booting. The failure prints, [ 1.204850] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 37 param 2 value 0 [ 2.699455] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 44 param 2 value 0 [ 2.708424] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 46 param 2 value 0 [ 2.717387] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 48 param 2 value 0 Now, these error prints mislead the user whether it is an actual failure or the feature itself is not there in the firmware. So, just to avoid confusion around this, add some debug prints before returning an error code. With that, it is easier to know whether it is an actual failure or the feature is unsupported. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Link: https://lore.kernel.org/r/20240920055410.2658465-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02firmware: xilinx: use u32 for reset ID in reset APIsRonak Jain
Refactors the reset handling mechanisms by replacing the reset ID's enum type with a u32. This update improves flexibility, allowing the reset ID to accommodate a broader range of values, including those that may not fit into predefined enum values. The use of u32 for reset ID enhances extensibility, especially for hardware platforms or features where more granular control of reset operations is required. By shifting to a general integer type, this change reduces constraints and simplifies integration with other system components that rely on non-enum-based reset IDs. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Link: https://lore.kernel.org/r/20240830100042.3163511-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 13:57:34 +0000