[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180801221809.GH19257@lunn.ch>
Date: Thu, 2 Aug 2018 00:18:09 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Arun Parameswaran <arun.parameswaran@...adcom.com>
Cc: Russell King - ARM Linux <linux@...linux.org.uk>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>, netdev@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v3 7/8] net: phy: Add support to configure clock in
Broadcom iProc mdio mux
> > As Florian pointed out, the clk_ API is happy to take a NULL pointer
> > for a clock. So you don't need this last else.
> >
> > Andrew
> >
> I do return with an error from the probe if the clk_prepare_enable() fails,
> so I was calling the prepare with a valid clock.
How many times do we need to say it?
NULL is a valid clock.
int clk_prepare(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_prepare_lock(clk->core);
}
int clk_enable(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_enable_lock(clk->core);
}
clk_prepare_enable(NULL) returns 0, which is not an error.
Andrew
Powered by blists - more mailing lists