From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932602AbcHVPYc (ORCPT ); Mon, 22 Aug 2016 11:24:32 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:62238 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932346AbcHVPY3 (ORCPT ); Mon, 22 Aug 2016 11:24:29 -0400 From: Arnd Bergmann To: Rob Herring Cc: Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Sebastian Reichel , Pavel Machek , Peter Hurley , NeilBrown , "Dr . H . Nikolaus Schaller" , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Mon, 22 Aug 2016 17:24:00 +0200 Message-ID: <2775954.hrE2UdODgU@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <20160818011445.22726-1-robh@kernel.org> <12886761.WF058qtZp8@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:AX/a1Fizl+72DrRV0eiamWGAVqxP2ZOFOjBvlgjJ8Cv6po8bgG7 13ZnqgD7jD6aHy4zLjVktewxF1HuursfbuUBfrLvTubWnzQkn3wgDuOPoMFDaARjNEg0nKV zhW4RpX2FzY4BsfhoTze+TGmEYo8SJKg+pioKuhzSP/wi90bhqmeGFngT1HhL10w+gRrE/S Gg876C7z/e5tVc3Uqt1ng== X-UI-Out-Filterresults: notjunk:1;V01:K0:9mIzt0MPghw=:iHtRZ4eaXfO/FlbWm7+sbb xR0jIBlIqWIyxiqRRpH4lLee/mK+lJVZAD53LL4cINSGGc+AfIEZbC2ZiP4Y9SsB3yTQDMliO qxVNkxymAVSKQUXqyXUxrdl+78VSlAacIEDcoEiZfneTfdcz3jF5W4QgkfH9BYx1Dr1oX1rFe m1tXc5pmhuWKwl1j8CKsgBMr9I9OsQnHgIbWlhqpEw2BA0tLTK54wNiMLFPiW7bPdfOuLCwJf ylVYrR98worVMrw7xXNZKKwjfEJ1jukwEb19CI4AFXIZ/stVtD6IC6/9yE9xQuZD4Rcq+ObBj EwC/NGoQhK4liH6lIIqUXmbn03bVuP6Wj90s/IN93LbEBPe4ELfnLmgjehZp/vgoad7b+x6rM 7tEfu92OiCnmKTEKTrJwl6qZe8FSgG7FkqCwCzbHayjtOmMGKe/kOKWiv1UfHQnsB0VdOTFuC dCYkwh9gfuskhdkfaJxzxbxUEopVvNBWY1SkX9FvuSMv23p42xLyJNqtrED4zNsliqfPJ3hP9 ejZq+l9cvrCuRp6sBs+EYSVV6AedR0HTQoOJIHWxTSsFdFkvonvAO9GAEbaSgiUg006t8pwQL F0sS7/P4wE9GZaRm8pcQujKy+FJVCL0AvbZXNFjTOOJ6h6g9HQWd4QuruPb+HTYK+2ELlPGNS Puhkl9h5dj7HOTyM1n1jvMMjf8RB4L/cWoJ9a0sqxzXnU9bT/CkyOcLRFwZPJxG/bZX7s4h1b tfjsA+8wnRAtERsE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: > On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: > > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: > >> > >> Before I spend more time on this, I'm looking mainly for feedback on the > >> general direction and structure (the interface with the existing serial > >> drivers in particular). > > > > Aside from the things that have already been mentioned in the discussion, > > I wonder how this should relate to the drivers/input/serio framework. > > As I mentioned, I did investigate that route. Ok, sorry for missing that. > > My impression is that there is some overlap in what you want > > to do here, and what serio does today as a line discipline on top > > of a tty line discipline (and on top of other non-uart serial > > connections), so we should look into whether the two can be unified > > or not. Here is what I found so far: > > > > For all I can tell, serio is only used for drivers/input/ but could > > easily be extended to other subsystems. It currently uses its own > > binary ID matching between drivers and devices through user space > > interfaces, though adding a DT binding for it would appear to be > > a good idea regardless. > > > > It also has a bus_type already, and with some operations defined on > > it. In particular, it has an "interrupt" method that is used to > > notify the client driver when a byte is available (and pass > > that byte along with it). This seems to be a useful addition to > > what you have. Since it is based on sending single characters > > both ways, transferring large amounts of data would be slower, > > but the interface is somewhat simpler. In principle, both > > character based and buffer based interfaces could coexist here > > as they do in some other interfaces (e.g. smbus). > > Given that about the only things it really provided are the bus_type > and associated boilerplate without much of a client interface, it > seemed to me that creating a new subsystem first made more sense. Then > we can convert serio to use the new subsystem. One possible downside of merging later is that we end up having to support the existing user space ABI for serio that may not fit well within whatever we come up with independently. I think there are two other valuable features provided by serio: - an existing set of drivers written to the API - the implementation of the tty_ldisc > I agree we'll probably need a character at time interface, but for > initial targets a buffer based interface is what's needed. I think what's more important than the 'character-at-a-time' interface is the notification about new data. Maybe I missed how you handle that today, but it seems that you can currently only handle polling for data using a blocking read. > > While serio is typically layered on top of tty-ldisc (on top of > > tty_port, which is often on top of uart_port) or on top of > > i8042/ps2 drivers, I suppose we could add another back-end on top > > of uart_port directly to avoid the ldisc configuration in many > > cases when using devicetree based setup. This should also address > > the main concern that Alan raised about generality of the > > subsystem: we'd always leave the option of either manual configuration > > of the tty-ldisc (for any tty_port) or configuring on-chip devices > > (using uart_port) directly through DT. Of course the same thing > > can be done if we hook into tty_port rather than uart_port. > > There are also some uart drivers that register directly with serio. Right, I think this is done to have automatic probing for the keyboard, rather than relying on the user space interface configuration. > I'm also thinking of using an ldisc backend as well as a way to move > forward with the slave drivers while tty_port rework is being done. Of > course that doesn't solve the fundamental problems with using an ldisc > already. Going the tty_port route is going take some time to > restructure things in the tty layer and require tree wide changes to > tty drivers. Would it make sense then to define a DT binding that can cover these four cases independent of the Linux usage: a) an existing tty line discipline matched to a tty port b) a serio device using the N_MOUSE line discipline (which happens to cover non-mouse devices these days) c) a uart_port slave attached directly to the uart (like in your current code) d) the same slave drivers using a new tty line discipline If we can handle all four, then at least we have some flexibility with moving around or merging the Linux implementation later. Arnd