From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755822AbcHVPyC (ORCPT ); Mon, 22 Aug 2016 11:54:02 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:59301 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754527AbcHVPx7 (ORCPT ); Mon, 22 Aug 2016 11:53:59 -0400 From: Arnd Bergmann To: Marcel Holtmann Cc: Rob Herring , Greg Kroah-Hartman , 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:46:48 +0200 Message-ID: <1921745.7GarJ3zo4T@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> <2775954.hrE2UdODgU@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:b5dTM1SDkA7fVTLuK7Gv2ml3VPJFjYIYhM4mRXO9UR5MET4ZdVh xRg4MA1eRJauWYkV5avEN1CgeQZ67hZ7GfLPWt5r4c89I1UCCH9S6GcQJa1COpivTPq1RA2 1R6oZoUvl77UrTbDtBCBA8CCxikGHytV45WwyQV8TYeGCrwAbcL0Z7kBN7ae4E0iWuh10hs gUyBtWGfrxphZinwe88mQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:WXkw6pSnqyQ=:7WF/LFSscul8QEU15N/g8N 6vNM3rdjggHSHT3lmnYd8WPjPvxhXSN+O7HJDCpvNm+iH3uHj4Dz+7DHTTnEkkBfUdfv1Tosu MPoELVugeckGmXWUroK8yIQaOsz6RF4oK7FAL19v/+NeKecwIS3E608CiIh/oKtpM3yKX5LV9 JxJQsCF0CA2urpYJJyD8XTD8SxVevV5kGvPcocg/f92pFggA23p8xHsM3UaXPgis2kD/JE4MO 45oBhO6XdNmBHxddCy4Ejikks+IzGirrE4aQYQPiOLp6pw/mi74urxOaO4cAx7Oz4pdIP9ycS Am+OccdSd009iP85Vz4qqKEZ3JnM4VP8rSFCP6cza69VFjngyX6afd/i3JIXWm7L+hJTaywr0 OlUAJYi7UAEu+fcsah1hqar1T/GsWIAWvupoo2B3XWj4h0ESPpcVvu8iyQch2AkpgiebJfZ8m Zc7N8nj+0RWGAdQ4Hf/66pXt58VZBDilE43I1wVqrl0YuyMorlBtKQLoFZHsVRrpMCWL7cSnh jwflzyP89whIFX88bjAkpl595yS2yNUvHaP14BHpm+//KRQJ6k5apDKQ1gtrARd1LDHd1FPzE tpZscxwjDg7ZLZjUMXGnAJTQruy+KAbFEpDsJbLqmdSdNtji429FBpeCuybT5nEFzqLppCF9z /sVS8+xkLtw4l9NGh1dse0BAbT7tAwolEk1XWt2tY/z9nYmJneOglK6pkeCaMhaWT6Ul9c2cm FG7gKBkLaj+2PFts Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, August 22, 2016 11:28:02 AM CEST Marcel Holtmann wrote: > >>> 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. > > if we need any kind of userspace ABI to setup of Bluetooth > over UART devices, then we have failed. We want that the > special UARTs are identified via ACPI or DT and become an > enumeratable bus. So we can attach a driver to it. I was not referring to new devices here, only to the existing user space ABI that is used for serio (input) devices. If we have any tools relying on e.g. the 'serio' name for the sysfs path, using another name for the new bus_type may cause incompatibility when merging the two. Arnd