From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934911AbcATRrH (ORCPT ); Wed, 20 Jan 2016 12:47:07 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:53170 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934158AbcATRqx (ORCPT ); Wed, 20 Jan 2016 12:46:53 -0500 Date: Wed, 20 Jan 2016 17:46:10 +0000 From: One Thousand Gnomes To: "H. Nikolaus Schaller" Cc: Rob Herring , Vostrikov Andrey , Mark Rutland , Peter Hurley , Rob Herring , List for communicating with real GTA04 owners , tomeu@tomeuvizoso.net, NeilBrown , Arnd Bergmann , "devicetree@vger.kernel.org" , Greg Kroah-Hartman , Sebastian Reichel , "linux-kernel@vger.kernel.org" , "linux-serial@vger.kernel.org" , Grant Likely , Jiri Slaby , Marek Belisko Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Message-ID: <20160120174610.1c64239a@lxorguk.ukuu.org.uk> In-Reply-To: <9E37C552-361C-4A54-980E-E3BFFF834302@goldelico.com> References: <481E05A9-A192-438D-B092-D7700B30BBC4@goldelico.com> <20160115110106.GA3262@leverpostej> <69F8E1E5-EF49-4C8E-88E9-973F82F7102E@goldelico.com> <569913A1.80606@cogentembedded.com> <56992959.2020204@hurleysoftware.com> <744620565.20160116103445@cogentembedded.com> <20160116233157.GA7774@rob-hp-laptop> <3D5F35D7-31B5-4E68-875F-7DD492EF0316@goldelico.com> <20160117141912.4aa2e46c@lxorguk.ukuu.org.uk> <1D5F146E-D347-453B-9158-8D269F8DA99C@goldelico.com> <20160117193849.69d00c28@lxorguk.ukuu.org.uk> <37DCE36D-0A5E-41C5-BDA4-857DCF9F2DD1@goldelico.com> <20160118111926.0882b422@lxorguk.ukuu.org.uk> <07F3B6C0-0C87-478C-B6DD-5C0EECB42D0D@goldelico.com> <20160118220319.051c9cc0@lxorguk.ukuu.org.uk> <9E37C552-361C-4A54-980E-E3BFFF834302@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: X-Mailing-List: linux-kernel@vger.kernel.org > The problem is that *I* have no control over user space. But I also don't want > to say to my users "that is not my problem - get it solved yourself". This does > not help them. Stuffing things into the kernel because the user space of a given platform can't get itself organised isn't helpful to the other billion plus Linux devices out there. > And, most device drivers are corner cases since they are special solutions > for singular platforms. Actually that is quite a small percentage - and the corner cases hide in drivers not in the core code, which is really important for maintainability. > >> I'm glad - because it raises some hard questions and while I don't agree > >> with some of your starting points (like needing to "open" a uart without > >> user space > > If have an idea how to turn off the device at boot time, before any user space > daemon is running, we can of course ignore that. Your early user space is responsible for it. If you can't accept that then I don't see any point continuing the conversation. > >> But see below as I think your mental model is perhaps wrong > >> and this is a point of confusion ? > > Maybe you do not accept that I want to keep as low level as reasonable (for me). It's always "for me". No the kernel project is not "for me" > >> Both of those techniques work in mainline without kernel changes (at > >> least on devices where the right gpio sysfs nodes exist > > they do not exist... For most they do because they are gpio lines so exportable to userspace. > >> This I think is actually the really hard and interesting part of the > >> problem. The "tell me about open and close" case is simple and can be > >> done via tty_port today with minimal extra hooks. There is a small > >> question about how you set those hooks from a DT binding > > tty has no binding. An UART hardware has. Another reason for me to > start with UARTs. Every uart is a tty_port, every non uart is a tty_port. There is no reason you can't bind to a non uart device. Your current patches create bindings for the uart layer. > >> For some hardware that is the only way I know to do this because the > >> power hungry uart receiver is physically powered down. I would have to > >> check but I *think* that is true even on a modern x86 PC that supports > >> wakeups via serial - although it may be well hidden in ACPI and firmware. > > Yes, agreed. But the gpio + interrupt solution was not mainlineable as well. That I am unsure about - at some point it is going to have to be sorted because it is increasingly common (if currently mostly invisible) > >> I'm not personally opoosed to the tty slave idea providing it ends up > >> attached to the tty_port not just uart. > > Well if you can tell us how to handle the data path I have no problems with it > to attach to the tty level. If your port is closed you have no data path. If you are using uart you have no data path because while your patch hooks a helper that some uarts use some of the time it's optional and a lot of uarts don't use it, so its not even uart generic. Alan