From: Toby Gray <toby.gray@realvnc.com>
To: balbi@ti.com
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Stefan Bigler <stefan.bigler@keymile.com>,
Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: TTY loosing data with u_serial gadget
Date: Thu, 24 Mar 2011 12:07:56 +0000 [thread overview]
Message-ID: <4D8B341C.4010406@realvnc.com> (raw)
In-Reply-To: <20110322085344.GN1837@legolas.emea.dhcp.ti.com>
On 22/03/2011 08:53, Felipe Balbi wrote:
> Patch attached, please give it a good round of test as I don't have how
> to exercise all line disciplines. I ran 100 randconfigs over night and
> no warnings or erros on that area, at least not that I could see (so
> many warning while compiling the kernel :-( )
Is this patch missing the changes to tty_buffer.c that were in
http://permalink.gmane.org/gmane.linux.usb.general/28976
Without the changes to tty_buffer.c to use the value returned from the
receive_buf call then doesn't this patch not work correctly?
Also with this patch, does the receive_room member of tty_struct have
any use? As far as I can tell it's also referenced in paste_selection in
drivers/tty/vt/selection.c. It's the case that past_selection uses
receive_buf so shouldn't it be updated to use the new return value
semantics for receive_buf?
Without modifying tty_buffer.c to not make use of receive_room I can't
get console terminals to work with this patch. Although I have to admit
that I've been applying the patch to 2.6.35.3 as that's the kernel my
development board is currently using, but I can't see any immediate
reason why the most recent kernel would be any different. However I'm
still fairly new to the interactions between the various bits of tty
code and drivers, so I could just be missing an important change that's
in 2.6.38+.
Regards,
Toby
next prev parent reply other threads:[~2011-03-24 12:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 20:47 TTY loosing data with u_serial gadget Stefan Bigler
2011-03-17 0:04 ` Greg KH
2011-03-18 16:35 ` Stefan Bigler
2011-03-18 17:08 ` Felipe Balbi
2011-03-18 18:06 ` Alan Cox
2011-03-21 9:32 ` Felipe Balbi
2011-03-22 8:53 ` Felipe Balbi
2011-03-22 11:04 ` Alan Cox
2011-03-22 17:01 ` Greg KH
2011-03-24 12:07 ` Toby Gray [this message]
2011-03-24 12:37 ` Felipe Balbi
2011-03-24 12:51 ` Toby Gray
2011-03-24 13:00 ` Felipe Balbi
2011-03-24 15:40 ` Stefan Bigler
2011-03-24 16:15 ` Toby Gray
2011-03-25 11:02 ` Felipe Balbi
2011-03-18 21:46 ` Stefan Bigler
2011-03-18 18:07 ` Alan Cox
2011-03-18 21:15 ` Stefan Bigler
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=4D8B341C.4010406@realvnc.com \
--to=toby.gray@realvnc.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=balbi@ti.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stefan.bigler@keymile.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox