Message ID | 20230321190136.449485-1-mpearson-lenovo@squebb.ca |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp1958090wrt; Tue, 21 Mar 2023 12:08:11 -0700 (PDT) X-Google-Smtp-Source: AK7set9Gfa8G89iSs7B5wM9IQCrJCUVlPEfqAsVlWK8lm4lAex75BOwUMBzKnGTR99ip0aBukzGq X-Received: by 2002:a05:6a20:ca49:b0:d9:4269:4d2b with SMTP id hg9-20020a056a20ca4900b000d942694d2bmr2756085pzb.0.1679425691133; Tue, 21 Mar 2023 12:08:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679425691; cv=none; d=google.com; s=arc-20160816; b=SBjNXC4TENsStvxJoVrPlT1LKAejXAqGyVbVAQvsDioVhPB7gYq6+vdzsj15c9m8na uFKz3+O+Ly3ItkMc6nzKinkD3Jl4+hOvXajrbCCHQiFW6Xgv9H1NOe2Y+/mGfVr0EG9+ Wh/0POWGoe6gU4r82TRgHPYy3L91HDcapp7bv1vhms5+ygtFz0g1brVmR0ijs/t16wW0 2gxCxZ0vacB4z0Vos/S6zPwK0TY9uPbPvXEY8fk3wmcigh/DDYJrGLnNxrZ94cUDhOw1 +Z6AJbeiGh+DdJBIHTXGX1keiX14QRJyx6bFSF2C96ye2TeIFmo6RzKI/wqsclngZHwL K2eA== 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 :feedback-id:dkim-signature:dkim-signature; bh=XDrvGUk9PJdg/6+5k40AIJKhr8ZrxDCGiHZcWcPJnLY=; b=CKn3JdoCQl0UYVmVBI4KBGuo+2yDelT3F2PRf1ifMzOxTBbpMllAVW4tXPki+yjfwG HzZKKgt9JORBroL8jdOD3j/QEhsMlSHyWrbtneOYhIFK2Hyx+U6RpnQsRsd7AofsNEoJ 9FclGXU97bjsDAyeOxHeQ5P8FWan6RpKBrI1AjLPBcVVY/hBgxq9Xw8m1e1tRUjP8bIb CyQVJtX5KLtN0O97gHy66mtAR+kM0IRYrbdJ/ceNlhjMx30gxxUhtOK1ME+96dcv2TjF wHgNZcfw92OJxZMSFaJLBadB4xlcXJMVCS/bTfH2BVkc13IH71T0DKAl2HO/pxqM8pNC iFuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@squebb.ca header.s=fm3 header.b=EfgI+vkM; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=kPhGCpTX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bl11-20020a056a00280b00b00625946a3273si12967694pfb.57.2023.03.21.12.07.55; Tue, 21 Mar 2023 12:08:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@squebb.ca header.s=fm3 header.b=EfgI+vkM; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=kPhGCpTX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229940AbjCUTCI (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Tue, 21 Mar 2023 15:02:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229976AbjCUTCB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Mar 2023 15:02:01 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FA5C56538; Tue, 21 Mar 2023 12:01:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B2EE55C0105; Tue, 21 Mar 2023 15:01:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 21 Mar 2023 15:01:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squebb.ca; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1679425305; x= 1679511705; bh=XDrvGUk9PJdg/6+5k40AIJKhr8ZrxDCGiHZcWcPJnLY=; b=E fgI+vkMEB/ivbm0D4fudXuJf7CN0WGeZlbpfPICNNQQv6ugakPD8AAbfHZS3z36z +YhRjYwCfaZaiTKLkjaqEK4sukYKnhNqcjalyWPkpcDTH3pvwrBrcRF3CoQvIrA+ uXmTkPVF4g2S0U6uZ+7S81rY3B89/utMjIYc+qQOoYLtbPpYPwE8ZyVh5jj7wPjk t/28pgazhF8O/0ZUj4L+ZdgPUM9r9Tu5uOSYiXtkblvdFQmzRNaZ+SYP88Q4zbDW dMt5ozbZDZdTeiZ9Yd0rVV/WwxBssRMvZrlmoPJqAnaiEB5UsTtpAZnYEsQvo3Mk dRvdX3MkA9SjrocwYNYjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1679425305; x= 1679511705; bh=XDrvGUk9PJdg/6+5k40AIJKhr8ZrxDCGiHZcWcPJnLY=; b=k PhGCpTXf0GQHmqRGaVccYzLnqWhqTPQ5Qe9eK5U+k4qPJnDq/S/SHl9siupuyyCL ydGkIGQA8r1nFhAemWGLjNlT5+YeqqrsevjM4RDGhJUANilzsqCRDFh86hSO8iHH ipW25a1cG9aNXHeJoCBtmm763owsxMDUHatW8/hpJmAwc0gl0+rbrwe0KNhBMoxB 4IGlRrGANV21qjm1a4kKA3X2qthvUrUOtxJKK0N7wkDBq2dPzLvU4VYinqrf+oy8 2GybUcMOedyzMRUl3nWVkaoDiR1Y+kNizrMn29hQ0kSY9iK42HKsHkXrYsvLeMPR BW+Mh8Gg12wOkHfDsxTMw== X-ME-Sender: <xms:GP8ZZLkutVFfr52RRMAxlvcxdwE2VUxUt-DjOVsOFfRFyw5nKFzhLA> <xme:GP8ZZO02oVp0iUkTk-M4mxxvRjXmGBEBEeQEYWZXumd3wvh0vFHsnXxSJxOCIK5gm _Cdtc0iFgRPA9J7TJ0> X-ME-Received: <xmr:GP8ZZBqp2Y0Ww8JsoHKGDiXWyOQ00qsTyOSrk2SmhGWXc-_Tn456YF9rRtshuLazVFBAM5btrNagTRoIcxNTrYkCjjVksGNsOxH4x_DAXMmA02lkOB65kHfkQ7j13i6BoDTd0ZkamA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdegtddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecuogetfedtuddqtdduucdludehmdenucfjughrpe fhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeforghrkhcurfgvrghr shhonhcuoehmphgvrghrshhonhdqlhgvnhhovhhosehsqhhuvggssgdrtggrqeenucggtf frrghtthgvrhhnpeeftddvjeefleffvefhgfejjeehudetteeigeeugfekhffhgeejudeu teehgfdvffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmphgvrghrshhonhdqlhgvnhhovhhosehsqhhuvggssgdrtggr X-ME-Proxy: <xmx:Gf8ZZDnIdagMQdq3gtGD179ESghqSCMzbOdZ3tAJpJ2vxMittC0FLg> <xmx:Gf8ZZJ062cqjGlqfs-D-_BJFn6magWMT8077ESIM8VbqjHQGjDivQA> <xmx:Gf8ZZCufyTjKRUKhg0gXF0iJbiiLwd-_TDYL9y6i0x7p7ZjKvxiUAA> <xmx:Gf8ZZCyfuCcD5oqwn3tbvHMrzVJTYY0dP1xcyhUs5-LBtDAxiVFzCA> Feedback-ID: ibe194615:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Mar 2023 15:01:44 -0400 (EDT) From: Mark Pearson <mpearson-lenovo@squebb.ca> To: mpearson-lenovo@squebb.ca Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler Date: Tue, 21 Mar 2023 15:01:36 -0400 Message-Id: <20230321190136.449485-1-mpearson-lenovo@squebb.ca> X-Mailer: git-send-email 2.39.2 In-Reply-To: <mpearson-lenovo@squebb.ca> References: <mpearson-lenovo@squebb.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761005473247822565?= X-GMAIL-MSGID: =?utf-8?q?1761005473247822565?= |
Series |
usb: typec: ucsi: acpi: Remove notifier before destroying handler
|
|
Commit Message
Mark Pearson
March 21, 2023, 7:01 p.m. UTC
Was debugging another issue (since fixed) and noticed that the acpi
notify_handler should be removed before the ucsi object is destroyed.
This isn't fixing any issues that I'm aware of - but I assume could
potentially lead to a race condition if you were really unlucky?
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
---
drivers/usb/typec/ucsi/ucsi_acpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Tue, Mar 21, 2023 at 03:01:36PM -0400, Mark Pearson wrote: > Was debugging another issue (since fixed) and noticed that the acpi > notify_handler should be removed before the ucsi object is destroyed. > > This isn't fixing any issues that I'm aware of - but I assume could > potentially lead to a race condition if you were really unlucky? > > Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> > --- > drivers/usb/typec/ucsi/ucsi_acpi.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c > index ce0c8ef80c04..be3bf4f996d3 100644 > --- a/drivers/usb/typec/ucsi/ucsi_acpi.c > +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c > @@ -176,12 +176,12 @@ static int ucsi_acpi_remove(struct platform_device *pdev) > { > struct ucsi_acpi *ua = platform_get_drvdata(pdev); > > - ucsi_unregister(ua->ucsi); > - ucsi_destroy(ua->ucsi); > - > acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev), ACPI_DEVICE_NOTIFY, > ucsi_acpi_notify); > > + ucsi_unregister(ua->ucsi); > + ucsi_destroy(ua->ucsi); > + > return 0; > } Calling ucsi_desctroy() after removing the notifier makes sense to me, but do you also need to unregister the instance after that? You may still be in the middle of init or resume, so I think we need to accept notifications until we are sure those have finished, i.e. ucsi_unregister() has finished. thanks,
Hi Heikki, On Thu, Mar 23, 2023, at 5:57 AM, Heikki Krogerus wrote: > On Tue, Mar 21, 2023 at 03:01:36PM -0400, Mark Pearson wrote: >> Was debugging another issue (since fixed) and noticed that the acpi >> notify_handler should be removed before the ucsi object is destroyed. >> >> This isn't fixing any issues that I'm aware of - but I assume could >> potentially lead to a race condition if you were really unlucky? >> >> Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> >> --- >> drivers/usb/typec/ucsi/ucsi_acpi.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c >> index ce0c8ef80c04..be3bf4f996d3 100644 >> --- a/drivers/usb/typec/ucsi/ucsi_acpi.c >> +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c >> @@ -176,12 +176,12 @@ static int ucsi_acpi_remove(struct platform_device *pdev) >> { >> struct ucsi_acpi *ua = platform_get_drvdata(pdev); >> >> - ucsi_unregister(ua->ucsi); >> - ucsi_destroy(ua->ucsi); >> - >> acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev), ACPI_DEVICE_NOTIFY, >> ucsi_acpi_notify); >> >> + ucsi_unregister(ua->ucsi); >> + ucsi_destroy(ua->ucsi); >> + >> return 0; >> } > > Calling ucsi_desctroy() after removing the notifier makes sense to me, > but do you also need to unregister the instance after that? > > You may still be in the middle of init or resume, so I think we need > to accept notifications until we are sure those have finished, i.e. > ucsi_unregister() has finished. > That makes sense - I hadn't considered that. I'll post an updated patch with the acpi_remove_notify_handler between the two calls. Thanks for the review Mark
diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c index ce0c8ef80c04..be3bf4f996d3 100644 --- a/drivers/usb/typec/ucsi/ucsi_acpi.c +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c @@ -176,12 +176,12 @@ static int ucsi_acpi_remove(struct platform_device *pdev) { struct ucsi_acpi *ua = platform_get_drvdata(pdev); - ucsi_unregister(ua->ucsi); - ucsi_destroy(ua->ucsi); - acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev), ACPI_DEVICE_NOTIFY, ucsi_acpi_notify); + ucsi_unregister(ua->ucsi); + ucsi_destroy(ua->ucsi); + return 0; }