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 [off-list ref]:

Hi Nikolaus,

H. Nikolaus Schaller wrote:

quoted

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