[PATCH 0/4] UART slave device support - version 4

[PATCH 0/4] UART slave device support - version 4

[NeilBrown]

Hi all,
 here is version 4 of my "UART slave device" patch set, previously
 known as "tty slave devices".

 The most obvious change is the name.  I realized that this isn't
 really about "tty"s at all - it is about UARTs.

 When a device is connected to a UART via RS-232 (or similar), there
 is a DTR line that can be used for power management, and other "modem
 control" lines.

 On an embedded board, it is very likely that there is no "DTR", and
 any power management need to be done using some completely separate
 mechanism.

 So these "slaves" are really just for devices permanently attached to
 UARTs without a full "RS-232" (or similar) connection.  The driver
 does all the extra control beyond Tx/Rx.

 The core serial code now "initializes" the "tty device" but may not
 "add" it.
 If it successfully finds a slave device, it gives the tty device to
 the slave.  If not, it calls "device_add()" itself.

 The slave device is responsible for adding the tty device when it is
 ready.

 There are two things that I'm not entirely happy with.

 Firstly there is the "uart_slave_activate()" call in tty_init_dev().
 Possibly this belongs more in tty_driver_install_tty(), but it is a
 bit out-off-place in either.
 To make it really clean I think I would need to create my own
 "tty_driver" which mirrors the one supplied by the uart but has a
 few little modification.  But that seems like a lot of clumsy work
 for very little gain.

 Secondly, between the creation of the slave device and the binding of
 a driver to it I'm holding an extra reference to the "tty_driver".
 This is to prevent calls to destruct_tty_driver().
 destruct_tty_driver() will unregister all the tty devices.
 But it cannot get at the uart_slave devices.
 I'm not at all sure I have the device unregistering side of things
 right.  As I was writing the code I imagined that I could arrange it
 so that then the tty was unregistered, that would drop the last ref
 on the slave and it would go away... I don't think that is right
 after all.  So that bit needs more work.

 Should the slave devices only be removed when the "uart_slave_core"
 modules is removed?

 And I'd very much like comment on the changed to be uart-based
 rather than tty-based.

 I've tested this set and it seems to work ... except that something
 is sadly broken with bluetooth support in 4.1-rc1 so I've only really
 tested the GPS driver.  I guess it is time to rebase to -rc3.


Thanks,
NeilBrown

---

NeilBrown (4):
      TTY: use class_find_device to find port in uart_suspend/resume.
      TTY: split tty_register_device_attr into 'initialize' and 'add' parts.
      TTY: add support for uart_slave devices.
      tty/slaves: add a driver to power on/off UART attached devices.


 .../bindings/uart_slave/wi2wi,w2cbw003.txt         |   19 +
 .../bindings/uart_slave/wi2wi,w2sg0004.txt         |   37 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 
 drivers/tty/serial/Kconfig                         |    1 
 drivers/tty/serial/Makefile                        |    2 
 drivers/tty/serial/serial_core.c                   |   30 +
 drivers/tty/serial/slave/Kconfig                   |   21 +
 drivers/tty/serial/slave/Makefile                  |    3 
 drivers/tty/serial/slave/serial-power-manager.c    |  510 ++++++++++++++++++++
 drivers/tty/serial/slave/uart_slave_core.c         |  168 +++++++
 drivers/tty/tty_io.c                               |  111 +++-
 drivers/tty/tty_port.c                             |   24 +
 include/linux/tty.h                                |   10 
 include/linux/uart_slave.h                         |   29 +
 14 files changed, 918 insertions(+), 48 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/uart_slave/wi2wi,w2cbw003.txt
 create mode 100644 Documentation/devicetree/bindings/uart_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/serial/slave/Kconfig
 create mode 100644 drivers/tty/serial/slave/Makefile
 create mode 100644 drivers/tty/serial/slave/serial-power-manager.c
 create mode 100644 drivers/tty/serial/slave/uart_slave_core.c
 create mode 100644 include/linux/uart_slave.h

--
Signature

[PATCH 1/4] TTY: use class_find_device to find port in uart_suspend/resume.

[NeilBrown]

uart_{suspend,resume}_port search the children of a uart device
to find a particular tty device.
This requires all the ttys to be direct children of the uart.

A future patch will allow a 'tty_slave' to intervene between
the port and the uart, voiding this requirement.

So change to use class_find_device.  This is made possible by
exporting a "tty_find_device" from tty_io.c.

This new "tty_find_device" is very similar to the existing
tty_get_device() which has a single caller, so discard
tty_get_device() and just use tty_find_device().

Signed-off-by: NeilBrown <neil@brown.name>
---
 drivers/tty/serial/serial_core.c |   21 ++++++++-------------
 drivers/tty/tty_io.c             |    6 +++---
 include/linux/tty.h              |    1 +
 3 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index eb5b03be9dfd..3ea16f524e89 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2005,26 +2005,19 @@ struct uart_match {
 	struct uart_driver *driver;
 };
 
