On Tue, 2 Jun 2009, Richard Ash wrote: > Quatech have replaced the ESU range of USB 1 to serial adaptors (for > which a driver is in staging/serqt_usb) with a new range of USB2.0 > devices. Unfortunately these are significantly different and do not work > with the original driver, and have different USB device IDs. > > Quatech have produced a modified version of their driver for these > devices, which is available from > > http://www.quatech.com/ManualsDriversFirmware/Communication/serqt_usb2_2.6_1.00.tar.gz > > This has all the same problems as the drivers they provide for the USB 1 > series of devices (based on old kernel code, doesn't compile with > current kernel, duplicates chunks of the usb-serial subsystem etc), but > also adds some new gotchas: > * the tarball unpacks to create a directory named serqt_usb, which > doesn't match the tarball name, and gets it mixed up with the old USB1 > driver if you aren't careful. > * The driver compiles to a module named serqt_usb.ko, clashing with the > USB1 driver. > * The driver is not backwards-compatible, so won't drive old USB1 > devices. > > I have started going through the Quatech driver for the USB2 devices and > the staging driver to see how possible it would be to merge the two > drivers and get support for the USB2 series in the kernel, but am now > uncertain if this is the right approach. > > Adding the new device IDs is straightforward, once some conflicting > preprocessor names are changed to make them unique. Once I get to the > serqt_probe function however, there is relatively little in common > between the two drivers, and so the attempt at a merged driver ends up > mainly composed of if statements switching between code for USB1 series > and code for USB2 series devices. This makes me uncertain whether trying > to produce a merged driver is a good idea or not. Judging by your description, writing a new driver would be better than trying to make a dual-purpose driver. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
