Subject: Re: Directly accessing serial ports from drivers w/o TTYs ?
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
References: <a159c02b-cec6-51a5-3bde-b0e8eab74055@gr13.net>
 <20170626155115.13617ed6@alans-desktop>
Cc: linux-kernel@vger.kernel.org
From: "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net>
Message-ID: <cf910296-8bd9-aca8-079b-149580f1ddd0@gr13.net>
Date: Thu, 29 Jun 2017 11:44:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170626155115.13617ed6@alans-desktop>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1013
Lines: 28

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