From: chenchangcheng <chenchangcheng@kylinos.cn>

When an Apple device is inserted into the host, and the host
wakes up from S3/S4 power states, if the reset_resume process
is triggered, the absence of a reset_resume callback in usbfs will
cause the device to unbind.
By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
uevents in reset_resume, the userspace is prompted to reissue commands
to re-establish the binding with usbfs.

Signed-off-by: chenchangcheng <chenchangcheng@kylinos.cn>
---
 drivers/usb/core/devio.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index f6ce6e26e0d4..358850596b0d 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -749,6 +749,14 @@ static int driver_resume(struct usb_interface *intf)
 	return 0;
 }
 
+static int driver_reset_resume(struct usb_interface *intf)
+{
+	struct usb_device *udev = interface_to_usbdev(intf);
+
+	kobject_uevent(&udev->dev.kobj, KOBJ_REMOVE);
+	kobject_uevent(&udev->dev.kobj, KOBJ_ADD);
+	return 0;
+}
 #ifdef CONFIG_PM
 /* The following routines apply to the entire device, not interfaces */
 void usbfs_notify_suspend(struct usb_device *udev)
@@ -776,6 +784,7 @@ struct usb_driver usbfs_driver = {
 	.disconnect =	driver_disconnect,
 	.suspend =	driver_suspend,
 	.resume =	driver_resume,
+	.reset_resume =	driver_reset_resume,
 	.supports_autosuspend = 1,
 };
 

base-commit: b19a97d57c15643494ac8bfaaa35e3ee472d41da
-- 
2.25.1

On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@163.com wrote:
> From: chenchangcheng <chenchangcheng@kylinos.cn>
> 
> When an Apple device is inserted into the host, and the host
> wakes up from S3/S4 power states, if the reset_resume process
> is triggered, the absence of a reset_resume callback in usbfs will
> cause the device to unbind.
> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
> uevents in reset_resume, the userspace is prompted to reissue commands
> to re-establish the binding with usbfs.

usbfs has no way to inform userspace when the device is reset.  This is 
true for normal resets as well as for reset-resumes (no pre_reset, 
post_reset, or reset_resume callbacks).  I don't see any point in trying 
to add support for the latter but not the former.

Unbinding the device forces userspace to re-open the device file and 
establish a new binding.  How does adding REMOVE and ADD uevents make 
the situation any better than it already is?

Alan Stern

At 2025-08-23 04:30:18, "Alan Stern" <stern@rowland.harvard.edu> wrote:
>On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@163.com wrote:
>> From: chenchangcheng <chenchangcheng@kylinos.cn>
>> 
>> When an Apple device is inserted into the host, and the host
>> wakes up from S3/S4 power states, if the reset_resume process
>> is triggered, the absence of a reset_resume callback in usbfs will
>> cause the device to unbind.
>> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
>> uevents in reset_resume, the userspace is prompted to reissue commands
>> to re-establish the binding with usbfs.
>
>usbfs has no way to inform userspace when the device is reset.  This is 
>true for normal resets as well as for reset-resumes (no pre_reset, 
>post_reset, or reset_resume callbacks).  I don't see any point in trying 
>to add support for the latter but not the former.
>
>Unbinding the device forces userspace to re-open the device file and 
>establish a new binding.  How does adding REMOVE and ADD uevents make 
>the situation any better than it already is?
>

>Alan Stern

Here is my reasoning: 
Currently, for Apple devices after S3/S4 states, since the USB hub loses power, 
the reset-resume process is triggered during resume. If the original 
reset_resume process is followed, the device would be forcibly unbound,
and the device_attach function would be used to rebind the driver.
However, usbfs is different in that it cannot automatically rebind
after unbinding and requires a userspace ioctl to re-establish the binding.

If we assume that the reset_resume callback of usbfs does nothing
and simply returns 0, the USB device would still be reset. When userspace
uses the previous file descriptor handle to issue a command, it would result
in an error: "PTP_OC 0x1007 receiving resp failed: PTP Session Not Open (0x2003)."

