> > > > I found Documentation/ioctl-numbers.txt for new-style ioctls. > > > > Currently I'm using 'N' with a range of 20 to 3F. > > > > Before a final release, I'll check if they're still unused. > > > > > > Heh, good luck, I don't think I'll take a patch adding new ioctls > > > without a _very_ good reason. > > > > What about the ioctls to control the latency of the on-chip buffers? > > They are very useful for performance tuning. IMHO there are enough > > useful uses for the new ioctls. > > For "normal" serial devices, or this odd bit controlled device?
The new ioctl handler is just for the ftdi_sio driver. > > > Also, you'll need to make the necessary > > > 64 bit thunking layer if somehow you convince me :) > > > > I thought using the _IO macros should do it > > or did I miss something? > > No, those macros don't do it. If you have a strong stomach, look at: > arch/sparc64/kernel/ioctl32.c > for just one of the arch specific files that you will have to modify. > Make sure you get them all, or you will have some angry maintainers to > deal with... But this isn't necessary if the new handler is inside the ftdi_sio driver, is it? :-) > > > > [FTDI Bit Bang mode] > > > But it isn't serial data, so you don't need the tty layer. Why not just > > > do it all though libusb/usbfs in userspace? > > > > But you have to send the data using the serial way. > > A userspace program using libusb would have to copy all the init > > and data writing code of the kernel. > > What init and data writing code? Reseting the chip, calculating/setting the baud rate, writing data etc. > > Also it would be better > > if people could use a stock kernel instead of having to download > > libusb and special software if they want to use the bitbang mode. > > Heh, it's _much_ easier to use a userspace program using libusb than to > tell someone to upgrade their kernel version. Trust me on this one. Well, as the "old" ftdi_sio driver had some bugs with BM type chips, they have to upgrade their kernel anyway. > > The bitbang mode just changes the final behavior of the chip, > > all data transfer is done the same way. > > But the end use of the device is then different, right? Not really. For example I'll use it as a synchronous serial line (using one output as clock line) on over 100+ machines to flash an Atmel microcontroller. Cheers, Thomas ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
