Message ID | 04cf79a5-df91-d8c2-83b2-ad9e9130ee7a@users.sourceforge.net (mailing list archive) |
---|---|
State | Changes Requested, archived |
Delegated to: | Stephen Boyd |
Headers | show |
On Wed, Sep 14, 2016 at 10:01 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Wed, 14 Sep 2016 21:17:18 +0200 > > Omit an extra message for a memory allocation failure in this function. > > Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 15 Sep 2016 21:07:17 Geert Uytterhoeven wrote: > On Wed, Sep 14, 2016 at 10:01 PM, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Wed, 14 Sep 2016 21:17:18 +0200 > > > > Omit an extra message for a memory allocation failure in this function. > > > > Link: > > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refacto > > r_Strings-WSang_0.pdf > > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> There are two other memory allocation failures printed by drivers in the same directory that, you'll get my ack if you extend this patch to remove the three messages in one go.
On Thu, Sep 15, 2016 at 10:13:17PM +0300, Laurent Pinchart wrote: > On Thursday 15 Sep 2016 21:07:17 Geert Uytterhoeven wrote: > > On Wed, Sep 14, 2016 at 10:01 PM, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > > Date: Wed, 14 Sep 2016 21:17:18 +0200 > > > > > > Omit an extra message for a memory allocation failure in this function. > > > > > > Link: > > > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refacto > > > r_Strings-WSang_0.pdf > > > > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > > There are two other memory allocation failures printed by drivers in the same > directory that, you'll get my ack if you extend this patch to remove the three > messages in one go. I agree.
>>> Omit an extra message for a memory allocation failure in this function. >>> >>> Link: >>> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refacto >>> r_Strings-WSang_0.pdf >>> >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > > There are two other memory allocation failures printed by drivers in the same > directory that, you'll get my ack Does this kind of feedback express a general acceptance for the deletion of similar error messages? > if you extend this patch to remove the three messages in one go. Does this wish influence the handling of suggested changes for the source file "drivers/clk/renesas/clk-mstp.c" anyhow? https://patchwork.kernel.org/patch/9332363/ Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 15 Sep 2016 22:17:41 SF Markus Elfring wrote: > >>> Omit an extra message for a memory allocation failure in this function. > >>> > >>> Link: > >>> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refact > >>> or_Strings-WSang_0.pdf > >>> > >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > >> > >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > > There are two other memory allocation failures printed by drivers in the > > same directory that, you'll get my ack > > Does this kind of feedback express a general acceptance for the deletion > of similar error messages? No, it's my opinion only. > > if you extend this patch to remove the three messages in one go. > > Does this wish influence the handling of suggested changes for the source > file "drivers/clk/renesas/clk-mstp.c" anyhow? > https://patchwork.kernel.org/patch/9332363/ Yes, please submit a new version of this patch that removes all the memory allocation error messages from drivers/clk/renesas/ in one go.
>> Does this wish influence the handling of suggested changes for the source >> file "drivers/clk/renesas/clk-mstp.c" anyhow? >> https://patchwork.kernel.org/patch/9332363/ > > Yes, please submit a new version of this patch that removes all the memory > allocation error messages from drivers/clk/renesas/ in one go. I find this kind of feedback a bit surprising and it seems to be promising to increase software development in this design direction. Have you got any corresponding scripts for the semantic patch language prepared to make such a source code adjustment safer (and a bit more convenient with the help of the Coccinelle software)? I am also curious on how the change acceptance will evolve for the other three update steps from this patch series when this one indicates further software update opportunities already. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/clk/renesas/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c index 9375777..1fdc44b 100644 --- a/drivers/clk/renesas/clk-mstp.c +++ b/drivers/clk/renesas/clk-mstp.c @@ -171,7 +171,6 @@ static void __init cpg_mstp_clocks_init(struct device_node *np) if (group == NULL || clks == NULL) { kfree(group); kfree(clks); - pr_err("%s: failed to allocate group\n", __func__); return; }