[PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

	Hi all,

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.

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

Part One[1] fixed all cases that I identified to be real bugs, in
response to a crash I saw on BeagleBone Black.

This series is the MMC subpart of Part Two, which fixes remaining cases
that are currently harmless.  These are still fragile, and may cause
future breakage when converting drivers to a different method for
specifying the parents.

Thanks for your comments!

[1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
     initialized (part 1)"
    https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be

Geert Uytterhoeven (2):
  mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
  mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized

 drivers/mmc/host/meson-gx-mmc.c    | 2 +-
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++--
 2 files changed, 3 insertions(+), 3 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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

	Hi all,

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.

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

Part One[1] fixed all cases that I identified to be real bugs, in
response to a crash I saw on BeagleBone Black.

This series is the MMC subpart of Part Two, which fixes remaining cases
that are currently harmless.  These are still fragile, and may cause
future breakage when converting drivers to a different method for
specifying the parents.

Thanks for your comments!

[1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
     initialized (part 1)"
    https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be

Geert Uytterhoeven (2):
  mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
  mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized

 drivers/mmc/host/meson-gx-mmc.c    | 2 +-
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++--
 2 files changed, 3 insertions(+), 3 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 1/2] mmc: meson-gx: FIXME: 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.

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

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/mmc/host/meson-gx-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 694bb443d5f3febf..698febdcd498826c 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
  */
 static int meson_mmc_clk_init(struct meson_host *host)
 {
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk_mux *mux;
 	struct clk_divider *div;
 	char clk_name[32];
-- 
2.43.0


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH 1/2] mmc: meson-gx: FIXME: 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.

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

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/mmc/host/meson-gx-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 694bb443d5f3febf..698febdcd498826c 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
  */
 static int meson_mmc_clk_init(struct meson_host *host)
 {
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	struct clk_mux *mux;
 	struct clk_divider *div;
 	char clk_name[32];
-- 
2.43.0

[PATCH 2/2] mmc: sdhci-of-arasan: 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.

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

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 4ca73e7d799ead0d..0ee22923ad568124 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -1552,8 +1552,8 @@ sdhci_arasan_register_sdcardclk(struct sdhci_arasan_data *sdhci_arasan,
 				struct device *dev)
 {
 	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
+	struct clk_init_data sdcardclk_init = {};
 	struct device_node *np = dev->of_node;
-	struct clk_init_data sdcardclk_init;
 	const char *parent_clk_name;
 	int ret;
 
@@ -1604,8 +1604,8 @@ sdhci_arasan_register_sampleclk(struct sdhci_arasan_data *sdhci_arasan,
 				struct device *dev)
 {
 	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
+	struct clk_init_data sampleclk_init = {};
 	struct device_node *np = dev->of_node;
-	struct clk_init_data sampleclk_init;
 	const char *parent_clk_name;
 	int ret;
 
-- 
2.43.0


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH 2/2] mmc: sdhci-of-arasan: 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.

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

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 4ca73e7d799ead0d..0ee22923ad568124 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -1552,8 +1552,8 @@ sdhci_arasan_register_sdcardclk(struct sdhci_arasan_data *sdhci_arasan,
 				struct device *dev)
 {
 	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
+	struct clk_init_data sdcardclk_init = {};
 	struct device_node *np = dev->of_node;
-	struct clk_init_data sdcardclk_init;
 	const char *parent_clk_name;
 	int ret;
 
@@ -1604,8 +1604,8 @@ sdhci_arasan_register_sampleclk(struct sdhci_arasan_data *sdhci_arasan,
 				struct device *dev)
 {
 	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
+	struct clk_init_data sampleclk_init = {};
 	struct device_node *np = dev->of_node;
-	struct clk_init_data sampleclk_init;
 	const char *parent_clk_name;
 	int ret;
 
-- 
2.43.0

Re: [PATCH 2/2] mmc: sdhci-of-arasan: 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] Another driver in the same subsystem (meson-mx-sdio.c) suffers from the exact same uninitialized struct clk_init_data issue that this patch fixes.
- [High] The driver registers multiple clock providers for the same device node but only deletes one on teardown, leading to a leaked provider struct, a leaked device node reference, and a dangling UAF pointer in the global clock providers list.
--

--- Patch [2]: [PATCH 2/2] mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized ---
commit 34a49f083df630f25a24052b358249a2c48b6055
Author: Geert Uytterhoeven <geert+renesas@glider.be>

mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized

The clk_init_data structure contains mutually-exclusive members for
specifying clock parents. Uninitialized members can cause issues exposed by
certain stack initialization configs. This commit zeroes the struct to prevent
bugs and future breakage.

[Severity: High]
This isn't a bug introduced by this patch, but I noticed another driver in
the same subsystem suffers from the exact same uninitialized struct
clk_init_data issue that this patch fixes.

In drivers/mmc/host/meson-mx-sdio.c:meson_mx_mmc_register_clks():

	struct clk_init_data init;
	...
	init.name = devm_kasprintf(host->controller->parent, ...);
	init.ops = &meson_mx_mmc_cfg_div_ops;
	init.flags = 0;
	...

Does this also need zero-initialization to avoid leaving fields like
parent_data and parent_hws as stack garbage, which could lead to memory
corruption during device probe?

> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 0a4b4696bc01c..aec617aa8e0ca 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
[ ... ]
> @@ -1638,8 +1638,8 @@ sdhci_arasan_register_sampleclk(struct sdhci_arasan_data *sdhci_arasan,
>  				struct device *dev)
>  {
>  	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
> +	struct clk_init_data sampleclk_init = {};
>  	struct device_node *np = dev->of_node;

[Severity: High]
This is a pre-existing issue, but I noticed a potential leak and dangling
pointer hazard when tearing down these clock providers.

If #clock-cells > 0, this driver registers both the sdcardclk and sampleclk
providers for the same dev->of_node via of_clk_add_provider().

During unbind, sdhci_arasan_unregister_sdclk() calls:

	of_clk_del_provider(dev->of_node);

Since of_clk_del_provider() stops after deleting the first matching provider
it finds (which would be sampleclk), does this leave the sdcardclk provider
on the global list? 

When the underlying clock is freed by devm, any subsequent DT lookup on this
node might fetch the dangling provider and return a freed struct clk pointer.
Could we be leaking a provider and device node reference here?

> -	struct clk_init_data sampleclk_init;
>  	const char *parent_clk_name;
>  	int ret;
>

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 2/2] mmc: sdhci-of-arasan: 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] Another driver in the same subsystem (meson-mx-sdio.c) suffers from the exact same uninitialized struct clk_init_data issue that this patch fixes.
- [High] The driver registers multiple clock providers for the same device node but only deletes one on teardown, leading to a leaked provider struct, a leaked device node reference, and a dangling UAF pointer in the global clock providers list.
--

--- Patch [2]: [PATCH 2/2] mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized ---
commit 34a49f083df630f25a24052b358249a2c48b6055
Author: Geert Uytterhoeven <geert+renesas@glider.be>

mmc: sdhci-of-arasan: Make sure clk_init_data is fully initialized

The clk_init_data structure contains mutually-exclusive members for
specifying clock parents. Uninitialized members can cause issues exposed by
certain stack initialization configs. This commit zeroes the struct to prevent
bugs and future breakage.

[Severity: High]
This isn't a bug introduced by this patch, but I noticed another driver in
the same subsystem suffers from the exact same uninitialized struct
clk_init_data issue that this patch fixes.

In drivers/mmc/host/meson-mx-sdio.c:meson_mx_mmc_register_clks():

	struct clk_init_data init;
	...
	init.name = devm_kasprintf(host->controller->parent, ...);
	init.ops = &meson_mx_mmc_cfg_div_ops;
	init.flags = 0;
	...

Does this also need zero-initialization to avoid leaving fields like
parent_data and parent_hws as stack garbage, which could lead to memory
corruption during device probe?

> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 0a4b4696bc01c..aec617aa8e0ca 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
[ ... ]
> @@ -1638,8 +1638,8 @@ sdhci_arasan_register_sampleclk(struct sdhci_arasan_data *sdhci_arasan,
>  				struct device *dev)
>  {
>  	struct sdhci_arasan_clk_data *clk_data = &sdhci_arasan->clk_data;
> +	struct clk_init_data sampleclk_init = {};
>  	struct device_node *np = dev->of_node;

[Severity: High]
This is a pre-existing issue, but I noticed a potential leak and dangling
pointer hazard when tearing down these clock providers.

If #clock-cells > 0, this driver registers both the sdcardclk and sampleclk
providers for the same dev->of_node via of_clk_add_provider().

During unbind, sdhci_arasan_unregister_sdclk() calls:

	of_clk_del_provider(dev->of_node);

Since of_clk_del_provider() stops after deleting the first matching provider
it finds (which would be sampleclk), does this leave the sdcardclk provider
on the global list? 

When the underlying clock is freed by devm, any subsequent DT lookup on this
node might fetch the dangling provider and return a freed struct clk pointer.
Could we be leaking a provider and device node reference here?

> -	struct clk_init_data sampleclk_init;
>  	const char *parent_clk_name;
>  	int ret;
>

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

Re: [PATCH 1/2] mmc: meson-gx: FIXME: 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] Uninitialized spinlock access in interrupt handler
--

--- Patch [1]: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized ---
commit 20368821444f654f1165c58c0816283a3774d376
Author: Geert Uytterhoeven <geert+renesas@glider.be>

mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized

This commit fully initializes the clk_init_data structure to avoid subtle
initialization issues. By ensuring all members are zeroed, it prevents bugs
when specific stack initialization configs are enabled.

> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 694bb443d5f3f..698febdcd4988 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
>   */
>  static int meson_mmc_clk_init(struct meson_host *host)
>  {
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	struct clk_mux *mux;
>  	struct clk_divider *div;
>  	char clk_name[32];

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how the
interrupt handler is registered relative to lock initialization in this driver.

In drivers/mmc/host/meson-gx-mmc.c:meson_mmc_probe(), the interrupt is
requested before the spinlock is initialized:

	ret = request_threaded_irq(host->irq, meson_mmc_irq,
				   meson_mmc_irq_thread, IRQF_ONESHOT,
				   dev_name(&pdev->dev), host);
	if (ret)
		goto err_init_clk;

	spin_lock_init(&host->lock);

If an interrupt fires immediately upon registration, the interrupt handler
can begin execution and attempt to acquire the uninitialized lock:

drivers/mmc/host/meson-gx-mmc.c:meson_mmc_irq() {
	...
	if (status & IRQ_SDIO) {
		spin_lock(&host->lock);
		__meson_mmc_enable_sdio_irq(host->mmc, 0);
		sdio_signal_irq(host->mmc);
		spin_unlock(&host->lock);
	...
}

Could this result in a lockdep warning or kernel oops if a spurious interrupt
or pending hardware event triggers before spin_lock_init() completes?

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 1/2] mmc: meson-gx: FIXME: 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] Uninitialized spinlock access in interrupt handler
--

--- Patch [1]: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized ---
commit 20368821444f654f1165c58c0816283a3774d376
Author: Geert Uytterhoeven <geert+renesas@glider.be>

mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized

This commit fully initializes the clk_init_data structure to avoid subtle
initialization issues. By ensuring all members are zeroed, it prevents bugs
when specific stack initialization configs are enabled.

> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 694bb443d5f3f..698febdcd4988 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
>   */
>  static int meson_mmc_clk_init(struct meson_host *host)
>  {
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	struct clk_mux *mux;
>  	struct clk_divider *div;
>  	char clk_name[32];

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how the
interrupt handler is registered relative to lock initialization in this driver.

In drivers/mmc/host/meson-gx-mmc.c:meson_mmc_probe(), the interrupt is
requested before the spinlock is initialized:

	ret = request_threaded_irq(host->irq, meson_mmc_irq,
				   meson_mmc_irq_thread, IRQF_ONESHOT,
				   dev_name(&pdev->dev), host);
	if (ret)
		goto err_init_clk;

	spin_lock_init(&host->lock);

If an interrupt fires immediately upon registration, the interrupt handler
can begin execution and attempt to acquire the uninitialized lock:

drivers/mmc/host/meson-gx-mmc.c:meson_mmc_irq() {
	...
	if (status & IRQ_SDIO) {
		spin_lock(&host->lock);
		__meson_mmc_enable_sdio_irq(host->mmc, 0);
		sdio_signal_irq(host->mmc);
		spin_unlock(&host->lock);
	...
}

Could this result in a lockdep warning or kernel oops if a spurious interrupt
or pending hardware event triggers before spin_lock_init() completes?

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

Re: [PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Michal Simek]

On 8/21/26 12:06, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> 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.
> 
> Hence this series aims to make sure all members are fully initialized,
> to avoid such bugs, and to prevent future breakage when converting
> drivers to a different method for specifying the parents.
> 
> Part One[1] fixed all cases that I identified to be real bugs, in
> response to a crash I saw on BeagleBone Black.
> 
> This series is the MMC subpart of Part Two, which fixes remaining cases
> that are currently harmless.  These are still fragile, and may cause
> future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Thanks for your comments!
> 
> [1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
>       initialized (part 1)"
>      https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be
> 
> Geert Uytterhoeven (2):
>    mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized


It looks like a broken series to me.

Thanks,
Michal

Re: [PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Michal Simek]

On 8/21/26 12:06, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> 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.
> 
> Hence this series aims to make sure all members are fully initialized,
> to avoid such bugs, and to prevent future breakage when converting
> drivers to a different method for specifying the parents.
> 
> Part One[1] fixed all cases that I identified to be real bugs, in
> response to a crash I saw on BeagleBone Black.
> 
> This series is the MMC subpart of Part Two, which fixes remaining cases
> that are currently harmless.  These are still fragile, and may cause
> future breakage when converting drivers to a different method for
> specifying the parents.
> 
> Thanks for your comments!
> 
> [1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
>       initialized (part 1)"
>      https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be
> 
> Geert Uytterhoeven (2):
>    mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized


It looks like a broken series to me.

Thanks,
Michal



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

Hi Michal,

On Fri, 21 Aug 2026 at 12:56, Michal Simek <michal.simek@amd.com> wrote:
> On 8/21/26 12:06, 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.
> >
> > Hence this series aims to make sure all members are fully initialized,
> > to avoid such bugs, and to prevent future breakage when converting
> > drivers to a different method for specifying the parents.
> >
> > Part One[1] fixed all cases that I identified to be real bugs, in
> > response to a crash I saw on BeagleBone Black.
> >
> > This series is the MMC subpart of Part Two, which fixes remaining cases
> > that are currently harmless.  These are still fragile, and may cause
> > future breakage when converting drivers to a different method for
> > specifying the parents.
> >
> > Thanks for your comments!
> >
> > [1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
> >       initialized (part 1)"
> >      https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be
> >
> > Geert Uytterhoeven (2):
> >    mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
>
> It looks like a broken series to me.

Doh, I made a silly mistake while filling in the correct patch prefix...

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/2] mmc: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

Hi Michal,

On Fri, 21 Aug 2026 at 12:56, Michal Simek <michal.simek@amd.com> wrote:
> On 8/21/26 12:06, 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.
> >
> > Hence this series aims to make sure all members are fully initialized,
> > to avoid such bugs, and to prevent future breakage when converting
> > drivers to a different method for specifying the parents.
> >
> > Part One[1] fixed all cases that I identified to be real bugs, in
> > response to a crash I saw on BeagleBone Black.
> >
> > This series is the MMC subpart of Part Two, which fixes remaining cases
> > that are currently harmless.  These are still fragile, and may cause
> > future breakage when converting drivers to a different method for
> > specifying the parents.
> >
> > Thanks for your comments!
> >
> > [1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
> >       initialized (part 1)"
> >      https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be
> >
> > Geert Uytterhoeven (2):
> >    mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
>
> It looks like a broken series to me.

Doh, I made a silly mistake while filling in the correct patch prefix...

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