Message ID | 20231107202818.4005791-8-u.kleine-koenig@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp3365551vqg; Thu, 16 Nov 2023 09:22:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IG+RAUq7W0P72ztEWx2gpqtlJFYrsmzBCmVQAC4CXyCSO44bbQgYpV087tdC2Bfn1Txp1lv X-Received: by 2002:a17:902:8302:b0:1cc:446c:770c with SMTP id bd2-20020a170902830200b001cc446c770cmr2560402plb.33.1700155338174; Thu, 16 Nov 2023 09:22:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700155338; cv=none; d=google.com; s=arc-20160816; b=zFHWbUXxuBJdVyV4RENIQIxMVYAtQJKnemXOO5WjpEiC/5dqX3Sh6PiWATb8LO8KI2 7jKx1FApyzidQ5jNTy+Fo2eyHL3rXlC9VJcc/dBYfgfoYYuVWOzK9QZs2ovlBsiFlXTu kiWbF++H9Kb8v95fyF24AxdQw4FBSIRj4Gbw2oSWVvnoAXxzXic5SV8PXSCOB82Jtnk7 RaSibHMdHWSHNTcJZoiSJ8aDbJLWVtknesuSJ3JLNdD7hJ1M440rIEA+AEJtZ52xSr4U pBQV5g0wFte42VwG1mACYg6jb7elKKIvkEytLNonlmyh0p8npl8OIcWQowa+kf70Qs0m 34fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=d7PTuwRRGAUs8jPLgWpVXxtD7X1izfc16/XQuM+2fKA=; fh=5CMTiJwyROOVJqu1EFOwyC2+DMvNDWeBONNDIzwPQy8=; b=rDBGEcTHviIv4aX2/Edxg3n4oz47eE6AaoawAH8XDoJ87tcdrDxi00vrZuDSy1Lc8Z J56jeubyNbWHTPevp544LwiSPiCk2cru9UK/DixkSM5REmayDb9UW71RfYjrQyVD6G43 57T6mT9MtAbr/cP/BTL9wOrAdzdXiPUqi4aYDhCEk68Eg3/ESgEFO+5Qm7GN6KPzrCn+ pDM1hsWR99eiz/i9ho8bQtR+3n6K0NiNecWbKSbQsM5zIALqcrCJnDNO/b4i8C+iKrjV F/7wQMGONCFMMHGN4yPaEe0IEVIpvikSTH/k/R4lMzJaa51u56erJD57m+V8CQYIBkVS wVsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id jj13-20020a170903048d00b001cc4fbe9281si12206773plb.582.2023.11.16.09.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 09:22:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id CEA77823627E; Thu, 16 Nov 2023 09:22:15 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231281AbjKPRWC (ORCPT <rfc822;jaysivo@gmail.com> + 30 others); Thu, 16 Nov 2023 12:22:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229634AbjKPRWB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Nov 2023 12:22:01 -0500 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [IPv6:2a0a:edc0:2:b01:1d::104]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E4C31A8 for <linux-kernel@vger.kernel.org>; Thu, 16 Nov 2023 09:21:58 -0800 (PST) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ukl@pengutronix.de>) id 1r3g3w-0004am-KM for linux-kernel@vger.kernel.org; Thu, 16 Nov 2023 18:21:56 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <ukl@pengutronix.de>) id 1r3g3w-009V4F-7j for linux-kernel@vger.kernel.org; Thu, 16 Nov 2023 18:21:56 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from <ukl@pengutronix.de>) id 1r3g3v-002jzQ-TP for linux-kernel@vger.kernel.org; Thu, 16 Nov 2023 18:21:55 +0100 Date: Tue, 7 Nov 2023 21:28:26 +0100 From: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de> To: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: kernel@pengutronix.de, linux-kernel@vger.kernel.org Subject: [PATCH 7/8] intel_th: Convert to platform remove callback returning void Message-ID: <20231107202818.4005791-8-u.kleine-koenig@pengutronix.de> In-Reply-To: <20231107202818.4005791-1-u.kleine-koenig@pengutronix.de> References: <20231107202818.4005791-1-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Developer-Signature: v=1; a=openpgp-sha256; l=1776; i=u.kleine-koenig@pengutronix.de; h=from:subject:message-id; bh=H3WlFhNwTWEIC3GKjb4EEIvAB33g9aMn3hNOG1gVFO0=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBlVk+Immp0fcXGkgz4XIC1bc8xl04RuvFfVrfN4 3VjNhMor+uJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCZVZPiAAKCRCPgPtYfRL+ Trg2B/4t3h2WeL07p0K6OfERb2hQw7Q/JGYAAlWPopXxn6AST1jwv15PHKjTCbAzNEZ5xs9iEc6 x5+vJfgs+7coJKkWjr3QRDlIidgKsW2HBALi5A46JJ2Yjno5hILFFdHjGKE26StID/OppEQH2yG 7CSeICkmNwcXW3bWE63a8pSnVWpIhS6ZjhyWgC0wywPCk16/rc61cjwvC4d7Vjoz2n/VqeP7jOm 3J7M2MZkgDLMiisAn0ekoAwlJw4sTC2ajganQsVQ9AUv7kGtAU7pFtAatXvH4XuqMAGByIkgKa+ oVOhIOue2fVab1eOJQ1WM97uoRkVW1eJCTUdiZAUD18p9tnV X-Developer-Key: i=u.kleine-koenig@pengutronix.de; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=1.3 required=5.0 tests=DATE_IN_PAST_96_XX, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 16 Nov 2023 09:22:15 -0800 (PST) X-Spam-Level: * X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782742083780987404 X-GMAIL-MSGID: 1782742083780987404 |
Series |
None
|
|
Commit Message
Uwe Kleine-König
Nov. 7, 2023, 8:28 p.m. UTC
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/hwtracing/intel_th/acpi.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--
2.42.0
Comments
Hello, On Tue, Nov 07, 2023 at 09:28:26PM +0100, Uwe Kleine-König wrote: > The .remove() callback for a platform driver returns an int which makes > many driver authors wrongly assume it's possible to do error handling by > returning an error code. However the value returned is ignored (apart > from emitting a warning) and this typically results in resource leaks. > > To improve here there is a quest to make the remove callback return > void. In the first step of this quest all drivers are converted to > .remove_new(), which already returns void. Eventually after all drivers > are converted, .remove_new() will be renamed to .remove(). > > Trivially convert this driver from always returning zero in the remove > callback to the void returning variant. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> I didn't get any feedback to this patch and it didn't make it into next up to now. Is this still on someone's radar? Best regards Uwe
Hello Alexander, On Wed, Jan 10, 2024 at 09:41:54AM +0100, Uwe Kleine-König wrote: > Hello, > > On Tue, Nov 07, 2023 at 09:28:26PM +0100, Uwe Kleine-König wrote: > > The .remove() callback for a platform driver returns an int which makes > > many driver authors wrongly assume it's possible to do error handling by > > returning an error code. However the value returned is ignored (apart > > from emitting a warning) and this typically results in resource leaks. > > > > To improve here there is a quest to make the remove callback return > > void. In the first step of this quest all drivers are converted to > > .remove_new(), which already returns void. Eventually after all drivers > > are converted, .remove_new() will be renamed to .remove(). > > > > Trivially convert this driver from always returning zero in the remove > > callback to the void returning variant. > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > I didn't get any feedback to this patch and it didn't make it into next > up to now. > > Is this still on someone's radar? Is there a chance to get this patch into v6.9-rc1? Are you the right one to talk to about this patch? (According to MAINTAINERS you are.) The patch was sent during the 6.7 merge window and now already missed the 6.8 one :-\ Best regards Uwe
Hello Greg, On Thu, Feb 15, 2024 at 10:16:41PM +0100, Uwe Kleine-König wrote: > On Wed, Jan 10, 2024 at 09:41:54AM +0100, Uwe Kleine-König wrote: > > On Tue, Nov 07, 2023 at 09:28:26PM +0100, Uwe Kleine-König wrote: > > > The .remove() callback for a platform driver returns an int which makes > > > many driver authors wrongly assume it's possible to do error handling by > > > returning an error code. However the value returned is ignored (apart > > > from emitting a warning) and this typically results in resource leaks. > > > > > > To improve here there is a quest to make the remove callback return > > > void. In the first step of this quest all drivers are converted to > > > .remove_new(), which already returns void. Eventually after all drivers > > > are converted, .remove_new() will be renamed to .remove(). > > > > > > Trivially convert this driver from always returning zero in the remove > > > callback to the void returning variant. > > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > I didn't get any feedback to this patch and it didn't make it into next > > up to now. > > > > Is this still on someone's radar? > > Is there a chance to get this patch into v6.9-rc1? Are you the right one > to talk to about this patch? (According to MAINTAINERS you are.) > > The patch was sent during the 6.7 merge window and now already missed > the 6.8 one :-\ I failed in several attempts to get feedback on this patch. You applied the last two patches for this driver (that is all patches since the driver was born). Would you care for that one, too? Tell me if you want a resend. Note that the other 7 patches from this series are already cared for, so if you're using b4 am or shazam, make use of -P7. Thanks Uwe
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes: > Hello Greg, > > On Thu, Feb 15, 2024 at 10:16:41PM +0100, Uwe Kleine-König wrote: >> On Wed, Jan 10, 2024 at 09:41:54AM +0100, Uwe Kleine-König wrote: >> > On Tue, Nov 07, 2023 at 09:28:26PM +0100, Uwe Kleine-König wrote: >> > > The .remove() callback for a platform driver returns an int which makes >> > > many driver authors wrongly assume it's possible to do error handling by >> > > returning an error code. However the value returned is ignored (apart >> > > from emitting a warning) and this typically results in resource leaks. >> > > >> > > To improve here there is a quest to make the remove callback return >> > > void. In the first step of this quest all drivers are converted to >> > > .remove_new(), which already returns void. Eventually after all drivers >> > > are converted, .remove_new() will be renamed to .remove(). >> > > >> > > Trivially convert this driver from always returning zero in the remove >> > > callback to the void returning variant. >> > > >> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> >> > >> > I didn't get any feedback to this patch and it didn't make it into next >> > up to now. >> > >> > Is this still on someone's radar? >> >> Is there a chance to get this patch into v6.9-rc1? Are you the right one >> to talk to about this patch? (According to MAINTAINERS you are.) >> >> The patch was sent during the 6.7 merge window and now already missed >> the 6.8 one :-\ > > I failed in several attempts to get feedback on this patch. You applied > the last two patches for this driver (that is all patches since the > driver was born). Would you care for that one, too? Tell me if you want > a resend. Note that the other 7 patches from this series are already > cared for, so if you're using b4 am or shazam, make use of -P7. Apologies. This looks good to me, I will pick it up for my next submission to Greg unless somebody objects. Regards, -- Alex
diff --git a/drivers/hwtracing/intel_th/acpi.c b/drivers/hwtracing/intel_th/acpi.c index 87f9024e4bbb..503620e9fd10 100644 --- a/drivers/hwtracing/intel_th/acpi.c +++ b/drivers/hwtracing/intel_th/acpi.c @@ -60,18 +60,16 @@ static int intel_th_acpi_probe(struct platform_device *pdev) return 0; } -static int intel_th_acpi_remove(struct platform_device *pdev) +static void intel_th_acpi_remove(struct platform_device *pdev) { struct intel_th *th = platform_get_drvdata(pdev); intel_th_free(th); - - return 0; } static struct platform_driver intel_th_acpi_driver = { .probe = intel_th_acpi_probe, - .remove = intel_th_acpi_remove, + .remove_new = intel_th_acpi_remove, .driver = { .name = DRIVER_NAME, .acpi_match_table = intel_th_acpi_ids,