[PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Ben Hutchings]

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
I'm not really sure whether it's better to do this in the drivers which
specify which firmware file to use, or just once in the xc2028 tuner
driver.  Your call.

Ben.

 drivers/media/dvb/dvb-usb/cxusb.c           |    1 +
 drivers/media/dvb/dvb-usb/dib0700_devices.c |    1 +
 drivers/media/video/cx18/cx18-driver.c      |    1 +
 drivers/media/video/cx23885/cx23885-dvb.c   |    3 +++
 drivers/media/video/cx88/cx88-cards.c       |    2 ++
 drivers/media/video/em28xx/em28xx-cards.c   |    3 +++
 drivers/media/video/ivtv/ivtv-driver.c      |    1 +
 drivers/media/video/saa7134/saa7134-cards.c |    2 ++
 8 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/cxusb.c b/drivers/media/dvb/dvb-usb/cxusb.c
index f65591f..bc44d30 100644
--- a/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/drivers/media/dvb/dvb-usb/cxusb.c
@@ -1863,3 +1863,4 @@ MODULE_AUTHOR("Chris Pascoe <c.pascoe@itee.uq.edu.au>");
 MODULE_DESCRIPTION("Driver for Conexant USB2.0 hybrid reference design");
 MODULE_VERSION("1.0-alpha");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 684146f..d003ff0 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -408,6 +408,7 @@ static struct xc2028_ctrl stk7700ph_xc3028_ctrl = {
 	.max_len = 64,
 	.demod = XC3028_FE_DIBCOM52,
 };
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 
 static struct xc2028_config stk7700ph_xc3028_config = {
 	.i2c_addr = 0x61,
diff --git a/drivers/media/video/cx18/cx18-driver.c b/drivers/media/video/cx18/cx18-driver.c
index e12082b..6fdd57e 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -237,6 +237,7 @@ MODULE_AUTHOR("Hans Verkuil");
 MODULE_DESCRIPTION("CX23418 driver");
 MODULE_SUPPORTED_DEVICE("CX23418 MPEG2 encoder");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 
 MODULE_VERSION(CX18_VERSION);
 
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c
index f4f046c..fe8331a 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -956,6 +956,9 @@ static int dvb_register(struct cx23885_tsport *port)
 	return ret;
 }
 
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
+MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
+
 int cx23885_dvb_register(struct cx23885_tsport *port)
 {
 
diff --git a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
index 7330a2d..4a91dd9 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -3080,6 +3080,8 @@ void cx88_setup_xc3028(struct cx88_core *core, struct xc2028_ctrl *ctl)
 }
 EXPORT_SYMBOL_GPL(cx88_setup_xc3028);
 
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
+
 static void cx88_card_setup(struct cx88_core *core)
 {
 	static u8 eeprom[256];
diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c
index 4fd91f5..8c2048b 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2090,6 +2090,9 @@ static void em28xx_setup_xc3028(struct em28xx *dev, struct xc2028_ctrl *ctl)
 	}
 }
 
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
+MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
+
 static void em28xx_tuner_setup(struct em28xx *dev)
 {
 	struct tuner_setup           tun_setup;
diff --git a/drivers/media/video/ivtv/ivtv-driver.c b/drivers/media/video/ivtv/ivtv-driver.c
index 7cdbc1a..4c74142 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -254,6 +254,7 @@ MODULE_SUPPORTED_DEVICE
     ("CX23415/CX23416 MPEG2 encoder (WinTV PVR-150/250/350/500,\n"
 		"\t\t\tYuan MPG series and similar)");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 
 MODULE_VERSION(IVTV_VERSION);
 
diff --git a/drivers/media/video/saa7134/saa7134-cards.c b/drivers/media/video/saa7134/saa7134-cards.c
index 7e40d6d..e137203 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -7029,6 +7029,8 @@ static void saa7134_tuner_setup(struct saa7134_dev *dev)
 	}
 }
 
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
+
 /* stuff which needs working i2c */
 int saa7134_board_init2(struct saa7134_dev *dev)
 {
-- 
1.6.5.2

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Andy Walls]