-static int serial_match_port(struct device *dev, void *data)
-{
-	struct uart_match *match = data;
-	struct tty_driver *tty_drv = match->driver->tty_driver;
-	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
-		match->port->line;
-
-	return dev->devt == devt; /* Actually, only one tty per port */
-}
 
 int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
 {
 	struct uart_state *state = drv->state + uport->line;
 	struct tty_port *port = &state->port;
 	struct device *tty_dev;
-	struct uart_match match = {uport, drv};
+	dev_t devt = MKDEV(drv->tty_driver->major,
+			   drv->tty_driver->minor_start) +
+		uport->line;
 
 	mutex_lock(&port->mutex);
 
-	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+	tty_dev = tty_find_device(devt);
 	if (device_may_wakeup(tty_dev)) {
 		if (!enable_irq_wake(uport->irq))
 			uport->irq_wake = 1;
@@ -2084,12 +2077,14 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
 	struct uart_state *state = drv->state + uport->line;
 	struct tty_port *port = &state->port;
 	struct device *tty_dev;
-	struct uart_match match = {uport, drv};
 	struct ktermios termios;
+	dev_t devt = MKDEV(drv->tty_driver->major,
+			   drv->tty_driver->minor_start) +
+		uport->line;
 
 	mutex_lock(&port->mutex);
 
-	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+	tty_dev = tty_find_device(devt);
 	if (!uport->suspended && device_may_wakeup(tty_dev)) {
 		if (uport->irq_wake) {
 			disable_irq_wake(uport->irq);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index e5695467598f..ccb99b772965 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3077,11 +3077,11 @@ static int dev_match_devt(struct device *dev, const void *data)
 }
 
 /* Must put_device() after it's unused! */
-static struct device *tty_get_device(struct tty_struct *tty)
+struct device *tty_find_device(dev_t devt)
 {
-	dev_t devt = tty_devnum(tty);
 	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
 }
+EXPORT_SYMBOL(tty_find_device);
 
 
 /**
@@ -3123,7 +3123,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver *driver, int idx)
 	tty->ops = driver->ops;
 	tty->index = idx;
 	tty_line_name(driver, idx, tty->name);
-	tty->dev = tty_get_device(tty);
+	tty->dev = tty_find_device(tty_devnum(tty));
 
 	return tty;
 }
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 358a337af598..04d5f1213700 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
 extern int tty_hung_up_p(struct file *filp);
 extern void do_SAK(struct tty_struct *tty);
 extern void __do_SAK(struct tty_struct *tty);
+extern struct device *tty_find_device(dev_t devt);
 extern void no_tty(void);
 extern void tty_flush_to_ldisc(struct tty_struct *tty);
 extern void tty_buffer_free_all(struct tty_port *port);

[PATCH 2/4] TTY: split tty_register_device_attr into 'initialize' and 'add' parts.

[NeilBrown]

This provides seperate
  tty_device_initialize_attr()
and
  tty_device_add_attr()

similar to device_initialize() and device_add().

Similiarly tty_port_initialize_device_attr() is added to match
tty_port_register_device_attr().

It will allow a client to separate initalization and adding of the
device.

Signed-off-by: NeilBrown <neil@brown.name>
---
 drivers/tty/tty_io.c   |  102 +++++++++++++++++++++++++++++++++---------------
 drivers/tty/tty_port.c |   24 +++++++++++
 include/linux/tty.h    |    9 ++++
 3 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index ccb99b772965..83ca25b9c2da 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3205,8 +3205,29 @@ static void tty_device_create_release(struct device *dev)
 	kfree(dev);
 }
 
+int tty_device_add(struct tty_driver *driver, struct device *dev)
+{
+	int retval;
+	bool cdev = false;
+	int index = dev->devt - MKDEV(driver->major,
+				      driver->minor_start);
+
+	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
+		retval = tty_cdev_add(driver, dev->devt, index, 1);
+		if (retval)
+			return retval;
+		cdev = true;
+	}
+	retval = device_add(dev);
+	if (retval == 0)
+		return 0;
+	if (cdev)
+		cdev_del(&driver->cdevs[index]);
+	return retval;
+}
+EXPORT_SYMBOL(tty_device_add);
 /**
- *	tty_register_device_attr - register a tty device
+ *	tty_device_initialize_attr - initialize a tty device, but don't 'add'
  *	@driver: the tty driver that describes the tty device
  *	@index: the index in the tty driver for this tty device
  *	@device: a struct device that is associated with this tty device.
@@ -3218,23 +3239,19 @@ static void tty_device_create_release(struct device *dev)
  *	Returns a pointer to the struct device for this tty device
  *	(or ERR_PTR(-EFOO) on error).
  *
- *	This call is required to be made to register an individual tty device
- *	if the tty driver's flags have the TTY_DRIVER_DYNAMIC_DEV bit set.  If
- *	that bit is not set, this function should not be called by a tty
- *	driver.
+ *	tty_device_add() must be called after this call returns successfully
+ *	before the device will be full registered and available.
  *
  *	Locking: ??
  */
-struct device *tty_register_device_attr(struct tty_driver *driver,
-				   unsigned index, struct device *device,
-				   void *drvdata,
-				   const struct attribute_group **attr_grp)
+struct device *tty_device_initialize_attr(struct tty_driver *driver,
+					  unsigned index, struct device *device,
+					  void *drvdata,
+					  const struct attribute_group **attr_grp)
 {
 	char name[64];
 	dev_t devt = MKDEV(driver->major, driver->minor_start) + index;
 	struct device *dev = NULL;
-	int retval = -ENODEV;
-	bool cdev = false;
 
 	if (index >= driver->num) {
 		printk(KERN_ERR "Attempt to register invalid tty line number "
@@ -3247,19 +3264,11 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
 	else
 		tty_line_name(driver, index, name);
 
-	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
-		retval = tty_cdev_add(driver, devt, index, 1);
-		if (retval)
-			goto error;
-		cdev = true;
-	}
-
 	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
-	if (!dev) {
-		retval = -ENOMEM;
-		goto error;
-	}
+	if (!dev)
+		return ERR_PTR(-ENOMEM);
 
+	device_initialize(dev);
 	dev->devt = devt;
 	dev->class = tty_class;
 	dev->parent = device;
@@ -3268,17 +3277,48 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
 	dev->groups = attr_grp;
 	dev_set_drvdata(dev, drvdata);
 
-	retval = device_register(dev);
-	if (retval)
-		goto error;
-
 	return dev;
+}
+EXPORT_SYMBOL_GPL(tty_device_initialize_attr);
 
-error:
-	put_device(dev);
-	if (cdev)
-		cdev_del(&driver->cdevs[index]);
-	return ERR_PTR(retval);
+/**
+ *	tty_register_device_attr - register a tty device
+ *	@driver: the tty driver that describes the tty device
+ *	@index: the index in the tty driver for this tty device
+ *	@device: a struct device that is associated with this tty device.
+ *		This field is optional, if there is no known struct device
+ *		for this tty device it can be set to NULL safely.
+ *	@drvdata: Driver data to be set to device.
+ *	@attr_grp: Attribute group to be set on device.
+ *
+ *	Returns a pointer to the struct device for this tty device
+ *	(or ERR_PTR(-EFOO) on error).
+ *
+ *	This call is required to be made to register an individual tty device
+ *	if the tty driver's flags have the TTY_DRIVER_DYNAMIC_DEV bit set.  If
+ *	that bit is not set, this function should not be called by a tty
+ *	driver.
+ *
+ *	Locking: ??
+ */
+struct device *tty_register_device_attr(struct tty_driver *driver,
+				   unsigned index, struct device *device,
+				   void *drvdata,
+				   const struct attribute_group **attr_grp)
+{
+	struct device *dev;
+	int ret;
+
+	dev = tty_device_initialize_attr(driver, index, device,
+					 drvdata, attr_grp);
+	if (IS_ERR(dev))
+		return dev;
+	ret = tty_device_add(driver, dev);
+	if (ret) {
+		put_device(dev);
+		return ERR_PTR(ret);
+	}
+	return dev;
 }
 EXPORT_SYMBOL_GPL(tty_register_device_attr);
 
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 40b31835f80b..f4145c0f1f45 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -97,6 +97,30 @@ struct device *tty_port_register_device_attr(struct tty_port *port,
 }
 EXPORT_SYMBOL_GPL(tty_port_register_device_attr);
 
+/**
+ * tty_port_initialize_device_attr - initialize tty device
+ * @port: tty_port of the device
+ * @driver: tty_driver for this device
+ * @index: index of the tty
+ * @device: parent if exists, otherwise NULL
+ * @drvdata: Driver data to be set to device.
+ * @attr_grp: Attribute group to be set on device.
+ *
+ * It is the same as tty_initialize_device_attr except the provided @port is
+ * linked to a concrete tty specified by @index. Use this or tty_port_install
+ * (or both). Call tty_port_link_device as a last resort.
+ */
+struct device *tty_port_initialize_device_attr(struct tty_port *port,
+		struct tty_driver *driver, unsigned index,
+		struct device *device, void *drvdata,
+		const struct attribute_group **attr_grp)
+{
+	tty_port_link_device(port, driver, index);
+	return tty_device_initialize_attr(driver, index, device, drvdata,
+					  attr_grp);
+}
+EXPORT_SYMBOL_GPL(tty_port_initialize_device_attr);
+
 int tty_port_alloc_xmit_buf(struct tty_port *port)
 {
 	/* We may sleep in get_zeroed_page() */
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 04d5f1213700..1b371ba9ed09 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -436,6 +436,11 @@ extern struct device *tty_register_device_attr(struct tty_driver *driver,
 				unsigned index, struct device *device,
 				void *drvdata,
 				const struct attribute_group **attr_grp);
+extern struct device *tty_device_initialize_attr(struct tty_driver *driver,
+				unsigned index, struct device *device,
+				void *drvdata,
+				const struct attribute_group **attr_grp);
+extern int tty_device_add(struct tty_driver *driver, struct device *dev);
 extern void tty_unregister_device(struct tty_driver *driver, unsigned index);
 extern int tty_read_raw_data(struct tty_struct *tty, unsigned char *bufp,
 			     int buflen);
@@ -534,6 +539,10 @@ extern struct device *tty_port_register_device_attr(struct tty_port *port,
 		struct tty_driver *driver, unsigned index,
 		struct device *device, void *drvdata,
 		const struct attribute_group **attr_grp);
+extern struct device *tty_port_initialize_device_attr(struct tty_port *port,
+		struct tty_driver *driver, unsigned index,
+		struct device *device, void *drvdata,
+		const struct attribute_group **attr_grp);
 extern int tty_port_alloc_xmit_buf(struct tty_port *port);
 extern void tty_port_free_xmit_buf(struct tty_port *port);
 extern void tty_port_destroy(struct tty_port *port);

[PATCH 4/4] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

If a platform has a particular device permanently attached to a UART,
there may be out-of-band signaling necessary to power the device
on and off.

This driver controls that signalling for a number of different devices.
It can
 - enable/disable a regulator
 - toggle a GPIO
 - register an 'rfkill' which can force the device to be off.

When the rfkill is absent or unblocked, the device will be on when the
associated tty device is open, and closed otherwise.

Signed-off-by: NeilBrown <neil@brown.name>
---
 .../bindings/uart_slave/wi2wi,w2cbw003.txt         |   19 +
 .../bindings/uart_slave/wi2wi,w2sg0004.txt         |   37 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 
 drivers/tty/serial/slave/Kconfig                   |   15 +
 drivers/tty/serial/slave/Makefile                  |    1 
 drivers/tty/serial/slave/serial-power-manager.c    |  510 ++++++++++++++++++++
 6 files changed, 583 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uart_slave/wi2wi,w2cbw003.txt
 create mode 100644 Documentation/devicetree/bindings/uart_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/serial/slave/serial-power-manager.c

diff --git a/Documentation/devicetree/bindings/uart_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/uart_slave/wi2wi,w2cbw003.txt
new file mode 100644
index 000000000000..cfe6ee5e01e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/uart_slave/wi2wi,w2cbw003.txt
@@ -0,0 +1,19 @@
+wi2wi bluetooth module
+
+This is accessed via a serial port and is largely controlled via that
+link.  Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2cbw003"
+- vdd-supply: regulator used to power the device.
+
+The node for this device must be the child of a UART.
+
+Example:
+
+&uart1 {
+       bluetooth {
+               compatible = "wi2wi,w2cbw003";
+               vdd-supply = <&vaux4>;
+       };
+};
diff --git a/Documentation/devicetree/bindings/uart_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/uart_slave/wi2wi,w2sg0004.txt
new file mode 100644
index 000000000000..6bcf3006c1a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/uart_slave/wi2wi,w2sg0004.txt
@@ -0,0 +1,37 @@
+wi2wi GPS device
+
+This is accessed via a serial port and is largely controlled via that
+link.  Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2sg0004"
+- gpios: gpio used to toggle 'on/off' pin
+- interrupts: interrupt generated by RX pin when device
+      should be off
+
+Optional properties:
+- vdd-supply: regulator used to power antenna
+- pinctrl: "default", "off"
+      if "off" setting is provided it is imposed when device should
+      be off.  This can route the RX pin to a GPIO interrupt.
+
+The w2sg0004 uses a pin-toggle both to power-on and to
+power-off, so the driver needs to detect what state it is in.
+It does this by detecting characters on the RX line.
+When it should be off, these can optionally be detected by a GPIO.
+
+The node for this device must be the child of a UART.
+
+Example:
+&uart2 {
+       gps {
+               compatible = "wi2iw,w2sg0004";
+               vdd-supply = <&vsim>;
+               gpios = <&gpio5 17 0>; /* GPIO_145 */
+               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
+               /* When off, switch RX to be an interrupt */
+               pinctrl-names = "default", "off";
+               pinctrl-0 = <&uart2_pins>;
+               pinctrl-1 = <&uart2_pins_rx_gpio>;
+       };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 80339192c93e..45c703a3b29d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -202,6 +202,7 @@ variscite	Variscite Ltd.
 via	VIA Technologies, Inc.
 virtio	Virtual I/O Device Specification, developed by the OASIS consortium
 voipac	Voipac Technologies s.r.o.
+wi2wi	wi2wi Inc.  http://www.wi2wi.com/
 winbond Winbond Electronics corp.
 wlf	Wolfson Microelectronics
 wm	Wondermedia Technologies, Inc.
diff --git a/drivers/tty/serial/slave/Kconfig b/drivers/tty/serial/slave/Kconfig
index 6620e78b763e..46285d8895b7 100644
--- a/drivers/tty/serial/slave/Kconfig
+++ b/drivers/tty/serial/slave/Kconfig
@@ -4,3 +4,18 @@ menuconfig UART_SLAVE
 	help
 	 Devices which attach via a uart, but need extra
 	 driver support for power management etc.
+
+if UART_SLAVE
+
+config SERIAL_POWER_MANAGER
+	tristate "Power Management controller for serial-attached devices"
+	default n
+	help
+	 Some devices permanently attached via a UART can benefit from
+	 being power-managed when the tty device is opened or closed.
+	 This driver can support several such devices with simple
+	 power requirements such as enabling a regulator.
+
+	 If in doubt, say 'N'
+
+endif
diff --git a/drivers/tty/serial/slave/Makefile b/drivers/tty/serial/slave/Makefile
index aac8697fa406..5d9b3d373138 100644
--- a/drivers/tty/serial/slave/Makefile
+++ b/drivers/tty/serial/slave/Makefile
@@ -1,2 +1,3 @@
 
 obj-$(CONFIG_UART_SLAVE) += uart_slave_core.o
+obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
diff --git a/drivers/tty/serial/slave/serial-power-manager.c b/drivers/tty/serial/slave/serial-power-manager.c
new file mode 100644
index 000000000000..81b8f909fd3a
--- /dev/null
+++ b/drivers/tty/serial/slave/serial-power-manager.c
@@ -0,0 +1,510 @@
+/*
+ * Serial-power-manager
+ * uart-slave device that intercepts open/close events on the tty,
+ * and turns power on/off for the device which is connected.
+ *
+ * Currently supported devices:
+ *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
+ *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
+ *
+ * When appropriate, an RFKILL will be registered which
+ * can power-down the device even when it is open.
+ *
+ * Device can be turned on either by
+ *  - enabling a regulator.  Disable to turn off
+ *  - toggling a GPIO.  Toggle again to turn off.  This requires
+ *     that we know the current state.  It is assumed to be 'off'
+ *     at boot, however if an interrupt can be generated when on,
+ *     such as by connecting RX to a GPIO, that can be used to detect
+ *     if the device is on when it should be off.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/regulator/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/tty.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/of_irq.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/rfkill.h>
+
+#include <linux/uart_slave.h>
+
+/* This is used for testing. Setting this module parameter
+ * will simulate booting with the device "on"
+ */
+static bool toggle_on_probe = false;
+module_param(toggle_on_probe, bool, 0);
+MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
+
+struct spm_config {
+	int	rfkill_type;		/* type of rfkill to register */
+	int	toggle_time;		/* msec to pulse GPIO for on/off */
+	int	toggle_gap;		/* minimum msecs between toggles */
+	bool	off_in_suspend;
+}
+	simple_config = {
+		.off_in_suspend = true,
+	},
+	w2sg_config = {
+		.rfkill_type = RFKILL_TYPE_GPS,
+		.toggle_time = 10,
+		.toggle_gap = 500,
+		.off_in_suspend = true,
+	};
+
+const static struct of_device_id spm_dt_ids[] = {
+       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
+       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
+       {}
+};
+
+struct spm_data {
+	const struct spm_config *config;
+	struct gpio_desc *gpiod;
+	int		irq;	/* irq line from RX pin when pinctrl
+				 * set to 'idle' */
+	struct regulator *reg;
+
+	unsigned long	toggle_time;
+	unsigned long	toggle_gap;
+	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
+	unsigned long	backoff;	/* jiffies since last_toggle when
+					 * we try again
+					 */
+	enum {Idle, Down, Up} state;	/* state-machine state. */
+
+	int		open_cnt;
+	bool		requested, is_on;
+	bool		suspended;
+	bool		reg_enabled;
+
+	struct pinctrl	*pins;
+	struct pinctrl_state *pins_off;
+
+	struct delayed_work work;
+	spinlock_t	lock;
+	struct device	*dev;
+
+	struct rfkill	*rfkill;
+
+	int (*old_open)(struct tty_struct * tty, struct file * filp);
+	void (*old_close)(struct tty_struct * tty, struct file * filp);
+
+};
+
+/* When a device is powered on/off by toggling a GPIO we perform
+ * all the toggling via a workqueue to ensure only one toggle happens
+ * at a time and to allow easy timing.
+ * This is managed as a state machine which transitions
+ *  Idle -> Down -> Up -> Idle
+ * The GPIO is held down for toggle_time and then up for toggle_time,
+ * and then we assume the device has changed state.
+ * We never toggle until at least toggle_gap has passed since the
+ * last toggle.
+ */
+static void toggle_work(struct work_struct *work)
+{
+	struct spm_data *data = container_of(
+		work, struct spm_data, work.work);
+
+	if (data->gpiod == NULL)
+		return;
+
+	spin_lock_irq(&data->lock);
+	switch (data->state) {
+	case Up:
+		data->state = Idle;
+		if (data->requested == data->is_on)
+			break;
+		if (!data->requested)
+			/* Assume it is off unless activity is detected */
+			break;
+		/* Try again in a while unless we get some activity */
+		dev_dbg(data->dev, "Wait %dusec until retry\n",
+			jiffies_to_msecs(data->backoff));
+		schedule_delayed_work(&data->work, data->backoff);
+		break;
+	case Idle:
+		if (data->requested == data->is_on)
+			break;
+
+		/* Time to toggle */
+		dev_dbg(data->dev, "Starting toggle to turn %s\n",
+			data->requested ? "on" : "off");
+		data->state = Down;
+		spin_unlock_irq(&data->lock);
+		gpiod_set_value_cansleep(data->gpiod, 1);
+		schedule_delayed_work(&data->work, data->toggle_time);
+
+		return;
+
+	case Down:
+		data->state = Up;
+		data->last_toggle = jiffies;
+		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
+			data->is_on ? "off" : "on");
+		data->is_on = ! data->is_on;
+		spin_unlock_irq(&data->lock);
+
+		gpiod_set_value_cansleep(data->gpiod, 0);
+		schedule_delayed_work(&data->work, data->toggle_time);
+
+		return;
+	}
+	spin_unlock_irq(&data->lock);
+}
+
+static irqreturn_t spm_isr(int irq, void *dev_id)
+{
+	struct spm_data *data = dev_id;
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (!data->requested && !data->is_on && data->state == Idle &&
+	    time_after(jiffies, data->last_toggle + data->backoff)) {
+		data->is_on = 1;
+		data->backoff *= 2;
+		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
+		if (!data->suspended)
+			schedule_delayed_work(&data->work, 0);
+	}
+	spin_unlock_irqrestore(&data->lock, flags);
+	return IRQ_HANDLED;
+}
+
+static void spm_on(struct spm_data *data)
+{
+	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
+		unsigned long flags;
+
+		if (!data->reg_enabled &&
+		    data->reg &&
+		    regulator_enable(data->reg) == 0)
+			data->reg_enabled = true;
+
+		spin_lock_irqsave(&data->lock, flags);
+		if (!data->requested) {
+			dev_dbg(data->dev, "TTY open - turn device on\n");
+			data->requested = true;
+			data->backoff = data->toggle_gap;
+			if (data->irq > 0) {
+				disable_irq(data->irq);
+				pinctrl_pm_select_default_state(data->dev);
+			}
+			if (!data->suspended && data->state == Idle)
+				schedule_delayed_work(&data->work, 0);
+		}
+		spin_unlock_irqrestore(&data->lock, flags);
+	}
+}
+
+static int spm_open(struct tty_struct *tty, struct file *filp)
+{
+	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
+
+	data->open_cnt++;
+	spm_on(data);
+	if (data->old_open)
+		return data->old_open(tty, filp);
+	return -ENODEV;
+}
+
+static void spm_off(struct spm_data *data)
+{
+	unsigned long flags;
+
+	if (data->reg && data->reg_enabled)
+		if (regulator_disable(data->reg) == 0)
+			data->reg_enabled = false;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (data->requested) {
+		data->requested = false;
+		data->backoff = data->toggle_gap;
+		if (data->pins_off) {
+			pinctrl_select_state(data->pins,
+					     data->pins_off);
+			enable_irq(data->irq);
+		}
+		if (!data->suspended && data->state == Idle)
+			schedule_delayed_work(&data->work, 0);
+	}
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static void spm_close(struct tty_struct *tty, struct file *filp)
+{
+	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
+
+	data->open_cnt--;
+	if (!data->open_cnt) {
+		dev_dbg(data->dev, "TTY closed - turn device off\n");
+		spm_off(data);
+	}
+
+	if (data->old_close)
+		data->old_close(tty, filp);
+}
+
+static int spm_rfkill_set_block(void *vdata, bool blocked)
+{
+	struct spm_data *data = vdata;
+
+	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
+	if (blocked)
+		spm_off(data);
+
+	if (!blocked &&
+	    data->open_cnt)
+		spm_on(data);
+
+	return 0;
+}
+
+static struct rfkill_ops spm_rfkill_ops = {
+	.set_block = spm_rfkill_set_block,
+};
+
+static int spm_suspend(struct device *dev)
+{
+	/* Ignore incoming data and just turn device off.
+	 * we cannot really wait for a separate thread to
+	 * do things, so we disable that and do it all
+	 * here
+	 */
+	struct spm_data *data = dev_get_drvdata(dev);
+
+	spin_lock_irq(&data->lock);
+	data->suspended = true;
+	spin_unlock_irq(&data->lock);
+	if (!data->config->off_in_suspend)
+		return 0;
+
+	if (data->gpiod) {
+
+		cancel_delayed_work_sync(&data->work);
+		if (data->state == Down) {
+			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
+			msleep(data->config->toggle_time);
+			gpiod_set_value_cansleep(data->gpiod, 0);
+			data->last_toggle = jiffies;
+			data->is_on = !data->is_on;
+			data->state = Up;
+		}
+		if (data->state == Up) {
+			msleep(data->config->toggle_time);
+			data->state = Idle;
+		}
+		if (data->is_on) {
+			dev_dbg(data->dev, "Suspending while device on: toggling\n");
+			gpiod_set_value_cansleep(data->gpiod, 1);
+			msleep(data->config->toggle_time);
+			gpiod_set_value_cansleep(data->gpiod, 0);
+			data->is_on = 0;
+		}
+	}
+
+	if (data->reg && data->reg_enabled)
+		if (regulator_disable(data->reg) == 0)
+			data->reg_enabled = false;
+
+	return 0;
+}
+
+static int spm_resume(struct device *dev)
+{
+	struct spm_data *data = dev_get_drvdata(dev);
+
+	spin_lock_irq(&data->lock);
+	data->suspended = false;
+	spin_unlock_irq(&data->lock);
+	schedule_delayed_work(&data->work, 0);
+
+	if (data->open_cnt &&
+	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
+		if (!data->reg_enabled &&
+		    data->reg &&
+		    regulator_enable(data->reg) == 0)
+			data->reg_enabled = true;
+	}
+	return 0;
+}
+
+static const struct dev_pm_ops spm_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
+};
+
+static int spm_probe(struct device *dev)
+{
+	struct uart_slave *slave = container_of(dev, struct uart_slave, dev);
+	struct spm_data *data;
+	struct regulator *reg;
+	int err;
+	const struct of_device_id *id;
+	const char *name;
+
+	if (dev->parent == NULL)
+		return -ENODEV;
+
+	id = of_match_device(spm_dt_ids, dev);
+	if (!id)
+		return -ENODEV;
+
+	if (dev->of_node && dev->of_node->name)
+		name = dev->of_node->name;
+	else
+		name = "serial-power-manager";
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->config = id->data;
+	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
+	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
+	data->last_toggle = jiffies;
+	data->backoff = data->toggle_gap;
+	data->state = Idle;
+	spin_lock_init(&data->lock);
+	INIT_DELAYED_WORK(&data->work, toggle_work);
+
+	/* If a regulator is provided, it is enabled on 'open'
+	 * and disabled on 'release'
+	 */
+	reg = devm_regulator_get(dev, "vdd");
+	if (IS_ERR(reg)) {
+		err = PTR_ERR(reg);
+		if (err != -ENODEV)
+			goto out;
+	} else
+		data->reg = reg;
+
+	/* If an irq is provided, any transitions are taken as
+	 * indication that the device is currently "on"
+	 */
+	data->irq = of_irq_get(dev->of_node, 0);
+	if (data->irq < 0) {
+		err = data->irq;
+		if (err != -EINVAL)
+			goto out;
+	} else {
+		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
+
+		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
+		err = devm_request_irq(dev, data->irq, spm_isr,
+				       IRQF_TRIGGER_FALLING,
+				       name, data);
+
+		if (err)
+			goto out;
+
+	}
+
+	/* If a gpio is provided, then it is used to turn the device
+	 * on/off.
+	 * The GPIO is toggled to change the state of the device.
+	 * A "toggle" involves holding the GPIO active for toggle_time.
+	 */
+	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
+	if (IS_ERR(data->gpiod)) {
+		err = PTR_ERR(data->gpiod);
+		if (err != -ENOENT)
+			goto out;
+		data->gpiod = NULL;
+	} else
+		dev_dbg(dev, "GPIO configured: %d\n",
+			desc_to_gpio(data->gpiod));
+
+	/* If an 'off' pinctrl state is defined, we apply that
+	 * when the device is assumed to be off.  This is expected to
+	 * route the 'rx' line to the 'irq' interrupt.
+	 */
+	data->pins = devm_pinctrl_get(dev);
+	if (data->pins && data->irq > 0) {
+		data->pins_off = pinctrl_lookup_state(data->pins, "off");
+		if (IS_ERR(data->pins_off))
+			data->pins_off = NULL;
+	}
+
+	if (data->config->rfkill_type) {
+		data->rfkill = rfkill_alloc(name, dev,
+					    data->config->rfkill_type,
+					    &spm_rfkill_ops, data);
+		if (!data->rfkill) {
+			err = -ENOMEM;
+			goto out;
+		}
+		err = rfkill_register(data->rfkill);
+		if (err) {
+			dev_err(dev, "Cannot register rfkill device");
+			rfkill_destroy(data->rfkill);
+			goto out;
+		}
+	}
+	dev_set_drvdata(dev, data);
+	data->dev = dev;
+	data->old_open = slave->ops.open;
+	data->old_close = slave->ops.close;
+	slave->ops.open = spm_open;
+	slave->ops.close = spm_close;
+	uart_slave_add_tty(slave);
+
+	if (data->pins_off)
+		pinctrl_select_state(data->pins, data->pins_off);
+	if (data->irq > 0)
+		enable_irq(data->irq);
+
+	if (toggle_on_probe && data->gpiod) {
+		dev_dbg(data->dev, "Performing initial toggle\n");
+		gpiod_set_value_cansleep(data->gpiod, 1);
+		msleep(data->config->toggle_time);
+		gpiod_set_value_cansleep(data->gpiod, 0);
+		msleep(data->config->toggle_time);
+	}
+	err = 0;
+out:
+	dev_dbg(data->dev, "Probed: err=%d\n", err);
+	return err;
+}
+
+static int spm_remove(struct device *dev)
+{
+       struct spm_data *data = dev_get_drvdata(dev);
+
+       if (data->rfkill) {
+               rfkill_unregister(data->rfkill);
+               rfkill_destroy(data->rfkill);
+       }
+       return 0;
+}
+
+static struct device_driver spm_driver = {
+	.name		= "serial-power-manager",
+	.owner		= THIS_MODULE,
+	.of_match_table	= spm_dt_ids,
+	.probe		= spm_probe,
+	.remove		= spm_remove,
+};
+
+static int __init spm_init(void)
+{
+       return uart_slave_driver_register(&spm_driver);
+}
+module_init(spm_init);
+
+static void __exit spm_exit(void)
+{
+	driver_unregister(&spm_driver);
+}
+module_exit(spm_exit);
+
+MODULE_AUTHOR("NeilBrown <neil@brown.name>");
+MODULE_DEVICE_TABLE(of, spm_dt_ids);
+MODULE_DESCRIPTION("Power management for Serial-attached device.");
+MODULE_LICENSE("GPL v2");

[PATCH 3/4] TTY: add support for uart_slave devices.

[NeilBrown]

A "uart slave" is a device permanently connected via UART.
Such a device may need its own driver, e.g. for powering
it up on tty open and powering it down on tty release.

When a device is connected to a UART by a 'standard' bus, such as
RS-232, signaling for power control typically uses "DTR".  When the
connection is permanent, as is common on "embedded" boards, separate
signaling may be needed and this requires a separate driver.

uart-slave is a new bus-type which drivers can be written and devices
created.

A "uart slave" device is declared as a child of the uart in
device-tree:

&uart1 {
    bluetooth {
        compatible = "wi2wi,w2cbw003";
        vdd-supply = <&vaux4>;
    };
};

This device will be inserted in the driver-model tree between the uart
and the tty.

The uart-slave driver can replace any of the tty_operations functions
so a call by the tty can be intercepted before being handled by the
uart.

When the tty port is initialized, the uart_slave device is created and
waits for a driver to be bound to it.  Once this happens the tty
device, which was previously initialized, will be added.  This slave
is now considered "finalized".

Any "finalized" slaves will be removed when the tty device is
unregistered.  e.g. by destruct_tty_driver.
While slaves are non-finalized they hold a reference to the tty driver
to prevent destruct_tty_driver from being called, as it cannot find
and free slave devices.

Signed-off-by: NeilBrown <neil@brown.name>
---
 drivers/tty/serial/Kconfig                 |    1 
 drivers/tty/serial/Makefile                |    2 
 drivers/tty/serial/serial_core.c           |    9 +-
 drivers/tty/serial/slave/Kconfig           |    6 +
 drivers/tty/serial/slave/Makefile          |    2 
 drivers/tty/serial/slave/uart_slave_core.c |  168 ++++++++++++++++++++++++++++
 drivers/tty/tty_io.c                       |    3 +
 include/linux/uart_slave.h                 |   29 +++++
 8 files changed, 219 insertions(+), 1 deletion(-)
 create mode 100644 drivers/tty/serial/slave/Kconfig
 create mode 100644 drivers/tty/serial/slave/Makefile
 create mode 100644 drivers/tty/serial/slave/uart_slave_core.c
 create mode 100644 include/linux/uart_slave.h

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f8120c1bde14..2601a8fb41a3 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1594,4 +1594,5 @@ endmenu
 config SERIAL_MCTRL_GPIO
 	tristate
 
+source drivers/tty/serial/slave/Kconfig
 endif # TTY
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index c3ac3d930b33..7a6ed85257f6 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -96,3 +96,5 @@ obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
+
+obj-y += slave/
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 3ea16f524e89..fcad5b30486f 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -34,6 +34,7 @@
 #include <linux/serial_core.h>
 #include <linux/delay.h>
 #include <linux/mutex.h>
+#include <linux/uart_slave.h>
 
 #include <asm/irq.h>
 #include <asm/uaccess.h>
@@ -2710,10 +2711,16 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
 	 * Register the port whether it's detected or not.  This allows
 	 * setserial to be used to alter this port's parameters.
 	 */
-	tty_dev = tty_port_register_device_attr(port, drv->tty_driver,
+	tty_dev = tty_port_initialize_device_attr(port, drv->tty_driver,
 			uport->line, uport->dev, port, uport->tty_groups);
 	if (likely(!IS_ERR(tty_dev))) {
 		device_set_wakeup_capable(tty_dev, 1);
+		if (uart_slave_register(uport->dev, tty_dev,
+					drv->tty_driver) < 0) {
+			ret = tty_device_add(drv->tty_driver, tty_dev);
+			if (ret)
+				put_device(tty_dev);
+		}
 	} else {
 		dev_err(uport->dev, "Cannot register tty device on line %d\n",
 		       uport->line);
diff --git a/drivers/tty/serial/slave/Kconfig b/drivers/tty/serial/slave/Kconfig
new file mode 100644
index 000000000000..6620e78b763e
--- /dev/null
+++ b/drivers/tty/serial/slave/Kconfig
@@ -0,0 +1,6 @@
+menuconfig UART_SLAVE
+	tristate "UART slave devices"
+	depends on OF
+	help
+	 Devices which attach via a uart, but need extra
+	 driver support for power management etc.
diff --git a/drivers/tty/serial/slave/Makefile b/drivers/tty/serial/slave/Makefile
new file mode 100644
index 000000000000..aac8697fa406
--- /dev/null
+++ b/drivers/tty/serial/slave/Makefile
@@ -0,0 +1,2 @@
+
+obj-$(CONFIG_UART_SLAVE) += uart_slave_core.o
diff --git a/drivers/tty/serial/slave/uart_slave_core.c b/drivers/tty/serial/slave/uart_slave_core.c
new file mode 100644
index 000000000000..d48d672300c2
--- /dev/null
+++ b/drivers/tty/serial/slave/uart_slave_core.c
@@ -0,0 +1,168 @@
+/*
+ * uart slave core - device bus for uart slaves
+ *
+ * Copyright (C) 2015 NeilBrown <neil@brown.name>
+ *
+ *    This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *    This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ */
+
+/*
+ * A "uart-slave" is a device permanently attached to a particular
+ * wired to a UART.
+ * A uart-slave has two particular roles.
+ * Firstly it can intercept any tty_operations to provide extra control
+ * of the device.  For example it might intercept "open" and "close"
+ * in order to power the device up and down.  It might intercept
+ * "hangup" to toggle a reset line on the device.
+ *
+ * Secondly it appears as a parent of the tty in the device model, so
+ * that any attributes it presents are visible to udev when the tty
+ * is added.  This allows udev to start appropriate handlers such as
+ * hciattach or inputattach.
+ *
+ * uart-slave devices must be described in devicetree as a child node
+ * of the node which described the attaching UART.
+ *
+ * If such a child is present, the tty device will not be registered
+ * until the slave device is fully probed and initialized.
+ */
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
+#include <linux/device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/tty.h>
+#include <linux/tty_driver.h>
+#include <linux/uart_slave.h>
+
+static int uart_slave_match(struct device *dev, struct device_driver *drv)
+{
+	return of_driver_match_device(dev, drv);
+}
+
+static void uart_slave_release(struct device *dev)
+{
+	struct uart_slave *slave =
+		container_of(dev, struct uart_slave, dev);
+
+	if (!slave->finalized) {
+		put_device(slave->tty_dev);
+		tty_driver_kref_put(slave->tty_drv);
+	}
+	of_node_put(dev->of_node);
+	kfree(slave);
+}
+
+struct bus_type uart_slave_bus_type = {
+	.name		= "uart-slave",
+	.match		= uart_slave_match,
+};
+
+int uart_slave_register(struct device *parent,
+			struct device *tty, struct tty_driver *drv)
+{
+	struct device_node *node, *found = NULL;
+	struct uart_slave *slave;
+	int retval;
+
+	if (!parent || !parent->of_node)
+		return -ENODEV;
+
+	for_each_available_child_of_node(parent->of_node, node) {
+		if (!of_get_property(node, "compatible", NULL))
+			continue;
+		if (found) {
+			dev_err(parent, "Multiple connected children found - non registered");
+			return -ENODEV;
+		}
+		found = node;
+	}
+	if (!found)
+		return -ENODEV;
+
+	slave = kzalloc(sizeof(*slave), GFP_KERNEL);
+	if (!slave)
+		return -ENOMEM;
+
+	slave->dev.bus = &uart_slave_bus_type;
+	slave->dev.parent = parent;
+	slave->dev.release = uart_slave_release;
+	slave->dev.of_node = of_node_get(found);
+	dev_set_name(&slave->dev, "%s", found->name);
+	slave->tty_dev = tty;
+	slave->tty_drv = tty_driver_kref_get(drv);
+	slave->ops = *drv->ops;
+	retval = device_register(&slave->dev);
+	if (retval)
+		put_device(&slave->dev);
+	return retval;
+}
+EXPORT_SYMBOL(uart_slave_register);
+
+void uart_slave_activate(struct tty_struct *tty)
+{
+	struct device *parent = NULL;
+	if (tty->dev)
+		parent = tty->dev->parent;
+	if (parent &&
+	    parent->bus == &uart_slave_bus_type)
+	{
+		struct uart_slave *dev =
+			container_of(parent, struct uart_slave, dev);
+		tty->ops = &dev->ops;
+	}
+}
+EXPORT_SYMBOL(uart_slave_activate);
+
+int uart_slave_add_tty(struct uart_slave *slave)
+{
+	int retval;
+	if (slave->finalized)
+		return -EBUSY;
+	slave->tty_dev->parent = &slave->dev;
+	retval = tty_device_add(slave->tty_drv,
+				slave->tty_dev);
+	/* If that succeeded, the tty now holds a reference to
+	 * the slave through ->parent, so that ref we hold
+	 * can be dropped, as can our ref on the tty driver.
+	 */
+	slave->finalized = true;
+	tty_driver_kref_put(slave->tty_drv);
+	put_device(&slave->dev);
+	return retval;
+}
+EXPORT_SYMBOL(uart_slave_add_tty);
+
+int uart_slave_driver_register(struct device_driver *drv)
+{
+	drv->bus = &uart_slave_bus_type;
+	return driver_register(drv);
+}
+EXPORT_SYMBOL(uart_slave_driver_register);
+
+static int __init uart_slave_init(void)
+{
+	return bus_register(&uart_slave_bus_type);
+}
+
+static void __exit uart_slave_exit(void)
+{
+	bus_unregister(&uart_slave_bus_type);
+}
+
+postcore_initcall(uart_slave_init);
+module_exit(uart_slave_exit);
+MODULE_AUTHOR("NeilBrown <neil@brown.name>");
+MODULE_DESCRIPTION("UART-slave core support.");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 83ca25b9c2da..2bf516f99dd2 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -95,6 +95,7 @@
 #include <linux/seq_file.h>
 #include <linux/serial.h>
 #include <linux/ratelimit.h>
+#include <linux/uart_slave.h>
 
 #include <linux/uaccess.h>
 
@@ -1531,6 +1532,8 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx)
 	if (retval < 0)
 		goto err_deinit_tty;
 
+	uart_slave_activate(tty);
+
 	if (!tty->port)
 		tty->port = driver->ports[idx];
 
diff --git a/include/linux/uart_slave.h b/include/linux/uart_slave.h
new file mode 100644
index 000000000000..9a19825ce47a
--- /dev/null
+++ b/include/linux/uart_slave.h
@@ -0,0 +1,29 @@
+#ifndef _LINUX_UART_SLAVE_H
+#define _LINUX_UART_SLAVE_H
+struct uart_slave {
+	struct device *tty_dev;
+	struct tty_driver *tty_drv;
+	struct tty_operations ops;
+	struct device dev;
+	bool finalized;
+};
+
+int uart_slave_add_tty(struct uart_slave *slave);
+int uart_slave_driver_register(struct device_driver *drv);
+#if IS_ENABLED(CONFIG_UART_SLAVE)
+void uart_slave_activate(struct tty_struct *tty);
+int uart_slave_register(struct device *parent,
+			struct device *tty, struct tty_driver *drv);
+#else
+static inline void uart_slave_activate(struct tty_struct *tty)
+{
+}
+static inline int uart_slave_register(struct device *parent,
+				     struct device *tty,
+				     struct tty_driver *drv)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif /* _LINUX_UART_SLAVE_H */

Re: [PATCH 3/4] TTY: add support for uart_slave devices.

[Paul Bolle]

Just a nit: a license mismatch.

On Mon, 2015-05-11 at 11:56 +1000, NeilBrown wrote:
> --- /dev/null
> +++ b/drivers/tty/serial/slave/uart_slave_core.c

> + *    This program is free software; you can redistribute it and/or modify
> + *   it under the terms of the GNU General Public License as published by
> + *   the Free Software Foundation; either version 2 of the License, or
> + *   (at your option) any later version.
> + *
> + *    This program is distributed in the hope that it will be useful,
> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *   GNU General Public License for more details.

This states the license is GPL v2 or later.

> +MODULE_LICENSE("GPL v2");

And, according to include/linux/module.h, this states the license is
just GPL v2. So I think either the comment at the top of this file or
the license ident used in the MODULE_LICENSE() macro needs to change.

Thanks,


Paul Bolle

Re: [PATCH 3/4] TTY: add support for uart_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

On Tue, 12 May 2015 10:31:01 +0200 Paul Bolle <pebolle@tiscali.nl> wrote:

> Just a nit: a license mismatch.
> 
> On Mon, 2015-05-11 at 11:56 +1000, NeilBrown wrote:
> > --- /dev/null
> > +++ b/drivers/tty/serial/slave/uart_slave_core.c
> 
> > + *    This program is free software; you can redistribute it and/or modify
> > + *   it under the terms of the GNU General Public License as published by
> > + *   the Free Software Foundation; either version 2 of the License, or
> > + *   (at your option) any later version.
> > + *
> > + *    This program is distributed in the hope that it will be useful,
> > + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + *   GNU General Public License for more details.
> 
> This states the license is GPL v2 or later.
> 
> > +MODULE_LICENSE("GPL v2");
> 
> And, according to include/linux/module.h, this states the license is
> just GPL v2. So I think either the comment at the top of this file or
> the license ident used in the MODULE_LICENSE() macro needs to change.
> 
> Thanks,
> 
> 
> Paul Bolle
> 

Thanks.  I've modified the comment to be explicit that only 'version 2' is
appropriate.

NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCH 0/4] UART slave device support - version 4

[Greg Kroah-Hartman]

On Mon, May 11, 2015 at 11:56:14AM +1000, NeilBrown wrote:
> Hi all,
>  here is version 4 of my "UART slave device" patch set, previously
>  known as "tty slave devices".
> 
>  The most obvious change is the name.  I realized that this isn't
>  really about "tty"s at all - it is about UARTs.

Then next time you might also want to cc: the linux-serial mailing list
so the developers there can review it :)

thanks,

greg k-h

Re: [PATCH 0/4] UART slave device support - version 4

[Linus Walleij]

Hi Neil,

first, this is a *VERY* interesting and much needed patch series,
I intend to look closer at it, and if possible test it with some
(heh) board file device. Would be happy of you put me on CC for these.

On Mon, May 11, 2015 at 3:56 AM, NeilBrown <neil@brown.name> wrote:

>  When a device is connected to a UART via RS-232 (or similar), there
>  is a DTR line that can be used for power management, and other "modem
>  control" lines.
>
>  On an embedded board, it is very likely that there is no "DTR", and
>  any power management need to be done using some completely separate
>  mechanism.
>
>  So these "slaves" are really just for devices permanently attached to
>  UARTs without a full "RS-232" (or similar) connection.  The driver
>  does all the extra control beyond Tx/Rx.

What is usually happening (and I have seen it in a few places) is that
the SoC has *one* fully featured RS232 with CTS/RTS and even
DTS,DCD,RI and other esoterica, which is intended to be connected to a
host serial port or so, for example if this SoC is to act as a modem
or a fax machine, or if it is to drive one.

Then they often have a few more UART blocks, usually identical, which
only have RxD+TxD available, so they are "just" UARTs.

To complicate things further, you may wonder what happened with
the CTS/RTS (etc) signals from the other blocks. Usually they are there
in the silicon but just routed to dead ends.

To complicate it even further, usually all these pins are placed under
pin control multiplexing, so in an actual electronic design, the
system will mux out CTS/RTS (etc) from the fully featured RS232
blocks and only use them as UARTs anyways.

Then there are those who created real simple RxD/TxD-only UARTs
("yeah lets dump this RS232 legacy crap" / "yeah yeah")
and then realized they want to drive modems ("oh crap, it seemed
like a good idea at the time"). Then they usually take
two GPIO pins for CTS/RTS and drive them as GPIOs using
software and you have a cheap 4-line modem line. This is what
drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.

> I've tested this set and it seems to work ... except that something
>  is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>  tested the GPS driver.  I guess it is time to rebase to -rc3.

You have a hardware taget I see. Which one?

Yours,
Linus Walleij

Re: [PATCH 0/4] UART slave device support - version 4

[NeilBrown]

On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
<linus.walleij@linaro.org> wrote:

> Hi Neil,
> 
> first, this is a *VERY* interesting and much needed patch series,
> I intend to look closer at it, and if possible test it with some
> (heh) board file device. Would be happy of you put me on CC for these.
> 
> On Mon, May 11, 2015 at 3:56 AM, NeilBrown <neil@brown.name> wrote:
> 
> >  When a device is connected to a UART via RS-232 (or similar), there
> >  is a DTR line that can be used for power management, and other "modem
> >  control" lines.
> >
> >  On an embedded board, it is very likely that there is no "DTR", and
> >  any power management need to be done using some completely separate
> >  mechanism.
> >
> >  So these "slaves" are really just for devices permanently attached to
> >  UARTs without a full "RS-232" (or similar) connection.  The driver
> >  does all the extra control beyond Tx/Rx.
> 
> What is usually happening (and I have seen it in a few places) is that
> the SoC has *one* fully featured RS232 with CTS/RTS and even
> DTS,DCD,RI and other esoterica, which is intended to be connected to a
> host serial port or so, for example if this SoC is to act as a modem
> or a fax machine, or if it is to drive one.
> 
> Then they often have a few more UART blocks, usually identical, which
> only have RxD+TxD available, so they are "just" UARTs.
> 
> To complicate things further, you may wonder what happened with
> the CTS/RTS (etc) signals from the other blocks. Usually they are there
> in the silicon but just routed to dead ends.
> 
> To complicate it even further, usually all these pins are placed under
> pin control multiplexing, so in an actual electronic design, the
> system will mux out CTS/RTS (etc) from the fully featured RS232
> blocks and only use them as UARTs anyways.
> 
> Then there are those who created real simple RxD/TxD-only UARTs
> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
> and then realized they want to drive modems ("oh crap, it seemed
> like a good idea at the time"). Then they usually take
> two GPIO pins for CTS/RTS and drive them as GPIOs using
> software and you have a cheap 4-line modem line. This is what
> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
> 
> > I've tested this set and it seems to work ... except that something
> >  is sadly broken with bluetooth support in 4.1-rc1 so I've only really
> >  tested the GPS driver.  I guess it is time to rebase to -rc3.
> 
> You have a hardware taget I see. Which one?

GTA04 (www.gta04.org - openmoko successor).

3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
half of a wifi/bluetooth module, and one to a GPS.

For the GPS, I just want to power on/off when the TTY is opened/closed,
but the power-on sequence is non-trivial as both "turn on" and
"turn-off' toggle the same line, so I need to be able to detect current
state.

For the bluetooth, the power is a (shared) regulator.  As well as
power-on when the TTY is opened, I'd like regulator to be turned of
when I "hciconfig down" - even though the TTY is still open.
I did a patch a while ago which hooked in to hci_uart_{open,close} to
make this work, but it isn't a really good patch.

It would be nice to hide the TTY from user-space in the bluetooth case,
and have the "hciattach" happen in the kernel, but I think hciattach
does extra initialisation...

NeilBrown

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Linus,

Am 12.08.2015 um 01:20 schrieb NeilBrown <neil@brown.name>:

> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
> <linus.walleij@linaro.org> wrote:
> 
>> Hi Neil,
>> 
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>> 
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown <neil@brown.name> wrote:
>> 
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>> 
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>> 
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection.  The driver
>>> does all the extra control beyond Tx/Rx.
>> 
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>> 
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>> 
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>> 
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>> 
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>> 
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver.  I guess it is time to rebase to -rc3.
>> 
>> You have a hardware taget I see. Which one?
> 
> GTA04 (www.gta04.org - openmoko successor).
> 
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
> 
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
> 
> For the bluetooth, the power is a (shared) regulator.  As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
> 
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
> 
> NeilBrown


we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.

See:
https://lkml.org/lkml/2015/6/28/91

Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

Hi!

> we (the developers of the hardware) have proposed an alternative
> approach to Neil’s implementation - for the same device and solving
> the same problem (notifying tty open/close and uart activity to the
> slave device driver), but differently.
> 
> See:
> https://lkml.org/lkml/2015/6/28/91
> 
> Discussion has not yet settled on which approach is better. So your
> opinion of comparing both is welcome.

Actually, yes, discussion has settled, agreeing that phandle reference
for the uart is a bad idea, Nikolaus just refuses to listen to anyone,
asking "device tree maintainer opinion", and then just simply ignoring
it when he does not like it, and then making promises he did not keep.

Please don't stall patches just because of that.

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 28.08.2015 um 09:02 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>> we (the developers of the hardware) have proposed an alternative
>> approach to Neil’s implementation - for the same device and solving
>> the same problem (notifying tty open/close and uart activity to the
>> slave device driver), but differently.
>> 
>> See:
>> https://lkml.org/lkml/2015/6/28/91
>> 
>> Discussion has not yet settled on which approach is better. So your
>> opinion of comparing both is welcome.
> 
> Actually, yes, discussion has settled, agreeing that phandle reference
> for the uart is a bad idea, Nikolaus just refuses to listen to anyone,

no, I only refuse to listen to you.

You are neither maintainer for any subsystem that is involved nor have
you contributed technical arguments pro/con and it appears to me that
you refuse to listen to my argumentation.

> asking "device tree maintainer opinion", and then just simply ignoring
> it when he does not like it, and then making promises he did not keep.


Which promises did I not keep? Please be specific, instead of insulting.

I bring up this alternative again, since I get the impression that most readers
are simply not aware of *both* alternative proposals.

> Please don't stall patches just because of that.

Please provide better arguments and don’t spread FUD.

Please have a look into our RFC implementation and study it carefully
to learn why it is the better (IMHO more flexible, easier to maintain, more
modular) approach. Even if you don’t like phandles.

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


BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

> > asking "device tree maintainer opinion", and then just simply ignoring
> > it when he does not like it, and then making promises he did not keep.
> 
> Which promises did I not keep? Please be specific, instead of

You promised to shut up.

> Please have a look into our RFC implementation and study it carefully
> to learn why it is the better (IMHO more flexible, easier to maintain, more
> modular) approach. Even if you don’t like phandles.

It was also NAKed by device tree maintainers.

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Christ van Willegen]

Hi all,

I will reverse a part of this e-mail to make replying easier.

On Fri, Aug 28, 2015 at 1:04 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Please have a look into our RFC implementation and study it carefully
>> to learn why it is the better (IMHO more flexible, easier to maintain, more
>> modular) approach. Even if you don’t like phandles.
>
> It was also NAKed by device tree maintainers.

This may be true, I can't recall those specific mails...

> You promised to shut up.

But this is uncalled for.

IIRC there was, indeed, a long technical discussion about how to
connect the Bluetooth chip to the 'UART'.

I've seen Neil patches, and I've seen patches by Nikolaus.

Both appear to have their problems. I think it's fair to:

- Listen carefully to all arguments.
- Have a benevolent dictator, which we have, look into the problem
- Only 'shut up' after a thorough technical analysis has been made
about both approaches to the problem.

Both may have their merit in a number of ways. Don't just close your
eyes, put your fingers in your ears and say 'I can't hear you!'. We
are all adults, or at least, we should be in behaviour. The Linux
system has grown so much _beacuse_ of people working together. Calling
each other names and exiling them will _not_ solve the problem.

Christ van Willegen
-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: [PATCH 0/4] UART slave device support - version 4

[Tomeu Vizoso]

On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
> Hi all,
>  here is version 4 of my "UART slave device" patch set, previously
>  known as "tty slave devices".

Hi Neil,

do you (or someone else) have plans to continue this work in the short
or medium term?

Regards,

Tomeu

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Tomeu,

Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:

> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
>> Hi all,
>> here is version 4 of my "UART slave device" patch set, previously
>> known as "tty slave devices".
> 
> Hi Neil,
> 
> do you (or someone else) have plans to continue this work in the short
> or medium term?

yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:

<http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>

There is one point still to be solved: the exact style of the DT bindings.

We have an idea how a driver can implement two different styles (child node AND phandle)
so that it is up to the DTS developer to use the one that best fits into the existing DTS.
 
BR,
Nikolaus

Re: [PATCH 0/4] UART slave device support - version 4

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Wed, Jan 13 2016, Tomeu Vizoso wrote:

> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
>> Hi all,
>>  here is version 4 of my "UART slave device" patch set, previously
>>  known as "tty slave devices".
>
> Hi Neil,
>
> do you (or someone else) have plans to continue this work in the short
> or medium term?
>

I personally have no current plans.  Too many other interesting things
to do and my interest in the hardware is in the waning phase.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

On Wed 2016-01-13 08:28:24, NeilBrown wrote:
> On Wed, Jan 13 2016, Tomeu Vizoso wrote:
> 
> > On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
> >> Hi all,
> >>  here is version 4 of my "UART slave device" patch set, previously
> >>  known as "tty slave devices".
> >
> > Hi Neil,
> >
> > do you (or someone else) have plans to continue this work in the short
> > or medium term?
> >
> 
> I personally have no current plans.  Too many other interesting things
> to do and my interest in the hardware is in the waning phase.

Can we convince you to play with N900? Your python stuff should still
work, it has keyboard, and we have calls working now ;-).		Pavel

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Mark Rutland]

On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
> Hi Tomeu,
> 
> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:
> 
> > On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
> >> Hi all,
> >> here is version 4 of my "UART slave device" patch set, previously
> >> known as "tty slave devices".
> > 
> > Hi Neil,
> > 
> > do you (or someone else) have plans to continue this work in the short
> > or medium term?
> 
> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:
> 
> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>
> 
> There is one point still to be solved: the exact style of the DT bindings.
> 
> We have an idea how a driver can implement two different styles (child node AND phandle)
> so that it is up to the DTS developer to use the one that best fits into the existing DTS.

>From my perspective as a binding maintainer, and as I stated before, the
child node approach made the most sense and was most consistent with the
way we handle other devices.

I don't understand what the benefit of supporting two styles of
description would be, relative to the maintenance cost. Nor do I
understand your fixation with the phandle approach, given it has been
repeatedly disagreed with by binding maintainers.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Mark Rutland]

On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
> Hi Mark,
> 
> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> 
> > On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Tomeu,
> >> 
> >> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:
> >> 
> >>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
> >>>> Hi all,
> >>>> here is version 4 of my "UART slave device" patch set, previously
> >>>> known as "tty slave devices".
> >>> 
> >>> Hi Neil,
> >>> 
> >>> do you (or someone else) have plans to continue this work in the short
> >>> or medium term?
> >> 
> >> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:
> >> 
> >> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>
> >> 
> >> There is one point still to be solved: the exact style of the DT bindings.
> >> 
> >> We have an idea how a driver can implement two different styles (child node AND phandle)
> >> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
> > 
> > From my perspective as a binding maintainer, and as I stated before, the
> > child node approach made the most sense and was most consistent with the
> 
> > way we handle other devices.
> 
> I simply don't see that this is the most common way other devices are handled.
> 
> I find many counter-examples which use phandles:
> * gpios
> * regulators
> * iio channels used by other drivers (e.g. iio-hwmon)
> * phy devices
> * timers
> * pwms
> * interrupts
> * dma

As was previously described to you, in these cases phandles are used
when these are _resources_ used by another device, not for the main
programmer-visible interface to the device.

Conceptually, A UART slave is far closer to SPI or I2C, where the slave
is represented as a sub-node.

I wasn't aware of any instances of timers being referred to by phandle
by other devices -- that seems distinctly odd. Where do you see that
happening.

> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)

Subsystem type bindings are more of a special case, and regardless the
components have nodes in the relevant portions of the DT.

> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)

If this is so different, how is it relevant?

> All of them define the provider in one node. And refer to it by a phandle in another node
> where they are used.
> 
> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.

I agree that provider-consumer type relationships are typically
described in this manner.

However, master-slave relationships are not.

> Next, if I look up real world DT sources, child nodes have in a majority of cases a
> reg = <...> or ranges = <...> entry to define specific addresses of each child node and
> to distinguish between them.
> 
> This is not always the case (e.g. children of the root node) but often. Therefore I assume
> the child-node pattern is mainly intended for distinguishing between multiple *addressable*
> subdevices connected to a single provider, i.e. some sort of "shared bus".

We can have MMC controllers that only have a single sub-device, yet this
may have a node for this, rather than using phandles. The addressability
has no bearing.

> In the specific problem I (and Neil) want to solve (GTA04 devices and
> more to come), the UART is simply a provider of serial data lines and
> power control events (or whatever the driver implementations want to
> do with the knowledge about this connection).
> 
> Although we have multiple such uart-device connections, they are all
> individual point-to-point.
> 
> Not a bus structure with multiple clients. So there are several simple
> provider-consumer relations.  Hence there is no urgent need for
> addresses of multiple child nodes of a single UART and no reg/ranges
> property.

As above, the addressability doesn't matter.

> Of course, with the child node approach it would give the flexibility
> to introduce such
> a feature easily in the future - but I don't see a use case. Not even at the horizon.
> 
> And I wonder how I should implement a driver if a child node provides a reg property.
> Should I invent and implement a protocol layer to make the UART an addressable bus?

Why would it have a reg property if it were a UART slave?

If a device has multiple slave interfaces, it requires separate nodes
for these. In that case, you'd need to group those together with phandle
references.

> But the chip I connect to an UART does not understand that and I can't change it.

I don't follow what you mean by this. In what way does the binding
description affect the physical device? Are you talking about a driver?

> So it is probably not expected by the uart-slaves story - and I have no need for addressability
> of multiple subnodes.
> 
> So I conclude: the single chip is the consumer of a simple UART provider and should therefore
> be described as a connection through a phandle. Like in all the other DT examples listed
> above. The best description is IMHO:
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/iio-bindings.txt
> 
> At least this is how I see the DT world when going through some device tree files
> and trying to deduce what the common style is.
> 
> This appears to be opposite to what you say: "most consistent with the way we
> handle other devices". I only find that other devices which understand some addressing
> scheme are handled that way.

It's consistent with the way we handle *slave* devices (i.e. we describe
the programming interface on a sub-node to the device that provides
access to that programming interface).

The phandle case describes side-band interfaces.

> > I don't understand what the benefit of supporting two styles of
> > description would be, relative to the maintenance cost.
> 
> Supporting both styles is a proposal to make both of us happy.
> 
> And there isn't much to be maintained. It is just a notice in the bindings document
> of uart-slaves that the phandle is optional, if the node is the single child node of an
> UART. If it isn't a subnode of an UART, or not at index 0, the phandle is needed
> to describe the cross-reference. So it can be seen as a simple extension to move
> the node outside but keep the link.
> 
> A rough estimate is that it requires just ~20 lines to implement in our driver (unless
> we need locks, error handling etc.).
> 
> Then, the DT developers (like me) can decide which style better fits into the DTS
> structure that already exists, when adding a salve device to some UART.

Which then leads to confusion as DTs are arbitrarily different for no
real reason. That makes things harder to maintain, even if only ~20
lines of code were necessary.

> My experience from almost daily work with device trees is that phandles give
> more flexibility in expressing the hardware structure in DT language. And they
> allow to better group properties. In this case: "I am connected to interface ...".
> 
> And the allow to easily modify it by includes and overlays to describe small hardware
> variants ("I am now connected to a different interface ..."). Moving a subnode between
> parents is difficult without multiple well designed include files, while for phandle
> there is a simple idiom:
> 
> 	#include <existing.dts(i)>
> 	&child { link = <&new-parent>; };
> 
> IMHO this is easy to read and understand. And I have used that pattern several
> times, e.g. for "adding" hardware to some evaluation board without touching the
> original DTS. So I don't want to miss it in this case.
> 
> > Nor do I
> > understand your fixation with the phandle approach,
> 
> Well, because I don't understand your fixation on the child node approach for this
> non-addressable point-to-point connection. Why prepare for a feature that nobody
> really needs and has asked for?

Addressability was not my main concern. Consistency with other "bus"
types is a major concern. See below for what I mean by "bus", as we are
clearly using the term differently.

> To be more specific:
> 
> * I find that the phandle approach better (more flexible) suits the problem I want to have solved.
> * there is no need for multiple child nodes for a point-to-point connection, because UART is rarely used as a bus.

