Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1464881 > unrolled thread

[RFC PATCH 0/3] UART slave device bus

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 03:20 +0200
    Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 12:30 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 12:40 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 16:00 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 15:20 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:50 +0200
          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
    Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 12:40 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 12:50 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
          Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:50 +0200
        Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:00 +0200
        Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:30 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:10 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:30 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:50 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 14:00 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:20 +0200
          Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
              Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:20 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 15:10 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:00 +0200
        Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:10 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
            Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:10 +0200
    Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:10 +0200
    Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-18 15:20 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-19 03:50 +0200
    Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:30 +0200
      Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:10 +0200
      Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:30 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 04:50 +0200
        Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:40 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 17:40 +0200
    Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 03:30 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:40 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 07:30 +0200
          Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 09:40 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 10:00 +0200
              Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 20:00 +0200
                Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 22:30 +0200
                Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:40 +0200
                  Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
                    Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:50 +0200
                      Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-22 23:30 +0200
                        Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 23:50 +0200
                        Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:50 +0200
                          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
                            Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:20 +0200
                          Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-23 09:30 +0200
            Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
              Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 19:50 +0200
                Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:30 +0200
                  Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
                    Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-21 19:20 +0200
                      Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 20:30 +0200
                        Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 11:20 +0200
                          Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 11:40 +0200
          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 16:50 +0200
    Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 14:40 +0200
      Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 15:50 +0200
        Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 17:30 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 17:30 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 18:00 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 18:50 +0200
            Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:10 +0200
              Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:40 +0200
                Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:20 +0200
                  Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 23:40 +0200
                    Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-23 00:10 +0200
                      Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
                        Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 02:00 +0200
                          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 02:20 +0200
                            Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 03:00 +0200
                              Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-24 16:00 +0200
                                Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-24 16:40 +0200
                            Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-23 13:50 +0200
                      Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:10 +0200
              Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 19:40 +0200
                Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:10 +0200
                  Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 00:10 +0200
                    Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:20 +0200
          Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:20 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:10 +0200
              Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:10 +0200
                Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:20 +0200
                  Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:50 +0200
              Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 00:20 +0200
            Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-24 14:30 +0200
          Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 23:20 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#1465179

Hi!

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

./drivers/usb/serial/garmin_gps.c ?

Hmm, some cleanups would be welcome there... plus it would be good to
know what is its interface to userland... it is not easily apparent
from the code.

Actually, having some kind of common support for GPSes in the kernel
would be nice. (Chardev that spits NMEA data?) For example N900 GPS is
connected over network (phonet) interface, with userland driver
translating custom protocol into NMEA. Not very nice from "kernel
should provide hardware abstraction" point of view.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1465186

> Am 18.08.2016 um 13:10 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> 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?
> 
> ./drivers/usb/serial/garmin_gps.c ?
> 
> Hmm, some cleanups would be welcome there... plus it would be good to
> know what is its interface to userland... it is not easily apparent
> from the code.
> 
> Actually, having some kind of common support for GPSes in the kernel
> would be nice. (Chardev that spits NMEA data?

Yes and no. How do you apply tcsetattr to such a device? More or less
by implementing another tty stack?

> ) For example N900 GPS is
> connected over network (phonet) interface, with userland driver
> translating custom protocol into NMEA. Not very nice from "kernel
> should provide hardware abstraction" point of view.

Indeed. In such a case the translation should be done in the kernel.
But it is not necessary for devices that already provide NEMA over UART.
Still user-space should be able to tcsetattr how it wants to see the records
(mainly CR/LF translations).

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1465196

Hi Nikolaus,

>>>> 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?
>> 
>> ./drivers/usb/serial/garmin_gps.c ?
>> 
>> Hmm, some cleanups would be welcome there... plus it would be good to
>> know what is its interface to userland... it is not easily apparent
>> from the code.
>> 
>> Actually, having some kind of common support for GPSes in the kernel
>> would be nice. (Chardev that spits NMEA data?
> 
> Yes and no. How do you apply tcsetattr to such a device? More or less
> by implementing another tty stack?
> 
>> ) For example N900 GPS is
>> connected over network (phonet) interface, with userland driver
>> translating custom protocol into NMEA. Not very nice from "kernel
>> should provide hardware abstraction" point of view.
> 
> Indeed. In such a case the translation should be done in the kernel.
> But it is not necessary for devices that already provide NEMA over UART.
> Still user-space should be able to tcsetattr how it wants to see the records
> (mainly CR/LF translations).