On Sat, 2009-11-07 at 21:47 +0000, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> I'm not really sure whether it's better to do this in the drivers which
> specify which firmware file to use, or just once in the xc2028 tuner
> driver.  Your call.
> 
> Ben.

Ben,

I would suspect it's better left in the xc2028 tuner driver module. 

Rationale:

a. it will be consistent with other modules like the cx25840 module.
ivtv and cx23885 load the cx25840 module yet the MODULE_FIRMWARE
advertisement for the CX2584[0123] or CX2388[578] A/V core firmware is
in the cx25840 module.

b. not every ivtv or cx18 supported TV card, for example, needs the
XCeive tuner chip firmware, so it's not a strict requirement for those
modules.  It is a strict(-er) requirement for the xc2028 module.

My $0.02

Regards,
Andy

>  drivers/media/dvb/dvb-usb/cxusb.c           |    1 +
>  drivers/media/dvb/dvb-usb/dib0700_devices.c |    1 +
>  drivers/media/video/cx18/cx18-driver.c      |    1 +
>  drivers/media/video/cx23885/cx23885-dvb.c   |    3 +++
>  drivers/media/video/cx88/cx88-cards.c       |    2 ++
>  drivers/media/video/em28xx/em28xx-cards.c   |    3 +++
>  drivers/media/video/ivtv/ivtv-driver.c      |    1 +
>  drivers/media/video/saa7134/saa7134-cards.c |    2 ++
>  8 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-usb/cxusb.c b/drivers/media/dvb/dvb-usb/cxusb.c
> index f65591f..bc44d30 100644
> --- a/drivers/media/dvb/dvb-usb/cxusb.c
> +++ b/drivers/media/dvb/dvb-usb/cxusb.c
> @@ -1863,3 +1863,4 @@ MODULE_AUTHOR("Chris Pascoe <c.pascoe@itee.uq.edu.au>");
>  MODULE_DESCRIPTION("Driver for Conexant USB2.0 hybrid reference design");
>  MODULE_VERSION("1.0-alpha");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c b/drivers/media/dvb/dvb-usb/dib0700_devices.c
> index 684146f..d003ff0 100644
> --- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
> +++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
> @@ -408,6 +408,7 @@ static struct xc2028_ctrl stk7700ph_xc3028_ctrl = {
>  	.max_len = 64,
>  	.demod = XC3028_FE_DIBCOM52,
>  };
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
>  
>  static struct xc2028_config stk7700ph_xc3028_config = {
>  	.i2c_addr = 0x61,
> diff --git a/drivers/media/video/cx18/cx18-driver.c b/drivers/media/video/cx18/cx18-driver.c
> index e12082b..6fdd57e 100644
> --- a/drivers/media/video/cx18/cx18-driver.c
> +++ b/drivers/media/video/cx18/cx18-driver.c
> @@ -237,6 +237,7 @@ MODULE_AUTHOR("Hans Verkuil");
>  MODULE_DESCRIPTION("CX23418 driver");
>  MODULE_SUPPORTED_DEVICE("CX23418 MPEG2 encoder");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
>  
>  MODULE_VERSION(CX18_VERSION);
>  
> diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c
> index f4f046c..fe8331a 100644
> --- a/drivers/media/video/cx23885/cx23885-dvb.c
> +++ b/drivers/media/video/cx23885/cx23885-dvb.c
> @@ -956,6 +956,9 @@ static int dvb_register(struct cx23885_tsport *port)
>  	return ret;
>  }
>  
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> +MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
> +
>  int cx23885_dvb_register(struct cx23885_tsport *port)
>  {
>  
> diff --git a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
> index 7330a2d..4a91dd9 100644
> --- a/drivers/media/video/cx88/cx88-cards.c
> +++ b/drivers/media/video/cx88/cx88-cards.c
> @@ -3080,6 +3080,8 @@ void cx88_setup_xc3028(struct cx88_core *core, struct xc2028_ctrl *ctl)
>  }
>  EXPORT_SYMBOL_GPL(cx88_setup_xc3028);
>  
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> +
>  static void cx88_card_setup(struct cx88_core *core)
>  {
>  	static u8 eeprom[256];
> diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c
> index 4fd91f5..8c2048b 100644
> --- a/drivers/media/video/em28xx/em28xx-cards.c
> +++ b/drivers/media/video/em28xx/em28xx-cards.c
> @@ -2090,6 +2090,9 @@ static void em28xx_setup_xc3028(struct em28xx *dev, struct xc2028_ctrl *ctl)
>  	}
>  }
>  
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> +MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
> +
>  static void em28xx_tuner_setup(struct em28xx *dev)
>  {
>  	struct tuner_setup           tun_setup;
> diff --git a/drivers/media/video/ivtv/ivtv-driver.c b/drivers/media/video/ivtv/ivtv-driver.c
> index 7cdbc1a..4c74142 100644
> --- a/drivers/media/video/ivtv/ivtv-driver.c
> +++ b/drivers/media/video/ivtv/ivtv-driver.c
> @@ -254,6 +254,7 @@ MODULE_SUPPORTED_DEVICE
>      ("CX23415/CX23416 MPEG2 encoder (WinTV PVR-150/250/350/500,\n"
>  		"\t\t\tYuan MPG series and similar)");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
>  
>  MODULE_VERSION(IVTV_VERSION);
>  
> diff --git a/drivers/media/video/saa7134/saa7134-cards.c b/drivers/media/video/saa7134/saa7134-cards.c
> index 7e40d6d..e137203 100644
> --- a/drivers/media/video/saa7134/saa7134-cards.c
> +++ b/drivers/media/video/saa7134/saa7134-cards.c
> @@ -7029,6 +7029,8 @@ static void saa7134_tuner_setup(struct saa7134_dev *dev)
>  	}
>  }
>  
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> +
>  /* stuff which needs working i2c */
>  int saa7134_board_init2(struct saa7134_dev *dev)
>  {

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Devin Heitmueller]

