Re: [PATCH] gpu: host1x: clk_round_rate() can return a zero upon error

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Mon, Dec 09, 2013 at 06:00:12PM -0800, Paul Walmsley wrote:
> 
> Treat both negative and zero return values from clk_round_rate() as
> errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather than a
> signed type, since some clock sources can generate rates higher than
> (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of zero
> will be considered a error.  All other values will be considered valid
> rates.  The comparison against values less than 0 is kept to preserve
> the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley <pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Arto Merilainen <amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Terje Bergström <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> Applies on v3.13-rc3.  See also:
> 
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
> 
>  drivers/gpu/drm/tegra/hdmi.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> index 0cd9bc2056e8..8cf9d3aeb0cd 100644
> --- a/drivers/gpu/drm/tegra/hdmi.c
> +++ b/drivers/gpu/drm/tegra/hdmi.c
> @@ -959,7 +959,7 @@ static int tegra_output_hdmi_check_mode(struct tegra_output *output,
>  	parent = clk_get_parent(hdmi->clk_parent);
> 
>  	err = clk_round_rate(parent, pclk * 4);
> -	if (err < 0)
> +	if (err <= 0)
>  		*status = MODE_NOCLOCK;
>  	else
>  		*status = MODE_OK;

Looks good. Out of curiosity, what are the plans on how to change the
clk_round_rate() API. I assume that at some point it will be modified
to return an unsigned long? At that point we'll need to update all
drivers as well to make sure the signed variables don't overflow.

Perhaps unsigned long long would be a better choice for future
compatibility?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]