linux-kernel - Re: Directly accessing serial ports from drivers w/o TTYs ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Jun 2017 11:44:58 +0000
From:   "Enrico Weigelt, metux IT consult" <enrico.weigelt@...3.net>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Directly accessing serial ports from drivers w/o TTYs ?

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