* [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners @ 2009-11-07 21:47 Ben Hutchings 2009-11-08 1:37 ` Andy Walls 0 siblings, 1 reply; 12+ messages in thread From: Ben Hutchings @ 2009-11-07 21:47 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 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 0 siblings, 1 reply; 12+ messages in thread From: Andy Walls @ 2009-11-08 1:37 UTC (permalink / raw) To: Ben Hutchings; +Cc: Mauro Carvalho Chehab, linux-media 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) > { ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 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 0 siblings, 2 replies; 12+ messages in thread From: Devin Heitmueller @ 2009-11-08 1:44 UTC (permalink / raw) To: Andy Walls; +Cc: Ben Hutchings, Mauro Carvalho Chehab, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-08 1:44 ` Devin Heitmueller @ 2009-11-08 2:02 ` Andy Walls 2009-11-08 2:03 ` Ben Hutchings 1 sibling, 0 replies; 12+ messages in thread From: Andy Walls @ 2009-11-08 2:02 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Ben Hutchings, Mauro Carvalho Chehab, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 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 1 sibling, 1 reply; 12+ messages in thread From: Ben Hutchings @ 2009-11-08 2:03 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Andy Walls, Mauro Carvalho Chehab, linux-media [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-08 2:03 ` Ben Hutchings @ 2009-11-08 3:20 ` Mauro Carvalho Chehab 2009-11-08 23:32 ` hermann pitton 0 siblings, 1 reply; 12+ messages in thread From: Mauro Carvalho Chehab @ 2009-11-08 3:20 UTC (permalink / raw) To: Ben Hutchings; +Cc: Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-08 3:20 ` Mauro Carvalho Chehab @ 2009-11-08 23:32 ` hermann pitton 2009-11-09 0:43 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 12+ messages in thread From: hermann pitton @ 2009-11-08 23:32 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-08 23:32 ` hermann pitton @ 2009-11-09 0:43 ` Mauro Carvalho Chehab 2009-11-09 2:02 ` hermann pitton 0 siblings, 1 reply; 12+ messages in thread From: Mauro Carvalho Chehab @ 2009-11-09 0:43 UTC (permalink / raw) To: hermann pitton; +Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-09 0:43 ` Mauro Carvalho Chehab @ 2009-11-09 2:02 ` hermann pitton 2009-11-09 11:37 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 12+ messages in thread From: hermann pitton @ 2009-11-09 2:02 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-09 2:02 ` hermann pitton @ 2009-11-09 11:37 ` Mauro Carvalho Chehab 2009-11-09 23:53 ` hermann pitton 0 siblings, 1 reply; 12+ messages in thread From: Mauro Carvalho Chehab @ 2009-11-09 11:37 UTC (permalink / raw) To: hermann pitton; +Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-09 11:37 ` Mauro Carvalho Chehab @ 2009-11-09 23:53 ` hermann pitton 2009-11-10 0:19 ` hermann pitton 0 siblings, 1 reply; 12+ messages in thread From: hermann pitton @ 2009-11-09 23:53 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners 2009-11-09 23:53 ` hermann pitton @ 2009-11-10 0:19 ` hermann pitton 0 siblings, 0 replies; 12+ messages in thread From: hermann pitton @ 2009-11-10 0:19 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ben Hutchings, Devin Heitmueller, Andy Walls, linux-media [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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-11-10 0:27 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.