I disagree here. NMEA is a standard and the kernel should just enforce framing of NMEA sentences. It makes no difference what the CR/LF is. Userspace gets full sentences.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1465214

> Am 18.08.2016 um 13:49 schrieb Marcel Holtmann <marcel@holtmann.org>:
> 
> Hi Nikolaus,
> 
>>>>> 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?
>>> 
>>> ./drivers/usb/serial/garmin_gps.c ?
>>> 
>>> Hmm, some cleanups would be welcome there... plus it would be good to
>>> know what is its interface to userland... it is not easily apparent
>>> from the code.
>>> 
>>> Actually, having some kind of common support for GPSes in the kernel
>>> would be nice. (Chardev that spits NMEA data?
>> 
>> Yes and no. How do you apply tcsetattr to such a device? More or less
>> by implementing another tty stack?
>> 
>>> ) For example N900 GPS is
>>> connected over network (phonet) interface, with userland driver
>>> translating custom protocol into NMEA. Not very nice from "kernel
>>> should provide hardware abstraction" point of view.
>> 
>> Indeed. In such a case the translation should be done in the kernel.
>> But it is not necessary for devices that already provide NEMA over UART.
>> Still user-space should be able to tcsetattr how it wants to see the records
>> (mainly CR/LF translations).
> 
> I disagree here. NMEA is a standard and the kernel should just enforce framing of NMEA sentences.

AFAIR, NMEA was originally sort of a serial bus going through a ship. Where masters (a gps receiver)
can send records with position and speed data and clients (e.g. an auto-pilot) can receive them and
process their actions and send control commands to a motor / winding engine. But I would have to do
more research about this.

> It makes no difference what the CR/LF is. Userspace gets full sentences.

NMEA defines that devices connected to the NMEA source receive characters and not sentences.

For example an NMEA record defines a checksum. Should that also be exposed to user space or hidden?
How should checksum errors be reported or handled by the kernel?

I would agree if we want to write an abstract "position in geospace" driver/subsystem which reports
the position on surface and height and speed and direction. Then we can hide everything in the kernel.
But this would no longer send sentences to user space but cooked coordinates. More like iio data.

And next issue: how should we handle GPS devices with a bidirectional interface where sending
some special command sequence over the UART switches to SIRF or some other proprietary
mode? Then, the driver (ans Linux) can't squeeze that into NMEA sentences any more. By
doing this in the kernel we make it more inflexible.

Puh, when digging into this topic it becomes more and more complex and we are making it more
complex than it is currently working.

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1465194

Hi Pavel,

>>> 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?
> 
> ./drivers/usb/serial/garmin_gps.c ?
> 
> Hmm, some cleanups would be welcome there... plus it would be good to
> know what is its interface to userland... it is not easily apparent
> from the code.

however that driver is not a line discipline. That is just an USB driver. But I agree if we create a GPS driver framework / subsystem, then this one should be converted into using it.

> Actually, having some kind of common support for GPSes in the kernel
> would be nice. (Chardev that spits NMEA data?) For example N900 GPS is
> connected over network (phonet) interface, with userland driver
> translating custom protocol into NMEA. Not very nice from "kernel
> should provide hardware abstraction" point of view.

I agree that if we just had a dedicated GPS NMEA char device, then that would be great. However we might just add an additional /dev/unmea like /dev/uinput, /dev/uhid, /dev/vhci. It could be used for unit testing and also hardware where the protocol is in userspace in the first. Like the mentioned QMI or some Intel AT command based modem. We would then just convert oFono to create the /dev/unmea device for us. The advantage is that then even userspace NMEA device are part of the device tree and enumerated by udev.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1465249

Hi!

> >>> 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?
> > 
> > ./drivers/usb/serial/garmin_gps.c ?
> > 
> > Hmm, some cleanups would be welcome there... plus it would be good to
> > know what is its interface to userland... it is not easily apparent
> > from the code.
> 
> however that driver is not a line discipline. That is just an USB driver. But I agree if we create a GPS driver framework / subsystem, then this one should be converted into using it.
>

