[PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Paul Bolle]

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.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
"[...] 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(-)

diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index 1392b61d6ebe..90dc927f0e1e 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -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;
-- 
1.9.3

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Alan Stern]

On Tue, 24 Jun 2014, Paul Bolle wrote:

> 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.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> "[...] 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(-)
> 
> diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
> index 1392b61d6ebe..90dc927f0e1e 100644
> --- a/Documentation/usb/power-management.txt
> +++ b/Documentation/usb/power-management.txt
> @@ -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

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Paul Bolle]

On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> 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

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Alan Stern]

On Tue, 24 Jun 2014, Paul Bolle wrote:

> On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> > 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

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Paul Bolle]

On Tue, 2014-06-24 at 13:19 -0400, Alan Stern wrote:
> On Tue, 24 Jun 2014, Paul Bolle wrote:
> > On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> > > 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?

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

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Alan Stern]

On Wed, 2 Jul 2014, Paul Bolle wrote:

> On Tue, 2014-06-24 at 13:19 -0400, Alan Stern wrote:
> > On Tue, 24 Jun 2014, Paul Bolle wrote:
> > > On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> > > > 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?
> 
> 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