In Linux terminology a "bus" is effectively anything that provides us
with a programming interface to some number of devices. That number may
be 1 (i.e. a point-to-point connection is just a particular case of a
"bus").

That is what I mean when I talk about a "bus", and that is why I believe
that UARTs should be treated as with other busses if we are going to
handle slave devices.

I appreciate that this is not quite its usual meaning

> * I see a lot of examples where phandles are intensively used and there it appears to be right to do so.
> 
> I just know that you conclude "child nodes made the most sense and was most consistent".
> 
> But I still wonder why. It does not appear to match what I observe in arch/arm/boot/dts
> and the problem I want to solve.
> 
> > given it has been
> > repeatedly disagreed with by binding maintainers.
> 
> Binding maintainers may sometimes be as wrong as I may be here. This needs a discussion
> but not a circular argument, that it already has been disagreed repeatedly.

We all make mistakes, certainly.

However, you have ignored the distinction that has been described
repeatedly w.r.t. slaves vs random side-band relationships.

> I may have missed it, but I am also not aware that there was a technical analysis of both
> approaches, comparing the pro's and con's. I had received requests to show code for the
> phandle approach and we provided it.
> 
> Coming to different conclusions can happen, if requirements are weighted differently. Or
> the problem to be solved is not completely understood. But then, the requirements and
> assumptions should be discussed (which is difficult on a patch-review-based discussion list).
> 
> On a more general level, the key problem is that *I* have to write and maintain a
> multitude of board specific DTS files (not all of them in mainline) using the style
> *you* decide.

While myself and others will be having to maintain bindings and
infrastructure for whatever is used. I appreciate one style might be
more painful in some cases, but that pain isn't necessarily only
constrained to dts authors.

> A style which I don't feel to be the "right" one, because it is less flexible (e.g. swapping
> child nodes between parents in board variants).
> 
> Summary: your decision gives flexibility for future expansion that I do not need (and
> probably nobody else) and does not provide the flexibility I need today (and others
> might appreciate).
> 
> So what should I do? Except being fixed on the phandle approach, repeating my arguments
> and describe requirements. And submitting our code and bindings document proposal
> every now and then?

Follow the advice from myself and others, and describe the device as a
slave, under the UART providing access to the programmers' interface. By
your own admission that works, it's simply that you don't like the style
of the dts.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Mark,

Am 15.01.2016 um 12:01 schrieb Mark Rutland <mark.rutland@arm.com>:

> On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
>> Hi Mark,
>> 
>> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>> 
>>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Tomeu,
>>>> 
>>>> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:
>>>> 
>>>>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
>>>>>> Hi all,
>>>>>> here is version 4 of my "UART slave device" patch set, previously
>>>>>> known as "tty slave devices".
>>>>> 
>>>>> Hi Neil,
>>>>> 
>>>>> do you (or someone else) have plans to continue this work in the short
>>>>> or medium term?
>>>> 
>>>> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:
>>>> 
>>>> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>
>>>> 
>>>> There is one point still to be solved: the exact style of the DT bindings.
>>>> 
>>>> We have an idea how a driver can implement two different styles (child node AND phandle)
>>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
>>> 
>>> From my perspective as a binding maintainer, and as I stated before, the
>>> child node approach made the most sense and was most consistent with the
>> 
>>> way we handle other devices.
>> 
>> I simply don't see that this is the most common way other devices are handled.
>> 
>> I find many counter-examples which use phandles:
>> * gpios
>> * regulators
>> * iio channels used by other drivers (e.g. iio-hwmon)
>> * phy devices
>> * timers
>> * pwms
>> * interrupts
>> * dma
> 
> As was previously described to you, in these cases phandles are used
> when these are _resources_ used by another device, not for the main
> programmer-visible interface to the device.

Ah, I think I finally begin to understand the rule you are following:

	If a device's data interface can be seen in user space, this interface
	is sort of a "main interface" and must be modelled in DT by a
	parent-child relationship.

But then you obviously ignore the basic rule that DT describes hardware
in an OS agnostic way and mix it up with programmer-visible interfaces
and a not well defined concept of "main" and "other" interfaces.

So I doubt that this rule is really necessary. A different OS could use the
same DT but not provide a programmer's interface at all.

Or is this no longer a general goal of DT to be OS agnostic?

Now I also think I better understand what you meant by "main interface"
a while ago.

For me, when looking into a chip data sheet, the main interface is a sometimes
arbitrary. Or when viewing it through device driver implementors glasses
I may end up with a different main interface.

>From the hardware schematics, I can't read which interface is "main". I can
only read which components and signals are connected. So the information
what is "main" must come from somewhere else, but not the hardware.

You appear to have a definition based on Linux user space interfaces
which is distinct from mine and at least explains why the discussion takes
so long and we don't come to a common view.

> 
> Conceptually, A UART slave is far closer to SPI or I2C, where the slave
> is represented as a sub-node.

Only if you have the goal to describe the data/command path ("main interface")
in DT.

I mentioned it several times: USB-PHYs use the phandle approach to attach
a single PHY to the usb controller, although there is usually some ULPI-"bus"
interface (12 parallel wires) between. And the PHY is clearly more "slave" than
the usb controller, isn't it?

But with phandle, the usb controller is a _resource_ for the PHY. So would
you say this is wrong?

This is the design pattern (for DT and drivers) we have copied for our tty-slave
proposal.

> I wasn't aware of any instances of timers being referred to by phandle
> by other devices -- that seems distinctly odd. Where do you see that
> happening.

I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
and that may be a special type of OMAP timers.

> 
>> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)
> 
> Subsystem type bindings are more of a special case, and regardless the
> components have nodes in the relevant portions of the DT.

> 
>> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)
> 
> If this is so different, how is it relevant?

It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
isn't grouped there, and uses a phandle to refer to its &mmc "master".

Its function is quite similar what we need for our GPS chip: control power sequences
of a remote device.

> 
>> All of them define the provider in one node. And refer to it by a phandle in another node
>> where they are used.
>> 
>> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.
> 
> I agree that provider-consumer type relationships are typically
> described in this manner.

Ok.

> 
> However, master-slave relationships are not.

It looks as if you see a significant difference between provider-consumer and master-slave
relationship which I was not sure of which applies to what and where you make the distinction.

By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
device a "slave" (except the user-space view)?

UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
is well defined). Rather, both are formally DTE connected by a null-modem.

This is another substantial difference between UART and I2C/SPI besides addressability.

> 
>> Next, if I look up real world DT sources, child nodes have in a majority of cases a
>> reg = <...> or ranges = <...> entry to define specific addresses of each child node and
>> to distinguish between them.
>> 
>> This is not always the case (e.g. children of the root node) but often. Therefore I assume
>> the child-node pattern is mainly intended for distinguishing between multiple *addressable*
>> subdevices connected to a single provider, i.e. some sort of "shared bus".
> 
> We can have MMC controllers that only have a single sub-device, yet this
> may have a node for this, rather than using phandles. The addressability
> has no bearing.

I admit that there are exceptions and MMC slaves (e.g. a single WiFi chip) is one
of them, but there are many cases where subnodes are addressable. e.g. I2C, SPI.
and e.g. the whole internal structure of SoCs.

A source of wisdom is

http://devicetree.org/Device_Tree_Usage#How_Addressing_Works

Although not explicitly said it gives me the impression that the parent-child
pattern is always tightly related with addresses and address translation
(including the degenerate case of reg = <0> which could be thought to apply
to the MMC example).

And it mentions for "Non Memory Mapped Devices" nodes "Instead the
parent device's driver would perform indirect access on behalf of the CPU".

So this document could be interpreted as that a parent driver *must* translate
addresses of children which would be exactly contrary to the view you describe
to me that there is no bearing.

Is this document wrong or irrelevant to our device trees (please give me a link
to a better document)?

> 
>> In the specific problem I (and Neil) want to solve (GTA04 devices and
>> more to come), the UART is simply a provider of serial data lines and
>> power control events (or whatever the driver implementations want to
>> do with the knowledge about this connection).
>> 
>> Although we have multiple such uart-device connections, they are all
>> individual point-to-point.
>> 
>> Not a bus structure with multiple clients. So there are several simple
>> provider-consumer relations.  Hence there is no urgent need for
>> addresses of multiple child nodes of a single UART and no reg/ranges
>> property.
> 
> As above, the addressability doesn't matter.
> 
>> Of course, with the child node approach it would give the flexibility
>> to introduce such
>> a feature easily in the future - but I don't see a use case. Not even at the horizon.
>> 
>> And I wonder how I should implement a driver if a child node provides a reg property.
>> Should I invent and implement a protocol layer to make the UART an addressable bus?
> 
> Why would it have a reg property if it were a UART slave?

Under the assumption that addressability matters and multiple parent-child
nodes are usually used for addressable slaves. To group all of them under
a single master. Then we would need reg = <1> etc. handled by the uart master
driver.

> 
> If a device has multiple slave interfaces, it requires separate nodes
> for these. In that case, you'd need to group those together with phandle
> references.

Yes.

> 
>> But the chip I connect to an UART does not understand that and I can't change it.
> 
> I don't follow what you mean by this. In what way does the binding
> description affect the physical device? Are you talking about a driver?

It is meant to comment about addressability discussion and protocol layer. If there is a
protocol layer, the chip must be able to understand the protocol for addresses. And since
I can't change the chip I can't introduce addresses. Hence can't make the uart-slave an
addressable chip. This limits the subnode approach to a single subnode and always
makes it a degenerate "bus".

> 
>> So it is probably not expected by the uart-slaves story - and I have no need for addressability
>> of multiple subnodes.
>> 
>> So I conclude: the single chip is the consumer of a simple UART provider and should therefore
>> be described as a connection through a phandle. Like in all the other DT examples listed
>> above. The best description is IMHO:
>> 
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/iio-bindings.txt
>> 
>> At least this is how I see the DT world when going through some device tree files
>> and trying to deduce what the common style is.
>> 
>> This appears to be opposite to what you say: "most consistent with the way we
>> handle other devices". I only find that other devices which understand some addressing
>> scheme are handled that way.
> 
> It's consistent with the way we handle *slave* devices (i.e. we describe
> the programming interface on a sub-node to the device that provides
> access to that programming interface).

Ok, I understand, based on your programming interface view.

This means:

user-space -> /dev/tty* -> UART -> chip

> 
> The phandle case describes side-band interfaces.

Probably this is the key.

In my PoV the data interface (programmer's API) already works (through /dev/tty*)
without need to change DT. E.g. if the GPS chip is powered on by U-Boot.

What is missing in kernel.org is just that the driver of a slave can know when to
power up/down.

Therefore the driver just needs to know the UART and ask for state information.
Exactly the same as e.g. some driver might need to access the iio interface
of some other device.

Now the question is: is this a side-band interface or not?

IMHO yes.

There is also another use case to consider that was mentioned long ago: someone
wanted to hide an UART from the tty layer so that it is not visible to the user
space at all and the "slave" driver wraps it effectively inside the kernel.

In that case a "slave" device driver uses the whole UART as a _resource_ to
get access to the AT commands or whatever the chip understands and
can present the data to user space with a different API (e.g. iio).

Then, it would be obvious that the device driver has its own node and
uses some phandle to know about the SoC UART it is connected to.

This would be

user-space ->/sys/bus/iio -> chip -> UART

It appears to be impossible to correctly model both UART slave relations
in a single DT...

> 
>>> I don't understand what the benefit of supporting two styles of
>>> description would be, relative to the maintenance cost.
>> 
>> Supporting both styles is a proposal to make both of us happy.
>> 
>> And there isn't much to be maintained. It is just a notice in the bindings document
>> of uart-slaves that the phandle is optional, if the node is the single child node of an
>> UART. If it isn't a subnode of an UART, or not at index 0, the phandle is needed
>> to describe the cross-reference. So it can be seen as a simple extension to move
>> the node outside but keep the link.
>> 
>> A rough estimate is that it requires just ~20 lines to implement in our driver (unless
>> we need locks, error handling etc.).
>> 
>> Then, the DT developers (like me) can decide which style better fits into the DTS
>> structure that already exists, when adding a salve device to some UART.
> 
> Which then leads to confusion as DTs are arbitrarily different for no
> real reason. That makes things harder to maintain, even if only ~20
> lines of code were necessary.

1 line in DT + location
~20 lines in tty-driver code

> 
>> My experience from almost daily work with device trees is that phandles give
>> more flexibility in expressing the hardware structure in DT language. And they
>> allow to better group properties. In this case: "I am connected to interface ...".
>> 
>> And the allow to easily modify it by includes and overlays to describe small hardware
>> variants ("I am now connected to a different interface ..."). Moving a subnode between
>> parents is difficult without multiple well designed include files, while for phandle
>> there is a simple idiom:
>> 
>> 	#include <existing.dts(i)>
>> 	&child { link = <&new-parent>; };
>> 
>> IMHO this is easy to read and understand. And I have used that pattern several
>> times, e.g. for "adding" hardware to some evaluation board without touching the
>> original DTS. So I don't want to miss it in this case.
>> 
>>> Nor do I
>>> understand your fixation with the phandle approach,
>> 
>> Well, because I don't understand your fixation on the child node approach for this
>> non-addressable point-to-point connection. Why prepare for a feature that nobody
>> really needs and has asked for?
> 
> Addressability was not my main concern. Consistency with other "bus"
> types is a major concern. See below for what I mean by "bus", as we are
> clearly using the term differently.

> 
>> To be more specific:
>> 
>> * I find that the phandle approach better (more flexible) suits the problem I want to have solved.
>> * there is no need for multiple child nodes for a point-to-point connection, because UART is rarely used as a bus.
> 
> In Linux terminology a "bus" is effectively anything that provides us
> with a programming interface to some number of devices.

This "number of devices" is why I think addressability is a natural consequence of "bus".

> That number may
> be 1 (i.e. a point-to-point connection is just a particular case of a
> "bus").

Yes, of course there are degenerate cases where addressability can be ignored 
(0 or 1 bus client).

> 
> That is what I mean when I talk about a "bus", and that is why I believe
> that UARTs should be treated as with other busses if we are going to
> handle slave devices.

> 
> I appreciate that this is not quite its usual meaning

It is not far from my definition, except that you deny that multiple devices always need
some addressing mechanism. Which you can only ignore if there is a degenerate
case of a point-to-point connection.

What your definition does not describe is the distinction between "payload" and
side-band information.

And again you argue with Linux terminology and programming interface when
trying to describe hardware.

> 
>> * I see a lot of examples where phandles are intensively used and there it appears to be right to do so.
>> 
>> I just know that you conclude "child nodes made the most sense and was most consistent".
>> 
>> But I still wonder why. It does not appear to match what I observe in arch/arm/boot/dts
>> and the problem I want to solve.
>> 
>>> given it has been
>>> repeatedly disagreed with by binding maintainers.
>> 
>> Binding maintainers may sometimes be as wrong as I may be here. This needs a discussion
>> but not a circular argument, that it already has been disagreed repeatedly.
> 
> We all make mistakes, certainly.
> 
> However, you have ignored the distinction that has been described
> repeatedly w.r.t. slaves vs random side-band relationships.

No, not at all.

I just insist (and have also repeated several times) that for our device problem is just a side-band
relationship that needs to be modeled.

And IMHO nobody has described that he/she needs a solution to model the *data* relationship
for devices connected behind a tty port.

> 
>> I may have missed it, but I am also not aware that there was a technical analysis of both
>> approaches, comparing the pro's and con's. I had received requests to show code for the
>> phandle approach and we provided it.
>> 
>> Coming to different conclusions can happen, if requirements are weighted differently. Or
>> the problem to be solved is not completely understood. But then, the requirements and
>> assumptions should be discussed (which is difficult on a patch-review-based discussion list).
>> 
>> On a more general level, the key problem is that *I* have to write and maintain a
>> multitude of board specific DTS files (not all of them in mainline) using the style
>> *you* decide.
> 
> While myself and others will be having to maintain bindings and
> infrastructure for whatever is used. I appreciate one style might be
> more painful in some cases, but that pain isn't necessarily only
> constrained to dts authors.

Please explain your pain by the phandle (only) approach or the pain
for the non-dts authors you mention.

We will provide a bindings document, examples and 2-3 drivers and board,dts using it.

What do you expect to have to maintain?

IMHO your work is exactly the same for both variants.

> 
>> A style which I don't feel to be the "right" one, because it is less flexible (e.g. swapping
>> child nodes between parents in board variants).
>> 
>> Summary: your decision gives flexibility for future expansion that I do not need (and
>> probably nobody else) and does not provide the flexibility I need today (and others
>> might appreciate).
>> 
>> So what should I do? Except being fixed on the phandle approach, repeating my arguments
>> and describe requirements. And submitting our code and bindings document proposal
>> every now and then?
> 
> Follow the advice from myself and others, and describe the device as a
> slave, under the UART providing access to the programmers' interface.

Yes, that would be obviously the easiest for you :)

I would have to work with a DT structure that I don't see necessary to solve my problem,
and have the additional pain with arranging the board.dts files in an easy to maintain
way (can't use simple phandle overwriting).

> By
> your own admission that works, it's simply that you don't like the style
> of the dts.

It is not a simple dislike. I think it is the wrong solution (harming future development if cast
into concrete) for the practical problems I (and maybe others) have to be solved.

After all (it is a very complex topic which is probably the reason why almost nobody jumps
in to argue), I think we have condensed it into that we simply have different goals/problems
to be solved and different starting points:

* you want to see that DT describes the data (=main) interface from the uart to the chip. This
   is based on looking which programmer-visible "main" interfaces are available to user space (a
   rule which I doubt is needed and helpful for an OS agnostic formal hardware description).
  You see the SoC UART as "master" and the chip as "slave" (even if there are no clear master-slave
   roles in UART serial interfaces).

* I want to describe the side-band interface from the chip to the uart to be able to know how to
   control power of the chip and can even ignore that there is any user space API. This makes
   the UART a status resource to be queried by the "slave".

>From each of both goals it is clear that we come to different conclusions about the right way.

And I wonder if the wording "uart-slave" is misleading? Is "uart-control" better? Or "uart-client"?

So we do not have to discuss solutions and which one is right but the problem to be solved.

Now what can I do to convince you and accept my view and the problem I want to
solve for Linux?

BR and thanks for clarifying your PoV,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andrey Vostrikov]

Hi Nikolaus,

H. Nikolaus Schaller wrote:
> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
> for devices connected behind a tty port.

I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.

This MCU implements several functions that will be implemented as MFD driver:
  - watchdog and system reset
  - NVMEM EEPROM
  - HWMON sensors
  - Input/power button
  - and similar low level functions

So in my case DTS binding looks like:

&uart3 {
	mcu {
		line-speed = <baud rate>;
		watchdog {
			timeout = <ms>;
			...other params...
		};
		eeprom {
			#address-cells
			#size-cells
			cell1 : cell@1 {
				reg = <1 2>;
			};
			cell2 : cell@2 {
				reg = <2 1>;
			};
		};
		hwmon {
			sensors-list = "voltage", "current", etc...;
		}
	}
}

This MCU receives commands and notifies MFD driver about events via UART protocol.
It looks like not really a slave though, more like a partnership from data flow point of view.

There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).


Best regards,
Andrey

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Andrey,
ah that is fine to learn about another project that needs some solution (however it will look like).

Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:

> Hi Nikolaus,
> 
> H. Nikolaus Schaller wrote:
>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>> for devices connected behind a tty port.
> 
> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
> 
> This MCU implements several functions that will be implemented as MFD driver:
> - watchdog and system reset
> - NVMEM EEPROM
> - HWMON sensors
> - Input/power button
> - and similar low level functions
> 
> So in my case DTS binding looks like:
> 
> &uart3 {
> 	mcu {
> 		line-speed = <baud rate>;
> 		watchdog {
> 			timeout = <ms>;
> 			...other params...
> 		};
> 		eeprom {
> 			#address-cells
> 			#size-cells
> 			cell1 : cell@1 {
> 				reg = <1 2>;
> 			};
> 			cell2 : cell@2 {
> 				reg = <2 1>;
> 			};
> 		};
> 		hwmon {
> 			sensors-list = "voltage", "current", etc...;
> 		}
> 	}
> }

With my proposal it would just become

/ {
	themcu: mcu {
		uart = <&uart3>;
		line-speed = <baud rate>;
		watchdog {
			timeout = <ms>;
			...other params...
		};
		eeprom {
			#address-cells
			#size-cells
			cell1 : cell@1 {
				reg = <1 2>;
			};
			cell2 : cell@2 {
				reg = <2 1>;
			};
		};
		hwmon {
			sensors-list = "voltage", "current", etc...;
		}
	}
};

Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by

&themcu {
	uart = <&uart1>;
};

With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).

> 
> This MCU receives commands and notifies MFD driver about events via UART protocol.
> It looks like not really a slave though, more like a partnership from data flow point of view.

Yes!. That is why I started to question the term "slave".

And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.

> 
> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).

Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 

We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.

In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).

As you see, I have a driver-specific standpoint (and not coming from user space).

Thanks for sharing this example.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Mark Rutland]

On Fri, Jan 15, 2016 at 04:05:45PM +0100, H. Nikolaus Schaller wrote:
> Hi Mark,
> 
> Am 15.01.2016 um 12:01 schrieb Mark Rutland <mark.rutland@arm.com>:
> 
> > On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Mark,
> >> 
> >> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> >> 
> >>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
> >>>> There is one point still to be solved: the exact style of the DT bindings.
> >>>> 
> >>>> We have an idea how a driver can implement two different styles (child node AND phandle)
> >>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
> >>> 
> >>> From my perspective as a binding maintainer, and as I stated before, the
> >>> child node approach made the most sense and was most consistent with the
> >> 
> >>> way we handle other devices.
> >> 
> >> I simply don't see that this is the most common way other devices are handled.
> >> 
> >> I find many counter-examples which use phandles:
> >> * gpios
> >> * regulators
> >> * iio channels used by other drivers (e.g. iio-hwmon)
> >> * phy devices
> >> * timers
> >> * pwms
> >> * interrupts
> >> * dma
> > 
> > As was previously described to you, in these cases phandles are used
> > when these are _resources_ used by another device, not for the main
> > programmer-visible interface to the device.
> 
> Ah, I think I finally begin to understand the rule you are following:
> 
> 	If a device's data interface can be seen in user space, this interface
> 	is sort of a "main interface" and must be modelled in DT by a
> 	parent-child relationship.

No, you have misunderstood. This has _nothing_ to do with userspace.

This has everything to do with the "programmer's interface" as you would
find documented in a TRM -- effectively where a driver would communicate
with the device (e.g. MMIO/SPI/I2C registers).

[...]

> Now I also think I better understand what you meant by "main interface"
> a while ago.
> 
> For me, when looking into a chip data sheet, the main interface is a sometimes
> arbitrary. Or when viewing it through device driver implementors glasses
> I may end up with a different main interface.
> 
> From the hardware schematics, I can't read which interface is "main". I can
> only read which components and signals are connected. So the information
> what is "main" must come from somewhere else, but not the hardware.
> 
> You appear to have a definition based on Linux user space interfaces
> which is distinct from mine and at least explains why the discussion takes
> so long and we don't come to a common view.

This is nothing to do with userspace.

Admittedly, on a device which has multiple slave interfaces, "main" is
arbitrary. If I've followed correctly, that's not the cae here.

> > Conceptually, A UART slave is far closer to SPI or I2C, where the slave
> > is represented as a sub-node.
> 
> Only if you have the goal to describe the data/command path ("main interface")
> in DT.

This is the way devices are described in DT -- walking from the root to
a leaf you follow the path from the CPU to a slave interface.

Some things don't have slave interfaces (e.g. fixed-clocks), but still
need to be referred to, so those still get placed in the DT. There are
arguments to be had w.r.t. their placement, but that's another
discussion entirely.

> I mentioned it several times: USB-PHYs use the phandle approach to attach
> a single PHY to the usb controller, although there is usually some ULPI-"bus"
> interface (12 parallel wires) between. And the PHY is clearly more "slave" than
> the usb controller, isn't it?

Some PHYs have additional interfaces, so their CPU-visible slave
interface is described. This necessitates the phandle reference in the
general case.

> But with phandle, the usb controller is a _resource_ for the PHY. So would
> you say this is wrong?

Not entirely.

> This is the design pattern (for DT and drivers) we have copied for our tty-slave
> proposal.

We have plenty of other ways of describing relationships today. The
existence of one style (and its continued support for ABI reasons) does
not mean that it's a style we want to proliferate.

> 
> > I wasn't aware of any instances of timers being referred to by phandle
> > by other devices -- that seems distinctly odd. Where do you see that
> > happening.
> 
> I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
> and that may be a special type of OMAP timers.

I took a quick look and couldn't spot where that happened. I take it
the timer was a "ti,omap3430-timer"? Or have I misunderstood?

What referenced it by phandle? In which dt?

> >> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)
> > 
> > Subsystem type bindings are more of a special case, and regardless the
> > components have nodes in the relevant portions of the DT.
> 
> > 
> >> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)
> > 
> > If this is so different, how is it relevant?
> 
> It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
> isn't grouped there, and uses a phandle to refer to its &mmc "master".
> 
> Its function is quite similar what we need for our GPS chip: control power sequences
> of a remote device.

That may fit your one particular use-case, but for UART slaves generally
we should have a kernel driver (which can do more than a trivial
power-up), at which point you need a node, and the separate sequence
node is useless.

> >> All of them define the provider in one node. And refer to it by a phandle in another node
> >> where they are used.
> >> 
> >> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.
> > 
> > I agree that provider-consumer type relationships are typically
> > described in this manner.
> 
> Ok.
> 
> > 
> > However, master-slave relationships are not.
> 
> It looks as if you see a significant difference between provider-consumer and master-slave
> relationship which I was not sure of which applies to what and where you make the distinction.
> 
> By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
> device a "slave" (except the user-space view)?

Typically a "slave" accepts commands, and won't send commands of its own
accord. This case is admittedly fuzzier given that a UART slave could
send a stream of bytes at any point, but that's data.

The distinction is really that the UART slave won't control other
devices -- you can think of the entire path of the CPU to the UART as
the master.

> UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
> is well defined). Rather, both are formally DTE connected by a null-modem.
> 
> This is another substantial difference between UART and I2C/SPI besides addressability.

Sure, except for the fact that the device attached to the UART logically
follows a "slave" role. The rest of the system would be usable without
it, and it assert no control over anything else.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Peter Hurley]

On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
> Hi Andrey,
> ah that is fine to learn about another project that needs some solution (however it will look like).
> 
> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
> 
>> Hi Nikolaus,
>>
>> H. Nikolaus Schaller wrote:
>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>> for devices connected behind a tty port.
>>
>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>
>> This MCU implements several functions that will be implemented as MFD driver:
>> - watchdog and system reset
>> - NVMEM EEPROM
>> - HWMON sensors
>> - Input/power button
>> - and similar low level functions
>>
>> So in my case DTS binding looks like:
>>
>> &uart3 {
>> 	mcu {
>> 		line-speed = <baud rate>;
>> 		watchdog {
>> 			timeout = <ms>;
>> 			...other params...
>> 		};
>> 		eeprom {
>> 			#address-cells
>> 			#size-cells
>> 			cell1 : cell@1 {
>> 				reg = <1 2>;
>> 			};
>> 			cell2 : cell@2 {
>> 				reg = <2 1>;
>> 			};
>> 		};
>> 		hwmon {
>> 			sensors-list = "voltage", "current", etc...;
>> 		}
>> 	}
>> }
> 
> With my proposal it would just become
> 
> / {
> 	themcu: mcu {
> 		uart = <&uart3>;
> 		line-speed = <baud rate>;
> 		watchdog {
> 			timeout = <ms>;
> 			...other params...
> 		};
> 		eeprom {
> 			#address-cells
> 			#size-cells
> 			cell1 : cell@1 {
> 				reg = <1 2>;
> 			};
> 			cell2 : cell@2 {
> 				reg = <2 1>;
> 			};
> 		};
> 		hwmon {
> 			sensors-list = "voltage", "current", etc...;
> 		}
> 	}
> };
> 
> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
> 
> &themcu {
> 	uart = <&uart1>;
> };
> 
> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
> 
>>
>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>> It looks like not really a slave though, more like a partnership from data flow point of view.
> 
> Yes!. That is why I started to question the term "slave".
> 
> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
> 
>>
>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
> 
> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
> 
> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
> 
> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
> 
> As you see, I have a driver-specific standpoint (and not coming from user space).
> 
> Thanks for sharing this example.


I'd like to see the exemplar slave driver be something more complicated than
trivial on-off, before hacking in junk into the serial core.

As it stands, this gps could be supported on any uart driver that implements
mctrl gpios (which is trivial with the serial mctrl gpio helpers).

Not that I'm against uart slave device support, just that I don't think hacks
is the way to go about it.

What I'd like to see is a split of the serial core into a tty driver and a
standalone device abstraction. Anything else is just workarounds.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Peter,

Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>> Hi Andrey,
>> ah that is fine to learn about another project that needs some solution (however it will look like).
>> 
>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>> 
>>> Hi Nikolaus,
>>> 
>>> H. Nikolaus Schaller wrote:
>>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>>> for devices connected behind a tty port.
>>> 
>>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>> 
>>> This MCU implements several functions that will be implemented as MFD driver:
>>> - watchdog and system reset
>>> - NVMEM EEPROM
>>> - HWMON sensors
>>> - Input/power button
>>> - and similar low level functions
>>> 
>>> So in my case DTS binding looks like:
>>> 
>>> &uart3 {
>>> 	mcu {
>>> 		line-speed = <baud rate>;
>>> 		watchdog {
>>> 			timeout = <ms>;
>>> 			...other params...
>>> 		};
>>> 		eeprom {
>>> 			#address-cells
>>> 			#size-cells
>>> 			cell1 : cell@1 {
>>> 				reg = <1 2>;
>>> 			};
>>> 			cell2 : cell@2 {
>>> 				reg = <2 1>;
>>> 			};
>>> 		};
>>> 		hwmon {
>>> 			sensors-list = "voltage", "current", etc...;
>>> 		}
>>> 	}
>>> }
>> 
>> With my proposal it would just become
>> 
>> / {
>> 	themcu: mcu {
>> 		uart = <&uart3>;
>> 		line-speed = <baud rate>;
>> 		watchdog {
>> 			timeout = <ms>;
>> 			...other params...
>> 		};
>> 		eeprom {
>> 			#address-cells
>> 			#size-cells
>> 			cell1 : cell@1 {
>> 				reg = <1 2>;
>> 			};
>> 			cell2 : cell@2 {
>> 				reg = <2 1>;
>> 			};
>> 		};
>> 		hwmon {
>> 			sensors-list = "voltage", "current", etc...;
>> 		}
>> 	}
>> };
>> 
>> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
>> 
>> &themcu {
>> 	uart = <&uart1>;
>> };
>> 
>> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>> 
>>> 
>>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>>> It looks like not really a slave though, more like a partnership from data flow point of view.
>> 
>> Yes!. That is why I started to question the term "slave".
>> 
>> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>> 
>>> 
>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>> 
>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
>> 
>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>> 
>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>> 
>> As you see, I have a driver-specific standpoint (and not coming from user space).
>> 
>> Thanks for sharing this example.
> 
> 
> I'd like to see the exemplar slave driver be something more complicated than
> trivial on-off, before hacking in junk into the serial core.
> 
> As it stands, this gps could be supported on any uart driver that implements
> mctrl gpios (which is trivial with the serial mctrl gpio helpers).

in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
that there is data activity. This is something mctrl can't provide.

And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.

In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
forward changes of the mctrl bits to the partner driver.

> 
> Not that I'm against uart slave device support, just that I don't think hacks
> is the way to go about it.
> 
> What I'd like to see is a split of the serial core into a tty driver and a
> standalone device abstraction. Anything else is just workarounds.

Here (was rebased from what I had submitted to LKML a while ago):

1. serial core (two patches add API for any such partner drivers)

http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68

2. standalone driver example (using the new API)

http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Peter Hurley]

On 01/15/2016 09:32 AM, H. Nikolaus Schaller wrote:
> Hi Peter,
> 
> Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>> Hi Andrey,
>>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>>
>>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>>
>>>> Hi Nikolaus,
>>>>
>>>> H. Nikolaus Schaller wrote:
>>>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>>>> for devices connected behind a tty port.
>>>>
>>>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>>>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>>>
>>>> This MCU implements several functions that will be implemented as MFD driver:
>>>> - watchdog and system reset
>>>> - NVMEM EEPROM
>>>> - HWMON sensors
>>>> - Input/power button
>>>> - and similar low level functions
>>>>
>>>> So in my case DTS binding looks like:
>>>>
>>>> &uart3 {
>>>> 	mcu {
>>>> 		line-speed = <baud rate>;
>>>> 		watchdog {
>>>> 			timeout = <ms>;
>>>> 			...other params...
>>>> 		};
>>>> 		eeprom {
>>>> 			#address-cells
>>>> 			#size-cells
>>>> 			cell1 : cell@1 {
>>>> 				reg = <1 2>;
>>>> 			};
>>>> 			cell2 : cell@2 {
>>>> 				reg = <2 1>;
>>>> 			};
>>>> 		};
>>>> 		hwmon {
>>>> 			sensors-list = "voltage", "current", etc...;
>>>> 		}
>>>> 	}
>>>> }
>>>
>>> With my proposal it would just become
>>>
>>> / {
>>> 	themcu: mcu {
>>> 		uart = <&uart3>;
>>> 		line-speed = <baud rate>;
>>> 		watchdog {
>>> 			timeout = <ms>;
>>> 			...other params...
>>> 		};
>>> 		eeprom {
>>> 			#address-cells
>>> 			#size-cells
>>> 			cell1 : cell@1 {
>>> 				reg = <1 2>;
>>> 			};
>>> 			cell2 : cell@2 {
>>> 				reg = <2 1>;
>>> 			};
>>> 		};
>>> 		hwmon {
>>> 			sensors-list = "voltage", "current", etc...;
>>> 		}
>>> 	}
>>> };
>>>
>>> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
>>>
>>> &themcu {
>>> 	uart = <&uart1>;
>>> };
>>>
>>> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>>>
>>>>
>>>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>>>> It looks like not really a slave though, more like a partnership from data flow point of view.
>>>
>>> Yes!. That is why I started to question the term "slave".
>>>
>>> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>>>
>>>>
>>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>>
>>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
>>>
>>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>>
>>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>>
>>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>>
>>> Thanks for sharing this example.
>>
>>
>> I'd like to see the exemplar slave driver be something more complicated than
>> trivial on-off, before hacking in junk into the serial core.
>>
>> As it stands, this gps could be supported on any uart driver that implements
>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
> 
> in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
> that there is data activity. This is something mctrl can't provide.

