All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: alan@lxorguk.ukuu.org.uk
Cc: rmk+lkml@arm.linux.org.uk, galak@freescale.com, akpm@osdl.org,
	linux-kernel@vger.kernel.org, linuppc-embedded@freescale.com,
	vbordug@ru.mvista.com
Subject: Re: [PATCH] cpm_uart: Fix spinlock initialization
Date: Fri, 12 Aug 2005 14:58:09 -0700 (PDT)	[thread overview]
Message-ID: <20050812.145809.88701697.davem@davemloft.net> (raw)
In-Reply-To: <1123884186.22460.79.camel@localhost.localdomain>

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 12 Aug 2005 23:03:05 +0100

> http://zeniv.linux.org.uk/~alan/serial.diff

I like this a lot, and the count return based error handling
is nice as well.  Should a driver sink any bytes that the
TTY flip interface couldn't eat or should it just wait for
the overrun event?

With respect to that, in fact, there seems to be some questions
of consistency regarding tty_insert_flip_char() and the
tty_prepare_*() interfaces.  If tty_insert_flip_char() fails
to stow away the character (due to memory allocation failure),
this just happens transparently.  However, when using the
tty_prepare_*() stuff the driver just doesn't sink the bytes
at that time.

Perhaps there should be some kind of counterpart for
tty_insert_flip_char() (something like tty_prepare_to_insert_*() or
whatever) so that the "out-of-space" handling can be made more
consistent.

Some other things caught my eye while reading this:

--- linux.vanilla-2.6.13-rc6/drivers/char/hvc_console.c	2005-08-10 13:57:08.000000000 +0100
+++ linux-2.6.13-rc6/drivers/char/hvc_console.c	2005-07-18 19:06:42.000000000 +0100
 ...
+		count = tty_buffer_request_room(tty. N_INBUF);

that "." should be a "," obviously.  Also:

--- linux.vanilla-2.6.13-rc6/drivers/char/pcmcia/synclink_cs.c	2005-08-10 13:57:08.000000000 +0100
+++ linux-2.6.13-rc6/drivers/char/pcmcia/synclink_cs.c	2005-07-25 15:49:51.000000000 +0100
 ...
-		printk("%s(%d):rx_ready_async count=%d\n",
-			__FILE__,__LINE__,tty->flip.count);
+		printk("%s(%d):rx_ready",
+			__FILE__,__LINE__);

The name of the function really is "rx_ready_async", no real need
to condense it to "rx_ready" and in fact this might confuse someone
actually reading this debug message.

Next, I have a question about the logic of tty_buffer_find().

I interpret it's intended semantics as "Give me TTY buffer of size
at least 'size'." But it seems to be checking something else
while traversing the buffer list:

+	while((*tbh) != NULL) {
+		struct tty_buffer *t = *tbh;
+		if(t->size <= size) {
 ...
+			return t;

This returns the first tty buffer found in the list which is
"smaller than or equal to" size, so I think this test is reversed
and should instead be:

+		if(t->size >= size) {

Keep up the good work :-)


  reply	other threads:[~2005-08-12 21:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-12 16:32 [PATCH] cpm_uart: Fix spinlock initialization Kumar Gala
2005-08-12 19:46 ` Russell King
2005-08-12 19:54   ` Kumar Gala
2005-08-12 22:03   ` Alan Cox
2005-08-12 21:58     ` David S. Miller [this message]
2005-08-13 11:41       ` Alan Cox
2005-08-13 19:15   ` Russell King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050812.145809.88701697.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=galak@freescale.com \
    --cc=linuppc-embedded@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=vbordug@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.