[PATCH treewide 0/5] clk: Make sure clk_init_data is fully initialized (part 1)

[PATCH treewide 0/5] clk: Make sure clk_init_data is fully initialized (part 1)

[Geert Uytterhoeven]

	Hi all,

The clk_init_data structure contains three mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  When commit
fc0c209c147f35ed ("clk: Allow parents to be specified without string
names") added the last two methods, this was done in a
backwards-compatible way, using a priority-based scheme:
  - .name, .ops, .num_parents, and .flags must always be initialized,
  - if .num_parents is non-zero, .parent_names must be initialized,
      - if .parent_names is NULL, .parent_data must be initialized,
	  - if .parent_data is NULL, .parent_hws must be initialized
	    and valid.

However, not initializing all members may cause subtle issues, which are
only exposed when CONFIG_INIT_STACK_ALL_PATTERN or
CONFIG_INIT_STACK_NONE is enabled.

Hence this series makes sure all members are fully initialized, to fix
such bugs, and to avoid future breakage when converting drivers to a
different method for specifying the parents.

This (small) series is part 1, and fixes all cases that I identified to
be real bugs:
  - The first patch fixes a crash I saw on BeagleBone Black,
  - The other patches are only compile-tested.
All patches in this series can be applied independently.

Part 2 will be much larger (touching 185 files), and will fix the
remaining cases that are currently harmless.

Thanks for your comments!

Geert Uytterhoeven (5):
  clk: ti: Make sure clk_init_data is fully initialized
  clk: visconti: Make sure clk_init_data is fully initialized
  hwmon: (ltc4282) Make sure clk_init_data is fully initialized
  iio: frequency: adf4377: Make sure clk_init_data is fully initialized
  spi: amlogic-spisg: Make sure clk_init_data is fully initialized

 drivers/clk/ti/adpll.c          | 4 ++--
 drivers/clk/ti/divider.c        | 2 +-
 drivers/clk/ti/mux.c            | 2 +-
 drivers/clk/visconti/clkc.c     | 2 +-
 drivers/hwmon/ltc4282.c         | 2 +-
 drivers/iio/frequency/adf4377.c | 2 +-
 drivers/spi/spi-amlogic-spisg.c | 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

-- 
2.43.0

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH treewide 1/5] clk: ti: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

_register_mux() fills in init.parent_data, and assumes that
init.parent_names is NULL.  However, the latter in uninitialized, and
thus may cause a crash.

Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.

Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name")
Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/clk/ti/adpll.c   | 4 ++--
 drivers/clk/ti/divider.c | 2 +-
 drivers/clk/ti/mux.c     | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
