Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2

[Antti Palosaari <crope@iki.fi>]

On 01/07/2013 10:13 PM, Malcolm Priestley wrote:
> On Mon, 2013-01-07 at 21:37 +0200, Antti Palosaari wrote:
>> On 10/06/2012 06:40 PM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 01 Oct 2012 14:21:34 +0300
>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>
>>>> On 10/01/2012 02:15 PM, Mauro Carvalho Chehab wrote:
>>>>> Em Sun, 30 Sep 2012 19:36:50 +0200
>>>>> Damien Bally <biribi@free.fr> escreveu:
>>>>>
>>>>>>
>>>>>>
>>>>>> Le 29/09/2012 19:33, Mauro Carvalho Chehab a écrit :
>>>>>>      It seems that the it931x variant has bcdDevice equal to 2.00,
>>>>>>> from Damien's email:
>>>>>>>
>>>>>>>        idVendor           0x0ccd TerraTec Electronic GmbH
>>>>>>>        idProduct          0x0099
>>>>>>>        bcdDevice            2.00
>>>>>>>        iManufacturer           1 ITE Technologies, Inc.
>>>>>>>        iProduct                2 DVB-T TV Stick
>>>>>>>        iSerial                 0
>>>>>>>
>>>>>>> If the af9015 variant uses another bcdDevice, the fix should be simple.
>>>>>>
>>>>>> Alas, according to
>>>>>> http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_USB_Dual_RC the
>>>>>> af9015 variant appears to have the same bcdDevice. I join both lsusb
>>>>>> outputs for comparison.
>>>>>
>>>>> Well, then the alternative is to let both drivers to handle this USB ID,
>>>>> and add a code there on each of them that will check if the device is the
>>>>> right one, perhaps by looking at iProduct string. If the driver doesn't
>>>>> recognize it, it should return -ENODEV at .probe() time. The USB core will
>>>>> call the second driver.
>>>>
>>>> It is the easiest solution, but there should be very careful. Those
>>>> strings could change from device to device. I used earlier af9015 eeprom
>>>> hash (those string as coming from the eeprom) to map TerraTec dual
>>>> remote controller and git bug report quite soon as it didn't worked.
>>>> After I looked the reason I found out they was changed some not
>>>> meaningful value.
>>>
>>> Yeah, those strings can change, especially when vendors don't care enough
>>> to use a different USB ID/bcdDevice for different models. Yet, seems to
>>> be the cleaner approach, among the alternatives.
>>
>> Damien, care to test?
>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner
>>
>> I split tuner out from IT9135 driver and due to that AF9035 driver
>> supports IT9135 too (difference between AF9035 and IT9135 is integrated
>> RF-tuner). I added iManufacturer based checks for both AF9015 and AF9035
>> drivers
>
> I can't see the point of adding this to the af9035/af9033 driver. It is
> going to turn into one enormous blob.

Stop speaking bullshit! It increases AF9035/AF9033 driver size 
marginally. I could guess total binary size of AF9035+AF9033+IT913X 
(IT913X == that new tuner driver) is smaller than size of your IT9135 blob.

> The it913x is a stable driver and has it own entity moving forward.
>
> The only thing that needs to happen is the id is added to it913x driver
> and if it doesn't apply drop it.
>
> Nack.

If you remember about year back when IT9135 was mainlined I reviewed 
that stuff and criticized it wasn't split correctly. I also pointed out 
all what is needed is new RF-tuner driver as AF9035/AF9033 is just same 
silicon, but without a integrated tuner. You said on one mail something 
like it is too much different than AF9035 family, I didn't cared to 
start stupid yes/no discussion on that time.

You don't have any technical reason to NACK it. Last time I was 
"discussing" with DS3000+TS2020 split with you and you were against. 
Same happens now. I ask you to look driver guidelines [1] and stop 
speaking BS, instead start fixing your own stuff and you will never end 
up situation like that.

[1] http://lwn.net/Articles/529490/

Antti

-- 
http://palosaari.fi/