Message ID | 20231025130737.2015468-3-gnstark@salutedevices.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce89:0:b0:403:3b70:6f57 with SMTP id p9csp2586966vqx; Wed, 25 Oct 2023 06:08:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFB9GmicoYZk1wZ1xKFN1lhHe4Zn0TApKZrC6KxO7KPLpp46f0MNDseCejItFDIXk/spnQA X-Received: by 2002:a05:6808:17a3:b0:3b2:e3b5:b94 with SMTP id bg35-20020a05680817a300b003b2e3b50b94mr18958404oib.16.1698239301166; Wed, 25 Oct 2023 06:08:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698239301; cv=none; d=google.com; s=arc-20160816; b=ElPRLqko8KKgaOl9VJo3IDWvUfvHgyP77HTUdYs+ksdpUeQdMctnQTOCJPouvatR9A RIHmSRk+fSerShTfW2VdNqJX5R4uvgJI1gVY6QGgqkHYc+Bv7c/Fg7zI6D4OD5UKgfM1 8CiOsGcoP/qRvz1ElPhXzMUDnE9eSB/DYglD+Dsf0VMsQDOWpzGXTES6q4KjsmvvuRh6 m+kNfPxebJCu9+HyEP31NK4ReMgX2qgo7AUyJ+Smmuc7oSfF49AWdxwgqEJ1RICY5+TF qXXkyXGN+5xJqWMmVexmdlutHC7JtfhtDYOUETasj9M6a2bDWRBAKNEiSZV+X/YNrDfe BfKg== 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:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=bfmNKLq7qXt685RQkGWfdj7Fq3sNLbKBr4vZ23mFyMU=; fh=TH/KyKkXF5LipyBG9stysnOYaFHGBRYytRmnm4H0CpA=; b=pgYGl6nPzNBexnk9onPT2eZVhKH+p8O5yFn92hvfaRzgbgAFpBgu+76rzANpr8AeeN /GsUUcmz9cRPaR3i/7SrH9EI2QkKX0V4WZwr2lzP51o85Kb9WreujvzrZgcK8L2YwiWM Y7GFZz+bvCCc6gYlUfA+2D7YTY3itJ2bZsbUDno4ct3SJnQ2wA/9RddXPpZni+m9zSQX 5/oym1eMAZG/vSmq5JyZqU2rm587MOyGHVSqCsmBXsY8KSuBCrFGZQnyonrr5AIPJk5H g5Wj15i9w51HgwM9+k+PwEhbwZzzRgloC4L5KsHrDzKCZ4UsfE6sV4aW4KakqaQRZ3nQ /jgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=VojGS1Pp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id x23-20020a25acd7000000b00d86a6df0615si11140589ybd.730.2023.10.25.06.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 06:08:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=VojGS1Pp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 547D0801DA05; Wed, 25 Oct 2023 06:08:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344318AbjJYNHy (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Wed, 25 Oct 2023 09:07:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234066AbjJYNHx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 25 Oct 2023 09:07:53 -0400 Received: from mx1.sberdevices.ru (mx1.sberdevices.ru [37.18.73.165]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85E9412F; Wed, 25 Oct 2023 06:07:47 -0700 (PDT) Received: from p-infra-ksmg-sc-msk01 (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id B5F61100044; Wed, 25 Oct 2023 16:07:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru B5F61100044 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1698239264; bh=bfmNKLq7qXt685RQkGWfdj7Fq3sNLbKBr4vZ23mFyMU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=VojGS1PppsDkwWGmglY1Afhu5vYAKIYEUkEHdbS8F1mzDQmnEWIJJKLEu5ge1jdKk jz9GjXWVhsKYUqVgkk6ZU7SYg50fwdfLaZXmNuSgalrOibjjfWCRjsm5h3w79k5g+K FkHvvweEIoiTlvnLeuBmY15fp2mg/5t0cZjCIGg1P5myRI1ECi7Tk1xgdjgZfMqet9 +BMue/7yrY0AhX84Oeroa+AVJdiOZXgAkAfkkqDrom4iyT3QHAc5ZKlvXVgulumCHC uq87G1cFwo3PxrvrAITB6YhIM4rzluhSPzcX0+N8HSBESMawpUffI+Vl6R/xHdP+/C ztSeq+Vm0XV5Q== Received: from p-i-exch-sc-m01.sberdevices.ru (p-i-exch-sc-m01.sberdevices.ru [172.16.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sberdevices.ru (Postfix) with ESMTPS; Wed, 25 Oct 2023 16:07:44 +0300 (MSK) Received: from localhost.localdomain (100.64.160.123) by p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Wed, 25 Oct 2023 16:07:44 +0300 From: George Stark <gnstark@salutedevices.com> To: <pavel@ucw.cz>, <lee@kernel.org>, <vadimp@nvidia.com>, <mpe@ellerman.id.au>, <npiggin@gmail.com>, <christophe.leroy@csgroup.eu>, <gnstark@salutedevices.com> CC: <linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>, <kernel@sberdevices.ru> Subject: [PATCH 2/8] leds: nic78bx: explicitly unregister LEDs at module's shutdown Date: Wed, 25 Oct 2023 16:07:31 +0300 Message-ID: <20231025130737.2015468-3-gnstark@salutedevices.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231025130737.2015468-1-gnstark@salutedevices.com> References: <20231025130737.2015468-1-gnstark@salutedevices.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [100.64.160.123] X-ClientProxiedBy: p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) To p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) X-KSMG-Rule-ID: 10 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 180883 [Oct 25 2023] X-KSMG-AntiSpam-Version: 6.0.0.2 X-KSMG-AntiSpam-Envelope-From: gnstark@salutedevices.com X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 543 543 1e3516af5cdd92079dfeb0e292c8747a62cb1ee4, {Tracking_from_domain_doesnt_match_to}, 127.0.0.199:7.1.2;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;100.64.160.123:7.1.2;p-i-exch-sc-m01.sberdevices.ru:7.1.1,5.0.1;salutedevices.com:7.1.1, FromAlignment: s, ApMailHostAddress: 100.64.160.123 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean X-KSMG-LinksScanning: Clean X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.0.1.6960, bases: 2023/10/25 11:29:00 #22291710 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.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 (pete.vger.email [0.0.0.0]); Wed, 25 Oct 2023 06:08:07 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780732973782438485 X-GMAIL-MSGID: 1780732973782438485 |
Series |
devm_led_classdev_register() usage problem
|
|
Commit Message
George Stark
Oct. 25, 2023, 1:07 p.m. UTC
LEDs are registered using devm_led_classdev_register() and automatically
unregistered after module's remove(). led_classdev_unregister() calls
led_set_brightness() to turn off the LEDs and module's appropriate callback
uses resources those were destroyed already in module's remove().
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark <gnstark@salutedevices.com>
---
drivers/leds/leds-nic78bx.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
Le 25/10/2023 à 15:07, George Stark a écrit : > LEDs are registered using devm_led_classdev_register() and automatically > unregistered after module's remove(). led_classdev_unregister() calls > led_set_brightness() to turn off the LEDs and module's appropriate callback > uses resources those were destroyed already in module's remove(). > So explicitly unregister LEDs at module shutdown. > > Signed-off-by: George Stark <gnstark@salutedevices.com> > --- > drivers/leds/leds-nic78bx.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c > index f196f52eec1e..12b70fcad37f 100644 > --- a/drivers/leds/leds-nic78bx.c > +++ b/drivers/leds/leds-nic78bx.c > @@ -170,6 +170,10 @@ static int nic78bx_probe(struct platform_device *pdev) > static int nic78bx_remove(struct platform_device *pdev) > { > struct nic78bx_led_data *led_data = platform_get_drvdata(pdev); > + int i; > + > + for (i = 0; i < ARRAY_SIZE(nic78bx_leds); i++) > + devm_led_classdev_unregister(&pdev->dev, &nic78bx_leds[i].cdev); The whole purpose of devm_ functions is that you don't need to call unregister when removing the driver as the dev core will do it for you. I understand your problem but I think this is not the solution. > > /* Lock LED register */ > outb(NIC78BX_LOCK_VALUE,
Hello Christophe. Thanks for the review. On 11/6/23 11:13, Christophe Leroy wrote: > > > Le 25/10/2023 à 15:07, George Stark a écrit : >> LEDs are registered using devm_led_classdev_register() and automatically >> unregistered after module's remove(). led_classdev_unregister() calls >> led_set_brightness() to turn off the LEDs and module's appropriate callback >> uses resources those were destroyed already in module's remove(). >> So explicitly unregister LEDs at module shutdown. >> >> Signed-off-by: George Stark <gnstark@salutedevices.com> >> --- >> drivers/leds/leds-nic78bx.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c >> index f196f52eec1e..12b70fcad37f 100644 >> --- a/drivers/leds/leds-nic78bx.c >> +++ b/drivers/leds/leds-nic78bx.c >> @@ -170,6 +170,10 @@ static int nic78bx_probe(struct platform_device *pdev) >> static int nic78bx_remove(struct platform_device *pdev) >> { >> struct nic78bx_led_data *led_data = platform_get_drvdata(pdev); >> + int i; >> + >> + for (i = 0; i < ARRAY_SIZE(nic78bx_leds); i++) >> + devm_led_classdev_unregister(&pdev->dev, &nic78bx_leds[i].cdev); > > The whole purpose of devm_ functions is that you don't need to call > unregister when removing the driver as the dev core will do it for you. > I understand your problem but I think this is not the solution. I agree my solution is questionable although devm_led_classdev_unregister() is exists for some reason. Probably it's not the best solution to remove led_set_brightness() from led_classdev_unregister() either. Or we'll have to patch a lot of drivers which use led subsystem to call led_set_brightness() manually to keep leds' previous behavior. Well if we can't easily unregister leds before module's remove() callback is completed may be we can get rid of remove() itself and manage all resources using devm API. In that case by the time led_set_brightness() is called from led_classdev_unregister() all dependent resources will be alive. I'll try it in the next patch series. > >> >> /* Lock LED register */ >> outb(NIC78BX_LOCK_VALUE,
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c index f196f52eec1e..12b70fcad37f 100644 --- a/drivers/leds/leds-nic78bx.c +++ b/drivers/leds/leds-nic78bx.c @@ -170,6 +170,10 @@ static int nic78bx_probe(struct platform_device *pdev) static int nic78bx_remove(struct platform_device *pdev) { struct nic78bx_led_data *led_data = platform_get_drvdata(pdev); + int i; + + for (i = 0; i < ARRAY_SIZE(nic78bx_leds); i++) + devm_led_classdev_unregister(&pdev->dev, &nic78bx_leds[i].cdev); /* Lock LED register */ outb(NIC78BX_LOCK_VALUE,