On Sun, Jun 28, 2015 at 2:46 PM, Marek Belisko <marek@xxxxxxxxxxxxx> wrote: > From: "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> > > 1. add registered uart_ports to a search list > 2. provide a function to search an uart_port by phandle. This copies the > mechanism how devm_usb_get_phy_by_phandle() works How does this relate to Neil's tty/uart slaves series? > Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> > Signed-off-by: Marek Belisko <marek@xxxxxxxxxxxxx> > --- > Documentation/serial/slaves.txt | 36 ++++++++++++++ You need to split this into DT binding and whatever kernel specific documentation you want. My comment below apply to what goes in the binding doc. > drivers/tty/serial/serial_core.c | 103 +++++++++++++++++++++++++++++++++++++++ > include/linux/serial_core.h | 10 ++++ > 3 files changed, 149 insertions(+) > create mode 100644 Documentation/serial/slaves.txt > > diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt > new file mode 100644 > index 0000000..6f8d44d > --- /dev/null > +++ b/Documentation/serial/slaves.txt > @@ -0,0 +1,36 @@ > +UART slave device support > + > +A remote device connected to a RS232 interface is usually power controlled by the DTR line. > +The DTR line is managed automatically by the UART driver for open() and close() syscalls > +and on demand by tcsetattr(). > + > +With embedded devices, the serial peripheral might be directly and always connected to the UART > +and there might be no physical DTR line involved. Power control (on/off) has to be done by some > +chip specific device driver (which we call "UART slave") through some mechanisms (I2C, GPIOs etc.) > +not related to the serial interface. Some devices do not explicitly tell their power state except > +by sending or not sending data to the UART. In such a case the device driver must be able to monitor > +data activity. The role of the device driver is to encapsulate such power control in a single place. > + > +This patch series allows to support such drivers by providing: > +* a mechanism that a slave driver can identify the UART instance it is connected to > +* a mechanism that UART slave drivers can register to be notified > +* notfications for DTR (and other modem control) state changes This has nothing to do with the binding really, but is rather a Linux driver feature. > +* notifications that the UART has received some data from the UART > + > +A slave device simply adds a phandle reference to the UART it is connected to, e.g. By default I think this should be a sub-node of the uart. There are more complicated cases of combo devices which we may need to support with phandles, but by default we should use sub-nodes to describe connections. > + > + gps { > + compatible = "wi2wi,w2sg0004"; > + uart = <&uart1>; What if you have a device with 2 uart connections? Do you have 2 items in the list or do multiple "<name>-uart" entries? The former is probably sufficient and easier to parse. > + }; > + > +The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart driver. > +This API follows the concept of devm_usb_get_phy_by_phandle(). > + > +A slave device driver registers itself with serial_register_slave() to receive notifications. > +Notification handler callbacks can be registered by serial_register_mctrl_notification() and > +serial_register_rx_notification(). If an UART has registered a NULL slave or a NULL handler, > +no notifications are sent. > + > +RX notification handlers can define a ktermios during setup and the handler function can modify > +or decide to throw away each character that is passed upwards. All these 3 paragraphs should not be in the binding doc. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html