Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Douglas Schilling Landgraf wrote: Hello, On Fri, May 14, 2010 at 12:54 AM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - ir-core-priv.h: error: field 'rx_work' has incomplete type Added: - cx231xx.h: Add include media/ir-kbd-i2c.h Douglas, I'm noticing no compilation errors upstream. So, this is probably a backport-only ussue. Please merge the upstream diffs at hg, since there were several changes there that should be applied at the backport tree. -- Cheers, Mauro -- 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello, On Fri, May 14, 2010 at 12:54 AM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - ir-core-priv.h: error: field 'rx_work' has incomplete type Added: - cx231xx.h: Add include media/ir-kbd-i2c.h 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - ir-core-priv.h: error: field 'rx_work' has incomplete type 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - cx23888-ir: fix kfifo erros for kernels 2.6.33 - meye: fix kfifo errors for kernels 2.6.33 Cheers, 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - radio-tea5764: Correct size given to memsetdefault - uvc: Correct size given to memset - radio-sf16fmi: add autoprobing - radio-sf16fmi: fix mute, add SF16-FMP to texts - vpif: move vpif_remove to .devexit - vpfe_capture: move vpfe_remove to .devexit - sh_mobile_ceu_camera: don't use __exit_p to wrap sh_mobile_ceu_remove - vpss: move vpss_remove to .devexit - Use dev-bus_id instead of dev_name in pre 2.6.26 kernels - bttv: fix MODULE_PARM_DESC for i2c_debug and i2c_hw - radio-si470x: support PM functions - radio-si470x: support RDS on si470x i2c driver - radio-si470x: move some file operations to common file - videobuf_dma_contig_user_get() for non-aligned offsets - bttv: add i2c addr for old WinTV card to IR probe list - ov511.c typo: lock = unlock - pms.c: fix use of KERNEL_VERSION - cpia2: use __stringify macro. - vpif_display/saa7134-alsa/quickcam_messenger: Move dereference after NULL test - PWC: parameter trace is only available in debug 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for the following: - go7007: sound needs compat.hdefault tip - go7007: convert printks to v4l2_info - s2250-board: Implement brightness and contrast controls - s2250-board: Fix memory leaks - go7007: Implement vidioc_g_std and vidioc_querystd - go7007: Merge struct gofh and go declarations - go7007: Fix mpeg controls - go7007: Fix whitespace and line lengths - go7007: Updates to Kconfig and Makefile - radio-si4713: remove #include linux/version.h - video: initial support for ADV7180 - kzalloc failure ignored in au8522_probe() - GSPCA: kmalloc failure ignored in sd_start() - kmalloc failure ignored in lgdt3304_attach() and s921_attach() - kmalloc failure ignored in m920x_firmware_download() - Add support for Compro VideoMate E800 (DVB-T part only) - FM TX: si4713: Kconfig: Fixed two typos. - uvc: introduce missing kfree - Change tuner type of BeholdTV cards 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, On Tue, 28 Jul 2009 12:04:48 -0300 Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - saa7134: fix lock imbalancedefault tip - af9015: Fix for crash in dvb-usb-af9015 - v4l doc: fix cqcam source code path - stv680: kfree called before usb_kill_urb - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type - ir-kbd-i2c: Remove superfulous inlines - ir-kbd-i2c: fix spaces - gspca - sn9c20x: Fix up i2c_r functions Added to the above list: hdpvr: fix lock imbalances 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Em Thu, 30 Jul 2009 16:07:04 -0400 Douglas Schilling Landgraf dougsl...@gmail.com escreveu: Hello Mauro, On Tue, 28 Jul 2009 12:04:48 -0300 Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - saa7134: fix lock imbalancedefault tip - af9015: Fix for crash in dvb-usb-af9015 - v4l doc: fix cqcam source code path - stv680: kfree called before usb_kill_urb - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type - ir-kbd-i2c: Remove superfulous inlines - ir-kbd-i2c: fix spaces - gspca - sn9c20x: Fix up i2c_r functions This one already came via Jean-Francois tree. I'm cherry-picking the other ones. Cheers, Mauro -- 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - saa7134: fix lock imbalancedefault tip - af9015: Fix for crash in dvb-usb-af9015 - v4l doc: fix cqcam source code path - stv680: kfree called before usb_kill_urb - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type - ir-kbd-i2c: Remove superfulous inlines - ir-kbd-i2c: fix spaces - gspca - sn9c20x: Fix up i2c_r functions 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for the following: bttv and meye: Use PCI_VDEVICE radio-si470x: fix lock imbalance em28xx, fix lock imbalance adv7343: remove unused #include linux/version.h mt312: Fix checkpatch warnings remove redundant tests on unsigned ivtv-driver.c: Remove unnecessary semicolons Remove unnecessary semicolons cx18-fileops.c: Remove unnecessary semicolons Cheers, 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - em28xx: Fix for Slow Memory Leak - bt8xx: remove always false if 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Hermann. On Thu, 12 Mar 2009 01:44:30 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Mittwoch, den 11.03.2009, 14:44 -0300 schrieb Douglas Schilling Landgraf: Hello, On Sun, 08 Mar 2009 01:45:36 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: 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 -- Added to the same tree new version of script: - A few improvements to initial version of script - Added validations to avoid issues to users - Added a huge red warning message IMO, the current version will cover those suggestions. If not, please let me know. Thanks everyone, Douglas seems to be safe to me on the saa7134 driver, but those pointing to further risks are welcome. Good to know! The dual saa7134 PCI bridge devices in need of a correct eeprom are out of the game in the original dual/triple slots, even first and second bridge might be swapped compared to the m$ driver and so on. Those tools are around anyway, I remember the case of a manipulated eeprom we alredy had. (with one of Dmitry's devices, IIRC) On some mobo's with lots of saa713X devices the eeprom readout can be flaky sometimes. If it is only a single device likely the PSU is becoming faulty, just to remember to check against that too. If there is a known list of critical eeprom types and about cases we disabled the write protection, this would be good to know as well. Agreed. Thanks for your comments! Cheers, 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello, On Sun, 08 Mar 2009 01:45:36 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: 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 -- Added to the same tree new version of script: - A few improvements to initial version of script - Added validations to avoid issues to users - Added a huge red warning message IMO, the current version will cover those suggestions. If not, please let me know. Thanks everyone, 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
On Wed, Mar 11, 2009 at 2:05 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: I have forgot to say this: - Added backup feature to the script. Before any update of eeprom the script will make backup of current eeprom and dmesg. IMO, the current version will cover those suggestions. If not, please let me know. Thanks everyone, Douglas Cheers, Douglas Hello Douglas, The only suggestion I might make is that perhaps you should check the dmesg and expicitly bail out if the device is detected as an em2874/em2884, since in that case this script *definitely* will not work and, since microcode is stored on the chip, corruption of the eeprom (such as attempting to load an em2882 eeprom content onto an em2884) will brick the board with no path for software-based recovery (you will not be able to run the tool again). Regards, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hi, Am Mittwoch, den 11.03.2009, 14:44 -0300 schrieb Douglas Schilling Landgraf: Hello, On Sun, 08 Mar 2009 01:45:36 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: 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 -- Added to the same tree new version of script: - A few improvements to initial version of script - Added validations to avoid issues to users - Added a huge red warning message IMO, the current version will cover those suggestions. If not, please let me know. Thanks everyone, Douglas seems to be safe to me on the saa7134 driver, but those pointing to further risks are welcome. The dual saa7134 PCI bridge devices in need of a correct eeprom are out of the game in the original dual/triple slots, even first and second bridge might be swapped compared to the m$ driver and so on. Those tools are around anyway, I remember the case of a manipulated eeprom we alredy had. (with one of Dmitry's devices, IIRC) On some mobo's with lots of saa713X devices the eeprom readout can be flaky sometimes. If it is only a single device likely the PSU is becoming faulty, just to remember to check against that too. If there is a known list of critical eeprom types and about cases we disabled the write protection, this would be good to know as well. 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
On Sat, 7 Mar 2009 23:22:59 -0300 Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello everyone, First of all, thanks for your comments guys. On Sat, 7 Mar 2009 18:26:05 -0500 Devin Heitmueller devin.heitmuel...@gmail.com 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. Is this something we *really* need? IMO yes. The first version of this script was created because an em28xx user sent an email to me and Mauro asking *help* since his eeprom was lost and he would like to recover it. A few time later, his board was recovered by [this script] and now his device is working and supported by the upstream driver. 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. Well, I have read several good ideas from you and others developers. For now, it's very easy to implement such warning message, no problem from my side. 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? As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell bad because a user replaced his eeprom. We are here because we want to help them. So, let's add such warning message. 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). Ok, I will add a comment to the script for such chipsets since I don't have those here for test now. On the other hand, I have tested with several older em28xx devices replacing a *good* eeprom with *wrong* eeprom and then replaced it again with a good one.. no bad affects, device is working fine like new. *Of course, neither me or Mauro we DO NOT recommend nobody to run this script if it's not really needed (like: erased/wrong eeprom cases).* Maybe one option is to first dump the eeprom and save on some backup file. Of course, we should add some warning messages, confirmation, etc, to avoid that such tool to be blindly used. Cheers, Mauro -- 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: 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 -- 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. :) Another solution, that may be more complicated for the developer, but simpler for the end user, is a module parameter to select a compiled in eeprom image if the user knows what device he has, but the EEPROM is trashed. A similar option would be to use the kernel firmware loading facility to load in an eeprom firmware image for various devices to use in the driver, if the eeprom is trashed. Neither of those would write the new eeprom data, and hence neither would help the dual-boot Linux/Windows user. Regards, Andy Just receiving this one. Yes, that is the major problem in worst case. 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
On Sat, Mar 7, 2009 at 7:06 PM, Andy Walls awa...@radix.net wrote: 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. :) Yeah, this is really not a very good argument. Think of the average user - he reads something on a newsgroup and thinks, Oh, maybe my eeprom is corrupted. And then he blindly runs the three steps above. But he doesn't have the eeprom on his machine, so he copies it from someone else's dmesg output he finds on the Internet, and doesn't realize that the HVR-850 based on the Auvtiek chipset is different than the HVR-850 based on em28xx. Instant eeprom corruption. 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 Perhaps responsible wasn't the best word to use as it implies a legal implication. Sure, you're not legally responsible, but you better feel damn responsible if you hand a tool like this to some user who is just trying to make his device work and he trashes it out because he doesn't know what the hell he is doing. 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?). To answer your question, consider the definition of non-functioning to an average user. This can mean *anything*. He could be trying to use tvtime to watch a DVB tv source. And he runs this script and breaks a perfectly good piece of hardware. 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. I don't doubt that this tool could be useful for a select few developers, but indeed it needs to say something like Don't ever run this tool unless somebody who knows what the hell he is talking about tells you to. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello everyone, First of all, thanks for your comments guys. On Sat, 7 Mar 2009 18:26:05 -0500 Devin Heitmueller devin.heitmuel...@gmail.com 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. Is this something we *really* need? IMO yes. The first version of this script was created because an em28xx user sent an email to me and Mauro asking *help* since his eeprom was lost and he would like to recover it. A few time later, his board was recovered by [this script] and now his device is working and supported by the upstream driver. 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. Well, I have read several good ideas from you and others developers. For now, it's very easy to implement such warning message, no problem from my side. 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? As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell bad because a user replaced his eeprom. We are here because we want to help them. So, let's add such warning message. 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). Ok, I will add a comment to the script for such chipsets since I don't have those here for test now. On the other hand, I have tested with several older em28xx devices replacing a *good* eeprom with *wrong* eeprom and then replaced it again with a good one.. no bad affects, device is working fine like new. *Of course, neither me or Mauro we DO NOT recommend nobody to run this script if it's not really needed (like: erased/wrong eeprom cases).* 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hi, Am Samstag, den 07.03.2009, 23:22 -0300 schrieb Douglas Schilling Landgraf: Hello everyone, First of all, thanks for your comments guys. On Sat, 7 Mar 2009 18:26:05 -0500 Devin Heitmueller devin.heitmuel...@gmail.com 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. Is this something we *really* need? IMO yes. The first version of this script was created because an em28xx user sent an email to me and Mauro asking *help* since his eeprom was lost and he would like to recover it. A few time later, his board was recovered by [this script] and now his device is working and supported by the upstream driver. 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. Well, I have read several good ideas from you and others developers. For now, it's very easy to implement such warning message, no problem from my side. 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? As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell bad because a user replaced his eeprom. We are here because we want to help them. So, let's add such warning message. 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). Ok, I will add a comment to the script for such chipsets since I don't have those here for test now. On the other hand, I have tested with several older em28xx devices replacing a *good* eeprom with *wrong* eeprom and then replaced it again with a good one.. no bad affects, device is working fine like new. *Of course, neither me or Mauro we DO NOT recommend nobody to run this script if it's not really needed (like: erased/wrong eeprom cases).* Thanks, Douglas -- it is even more funny and at least all guys here since a little bit longer do know this very well on the saa713x. Hartmut, under pressure doing the best work on the saa713x after Gerd did quit, was close to disclosure the intended Philips eeprom content. He luckily did not! , since the OEMs did play their own games. Which they were obviously implicitly allowed to do, if they take large amounts of new chips. This is all fine so far, no irony. Since we still don't have an extensive decoding of the eeprom contents, because of such, we can at least find lots of unused bytes shared by all of them. We can potentially use them for our own needs without breaking anything, until someone spits in the soup again. :) 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/
On Sun, 22 Feb 2009 12:50:34 -0500 CityK ci...@rogers.com wrote: Douglas Schilling Landgraf wrote: Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the following: - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 It is not clear to me why this ended up in /v4l2-apps/test, as opposed to /v4l2/util -- can someone comment? Thanks. You're right. This one is at the wrong place. I'll move it. Cheers, Mauro -- 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/
On Thu, 26 Feb 2009 15:28:11 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Sun, 22 Feb 2009 12:50:34 -0500 CityK ci...@rogers.com wrote: Douglas Schilling Landgraf wrote: Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the following: - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 It is not clear to me why this ended up in /v4l2-apps/test, as opposed to /v4l2/util -- can someone comment? Thanks. You're right. This one is at the wrong place. I'll move it. Thanks Mauro/CityK! Cheers, 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
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/
Douglas Schilling Landgraf wrote: Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the following: - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 It is not clear to me why this ended up in /v4l2-apps/test, as opposed to /v4l2/util -- can someone comment? Thanks. -- 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