index e305fcbac6475b03..8885d28face50beb 100644
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -483,7 +483,7 @@ static const struct clk_ops ti_adpll_ops = {
 
 static int ti_adpll_init_dco(struct ti_adpll_data *d)
 {
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk *clock;
 	const char *postfix;
 	int width, err;
@@ -576,7 +576,7 @@ static int ti_adpll_init_clkout(struct ti_adpll_data *d,
 				struct clk *clk1)
 {
 	struct ti_adpll_clkout_data *co;
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk_ops *ops;
 	const char *parent_names[2];
 	const char *child_name;
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index af923b8cb0ed8fbc..3b438c2d68aacd7c 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -311,7 +311,7 @@ static struct clk *_register_divider(struct device_node *node,
 				     u32 flags,
 				     struct clk_omap_divider *div)
 {
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	const char *parent_name;
 	const char *name;
 
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index ded4432f7528cc6e..0fef60e82107a5a5 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -124,9 +124,9 @@ static struct clk *_register_mux(struct device_node *node, const char *name,
 				 struct clk_omap_reg *reg, u8 shift, u32 mask,
 				 s8 latch, u8 clk_mux_flags, u32 *table)
 {
+	struct clk_init_data init = {};
 	struct clk_omap_mux *mux;
 	struct clk *clk;
-	struct clk_init_data init;
 
 	/* allocate the mux */
 	mux = kzalloc_obj(*mux);
-- 
2.43.0

[PATCH treewide 2/5] clk: visconti: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

visconti_clk_register_gate() fills in init.parent_data, and assumes that
init.parent_names is NULL.  However, the latter in uninitialized, and
thus may cause a crash.

Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.

Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/clk/visconti/clkc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/visconti/clkc.c b/drivers/clk/visconti/clkc.c
index d0b193b5d0b35f94..4018d1298880dfbb 100644
--- a/drivers/clk/visconti/clkc.c
+++ b/drivers/clk/visconti/clkc.c
@@ -81,9 +81,9 @@ static struct clk_hw *visconti_clk_register_gate(struct device *dev,
 						 u8	rs_idx,
 						 spinlock_t *lock)
 {
+	struct clk_init_data init = {};
 	struct visconti_clk_gate *gate;
 	struct clk_parent_data *pdata;
-	struct clk_init_data init;
 	struct clk_hw *hw;
 	int ret;
 
-- 
2.43.0

[PATCH treewide 3/5] hwmon: (ltc4282) Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

ltc428_clk_provider_setup() does not fill in any parent clocks, and
assumes that init.num_parents is NULL.  However, the latter in
uninitialized, and thus may cause a crash.

Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.

Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/hwmon/ltc4282.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/ltc4282.c b/drivers/hwmon/ltc4282.c
index b1675dc5b3c7fd2f..54ba4b8542e94b7b 100644
--- a/drivers/hwmon/ltc4282.c
+++ b/drivers/hwmon/ltc4282.c
@@ -1106,7 +1106,7 @@ static const struct clk_ops ltc4282_ops = {
 static int ltc428_clk_provider_setup(struct ltc4282_state *st,
 				     struct device *dev)
 {
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	int ret;
 
 	if (!IS_ENABLED(CONFIG_COMMON_CLK))
-- 
2.43.0

[PATCH treewide 4/5] iio: frequency: adf4377: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

adf4377_clk_register() fills in init.parent_data, and assumes that
init.parent_names is NULL.  However, the latter in uninitialized, and
thus may cause a crash.

Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.

Fixes: 60e5448ddbec2dc2 ("iio: frequency: adf4377: add clk provider support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/iio/frequency/adf4377.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c
index 4dd19a9aa9943c57..f4eb9ba5878e1893 100644
--- a/drivers/iio/frequency/adf4377.c
+++ b/drivers/iio/frequency/adf4377.c
@@ -990,7 +990,7 @@ static int adf4377_clk_register(struct adf4377_state *st)
 {
 	struct spi_device *spi = st->spi;
 	struct device *dev = &spi->dev;
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk_parent_data parent_data;
 	int ret;
 
-- 
2.43.0

[PATCH treewide 5/5] spi: amlogic-spisg: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

aml_spisg_clk_init() fills in init.parent_data, and assumes that
init.parent_names is NULL.  However, the latter in uninitialized, and
thus may cause a crash.

Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.

Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/spi/spi-amlogic-spisg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-spisg.c
index afc8af04638d3b6e..9049a87e9d0f2df6 100644
--- a/drivers/spi/spi-amlogic-spisg.c
+++ b/drivers/spi/spi-amlogic-spisg.c
@@ -636,7 +636,7 @@ static int aml_spisg_target_abort(struct spi_controller *ctlr)
 static int aml_spisg_clk_init(struct spisg_device *spisg, void __iomem *base)
 {
 	struct device *dev = &spisg->pdev->dev;
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk_divider *div;
 	struct clk_div_table *tbl;
 	char name[32];
-- 
2.43.0

Re: [PATCH treewide 1/5] clk: ti: Make sure clk_init_data is fully initialized

[sashiko-bot]

> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> _register_mux() fills in init.parent_data, and assumes that
> init.parent_names is NULL.  However, the latter in uninitialized, and
> thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name")
> Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787165329.git.geert+renesas@glider.be?part=1

Re: [PATCH treewide 3/5] hwmon: (ltc4282) Make sure clk_init_data is fully initialized

[sashiko-bot]

> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> ltc428_clk_provider_setup() does not fill in any parent clocks, and
> assumes that init.num_parents is NULL.  However, the latter in
> uninitialized, and thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787165329.git.geert+renesas@glider.be?part=3

Re: [PATCH treewide 4/5] iio: frequency: adf4377: Make sure clk_init_data is fully initialized

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix for uninitialized stack variables: `struct clk_parent_data parent_data` remains uninitialized on the stack, leading to a kernel crash during clock registration.
--

--- Patch [4]: [PATCH treewide 4/5] iio: frequency: adf4377: Make sure clk_init_data is fully initialized ---
commit 99e024a77f5bce5921d3c6b46054263aa450610d
Author: Geert Uytterhoeven <geert+renesas@glider.be>

iio: frequency: adf4377: Make sure clk_init_data is fully initialized

This commit initializes the clk_init_data structure in
adf4377_clk_register() to zero. This prevents crashes caused by
uninitialized fields like parent_names when CONFIG_INIT_STACK_ALL_PATTERN
or CONFIG_INIT_STACK_NONE is enabled.

> diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c
> --- a/drivers/iio/frequency/adf4377.c
> +++ b/drivers/iio/frequency/adf4377.c
> @@ -999,7 +999,7 @@ static int adf4377_clk_register(struct adf4377_state *st)
>  {
>  	struct spi_device *spi = st->spi;
>  	struct device *dev = &spi->dev;
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	struct clk_parent_data parent_data;

[Severity: High]
This is a pre-existing issue, but does this struct clk_parent_data also
need to be zero-initialized?

Only fw_name is explicitly assigned below, leaving name, hw, and index
populated with stack garbage. When adf4377_clk_register() passes this to
the clock framework, clk_core_populate_parent_map() will read
parent_data.name and pass it to clk_cpy_name(), which ultimately calls
strlen() and can cause a page fault during probe.

[ ... ]

>  	parent_data.fw_name = "ref_in";
>  
>  	init.ops = &adf4377_clk_ops;
>  	init.parent_data = &parent_data;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787165329.git.geert+renesas@glider.be?part=4

Re: [PATCH treewide 5/5] spi: amlogic-spisg: Make sure clk_init_data is fully initialized

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Severe imbalance in clock prepare/enable counts for `pclk` and `core` clocks, leading to negative enable counts and warnings during driver probe failure or removal.
- [High] Missing cleanup for runtime PM and `sclk` clock on the probe error path and module removal.
--

--- Patch [5]: [PATCH treewide 5/5] spi: amlogic-spisg: Make sure clk_init_data is fully initialized ---
commit aa4fc6e665f6f8293335c8edd96584e8cdda40c6
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Subject: spi: amlogic-spisg: Make sure clk_init_data is fully initialized

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues.

Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver")

> diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-spisg.c
> index afc8af04638d3..9049a87e9d0f2 100644
> --- a/drivers/spi/spi-amlogic-spisg.c
> +++ b/drivers/spi/spi-amlogic-spisg.c
> @@ -636,7 +636,7 @@ static int aml_spisg_target_abort(struct spi_controller *ctlr)
>  static int aml_spisg_clk_init(struct spisg_device *spisg, void __iomem *base)
>  {
>  	struct device *dev = &spisg->pdev->dev;
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	struct clk_divider *div;
>  	struct clk_div_table *tbl;
>  	char name[32];

[Severity: High]
This is a pre-existing issue, but I noticed a severe imbalance in clock
prepare/enable counts for the pclk and core clocks.

In aml_spisg_clk_init(), pclk is acquired with devm_clk_get_enabled():

	spisg->pclk = devm_clk_get_enabled(dev, "pclk");

But later in the same function, it is manually disabled:

	clk_disable_unprepare(spisg->pclk);

Since pclk is managed by devres, won't this manual disable unbalance the
clock enable count right from the start? 

This pattern is also repeated in the probe error path and remove functions:

drivers/spi/spi-amlogic-spisg.c:aml_spisg_probe() {
...
out_clk:
	if (spisg->core)
		clk_disable_unprepare(spisg->core);
	clk_disable_unprepare(spisg->pclk);

	return ret;
}

Does this cause double-disables and negative enable counts when the
devres cleanup runs?

[Severity: High]
This is also a pre-existing issue, but I noticed missing cleanup for
runtime PM and the sclk clock.

In aml_spisg_clk_init(), sclk is manually enabled:

	clk_prepare_enable(spisg->sclk);

And in aml_spisg_probe(), runtime PM is enabled:

	pm_runtime_enable(&spisg->pdev->dev);

However, if devm_request_irq() or spi_register_controller() fails, the
out_clk error path simply returns:

drivers/spi/spi-amlogic-spisg.c:aml_spisg_probe() {
...
out_clk:
	if (spisg->core)
		clk_disable_unprepare(spisg->core);
	clk_disable_unprepare(spisg->pclk);

	return ret;
}

Doesn't this leak the sclk enable count and leave runtime PM enabled?

Additionally, aml_spisg_remove() also lacks a pm_runtime_disable() call
and skips disabling sclk if the device is not runtime suspended. Should
there be explicit teardowns for these in the error and removal paths?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787165329.git.geert+renesas@glider.be?part=5

Re: [PATCH treewide 2/5] clk: visconti: Make sure clk_init_data is fully initialized

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] visconti_reset_status() incorrectly uses the bit index directly instead of a bitmask, resulting in corrupted status checks.
--

--- Patch [2]: [PATCH treewide 2/5] clk: visconti: Make sure clk_init_data is fully initialized ---
commit 61772ea3c610a3b3ebf435b199e400c1c5aaee4c
Author: Geert Uytterhoeven <geert+renesas@glider.be>

clk: visconti: Make sure clk_init_data is fully initialized

The clk_init_data structure contains several mutually-exclusive members for
different methods to specify the possible parents of a clock. Not
initializing all members may cause subtle issues when uninitialized members
are unexpectedly accessed. This commit ensures all members are fully
initialized to zero.

> diff --git a/drivers/clk/visconti/clkc.c b/drivers/clk/visconti/clkc.c
> index d0b193b5d0b35..4018d1298880d 100644
> --- a/drivers/clk/visconti/clkc.c
> +++ b/drivers/clk/visconti/clkc.c
> @@ -81,9 +81,9 @@ static struct clk_hw *visconti_clk_register_gate(struct device *dev,
>  						 u8	rs_idx,
>  						 spinlock_t *lock)
>  {
> +	struct clk_init_data init = {};
>  	struct visconti_clk_gate *gate;
>  	struct clk_parent_data *pdata;
> -	struct clk_init_data init;
>  	struct clk_hw *hw;
>  	int ret;
>  

[Severity: High]
This is a pre-existing issue, but while reviewing the visconti clock and
reset driver changes, I noticed a potential problem with how rs_idx is used.

In drivers/clk/visconti/reset.c:visconti_reset_status():

	spin_lock_irqsave(reset->lock, flags);
	ret = regmap_read(reset->regmap, data->rson_offset, &reg);
	spin_unlock_irqrestore(reset->lock, flags);
	if (ret)
		return ret;

	return !(reg & data->rs_idx);

Is this reset status check operating as intended? Since rs_idx is a raw bit
index (0-31), would it be more accurate to mask the register with
BIT(data->rs_idx) rather than the raw index value?

Masking with the raw index seems like it could produce incorrect status
returns. For example, if rs_idx is 0, the mask would always evaluate to 0.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787165329.git.geert+renesas@glider.be?part=2

Re: [PATCH treewide 3/5] hwmon: (ltc4282) Make sure clk_init_data is fully initialized

[Guenter Roeck]

On Wed, Aug 19, 2026 at 09:05:17PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> ltc428_clk_provider_setup() does not fill in any parent clocks, and
> assumes that init.num_parents is NULL.  However, the latter in
> uninitialized, and thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Applied.

Thanks,
Guenter

> ---
> Compile-tested only.
> ---
>  drivers/hwmon/ltc4282.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ltc4282.c b/drivers/hwmon/ltc4282.c
> index b1675dc5b3c7fd2f..54ba4b8542e94b7b 100644
> --- a/drivers/hwmon/ltc4282.c
> +++ b/drivers/hwmon/ltc4282.c
> @@ -1106,7 +1106,7 @@ static const struct clk_ops ltc4282_ops = {
>  static int ltc428_clk_provider_setup(struct ltc4282_state *st,
>  				     struct device *dev)
>  {
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	int ret;
>  
>  	if (!IS_ENABLED(CONFIG_COMMON_CLK))

Re: [PATCH treewide 1/5] clk: ti: Make sure clk_init_data is fully initialized

[Brian Masney]

On Wed, Aug 19, 2026 at 09:05:15PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> _register_mux() fills in init.parent_data, and assumes that
> init.parent_names is NULL.  However, the latter in uninitialized, and
> thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name")
> Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Brian Masney <bmasney@redhat.com>

Re: [PATCH treewide 2/5] clk: visconti: Make sure clk_init_data is fully initialized

[Brian Masney]

On Wed, Aug 19, 2026 at 09:05:16PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> visconti_clk_register_gate() fills in init.parent_data, and assumes that
> init.parent_names is NULL.  However, the latter in uninitialized, and
> thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Brian Masney <bmasney@redhat.com>

Re: [PATCH treewide 3/5] hwmon: (ltc4282) Make sure clk_init_data is fully initialized

[Brian Masney]

On Wed, Aug 19, 2026 at 09:05:17PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> ltc428_clk_provider_setup() does not fill in any parent clocks, and
> assumes that init.num_parents is NULL.  However, the latter in
> uninitialized, and thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Brian Masney <bmasney@redhat.com>

Re: [PATCH treewide 4/5] iio: frequency: adf4377: Make sure clk_init_data is fully initialized

[Brian Masney]

On Wed, Aug 19, 2026 at 09:05:18PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> adf4377_clk_register() fills in init.parent_data, and assumes that
> init.parent_names is NULL.  However, the latter in uninitialized, and
> thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: 60e5448ddbec2dc2 ("iio: frequency: adf4377: add clk provider support")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Brian Masney <bmasney@redhat.com>

Re: [PATCH treewide 5/5] spi: amlogic-spisg: Make sure clk_init_data is fully initialized

[Brian Masney]

On Wed, Aug 19, 2026 at 09:05:19PM +0200, Geert Uytterhoeven wrote:
> The clk_init_data structure contains several mutually-exclusive members
> for different methods to specify the possible parents of a clock,
> prompting drivers to initialize only the members they need.  However,
> not initializing all members may cause subtle issues, which are only
> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
> enabled.
> 
> aml_spisg_clk_init() fills in init.parent_data, and assumes that
> init.parent_names is NULL.  However, the latter in uninitialized, and
> thus may cause a crash.
> 
> Make sure all members are fully initialized, to fix such bugs, and to
> avoid future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Brian Masney <bmasney@redhat.com>