On Sat, 2009-03-07 at 18:26 -0500, Devin Heitmueller wrote: > On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf > <dougsland@xxxxxxxxx> wrote: > > Hi Mauro, > > > > Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the > > following: > > > > - v4l2-apps/util: Add rewrite_eeprom tool > > Modules this script is known to work with: > > em28xx and saa7134 > > > > Thanks, > > Douglas > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Wow, this script really scares the crap out of me. Actually it appears to be a meta-script. It builds a script of i2c-set commands to reload an eeprom. You then have an opportunity to review the script to reload the EEPROM and then run it. You first have to load the gun, then pull the trigger an shoot yourself in the foot. :) > Is this something > we *really* need? No. IMO, factory provisionsing is the purview of the manufacturer. Does someone actually have evidence of the Windows drivers reloading the eeproms on these devices if it is, in fact, true that: "the eeprom may be erased, due to a bug on a *few eeprom* chipsets that sometimes considers i2c messages to other devices as being for it" But I don't have trashed eeprom sitting in front of me, and I don't have to build 256 i2cset commands by hand. :) > If so, it needs to have a HUGE WARNING explaining > the few cases that it should actually be used, and it should also > explicitly block usage against chipsets except for those that have > been validated to work. I agree with these. > Do you really want to be responsible for the > first time some unknowing user runs this against cx88 or some other > chipset you never tried it against and it bricks their board? Section 11 of the GPL legally absolves the authors of most, if not all, responsibility NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. > Also, this won't work against newer em28xx chipsets like the em2874 > and em2884, which have 16-bit eeproms. And if you corrupt the eeprom > on the em2874, you actually *WILL* brick the device (which is why I > removed the code that reads the eeprom in the first place). The script should state in big letters that EXPERT knowledge of the device in question is required to reduce the risk. Perhaps reiterating portions of section 11 of the GPL. (But then again, what is the risk of a non-functioning device continuing not to function?). The real risk is running the linux code that trashes the eeprom in the first place. I would look to prevent that code from running, or at least flag the risky condition in the kernel log. > Devin Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
