linux-kernel - Re: [RFC PATCH 0/3] UART slave device bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Aug 2016 12:55:21 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	"H. Nikolaus Schaller" <hns@...delico.com>,
	Rob Herring <robh@...nel.org>, Jiri Slaby <jslaby@...e.com>,
	Sebastian Reichel <sre@...nel.org>,
	Pavel Machek <pavel@....cz>,
	Peter Hurley <peter@...leysoftware.com>,
	NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] UART slave device bus

On Thu, Aug 18, 2016 at 12:49:47PM +0200, Marcel Holtmann wrote:
> Hi Nikolaus,
> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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.
> >> 
> >> 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).
> > 
> > Some quick comments (can't do any real life tests in the next weeks) from my (biased) view:
> > 
> > * 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.
> > 
> >   We have tapped the tty layer only because it can not be 100% avoided if we use serial_core.
> > 
> > * 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.
> > 
> > * 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.
> 
> 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.

I would _love_ to see that happen, but what about the GPS line
discipline that we have today?  How would that match up with a char
device driver?

thanks,

greg k-h