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: <28DDAF2B-2341-403B-80D8-DA0A63F51FF1@holtmann.org> Date: Thu, 18 Aug 2016 13:02:41 +0200 Cc: Rob Herring , Greg Kroah-Hartman , 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: References: <20160818011445.22726-1-robh@kernel.org> <118926C8-F4D0-41F5-B6A8-690E0312F3FB@goldelico.com> <28DDAF2B-2341-403B-80D8-DA0A63F51FF1@holtmann.org> To: Marcel Holtmann Sender: linux-serial-owner@vger.kernel.org List-ID: Hi Marcel, > Am 18.08.2016 um 12:49 schrieb Marcel Holtmann : >=20 > Hi Nikolaus, >=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 >>> There have been several attempts to improve support, but they suffer = from >>> still being tied into the tty layer and/or abusing the platform bus. = This >>> is a prototype to show creating a proper UART bus for UART devices. = It is >>> tied into the serial core (really struct uart_port) below the tty = layer >>> in order to use existing serial drivers. >>>=20 >>> This is functional with minimal testing using the loopback driver = and >>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the = slave >>> device). It still needs lots of work and polish. >>>=20 >>> TODOs: >>> - Figure out the port locking. mutex plus spinlock plus refcounting? = I'm >>> hoping all that complexity is from the tty layer and not needed = here. >>> - Split out the controller for uart_ports into separate driver. Do = we see >>> a need for controller drivers that are not standard serial drivers? >>> - Implement/test the removal paths >>> - Fix the receive callbacks for more than character at a time (i.e. = DMA) >>> - Need better receive buffering than just a simple circular buffer = or >>> perhaps a different receive interface (e.g. direct to client = buffer)? >>> - Test with other UART drivers >>> - Convert a real driver/line discipline over to UART bus. >>>=20 >>> 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). >>=20 >> Some quick comments (can't do any real life tests in the next weeks) = from my (biased) view: >>=20 >> * tieing the solution into uart_port is the same as we had done. The = difference seems to >> me that you completely bypass serial_core (and tty) while we want to = integrate it with standard tty operation. >>=20 >> We have tapped the tty layer only because it can not be 100% avoided = if we use serial_core. >>=20 >> * one feedback I had received was that there may be uart device = drivers not using serial_core. I am not sure if your approach addresses = that. >>=20 >> * what I don't see is how we can implement our GPS device power = control driver: >> - the device should still present itself as a tty device (so that cat = /dev/ttyO1 reports NMEA records) and should >> not be completely hidden from user space or represented by a new = interface type invented just for this device >> (while the majority of other GPS receivers are still simple tty = devices). >> - how we can detect that the device is sending data to the UART while = no user space process has the uart port open >> i.e. when does the driver know when to start/stop the UART. >=20 > I am actually not convinced that GPS should be represented as = /dev/ttyS0 or similar TTY. It think they deserve their own driver = exposing them as simple character devices. That way we can have a proper = DEVTYPE and userspace can find them correctly. We can also annotate them = if needed for special settings. Yes, we can. But AFAIK no user space GPS client is expecting to have a = new DEVTYPE. I have several different GPS devices. One is by bluetooth. So I get a = /dev/tty through hci. Another one has an USB cable. I get a /dev/tty = through some USB serial converter. A third one is integrated in a 4G = modem which provides a /dev/ttyACM port. So I always get something which = looks like a /dev/tty... Seems to be pretty standard. Yes it would be nice to have a /dev/gps2 device. And how do you want to control if the gps device should send records = with cr / lf (INLCR, IGNCR)? Can you use tcsetattr? >=20 > Such a driver then can also take care of the power control on open() = and close(). As it should be done in the first place. Yes it could do that as well. > And then we can also remove the RFKILL hacks for GPS devices as well. = For example that is what Intel and Broadcom Bluetooth devices do now. = The power control is hooked into hciconfig hci0 up/down. >=20 > Regards >=20 > Marcel >=20 BR, Nikolaus