From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Date: Mon, 15 Jan 2018 16:35:43 +0000 Subject: Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_ Message-Id: <20180115163543.GA10657@lenoch> List-Id: References: <7719b4e7-1081-6fa4-6f14-f45cf062482d@users.sourceforge.net> <20180115134101.GA6711@lenoch> <1ebb5ac5-aa4d-7c19-94db-210b518d562f@users.sourceforge.net> <20180115160522.GA2672@lenoch> <11eaf92d-3928-531f-35e8-fb5a60ff03e3@users.sourceforge.net> In-Reply-To: <11eaf92d-3928-531f-35e8-fb5a60ff03e3@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: SF Markus Elfring Cc: linux-omap@vger.kernel.org, Lee Jones , Tony Lindgren , LKML , kernel-janitors@vger.kernel.org On Mon, Jan 15, 2018 at 05:21:47PM +0100, SF Markus Elfring wrote: > >>>> @@ -258,7 +256,6 @@ static int usbtll_omap_probe(struct platform_dev= ice *pdev) > >>>> GFP_KERNEL); > >>>> if (!tll->ch_clk) { > >>>> ret =3D -ENOMEM; > >>>> - dev_err(dev, "Couldn't allocate memory for channel clocks\n"); > >>> > >>> I'd either leave this one, just to know which allocation failed or be= tter use > >>> something like this =E2=80=A6 > >> > >> Are you aware on the structure for a Linux allocation failure report? > >=20 > > Just created one (not OMAP and not this driver, but that does not matte= r now): >=20 > Thanks for your example. >=20 > > ---[ end trace 3c79eadf2363e939 ]--- > > max9867: probe of 1-0018 failed with error -12 > >=20 > > driver was instructed to alloc insane number of bytes using devm_kzallo= c in > > max9867_i2c_probe. > > Now, if probe function calls devm_kzalloc two times and one of them fai= ls, > > you cannot easily say which one without looking at assembly listing. >=20 > Will this situation change with any other implementation for such backtra= ces? How much that situation changes depends mainly on that very person who is sending bugreport and his/her ability and willigness to eventually change said implementation. In the other words your question (presumably) expects a world of ideal backtraces, which is (so far) rarely the case. Anyway, if we agree to change the way we allocate driver data here, the iss= ue this debate is about will no longer exist. Best reards, 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