kernel/linux.git/drivers/hwspinlock, branch v6.1.168

hwspinlock: Introduce hwspin_lock_bust()

2024-09-08T05:53:09+00:00

[ Upstream commit 7c327d56597d8de1680cf24e956b704270d3d84a ] When a remoteproc crashes or goes down unexpectedly this can result in a state where locks held by the remoteproc will remain locked possibly resulting in deadlock. This new API hwspin_lock_bust() allows hwspinlock implementers to define a bust operation for freeing previously acquired hwspinlocks after verifying ownership of the acquired lock. Signed-off-by: Richard Maina Reviewed-by: Bjorn Andersson Signed-off-by: Chris Lew Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-1-c8b924ffa5a2@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

hwspinlock: qcom: add missing regmap config for SFPB MMIO implementation

2023-09-19T10:28:05+00:00

commit 23316be8a9d450f33a21f1efe7d89570becbec58 upstream. Commit 5d4753f741d8 ("hwspinlock: qcom: add support for MMIO on older SoCs") introduced and made regmap_config mandatory in the of_data struct but didn't add the regmap_config for sfpb based devices. SFPB based devices can both use the legacy syscon way to probe or the new MMIO way and currently device that use the MMIO way are broken as they lack the definition of the now required regmap_config and always return -EINVAL (and indirectly makes fail probing everything that depends on it, smem, nandc with smem-parser...) Fix this by correctly adding the missing regmap_config and restore function of hwspinlock on SFPB based devices with MMIO implementation. Cc: stable@vger.kernel.org Fixes: 5d4753f741d8 ("hwspinlock: qcom: add support for MMIO on older SoCs") Signed-off-by: Christian Marangi Link: https://lore.kernel.org/r/20230716022804.21239-1-ansuelsmth@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

hwspinlock: qcom: add support for MMIO on older SoCs

2022-09-13T22:01:18+00:00

Older Qualcomm SoCs have TCSR mutex registers with 0x80 stride, instead of 0x1000. Add dedicated compatibles and regmap for such case. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220909092035.223915-5-krzysztof.kozlowski@linaro.org

hwspinlock: qcom: correct MMIO max register for newer SoCs

2022-09-13T22:01:18+00:00

Newer ARMv8 Qualcomm SoCs using 0x1000 register stride have maximum register 0x20000 (32 mutexes * 0x1000). Fixes: 7a1e6fb1c606 ("hwspinlock: qcom: Allow mmio usage in addition to syscon") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220909092035.223915-4-krzysztof.kozlowski@linaro.org

hwspinlock: qcom: Add support for mmio usage to sfpb-mutex

2022-07-17T02:47:44+00:00

Allow sfpb-mutex to use mmio in addition to syscon. Signed-off-by: Christian Marangi Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220707102040.1859-1-ansuelsmth@gmail.com

hwspinlock: using pm_runtime_resume_and_get instead of pm_runtime_get_sync

2022-04-22T23:03:04+00:00

Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot Signed-off-by: Minghao Chi Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220418105508.2558696-1-chi.minghao@zte.com.cn

hwspinlock: sprd: Use struct_size() helper in devm_kzalloc()

2022-03-11T20:56:57+00:00

Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: drivers/hwspinlock/sprd_hwspinlock.c:96:36: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Baolin Wang Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220125225723.GA78256@embeddedor

hwspinlock: stm32: Use struct_size() helper in devm_kzalloc()

2022-03-11T20:56:15+00:00

Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: drivers/hwspinlock/stm32_hwspinlock.c:84:32: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Baolin Wang Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220125021353.GA29777@embeddedor

hwspinlock: stm32: enable clock at probe

2021-11-17T22:12:44+00:00

Set the clock during probe and keep its control during suspend / resume operations. This fixes an issue when CONFIG_PM is not set and where the clock is never enabled. Make use of devm_ functions to simplify the code. Signed-off-by: Fabien Dessenne Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211011135836.1045437-1-fabien.dessenne@foss.st.com

hwspinlock: add sun6i hardware spinlock support

2021-05-28T03:19:42+00:00

Adds the sun6i_hwspinlock driver for the hardware spinlock unit found in most of the sun6i compatible SoCs. This unit provides at least 32 spinlocks in hardware. The implementation supports 32, 64, 128 or 256 32bit registers. A lock can be taken by reading a register and released by writing a 0 to it. This driver supports all 4 spinlock setups, but for now only the first setup (32 locks) seem to exist in available devices. This spinlock unit is shared between all ARM cores and the embedded companion core. All of them can take/release a lock with a single cycle operation. It can be used to sync access to devices shared by the ARM cores and the companion core. There are two ways to check if a lock is taken. The first way is to read a lock. If a 0 is returned, the lock was free and is taken now. If an 1 is returned, the caller has to try again. Which means the lock is taken. The second way is to read a 32bit wide status register where every bit represents one of the 32 first locks. According to the datasheets this status register supports only the 32 first locks. This is the reason the first way (lock read/write) approach is used to be able to cover all 256 locks in future devices. The driver also reports the amount of supported locks via debugfs. Reviewed-by: Samuel Holland Acked-by: Maxime Ripard Signed-off-by: Wilken Gottwalt Link: https://lore.kernel.org/r/bfd2b97307c2321b15c09683f4bd5e1fcc792f13.1615713499.git.wilken.gottwalt@posteo.net Signed-off-by: Bjorn Andersson