On Fri, Jun 19, 2009 at 12:51:25PM +0100, Richard Ash wrote: > On Tue, 2009-06-02 at 16:00 -0700, Greg KH wrote: > > > Judging by your description, writing a new driver would be better than > > > trying to make a dual-purpose driver. > > > > I agree. Especially as someone just rewrote the serqt_usb driver in the > > staging tree to be a "proper" usb-serial driver. So your patches will > > not apply anymore anyway :( > > I have started (slowly due to other work) on such a driver, which is > indeed much easier to do. I am using the re-written USB 1.1 driver as a > guide for structuring the new driver. Where I am struggling is with what > exactly is done for you by the usb-serial layer, as I can't find any > specific documentation on writing USB serial drivers using the kernel > infrastructure. Where the devices are similar this isn't a problem, but > it makes things harder where the hardware design is eccentric. > > In particular, the USB 2.0 series devices have only on bulk in and out > endpoint, which is shared between the multiple ports using headers on > each URB (as far as I can see based on the vendor driver code). I'm not > clear what the best way of handling this is - do I need to initialise > the endpoints / URBs, and if so, what function do it do it in? Will > keeping the URBs in port 0's structure and then referencing them there > as required be a good idea or a bad one? > > The patch below is of the "works as far as it goes" variety, in that the > module compiles and loads, the device nodes are registered and the unit > switched on, but nothing actually works. Can you submit this in a format that I can apply it (non-line-wrapped, and a signed-off-by: line)? thanks, greg k-h -- 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
