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) { >
