Greg KH wrote:
On Wed, Feb 13, 2008 at 01:31:54PM -0600, Andrew McKay wrote:
Hi
For a project I'm working on we had to add GPIO support to the cp2103
driver in the 2.6.20.4 kernel.
Can't you just do this from a usbfs/libusb application from userspace
instead? Why add a custom ioctl to the driver? Or are you also using
the serial portion of the driver and need that to also talk to the
device?
I've never heard of usbfs/libusb before. As I mentioned before. I'm a complete
newb to USB development. I got thrown into it because of some serious bugs we
were having with the CP2103. I'll have to look into this as well.
In our project we're using the serial portion of the driver already in the
kernel. On our hardware we added extra serial ports with the CP2103 on board
(don't ask why, I wasn't happy about that choice). Beside the serial connectors
we have an LED that gives the user a status of the port. The userland
application that is reading and writing from the serial port controls the LEDs.
Off = unactive
On = active
Flashing = error talking to connected device
This leads me to my question. Is there a buffer that the control URB ends
up sitting in that doesn't get flushed until a certain number of bytes are
sent to the USB end point? If this is the case, is there an accepted
method of fushing the URB to the USB endpoint?
It should be there when you get called back.
Do you have the docs for how this chip really works? If so, that might
help out as the driver was written by reverse-engineering the protocol,
so there might be bugs in the driver.
No I don't have a lot of information about how this chip really works. We
managed to get some information about what byte sequence to send to it to get
the GPIOs to toggle on and off.
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
