Hello Greg , My code does tries to follow coding conventions. I have referred the CodingStyle doc.The file I sent was a txt file enough to view some important portions of the code.
I am not sure what you meant by not following coding conventions. It would be good if you could point the crucial points/conventions which I have missed that render my code uncomprehensible/unreadable. I would be glad to get those :) Till the time I fix the Coding sytle issues (based on your comments) I need few more inputs from you on the following I see this at http://gate.brimson.com/downloads/edgeport_release_notes-0.4-2.txt Sometimes a port will stop sending data. You can still receive data on the port, but not send data from the port. After this happens, the close of the port seems to hang-- for example, minicom will not exit. Closing and reopening the port does not fix the problem; the Edgeport must be disconnected and reconnected. I am facing the same issue described in Scenario 1. Whats the way to analyze this ? This is inconsitently reproducible. In Scenario 2 . After Every reboot minicom fails to read on ttyUSB* . However following are the ways in which read starts working - 1) From Hyperterminal on other end if I have the option "Send line ends with line feed" And I type "Hello <Enter> " I get "Hello" echoed on minicom at ttyUSB0 . However if there minicom at the other end and you are typing "Hello < Enter> " still there is no characters echoed on minicom at ttyUSB0 . It happens only when hyperterminal is used to feed characters :( 2) After I send files from minicom at ttyUSB0 to the other end , then I type something from the other end I am able to read on minicom at ttyUSB0 . 3) If the read is not working and minicom session is on , I explicitly set the non-canonical mode by passing the argument -icanon using stty.... i.e stty -F /dev/ttyUSB0 -icanon Then also the chars I typed till that time (which were not being echoed) get echoed on to minicom. Does the driver need to do anything explicitly . I also tried setting tty->termios->c_lflag to switch OFF ICANON mode. I am not sure on tty code and ldisc code ( specially the read path ) .What would be causing the tty layer/ldisc to buffer data and not signal it to application . In Scenario 2 , I always find that my code which pushes data to the tty layer is called. I am debugging the tty layer but would be glad if I get some quick pointers . Hope I am able to convey these weird scenarios. Thanking you in anticipation . Regards, Monali. > -----Original Message----- > From: Greg KH [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 26, 2005 12:13 PM > To: Monali Vishnu Katkar (WT01 - EMBEDDED & PRODUCT ENGINEERING > SOLUTIONS) > Cc: linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED] > Subject: Re: Needed help on the usb-serial driver- debugging > read/write issues > > > On Tue, Apr 26, 2005 at 11:09:55AM +0530, [EMAIL PROTECTED] > wrote: > > > > Hello Al and Greg, > > As you know, I am working on USB Serial devices by Oxford > Semi. These > > drivers will be released with GPL license. > > <snip> > > In order for us to be able to help you, please attach your full > driver. > > Also, please fix up all of the coding style issues in the code, > otherwise it is _very_ hard for us to be able to read the file and > notice anything wrong with it. For the proper coding style rules, > please see the file, Documentation/CodingStyle in the kernel source > tree. > > Actually, I will not even attempt to read code that doesn't at least > try to follow those rules :) > > thanks, > > greg k-h > ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
