Hi Roman, glad to see you're still alive!
On Wednesday 2 November 2005 11:46, Roman Kagan wrote:
> On Tue, Nov 01, 2005 at 01:04:02PM +0000, David Woodhouse wrote:
> > On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> > > this code looks like a 'orrible hack to work around a common problem
> > > with USB modem's of this type: if the modem is plugged in while the
> > > system boots, the driver may look for firmware before the filesystem
> > > holding the firmware is mounted; I guess the delay usually gives
> > > the filesystem enough time to be mounted. I'm told that the correct
> > > solution is to stick the firmware in an initramfs as well.
> >
> > Why can't we request the firmware again when the device is first used,
> > if it wasn't present when the driver was first loaded?
>
> Because the firmware loading can take long, and apps may legitimately
> give up opening the device after a timeout.
>
> Besides, it doesn't look logical. An uninitialized device is not
> particularly useful for anything but initialization. You don't create,
> say, a network device for your ethernet card until you're finished with
> its PCI setup, do you?
>
> I think the async firmware loading can do the job nicely, in a generic
> manner. BTW the usbatm drivers do it already (wasn't it you who
> implemented it? :), long before request_firmware_nowait() was available.
> So it's only a matter of tools adjusting, which seems to be going on.
I can't help feeling that it is wrong to add ad-hoc code to drivers (such
as: if the firmware wasn't there, try to load it again later) in an attempt
to work around what is, in the end, a userspace configuration problem. The
fact that configuring userspace correctly seems to be tricky is sad, but not
the driver's problem.
I don't mind using request_firmware_nowait by the way. The lack of a
timeout is no problem as long as we make it possible for the user to shoot
the firmware loading down by sending a signal.
Ciao,
Duncan.
PS: On the other hand, users are feeling the pain, which means I get to feel
their pain, which tempts me to hack in a workaround ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]