USB: remove CONFIG_USB_PERSIST from Documentation
Subsystems (2)
PATCH 1/1 USB: remove CONFIG_USB_PERSIST from Documentation
CONFIG_USB_PERSIST was removed in v2.6.26. Remove a reference to it from Documentation. That reference was a bit odd to begin with.
---
"[...] under certain circumstances [...]"? Is that about USB_QUIRK_RESET_RESUME? Anyhow, I feel this paragraph needs more work, but that would require quite a bit of hand-holding. Perhaps Alan or Greg would like to hold my hand here...
Documentation/usb/power-management.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/usb/power-management.txt +1 -1
@@ -304,7 +304,7 @@ using the USB Persist facility.) The reset_resume method is used by the USB Persist facility (see Documentation/usb/persist.txt) and it can also be used under certain -circumstances when CONFIG_USB_PERSIST is not enabled. Currently, if a +circumstances when that facility is not enabled. Currently, if a device is reset during a resume and the driver does not have a reset_resume method, the driver won't receive any notification about the resume. Later kernels will call the driver's disconnect method;
Signature · 1 line
1.9.3
Quoted 18 lines · Paul Bolle
CONFIG_USB_PERSISTwas removed in v2.6.26. Remove a reference to it from Documentation. That reference was a bit odd to begin with.Signed-off-by Paul Bolle <[email protected]>---
"[...] under certain circumstances [...]"? Is that aboutUSB_QUIRK_RESET_RESUME? Anyhow, I feel this paragraph needs more work, but that would require quite a bit of hand-holding. Perhaps Alan or Greg would like to hold my hand here...Documentation/usb/power-management.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Documentation/usb/power-management.txt +0
-0
Documentation/usb/power-management.txt using the USB Persist facility.) · line 310
Quoted 8 lines
Documentation/usb/power-management.txt +1
-1@@ -304,7 +304,7 @@ using the USB Persist facility.) The reset_resume method is used by the USB Persist facility (see Documentation/usb/persist.txt) and it can also be used under certain -circumstances when CONFIG_USB_PERSIST is not enabled. Currently, if a +circumstances when that facility is not enabled. Currently, if a device is reset during a resume and the driver does not have a reset_resume method, the driver won't receive any notification about the resume. Later kernels will call the driver's disconnect method;
I don't remember what the "certain circumstances" referred to originally. Right now, if the USB_QUIRK_RESET_RESUME quirk is set (meaning that the device can't reset properly so it always has to be reset-resumed) then persist will be used even if it isn't enabled.
Also, that "Later kernels" thing has already arrived. I believe it was implemented in 2.6.35.
Alan Stern
Quoted 2 lines · Alan Stern
Also, that "Later kernels" thing has already arrived. I believe it was implemented in 2.6.35.
How does the kernel currently call the disconnect method? I can't yet say for sure, and it seems silly to send a v2 dropping those lines without actually knowing why they can be dropped.
Thanks,
Paul Bolle
Quoted 7 lines · Paul Bolle
Quoted 2 lines · Alan Stern
Also, that "Later kernels" thing has already arrived. I believe it was implemented in 2.6.35.
How does the kernel currently call the disconnect method? I can't yet say for sure, and it seems silly to send a v2 dropping those lines without actually knowing why they can be dropped.
In drivers/usb/core/driver.c:usb_resume_complete(), which is called during the final "complete" phase of system suspend, interfaces that were marked for rebinding (because their drivers didn't have proper PM support) get rebound.
Is that what you wanted to know?
Alan Stern
Quoted 9 lines · Alan Stern
Quoted 7 lines · Paul Bolle
Quoted 2 lines · Alan Stern
Also, that "Later kernels" thing has already arrived. I believe it was implemented in 2.6.35.
How does the kernel currently call the disconnect method? I can't yet say for sure, and it seems silly to send a v2 dropping those lines without actually knowing why they can be dropped.
Quoted 6 lines
In drivers/usb/core/driver.c:usb_resume_complete(), which is called during the final "complete" phase of system suspend, interfaces that were marked for rebinding (because their drivers didn't have proper PM support) get rebound.
Is that what you wanted to know?
I haven't yet discovered what the link is between rebinding and the "disconnect" method. I'll have to study that. This is far from urgent, so that might take me quite some time.
Thanks anyway,
Paul Bolle
Quoted 15 lines · Paul Bolle
Quoted 14 lines · Alan Stern
Quoted 7 lines · Paul Bolle
Quoted 2 lines · Alan Stern
Also, that "Later kernels" thing has already arrived. I believe it was implemented in 2.6.35.
How does the kernel currently call the disconnect method? I can't yet say for sure, and it seems silly to send a v2 dropping those lines without actually knowing why they can be dropped.
In drivers/usb/core/driver.c:usb_resume_complete(), which is called during the final "complete" phase of system suspend, interfaces that were marked for rebinding (because their drivers didn't have proper PM support) get rebound.
Quoted 5 lines
Quoted 1 line
Is that what you wanted to know?
I haven't yet discovered what the link is between rebinding and the "disconnect" method. I'll have to study that. This is far from urgent, so that might take me quite some time.
Rebinding means unbinding followed by binding. The disconnect method gets called during unbinding. The detailed call chain is:
usb_resume_complete -> rebind_marked_interfaces -> usb_rebind_intf -> usb_forced_unbind_intf -> usb_driver_release_interface -> device_release_driver -> __device_release_driver -> usb_unbind_interface -> disconnect.
Alan Stern