Dear Alan, Thanks a lot for your answer. It seems I still have some code reverse engineering to do to find the good example for my application. 2009/7/6 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Mon, 6 Jul 2009, Sylvain PORTES wrote: > >> Hello, >> >> I am very new to Linux Kernel framework. >> >> All I did is an adaptation of an existing driver (LegoTower) for my >> specific application it was working well until I had to add an other >> communication endpoints pair. >> >> I am now dealing with the problem of accessing to two endpoints with >> the same driver. > > Why is that a problem? Lots of other drivers do it. What is according to you the best example of managing "independent" access to two endpoints (in fact 4 : 2 (IN/OUT) pairs. > >> I found several tricks : >> > using IOCtrl but I still have the problem of multi threaded access, >> > then I thought to adding a "trick" like : first byte of writing >> indicates which endpoint shall be written and the read data the first >> byte is indicating where the data comes from but the I feel it is not >> the good way to do. >> >> Then I thought multiple dev could be the solution, I browsed the usb >> kernel driver sources but it seems that the rule is one dev per device >> driver. > > No, a driver can manage multiple devices. However it is most unusual > (probably never occurs at all) for multiple drivers to manage a single > device. > > Why do you need multiple drivers? > My final application is a USB/I2C converter. My device is a µController which has two I2C ports. The idea is to have a endpoint pair for each I2C ports. Indeed the max I2C throughput is 400 kbits/sec = 50 kBytes/sec. With a full speed interrupt endpoint the theoretical throughput is 64 kBytes/sec. Then in fact I would have two devs (something like "usb_i2c1" and "usb_i2c2") which could manage the same traditional fops for these ports. These dev files shall manage multiple threaded access ( asynch io I guess) I am really interesting in having your expert point of view on the best approach for doing such a driver. I went on my research, I guess I have to look at USB serial converter access. I had a look also at endpoint.c in the drivers/usb/core. I saw that some endpoint devices are created in /dev/ but I don't know if I can use it directly. I know I am maybe a little bit confusing (maybe because I am a little bit confused and lost in front of the immensity of the possibility of Linux kernel world.) > Why can't you write a single driver > that handles several endpoints? What is the best way ( and the cleanest way ) to do it ? With IOCTL ? If so, from my actual understanding for two consecutive write(or read) operations on the two different endpoint pair, I would need : 1> Enable "usbi2c1" IOCTL 2> write 3> Enable "usbi2c2" IOCTL 4 > write Am I understanding well ? Then how could I guarantee in case of multi-threaded access that this scenario never happens: 1> Enable "usbi2c1" IOCTL from thread 1 3> Enable "usbi2c2" IOCTL from thread 2 2> write thread 1 (ouch...) >> So I start working on Linux-usb mailing list archives. Then I found >> evocation of usbfs2 which seems to be exactly what I need. > > usbfs2 doesn't exist. It is "vaporware". > >> I looked for documentation, I saw the vid of Sarah presentation (very >> impressive) and started to get her sources from her git. >> I am not a specialist of Git either but basically what I got is an >> image of Kernel Src. Browsing exchange about "multiple devices for one >> Usb interface" topic in archives, I noticed an email from Sarah which >> mentionned her code was in the file : "drivers/usb/core/endpoint_ >> fops.c" >> But I don't have it in the files I cloned from sarah git. >> >> So my question is simple, is there an HOW TO use usbfs2 ? >> Is there a documentation about usbfs2 which explains how it's work >> and what shall be done to make it acceptable to the main kernel tree. > > There is no documentation and there is no code. Perhaps Sarah has > written some stuff and not made it available, but even if she has, it > will be very incomplete. I am really sorry about that, from the presentation she did it looked very interesting for me. > > 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