A binary state is hardly "meta-data". What is the purpose of the rx notification?


> And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.

Genericity. If this chip needs such a state mechanism, then that should be reflected
generically in gpio support, and we're back to trivial mctrl.


> In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
> forward changes of the mctrl bits to the partner driver.

Please feel free to submit patches for mctrl gpios for the omap-serial driver.


>> Not that I'm against uart slave device support, just that I don't think hacks
>> is the way to go about it.
>>
>> What I'd like to see is a split of the serial core into a tty driver and a
>> standalone device abstraction. Anything else is just workarounds.

I think you misunderstand what I mean by "standalone device abstraction"; let me
be clearer: "standalone UART device abstraction".

Regards,
Peter Hurley

> Here (was rebased from what I had submitted to LKML a while ago):
> 
> 1. serial core (two patches add API for any such partner drivers)
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68
> 
> 2. standalone driver example (using the new API)
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a
> 
> BR and thanks,
> Nikolaus
> 

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 15.01.2016 um 18:43 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 01/15/2016 09:32 AM, H. Nikolaus Schaller wrote:
>> Hi Peter,
>> 
>> Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>>> Hi Andrey,
>>>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>>> 
>>>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>>> 
>>>>> Hi Nikolaus,
>>>>> 
>>>>> H. Nikolaus Schaller wrote:
>>>>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>>>>> for devices connected behind a tty port.
>>>>> 
>>>>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>>>>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>>>> 
>>>>> This MCU implements several functions that will be implemented as MFD driver:
>>>>> - watchdog and system reset
>>>>> - NVMEM EEPROM
>>>>> - HWMON sensors
>>>>> - Input/power button
>>>>> - and similar low level functions
>>>>> 
>>>>> So in my case DTS binding looks like:
>>>>> 
>>>>> &uart3 {
>>>>> 	mcu {
>>>>> 		line-speed = <baud rate>;
>>>>> 		watchdog {
>>>>> 			timeout = <ms>;
>>>>> 			...other params...
>>>>> 		};
>>>>> 		eeprom {
>>>>> 			#address-cells
>>>>> 			#size-cells
>>>>> 			cell1 : cell@1 {
>>>>> 				reg = <1 2>;
>>>>> 			};
>>>>> 			cell2 : cell@2 {
>>>>> 				reg = <2 1>;
>>>>> 			};
>>>>> 		};
>>>>> 		hwmon {
>>>>> 			sensors-list = "voltage", "current", etc...;
>>>>> 		}
>>>>> 	}
>>>>> }
>>>> 
>>>> With my proposal it would just become
>>>> 
>>>> / {
>>>> 	themcu: mcu {
>>>> 		uart = <&uart3>;
>>>> 		line-speed = <baud rate>;
>>>> 		watchdog {
>>>> 			timeout = <ms>;
>>>> 			...other params...
>>>> 		};
>>>> 		eeprom {
>>>> 			#address-cells
>>>> 			#size-cells
>>>> 			cell1 : cell@1 {
>>>> 				reg = <1 2>;
>>>> 			};
>>>> 			cell2 : cell@2 {
>>>> 				reg = <2 1>;
>>>> 			};
>>>> 		};
>>>> 		hwmon {
>>>> 			sensors-list = "voltage", "current", etc...;
>>>> 		}
>>>> 	}
>>>> };
>>>> 
>>>> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
>>>> 
>>>> &themcu {
>>>> 	uart = <&uart1>;
>>>> };
>>>> 
>>>> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>>>> 
>>>>> 
>>>>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>>>>> It looks like not really a slave though, more like a partnership from data flow point of view.
>>>> 
>>>> Yes!. That is why I started to question the term "slave".
>>>> 
>>>> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>>>> 
>>>>> 
>>>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>>> 
>>>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
>>>> 
>>>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>>> 
>>>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>>> 
>>>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>>> 
>>>> Thanks for sharing this example.
>>> 
>>> 
>>> I'd like to see the exemplar slave driver be something more complicated than
>>> trivial on-off, before hacking in junk into the serial core.
>>> 
>>> As it stands, this gps could be supported on any uart driver that implements
>>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>> 
>> in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
>> that there is data activity. This is something mctrl can't provide.
> 
> A binary state is hardly "meta-data". What is the purpose of the rx notification?

the GPS chip can send data when it is not expected.

The bit tells that there is data activity on the data line (RX). Hence I call this "meta-data"
because it is condensed information about other data..

> 
> 
>> And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.
> 
> Genericity. If this chip needs such a state mechanism, then that should be reflected
> generically in gpio support, and we're back to trivial mctrl.

Argh... Sorry.

Should a swiss army knife GPIO driver be the solution for everything that a driver can do by simply
*using* a GPIO?

BTW: we did have a proposal back tree years that made the GPS driver present itself as
a gpio controller with a single gpio.

We called that "virtual gpio". Then we would simply connect the gps driver's
virtual power control gpio to a gpio-mctrl (or dtr-gpio).

This was rejected because a virtual gpio is not a piece of hardware. And the device/driver
is *not* a gpio.

> 
> 
>> In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
>> forward changes of the mctrl bits to the partner driver.
> 
> Please feel free to submit patches for mctrl gpios for the omap-serial driver.

Well, I don't necessarily need mctrl gpios. I need to get RX data activity notifications in addition.

BTW: with our patch you can easily add a generic mctrl driver that works for all serial
drivers. A sketch implementation (tied to a specific gpio based RS232 device) is here:

<http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Documentation/devicetree/bindings/misc/ti%2Ctrs3386.txt;h=0e39ed1a47df9bb7bc747fca66548ff982b19cc5>

Then it is not necessary to implement mctrl for different uart drivers.

> 
> 
>>> Not that I'm against uart slave device support, just that I don't think hacks
>>> is the way to go about it.
>>> 
>>> What I'd like to see is a split of the serial core into a tty driver and a
>>> standalone device abstraction. Anything else is just workarounds.
> 
> I think you misunderstand what I mean by "standalone device abstraction"; let me
> be clearer: "standalone UART device abstraction".

Hm. Sorry, but I still don't understand what you mean and don't know what I should
abstract. Can you please give an example?

> 
> Regards,
> Peter Hurley
> 
>> Here (was rebased from what I had submitted to LKML a while ago):
>> 
>> 1. serial core (two patches add API for any such partner drivers)
>> 
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68
>> 
>> 2. standalone driver example (using the new API)
>> 
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a
>> 
>> BR and thanks,
>> Nikolaus
>> 
> 

Did you look into these patches to understand what we propose?

Best Regards and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 15.01.2016 um 17:12 schrieb Mark Rutland <mark.rutland@arm.com>:

> On Fri, Jan 15, 2016 at 04:05:45PM +0100, H. Nikolaus Schaller wrote:
>> Hi Mark,
>> 
>> Am 15.01.2016 um 12:01 schrieb Mark Rutland <mark.rutland@arm.com>:
>> 
>>> On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Mark,
>>>> 
>>>> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>> 
>>>>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
>>>>>> There is one point still to be solved: the exact style of the DT bindings.
>>>>>> 
>>>>>> We have an idea how a driver can implement two different styles (child node AND phandle)
>>>>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
>>>>> 
>>>>> From my perspective as a binding maintainer, and as I stated before, the
>>>>> child node approach made the most sense and was most consistent with the
>>>> 
>>>>> way we handle other devices.
>>>> 
>>>> I simply don't see that this is the most common way other devices are handled.
>>>> 
>>>> I find many counter-examples which use phandles:
>>>> * gpios
>>>> * regulators
>>>> * iio channels used by other drivers (e.g. iio-hwmon)
>>>> * phy devices
>>>> * timers
>>>> * pwms
>>>> * interrupts
>>>> * dma
>>> 
>>> As was previously described to you, in these cases phandles are used
>>> when these are _resources_ used by another device, not for the main
>>> programmer-visible interface to the device.
>> 
>> Ah, I think I finally begin to understand the rule you are following:
>> 
>> 	If a device's data interface can be seen in user space, this interface
>> 	is sort of a "main interface" and must be modelled in DT by a
>> 	parent-child relationship.
> 
> No, you have misunderstood. This has _nothing_ to do with userspace.

Obviously.

> 
> This has everything to do with the "programmer's interface" as you would
> find documented in a TRM -- effectively where a driver would communicate
> with the device (e.g. MMIO/SPI/I2C registers).

What does that have to do with DT descriptions?

I think we agree that as long as the driver can acquire a handle to the interface
chip (UART, I2C controller etc.) through some driver API, it can communicate
(and encapsulate) everything described by the TRM.

I may have a special case that my devices have no programming interface.

GPS simply starts to send NMEA records (ASCII) and Bluetooth protocol is
a user-space daemon.

So the driver does not want to touch the data. Or generate/consume it. Or write
commands (although it could, since it knows the UART driver instance).

For a typical I2C driver this is different. It reads/writes specific registers by telling
the I2C controller (master / parent) to do that on an address specified by the
child DT node.

> 
> [...]
> 
>> Now I also think I better understand what you meant by "main interface"
>> a while ago.
>> 
>> For me, when looking into a chip data sheet, the main interface is a sometimes
>> arbitrary. Or when viewing it through device driver implementors glasses
>> I may end up with a different main interface.
>> 
>> From the hardware schematics, I can't read which interface is "main". I can
>> only read which components and signals are connected. So the information
>> what is "main" must come from somewhere else, but not the hardware.
>> 
>> You appear to have a definition based on Linux user space interfaces
>> which is distinct from mine and at least explains why the discussion takes
>> so long and we don't come to a common view.
> 
> This is nothing to do with userspace.
> 
> Admittedly, on a device which has multiple slave interfaces, "main" is
> arbitrary. If I've followed correctly, that's not the cae here.

No, we have a single data path and a single power control line.

So the power control line is the "main" interface (described in the TRM of the chip).

And the driver just needs to know that data is coming out of the chip. It does not
need to know which data.

As said, the purpose of this driver is to control power of the chip by monitoring data
stream, controlling the power control input through a gpio and not to modify or use
the data channel like it would be for SPI or I2C.

For example for a touch screen controller the driver sends commands over I2C
and receives position data. This is translated into input events. Power on/off
is usually another I2C command.

It is a completely different situation and supports my view that devices
connected to UARTs should not necessarily be modeled like I2C and SPI
slaves (where there are explicit master / slave roles).

> 
>>> Conceptually, A UART slave is far closer to SPI or I2C, where the slave
>>> is represented as a sub-node.
>> 
>> Only if you have the goal to describe the data/command path ("main interface")
>> in DT.
> 
> This is the way devices are described in DT -- walking from the root to
> a leaf you follow the path from the CPU to a slave interface.

Ok, that is a new piece of DT design guidelines.

But again which path do you exactly mean? User-Data path? Address path?
Command path? Electrical paths? Power enable path? They may not be the same.

> 
> Some things don't have slave interfaces (e.g. fixed-clocks), but still
> need to be referred to, so those still get placed in the DT. There are
> arguments to be had w.r.t. their placement, but that's another
> discussion entirely.
> 
>> I mentioned it several times: USB-PHYs use the phandle approach to attach
>> a single PHY to the usb controller, although there is usually some ULPI-"bus"
>> interface (12 parallel wires) between. And the PHY is clearly more "slave" than
>> the usb controller, isn't it?
> 
> Some PHYs have additional interfaces, so their CPU-visible slave
> interface is described. This necessitates the phandle reference in the
> general case.

> 
>> But with phandle, the usb controller is a _resource_ for the PHY. So would
>> you say this is wrong?
> 
> Not entirely.
> 
>> This is the design pattern (for DT and drivers) we have copied for our tty-slave
>> proposal.
> 
> We have plenty of other ways of describing relationships today. The
> existence of one style (and its continued support for ABI reasons) does
> not mean that it's a style we want to proliferate.

Is there a description about all these style rules? It is really difficult to get them
written down by such lengthy discussions.

> 
>> 
>>> I wasn't aware of any instances of timers being referred to by phandle
>>> by other devices -- that seems distinctly odd. Where do you see that
>>> happening.
>> 
>> I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
>> and that may be a special type of OMAP timers.
> 
> I took a quick look and couldn't spot where that happened. I take it
> the timer was a "ti,omap3430-timer"? Or have I misunderstood?
> 
> What referenced it by phandle? In which dt?

Ah, it is "ti,timer" and not general "timer" introduced recently:

<https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt>

My flaw.

> 
>>>> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)
>>> 
>>> Subsystem type bindings are more of a special case, and regardless the
>>> components have nodes in the relevant portions of the DT.
>> 
>>> 
>>>> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)
>>> 
>>> If this is so different, how is it relevant?
>> 
>> It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
>> isn't grouped there, and uses a phandle to refer to its &mmc "master".
>> 
>> Its function is quite similar what we need for our GPS chip: control power sequences
>> of a remote device.
> 
> That may fit your one particular use-case, but for UART slaves generally
> we should have a kernel driver (which can do more than a trivial
> power-up), at which point you need a node, and the separate sequence
> node is useless.

What we need is similar, the solution is of course not exactly the same.

But why does the DT node have to move (except adding properties)
if the kernel driver does more complex things? It already needs to know
the relationship to the remote device for trivial tasks.

> 
>>>> All of them define the provider in one node. And refer to it by a phandle in another node
>>>> where they are used.
>>>> 
>>>> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.
>>> 
>>> I agree that provider-consumer type relationships are typically
>>> described in this manner.
>> 
>> Ok.
>> 
>>> 
>>> However, master-slave relationships are not.
>> 
>> It looks as if you see a significant difference between provider-consumer and master-slave
>> relationship which I was not sure of which applies to what and where you make the distinction.
>> 
>> By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
>> device a "slave" (except the user-space view)?
> 
> Typically a "slave" accepts commands, and won't send commands of its own
> accord. This case is admittedly fuzzier given that a UART slave could
> send a stream of bytes at any point, but that's data.

It could not only, it does in our case. Which is the main reason why we need a dedicated
driver.

And there are no standardized UART slave commands. Well, GSM07.07 to some extent.
But that is a protocol handled by user space daemons. And commands are completely
mixed with data so that there are escape characters etc.

> 
> The distinction is really that the UART slave won't control other
> devices -- you can think of the entire path of the CPU to the UART as
> the master.

What if there is a plain old terminal device hard wired to the UART?

Here, I would see the user typing commands as "the master" :)
And the data flow is from device to UART to CPU.

Or if the device is an MCU that is connected to a getty login port?

So IMHO we have introduced much of the problem by thinking in "UART slave" categories.

UART seems indeed to be a different beast, because it is more a "partner" thing.

More like a subsystem (maybe audio/sound?) connected to the main CPU by means
of the UART.

> 
>> UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
>> is well defined). Rather, both are formally DTE connected by a null-modem.
>> 
>> This is another substantial difference between UART and I2C/SPI besides addressability.
> 
> Sure, except for the fact that the device attached to the UART logically
> follows a "slave" role. The rest of the system would be usable without
> it, and it assert no control over anything else.

Ok, if you take this view, it is indeed sort of a subordinate. Nothing happens if the
user does not press the power-on button :)

Also to be considered is that the UART is also unusable without the device being
powered on or a partner device being connected.

But we are back to discuss solutions and details and not requirements which makes
this a non-ending story because it is more confusing than bringing it to the key factors.

And please give me some links where all these DT styles and rules are written down.
It would make it easier to develop something that fits, without lengthy discussions.

Or to separately discuss rules.

And, may I repeat my question what I can do to convince you to accept a practical
solution? What could go wrong if you would accept the phandle approach? Which
known UART topic would it not solve or make impossible to solve?

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Peter Hurley]

On 01/15/2016 09:58 AM, H. Nikolaus Schaller wrote:
> 
> Am 15.01.2016 um 18:43 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 01/15/2016 09:32 AM, H. Nikolaus Schaller wrote:
>>> Hi Peter,
>>>
>>> Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>
>>>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>>>> Hi Andrey,
>>>>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>>>>
>>>>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>>>>
>>>>>> Hi Nikolaus,
>>>>>>
>>>>>> H. Nikolaus Schaller wrote:
>>>>>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>>>>>> for devices connected behind a tty port.
>>>>>>
>>>>>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>>>>>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>>>>>
>>>>>> This MCU implements several functions that will be implemented as MFD driver:
>>>>>> - watchdog and system reset
>>>>>> - NVMEM EEPROM
>>>>>> - HWMON sensors
>>>>>> - Input/power button
>>>>>> - and similar low level functions
>>>>>>
>>>>>> So in my case DTS binding looks like:
>>>>>>
>>>>>> &uart3 {
>>>>>> 	mcu {
>>>>>> 		line-speed = <baud rate>;
>>>>>> 		watchdog {
>>>>>> 			timeout = <ms>;
>>>>>> 			...other params...
>>>>>> 		};
>>>>>> 		eeprom {
>>>>>> 			#address-cells
>>>>>> 			#size-cells
>>>>>> 			cell1 : cell@1 {
>>>>>> 				reg = <1 2>;
>>>>>> 			};
>>>>>> 			cell2 : cell@2 {
>>>>>> 				reg = <2 1>;
>>>>>> 			};
>>>>>> 		};
>>>>>> 		hwmon {
>>>>>> 			sensors-list = "voltage", "current", etc...;
>>>>>> 		}
>>>>>> 	}
>>>>>> }
>>>>>
>>>>> With my proposal it would just become
>>>>>
>>>>> / {
>>>>> 	themcu: mcu {
>>>>> 		uart = <&uart3>;
>>>>> 		line-speed = <baud rate>;
>>>>> 		watchdog {
>>>>> 			timeout = <ms>;
>>>>> 			...other params...
>>>>> 		};
>>>>> 		eeprom {
>>>>> 			#address-cells
>>>>> 			#size-cells
>>>>> 			cell1 : cell@1 {
>>>>> 				reg = <1 2>;
>>>>> 			};
>>>>> 			cell2 : cell@2 {
>>>>> 				reg = <2 1>;
>>>>> 			};
>>>>> 		};
>>>>> 		hwmon {
>>>>> 			sensors-list = "voltage", "current", etc...;
>>>>> 		}
>>>>> 	}
>>>>> };
>>>>>
>>>>> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
>>>>>
>>>>> &themcu {
>>>>> 	uart = <&uart1>;
>>>>> };
>>>>>
>>>>> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>>>>>
>>>>>>
>>>>>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>>>>>> It looks like not really a slave though, more like a partnership from data flow point of view.
>>>>>
>>>>> Yes!. That is why I started to question the term "slave".
>>>>>
>>>>> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>>>>>
>>>>>>
>>>>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>>>>
>>>>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
>>>>>
>>>>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>>>>
>>>>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>>>>
>>>>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>>>>
>>>>> Thanks for sharing this example.
>>>>
>>>>
>>>> I'd like to see the exemplar slave driver be something more complicated than
>>>> trivial on-off, before hacking in junk into the serial core.
>>>>
>>>> As it stands, this gps could be supported on any uart driver that implements
>>>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>>>
>>> in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
>>> that there is data activity. This is something mctrl can't provide.
>>
>> A binary state is hardly "meta-data". What is the purpose of the rx notification?
> 
> the GPS chip can send data when it is not expected.

So?

> The bit tells that there is data activity on the data line (RX). Hence I call this "meta-data"
> because it is condensed information about other data..

Again, why does it matter? What do you do with it?
To workaround defective h/w design missing power sense?

I'd rather see a more fully-featured exemplar, to prove that this interface is
sufficiently complete.


>>> And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.
>>
>> Genericity. If this chip needs such a state mechanism, then that should be reflected
>> generically in gpio support, and we're back to trivial mctrl.
> 
> Argh... Sorry.
> 
> Should a swiss army knife GPIO driver be the solution for everything that a driver can do by simply
> *using* a GPIO?

If gpio can support heartbeat, certainly it can support momentary switch?


> BTW: we did have a proposal back tree years that made the GPS driver present itself as
> a gpio controller with a single gpio.
> 
> We called that "virtual gpio". Then we would simply connect the gps driver's
> virtual power control gpio to a gpio-mctrl (or dtr-gpio).
> 
> This was rejected because a virtual gpio is not a piece of hardware. And the device/driver
> is *not* a gpio.

I don't care about things not related to uart.


>>> In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
>>> forward changes of the mctrl bits to the partner driver.
>>
>> Please feel free to submit patches for mctrl gpios for the omap-serial driver.
> 
> Well, I don't necessarily need mctrl gpios. I need to get RX data activity notifications in addition.
> 
> BTW: with our patch you can easily add a generic mctrl driver that works for all serial
> drivers. A sketch implementation (tied to a specific gpio based RS232 device) is here:
> 
> <http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Documentation/devicetree/bindings/misc/ti%2Ctrs3386.txt;h=0e39ed1a47df9bb7bc747fca66548ff982b19cc5>
> 
> Then it is not necessary to implement mctrl for different uart drivers.

Not really. Look at how the imx driver uses mctrl gpios.
Generic support would need to allow the gpio state to vary from the mctrl state.


>>>> Not that I'm against uart slave device support, just that I don't think hacks
>>>> is the way to go about it.
>>>>
>>>> What I'd like to see is a split of the serial core into a tty driver and a
>>>> standalone device abstraction. Anything else is just workarounds.
>>
>> I think you misunderstand what I mean by "standalone device abstraction"; let me
>> be clearer: "standalone UART device abstraction".
> 
> Hm. Sorry, but I still don't understand what you mean and don't know what I should
> abstract. Can you please give an example?

How will this support a Bluetooth uart slave without a userspace tool?
One that needs to load firmware.

How will it support multiple channels over the same uart to different
slaves (ala TI's Shared Transport)?

A uart slave driver should load independently and open a serial device
(optionally exclusively) and operate without userspace/tty at all.


>>> Here (was rebased from what I had submitted to LKML a while ago):
>>>
>>> 1. serial core (two patches add API for any such partner drivers)
>>>
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68
>>>
>>> 2. standalone driver example (using the new API)
>>>
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a
>>>
>>> BR and thanks,
>>> Nikolaus
>>>
>>
> 
> Did you look into these patches to understand what we propose?

Yes.

The open-coding of uart initialization in uart_register_rx_notification()
was particularly ugly. That's a good example of what needs abstracting.

And why does the generic concept of rx_notification() imply that the slave
device does not expect shutdown when commanded? That seems very specific to
the broken h/w design of this device, and not what most slave device drivers
would expect. Not that I'm suggesting you refine this approach.

And the whole idea of not performing device shutdown when commanded is broken.

Maybe some of this design was outlined in the cover letter?


On 10/16/2015 11:08 AM, H. Nikolaus Schaller wrote:
> H. Nikolaus Schaller (3):
>   tty: serial core: provide a method to search uart by phandle
>   tty: serial_core: add hooks for uart slave drivers
>   misc: Add w2sg0004 gps receiver driver
> 
>  .../devicetree/bindings/misc/wi2wi,w2sg0004.txt    |  18 +
>  .../devicetree/bindings/serial/slaves.txt          |  16 +
>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>  Documentation/serial/slaves.txt                    |  36 ++
>  drivers/misc/Kconfig                               |  18 +
>  drivers/misc/Makefile                              |   1 +
>  drivers/misc/w2sg0004.c                            | 443 +++++++++++++++++++++
>  drivers/tty/serial/serial_core.c                   | 214 +++++++++-
>  include/linux/serial_core.h                        |  25 +-
>  include/linux/w2sg0004.h                           |  27 ++
>  10 files changed, 793 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>  create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
>  create mode 100644 Documentation/serial/slaves.txt
>  create mode 100644 drivers/misc/w2sg0004.c
>  create mode 100644 include/linux/w2sg0004.h


Hmmm, nope.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

On Fri 2016-01-15 10:34:51, H. Nikolaus Schaller wrote:
> Hi Mark,
> 
> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> 
> > On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Tomeu,
> >> 
> >> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:
> >> 
> >>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
> >>>> Hi all,
> >>>> here is version 4 of my "UART slave device" patch set, previously
> >>>> known as "tty slave devices".
> >>> 
> >>> Hi Neil,
> >>> 
> >>> do you (or someone else) have plans to continue this work in the short
> >>> or medium term?
> >> 
> >> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:
> >> 
> >> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>
> >> 
> >> There is one point still to be solved: the exact style of the DT bindings.
> >> 
> >> We have an idea how a driver can implement two different styles (child node AND phandle)
> >> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
> > 
> > From my perspective as a binding maintainer, and as I stated before, the
> > child node approach made the most sense and was most consistent with the
> 
> > way we handle other devices.
> 
> I simply don't see that this is the most common way other devices
> are handled.

You promised to shut up once maintainers speak, that happened, and you
did not shut up. Just do it now.

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 15.01.2016 um 20:40 schrieb Pavel Machek <pavel@ucw.cz>:

> On Fri 2016-01-15 10:34:51, H. Nikolaus Schaller wrote:
>> Hi Mark,
>> 
>> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>> 
>>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Tomeu,
>>>> 
>>>> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>:
>>>> 
>>>>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote:
>>>>>> Hi all,
>>>>>> here is version 4 of my "UART slave device" patch set, previously
>>>>>> known as "tty slave devices".
>>>>> 
>>>>> Hi Neil,
>>>>> 
>>>>> do you (or someone else) have plans to continue this work in the short
>>>>> or medium term?
>>>> 
>>>> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0:
>>>> 
>>>> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4>
>>>> 
>>>> There is one point still to be solved: the exact style of the DT bindings.
>>>> 
>>>> We have an idea how a driver can implement two different styles (child node AND phandle)
>>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
>>> 
>>> From my perspective as a binding maintainer, and as I stated before, the
>>> child node approach made the most sense and was most consistent with the
>> 
>>> way we handle other devices.
>> 
>> I simply don't see that this is the most common way other devices
>> are handled.
> 
> You promised to shut up once maintainers speak, that happened, and you
> did not shut up. Just do it now.

Nobody has asked for your unqualified and not helpful comments.

So please shut up yourself and stop to disturb Free Software projects.

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Peter,

Am 15.01.2016 um 20:23 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 01/15/2016 09:58 AM, H. Nikolaus Schaller wrote:
>> 
>> Am 15.01.2016 um 18:43 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 01/15/2016 09:32 AM, H. Nikolaus Schaller wrote:
>>>> Hi Peter,
>>>> 
>>>> Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>> 
>>>>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>>>>> Hi Andrey,
>>>>>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>>>>> 
>>>>>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>>>>> 
>>>>>>> Hi Nikolaus,
>>>>>>> 
>>>>>>> H. Nikolaus Schaller wrote:
>>>>>>>> And IMHO nobody has described that he/she needs a solution to model the*data*  relationship
>>>>>>>> for devices connected behind a tty port.
>>>>>>> 
>>>>>>> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
>>>>>>> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>>>>>>> 
>>>>>>> This MCU implements several functions that will be implemented as MFD driver:
>>>>>>> - watchdog and system reset
>>>>>>> - NVMEM EEPROM
>>>>>>> - HWMON sensors
>>>>>>> - Input/power button
>>>>>>> - and similar low level functions
>>>>>>> 
>>>>>>> So in my case DTS binding looks like:
>>>>>>> 
>>>>>>> &uart3 {
>>>>>>> 	mcu {
>>>>>>> 		line-speed = <baud rate>;
>>>>>>> 		watchdog {
>>>>>>> 			timeout = <ms>;
>>>>>>> 			...other params...
>>>>>>> 		};
>>>>>>> 		eeprom {
>>>>>>> 			#address-cells
>>>>>>> 			#size-cells
>>>>>>> 			cell1 : cell@1 {
>>>>>>> 				reg = <1 2>;
>>>>>>> 			};
>>>>>>> 			cell2 : cell@2 {
>>>>>>> 				reg = <2 1>;
>>>>>>> 			};
>>>>>>> 		};
>>>>>>> 		hwmon {
>>>>>>> 			sensors-list = "voltage", "current", etc...;
>>>>>>> 		}
>>>>>>> 	}
>>>>>>> }
>>>>>> 
>>>>>> With my proposal it would just become
>>>>>> 
>>>>>> / {
>>>>>> 	themcu: mcu {
>>>>>> 		uart = <&uart3>;
>>>>>> 		line-speed = <baud rate>;
>>>>>> 		watchdog {
>>>>>> 			timeout = <ms>;
>>>>>> 			...other params...
>>>>>> 		};
>>>>>> 		eeprom {
>>>>>> 			#address-cells
>>>>>> 			#size-cells
>>>>>> 			cell1 : cell@1 {
>>>>>> 				reg = <1 2>;
>>>>>> 			};
>>>>>> 			cell2 : cell@2 {
>>>>>> 				reg = <2 1>;
>>>>>> 			};
>>>>>> 		};
>>>>>> 		hwmon {
>>>>>> 			sensors-list = "voltage", "current", etc...;
>>>>>> 		}
>>>>>> 	}
>>>>>> };
>>>>>> 
>>>>>> Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
>>>>>> 
>>>>>> &themcu {
>>>>>> 	uart = <&uart1>;
>>>>>> };
>>>>>> 
>>>>>> With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>>>>>> 
>>>>>>> 
>>>>>>> This MCU receives commands and notifies MFD driver about events via UART protocol.
>>>>>>> It looks like not really a slave though, more like a partnership from data flow point of view.
>>>>>> 
>>>>>> Yes!. That is why I started to question the term "slave".
>>>>>> 
>>>>>> And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>>>>>> 
>>>>>>> 
>>>>>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>>>>> 
>>>>>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c. 
>>>>>> 
>>>>>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>>>>> 
>>>>>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>>>>> 
>>>>>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>>>>> 
>>>>>> Thanks for sharing this example.
>>>>> 
>>>>> 
>>>>> I'd like to see the exemplar slave driver be something more complicated than
>>>>> trivial on-off, before hacking in junk into the serial core.
>>>>> 
>>>>> As it stands, this gps could be supported on any uart driver that implements
>>>>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>>>> 
>>>> in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
>>>> that there is data activity. This is something mctrl can't provide.
>>> 
>>> A binary state is hardly "meta-data". What is the purpose of the rx notification?
>> 
>> the GPS chip can send data when it is not expected.
> 
> So?

Yes. It is simply not possible for a driver to know if the chip is enabled
or disabled at boot time. So the chip might or might not send data
when the driver is being probed.

And sending a turn-on/off impulse does just change the state, but the
driver still can't know.

It can only detect this state if the chip sends data when the driver
does not expect. So it knows that its assumption about the power
state is wrong. Then it can effectively skip one impulse and the
driver's assumption and the chip are in sync.

> 
>> The bit tells that there is data activity on the data line (RX). Hence I call this "meta-data"
>> because it is condensed information about other data..
> 
> Again, why does it matter? What do you do with it?
> To workaround defective h/w design missing power sense?

It is not defective. It is designed that way. Probably for a standalone
use case where a real push button allows the operator to turn it on
or off. And she can see if NMEA records are received and push the
button if needed.

And our driver must essentially do the same. Monitor the RX line
and push the button if there is data when nobody wants to have it
("ah, that thing has not been turned off by the previous crew"). 

The designers probably didn't think that monitoring the RX line is
a problem for an MCU.

> 
> I'd rather see a more fully-featured exemplar, to prove that this interface is
> sufficiently complete.

Which features are you missing?

> 
> 
>>>> And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.
>>> 
>>> Genericity. If this chip needs such a state mechanism, then that should be reflected
>>> generically in gpio support, and we're back to trivial mctrl.
>> 
>> Argh... Sorry.
>> 
>> Should a swiss army knife GPIO driver be the solution for everything that a driver can do by simply
>> *using* a GPIO?
> 
> If gpio can support heartbeat, certainly it can support momentary switch?

Yes it can. Could even simplify the driver implementation a little. But it does not solve
the unknown power state issue.

> 
>> BTW: we did have a proposal back tree years that made the GPS driver present itself as
>> a gpio controller with a single gpio.
>> 
>> We called that "virtual gpio". Then we would simply connect the gps driver's
>> virtual power control gpio to a gpio-mctrl (or dtr-gpio).
>> 
>> This was rejected because a virtual gpio is not a piece of hardware. And the device/driver
>> is *not* a gpio.
> 
> I don't care about things not related to uart.

? me = puzzled

You just explained to me that I should use a gpio to connect to the mctrl to control the device.
Then I tell that we have proposed that and it was rejected. And you answer that you don't care
about it.

> 
> 
>>>> In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
>>>> forward changes of the mctrl bits to the partner driver.
>>> 
>>> Please feel free to submit patches for mctrl gpios for the omap-serial driver.
>> 
>> Well, I don't necessarily need mctrl gpios. I need to get RX data activity notifications in addition.
>> 
>> BTW: with our patch you can easily add a generic mctrl driver that works for all serial
>> drivers. A sketch implementation (tied to a specific gpio based RS232 device) is here:
>> 
>> <http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Documentation/devicetree/bindings/misc/ti%2Ctrs3386.txt;h=0e39ed1a47df9bb7bc747fca66548ff982b19cc5>
>> 
>> Then it is not necessary to implement mctrl for different uart drivers.
> 
> Not really. Look at how the imx driver uses mctrl gpios.

Yes, I know there is serial_mctrl_gpio.c but it is to be called by the device specific UART
driver and not by the general serial-core layer.

But I didn't find it being used by drivers/tty/serial/imx.c

> Generic support would need to allow the gpio state to vary from the mctrl state.

Maybe I need a little more explanation when this should happen.
If a gpio is to represent the RTS or DTR line, why should it not be set as defined by mctrl
which is changed by tcsetattr/ioctl?

> 
> 
>>>>> Not that I'm against uart slave device support, just that I don't think hacks
>>>>> is the way to go about it.
>>>>> 
>>>>> What I'd like to see is a split of the serial core into a tty driver and a
>>>>> standalone device abstraction. Anything else is just workarounds.
>>> 
>>> I think you misunderstand what I mean by "standalone device abstraction"; let me
>>> be clearer: "standalone UART device abstraction".
>> 
>> Hm. Sorry, but I still don't understand what you mean and don't know what I should
>> abstract. Can you please give an example?
> 
> 1. How will this support a Bluetooth uart slave without a userspace tool?
> One that needs to load firmware.
> 
> 2. How will it support multiple channels over the same uart to different
> slaves (ala TI's Shared Transport)?
> 
> 3. A uart slave driver should load independently and open a serial device
> (optionally exclusively) and operate without userspace/tty at all.

Ok, this is a good list of additional requirements and of course finally, an acceptable
solution should cover them as well. Not necessarily in a first step but in a second.

So let's go through them an look how they fit into our proposed driver code.

First of all. the driver can get a handle to the struct uart_port by
calling devm_serial_get_uart_by_phandle().

1. It should be possible to export a wrapper for __uart_put_char() so that the
device driver can send bytes of the firmware to the UART it knows about.

2. the driver can already add a rx_notification function to handle received characters.
It can decide if they should go to the tty layer or not. 

In this case they should not go to the tty layer but should be queued up in the
individual rx transport queues.

If the tx transport queues have new data, the driver can send the characters through
the same mechanism as in 1.

So the driver can communicate with the connected device and it can implement and
encapsulate the shared transport (or other) protocols.

How it presents the multiple channels (another set of UARTs?) is completely up to the
driver and no influenced by the hooks into serial-core.

So lets try a drawing:

device <--> uart <--> serial-core <-- new hooks ---> device driver <---> protocol interfaces

The most complex part will probably be to handle locking correctly.

3. this needs a little more study and deeper rework of the tty/serial interaction.

It is an area that I do not completely understand and have not researched in
detail, because I do not (yet) have a need for it.

The main component is probably attaching some "do-not-present-as-tty" DT property
to the UART DT node and prevent the tty layer from presenting a /dev/tty*.

This may need patches for the tty layer. So far we do neither touch the tty layer driver
nor any of the SoC specific uart drivers. We just hook into serial-core.c

I just stumbled about this article which helps (certainly not you, but me and other readers)
to understand what we are talking about. 

http://www.linuxjournal.com/article/6331

> 
> 
>>>> Here (was rebased from what I had submitted to LKML a while ago):
>>>> 
>>>> 1. serial core (two patches add API for any such partner drivers)
>>>> 
>>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
>>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68
>>>> 
>>>> 2. standalone driver example (using the new API)
>>>> 
>>>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a
>>>> 
>>>> BR and thanks,
>>>> Nikolaus
>>>> 
>>> 
>> 
>> Did you look into these patches to understand what we propose?
> 
> Yes.

Ok, and sorry for assuming anything else.

> 
> The open-coding of uart initialization in uart_register_rx_notification()
> was particularly ugly. That's a good example of what needs abstracting.

It is because I did not want to break anything in the serial-core driver
and therefore wanted to keep the patches as non-invasive as possible.

And some parts of UART-initialization are ugly before we added anything...
This just tries to copy the initialization sequence.

But discussing implementation details makes only sense if the general
principle is agreed on. Then I am happy to work on such improvements
and code can be refactored of course, if requested but is something
where I need help not to break existing things.

it also needs test cases and much more work which would IMHO hide
the basic concept if we do it upfront.

> And why does the generic concept of rx_notification() imply that the slave
> device does not expect shutdown when commanded?

If a driver is opened, and any notification is registered, the UART is opened.
And as soon as all notifications are removed it is shut down.

In between it should not be shutdown even if user-space does an open()
and close(). Therefore we have to disable the calls to shutdown in this
case.

The reason is that a protocol engine (and I see the GPS RX line monitoring
and gpio impulse generation as a very simple protocol engine) must keep
the connection to the device "alive".

> That seems very specific to
> the broken h/w design of this device, and not what most slave device drivers
> would expect. Not that I'm suggesting you refine this approach.

No, it is not specific. It is very general. As long as a driver needs the UART,
the UART is not shut down.

> And the whole idea of not performing device shutdown when commanded is broken.

As soon as neither the device driver nor a tty port needs the UART any more, it is shut down.

> 
> Maybe some of this design was outlined in the cover letter?

Yes it was.

If I remember correctly there was one occasion where the cover letter was lost by a
glitch.

I immediately recognized that this would create confusion but it was too late and
I could not do anything else than send it again:

https://lkml.org/lkml/2015/10/16/786

> 
> 
> On 10/16/2015 11:08 AM, H. Nikolaus Schaller wrote:
>> H. Nikolaus Schaller (3):
>>  tty: serial core: provide a method to search uart by phandle
>>  tty: serial_core: add hooks for uart slave drivers
>>  misc: Add w2sg0004 gps receiver driver
>> 
>> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt    |  18 +
>> .../devicetree/bindings/serial/slaves.txt          |  16 +
>> .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>> Documentation/serial/slaves.txt                    |  36 ++
>> drivers/misc/Kconfig                               |  18 +
>> drivers/misc/Makefile                              |   1 +
>> drivers/misc/w2sg0004.c                            | 443 +++++++++++++++++++++
>> drivers/tty/serial/serial_core.c                   | 214 +++++++++-
>> include/linux/serial_core.h                        |  25 +-
>> include/linux/w2sg0004.h                           |  27 ++
>> 10 files changed, 793 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
>> create mode 100644 Documentation/serial/slaves.txt
>> create mode 100644 drivers/misc/w2sg0004.c
>> create mode 100644 include/linux/w2sg0004.h
> 
> 
> Hmmm, nope.
> 
> Regards,
> Peter Hurley

Best regards and thanks for the good comments,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Rob Herring]

On Fri, Jan 15, 2016 at 11:16 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>> Hi Andrey,
>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>
>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>
>>> Hi Nikolaus,
>>>
>>> H. Nikolaus Schaller wrote:

[...]

>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>
>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c.
>>
>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>
>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>
>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>
>> Thanks for sharing this example.
>
>
> I'd like to see the exemplar slave driver be something more complicated than
> trivial on-off, before hacking in junk into the serial core.
>
> As it stands, this gps could be supported on any uart driver that implements
> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>
> Not that I'm against uart slave device support, just that I don't think hacks
> is the way to go about it.

I assume line disciplines seemed a good solution at the time, but they
seem like a hack to me.

> What I'd like to see is a split of the serial core into a tty driver and a
> standalone device abstraction. Anything else is just workarounds.

+1 on that. We need a proper subsystem for in kernel drivers of
connected UART devices.

The kernel is where all the work is, not the DT bindings, so we should
spend our time on the kernel side. There's already a fairly clean
split between serial core and tty layer, so it should be possible to
use serial core without too much surgery to all the UART drivers.

Rob

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Vostrikov Andrey]

