From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3492FCCD1AB for ; Mon, 20 Oct 2025 11:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZGTcwx4IHNOiss2uaKQt1/MHVnmfljsVIpa35dYGyzU=; b=UfIy0ZKjxIOFHO 9pDKbH9sSGj5tD3h9cDJxHoXiSGMSFehsuFf6HTm7+6ZTUFNqoxsxi3zsNXyBr4t9d7GqnA6jJIqG Q/0ZTTvGLLt8kApgf54LKHSu0KM+iCn5aXnAgYpoKj+teGOZu/ZpZjkPaU3QhYSUhdYO6Z9zuMw5V GeVIagmOeVtQpXL3tGOMHrQbSPV5JNMzKCFVA4jxrwuIzVuVN2PSP25qODcInNh3o2q8RMD/I3EL/ GmeFeWmD9+/bPyQcVQdU+9QxT7VAi6mkbjIl3viFzDPVonubosfJoRleZGd0CKjg9tYMlNPza3G6M o3K8X/87oBHnvJTh/UQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vAoVt-0000000D9Q3-3flf; Mon, 20 Oct 2025 11:57:22 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uWuEi-00000007s3v-1VNK; Wed, 02 Jul 2025 09:58:42 +0000 Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4bXFdQ6LTjz6L55h; Wed, 2 Jul 2025 17:55:38 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id B5DAB1404FD; Wed, 2 Jul 2025 17:58:31 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 2 Jul 2025 11:58:28 +0200 Date: Wed, 2 Jul 2025 10:58:26 +0100 From: Jonathan Cameron To: Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= CC: Jonathan Cameron , Waqar Hameed , Vignesh Raghavendra , "Julien Panis" , William Breathitt Gray , "Linus Walleij" , Bartosz Golaszewski , Peter Rosin , David Lechner , Nuno =?ISO-8859-1?Q?S=E1?= , Andy Shevchenko , Cosmin Tanislav , "Lars-Peter Clausen" , Michael Hennerich , Matthias Brugger , AngeloGioacchino Del Regno , Matteo Martelli , Heiko Stuebner , Francesco Dolcini , =?ISO-8859-1?Q?Jo=E3o?= Paulo =?ISO-8859-1?Q?Gon=E7alves?= , Hugo Villeneuve , Subhajit Ghosh , Mudit Sharma , Gerald Loacker , Song Qiang , Crt Mori , Dmitry Torokhov , Ulf Hansson , Karol Gugala , Mateusz Holenko , Gabriel Somlo , Joel Stanley , Claudiu Manoil , Vladimir Oltean , Wei Fang , Clark Wang , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vinod Koul , Kishon Vijay Abraham I , Krzysztof Kozlowski , Alim Akhtar , Sebastian Reichel , "Neil Armstrong" , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Han Xu , Haibo Chen , Yogesh Gaur , Mark Brown , Avri Altman , Bart Van Assche , "James E.J. Bottomley" , "Martin K. Petersen" , Souradeep Chowdhury , Greg Kroah-Hartman , Liam Girdwood , "Peter Ujfalusi" , Bard Liao , Ranjani Sridharan , Daniel Baluta , Kai Vehmanen , Pierre-Louis Bossart , Jaroslav Kysela , "Takashi Iwai" , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , , , , , , , , , , , , , , , , , , , , , , , , , "Joe Perches" , Andy Whitcroft , "Dwaipayan Ray" , Lukas Bulwahn Subject: Re: [PATCH] Remove error prints for devm_add_action_or_reset() Message-ID: <20250702105826.0000315e@huawei.com> In-Reply-To: References: <20250701185519.1410e831@jic23-huawei> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To frapeml500008.china.huawei.com (7.182.85.71) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250702_025840_678206_EEE540ED X-CRM114-Status: GOOD ( 42.05 ) X-Mailman-Approved-At: Mon, 20 Oct 2025 04:56:36 -0700 X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Wed, 2 Jul 2025 08:54:48 +0200 Uwe Kleine-K=F6nig wrote: > Hello Jonathan, > = > On Tue, Jul 01, 2025 at 06:55:19PM +0100, Jonathan Cameron wrote: > > On Tue, 1 Jul 2025 19:44:17 +0200 > > Uwe Kleine-K=F6nig wrote: > > = > > > On Tue, Jul 01, 2025 at 05:03:33PM +0200, Waqar Hameed wrote: = > > > > drivers/pwm/pwm-meson.c | 3 +-- = > > > = > > > Looking at this driver I tried the following: = > > = > > I'm not sure what we actually want here. > > = > > My thought when suggesting removing instances of this > > particular combination wasn't saving on code size, but rather just > > general removal of pointless code that was getting cut and > > paste into new drivers and wasting a tiny bit of review bandwidth. > > I'd consider it bad practice to have patterns like > > = > > void *something =3D kmalloc(); > > if (!something) > > return dev_err_probe(dev, -ENOMEM, ..); > > = > > and my assumption was people would take a similar view with > > devm_add_action_or_reset(). > > > > It is a bit nuanced to have some cases where we think prints > > are reasonable and others where they aren't so I get your > > point about consistency. = > = > The problem I see is that there are two classes of functions: a) Those > that require an error message and b) those that don't. Class b) consists > of the functions that can only return success or -ENOMEM and the > functions that emit an error message themselves. (And another problem I > see is that for the latter the error message is usually non-optimal > because the function doesn't know the all details of the request. See my > reply to Andy for more details about that rant.) > = > IMHO what takes away the review bandwidth is that the reviewer has to > check which class the failing function is part of. If this effort > results in more driver authors not adding an error message after > devm_add_action_or_reset() that's nice, but in two months I have > forgotten the details of this discussion and I have to recheck if > devm_add_action_or_reset() is part of a) or b) and so the burden is > still on me. Maybe this is a job for checkpatch, at least for the common cases. There is already a check for kmalloc etc. https://elixir.bootlin.com/linux/v6.16-rc4/source/scripts/checkpatch.pl#L64= 42 +CC Joe (who wrote the allocation functions test years ago) and other check= patch folk. > = > So to give my answer on your question "What do we actually want here?": > Please let us get rid of the need to care for a) or b). > = > > The code size reduction is nice so I'd not be against it as an extra > > if the reduction across a kernel builds is significant and enough > > people want to keep these non printing prints. = > = > To complete implementing my wish all API functions would need to stop to > emit an error message. Unfortunately that isn't without downsides > because the result is that there are more error strings and so the > kernel size is increased. So you have to weight if you prefer individual > error messages and easier review/maintenance at the cost of a bigger > binary size and more dev_err_probe() calls in drivers eating vertical > space in your editor. > = > I know on which side I am, but I bet we won't find agreement about that > in the kernel community ... > = > Best regards > Uwe > = _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip