Am Dienstag, 3. Januar 2012, 06:53:46 schrieb Linus Torvalds:
> On Mon, Jan 2, 2012 at 7:25 PM, Matthew Garrett <mjg@xxxxxxxxxx> wrote:
> > On Mon, Jan 02, 2012 at 09:45:58PM -0500, Alan Stern wrote:
> >
> >> Wait a second. Why does isight_firmware bind at this time? Binding to
> >> new devices is handled by khubd, which doesn't start running again
> >> until after the resume is finished (the device appears to be new
> >> because its descriptors have changed). At that point there should be
> >> no trouble reloading the firmware.
> >
> > Then why are we getting this warning? The firmware is only loaded in the
> > probe function.
>
> The USB suspend/resume function does that "unbind/rebind" dance, and
> that causes a "device_attach()". Which causes a probe() to be called.
>
> Should it do that? I think not, not if the ID's haven't changed. But I
> don't know the USB layer all that well.
The ID has changed. That is why we run into this problem.
And indeed the USB layer does the rebind only if either
a) ID has changed
b) the driver tells us that it cannot deal with a device that has lost its state
> The whole USB suspend/resume code is also very confused in general.
> See for example commit c043f1245654 ("USB: unbind all interfaces
> before rebinding them") which talks about how the USB layer needs to
> unbind all interfaces in order to rebind them later. But then you
> look at the *code*, and it actually does a DO_REBIND, not an unbind!
Understood. Working on that.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
