ade9000_setup_clkout() passes NULL as the register address when
registering a divider clock. During clock registration, the common
clock framework calls clk_divider_recalc_rate(), which dereferences
the address through readl(). As a result, probing an ADE9000 configured
as a clock provider with an external input clock crashes.

CLKOUT passes CLKIN through without changing its rate. Register it as
a 1:1 fixed-factor clock, which does not require register access.

Fixes: 81de7b4619fc ("iio: adc: add ade9000 support")
Cc: stable@vger.kernel.org
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
 drivers/iio/adc/ade9000.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
index e57e24b6acdf7..4e96cc37fbedf 100644
--- a/drivers/iio/adc/ade9000.c
+++ b/drivers/iio/adc/ade9000.c
@@ -1647,8 +1647,9 @@ static int ade9000_setup_clkout(struct device *dev, struct ade9000_state *st)
 		return 0;
 
 	/* CLKOUT passes through CLKIN with divider of 1 */
-	clkout_hw = devm_clk_hw_register_divider(dev, "clkout", __clk_get_name(st->clkin),
-						 CLK_SET_RATE_PARENT, NULL, 0, 1, 0, NULL);
+	clkout_hw = devm_clk_hw_register_fixed_factor(dev, "clkout",
+						      __clk_get_name(st->clkin),
+						      CLK_SET_RATE_PARENT, 1, 1);
 	if (IS_ERR(clkout_hw))
 		return dev_err_probe(dev, PTR_ERR(clkout_hw), "Failed to register clkout");
 

base-commit: 6b9f23b5460818aaf199dda90210d5fc08d66c8f
-- 
2.25.1

On Mon, Aug 24, 2026 at 08:52:10PM +0800, Linmao Li wrote:
> ade9000_setup_clkout() passes NULL as the register address when
> registering a divider clock. During clock registration, the common
> clock framework calls clk_divider_recalc_rate(), which dereferences
> the address through readl(). As a result, probing an ADE9000 configured
> as a clock provider with an external input clock crashes.
> 
> CLKOUT passes CLKIN through without changing its rate. Register it as
> a 1:1 fixed-factor clock, which does not require register access.

Do you have HW to test? What will be the result for the internal clock case?

-- 
With Best Regards,
Andy Shevchenko

在 2026/8/24 23:08, Andy Shevchenko 写道:
> On Mon, Aug 24, 2026 at 08:52:10PM +0800, Linmao Li wrote:
>> ade9000_setup_clkout() passes NULL as the register address when
>> registering a divider clock. During clock registration, the common
>> clock framework calls clk_divider_recalc_rate(), which dereferences
>> the address through readl(). As a result, probing an ADE9000 configured
>> as a clock provider with an external input clock crashes.
>>
>> CLKOUT passes CLKIN through without changing its rate. Register it as
>> a 1:1 fixed-factor clock, which does not require register access.
> Do you have HW to test? What will be the result for the internal clock case?
No, unfortunately I do not have access to the hardware, so this is
based on code inspection only.

For the crystal oscillator case, the device tree does not provide a
clocks property. devm_clk_get_optional_enabled() therefore returns
NULL, and ade9000_setup_clkout() returns here:

         if (!device_property_present(dev, "#clock-cells") || !st->clkin)
                 return 0;

No clock provider is registered in that case. This behavior is
unchanged by the patch. The modified registration path is reached only
when an external input clock is present and the device is configured as
a clock provider.

Thanks,
Linmao
>

On Wed, Aug 26, 2026 at 10:24:18AM +0800, Linmao Li wrote:
> 
> 在 2026/8/24 23:08, Andy Shevchenko 写道:
> > On Mon, Aug 24, 2026 at 08:52:10PM +0800, Linmao Li wrote:
> > > ade9000_setup_clkout() passes NULL as the register address when
> > > registering a divider clock. During clock registration, the common
> > > clock framework calls clk_divider_recalc_rate(), which dereferences
> > > the address through readl(). As a result, probing an ADE9000 configured
> > > as a clock provider with an external input clock crashes.
> > > 
> > > CLKOUT passes CLKIN through without changing its rate. Register it as
> > > a 1:1 fixed-factor clock, which does not require register access.
> > Do you have HW to test? What will be the result for the internal clock case?
> No, unfortunately I do not have access to the hardware, so this is
> based on code inspection only.
> 
> For the crystal oscillator case, the device tree does not provide a
> clocks property. devm_clk_get_optional_enabled() therefore returns
> NULL, and ade9000_setup_clkout() returns here:
> 
>         if (!device_property_present(dev, "#clock-cells") || !st->clkin)
>                 return 0;
> 
> No clock provider is registered in that case. This behavior is
> unchanged by the patch. The modified registration path is reached only
> when an external input clock is present and the device is configured as
> a clock provider.

Then add a sentence to summarise this, something like "this change doesn't
affect the configuration with the internal clock".

-- 
With Best Regards,
Andy Shevchenko