Hi, Am Samstag, den 07.03.2009, 19:06 -0500 schrieb Andy Walls: > On Sat, 2009-03-07 at 18:26 -0500, Devin Heitmueller wrote: > > On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf > > <dougsl...@gmail.com> 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 majord...@vger.kernel.org > > > 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 >
as far I know we never had a report about destroyed eeprom content on the saa7134 driver, but it seems Mauro and Douglas have seen it ? On the saa7134 I won't care that much, since currently we still can force all settings even with an erased eeprom, but if users cause trouble by using the script in a wrong way, their windows drivers won't work anymore and they don't have a chance to fix them except writing back the right eeprom content. In the past the DScaler guys had such a trouble on the cx88xx MSI t...@nywhere Master caused by them and they were badly in need of such a tool. So, in general it is good to have it, but there needs to be that BIG RED WARNING :) Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