Hi, Rob.

> On Fri, Jan 15, 2016 at 11:16 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>> Hi Andrey,
>>> ah that is fine to learn about another project that needs some solution (however it will look like).
>>>
>>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
>>>
>>>> Hi Nikolaus,
>>>>
>>>> H. Nikolaus Schaller wrote:

> [...]

>>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
>>>
>>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c.
>>>
>>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
>>>
>>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
>>>
>>> As you see, I have a driver-specific standpoint (and not coming from user space).
>>>
>>> Thanks for sharing this example.
>>
>>
>> I'd like to see the exemplar slave driver be something more complicated than
>> trivial on-off, before hacking in junk into the serial core.
>>
>> As it stands, this gps could be supported on any uart driver that implements
>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>>
>> Not that I'm against uart slave device support, just that I don't think hacks
>> is the way to go about it.

> I assume line disciplines seemed a good solution at the time, but they
> seem like a hack to me.
What would be best implementation in following use case:
- there are several microcontrollers/devices that use same protocol on top of UART (<STX>-<DATA>-<CRC>-<ETX>)
- microcontoller could provide several functions to system, e.g. watchdog, HWMON etc., that not require user space interaction
- there are several implementations of firmware that use different commands/events transferred as <DATA> and different <CRC> algorithms installed on several HW variants

If we take picture from Nikolaus's email:
device <--> uart <--> serial-core <-- new hooks ---> device driver <---> protocol interfaces

It would be nice to have a layer such as line discipline between serial core and device driver to use high level API to transfer data via UART.
But current implementation of line disciplines is intended to be used from user space and via tty layer.

>> What I'd like to see is a split of the serial core into a tty driver and a
>> standalone device abstraction. Anything else is just workarounds.

> +1 on that. We need a proper subsystem for in kernel drivers of
> connected UART devices.

Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space.
Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'.

> The kernel is where all the work is, not the DT bindings, so we should
> spend our time on the kernel side. There's already a fairly clean
> split between serial core and tty layer, so it should be possible to
> use serial core without too much surgery to all the UART drivers.

> Rob



-- 
Best regards,
Andrey Vostrikov

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Rob Herring]

On Sat, Jan 16, 2016 at 10:34:45AM +0300, Vostrikov Andrey wrote:
> Hi, Rob.
> 
> > On Fri, Jan 15, 2016 at 11:16 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> >> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
> >>> Hi Andrey,
> >>> ah that is fine to learn about another project that needs some solution (however it will look like).
> >>>
> >>> Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:
> >>>
> >>>> Hi Nikolaus,
> >>>>
> >>>> H. Nikolaus Schaller wrote:
> 
> > [...]
> 
> >>>> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
> >>>
> >>> Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c.
> >>>
> >>> We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
> >>>
> >>> In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
> >>>
> >>> As you see, I have a driver-specific standpoint (and not coming from user space).
> >>>
> >>> Thanks for sharing this example.
> >>
> >>
> >> I'd like to see the exemplar slave driver be something more complicated than
> >> trivial on-off, before hacking in junk into the serial core.
> >>
> >> As it stands, this gps could be supported on any uart driver that implements
> >> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
> >>
> >> Not that I'm against uart slave device support, just that I don't think hacks
> >> is the way to go about it.
> 
> > I assume line disciplines seemed a good solution at the time, but they
> > seem like a hack to me.
> What would be best implementation in following use case:
> - there are several microcontrollers/devices that use same protocol on top of UART (<STX>-<DATA>-<CRC>-<ETX>)
> - microcontoller could provide several functions to system, e.g. watchdog, HWMON etc., that not require user space interaction
> - there are several implementations of firmware that use different commands/events transferred as <DATA> and different <CRC> algorithms installed on several HW variants

Yes, and combo chips with BT, FM radio and/or NFC muxed on UART port are 
quite common.

> If we take picture from Nikolaus's email:
> device <--> uart <--> serial-core <-- new hooks ---> device driver <---> protocol interfaces
> 
> It would be nice to have a layer such as line discipline between serial core and device driver to use high level API to transfer data via UART.
> But current implementation of line disciplines is intended to be used from user space and via tty layer.

We'll probably need to support some sort of layers or plugins to 
provide both muxing and protocol support. Even in the single function 
case, we'll need to be able to have BT chip driver and generic BT HCI 
protocol modules.

> >> What I'd like to see is a split of the serial core into a tty driver and a
> >> standalone device abstraction. Anything else is just workarounds.
> 
> > +1 on that. We need a proper subsystem for in kernel drivers of
> > connected UART devices.
> 
> Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space.
> Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'.

I looked at serio a bit to see if it could be used or expanded. There is 
the line discipline, but then there are serial drivers which connect to 
serio (or tty layer) directly. The SUN serial ports and keyboard are an 
example IIRC. That may have been the only one... I found that serio is 
pretty limited and doesn't provide much of a starting point. It's 
functionality could be rolled into some new though.

Rob

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi,

Am 17.01.2016 um 00:31 schrieb Rob Herring <robh@kernel.org>:

> On Sat, Jan 16, 2016 at 10:34:45AM +0300, Vostrikov Andrey wrote:
>> What would be best implementation in following use case:
>> - there are several microcontrollers/devices that use same protocol on top of UART (<STX>-<DATA>-<CRC>-<ETX>)
>> - microcontoller could provide several functions to system, e.g. watchdog, HWMON etc., that not require user space interaction
>> - there are several implementations of firmware that use different commands/events transferred as <DATA> and different <CRC> algorithms installed on several HW variants
> 
> Yes, and combo chips with BT, FM radio and/or NFC muxed on UART port are 
> quite common.

Indeed. Which raises another DT modelling question: should each component
have its own node (and individual compatible string) or should there be a node
for the whole combo chip. And is it the child of MMC/SDIO or of the UART?

But let's postpone this difficult thing.

> 
>> If we take picture from Nikolaus's email:
>> device <--> uart <--> serial-core <-- new hooks ---> device driver <---> protocol interfaces
>> 
>>> +1 on that. We need a proper subsystem for in kernel drivers of
>>> connected UART devices.
>> 
>> Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space.
>> Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'.
> 
> I looked at serio a bit to see if it could be used or expanded. There is 
> the line discipline, but then there are serial drivers which connect to 
> serio (or tty layer) directly. The SUN serial ports and keyboard are an 
> example IIRC. That may have been the only one... I found that serio is 
> pretty limited and doesn't provide much of a starting point. It's 
> functionality could be rolled into some new though.

I think the best location is serial-core.c. It connects the tty layer with the SoC
specific uart drivers.

So the picture of data/control flow looks like:

user-space <-> /dev/TTY* <-> tty layer <-+
                                         +--> serial-core.c  <-> UART hardware driver <-> null-modem <-> UART <-> peer MCU
peer device driver <---------------------+

This needs a new peer device API for device drivers which is provided
by the serial core.

When translating the system requirements you have provided and mixing
with mine, I think we need:

1. mechanism to receive characters sent by the peer MCU
2. mechanism to send characters to the peer (or a block for firmware download)
3. mechanism to open/close the UART (even if there is no user space/tty client)
4. mechanism to set the struct termios of the UART (baud rate etc.)
5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl
6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all

Then, we just need a normal device driver for the peer device (you can call
it "plugin"). This driver module can implement all needed state engines
I am aware of (power control, packetization, multiplexing).

Is anything missing?

Our implementation proposal from October already solves parts of this (1, 3, 4, 5)
and I have now some ideas how the missing ones could easily be added.

So please give me some days to develop it a little to post a patch set
which includes sketches for the extensions. And I want to add a blueprint for
a driver for the more complex situation with firmware download & protocol engine.

But please note that I will not be able to test sending of characters, since
none of my drivers or peer devices needs that or can handle.

Therefore the code will not be tested and sometimes just a sketch to
transport the idea. It will need quite some work and help to get it stabilized.

Regards and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> When translating the system requirements you have provided and mixing
> with mine, I think we need:
> 
> 1. mechanism to receive characters sent by the peer MCU

Low level driver queue of some kind

> 2. mechanism to send characters to the peer (or a block for firmware download)

Ditto (maybe even netlink)

> 3. mechanism to open/close the UART (even if there is no user space/tty client)

So don't use the tty layer in the first place

> 4. mechanism to set the struct termios of the UART (baud rate etc.)

Can be done without the tty layer.

> 5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl
> 6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all

This sounds the wrong way up entirely.

Instead of trying to make the tty layer do weird stuff, make the driver
present a tty that is only the things that it wants to be exposed as a
tty if any. If there are none then don't use the tty layer at all.

We have lots of interfaces to random MCUs. Many of them talk "serial"
protocols, almost none of them pretend to be the tty layer.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 17.01.2016 um 15:19 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>> When translating the system requirements you have provided and mixing
>> with mine, I think we need:
>> 
>> 1. mechanism to receive characters sent by the peer MCU
> 
> Low level driver queue of some kind

Yes, could be useful. Depends on what the peer drivers need.

Some might just have a simple state engine so that they can
process each character as it is incoming and place it into
one of several receive queues managed by the driver. So they
do not need a central queue for incoming characters.

> 
>> 2. mechanism to send characters to the peer (or a block for firmware download)
> 
> Ditto (maybe even netlink)

I haven't yet coded anything for that requirement but the UART already appears to
have a TX queue. So it should suffice to append the characters to it and they are
queued up.

> 
>> 3. mechanism to open/close the UART (even if there is no user space/tty client)
> 
> So don't use the tty layer in the first place

For the implementation I propose, we aren't using the tty layer in the first place. We
use the struct uart_port which is a glue layer in serial-core.c

I think I should reformulate this requirement (we need it for our GPS chip driver):

3. mechanism to open/close the UART by the peer driver (for power management of the
UART), even if it there is a user-space tty client for the same UART which might or might
not be open at any time. Manage that in an optimal way.

For the GPS chip I am only interested in mctrl and if characters are received. But
I still want them to arrive at user space through a standard tty interface. So a solution
that does not interwork and cooperate with the tty layer is not a useable solution for
my requirements.

> 
>> 4. mechanism to set the struct termios of the UART (baud rate etc.)
> 
> Can be done without the tty layer.

Yes, our implementation does it without. A struct termios is passed down to the
UART hardware driver which translates it into clock divider settings etc. but
ignores some fields. This is the way it is already done today for tcsetattr() after
rippling down through higher level layers:

http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L458

> 
>> 5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl
>> 6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all
> 
> This sounds the wrong way up entirely.
> 
> Instead of trying to make the tty layer do weird stuff, make the driver
> present a tty that is only the things that it wants to be exposed as a
> tty if any. If there are none then don't use the tty layer at all.

The reason appears to sit here:

http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725

This means that as soon as some UART is successfully probed, a new tty
interface is created for it. So we simply have to optionally disable it. This is
described by requirement 6.

Sounds easier to me than rearranging the whole tty / serial-core stuff.
I prefer to leave that really big task as an exercise to someone else...

> 
> We have lots of interfaces to random MCUs. Many of them talk "serial"
> protocols, almost none of them pretend to be the tty layer.

If there are may devices (I assume you think of a serial mouse or touchscreen
for example) that can be implemented to talk "serial", they still can do,
should do and do not need to use this new API. It is not intended to be
a replacement for mature and good solutions.

But we have some cases where we need it because we can't get the
problems solved at higher layers.

This layer is also chosen with execution speed in mind. The closer to the
hardware driver, the faster it is. But it should not touch the ~50 different
UART drivers we have and work with any of them. This is why I think
serial-core and struct uart_port is the right level. Even if it looks like a hack.

So please wait until I have updated the patch set of our proposal. Then you
can see that we do not directly touch the tty layer.

Thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> 3. mechanism to open/close the UART by the peer driver (for power management of the
> UART), even if it there is a user-space tty client for the same UART which might or might
> not be open at any time. Manage that in an optimal way.

Power management doesn't have to go via the uart layer. You can even
manage it via the existing sysfs power interfaces (and some Android
devices do in fact do exactly that either by controlling the uart pm or
using a gpio line). Not pretty either but means people are only peeing
in their own backyard. What goes into the kernel costs *everyone*, what
goes in device user space costs only the perpetrator.

It would help to rewind and understand what your needs are not what your
implementation as it stands is. Why can't you just use hciattach like
everyone else ? Improving the PM logic by refining the existing hci
ldisc to be power smart so everyone benefits from any improvement might
be a useful other discussion.

The 8686 is already working in serial mode  with no kernel hackery on
other boards.

> For the GPS chip I am only interested in mctrl and if characters are received. But
> I still want them to arrive at user space through a standard tty interface. So a solution
> that does not interwork and cooperate with the tty layer is not a useable solution for
> my requirements.

Why does it matter how they arrive so long as your user space can
interpret it correctly. Or is your user space some proprietary blob you
can't change ?

Them arriving by a tty interface is fine - no issue with that providing
it doesn't need to mess up core code.

> The reason appears to sit here:
> 
> http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725
> 
> This means that as soon as some UART is successfully probed, a new tty
> interface is created for it. So we simply have to optionally disable it. This is
> described by requirement 6.

You can just report EBUSY in your open method. You don't need to touch
the serial core layer. It's quite sufficient to do

	if (busy)
		return -EBUSY;

at the top of your uart open method.

> UART drivers we have and work with any of them. This is why I think
> serial-core and struct uart_port is the right level. Even if it looks like a hack.

Your "looks like" instinct is IMHO bang on - looks like a hack, is a
hack. It's also unnecessary as you can hide it in your open method if you
must do that.

> So please wait until I have updated the patch set of our proposal. Then you
> can see that we do not directly touch the tty layer.

The uart layer is part of the tty layer. It's just a glue library to make
writing some tty drivers a bit easier. It's tied deeply to the tty_port
implementation. One day it might even cease to exist replaced by more
generic tty_port helpers.

The tty layer is also an *abstract* concept. There is no real world tie
between physical collections of shift registers that dribble bits to one
another and tty devices in the kernel. You only need a tty driver for
certain types of user interaction.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 17.01.2016 um 20:38 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>> 3. mechanism to open/close the UART by the peer driver (for power management of the
>> UART), even if it there is a user-space tty client for the same UART which might or might
>> not be open at any time. Manage that in an optimal way.
> 
> Power management doesn't have to go via the uart layer. You can even
> manage it via the existing sysfs power interfaces (and some Android
> devices do in fact do exactly that either by controlling the uart pm or
> using a gpio line). Not pretty either but means people are only peeing
> in their own backyard. What goes into the kernel costs *everyone*, what
> goes in device user space costs only the perpetrator.
> 
> It would help to rewind and understand what your needs are not what your
> implementation as it stands is. Why can't you just use hciattach like
> everyone else ? Improving the PM logic by refining the existing hci
> ldisc to be power smart so everyone benefits from any improvement might
> be a useful other discussion.

I have not counted how often I have explained that, but I am happy to do it
again.

* the GTA04 device is an open hackable smartphone platform where power saving is highest priority
* the platform includes the kernel, but we don't want to prescribe any specific user space (i.e. we can't assume that a specific daemon exists or can't modify it)
* the wi2wi,w2sg0084 chip is a GPS chip (it does not understand HCI protocol, it just sends NMEA records if powered on)
* we want to provide NMEA data through /dev/ttyO1 (it uses an OMAP UART) because a tty port is the most common interface for GPS devices (e.g. a bluetooth GPS mouse is also presented as a tty)
* we want the chip to automatically power up as soon (but not before) as any gps client opens /dev/ttyO1 (or activates the DTR mctrl)
* we want the chip to automatically power down if no process uses /dev/ttyO1 any more

The standard logic of GPS daemons and applications is to receive
NMEA records through some serial /dev/tty.

Please tell me how power on/off management can be done without intercepting
somewhere in the kernel that /dev/ttyO1 is opened/closed (which is not the same
as suspend/resume).

Secondly, the chip has a very special logic that it may end up in the opposite
power state than the kernel driver thinks. Especially after boot it simply can not
know the state. The chip might be powered up/send records or might not.

A driver can only detect such a discrepancy if it thinks the GPS chip is powered off,
but there is still data coming through the UART.

Please tell me how this situation can be detected without monitoring the data stream
in the kernel going to /dev/ttyO1 - from the UART behind it - even if /dev/ttyO1 is closed.

This are *our* requirements.

Other people think that our approach helps to solve their driver architecture as well
and have added their requirements on top. This is why I attempt to make the API
more general than just for our own use-cases.

> 
> The 8686 is already working in serial mode  with no kernel hackery on
> other boards.

You appear to mix the chips we are talking about. We have the w2sg0084 gps
chip and a w2cbw003, which is a combo of an 8686 and a CSR BT serial device.

Both chips need somehow to be powered on or off if not used. Ideally automatically
at the moment no user space client is using them any more. For the bluetooth side
the moment to power off is when a hciattach is killed.

Other 8686 boards appear not to have such critical power restrictions and then they
just leave power on.

> 
>> For the GPS chip I am only interested in mctrl and if characters are received. But
>> I still want them to arrive at user space through a standard tty interface. So a solution
>> that does not interwork and cooperate with the tty layer is not a useable solution for
>> my requirements.
> 
> Why does it matter how they arrive so long as your user space can
> interpret it correctly. Or is your user space some proprietary blob you
> can't change ?

No, the opposite: it can be any open source application, which by principle
could be changed in any way. But we can't because we as the hardware
platform+kernel developers have no (and don't want to have) control over
the the user space. So we have to fit into the standards of the user space.

> 
> Them arriving by a tty interface is fine - no issue with that providing
> it doesn't need to mess up core code.

You appear to assume that the tty port is always open and there is
a background daemon running.

Here, we need to solve the problem to power down the chip if NO
tty port is open any more.

We simply don't see a solution for this outside the kernel and inside without
touching the UART code. Although there have been many very skilled
developers involved in the past 3 years to get what we need into the
mainline kernel. There had been proposals for approx. 3 or 4 different
architectures which were all rejected for good reasons and the current
one is the one which tries to overcome all known objections and of
course raises new questions.

> 
>> The reason appears to sit here:
>> 
>> http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725
>> 
>> This means that as soon as some UART is successfully probed, a new tty
>> interface is created for it. So we simply have to optionally disable it. This is
>> described by requirement 6.
> 
> You can just report EBUSY in your open method. You don't need to touch
> the serial core layer. It's quite sufficient to do
> 
> 	if (busy)
> 		return -EBUSY;
> 
> at the top of your uart open method.

Hm. I am not writing a new UART driver or touch them. I am using the existing
ones (omap-serial). They all call this uart_add_one_port() in their probe() function.

If I would modify just omap-serial, people would for sure complain that the solution
is not generic enough.

> 
>> UART drivers we have and work with any of them. This is why I think
>> serial-core and struct uart_port is the right level. Even if it looks like a hack.
> 
> Your "looks like" instinct is IMHO bang on - looks like a hack, is a
> hack.

It is not *my* instinct that says "looks like". It was:

1. meant to be read as "Even if it looks like a hack to the uninformed reader of the patch"
2. it was said by some reviewer

For me it is not a hack, it is a well thought logical consequence of the requirements
combined with the current code architecture as it exists (which often looks like a hack to me)
and the goal to make changes as non-intrusive as possible.

> It's also unnecessary as you can hide it in your open method if you
> must do that.

Creating tty ports is not *my* open method. It is part of the way all system
UARTs are initialized. So I can't handle this case in *my* open method, because
I have none that is tty_port related.

> 
>> So please wait until I have updated the patch set of our proposal. Then you
>> can see that we do not directly touch the tty layer.
> 
> The uart layer is part of the tty layer. It's just a glue library to make
> writing some tty drivers a bit easier.

Yes, and exactly that is helpful to solve this problem. We attach only to the
glue layer and everything is done.

> It's tied deeply to the tty_port
> implementation. One day it might even cease to exist replaced by more
> generic tty_port helpers.

Is there a concrete plan to change that? Is anyone working on it now?

If not, I would not worry about this, because it is not specific to the problem
we want to solve today (to be precise: since 3 years).

But even if it is changed, there must always be some glue between UARTs
and tty_port helpers. So it can't disappear - it can only change in structure..

> The tty layer is also an *abstract* concept. There is no real world tie
> between physical collections of shift registers that dribble bits to one
> another and tty devices in the kernel. You only need a tty driver for
> certain types of user interaction.

And we need it to process the GPS data by standard applications and tools.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andrey Vostrikov]

Hi,

H. Nikolaus Schaller wrote:
> Hi Alan,
>
> Am 17.01.2016 um 20:38 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
>
>>> 3. mechanism to open/close the UART by the peer driver (for power management of the
>>> UART), even if it there is a user-space tty client for the same UART which might or might
>>> not be open at any time. Manage that in an optimal way.
>> Power management doesn't have to go via the uart layer. You can even
>> manage it via the existing sysfs power interfaces (and some Android
>> devices do in fact do exactly that either by controlling the uart pm or
>> using a gpio line). Not pretty either but means people are only peeing
>> in their own backyard. What goes into the kernel costs *everyone*, what
>> goes in device user space costs only the perpetrator.
>>
>> It would help to rewind and understand what your needs are not what your
>> implementation as it stands is. Why can't you just use hciattach like
>> everyone else ? Improving the PM logic by refining the existing hci
>> ldisc to be power smart so everyone benefits from any improvement might
>> be a useful other discussion.
> I have not counted how often I have explained that, but I am happy to do it
> again.
>
> * the GTA04 device is an open hackable smartphone platform where power saving is highest priority
> * the platform includes the kernel, but we don't want to prescribe any specific user space (i.e. we can't assume that a specific daemon exists or can't modify it)
> * the wi2wi,w2sg0084 chip is a GPS chip (it does not understand HCI protocol, it just sends NMEA records if powered on)
> * we want to provide NMEA data through /dev/ttyO1 (it uses an OMAP UART) because a tty port is the most common interface for GPS devices (e.g. a bluetooth GPS mouse is also presented as a tty)
> * we want the chip to automatically power up as soon (but not before) as any gps client opens /dev/ttyO1 (or activates the DTR mctrl)
> * we want the chip to automatically power down if no process uses /dev/ttyO1 any more
>
> The standard logic of GPS daemons and applications is to receive
> NMEA records through some serial /dev/tty.
>
> Please tell me how power on/off management can be done without intercepting
> somewhere in the kernel that /dev/ttyO1 is opened/closed (which is not the same
> as suspend/resume).
>
> Secondly, the chip has a very special logic that it may end up in the opposite
> power state than the kernel driver thinks. Especially after boot it simply can not
> know the state. The chip might be powered up/send records or might not.
>
> A driver can only detect such a discrepancy if it thinks the GPS chip is powered off,
> but there is still data coming through the UART.
>
> Please tell me how this situation can be detected without monitoring the data stream
> in the kernel going to /dev/ttyO1 - from the UART behind it - even if /dev/ttyO1 is closed.
>
> This are *our* requirements.
>
> Other people think that our approach helps to solve their driver architecture as well
> and have added their requirements on top. This is why I attempt to make the API
> more general than just for our own use-cases.
In my case, I have an MCU that sits behind UART and provides several low-level functions, that should be exposed via well-known API (Watchdog, NVMEM, HWMON, LEDs, input, etc)
* MCU is connected via dedicated UART on SoC.
* port should not be exposed to user space via tty layer (impossible now, as soon as port driver is registered, tty layer will create /dev/tty* device for it)
* MCU should be probed as soon as possible without 'open' call from user space that is usually done by 'Xattach' app/daemon
* it is needed to configure UART speed and have some abstraction layer for data transfer (same as line discipline, but in kernel only)

As there is no concept as UART BUS (even if it is point to point) there is no way right now to make this happen.
Just a thought, would it be a good idea to use 'device_type' attribute in device tree to differentiate port type, i.e. whether it should be treated as normal serial port or as UART BUS?
for example:
uart1 {
     device_type = "serial";
     ...
};
uart2 {
     device_type = "serial_bus";
     ..
};

