Re: loading firmware while usermodehelper disabled.

[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 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!

The USB suspend/resume code is full of those crazy "let's use one
function, and pass it as an *argument* what to do". It's a disease.
The PM layer used to do the same thing (PMSG_xyz crap), and we've
largely gotten rid of it, but USB still plays around with those things
and makes it even *worse* exactly with these kinds of
"do_unbind_rebind()" routines that then look at the argument instead
of having a sane routine for unbinding and another sane routine for
re-binding.

So I can't follow the crap. I *can* follow the fact that people who
write the code (or the commit messages) are clearly totally confused
by it, even when they maintain it, as exemplified by the above
example.

Alan?

                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/