Aha.

> > Actually, having some kind of common support for GPSes in the kernel
> > would be nice. (Chardev that spits NMEA data?) For example N900 GPS is
> > connected over network (phonet) interface, with userland driver
> > translating custom protocol into NMEA. Not very nice from "kernel
> > should provide hardware abstraction" point of view.
> 
> I agree that if we just had a dedicated GPS NMEA char device, then that would be great. However we might just add an additional /dev/unmea like /dev/uinput, /dev/uhid, /dev/vhci. It could be used for unit testing and also hardware where the protocol is in userspace in the first. Like the mentioned QMI or some Intel AT command based modem. We would then just convert oFono to create the /dev/unmea device for us. The advantage is that then even userspace NMEA device are part of the device tree and enumerated by udev.
>

Yep, that would	make sense, one	day. (Another discussion is if NMEA is
the right protocol to use for kernel<->user interface, esr has some
rather good reasons to believe it is not. But that, too, can wait...)

Anyway, whatever works for bluetooth is likely to work for future gps
subsystem, so we should be ok here. And having support for serial
devices (not pretending they are platform) is a good step forward.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1465155

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

[toc] | [prev] | [next] | [standalone]

#1465169

Hi Marcel,

> Am 18.08.2016 um 12:49 schrieb Marcel Holtmann <marcel@holtmann.org>:
> 
> 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.

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?

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

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1465198

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.
> 
> Yes, we can. But AFAIK no user space GPS client is expecting to have a new DEVTYPE.

but we can fix userspace clients to deal with 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.

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.

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.

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.

However honestly, my main focus would be to get Bluetooth UARTs integrated natively without line discipline before I would worry about GPS.

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

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.

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. Something similar could be done for GPS NMEA. Anyway, I am just pointing out ideas here. We do not have the UART bus upstream yet.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1465206

Hi Marcel,

> Am 18.08.2016 um 13:41 schrieb Marcel Holtmann <marcel@holtmann.org>:
> 
> 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.
>> 
>> Yes, we can. But AFAIK no user space GPS client is expecting to have a new DEVTYPE.
> 
> but we can fix userspace clients to deal with 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.
> 
> 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.
> 
> 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.
> 
> 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...

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

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

[toc] | [prev] | [next] | [standalone]

#1465160

Hi!

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

Looks good to me.

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1465305

On Thu, Aug 18, 2016 at 3:14 AM, Rob Herring <robh@kernel.org> wrote:

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

Freaking *awesome* Rob, this really really needs to happen.
I'm very happy that you're driving this.

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

I have Bluetooth (HCI) over UART on the Nomadik and Ux500,
both with DMA support for the PL011 too. So I hope to be able
to utilize this.

(The HCI transport is then used for GPS, FM radio and whatnot
but that is another issue.)

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1465843

Hi Linus,

>> 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.
> 
> Freaking *awesome* Rob, this really really needs to happen.
> I'm very happy that you're driving this.
> 
>> 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.
> 
> I have Bluetooth (HCI) over UART on the Nomadik and Ux500,
> both with DMA support for the PL011 too. So I hope to be able
> to utilize this.
> 
> (The HCI transport is then used for GPS, FM radio and whatnot
> but that is another issue.)

that is something we can already solve via regmap. We have started work on Intel LnP which also includes a FM radio chip where registers/interrupts are exposed via HCI commands/events. So fundamentally the Bluetooth HCI device would expose the GPS and FM radio nodes via regmap.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1465527

On Wed, 17 Aug 2016 20:14:42 -0500
Rob Herring <robh@kernel.org> wrote:

This was proposed ages ago and the point clearly made that

a) the idea doesn't work because uarts are not required to use the uart
layer and even those that do sometimes only use half of it

b) that you should use the tty_port abstraction

So instead of just waiting some months and recycling the proposals it's
unfortunate that no listening and reworking was done.

https://lkml.org/lkml/2016/1/18/177

So I'm giving this a large neon flashing NAK, because none of the
problems have been addressed.

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

