The KOBJ_CHANGE uevent is sent before gadget unbind is actually
executed, resulting in inaccurate uevent emitted at incorrect timing
(the uevent would have USB_UDC_DRIVER variable set while it would
soon be removed).
Move the KOBJ_CHANGE uevent to the end of the unbind function so that
uevent is sent only after the change has been made.

Signed-off-by: Roy Luo <royluo@google.com>
---
 drivers/usb/gadget/udc/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index ded9531f141b..d59f94464b87 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1646,8 +1646,6 @@ static void gadget_unbind_driver(struct device *dev)
 
 	dev_dbg(&udc->dev, "unbinding gadget driver [%s]\n", driver->function);
 
-	kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
-
 	udc->allow_connect = false;
 	cancel_work_sync(&udc->vbus_work);
 	mutex_lock(&udc->connect_lock);
@@ -1667,6 +1665,8 @@ static void gadget_unbind_driver(struct device *dev)
 	driver->is_bound = false;
 	udc->driver = NULL;
 	mutex_unlock(&udc_lock);
+
+	kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
 }
 
 /* ------------------------------------------------------------------------- */

base-commit: 9b6de136b5f0158c60844f85286a593cb70fb364
-- 
2.43.0.rc1.413.gea7ed67945-goog

On Wed, Nov 22, 2023 at 10:00:01PM +0000, Roy Luo wrote:
> The KOBJ_CHANGE uevent is sent before gadget unbind is actually
> executed, resulting in inaccurate uevent emitted at incorrect timing
> (the uevent would have USB_UDC_DRIVER variable set while it would
> soon be removed).
> Move the KOBJ_CHANGE uevent to the end of the unbind function so that
> uevent is sent only after the change has been made.
> 
> Signed-off-by: Roy Luo <royluo@google.com>
> ---
>  drivers/usb/gadget/udc/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

What commit does this fix?

The logic is there since day 1 of udc in Commit
2ccea03a8f7ec93641791f2760d7cdc6cab6205f (usb: gadget: introduce UDC
Class). Do you still want me to put on a fix tag?

(Sorry for the spam, forgot to switch to plain text mode..)

On Wed, Nov 22, 2023 at 2:07 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Nov 22, 2023 at 10:00:01PM +0000, Roy Luo wrote:
> > The KOBJ_CHANGE uevent is sent before gadget unbind is actually
> > executed, resulting in inaccurate uevent emitted at incorrect timing
> > (the uevent would have USB_UDC_DRIVER variable set while it would
> > soon be removed).
> > Move the KOBJ_CHANGE uevent to the end of the unbind function so that
> > uevent is sent only after the change has been made.
> >
> > Signed-off-by: Roy Luo <royluo@google.com>
> > ---
> >  drivers/usb/gadget/udc/core.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> What commit does this fix?
>
>

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Nov 22, 2023 at 03:13:20PM -0800, Roy Luo wrote:
> The logic is there since day 1 of udc in Commit
> 2ccea03a8f7ec93641791f2760d7cdc6cab6205f (usb: gadget: introduce UDC
> Class). Do you still want me to put on a fix tag?

Yes please, and do you want this backported to all older stable kernels?

thanks,

greg k-h

On Thu, Nov 23, 2023 at 12:52 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?

Thanks for the tips and your patience, I hope I get the format correct
this time.

> On Wed, Nov 22, 2023 at 03:13:20PM -0800, Roy Luo wrote:
> > The logic is there since day 1 of udc in Commit
> > 2ccea03a8f7ec93641791f2760d7cdc6cab6205f (usb: gadget: introduce UDC
> > Class). Do you still want me to put on a fix tag?
>
> Yes please, and do you want this backported to all older stable kernels?

Ok I will add a fix tag in v2.
As for backporting to stable kernels, I don't see a strong need that
satisfies https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Please let me know if you think otherwise.

Thanks,
Roy