[linux-dvb] Linux DVB on Mac PowerPC (Yellow Dog Linux - Freecom USB and DEC2000-t)

[Tim Hewett]

Johannes,

I have tested a merge of your patch and my removal of le16_to_cpu
on the latest CVS of the old dvb-kernel tree (the new v4l one doesn't
work for the DEC2000, there is a problem with setting the hardware
stream filters). It works fine.

HTH,

Tim.


On 18 Dec 2005, at 19:06, Johannes Stezenbach wrote:

> Hi Tim,
>
> On Mon, Dec 12, 2005, Tim Hewett wrote:
>> On 12 Dec 2005, at 12:11, Johannes Stezenbach wrote:
>>
>>>
>>> le16_to_cpu() does nothing on Intel.  But IIRC those le16_to_cpu()
>>> calls were added because of some other PPC user's complaints.
>>>
>>> See rev 1.63 in
>>> http://linuxtv.org/cgi-bin/viewcvs.cgi/v4l-dvb/linux/drivers/media/
>>> dvb/ttusb-dec/ttusb_dec.c?rev=1.77&root=v4l&view=log
>>>
>>> I need to check this. Does someone have a hint for me?
>
> As usual, no one cared to look into it :-(
>
> http://lwn.net/Articles/2.6-kernel-api/ suggests that
> the endianness of idProduct etc. changed in 2.6.11.
>
> So if someone cares about backwards compatibility with
> 2.6.10 or older on big endian platforms: I don't.
>
>
>>> Anyway, I noticed before that the switch() statement lacks a default
>>> label. Of course I thought "it can't happen, because _probe() won't
>>> be called for a wrong id"...
>>
>> At one point I was getting the printk after the second switch saying
>> "dvb-ttusb-dec: A frontend driver was not found for device 0x0810"
>> when the DEC2000's id is 0x1008. This was with the DEC having
>> been put into slave mode using my Mandrake 9.1 Pentium III (which
>> the DEC always worked fine with), then plugged into the iBook's
>> USB while still in slave mode - I think this allowed the driver to  
>> get
>> past the first switch without an exception. This was all before the
>> le19_to_cpu() calls were removed. It leaves me wondering whether
>> higher level kernel functions, e.g. the generic USB module, are
>> already resolving the byte ordering in the USB id, which is then
>> undone by the calls to le19_to_cpu() in the DEC driver on the PPC
>> arch. Clearly the printk shows that there is opposite byte ordering
>> to that expected by the switch.
>
> I'd like to commit the error handling fixes below, could you test  
> this?
>
> Thanks,
> Johannes
>
>
> Index: linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c
> ===================================================================
> RCS file: /cvs/video4linux/v4l-dvb/linux/drivers/media/dvb/ttusb- 
> dec/ttusb_dec.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 ttusb_dec.c
> --- linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c	9 Dec 2005  
> 21:53:00 -0000	1.77
> +++ linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c	18 Dec 2005  
> 18:48:19 -0000
> @@ -1601,6 +1601,7 @@ static int ttusb_dec_probe(struct usb_in
>  {
>  	struct usb_device *udev;
>  	struct ttusb_dec *dec;
> +	int rc;
>
>  	dprintk("%s\n", __FUNCTION__);
>
> @@ -1627,15 +1628,23 @@ static int ttusb_dec_probe(struct usb_in
>  	case 0x1009:
>  		ttusb_dec_set_model(dec, TTUSB_DEC2540T);
>  		break;
> +	default:
> +		printk("%s: invalid product id %04x\n",
> +		       __FUNCTION__, le16_to_cpu(id->idProduct));
> +		kfree(dec);
> +		return -ENXIO;
>  	}
>
>  	dec->udev = udev;
>
> -	if (ttusb_dec_init_usb(dec))
> -		return 0;
> -	if (ttusb_dec_init_stb(dec)) {
> +	if ((rc = ttusb_dec_init_usb(dec))) {
> +		kfree(dec);
> +		return rc;
> +	}
> +	if ((rc = ttusb_dec_init_stb(dec))) {
>  		ttusb_dec_exit_usb(dec);
> -		return 0;
> +		kfree(dec);
> +		return rc;
>  	}
>  	ttusb_dec_init_dvb(dec);
>
> @@ -1649,6 +1658,8 @@ static int ttusb_dec_probe(struct usb_in
>  	case 0x1009:
>  		dec->fe = ttusbdecfe_dvbt_attach(&fe_config);
>  		break;
> +	default:
> +		BUG();
>  	}
>
>  	if (dec->fe == NULL) {
>