mbox series

[v2,0/9] Serial slave device bus

Message ID 20170116225436.17505-1-robh@kernel.org
Headers show
Series Serial slave device bus | expand

Message

Rob Herring (Arm) Jan. 16, 2017, 10:54 p.m. UTC
Here's a new version of the serdev bus support with all the review
feedback so far incorporated. I've left it named serdev for now pending
any further votes one way or the other, but I did rename the sysfs visible
portions to "serial".

There's still some discussion about what to do with devices that pass thru
data to userspace unmodified like GPS and could still use tty device for
the data path. IMO, we should treat this as a separate problem following
this series. Drivers we want to convert to serdev and already in the
kernel don't need this functionality.

I need a SoB from Alan on his patch 2 and would like review from Alan and/or
Peter on the locking in patch 5.

I have hacked up versions of the BT ldisc and TI ST drivers moved over to
use the serdev bus. I have BT working on the HiKey board which has TI BT.
With the serdev bus support, it eliminates the need for the TI userspace
UIM daemon. I've made some progress cleaning up the TI-ST into proper
patches and also got it working at 3Mbps.

Changelog is in individual patches. Previous version is here[1]. This
series and the mentioned drivers can be found here[2].

Rob

[1] https://lkml.org/lkml/2017/1/6/411
[2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git serial-bus-v3


Alan Cox (1):
  tty_port: allow a port to be opened with a tty that has no file handle

Rob Herring (8):
  tty: move the non-file related parts of tty_release to new
    tty_release_struct
  tty_port: make tty_port_register_device wrap
    tty_port_register_device_attr
  tty: constify tty_ldisc_receive_buf buffer pointer
  tty_port: Add port client functions
  dt/bindings: Add a serial/UART attached device binding
  serdev: Introduce new bus for serial attached devices
  serdev: add a tty port controller driver
  tty_port: register tty ports with serdev bus

 .../devicetree/bindings/serial/slave-device.txt    |  36 ++
 MAINTAINERS                                        |   8 +
 drivers/char/Kconfig                               |   1 +
 drivers/tty/Makefile                               |   1 +
 drivers/tty/serdev/Kconfig                         |  16 +
 drivers/tty/serdev/Makefile                        |   5 +
 drivers/tty/serdev/core.c                          | 421 +++++++++++++++++++++
 drivers/tty/serdev/serdev-ttyport.c                | 240 ++++++++++++
 drivers/tty/tty_buffer.c                           |  19 +-
 drivers/tty/tty_io.c                               |  52 ++-
 drivers/tty/tty_port.c                             |  58 ++-
 include/linux/serdev.h                             | 234 ++++++++++++
 include/linux/tty.h                                |  12 +-
 13 files changed, 1062 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/slave-device.txt
 create mode 100644 drivers/tty/serdev/Kconfig
 create mode 100644 drivers/tty/serdev/Makefile
 create mode 100644 drivers/tty/serdev/core.c
 create mode 100644 drivers/tty/serdev/serdev-ttyport.c
 create mode 100644 include/linux/serdev.h

--
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Greg Kroah-Hartman Jan. 20, 2017, 1:44 p.m. UTC | #1
On Mon, Jan 16, 2017 at 04:54:27PM -0600, Rob Herring wrote:
> Here's a new version of the serdev bus support with all the review

> feedback so far incorporated. I've left it named serdev for now pending

> any further votes one way or the other, but I did rename the sysfs visible

> portions to "serial".

> 

> There's still some discussion about what to do with devices that pass thru

> data to userspace unmodified like GPS and could still use tty device for

> the data path. IMO, we should treat this as a separate problem following

> this series. Drivers we want to convert to serdev and already in the

> kernel don't need this functionality.

> 

> I need a SoB from Alan on his patch 2 and would like review from Alan and/or

> Peter on the locking in patch 5.


I've applied the first 4 patches now, can you respin this and hopefully
Peter will review that patch, as I'd like him to before taking it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marcel Holtmann Jan. 20, 2017, 2:14 p.m. UTC | #2
Hi Linus,

>> There's still some discussion about what to do with devices that pass thru

>> data to userspace unmodified like GPS and could still use tty device for

>> the data path. IMO, we should treat this as a separate problem following

>> this series. Drivers we want to convert to serdev and already in the

>> kernel don't need this functionality.

> 

> In my simple opinion GPSes shound live in drivers/iio/gps simply by

> usecase association: streaming out a series of accelerometer readings

> periodically through IIOs chardevs and other data about the physical

> world is not any different from the GPS usecase that give you a stream

> of coordinates on where on this planet you are.

> 

> The fact that vendors like to defer GPS processing to userspace because

> it is considered "secret sauce" is not the concern of the kernel community,

> though problems like that in general is the great tragedy of our time.

> 

> It would be fun to see a pure, reverse-engineered GPS driver in IIO.


except for the pure NMEA devices. Which are pretty much defined as terminal devices using RS422 and 4800 baud. For anything non-NMEA, I would agree that using IIO might be a good option. So instead of a GPS subsystem, might just have a GPS class / type in the IIO subsystem.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html