Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966818AbeAOQfs (ORCPT + 1 other); Mon, 15 Jan 2018 11:35:48 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:51718 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966302AbeAOQfq (ORCPT ); Mon, 15 Jan 2018 11:35:46 -0500 Date: Mon, 15 Jan 2018 17:35:43 +0100 From: Ladislav Michl To: SF Markus Elfring Cc: linux-omap@vger.kernel.org, Lee Jones , Tony Lindgren , LKML , kernel-janitors@vger.kernel.org Subject: Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_probe() Message-ID: <20180115163543.GA10657@lenoch> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <11eaf92d-3928-531f-35e8-fb5a60ff03e3@users.sourceforge.net> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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_device *pdev) > >>>> GFP_KERNEL); > >>>> if (!tll->ch_clk) { > >>>> ret = -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 better use > >>> something like this … > >> > >> Are you aware on the structure for a Linux allocation failure report? > > > > Just created one (not OMAP and not this driver, but that does not matter now): > > Thanks for your example. > > > ---[ end trace 3c79eadf2363e939 ]--- > > max9867: probe of 1-0018 failed with error -12 > > > > driver was instructed to alloc insane number of bytes using devm_kzalloc in > > max9867_i2c_probe. > > Now, if probe function calls devm_kzalloc two times and one of them fails, > > you cannot easily say which one without looking at assembly listing. > > Will this situation change with any other implementation for such backtraces? 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 issue this debate is about will no longer exist. Best reards, ladis