On Sat, Nov 7, 2009 at 8:37 PM, Andy Walls <awalls@radix.net> wrote:
> On Sat, 2009-11-07 at 21:47 +0000, Ben Hutchings wrote:
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> ---
>> I'm not really sure whether it's better to do this in the drivers which
>> specify which firmware file to use, or just once in the xc2028 tuner
>> driver.  Your call.
>>
>> Ben.
>
> Ben,
>
> I would suspect it's better left in the xc2028 tuner driver module.
>
> Rationale:
>
> a. it will be consistent with other modules like the cx25840 module.
> ivtv and cx23885 load the cx25840 module yet the MODULE_FIRMWARE
> advertisement for the CX2584[0123] or CX2388[578] A/V core firmware is
> in the cx25840 module.
>
> b. not every ivtv or cx18 supported TV card, for example, needs the
> XCeive tuner chip firmware, so it's not a strict requirement for those
> modules.  It is a strict(-er) requirement for the xc2028 module.
>
> My $0.02
>
> Regards,
> Andy

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.

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?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Andy Walls]

On Sat, 2009-11-07 at 20:44 -0500, Devin Heitmueller wrote:
> On Sat, Nov 7, 2009 at 8:37 PM, Andy Walls <awalls@radix.net> wrote:
> > On Sat, 2009-11-07 at 21:47 +0000, Ben Hutchings wrote:
> >> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> >> ---
> >> I'm not really sure whether it's better to do this in the drivers which
> >> specify which firmware file to use, or just once in the xc2028 tuner
> >> driver.  Your call.
> >>
> >> Ben.
> >
> > Ben,
> >
> > I would suspect it's better left in the xc2028 tuner driver module.
> >
> > Rationale:
> >
> > a. it will be consistent with other modules like the cx25840 module.
> > ivtv and cx23885 load the cx25840 module yet the MODULE_FIRMWARE
> > advertisement for the CX2584[0123] or CX2388[578] A/V core firmware is
> > in the cx25840 module.
> >
> > b. not every ivtv or cx18 supported TV card, for example, needs the
> > XCeive tuner chip firmware, so it's not a strict requirement for those
> > modules.  It is a strict(-er) requirement for the xc2028 module.
> >
> > My $0.02
> >
> > Regards,
> > Andy
> 
> 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.
> 
> 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?

