mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Duncan Sands <duncan.sands@math.u-psud.fr>
To: Roman Kagan <rkagan@sw.ru>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, usbatm@lists.infradead.org,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [PATCH]  Eagle and ADI 930 usb adsl modem driver
Date: Wed, 2 Nov 2005 12:01:17 +0100	[thread overview]
Message-ID: <200511021201.17686.duncan.sands@math.u-psud.fr> (raw)
In-Reply-To: <20051102104617.GA2098@panda.sw.ru>

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 ;)

  reply	other threads:[~2005-11-02 11:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-29 22:37 matthieu castet
2005-10-31 23:58 ` Andrew Morton
2005-11-01 12:40   ` Duncan Sands
2005-11-01 13:04     ` David Woodhouse
2005-11-01 13:12       ` Marco d'Itri
2005-11-02  7:42       ` Duncan Sands
2005-11-02  7:45         ` David Woodhouse
2005-11-02  8:02           ` Duncan Sands
2005-11-02 10:46       ` Roman Kagan
2005-11-02 11:01         ` Duncan Sands [this message]
2005-11-01 13:49     ` matthieu castet
2005-11-02  5:29       ` Andrew Morton
2005-11-02 22:27         ` Greg KH
2005-11-02  7:45       ` Duncan Sands
2005-11-01 14:08   ` matthieu castet
2005-11-02  5:34     ` Andrew Morton
2005-11-02  7:47     ` Duncan Sands
2005-11-01 22:45 ` Greg KH
2005-11-02  7:54   ` Duncan Sands
2005-11-02  8:03     ` Greg KH
2005-11-02  8:45       ` [linux-usb-devel] " Oliver Neukum
2005-11-02  8:52         ` Duncan Sands
2005-11-02 21:39           ` Greg KH
2005-11-02 21:37         ` Greg KH
2005-11-02 15:56   ` Alan Stern
2005-11-02 20:15   ` matthieu castet
2005-11-02 21:18     ` matthieu castet
2005-11-07 17:47       ` Greg KH
2005-11-06 18:44     ` matthieu castet
2005-11-07 17:47       ` Greg KH
2005-11-07 17:46     ` Greg KH
2005-11-07 18:47       ` matthieu castet
2005-11-07 22:27       ` matthieu castet
2005-11-07 23:02         ` matthieu castet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511021201.17686.duncan.sands@math.u-psud.fr \
    --to=duncan.sands@math.u-psud.fr \
    --cc=akpm@osdl.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=rkagan@sw.ru \
    --cc=usbatm@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®