On 12/17/25 5:37 AM, Michal Simek wrote: > As it is visible clk_get_rate() is returning ulong: > ulong clk_get_rate(struct clk *clk); > > Also struct clk_ops is defining it as > ulong (*get_rate)(struct clk *clk); > > That's why return 0 rate when ops->get_rate is not implemented which is > the same value as is return when clock is not valid. > > Signed-off-by: Michal Simek <[email protected]> > --- > > Another alternative is obviously also return only long and fix all > get_rate calls.
I noticed this oddness too recently while working on some clock drivers. I suspect most people don't realize that clk get rate functions can return an error because the type is unsigned and they don't read the documentation. The driver I was working on had a number of bugs due to this. Changing the type to signed seems sensible. But I do wonder if there are some GHz clock rates > INT_MAX on 32-bit platforms. Changing the type could be problematic in that case. If that is the case, the next best thing could be something similar to IS_ERR() and PTR_ERR() for checking the return value of clk rate functions, e.g RATE_IS_ERR() and RATE_ERR(). > --- > drivers/clk/clk-uclass.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c > index 4420651f765c..bca818530d4c 100644 > --- a/drivers/clk/clk-uclass.c > +++ b/drivers/clk/clk-uclass.c > @@ -490,7 +490,7 @@ ulong clk_get_rate(struct clk *clk) > ops = clk_dev_ops(clk->dev); > > if (!ops->get_rate) > - return -ENOSYS; There are a number of places checking rates for this return value so I think changing it could unintentionally break things. > + return 0; > > return ops->get_rate(clk); > }
