Johannes, 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? > > 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. Logically it makes sense that the Pentium ought to still work without the calls to le19_to_cpu() (since you mention that on Intel it does nothing), I will try it later to confirm that. If it works then it seems that the removal of these calls will work across architectures. >> Now both devices work on Yellow Dog Linux on the PowerPC CPU, >> the Freecom even supports recording multiple channels from the >> same multiplex, the DEC2000 doesn't probably because USB1.1 >> isn't fast enough. > > Thanks for digging into this. > > Johannes Regards, Tim.