Devin,

Maybe these old references will help answer questions:

http://lwn.net/Articles/197362/
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg01007.html


I generally think (as likely you may) that V4L-DVB drivers may have a
somewhat unique position of having multi-card, multi-chip firmware image
needs.

Some firmware is mandatory for all cards supported by a driver - that's
not an issue.  

However, many drivers then have cases where "you may need these other
two firmwares files too, depending on the card you have and the version
of the card you have."

In the cx18 driver, the Yuan MPC-718 is a good example of such a card.

The ivtv driver has a number of required firmware permutations, given
the cards it supports.  The only firmware that is always required in
ivtv is the MPEG encoder firmware.

I'm not sure if MODULE_FIRMWARE advertisements won't cause people undue
worry/work without more amplifying information associated with the
firmware file names.  Maybe it's a "don't care" in the end;  I've
noticed a trend that many users don't know about /sbin/modinfo...

Regards,
Andy

> Devin

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Sat, 2009-11-07 at 20:44 -0500, Devin Heitmueller wrote:
> On Sat, Nov 7, 2009 at 8:37 PM, Andy Walls <awalls@radix.net> wrote:
> > On Sat, 2009-11-07 at 21:47 +0000, Ben Hutchings wrote:
> >> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> >> ---
> >> I'm not really sure whether it's better to do this in the drivers which
> >> specify which firmware file to use, or just once in the xc2028 tuner
> >> driver.  Your call.
> >>
> >> Ben.
> >
> > Ben,
> >
> > I would suspect it's better left in the xc2028 tuner driver module.
> >
> > Rationale:
> >
> > a. it will be consistent with other modules like the cx25840 module.
> > ivtv and cx23885 load the cx25840 module yet the MODULE_FIRMWARE
> > advertisement for the CX2584[0123] or CX2388[578] A/V core firmware is
> > in the cx25840 module.
> >
> > b. not every ivtv or cx18 supported TV card, for example, needs the
> > XCeive tuner chip firmware, so it's not a strict requirement for those
> > modules.  It is a strict(-er) requirement for the xc2028 module.
> >
> > My $0.02
> >
> > Regards,
> > Andy
> 
> 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.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                            - Robert Coveyou

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Mauro Carvalho Chehab]

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

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[hermann pitton]

Hi,

Am Sonntag, den 08.11.2009, 01:20 -0200 schrieb Mauro Carvalho Chehab:
> 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.

Mauro, that could lead to some misunderstanding of the current use
conditions, at least on saa7134.

Minor annotations, the tda10046 does not store firmware internally, but
there are cards which have an extra eeprom to store such firmware.

If such a firmware eeprom is found and correctly configured, the driver
in all cases will load the firmware from that eeprom and all other
firmware in /lib/firmware is ignored.

If not, the firmware will be loaded from /lib/firmware.

For all what I know, firmware revisions 26 and 29 are both valid
"enough", correspondents to what we can load either from TechnoTrend or
LifeView with the getfirmware script, and might be either stored in an
extra eeprom or loaded from host/file.

Prior revisions had issues with missing freqs, in what combination ever.

We also can't totally exclude, given the whole mass of such, that in
some cases firmware eeproms might exist on some boards, but are not
correctly configured and load from host only because of that.

