public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler
@ 2023-03-21 19:01 Mark Pearson
  2023-03-23  9:57 ` Heikki Krogerus
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Pearson @ 2023-03-21 19:01 UTC (permalink / raw)
  To: mpearson-lenovo; +Cc: heikki.krogerus, gregkh, linux-usb, linux-kernel

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;
 }
 
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler
  2023-03-21 19:01 [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler Mark Pearson
@ 2023-03-23  9:57 ` Heikki Krogerus
  2023-03-24 12:50   ` Mark Pearson
  0 siblings, 1 reply; 3+ messages in thread
From: Heikki Krogerus @ 2023-03-23  9:57 UTC (permalink / raw)
  To: Mark Pearson; +Cc: gregkh, linux-usb, linux-kernel

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,

-- 
heikki

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler
  2023-03-23  9:57 ` Heikki Krogerus
@ 2023-03-24 12:50   ` Mark Pearson
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Pearson @ 2023-03-24 12:50 UTC (permalink / raw)
  To: Heikki Krogerus; +Cc: Greg KH, linux-usb, linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-03-24 12:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-21 19:01 [PATCH] usb: typec: ucsi: acpi: Remove notifier before destroying handler Mark Pearson
2023-03-23  9:57 ` Heikki Krogerus
2023-03-24 12:50   ` Mark Pearson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox