Re: rearding USB-to-serial device driver

Re: rearding USB-to-serial device driver

[Greg KH]

On Fri, May 21, 2010 at 10:18:45AM +0530, raj uprade wrote:
> Dear Sir,
>               I need your help...I have written a  device driver  named
> mcmdriver.But now I want to use USB port as a serial port.When I plug the
> USB-to-Serial device, I get the ttyUSB0 device file, but I am unable to get
> the details reagarding port address and IRQ associated with ttyUSB0 device
> file.

There is no such thing when it comes to USB devices, especially usb to
serial devices.

> I am clueless how I should proceed.kindly guide me is it possible to
> interface pl2303.c with my mcmdriver.c
> I have also ataached the mcmdriver.c file ....
> 
> *Details regarding mcmdriver.c*
> 
> The mcmdriver module implements a RS-485 multi-drop communication with MCMs
> at 9.6 kbps.
> The mcmdriver module associates a /dev/mcmdriver file to a PC serial port,
> and provides the open, close, read and write functions on it. During the
> module loading, the root can choose which serial port is to be used (serial
> port 1 at 0x3f8, or serial port 2 at 0x2f8).
> This driver is using an interrupt handler that stores incoming data as soon
> as they arrived, unless an overrun or a framing error occurs. The IRQ number
> used is the one usually reserved for the first PC serial port (IRQ 4).
> The reading call is implemented as a “blocking read with time-out”. When
> data arrive on the port, the driver decodes the 2 first bytes to know the
> size of the incoming packet. If a full packet has been received, the 'read'
> returns, otherwise it waits during a maximum period of 2 secs (200 jiffies).
> Bytes are not stored whenever an overrun or a framing error occurs. If the
> Check Sum is right, 'read' copies the packet into the buffer passed in
> argument and returns its size, otherwise it only returns -1.
> A writing call automatically outputs bytes on the serial port as defined in
> the multi-drop RS-485 protocol. All the RTS line and 9-bit operations are
> transparent to the user, who must just be sure that the first byte of the
> sent packet is the MCM address. The 'write' call waits until all the bytes
> are sent, and sends 1 after completion.

Shouldn't this all be done as a line discipline instead of trying to
replace the default serial driver?  Your module will only look to work
with the "standard" serial port on a system, which are getting more and
more rare these days.

thanks,

greg k-h