The tendency seen overall is that competitors save the few cents for an
extra firmware eeprom these days ...

Cheers,
Hermann

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

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Mauro Carvalho Chehab]

Em Mon, 09 Nov 2009 00:32:29 +0100
hermann pitton <hermann-pitton@arcor.de> escreveu:

> > 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.
> 
> Mauro, that could lead to some misunderstanding of the current use
> conditions, at least on saa7134.
> 
> Minor annotations, the tda10046 does not store firmware internally, but
> there are cards which have an extra eeprom to store such firmware.
> 
> If such a firmware eeprom is found and correctly configured, the driver
> in all cases will load the firmware from that eeprom and all other
> firmware in /lib/firmware is ignored.
> 
> If not, the firmware will be loaded from /lib/firmware.
> 
> For all what I know, firmware revisions 26 and 29 are both valid
> "enough", correspondents to what we can load either from TechnoTrend or
> LifeView with the getfirmware script, and might be either stored in an
> extra eeprom or loaded from host/file.
> 
> Prior revisions had issues with missing freqs, in what combination ever.
> 
> We also can't totally exclude, given the whole mass of such, that in
> some cases firmware eeproms might exist on some boards, but are not
> correctly configured and load from host only because of that.
> 
> The tendency seen overall is that competitors save the few cents for an
> extra firmware eeprom these days ...

Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
revision 29 stored at the eeprom).

The point is that it is not mandatory for such devices to have a firmware
at the filesystem for the device to work. So, a static indication that
devices with tda10046 need firmware is wrong, since some devices don't need
it.

Cheers,
Mauro

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[hermann pitton]

Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab:
> Em Mon, 09 Nov 2009 00:32:29 +0100
> hermann pitton <hermann-pitton@arcor.de> escreveu:
> 
> > > 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.
> > 
> > Mauro, that could lead to some misunderstanding of the current use
> > conditions, at least on saa7134.
> > 
> > Minor annotations, the tda10046 does not store firmware internally, but
> > there are cards which have an extra eeprom to store such firmware.
> > 
> > If such a firmware eeprom is found and correctly configured, the driver
> > in all cases will load the firmware from that eeprom and all other
> > firmware in /lib/firmware is ignored.
> > 
> > If not, the firmware will be loaded from /lib/firmware.
> > 
> > For all what I know, firmware revisions 26 and 29 are both valid
> > "enough", correspondents to what we can load either from TechnoTrend or
> > LifeView with the getfirmware script, and might be either stored in an
> > extra eeprom or loaded from host/file.
> > 
> > Prior revisions had issues with missing freqs, in what combination ever.
> > 
> > We also can't totally exclude, given the whole mass of such, that in
> > some cases firmware eeproms might exist on some boards, but are not
> > correctly configured and load from host only because of that.
> > 
> > The tendency seen overall is that competitors save the few cents for an
> > extra firmware eeprom these days ...
> 
> Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
> revision 29 stored at the eeprom).
> 
> The point is that it is not mandatory for such devices to have a firmware
> at the filesystem for the device to work. So, a static indication that
> devices with tda10046 need firmware is wrong, since some devices don't need
> it.

There are of course lots of devices needing the firmware mandatory at
the file system. I try to tell that it is not a mistake, in case the
device has no firmware on an extra eeprom, to store latest revision
in /lib/firmware. Or tell me better ...

But also, OEMs a little bit more motivated on new hardware will not
count the costs of an extra firmware eeprom, if being first in having
substantial amounts of chips and get a good deal for such. But that was
the past.

> Cheers,
> Mauro

Else I do totally agree.

I do just point to some ambiguous conditions we should stay aware of.

It is very unlikely that we can "talk" them away.

Do we have all firmware loaded from eeproms possibly existing on cards
is only one minor question.

Maybe we miss some.

Should we not even better avoid such, since still no official update for
firmware eeprom flashing?

