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
> On Thu, 7 Dec 2006 21:16:27 +0100 Michael Westermann <[email protected]> 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.
On Sat, Dec 09, 2006 at 10:50:14PM -0800, Andrew Morton wrote:
> > On Thu, 7 Dec 2006 21:16:27 +0100 Michael Westermann <[email protected]> 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: