All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Andy Walls <awalls@radix.net>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using  XC2028 and XC3028L tuners
Date: Sun, 8 Nov 2009 01:20:42 -0200	[thread overview]
Message-ID: <20091108012042.798835dd@pedra.chehab.org> (raw)
In-Reply-To: <1257645834.15927.634.camel@localhost>

Hi Ben,

> > It's not clear to me what this MODULE_FIRMWARE is going to be used
> > for, but if it's for some sort of module dependency system, then it
> > definitely should *not* be a dependency for em28xx.  There are lots of
> > em28xx based devices that do not use the xc3028, and those users
> > should not be expected to go out and find/extract the firmware for
> > some tuner they don't have.
> 
> This information is currently used by initramfs builders to find
> required firmware files.  I also use this information in the Debian
> kernel upgrade script to warn if a currently loaded driver may require
> firmware in the new kernel version and the firmware is not installed.
> This is important during the transition of various drivers from built-in
> to separate firmware.
> 
> Neither of these uses applies to TV tuners, but the information may
> still be useful in installers.

> > Also, how does this approach handle the situation where there are two
> > different possible firmwares depending on the card using the firmware.
> >  As in the example above, you the xc3028 can require either the xc3028
> > or xc3028L firmware depending on the board they have.  Does this
> > change now result in both firmware images being required?
> 
> It really depends on how the information is used.  Given that there are
> many drivers that load different firmware files for different devices
> (or even support multiple different versions with different names), it
> would be rather stupid to treat these declaration as requirements.

I agree. An interesting case happens with devices that uses tda10046 DVB demods.
They have the firmware stored internally on their eeprom. Those firmwares can be
replaced by a different version loaded in ram, but, in general, they work
properly with the eeprom one. So, even having the firmware load code there,
the firmware at /lib/firmware is optional.

-

I don't see any reason why we should add MODULE_FIRMWARE for v4l/dvb devices.
As you said, its primary usage is focused on booting a machine, and none
of those devices would affect booting. 

As you pointed, the secondary usage doesn't seem to apply to those devices as
well, and seems to be distro-specific, since different distros use different
methods to check for firmware dependencies, generally relying at the package
metadata. To make things worse, several of those firmwares still don't have any
redistribution rights license that would be required for its inclusion on a distro
package.

Also, as this macro have no current usage that would make sense for those
drivers, I'm afraid that, as time goes by, people will simply forget to
keep it updated, since they'll need to add the same firmware name on two
different places.

That's said, for now, the better is to not add those macros for the devices
under /drivers/media. They'll just waste some space at the object file, and
require an additional maintenance care for no good reason.

Cheers,
Mauro

  reply	other threads:[~2009-11-08  3:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-07 21:47 [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners Ben Hutchings
2009-11-08  1:37 ` Andy Walls
2009-11-08  1:44   ` Devin Heitmueller
2009-11-08  2:02     ` Andy Walls
2009-11-08  2:03     ` Ben Hutchings
2009-11-08  3:20       ` Mauro Carvalho Chehab [this message]
2009-11-08 23:32         ` hermann pitton
2009-11-09  0:43           ` Mauro Carvalho Chehab
2009-11-09  2:02             ` hermann pitton
2009-11-09 11:37               ` Mauro Carvalho Chehab
2009-11-09 23:53                 ` hermann pitton
2009-11-10  0:19                   ` hermann pitton

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=20091108012042.798835dd@pedra.chehab.org \
    --to=mchehab@infradead.org \
    --cc=awalls@radix.net \
    --cc=ben@decadent.org.uk \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@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.