From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755056AbcHVMhe (ORCPT ); Mon, 22 Aug 2016 08:37:34 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:59904 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbcHVMhb (ORCPT ); Mon, 22 Aug 2016 08:37:31 -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 , linux-bluetooth@vger.kernel.org, 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 14:37:02 +0200 Message-ID: <12886761.WF058qtZp8@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160818011445.22726-1-robh@kernel.org> References: <20160818011445.22726-1-robh@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:g2Q6u9lwsucZwoXcLmvM1TPNOYwHkYBN5OhrfKDznvKt+pFKAO7 gyLWRFVANXBruYdBWV6CUfPJ2GSLB/n+BFKxZsbZWbKoeLZoupTuT3myi+y6wSNZYNI1e/Y RfuuIJmlX+p1smfZKragHzJIse+DY5E4gYLvIqCqtOufAqzbZ0a+V91mu+YLR52Cn1EZ0c3 hshKqrdkorGNFlNreybwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:azQy/jxFjCA=:E5YTa0PnnKj+57s3M2G4sI hYV3NST5xceKOhs8vdkaq7gAcibMOzPDZzO6rojELoaB+NBW9WkHYiQi2PwlS/OPgV4VsWcTc FPeCfIIZ7bgs/M3fAJQyAaTvbRw64C6Y4c4g/X1EHNE3nTV8wrd+XiCmN0BexkmgxU9mLJdA8 xKpjh3v3QuwdaWzvjF2IR/nuoIw1vJvLObavaM2hoSh/71lmjjp2h6dCBEC3AxKnNd005wmCs faGOlBb95ttr+YU8iC1YSh9ST2TjfMQcsVZQSu9BOF9nWIcd7CdbUyOvZICywZU9jzHhIRvdJ NMGTSXDERK794LdcZ2r5Xm53fgjgGUttYVaInzaknVlqf3G3tmTbwv86kWBUD1n4MrM273+0Q oxrwLC870eLxvigzZneZ67tYwn1bLdwMysiBkCqWVesDvUW7U3HfI9ILeeYVgeLRVafXm4VKW SpVehhLhopx9I9Y9VcMjhogK02aCZy8toCTIq6szkpYylS1IAArSzBSgT7wsbe+Z0C+UAXCBQ Ox9Pu0hGgEsaYMtOHzslhD45r5vgLh47RYFzB4Qs1NESG5JSf+s9zPFjgoR61WqE6dSTQCsLK Ekoj6UCdMr4O0EGNnw+HQMrZXECXhe1rcFin290D+kxoFc1IB3yj8aO8kNl4thr/8IGs42Ich H7qDwqA0zuZY8+r1dSvzSQj7MnOPc5p33sT+5VKYCZIImXaxdKuWk19FC8jYXvug6LDnY9rOc 4Jkut/BxWPUWT94U Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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). 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. Arnd