[linux-usb-devel] [RFC] g_serial: Real tty device passthrough.
laforge at openmoko.org
Sat Mar 10 00:04:31 CET 2007
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
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
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
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20070310/0634e8d8/attachment.pgp
More information about the openmoko-kernel