On Thu, Jan 08, 2026 at 05:58:42PM -0600, David Lechner wrote: > 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.
Yeah, so there's a few threads over the past few months that need to be read here, before we decide if there's anything we can do. At least some of it all is covered in: https://lore.kernel.org/u-boot/[email protected]/ (and the rest of the thread), and I think there's others as well if you search around for clk and Andrew. -- Tom
signature.asc
Description: PGP signature