For most platforms it works very nicely and out of the box. The only
real issue I have actually seen is the bandwidth issue from early tty
based 3G modems. That's not hard to fix with some tty buffer changes.
Basically you need a tty port pointer that is atomic exchangable and
points either to the usual tty queue logic or to a 'fastpath' handler
which just gets thrown a block of bytes and told to use them or lose them
- which is the interface the non n_tty ldiscs want anyway. That's exactly
what you would need to fix to support in kernel stuff as well. The tty
queue mechanism for devices that can receive in blocks just becomes a
fastpath.

There are some disgusting Android turds floating around out of tree where
people use things like userspace GPIO line control but you won't fix most
of those anyway because they are generally being used for user
space modules including dumb GPS where the US government rules won't allow
them to be open sourced anyway.

> - Split out the controller for uart_ports into separate driver. Do we see
>   a need for controller drivers that are not standard serial drivers?

As I told you over six months ago uart_port is not the correct
abstraction. You need to be working at the tty_port layer. The original
design of tty_port was indeed partly to push towards being able to have a
serial interface that is in use but not open to user space. The rather
nice rework that the maintainers have done to put the buffers in the
tty_port takes it closer still.

Plenty of the classic serial port interfaces also don't use the UART
layer including every USB device (which is most of them these days), SDIO
and others. USB has to be covered for this to be sensible.

Your changes also don't work because serial uart drivers are not obliged
to use any of the uart buffering helpers and particularly on the rx side
many do not do so and the performance hit would be too high.

It's been explained how to make it work with tty_port, every tty is a
dynamic file handle life time object bound to a tty_port. Every tty has a
tty_port, every tty driver has a tty_port.

Alan

[toc] | [prev] | [next] | [standalone]

#1465705

> Am 18.08.2016 um 17:38 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
> 
>>> Your changes also don't work because serial uart drivers are not obliged
>>> to use any of the uart buffering helpers and particularly on the rx side
>>> many do not do so and the performance hit would be too high.  
>> 
>> The SoC I have, is using it.
> 
> The Linux kernel does generalised implementations. Yes it may work on
> your board but it doesn't work for everything.

It needs to work only on boards with a SoC UART. Not with a tty over
USB or something else. This is the generalisation I see. Any SoC with
uart_port driver support (and as far as I see many are).

> It's the difference
> between doing it properly and hacking your board to work.

Agreed. But solving problems nobody really has is overengineering.

Especially if the generalised implementation that is being discussed
(tty_port) does not even solve the problem. Or only in a very clumsy
and difficult way. In such a case a generalisation seems to be the
wrong approach to me.

And we should start to accept that we mix up different requirements
and try a single solution for almost everyone we can imagine (which
isn't bad initially, but can prohibit to find a solution at all) except the
real use case that is on the table. That is why I always come back
to the practical problem to implement my driver and want to know
how it can be done.

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1465788

Hi Alan,

> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
> 
> On Wed, 17 Aug 2016 20:14:42 -0500
> Rob Herring <robh@kernel.org> wrote:
> 
> This was proposed ages ago and the point clearly made that
> 
> a) the idea doesn't work because uarts are not required to use the uart
> layer and even those that do sometimes only use half of it
> 
> b) that you should use the tty_port abstraction
> 
> So instead of just waiting some months and recycling the proposals it's
> unfortunate that no listening and reworking was done.
> 
> https://lkml.org/lkml/2016/1/18/177
> 
> So I'm giving this a large neon flashing NAK, because none of the
> problems have been addressed.
> 
>> 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.
> 
> For most platforms it works very nicely and out of the box. The only
> real issue I have actually seen is the bandwidth issue from early tty
> based 3G modems. That's not hard to fix with some tty buffer changes.
> Basically you need a tty port pointer that is atomic exchangable and
> points either to the usual tty queue logic or to a 'fastpath' handler
> which just gets thrown a block of bytes and told to use them or lose them
> - which is the interface the non n_tty ldiscs want anyway. That's exactly
> what you would need to fix to support in kernel stuff as well. The tty
> queue mechanism for devices that can receive in blocks just becomes a
> fastpath.
> 
> There are some disgusting Android turds floating around out of tree where
> people use things like userspace GPIO line control but you won't fix most
> of those anyway because they are generally being used for user
> space modules including dumb GPS where the US government rules won't allow
> them to be open sourced anyway.
> 
>> - Split out the controller for uart_ports into separate driver. Do we see
>>  a need for controller drivers that are not standard serial drivers?
> 
> As I told you over six months ago uart_port is not the correct
> abstraction. You need to be working at the tty_port layer. The original
> design of tty_port was indeed partly to push towards being able to have a
> serial interface that is in use but not open to user space. The rather
> nice rework that the maintainers have done to put the buffers in the
> tty_port takes it closer still.
> 
> Plenty of the classic serial port interfaces also don't use the UART
> layer including every USB device (which is most of them these days), SDIO
> and others. USB has to be covered for this to be sensible.

