From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Date: Mon, 27 Nov 2017 17:44:54 +0000 Subject: Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions Message-Id: <20171127174454.GA18851@lenoch> List-Id: References: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> In-Reply-To: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: SF Markus Elfring Cc: "Andrew F. Davis" , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Arvind Yadav , Bartlomiej Zolnierkiewicz , Tomi Valkeinen , LKML , kernel-janitors@vger.kernel.org On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote: > >> Omit an extra message for a memory allocation failure in these functio= ns. > =E2=80=A6 > > nak, unlike many others, these message give extra info on which > > allocation failed, that can be useful. >=20 > Can a default allocation failure report provide the information > which you might expect so far? You should be able to answer that question yourself. And if you are unable to do so, just do not sent changes pointed by any code analysis tools. As a side note, if you look at whole call chain, you'll find quite some room for optimizations - look how dev and pdev are used. That also applies to other patches. Best regards, ladis -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Date: Mon, 27 Nov 2017 17:44:54 +0000 Subject: Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions Message-Id: <20171127174454.GA18851@lenoch> List-Id: References: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> In-Reply-To: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: SF Markus Elfring Cc: "Andrew F. Davis" , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Arvind Yadav , Bartlomiej Zolnierkiewicz , Tomi Valkeinen , LKML , kernel-janitors@vger.kernel.org On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote: > >> Omit an extra message for a memory allocation failure in these functio= ns. > =E2=80=A6 > > nak, unlike many others, these message give extra info on which > > allocation failed, that can be useful. >=20 > Can a default allocation failure report provide the information > which you might expect so far? You should be able to answer that question yourself. And if you are unable to do so, just do not sent changes pointed by any code analysis tools. As a side note, if you look at whole call chain, you'll find quite some room for optimizations - look how dev and pdev are used. That also applies to other patches. Best regards, ladis From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Subject: Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions Date: Mon, 27 Nov 2017 18:44:54 +0100 Message-ID: <20171127174454.GA18851@lenoch> References: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <502de06b-ca86-d0ff-bd50-d260fbe46fe5@users.sourceforge.net> Sender: linux-kernel-owner@vger.kernel.org To: SF Markus Elfring Cc: "Andrew F. Davis" , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Arvind Yadav , Bartlomiej Zolnierkiewicz , Tomi Valkeinen , LKML , kernel-janitors@vger.kernel.org List-Id: linux-omap@vger.kernel.org On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote: > >> Omit an extra message for a memory allocation failure in these functions. > … > > nak, unlike many others, these message give extra info on which > > allocation failed, that can be useful. > > Can a default allocation failure report provide the information > which you might expect so far? You should be able to answer that question yourself. And if you are unable to do so, just do not sent changes pointed by any code analysis tools. As a side note, if you look at whole call chain, you'll find quite some room for optimizations - look how dev and pdev are used. That also applies to other patches. Best regards, ladis