Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC PATCH 0/3] UART slave device bus From: "H. Nikolaus Schaller" In-Reply-To: <20160818152528.569eb426@lxorguk.ukuu.org.uk> Date: Thu, 18 Aug 2016 17:14:21 +0200 Cc: Rob Herring , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Sebastian Reichel , Pavel Machek , Peter Hurley , NeilBrown , Arnd Bergmann , Linus Walleij , linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com> References: <20160818011445.22726-1-robh@kernel.org> <20160818152528.569eb426@lxorguk.ukuu.org.uk> To: One Thousand Gnomes List-ID: Hi Alan, > Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes = : >=20 > On Wed, 17 Aug 2016 20:14:42 -0500 > Rob Herring wrote: >=20 > This was proposed ages ago and the point clearly made that >=20 > a) the idea doesn't work because uarts are not required to use the = uart > layer and even those that do sometimes only use half of it >=20 > b) that you should use the tty_port abstraction >=20 > So instead of just waiting some months and recycling the proposals = it's > unfortunate that no listening and reworking was done. >=20 > https://lkml.org/lkml/2016/1/18/177 >=20 > So I'm giving this a large neon flashing NAK, because none of the > problems have been addressed. >=20 >> Currently, devices attached via a UART are not well supported in the >> kernel. The problem is the device support is done in tty line = disciplines, >> various platform drivers to handle some sideband, and in userspace = with >> utilities such as hciattach. >=20 > For most platforms it works very nicely and out of the box. The only > real issue I have actually seen is the bandwidth issue from early tty > based 3G modems. That's not hard to fix with some tty buffer changes. > Basically you need a tty port pointer that is atomic exchangable and > points either to the usual tty queue logic or to a 'fastpath' handler > which just gets thrown a block of bytes and told to use them or lose = them > - which is the interface the non n_tty ldiscs want anyway. That's = exactly > what you would need to fix to support in kernel stuff as well. The tty > queue mechanism for devices that can receive in blocks just becomes a > fastpath. >=20 > There are some disgusting Android turds floating around out of tree = where > people use things like userspace GPIO line control but you won't fix = most > of those anyway because they are generally being used for user > space modules including dumb GPS where the US government rules won't = allow > them to be open sourced anyway. >=20 >> - Split out the controller for uart_ports into separate driver. Do we = see >> a need for controller drivers that are not standard serial drivers? >=20 > As I told you over six months ago uart_port is not the correct > abstraction. You need to be working at the tty_port layer. The = original > design of tty_port was indeed partly to push towards being able to = have a > serial interface that is in use but not open to user space. The rather > nice rework that the maintainers have done to put the buffers in the > tty_port takes it closer still. >=20 > Plenty of the classic serial port interfaces also don't use the UART > layer including every USB device (which is most of them these days), = SDIO > and others. USB has to be covered for this to be sensible. It looks as if you try to solve a different problem than some of us. = Maybe this is the reason why you get the impression that nobody is listening to your = proposal (but that seems to be common for this topic - I have the impression that nobody is listening to my proposals... so don't mind). I can only talk for my device where I just want to be able to write a = driver that gets access to a low level physical UART within a SoC (a little = abstracted by uart_port) to directly talk to a device connected to such an UART for = reasons I have explained plenty of times. Other devices may have orthogonal needs (or suspected needs) and hence a single solution may not fit everybody. =20 >=20 > Your changes also don't work because serial uart drivers are not = obliged > to use any of the uart buffering helpers and particularly on the rx = side > many do not do so and the performance hit would be too high. The SoC I have, is using it. >=20 > It's been explained how to make it work with tty_port, every tty is a > dynamic file handle life time object bound to a tty_port. Every tty = has a > tty_port, every tty driver has a tty_port. >=20 > Alan BR, Nikolaus