It looks as if you try to solve a different problem than some of us. Maybe this is
the reason why you get the impression that nobody is listening to your proposal
(but that seems to be common for this topic - I have the impression that
nobody is listening to my proposals... so don't mind).

I can only talk for my device where I just want to be able to write a driver that
gets access to a low level physical UART within a SoC (a little abstracted
by uart_port) to directly talk to a device connected to such an UART for reasons
I have explained plenty of times.

Other devices may have orthogonal needs (or suspected needs) and hence
a single solution may not fit everybody.
 
> 
> Your changes also don't work because serial uart drivers are not obliged
> to use any of the uart buffering helpers and particularly on the rx side
> many do not do so and the performance hit would be too high.

The SoC I have, is using it.

> 
> It's been explained how to make it work with tty_port, every tty is a
> dynamic file handle life time object bound to a tty_port. Every tty has a
> tty_port, every tty driver has a tty_port.

> 
> Alan

BR, Nikolaus

[toc] | [prev] | [next] | [standalone]

#1465942

On Thu, Aug 18, 2016 at 9:25 AM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> On Wed, 17 Aug 2016 20:14:42 -0500
> Rob Herring <robh@kernel.org> wrote:
>
> This was proposed ages ago and the point clearly made that
>
> a) the idea doesn't work because uarts are not required to use the uart
> layer and even those that do sometimes only use half of it
>
> b) that you should use the tty_port abstraction
>
> So instead of just waiting some months and recycling the proposals it's
> unfortunate that no listening and reworking was done.
>
> https://lkml.org/lkml/2016/1/18/177
>
> So I'm giving this a large neon flashing NAK, because none of the
> problems have been addressed.
>
>> 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.
>
> For most platforms it works very nicely and out of the box. The only
> real issue I have actually seen is the bandwidth issue from early tty
> based 3G modems. That's not hard to fix with some tty buffer changes.
> Basically you need a tty port pointer that is atomic exchangable and
> points either to the usual tty queue logic or to a 'fastpath' handler
> which just gets thrown a block of bytes and told to use them or lose them
> - which is the interface the non n_tty ldiscs want anyway. That's exactly
> what you would need to fix to support in kernel stuff as well. The tty
> queue mechanism for devices that can receive in blocks just becomes a
> fastpath.
>
> There are some disgusting Android turds floating around out of tree where
> people use things like userspace GPIO line control but you won't fix most
> of those anyway because they are generally being used for user
> space modules including dumb GPS where the US government rules won't allow
> them to be open sourced anyway.
>
>> - Split out the controller for uart_ports into separate driver. Do we see
>>   a need for controller drivers that are not standard serial drivers?
>
> As I told you over six months ago uart_port is not the correct
> abstraction. You need to be working at the tty_port layer. The original
> design of tty_port was indeed partly to push towards being able to have a
> serial interface that is in use but not open to user space. The rather
> nice rework that the maintainers have done to put the buffers in the
> tty_port takes it closer still.
>
> Plenty of the classic serial port interfaces also don't use the UART
> layer including every USB device (which is most of them these days), SDIO
> and others. USB has to be covered for this to be sensible.

Plenty? Really?. Lets break down the tty drivers in the kernel which
don't use uart_port.

