[linux-usb-devel] [RFC] g_serial: Real tty device passthrough.

[Harald Welte]

On Fri, Mar 09, 2007 at 03:25:58PM -0400, Felipe Balbi wrote:
> >2. Ask about opinions and suggestions for doing this in an elegant
> >   way. We don't like to write throw-away code. It should go into
> >   mainline and also be used for other projects.
> >
> >Just to get it right. You suggest to extend g_serial for communication
> >with another driver and write some glue which communicates with
> >g_serial on the one and ttySAC0 on the other side?
> >
> >I could life with that solution, but why not extend g_serial with a
> >paramter to communicate directly with another tty?
> 
> Yep... this could be done... actually it's not that difficult, check
> the code here:
> 
> #define GS_MAJOR			127
> #define GS_MINOR_START		  0
> 
> I think the first test here is to change this two defines for you
> MAJOR and MINOR numbers, the ones for /dev/ttySACx

Sory, but WTF?

Why would changing the major/minor device numbers of g_serial do
anything to solve _any_ problem (not even talking about the specific
problem here)?   

We haev:

1) A linux based embedded device
2) a physical serial port (doesn't matter that there's a GSM Modem
   behind it) that uses the standard kernel serial driver interface
3) a USB device controller for the standard kernel gadget system
4) the standard g_serial driver for the gadget framework, which creates
   a virtual serial port on the device and a virtual usb serial port on
   the host

What we are trying to do is to export a physical serial port as a
virtual serial port over the usb device controller.

Thus, the 'virtual serial device' part of g_serial needs to be cleanly
separated from the 'usb serial device emulation' of g_serial, and then
spliced with the physical serial device.

> Maybe you'll need some other work for this to work fine... I'll be
> reading Samsung's s3c2410 serial code to check how to connect them...

There is nothing specific to the samsung in this whole discussion, so I
don't see how any of that reading would bring you any further, sorry.

-- 
- Harald Welte <laforge at gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20070310/0634e8d8/attachment.pgp