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 <[email protected]>
---
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 <[email protected]>
> ---
> 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 <[email protected]> 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 <[email protected]>
> > ---
> > 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 <[email protected]> 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