Re: [PATCH 2/2] clk: si544: add support for si549

[sashiko-bot@kernel.org]

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

New issues:
- [High] Missing validation of `i2c_get_match_data()` result leads to a NULL pointer dereference.
- [Low] Unused 'desc' field added to 'struct clk_si544'.
- [Low] Calculation functions take an unused 'data' parameter but rely on caller-initialized output structs.

Pre-existing issues:
- [High] Unconditional dereference of `client->dev.of_node` if Device Tree is not used.
- [High] Unvalidated hardware register reads can lead to a hardware divide-by-zero exception.
--

commit cd7f9cb7be2c12aa433f045f924c907e1d3f9ecc
Author: Pavel Löbl <pavel@loebl.cz>

clk: si544: add support for si549

This commit adds support for the Si549 programmable clock generator,
which differs from the Si544 in its internal oscillator frequency. It
also adds support for three speed grade variants and fixes the maximum
frequency limit for the Si544 C variant.

> diff --git a/drivers/clk/clk-si544.c b/drivers/clk/clk-si544.c
> index 09c06ecec1a52..2643546eb9405 100644
> --- a/drivers/clk/clk-si544.c
> +++ b/drivers/clk/clk-si544.c
> @@ -56,11 +58,17 @@
>  #define DELTA_M_FRAC_NUM	19
>  #define DELTA_M_FRAC_DEN	20000
>  
> +struct si544_clk_desc {
> +	unsigned long max_freq;
> +	unsigned long xo_freq;
> +};
> +
>  struct clk_si544 {
> +	const struct si544_clk_desc *desc;

[Severity: Low]
Is this desc field needed? It appears to be declared but never populated
or accessed anywhere in the driver, while chip_info is used instead.

>  	struct clk_hw hw;
>  	struct regmap *regmap;
>  	struct i2c_client *i2c_client;
> -	unsigned long  max_freq;
> +	const struct si544_clk_desc *chip_info;
>  };
>  #define to_clk_si544(_hw)	container_of(_hw, struct clk_si544, hw)

[ ... ]

> @@ -193,14 +204,15 @@ static bool is_valid_frequency(const struct clk_si544 *data,
>  	if (frequency < SI544_MIN_FREQ)
>  		return false;
>  
> -	return frequency <= data->max_freq;
> +	return frequency <= data->chip_info->max_freq;
>  }
>  
>  /* Calculate divider settings for a given frequency */
> -static int si544_calc_muldiv(struct clk_si544_muldiv *settings,
> -	unsigned long frequency)
> +static int si544_calc_muldiv(const struct clk_si544 *data,
> +	struct clk_si544_muldiv *settings, unsigned long frequency)
>  {
>  	u64 vco;
> +	u32 fxo = settings->xo_freq;

[Severity: Low]
Does this code need to read xo_freq from the settings output struct rather
than utilizing the explicitly provided data context pointer? The data
parameter seems completely unused in this function.

>  	u32 ls_freq;
>  	u32 tmp;
>  	u8 res;

[ ... ]

> @@ -254,19 +266,20 @@ static int si544_calc_muldiv(struct clk_si544_muldiv *settings,
>  }
>  
>  /* Calculate resulting frequency given the register settings */
> -static unsigned long si544_calc_center_rate(
> +static unsigned long si544_calc_center_rate(const struct clk_si544 *data,
>  		const struct clk_si544_muldiv *settings)
>  {
>  	u32 d = settings->hs_div * BIT(settings->ls_div_bits);
> +	u32 fxo = settings->xo_freq;
>  	u64 vco;
>  
>  	/* Calculate VCO from the fractional part */
> -	vco = (u64)settings->fb_div_frac * FXO;
> -	vco += (FXO / 2);
> +	vco = (u64)settings->fb_div_frac * fxo;
> +	vco += (fxo / 2);
>  	vco >>= 32;
>  
>  	/* Add the integer part of the VCO frequency */
> -	vco += (u64)settings->fb_div_int * FXO;
> +	vco += (u64)settings->fb_div_int * fxo;
>  
>  	/* Apply divider to obtain the generated frequency */
>  	do_div(vco, d);

[Severity: High]
This is a pre-existing issue, but could this do_div() trigger a hardware
divide-by-zero exception?

If the hardware is faulty or unresponsive, si544_get_muldiv() might read
0 for SI544_REG_HS_DIV from I2C without validating it. This would cause
settings->hs_div to evaluate to 0, which then results in d being 0 here.

>  	return vco;
>  }

[ ... ]

> @@ -446,7 +460,7 @@ static int si544_probe(struct i2c_client *client)
>  	init.num_parents = 0;
>  	data->hw.init = &init;
>  	data->i2c_client = client;
> -	data->max_freq = (uintptr_t)i2c_get_match_data(client);
> +	data->chip_info = i2c_get_match_data(client);

[Severity: High]
Can i2c_get_match_data() return NULL here if the device is instantiated via
sysfs new_device with a generic fallback name or driver_override?

If so, storing NULL in data->chip_info could lead to a NULL pointer
dereference, as it is dereferenced unconditionally in si544_get_muldiv():

drivers/clk/clk-si544.c:si544_get_muldiv() {
    ...
    settings->xo_freq = data->chip_info->xo_freq;
    ...
}

Should the return value of i2c_get_match_data() be validated?

>  
>  	if (of_property_read_string(client->dev.of_node, "clock-output-names",
>  			&init.name))

[Severity: High]
This is a pre-existing issue, but does this fallback path unconditionally
dereference client->dev.of_node if Device Tree is not used?

If the device is instantiated on a non-DT system (e.g. via I2C board info,
ACPI, or sysfs instantiation), client->dev.of_node will be NULL.
of_property_read_string() will return an error, causing the fallback path
to dereference client->dev.of_node->name unconditionally:

drivers/clk/clk-si544.c:si544_probe() {
    ...
    if (of_property_read_string(client->dev.of_node, "clock-output-names",
            &init.name))
        init.name = client->dev.of_node->name;
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701130927.3858536-1-pavel@loebl.cz?part=2