All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Duncan Sands <duncan.sands@math.u-psud.fr>
Cc: Jon Masters <jonathan@jonmasters.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] binary firmware and modules
Date: Tue, 18 Apr 2006 17:41:18 +0200	[thread overview]
Message-ID: <1145374878.10255.69.camel@localhost> (raw)
In-Reply-To: <200604181659.04657.duncan.sands@math.u-psud.fr>

Hi Duncan,

> > we have two kind of devices that need firmware download. The easy and
> > clean ones which need one or two files and these basically change not
> > that often. In most cases these are the network or storage devices and
> > for exactly these we need the MODULE_FIRMWARE() support to know which
> > files have to be put into initrd.
> 
> > The messed up devices like the Speedtouch and maybe even some WiFi
> > dongles are another story.
> 
> I don't know why you consider the speedtouch to be messed up.  What's
> messed up is not the modems themselves, but the fact that we don't know
> what modems exist, and how they differ in their firmware requirements.

if you don't know the firmware requirements, then this is what I call
messed up. I now that this is basically the fault of the manufacturer or
missing specifications, but wild guessing on the firmware doesn't really
help. A kernel driver should know which firmware it needs.

> Anyway, speedtouch users also need their firmware to end up in any initrd.
> Since the driver expects all firmware files to start with "speedtch",
> the MODULE_FIRMWARE scheme would work for the speedtouch driver too as
> long as it allows the driver to specify just the initial part of a file
> name.  You could go all the way to regular expressions, but that seems
> a bit ridiculous.

I personally prefer full firmware names. This makes the dependency easy
and even an end user can call modinfo and see what firmware is expected
by a certain driver (without looking at the source code).

Regards

Marcel



  reply	other threads:[~2006-04-18 15:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-15  8:10 [RFC] binary firmware and modules Jon Masters
2006-04-15  9:54 ` Oliver Neukum
2006-04-17 14:22   ` John W. Linville
2006-04-17 14:29     ` Arjan van de Ven
2006-04-17 14:38       ` Marcel Holtmann
2006-04-17 15:15       ` Duncan Sands
2006-04-17 16:10         ` Marcel Holtmann
2006-04-18 13:16 ` Jon Masters
2006-04-18 13:37   ` Duncan Sands
2006-04-18 14:14     ` Jon Masters
2006-04-18 15:14       ` Duncan Sands
2006-04-19  0:01         ` Jon Masters
2006-04-18 14:22     ` Marcel Holtmann
2006-04-18 14:59       ` Duncan Sands
2006-04-18 15:41         ` Marcel Holtmann [this message]
2006-04-19 13:28           ` Mark Lord
2006-04-19 13:37             ` Marcel Holtmann
2006-04-19 14:10               ` Jon Masters
2006-04-18 14:25   ` Marcel Holtmann

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=1145374878.10255.69.camel@localhost \
    --to=marcel@holtmann.org \
    --cc=duncan.sands@math.u-psud.fr \
    --cc=jonathan@jonmasters.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.