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