To restore the bridge eeprom we seem to be not such bad now, but also
the reasons for a possible corruption are far from clearly identified in
case we should be involved in it.

Despite of legal issues, we should have the latest revision of the
tda10046 firmware at the host. As said, those having it at an extra
eeprom will load it anyway from there.

Cheers,
Hermann
 

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[Mauro Carvalho Chehab]

Em Mon, 09 Nov 2009 03:02:49 +0100
hermann pitton <hermann-pitton@arcor.de> escreveu:

> 
> Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab:
> > Em Mon, 09 Nov 2009 00:32:29 +0100
> > hermann pitton <hermann-pitton@arcor.de> escreveu:
> > 
> > > > 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.
> > > 
> > > Mauro, that could lead to some misunderstanding of the current use
> > > conditions, at least on saa7134.
> > > 
> > > Minor annotations, the tda10046 does not store firmware internally, but
> > > there are cards which have an extra eeprom to store such firmware.
> > > 
> > > If such a firmware eeprom is found and correctly configured, the driver
> > > in all cases will load the firmware from that eeprom and all other
> > > firmware in /lib/firmware is ignored.
> > > 
> > > If not, the firmware will be loaded from /lib/firmware.
> > > 
> > > For all what I know, firmware revisions 26 and 29 are both valid
> > > "enough", correspondents to what we can load either from TechnoTrend or
> > > LifeView with the getfirmware script, and might be either stored in an
> > > extra eeprom or loaded from host/file.
> > > 
> > > Prior revisions had issues with missing freqs, in what combination ever.
> > > 
> > > We also can't totally exclude, given the whole mass of such, that in
> > > some cases firmware eeproms might exist on some boards, but are not
> > > correctly configured and load from host only because of that.
> > > 
> > > The tendency seen overall is that competitors save the few cents for an
> > > extra firmware eeprom these days ...
> > 
> > Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
> > revision 29 stored at the eeprom).
> > 
> > The point is that it is not mandatory for such devices to have a firmware
> > at the filesystem for the device to work. So, a static indication that
> > devices with tda10046 need firmware is wrong, since some devices don't need
> > it.
> 
> There are of course lots of devices needing the firmware mandatory at
> the file system. I try to tell that it is not a mistake, in case the
> device has no firmware on an extra eeprom, to store latest revision
> in /lib/firmware. Or tell me better ...
> 
> But also, OEMs a little bit more motivated on new hardware will not
> count the costs of an extra firmware eeprom, if being first in having
> substantial amounts of chips and get a good deal for such. But that was
> the past.
> 
> > Cheers,
> > Mauro
> 
> Else I do totally agree.
> 
> I do just point to some ambiguous conditions we should stay aware of.
> 
> It is very unlikely that we can "talk" them away.
> 
> Do we have all firmware loaded from eeproms possibly existing on cards
> is only one minor question.
> 
> Maybe we miss some.
> 
> Should we not even better avoid such, since still no official update for
> firmware eeprom flashing?
> 
> To restore the bridge eeprom we seem to be not such bad now, but also
> the reasons for a possible corruption are far from clearly identified in
> case we should be involved in it.
> 
> Despite of legal issues, we should have the latest revision of the
> tda10046 firmware at the host. As said, those having it at an extra
> eeprom will load it anyway from there.

Hermann, maybe you missed the point here: the driver will keep dynamically
loading the modules at the right place, for the devices that really need
firmwares to run.

The issue I'm seeing is that the MODULE_FIRMWARE series of patches is adding an
static meta-tag that indicates that the devices associated with a driver will
need one or more firmwares, with the specified names at the tag.

While it is not clear on Ben's proposal how those userspace tools will be,
considering that he is concerning about initramfs and that there are devices
(like for example rtl8192u) that needs several firmwares to run, in order to
properly work for initramfs, the tools should assume that all firmwares using
the tag will be needed for that device, to be sure that the machine won't hang
during the boot.

