Hi folks,
is there already a way for accessing serial ports from drivers,
w/o having to go through the TTY subsystem ?
Serdev seems provide a connection between arbitrary TTYs to device
drivers. But this implies always having a TTY for each UART (even if
it's never used outside the kernel).
Is there any way for accessing uarts more directly ?
--mtx
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
On Mon, 26 Jun 2017 00:43:12 +0200
"Enrico Weigelt, metux IT consult" <[email protected]> wrote:
> Hi folks,
>
>
> is there already a way for accessing serial ports from drivers,
> w/o having to go through the TTY subsystem ?
>
> Serdev seems provide a connection between arbitrary TTYs to device
> drivers. But this implies always having a TTY for each UART (even if
> it's never used outside the kernel).
>
> Is there any way for accessing uarts more directly ?
You can write your own driver for the physical hardware and claim it in
your driver. Shouldn't normally be needed except for bizarre cases when a
serial link is used for something very non tty like (eg as GPIO lines).
Otherwise all the low level tty device locking, queues and interfaces
assume there is a tty_struct attached to it, so yes you need a tty
struct.
Why do you need to do otherwise ?
Alan
On 26.06.2017 14:51, Alan Cox wrote:
Hi,
> You can write your own driver for the physical hardware and claim it in
> your driver. Shouldn't normally be needed except for bizarre cases when a
> serial link is used for something very non tty like (eg as GPIO lines).
In my case, it's not really a serial link, but an backplane w/ FIFOs,
which looks like a serial ports to the host (AFAIK, historically coming
from older systems which actually had various serial controllers, eg.
rs232, rs485/mvb, etc). The backplane seems to simulate the lower
layers of an mvb network.
> Otherwise all the low level tty device locking, queues and interfaces
> assume there is a tty_struct attached to it, so yes you need a tty
> struct.
I was thinking about something that looks like serdev from consumer
side, but instead directly works on struct uart_port, w/o actually
allocating a tty (and also the funny things like signals, etc).
> Why do you need to do otherwise ?
Maybe it could offer better performance ?
--mtx
> I was thinking about something that looks like serdev from consumer
> side, but instead directly works on struct uart_port, w/o actually
> allocating a tty (and also the funny things like signals, etc).
uart_port is only a subset of tty devices and also relies upon tty for
some of the locking and other behaviour.
> > Why do you need to do otherwise ?
>
> Maybe it could offer better performance ?
Unless you have very tight latency requirements I would be surprised if
you could do that much better even on a slow machine. If you don't need
tty semantics then you can probably beat it hands down by writing your
own custom driver for the hardware that doesn't pretend to be a tty in
the first place.
The cost in the tty stack is pretty much all the Unix tty API and POSIX
guarantees.
Alan