All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joey Oravec <joravec@drewtech.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: linux raw serio driver 32 byte maximum
Date: Tue, 30 Aug 2011 20:40:31 -0400	[thread overview]
Message-ID: <4E5D82FF.4060100@drewtech.com> (raw)
In-Reply-To: <20110830225017.GA2405@core.coreip.homeip.net>

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

      reply	other threads:[~2011-08-31  0:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

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=4E5D82FF.4060100@drewtech.com \
    --to=joravec@drewtech.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /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.