Hi guys, Am Sonntag, den 05.12.2010, 13:22 -0500 schrieb Devin Heitmueller: > On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov <4ernov@xxxxxxxxx> wrote: > > Hello, Steve, > > thank you very much for your comments! > > > > As for DVB maybe I'm not correct. The initialization itself, which the DVB > > part of patch is about, is fully tested by me and works successfully on my > > everyday PC. The thing I meant saying 'untested' concerned receiving DVB > > signal through the initialized device. > > > > So I think I was mistaken that the code itself is untested. I hope it's > > possible to add full of this patch. > > Hello Alexey, > > What I believe Steven is trying to say is the device successfully > initializing is not enough to consider the DVB part of the driver to > be "working". If you have not seen the device receiving digital > television, the DVB parts of this patch should not be committed. > > There are a variety of other reasons why DVB streaming would not work > even if the device properly initializes. These can include an > improperly configured IF, wrong GPIOs, missing power management code, > etc. > > It is far worse for a user to be led to believe the driver should be > working but doesn't then it is for the driver claim to not work with > DVB at all. This is how we end up with users wasting hours wondering > what is wrong with their MythTV setup when in fact the driver never > actually worked in the first place. > > Find someone to test the DVB parts of the board that it shows DVB > streaming. If you cannot do that, remove those parts from the patch > until someone can be found who is able to test the functionality. > > Devin > Devin and Steven are totally right. There should not be any untested hardware functionality enabled. I have spend countless time, zillions of emails, often even years after the initial support for a new device was enabled, to hunt down what people did really test and what was only copy/paste from a previous card entry. Never add untested stuff ! We agreed, years ago, that even in a case we can likely expect a standard behavior on some new hardware, given the expertise of someone who might have seen maybe hundreds of similar devices previously, only #if 0 for the untested stuff is allowed. Even if we have muxes, gpios etc, we can take from windows drivers, .inf files or regspy.exe/DScaler for example, it is still not really safe to enable such untested inputs and leave only a comment in the code like "untested, taken from the .inf" or so. PCI cards for example, with the same subvendor and subdevice ID, can have never ending new revisions, changing almost everything they started with on the first revision for _multiple_ times. Audio and video muxes, all sort of gpio controls from all sort of chips on the board, the AGC, the LNA type, the i2c gate, the IR support ... All you can imagine and more really happens concerning hardware, and we have cases where even eeprom decoding doesn't help and some unknown vendor specific checksums come into the game. We still are in need of full hardware documentation, down to the smallest chip and any line on the PCB, and do miss it. And overall this is improved by more and more hidden devices in products with a seal stating, if broken any warranty is gone, and soldered RF shielding over the relevant parts, hardly to remove without breaking the device. Never add untested stuff. Cheers, Hermann -- 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