>> The 8686 is already working in serial mode  with no kernel hackery on
>> other boards.
> You appear to mix the chips we are talking about. We have the w2sg0084 gps
> chip and a w2cbw003, which is a combo of an 8686 and a CSR BT serial device.
>
> Both chips need somehow to be powered on or off if not used. Ideally automatically
> at the moment no user space client is using them any more. For the bluetooth side
> the moment to power off is when a hciattach is killed.
>
> Other 8686 boards appear not to have such critical power restrictions and then they
> just leave power on.
>
>>> For the GPS chip I am only interested in mctrl and if characters are received. But
>>> I still want them to arrive at user space through a standard tty interface. So a solution
>>> that does not interwork and cooperate with the tty layer is not a useable solution for
>>> my requirements.
>> Why does it matter how they arrive so long as your user space can
>> interpret it correctly. Or is your user space some proprietary blob you
>> can't change ?
> No, the opposite: it can be any open source application, which by principle
> could be changed in any way. But we can't because we as the hardware
> platform+kernel developers have no (and don't want to have) control over
> the the user space. So we have to fit into the standards of the user space.
>
>> Them arriving by a tty interface is fine - no issue with that providing
>> it doesn't need to mess up core code.
> You appear to assume that the tty port is always open and there is
> a background daemon running.
>
> Here, we need to solve the problem to power down the chip if NO
> tty port is open any more.
>
> We simply don't see a solution for this outside the kernel and inside without
> touching the UART code. Although there have been many very skilled
> developers involved in the past 3 years to get what we need into the
> mainline kernel. There had been proposals for approx. 3 or 4 different
> architectures which were all rejected for good reasons and the current
> one is the one which tries to overcome all known objections and of
> course raises new questions.
>
>>> The reason appears to sit here:
>>>
>>> http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725
>>>
>>> This means that as soon as some UART is successfully probed, a new tty
>>> interface is created for it. So we simply have to optionally disable it. This is
>>> described by requirement 6.
>> You can just report EBUSY in your open method. You don't need to touch
>> the serial core layer. It's quite sufficient to do
>>
>> 	if (busy)
>> 		return -EBUSY;
>>
>> at the top of your uart open method.
> Hm. I am not writing a new UART driver or touch them. I am using the existing
> ones (omap-serial). They all call this uart_add_one_port() in their probe() function.
>
> If I would modify just omap-serial, people would for sure complain that the solution
> is not generic enough.
>
>>> UART drivers we have and work with any of them. This is why I think
>>> serial-core and struct uart_port is the right level. Even if it looks like a hack.
>> Your "looks like" instinct is IMHO bang on - looks like a hack, is a
>> hack.
> It is not *my* instinct that says "looks like". It was:
>
> 1. meant to be read as "Even if it looks like a hack to the uninformed reader of the patch"
> 2. it was said by some reviewer
>
> For me it is not a hack, it is a well thought logical consequence of the requirements
> combined with the current code architecture as it exists (which often looks like a hack to me)
> and the goal to make changes as non-intrusive as possible.
>
>> It's also unnecessary as you can hide it in your open method if you
>> must do that.
> Creating tty ports is not *my* open method. It is part of the way all system
> UARTs are initialized. So I can't handle this case in *my* open method, because
> I have none that is tty_port related.
>
>>> So please wait until I have updated the patch set of our proposal. Then you
>>> can see that we do not directly touch the tty layer.
>> The uart layer is part of the tty layer. It's just a glue library to make
>> writing some tty drivers a bit easier.
> Yes, and exactly that is helpful to solve this problem. We attach only to the
> glue layer and everything is done.
>
>> It's tied deeply to the tty_port
>> implementation. One day it might even cease to exist replaced by more
>> generic tty_port helpers.
> Is there a concrete plan to change that? Is anyone working on it now?
>
> If not, I would not worry about this, because it is not specific to the problem
> we want to solve today (to be precise: since 3 years).
>
> But even if it is changed, there must always be some glue between UARTs
> and tty_port helpers. So it can't disappear - it can only change in structure..
>
>> The tty layer is also an *abstract* concept. There is no real world tie
>> between physical collections of shift registers that dribble bits to one
>> another and tty devices in the kernel. You only need a tty driver for
>> certain types of user interaction.
> And we need it to process the GPS data by standard applications and tools.
>
> BR,
> Nikolaus
>
Best regards,
Andrey

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> I have not counted how often I have explained that, but I am happy to do it
> again.
> 
> * the GTA04 device is an open hackable smartphone platform where power saving is highest priority

Yep I did real the manual before replying last time.

> * the wi2wi,w2sg0084 chip is a GPS chip (it does not understand HCI protocol, it just sends NMEA records if powered on)
> * we want to provide NMEA data through /dev/ttyO1 (it uses an OMAP UART) because a tty port is the most common interface for GPS devices (e.g. a bluetooth GPS mouse is also presented as a tty)
> * we want the chip to automatically power up as soon (but not before) as any gps client opens /dev/ttyO1 (or activates the DTR mctrl)
> * we want the chip to automatically power down if no process uses /dev/ttyO1 any more
> The standard logic of GPS daemons and applications is to receive
> NMEA records through some serial /dev/tty.
> 
> Please tell me how power on/off management can be done without intercepting
> somewhere in the kernel that /dev/ttyO1 is opened/closed (which is not the same
> as suspend/resume).

Your user space can do it (as most Android does).

> Secondly, the chip has a very special logic that it may end up in the opposite
> power state than the kernel driver thinks. Especially after boot it simply can not
> know the state. The chip might be powered up/send records or might not.
> 
> A driver can only detect such a discrepancy if it thinks the GPS chip is powered off,
> but there is still data coming through the UART.

To play devils advocate a moment: so can user space.

> Please tell me how this situation can be detected without monitoring the data stream
> in the kernel going to /dev/ttyO1 - from the UART behind it - even if /dev/ttyO1 is closed.
> 
> This are *our* requirements.

The Linux kernel runs on billions of devices. If we put kernel hooks in
random glue layers for every weird little platform corner case it would
collapse in a heap. Those are *our* requirements. Thus it is good to push
back on stuff that can be done in user space just as well.

> Other people think that our approach helps to solve their driver architecture as well
> and have added their requirements on top. This is why I attempt to make the API
> more general than just for our own use-cases.

If it's going to be generic then it needs to be dealing with this at the
tty/tty_port level not uart. uart isn't a general serial abstraction,
tty_port and tty are. uart is just a helper library for some types of
port.

In practise that ought to be a small distinction. If you have to bind
some kind of device logic to the port activation/deactivation then bind
it to tty_port not uart. uart open/close is basically an implementation
of the tty port->ops->activate() and port->ops->shutdown() method.

> 
> > 
> > The 8686 is already working in serial mode  with no kernel hackery on
> > other boards.
> 
> You appear to mix the chips we are talking about. We have the w2sg0084 gps
> chip and a w2cbw003, which is a combo of an 8686 and a CSR BT serial device.
> 
> Both chips need somehow to be powered on or off if not used. Ideally automatically
> at the moment no user space client is using them any more. For the bluetooth side
> the moment to power off is when a hciattach is killed.
> 
> Other 8686 boards appear not to have such critical power restrictions and then they
> just leave power on.

The ones I am familiar with either have the userspace managing it via
sysfs (which has some latency advantages when doing clever stuff) or
wired the power control to the carrier signal (or that is declared the
gpio that controls it to be the carrier).

> No, the opposite: it can be any open source application, which by principle
> could be changed in any way. But we can't because we as the hardware
> platform+kernel developers have no (and don't want to have) control over
> the the user space. So we have to fit into the standards of the user space.

Well the standard of user space today *is* managing via sysfs or the
carrier trick. Take a look at all the Android devices out there - they
all tackle it that way. Some of them do very aggressive power management
as you can imagine. But yes that's ugly 8)

> Here, we need to solve the problem to power down the chip if NO
> tty port is open any more.

port->ops->shutdown in the tty layer.

> > You can just report EBUSY in your open method. You don't need to touch
> > the serial core layer. It's quite sufficient to do
> > 
> > 	if (busy)
> > 		return -EBUSY;
> > 
> > at the top of your uart open method.
> 
> Hm. I am not writing a new UART driver or touch them. I am using the existing
> ones (omap-serial). They all call this uart_add_one_port() in their probe() function.

At the moment. But they may not, or they may get folded together.

> If I would modify just omap-serial, people would for sure complain that the solution
> is not generic enough.

I would say two things

1. If you modify omap-serial it's not that generic, but it doesn't mess
with library code it shouldn't. That is better than messing with uart
layer code. It also solves your problem and localises the solution. That
to me is a win.

2. If not then hook tty_port_shutdown() and tty_port_open() because those
are the right abstraction point. Everything in the kernel that is a tty
is a tty_port.

> > The uart layer is part of the tty layer. It's just a glue library to make
> > writing some tty drivers a bit easier.
> 
> Yes, and exactly that is helpful to solve this problem. We attach only to the
> glue layer and everything is done.

It's the wrong place - it's not the abstraction.

What I am trying to say is that if you do this generically then add the
needed method calls into tty_port_open and tty_port_shutdown, make them
run after port->ops->activate and before port->ops->shutdown so there is
a sensible ordering if you need to do something to the port itself, and
also so on open it only runs if port->ops->activate succeeded.

Something like

       if (!test_bit(ASYNCB_INITIALIZED, &port->flags)) {
                clear_bit(TTY_IO_ERROR, &tty->flags);
                if (port->ops->activate) {
                        int retval = port->ops->activate(port, tty);
                        if (retval) {
                                mutex_unlock(&port->mutex);
                                return retval;
                        }
                }
		/* Wake the device if we have one tied to us */
		if (port->ops->activate_slave)
			port->ops->activate_slave(port, tty);
                set_bit(ASYNCB_INITIALIZED, &port->flags);
	}

Then all you need is the (possibly device specific) small patches to check
the device tree for the bindings on init, and if so set the port->ops
methods according to the binding.

> > It's tied deeply to the tty_port
> > implementation. One day it might even cease to exist replaced by more
> > generic tty_port helpers.
> 
> Is there a concrete plan to change that? Is anyone working on it now?

Nobody wants to lose the ability to do so or to move stuff around.

> If not, I would not worry about this, because it is not specific to the problem
> we want to solve today (to be precise: since 3 years).

You solve it today you block other things for the next 20 years. The
kernel has to deal in long terms.

> > The tty layer is also an *abstract* concept. There is no real world tie
> > between physical collections of shift registers that dribble bits to one
> > another and tty devices in the kernel. You only need a tty driver for
> > certain types of user interaction.
> 
> And we need it to process the GPS data by standard applications and tools.

Ok - no problem with that, and for what you've explained that bit makes
sense.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi,

Am 18.01.2016 um 09:56 schrieb Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>:

> Hi,
> 
> H. Nikolaus Schaller wrote:
>> Hi Alan,
>> 
>> Am 17.01.2016 um 20:38 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
>> 
>>>> 3. mechanism to open/close the UART by the peer driver (for power management of the
>>>> UART), even if it there is a user-space tty client for the same UART which might or might
>>>> not be open at any time. Manage that in an optimal way.
>>> Power management doesn't have to go via the uart layer. You can even
>>> manage it via the existing sysfs power interfaces (and some Android
>>> devices do in fact do exactly that either by controlling the uart pm or
>>> using a gpio line). Not pretty either but means people are only peeing
>>> in their own backyard. What goes into the kernel costs *everyone*, what
>>> goes in device user space costs only the perpetrator.
>>> 
>>> It would help to rewind and understand what your needs are not what your
>>> implementation as it stands is. Why can't you just use hciattach like
>>> everyone else ? Improving the PM logic by refining the existing hci
>>> ldisc to be power smart so everyone benefits from any improvement might
>>> be a useful other discussion.
>> I have not counted how often I have explained that, but I am happy to do it
>> again.
>> 
>> * the GTA04 device is an open hackable smartphone platform where power saving is highest priority
>> * the platform includes the kernel, but we don't want to prescribe any specific user space (i.e. we can't assume that a specific daemon exists or can't modify it)
>> * the wi2wi,w2sg0084 chip is a GPS chip (it does not understand HCI protocol, it just sends NMEA records if powered on)
>> * we want to provide NMEA data through /dev/ttyO1 (it uses an OMAP UART) because a tty port is the most common interface for GPS devices (e.g. a bluetooth GPS mouse is also presented as a tty)
>> * we want the chip to automatically power up as soon (but not before) as any gps client opens /dev/ttyO1 (or activates the DTR mctrl)
>> * we want the chip to automatically power down if no process uses /dev/ttyO1 any more
>> 
>> The standard logic of GPS daemons and applications is to receive
>> NMEA records through some serial /dev/tty.
>> 
>> Please tell me how power on/off management can be done without intercepting
>> somewhere in the kernel that /dev/ttyO1 is opened/closed (which is not the same
>> as suspend/resume).
>> 
>> Secondly, the chip has a very special logic that it may end up in the opposite
>> power state than the kernel driver thinks. Especially after boot it simply can not
>> know the state. The chip might be powered up/send records or might not.
>> 
>> A driver can only detect such a discrepancy if it thinks the GPS chip is powered off,
>> but there is still data coming through the UART.
>> 
>> Please tell me how this situation can be detected without monitoring the data stream
>> in the kernel going to /dev/ttyO1 - from the UART behind it - even if /dev/ttyO1 is closed.
>> 
>> This are *our* requirements.
>> 
>> Other people think that our approach helps to solve their driver architecture as well
>> and have added their requirements on top. This is why I attempt to make the API
>> more general than just for our own use-cases.
> In my case, I have an MCU that sits behind UART and provides several low-level functions, that should be exposed via well-known API (Watchdog, NVMEM, HWMON, LEDs, input, etc)
> * MCU is connected via dedicated UART on SoC.
> * port should not be exposed to user space via tty layer (impossible now, as soon as port driver is registered, tty layer will create /dev/tty* device for it)

That is what I want to optionally disable in uart_add_one_port().

> * MCU should be probed as soon as possible without 'open' call from user space that is usually done by 'Xattach' app/daemon

in our proposed solution some uart peer is probed as early as possible. It then tries to attach to the UART. If the UART has not yet been successfully probed, a -EPROBE_DEFER is returned and the MCU probe can be deferred as well. This does not need an open() call from user space to work.

> * it is needed to configure UART speed and have some abstraction layer for data transfer (same as line discipline, but in kernel only)
> 
> As there is no concept as UART BUS (even if it is point to point) there is no way right now to make this happen.
> Just a thought, would it be a good idea to use 'device_type' attribute in device tree to differentiate port type, i.e. whether it should be treated as normal serial port or as UART BUS?
> for example:
> uart1 {
>    device_type = "serial";
>    ...
> };
> uart2 {
>    device_type = "serial_bus";
>    ..
> };

My proposal for this will be something like (I haven't decided myself on this)

uart2 {
	hide-tty-port;
};

or

uart2 {
	peer-mode;
};

or

uart2 {
	dedicated;
};

but the result is the same and the exact property name and value can be discussed later on.

> 
>>> The 8686 is already working in serial mode  with no kernel hackery on
>>> other boards.
>> You appear to mix the chips we are talking about. We have the w2sg0084 gps
>> chip and a w2cbw003, which is a combo of an 8686 and a CSR BT serial device.
>> 
>> Both chips need somehow to be powered on or off if not used. Ideally automatically
>> at the moment no user space client is using them any more. For the bluetooth side
>> the moment to power off is when a hciattach is killed.
>> 
>> Other 8686 boards appear not to have such critical power restrictions and then they
>> just leave power on.
>> 
>>>> For the GPS chip I am only interested in mctrl and if characters are received. But
>>>> I still want them to arrive at user space through a standard tty interface. So a solution
>>>> that does not interwork and cooperate with the tty layer is not a useable solution for
>>>> my requirements.
>>> Why does it matter how they arrive so long as your user space can
>>> interpret it correctly. Or is your user space some proprietary blob you
>>> can't change ?
>> No, the opposite: it can be any open source application, which by principle
>> could be changed in any way. But we can't because we as the hardware
>> platform+kernel developers have no (and don't want to have) control over
>> the the user space. So we have to fit into the standards of the user space.
>> 
>>> Them arriving by a tty interface is fine - no issue with that providing
>>> it doesn't need to mess up core code.
>> You appear to assume that the tty port is always open and there is
>> a background daemon running.
>> 
>> Here, we need to solve the problem to power down the chip if NO
>> tty port is open any more.
>> 
>> We simply don't see a solution for this outside the kernel and inside without
>> touching the UART code. Although there have been many very skilled
>> developers involved in the past 3 years to get what we need into the
>> mainline kernel. There had been proposals for approx. 3 or 4 different
>> architectures which were all rejected for good reasons and the current
>> one is the one which tries to overcome all known objections and of
>> course raises new questions.
>> 
>>>> The reason appears to sit here:
>>>> 
>>>> http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725
>>>> 
>>>> This means that as soon as some UART is successfully probed, a new tty
>>>> interface is created for it. So we simply have to optionally disable it. This is
>>>> described by requirement 6.
>>> You can just report EBUSY in your open method. You don't need to touch
>>> the serial core layer. It's quite sufficient to do
>>> 
>>> 	if (busy)
>>> 		return -EBUSY;
>>> 
>>> at the top of your uart open method.
>> Hm. I am not writing a new UART driver or touch them. I am using the existing
>> ones (omap-serial). They all call this uart_add_one_port() in their probe() function.
>> 
>> If I would modify just omap-serial, people would for sure complain that the solution
>> is not generic enough.
>> 
>>>> UART drivers we have and work with any of them. This is why I think
>>>> serial-core and struct uart_port is the right level. Even if it looks like a hack.
>>> Your "looks like" instinct is IMHO bang on - looks like a hack, is a
>>> hack.
>> It is not *my* instinct that says "looks like". It was:
>> 
>> 1. meant to be read as "Even if it looks like a hack to the uninformed reader of the patch"
>> 2. it was said by some reviewer
>> 
>> For me it is not a hack, it is a well thought logical consequence of the requirements
>> combined with the current code architecture as it exists (which often looks like a hack to me)
>> and the goal to make changes as non-intrusive as possible.
>> 
>>> It's also unnecessary as you can hide it in your open method if you
>>> must do that.
>> Creating tty ports is not *my* open method. It is part of the way all system
>> UARTs are initialized. So I can't handle this case in *my* open method, because
>> I have none that is tty_port related.
>> 
>>>> So please wait until I have updated the patch set of our proposal. Then you
>>>> can see that we do not directly touch the tty layer.
>>> The uart layer is part of the tty layer. It's just a glue library to make
>>> writing some tty drivers a bit easier.
>> Yes, and exactly that is helpful to solve this problem. We attach only to the
>> glue layer and everything is done.
>> 
>>> It's tied deeply to the tty_port
>>> implementation. One day it might even cease to exist replaced by more
>>> generic tty_port helpers.
>> Is there a concrete plan to change that? Is anyone working on it now?
>> 
>> If not, I would not worry about this, because it is not specific to the problem
>> we want to solve today (to be precise: since 3 years).
>> 
>> But even if it is changed, there must always be some glue between UARTs
>> and tty_port helpers. So it can't disappear - it can only change in structure..
>> 
>>> The tty layer is also an *abstract* concept. There is no real world tie
>>> between physical collections of shift registers that dribble bits to one
>>> another and tty devices in the kernel. You only need a tty driver for
>>> certain types of user interaction.
>> And we need it to process the GPS data by standard applications and tools.
>> 
>> BR,
>> Nikolaus
>> 
> Best regards,
> Andrey

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 18.01.2016 um 12:19 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>> I have not counted how often I have explained that, but I am happy to do it
>> again.
>> 
>> * the GTA04 device is an open hackable smartphone platform where power saving is highest priority
> 
> Yep I did real the manual before replying last time.

That is good to know, because it allows to refer to it if necessary.

> 
>> * the wi2wi,w2sg0084 chip is a GPS chip (it does not understand HCI protocol, it just sends NMEA records if powered on)
>> * we want to provide NMEA data through /dev/ttyO1 (it uses an OMAP UART) because a tty port is the most common interface for GPS devices (e.g. a bluetooth GPS mouse is also presented as a tty)
>> * we want the chip to automatically power up as soon (but not before) as any gps client opens /dev/ttyO1 (or activates the DTR mctrl)
>> * we want the chip to automatically power down if no process uses /dev/ttyO1 any more
>> The standard logic of GPS daemons and applications is to receive
>> NMEA records through some serial /dev/tty.
>> 
>> Please tell me how power on/off management can be done without intercepting
>> somewhere in the kernel that /dev/ttyO1 is opened/closed (which is not the same
>> as suspend/resume).
> 
> Your user space can do it (as most Android does).

How can it do it in automatically in a standardized way without need for daemon support?

> 
>> Secondly, the chip has a very special logic that it may end up in the opposite
>> power state than the kernel driver thinks. Especially after boot it simply can not
>> know the state. The chip might be powered up/send records or might not.
>> 
>> A driver can only detect such a discrepancy if it thinks the GPS chip is powered off,
>> but there is still data coming through the UART.
> 
> To play devils advocate a moment: so can user space.

* how can it be done without permanently running a daemon that monitors RX data (/dev/tty*)
and attaches to some /sysfs control?
* how can the daemon present another /dev/tty so that applications expecting such
an interface can attach to it (maybe through pty - but isn't that an overkill?)
* Who makes sure that this daemon is installed and running right after boot up on *any* Linux system
so that it can always react in case that the chip did start when it should be off?

More generally: what is a kernel good for? Why do we need kernel drivers?

You can do almost everything in user space if you want to: we can expose
every wire to /sys/class/gpio and clever user space daemons can bitbang on
them to implement any protocol.

Well, only in theory: this is too slow and needs too much energy because the CPU
runs at 100%.

Just think about waking up the daemon process if a character is received. This is
much more costly than calling a notification function in the kernel driver which might
have to execute just 4 or 5 assembler instructions to decide what to do.

So kernel drivers are sometimes the best solution and more efficient and controllable
than a user space daemon.

That is why we propose a kernel solution for this problem.

> 
>> Please tell me how this situation can be detected without monitoring the data stream
>> in the kernel going to /dev/ttyO1 - from the UART behind it - even if /dev/ttyO1 is closed.
>> 
>> This are *our* requirements.
> 
> The Linux kernel runs on billions of devices. If we put kernel hooks in
> random glue layers for every weird little platform corner case it would
> collapse in a heap. Those are *our* requirements. Thus it is good to push
> back on stuff that can be done in user space just as well.

I understand that. But what is Linux good for? For it's own sake or for
users and platforms using it? Isn't it that we take it from the community
and contribute improvements back to it?

And it appears that this is not a little platform corner case but there is some
more general need for drivers to access the UART layer and not a higher level
abstraction. The networking stack also has mechanisms to access all layers
because not everything can be done on every layer (some functions of
lower layers are hidden when accessing higher layers - e.g. you can't
get the Ethernet MAC from the TCP/socket layer) and it might be more
performant to directly go to a lower layer.

So to me it appears that such a kernel feature is missing. Therefore we
are discussing it.

> 
>> Other people think that our approach helps to solve their driver architecture as well
>> and have added their requirements on top. This is why I attempt to make the API
>> more general than just for our own use-cases.
> 
> If it's going to be generic then it needs to be dealing with this at the
> tty/tty_port level not uart. uart isn't a general serial abstraction,
> tty_port and tty are.

well I think most driver projects that have expressed that they want to have
such a solution just want an UART abstraction and not a general tty/serial
interface with all bells and whistles.

> uart is just a helper library for some types of
> port.

Yes, this is the type of port, our peer devices are directly connected to.

> In practise that ought to be a small distinction. If you have to bind
> some kind of device logic to the port activation/deactivation then bind
> it to tty_port not uart. uart open/close is basically an implementation
> of the tty port->ops->activate() and port->ops->shutdown() method.

I am not sure if that still exists for UART based tty_ports (but I am not
understanding everything of the tty layer and have not followed recent
changes since I have focussed on the uart_port and serial-core):

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/serial_core.c?id=9e31364fc3272073ec8c5fac18a3e01d4f013418

Independently of that, doing the port open/close could work that way, if
it were the only topic to be solved.

But we need several components to make everything we need work.

All of them need to be present.

Another question if we discuss moving the hooks into the tty_port layer:

is it possible from tty layer to activate the UART without a user-space open()
and keep it activated after a close()?

> 
>> 
>>> 
>>> The 8686 is already working in serial mode  with no kernel hackery on
>>> other boards.
>> 
>> You appear to mix the chips we are talking about. We have the w2sg0084 gps
>> chip and a w2cbw003, which is a combo of an 8686 and a CSR BT serial device.
>> 
>> Both chips need somehow to be powered on or off if not used. Ideally automatically
>> at the moment no user space client is using them any more. For the bluetooth side
>> the moment to power off is when a hciattach is killed.
>> 
>> Other 8686 boards appear not to have such critical power restrictions and then they
>> just leave power on.
> 
> The ones I am familiar with either have the userspace managing it via
> sysfs (which has some latency advantages when doing clever stuff) or
> wired the power control to the carrier signal (or that is declared the
> gpio that controls it to be the carrier).

How many of these special drivers are in mainline? Our target is to get full support
by mainline and not run our own kernel branch forever. Because we are not
yet-another-android-thing-that-just-needs-to-work-for-6-months-and-nobody-cares-
about-updates-and-GPL.

In all mainlining attempts I know, the user-space control approach was rejected
because it was said that the kernel should take care of and not a /sysfs or some
other artificial protocol.

Especially as the information when to power on the chip is already known inside the
kernel and does not need a new side-band control mechanism. Other similar (GPS)
devices don't need it as well. This makes our devices unnecessarily a big exception
on user-side, especially as we have proven that it can be solved inside the kernel.

We just have not found an architecture that is accepted by mainline.

Some years ago all this started with this proposal:
* make the driver expose an gpio
* use mctrl-gpios for the DTR line
* connect them in device tree

http://neil.brown.name/blog/20120724060722

This was rejected because a chip driver is not a gpio controller and virtual gpios
are not gpios. In other words: sysfs managing and its related device tree representation
was rejected for mainlining as well.

But anyway, it would not solve the device RX data stream monitoring problem.
It just could be a solution to know when to turn the chip on or off.

Neil's proposal to monitor the RX line was rejected because it was doing
nasty tricks with switching pinmux states and setting a temporary interrupt
on the UART RX line.

Therefore we now want to monitor the RX line "behind" the UART, i.e. on the
byte stream coming from the UART shift registers.

This did lead to tty/uart slaves concept and everybody wanted it. Now as we
have code proposals it should go back to become a user space daemon...

> 
>> No, the opposite: it can be any open source application, which by principle
>> could be changed in any way. But we can't because we as the hardware
>> platform+kernel developers have no (and don't want to have) control over
>> the the user space. So we have to fit into the standards of the user space.
> 
> Well the standard of user space today *is* managing via sysfs or the
> carrier trick. Take a look at all the Android devices out there - they
> all tackle it that way. Some of them do very aggressive power management
> as you can imagine. But yes that's ugly 8)

And these solutions are not mainline. Or is any of these?

> 
>> Here, we need to solve the problem to power down the chip if NO
>> tty port is open any more.
> 
> port->ops->shutdown in the tty layer.
> 
>>> You can just report EBUSY in your open method. You don't need to touch
>>> the serial core layer. It's quite sufficient to do
>>> 
>>> 	if (busy)
>>> 		return -EBUSY;
>>> 
>>> at the top of your uart open method.
>> 
>> Hm. I am not writing a new UART driver or touch them. I am using the existing
>> ones (omap-serial). They all call this uart_add_one_port() in their probe() function.
> 
> At the moment. But they may not, or they may get folded together.

Are they? If you have a clear plan for changes, we can update our hooks to what
you have planned.

Otherwise we are digging in the dark.

> 
>> If I would modify just omap-serial, people would for sure complain that the solution
>> is not generic enough.
> 
> I would say two things
> 
> 1. If you modify omap-serial it's not that generic, but it doesn't mess
> with library code it shouldn't.

And tomorrow comes someone who connects the same chip to an i.MX.
Next week to a Samsung SoC. Every time we add the same patches
to the device specific UART driver.

> That is better than messing with uart
> layer code. It also solves your problem and localises the solution. That
> to me is a win.


Neil had proposed that a while ago and there was code in the kernel, but it
was removed last year, because it is not general enough and we did not
get the driver into mainline that would have used it: 985bfd54

> 
> 2. If not then hook tty_port_shutdown() and tty_port_open() because those
> are the right abstraction point. Everything in the kernel that is a tty
> is a tty_port.

What is in your view the right abstraction point for a peer device driver to get
notified about rx characters (even if the tty is currently not open)?

> 
>>> The uart layer is part of the tty layer. It's just a glue library to make
>>> writing some tty drivers a bit easier.
>> 
>> Yes, and exactly that is helpful to solve this problem. We attach only to the
>> glue layer and everything is done.
> 
> It's the wrong place - it's not the abstraction.

Maybe we think about different levels of abstractions.

I think on a level of abstraction of all the different UART drivers. Which is sufficient
to access the UART by the peer driver. This is why I call it UART-peer (and
not serial or tty peer).

I understand the peer device driver requirements that were mentioned so far,
that they all will be happy with basic UART functionality (receive characters,
send characters, activate/deactivate, set baud rate).

You want to abstract from UART and add all tty bells and whistles. We need them
for the GPS chip's data stream (because our unknown GPS applications might
use them) - but other low level UART peer drivers do not even need them.

> 
> What I am trying to say is that if you do this generically then add the
> needed method calls into tty_port_open and tty_port_shutdown, make them
> run after port->ops->activate and before port->ops->shutdown so there is
> a sensible ordering if you need to do something to the port itself, and
> also so on open it only runs if port->ops->activate succeeded.
> 
> Something like
> 
>       if (!test_bit(ASYNCB_INITIALIZED, &port->flags)) {
>                clear_bit(TTY_IO_ERROR, &tty->flags);
>                if (port->ops->activate) {
>                        int retval = port->ops->activate(port, tty);
>                        if (retval) {
>                                mutex_unlock(&port->mutex);
>                                return retval;
>                        }
>                }
> 		/* Wake the device if we have one tied to us */
> 		if (port->ops->activate_slave)
> 			port->ops->activate_slave(port, tty);
>                set_bit(ASYNCB_INITIALIZED, &port->flags);
> 	}
> 
> Then all you need is the (possibly device specific) small patches to check
> the device tree for the bindings on init, and if so set the port->ops
> methods according to the binding.

For me it appears to only solves a small part of the whole problem.

1. it must be possible to start the UART before any user-space open()
2. the UART must be kept running as long as the peer driver wants to
monitor rx data
3. we need a hook to monitor: that (and which) data is incoming

Another aspect is that on a physical RS232 the DTR line is usually
used to power on/off a remote device (the DCE). Therefore I prefer
to mimic that in software by intercepting the mctrl changes. This
additionally allows a client to turn off power of the chip through a "standard"
protocol, even while the tty file is kept open.

> 
>>> It's tied deeply to the tty_port
>>> implementation. One day it might even cease to exist replaced by more
>>> generic tty_port helpers.
>> 
>> Is there a concrete plan to change that? Is anyone working on it now?
> 
> Nobody wants to lose the ability to do so or to move stuff around.

Indeed. But why would you loose this ability at all?

> 
>> If not, I would not worry about this, because it is not specific to the problem
>> we want to solve today (to be precise: since 3 years).
> 
> You solve it today you block other things for the next 20 years. The
> kernel has to deal in long terms.

i understand what you mean but I don't think we are blocking anything.

This is a too black&white view for me. Especially since we would probably still
have all the APIs of ca. Linux 1.3 (1996) if things were blocked for 20 years
by any new piece of hardware. I am quite sure that a lot of things has been
completely turned upside down in the past 20 years.

If significant architectural changes are to be done, you can deprecate this
API and ask all users (driver authors) to replace it with something new.
And if they aren't adjusted within some time or no new interface is proposed,
they get removed. The *I* have the problem back on my table and not you :)

Isn't this a standard way to handle such situations?

Things are gradually changed every now and then. And other parts have to
follow. BTW: most of my work to update a production kernel to a new -rc1 is
to adjust non-mainline (or not-yet) drivers to such API changes.

So this is daily life for someone who maintains a working kernel for a specific
device and therefore does not come unexpected.

So it is more you blocking an adequate solution for our devices than we blocking
Linux development...

> 
>>> The tty layer is also an *abstract* concept. There is no real world tie
>>> between physical collections of shift registers that dribble bits to one
>>> another and tty devices in the kernel. You only need a tty driver for
>>> certain types of user interaction.
>> 
>> And we need it to process the GPS data by standard applications and tools.
> 
> Ok - no problem with that, and for what you've explained that bit makes
> sense.
> 
> Alan

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > Your user space can do it (as most Android does).
> 
> How can it do it in automatically in a standardized way without need for daemon support?

You don't need to - it can be device specific. In Android it usually is.
I've never understood why low end devices don't also abstract user space
descriptions of power control into DT nodes as well as kernel properties ?

> * how can the daemon present another /dev/tty so that applications expecting such
> an interface can attach to it (maybe through pty - but isn't that an overkill?)

You don't need to - you can monitor the rx/tx stats via procfs too. Not
pretty but given the daemon can do both the decoding and the monitoring
for your device it all seems a strawman. I'd argue given the sheer range
of ways people PM a GPS that you ought to have those power abstractions
in the user space daemon. They might use kernel methods, they might not.

> * Who makes sure that this daemon is installed and running right after boot up on *any* Linux system
> so that it can always react in case that the chip did start when it should be off?

Whoever puts the distribution together. The kernel runs init. Beyond that
we don't care. Not our problem. You can boot into emacs if you want.

> More generally: what is a kernel good for? Why do we need kernel drivers?

To maintain security, to manage hardware elements that cannot be managed
in user space, and to provide abstractions where the abstraction is
necessary and meaningful to a large number of users (not a corner case
phone device unless the abstraction can be made meaningful and widely
useful).

> Just think about waking up the daemon process if a character is received. This is
> much more costly than calling a notification function in the kernel driver which might
> have to execute just 4 or 5 assembler instructions to decide what to do.

The logical continuation of that is of course not to have user space but
write your entire phone device in ring 0. Point being it is always a
trade off.

Your only way currently to do that is to open the tty and set a line
discipline which does your monitoring then hold it open. We can't stack
ldiscs either. If you want to monitor the line state with the physical
uart receiver powered down then this won't work at all.

> So kernel drivers are sometimes the best solution and more efficient and controllable
> than a user space daemon.

Sometimes but not always. And even if a kernel device is the right
solution to your device that doesn't mean it's general purpose enough to
justify being stuffed upstream. Android is full of "interesting" device
specific tweaks the sum of which would sink the kernel project.

> I understand that. But what is Linux good for? For it's own sake or for
> users and platforms using it? Isn't it that we take it from the community
> and contribute improvements back to it?

Only when the community benefits overall.

> So to me it appears that such a kernel feature is missing. Therefore we
> are discussing it.

I'm glad - because it raises some hard questions and while I don't agree
with some of your starting points (like needing to "open" a uart without
user space) I do agree that

- There isn't a nice way to bind extra non device specific behaviour to
  open and close (but we have the right places to add one)

- There isn't a way to monitor rx data (and this is *really* hard to
  sort especially when the uart is powered down)

- Monitoring mctrl via a nice abstraction is going to need the mctrl
  ops moving from tty to tty_port if you want to use that to trigger tty
  slave behaviour. Doable but a change.

> well I think most driver projects that have expressed that they want to have
> such a solution just want an UART abstraction and not a general tty/serial
> interface with all bells and whistles.

There isn't any difference at the proper abstraction layer. If you wanted
your monitor to power on and off when you open a console that's the same
problem space.

> > uart is just a helper library for some types of
> > port.
> 
> Yes, this is the type of port, our peer devices are directly connected to.

Think about the bigger picture. The high level abstraction is the tty and
the tty_port. But see below as I think your mental model is perhaps wrong
and this is a point of confusion ?

> Another question if we discuss moving the hooks into the tty_port layer:
> 
> is it possible from tty layer to activate the UART without a user-space open()
> and keep it activated after a close()?

No the entire tty layer from top to bottom assumes that you activate a
device by opening it from user space. uart, tty, the lot. The only
corner case weird exception is the serial console and that is a horrible
hack for output only - so anything that fixes that assumption should also
be made to fix the console case.

It's never really mattered because the obscure corner cases where you
want a tty held open the cost is minimal because you just let systemd or
similar own the file handle along with everything else it is hanging on
to.

> > The ones I am familiar with either have the userspace managing it via
> > sysfs (which has some latency advantages when doing clever stuff) or
> > wired the power control to the carrier signal (or that is declared the
> > gpio that controls it to be the carrier).
> 
> How many of these special drivers are in mainline? Our target is to get full support
> by mainline and not run our own kernel branch forever. Because we are not
> yet-another-android-thing-that-just-needs-to-work-for-6-months-and-nobody-cares-
> about-updates-and-GPL.

Both of those techniques work in mainline without kernel changes (at
least on devices where the right gpio sysfs nodes exist). Not pretty and
it would be better to abstract it - although ACPI often abstracts it by
having the kernel power down the uart which calls into ACPI which pokes a
GPIO line so presumably devicetree could learn the same tricks if it got
better at describing power management.

> In all mainlining attempts I know, the user-space control approach was rejected
> because it was said that the kernel should take care of and not a /sysfs or some
> other artificial protocol.

I'm not sure who said that but they obviously didn't look at the real
world 8)

> But anyway, it would not solve the device RX data stream monitoring problem.
> It just could be a solution to know when to turn the chip on or off.

This I think is actually the really hard and interesting part of the
problem. The "tell me about open and close" case is simple and can be
done via tty_port today with minimal extra hooks. There is a small
question about how you set those hooks from a DT binding - mostly because
we want the tty_port method table to be const for security reasons.

The data one is much harder because the abstractions in the tty_port
never see data. It goes direct from the hardware interface (possibly via
a support library liek uart but not always) on to the core of the tty
code. It's also a very hot path on things like older USB 3G modems that
use AT commands. Peter has done minor miracles on making it more
efficient but a USB modem can still really stress a small CPU without any
further callbacks appearing.

> Neil's proposal to monitor the RX line was rejected because it was doing
> nasty tricks with switching pinmux states and setting a temporary interrupt
> on the UART RX line.

For some hardware that is the only way I know to do this because the
power hungry uart receiver is physically powered down. I would have to
check but I *think* that is true even on a modern x86 PC that supports
wakeups via serial - although it may be well hidden in ACPI and firmware.

> Therefore we now want to monitor the RX line "behind" the UART, i.e. on the
> byte stream coming from the UART shift registers.
> 
> This did lead to tty/uart slaves concept and everybody wanted it. Now as we
> have code proposals it should go back to become a user space daemon...

I'm not personally opoosed to the tty slave idea providing it ends up
attached to the tty_port not just uart.

> > 2. If not then hook tty_port_shutdown() and tty_port_open() because those
> > are the right abstraction point. Everything in the kernel that is a tty
> > is a tty_port.
> 
> What is in your view the right abstraction point for a peer device driver to get
> notified about rx characters (even if the tty is currently not open)?

I don't think you have one. A lot of hardware has the receiver and
transceiver physically powered off when the tty is closed. You can't even
touch the registers in some cases (eg a PCI port in D3 state).

I certainly have no good ideas for that specific case because apart from
things buried in stuff like ACPI I don't know of any general purpose way
to ask "how do I make some other piece of hardware peek at the level on
that line and/or trigger on rising or falling edges"

> I think on a level of abstraction of all the different UART drivers. Which is sufficient
> to access the UART by the peer driver. This is why I call it UART-peer (and
> not serial or tty peer).

Not all uarts use the uart layer. It's an optional helper.

> You want to abstract from UART and add all tty bells and whistles. We need them
> for the GPS chip's data stream (because our unknown GPS applications might
> use them) - but other low level UART peer drivers do not even need them.

Ok I think the model you have may be wrong.

The lowest level physical interface abstraction in the whole tty stack is
the tty_port. Every object which can be opened as a tty contains a
tty_port, and the tty_port lifetime is the lifetime of the "physical"
interface to which it is attached.

tty_port requires the device provide a set of methods.

uart optionally sits on top of tty_port. It provides the tty_port methods
and provides a differentish set of low level abstractions more suited to
byte oriended serial port devices. Console doesn't use it, sdio serial
doesn't use it, some uarts don't use it, usb doesn't use it (including
on-board HSIC and SSIC devices), most jtag serials don't use it either.

The tty layer talks to the tty_port layer and also directly to tty
methods provided by the physical device. Conveniently for you the
tty_port abstracts opening and closing the device. Inconveniently for you
it doesn't really mediate receiving and sending data although it does hold
the buffers used.

> > Then all you need is the (possibly device specific) small patches to check
> > the device tree for the bindings on init, and if so set the port->ops
> > methods according to the binding.
> 
> For me it appears to only solves a small part of the whole problem.
> 
> 1. it must be possible to start the UART before any user-space open()

There is no tty layer support at any level to do this, nor any reason
I've seen advanced to justify all the extra complexity needed.

> 2. the UART must be kept running as long as the peer driver wants to
> monitor rx data

Correct, otherwise in the general case the uart may be physically powered
off and the kernel will in fact try aggressively to do so.

> 3. we need a hook to monitor: that (and which) data is incoming

That isn't tty_port related - but it's certainly hard.

> Another aspect is that on a physical RS232 the DTR line is usually
> used to power on/off a remote device (the DCE). Therefore I prefer
> to mimic that in software by intercepting the mctrl changes. This
> additionally allows a client to turn off power of the chip through a "standard"
> protocol, even while the tty file is kept open.

The mctrl currently goes via tty->ops->tiocmset()/tiocmget. That IMHO is
actually an oddity and moving it to the tty_port would make sense anyway
because it's state and behaviour that is persistent at hardware level.

I don't know what Peter thinks about that however.

> > Nobody wants to lose the ability to do so or to move stuff around.
> 
> Indeed. But why would you loose this ability at all?

Because all your hooks would break.

> If significant architectural changes are to be done, you can deprecate this
> API and ask all users (driver authors) to replace it with something new.
> And if they aren't adjusted within some time or no new interface is proposed,
> they get removed. The *I* have the problem back on my table and not you :)
> 
> Isn't this a standard way to handle such situations?
> 
> Things are gradually changed every now and then. And other parts have to
> follow. BTW: most of my work to update a production kernel to a new -rc1 is
> to adjust non-mainline (or not-yet) drivers to such API changes.

What usually happens is the creator the tangle has despite best
intentions ended up somewhere else on another project, their users whine
if we break it, someone screams regression and it all gets dumped on the
maintainers.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Just a first short answer (can't work 7/24 :).

Am 18.01.2016 um 23:03 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>>> Your user space can do it (as most Android does).
>> 
>> How can it do it in automatically in a standardized way without need for daemon support?
> 
> You don't need to - it can be device specific. In Android it usually is.
> I've never understood why low end devices don't also abstract user space
> descriptions of power control into DT nodes as well as kernel properties ?
> 
>> * how can the daemon present another /dev/tty so that applications expecting such
>> an interface can attach to it (maybe through pty - but isn't that an overkill?)
> 
> You don't need to - you can monitor the rx/tx stats via procfs too. Not
> pretty but given the daemon can do both the decoding and the monitoring
> for your device it all seems a strawman. I'd argue given the sheer range
> of ways people PM a GPS that you ought to have those power abstractions
> in the user space daemon. They might use kernel methods, they might not.
> 
>> * Who makes sure that this daemon is installed and running right after boot up on *any* Linux system
>> so that it can always react in case that the chip did start when it should be off?
> 
> Whoever puts the distribution together. The kernel runs init. Beyond that
> we don't care. Not our problem. You can boot into emacs if you want.

Well, it is my big problem which goes contrary to our goal to have the best
supported platform... We would have to provide and maintain such things
so that they are compatible to a plethora of unknown runtime environments.

> 
> 
>> More generally: what is a kernel good for? Why do we need kernel drivers?
> 
> To maintain security, to manage hardware elements that cannot be managed
> in user space, and to provide abstractions where the abstraction is
> necessary and meaningful to a large number of users (not a corner case
> phone device unless the abstraction can be made meaningful and widely
> useful).
> 
>> Just think about waking up the daemon process if a character is received. This is
>> much more costly than calling a notification function in the kernel driver which might
>> have to execute just 4 or 5 assembler instructions to decide what to do.
> 
> The logical continuation of that is of course not to have user space but
> write your entire phone device in ring 0. Point being it is always a
> trade off.
> 
> Your only way currently to do that is to open the tty and set a line
> discipline which does your monitoring then hold it open. We can't stack
> ldiscs either. If you want to monitor the line state with the physical
> uart receiver powered down then this won't work at all.
> 
>> So kernel drivers are sometimes the best solution and more efficient and controllable
>> than a user space daemon.
> 
> Sometimes but not always. And even if a kernel device is the right
> solution to your device that doesn't mean it's general purpose enough to
> justify being stuffed upstream. Android is full of "interesting" device
> specific tweaks the sum of which would sink the kernel project.
> 
>> I understand that. But what is Linux good for? For it's own sake or for
>> users and platforms using it? Isn't it that we take it from the community
>> and contribute improvements back to it?
> 
> Only when the community benefits overall.
> 
>> So to me it appears that such a kernel feature is missing. Therefore we
>> are discussing it.
> 
> I'm glad - because it raises some hard questions and while I don't agree
> with some of your starting points (like needing to "open" a uart without
> user space) I do agree that
> 
> - There isn't a nice way to bind extra non device specific behaviour to
>  open and close (but we have the right places to add one)
> 
> - There isn't a way to monitor rx data (and this is *really* hard to
>  sort especially when the uart is powered down)

Exactly. This is why we already work 3 years on this topic...

The solution is to optionally keep it powered up - as long as the peer
device asks for.

> 
> - Monitoring mctrl via a nice abstraction is going to need the mctrl
>  ops moving from tty to tty_port if you want to use that to trigger tty
>  slave behaviour. Doable but a change.
> 
>> well I think most driver projects that have expressed that they want to have
>> such a solution just want an UART abstraction and not a general tty/serial
>> interface with all bells and whistles.
> 
> There isn't any difference at the proper abstraction layer. If you wanted
> your monitor to power on and off when you open a console that's the same
> problem space.
> 
>>> uart is just a helper library for some types of
>>> port.
>> 
>> Yes, this is the type of port, our peer devices are directly connected to.
> 
> Think about the bigger picture. The high level abstraction is the tty and
> the tty_port. But see below as I think your mental model is perhaps wrong
> and this is a point of confusion ?
> 
>> Another question if we discuss moving the hooks into the tty_port layer:
>> 
>> is it possible from tty layer to activate the UART without a user-space open()
>> and keep it activated after a close()?
> 
> No the entire tty layer from top to bottom assumes that you activate a
> device by opening it from user space. uart, tty, the lot. The only
> corner case weird exception is the serial console and that is a horrible
> hack for output only - so anything that fixes that assumption should also
> be made to fix the console case.
> 
> It's never really mattered because the obscure corner cases where you
> want a tty held open the cost is minimal because you just let systemd or
> similar own the file handle along with everything else it is hanging on
> to.
> 
>>> The ones I am familiar with either have the userspace managing it via
>>> sysfs (which has some latency advantages when doing clever stuff) or
>>> wired the power control to the carrier signal (or that is declared the
>>> gpio that controls it to be the carrier).
>> 
>> How many of these special drivers are in mainline? Our target is to get full support
>> by mainline and not run our own kernel branch forever. Because we are not
>> yet-another-android-thing-that-just-needs-to-work-for-6-months-and-nobody-cares-
>> about-updates-and-GPL.
> 
> Both of those techniques work in mainline without kernel changes (at
> least on devices where the right gpio sysfs nodes exist). Not pretty and
> it would be better to abstract it - although ACPI often abstracts it by
> having the kernel power down the uart which calls into ACPI which pokes a
> GPIO line so presumably devicetree could learn the same tricks if it got
> better at describing power management.
> 
>> In all mainlining attempts I know, the user-space control approach was rejected
>> because it was said that the kernel should take care of and not a /sysfs or some
>> other artificial protocol.
> 
> I'm not sure who said that but they obviously didn't look at the real
> world 8)
> 
>> But anyway, it would not solve the device RX data stream monitoring problem.
>> It just could be a solution to know when to turn the chip on or off.
> 
> This I think is actually the really hard and interesting part of the
> problem. The "tell me about open and close" case is simple and can be
> done via tty_port today with minimal extra hooks. There is a small
> question about how you set those hooks from a DT binding - mostly because
> we want the tty_port method table to be const for security reasons.
> 
> The data one is much harder because the abstractions in the tty_port
> never see data. It goes direct from the hardware interface (possibly via
> a support library liek uart but not always) on to the core of the tty
> code. It's also a very hot path on things like older USB 3G modems that
> use AT commands. Peter has done minor miracles on making it more
> efficient but a USB modem can still really stress a small CPU without any
> further callbacks appearing.
> 
>> Neil's proposal to monitor the RX line was rejected because it was doing
>> nasty tricks with switching pinmux states and setting a temporary interrupt
>> on the UART RX line.
> 
> For some hardware that is the only way I know to do this because the
> power hungry uart receiver is physically powered down. I would have to
> check but I *think* that is true even on a modern x86 PC that supports
> wakeups via serial - although it may be well hidden in ACPI and firmware.
> 
>> Therefore we now want to monitor the RX line "behind" the UART, i.e. on the
>> byte stream coming from the UART shift registers.
>> 
>> This did lead to tty/uart slaves concept and everybody wanted it. Now as we
>> have code proposals it should go back to become a user space daemon...
> 
> I'm not personally opoosed to the tty slave idea providing it ends up
> attached to the tty_port not just uart.
> 
>>> 2. If not then hook tty_port_shutdown() and tty_port_open() because those
>>> are the right abstraction point. Everything in the kernel that is a tty
>>> is a tty_port.
>> 
>> What is in your view the right abstraction point for a peer device driver to get
>> notified about rx characters (even if the tty is currently not open)?
> 
> I don't think you have one. A lot of hardware has the receiver and
> transceiver physically powered off when the tty is closed. You can't even
> touch the registers in some cases (eg a PCI port in D3 state).

This is why I want to keep the UART open as long as the peer driver
tells to do so.

> 
> I certainly have no good ideas for that specific case because apart from
> things buried in stuff like ACPI I don't know of any general purpose way
> to ask "how do I make some other piece of hardware peek at the level on
> that line and/or trigger on rising or falling edges"
> 
>> I think on a level of abstraction of all the different UART drivers. Which is sufficient
>> to access the UART by the peer driver. This is why I call it UART-peer (and
>> not serial or tty peer).
> 
> Not all uarts use the uart layer. It's an optional helper.
> 
>> You want to abstract from UART and add all tty bells and whistles. We need them
>> for the GPS chip's data stream (because our unknown GPS applications might
>> use them) - but other low level UART peer drivers do not even need them.
> 
> Ok I think the model you have may be wrong.
> 
> The lowest level physical interface abstraction in the whole tty stack is
> the tty_port. Every object which can be opened as a tty contains a
> tty_port, and the tty_port lifetime is the lifetime of the "physical"
> interface to which it is attached.
> 
> tty_port requires the device provide a set of methods.
> 
> uart optionally sits on top of tty_port. It provides the tty_port methods
> and provides a differentish set of low level abstractions more suited to
> byte oriended serial port devices. Console doesn't use it, sdio serial
> doesn't use it, some uarts don't use it, usb doesn't use it (including
> on-board HSIC and SSIC devices), most jtag serials don't use it either.
> 
> The tty layer talks to the tty_port layer and also directly to tty
> methods provided by the physical device.

Ok, I see. My picture was more a layer scheme based on the path how
data flows from the hardware specific uart driver to the uart layer and
then to the tty_port things.

> Conveniently for you the
> tty_port abstracts opening and closing the device. Inconveniently for you
> it doesn't really mediate receiving and sending data although it does hold
> the buffers used.

Yes.

> 
>>> Then all you need is the (possibly device specific) small patches to check
>>> the device tree for the bindings on init, and if so set the port->ops
>>> methods according to the binding.
>> 
>> For me it appears to only solves a small part of the whole problem.
>> 
>> 1. it must be possible to start the UART before any user-space open()
> 
> There is no tty layer support at any level to do this, nor any reason
> I've seen advanced to justify all the extra complexity needed.

This is why I want to do it on the uart_port.

> 
>> 2. the UART must be kept running as long as the peer driver wants to
>> monitor rx data
> 
> Correct, otherwise in the general case the uart may be physically powered
> off and the kernel will in fact try aggressively to do so.
> 
>> 3. we need a hook to monitor: that (and which) data is incoming
> 
> That isn't tty_port related - but it's certainly hard.

Not, if we do it on uart_port level... It already works with two not very
big patches.

> 
>> Another aspect is that on a physical RS232 the DTR line is usually
>> used to power on/off a remote device (the DCE). Therefore I prefer
>> to mimic that in software by intercepting the mctrl changes. This
>> additionally allows a client to turn off power of the chip through a "standard"
>> protocol, even while the tty file is kept open.
> 
> The mctrl currently goes via tty->ops->tiocmset()/tiocmget. That IMHO is
> actually an oddity and moving it to the tty_port would make sense anyway
> because it's state and behaviour that is persistent at hardware level.
> 
> I don't know what Peter thinks about that however.
> 
>>> Nobody wants to lose the ability to do so or to move stuff around.
>> 
>> Indeed. But why would you loose this ability at all?
> 
> Because all your hooks would break.

Only if you do big changes. That is why I ask if such big changes are planned
or can be anticipated. They probably don't come unexpectedly around the corner.

And if you reject other changes like ours, there won't be any in the next 20 years :)

> 
>> If significant architectural changes are to be done, you can deprecate this
>> API and ask all users (driver authors) to replace it with something new.
>> And if they aren't adjusted within some time or no new interface is proposed,
>> they get removed. The *I* have the problem back on my table and not you :)
>> 
>> Isn't this a standard way to handle such situations?
>> 
>> Things are gradually changed every now and then. And other parts have to
>> follow. BTW: most of my work to update a production kernel to a new -rc1 is
>> to adjust non-mainline (or not-yet) drivers to such API changes.
> 
> What usually happens is the creator the tangle has despite best
> intentions ended up somewhere else on another project, their users whine
> if we break it, someone screams regression and it all gets dumped on the
> maintainers.

That is of course something we want to avoid. This is why I persistently try
to discuss it with you every detail. Fortunately a good discussion has now started.

And it looks that we either need a kernel solution or a user space solution - but
none makes the responsible party happy... Although that is not a criterion for
a whole system architecture. There the more efficient solution should be done.
Efficient in terms of LOC, speed, maintenance requirements.

BR & GN,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

On Mon, 18 Jan 2016 22:03:19 +0000
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:

> > > Your user space can do it (as most Android does).
> > 
> > How can it do it in automatically in a standardized way without need for daemon support?
> 
> You don't need to - it can be device specific. In Android it usually is.
> I've never understood why low end devices don't also abstract user space
> descriptions of power control into DT nodes as well as kernel properties ?
> 
Well, on these android devices, they are only intended to run android and
have another abstraction layer where you can hide things.
If doing actions on opening or closing a tty should not be implemented in
kernel space, then an alternative I see would be to at least have proper
rfkill support for bluetooth and gps in kernel. Then userspace can at least
can talk to a standardised interface. So userspace just has to implement
generic things.

That would mean for the kernel drivers needed:


W2CBW003/bluetooth:
   map the rfkill to just a simple regulator

W2SG0004/gps:
   being notified about incoming data
     a) the nice way: getting it from the tty/tty_port layer
 	(but requiring changes at generic kernel code)
        or
     b) the ugly way:
        remux the data line as a gpio and simply look for state
        changes during rfkill call (probably only during unblock)
	The first characters after power on would probably be lost
        toggle a gpio depending on the desired and detected state

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > Whoever puts the distribution together. The kernel runs init. Beyond that
> > we don't care. Not our problem. You can boot into emacs if you want.
> 
> Well, it is my big problem which goes contrary to our goal to have the best
> supported platform... We would have to provide and maintain such things
> so that they are compatible to a plethora of unknown runtime environments.

Every platform does this and has to do this. GTA04 userspace is different
to Raspberry PI userspace is different to PC userspace etc. Your graphics
is different to other people, you don't have a keyboard. All these
require there is some customisation going on.

> > - There isn't a nice way to bind extra non device specific behaviour to
> >  open and close (but we have the right places to add one)
> > 
> > - There isn't a way to monitor rx data (and this is *really* hard to
> >  sort especially when the uart is powered down)
> 
> Exactly. This is why we already work 3 years on this topic...
> 
> The solution is to optionally keep it powered up - as long as the peer
> device asks for.

That won't work on a lot of platforms. They need to power down the uart
to get the power savings and they expect some kind of other monitor like
GPIO. Eg some x86 power states are not achievable on certain SoCs with the
uart powered up. We are already using GPIO triggers on lots of devices,
even if people haven't noticed what is going on because the firmware
hides it all or it's done in user space on the device.

For that to work generically we would need a way to go from a serial port
to a gpio or other monitor setting, described via ACPI and/or DT. We'd
also need a way to open a port in powered off mode, or perhaps to be able
to make open() block for an event on the downed port (just like today you
can block for carrier), but do it before bringing the port active and thus
powering it on.

I don't like the open case because it then means you can't use poll() on
a set of ports to wait cleanly for an event to power them on but the
alternative is really hard because you would have to know that no other
thread of execution or IRQ handler or timer for the port could touch the
hardware

- you were the only thread of execution in the driver
- you held sufficient locks to prevent any other thread of execution
  entering your tty code and touching the hardware

and then in effect do

	tty_port_shutdown	// power down
	port->ops->monitor_rx() (some new method)
	tty_port_open		// power up

We don't normally get into the situation where we have a userspace or
kernel reference open to a device which may be physically powered off.

In that sense having the gpio monitoring separate and the relationship
described to user space (or to some gpio/monitoring driver) by DT is a
lot cleaner IMHO.

The open case can be made to work so that opening the tty can block with
it powered off until an event happens, then powers up the uart. That one
would be doable.

> >> What is in your view the right abstraction point for a peer device driver to get
> >> notified about rx characters (even if the tty is currently not open)?
> > 
> > I don't think you have one. A lot of hardware has the receiver and
> > transceiver physically powered off when the tty is closed. You can't even
> > touch the registers in some cases (eg a PCI port in D3 state).
> 
> This is why I want to keep the UART open as long as the peer driver
> tells to do so.

For the cases that works this is the same as user space keeping the tty
open. You might want a peer driver just to avoid continually waking up
user space, but that could probably also be an ldisc.
 
> >> For me it appears to only solves a small part of the whole problem.
> >> 
> >> 1. it must be possible to start the UART before any user-space open()
> > 
> > There is no tty layer support at any level to do this, nor any reason
> > I've seen advanced to justify all the extra complexity needed.
> 
> This is why I want to do it on the uart_port.

The problem is pretty much the same for uart and tty_port. There is also
no reason you've yet given that to me justifies need to open it from
kernel space.

However doing the open/close hooks is the same in both cases. The termios
one for modem state monitoring is a tiny shift of a method between two
places (and the ripple of the change through all the drivers). The one
that causes all the trouble is monitoring receive data because that goes
directly via the tty flip buffers if the device is powered on, so there
is nowhere to intercept it cleanly. Not only that but when the port is
present but not bound to a userspace tty most devices don't even read the
bytes from the hardware interface and queue them.

If we take your patch then

The hook to uart_update_mctrl becomes a hook to the tty_port termios
method (which right now is for historical reasons still in tty but can
move)

The hook to uart_port_startup becomes the hook I posted to the
tty_port_open method. Probably the method needs to be a
tty_port->slave_ops and not tty_port->ops because ops is const and shared
between physical interfaces. That's a detail.

The hook to uart_port_shutdown becomes a hook to tty_port_shutdown.

Those three are fairly trivial.

Your patch to uart_insert_char doesn't work anyway as that is an
*optional* helper that only some uart drivers use.

That would mean
- Firmware describes the port relationship
- The firmware parsing installs the tty_port->slave_ops pointer at boot
  time or when the module for the serial port is loaded. (Care needed for
  serial console that gets one), and does the right thing on hot
  unplugging, and has the right locking for unplug while scanning

that is much as you have in the patch now, but with the right abstraction
layer and I think some locking tweaks.

> >> 2. the UART must be kept running as long as the peer driver wants to
> >> monitor rx data
> > 
> > Correct, otherwise in the general case the uart may be physically powered
> > off and the kernel will in fact try aggressively to do so.
> > 
> >> 3. we need a hook to monitor: that (and which) data is incoming
> > 
> > That isn't tty_port related - but it's certainly hard.
> 
> Not, if we do it on uart_port level... It already works with two not very
> big patches.

If you require the uart to be powered up then your "peer" is just a line
discipline pushed onto the port by a userspace process holding the tty
open.

So I'd do

	open /dev/ttyWhatever
	set the ldisc to a new "don't wake me until X happens" ldisc
	poll (blocks until X happens)
	set the ldisc to N_TTY
	do stuff
	close

> > Because all your hooks would break.
> 
> Only if you do big changes. That is why I ask if such big changes are planned
> or can be anticipated. They probably don't come unexpectedly around the corner.

They often do. 

> And it looks that we either need a kernel solution or a user space solution - but
> none makes the responsible party happy... Although that is not a criterion for
> a whole system architecture. There the more efficient solution should be done.
> Efficient in terms of LOC, speed, maintenance requirements.

As measured for the sum of the kernel community not just Gta04 users.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,
here the missing answers.

Am 18.01.2016 um 23:32 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

> Just a first short answer (can't work 7/24 :).
> 
> Am 18.01.2016 um 23:03 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
> 
>>>> Your user space can do it (as most Android does).
>>> 
>>> How can it do it in automatically in a standardized way without need for daemon support?
>> 
>> You don't need to - it can be device specific. In Android it usually is.
>> I've never understood why low end devices don't also abstract user space
>> descriptions of power control into DT nodes as well as kernel properties ?

I don't know.

But what I know is that I don't want to solve someone else's problems...

>> 
>>> * how can the daemon present another /dev/tty so that applications expecting such
>>> an interface can attach to it (maybe through pty - but isn't that an overkill?)
>> 
>> You don't need to - you can monitor the rx/tx stats via procfs too. Not
>> pretty but given the daemon can do both the decoding and the monitoring
>> for your device it all seems a strawman. I'd argue given the sheer range
>> of ways people PM a GPS that you ought to have those power abstractions
>> in the user space daemon. They might use kernel methods, they might not.

The problem is that *I* have no control over user space. But I also don't want
to say to my users "that is not my problem - get it solved yourself". This does
not help them.

Especially as I can help them with the kernel based solutions we have.

>> 
>>> * Who makes sure that this daemon is installed and running right after boot up on *any* Linux system
>>> so that it can always react in case that the chip did start when it should be off?
>> 
>> Whoever puts the distribution together. The kernel runs init. Beyond that
>> we don't care. Not our problem. You can boot into emacs if you want.
> 
> Well, it is my big problem which goes contrary to our goal to have the best
> supported platform... We would have to provide and maintain such things
> so that they are compatible to a plethora of unknown runtime environments.
> 
>> 
>> 
>>> More generally: what is a kernel good for? Why do we need kernel drivers?
>> 
>> To maintain security, to manage hardware elements that cannot be managed
>> in user space,

Ahem. Most hardware elements can be manages in user space. Use FUSE for
everything and you will only need 10% of the kernel code.

So why are you always arguing with exaggerations?

>> and to provide abstractions where the abstraction is
>> necessary and meaningful to a large number of users (not a corner case
>> phone device

well, phone devices in general outnumber all other devices in sheer numbers.

Yes, the GTA04 has low quantities. But the main hurdle I always hear is that
the kernel is not good enough.

>> unless the abstraction can be made meaningful and widely
>> useful).

And, most device drivers are corner cases since they are special solutions
for singular platforms.

>> 
>>> Just think about waking up the daemon process if a character is received. This is
>>> much more costly than calling a notification function in the kernel driver which might
>>> have to execute just 4 or 5 assembler instructions to decide what to do.
>> 
>> The logical continuation of that is of course not to have user space but
>> write your entire phone device in ring 0. Point being it is always a
>> trade off.
>> 
>> Your only way currently to do that is to open the tty and set a line
>> discipline which does your monitoring then hold it open. We can't stack
>> ldiscs either. If you want to monitor the line state with the physical
>> uart receiver powered down then this won't work at all.
>> 
>>> So kernel drivers are sometimes the best solution and more efficient and controllable
>>> than a user space daemon.
>> 
>> Sometimes but not always.

I am only interested in this case and here it obviously is.

>> And even if a kernel device is the right
>> solution to your device that doesn't mean it's general purpose enough to
>> justify being stuffed upstream. Android is full of "interesting" device
>> specific tweaks the sum of which would sink the kernel project.

This is of course an argument which we have to overcome.

>> 
>>> I understand that. But what is Linux good for? For it's own sake or for
>>> users and platforms using it? Isn't it that we take it from the community
>>> and contribute improvements back to it?
>> 
>> Only when the community benefits overall.

Yes, it benefits because there are several requests for such tty/uart slaves/peers.
>From this I deduce that there is community demand.

I brought up this discussion again, because Andrey and Tomeu recently asked
for progress.

>> 
>>> So to me it appears that such a kernel feature is missing. Therefore we
>>> are discussing it.
>> 
>> I'm glad - because it raises some hard questions and while I don't agree
>> with some of your starting points (like needing to "open" a uart without
>> user space

If have an idea how to turn off the device at boot time, before any user space
daemon is running, we can of course ignore that.

>> ) I do agree that
>> 
>> - There isn't a nice way to bind extra non device specific behaviour to
>> open and close (but we have the right places to add one)
>> 
>> - There isn't a way to monitor rx data (and this is *really* hard to
>> sort especially when the uart is powered down)
> 
> Exactly. This is why we already work 3 years on this topic...
> 
> The solution is to optionally keep it powered up - as long as the peer
> device asks for.
> 
>> 
>> - Monitoring mctrl via a nice abstraction is going to need the mctrl
>> ops moving from tty to tty_port if you want to use that to trigger tty
>> slave behaviour. Doable but a change.

Yes, any new function or improvement is a change.

>> 
>>> well I think most driver projects that have expressed that they want to have
>>> such a solution just want an UART abstraction and not a general tty/serial
>>> interface with all bells and whistles.
>> 
>> There isn't any difference at the proper abstraction layer. If you wanted
>> your monitor to power on and off when you open a console that's the same
>> problem space.
>> 
>>>> uart is just a helper library for some types of
>>>> port.
>>> 
>>> Yes, this is the type of port, our peer devices are directly connected to.
>> 
>> Think about the bigger picture. The high level abstraction is the tty and
>> the tty_port.

Yes, it is indeed.

>> But see below as I think your mental model is perhaps wrong
>> and this is a point of confusion ?

Maybe you do not accept that I want to keep as low level as reasonable (for me).

>> 
>>> Another question if we discuss moving the hooks into the tty_port layer:
>>> 
>>> is it possible from tty layer to activate the UART without a user-space open()
>>> and keep it activated after a close()?
>> 
>> No the entire tty layer from top to bottom assumes that you activate a
>> device by opening it from user space. uart, tty, the lot. The only
>> corner case weird exception is the serial console and that is a horrible
>> hack for output only - so anything that fixes that assumption should also
>> be made to fix the console case.

Reasonable.

>> 
>> It's never really mattered because the obscure corner cases where you
>> want a tty held open the cost is minimal because you just let systemd or
>> similar own the file handle along with everything else it is hanging on
>> to.
>> 
>>>> The ones I am familiar with either have the userspace managing it via
>>>> sysfs (which has some latency advantages when doing clever stuff) or
>>>> wired the power control to the carrier signal (or that is declared the
>>>> gpio that controls it to be the carrier).
>>> 
>>> How many of these special drivers are in mainline? Our target is to get full support
>>> by mainline and not run our own kernel branch forever. Because we are not
>>> yet-another-android-thing-that-just-needs-to-work-for-6-months-and-nobody-cares-
>>> about-updates-and-GPL.
>> 
>> Both of those techniques work in mainline without kernel changes (at
>> least on devices where the right gpio sysfs nodes exist

they do not exist...

>> ). Not pretty and
>> it would be better to abstract it - although ACPI often abstracts it by
>> having the kernel power down the uart which calls into ACPI which pokes a
>> GPIO line so presumably devicetree could learn the same tricks if it got
>> better at describing power management.

I do not want to wait until that happens.

>> 
>>> In all mainlining attempts I know, the user-space control approach was rejected
>>> because it was said that the kernel should take care of and not a /sysfs or some
>>> other artificial protocol.
>> 
>> I'm not sure who said that but they obviously didn't look at the real
>> world 8)
>> 
>>> But anyway, it would not solve the device RX data stream monitoring problem.
>>> It just could be a solution to know when to turn the chip on or off.
>> 
>> This I think is actually the really hard and interesting part of the
>> problem. The "tell me about open and close" case is simple and can be
>> done via tty_port today with minimal extra hooks. There is a small
>> question about how you set those hooks from a DT binding

