* [PATCH RFC v4 05/12] clk: zte: Add zx PLL support infrastructure
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>
I am guessing how much of this is reusable among other zx chips or even
differently named ZTE platforms (if there are any). From reading the old
zx2967 code, I think the PLL code would be reusable there, maybe with
platform specific bitmasks but otherwise the same logic.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/pll-zx.c | 460 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 459 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
index c0475d5441fb..f077b6b56841 100644
--- a/drivers/clk/zte/pll-zx.c
+++ b/drivers/clk/zte/pll-zx.c
@@ -11,9 +11,467 @@
#include "clk-zx.h"
+/* This code has only been tested with zx297520v3 PLLs, but from reading the zx296718 clock code it
+ * looks like PLL registers are similar. ZTE's sources explain the PLL register contents only in a
+ * .cmm file (A Lauterback TRACE32 script) and some unused headers in their U-Boot code dump, which
+ * may not be accurate. When calculating the frequencies from the default PLL configuration the
+ * results match the fixed rate clocks from their clock driver.
+ *
+ * The 26mhz and 32khz clocks can be easily observed with the timers. The 104mhz output can be
+ * observed through the UART. One 122.88 PLL can be observed through the TDM device. All others can
+ * only be indirectly infered, e.g. by comparing CPU speed or SDIO transfer rate between the fixed
+ * 26 MHz oscillator and the provided PLL frequency.
+ *
+ * The formula to calculate the clock is ((ref / refdiv) * fbdiv) / postdiv1 / postdiv2. The masks
+ * are given below. There are a few control flags:
+ *
+ * Bit 31: Disables the PLL, but passes the reference through unmodified. If POSTDIV_OUT_DISABLE
+ * still matters is different between PLLs.
+ * Bit 30: Returns if the PLL is locked
+ * Bit 29: Not named in ZTE's code, but can be set. There is no obvious impact. Lock times are
+ * unchanged, so it doesn't influence or bypass lock detection. It doesn't raise any IRQs or
+ * influence GPIOs.
+ * Bit 27: Given its name it likely disables the Delta-Sigma Modulator, if one exists at all. The
+ * boot ROM sets it on every PLL. Unsetting it marginally decreases the time it takes to
+ * lock to the reference clock (from ~400us to ~300us). Regardless of this bit I could not
+ * make the supposed fractional part in register 2 work.
+ * Bit 24: Bypasses the VCO, but still applies refdiv and postdiv. Doesn't matter if PLL_DISABLE=1.
+ */
+
+#define ZX29_PLL_DISABLE BIT(31)
+#define ZX29_PLL_LOCKED BIT(30)
+#define ZX29_PLL_LOCK_FILTER BIT(29)
+#define ZX29_PLL_DSM_DISABLE BIT(27)
+#define ZX29_PLL_PARENT_MASK GENMASK(26, 25)
+#define ZX29_PLL_PARENT_SHIFT 25
+#define ZX29_PLL_BYPASS BIT(24)
+#define ZX29_PLL_REFDIV_MASK GENMASK(23, 18)
+#define ZX29_PLL_REFDIV_SHIFT 18
+#define ZX29_PLL_FBDIV_MASK GENMASK(17, 6)
+#define ZX29_PLL_FBDIV_SHIFT 6
+#define ZX29_PLL_POSTDIV1_MASK GENMASK(5, 3)
+#define ZX29_PLL_POSTDIV1_SHIFT 3
+#define ZX29_PLL_POSTDIV2_MASK GENMASK(2, 0)
+#define ZX29_PLL_POSTDIV2_SHIFT 0
+
+/* The second register is supposed to have another 24 bit value that gets added to fbdiv but it is
+ * always 0 in the preconfigured values. I could not observe any effect from setting it to something
+ * other than 0, regardless of the DSM disable bit. It is possible that it is only supported by
+ * dpll, which is a possible parent for i2s.
+ *
+ * Bits 28:25 contain more flags:
+ *
+ * Bit 27: Setting ZX29_PLL_DACAP slows down the lock time and obivates the speed gained from
+ * !DSM_DISABLE. No other effect observed.
+ *
+ * Bit 26: ZX29_PLL_4PHASE_OUT_DISABLE is set on some PLLs on boot but not on others. It is set on
+ * boot on mpll and upll, but not gpll, dpll or unknownpll. I am not sure what it does
+ * either. The SDIO devices break if they are fed from gpll with this flag set, but they
+ * work ok if they are fed from mpll without this flag set.
+ *
+ * Bit 25: ZX29_PLL_POSTDIV_OUT_DISABLE seems to disable the PLL output entirely. Whether it is
+ * bypassed by PLL_DISABLE differs between PLLs. gpll still produces an output clock if
+ * PLL_DISABLE = 1 and POSTDIV_DISABLE = 1, but produces no output if PLL_DISABLE = 0 and
+ * POSTDIV_DISABLE = 1. The dpll feeder ("unknownpll") at 0x100 produces no output clock
+ * if both PLL_DISABLE and POSTDIV_DISABLE are set to 1.
+ *
+ * Bit 24: ZX29_PLL_VCO_OUT_DISABLE probably disables the output of the VCO clock without
+ * post-VCO-dividers, but the raw VCO output is not a possible parent of any consumer clock,
+ * so I could not confirm this. It does not disable the VCO entirely - that's what
+ * PLL_DISABLE does.
+ *
+ * A spinlock should not be needed. PLLs don't share their registers with anything else and the
+ * global prepare mutex and enable spinlock should be enough. Beware of conflicts in reg2 between
+ * POSTDIV_OUT_DISABLE and the fractional value in case you find out how fractional dividers work
+ * and add support for them.
+ */
+#define ZX29_PLL_REG2_OFFSET 4
+#define ZX29_PLL_DACAP BIT(27)
+#define ZX29_PLL_4PHASE_OUT_DISABLE BIT(26)
+#define ZX29_PLL_POSTDIV_OUT_DISABLE BIT(25)
+#define ZX29_PLL_VCO_OUT_DISABLE BIT(24)
+
+/* The VCO's frequency range is limited. The stock settings run the VCO between 960 and 1248 MHz.
+ * Ad-hoc testing with gpll suggests that at least this PLL remains stable down to about 7 MHz and
+ * up to 2 GHz and produces a clock that can be used by the SDIO controller. Attempting to run the
+ * mpll VCO at 624 MHz and setting postdiv1 = postdiv2 = 1 - which should result in the same output
+ * frequency - or running it at 1872 MHz with an effective post divider of 3 crashes the CPU. Most
+ * likely the PLLs become unstable outside their core range and the SDIO controller is much more
+ * forgiving than CPU and DRAM are.
+ */
+#define ZX29_PLL_VCO_MAX_FREQ (1300*HZ_PER_MHZ)
+#define ZX29_PLL_VCO_MIN_FREQ (900*HZ_PER_MHZ)
+
+struct zx29_clk_pll {
+ struct clk_hw hw;
+ struct device *dev;
+ struct regmap *map;
+ unsigned long init_rate;
+ u16 reg;
+};
+
+static inline struct zx29_clk_pll *to_zx29_clk_pll(struct clk_hw *hw)
+{
+ return container_of(hw, struct zx29_clk_pll, hw);
+}
+
+static int zx29_pll_is_prepared(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res;
+
+ res = regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+ if (res < 0)
+ return res;
+
+ return !res;
+}
+
+static int zx29_pll_prepare(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+ if (res < 0)
+ return res;
+
+ /* Lock duration is usually between 300us to 500us */
+ res = regmap_read_poll_timeout(pll->map, pll->reg, val, val & ZX29_PLL_LOCKED, 50, 2000);
+ dev_dbg(pll->dev, "%s: Enable result %u val 0x%08x\n", clk_hw_get_name(&pll->hw), res, val);
+ return res;
+}
+
+static void zx29_pll_unprepare(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ regmap_set_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+}
+
+static int zx29_pll_is_enabled(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res;
+
+ res = regmap_test_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+ if (res < 0)
+ return res;
+
+ return !res;
+}
+
+static int zx29_pll_enable(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ return regmap_clear_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+}
+
+static void zx29_pll_disable(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ regmap_set_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+}
+
+static unsigned long zx29_pll_get_rate(const struct zx29_clk_pll *pll, unsigned long parent_rate,
+ u32 setting)
+{
+ unsigned long refdiv, fbdiv, postdiv1, postdiv2, freq;
+ const char *name = clk_hw_get_name(&pll->hw);
+ u64 vco;
+
+ refdiv = (setting & ZX29_PLL_REFDIV_MASK) >> ZX29_PLL_REFDIV_SHIFT;
+ fbdiv = (setting & ZX29_PLL_FBDIV_MASK) >> ZX29_PLL_FBDIV_SHIFT;
+ postdiv1 = (setting & ZX29_PLL_POSTDIV1_MASK) >> ZX29_PLL_POSTDIV1_SHIFT;
+ postdiv2 = (setting & ZX29_PLL_POSTDIV2_MASK) >> ZX29_PLL_POSTDIV2_SHIFT;
+ dev_dbg(pll->dev, "%s: reference clock %lu HZ, PLL setting 0x%08x\n",
+ name, parent_rate, setting);
+
+ if (!refdiv || !postdiv1 || !postdiv2) {
+ dev_err(pll->dev, "%s: divide by zero (%lu, %lu, %lu)\n", name, refdiv, postdiv1,
+ postdiv2);
+ return 0;
+ }
+
+ vco = div_u64((u64)parent_rate * fbdiv, refdiv);
+ freq = div_u64(div_u64(vco, postdiv1), postdiv2);
+ dev_dbg(pll->dev, "%s: refdiv %lu fbdiv %lu\n", name, refdiv, fbdiv);
+ dev_dbg(pll->dev, "%s: postdiv1 %lu postdiv2 %lu\n", name, postdiv1, postdiv2);
+
+ dev_dbg(pll->dev, "%s: %lu MHZ\n", name, freq / HZ_PER_MHZ);
+
+ return freq;
+}
+
+static unsigned long zx29_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0)
+ return res;
+
+ return zx29_pll_get_rate(pll, parent_rate, val);
+}
+
+static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
+ unsigned long rate)
+{
+ const unsigned int postdiv1_max = (1 << hweight32(ZX29_PLL_POSTDIV1_MASK)) - 1;
+ const unsigned int postdiv2_max = (1 << hweight32(ZX29_PLL_POSTDIV2_MASK)) - 1;
+ unsigned long fbdiv, refdiv, best_fbdiv = 0, best_refdiv = 0;
+ u32 postdiv1 = 0, postdiv2 = 0, i, j, setting;
+ const char *name = clk_hw_get_name(&pll->hw);
+ long best = LONG_MAX;
+
+ /* This code produces the same VCO settings that the boot loader and stock firmware use for
+ * the standard frequencies. It has seen only very little manual testing beyond that.
+ *
+ * The goal is to find a VCO setting that gets us as close as possible to the desired output
+ * rate, while being within the VCO's operating limits and achievable with the input value
+ * range. It is iterating over possible post-VCO diver values (1-7)*(1-7) to look for valid
+ * VCO target frequencies and then looks for refdiv and fbdiv values to achieve the VCO
+ * frequency from the reference frequency.
+ */
+ for (j = 1; j <= postdiv2_max; j++) {
+ for (i = 1; i <= postdiv1_max; i++) {
+ u64 vco = (u64)rate * i * j;
+ long out;
+
+ if (vco > ZX29_PLL_VCO_MAX_FREQ || vco < ZX29_PLL_VCO_MIN_FREQ)
+ continue;
+
+ rational_best_approximation(vco, parent_rate,
+ (1 << hweight32(ZX29_PLL_FBDIV_MASK)) - 1,
+ (1 << hweight32(ZX29_PLL_REFDIV_MASK)) - 1,
+ &fbdiv, &refdiv);
+ setting = fbdiv << ZX29_PLL_FBDIV_SHIFT;
+ setting |= refdiv << ZX29_PLL_REFDIV_SHIFT;
+ setting |= i << ZX29_PLL_POSTDIV1_SHIFT;
+ setting |= j << ZX29_PLL_POSTDIV2_SHIFT;
+ out = zx29_pll_get_rate(pll, parent_rate, setting);
+
+ if (abs(out - rate) > best)
+ continue;
+
+ if (abs(out - rate) < best) {
+ postdiv1 = i;
+ postdiv2 = j;
+ best_fbdiv = fbdiv;
+ best_refdiv = refdiv;
+ best = abs(out - rate);
+
+ if (!best)
+ goto search_done;
+ }
+ }
+ }
+search_done:
+
+ if (!postdiv1) {
+ dev_err(pll->dev, "Did not find a setting for %lu Hz, parent %lu Hz\n",
+ rate, parent_rate);
+ return 0;
+ }
+
+ dev_dbg(pll->dev, "%s: parent rate %lu\n", name, parent_rate);
+ dev_dbg(pll->dev, "%s: found VCO dividers %u and %u\n", name, postdiv1, postdiv2);
+ dev_dbg(pll->dev, "%s: VCO target rate %lu\n", name, rate * postdiv1 * postdiv2);
+
+ dev_dbg(pll->dev, "%s: Got fbdiv = %lu refdiv = %lu\n", name, best_fbdiv, best_refdiv);
+
+ setting = best_fbdiv << ZX29_PLL_FBDIV_SHIFT;
+ setting |= best_refdiv << ZX29_PLL_REFDIV_SHIFT;
+ setting |= postdiv1 << ZX29_PLL_POSTDIV1_SHIFT;
+ setting |= postdiv2 << ZX29_PLL_POSTDIV2_SHIFT;
+ dev_dbg(pll->dev, "%s: Final setting 0x%08x\n", name, setting);
+
+ return setting;
+}
+
+static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ unsigned long new_rate, parent_rate = clk_hw_get_rate(clk_hw_get_parent(&pll->hw));
+ u32 setting;
+
+ setting = zx29_pll_calc_values(pll, parent_rate, req->rate);
+ if (!setting)
+ return -EINVAL;
+
+ new_rate = zx29_pll_get_rate(pll, parent_rate, setting);
+ if (new_rate != req->rate) {
+ dev_warn(pll->dev, "Did not find an exact match. Want %lu, got %lu\n",
+ req->rate, new_rate);
+ req->rate = new_rate;
+ }
+
+ return 0;
+}
+
+static int zx29_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res = -EINVAL;
+ u32 setting;
+
+ setting = zx29_pll_calc_values(pll, parent_rate, rate);
+ if (zx29_pll_get_rate(pll, parent_rate, setting) == rate) {
+ res = regmap_update_bits(pll->map, pll->reg, 0x00ffffff, setting);
+ dev_info(pll->dev, "%s: Setting rate: 0x%08x\n", clk_hw_get_name(hw), setting);
+ }
+
+ return res;
+}
+
+static u8 zx29_pll_get_parent(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0)
+ return 0xff;
+
+ val = (val & ZX29_PLL_PARENT_MASK) >> ZX29_PLL_PARENT_SHIFT;
+ dev_dbg(pll->dev, "%s: Parent 0x%x\n", clk_hw_get_name(hw), val);
+
+ return val;
+}
+
+static int zx29_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 idx_shift = index << ZX29_PLL_PARENT_SHIFT;
+ int res;
+ u32 val;
+
+ res = regmap_update_bits(pll->map, pll->reg, ZX29_PLL_PARENT_MASK, idx_shift);
+ if (res < 0)
+ return res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0)
+ return res;
+
+ if ((val & ZX29_PLL_PARENT_MASK) != idx_shift) {
+ dev_err(pll->dev, "Hardware rejected PLL parent %u\n", index);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int zx29_pll_init(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ const char *name = clk_hw_get_name(hw);
+ int res;
+
+ dev_dbg(pll->dev, "%s: initializing\n", name);
+
+ /* Remove the bypass flag so we don't have to bother with it in enable/disable. I have
+ * never seen it set by the earlier boot stages anyhow.
+ */
+ res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_BYPASS);
+ if (res < 0)
+ return res;
+
+ if (regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE) > 0) {
+ if (pll->init_rate) {
+ dev_dbg(pll->dev, "%s: Setting to %lu Hz\n", name, pll->init_rate);
+ res = clk_set_rate(pll->hw.clk, pll->init_rate);
+ if (res) {
+ dev_err(pll->dev, "%s: Failed to set rate.\n", name);
+ return res;
+ }
+ }
+
+ /* Set ZX29_PLL_POSTDIV_OUT_DISABLE for PLLs that have ZX29_PLL_DISABLE for
+ * consistency with .enable and .prepare. This ensures that .prepare doesn't
+ * inadvertedly enable PLLs without .enable being called.
+ */
+ res = regmap_set_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+ if (res < 0)
+ return res;
+ }
+
+ return 0;
+}
+
+const struct clk_ops zx29_pll_ops = {
+ .init = zx29_pll_init,
+ .is_prepared = zx29_pll_is_prepared,
+ .prepare = zx29_pll_prepare,
+ .unprepare = zx29_pll_unprepare,
+ .is_enabled = zx29_pll_is_enabled,
+ .enable = zx29_pll_enable,
+ .disable = zx29_pll_disable,
+ .recalc_rate = zx29_pll_recalc_rate,
+ .determine_rate = zx29_pll_determine_rate,
+ .get_parent = zx29_pll_get_parent,
+ .set_parent = zx29_pll_set_parent,
+ .set_rate = zx29_pll_set_rate,
+};
+
int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
const struct zx_pll_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zx29_clk_pll *pll;
+ unsigned int i, f;
+ struct clk_hw *hw;
+ char plldiv[32];
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zx29_pll_ops;
+ init.parent_names = desc[i].parents;
+ init.num_parents = desc[i].num_parents;
+ pll->hw.init = &init;
+ pll->map = regmap;
+ pll->reg = desc[i].reg;
+ pll->init_rate = desc[i].rate;
+
+ res = devm_clk_hw_register(dev, &pll->hw);
+ if (res)
+ return res;
+ if (desc[i].id && desc[i].postdivs && desc[i].postdivs[0] == 1)
+ clocks->hws[desc[i].id] = &pll->hw;
+
+ for (f = 0; f < desc[i].num_postdivs; ++f) {
+ if (desc[i].postdivs[f] == 1)
+ continue;
+
+ snprintf(plldiv, sizeof(plldiv), "%s_d%u", desc[i].name,
+ desc[i].postdivs[f]);
+ hw = devm_clk_hw_register_fixed_factor(dev, plldiv, desc[i].name,
+ 0, 1, desc[i].postdivs[f]);
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ dev_dbg(pll->dev, "%s: %lu hz\n", clk_hw_get_name(hw), clk_hw_get_rate(hw));
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id + f] = hw;
+ }
+ }
+
+ return 0;
}
--
2.53.0
^ permalink raw reply related
* [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
* Re: [PATCH 5/13] ASoC: qcom: Add QAIF shared data structures and variant interface
From: Srinivas Kandagatla @ 2026-06-16 20:28 UTC (permalink / raw)
To: Harendra Gautam, Srinivas Kandagatla
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sound, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260605103739.3557573-6-harendra.gautam@oss.qualcomm.com>
On 6/5/26 11:37 AM, Harendra Gautam wrote:
>
> + struct reg_field cif_rddma_shram_wm;
> + struct reg_field cif_rddma_active_ch_en;
> + struct reg_field cif_rddma_fs_sel;
> + struct reg_field cif_rddma_fs_delay;
> + struct reg_field cif_rddma_fs_out_gate;
> + struct reg_field cif_rddma_intf_dyncclk;
> + struct reg_field cif_rddma_en_16bit_unpack;
> +
Why do we need to use reg_field?, currently this patchset only supports
one SoC. reg_field makes sense only when there is change in bit
positions across SoCs and if we want to leverage from existing driver.
--srini
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-16 20:30 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n26H2t=pi_C+t8jP_cWXGSa5pk=1cpTZtkBh3=RQsUk2g@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:45:25AM +0300, Svyatoslav Ryhel wrote:
>
> I have tested your code on my P895 and it works perfectly fine. Should
> I resend with these changes or you can integrate them while picking
> patchset?
I think there was an update requested by Rob for the bindings?
>
> Thank you for your suggestions and efforts!
Thank you for your patience.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: sashiko-bot @ 2026-06-16 20:32 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-1-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added file pattern in MAINTAINERS does not match the created dt-bindings file path.
--
commit ab1e6a61e65e8f9fc9215bf930c7a45ed74a798a
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
This commit introduces the device tree bindings and clock definitions for
the ZTE zx297520v3 SoC top clock and reset controller. It details the
hardware separation of clocks, PLLs, and documents the available clocks.
[ ... ]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 069b4aa6b523c..96a5f3bcfc06a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3869,8 +3869,10 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Odd fixes
> F: Documentation/arch/arm/zte/
> F: Documentation/devicetree/bindings/arm/zte.yaml
> +F: Documentation/devicetree/zte,zx297520v3-*
[Severity: Low]
Does this MAINTAINERS pattern accurately match the new binding?
The newly added file pattern is missing the bindings/clock/ directory
components, so it will not match the created file at
Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml.
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> +F: include/dt-bindings/clock/zte,zx297520v3-clk.h
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
From: sashiko-bot @ 2026-06-16 20:34 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-3-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree example contains undefined phandle references (`&osc26m`, `&osc32k`, `&topclk`), which will cause `dtc` and `make dt_binding_check` to fail with a compilation error.
--
commit 58efa7efa64df52a18f1832747a61ff0688b9833
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
This commit adds device tree bindings for the ZTE zx297520v3 SoC LSP
clock and reset controller. It introduces the YAML schema documenting
the required properties and provides the corresponding clock and reset
macros in a new header file.
> diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml
> new file mode 100644
> index 0000000000000..096295edb6e26
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + matrixclk: clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
[Severity: Low]
Will this cause a dtc compilation failure during make dt_binding_check?
The phandles &osc26m, &osc32k, and &topclk do not appear to be defined
as nodes anywhere within this example block. Does this example need dummy
nodes defined for these clocks so the labels can resolve and the example
can compile successfully?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH RFC v4 08/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks
From: sashiko-bot @ 2026-06-16 20:37 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260616-zx29clk-v4-8-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect case used for parent clock name "AHB_wclk" for the "gmac_ahb" gate.
--
commit cf4f2a13a47e51fe8fab640925ef1ac3aa154e9d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 matrix clocks
This commit introduces the clock driver for the ZTE zx297520v3 matrix
clocks, covering high-speed devices like CPU, DMA, RAM, SDIO, and Ethernet.
It maps out the multiplexers and gate clocks consumed by these devices
based on the available PLL inputs.
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> index 50263bca6e087..d90aadf180269 100644
> --- a/drivers/clk/zte/clk-zx297520v3.c
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> +static const struct zx_gate_desc zx297520v3_matrix_gates[] = {
[ ... ]
> + 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),
[Severity: Medium]
Will this string mismatch result in gmac_ahb becoming an orphaned clock?
The Common Clock Framework resolves clock parents using exact case-sensitive
string matching. If the actual clock registered in zx297520v3_top_gates
is named "ahb_wclk", using "AHB_wclk" here will fail to link.
Even if an immediate system crash is averted because the parent clock is
marked with CLK_IS_CRITICAL and permanently enabled by the framework,
does this incorrect parent name break the clock tree topology and tracking
for the GMAC driver?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH RFC v4 11/12] ARM: dts: zte: Declare zx297520v3 clock device nodes
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260616-zx29clk-v4-11-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `interrupts` property for the `uart2` device node was unintentionally deleted during the clock updates.
--
commit 59fdf05791fcf663705de912314c4a81bdabedae
Author: Stefan Dösinger <stefandoesinger@gmail.com>
ARM: dts: zte: Declare zx297520v3 clock device nodes
This commit introduces clock device nodes for zx297520v3, wires up the UART
clocks and resets, and replaces the placeholder uartclk node.
> diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
> index a16c30a164bb9..a2b6909e7434d 100644
> --- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
> +++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
[ ... ]
> @@ -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>;
[Severity: High]
Was the interrupts property unintentionally deleted here during the clock
updates for the uart2 node?
The PL011 UART driver requires the interrupts property per its device tree
schema binding to handle rx/tx operations. Removing this property breaks
device tree validation and prevents hardware interrupt assignment for uart2.
This could cause the driver to fail during probing or completely break
interrupt-driven serial communication, rendering uart2 unusable.
> clock-names = "uartclk", "apb_pclk";
> + resets = <&lspclk ZX297520V3_UART2_RESET>;
> status = "disabled";
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=11
^ permalink raw reply
* Re: [PATCH RFC v4 04/12] clk: zte: Add Clock registration infrastructure.
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260616-zx29clk-v4-4-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Use-After-Free Vulnerability due to tying `struct auxiliary_device` memory lifetime to devres.
- [High] Invalid pointer dereference due to incorrect error checking of `device_node_to_regmap()`.
--
commit d5b040629c9146bc0aaf0162d247a5520ba7ab60
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add Clock registration infrastructure.
The next patches will implement the regmap clocks and PLL driver. The
actual hardware specific clock listing will live in a separate module.
> diff --git a/drivers/clk/zte/clk-zx.c b/drivers/clk/zte/clk-zx.c
> new file mode 100644
> index 0000000000000..6e21c4a82a46c
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx.c
> @@ -0,0 +1,157 @@
[ ... ]
> +static void zx_adev_release(struct device *dev)
> +{
> + dev_info(dev, "Aux device released.\n");
> +}
[Severity: High]
Does this release callback need to free the memory for the auxiliary device?
If struct auxiliary_device is allocated with devres, its memory is freed
when devres triggers during unbind. This might happen before this callback
is invoked if other subsystems hold a reference to the device, potentially
causing a use-after-free.
> +
> +static void zx_adev_unregister(void *data)
> +{
> + struct auxiliary_device *adev = data;
> +
> + auxiliary_device_delete(adev);
> + auxiliary_device_uninit(adev);
> +}
[Severity: High]
While this devres action decreases the device reference count, does devres
unconditionally free the adev memory right after this action returns? This
could lead to a use-after-free if lingering references are held.
> +
> +int zx_clk_probe(struct platform_device *pdev)
> +{
> + unsigned int public_clk_count = 1, highest_id = 0;
> + struct clk_hw_onecell_data *clocks;
> + struct device *dev = &pdev->dev;
> + const struct zx_clk_data *data;
> + struct auxiliary_device *adev;
> + struct regmap *map;
> + struct clk *clk;
> + unsigned int i;
> + int res;
> +
> + data = device_get_match_data(dev);
> + if (!data)
> + return -EINVAL;
> +
> + map = device_node_to_regmap(dev->of_node);
> + if (!map)
[Severity: High]
Since device_node_to_regmap() returns an ERR_PTR on failure rather than
NULL, should this check use IS_ERR(map)? Treating an error pointer as a
valid pointer could lead to a kernel panic when it is later dereferenced by
the clock framework.
> + return -EINVAL;
> +
[ ... ]
> + res = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clocks);
> + if (res)
> + return res;
> +
> + adev = devm_kzalloc(dev, sizeof(*adev), GFP_KERNEL);
[Severity: High]
Does allocating adev with devm_kzalloc() improperly tie the lifetime of
the embedded struct device to devres?
Since struct device is reference counted, could an external reference
outlive the devres unbind phase, resulting in a use-after-free when
zx_adev_release() is finally called on the freed memory?
> + if (!adev)
> + return -ENOMEM;
> +
> + adev->name = data->reset_auxdev_name;
> + adev->dev.parent = dev;
> + adev->dev.release = zx_adev_release;
> + adev->dev.of_node = dev->of_node;
> +
> + res = auxiliary_device_init(adev);
> + if (res)
> + return dev_err_probe(dev, res, "Failed to init aux dev %s\n", adev->name);
> +
> + res = auxiliary_device_add(adev);
> + if (res) {
> + auxiliary_device_uninit(adev);
> + return dev_err_probe(dev, res, "Failed to add aux dev %s\n", adev->name);
> + }
> +
> + return devm_add_action_or_reset(dev, zx_adev_unregister, adev);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH RFC v4 09/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-9-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The static array `tdm_lsp_sel` is defined but never used, causing an unused-const-variable compiler warning.
- [Low] Multiple internal data structures contain a typo in their name: `zx297529v3_` instead of `zx297520v3_`.
--
commit 62ece0243f8a2453a83a724365246a3a8447995d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 LSP clocks
This commit introduces a clock driver for the "LSP" (low speed peripherals)
block of the ZTE ZX297520v3 SoC. It adds support for various peripherals
including UART, I2C, SPI, timers, and I2S.
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> index d90aadf180269..26b05f2bf97ae 100644
> --- a/drivers/clk/zte/clk-zx297520v3.c
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> +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",
> +};
[Severity: Low]
Is this array intended to be used somewhere? It appears to be defined but
never referenced in the file, which might trigger a -Wunused-const-variable
compiler warning.
> +
> +static const char * const spi_lsp_sel[] = {
> + "lsp_osc26m",
[ ... ]
> + 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"
> +};
[Severity: Low]
This isn't a bug, but should these arrays be named zx297520v3_lsp_inputs
instead of zx297529v3_lsp_inputs? It looks like there's a typo in the
numbering (9 instead of 0) compared to the other structures and the SoC
device name.
> +
> +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),
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH RFC v4 06/12] clk: zte: Add regmap based clocks
From: sashiko-bot @ 2026-06-16 20:39 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-6-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] In `zte_clk_regmap_gate_is_enabled`, the result of `regmap_read` is ignored and the read value is not properly masked, leading to uninitialized memory use and incorrect clock state reporting.
Pre-existing issues:
- [High] Allocating `struct auxiliary_device` with `devm_kzalloc` causes a Use-After-Free when the parent device is removed while external references still exist.
--
commit 4134682feec28075c68eddb683db94b9fb9b761a
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add regmap based clocks
This commit adds regmap based clocks for ZTE, simplifying the implementation
based on the meson clock regmap code.
> diff --git a/drivers/clk/zte/clk-regmap.c b/drivers/clk/zte/clk-regmap.c
> index 7908f1562f639..d9459417d17dd 100644
> --- a/drivers/clk/zte/clk-regmap.c
> +++ b/drivers/clk/zte/clk-regmap.c
[ ... ]
> +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;
> +}
[Severity: High]
Does this code properly mask the specific gate bit? Since clock gates commonly
share registers, returning !!val might erroneously report this specific gate
as enabled whenever any other bit in the register is active, rather than using
BIT(clk->shift) to evaluate the correct bit.
Also, should the return value of regmap_read() be checked here? If the read
fails, val remains uninitialized, which could lead to evaluating stack
garbage.
[ ... ]
In drivers/clk/zte/clk-zx.c:
[Severity: High]
This is a pre-existing issue, but does allocating the auxiliary_device with
devm_kzalloc() in zx_clk_probe() create a use-after-free risk?
If the parent device is unbound, devres will automatically free the memory
for the auxiliary_device. However, if external references to the embedded
device still exist, the memory will be freed while it is still in use.
When the final reference is eventually dropped, the kernel will attempt to
call the release callback on the freed memory:
zx_adev_release() {
dev_info(dev, "Aux device released.\n");
}
Should the structure be allocated with kzalloc() instead, and explicitly
freed inside the release callback?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: hamoa: Fix xbl_tmp_buffer_mem size
From: Hans de Goede @ 2026-06-16 20:40 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree
In-Reply-To: <21a97c4b-293f-435c-91fe-ca7394b5a2b0@oss.qualcomm.com>
Hi konrad,
On 16-Jun-26 1:04 PM, Konrad Dybcio wrote:
> On 5/25/26 2:46 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 25-May-26 14:29, Konrad Dybcio wrote:
>>> On 5/25/26 1:47 PM, Hans de Goede wrote:
>>>> The EFI memtable (shown when booting with efi=debug) shows that the
>>>> xbl_tmp_buffer_mem region size is 0x1c0000 bytes large not 0xc00000 bytes:
>>>>
>>>> efi: 0x000082800000-0x0000829bffff [Reserved |
>>>> efi: 0x0000829c0000-0x000083efffff [Conventional|
>>>>
>>>> This fix aligns the size with the EFI reported size and makes /proc/iomem
>>>> correctly show mem blocks matching the EFI memmap:
>>>>
>>>> 82800000-829bffff : reserved
>>>> 829c0000-83efffff : System RAM
>>>>
>>>> Instead of:
>>>>
>>>> 82800000-833fffff : reserved
>>>> 83400000-83efffff : System RAM
>>>>
>>>> before this change
>>>>
>>>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> index de0f2346cb38..5a2e84365901 100644
>>>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> @@ -582,7 +582,7 @@ tz_stat_mem: tz-stat@82700000 {
>>>> };
>>>>
>>>> xbl_tmp_buffer_mem: xbl-tmp-buffer@82800000 {
>>>> - reg = <0x0 0x82800000 0x0 0xc00000>;
>>>> + reg = <0x0 0x82800000 0x0 0x1c0000>;
>>>
>>> FWIW the reference memory map shows a contiguous block of:
>>>
>>> 0x8280_0000 -> "no reclaim XBL scratch_buffer2"
>>> 0x829c_0000 -> "reclaimable XBL scratch_buffer"
>>> 0x83f0_0000-0x8400_0000 -> "no reclaim xbl scratch_buffer1"
>>
>> Thanks, so the first part here 0x8280_0000 - 0x829c_0000
>> aligns with the EFI reservation and with the dts reservation
>> after my patch.
>>
>> 0x829c_0000 - 0x83f0_0000 being reclaimable matches with
>> both EFI + the dts (old and new with a different start)
>> having this as usable RAM.
>>
>> The 0x83f0_0000-0x8400_0000 area seems to be marked as
>> reserved by neither EFI nor the current dts...
>>
>> With the first part of the reference memory map aligning
>> with what EFI shows, I think this patch is correct.
>>
>> I wonder if we should do anything about the 0x83f0_0000-0x8400_0000
>> range though ?
>
> The logs in your commit message suggest the UEFI ahd already taken care
> of reserving that bit
>
> Could you post the full output of `memmap` in uefi shell on your device?
I find just booting with efi=debug easier. Here is the EFI memmap as
seen/printed by Linux when booting with efi=debug:
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x000080800000-0x000080dfffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000815a0000-0x0000819fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081a00000-0x000081a3ffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081d00000-0x000081dfffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081f20000-0x000081f2ffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081f38000-0x0000826fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000829c0000-0x000083efffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000084000000-0x000084afffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000085380000-0x0000866bffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000091480000-0x0000a67fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a6800000-0x0000a7f00fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f01000-0x0000a7f01fff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f02000-0x0000a7f04fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f05000-0x0000a7f0cfff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f0d000-0x0000a7f18fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f19000-0x0000a7ffffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a8000000-0x0000bbc0ffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000bbc10000-0x0000c177ffff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c1780000-0x0000c178afff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c178b000-0x0000c3933fff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c3934000-0x0000c4c76fff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c4c77000-0x0000c50aafff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c50ab000-0x0000c54fcfff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c54fd000-0x0000c5b12fff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b13000-0x0000c5b21fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b22000-0x0000c5b23fff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b24000-0x0000c5b34fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b35000-0x0000c62e3fff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62e4000-0x0000c62e4fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62e5000-0x0000c62edfff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62ee000-0x0000c65f6fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c65f7000-0x0000c66d5fff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c66d6000-0x0000cf6ecfff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000cf6ed000-0x0000cfbb9fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000cfbba000-0x0000d0020fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d0021000-0x0000d5135fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5136000-0x0000d5136fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5137000-0x0000d5cedfff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5cee000-0x0000d5e7dfff [Runtime Code|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5e7e000-0x0000d6c8dfff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6c8e000-0x0000d6c9dfff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6c9e000-0x0000d6d02fff [ACPI Mem NVS| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6d03000-0x0000d6ddefff [ACPI Reclaim| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6ddf000-0x0000d6ddffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6de0000-0x0000d6e0ffff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6e10000-0x0000d7ffffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000de5b0000-0x0000e46fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000e69c0000-0x0000f84fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000880000000-0x000cc236ffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000cc2370000-0x000cc6bdffff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000cc6be0000-0x000ffdffffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ffe000000-0x000fffffffff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x00000c264000-0x00000c264fff [MMIO |RUN| | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081a40000-0x000081cfffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081e00000-0x000081efffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081f00000-0x000081f1ffff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x000081f30000-0x000081f37fff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x000082700000-0x0000827fffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000082800000-0x0000829bffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000083f00000-0x000083ffffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000084b00000-0x00008537ffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000866c0000-0x00009137ffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000e4700000-0x0000e47fffff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x0000e4800000-0x0000e69bffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000ff800000-0x0000ffffffff [Reserved | | | | | | | | | | | | | | |UC]
Let me know if you want the efi shell output instead of this.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH RFC v4 12/12] ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards
From: sashiko-bot @ 2026-06-16 20:42 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-12-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `syscon-reboot` node is incorrectly defined at the root level using the explicitly deprecated `regmap` property.
--
commit afa99cf55be8056135e61b54fc719550822bda85
Author: Stefan Dösinger <stefandoesinger@gmail.com>
ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards
This commit adds a syscon-reboot node to the zx297520v3 device tree. It allows
resetting the board by writing a value to a register exposed by the topclk
syscon.
> diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
> index a2b6909e7434d..013ece51c2a09 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>;
[Severity: Low]
Does this use a deprecated property? According to the syscon-reboot device
tree bindings, the regmap property is explicitly deprecated.
The documented modern requirement is to define the syscon-reboot node as a
child of the system controller node. Introducing new nodes using deprecated
bindings can trigger make dtbs_check warnings.
To resolve this, the syscon-reboot node could be moved to be a child of topclk,
and topclk's compatible string could be updated to include "simple-mfd" to
ensure the driver core automatically probes the child node.
> + offset = <0x0>;
> + mask = <0x1>;
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=12
^ permalink raw reply
* Re: [PATCH RFC v4 07/12] clk: zte: Introduce a driver for zx297520v3 top clocks
From: sashiko-bot @ 2026-06-16 20:43 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-7-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The 'dpll' and 'unknownpll' clocks are incorrectly configured with a single parent, leading to incorrect rate calculations and potential clock orphaning.
Pre-existing issues:
- [High] The `struct auxiliary_device` is allocated with `devm_kzalloc`, decoupling its memory lifecycle from its embedded kobject reference count.
- [High] The driver fails to properly validate the return value of `device_node_to_regmap()`, resulting in an invalid pointer dereference if the regmap cannot be obtained.
--
commit 41eccb5b69bddbf772e343c7bf76be8415a468bc
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 top clocks
This commit introduces a new clock driver for the ZTE zx297520v3 SoC.
It adds support for the top clocks, including various PLLs, AHB, timers,
and USB controllers. The patch wires up the clock configuration structures
and registers the driver via the zx_clk_probe framework.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> new file mode 100644
> index 0000000000000..50263bca6e087
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> + /* 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),
[Severity: High]
The documentation block here states this PLL has two possible parents, but it
is restricted to the single parent in clk_main. Does hardcoding a single parent
cause an out-of-bounds index lookup if the hardware selects a parent index > 0?
> + .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),
[Severity: High]
Similarly, the comment states this PLL accepts parent values 0, 1, 2, and 3,
with parent 0 being unknownpll_d2. Since clk_main only contains osc26m, does
restricting this to a single parent cause the clock framework to erroneously
compute all DPLL-derived frequencies using 26 MHz instead of 23.04 MHz?
> + .rate = 491520000,
> + .postdivs = pll_postdivs,
> + .num_postdivs = ARRAY_SIZE(pll_postdivs),
> + .reg = 0x18,
> + },
[ ... ]
> +static struct platform_driver clk_zx297520v3 = {
> + .probe = zx_clk_probe,
[Severity: High]
This is a pre-existing issue, but I noticed two concerns in zx_clk_probe()
located in clk-zx.c:
First, zx_clk_probe() calls device_node_to_regmap(dev->of_node) which
returns an ERR_PTR on failure. The code checks for failure using:
if (!map)
return -EINVAL;
Since an error pointer is non-null, will this check evaluate to false and
allow an invalid pointer to be dereferenced later?
Second, zx_clk_probe() allocates the auxiliary device using devm_kzalloc().
When the driver unbinds, devres executes zx_adev_unregister() to uninitialize
the device before freeing the devm-managed memory.
If an external entity holds an active reference to the auxiliary device,
the reference count will remain non-zero. Could this result in a
use-after-free when the external reference is dropped and put_device() tries
to access the already-freed memory?
> + .driver = {
> + .name = "clk-zx297520v3",
> + .of_match_table = of_match_zx297520v3,
> + },
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH RFC v4 05/12] clk: zte: Add zx PLL support infrastructure
From: sashiko-bot @ 2026-06-16 20:43 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-5-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [High] Calling `clk_set_rate` inside the `.init` callback fails silently or deterministically due to unestablished clock topology.
- [High] `zx29_pll_determine_rate` dereferences NULL for orphan clocks and ignores the dynamic rate propagation requested by the framework.
- [High] `zx29_pll_recalc_rate` returns a negative error code cast to a massive `unsigned long` on regmap read failure.
- [High] Use-After-Free of `struct auxiliary_device` due to `devm_kzalloc` allocation.
- [Medium] If `zx29_pll_prepare` fails to lock the PLL, it returns an error but leaves the hardware permanently enabled.
- [Low] Excessive `dev_warn` and `dev_err` logging during standard rate calculation queries will spam the kernel log.
- [Low] The `pll->dev` pointer is never initialized, causing all driver logging functions to use a NULL device.
--
commit 374687dfee47dfcb141c2ae13759333d3bad3cde
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add zx PLL support infrastructure
This patch implements the core PLL infrastructure for ZTE zx platforms.
It provides functions for clock calculation, setting parent rates, and
registering the PLL operations with the Common Clock Framework.
> diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
> index c0475d5441fbc..f077b6b56841e 100644
> --- a/drivers/clk/zte/pll-zx.c
> +++ b/drivers/clk/zte/pll-zx.c
[ ... ]
> +static int zx29_pll_prepare(struct clk_hw *hw)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + u32 val;
> + int res;
> +
> + res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
> + if (res < 0)
> + return res;
> +
> + /* Lock duration is usually between 300us to 500us */
> + res = regmap_read_poll_timeout(pll->map, pll->reg, val, val & ZX29_PLL_LOCKED, 50, 2000);
> + dev_dbg(pll->dev, "%s: Enable result %u val 0x%08x\n", clk_hw_get_name(&pll->hw), res, val);
> + return res;
[Severity: Medium]
If regmap_read_poll_timeout() times out waiting for the lock bit, does this
leave the hardware permanently enabled? The ZX29_PLL_DISABLE bit is cleared
above, but it does not appear to be restored on this error path. The core
will treat the clock as unprepared and won't call the unprepare operation,
which could leak power and leave the hardware in an unlocked state.
> +}
[ ... ]
> +static unsigned long zx29_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + u32 val;
> + int res;
> +
> + res = regmap_read(pll->map, pll->reg, &val);
> + if (res < 0)
> + return res;
[Severity: High]
Could this return a massive fake clock rate? Because this function returns
unsigned long, if regmap_read() fails and returns a negative error code
like -EINVAL, the negative integer gets implicitly cast to a very large
unsigned value. Should this return 0 on failure to prevent corrupting rate
calculations across the clock tree?
> +
> + return zx29_pll_get_rate(pll, parent_rate, val);
> +}
[ ... ]
> +static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
> + unsigned long rate)
> +{
[ ... ]
> +search_done:
> +
> + if (!postdiv1) {
> + dev_err(pll->dev, "Did not find a setting for %lu Hz, parent %lu Hz\n",
> + rate, parent_rate);
> + return 0;
> + }
[Severity: Low]
Will this dev_err() flood the kernel log with false positives? The Common
Clock Framework frequently performs exploratory rate queries during normal
tree traversal, so unachievable out-of-bounds rates might be a normal part
of clock negotiation rather than a true device error.
> +
> + dev_dbg(pll->dev, "%s: parent rate %lu\n", name, parent_rate);
[ ... ]
> +static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + unsigned long new_rate, parent_rate = clk_hw_get_rate(clk_hw_get_parent(&pll->hw));
[Severity: High]
Is there a risk of a NULL pointer dereference here? If the clock is an
orphan and has no parent attached yet, clk_hw_get_parent() returns NULL.
Passing NULL into clk_hw_get_rate() will panic when it dereferences hw->core.
Also, shouldn't this use req->best_parent_rate instead to properly support
dynamic rate propagation?
> + u32 setting;
> +
> + setting = zx29_pll_calc_values(pll, parent_rate, req->rate);
> + if (!setting)
> + return -EINVAL;
> +
> + new_rate = zx29_pll_get_rate(pll, parent_rate, setting);
> + if (new_rate != req->rate) {
> + dev_warn(pll->dev, "Did not find an exact match. Want %lu, got %lu\n",
> + req->rate, new_rate);
[Severity: Low]
Is it safe to log a warning here? The framework routinely requests inexact
rates during clock rounding operations, so this could also cause excessive
console spam during normal execution.
> + req->rate = new_rate;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static int zx29_pll_init(struct clk_hw *hw)
> +{
[ ... ]
> + if (regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE) > 0) {
> + if (pll->init_rate) {
> + dev_dbg(pll->dev, "%s: Setting to %lu Hz\n", name, pll->init_rate);
> + res = clk_set_rate(pll->hw.clk, pll->init_rate);
[Severity: High]
Does this rate change silently fail? At the time the init callback runs
during device registration, the clock topology is not fully established and
pll->hw.clk is often NULL. Calling clk_set_rate() with a NULL clock will
simply return 0 without applying the expected initial rate to the hardware.
> + if (res) {
> + dev_err(pll->dev, "%s: Failed to set rate.\n", name);
> + return res;
> + }
> + }
[ ... ]
> +int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
> + const struct zx_pll_desc *desc, unsigned int num,
> + struct clk_hw_onecell_data *clocks)
> +{
> + struct zx29_clk_pll *pll;
> + unsigned int i, f;
> + struct clk_hw *hw;
> + char plldiv[32];
> + int res;
> +
> + for (i = 0; i < num; ++i) {
> + struct clk_init_data init = {};
> +
> + pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return -ENOMEM;
> +
> + init.name = desc[i].name;
> + init.ops = &zx29_pll_ops;
[Severity: Low]
Are we missing an assignment to pll->dev here? Since devm_kzalloc() zeroes
the memory and the dev pointer is never explicitly mapped to pll->dev,
won't all subsequent calls to dev_dbg(), dev_err(), and dev_warn() end up
using a NULL device pointer and breaking debug message filtering?
> + init.parent_names = desc[i].parents;
> + init.num_parents = desc[i].num_parents;
[ ... ]
While reviewing the broader changes in this driver series, I noticed a
regression in zx_clk_probe() inside drivers/clk/zte/clk-zx.c:
[Severity: High]
Can the use of devm_kzalloc() to allocate the auxiliary device (adev) lead
to a Use-After-Free? The devm framework might abruptly free the memory
during unbind, breaking standard device lifetime rules. If another
subsystem is holding a reference to the device, this memory will be freed
out from under it before the core drops the final reference and calls the
proper release callback.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Conor Dooley @ 2026-06-16 20:50 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <4bc99611-4bf1-4797-ba31-6f1d7dee1e1e@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]
On Tue, Jun 16, 2026 at 02:54:55PM -0500, David Lechner wrote:
> On 6/16/26 11:07 AM, Conor Dooley wrote:
> > On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> >> ---
> >> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> >> MAINTAINERS | 7 +
> >> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> >> 3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> + Supports the following Texas Instruments' ADC chips:
> >> + - ADS112C14 (16-bit)
> >> + - ADS122C14 (24-bit)
> >> +
> >> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> + These chips are primarily designed for use with temperature sensors such as
> >> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> + represents the conditions required to make a measurement rather than strictly
> >> + just the physical input channels.
> >> +
> >> +maintainers:
> >> + - David Lechner <dlechner@baylibre.com>
> >> +
> >> +unevaluatedProperties: false
> >
> > Weird positioning of this.
>
> IIRC, Rob asked that I do it in this order on another binding a while
> ago (the reasoning being that it was too far away from properties:
> otherwise), so I've done it like this on a few bindings now. It doesn't
> make much difference to me though.
Too far away because it refers to properties in the "main" node, but
appears conventionally after a rake of properties belonging to the
children?
>
> >
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - ti,ads112c14
> >> + - ti,ads122c14
> >> +
> >> + reg:
> >> + items:
> >> + - minimum: 0x40
> >> + maximum: 0x47
> >> +
> >> + clocks:
> >> + maxItems: 1
> >> + description: Optional external clock connected to GPIO3 pin.
> >> +
> >> + avdd-supply: true
> >> + dvdd-supply: true
> >> +
> >> + refp-supply: true
> >> + refn-supply: true
> >> +
> >> + refp-refn-resistor-ohms:
> >
> > Missing prefix here and elsewhere.
>
> I thought we didn't need a prefix when using standard units.
You don't need a ref to a typedef, but you still need a prefix if it is
some random resistor that's specific to this device etc.
> >> + ti,vref-source:
> >> + description: |
> >> + Indicates the source for the reference voltage for this channel.
> >> + 0 - Internal 2.5V reference
> >> + 1 - Internal 1.25V reference
> >> + 2 - External reference (REFP-REFN)
> >> + 3 - AVDD as reference
> >
> > My usual complaint here about things you have to make macros for, could
> > these just be strings from the get-go?
>
> As in the commit message, this is an existing property name, so I didn't want
> to change the type. But I agree that strings are better for this kind of thing
> so perhaps I should just use a different property name instead so we can do
> it better.
I wouldn't get too hung up on that sound adc, particularly since it
seems to have been added without an ack from a devicetree maintainer.
If you were trying to share a driver or something then I'd consider it
differently but these seem to be unrelated devices.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-16 21:04 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260616-livable-muster-d268af11dcc8@spud>
On 6/16/26 3:50 PM, Conor Dooley wrote:
> On Tue, Jun 16, 2026 at 02:54:55PM -0500, David Lechner wrote:
>> On 6/16/26 11:07 AM, Conor Dooley wrote:
>>> On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
>>>> Add new bindings for ti,ads122c14 and similar devices.
>>>>
>>>> This is an ADC that is primarily intended for use with temperature
>>>> sensors. There are a few unusual properties because of this. In
>>>> particular, the reference voltage source and current output requirements
>>>> can be different for each measurement, so these are included in the
>>>> channel bindings.
>>>>
>>>> The REFP/REFN reference voltage is usually just connected to a resistor
>>>> that is being driven by the ADC's current outputs, so there is special
>>>> property for this case rather than requiring a regulator to be defined
>>>> to represent that.
>>>>
>>>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>>>> have preferred an enum of strings).
>>>>
>>>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>>>> MAINTAINERS | 7 +
>>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>>> 3 files changed, 242 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>>> new file mode 100644
>>>> index 000000000000..dc7f37cad772
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>>> @@ -0,0 +1,224 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Texas Instruments' ADS112C14 and similar ADC chips
>>>> +
>>>> +description: |
>>>> + Supports the following Texas Instruments' ADC chips:
>>>> + - ADS112C14 (16-bit)
>>>> + - ADS122C14 (24-bit)
>>>> +
>>>> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
>>>> +
>>>> + These chips are primarily designed for use with temperature sensors such as
>>>> + RTDs and thermocouples. The channel bindings reflect this in that each channel
>>>> + represents the conditions required to make a measurement rather than strictly
>>>> + just the physical input channels.
>>>> +
>>>> +maintainers:
>>>> + - David Lechner <dlechner@baylibre.com>
>>>> +
>>>> +unevaluatedProperties: false
>>>
>>> Weird positioning of this.
>>
>> IIRC, Rob asked that I do it in this order on another binding a while
>> ago (the reasoning being that it was too far away from properties:
>> otherwise), so I've done it like this on a few bindings now. It doesn't
>> make much difference to me though.
>
> Too far away because it refers to properties in the "main" node, but
> appears conventionally after a rake of properties belonging to the
> children?
>
I found the original request:
https://lore.kernel.org/all/20241022204312.GA1524310-robh@kernel.org/
"Easier to read the indented cases that way."
Reading it again, it sounds like the request was just for the indented
additionalProperties to be moved.
^ permalink raw reply
* Re: [PATCH v2 0/2] ASoC: simple-card-utils: support system-clock-id DT property
From: Wang, Sen @ 2026-06-16 21:14 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Mark Brown, Kuninori Morimoto, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
linux-sound, devicetree, linux-kernel
In-Reply-To: <20260607163845.652bcc73@kemnade.info>
On 6/7/2026 9:38 AM, Andreas Kemnade wrote:
> Hi,
>
> On Fri, 15 May 2026 11:13:56 -0500
> Sen Wang <sen@ti.com> wrote:
>
>> Adding an optional, u32 system-clock-id DT property into the generic machine
>> driver so clocking topology info can be exposed in DT.
>>
> while having this binding would solve some of my problem. I am wondering
> whether is the right approach. What about modelling the clocks involved
> using the clk framework, so let some more codecs/dais be clock provider.
> So things can be configured that way.
> E.g. tlv320aic32x4-clk.c
>
> Same for set_div() which is also unavailable in these generic cards.
>
Hi Andreas, just got back from break, sorry for the delayed message.
I agree with you, in retrospect, this patch is indeed a hasty patch that
only covers up the legacy clk-id scheme rather than adapting the modern
clk framework.
Modeling individual cpu/codec DAI clocks does seem to be the way to go,
not the one patch fix-all solution I'd hope for, but I still wanted to
see if I can reuse the existing CCF patterns for drivers with
clk-id/div-id as an alternative.
Best,
Sen Wang
^ permalink raw reply
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: Dmitry Torokhov @ 2026-06-16 21:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <CAPVz0n2fnM6zYtP9bCtsY9mcLdce_R+1UPmMo0o4JRgjnhuhKA@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:25:25AM +0300, Svyatoslav Ryhel wrote:
> вт, 16 черв. 2026 р. о 07:26 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Thu, May 28, 2026 at 08:32:00AM +0300, Svyatoslav Ryhel wrote:
> > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > >
> > > Add support for multimedia top button row of ASUS Transformer's Mobile
> > > Dock keyboard. Driver is made that function keys (F1-F12) are used by
> > > default which suits average Linux use better and with pressing
> > > ScreenLock + AltGr function keys layout is switched to multimedia keys.
> > > Since this only modifies codes sent by asus-ec-keys it doesn't affect
> > > normal keyboards at all.
> >
> > I think using input handler to intercept ScreenLock + AltGr is quite
> > awkward. I think this also passes the original key events (unless you
> > make it a filter not a regular handler).
> >
> > I do not see benefit for reacting to AltGr+ScreenLock on other keyboards
> > to activate the special mode on this one. So given the fact that you
> > already mange the data stream when you split it into "serio" ports,
> > maybe just intercept this key combo right there and create the input
> > device and signal input events right there?
> >
>
> Though it seems awkward at a first glance, media keys are integrated
> with a standard keyboard in a detachable dock. It is highly unlikely
> that media keys will be used with a different keyboard then the one
> that is integrated with dock. Additionally, the ScreenLock key has a
> code specific to this driver and is not in general use, so even if any
> standard keyboard has AltGr but none has ScreenLock specific to this
> driver except the dock itself. Handler is also set as observer so it
> should not interfere with work of other input devices.
I am not concerned about it interfering with other drivers, I am
concerned about it unnecessarily connecting to unrelated devices
(anything that declares EV_KEY).
Again, I think having input handler is not appropriate here. I would
fold this patch into the patch that introduces the 2 serio ports,
enhanced the data stream analysis to detect your key combo, and then
report through this new input device. You do not need to have the round
trip through atkbd and the new input handler for this.
Thanks.
--
Dmitry
^ permalink raw reply
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