[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Wyk9BYR3cnfm=9tBh=XBxEP=udMTeaEYPzAqa5m8x=yg@mail.gmail.com>
Date: Tue, 1 Dec 2020 08:05:18 -0800
From: Doug Anderson <dianders@...omium.org>
To: Chris Ruehl <chris.ruehl@...ys.com.hk>
Cc: Kishon Vijay Abraham I <kishon@...com>,
Vinod Koul <vkoul@...nel.org>,
Heiko Stuebner <heiko@...ech.de>,
Ulf Hansson <ulf.hansson@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>
Subject: Re: [PATCH] phy: rockchip-emmc: emmc_phy_init() always return 0
Hi,
On Mon, Nov 30, 2020 at 7:10 PM Chris Ruehl <chris.ruehl@...ys.com.hk> wrote:
>
> rockchip_emmc_phy_init() return variable is not set with the error value
> if clk_get() failed. The debug message print 0 on error and the function
> always return 0.
> Fix it using PTR_ERR().
>
> Fixes: 52c0624a10cce phy: rockchip-emmc: Set phyctrl_frqsel based on card clock
>
> Signed-off-by: Chris Ruehl <chris.ruehl@...ys.com.hk>
> ---
> drivers/phy/rockchip/phy-rockchip-emmc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c b/drivers/phy/rockchip/phy-rockchip-emmc.c
> index 48e2d75b1004..75faee5c0d27 100644
> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
> @@ -253,6 +253,7 @@ static int rockchip_emmc_phy_init(struct phy *phy)
> */
> rk_phy->emmcclk = clk_get(&phy->dev, "emmcclk");
> if (IS_ERR(rk_phy->emmcclk)) {
> + ret = PTR_ERR(rk_phy->emmcclk);
I'm pretty sure your patch isn't correct and it would break use cases.
Is it fixing some bug that you're aware of, or you found it via code
inspection?
Specifically:
* The big comment block in this function says that the clock is
optional and that we're ignoring errors.
* The printout in this function is "dbg" level, which is an extra
indication that we aren't concerned with these errors.
Arguably the code could be made better. If you want to improve it,
you could check for just the error we expect if the clock isn't
specified (probably -ENODEV, but you should check) and treat all other
failures as real errors.
-Doug
Powered by blists - more mailing lists