In the case of the v4l-dvb devices, the firmware needs are dynamic.

For example, in the case of tuner-xc2028, you need _OR_ xc3028 _OR_ xc3028l
firmwares (and, if considering tm6000 devices, you may need firmware version 1
for older devices). In the case of tda10046, some devices will need a firmware,
while others won't need. 

So, you'll only know what firmware is really needed at runtime.

An alternative for a static table would be to associate the firmware needs
to the USB and PCI ID's, but even the USB/PCI ID tables will also have some
troubles. For example, the flexcop driver supports 7 different versions of a
device, all sharing the same PCI ID, but each version requires a different
frontend. The driver only knows what frontend is needed at runtime, after
probing the i2c bus at the device.

So, the main point here is that a tag like this is useless for the devices under
drivers/media. The only way to really know for sure what firmware is needed on
a particular hardware is to catch the firmware requests. If such check is
really needed, the better is to add a hook at the userspace, catching all
requests for firmwares for the detected hardware. Such usage will get 100% of
the cases and won't require any kernel changes.

That's said, I can fully understand the utility of that having a tag like that
for block and network devices that needs to load a firmware during boot time,
at initramfs. As you need to access the hard disk or the network in order to
mount the file system, having the proper firmware there is mandatory.

Except for those kind of devices, we shouldn't be adding MODULE_FIRMWARE to
other random devices, especially where the firmware requirements cannot be
specified by a static rule.

Cheers,
Mauro

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[hermann pitton]

Hi,

Am Montag, den 09.11.2009, 09:37 -0200 schrieb Mauro Carvalho Chehab:
> Em Mon, 09 Nov 2009 03:02:49 +0100
> hermann pitton <hermann-pitton@arcor.de> escreveu:
> 
> > 
> > Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab:
> > > Em Mon, 09 Nov 2009 00:32:29 +0100
> > > hermann pitton <hermann-pitton@arcor.de> escreveu:
> > > 
> > > > > 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.
> > > > 
> > > > Mauro, that could lead to some misunderstanding of the current use
> > > > conditions, at least on saa7134.
> > > > 
> > > > Minor annotations, the tda10046 does not store firmware internally, but
> > > > there are cards which have an extra eeprom to store such firmware.
> > > > 
> > > > If such a firmware eeprom is found and correctly configured, the driver
> > > > in all cases will load the firmware from that eeprom and all other
> > > > firmware in /lib/firmware is ignored.
> > > > 
> > > > If not, the firmware will be loaded from /lib/firmware.
> > > > 
> > > > For all what I know, firmware revisions 26 and 29 are both valid
> > > > "enough", correspondents to what we can load either from TechnoTrend or
> > > > LifeView with the getfirmware script, and might be either stored in an
> > > > extra eeprom or loaded from host/file.
> > > > 
> > > > Prior revisions had issues with missing freqs, in what combination ever.
> > > > 
> > > > We also can't totally exclude, given the whole mass of such, that in
> > > > some cases firmware eeproms might exist on some boards, but are not
> > > > correctly configured and load from host only because of that.
> > > > 
> > > > The tendency seen overall is that competitors save the few cents for an
> > > > extra firmware eeprom these days ...
> > > 
> > > Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
> > > revision 29 stored at the eeprom).
> > > 
> > > The point is that it is not mandatory for such devices to have a firmware
> > > at the filesystem for the device to work. So, a static indication that
> > > devices with tda10046 need firmware is wrong, since some devices don't need
> > > it.
> > 
> > There are of course lots of devices needing the firmware mandatory at
> > the file system. I try to tell that it is not a mistake, in case the
> > device has no firmware on an extra eeprom, to store latest revision
> > in /lib/firmware. Or tell me better ...
> > 
> > But also, OEMs a little bit more motivated on new hardware will not
> > count the costs of an extra firmware eeprom, if being first in having
> > substantial amounts of chips and get a good deal for such. But that was
> > the past.
> > 
> > > Cheers,
> > > Mauro
> > 
> > Else I do totally agree.
> > 
> > I do just point to some ambiguous conditions we should stay aware of.
> > 
> > It is very unlikely that we can "talk" them away.
> > 
> > Do we have all firmware loaded from eeproms possibly existing on cards
> > is only one minor question.
> > 
> > Maybe we miss some.
> > 
> > Should we not even better avoid such, since still no official update for
> > firmware eeprom flashing?
> > 
> > To restore the bridge eeprom we seem to be not such bad now, but also
> > the reasons for a possible corruption are far from clearly identified in
> > case we should be involved in it.
> > 
> > Despite of legal issues, we should have the latest revision of the
> > tda10046 firmware at the host. As said, those having it at an extra
> > eeprom will load it anyway from there.
> 
> Hermann, maybe you missed the point here: the driver will keep dynamically
> loading the modules at the right place, for the devices that really need
> firmwares to run.
> 
> The issue I'm seeing is that the MODULE_FIRMWARE series of patches is adding an
> static meta-tag that indicates that the devices associated with a driver will
> need one or more firmwares, with the specified names at the tag.
> 
> While it is not clear on Ben's proposal how those userspace tools will be,
> considering that he is concerning about initramfs and that there are devices
> (like for example rtl8192u) that needs several firmwares to run, in order to
> properly work for initramfs, the tools should assume that all firmwares using
> the tag will be needed for that device, to be sure that the machine won't hang
> during the boot.
> 
> In the case of the v4l-dvb devices, the firmware needs are dynamic.
> 
> For example, in the case of tuner-xc2028, you need _OR_ xc3028 _OR_ xc3028l
> firmwares (and, if considering tm6000 devices, you may need firmware version 1
> for older devices). In the case of tda10046, some devices will need a firmware,
> while others won't need. 
> 
> So, you'll only know what firmware is really needed at runtime.
> 
> An alternative for a static table would be to associate the firmware needs
> to the USB and PCI ID's, but even the USB/PCI ID tables will also have some
> troubles. For example, the flexcop driver supports 7 different versions of a
> device, all sharing the same PCI ID, but each version requires a different
> frontend. The driver only knows what frontend is needed at runtime, after
> probing the i2c bus at the device.

