Hi Michael, > -----Original Message----- > From: Michael Nazzareno Trimarchi <[email protected]> > Sent: Thursday, July 25, 2024 5:26 PM > To: Z.Q. Hou <[email protected]>; Simon Glass <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH] clk: fix ccf_clk_get_rate > > Hi > > On Thu, Jul 25, 2024 at 10:53 AM Z.Q. Hou <[email protected]> wrote: > > > > Hi Michael, > > > > > -----Original Message----- > > > From: Michael Nazzareno Trimarchi <[email protected]> > > > Sent: Thursday, July 25, 2024 3:32 PM > > > To: Z.Q. Hou <[email protected]> > > > Cc: [email protected]; [email protected]; [email protected]; > > > [email protected] > > > Subject: Re: [PATCH] clk: fix ccf_clk_get_rate > > > > > > Hi > > > > > > On Thu, Jul 25, 2024 at 9:16 AM Zhiqiang Hou <[email protected]> > > > wrote: > > > > > > > > From: Hou Zhiqiang <[email protected]> > > > > > > > > As the type of return value is 'ulong', when clk_get_by_id() > > > > failed, it should return 0 to indicate the get_rate operation doesn't > succeed. > > > > > > > > > > I understand your point here but the clk_get_rate that can call the > > > ccf clk_get_rate can already return -ENOSYS. > > > > will also fix it. > > > > Is there any usage of the error set on the latest bit of the clock? We need to > be sure that this is correct use accross the uboot. The clk-uclass define the > error that can return
The problem is this function's return value is 'ulong', if use the error set, the caller will treat it as a good value instead of a error number. There are several APIs have the same problem. 2 methods to fix it: 1. keep the API's prototype, and use '0' to indicate error condition, but a real '0' return value is also considered as error. 2. Change the return type to like 'long long int', and use a negative error number to indicate error condition. Need to update the check of return value for all the callers. Any suggestion? Thanks, Zhiqiang
