[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2d88272-2465-4fcf-b89d-b515a1fbee7f@tuxon.dev>
Date: Sat, 6 Dec 2025 16:31:03 +0200
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Brian Masney <bmasney@...hat.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Maxime Ripard <mripard@...nel.org>,
Conor Dooley <conor@...nel.org>, Dan Carpenter <dan.carpenter@...aro.org>
Cc: linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v3 2/4] clk: microchip: core: correct return value on
*_get_parent()
On 12/5/25 21:46, Brian Masney wrote:
> roclk_get_parent() and sclk_get_parent() has the possibility of
> returning -EINVAL, however the framework expects this call to always
> succeed since the return value is unsigned.
>
> If there is no parent map defined, then the current value programmed in
> the hardware is used. Let's use that same value in the case where
> -EINVAL is currently returned.
>
> This index is only used by clk_core_get_parent_by_index(), and it
> validates that it doesn't overflow the number of available parents.
>
> Reported-by: kernel test robot <lkp@...el.com>
I'm getting this from checkpatch:
Applying: clk: microchip: core: correct return value on *_get_parent()
[Checking commit] 910546c58dc2 clk: microchip: core: correct return value
on *_get_parent()
[Checkpatch] WARNING: Reported-by: should be immediately followed by
Closes: with a URL to the report
#17:
Reported-by: kernel test robot <lkp@...el.com>
Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> Closes: https://lore.kernel.org/r/202512050233.R9hAWsJN-lkp@intel.com/
> Signed-off-by: Brian Masney <bmasney@...hat.com>
Other than the above:
Reviewed-by: Claudiu Beznea <claudiu.beznea@...on.dev>
Powered by blists - more mailing lists