[linux-usb-devel] New driver proposal: iuu_phoenix

Hi, I try to make a new driver for infinity unlimited usb. I use the usbserial layer to manage the lowlevel functions like probing or ttyUSBx creation/selection. The driver works but only after a first sequence open and close of the device by a program in the user space. After this first

Re: [linux-usb-devel] New driver proposal: iuu_phoenix

[mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 juillet 2007 12:54 À : linux-usb-devel@lists.sourceforge.net Cc : Alain Degreffe Objet : Re: [linux-usb-devel] New driver proposal: iuu_phoenix Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe: Hi, I try to make a new driver for infinity unlimited usb. I

Re: [linux-usb-devel] New driver proposal: iuu_phoenix

11 juillet 2007 13:25 À : linux-usb-devel@lists.sourceforge.net Cc : Alain Degreffe Objet : Re: [linux-usb-devel] New driver proposal: iuu_phoenix Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe: Mmmh, I don't think so because ,because in the debug, after the insmod, if I open the device

[linux-usb-devel] flip buffer initialisation - iuu_phoenix

I in the code submitted yesterday, I had ( I always have it ) a problem with the flip buffer... The data are well coming from the usb reader but the flush of the flip buffer doesn't work after the very first device open... The close function must be called before. After that, all is working well

[linux-usb-devel] iuu_phoenix drivers. New submit for review

As requested, I have replaced all DMA by kmalloc. The CodingStyle came from Lindent script. The all defines are now in a .h file So I'm ready for your comments... Thanks for your time and your help. It's funny to observe that the driver is running faster with kmalloc than before ( with DMA

Re: [linux-usb-devel] New driver proposal: iuu_phoenix patch formatted and indepedent file for external compilation

I will prepare a new patch including some improvements.. And Yes ! of course I'm pretty sure about any later version :-) ! Alain -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Greg KH Envoyé : mercredi 18 juillet 2007 10:41 À : Alain Degreffe Cc

[linux-usb-devel] [PATCH] iuu_phoenix new driver proposal

This patch add the new iuu_phoenix driver. Signed-off-by: Alain Degreffe [EMAIL PROTECTED] diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index 3efe670..1afcd0d 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -554,6 +554,15 @@ config

[linux-usb-devel] [PATCH] iuu_phoenix new driver proposal 2

I follow you comments... Am Mittwoch 18 Juli 2007 schrieb eczema: + if ((set == 0) priv-TIOSTATUS == TIOCM_RTS) { + dbg(%s TIOCMSET RESET called !!!, __FUNCTION__); + priv-TIOSTATUS = 0; + if (iuu_reset(port, 0x0C)) +

[linux-usb-devel] iuu_phoenix new driver latency problem.... idea needed...

Oliver Neukum Envoyé : jeudi 19 juillet 2007 8:22 À : linux-usb-devel@lists.sourceforge.net Cc : Alain Degreffe Objet : Re: [linux-usb-devel] [PATCH] iuu_phoenix new driver proposal 2 Am Mittwoch 18 Juli 2007 schrieb Alain Degreffe: +static int iuu_tiocmget(struct usb_serial_port *port, struct

[linux-usb-devel] urb-status -EOVERFLOW

Hi, After a big rewriting of iuu_phoenix, I have the following problem. The polling is well working with callback mechanism but only during 30 seconds maximum. After sometime, The read_bulk_callback give me an urb-status EOVERFLOW... Is the polling running to faster than the device can support ?

Re: [linux-usb-devel] urb-status -EOVERFLOW

PROTECTED] De la part de Alan Stern Envoyé : dimanche 22 juillet 2007 18:02 À : Alain Degreffe Cc : linux-usb-devel@lists.sourceforge.net Objet : Re: [linux-usb-devel] urb-status -EOVERFLOW On Sun, 22 Jul 2007, Alain Degreffe wrote: Hi, After a big rewriting of iuu_phoenix, I have

[linux-usb-devel] iuu_phoenix driver crash the kernel... help needed

Hi all, I just have rewritten the driver to do a constant polling. This imply that the module work in interrupt context. The driver works for a while but after some time ( 1 to 120 seconds… it depends ), the driver produce a Oops. But the oops don’t give any error on the driver function but show

Re: [linux-usb-devel] usb-serial.c question - potential Memory fault

Well I try to follow pl2303 wMaxPacketSize 0x0040 1x 64 bytes is the size retuned by the endpoint (I just plug my own pl2303 to check the value) line / code 330 priv-buf = pl2303_buf_alloc(PL2303_BUF_SIZE); where PL2303_BUF_SIZE = 1024 ! 377 count =

Re: [linux-usb-devel] usb-serial.c question - potential Memory fault

:[EMAIL PROTECTED] De la part de Alain Degreffe Envoyé : mardi 31 juillet 2007 7:13 À : 'Greg KH' Cc : linux-usb-devel@lists.sourceforge.net Objet : Re: [linux-usb-devel] usb-serial.c question - potential Memory fault Well I try to follow pl2303 wMaxPacketSize 0x0040 1x 64 bytes is the size

Re: [linux-usb-devel] usb-serial.c question - potential Memory fault

Greg, You are right ( of course ), but using the buffer given by the usb-serial seems to bo logic as I said. By this way I don't create unnecessary buffer. But in bulk transfer, the buffer_size can be greater than The value given by the endpoint. The usb lowlevel will split the bulk tranfsert.

Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments

By the way, What are the condition to see this driver in the main kernel tree ? Alain -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de [EMAIL PROTECTED] Envoyé : dimanche 12 août 2007 11:02 À : linux-usb-devel@lists.sourceforge.net Objet :