Therefore, by adding REMOVE and ADD uevents in the reset_resume process,
userspace is notified to first unbind and then rebind. This approach avoids the aforementioned issue.

Chen Changcheng

On Mon, Aug 25, 2025 at 09:36:49AM +0800, 自己 wrote:
> At 2025-08-23 04:30:18, "Alan Stern" <stern@rowland.harvard.edu> wrote:
> >On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@163.com wrote:
> >> From: chenchangcheng <chenchangcheng@kylinos.cn>
> >> 
> >> When an Apple device is inserted into the host, and the host
> >> wakes up from S3/S4 power states, if the reset_resume process
> >> is triggered, the absence of a reset_resume callback in usbfs will
> >> cause the device to unbind.
> >> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
> >> uevents in reset_resume, the userspace is prompted to reissue commands
> >> to re-establish the binding with usbfs.
> >
> >usbfs has no way to inform userspace when the device is reset.  This is 
> >true for normal resets as well as for reset-resumes (no pre_reset, 
> >post_reset, or reset_resume callbacks).  I don't see any point in trying 
> >to add support for the latter but not the former.
> >
> >Unbinding the device forces userspace to re-open the device file and 
> >establish a new binding.  How does adding REMOVE and ADD uevents make 
> >the situation any better than it already is?
> >
> 
> >Alan Stern
> 
> Here is my reasoning: 
> Currently, for Apple devices after S3/S4 states, since the USB hub loses power, 
> the reset-resume process is triggered during resume. If the original 
> reset_resume process is followed, the device would be forcibly unbound,
> and the device_attach function would be used to rebind the driver.
> However, usbfs is different in that it cannot automatically rebind
> after unbinding and requires a userspace ioctl to re-establish the binding.
> 
> If we assume that the reset_resume callback of usbfs does nothing
> and simply returns 0, the USB device would still be reset. When userspace
> uses the previous file descriptor handle to issue a command, it would result
> in an error: "PTP_OC 0x1007 receiving resp failed: PTP Session Not Open (0x2003)."
> 
> Therefore, by adding REMOVE and ADD uevents in the reset_resume process,
> userspace is notified to first unbind and then rebind. This approach avoids the aforementioned issue.

Doesn't the "PTP Session Not Open" error notify userspace to unbind and 
rebind?  Why is adding REMOVE and ADD uevents any better?

In the current kernel there is no reset_resume callback for usbfs.  
Consequently, when userspace uses the previous file descriptor handle to 
issue an ioctl command after a resume, it gets a -ENODEV error.  Doesn't 
this also notify userspace that it should unbind and rebind?  Why is 
adding a reset_resume callback any better?

Alan Stern

