* linux raw serio driver 32 byte maximum
@ 2011-08-30 21:59 Joey Oravec
2011-08-30 22:50 ` Dmitry Torokhov
0 siblings, 1 reply; 3+ messages in thread
From: Joey Oravec @ 2011-08-30 21:59 UTC (permalink / raw)
To: dtor; +Cc: linux-input
Dmitry -
In serio_raw.c function serio_raw_write() there's a check:
if (count > 32)
count = 32;
which coerces any call to write a maximum of 32 bytes. Do you know why
this limitation is in the code? Characters get written one-by-one to the
tty layer so I don't understand why it's there.
I'm not sure which section of the manpage defines write for a serial
port. In the ordinary case I expected this function to keep transmitting
until complete or an error occurs. If O_NONBLOCK was specified then I
might expect EAGAIN. Right now my calling code doesn't expect a
successful partial write. Do you think this module is doing the right
thing? Can you comment on what the caller must expect?
-joey
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux raw serio driver 32 byte maximum
2011-08-30 21:59 linux raw serio driver 32 byte maximum Joey Oravec
@ 2011-08-30 22:50 ` Dmitry Torokhov
2011-08-31 0:40 ` Joey Oravec
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Torokhov @ 2011-08-30 22:50 UTC (permalink / raw)
To: Joey Oravec; +Cc: linux-input
Hi Joey,
On Tue, Aug 30, 2011 at 05:59:49PM -0400, Joey Oravec wrote:
> Dmitry -
>
> In serio_raw.c function serio_raw_write() there's a check:
>
> if (count > 32)
> count = 32;
>
> which coerces any call to write a maximum of 32 bytes. Do you know
> why this limitation is in the code? Characters get written
> one-by-one to the tty layer so I don't understand why it's there.
The driver was trying to mimic behavior of 2.4 psaux device as close as
possible so 32 bytes limit came from there. Besides I think it is a good
idea to not allow one process hog serio port for too long...
>
> I'm not sure which section of the manpage defines write for a serial
> port. In the ordinary case I expected this function to keep
> transmitting until complete or an error occurs. If O_NONBLOCK was
> specified then I might expect EAGAIN. Right now my calling code
> doesn't expect a successful partial write. Do you think this module
> is doing the right thing? Can you comment on what the caller must
> expect?
I think you should handle partial writes. Even if driver honored
O_NONBLOCK you could get a partial write and not necessarily EAGAIN.
May I ask you what you are using serio_raw for?
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux raw serio driver 32 byte maximum
2011-08-30 22:50 ` Dmitry Torokhov
@ 2011-08-31 0:40 ` Joey Oravec
0 siblings, 0 replies; 3+ messages in thread
From: Joey Oravec @ 2011-08-31 0:40 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
On 8/30/2011 6:50 PM, Dmitry Torokhov wrote:
> May I ask you what you are using serio_raw for?
We make chips for embedded systems that have a UART host-interface and
implement several functions (rtc, gpio, power control, etc). The
protocol is framed and involves both command-response and unsolicited
messages. I'm writing an MFD kernel driver that handles communication
and exposes standard kernel interfaces for each feature.
I started with serio which registers a line discipline and provide basic
serial access in the kernel. Then I created a reusable module based on
serio_raw that does any buffering necessary and decodes the bytes into
frames. Finally it registers a platform device which gets connected to a
platform driver (my MFD driver). Through this stack my kernel driver is
able to send/receive framed serial data and can communicate with my chip.
I'm open to suggestions about how to improve this design. Writing this
sort of driver feels way more difficult than one for an i2c or SPI
device. This approach requires a lot of kernel layers AND running
inputattach in userspace just to connect a driver to a device on a
serial port. Maybe you'll have a better idea?
> I think you should handle partial writes. Even if driver honored
> O_NONBLOCK you could get a partial write and not necessarily EAGAIN.
As described above, it's a little different because I'm working inside
the kernel. However I need to conform to kernel standards for read/write
because my code uses serio and eventually the TTY layer.
My driver must either rely on the serio write blocking, or call serio
write in a while-loop and handle partial writes and any error codes.
Incoming data doesn't have this ambiguity because serio calls that
interrupt callback to process one character at a time.
-joey
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-08-31 0:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-30 21:59 linux raw serio driver 32 byte maximum Joey Oravec
2011-08-30 22:50 ` Dmitry Torokhov
2011-08-31 0:40 ` Joey Oravec
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.