[PATCH v6 11/12] reset: zte: Add a zx297520v3 reset driver
Philipp Zabel
p.zabel at pengutronix.de
Fri Jul 3 02:16:09 PDT 2026
On Do, 2026-07-02 at 23:28 +0300, Stefan Dösinger wrote:
> This drives the MFD child devices created by the zx297520v3-crm driver
> as well as the aux device created by the zx297520v3-lspclk driver.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger at gmail.com>
>
> ---
>
> v6:
> Add a comment wrt checking all bits in .status() (Philipp)
> include cleanup (Philipp, Sashiko)
>
> v5:
> Make top and matrix MFD children instead of aux devices
> Split USB PHY reset into its own reset ID
> Remove USB reset wait code - this will be handled via syscon from a
> future minimal phy-zx29-usb driver
> ---
> MAINTAINERS | 1 +
> drivers/reset/Kconfig | 10 ++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-zte-zx297520v3.c | 234 +++++++++++++++++++++++++++++++++++
> 4 files changed, 246 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8f2e436cb42b..084d30fec1cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3883,6 +3883,7 @@ F: Documentation/devicetree/bindings/soc/zte/
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> F: drivers/clk/zte/
> +F: drivers/reset/reset-zte-zx297520v3.c
> F: drivers/soc/zte/
> F: include/dt-bindings/clock/zte,zx297520v3-clk.h
> F: include/dt-bindings/reset/zte,zx297520v3-reset.h
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3..4dca1f89d22b 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -404,6 +404,16 @@ config RESET_UNIPHIER_GLUE
> on UniPhier SoCs. Say Y if you want to control reset signals
> provided by the glue layer.
>
> +config RESET_ZTE_ZX297520V3
> + tristate "ZTE zx297520v3 Reset Driver"
> + depends on ZTE_ZX297520V3_CRM || COMPILE_TEST
> + default SOC_ZX297520V3
> + help
> + This enables the reset controllers for ZTE zx297520v3 SoCs. The reset
> + controllers are part of the clock and reset management controllers on
> + this board, so you will also need ZTE_ZX297520V3_CRM. Enable this if
> + you are building a kernel for a ZTE x297520v3 based board.
> +
> config RESET_ZYNQ
> bool "ZYNQ Reset Driver" if COMPILE_TEST
> default ARCH_ZYNQ
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 3e52569bd276..9a8a48d44dc4 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -50,5 +50,6 @@ obj-$(CONFIG_RESET_TI_TPS380X) += reset-tps380x.o
> obj-$(CONFIG_RESET_TN48M_CPLD) += reset-tn48m.o
> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> obj-$(CONFIG_RESET_UNIPHIER_GLUE) += reset-uniphier-glue.o
> +obj-$(CONFIG_RESET_ZTE_ZX297520V3) += reset-zte-zx297520v3.o
> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
> obj-$(CONFIG_RESET_ZYNQMP) += reset-zynqmp.o
> diff --git a/drivers/reset/reset-zte-zx297520v3.c b/drivers/reset/reset-zte-zx297520v3.c
> new file mode 100644
> index 000000000000..75a9e6e93cda
> --- /dev/null
> +++ b/drivers/reset/reset-zte-zx297520v3.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Stefan Dösinger
> + */
> +#include <dt-bindings/reset/zte,zx297520v3-reset.h>
> +#include <linux/reset-controller.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/errno.h>
> +#include <linux/bits.h>
> +#include <linux/err.h>
> +
> +/* Most devices on the zx297520v3 SoC have one reset bit per clock line. As a rule of thumb, the
> + * lower bit disconnects the device from the bus, similarly to turning off PCLK - registers read 0
> + * or hang indefinitely. Unlike PCLK, this reset may have a lingering effect after deasserting.
> + * E.g. timers will be disabled, but retain their counter value.
> + *
> + * The other bit resets the actual device registers.
> + *
> + * For some devices, e.g. GMAC, both reset bits behave in the same way: They disconnect the device
> + * and registers will have their default state after deasserting. For devices that have two reset
> + * bits, both need to be deasserted for the device to function.
> + */
> +struct zte_reset_reg {
> + u32 mask;
> + u16 reg;
> +};
> +
> +struct zte_reset_data {
> + const struct zte_reset_reg *resets;
> + unsigned int num;
> +};
> +
> +struct zte_reset {
> + struct reset_controller_dev rcdev;
> + struct regmap *map;
> + const struct zte_reset_reg *resets;
> +};
> +
> +static inline struct zte_reset *to_zte_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct zte_reset, rcdev);
> +}
> +
> +static int zx29_rst_assert(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> +
> + return regmap_clear_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
> +}
> +
> +static int zx29_rst_deassert(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> +
> + return regmap_set_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
> +}
> +
> +static int zx29_rst_status(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> + int res;
> +
> + /* Devices with two reset bits need both deasserted to work. So only report them as
> + * deasserted if both bits are set.
> + *
> + * assert()/deassert() will always clear/set both. The only reason a device might be in a
> + * hybrid state is an unexpected handover state from the bootloader.
> + */
> + res = regmap_test_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
> + if (res < 0)
> + return res;
> +
> + return !res;
> +}
> +
> +static const struct reset_control_ops zx29_rst_ops = {
> + .assert = zx29_rst_assert,
> + .deassert = zx29_rst_deassert,
> + .status = zx29_rst_status,
> +};
> +
> +static const struct zte_reset_reg zx297520v3_top_resets[] = {
> + /* This bit is set by ZTE's cpko.ko blob, it looks like a reset bit for the LTE DSP
> + * coprocessor. Clocks for it are in matrixcrm.
> + */
> + [ZX297520V3_ZSP_RESET] = { .reg = 0x13c, .mask = BIT(0) },
> +
> + [ZX297520V3_UART0_RESET] = { .reg = 0x78, .mask = BIT(6) | BIT(7) },
> + [ZX297520V3_I2C0_RESET] = { .reg = 0x74, .mask = BIT(8) | BIT(9) },
> + /* Only one reset. Bit 5 is settable but does not do anything observable */
> + [ZX297520V3_RTC_RESET] = { .reg = 0x74, .mask = BIT(4) },
> + [ZX297520V3_TIMER_T08_RESET] = { .reg = 0x78, .mask = BIT(4) | BIT(5) },
> + [ZX297520V3_TIMER_T09_RESET] = { .reg = 0x78, .mask = BIT(2) | BIT(3) },
> + /* Only one reset. Bit 0 is settable but does not do anything observable */
> + [ZX297520V3_PMM_RESET] = { .reg = 0x74, .mask = BIT(1) },
> +
> + /* I haven't found any clocks for GPIO. It probably wouldn't make much
> + * sense anyway. Only one reset bit per controller.
> + */
> + [ZX297520V3_GPIO_RESET] = { .reg = 0x74, .mask = BIT(3) },
> + [ZX297520V3_GPIO8_RESET] = { .reg = 0x74, .mask = BIT(2) },
> +
> + [ZX297520V3_TIMER_T12_RESET] = { .reg = 0x74, .mask = BIT(6) | BIT(7) },
> + [ZX297520V3_TIMER_T13_RESET] = { .reg = 0x7c, .mask = BIT(0) | BIT(1) },
> + [ZX297520V3_TIMER_T14_RESET] = { .reg = 0x7c, .mask = BIT(2) | BIT(3) },
> + [ZX297520V3_TIMER_T15_RESET] = { .reg = 0x74, .mask = BIT(10) | BIT(11) },
> + [ZX297520V3_TIMER_T16_RESET] = { .reg = 0x7c, .mask = BIT(4) | BIT(5) },
> + [ZX297520V3_TIMER_T17_RESET] = { .reg = 0x12c, .mask = BIT(0) | BIT(1) },
> + [ZX297520V3_WDT_T18_RESET] = { .reg = 0x74, .mask = BIT(12) | BIT(13) },
> + [ZX297520V3_USIM1_RESET] = { .reg = 0x74, .mask = BIT(14) | BIT(15) },
> + [ZX297520V3_AHB_RESET] = { .reg = 0x70, .mask = BIT(0) | BIT(1) },
> +
> + /* USB reset. 0x84 returns the USB device status (0x1 for HSIC up, 0x2 for USB up, but
> + * all 3 bits (PCLK, WCLK, PHY) need to be deasserted for the device to report ready.
> + * Thus polling the status is the responsibility of the USB PHY driver.
> + */
> + [ZX297520V3_USB_PHY_RESET] = { .reg = 0x80, .mask = BIT(3) },
> + [ZX297520V3_USB_RESET] = { .reg = 0x80, .mask = BIT(4) | BIT(5) },
> + [ZX297520V3_HSIC_PHY_RESET] = { .reg = 0x80, .mask = BIT(0) },
> + [ZX297520V3_HSIC_RESET] = { .reg = 0x80, .mask = BIT(1) | BIT(2) },
> +};
> +
> +static const struct zte_reset_data zx297520v3_topreset_data = {
> + .resets = zx297520v3_top_resets,
> + .num = ARRAY_SIZE(zx297520v3_top_resets),
> +};
> +
> +static const struct zte_reset_reg zx297520v3_matrix_resets[] = {
> + [ZX297520V3_CPU_RESET] = { .reg = 0x28, .mask = BIT(1) },
> + [ZX297520V3_EDCP_RESET] = { .reg = 0x68, .mask = BIT(0) },
> + [ZX297520V3_SD0_RESET] = { .reg = 0x58, .mask = BIT(1) },
> + [ZX297520V3_SD1_RESET] = { .reg = 0x58, .mask = BIT(0) },
> + [ZX297520V3_NAND_RESET] = { .reg = 0x58, .mask = BIT(4) },
> + [ZX297520V3_PDCFG_RESET] = { .reg = 0x94, .mask = BIT(20) },
> + [ZX297520V3_SSC_RESET] = { .reg = 0x94, .mask = BIT(24) },
> + [ZX297520V3_GMAC_RESET] = { .reg = 0x114, .mask = BIT(0) | BIT(1) },
> + [ZX297520V3_VOU_RESET] = { .reg = 0x16c, .mask = BIT(0) },
> +};
> +
> +static const struct zte_reset_data zx297520v3_matrixreset_data = {
> + .resets = zx297520v3_matrix_resets,
> + .num = ARRAY_SIZE(zx297520v3_matrix_resets),
> +};
> +
> +static const struct zte_reset_reg zx297520v3_lsp_resets[] = {
> + [ZX297520V3_TIMER_L1_RESET] = { .reg = 0x04, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_WDT_L2_RESET] = { .reg = 0x08, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_WDT_L3_RESET] = { .reg = 0x0c, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_PWM_RESET] = { .reg = 0x10, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_I2S0_RESET] = { .reg = 0x14, .mask = BIT(8) | BIT(9) },
> + /* 0x18: Not writeable */
> + [ZX297520V3_I2S1_RESET] = { .reg = 0x1c, .mask = BIT(8) | BIT(9) },
> + /* 0x20: Not writeable */
> + [ZX297520V3_QSPI_RESET] = { .reg = 0x24, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_UART1_RESET] = { .reg = 0x28, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_I2C1_RESET] = { .reg = 0x2c, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_SPI0_RESET] = { .reg = 0x30, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_TIMER_LB_RESET] = { .reg = 0x34, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_TIMER_LC_RESET] = { .reg = 0x38, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_UART2_RESET] = { .reg = 0x3c, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_WDT_LE_RESET] = { .reg = 0x40, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_TIMER_LF_RESET] = { .reg = 0x44, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_SPI1_RESET] = { .reg = 0x48, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_TIMER_L11_RESET] = { .reg = 0x4c, .mask = BIT(8) | BIT(9) },
> + [ZX297520V3_TDM_RESET] = { .reg = 0x50, .mask = BIT(8) | BIT(9) },
> +};
> +
> +static const struct zte_reset_data zx297520v3_lspreset_data = {
> + .resets = zx297520v3_lsp_resets,
> + .num = ARRAY_SIZE(zx297520v3_lsp_resets),
> +};
> +
> +static int reset_zx297520v3_probe(struct platform_device *pdev)
> +{
> + const struct platform_device_id *id = platform_get_device_id(pdev);
> + struct device *dev = &pdev->dev;
> + struct device_node *of_node = dev->parent->of_node;
> + const struct zte_reset_data *data;
> + struct zte_reset *rst;
> +
> + if (!id)
> + return -ENODEV;
> + data = (const struct zte_reset_data *)id->driver_data;
> +
> + rst = devm_kzalloc(dev, sizeof(*rst), GFP_KERNEL);
> + if (!rst)
> + return -ENOMEM;
> +
> + rst->resets = data->resets;
> + rst->rcdev.owner = THIS_MODULE;
> + rst->rcdev.nr_resets = data->num;
> + rst->rcdev.ops = &zx29_rst_ops;
> + rst->rcdev.of_node = of_node;
> + rst->rcdev.dev = dev;
> +
> + rst->map = device_node_to_regmap(of_node);
> + if (IS_ERR(rst->map))
> + return dev_err_probe(dev, PTR_ERR(rst->map), "Cannot get parent syscon regmap\n");
Does your parent even have to be a syscon?
Could you just create the regmap in the MFD driver and use
dev_get_regmap(pdev->dev.parent, NULL) here?
> +
> + return devm_reset_controller_register(dev, &rst->rcdev);
> +}
> +
> +static const struct platform_device_id reset_zx297520v3_ids[] = {
> + {
> + .name = "zx297520v3-topreset",
> + .driver_data = (kernel_ulong_t)&zx297520v3_topreset_data,
> + },
> + {
> + .name = "zx297520v3-matrixreset",
> + .driver_data = (kernel_ulong_t)&zx297520v3_matrixreset_data,
> + },
> + {
> + .name = "zx297520v3-lspreset",
> + .driver_data = (kernel_ulong_t)&zx297520v3_lspreset_data,
> + },
> + { }
> +};
MODULE_DEVICE_TABLE(platform, reset_zx297520v3_ids);
With that,
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
regards
Philipp
More information about the linux-arm-kernel
mailing list