Hi Marcel,

Am 18.08.2016 um 13:41 schrieb Marcel Holtmann [off-list ref]:
=20
Hi Nikolaus,
=20

quoted

quoted

quoted

quoted

Currently, devices attached via a UART are not well supported in =

the

quoted

quoted

quoted

quoted

kernel. The problem is the device support is done in tty line =

disciplines,

quoted

quoted

quoted

quoted

various platform drivers to handle some sideband, and in userspace =

with

quoted

quoted

quoted

quoted

utilities such as hciattach.
=20
There have been several attempts to improve support, but they =

suffer from

quoted

quoted

quoted

quoted

still being tied into the tty layer and/or abusing the platform =

bus. This

quoted

quoted

quoted

quoted

is a prototype to show creating a proper UART bus for UART =

devices. It is

quoted

quoted

quoted

quoted

tied into the serial core (really struct uart_port) below the tty =

layer

quoted

quoted

quoted

quoted

in order to use existing serial drivers.
=20
This is functional with minimal testing using the loopback driver =

and

quoted

quoted

quoted

quoted

pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the =

slave

quoted

quoted

quoted

quoted

device). It still needs lots of work and polish.
=20
TODOs:
- Figure out the port locking. mutex plus spinlock plus =

refcounting? I'm

quoted

quoted

quoted

quoted

hoping all that complexity is from the tty layer and not needed =

here.

quoted

quoted

quoted

quoted

- Split out the controller for uart_ports into separate driver. Do =

we see

quoted

quoted

quoted

quoted

a need for controller drivers that are not standard serial =

drivers?

quoted

quoted

quoted

quoted

- Implement/test the removal paths
- Fix the receive callbacks for more than character at a time =

(i.e. DMA)

quoted

quoted

quoted

quoted

- Need better receive buffering than just a simple circular buffer =

or

quoted

quoted

quoted

quoted

perhaps a different receive interface (e.g. direct to client =

buffer)?

quoted

quoted

quoted

quoted

- 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

quoted

quoted

quoted

quoted

general direction and structure (the interface with the existing =

serial

quoted

quoted

quoted

quoted

drivers in particular).

=20
Some quick comments (can't do any real life tests in the next =

weeks) from my (biased) view:

quoted

quoted

quoted

=20
* tieing the solution into uart_port is the same as we had done. =

The difference seems to

quoted

quoted

quoted

me that you completely bypass serial_core (and tty) while we want =

to integrate it with standard tty operation.

quoted

quoted

quoted

=20
We have tapped the tty layer only because it can not be 100% =

avoided if we use serial_core.

quoted

quoted

quoted

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

quoted

quoted

quoted

=20
* what I don't see is how we can implement our GPS device power =

control driver:

quoted

quoted

quoted

- the device should still present itself as a tty device (so that =

cat /dev/ttyO1 reports NMEA records) and should

quoted

quoted

quoted

not be completely hidden from user space or represented by a new =

interface type invented just for this device

quoted

quoted

quoted

(while the majority of other GPS receivers are still simple tty =

devices).

quoted

quoted

quoted

- how we can detect that the device is sending data to the UART =

while no user space process has the uart port open

quoted

quoted

quoted

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.

quoted

=20
Yes, we can. But AFAIK no user space GPS client is expecting to have =

a new DEVTYPE.

=20
but we can fix userspace clients to deal with DEVTYPE.
=20

quoted

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.

=20
Actually for Bluetooth RFCOMM it would be a lot better to use the =

RFCOMM socket instead of the TTY emulation. However that said, Bluetooth =
RFCOMM is already split in a way that you can have either a socket or a =
TTY emulation. There is nothing stopping us from adding a GPS emulation =
and with that natively hooking it up to a future GPS driver. I mean why =
not have a GPS subsystem that allows for that. I know this is future =
talk, but it can be done.

=20
Same goes for the USB GPS devices that use a serial converter. If they =

use proper VID:PID or some sort of identification, we can have a =
dedicated USB driver that matches it to a GPS device. At the end of the =
day, the only difference for the usb-serial driver is if it registers a =
TTY or a future GPS device.

=20
The 4G modem ones are a bit funky. Not all of them expose a ttyACM =

port btw. Some of them have the NMEA via Qualcomm QMI or some other =
channel. So inside oFono we have abstracted that into a file descriptor =
so that power control etc. is handled by oFono. Since you need to use =
the telephony stack to control the GPS state. But again here, there is =
nothing stopping us from moving parts of QMI into the kernel. We have =
done that for the Nokia ISI and the ST-Ericsson CAIF already.

Yes, agreed. But here we try to optimize the kernel and a specific =
variant of user space code. I am not sure if we should do that.

However honestly, my main focus would be to get Bluetooth UARTs =

integrated natively without line discipline before I would worry about =
GPS.

Well, for me it is the opposite. I have no problem with running existing =
user space code like hciattach on a hci tty port. Even with older OS =
versions.
But I can't control the power of this GPS device with a standard user =
space mechanism. So for my GPS it either needs new kernel support to =
work with old and existing user space code or needs new user space code =
in projects I don't even know the name...

=20

quoted

Yes it would be nice to have a /dev/gps2 device.
=20
And how do you want to control if the gps device should send records =

with cr / lf (INLCR, IGNCR)? Can you use tcsetattr?

=20
That needs to be seen. In general NMEA does not need it. However there =

is more than NMEA out there. Maybe it would need to focus on NMEA GPS =
anyway. As said above, oFono just hands out the NMEA sentences for QMI =
devices via file descriptor. So I am not sure we need to control that =
much.

Well, you must have some agreement between the device internals and the =
user space read() processor if CR LF are to be treated as a single line =
or two lines (one empty) or whatever. It can be controlled either by =
user space (ignore the empty line) or by tcsetattr. Is that something =
the kernel should enforce in this case? Or should the user space tell =
the kernel by tcsetattr? I really don't know..

=20
I mean with Bluetooth we have done a bunch of extra framing =

enforcement so that a read() only returns a full frame. So that =
userspace applications have it a lot easier and don't have to worry =
about byte-byte reading.

Indeed for Bluetooth it is sort of a low level network stack driver.

Something similar could be done for GPS NMEA.

Yes it could, but I am not sure if Linux should solve this at all.

Anyway, I am just pointing out ideas here. We do not have the UART bus =

upstream yet.

Indeed, we need an agreeable solution for that first.

Maybe the main problem is that too many unsolved ideas are tried to be =
squeezed into a single solution fits everyone.

BR,
Nikolaus