[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180102225955.GL7997@codeaurora.org>
Date: Tue, 2 Jan 2018 14:59:55 -0800
From: Stephen Boyd <sboyd@...eaurora.org>
To: Paul Cercueil <paul@...pouillou.net>
Cc: Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Marc Zyngier <marc.zyngier@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Lee Jones <lee.jones@...aro.org>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/6] clk: ingenic: Add JZ47xx TCU clocks driver
On 01/02, Paul Cercueil wrote:
> >> + goto err_free_tcu;
> >> + }
> >> +
> >> + tcu->clocks.clk_num = nb_clks;
> >> + tcu->clocks.clks = kcalloc(nb_clks, sizeof(struct clk *),
> >>GFP_KERNEL);
> >> + if (!tcu->clocks.clks) {
> >> + pr_err("%s: cannot allocate memory\n", __func__);
> >
> >We don't need allocation error messages. Please run checkpatch.
>
> I did run checkpatch, which warned about this, but that's a false
> positive to me.
> The callback passed to CLK_OF_DECLARE() has a return type void, so
> there's no
> way I can return -ENOMEM, and I don't want the error to be unnoticed.
The kernel typically spews a bunch of information when an
allocation error happens, so your pr_err() will be lost in the
spew, which is why it's not really necessary.
>
> About the other remarks - I agree with you, I'll fix these in the V2.
>
Ok.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists