DTR/DSR handshake in kernelspace third traying

DTR/DSR handshake in kernelspace third traying

[Michael Westermann]

Hello,

I've send 2 patches for a DTS/DSR handshaking to the list

http://lkml.org/lkml/2004/5/7/76  and long long time ago 1998

My problem are manufacturers the make printers with
DTR/DSR Handschaking. POS Printers are very sensible for
a buffer overrun!

For on or two printers, we can wire a adapter, for 10000...30000
printers is a software option the better way.

I've write a patch for 2.2 and published it, 
I've write a patch for 2.4 and published it, but i've see there is no

DTR/DSR Handshaking in the kernel 2.6.

I'm a litte bit  frusted. Are a few  thousands pos-systems not
enough for upgrading the standard kernel sources?

Have I a really chance to commit a patch for kernel 2.6.

What is the best way to handle this problem.

Thanks for comments ;-)

Michael Westermann

Re: DTR/DSR handshake in kernelspace third traying

[Andrew Morton]

> On Thu, 7 Dec 2006 21:16:27 +0100 Michael Westermann <michael@dvmwest.de> wrote:
> Hello,
> 
> I've send 2 patches for a DTS/DSR handshaking to the list
> 
> http://lkml.org/lkml/2004/5/7/76  and long long time ago 1998
> 
> My problem are manufacturers the make printers with
> DTR/DSR Handschaking. POS Printers are very sensible for
> a buffer overrun!
> 
> For on or two printers, we can wire a adapter, for 10000...30000
> printers is a software option the better way.
> 
> I've write a patch for 2.2 and published it, 
> I've write a patch for 2.4 and published it, but i've see there is no
> 
> DTR/DSR Handshaking in the kernel 2.6.
> 
> I'm a litte bit  frusted. Are a few  thousands pos-systems not
> enough for upgrading the standard kernel sources?
> 
> Have I a really chance to commit a patch for kernel 2.6.
> 

I'd say so.  Please make sure that such a patch is against the very latest
Linus kernel from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots. 
Also, the more comprehensive the patch's description the better - why it is
needed, what it does, how it works, etc.  Your 2004 description was rather
terse.

I seem to recall that the people who understand and work on this code
discussed this issue earlier this year, but I forget the conclusion.  Some
archive searching might be useful.

Re: DTR/DSR handshake in kernelspace third traying

[Russell King]

On Sat, Dec 09, 2006 at 10:50:14PM -0800, Andrew Morton wrote:
> > On Thu, 7 Dec 2006 21:16:27 +0100 Michael Westermann <michael@dvmwest.de> wrote:
> > Hello,
> > 
> > I've send 2 patches for a DTS/DSR handshaking to the list
> > 
> > http://lkml.org/lkml/2004/5/7/76  and long long time ago 1998
> > 
> > My problem are manufacturers the make printers with
> > DTR/DSR Handschaking. POS Printers are very sensible for
> > a buffer overrun!
> > 
> > For on or two printers, we can wire a adapter, for 10000...30000
> > printers is a software option the better way.
> > 
> > I've write a patch for 2.2 and published it, 
> > I've write a patch for 2.4 and published it, but i've see there is no
> > 
> > DTR/DSR Handshaking in the kernel 2.6.
> > 
> > I'm a litte bit  frusted. Are a few  thousands pos-systems not
> > enough for upgrading the standard kernel sources?
> > 
> > Have I a really chance to commit a patch for kernel 2.6.
> > 
> 
> I'd say so.  Please make sure that such a patch is against the very latest
> Linus kernel from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots. 
> Also, the more comprehensive the patch's description the better - why it is
> needed, what it does, how it works, etc.  Your 2004 description was rather
> terse.
> 
> I seem to recall that the people who understand and work on this code
> discussed this issue earlier this year, but I forget the conclusion.  Some
> archive searching might be useful.

Andrew,

My stance on handshaking has always been that it should be something
controlled via termios, not via some driver specific ioctl() which is
different for every single driver.

I see that this 2.4 patch actually does that, which is great.  A
couple of points though:

1. CRTSCTS should select RTS/CTS flow control.  There should be CDTRDSR
   for DTR/DSR flow, not CHWFLOW plus some additional ioctl.

2. the patch does not adequately handle switching flow control modes.
   The handling in set_termios is not sufficient - eg, when switching
   from CRTSCTS with de-asserted CTS to CDTRDSR with asserted DSR will
   result in the driver believing that the flow control signal is still
   deasserted.  Incidentally, this also directly affects changing the
   flow control method via the additional ioctls.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: