From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752740AbcAQOT6 (ORCPT <rfc822;w@1wt.eu>);
	Sun, 17 Jan 2016 09:19:58 -0500
Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:40244 "EHLO
	lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752235AbcAQOT4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 17 Jan 2016 09:19:56 -0500
Date: Sun, 17 Jan 2016 14:19:12 +0000
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Rob Herring <robh@kernel.org>,
        Vostrikov Andrey <andrey.vostrikov@cogentembedded.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Peter Hurley <peter@hurleysoftware.com>,
        Rob Herring <robherring2@gmail.com>,
        List for communicating with real GTA04 owners 
	<gta04-owner@goldelico.com>,
        tomeu@tomeuvizoso.net, NeilBrown <neil@brown.name>,
        Arnd Bergmann <arnd@arndb.de>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Sebastian Reichel <sre@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
        Grant Likely <grant.likely@linaro.org>, Jiri Slaby <jslaby@suse.cz>,
        Marek Belisko <marek@goldelico.com>
Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Message-ID: <20160117141912.4aa2e46c@lxorguk.ukuu.org.uk>
In-Reply-To: <3D5F35D7-31B5-4E68-875F-7DD492EF0316@goldelico.com>
References: <481E05A9-A192-438D-B092-D7700B30BBC4@goldelico.com>
	<20160113191542.GA12086@leverpostej>
	<1CD6CA14-AE4F-444F-A9A2-CF9B9485F2DC@goldelico.com>
	<20160115110106.GA3262@leverpostej>
	<69F8E1E5-EF49-4C8E-88E9-973F82F7102E@goldelico.com>
	<569913A1.80606@cogentembedded.com>
	<CB69F6F0-B40B-47D1-B175-8401F43288C5@goldelico.com>
	<56992959.2020204@hurleysoftware.com>
	<CAL_JsqL=Wotz4FuoV7PULfZNfSV=S_q0iOzkckVA3NDDzMdfZQ@mail.gmail.com>
	<744620565.20160116103445@cogentembedded.com>
	<20160116233157.GA7774@rob-hp-laptop>
	<3D5F35D7-31B5-4E68-875F-7DD492EF0316@goldelico.com>
Organization: Intel Corporation
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> When translating the system requirements you have provided and mixing
> with mine, I think we need:
> 
> 1. mechanism to receive characters sent by the peer MCU

Low level driver queue of some kind

> 2. mechanism to send characters to the peer (or a block for firmware download)

Ditto (maybe even netlink)

> 3. mechanism to open/close the UART (even if there is no user space/tty client)

So don't use the tty layer in the first place

> 4. mechanism to set the struct termios of the UART (baud rate etc.)

Can be done without the tty layer.

> 5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl
> 6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all

This sounds the wrong way up entirely.

Instead of trying to make the tty layer do weird stuff, make the driver
present a tty that is only the things that it wants to be exposed as a
tty if any. If there are none then don't use the tty layer at all.

We have lots of interfaces to random MCUs. Many of them talk "serial"
protocols, almost none of them pretend to be the tty layer.

Alan