* [PATCH RFC v4 06/12] clk: zte: Add regmap based clocks
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This is based on meson/clk-regmap.c, although slightly simplified. I
have kept the copyright lines at the top of the file to indicate its
origin.
I see that numerous clock drivers have their own incarnation of regmap
based mux/div/gate clocks. If there is any version of it that is likely
to be elevated to shared code liks clk-gate.c I'll copy that and try to
use it as unmodified as possible.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/clk-regmap.c | 223 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 220 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/zte/clk-regmap.c b/drivers/clk/zte/clk-regmap.c
index 7908f1562f63..d9459417d17d 100644
--- a/drivers/clk/zte/clk-regmap.c
+++ b/drivers/clk/zte/clk-regmap.c
@@ -6,25 +6,242 @@
* Author: Stefan Dösinger <stefandoesinger@gmail.com>
*/
+#include <linux/clk-provider.h>
+#include <linux/regmap.h>
+#include <linux/device.h>
+
#include "clk-zx.h"
+struct zte_clk_regmap {
+ struct clk_hw hw;
+ struct regmap *map;
+ u16 reg;
+ u8 shift;
+ u8 size;
+};
+
+static inline struct zte_clk_regmap *to_zte_clk_regmap(struct clk_hw *hw)
+{
+ return container_of(hw, struct zte_clk_regmap, hw);
+}
+
+static int zte_clk_regmap_gate_enable(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ return regmap_set_bits(clk->map, clk->reg, BIT(clk->shift));
+}
+
+static void zte_clk_regmap_gate_disable(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ regmap_clear_bits(clk->map, clk->reg, BIT(clk->shift));
+}
+
+static int zte_clk_regmap_gate_is_enabled(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ u32 val;
+
+ regmap_read(clk->map, clk->reg, &val);
+ return !!val;
+}
+
+static const struct clk_ops zte_clk_regmap_gate_ops = {
+ .enable = zte_clk_regmap_gate_enable,
+ .disable = zte_clk_regmap_gate_disable,
+ .is_enabled = zte_clk_regmap_gate_is_enabled,
+};
+
int zx_clk_register_gates(struct device *dev, struct regmap *regmap,
const struct zx_gate_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_gate_ops;
+ init.parent_names = &desc[i].parent;
+ init.num_parents = 1;
+ init.flags = CLK_SET_RATE_PARENT | desc[i].flags;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = 1;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
+}
+
+static unsigned long zte_clk_regmap_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, clk->reg, &val);
+ if (ret)
+ /* Gives a hint that something is wrong */
+ return 0;
+
+ val >>= clk->shift;
+ val &= clk_div_mask(clk->size);
+ return divider_recalc_rate(hw, prate, val, NULL, 0, clk->size);
}
+static int zte_clk_regmap_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ return divider_determine_rate(hw, req, NULL, clk->size, 0);
+}
+
+static int zte_clk_regmap_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = divider_get_val(rate, parent_rate, NULL, clk->size, 0);
+ if (ret < 0)
+ return ret;
+
+ val = (unsigned int)ret << clk->shift;
+ return regmap_update_bits(clk->map, clk->reg, clk_div_mask(clk->size) << clk->shift, val);
+};
+
+static const struct clk_ops zte_clk_regmap_divider_ops = {
+ .recalc_rate = zte_clk_regmap_div_recalc_rate,
+ .determine_rate = zte_clk_regmap_div_determine_rate,
+ .set_rate = zte_clk_regmap_div_set_rate,
+};
+
int zx_clk_register_dividers(struct device *dev, struct regmap *regmap,
const struct zx_div_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_divider_ops;
+ init.parent_names = &desc[i].parent;
+ init.num_parents = 1;
+ init.flags = CLK_SET_RATE_PARENT;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = desc[i].size;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
}
+static u8 zte_clk_regmap_mux_get_parent(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, clk->reg, &val);
+ if (ret)
+ return 0xff;
+
+ val >>= clk->shift;
+ val &= GENMASK(clk->size - 1, 0);
+ return clk_mux_val_to_index(hw, NULL, 0, val);
+}
+
+static int zte_clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val = clk_mux_index_to_val(NULL, 0, index);
+
+ return regmap_update_bits(clk->map, clk->reg,
+ GENMASK(clk->size - 1, 0) << clk->shift,
+ val << clk->shift);
+}
+
+static int zte_clk_regmap_mux_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+ return clk_mux_determine_rate_flags(hw, req, 0);
+}
+
+static const struct clk_ops zte_clk_regmap_mux_ops = {
+ .get_parent = zte_clk_regmap_mux_get_parent,
+ .set_parent = zte_clk_regmap_mux_set_parent,
+ .determine_rate = zte_clk_regmap_mux_determine_rate,
+};
+
int zx_clk_register_muxes(struct device *dev, struct regmap *regmap,
const struct zx_mux_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_mux_ops;
+ init.parent_names = desc[i].parents;
+ init.num_parents = desc[i].num_parents;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = desc[i].size;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 07/12] clk: zte: Introduce a driver for zx297520v3 top clocks
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This register space controls core devices: PLLs, the AHB bus, a lot of
timers, the USB controller, the Cortex M0 processor that boots the board
and a few other devices. For some reason the LTE coprocessor is also
partially controlled by it. The main application processor and DDR
memory are not found here though.
The register to reboot the board is found here, as well as a register to
control of watchdog expiries cause a board reset.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/Kconfig | 11 +
drivers/clk/zte/Makefile | 1 +
drivers/clk/zte/clk-zx297520v3.c | 431 +++++++++++++++++++++++++++++++++++++++
3 files changed, 443 insertions(+)
diff --git a/drivers/clk/zte/Kconfig b/drivers/clk/zte/Kconfig
index b7b65a2172a9..12906212ec1e 100644
--- a/drivers/clk/zte/Kconfig
+++ b/drivers/clk/zte/Kconfig
@@ -15,3 +15,14 @@ config COMMON_CLK_ZTE
of this.
Enable this if you are building a kernel for a ZTE designed board.
+
+config CLK_ZTE_ZX297520V3
+ tristate "Clock driver for ZTE zx297520v3 based SoCs"
+ depends on COMMON_CLK_ZTE
+ default SOC_ZX297520V3
+ help
+ This driver supports ZTE zx297520v3 basic clocks.
+
+ Enable this if you want to build a kernel that is able to run on
+ boards based on this SoC. You can safely enable multiple clock
+ drivers. The one(s) matching the device tree will be used.
diff --git a/drivers/clk/zte/Makefile b/drivers/clk/zte/Makefile
index 27db07293165..2c073512e919 100644
--- a/drivers/clk/zte/Makefile
+++ b/drivers/clk/zte/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_COMMON_CLK_ZTE) += clk-zte.o
+obj-$(CONFIG_CLK_ZTE_ZX297520V3) += clk-zx297520v3.o
clk-zte-y += clk-zx.o pll-zx.o clk-regmap.o
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
new file mode 100644
index 000000000000..50263bca6e08
--- /dev/null
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+#include <dt-bindings/clock/zte,zx297520v3-clk.h>
+#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+
+#include "clk-zx.h"
+
+MODULE_IMPORT_NS("ZTE_CLK");
+
+/* Used for gates where we don't know the parent input(s). Assume general bus clock. */
+static const char * const clk_unknown[] = {
+ "osc26m",
+};
+
+/* Used for gates where we know it is using the 26 mhz main clock. */
+static const char * const clk_main[] = {
+ "osc26m",
+};
+
+static const char * const zx297529v3_top_inputs[] = {
+ "osc26m",
+ "osc32k"
+};
+
+/* Top and matrix clocks are chaotic - I haven't found a consistent pattern behind their register
+ * and bit locations. Generally there are two gates (pclk, wclk), one mux, two resets and sometimes
+ * one divider, but exceptions apply. For some devices there is only a reset and some general
+ * (parent) clocks need setup. This structure plus macro handles the somewhat regular parts.
+ *
+ * There are some patterns that can be observed.
+ * mux 0x3c, div 0x48, gate 0x54
+ * mux 0x40, div 0x4c, gate 0x5c
+ * mux 0x44, div 0x50, gate 0x60
+ *
+ * For a 0 - 0xc - 0x18 pattern. Muxes from 0x3c to 0x44, dividers from 0x48 to 0x50, gates 0x54 to
+ * 0x60. The pattern is broken for timer t17 though.
+ *
+ * Gates have 4 bits per clock - bit 0 for wclk, bit 1 for pclk, bit 2 for something the ZTE kernel
+ * calls "gate" (the bits we use here are called "en"), which I don't know what it does, and bit 3
+ * seems unused. E.g. offset 0x54 accepts all bits in 0xF77F7F7F - suggesting RTC, I2C0 have an
+ * extra gate bit.
+ *
+ * The default mpll settings multiply the 26 MHz reference clock times 24. A mux selection of 26 MHz
+ * could mean using the 26 MHz oscillator directly, or passing it through the PLL and divide by 24.
+ *
+ * If a UART is set to mpl_d6 (default 104 MHz), changing the mpll multipliers does affect UART
+ * timing as it should. This does not happen when the UART is set to 26 MHz input or timers that
+ * read 26 MHz input. This suggests 26 MHz clocks use the reference clock directly.
+ */
+
+/* AHB: The clock mux works and impact can be tested e.g. with iperf speed testing of the USB
+ * network connection. Values 2 and 3 give the same speed.
+ */
+static const char * const ahb_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+ "mpll_d8", /* 78 mhz */
+ "mpll_d8", /* 78 mhz */
+};
+
+static const char * const timer_top_sel[] = {
+ "osc32k",
+ "osc26m",
+};
+
+static const char * const uart_top_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+};
+
+/* The Cortex M0 coprocessor. It is responsible for booting the board and runs some power management
+ * helper code on the stock firmware, but isn't critical. We can run custom code on it but currently
+ * do not. These bits control the speed and the values are mentioned in ZTE's uboot. It isn't clear
+ * to me if this is directly responsible for the m0 clock, or if it is the input to another clock.
+ * Most likely it is the latter - setting it to osc32k slows down GPIO reads done on the Cortex A53
+ * a lot, although the speed of the A53 and DRAM access remains unaffected.
+ *
+ * I also haven't found a gate that shuts the m0 off and allows restarting. There don't seem to be
+ * resets either.
+ */
+static const char * const m0_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+ "mpll_d8", /* 78 mhz */
+ "osc32k", /* Yes, tested. It is SLLLLOOOOOWWW. */
+};
+
+/* Clk_out0/1/2/32k: These clocks are exposed on GPIOs 15, 16, 17 and 18 respectively. They are used
+ * in ZTE's camera and sound code, by directly poking into the clock registers from the device
+ * drivers. Until the respective devices are supported they can safely be switched off.
+ *
+ * For clk_out1 ZTE's camera code says the following:
+ *
+ * 0 -> 20 MHz
+ * 1 -> 40 MHz
+ * 2 -> 13 MHz
+ * 3 -> 26 MHz
+ *
+ * 0 and 1 read from upll. I confirmed their rates (upll_d24 and upll_d12) by setting upll to a very
+ * low frequency and sampling the clock by GPIO reads. The outputs of 2 and 3 are way too high to
+ * test that way. Both are not reading from any PLL. I am fairly sure that 3 is just direct osc26m
+ * because it perfectly matches what out2 is showing in its 26 MHz setting. Setting 2 is an enigma.
+ * It is not from any PLL (disable postdiv_out on all of them and the clock will keep oscillating).
+ *
+ * Probably the best way us to model this as a mux (bit 7) and divider (bit 6), but since this is
+ * not a plain val+1 divider like the rest of the divs I am leaving the divider out until an actual
+ * hardware user is found. It would need support for divider tables or flags in the regmap div
+ * clocks.
+ *
+ * Clk_out2 is similar, but it has only one control bit in top 0x34 bit 8. Neither setting selects
+ * a PLL output. When setting *0x34 = 0x080, clk_out1 and clk_out2 are in lockstep, presumably
+ * running at 13 MHz (clk_out1 mux select 26m, both have their divider set to 2). 0x1c0 also runs in
+ * lockstep (clk_out1 select 26m, both div 1).
+ *
+ * clk_out0 has a mux in bit 5. Value 0 most likely selects osc26m. I am not entirely sure about
+ * value 1 (which is the default), but the m0 mux has an impact on it. It looks like a debug pin
+ * that exposes some core clock.
+ */
+
+static const char * const out0_sel[] = {
+ "osc26m",
+ "m0_wclk",
+};
+
+static const char * const out1_sel[] = {
+ "upll_d12", /* 40 MHz */
+ "osc26m",
+};
+
+/* Clk_o is similar to clk_out*, providing a clock on GPIO 20, presumably for driving a (R)MII phy.
+ * The 50 MHz value is documented in a stray comment in ZTE's GMAC driver. I tested it similarly to
+ * the above pins. Mux setting 0 gives half the count as setting 1 and setting 1 gives gpll divided
+ * by 4 - matching the 50 MHz suggested by the ZTE comment at the default gpll settings. Gating gpll
+ * stops the clock for values 0 and 1.
+ *
+ * Settings 2 and 3 are possible, but seem to return garbage. It is generally pulsing up and down,
+ * except if both gpll and upll are stopped. I suspect it just reads random electrical fluctuation
+ * from other places in the board. Yes, I had a pull-down enabled when testing this.
+ *
+ * This could also be a case of mux + inverse div, but since the settings we might possibly need are
+ * standard gpll outputs just model it as a mux.
+ *
+ * I am not aware of any board that uses this though. The Ethernet equipped ones I have all run the
+ * phy with its own oscillator.
+ */
+static const char * const rmii_sel[] = {
+ "gpll_d8", /* 25 MHz */
+ "gpll_d4", /* 50 MHz */
+};
+
+static const unsigned int mpll_postdivs[] = {1, 2, 3, 4, 5, 6, 8, 12, 16, 26};
+static const unsigned int pll_postdivs[] = {1, 2, 3, 4, 5, 6, 8, 12, 16};
+static const unsigned int unknownpll_postdivs[] = {2};
+
+static const struct zx_pll_desc zx297520v3_plls[] = {
+ /* Default setting: 0x48040c11. 624/312/156. Only a single possible parent. This is the
+ * PLL for pretty much everything, including CPU, RAM and USB.
+ *
+ * Changing this PLL makes it possible to overclock the CPU or do more fine grained
+ * underclocking than the CPU's mux allows. It does run into two problems though: The USB
+ * device uses this PLL's output directly and is *very* sensitive to differences. DRAM
+ * is also fed by this clock and needs to be re-trained on larger changes, which needs to
+ * be done by the stage 1 boot loader.
+ */
+ {
+ .id = ZX297520V3_MPLL,
+ .name = "mpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = mpll_postdivs,
+ .num_postdivs = ARRAY_SIZE(mpll_postdivs),
+ .reg = 0x8
+ },
+
+ /* ZTE's code calls this PLL "upll". The only possible consumer I found is clk_out1, which
+ * outputs this clock on GPIO 16. The device that consumes this is an SPI camera, which I
+ * haven't seen in any device so far.
+ *
+ * Long story short, shut it off.
+ */
+ {
+ .id = ZX297520V3_UPLL,
+ .name = "upll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x10,
+ },
+
+ /* Default value 0x4834902d. Feeds dpll. 46.08 MHz. Bit 25 can be set, so two parents are
+ * possible. It looks like both values select the 26 MHz oscillator though.
+ */
+ {
+ .id = 0,
+ .name = "unknownpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = unknownpll_postdivs,
+ .num_postdivs = ARRAY_SIZE(unknownpll_postdivs),
+ .reg = 0x100,
+ },
+
+ /* The documentation says 491.52 MHz and measurement with the LSP TDM device supports this.
+ * The default value is 0x480c2011, but not all boot loaders set it up. To get to 491.52
+ * with these settings it needs a 23.04 MHz reference clock, which matches unknownpll_d2.
+ * If unknownpll is disabled, dpll loses its lock. We set the frequency on this PLL if we
+ * find it is not enabled by the boot loader.
+ *
+ * The proprietary LTE driver or coproc enables and disables it. TDM and I2S can use it.
+ *
+ * It accepts parent values 0, 1, 2 and 3. Parent 0 is unknownpll_d2. The others look like
+ * osc26m. With a parent != 0 dpll never loses its lock even when all other PLLs are off
+ * and the TDM counter register increases at a rate consistent with a 26.0/23.04 clock
+ * increase.
+ */
+ {
+ .id = ZX297520V3_DPLL,
+ .name = "dpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 491520000,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x18,
+ },
+
+ /* "g" is either for "general" or "gigahertz". The VCO runs at 1GHz. Output clocks are 200,
+ * 100, 50, 25, ... MHz. It is used optionally by SDIO and QSPI and can drive a GPIO clock
+ * output for RMII, so it doesn't seem very general.
+ */
+ {
+ .id = ZX297520V3_GPLL,
+ .name = "gpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x110,
+ },
+};
+
+#define MUX(_id, _name, _parents, _reg, _shift, _size) { \
+ _id, _name, _parents, ARRAY_SIZE(_parents), _reg, _shift, _size}
+
+#define DIV(_id, _name, _parent, _reg, _shift, _size) { _id, _name, _parent, _reg, _shift, _size }
+
+#define GATE(_id, _name, _parent, _reg, _shift, _flags) { \
+ .id = _id, \
+ .name = _name, \
+ .parent = _parent, \
+ .flags = _flags, \
+ .reg = _reg, \
+ .shift = _shift, \
+}
+
+static const struct zx_mux_desc zx297520v3_top_muxes[] = {
+ MUX(ZX297520V3_M0_WCLK, "m0_wclk", m0_sel, 0x38, 0, 2),
+ MUX(0, "ahb_mux", ahb_sel, 0x3c, 4, 2),
+ MUX(0, "timer_t08_mux", timer_top_sel, 0x40, 1, 1),
+ MUX(0, "timer_t09_mux", timer_top_sel, 0x40, 0, 1),
+ MUX(0, "timer_t12_mux", timer_top_sel, 0x3c, 0, 1),
+ MUX(0, "timer_t13_mux", timer_top_sel, 0x44, 0, 1),
+ MUX(0, "timer_t14_mux", timer_top_sel, 0x44, 1, 1),
+ MUX(0, "timer_t15_mux", timer_top_sel, 0x3c, 3, 1),
+ MUX(0, "timer_t16_mux", timer_top_sel, 0x44, 2, 1),
+ MUX(0, "timer_t17_mux", timer_top_sel, 0x120, 0, 1),
+ MUX(0, "wdt_t18_mux", timer_top_sel, 0x3c, 6, 1),
+ MUX(0, "i2c0_mux", uart_top_sel, 0x3c, 1, 1),
+ MUX(0, "uart0_mux", uart_top_sel, 0x40, 2, 1),
+ MUX(0, "out0_mux", out0_sel, 0x34, 5, 1),
+ MUX(0, "out1_mux", out1_sel, 0x34, 7, 1),
+ MUX(0, "rmiiphy_mux", rmii_sel, 0x11c, 0, 2),
+};
+
+static const struct zx_div_desc zx297520v3_top_dividers[] = {
+ DIV(0, "timer_t08_div", "timer_t08_mux", 0x4c, 8, 4),
+ DIV(0, "timer_t09_div", "timer_t09_mux", 0x4c, 0, 4),
+ DIV(0, "timer_t12_div", "timer_t12_mux", 0x48, 0, 4),
+ DIV(0, "timer_t13_div", "timer_t13_mux", 0x50, 0, 4),
+ DIV(0, "timer_t14_div", "timer_t14_mux", 0x50, 4, 4),
+ DIV(0, "timer_t15_div", "timer_t15_mux", 0x48, 4, 4),
+ DIV(0, "timer_t16_div", "timer_t16_mux", 0x50, 8, 4),
+ DIV(0, "timer_t17_div", "timer_t17_mux", 0x124, 0, 4),
+ DIV(0, "wdt_t18_div", "wdt_t18_mux", 0x48, 8, 4),
+ DIV(0, "usim1_div", clk_main[0], 0x48, 12, 1),
+};
+
+static const struct zx_gate_desc zx297520v3_top_gates[] = {
+ /* Turning off this clock crashes the device. */
+ GATE(ZX297520V3_AHB_WCLK, "ahb_wclk", "ahb_mux", 0x54, 12,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_AHB_PCLK, "ahb_pclk", clk_main[0], 0x54, 13,
+ CLK_IS_CRITICAL),
+
+ /* SRAM1 and 2 clocks. Leave them on for now, as turning them off carelessly hangs the M0 */
+ GATE(ZX297520V3_SRAM1_PCLK, "sram1_pclk", clk_main[0], 0x54, 18,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_SRAM2_PCLK, "sram2_pclk", clk_main[0], 0x54, 16,
+ CLK_IS_CRITICAL),
+
+ /* Pinmux (AON, TOP, IOCFG but not PDCFG). Critical as well until we have a driver that
+ * consumes it. I don't think we'll realistically shut this off ever.
+ *
+ * Setting either bit 0 or 1 in register 0x58 makes the device work.
+ */
+ GATE(ZX297520V3_PMM_WCLK, "pmm_wclk", clk_main[0], 0x58, 0,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_PMM_PCLK, "pmm_pclk", clk_main[0], 0x58, 1,
+ CLK_IS_CRITICAL),
+
+ /* Timers. We don't use any of them, just shut them off. The timers are named and sorted
+ * by the IO address of the main timer controls. Some of the controls are documented in
+ * ZTE's kernel, the others I found by trial and error.
+ *
+ * Timer T17 is used by the ZSP firmware. The rproc driver will enable it as needed.
+ */
+ GATE(ZX297520V3_TIMER_T08_WCLK, "timer_t08_wclk", "timer_t08_div", 0x5c, 8, 0),
+ GATE(ZX297520V3_TIMER_T08_PCLK, "timer_t08_pclk", clk_main[0], 0x5c, 9, 0),
+ GATE(ZX297520V3_TIMER_T09_WCLK, "timer_t09_wclk", "timer_t09_div", 0x5c, 4, 0),
+ GATE(ZX297520V3_TIMER_T09_PCLK, "timer_t09_pclk", clk_main[0], 0x5c, 5, 0),
+ GATE(ZX297520V3_TIMER_T12_WCLK, "timer_t12_wclk", "timer_t12_div", 0x54, 4, 0),
+ GATE(ZX297520V3_TIMER_T12_PCLK, "timer_t12_pclk", clk_main[0], 0x54, 5, 0),
+ GATE(ZX297520V3_TIMER_T13_WCLK, "timer_t13_wclk", "timer_t13_div", 0x60, 0, 0),
+ GATE(ZX297520V3_TIMER_T13_PCLK, "timer_t13_pclk", clk_main[0], 0x60, 1, 0),
+ GATE(ZX297520V3_TIMER_T14_WCLK, "timer_t14_wclk", "timer_t14_div", 0x60, 4, 0),
+ GATE(ZX297520V3_TIMER_T14_PCLK, "timer_t14_pclk", clk_main[0], 0x60, 5, 0),
+ GATE(ZX297520V3_TIMER_T15_WCLK, "timer_t15_wclk", "timer_t15_div", 0x54, 20, 0),
+ GATE(ZX297520V3_TIMER_T15_PCLK, "timer_t15_pclk", clk_main[0], 0x54, 21, 0),
+ GATE(ZX297520V3_TIMER_T16_WCLK, "timer_t16_wclk", "timer_t16_div", 0x60, 8, 0),
+ GATE(ZX297520V3_TIMER_T16_PCLK, "timer_t16_pclk", clk_main[0], 0x60, 9, 0),
+ GATE(ZX297520V3_TIMER_T17_WCLK, "timer_t17_wclk", "timer_t17_div", 0x128, 0, 0),
+ GATE(ZX297520V3_TIMER_T17_PCLK, "timer_t17_pclk", clk_main[0], 0x128, 1, 0),
+ /* This watchdog is set up by the bootloader and in normal operation the m0 firmware will
+ * feed the dog. The m0 firmware in turn wants to be fed in its own way. Since we normally
+ * don't run any m0 firmware we shut it off by default and expose it to userspace via the
+ * watchdog driver.
+ */
+ GATE(ZX297520V3_WDT_T18_WCLK, "wdt_t18_wclk", "wdt_t18_div", 0x54, 24, 0),
+ GATE(ZX297520V3_WDT_T18_PCLK, "wdt_t18_pclk", clk_main[0], 0x54, 25, 0),
+
+ GATE(ZX297520V3_I2C0_WCLK, "i2c0_wclk", "i2c0_mux", 0x54, 8, 0),
+ GATE(ZX297520V3_I2C0_PCLK, "i2c0_pclk", clk_main[0], 0x54, 9, 0),
+ GATE(ZX297520V3_UART0_WCLK, "uart0_wclk", "uart0_mux", 0x5c, 12, 0),
+ GATE(ZX297520V3_UART0_PCLK, "uart0_pclk", clk_main[0], 0x5c, 13, 0),
+
+ /* ZTE says the USB input is a 24 MHz clock based on mpll. Testing shows that Upll is not
+ * involved. The USB register space can be accessed with ahb_pclk gated, but not with
+ * ahb_wclk gated. ZTE also lists ahb_wclk as parent for the second clock.
+ */
+ GATE(ZX297520V3_USB_WCLK, "usb_wclk", "mpll_d26", 0x6c, 3, 0),
+ GATE(ZX297520V3_USB_PCLK, "usb_pclk", "ahb_wclk", 0x6c, 4, 0),
+ /* The HSIC hardware is listed in ZTE's code with a physical address of 0x01600000. These
+ * bits are part of the ones that control it.
+ */
+ GATE(ZX297520V3_HSIC_WCLK, "hsic_wclk", "mpll_d26", 0x6c, 1, 0),
+ GATE(ZX297520V3_HSIC_PCLK, "hsic_pclk", "ahb_wclk", 0x6c, 2, 0),
+
+ /* How does this RTC work? I don't know, the ZTE kernel does not talk to it. The actual RTC
+ * is on the I2C connected PMIC.
+ */
+ GATE(ZX297520V3_RTC_WCLK, "rtc_wclk", clk_unknown[0], 0x54, 0, 0),
+ GATE(ZX297520V3_RTC_PCLK, "rtc_pclk", clk_main[0], 0x54, 1, 0),
+
+ GATE(ZX297520V3_USIM1_WCLK, "usim1_wclk", "usim1_div", 0x54, 28, 0),
+ GATE(ZX297520V3_USIM1_PCLK, "usim1_pclk", clk_main[0], 0x54, 29, 0),
+
+ /* LTE: gate only as far as I can see. I looked for resets and did not find any. There may
+ * be mux/div, but without understanding the behavior of this hardware it is impossible to
+ * tell. They are sorted by physical MMIO address of the devices, which happens to be the
+ * inverse order of the bits.
+ *
+ * I don't know what "LPM", "TD" and "W" mean. I copied them from ZTE's names.
+ */
+ GATE(ZX297520V3_LPM_GSM_WCLK, "lpm_gsm_wclk", clk_unknown[0], 0x58, 10, 0),
+ GATE(ZX297520V3_LPM_GSM_PCLK, "lpm_gsm_pclk", clk_unknown[0], 0x58, 11, 0),
+ GATE(ZX297520V3_LPM_LTE_WCLK, "lpm_lte_wclk", clk_unknown[0], 0x58, 8, 0),
+ GATE(ZX297520V3_LPM_LTE_PCLK, "lpm_lte_pclk", clk_unknown[0], 0x58, 9, 0),
+ GATE(ZX297520V3_LPM_TD_WCLK, "lpm_td_wclk", clk_unknown[0], 0x58, 6, 0),
+ GATE(ZX297520V3_LPM_TD_PCLK, "lpm_td_pclk", clk_unknown[0], 0x58, 7, 0),
+ GATE(ZX297520V3_LPM_W_WCLK, "lpm_w_wclk", clk_unknown[0], 0x58, 4, 0),
+ GATE(ZX297520V3_LPM_W_PCLK, "lpm_w_pclk", clk_unknown[0], 0x58, 5, 0),
+
+ GATE(ZX297520V3_OUT0_WCLK, "out0_wclk", "out0_mux", 0x34, 0, 0),
+ GATE(ZX297520V3_OUT1_WCLK, "out1_wclk", "out1_mux", 0x90, 2, 0),
+ GATE(ZX297520V3_OUT2_WCLK, "out2_wclk", clk_main[0], 0x94, 2, 0),
+ GATE(ZX297520V3_OUT32K_WCLK, "out32k_wclk", "osc32k", 0x34, 1, 0),
+ GATE(ZX297520V3_RMIIPHY_WCLK, "rmiiphy_wclk", "rmiiphy_mux", 0x11c, 2, 0),
+};
+
+static const struct zx_clk_data zx297520v3_topclk_data = {
+ .inputs = zx297529v3_top_inputs,
+ .num_inputs = ARRAY_SIZE(zx297529v3_top_inputs),
+ .plls = zx297520v3_plls,
+ .num_plls = ARRAY_SIZE(zx297520v3_plls),
+ .muxes = zx297520v3_top_muxes,
+ .num_muxes = ARRAY_SIZE(zx297520v3_top_muxes),
+ .divs = zx297520v3_top_dividers,
+ .num_divs = ARRAY_SIZE(zx297520v3_top_dividers),
+ .gates = zx297520v3_top_gates,
+ .num_gates = ARRAY_SIZE(zx297520v3_top_gates),
+ .reset_auxdev_name = "zx297520v3_toprst"
+};
+
+static const struct of_device_id of_match_zx297520v3[] = {
+ { .compatible = "zte,zx297520v3-topclk", .data = &zx297520v3_topclk_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_match_zx297520v3);
+
+static struct platform_driver clk_zx297520v3 = {
+ .probe = zx_clk_probe,
+ .driver = {
+ .name = "clk-zx297520v3",
+ .of_match_table = of_match_zx297520v3,
+ },
+};
+
+module_platform_driver(clk_zx297520v3);
+
+MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
+MODULE_DESCRIPTION("ZTE zx297520v3 clock driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 08/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This clock controller controls high speed devices: CPU, DMA, RAM, SDIO,
Ethernet. The only non-clock, non-reset registers I have spotted here
are hardware spinlocks.
I put the entire set of PLL generated frequencies as consumed clocks in
the binding. Due to lack of a data sheet I can't rule out that the any
of the PLL subdivions are used.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/clk-zx297520v3.c | 172 +++++++++++++++++++++++++++++++++++++++
1 file changed, 172 insertions(+)
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
index 50263bca6e08..d90aadf18026 100644
--- a/drivers/clk/zte/clk-zx297520v3.c
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -410,8 +410,180 @@ static const struct zx_clk_data zx297520v3_topclk_data = {
.reset_auxdev_name = "zx297520v3_toprst"
};
+static const char * const cpu_sel[] = {
+ "osc26m",
+ "mpll", /* 624 MHz */
+ "mpll_d2", /* 312 MHz */
+ "mpll_d4", /* 156 MHz */
+};
+
+static const char * const sd0_sel[] = {
+ "osc26m",
+ "mpll_d4", /* 156 MHz */
+ "gpll_d2", /* 100 MHz */
+ "mpll_d8", /* 78 MHz */
+ "gpll_d4", /* 50 MHz */
+ "gpll_d8", /* 25 MHz */
+};
+
+static const char * const sd1_sel[] = {
+ "osc26m",
+ "gpll_d2", /* 100 MHz */
+ "mpll_d8", /* 78 MHz */
+ "gpll_d4", /* 50 MHz */
+ "mpll_d16", /* 39 MHz */
+ "gpll_d8", /* 25 MHz */
+};
+
+static const char * const nand_sel[] = {
+ "mpll_d4", /* 156 MHz */
+ "osc26m",
+};
+
+static const char * const edcp_sel[] = {
+ "osc26m",
+ "mpll_d4", /* 156 MHz */
+ "mpll_d5", /* 124.8 MHz */
+ "mpll_d6", /* 104 MHz */
+};
+
+static const char * const tdm_sel[] = {
+ "osc26m",
+ "dpll_d4", /* 122.88 MHz */
+ "mpll_d6", /* 104 MHz */
+};
+
+static const struct zx_mux_desc zx297520v3_matrix_muxes[] = {
+ MUX(0, "cpu_mux", cpu_sel, 0x20, 0, 2),
+ MUX(0, "sd0_mux", sd0_sel, 0x50, 4, 3),
+ MUX(0, "sd1_mux", sd1_sel, 0x50, 8, 3),
+ MUX(0, "nand_mux", nand_sel, 0x50, 12, 2),
+ MUX(0, "edcp_mux", edcp_sel, 0x50, 16, 2),
+ MUX(0, "tdm_mux", tdm_sel, 0x50, 24, 2),
+};
+
+static const struct zx_gate_desc zx297520v3_matrix_gates[] = {
+ /* Both 0x24 and 0x28 bits 1 and 2 stop the CPU. There is also a bit in topclk+0x138, which
+ * ZTE's uboot calls "A53 reset", which also stops the CPU. I can't really tell the
+ * difference between matrix+28 and top+138. The clock (maxtrix+0x24) can be disabled and
+ * enabled from the Cortex M0 and it will nicely stop and restart the A53, retaining all
+ * state.
+ *
+ * 0x50, bits 0-3 have the DDR clock. A lot of DDR gates and resets are in 0x100.
+ */
+ GATE(ZX297520V3_CPU_WCLK, "cpu_wclk", "cpu_mux", 0x24, 1,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_CPU_PCLK, "cpu_pclk", clk_main[0], 0x24, 2,
+ CLK_IS_CRITICAL),
+
+ /* ZSP aka LTE DSP clock. I think there is a mux at matrix+0x30, but I have no idea
+ * about the frequencies it selects.
+ */
+ GATE(ZX297520V3_ZSP_WCLK, "zsp_wclk", clk_unknown[0], 0x3c, 0, 0),
+
+ GATE(ZX297520V3_SD0_WCLK, "sd0_wclk", "sd0_mux", 0x54, 12, 0),
+ GATE(ZX297520V3_SD0_PCLK, "sd0_pclk", clk_main[0], 0x54, 13, 0),
+ GATE(ZX297520V3_SD0_CDET, "sd0_cdet", "osc32k", 0x54, 14, 0),
+ GATE(ZX297520V3_SD1_WCLK, "sd1_wclk", "sd1_mux", 0x54, 4, 0),
+ GATE(ZX297520V3_SD1_PCLK, "sd1_pclk", clk_main[0], 0x54, 5, 0),
+ /* I don't know how the cdet clock works. Card detection in the way the dwc,mmc driver uses
+ * it appears broken no matter this clock's setting.
+ */
+ GATE(ZX297520V3_SD1_CDET, "sd1_cdet", "osc32k", 0x54, 6, 0),
+
+ /* This is some "denali" NAND, not the qspi connected one */
+ GATE(ZX297520V3_NAND_WCLK, "nand_wclk", "nand_mux", 0x54, 20, 0),
+ GATE(ZX297520V3_NAND_PCLK, "nand_pclk", clk_main[0], 0x54, 21, 0),
+ GATE(ZX297520V3_SSC_WCLK, "ssc_wclk", clk_unknown[0], 0x84, 1, 0),
+ GATE(ZX297520V3_SSC_PCLK, "ssc_pclk", clk_main[0], 0x84, 2, 0),
+
+ /* Yes, WCLK bit > PCLK bit for EDCP */
+ GATE(ZX297520V3_EDCP_WCLK, "edcp_wclk", "edcp_mux", 0x64, 2, 0),
+ GATE(ZX297520V3_EDCP_PCLK, "edcp_pclk", clk_main[0], 0x64, 1, 0),
+
+ /* There are a lot more VOU related controls in these registers, but turning off the main
+ * clock seems to shut off the entire VOU MMIO range.
+ */
+ GATE(ZX297520V3_VOU_WCLK, "vou_wclk", clk_unknown[0], 0x168, 0, 0),
+ GATE(ZX297520V3_VOU_PCLK, "vou_pclk", clk_main[0], 0x168, 1, 0),
+
+ /* PDCFG. Like PMM, either clock bit will allow the device to function. */
+ GATE(ZX297520V3_PDCFG_WCLK, "pdcfg_wclk", clk_unknown[0], 0x88, 0,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_PDCFG_PCLK, "pdcfg_pclk", clk_main[0], 0x88, 1,
+ CLK_IS_CRITICAL),
+
+ /* ZTE's driver has a statemt to the effect of *(top->base+0x11c) = 5, with a comment
+ * suggesting that this sets a 50 mhz clock. The clock code itself lists gmac clocks in
+ * matrix+110 and lists the parents of these clock as 50mhz gpll output, but the GMAC
+ * driver never enables the clocks. It turns out ZTE's code is highly misleading.
+ *
+ * The GMAC's work clock is definitly not any gpll output because it keeps working fine with
+ * gpll disabled. The MDIO speed is mostly unaffected by mpll speed changes, so it is most
+ * likely not fed by mpll either. All other PLLs can be disabled without breaking GMAC, so
+ * osc26m is the only possible remaining parent.
+ *
+ * The GMAC Gates are left enabled by the boot loader and are required for the GMAC to work.
+ *
+ * As for the 50 MHz comment: See rmiiphy_wclk.
+ */
+ GATE(ZX297520V3_GMAC_WCLK, "gmac_wclk", clk_main[0], 0x110, 0, 0),
+ GATE(ZX297520V3_GMAC_PCLK, "gmac_pclk", clk_main[0], 0x110, 1, 0),
+ GATE(ZX297520V3_GMAC_AHB, "gmac_ahb", "AHB_wclk", 0x110, 2, 0),
+
+ GATE(ZX297520V3_MBOX_PCLK, "mbox_pclk", clk_main[0], 0x88, 2, 0),
+ GATE(ZX297520V3_DMA_PCLK, "dma_pclk", clk_main[0], 0x94, 3, 0),
+
+ /* LSP uplink clocks. The PCLK is fairly obvious (disabling it shuts off the entire LSP
+ * register area). The WCLK speeds were deduced by setting timers and qspi muxes to a
+ * specific speed and seeing which bit in matrix+0x7c needs to be enabled for the device
+ * to work.
+ *
+ * Due to the timers I am certain about the 26mhz and 32khz clocks. I cannot directly
+ * observe the qspi mux frequency, so the clock rates depend on ZTE's qspi mux selection
+ * being correct.
+ *
+ * Two additional bits are specific to sound components - the mux for the LSP's TDM IP is
+ * in matrixclk and gets passed down. I2S has a mux in LSP, which can select the dpll_d4
+ * clock.
+ */
+ GATE(ZX297520V3_LSP_MPLL_D5_WCLK, "lsp_mpll_d5", "mpll_d5", 0x7c, 0, 0),
+ GATE(ZX297520V3_LSP_MPLL_D4_WCLK, "lsp_mpll_d4", "mpll_d4", 0x7c, 1, 0),
+ GATE(ZX297520V3_LSP_MPLL_D6_WCLK, "lsp_mpll_d6", "mpll_d6", 0x7c, 2, 0),
+ GATE(ZX297520V3_LSP_MPLL_D8_WCLK, "lsp_mpll_d8", "mpll_d8", 0x7c, 3, 0),
+ GATE(ZX297520V3_LSP_MPLL_D12_WCLK, "lsp_mpll_d12", "mpll_d12", 0x7c, 4, 0),
+ GATE(ZX297520V3_LSP_OSC26M_WCLK, "lsp_osc26m", clk_main[0], 0x7c, 5, 0),
+ GATE(ZX297520V3_LSP_OSC32K_WCLK, "lsp_osc32k", "osc32k", 0x7c, 6, 0),
+ GATE(ZX297520V3_LSP_PCLK, "lsp_pclk", clk_main[0], 0x7c, 7, 0),
+ GATE(ZX297520V3_LSP_TDM_WCLK, "lsp_tdm_wclk", "tdm_mux", 0x7c, 8, 0),
+ GATE(ZX297520V3_LSP_DPLL_D4_WCLK, "lsp_dpll_d4", "dpll_d4", 0x7c, 9, 0),
+};
+
+static const char * const zx297529v3_matrix_inputs[] = {
+ "osc26m", "osc32k",
+ "mpll", "mpll_d2", "mpll_d3", "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
+ "mpll_d16", "mpll_d26",
+ "upll", "upll_d2", "upll_d3", "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
+ "upll_d16",
+ "dpll", "dpll_d2", "dpll_d3", "dpll_d4", "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12",
+ "dpll_d16",
+ "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5", "gpll_d6", "gpll_d8", "gpll_d12",
+ "gpll_d16",
+};
+
+static const struct zx_clk_data zx297520v3_matrixclk_data = {
+ .inputs = zx297529v3_matrix_inputs,
+ .num_inputs = ARRAY_SIZE(zx297529v3_matrix_inputs),
+ .muxes = zx297520v3_matrix_muxes,
+ .num_muxes = ARRAY_SIZE(zx297520v3_matrix_muxes),
+ .gates = zx297520v3_matrix_gates,
+ .num_gates = ARRAY_SIZE(zx297520v3_matrix_gates),
+ .reset_auxdev_name = "zx297520v3_matrixrst"
+};
+
static const struct of_device_id of_match_zx297520v3[] = {
{ .compatible = "zte,zx297520v3-topclk", .data = &zx297520v3_topclk_data },
+ { .compatible = "zte,zx297520v3-matrixclk", .data = &zx297520v3_matrixclk_data },
{ }
};
MODULE_DEVICE_TABLE(of, of_match_zx297520v3);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 09/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
"LSP" is ZTE's term for this part of the SoC, I suspect it stands for
"low speed peripherals". The main UART is here, together with the flash
controller and more surplus proprietary timers.
It also has two more I2C controllers that supposedly connect to a
battery charger, SPI for displays and I2S for analog telephones. The
boards I have don't have any of these components though.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/clk-zx297520v3.c | 192 +++++++++++++++++++++++++++++++++++++++
1 file changed, 192 insertions(+)
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
index d90aadf18026..26b05f2bf97a 100644
--- a/drivers/clk/zte/clk-zx297520v3.c
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -581,9 +581,201 @@ static const struct zx_clk_data zx297520v3_matrixclk_data = {
.reset_auxdev_name = "zx297520v3_matrixrst"
};
+/* LSP clock entries have a common pattern: Bit 0 for WCLK, Bit 1 for PCLK. Bit 4 (and sometimes
+ * more) for WCLK mux.
+ *
+ * Bit 8 and 9 are reset bits. I don't know the difference between the two, but they both need to be
+ * set to deassert the reset.
+ *
+ * Bits 15:12 can be a divisor, but not all clocks have it. Some clocks have a divisor in 19:16.
+ *
+ * The ID given in this table is the first register in the device's MMIO space. ZTE's drivers
+ * usually call this a version register, but it looks more like a device identifier.
+ *
+ * It looks like the registers map to devices like this:
+ *
+ * Timer reg function div dev offset(lsp + xxxx) ID
+ * 0x0: Read-only, probably device identifier 0x00752100
+ * 0x4: timer_l1 Y 0x1000 0x02020000
+ * 0x8: watchdog_l2 Y 0x2000 0x02020000
+ * 0xc: watchdog_l3 Y 0x3000 0x02020000
+ * 0x10: pwm N 0x4000 0x01020000
+ * 0x14: i2s0 Yh 0x5000 0x01030000
+ * 0x18: always 0 - - -
+ * 0x1c: i2s1 Yh 0x6000 0x01030000
+ * 0x20: always 0 - - -
+ * 0x24: qspi N 0x7000 0x01040000
+ * 0x28: uart1 N 0x8000 0x01060000
+ * 0x2c: i2c1 N 0x9000 0x01020000
+ * 0x30: spi0 Y 0xa000 0x01040000
+ * 0x34: timer_lb Y 0xb000 0x02020000
+ * 0x38: timer_lc Y 0xc000 0x02020000
+ * 0x3c: uart2 N 0xd000 0x01060000
+ * 0x40: watchdog_le Y 0xe000 0x02020000
+ * 0x44: timer_lf Y 0xf000 0x02020000
+ * 0x48: spi1 Y 0x10000 0x01040000
+ * 0x4c: timer_l11 Y 0x11000 0x02020000
+ * 0x50: tdm Yh 0x12000 0x01040000
+ *
+ * Registers 0x58, 0x5c, 0x60, 0x64, 0x68 seem to contain more controls for i2s and tdm.
+ *
+ * I am not sure about the device at offset 0x4000 (clk reg 0x10). The ID matches that of i2c, but
+ * it has a larger register set. I suspect it is a PWM device, but I have not seen any ZTE kernel
+ * operate it - even devices with displays only use a GPIO to control the backlight.
+ */
+
+static const char * const timer_lsp_sel[] = {
+ "lsp_osc32k",
+ "lsp_osc26m",
+};
+
+static const char * const uart_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d6",
+};
+
+static const char * const i2s_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_dpll_d4",
+ "lsp_mpll_d6",
+ /* Unknown */
+};
+
+static const char * const tdm_lsp_sel[] = {
+ "lsp_tdm_wclk",
+};
+
+static const char * const spi_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d4",
+ "lsp_mpll_d6",
+ /* Unknown */
+};
+
+static const char * const qspi_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d4",
+ "lsp_mpll_d5",
+ "lsp_mpll_d6",
+ "lsp_mpll_d8",
+ "lsp_mpll_d12",
+ "lsp_osc26m",
+ "lsp_osc26m",
+};
+
+static const struct zx_mux_desc zx297520v3_lsp_muxes[] = {
+ MUX(0, "timer_l1_mux", timer_lsp_sel, 0x04, 4, 1),
+ MUX(0, "wdt_l2_mux", timer_lsp_sel, 0x08, 4, 1),
+ MUX(0, "wdt_l3_mux", timer_lsp_sel, 0x0c, 4, 1),
+ /* PWM: No mux bit can be set */
+ MUX(0, "i2s0_mux", i2s_lsp_sel, 0x14, 4, 2),
+ /* 0x18: Always 0 */
+ MUX(0, "i2s1_mux", i2s_lsp_sel, 0x1c, 4, 2),
+ /* 0x20: Always 0 */
+ MUX(0, "qspi_mux", qspi_lsp_sel, 0x24, 4, 3),
+ MUX(0, "uart1_mux", uart_lsp_sel, 0x28, 4, 1),
+ MUX(0, "i2c1_mux", uart_lsp_sel, 0x2c, 4, 1),
+ MUX(0, "spi0_mux", spi_lsp_sel, 0x30, 4, 2),
+ MUX(0, "timer_lb_mux", timer_lsp_sel, 0x34, 4, 1),
+ MUX(0, "timer_lc_mux", timer_lsp_sel, 0x38, 4, 1),
+ MUX(0, "uart2_mux", uart_lsp_sel, 0x3c, 4, 1),
+ MUX(0, "wdt_le_mux", timer_lsp_sel, 0x40, 4, 1),
+ MUX(0, "timer_lf_mux", timer_lsp_sel, 0x44, 4, 1),
+ MUX(0, "spi1_mux", spi_lsp_sel, 0x48, 4, 2),
+ MUX(0, "timer_l11_mux", timer_lsp_sel, 0x4c, 4, 1),
+ /* TDM: No mux in LSP. Instead, it is in matrix with a separate clk line to LSP */
+};
+
+static const struct zx_div_desc zx297520v3_lsp_dividers[] = {
+ DIV(0, "timer_l1_div", "timer_l1_mux", 0x04, 12, 4),
+ DIV(0, "wdt_l2_div", "wdt_l2_mux", 0x08, 12, 4),
+ DIV(0, "wdt_l3_div", "wdt_l3_mux", 0x0c, 12, 4),
+ /* PWM: No div */
+ DIV(0, "i2s0_div", "i2s0_mux", 0x14, 16, 4),
+ /* 0x18: Always 0 */
+ DIV(0, "i2s1_div", "i2s1_mux", 0x1c, 16, 4),
+ /* 0x20: Always 0 */
+ /* qspi, uart1, i2c1: No div */
+ DIV(0, "spi0_div", "spi0_mux", 0x30, 12, 4),
+ DIV(0, "timer_lb_div", "timer_lb_mux", 0x34, 12, 4),
+ DIV(0, "timer_lc_div", "timer_lc_mux", 0x38, 12, 4),
+ /* uart2: No div */
+ DIV(0, "wdt_le_div", "wdt_le_mux", 0x40, 12, 4),
+ DIV(0, "timer_lf_div", "timer_lf_mux", 0x44, 12, 4),
+ DIV(0, "spi1_div", "spi1_mux", 0x48, 12, 4),
+ DIV(0, "timer_l11_div", "timer_l11_mux", 0x4c, 12, 4),
+ DIV(0, "tdm_div", "lsp_tdm_wclk", 0x50, 16, 4),
+};
+
+static const struct zx_gate_desc zx297520v3_lsp_gates[] = {
+ GATE(ZX297520V3_TIMER_L1_WCLK, "timer_l1_wclk", "timer_l1_div", 0x04, 0, 0),
+ GATE(ZX297520V3_TIMER_L1_PCLK, "timer_l1_pclk", "lsp_pclk", 0x04, 1, 0),
+ GATE(ZX297520V3_WDT_L2_WCLK, "wdt_l2_wclk", "wdt_l2_div", 0x08, 0, 0),
+ GATE(ZX297520V3_WDT_L2_PCLK, "wdt_l2_pclk", "lsp_pclk", 0x08, 1, 0),
+ GATE(ZX297520V3_WDT_L3_WCLK, "wdt_l3_wclk", "wdt_l3_div", 0x0c, 0, 0),
+ GATE(ZX297520V3_WDT_L3_PCLK, "wdt_l3_pclk", "lsp_pclk", 0x0c, 1, 0),
+ /* I don't know the LSP parent. It must be one of the LSP inputs though. */
+ GATE(ZX297520V3_PWM_WCLK, "pwm_wclk", "lsp_osc26m", 0x10, 0, 0),
+ GATE(ZX297520V3_PWM_PCLK, "pwm_pclk", "lsp_pclk", 0x10, 1, 0),
+ GATE(ZX297520V3_I2S0_WCLK, "i2s0_wclk", "i2s0_div", 0x14, 0, 0),
+ GATE(ZX297520V3_I2S0_PCLK, "i2s0_pclk", "lsp_pclk", 0x14, 1, 0),
+ /* 0x1c: Always 0 */
+ GATE(ZX297520V3_I2S1_WCLK, "i2s1_wclk", "i2s1_div", 0x1c, 0, 0),
+ GATE(ZX297520V3_I2S1_PCLK, "i2s1_pclk", "lsp_pclk", 0x1c, 1, 0),
+ /* 0x20: Always 0 */
+ GATE(ZX297520V3_QSPI_WCLK, "qspi_wclk", "qspi_mux", 0x24, 0, 0),
+ GATE(ZX297520V3_QSPI_PCLK, "qspi_pclk", "lsp_pclk", 0x24, 1, 0),
+ GATE(ZX297520V3_UART1_WCLK, "uart1_wclk", "uart1_mux", 0x28, 0, 0),
+ GATE(ZX297520V3_UART1_PCLK, "uart1_pclk", "lsp_pclk", 0x28, 1, 0),
+ GATE(ZX297520V3_I2C1_WCLK, "i2c1_wclk", "i2c1_mux", 0x2c, 0, 0),
+ GATE(ZX297520V3_I2C1_PCLK, "i2c1_pclk", "lsp_pclk", 0x2c, 1, 0),
+ GATE(ZX297520V3_SPI0_WCLK, "spi0_wclk", "spi0_div", 0x30, 0, 0),
+ GATE(ZX297520V3_SPI0_PCLK, "spi0_pclk", "lsp_pclk", 0x30, 1, 0),
+ GATE(ZX297520V3_TIMER_LB_WCLK, "timer_lb_wclk", "timer_lb_div", 0x34, 0, 0),
+ GATE(ZX297520V3_TIMER_LB_PCLK, "timer_lb_pclk", "lsp_pclk", 0x34, 1, 0),
+ GATE(ZX297520V3_TIMER_LC_WCLK, "timer_lc_wclk", "timer_lc_div", 0x38, 0, 0),
+ GATE(ZX297520V3_TIMER_LC_PCLK, "timer_lc_pclk", "lsp_pclk", 0x38, 1, 0),
+ GATE(ZX297520V3_UART2_WCLK, "uart2_wclk", "uart2_mux", 0x3c, 0, 0),
+ GATE(ZX297520V3_UART2_PCLK, "uart2_pclk", "lsp_pclk", 0x3c, 1, 0),
+ GATE(ZX297520V3_WDT_LE_WCLK, "wdt_le_wclk", "wdt_le_div", 0x40, 0, 0),
+ GATE(ZX297520V3_WDT_LE_PCLK, "wdt_le_pclk", "lsp_pclk", 0x40, 1, 0),
+ GATE(ZX297520V3_TIMER_LF_WCLK, "timer_lf_wclk", "timer_lf_div", 0x44, 0, 0),
+ GATE(ZX297520V3_TIMER_LF_PCLK, "timer_lf_pclk", "lsp_pclk", 0x44, 1, 0),
+ GATE(ZX297520V3_SPI1_WCLK, "spi1_wclk", "spi1_div", 0x48, 0, 0),
+ GATE(ZX297520V3_SPI1_PCLK, "spi1_pclk", "lsp_pclk", 0x48, 1, 0),
+ GATE(ZX297520V3_TIMER_L11_WCLK, "timer_l11_wclk", "timer_l11_div", 0x4c, 0, 0),
+ GATE(ZX297520V3_TIMER_L11_PCLK, "timer_l11_pclk", "lsp_pclk", 0x4c, 1, 0),
+ GATE(ZX297520V3_TDM_WCLK, "tdm_wclk", "tdm_div", 0x50, 0, 0),
+ GATE(ZX297520V3_TDM_PCLK, "tdm_pclk", "lsp_pclk", 0x50, 1, 0),
+};
+
+static const char * const zx297529v3_lsp_inputs[] = {
+ "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
+ "osc26m", "osc32k", "tdm_wclk", "dpll_d4"
+};
+
+static const char * const zx297529v3_lsp_inputs_enable[] = {
+ "pclk"
+};
+
+static const struct zx_clk_data zx297520v3_lspclk_data = {
+ .inputs_enable = zx297529v3_lsp_inputs_enable,
+ .num_inputs_enable = ARRAY_SIZE(zx297529v3_lsp_inputs_enable),
+ .inputs = zx297529v3_lsp_inputs,
+ .num_inputs = ARRAY_SIZE(zx297529v3_lsp_inputs),
+ .muxes = zx297520v3_lsp_muxes,
+ .num_muxes = ARRAY_SIZE(zx297520v3_lsp_muxes),
+ .divs = zx297520v3_lsp_dividers,
+ .num_divs = ARRAY_SIZE(zx297520v3_lsp_dividers),
+ .gates = zx297520v3_lsp_gates,
+ .num_gates = ARRAY_SIZE(zx297520v3_lsp_gates),
+ .reset_auxdev_name = "zx297520v3_lsprst"
+};
+
static const struct of_device_id of_match_zx297520v3[] = {
{ .compatible = "zte,zx297520v3-topclk", .data = &zx297520v3_topclk_data },
{ .compatible = "zte,zx297520v3-matrixclk", .data = &zx297520v3_matrixclk_data },
+ { .compatible = "zte,zx297520v3-lspclk", .data = &zx297520v3_lspclk_data },
{ }
};
MODULE_DEVICE_TABLE(of, of_match_zx297520v3);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This drives the auxiliary devices created by the clock driver.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
MAINTAINERS | 1 +
drivers/reset/Kconfig | 11 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-zte-zx297520v3.c | 224 +++++++++++++++++++++++++++++++++++
4 files changed, 237 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f1f0459b2c72..55bf0290343a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3871,6 +3871,7 @@ F: Documentation/devicetree/zte,zx297520v3-*
F: arch/arm/boot/dts/zte/
F: arch/arm/mach-zte/
F: drivers/clk/zte/
+F: drivers/reset/reset-zte-zx297520v3.c
F: include/dt-bindings/clock/zte,zx297520v3-clk.h
ARM/ZYNQ ARCHITECTURE
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index d009eb0849a3..116dd23f1b8e 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -404,6 +404,17 @@ 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 (ARCH_ZTE || COMPILE_TEST)
+ default CLK_ZTE_ZX297520V3
+ select AUXILIARY_BUS
+ help
+ This enables the reset controller for ZTE zx297520v3 SoCs. The reset
+ controller is part of the clock controller on this SoC. This driver
+ operates on an auxiliary device exposed by the clock driver. Enable
+ this driver if you plan to boot the kernel on a zx297520v3 based SoC.
+
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..2022f4df2ebd
--- /dev/null
+++ b/drivers/reset/reset-zte-zx297520v3.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+#include <dt-bindings/clock/zte,zx297520v3-clk.h>
+#include <linux/reset-controller.h>
+#include <linux/platform_device.h>
+#include <linux/auxiliary_bus.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/iopoll.h>
+#include <linux/delay.h>
+
+struct zte_reset_reg {
+ u32 mask, wait_mask;
+ u16 reg;
+};
+
+struct zte_reset_info {
+ 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);
+ int res;
+ u32 val;
+
+ res = regmap_set_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
+ if (res)
+ return res;
+
+ /* This is a special case used only by USB reset */
+ if (rst->resets[id].wait_mask) {
+ return regmap_read_poll_timeout(rst->map, rst->resets[id].reg + 4, val,
+ val & rst->resets[id].wait_mask, 1, 100);
+ }
+
+ return 0;
+}
+
+static int zx29_rst_status(struct reset_controller_dev *rcdev, unsigned long id)
+{
+ struct zte_reset *rst = to_zte_reset(rcdev);
+ int res;
+
+ 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 matrixclk.
+ */
+ [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) },
+ [ZX297520V3_RTC_RESET] = { .reg = 0x74, .mask = BIT(4) | BIT(5) },
+ [ZX297520V3_TIMER_T08_RESET] = { .reg = 0x78, .mask = BIT(4) | BIT(5) },
+ [ZX297520V3_TIMER_T09_RESET] = { .reg = 0x78, .mask = BIT(2) | BIT(3) },
+ [ZX297520V3_PMM_RESET] = { .reg = 0x74, .mask = BIT(0) | 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. This is slightly special because it needs to wait for a ready bit after
+ * deasserting.
+ */
+ [ZX297520V3_USB_RESET] = { .reg = 0x80, .mask = BIT(3) | BIT(4) | BIT(5),
+ .wait_mask = BIT(1)},
+ [ZX297520V3_HSIC_RESET] = { .reg = 0x80, .mask = BIT(0) | BIT(1) | BIT(2),
+ .wait_mask = BIT(0)},
+};
+
+static const struct zte_reset_info zx297520v3_top_info = {
+ .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_info zx297520v3_matrix_info = {
+ .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_info zx297520v3_lsp_info = {
+ .resets = zx297520v3_lsp_resets,
+ .num = ARRAY_SIZE(zx297520v3_lsp_resets),
+};
+
+static int reset_zx297520v3_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ const struct zte_reset_info *drv_info;
+ struct device *dev = &adev->dev;
+ struct zte_reset *rst;
+
+ drv_info = (struct zte_reset_info *)id->driver_data;
+
+ rst = devm_kzalloc(dev, sizeof(*rst), GFP_KERNEL);
+ if (!rst)
+ return -ENOMEM;
+
+ rst->resets = drv_info->resets;
+ rst->rcdev.owner = THIS_MODULE;
+ rst->rcdev.nr_resets = drv_info->num;
+ rst->rcdev.ops = &zx29_rst_ops;
+ rst->rcdev.of_node = dev->of_node;
+ rst->rcdev.dev = dev;
+ rst->rcdev.of_reset_n_cells = 1;
+
+ rst->map = device_node_to_regmap(dev->of_node);
+ if (IS_ERR(rst->map))
+ return dev_err_probe(dev, PTR_ERR(rst->map), "Cannot get parent syscon regmap\n");
+
+ return devm_reset_controller_register(dev, &rst->rcdev);
+}
+
+static const struct auxiliary_device_id reset_zx297520v3_ids[] = {
+ {
+ .name = "clk_zte.zx297520v3_toprst",
+ .driver_data = (kernel_ulong_t)&zx297520v3_top_info,
+ },
+ {
+ .name = "clk_zte.zx297520v3_matrixrst",
+ .driver_data = (kernel_ulong_t)&zx297520v3_matrix_info,
+ },
+ {
+ .name = "clk_zte.zx297520v3_lsprst",
+ .driver_data = (kernel_ulong_t)&zx297520v3_lsp_info,
+ },
+ { },
+};
+
+MODULE_DEVICE_TABLE(auxiliary, reset_zx297520v3_ids);
+
+static struct auxiliary_driver reset_zx297520v3_drv = {
+ .name = "zx297520v3_reset",
+ .id_table = reset_zx297520v3_ids,
+ .probe = reset_zx297520v3_probe,
+};
+
+module_auxiliary_driver(reset_zx297520v3_drv);
+
+MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
+MODULE_DESCRIPTION("ZTE zx297520v3 reset driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 11/12] ARM: dts: zte: Declare zx297520v3 clock device nodes
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This makes use of the driver added in the previous patches. It wires up
the uart clocks and resets and allows getting rid of the placeholder
uartclk node.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 90 +++++++++++++++++++++++++++++++----
1 file changed, 81 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index a16c30a164bb..a2b6909e7434 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/zte,zx297520v3-clk.h>
/ {
#address-cells = <1>;
@@ -20,13 +21,16 @@ cpu@0 {
};
};
- /* Base bus clock and default for the UART. It will be replaced once a clock driver has
- * been added.
- */
- uartclk: uartclk-26000000 {
- #clock-cells = <0>;
+ osc26m: osc26m {
compatible = "fixed-clock";
clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ osc32k: osc32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
};
timer {
@@ -70,13 +74,80 @@ gic: interrupt-controller@f2000000 {
<0xf2040000 0x20000>;
};
+ topclk: clock-controller@13b000 {
+ compatible = "zte,zx297520v3-topclk", "syscon";
+ reg = <0x0013b000 0x400>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&osc26m>, <&osc32k>;
+ clock-names = "osc26m", "osc32k";
+ };
+
+ matrixclk: clock-controller@1306000 {
+ compatible = "zte,zx297520v3-matrixclk", "syscon";
+ reg = <0x01306000 0x400>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&osc26m>, <&osc32k>,
+ <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
+ <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
+ <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
+ <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
+ <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
+ <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
+ <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
+ <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
+ <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
+ <&topclk ZX297520V3_UPLL_D16>,
+ <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
+ <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
+ <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
+ <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
+ <&topclk ZX297520V3_DPLL_D16>,
+ <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
+ <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
+ <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
+ <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
+ <&topclk ZX297520V3_GPLL_D16>;
+ clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3", "mpll_d4",
+ "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12", "mpll_d16",
+ "mpll_d26", "upll", "upll_d2", "upll_d3", "upll_d4",
+ "upll_d5", "upll_d6", "upll_d8", "upll_d12", "upll_d16",
+ "dpll", "dpll_d2", "dpll_d3", "dpll_d4", "dpll_d5", "dpll_d6",
+ "dpll_d8", "dpll_d12", "dpll_d16", "gpll", "gpll_d2",
+ "gpll_d3", "gpll_d4", "gpll_d5", "gpll_d6", "gpll_d8",
+ "gpll_d12", "gpll_d16";
+ };
+
+ lspclk: clock-controller@1400000 {
+ compatible = "zte,zx297520v3-lspclk";
+ reg = <0x01400000 0x100>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ clocks = <&matrixclk ZX297520V3_LSP_MPLL_D5_WCLK>,
+ <&matrixclk ZX297520V3_LSP_MPLL_D4_WCLK>,
+ <&matrixclk ZX297520V3_LSP_MPLL_D6_WCLK>,
+ <&matrixclk ZX297520V3_LSP_MPLL_D8_WCLK>,
+ <&matrixclk ZX297520V3_LSP_MPLL_D12_WCLK>,
+ <&matrixclk ZX297520V3_LSP_OSC26M_WCLK>,
+ <&matrixclk ZX297520V3_LSP_OSC32K_WCLK>,
+ <&matrixclk ZX297520V3_LSP_PCLK>,
+ <&matrixclk ZX297520V3_LSP_TDM_WCLK>,
+ <&matrixclk ZX297520V3_LSP_DPLL_D4_WCLK>;
+ clock-names = "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
+ "osc26m", "osc32k", "pclk", "tdm_wclk", "dpll_d4";
+ };
+
+
uart0: serial@131000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x0018c011>;
reg = <0x00131000 0x1000>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&topclk ZX297520V3_UART0_WCLK>, <&topclk ZX297520V3_UART0_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&topclk ZX297520V3_UART0_RESET>;
status = "disabled";
};
@@ -85,8 +156,9 @@ uart1: serial@1408000 {
arm,primecell-periphid = <0x0018c011>;
reg = <0x01408000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&lspclk ZX297520V3_UART1_WCLK>, <&lspclk ZX297520V3_UART1_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&lspclk ZX297520V3_UART1_RESET>;
status = "disabled";
};
@@ -94,9 +166,9 @@ uart2: serial@140d000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x0018c011>;
reg = <0x0140d000 0x1000>;
- interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&lspclk ZX297520V3_UART2_WCLK>, <&lspclk ZX297520V3_UART2_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&lspclk ZX297520V3_UART2_RESET>;
status = "disabled";
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v4 12/12] ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards
From: Stefan Dösinger @ 2026-06-16 20:26 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com>
This is fairly simple with the driver exposing a syscon regmap. Write a
one to the lowest bit of register 0 and the board resets.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index a2b6909e7434..013ece51c2a0 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -33,6 +33,13 @@ osc32k: osc32k {
#clock-cells = <0>;
};
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ regmap = <&topclk>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
--
2.53.0
^ permalink raw reply related
* [arm-platforms:kvm-arm64/nv3 37/37] arch/arm64/kvm/sys_regs.c:222:30: error: expected ';' after expression
From: kernel test robot @ 2026-06-16 20:36 UTC (permalink / raw)
To: Marc Zyngier; +Cc: llvm, oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nv3
head: aa9a6e84f564417704258a20210b95d18ebf5601
commit: aa9a6e84f564417704258a20210b95d18ebf5601 [37/37] WIP
config: arm64-randconfig-003 (https://download.01.org/0day-ci/archive/20260617/202606170443.zZpDusGs-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260617/202606170443.zZpDusGs-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606170443.zZpDusGs-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/arm64/kvm/sys_regs.c:222:30: error: expected ';' after expression
222 | loc->loc = SR_LOC_SPECIAL : SR_LOC_MEMORY;
| ^
| ;
arch/arm64/kvm/sys_regs.c:222:32: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation]
222 | loc->loc = SR_LOC_SPECIAL : SR_LOC_MEMORY;
| ^
arch/arm64/kvm/sys_regs.c:221:3: note: previous statement is here
221 | if (is_hyp_ctxt(vcpu))
| ^
arch/arm64/kvm/sys_regs.c:222:32: warning: expression result unused [-Wunused-value]
222 | loc->loc = SR_LOC_SPECIAL : SR_LOC_MEMORY;
| ^~~~~~~~~~~~~
2 warnings and 1 error generated.
vim +222 arch/arm64/kvm/sys_regs.c
168
169 #define MAPPED_EL2_SYSREG(r, m, t) \
170 case r: { \
171 locate_mapped_el2_register(vcpu, r, m, t, loc); \
172 break; \
173 }
174
175 static void locate_register(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg,
176 struct sr_loc *loc)
177 {
178 if (!vcpu_get_flag(vcpu, SYSREGS_ON_CPU)) {
179 loc->loc = SR_LOC_MEMORY;
180 return;
181 }
182
183 switch (reg) {
184 MAPPED_EL2_SYSREG(SCTLR_EL2, SCTLR_EL1,
185 translate_sctlr_el2_to_sctlr_el1 );
186 MAPPED_EL2_SYSREG(TTBR0_EL2, TTBR0_EL1,
187 translate_ttbr0_el2_to_ttbr0_el1 );
188 MAPPED_EL2_SYSREG(TTBR1_EL2, TTBR1_EL1, NULL );
189 MAPPED_EL2_SYSREG(TCR_EL2, TCR_EL1,
190 translate_tcr_el2_to_tcr_el1 );
191 MAPPED_EL2_SYSREG(VBAR_EL2, VBAR_EL1, NULL );
192 MAPPED_EL2_SYSREG(AFSR0_EL2, AFSR0_EL1, NULL );
193 MAPPED_EL2_SYSREG(AFSR1_EL2, AFSR1_EL1, NULL );
194 MAPPED_EL2_SYSREG(ESR_EL2, ESR_EL1, NULL );
195 MAPPED_EL2_SYSREG(FAR_EL2, FAR_EL1, NULL );
196 MAPPED_EL2_SYSREG(MAIR_EL2, MAIR_EL1, NULL );
197 MAPPED_EL2_SYSREG(TCR2_EL2, TCR2_EL1, NULL );
198 MAPPED_EL2_SYSREG(PIR_EL2, PIR_EL1, NULL );
199 MAPPED_EL2_SYSREG(PIRE0_EL2, PIRE0_EL1, NULL );
200 MAPPED_EL2_SYSREG(POR_EL2, POR_EL1, NULL );
201 MAPPED_EL2_SYSREG(AMAIR_EL2, AMAIR_EL1, NULL );
202 MAPPED_EL2_SYSREG(ELR_EL2, ELR_EL1, NULL );
203 MAPPED_EL2_SYSREG(SPSR_EL2, SPSR_EL1, NULL );
204 MAPPED_EL2_SYSREG(CONTEXTIDR_EL2, CONTEXTIDR_EL1, NULL );
205 MAPPED_EL2_SYSREG(SCTLR2_EL2, SCTLR2_EL1, NULL );
206 case CNTHCTL_EL2:
207 /* CNTHCTL_EL2 is super special, unless we support NV2p1 */
208 loc->loc = (is_hyp_ctxt(vcpu) && vcpu_el2_e2h_is_set(vcpu) ?
209 SR_LOC_SPECIAL : SR_LOC_MEMORY);
210 break;
211 case CPTR_EL2:
212 /*
213 * CPTR_EL2 is just as special, and needs a certain amount
214 * of handholding. It always lives in memory, due to being
215 * heavily trapped thanks to CPACR_EL1.TCPAC being RES0.
216 * FEAT_NV2p1 fixes this.
217 */
218 locate_mapped_el2_register(vcpu, CPTR_EL2, CPACR_EL1,
219 translate_cptr_el2_to_cpacr_el1,
220 loc);
221 if (is_hyp_ctxt(vcpu))
> 222 loc->loc = SR_LOC_SPECIAL : SR_LOC_MEMORY;
223 break;
224 default:
225 loc->loc = locate_direct_register(vcpu, reg);
226 }
227 }
228
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Frank Li @ 2026-06-16 20:47 UTC (permalink / raw)
To: Hongling Zeng
Cc: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd,
dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719
In-Reply-To: <20260616060449.42225-1-zenghongling@kylinos.cn>
On Tue, Jun 16, 2026 at 02:04:49PM +0800, Hongling Zeng wrote:
> When terminating a non-cyclic DMA transfer, the active descriptor
> is not properly reclaimed. The descriptor is removed from the
> desc_issued list in sun6i_dma_start_desc(), but in
> sun6i_dma_terminate_all(), only cyclic transfer descriptors are
> added to the desc_completed list before cleanup.
>
> For non-cyclic transfers, pchan->desc is set to NULL without first
> adding the descriptor back to a list that vchan_get_all_descriptors()
> can collect. This causes the descriptor and its associated LLI chain
> to be permanently leaked.
>
> Fix by ensuring both cyclic and non-cyclic active descriptors are
> added to the desc_completed list before setting pchan->desc to NULL.
>
> Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>
> ---
> Change in v2;
> -Add pchan->desc != pchan->done check to prevent race condition
> where completed descriptors could be double-added to desc_completed
> list, causing list corruption
> ---
> drivers/dma/sun6i-dma.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 7a79f346250a..12d038ef5f2e 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -946,16 +946,14 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
>
> spin_lock_irqsave(&vchan->vc.lock, flags);
>
> - if (vchan->cyclic) {
> - vchan->cyclic = false;
> - if (pchan && pchan->desc) {
> - struct virt_dma_desc *vd = &pchan->desc->vd;
> - struct virt_dma_chan *vc = &vchan->vc;
> + if (pchan && pchan->desc && pchan->desc != pchan->done) {
> + struct virt_dma_desc *vd = &pchan->desc->vd;
> + struct virt_dma_chan *vc = &vchan->vc;
>
> - list_add_tail(&vd->node, &vc->desc_completed);
> - }
> + list_add_tail(&vd->node, &vc->desc_completed);
should It be in desc_terminated queue?
ref: https://lore.kernel.org/dmaengine/ajETw7uwVx_U9o5F@ryzen/T/#m541c24b45fb425c6a8a81d800db225b58411447e
Frank
> }
>
> + vchan->cyclic = false;
> vchan_get_all_descriptors(&vchan->vc, &head);
>
> if (pchan) {
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
From: Unnathi Chalicheemala @ 2026-06-16 21:14 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jens Wiklander, linux-arm-kernel, linux-kernel, linux-arm-msm,
kernel, Trilok Soni, Satya Durga Srinivasu Prabhala
In-Reply-To: <20260612-fat-energetic-hummingbird-8ddc62@sudeepholla>
On 6/12/2026 3:55 AM, Sudeep Holla wrote:
>
>> Per the FF-A spec, the all-zeros UUID is the defined wildcard that
>> instructs the SPMC to return information for all partitions. Map NULL
>> and empty string to uuid_null rather than crashing in uuid_parse(),
>> preserving the intended "return all partitions" semantics for callers
>> that pass NULL.
>>
>
> Agreed on the spec part but not w.r.t the interface. Where is the driver
> using this call and why is it sending null or wants to extract all the
> partition information ?
>
A developer wanting all partitions might reasonably pass the all-zeros string
"00000000-0000-0000-0000-000000000000"?
>> Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
>> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
>> ---
>> drivers/firmware/arm_ffa/driver.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
>> index b9f17fda7243..dd500fb81b79 100644
>> --- a/drivers/firmware/arm_ffa/driver.c
>> +++ b/drivers/firmware/arm_ffa/driver.c
>> @@ -1129,7 +1129,9 @@ static int ffa_partition_info_get(const char *uuid_str,
>> uuid_t uuid;
>> struct ffa_partition_info *pbuf;
>>
>> - if (uuid_parse(uuid_str, &uuid)) {
>> + if (!uuid_str || uuid_str[0] == '\0') {
>> + uuid = uuid_null;
>
> I object to make it uuid_null. Below check is enough to check NULL
> dereference.
>
> - if (uuid_parse(uuid_str, &uuid)) {
> + if (!uuid_str || uuid_parse(uuid_str, &uuid)) {
>
>
> I don't think we need to service NULL as valid argument via this interface
> as the callee driver needs to pass its partition UUID here.
>
I agree with you, NULL doesn't seem like a valid use case.
Will send another version with your suggestion, thank you for the review.
Regards,
Unnathi
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort
From: Doug Anderson @ 2026-06-16 21:38 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <167493d30ef6c99a44291de14cddd41ced8149c4.1781490440.git.kas@kernel.org>
Hi,
On Sun, Jun 14, 2026 at 7:36 PM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> +/*
> + * Bring the local CPU to a stop, saving its register state into the vmcore
> + * on the kdump crash path first. The single point every arm64 stop path
> + * funnels through, so the bookkeeping (mask interrupts, mark offline, mask
> + * SDEI, optionally power off) lives in one place:
> + *
> + * - the regular IPI_CPU_STOP and pseudo-NMI IPI_CPU_STOP_NMI handlers;
> + * - panic_smp_self_stop(), a CPU parking itself on a parallel panic();
> + * - the SDEI cross-CPU NMI handler (drivers/firmware/arm_sdei_nmi.c),
> + * which reaches CPUs the stop IPIs could not.
> + *
> + * @regs is the register state to record in the vmcore on a crash stop; NULL
> + * means "capture the current context". @die_on_crash decides the kdump crash
> + * path: the IPI stop handlers pass true and power the CPU off (PSCI CPU_OFF,
> + * via __cpu_try_die()) so a capture kernel can reclaim it. The SDEI handler
> + * and panic_smp_self_stop() pass false and only park. For SDEI that is
> + * required, not just conservative: it runs inside an SDEI event that is
> + * deliberately never completed (completing it has firmware resume the wedged
> + * context), and a CPU_OFF from that not-yet-completed context wedges EL3 on
> + * some firmware -- a documented follow-up. Parking also matches this path's
> + * own fallback when CPU_OFF is unavailable.
Nice to have all the details in the function comment. Any reason why
you didn't use kernel-doc format? Nothing else in this file does, I
guess, but it doesn't seem like it would be a problem to start the
trend... ;-)
> @@ -59,8 +64,51 @@ static bool sdei_nmi_available;
>
> #define SDEI_NMI_EVENT 0
>
> +/*
> + * Backtrace and stop both ride SDEI event 0. That is not a chosen economy:
> + * event 0 is the only architecturally software-signalled event -- the sole
> + * event SDEI_EVENT_SIGNAL can target at an arbitrary PE. Every other event
> + * number is a firmware/platform interrupt-bound event, not something the
> + * kernel can raise cross-CPU, so a dedicated "stop" event would need
> + * firmware to define and bind it -- exactly the firmware dependency this
> + * driver sets out to avoid.
> + *
> + * Sharing one event means the handler must tell a stop apart from a
> + * backtrace. A stop is terminal and system-wide -- sdei_nmi_stop_cpus() is
> + * only reached from smp_send_stop() (reboot/halt/panic/kdump), which never
> + * returns -- so once a stop is requested, every later event-0 fire is a
> + * stop too. A single write-once flag therefore carries as much as a
> + * per-CPU mask would: sdei_nmi_stop_cpus() sets it before signalling, and
> + * the handler reads a set flag as "stop this CPU" and a clear flag as
> + * "backtrace" (handled by nmi_cpu_backtrace(), which self-gates on the
> + * framework's backtrace mask). A backtrace fire that races in after a stop
> + * has begun just stops that CPU instead -- harmless, it is going down.
> + */
> +static bool sdei_nmi_stopping;
> +
> static int sdei_nmi_handler(u32 event, struct pt_regs *regs, void *arg)
> {
> + if (READ_ONCE(sdei_nmi_stopping)) {
Don't you need a smp_rmb() before that, to match with the smp_wmb()?
-Doug
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix QoS counter configuration for Tx-fwd channels
From: patchwork-bot+netdevbpf @ 2026-06-16 22:11 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178160712947.2156222.3765685889775458986@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 18:50:29 +0800 you wrote:
> In airoha_qdma_init_qos_stats(), the Tx-fwd counter was incorrectly
> using register index (i << 1) instead of ((i << 1) + 1). This caused
> the Tx-fwd configuration to overwrite the Tx-cpu configuration for
> each QoS channel, resulting in incorrect QoS statistics.
>
> Fix by using the correct register index ((i << 1) + 1) for Tx-fwd
> counter configuration.
>
> [...]
Here is the summary with links:
- net: airoha: Fix QoS counter configuration for Tx-fwd channels
https://git.kernel.org/netdev/net-next/c/1402ecccf563
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Fix QoS counter configuration for Tx-fwd channels
From: patchwork-bot+netdevbpf @ 2026-06-16 22:11 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161132384.2164449.18407700117859190327@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 18:50:29 +0800 you wrote:
> In airoha_qdma_init_qos_stats(), the Tx-fwd counter was incorrectly
> using register index (i << 1) instead of ((i << 1) + 1). This caused
> the Tx-fwd configuration to overwrite the Tx-cpu configuration for
> each QoS channel, resulting in incorrect QoS statistics.
>
> Fix by using the correct register index ((i << 1) + 1) for Tx-fwd
> counter configuration.
>
> [...]
Here is the summary with links:
- [v2,net] net: airoha: Fix QoS counter configuration for Tx-fwd channels
https://git.kernel.org/netdev/net-next/c/1402ecccf563
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] PCI: meson: Fix PERST# timing by asserting reset before LTSSM enable
From: gowtham @ 2026-06-16 23:36 UTC (permalink / raw)
To: neil.armstrong
Cc: Ronald Claveau, robh, bhelgaas, khilman, jbrunet,
martin.blumenstingl, linux-pci, linux-amlogic, linux-arm-kernel,
linux-kernel, yue.wang, lpieralisi, kwilczynski, mani
In-Reply-To: <b2d8cb85-5529-4a4c-a233-64ca7a436f0b@linaro.org>
Hi,
As Neil suggested I moved the PCIe reset to init; I've updated the tag
at
https://github.com/GowthamKudupudi/linux/tree/meson-pcie-warm-reset-linux-7.0.y
Ronald, yes, I do think its proper to initialize PCIe with RESET Active.
Anyway we need the reset *cycle*. Please submit your patch as well.
Thank you!
...Gowtham
On Tue, 16 Jun 2026 08:06:02 +0200
neil.armstrong@linaro.org wrote:
> On 6/15/26 12:34, Ronald Claveau wrote:
> > On 6/14/26 3:56 AM, Gowtham Kudupudi wrote:
> >> On warm reboot, the PCIe controller's LTSSM starts link training
> >> immediately if PERST# is already deasserted from the previous boot.
> >> The driver then pulses PERST# for only 500us, which is too short to
> >> properly reset the endpoint device that has already started
> >> training.
> >>
> >> Fix by moving the PERST# assert/deassert pulse BEFORE enabling
> >> LTSSM, so the endpoint gets a clean reset cycle before link
> >> training begins.
> >>
> >> This was found on Amlogic G12B (A311D) with NVMe on an M.2 slot.
> >> Cold boot worked because POR held PERST# low; warm reboot did not.
> >> The fix was confirmed on a Banana Pi CM4 with Waveshare IO base
> >> board.
> >>
> >> Signed-off-by: Gowtham Kudupudi <gowtham@ferryfair.com>
> >> ---
> >> drivers/pci/controller/dwc/pci-meson.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pci-meson.c
> >> b/drivers/pci/controller/dwc/pci-meson.c index
> >> 5f8e2f4b3c12..3a7e9f1d5b8c 100644 ---
> >> a/drivers/pci/controller/dwc/pci-meson.c +++
> >> b/drivers/pci/controller/dwc/pci-meson.c @@ -310,8 +310,8 @@
> >> static int meson_pcie_start_link(struct dw_pcie *pci) {
> >> struct meson_pcie *mp = to_meson_pcie(pci);
> >>
> >> + meson_pcie_assert_reset(mp);
> >> meson_pcie_ltssm_enable(mp);
> >> - meson_pcie_assert_reset(mp);
>
> I think this change is valid, other controllers resets PERST
> in the host init callback, so either this or move to the
> init callback.
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>
> >>
> >> return 0;
> >> }
> >
> > Hi Gowtham,
> >
> > I have a patch [1] that I haven't submitted yet.
> > This might be related to your issue, what do you think ?
>
> Ronald, This fix is valid, it's definitely better to probe the
> driver with PERST asserted, please send it.
>
> Neil
>
> >
> > [1]
> > https://github.com/rclaveau-tech/linux-khadas/commit/bee0a02d9756
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jacob Keller @ 2026-06-16 23:42 UTC (permalink / raw)
To: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: linux-mips, netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615-dwmac-loongson1-v1-1-cbcf5bc01d9b@gmail.com>
On 6/15/2026 5:24 AM, Keguang Zhang via B4 Relay wrote:
> From: Keguang Zhang <keguang.zhang@gmail.com>
>
> Use dev_err_probe() for the missing match data case to simplify
> error handling.
>
> Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
> ---
At first I recalled that dev_err_probe does strange things with
-EPROBE_DEFER. From the documentation for dev_err_probe:
> * @dev: the pointer to the struct device
> * @err: error value to test
> * @fmt: printf-style format string
> * @...: arguments as specified in the format string
> *
> * This helper implements common pattern present in probe functions for error
> * checking: print debug or error message depending if the error value is
> * -EPROBE_DEFER and propagate error upwards.
> * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
> * checked later by reading devices_deferred debugfs attribute.
> * It replaces the following code sequence::
> *
> * if (err != -EPROBE_DEFER)
> * dev_err(dev, ...);
> * else
> * dev_dbg(dev, ...);
> * return err;
> *
> * with::
> *
> * return dev_err_probe(dev, err, ...);
> *
> * Using this helper in your probe function is totally fine even if @err
> * is known to never be -EPROBE_DEFER.
> * The benefit compared to a normal dev_err() is the standardized format
> * of the error code, which is emitted symbolically (i.e. you get "EAGAIN"
> * instead of "-35"), and having the error code returned allows more
> * compact error paths.
> *
> * Returns @err.
> */
I guess even without -EPROBE_DEFER this is still acceptable. The change
seems fine, if a bit of a minor cleanup. However, net-next is closed,
and this is definitely not a bug-fix worthy of net. This does have the
added benefit of
I'd probably also argue this may go against the desired goals of
net-next with only wanting such cleanups when in the context of other
larger work. Of course that decision ultimately belongs to the maintainers.
You can add my reviewed-by when/if you resubmit when net-next re-opens:
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> drivers/net/ethernet/stmicro/stmmac/dwmac-loongson1.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson1.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson1.c
> index de9aba756aac..ec34adb63f61 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson1.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson1.c
> @@ -176,10 +176,8 @@ static int ls1x_dwmac_probe(struct platform_device *pdev)
> "Unable to find syscon\n");
>
> data = of_device_get_match_data(&pdev->dev);
> - if (!data) {
> - dev_err(&pdev->dev, "No of match data provided\n");
> - return -EINVAL;
> - }
> + if (!data)
> + return dev_err_probe(&pdev->dev, -EINVAL, "No of match data provided\n");
>
> dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
> if (!dwmac)
>
> ---
> base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
> change-id: 20260602-dwmac-loongson1-5e1b9dfc3c62
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v2 1/3] Bluetooth: btmtksdio: correct btmtksdio_txrx_work() loop timeout check
From: Sean Wang @ 2026-06-17 0:40 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen, Sean Wang,
Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, stable
In-Reply-To: <20260616111224.152140-2-senozhatsky@chromium.org>
Hi,
On Tue, Jun 16, 2026 at 6:15 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> The btmtksdio_txrx_work() loop is expected to be terminated if running
> for longer than 5*HZ. However the timeout check is reversed:
> time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when
> old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred.
> Using OR with time_is_before_jiffies(txrx_timeout) means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
>
> Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/bluetooth/btmtksdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index 5b0fab7b89b5..c6f80c419e90 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -620,7 +620,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> if (btmtksdio_rx_packet(bdev, rx_size) < 0)
> bdev->hdev->stat.err_rx++;
> }
> - } while (int_status || time_is_before_jiffies(txrx_timeout));
> + } while (int_status && time_is_after_jiffies(txrx_timeout));
>
This patch has already been merged, so I think the series should be
respun based on the latest code.
> /* Enable interrupt */
> if (bdev->func->irq_handler)
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
>
^ permalink raw reply
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Andrew Jeffery @ 2026-06-17 0:44 UTC (permalink / raw)
To: Karthikeyan KS
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <20260616073053.1144730-1-karthiproffesional@gmail.com>
On Tue, 2026-06-16 at 07:30 +0000, Karthikeyan KS wrote:
> Hi Andrew,
>
> Happy to. Short version: ast2600-evb can't hit the SMP timing window,
> so I reproduce each missing piece deliberately. The driver code under
> test is unmodified -- only the stimulus and the post-race state are
> injected. Stock qemu-system-arm (Debian 8.2.2), no QEMU changes.
>
> Three obstacles, and what I did about each:
This looks like a lot of heavily LLM-assisted effort. Please review the
relevant documentation, starting here:
https://docs.kernel.org/process/submitting-patches.html#using-assisted-by
I feel the testing strategy is pretty questionable. Any invariant
violation is possible with that type of meddling.
I was interested in whether you drove the interrupt sequence via
emulated hardware. I asked because upstream qemu doesn't currently
support the snoop device.
In v3 you said:
The issue was observed on physical AST2600 (dual-core Cortex-A7)
in production under heavy POST code traffic during concurrent
userspace reads.
https://lore.kernel.org/all/20260527175939.2939714-1-karthiproffesional@gmail.com/
Is this true? What platform did you test with?
Andrew
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Alexey Kardashevskiy @ 2026-06-17 0:50 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <20260604083959.1265923-4-aneesh.kumar@kernel.org>
On 4/6/26 18:39, Aneesh Kumar K.V (Arm) wrote:
> Propagate force_dma_unencrypted() into DMA_ATTR_CC_SHARED in the
> dma-direct allocation path and use the attribute to drive the related
> decisions.
>
> This updates dma_direct_alloc(), dma_direct_free(), and
> dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
>
> Tested-by: Jiri Pirko <jiri@nvidia.com>
> Tested-by: Michael Kelley <mhklinux@outlook.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> kernel/dma/direct.c | 53 +++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index a741c8a2ee66..90dc5057a0c0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> bool remap = false, set_uncached = false;
> - bool mark_mem_decrypt = true;
> + bool mark_mem_decrypt = false;
> struct page *page;
> void *ret;
>
> + /*
> + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
> + * attribute. The direct allocator uses it internally after it has
> + * decided that the backing pages must be shared/decrypted, so the
> + * rest of the allocation path can consistently select DMA addresses,
> + * choose compatible pools and restore encryption on free.
Why this limit?
Context: I am looking for a memory pool for a few shared pages (to do some guest<->host communication), SWIOTLB seems like the right fit but swiotlb_alloc() is not exported and dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
> + */
> + if (attrs & DMA_ATTR_CC_SHARED)
> + return NULL;
> +
> + if (force_dma_unencrypted(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> + mark_mem_decrypt = true;
> + }
> +
> size = PAGE_ALIGN(size);
> if (attrs & DMA_ATTR_NO_WARN)
> gfp |= __GFP_NOWARN;
>
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
> + if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
> + DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev))
> return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>
> if (!dev_is_dma_coherent(dev)) {
> @@ -236,7 +251,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> * Remapping or decrypting memory may block, allocate the memory from
> * the atomic pools instead if we aren't allowed block.
> */
> - if ((remap || force_dma_unencrypted(dev)) &&
> + if ((remap || (attrs & DMA_ATTR_CC_SHARED)) &&
> dma_direct_use_pool(dev, gfp))
> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> @@ -312,12 +327,24 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> phys_addr_t phys;
> - bool mark_mem_encrypted = true;
> + bool mark_mem_encrypted = false;
> struct io_tlb_pool *swiotlb_pool;
> unsigned int page_order = get_order(size);
>
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
> + /* see dma_direct_alloc() for details */
> + WARN_ON(attrs & DMA_ATTR_CC_SHARED);
> +
> + /*
> + * if the device had requested for an unencrypted buffer,
> + * convert it to encrypted on free
> + */
> + if (force_dma_unencrypted(dev)) {
> + attrs |= DMA_ATTR_CC_SHARED;
> + mark_mem_encrypted = true;
> + }
> +
> + if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
> + DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev)) {
> /* cpu_addr is a struct page cookie, not a kernel address */
> dma_free_contiguous(dev, cpu_addr, size);
> return;
> @@ -366,10 +393,14 @@ void dma_direct_free(struct device *dev, size_t size,
> struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
> dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
> {
> + unsigned long attrs = 0;
> struct page *page;
> void *ret;
>
> - if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
> + if (force_dma_unencrypted(dev))
> + attrs |= DMA_ATTR_CC_SHARED;
> +
> + if ((attrs & DMA_ATTR_CC_SHARED) && dma_direct_use_pool(dev, gfp))
> return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> if (is_swiotlb_for_alloc(dev)) {
> @@ -403,7 +434,11 @@ void dma_direct_free_pages(struct device *dev, size_t size,
> phys_addr_t phys;
> void *vaddr = page_address(page);
> struct io_tlb_pool *swiotlb_pool;
> - bool mark_mem_encrypted = true;
> + /*
> + * if the device had requested for an unencrypted buffer,
> + * convert it to encrypted on free
> + */
> + bool mark_mem_encrypted = force_dma_unencrypted(dev);
>
> /* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
> if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 3/3] Bluetooth: btmtksdio: call cancel_work_sync() outside of host lock scope
From: Sean Wang @ 2026-06-17 0:56 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen, Sean Wang,
Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, stable
In-Reply-To: <20260616111224.152140-4-senozhatsky@chromium.org>
Hi,
On Tue, Jun 16, 2026 at 6:15 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> cancel_work_sync() should be called outside of host lock scope
> in order to avoid circular locking scenario:
>
> CPU0 CPU1
> close()/reset()
> sdio_claim_host()
> txrx_work
> sdio_claim_host() // sleeps
> cancel_work_sync() // sleeps
>
> In addition, when txrx_work() runs concurrently with close()/reset()
> it better not to re-enable interrupts by testing for BTMTKSDIO_FUNC_ENABLED
> and not BTMTKSDIO_HW_RESET_ACTIVE before C_INT_EN_SET write. However,
> btmtksdio_close() clears the BTMTKSDIO_FUNC_ENABLED too late (after
> cancel_work_sync() call). Move BTMTKSDIO_FUNC_ENABLED bit-clear earlier
> so that txrx_work can see concurrent close().
>
> Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/bluetooth/btmtksdio.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index d8c8d2857527..207d04cc2282 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -625,7 +625,9 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> } while (int_status && time_is_after_jiffies(txrx_timeout));
>
> /* Enable interrupt */
> - if (bdev->func->irq_handler)
> + if (bdev->func->irq_handler &&
> + test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state) &&
> + !test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
> sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
>
> sdio_release_host(bdev->func);
> @@ -741,6 +743,8 @@ static int btmtksdio_close(struct hci_dev *hdev)
> if (!test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state))
> return 0;
>
> + clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
> +
> sdio_claim_host(bdev->func);
>
> /* Disable interrupt */
> @@ -748,11 +752,12 @@ static int btmtksdio_close(struct hci_dev *hdev)
>
> sdio_release_irq(bdev->func);
>
> + sdio_release_host(bdev->func);
> cancel_work_sync(&bdev->txrx_work);
> + sdio_claim_host(bdev->func);
>
> btmtksdio_fw_pmctrl(bdev);
>
> - clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
> sdio_disable_func(bdev->func);
>
> sdio_release_host(bdev->func);
> @@ -1295,7 +1300,10 @@ static void btmtksdio_reset(struct hci_dev *hdev)
>
> sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
> skb_queue_purge(&bdev->txq);
> +
> + sdio_release_host(bdev->func);
> cancel_work_sync(&bdev->txrx_work);
> + sdio_claim_host(bdev->func);
>
> gpiod_set_value_cansleep(bdev->reset, 1);
> msleep(100);
The patch looks good to me. Inspired by your patch,
do you think should we add another patch to keep txrx_work out of the
reset window by rejecting TX during reset,
ignoring reset-time interrupts, and making queued workers exit early?
Some code like:
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -567,6 +567,8 @@ static void btmtksdio_txrx_work(struct work_struct *work)
pm_runtime_get_sync(bdev->dev);
sdio_claim_host(bdev->func);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ goto out;
/* Disable interrupt */
sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
@@ -628,6 +630,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
!test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
+out:
sdio_release_host(bdev->func);
pm_runtime_put_autosuspend(bdev->dev);
@@ -646,6 +649,9 @@ static void btmtksdio_interrupt(struct sdio_func *func)
/* Disable interrupt */
sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ return;
+
schedule_work(&bdev->txrx_work);
}
@@ -1250,6 +1256,9 @@ static int btmtksdio_send_frame(struct hci_dev
*hdev, struct sk_buff *skb)
{
struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
+ if (test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
+ return -EBUSY;
+
switch (hci_skb_pkt_type(skb)) {
case HCI_COMMAND_PKT:
hdev->stat.cmd_tx++;
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
>
^ permalink raw reply
* [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Wentao Liang @ 2026-06-17 1:41 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd
Cc: bmasney, linux-arm-kernel, linux-clk, linux-kernel, Wentao Liang
The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
reference to the parent clock for each CPU cluster, but it never
releases it with clk_put(). The returned clk is used only to read
the parent's name via __clk_get_name(), and the reference is leaked
on every successful cluster initialization as well as on the error
path when devm_clk_hw_register() fails.
Rather than adding clk_put() calls, replace the of_clk_get() +
__clk_get_name() pattern with of_clk_get_parent_name(), which is
the intended API for this use case and handles the reference
counting internally. This matches the pattern already used by the
sibling drivers clk-cpu.c and clk-corediv.c.
Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
v3: Replace incorrect Fixes tag.
v2: Replace of_clk_get() + __clk_get_name() with of_clk_get_parent_name()
as suggested by Brian Masney, instead of adding clk_put() calls.
Also correct the Fixes: tag to point to the original commit that
introduced the leak.
---
drivers/clk/mvebu/ap-cpu-clk.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
index a8175908e353..1cf63c7a0bc3 100644
--- a/drivers/clk/mvebu/ap-cpu-clk.c
+++ b/drivers/clk/mvebu/ap-cpu-clk.c
@@ -288,7 +288,6 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
char *clk_name = "cpu-cluster-0";
struct clk_init_data init;
const char *parent_name;
- struct clk *parent;
u64 cpu;
cpu = of_get_cpu_hwid(dn, 0);
@@ -304,13 +303,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
if (ap_cpu_data->hws[cluster_index])
continue;
- parent = of_clk_get(np, cluster_index);
- if (IS_ERR(parent)) {
- dev_err(dev, "Could not get the clock parent\n");
+ parent_name = of_clk_get_parent_name(np, cluster_index);
+ if (!parent_name) {
+ dev_err(dev, "Could not get the clock parent name\n");
of_node_put(dn);
return -EINVAL;
}
- parent_name = __clk_get_name(parent);
clk_name[12] += cluster_index;
ap_cpu_clk[cluster_index].clk_name =
ap_cp_unique_name(dev, np->parent, clk_name);
@@ -328,11 +326,9 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
ret = devm_clk_hw_register(dev, &ap_cpu_clk[cluster_index].hw);
if (ret) {
of_node_put(dn);
- clk_put(parent);
return ret;
}
ap_cpu_data->hws[cluster_index] = &ap_cpu_clk[cluster_index].hw;
- clk_put(parent);
}
ap_cpu_data->num = cluster_index + 1;
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for the MT8127 based Amazon ford tablet.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..5ddc79689df9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -124,6 +124,10 @@ properties:
- enum:
- mediatek,mt8127-moose
- const: mediatek,mt8127
+ - items:
+ - enum:
+ - amazon,ford
+ - const: mediatek,mt8127
- items:
- enum:
- mediatek,mt8135-evbp1
--
2.54.0
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
It can currently boot into initramfs with a working UART and
Simple Framebuffer using already initialized panel by the bootloader.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
index 37c4cded0eae..a610bc75c7d9 100644
--- a/arch/arm/boot/dts/mediatek/Makefile
+++ b/arch/arm/boot/dts/mediatek/Makefile
@@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-rfb-emmc.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+ mt8127-amazon-ford.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
new file mode 100644
index 000000000000..21bdab0e43f8
--- /dev/null
+++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+#include "mt8127.dtsi"
+
+/ {
+ model = "MediaTek MT8127 Amazon Ford";
+ compatible = "amazon,ford", "mediatek,mt8127";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+
+ framebuffer0: framebuffer@b7a00000 {
+ compatible = "simple-framebuffer";
+ memory-region = <&framebuffer_reserved>;
+ width = <1024>;
+ height = <600>;
+ stride = <(1024 * 2)>;
+ format = "r5g6b5";
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+
+ reserved-memory {
+ framebuffer_reserved: framebuffer@b7a00000 {
+ reg = <0 0xb7a00000 0 0x1000000>;
+ no-map;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&watchdog {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH 0/5] ARM: Basic support for Amazon ford tablet (MT8127)
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
This series of patches adds basic support for MT8127 SoC based Amazon ford
tablet and fixes a small indentation error in the dtsi file.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Zakariya Hadrami (5):
ARM: dts: mediatek: mt8127: Fix indentation error
ARM: dts: mediatek: mt8127: Add watchdog support
ARM: dts: mediatek: Add basic support for Amazon ford board
dt-bindings: arm: mediatek: Add MT8127 Amazon ford
dt-bindings: watchdog: mediatek: Add MT8127
.../devicetree/bindings/arm/mediatek.yaml | 4 ++
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 ++++++++++++++++++++++
arch/arm/boot/dts/mediatek/mt8127.dtsi | 9 ++++-
5 files changed, 60 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260616-mt8127-amazon-ford-basic-1509d7052f7e
Best regards,
--
Zakariya Hadrami <zkh1@proton.me>
^ permalink raw reply
* [PATCH 5/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
one.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..e6e4546da0aa 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -40,6 +40,7 @@ properties:
- mediatek,mt7622-wdt
- mediatek,mt7623-wdt
- mediatek,mt7629-wdt
+ - mediatek,mt8127-wdt
- mediatek,mt8173-wdt
- mediatek,mt8188-wdt
- mediatek,mt8189-wdt
--
2.54.0
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: mediatek: mt8127: Add watchdog support
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 2:20 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add watchdog node and disable it by default as it was not present
initially.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index bd61ec7e70c0..1855dda42710 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -159,5 +159,12 @@ uart3: serial@11005000 {
clocks = <&uart_clk>;
status = "disabled";
};
+
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8127-wdt","mediatek,mt6589-wdt";
+ reg = <0 0x10007000 0 0x100>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ status = "disabled";
+ };
};
};
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox