Another candidate for removal is drivers/char/pcmcia/synclink_cs.c
Everything I said about synclink.c/synclinkmp.c is true of that as well: the
hardware stopped being manufactured decades ago and is not available for
testing. The possibility of these cards still being around/functional for
> On Nov 5, 2020, at 1:10 AM, Jiri Slaby wrote:
>
> OK, let the loop alone. I would bet a half a pig that noone is able to test
> this driver. But one has to write this for someone to raise and admit they
> are still using it. In fact, there are _4_ google replies to "Microgate
>
> On Jan 4, 2019, at 2:23 AM, Tetsuo Handa
> wrote:
>
> But why not to clarify what are appropriate sanity checks?
> ...
> want a cleanup for scripts/checkpatch.pl .
These are good goals. I avoid purely cosmetic patches. I do not object to
cosmetic patches from others that do not change
> On Jan 3, 2019, at 3:32 AM, Tetsuo Handa
> wrote:
>
> On 2019/01/03 18:09, Jiri Slaby wrote:
>> On 02. 01. 19, 16:04, Tetsuo Handa wrote:
>>> + if (wait_event_interruptible(tty->read_wait,
>>> +(ret = -EIO, test_bit(TTY_OTHER_CLOSED, >flags)) ||
>>> +(ret = 0,
> On Jan 2, 2019, at 7:04 AM, Tetsuo Handa
> wrote:
>
> On 2019/01/01 12:11, Paul Fulghum wrote:
>> NAK to this patch. It causes lost wakeups in both read and write paths.
>>
>> The write path does not need changing.
>>
>> The read path can b
.
This patch supresses the warning by setting TASK_RUNNING before calling
copy_to_user.
[1]
https://syzkaller.appspot.com/bug?id=17d5de7f1fcab794cb8c40032f893f52de899324
Signed-off-by: Paul Fulghum
Reported-by: syzbot
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Arnd Bergmann
Cc: Alan Cox
On Dec 31, 2018, at 7:11 PM, Paul Fulghum wrote:
NAK to this patch. It causes lost wakeups in both read and write paths.
The write path does not need changing.
The read path can be fixed by setting current to TASK_RUNNING at the top of the
if (rbuf) block so the warning is not triggered
buffers are removed.
Signed-off-by: Paul Fulghum
--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-12-03 10:51:40.0 -0600
@@ -210,7 +210,7 @@ typedef struct _mgslpc_info {
char testing_irq;
unsigned
he relative comments (which are inside function) to the
> location just above ldisc_receive_buf ?
The added comment from my first patch described the reuse
of the data buffer as the flag buffer. Alan prefers to use
a zero initialized dummy buffer for the flag buffer argument.
Doing it that way
ldisc_receive_buf ?
The added comment from my first patch described the reuse
of the data buffer as the flag buffer. Alan prefers to use
a zero initialized dummy buffer for the flag buffer argument.
Doing it that way, the comment is not needed.
--
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven
buffers are removed.
Signed-off-by: Paul Fulghum pau...@microgate.com
--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-12-03 10:51:40.0 -0600
@@ -210,7 +210,7 @@ typedef struct _mgslpc_info {
char testing_irq
so valid memory is provided if the wrong
line discipline is used. Unused char_buf and flag_buf are removed.
Signed-off-by: Paul Fulghum
--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-11-30 12:50:23.0 -0600
he fact the flag buffer is ignored
when using N_HDLC. That way a misconfigured setup won't
cause problems and no unneeded allocations are made.
My suggestion is to leave it as is for now until I can make
those changes. I admit the current code is ugly enough to
cause confusion (sorry Chen Gang),
can make
those changes. I admit the current code is ugly enough to
cause confusion (sorry Chen Gang), but I don't see any immediate danger.
--
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982 (US Sales)
(512)345-7791 x102 (Direct)
(512)343-9046 (Fax)
Central Time Zone
so valid memory is provided if the wrong
line discipline is used. Unused char_buf and flag_buf are removed.
Signed-off-by: Paul Fulghum pau...@microgate.com
--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-11-30 12:50
Jiri Slaby wrote:
It should be fixed already as of
git-describe db99247a
v2.6.24-rc6-95-gdb99247
So since 2.6.24-rc7.
Maybe we should consider the fix for 2.6.23 too.
Whoops, I missed that.
Problem solved :-)
Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe
unless Jiri beats me to it.
Thanks,
Paul
--
Paul Fulghum
Microgate Systems, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
Paul Fulghum wrote:
Instead of reverting the patch can you try modifying
this part of the patch:
+ if (wait_event_interruptible_timeout(tty->write_wait,
+ !tty->driver->chars_in_buffer(tty), timeout))
+ return;
by
eturn;
It looks like the patch changed the behavior of
tty_wait_until_sent by not calling the driver
specific wait_until_sent if a timeout occurs.
--
Paul Fulghum
Microgate Systems, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
the patch changed the behavior of
tty_wait_until_sent by not calling the driver
specific wait_until_sent if a timeout occurs.
--
Paul Fulghum
Microgate Systems, Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Paul Fulghum wrote:
Instead of reverting the patch can you try modifying
this part of the patch:
+ if (wait_event_interruptible_timeout(tty-write_wait,
+ !tty-driver-chars_in_buffer(tty), timeout))
+ return;
by changing
unless Jiri beats me to it.
Thanks,
Paul
--
Paul Fulghum
Microgate Systems, Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
Jiri Slaby wrote:
It should be fixed already as of
git-describe db99247a
v2.6.24-rc6-95-gdb99247
So since 2.6.24-rc7.
Maybe we should consider the fix for 2.6.23 too.
Whoops, I missed that.
Problem solved :-)
Thanks,
Paul
--
To unsubscribe from this list: send the line unsubscribe
Fix missed serial input signal changes caused by rereading the
serial status register during interrupt processing. Now
processing is performed on original status register value.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink_gt.c2008-01-24 16:58:37.000
Fix missed serial input signal changes caused by rereading the
serial status register during interrupt processing. Now
processing is performed on original status register value.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink_gt.c2008-01-24 16:58:37.0
this new facility? The patch does not include
such an example so it is difficult for me to see
why you are adding this function.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
this new facility? The patch does not include
such an example so it is difficult for me to see
why you are adding this function.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Get module reference on open() by generic HDLC
to prevent module from unloading while interface
is active.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink_gt.c2007-07-08 18:32:17.0 -0500
+++ b/drivers/char/synclink_gt.c2007-08-14
Get module reference on open() by generic HDLC
to prevent module from unloading while interface
is active.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink_gt.c2007-07-08 18:32:17.0 -0500
+++ b/drivers/char/synclink_gt.c2007-08-14 12:27
fferent thing than these
in drivers/net/wan/ and I have no connection with it. Not sure
who is responsible, if anyone.
I am, my email is at the top of n_hdlc.c but there
is no maintainers entry.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe li
off-by: Alan Cox <[EMAIL PROTECTED]>
It looks good and clean.
I compiled and tested the patch with interleaved
tcflush() and read() calls, allowing random amounts
of receive data to accumulate between each call.
Acked-by: Paul Fulghum <[EMAIL PROTECTED]>
Thanks,
Paul
--
y
even though there is possibly still receive data being fed
to the ldisc.
If this is followed immediately by a read() then the
application gets unexpected (stale) data defeating the
purpose of the TCFLSH.
tty_buffer_flush() needs to wait for buf.flushpending to clear.
--
Paul Fulghum
Microgate S
at looks good, a little better than the solution
I was first considering. I'm compiling now.
This was a nasty bug for me to introduce :-(
Good work in finding this Laurent.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
Laurent Pinchart wrote:
Patch c5c34d4862e18ef07c1276d233507f540fb5a532 (tty: flush flip buffer on
ldisc input queue flush) introduces a race condition which can lead to memory
leaks.
The problem can be triggered when tcflush() is called when data are being
pushed to the line discipline
Laurent Pinchart wrote:
Patch c5c34d4862e18ef07c1276d233507f540fb5a532 (tty: flush flip buffer on
ldisc input queue flush) introduces a race condition which can lead to memory
leaks.
The problem can be triggered when tcflush() is called when data are being
pushed to the line discipline
the solution
I was first considering. I'm compiling now.
This was a nasty bug for me to introduce :-(
Good work in finding this Laurent.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
though there is possibly still receive data being fed
to the ldisc.
If this is followed immediately by a read() then the
application gets unexpected (stale) data defeating the
purpose of the TCFLSH.
tty_buffer_flush() needs to wait for buf.flushpending to clear.
--
Paul Fulghum
Microgate Systems
]
It looks good and clean.
I compiled and tested the patch with interleaved
tcflush() and read() calls, allowing random amounts
of receive data to accumulate between each call.
Acked-by: Paul Fulghum [EMAIL PROTECTED]
Thanks,
Paul
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from
these
in drivers/net/wan/ and I have no connection with it. Not sure
who is responsible, if anyone.
I am, my email is at the top of n_hdlc.c but there
is no maintainers entry.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
2.2.5 is using the same UART setup (trigger level of 8) as
the current code. There is no obvious difference in the
interrupt setup (same devices on the same interrupts).
So I have no helpful suggestions :-(
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
2.2.5 is using the same UART setup (trigger level of 8) as
the current code. There is no obvious difference in the
interrupt setup (same devices on the same interrupts).
So I have no helpful suggestions :-(
--
Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases an
increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not exhibit this problem.
Was
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases an
increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not exhibit this problem.
Was
On Fri, 2007-07-27 at 13:48 -0700, Lee Howard wrote:
> Here's the output:
>
> type: 4
> line: 1
> line: 760
> irq: 3
>flags: 1358954688
> xmit_fifo_size: 16
> custom_divisor: 0
>baud_base: 115200
OK, the FIFO should be
t hardware FIFO overruns,
you would never see any flow control action
as reported by Lee.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
OK, I see where TTY_OVERRUN is set:
include/linux/serial_core.h:uart_insert_char()
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
; time.
You are right, this error is output when the character flag TTY_OVERRUN
is encountered by n_tty.c which should be set by the driver
in response to a hardware FIFO overrun (not an ldisc buffer overrun).
I can't see anyplace in serial_core.c or 8250.c that sets TTY_OVERRUN.
--
Paul Fulgh
ttle()
These are called by N_TTY in response to buffer levels.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
g more data to the ldisc. This results in the
receive data you see after a TCFLSH.
Starting with 2.6.22 TCFLSH is processed by the intermediate
buffering as well as the ldisc to eliminate any remaining
receive data in the intermediate buffering.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscr
in the
receive data you see after a TCFLSH.
Starting with 2.6.22 TCFLSH is processed by the intermediate
buffering as well as the ldisc to eliminate any remaining
receive data in the intermediate buffering.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line
to buffer levels.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
are right, this error is output when the character flag TTY_OVERRUN
is encountered by n_tty.c which should be set by the driver
in response to a hardware FIFO overrun (not an ldisc buffer overrun).
I can't see anyplace in serial_core.c or 8250.c that sets TTY_OVERRUN.
--
Paul Fulghum
Microgate Systems
FIFO overruns,
you would never see any flow control action
as reported by Lee.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
OK, I see where TTY_OVERRUN is set:
include/linux/serial_core.h:uart_insert_char()
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Fri, 2007-07-27 at 13:48 -0700, Lee Howard wrote:
Here's the output:
type: 4
line: 1
line: 760
irq: 3
flags: 1358954688
xmit_fifo_size: 16
custom_divisor: 0
baud_base: 115200
OK, the FIFO should be enabled.
What
Fix transmit DMA stall when write() called in window after
previous transmit DMA completes but before previous serial
transmission completes.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink_gt.c2007-07-08 18:32:17.0 -0500
+++ b/driver
Fix transmit DMA stall when write() called in window after
previous transmit DMA completes but before previous serial
transmission completes.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink_gt.c2007-07-08 18:32:17.0 -0500
+++ b/drivers/char/synclink_gt.c
James Simmons wrote:
Done. I still smell a dead lock issue tho.
Yes, but it is an existing problem that was kicked
about with no real resolution.
No one can blame you for that! :-)
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe
ning at IRQ context and want to use low_latency.
In the end, I think they decided to leave the correct use of
low_latency WRT running in IRQ context to the caller.
It might be safest to drop this portion so you can get the
obvious part of the patch accepted (consolidating
the redundant xxx_schedule
the correct use of
low_latency WRT running in IRQ context to the caller.
It might be safest to drop this portion so you can get the
obvious part of the patch accepted (consolidating
the redundant xxx_schedule_flip functions).
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send
James Simmons wrote:
Done. I still smell a dead lock issue tho.
Yes, but it is an existing problem that was kicked
about with no real resolution.
No one can blame you for that! :-)
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
e once the work is scheduled
(with a delay of 1) new scheduling calls are ignored for
the same work structure.
I've been testing the change to 0 in tty_schedule_flip()
under various loads and data rates with no ill effects.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list
.
Whichever way everyone else wants to go.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
t interrupt time and then queued for processing.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
e the way it was done and it ended up causing
deadlocks in just that situation.
And the initial schedule has no reason to add the extra delay.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
to be the way it was done and it ended up causing
deadlocks in just that situation.
And the initial schedule has no reason to add the extra delay.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
.
Whichever way everyone else wants to go.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
and then queued for processing.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
the work is scheduled
(with a delay of 1) new scheduling calls are ignored for
the same work structure.
I've been testing the change to 0 in tty_schedule_flip()
under various loads and data rates with no ill effects.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send
Björn Steinbrink wrote:
Sorry for the delay, your mails didn't make it into my inbox, and I
usually just mark threads on which I'm Cc'ed as read in my lkml mailbox,
thus I didn't notice it earlier. Any traces of the lost mails on your
side?
No clues on this end.
The patch works as expected,
Björn Steinbrink wrote:
Sorry for the delay, your mails didn't make it into my inbox, and I
usually just mark threads on which I'm Cc'ed as read in my lkml mailbox,
thus I didn't notice it earlier. Any traces of the lost mails on your
side?
No clues on this end.
The patch works as expected,
Restore tty locked ioctl handler which was replaced with
an unlocked ioctl handler in hung_up_tty_fops by the patch:
commit e10cc1df1d2014f68a4bdcf73f6dd122c4561f94
Author: Paul Fulghum <[EMAIL PROTECTED]>
Date: Thu May 10 22:22:50 2007 -0700
tty: add compat_ioctl
This was re
On Fri, 2007-06-08 at 10:16 -0500, Paul Fulghum wrote:
> On Fri, 2007-06-08 at 05:06 +0200, Björn Steinbrink wrote:
> > This is do_tty_hangup() exchanging the fops while we're waiting for the
> > lock. The new fops (hung_up_tty_fops) only have the unlocked variant and
> >
On Fri, 2007-06-08 at 05:06 +0200, Björn Steinbrink wrote:
> This is do_tty_hangup() exchanging the fops while we're waiting for the
> lock. The new fops (hung_up_tty_fops) only have the unlocked variant and
> thus we Oops our way.
>
> The following program reproduces it quite easily on a SMP
variant and
> > thus we Oops our way.
>
> ah, yes, that explains it, thanks. Culprit:
>
> commit e10cc1df1d2014f68a4bdcf73f6dd122c4561f94
> Author: Paul Fulghum <[EMAIL PROTECTED]>
> Date: Thu May 10 22:22:50 2007 -0700
>
> tty: add compat_ioctl
&
our way.
ah, yes, that explains it, thanks. Culprit:
commit e10cc1df1d2014f68a4bdcf73f6dd122c4561f94
Author: Paul Fulghum [EMAIL PROTECTED]
Date: Thu May 10 22:22:50 2007 -0700
tty: add compat_ioctl
Add compat_ioctl method for tty code to allow processing of 32 bit ioctl
On Fri, 2007-06-08 at 05:06 +0200, Björn Steinbrink wrote:
This is do_tty_hangup() exchanging the fops while we're waiting for the
lock. The new fops (hung_up_tty_fops) only have the unlocked variant and
thus we Oops our way.
The following program reproduces it quite easily on a SMP box. I'm
On Fri, 2007-06-08 at 10:16 -0500, Paul Fulghum wrote:
On Fri, 2007-06-08 at 05:06 +0200, Björn Steinbrink wrote:
This is do_tty_hangup() exchanging the fops while we're waiting for the
lock. The new fops (hung_up_tty_fops) only have the unlocked variant and
thus we Oops our way.
...
Here
Restore tty locked ioctl handler which was replaced with
an unlocked ioctl handler in hung_up_tty_fops by the patch:
commit e10cc1df1d2014f68a4bdcf73f6dd122c4561f94
Author: Paul Fulghum [EMAIL PROTECTED]
Date: Thu May 10 22:22:50 2007 -0700
tty: add compat_ioctl
This was reported in:
[Bug
On Thu, 2007-05-24 at 14:28 +0200, Jiri Slaby wrote:
> n_hdlc, allow RESTARTSYS retval of tty write
>
> Cc: Paul Fulghum <[EMAIL PROTECTED]>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
>
Acked-by: Paul Fulghum <[EMAIL PROTECTED]>
--
Paul Fulghum
Microga
On Thu, 2007-05-24 at 14:28 +0200, Jiri Slaby wrote:
n_hdlc, allow RESTARTSYS retval of tty write
Cc: Paul Fulghum [EMAIL PROTECTED]
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
Acked-by: Paul Fulghum [EMAIL PROTECTED]
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from
James Simmons wrote:
Great Here is the patch updated with the delay value set to zero.
Acked-by: Paul Fulghum <[EMAIL PROTECTED]>
You should submit this to
Andrew Morton <[EMAIL PROTECTED]>
so it can get into the mm tree.
--
Paul
-
To unsubscribe from this list: s
Paul Fulghum wrote:
As the tty flip buffer code has evolved, that delay value of 1
was carried along. It may have had some historical purpose, but
I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with the timer
Add support for 32 bit ioctl on 64 bit systems for synclink_gt
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/include/linux/Kbuild 2007-04-25 22:08:32.0 -0500
+++ b/include/linux/Kbuild 2007-05-09 10:11:22.0 -05
Add support for 32 bit ioctl on 64 bit systems for synclink_gt
Cc: Arnd Bergmann [EMAIL PROTECTED]
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/include/linux/Kbuild 2007-04-25 22:08:32.0 -0500
+++ b/include/linux/Kbuild 2007-05-09 10:11:22.0 -0500
@@ -140,7
Paul Fulghum wrote:
As the tty flip buffer code has evolved, that delay value of 1
was carried along. It may have had some historical purpose, but
I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with the timer
James Simmons wrote:
Great Here is the patch updated with the delay value set to zero.
Acked-by: Paul Fulghum [EMAIL PROTECTED]
You should submit this to
Andrew Morton [EMAIL PROTECTED]
so it can get into the mm tree.
--
Paul
-
To unsubscribe from this list: send the line unsubscribe
Arnd Bergmann wrote:
To solve this, you can to change include/linux/Kbuild to list
synclink.h as unifdef-y instead of header-y, and put the parts
that you don't want to be in user space inside of #ifdef __KERNEL__.
Alternatively, you can put these kernel-internal definitions into
a private
'm trying
to figure out the rules for when and where you are allowed
to use compat.h, I'm not familiar with the headerscheck
facility so I'm not sure what it is looking for and the
error is not very helpful. There is nothing in Documentation
covering it.
--
Paul Fulghum
Microgate Systems, Ltd
-
To un
some historical purpose, but
I can't figure it out and it appears to have no use currently.
It would be better for performance to process the receive data
as soon as possible (delay value of 0).
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsu
, but
I can't figure it out and it appears to have no use currently.
It would be better for performance to process the receive data
as soon as possible (delay value of 0).
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
trying
to figure out the rules for when and where you are allowed
to use compat.h, I'm not familiar with the headerscheck
facility so I'm not sure what it is looking for and the
error is not very helpful. There is nothing in Documentation
covering it.
--
Paul Fulghum
Microgate Systems, Ltd
Arnd Bergmann wrote:
To solve this, you can to change include/linux/Kbuild to list
synclink.h as unifdef-y instead of header-y, and put the parts
that you don't want to be in user space inside of #ifdef __KERNEL__.
Alternatively, you can put these kernel-internal definitions into
a private
;
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500
@@ -365,6 +365,29 @@ static void tty_buffer_free(struct tty_s
}
/**
+ * tty_buffer_flush
-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500
@@ -365,6 +365,29 @@ static void tty_buffer_free(struct tty_s
}
/**
+ * tty_buffer_flush- flush full tty
Alan Cox wrote:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
should I understand this so that, if tty_buffer_request_room() returns
less than requested, the rest of the data should be dropped on the
floor?
If it returns NULL then either there is > 64K buffered
Antonino Ingargiola wrote:
For my use case would be more sensible to accept the new data and
discard the older one in the tty buffer: the tty buffer would be a
moving window of the most recent incoming data. This because if
someone does not read the incoming data maybe he's not interested in
it.
Antonino Ingargiola wrote:
For my use case would be more sensible to accept the new data and
discard the older one in the tty buffer: the tty buffer would be a
moving window of the most recent incoming data. This because if
someone does not read the incoming data maybe he's not interested in
it.
Alan Cox wrote:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
should I understand this so that, if tty_buffer_request_room() returns
less than requested, the rest of the data should be dropped on the
floor?
If it returns NULL then either there is 64K buffered (we
On Sat, 2007-05-05 at 18:58 +0200, Antonino Ingargiola wrote:
> This patch does not solve the problem with the cdc_acd driver. I still
> need to flush two times to really flush the input. And the "secondary
> buffer" still seems 26 bytes (as before).
I missed a bit, try this.
---
1 - 100 of 265 matches
Mail list logo
