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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