Consoles/Debug:
arch/alpha/kernel/srmcons.c
arch/cris/arch-v10/kernel/debugport.c
arch/ia64/hp/sim/simserial.c
arch/m68k/emu/nfcon.c
arch/parisc/kernel/pdc_cons.c
arch/xtensa/platforms/iss/console.c
drivers/char/ttyprintk.c
drivers/tty/bfin_jtag_comm.c
drivers/tty/ehv_bytechan.c
drivers/tty/hvc/hvc_console.c
drivers/tty/hvc/hvcs.c
drivers/tty/hvc/hvsi.c
drivers/tty/serial/kgdb_nmi.c
drivers/tty/mips_ejtag_fdc.c
drivers/tty/metag_da.c
drivers/misc/pti.c

SDIO UART:
drivers/mmc/card/sdio_uart.c

S390 (don't think BT dongle is a use case):
drivers/s390/char/con3215.c
drivers/s390/char/sclp_tty.c
drivers/s390/char/sclp_vt220.c
drivers/s390/char/tty3270.c

Firewire serial:
drivers/staging/fwserial/fwserial.c

Amiga serial:
drivers/tty/amiserial.c

Android emulator:
drivers/tty/goldfish.c

Multi-port serial boards (standard connectors and not embedded with
sideband signals):
drivers/tty/cyclades.c
drivers/tty/isicom.c
drivers/tty/moxa.c
drivers/tty/mxser.c
drivers/tty/rocket.c
drivers/tty/synclink.c
drivers/tty/synclink_gt.c
drivers/tty/synclinkmp.c
drivers/char/pcmcia/synclink_cs.c
drivers/ipack/devices/ipoctal.c
drivers/staging/dgnc/dgnc_tty.c

Modems (already a slave device):
drivers/isdn/capi/capi.c
drivers/isdn/gigaset/interface.c
drivers/isdn/i4l/isdn_tty.c
drivers/tty/nozomi.c
drivers/tty/ipwireless/tty.c
drivers/tty/serial/ifx6x60.c
drivers/net/usb/hso.c
drivers/staging/gdm724x/gdm_tty.c
drivers/usb/class/cdc-acm.c

USB:
drivers/usb/gadget/function/u_serial.c
drivers/usb/serial/usb-serial.c

Virtual devices:
net/bluetooth/rfcomm/tty.c
net/irda/ircomm/ircomm_tty.c

Could be updated to use uart_port:
drivers/tty/serial/crisv10.c

The only ones here I see us caring about are USB and SDIO as you
mentioned. SDIO suffers from the same embedded problem we are trying
to solve here with UART slave devices. The devices are always soldered
down with sideband GPIOs and power. If there is any device, then it's
ultimately going to need its own SDIO driver, not the the generic
sdio-uart. So the generic sdio-uart is pretty useless except maybe for
a discreet SDIO card which I haven't seen in at least 10 years or in a
product for 15 years.

That leaves usb-serial. If the current support is good enough, then
that will continue to work (as you said elsewhere, can't break
userspace). If someone really wants to do USB serial and wire in
sideband controls, then we could provide a host driver that hooks into
usb_serial_port.

> Your changes also don't work because serial uart drivers are not obliged
> to use any of the uart buffering helpers and particularly on the rx side
> many do not do so and the performance hit would be too high.

Do you have an example?

The only uart buffering helper is for the receive side with
uart_insert_char. Sure, a character at a time is not efficient, but
that is easily rectified. Or do you mean something else?

Rob

[toc] | [prev] | [next] | [standalone]

#1466306

> Plenty? Really?. Lets break down the tty drivers in the kernel which
> don't use uart_port.


That's the wrong list - those that use uart port but don't always use the
uart_insert_char helpers will also break. So you can start by adding

8250		
amba-pl011
atmel_serial
bcm63xx_uart
bfin_sport
bfin_sport_uart
crisv10
efm32-uart
etraxfs-uart
fsl_lpuart
icom
ifx6060
imx
ioc3_serial
ioc4_serial
kgdb_nmi
lantiq
lpc32xx_hs
m32r_sio
men_z135_uart
meson_uart
mpc52xx_uart
mps2-uart
mpsc
msm_serial
mux
mvebu-uart
mxs-auart
pch_uart
pic32_uart
pmac_zilog
samsung
serial-tegra
sh-sci
sirfsoc_uart
sn_console
sunhv
sunsab
sunsu
sunzilog
tilegx
timbuart
uartline
ucc_uart
vt8500_serial

Some of those you could handle reasonably easily as they are byte
oriented, however if your code takes any longer in clock terms to run on
the low end devices you'll be a regression. Some of these don't use
uart_insert_char because the cost of that tips them over the available
clock times.

Quite a few of them however use tty_insert_flip_string or the other
buffer handling functions, particularly when doing DMA so you would have
to do significant work to fit them into some 'byte callback' type model.

This again is why it needs to be at the tty_port layer. The receive paths
can be cleanly intercepted at the point you'd push to an ldisc - the
driver level code on rx doesn't care if you have a tty attached, because
bytes arrived whether the tty is open or not.

In the case of 8250 all the recent x86 class systems which have things
like bluetooth attached via the LPSS are using 8250 and with DMA so your
interface simply won't work.

There are also some other slight complications when you look at real
world implementations. Android devices tend to keep the GPS in userspace
so most of then can't use some magic extra API but just drive GPIO lines
via the sysfs GPIO interface. Most Android doesn't use the kernel BT
stack either.

Quite a few Android and other embedded devices also do power management by
shutting off the UART, routing the rx line to an edge triggered GPIO and
on the interrupt flipping the UART back on and losing the first byte,
picking a protocol that can recover from it.

Your model doesn't I think cover that, although I am somewhat at a loss as
to how to do that nicely!

> Consoles/Debug:
> arch/alpha/kernel/srmcons.c
> arch/cris/arch-v10/kernel/debugport.c
> arch/ia64/hp/sim/simserial.c
> arch/m68k/emu/nfcon.c
> arch/parisc/kernel/pdc_cons.c
> arch/xtensa/platforms/iss/console.c
> drivers/char/ttyprintk.c
> drivers/tty/bfin_jtag_comm.c
> drivers/tty/ehv_bytechan.c
> drivers/tty/hvc/hvc_console.c
> drivers/tty/hvc/hvcs.c
> drivers/tty/hvc/hvsi.c
> drivers/tty/serial/kgdb_nmi.c
> drivers/tty/mips_ejtag_fdc.c
> drivers/tty/metag_da.c
> drivers/misc/pti.c

You could attach a dongle of some sort to a supposed console/debug port
and people do that kind of crap on embedded devices to save a few cents.
The ones above look fine though.

> SDIO UART:
> drivers/mmc/card/sdio_uart.c

This is an area that definitely needs covering, except that the way the
power works may be completely opaque to the OS if it's something like an
ACPI OpRegion controlling it.

> S390 (don't think BT dongle is a use case):
> drivers/s390/char/con3215.c
> drivers/s390/char/sclp_tty.c
> drivers/s390/char/sclp_vt220.c
> drivers/s390/char/tty3270.c

I would prefer to think of the fact BT on S390 *would* work as a test of
the API being right.

> Firewire serial:
> drivers/staging/fwserial/fwserial.c
> 
> Amiga serial:
> drivers/tty/amiserial.c
> 
> Android emulator:
> drivers/tty/goldfish.c
> 
> Multi-port serial boards (standard connectors and not embedded with
> sideband signals):
> drivers/tty/cyclades.c
> drivers/tty/isicom.c
> drivers/tty/moxa.c
> drivers/tty/mxser.c
> drivers/tty/rocket.c
> drivers/tty/synclink.c
> drivers/tty/synclink_gt.c
> drivers/tty/synclinkmp.c
> drivers/char/pcmcia/synclink_cs.c
> drivers/ipack/devices/ipoctal.c
> drivers/staging/dgnc/dgnc_tty.c
> 
> Modems (already a slave device):
> drivers/isdn/capi/capi.c
> drivers/isdn/gigaset/interface.c
> drivers/isdn/i4l/isdn_tty.c
> drivers/tty/nozomi.c
> drivers/tty/ipwireless/tty.c
> drivers/tty/serial/ifx6x60.c
> drivers/net/usb/hso.c
> drivers/staging/gdm724x/gdm_tty.c
> drivers/usb/class/cdc-acm.c
> 
> USB:
> drivers/usb/gadget/function/u_serial.c
> drivers/usb/serial/usb-serial.c

Your list for USB is misleading. Just about every USB serial port uses
usb-serial as a midlayer so you are basically saying "Let's make a giant
weird special case". Just listing usb-serial would be like just listing
serial-core and saying you only support one device.

> That leaves usb-serial. If the current support is good enough, then
> that will continue to work (as you said elsewhere, can't break
> userspace). If someone really wants to do USB serial and wire in
> sideband controls, then we could provide a host driver that hooks into
> usb_serial_port.

Alreay happens when people are doing strange things nailing legacy
devices to HSIC/SSIC. USB is not just a pile of external cables that
always have the plug upside down, it has specifications for directly
routed low voltage on PCB consumers and bridges.

The fact you want two different host drivers and two APIs for the same
object connected to two identical interfaces but on different busses
should be raising alarm bells. We don't have different interfaces for
NE2000 over PCI or NE2000 over ISA !

> > Your changes also don't work because serial uart drivers are not obliged
> > to use any of the uart buffering helpers and particularly on the rx side
> > many do not do so and the performance hit would be too high.  
> 
> Do you have an example?
> 
> The only uart buffering helper is for the receive side with
> uart_insert_char. Sure, a character at a time is not efficient, but
> that is easily rectified. Or do you mean something else?

Not all of the uart drivers even use uart_insert_char. It's a convenience
helper that most of them bypass because it's completely useless if you
are doing things like DMA. Even the modern x86 PC UARTs don't and can't
use uart_insert_char and that basically is a killer.

Alan

[toc] | [prev] | [next] | [standalone]

#1466500

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, Aug 19, 2016 at 12:38:08PM +0100, One Thousand Gnomes wrote:
> There are also some other slight complications when you look at
> real world implementations. Android devices tend to keep the GPS
> in userspace so most of them can't use some magic extra API but
> just drive GPIO lines via the sysfs GPIO interface. Most Android
> doesn't use the kernel BT stack either.

I don't get the reasoning for this one. What has it to do with
an in-kernel API? People are also using libusb or doing i2c/spi
from userspace. Nevertheless we have an in-kernel API for those.

> Quite a few Android and other embedded devices also do power
> management by shutting off the UART, routing the rx line to an
> edge triggered GPIO and on the interrupt flipping the UART back
> on and losing the first byte, picking a protocol that can recover
> from it.
>
> Your model doesn't I think cover that, although I am somewhat at a
> loss as to how to do that nicely!

On OMAP this is supported by the serial driver via runtime PM and
wakeirq.

Actually my usecase for the API (bluetooth on Nokia N900, N950, N9),
there is an extra GPIO for the power management (high = uart
should be able to receive sth., low = uart can sleep). For this
I can just disable the wakeirq in the UART by not adding it to DT
and instead runtime manage it from the uart_dev child device.

While we are on that topic: The omap-serial driver does not enable
runtime PM by default, since it does not know if the remote side is
ok with loosing the first byte(s). One is expected to enable it
using the sysfs API.
But I think it should be safe to enable runtime PM for the serial
device in uart_dev_connect(). Due to the child device it will still
be kept disabled, except when the uart_dev also implements runtime_pm.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1465794

[Multipart message — attachments visible in raw view] — view raw

Hi Rob,

Thanks for going forward and implementing this. I also started,
but was far from a functional state.

On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote:
> 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).

I had a look at the uart_dev API:

int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow);
int uart_dev_connect(struct uart_device *udev);

  The flow control configuration should be done separately. e.g.:
  uart_dev_flow_control(struct uart_device *udev, bool enable);

int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count);
int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count);

  UART communication does not have to be host-initiated, so this
  API requires polling. Either some function similar to poll in
  userspace is needed, or it should be implemented as callback.
  
-- Sebastian

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | linux.kernel

csiph-web