user/sven/linux.git/drivers/reset, branch v6.9.3

reset: Instantiate reset GPIO controller for shared reset-gpios

2024-02-21T10:53:25Z

Devices sharing a reset GPIO could use the reset framework for coordinated handling of that shared GPIO line. We have several cases of such needs, at least for Devicetree-based platforms. If Devicetree-based device requests a reset line, while "resets" Devicetree property is missing but there is a "reset-gpios" one, instantiate a new "reset-gpio" platform device which will handle such reset line. This allows seamless handling of such shared reset-gpios without need of changing Devicetree binding [1]. To avoid creating multiple "reset-gpio" platform devices, store the Devicetree "reset-gpios" GPIO specifiers used for new devices on a linked list. Later such Devicetree GPIO specifier (phandle to GPIO controller, GPIO number and GPIO flags) is used to check if reset controller for given GPIO was already registered. If two devices have conflicting "reset-gpios" property, e.g. with different ACTIVE_xxx flags, this would allow to spawn two separate "reset-gpio" devices, where the second would fail probing on busy GPIO request. Link: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/ [1] Cc: Bartosz Golaszewski Cc: Chris Packham Cc: Sean Anderson Reviewed-by: Philipp Zabel Signed-off-by: Krzysztof Kozlowski Acked-by: Bartosz Golaszewski Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20240129115216.96479-5-krzysztof.kozlowski@linaro.org Signed-off-by: Philipp Zabel

reset: gpio: Add GPIO-based reset controller

2024-02-21T10:53:25Z

Add a simple driver to control GPIO-based resets using the reset controller API for the cases when the GPIOs are shared and reset should be coordinated. The driver is expected to be used by reset core framework for ad-hoc reset controllers. Cc: Bartosz Golaszewski Cc: Chris Packham Cc: Sean Anderson Reviewed-by: Bartosz Golaszewski Reviewed-by: Philipp Zabel Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240129115216.96479-4-krzysztof.kozlowski@linaro.org Signed-off-by: Philipp Zabel

reset: simple: add support for Sophgo SG2042

2024-02-21T10:51:39Z

Reuse reset-simple driver for the Sophgo SG2042 reset generator. Signed-off-by: Chen Wang Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/r/1cfd7b3ba447942784c4f7aa595e962399e9f617.1706577450.git.unicorn_wang@outlook.com Signed-off-by: Philipp Zabel

Merge tag 'soc-drivers-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2024-01-11T19:31:46Z

Pull SoC driver updates from Arnd Bergmann: "A new drivers/cache/ subsystem is added to contain drivers for abstracting cache flush methods on riscv and potentially others, as this is needed for handling non-coherent DMA but several SoCs require nonstandard hardware methods for it. op-tee gains support for asynchronous notification with FF-A, as well as support for a system thread for executing in secure world. The tee, reset, bus, memory and scmi subsystems have a couple of minor updates. Platform specific soc driver changes include: - Samsung Exynos gains driver support for Google GS101 (Tensor G1) across multiple subsystems - Qualcomm Snapdragon gains support for SM8650 and X1E along with added features for some other SoCs - Mediatek adds support for "Smart Voltage Scaling" on MT8186 and MT8195, and driver support for MT8188 along with some code refactoring. - Microchip Polarfire FPGA support for "Auto Update" of the FPGA bitstream - Apple M1 mailbox driver is rewritten into a SoC driver - minor updates on amlogic, mvebu, ti, zynq, imx, renesas and hisilicon" * tag 'soc-drivers-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (189 commits) memory: ti-emif-pm: Convert to platform remove callback returning void memory: ti-aemif: Convert to platform remove callback returning void memory: tegra210-emc: Convert to platform remove callback returning void memory: tegra186-emc: Convert to platform remove callback returning void memory: stm32-fmc2-ebi: Convert to platform remove callback returning void memory: exynos5422-dmc: Convert to platform remove callback returning void memory: renesas-rpc-if: Convert to platform remove callback returning void memory: omap-gpmc: Convert to platform remove callback returning void memory: mtk-smi: Convert to platform remove callback returning void memory: jz4780-nemc: Convert to platform remove callback returning void memory: fsl_ifc: Convert to platform remove callback returning void memory: fsl-corenet-cf: Convert to platform remove callback returning void memory: emif: Convert to platform remove callback returning void memory: brcmstb_memc: Convert to platform remove callback returning void memory: brcmstb_dpfe: Convert to platform remove callback returning void soc: qcom: llcc: Fix LLCC_TRP_ATTR2_CFGn offset firmware: qcom: qseecom: fix memory leaks in error paths dt-bindings: clock: google,gs101: rename CMU_TOP gate defines soc: qcom: llcc: Fix typo in kernel-doc dt-bindings: soc: qcom,aoss-qmp: document the X1E80100 Always-On Subsystem side channel ...

reset: Fix crash when freeing non-existent optional resets

2023-11-30T14:02:21Z

When obtaining one or more optional resets, non-existent resets are stored as NULL pointers, and all related error and cleanup paths need to take this into account. Currently only reset_control_put() and reset_control_bulk_put() get this right. All of __reset_control_bulk_get(), of_reset_control_array_get(), and reset_control_array_put() lack the proper checking, causing NULL pointer dereferences on failure or release. Fix this by moving the existing check from reset_control_bulk_put() to __reset_control_put_internal(), so it applies to all callers. The double check in reset_control_put() doesn't hurt. Fixes: 17c82e206d2a3cd8 ("reset: Add APIs to manage array of resets") Fixes: 48d71395896d54ee ("reset: Add reset_control_bulk API") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/2440edae7ca8534628cdbaf559ded288f2998178.1701276806.git.geert+renesas@glider.be Signed-off-by: Philipp Zabel

reset: Use device_get_match_data()

2023-11-28T16:23:01Z

Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring Reviewed-by: Patrice Chotard Link: https://lore.kernel.org/r/20231115205848.3732609-1-robh@kernel.org Signed-off-by: Philipp Zabel

reset: reset-meson: add support for Amlogic C3 SoC Reset Controller

2023-11-28T16:21:59Z

Add a new compatible string to support for the reset controller on the C3 SoC. The count and offset for C3 Soc RESET registers are same as S4 Soc. Signed-off-by: Zelong Dong Reviewed-by: Dmitry Rokosov Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20230914064018.18790-3-zelong.dong@amlogic.com Signed-off-by: Philipp Zabel

reset: uniphier-glue: Use devm_platform_get_and_ioremap_resource()

2023-11-28T16:19:39Z

Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li Link: https://lore.kernel.org/r/20230704120211.38122-7-frank.li@vivo.com Signed-off-by: Philipp Zabel

reset: sunplus: Use devm_platform_get_and_ioremap_resource()

2023-11-28T16:19:39Z

reset: simple: Convert to devm_platform_get_and_ioremap_resource()

2023-11-28T16:19:39Z