On 03/18/2015 07:02 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [150318 00:06]:
On 03/17/2015 08:38 PM, Tony Lindgren wrote:
* Mike Turquette <mturquette@xxxxxxxxxx> [150306 11:18]:
Quoting Tero Kristo (2015-02-25 11:04:18)
There is a case where NULL can be a valid return value for
ti_clk_get_reg_addr, specifically the case where both the provider index
and register offsets are zero. In this case, the current error checking
against a NULL pointer will fail. Thus, change the API to return a
ERR_PTR value in an error case, and change all the users of this API to
check against IS_ERR instead.
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
Cc: Michael Turquette <mturquette@xxxxxxxxxx>
Looks good to me.
...
---
drivers/clk/ti/apll.c | 5 +++--
drivers/clk/ti/autoidle.c | 2 +-
drivers/clk/ti/clk.c | 7 ++++---
drivers/clk/ti/divider.c | 4 ++--
drivers/clk/ti/dpll.c | 6 +++---
drivers/clk/ti/gate.c | 4 ++--
drivers/clk/ti/interface.c | 2 +-
drivers/clk/ti/mux.c | 4 ++--
8 files changed, 18 insertions(+), 16 deletions(-)
Can this patch be queued separately by Mike or is there some
dependency to this series?
Without this patch, patch #10 in the set causes a boot failure on omap3,
because the specific NULL value is returned for iva2_ck and the clock
register fails. This in turn breaks hwmod registration because iva2_ck is
missing.
Oh OK.
I would just queue this patch as part of this series to avoid any trouble.
Can this patch be applied separately before this series or does
it cause other problems? If it can be separated, Mike can maybe put it
into an immutable branch that I can merge in too.
Yea, that works also if Mike is okay with it.
-Tero
Other than wondering about the above and the dts related comments,
this series works for me with PM tests.
I hope to post a series with the dts related comments fixed later today.
Yes I'll take a look, thanks for doing that.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
