> > > 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? :-) > > Yes it is. That file is the thunking layer for a whole raft of ioctls > whose "real" handlers are within some other part of the kernel.
But why is it working anyway even though I haven't modified any arch/XXXX/kernel/ioctl32.c handler, just the ftdi_sio ioctl() handler? > > > > 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. > > Well, I'll wait to see the final result to make a judgement call, as I > don't think I really understand this different mode that this chipset > can be in. Think of it like setting hardware handshaking: You still talk to the driver the same way, the hardware handles the data just a bit different. 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
