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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Aug 2016 12:49:47 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	"H. Nikolaus Schaller" <hns@...delico.com>
Cc:	Rob Herring <robh@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.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

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.

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. 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.

Regards

Marcel