At 2025-08-25 10:01:44, "Alan Stern" <stern@rowland.harvard.edu> wrote:
>On Mon, Aug 25, 2025 at 09:36:49AM +0800, 自己 wrote:
>> At 2025-08-23 04:30:18, "Alan Stern" <stern@rowland.harvard.edu> wrote:
>> >On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@163.com wrote:
>> >> From: chenchangcheng <chenchangcheng@kylinos.cn>
>> >> 
>> >> When an Apple device is inserted into the host, and the host
>> >> wakes up from S3/S4 power states, if the reset_resume process
>> >> is triggered, the absence of a reset_resume callback in usbfs will
>> >> cause the device to unbind.
>> >> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
>> >> uevents in reset_resume, the userspace is prompted to reissue commands
>> >> to re-establish the binding with usbfs.
>> >
>> >usbfs has no way to inform userspace when the device is reset.  This is 
>> >true for normal resets as well as for reset-resumes (no pre_reset, 
>> >post_reset, or reset_resume callbacks).  I don't see any point in trying 
>> >to add support for the latter but not the former.
>> >
>> >Unbinding the device forces userspace to re-open the device file and 
>> >establish a new binding.  How does adding REMOVE and ADD uevents make 
>> >the situation any better than it already is?
>> >
>> 
>> >Alan Stern
>> 
>> Here is my reasoning: 
>> Currently, for Apple devices after S3/S4 states, since the USB hub loses power, 
>> the reset-resume process is triggered during resume. If the original 
>> reset_resume process is followed, the device would be forcibly unbound,
>> and the device_attach function would be used to rebind the driver.
>> However, usbfs is different in that it cannot automatically rebind
>> after unbinding and requires a userspace ioctl to re-establish the binding.
>> 
>> If we assume that the reset_resume callback of usbfs does nothing
>> and simply returns 0, the USB device would still be reset. When userspace
>> uses the previous file descriptor handle to issue a command, it would result
>> in an error: "PTP_OC 0x1007 receiving resp failed: PTP Session Not Open (0x2003)."
>> 
>> Therefore, by adding REMOVE and ADD uevents in the reset_resume process,
>> userspace is notified to first unbind and then rebind. This approach avoids the aforementioned issue.
>
>Doesn't the "PTP Session Not Open" error notify userspace to unbind and 
>rebind?  Why is adding REMOVE and ADD uevents any better?
>
>In the current kernel there is no reset_resume callback for usbfs.  
>Consequently, when userspace uses the previous file descriptor handle to 
>issue an ioctl command after a resume, it gets a -ENODEV error.  Doesn't 
>this also notify userspace that it should unbind and rebind?  Why is 
>adding a reset_resume callback any better?
>
>Alan Stern

According to the current experimental findings, when userspace encounters
an error while using the previous file descriptor (fd), it does not proceed to unbind
and rebind automatically. Therefore, the two uevents were added in the kernel to explicitly
notify userspace to unbind and rebind.

Chen Changcheng

On Mon, Aug 25, 2025 at 10:19:56AM +0800, 自己 wrote:
> According to the current experimental findings, when userspace encounters
> an error while using the previous file descriptor (fd), it does not proceed to unbind
> and rebind automatically. Therefore, the two uevents were added in the kernel to explicitly
> notify userspace to unbind and rebind.

Like Oliver said, this means that userspace needs to be fixed.  Not the 
kernel.

Alan Stern

On 8/25/25 04:19, 自己 wrote:

> According to the current experimental findings, when userspace encounters
> an error while using the previous file descriptor (fd), it does not proceed to unbind
> and rebind automatically. Therefore, the two uevents were added in the kernel to explicitly
> notify userspace to unbind and rebind.

Sure, but that means that user space has a bug.
That race is present in every case. Even if the kernel
were to notify user space by additional channels,
user space could already be in the process of calling
into the kernel.
There is no way of avoiding the need for user space
to handle this error return correctly.

	Regards
		Oliver

On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@163.com wrote:
> From: chenchangcheng <chenchangcheng@kylinos.cn>
> 
> When an Apple device is inserted into the host, and the host
> wakes up from S3/S4 power states, if the reset_resume process
> is triggered, the absence of a reset_resume callback in usbfs will
> cause the device to unbind.
> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
> uevents in reset_resume, the userspace is prompted to reissue commands
> to re-establish the binding with usbfs.
> 
> Signed-off-by: chenchangcheng <chenchangcheng@kylinos.cn>

Nit, we need a "real name", see the kernel documentation for details.

> ---
>  drivers/usb/core/devio.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index f6ce6e26e0d4..358850596b0d 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -749,6 +749,14 @@ static int driver_resume(struct usb_interface *intf)
>  	return 0;
>  }
>  
> +static int driver_reset_resume(struct usb_interface *intf)
> +{
> +	struct usb_device *udev = interface_to_usbdev(intf);
> +
> +	kobject_uevent(&udev->dev.kobj, KOBJ_REMOVE);
> +	kobject_uevent(&udev->dev.kobj, KOBJ_ADD);

But the object is not being removed and added.  So why lie like this?
How does userspace now handle this as the device did not go away?

This feels odd, what changed to require this kernel change to be added?

thanks,

greg k-h