tty has no binding. An UART hardware has. Another reason for me to
start with UARTs.

>> - mostly because
>> we want the tty_port method table to be const for security reasons.
>> 
>> The data one is much harder because the abstractions in the tty_port
>> never see data. It goes direct from the hardware interface (possibly via
>> a support library liek uart but not always) on to the core of the tty
>> code. It's also a very hot path on things like older USB 3G modems that
>> use AT commands. Peter has done minor miracles on making it more
>> efficient but a USB modem can still really stress a small CPU without any
>> further callbacks appearing.
>> 
>>> Neil's proposal to monitor the RX line was rejected because it was doing
>>> nasty tricks with switching pinmux states and setting a temporary interrupt
>>> on the UART RX line.
>> 
>> For some hardware that is the only way I know to do this because the
>> power hungry uart receiver is physically powered down. I would have to
>> check but I *think* that is true even on a modern x86 PC that supports
>> wakeups via serial - although it may be well hidden in ACPI and firmware.

Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.

>> 
>>> Therefore we now want to monitor the RX line "behind" the UART, i.e. on the
>>> byte stream coming from the UART shift registers.
>>> 
>>> This did lead to tty/uart slaves concept and everybody wanted it. Now as we
>>> have code proposals it should go back to become a user space daemon...
>> 
>> I'm not personally opoosed to the tty slave idea providing it ends up
>> attached to the tty_port not just uart.

Well if you can tell us how to handle the data path I have no problems with it
to attach to the tty level.

>> 
>>>> 2. If not then hook tty_port_shutdown() and tty_port_open() because those
>>>> are the right abstraction point. Everything in the kernel that is a tty
>>>> is a tty_port.
>>> 
>>> What is in your view the right abstraction point for a peer device driver to get
>>> notified about rx characters (even if the tty is currently not open)?
>> 
>> I don't think you have one. A lot of hardware has the receiver and
>> transceiver physically powered off when the tty is closed. You can't even
>> touch the registers in some cases (eg a PCI port in D3 state).
> 
> This is why I want to keep the UART open as long as the peer driver
> tells to do so.

If there is no peer driver or the peer drivers does not need the UART
it is exactly the same as today.

> 
>> 
>> I certainly have no good ideas for that specific case because apart from
>> things buried in stuff like ACPI I don't know of any general purpose way
>> to ask "how do I make some other piece of hardware peek at the level on
>> that line and/or trigger on rising or falling edges"
>> 
>>> I think on a level of abstraction of all the different UART drivers. Which is sufficient
>>> to access the UART by the peer driver. This is why I call it UART-peer (and
>>> not serial or tty peer).
>> 
>> Not all uarts use the uart layer. It's an optional helper.

I have researched and it appears that struct uart_port originally came in 2002
in release 2.4 for the sa1100 uart. Since then it has been extended significantly
and is now used by some uart hardware drivers.

But this is again a black&white argument. You recommended to be either general
or patch the omap-serial driver only that we have. I said that i want it a little
more general - which does not mean that I want to rewrite everything. I.e.
for my purposes it would suffice to support those UARTs that already use the
uart_port layer. If a hardware doesn't use it, it could be useful to rewrite the
UART device driver as well. But that is not something I feel I must do and
not now.

>> 
>>> You want to abstract from UART and add all tty bells and whistles. We need them
>>> for the GPS chip's data stream (because our unknown GPS applications might
>>> use them) - but other low level UART peer drivers do not even need them.
>> 
>> Ok I think the model you have may be wrong.
>> 
>> The lowest level physical interface abstraction in the whole tty stack is
>> the tty_port. Every object which can be opened as a tty contains a
>> tty_port, and the tty_port lifetime is the lifetime of the "physical"
>> interface to which it is attached.
>> 
>> tty_port requires the device provide a set of methods.
>> 
>> uart optionally sits on top of tty_port. It provides the tty_port methods
>> and provides a differentish set of low level abstractions more suited to
>> byte oriended serial port devices. Console doesn't use it, sdio serial
>> doesn't use it, some uarts don't use it, usb doesn't use it (including
>> on-board HSIC and SSIC devices), most jtag serials don't use it either.
>> 
>> The tty layer talks to the tty_port layer and also directly to tty
>> methods provided by the physical device.
> 
> Ok, I see. My picture was more a layer scheme based on the path how
> data flows from the hardware specific uart driver to the uart layer and
> then to the tty_port things.
> 
>> Conveniently for you the
>> tty_port abstracts opening and closing the device. Inconveniently for you
>> it doesn't really mediate receiving and sending data although it does hold
>> the buffers used.
> 
> Yes.
> 
>> 
>>>> Then all you need is the (possibly device specific) small patches to check
>>>> the device tree for the bindings on init, and if so set the port->ops
>>>> methods according to the binding.
>>> 
>>> For me it appears to only solves a small part of the whole problem.
>>> 
>>> 1. it must be possible to start the UART before any user-space open()
>> 
>> There is no tty layer support at any level to do this, nor any reason
>> I've seen advanced to justify all the extra complexity needed.
> 
> This is why I want to do it on the uart_port.
> 
>> 
>>> 2. the UART must be kept running as long as the peer driver wants to
>>> monitor rx data
>> 
>> Correct, otherwise in the general case the uart may be physically powered
>> off and the kernel will in fact try aggressively to do so.
>> 
>>> 3. we need a hook to monitor: that (and which) data is incoming
>> 
>> That isn't tty_port related - but it's certainly hard.
> 
> Not, if we do it on uart_port level... It already works with two not very
> big patches.
> 
>> 
>>> Another aspect is that on a physical RS232 the DTR line is usually
>>> used to power on/off a remote device (the DCE). Therefore I prefer
>>> to mimic that in software by intercepting the mctrl changes. This
>>> additionally allows a client to turn off power of the chip through a "standard"
>>> protocol, even while the tty file is kept open.
>> 
>> The mctrl currently goes via tty->ops->tiocmset()/tiocmget. That IMHO is
>> actually an oddity and moving it to the tty_port would make sense anyway
>> because it's state and behaviour that is persistent at hardware level.
>> 
>> I don't know what Peter thinks about that however.
>> 
>>>> Nobody wants to lose the ability to do so or to move stuff around.
>>> 
>>> Indeed. But why would you loose this ability at all?
>> 
>> Because all your hooks would break.
> 
> Only if you do big changes. That is why I ask if such big changes are planned
> or can be anticipated. They probably don't come unexpectedly around the corner.
> 
> And if you reject other changes like ours, there won't be any in the next 20 years :)
> 
>> 
>>> If significant architectural changes are to be done, you can deprecate this
>>> API and ask all users (driver authors) to replace it with something new.
>>> And if they aren't adjusted within some time or no new interface is proposed,
>>> they get removed. The *I* have the problem back on my table and not you :)
>>> 
>>> Isn't this a standard way to handle such situations?
>>> 
>>> Things are gradually changed every now and then. And other parts have to
>>> follow. BTW: most of my work to update a production kernel to a new -rc1 is
>>> to adjust non-mainline (or not-yet) drivers to such API changes.
>> 
>> What usually happens is the creator the tangle has despite best
>> intentions ended up somewhere else on another project, their users whine
>> if we break it, someone screams regression and it all gets dumped on the
>> maintainers.
> 
> That is of course something we want to avoid. This is why I persistently try
> to discuss it with you every detail. Fortunately a good discussion has now started.
> 
> And it looks that we either need a kernel solution or a user space solution - but
> none makes the responsible party happy... Although that is not a criterion for
> a whole system architecture. There the more efficient solution should be done.
> Efficient in terms of LOC, speed, maintenance requirements.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Next mail.

Am 19.01.2016 um 15:25 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>>> Whoever puts the distribution together. The kernel runs init. Beyond that
>>> we don't care. Not our problem. You can boot into emacs if you want.
>> 
>> Well, it is my big problem which goes contrary to our goal to have the best
>> supported platform... We would have to provide and maintain such things
>> so that they are compatible to a plethora of unknown runtime environments.
> 
> Every platform does this and has to do this. GTA04 userspace is different
> to Raspberry PI userspace is different to PC userspace etc. Your graphics
> is different to other people, you don't have a keyboard. All these
> require there is some customisation going on.

Not necessarily. If it is well designed and every problem is solved at the right
place.

In the case of our GPS chip some customization is already there in standard
user space code. Users can just choose or configure some /dev/tty name for
their standard navigation apps and daemons and it everything else should be
done by the kernel.

Neil did describe the goal long ago:

http://neil.brown.name/blog/20120724060722

> 
>>> - There isn't a nice way to bind extra non device specific behaviour to
>>> open and close (but we have the right places to add one)
>>> 
>>> - There isn't a way to monitor rx data (and this is *really* hard to
>>> sort especially when the uart is powered down)
>> 
>> Exactly. This is why we already work 3 years on this topic...
>> 
>> The solution is to optionally keep it powered up - as long as the peer
>> device asks for.
> 
> That won't work on a lot of platforms. They need to power down the uart
> to get the power savings and they expect some kind of other monitor like
> GPIO. Eg some x86 power states are not achievable on certain SoCs with the
> uart powered up. We are already using GPIO triggers on lots of devices,
> even if people haven't noticed what is going on because the firmware
> hides it all or it's done in user space on the device.

Our proposal is completely optional. If there is no UART peer, everything
runs as it does today. Only in the case the device driver needs the UART
to stay powered on it remains powered on.

> 
> For that to work generically we would need a way to go from a serial port
> to a gpio or other monitor setting, described via ACPI and/or DT.

In other words you ask for a device driver... A device driver that knows
which serial port and which gpio. And its exact setting are defined by DT.

This is exactly what we propose. We just need the connection from a
serial interface to that driver to do the monitoring.

> We'd
> also need a way to open a port in powered off mode, or perhaps to be able
> to make open() block for an event on the downed port (just like today you
> can block for carrier), but do it before bringing the port active and thus
> powering it on.
> 
> I don't like the open case because it then means you can't use poll() on
> a set of ports to wait cleanly for an event to power them on but the
> alternative is really hard because you would have to know that no other
> thread of execution or IRQ handler or timer for the port could touch the
> hardware
> 
> - you were the only thread of execution in the driver
> - you held sufficient locks to prevent any other thread of execution
>  entering your tty code and touching the hardware
> 
> and then in effect do
> 
> 	tty_port_shutdown	// power down
> 	port->ops->monitor_rx() (some new method)
> 	tty_port_open		// power up
> 
> We don't normally get into the situation where we have a userspace or
> kernel reference open to a device which may be physically powered off.
> 
> In that sense having the gpio monitoring separate and the relationship
> described to user space (or to some gpio/monitoring driver) by DT is a
> lot cleaner IMHO.
> 
> The open case can be made to work so that opening the tty can block with
> it powered off until an event happens, then powers up the uart. That one
> would be doable.

In our solution it simply powers up the UART and then it sets the mctrl DTR line
This will make the driver wake up the device. I.e. the problem you describe
does not exist.

> 
>>>> What is in your view the right abstraction point for a peer device driver to get
>>>> notified about rx characters (even if the tty is currently not open)?
>>> 
>>> I don't think you have one. A lot of hardware has the receiver and
>>> transceiver physically powered off when the tty is closed. You can't even
>>> touch the registers in some cases (eg a PCI port in D3

Ok, I think it is time to summarize (a little exaggerated) the discussion:

1. technical side:
* you prefer to attach to the tty layer
* you can solve the open/close issue
* you can not solve the rx monitoring issue
* we attach to the uart_port layer
* we have a working solution
* we avoid to handle rx monitoring and rx data processing separately

2. non-techncial side ("belief" level)
* you see the GTA04 as a small corner case which is not worth considering
* you do not account for others who have expressed that they are looking for something very similar
* you point out alternatives:
	* user space daemon
	* /sysfs control
	* virtual gpio
  but we are sitting between all chairs because all subsystems are directing us elsewhere
* you don't wan't anyone to touch uart_port because it may get magically removed
* you don't want to accept new interfaces since you fear that nobody maintains them
* and deprecating is also not a way to go because users will whine instead of following

This is impossible to argue against on technical level (except for the alternatives
because they are differently power efficient and fast - but they are also sort of
"beliefs" unless someone really benchmarks them).

Unfortunately how this discussion turned, breaks my believe that our project is something
exceptional and really welcome :(

Especially as I don't understand your role in this discussion (you are not listed as a MAINTAINER
of tty/serial-core).

And we see that almost all other smartphone projects who use Linux don't even think about
mainlining their things (just a note: our special Community is called "Open Pho(n)e (w. Li)nux"
and therefore *is* Linux (=kernel) based).

They just *use* Linux but don't contribute. If we are happy, they publish the sources
and some volunteer takes the time to integrate it into mainline. But may face the
same barriers as we do.

How this discussion went is a little disillusioning for me about the openness of
open source projects. It is open to discuss, but needs too much energy to really
contribute to the official project. Energy that is urgently missing elsewhere.

So I am now thinking about a third option (because daemon is not a good
option for me): we run our own kernel branch where we maintain these UART peer
patches. And rebase on top of every Linux release that comes. So it will
be available and maintained by the GTA04 project. But not on kernel.org.

That this is the outcome makes me sad because our dream is to be able
to say to everyone who wants "the" kernel: look at kernel.org. But this needs
acceptance. We were not able to get over 3 years of trying.

Going this way saves me a lot of enthusiasm to be put into pushing forwards
other things. And is not much work to maintain. Much less than rewriting the
code according to your proposals.

>From time to time we will tease LKML that there is something. And maybe
as time passes, you might reconsider everything.

BR and thanks for your PoV,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> The problem is that *I* have no control over user space. But I also don't want
> to say to my users "that is not my problem - get it solved yourself". This does
> not help them.

Stuffing things into the kernel because the user space of a given
platform can't get itself organised isn't helpful to the other billion
plus Linux devices out there.

> And, most device drivers are corner cases since they are special solutions
> for singular platforms.

Actually that is quite a small percentage - and the corner cases hide in
drivers not in the core code, which is really important for
maintainability.

> >> I'm glad - because it raises some hard questions and while I don't agree
> >> with some of your starting points (like needing to "open" a uart without
> >> user space
> 
> If have an idea how to turn off the device at boot time, before any user space
> daemon is running, we can of course ignore that.

Your early user space is responsible for it. If you can't accept that
then I don't see any point continuing the conversation.

> >> But see below as I think your mental model is perhaps wrong
> >> and this is a point of confusion ?
> 
> Maybe you do not accept that I want to keep as low level as reasonable (for me).

It's always "for me". No the kernel project is not "for me"

> >> Both of those techniques work in mainline without kernel changes (at
> >> least on devices where the right gpio sysfs nodes exist
> 
> they do not exist...

For most they do because they are gpio lines so exportable to userspace.

> >> This I think is actually the really hard and interesting part of the
> >> problem. The "tell me about open and close" case is simple and can be
> >> done via tty_port today with minimal extra hooks. There is a small
> >> question about how you set those hooks from a DT binding
> 
> tty has no binding. An UART hardware has. Another reason for me to
> start with UARTs.

Every uart is a tty_port, every non uart is a tty_port. There is no
reason you can't bind to a non uart device. Your current patches create
bindings for the uart layer.

> >> For some hardware that is the only way I know to do this because the
> >> power hungry uart receiver is physically powered down. I would have to
> >> check but I *think* that is true even on a modern x86 PC that supports
> >> wakeups via serial - although it may be well hidden in ACPI and firmware.
> 
> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.

That I am unsure about - at some point it is going to have to be sorted
because it is increasingly common (if currently mostly invisible)
 
> >> I'm not personally opoosed to the tty slave idea providing it ends up
> >> attached to the tty_port not just uart.
> 
> Well if you can tell us how to handle the data path I have no problems with it
> to attach to the tty level.

If your port is closed you have no data path. If you are using uart you
have no data path because while your patch hooks a helper that some uarts
use some of the time it's optional and a lot of uarts don't use it, so
its not even uart generic.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>> The problem is that *I* have no control over user space. But I also don't want
>> to say to my users "that is not my problem - get it solved yourself". This does
>> not help them.
> 
> Stuffing things into the kernel because the user space of a given
> platform can't get itself organised isn't helpful to the other billion
> plus Linux devices out there.

The assumption that there is  "the" user space of a given platform is wrong.

> 
>> And, most device drivers are corner cases since they are special solutions
>> for singular platforms.
> 
> Actually that is quite a small percentage - and the corner cases hide in
> drivers not in the core code, which is really important for
> maintainability.
> 
>>>> I'm glad - because it raises some hard questions and while I don't agree
>>>> with some of your starting points (like needing to "open" a uart without
>>>> user space
>> 
>> If have an idea how to turn off the device at boot time, before any user space
>> daemon is running, we can of course ignore that.
> 
> Your early user space is responsible for it. If you can't accept that
> then I don't see any point continuing the conversation.

Exactly. There are two reasons:
* we want to make sure that it works for any user space
* it should be done as early as possible

> 
>>>> But see below as I think your mental model is perhaps wrong
>>>> and this is a point of confusion ?
>> 
>> Maybe you do not accept that I want to keep as low level as reasonable (for me).
> 
> It's always "for me". No the kernel project is not "for me"
> 
>>>> Both of those techniques work in mainline without kernel changes (at
>>>> least on devices where the right gpio sysfs nodes exist
>> 
>> they do not exist...
> 
> For most they do because they are gpio lines so exportable to userspace.
> 
>>>> This I think is actually the really hard and interesting part of the
>>>> problem. The "tell me about open and close" case is simple and can be
>>>> done via tty_port today with minimal extra hooks. There is a small
>>>> question about how you set those hooks from a DT binding
>> 
>> tty has no binding. An UART hardware has. Another reason for me to
>> start with UARTs.
> 
> Every uart is a tty_port, every non uart is a tty_port. There is no
> reason you can't bind to a non uart device. Your current patches create
> bindings for the uart layer.

Yes and no. The &uart { compatible = "something"; } already exists.

> 
>>>> For some hardware that is the only way I know to do this because the
>>>> power hungry uart receiver is physically powered down. I would have to
>>>> check but I *think* that is true even on a modern x86 PC that supports
>>>> wakeups via serial - although it may be well hidden in ACPI and firmware.
>> 
>> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.
> 
> That I am unsure about - at some point it is going to have to be sorted
> because it is increasingly common (if currently mostly invisible)
> 
>>>> I'm not personally opoosed to the tty slave idea providing it ends up
>>>> attached to the tty_port not just uart.
>> 
>> Well if you can tell us how to handle the data path I have no problems with it
>> to attach to the tty level.
> 
> If your port is closed you have no data path. If you are using uart you
> have no data path because while your patch hooks a helper that some uarts
> use some of the time it's optional and a lot of uarts don't use

I wasn't aware that lots of uart's don't use it. At least one is using it. I would have
to check which percentage is using it and which isn't. Thanks for pointing this
out.

> it, so
> its not even uart generic.

Understood. I wasn't aware of that.

I just was under the false impression that this is the recommended common
and a well designed (object oriented) interface. struct uart_port
being the object and the uart_ops assigned to it, being the list of methods
that can be applied to an uart_port.

http://lxr.free-electrons.com/source/Documentation/serial/driver#L14
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L45
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L235

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dmitry Torokhov]

On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
<andrey.vostrikov@cogentembedded.com> wrote:
>
> Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space.
> Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'.

That was done mainly because almost none of the serial protocols could
be auto-probed, so device initialization/setup was moved out of kernel
and thus we have the separate line discipline and inputattach utility.

Thanks.

-- 
Dmitry

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Vostrikov Andrey]

Hi, Dmitry.

> On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
> <andrey.vostrikov@cogentembedded.com> wrote:
>>
>> Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space.
>> Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'.

> That was done mainly because almost none of the serial protocols could
> be auto-probed, so device initialization/setup was moved out of kernel
> and thus we have the separate line discipline and inputattach utility.

This  is understandable for "dummy" devices like mice, that only
report input events.

But  in  case there is "intellectual" MCU, that must reply on specific
commands  with specific response - it could be auto-probed. Especially
when it is hardwired. Unfortunately, there  is  no  API  to  do  it.
Opening  port and attaching line discipline  from  kernel  side
does  not  look good. The only example is '/dev/console', which is
implemented that way.

> Thanks.

-- 
Best regards,
Andrey Vostrikov

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Tomeu Vizoso]

On 20 January 2016 at 19:03, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
>
>>> The problem is that *I* have no control over user space. But I also don't want
>>> to say to my users "that is not my problem - get it solved yourself". This does
>>> not help them.
>>
>> Stuffing things into the kernel because the user space of a given
>> platform can't get itself organised isn't helpful to the other billion
>> plus Linux devices out there.
>
> The assumption that there is  "the" user space of a given platform is wrong.

I'm a bit surprised at the arguments being exchanged here regarding
why the kernel may or may not deal with the detail that a (say) BT
chip is behind a uart.

I would have expected that the main (and IMO sufficient) reason why
the kernel should do it is because the particular bus used to connect
a BT chip to the CPU is a hw detail that a kernel that does its job
should keep to itself. Same as userspace not needing to care if a BT
chip is behind SDIO or USB, why does it have to tell the kernel behind
which UART a BT chip is sitting?

Regards,

Tomeu

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Rob Herring]

On Fri, Jan 22, 2016 at 9:45 AM, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
> On 20 January 2016 at 19:03, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
>>
>>>> The problem is that *I* have no control over user space. But I also don't want
>>>> to say to my users "that is not my problem - get it solved yourself". This does
>>>> not help them.
>>>
>>> Stuffing things into the kernel because the user space of a given
>>> platform can't get itself organised isn't helpful to the other billion
>>> plus Linux devices out there.
>>
>> The assumption that there is  "the" user space of a given platform is wrong.
>
> I'm a bit surprised at the arguments being exchanged here regarding
> why the kernel may or may not deal with the detail that a (say) BT
> chip is behind a uart.
>
> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Thanks for writing exactly what I had not gotten around to writing.
You are exactly right. While historically UART devices where not
probe-able like SDIO (in theory) and USB are and maybe that was a
reason to handle in userspace, we do have the technology to describe
the UART connections now.

Adding Marcel who has also previously commented on the reasons why
this belongs in the kernel [1].

Rob

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002212.html

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Lots of reasons, some historic some not

1. Different BT chips have different interfaces, especially when it gets
to stuff like firmware reprogramming

2. In many cases we don't know at the kernel level where there are BT
uarts. It's improving with recent ACPI but for many systems it's simply
not available to the OS

3. The power management for a lot of BT (especially on device tree) is
not actually expressed, so you need a slightly customised daemon for each
device - that one is ugly but the serial and bt layers can't fix it.

4. Because you don't want to just automatically load and turn on
bluetooth just because it is there - it burns power


There is lots of stuff we probe and bind via user space - most things
these days in fact. That's much of why we have notifiers and udev. It's
frequently a win in flexibility, security and configurability to do stuff
via user daemons. We do it for example with all the volume management,
raid and disk encryption.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

On Fri, 22 Jan 2016 20:12:29 +0000
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:

> > I would have expected that the main (and IMO sufficient) reason why
> > the kernel should do it is because the particular bus used to connect
> > a BT chip to the CPU is a hw detail that a kernel that does its job
> > should keep to itself. Same as userspace not needing to care if a BT
> > chip is behind SDIO or USB, why does it have to tell the kernel behind
> > which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming
> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS
> 
Same is true for i2c devices. The solution there is that you have various
methods for providing the information to the kernel, some 
are autoprobed, some are via board files and you can also tell via sysfs
that there is one device.

> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.
> 
That boils down to a circular it is not there because it is not there.
If we express the power management, it can be done in kernel.

> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power
> 
Exactly the same is true for wifi and for many other devices for
which drivers are automatically handled in kernel, too.
Well, do you have a list of devices which do not burn power?
I would be highly interested in those.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 22.01.2016 um 21:12 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>> I would have expected that the main (and IMO sufficient) reason why
>> the kernel should do it is because the particular bus used to connect
>> a BT chip to the CPU is a hw detail that a kernel that does its job
>> should keep to itself. Same as userspace not needing to care if a BT
>> chip is behind SDIO or USB, why does it have to tell the kernel behind
>> which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming

HCI protocol is quite standardized. And firmware reprogramming is
rarely done. If it is needed, each chip type can have its own driver
module that knows how to inject firmware.

This just needs a decent kernel API for a chip driver to communicate
with the chip.

For SDIO connected WiFi chips it appears that firmware download done
by kernel modules is a standard solution.

> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS

We just need to describe the connection of some peer driver to some
UART by means of DT. Then, kernel level can know.

> 
> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.

The peer chip driver (not the serial or bt layers) could fix it. With help
from bt and serial layers.

> 
> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power

That is obviously something nobody wants.

If the chip must be turned on (or turns on) during boot, the driver
can turn it off right after initialization and make the subsystem sleep
until activated again. Then it does not burn power although it
loads automatically.

> 
> 
> There is lots of stuff we probe and bind via user space - most things
> these days in fact. That's much of why we have notifiers and udev. It's
> frequently a win in flexibility, security and configurability to do stuff
> via user daemons. We do it for example with all the volume management,
> raid and disk encryption.

Because volumes are something users really want to configure. They
can change their hardware configuration every now and then. And
there are removable media to be considered.

In our UART cases the underlaying hardware can't be reconfigured. So
there is no need to load this burden of config to the user.

For BT or GPS I just want it to work the same on all devices (independently
on how the specific chip is connected). Kernel should unify such things.
Or it would not be a Un(iplexed)ix.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > There is lots of stuff we probe and bind via user space - most things
> > these days in fact. That's much of why we have notifiers and udev. It's
> > frequently a win in flexibility, security and configurability to do stuff
> > via user daemons. We do it for example with all the volume management,
> > raid and disk encryption.  
> 
> Because volumes are something users really want to configure. They
> can change their hardware configuration every now and then. And
> there are removable media to be considered.

Like USB bluetooth dongles, like systems with external SPI ports, or plug
in SPI devices, or plug in gps devices on other interfaces ?

> In our UART cases the underlaying hardware can't be reconfigured. So
> there is no need to load this burden of config to the user.

Plenty of uarts it can be or the BT can be muxed with other device
endpoints.

> For BT or GPS I just want it to work the same on all devices (independently
> on how the specific chip is connected). Kernel should unify such things.
> Or it would not be a Un(iplexed)ix.

I think you are confusing Unix and Multics.

Unix is nothing to do with Linux and Unix was about creating a beautiful
system not by having a huge crap filled kernel, but by having only the
minimum necessary in the kernel. Unix was not about what was put in but
what was left out.

"We used to sit around in the Unix Room saying, 'What can we throw out?
Why is there this option?" - Doug McIlroy

GPS is a train wreck for commonality. Most GPS requires custom binary
only user space code often obfuscated in order to meet the regulations
governing GPS technology to stop third parties using it for missile
guidance.


Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 23.01.2016 um 18:28 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>>> There is lots of stuff we probe and bind via user space - most things
>>> these days in fact. That's much of why we have notifiers and udev. It's
>>> frequently a win in flexibility, security and configurability to do stuff
>>> via user daemons. We do it for example with all the volume management,
>>> raid and disk encryption.  
>> 
>> Because volumes are something users really want to configure. They
>> can change their hardware configuration every now and then. And
>> there are removable media to be considered.
> 
> Like USB bluetooth dongles, like systems with external SPI ports, or plug
> in SPI devices, or plug in gps devices on other interfaces ?
> 
>> In our UART cases the underlaying hardware can't be reconfigured. So
>> there is no need to load this burden of config to the user.
> 
> Plenty of uarts it can be or the BT can be muxed with other device
> endpoints.

Please give examples where the user can configure such a chip that is
soldered on the same PCB as the SoC.

> 
>> For BT or GPS I just want it to work the same on all devices (independently
>> on how the specific chip is connected). Kernel should unify such things.
>> Or it would not be a Un(iplexed)ix.
> 
> I think you are confusing Unix and Multics.

No, If I write Unix I mean Unix. The "Un" stands for "Uniplexed" which is
a pun of course. But it alludes to "Unification" giving the impression of
"Simplification".

> 
> Unix is nothing to do with Linux and Unix was about creating a beautiful
> system not by having a huge crap filled kernel,

and no crap filled user space.

> but by having only the
> minimum necessary in the kernel. Unix

I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd).

> was not about what was put in but
> what was left out.

Exactly. It left out complexity. E.g. everything is a file. You can use devices
like files. Just open some /dev/tty and get GPS NMEA records...

> 
> "We used to sit around in the Unix Room saying, 'What can we throw out?
> Why is there this option?" - Doug McIlroy

Fine. Let's throw out the idea to configure power on/off a GPS or BT device
by user space daemons for hard wired chips.

> 
> GPS is a train wreck for commonality. Most GPS requires custom binary
> only user space code often obfuscated in order to meet the regulations
> governing GPS technology to stop third parties using it for missile
> guidance.

Most GPS receivers I came across are modules which spit out NMEA
records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
may be others, but I don't want to have all problems of the world solved
at once.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > but by having only the
> > minimum necessary in the kernel. Unix  
> 
> I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd).

No and the quote below is from Doug McIlroy - who amongst other thing
invented pipes.

> > 
> > "We used to sit around in the Unix Room saying, 'What can we throw out?
> > Why is there this option?" - Doug McIlroy  

> Most GPS receivers I came across are modules which spit out NMEA
> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
> may be others, but I don't want to have all problems of the world solved
> at once.

The kernel lives in the big world, not your personal fiefdom

*PLONK*

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 24.01.2016 um 18:10 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:

>>> but by having only the
>>> minimum necessary in the kernel. Unix  
>> 
>> I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd).
> 
> No and the quote below is from Doug McIlroy - who amongst other thing
> invented pipes.

Which is a brilliant concept.

> 
>>> 
>>> "We used to sit around in the Unix Room saying, 'What can we throw out?
>>> Why is there this option?" - Doug McIlroy  

Maybe I am interpreting differently, but "throwing out unnecessary things from
Unix" is logically not the same as "having the minimum necessary in the kernel".

The latter appears to be implying to do *everything* which can be done in user space.
This is what I mean that the goal of throwing out everything not necessary from the
kernel leads to micro-kernel concepts. And neither Unix nor Linux did throw out
enough to become a microkernel. So they still have components which could be
thrown out and moved to user space.

And Unix is kernel + user space. So the citation could also mean that they did
throw out (and simplify) concepts in both areas. Not only from the kernel. So they
did balance and optimize the whole system (which is what I want to achieve as well).

Unfortunately I never had a chance to meet one of the Unix inventors, so I
can't ask them what they really meant and how they did work.

But anyways, this is discussing the wrong problem on the wrong level.

People out there (and me included) would like to hide or better, easier and
more systematically access devices directly connected on the same PCB to
a specific UART. And can't. Or can do only with ugly or inefficient solutions.

>From that we come to this fundamental discussion level because you say that
Linux should be a kernel which should only support the minimum. Therefore our
requests are rejected, because it could be solved by blowing up the user space.

This is IMHO your very valid opinion, but it is not a guideline that I observe when
going through the source tree. There are tons of things that could be done
in user space (e.g. what are all those I2C device drivers good for? /dev/i2c should
suffice to control every device from user space. What is iio good for in the kernel?
a library could translate everything into iio interfaces).

So this discrepancy is what I criticize because I don't see a basic rule or
design principle behind what is acceptable and what is not.

If it exists, please point me to it. I am open to learn about that.

> 
>> Most GPS receivers I came across are modules which spit out NMEA
>> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
>> may be others, but I don't want to have all problems of the world solved
>> at once.
> 
> The kernel lives in the big world, not your personal fiefdom

Every contribution initially looks at the area, the contributor is aware of and
knows best and does not find a solution using existing hooks. Then discussion
starts.

But what a contributor can't (and should never) accept is if his problem is
simply declared to be a non-problem without providing a *better* alternative
solution for it. Better for everybody including the contributor.

> 
> *PLONK*

Thanks.

Well, I have to apologize that I was not yet aware who hides behind the
"one thousand gnomes" e-mail address... Because I judge discussion partners
by what they say now and how they help to solve my actual problem for the future
(and not what they have done in the past).

So you do have a lot of experience with Linux history. And you are amongst
the handful of persons who know every detail of the Linux kernel. That is good
because it shows that you can really influence how this discussion ends.

But sometimes experience could be a little blocking to new ideas and experiences
not related to Linux (e.g. close to hardware or embedded design) brought in by
newcomers.

And it collides with my belief that everything can be done, if people want.

Now, how can we help those who want (for IMHO very understandable reasons)
to access a specific UART from kernel modules?

-- hns