sorry, if I did not follow up close enough. The flexcop driver is really
a good example.

> So, the main point here is that a tag like this is useless for the devices under
> drivers/media. The only way to really know for sure what firmware is needed on
> a particular hardware is to catch the firmware requests. If such check is
> really needed, the better is to add a hook at the userspace, catching all
> requests for firmwares for the detected hardware. Such usage will get 100% of
> the cases and won't require any kernel changes.
> 
> That's said, I can fully understand the utility of that having a tag like that
> for block and network devices that needs to load a firmware during boot time,
> at initramfs. As you need to access the hard disk or the network in order to
> mount the file system, having the proper firmware there is mandatory.
> 
> Except for those kind of devices, we shouldn't be adding MODULE_FIRMWARE to
> other random devices, especially where the firmware requirements cannot be
> specified by a static rule.
> 
> Cheers,
> Mauro

I for sure don't vote for having v4l-dvb firmware at boot available.

My maybe a little narrowed view is focused on the question, if we can
have latest tda10046 firmware at /lib/firmware and if there are any
cases known, like on other drivers, not to have it there.

If there are no known issues with latest, we should ask Philips/NXP if
we are allowed to distribute it with the kernel.

Cheers,
Hermann

Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

[hermann pitton]

[snip]
> 
> If there are no known issues with latest, we should ask Philips/NXP if
> we are allowed to distribute it with the kernel.

To make it more clear.

OEMs did modify the eeprom content of their devices not following the
Philips rules anymore and causing troubles.

I would like to know, if this can happen for firmware too.

I really hope it never came to this point.

Cheers,
Hermann