diff for duplicates of <118926C8-F4D0-41F5-B6A8-690E0312F3FB@goldelico.com>
diff --git a/a/1.txt b/N1/1.txt
index cf9a454..e96d636 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,76 +2,101 @@ Hi Rob,
many thanks for picking up this unsolved topic!
> Am 18.08.2016 um 03:14 schrieb Rob Herring <robh@kernel.org>:
->
+>=20
> Currently, devices attached via a UART are not well supported in the
-> kernel. The problem is the device support is done in tty line disciplines,
-> various platform drivers to handle some sideband, and in userspace with
+> kernel. The problem is the device support is done in tty line =
+disciplines,
+> various platform drivers to handle some sideband, and in userspace =
+with
> utilities such as hciattach.
->
-> There have been several attempts to improve support, but they suffer from
-> still being tied into the tty layer and/or abusing the platform bus. This
-> is a prototype to show creating a proper UART bus for UART devices. It is
-> tied into the serial core (really struct uart_port) below the tty layer
+>=20
+> There have been several attempts to improve support, but they suffer =
+from
+> still being tied into the tty layer and/or abusing the platform bus. =
+This
+> is a prototype to show creating a proper UART bus for UART devices. It =
+is
+> tied into the serial core (really struct uart_port) below the tty =
+layer
> in order to use existing serial drivers.
->
+>=20
> This is functional with minimal testing using the loopback driver and
-> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave
+> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the =
+slave
> device). It still needs lots of work and polish.
->
+>=20
> TODOs:
-> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm
+> - Figure out the port locking. mutex plus spinlock plus refcounting? =
+I'm
> hoping all that complexity is from the tty layer and not needed here.
-> - Split out the controller for uart_ports into separate driver. Do we see
+> - Split out the controller for uart_ports into separate driver. Do we =
+see
> a need for controller drivers that are not standard serial drivers?
> - Implement/test the removal paths
-> - Fix the receive callbacks for more than character at a time (i.e. DMA)
+> - Fix the receive callbacks for more than character at a time (i.e. =
+DMA)
> - Need better receive buffering than just a simple circular buffer or
> perhaps a different receive interface (e.g. direct to client buffer)?
> - Test with other UART drivers
> - Convert a real driver/line discipline over to UART bus.
->
-> Before I spend more time on this, I'm looking mainly for feedback on the
-> general direction and structure (the interface with the existing serial
+>=20
+> Before I spend more time on this, I'm looking mainly for feedback on =
+the
+> general direction and structure (the interface with the existing =
+serial
> drivers in particular).
-Some quick comments (can't do any real life tests in the next weeks) from my (biased) view:
+Some quick comments (can't do any real life tests in the next weeks) =
+from my (biased) view:
-* tieing the solution into uart_port is the same as we had done. The difference seems to
- me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation.
+* tieing the solution into uart_port is the same as we had done. The =
+difference seems to
+ me that you completely bypass serial_core (and tty) while we want to =
+integrate it with standard tty operation.
- We have tapped the tty layer only because it can not be 100% avoided if we use serial_core.
+ We have tapped the tty layer only because it can not be 100% avoided =
+if we use serial_core.
-* one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that.
+* one feedback I had received was that there may be uart device drivers =
+not using serial_core. I am not sure if your approach addresses that.
-* what I don't see is how we can implement our GPS device power control driver:
- - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should
- not be completely hidden from user space or represented by a new interface type invented just for this device
- (while the majority of other GPS receivers are still simple tty devices).
- - how we can detect that the device is sending data to the UART while no user space process has the uart port open
+* what I don't see is how we can implement our GPS device power control =
+driver:
+ - the device should still present itself as a tty device (so that cat =
+/dev/ttyO1 reports NMEA records) and should
+ not be completely hidden from user space or represented by a new =
+interface type invented just for this device
+ (while the majority of other GPS receivers are still simple tty =
+devices).
+ - how we can detect that the device is sending data to the UART while =
+no user space process has the uart port open
i.e. when does the driver know when to start/stop the UART.
-* I like that a driver can simply call uart_dev_config(udev, 115200, 'n', 8, 0); instead of our
- uart_register_rx_notification(data->uart, rx_notification, &termios); where we have to partially
+* I like that a driver can simply call uart_dev_config(udev, 115200, =
+'n', 8, 0); instead of our
+ uart_register_rx_notification(data->uart, rx_notification, =
+&termios); where we have to partially
fill the termios structure.
* it appears to need more code than our proposal did:
->
+>=20
> Rob
->
->
+>=20
+>=20
> Rob Herring (3):
> uart bus: Introduce new bus for UART slave devices
> tty: serial_core: make tty_struct optional
> tty: serial_core: add uart controller registration
->
+>=20
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/tty/serial/serial_core.c | 11 +-
> drivers/tty/tty_buffer.c | 2 +
> drivers/uart/Kconfig | 17 ++
> drivers/uart/Makefile | 3 +
-> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++
+> drivers/uart/core.c | 458 =
++++++++++++++++++++++++++++++++++++++++
> drivers/uart/loopback.c | 72 ++++++
> include/linux/serial_core.h | 3 +-
> include/linux/uart_device.h | 163 ++++++++++++++
@@ -91,20 +116,23 @@ vs.
>> 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
->>
+>>=20
>> .../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/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/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
diff --git a/a/content_digest b/N1/content_digest
index 5dfadb8..5706fd2 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -38,76 +38,101 @@
"many thanks for picking up this unsolved topic!\n",
"\n",
"> Am 18.08.2016 um 03:14 schrieb Rob Herring <robh\@kernel.org>:\n",
- "> \n",
+ ">=20\n",
"> Currently, devices attached via a UART are not well supported in the\n",
- "> kernel. The problem is the device support is done in tty line disciplines,\n",
- "> various platform drivers to handle some sideband, and in userspace with\n",
+ "> kernel. The problem is the device support is done in tty line =\n",
+ "disciplines,\n",
+ "> various platform drivers to handle some sideband, and in userspace =\n",
+ "with\n",
"> utilities such as hciattach.\n",
- "> \n",
- "> There have been several attempts to improve support, but they suffer from\n",
- "> still being tied into the tty layer and/or abusing the platform bus. This\n",
- "> is a prototype to show creating a proper UART bus for UART devices. It is\n",
- "> tied into the serial core (really struct uart_port) below the tty layer\n",
+ ">=20\n",
+ "> There have been several attempts to improve support, but they suffer =\n",
+ "from\n",
+ "> still being tied into the tty layer and/or abusing the platform bus. =\n",
+ "This\n",
+ "> is a prototype to show creating a proper UART bus for UART devices. It =\n",
+ "is\n",
+ "> tied into the serial core (really struct uart_port) below the tty =\n",
+ "layer\n",
"> in order to use existing serial drivers.\n",
- "> \n",
+ ">=20\n",
"> This is functional with minimal testing using the loopback driver and\n",
- "> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave\n",
+ "> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the =\n",
+ "slave\n",
"> device). It still needs lots of work and polish.\n",
- "> \n",
+ ">=20\n",
"> TODOs:\n",
- "> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm\n",
+ "> - Figure out the port locking. mutex plus spinlock plus refcounting? =\n",
+ "I'm\n",
"> hoping all that complexity is from the tty layer and not needed here.\n",
- "> - Split out the controller for uart_ports into separate driver. Do we see\n",
+ "> - Split out the controller for uart_ports into separate driver. Do we =\n",
+ "see\n",
"> a need for controller drivers that are not standard serial drivers?\n",
"> - Implement/test the removal paths\n",
- "> - Fix the receive callbacks for more than character at a time (i.e. DMA)\n",
+ "> - Fix the receive callbacks for more than character at a time (i.e. =\n",
+ "DMA)\n",
"> - Need better receive buffering than just a simple circular buffer or\n",
"> perhaps a different receive interface (e.g. direct to client buffer)?\n",
"> - Test with other UART drivers\n",
"> - Convert a real driver/line discipline over to UART bus.\n",
- "> \n",
- "> Before I spend more time on this, I'm looking mainly for feedback on the\n",
- "> general direction and structure (the interface with the existing serial\n",
+ ">=20\n",
+ "> Before I spend more time on this, I'm looking mainly for feedback on =\n",
+ "the\n",
+ "> general direction and structure (the interface with the existing =\n",
+ "serial\n",
"> drivers in particular).\n",
"\n",
- "Some quick comments (can't do any real life tests in the next weeks) from my (biased) view:\n",
+ "Some quick comments (can't do any real life tests in the next weeks) =\n",
+ "from my (biased) view:\n",
"\n",
- "* tieing the solution into uart_port is the same as we had done. The difference seems to\n",
- " me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation.\n",
+ "* tieing the solution into uart_port is the same as we had done. The =\n",
+ "difference seems to\n",
+ " me that you completely bypass serial_core (and tty) while we want to =\n",
+ "integrate it with standard tty operation.\n",
"\n",
- " We have tapped the tty layer only because it can not be 100% avoided if we use serial_core.\n",
+ " We have tapped the tty layer only because it can not be 100% avoided =\n",
+ "if we use serial_core.\n",
"\n",
- "* one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that.\n",
+ "* one feedback I had received was that there may be uart device drivers =\n",
+ "not using serial_core. I am not sure if your approach addresses that.\n",
"\n",
- "* what I don't see is how we can implement our GPS device power control driver:\n",
- " - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should\n",
- " not be completely hidden from user space or represented by a new interface type invented just for this device\n",
- " (while the majority of other GPS receivers are still simple tty devices).\n",
- " - how we can detect that the device is sending data to the UART while no user space process has the uart port open\n",
+ "* what I don't see is how we can implement our GPS device power control =\n",
+ "driver:\n",
+ " - the device should still present itself as a tty device (so that cat =\n",
+ "/dev/ttyO1 reports NMEA records) and should\n",
+ " not be completely hidden from user space or represented by a new =\n",
+ "interface type invented just for this device\n",
+ " (while the majority of other GPS receivers are still simple tty =\n",
+ "devices).\n",
+ " - how we can detect that the device is sending data to the UART while =\n",
+ "no user space process has the uart port open\n",
" i.e. when does the driver know when to start/stop the UART.\n",
"\n",
- "* I like that a driver can simply call uart_dev_config(udev, 115200, 'n', 8, 0); instead of our\n",
- " uart_register_rx_notification(data->uart, rx_notification, &termios); where we have to partially\n",
+ "* I like that a driver can simply call uart_dev_config(udev, 115200, =\n",
+ "'n', 8, 0); instead of our\n",
+ " uart_register_rx_notification(data->uart, rx_notification, =\n",
+ "&termios); where we have to partially\n",
" fill the termios structure.\n",
"\n",
"* it appears to need more code than our proposal did:\n",
"\n",
- "> \n",
+ ">=20\n",
"> Rob\n",
- "> \n",
- "> \n",
+ ">=20\n",
+ ">=20\n",
"> Rob Herring (3):\n",
"> uart bus: Introduce new bus for UART slave devices\n",
"> tty: serial_core: make tty_struct optional\n",
"> tty: serial_core: add uart controller registration\n",
- "> \n",
+ ">=20\n",
"> drivers/Kconfig | 2 +\n",
"> drivers/Makefile | 1 +\n",
"> drivers/tty/serial/serial_core.c | 11 +-\n",
"> drivers/tty/tty_buffer.c | 2 +\n",
"> drivers/uart/Kconfig | 17 ++\n",
"> drivers/uart/Makefile | 3 +\n",
- "> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++\n",
+ "> drivers/uart/core.c | 458 =\n",
+ "+++++++++++++++++++++++++++++++++++++++\n",
"> drivers/uart/loopback.c | 72 ++++++\n",
"> include/linux/serial_core.h | 3 +-\n",
"> include/linux/uart_device.h | 163 ++++++++++++++\n",
@@ -127,20 +152,23 @@
">> tty: serial core: provide a method to search uart by phandle\n",
">> tty: serial_core: add hooks for uart slave drivers\n",
">> misc: Add w2sg0004 gps receiver driver\n",
- ">> \n",
+ ">>=20\n",
">> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt | 18 +\n",
">> .../devicetree/bindings/serial/slaves.txt | 16 +\n",
">> .../devicetree/bindings/vendor-prefixes.txt | 1 +\n",
">> Documentation/serial/slaves.txt | 36 ++\n",
">> drivers/misc/Kconfig | 18 +\n",
">> drivers/misc/Makefile | 1 +\n",
- ">> drivers/misc/w2sg0004.c | 443 +++++++++++++++++++++\n",
+ ">> drivers/misc/w2sg0004.c | 443 =\n",
+ "+++++++++++++++++++++\n",
">> drivers/tty/serial/serial_core.c | 214 +++++++++-\n",
">> include/linux/serial_core.h | 25 +-\n",
">> include/linux/w2sg0004.h | 27 ++\n",
">> 10 files changed, 793 insertions(+), 6 deletions(-)\n",
- ">> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt\n",
- ">> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt\n",
+ ">> create mode 100644 =\n",
+ "Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt\n",
+ ">> create mode 100644 =\n",
+ "Documentation/devicetree/bindings/serial/slaves.txt\n",
">> create mode 100644 Documentation/serial/slaves.txt\n",
">> create mode 100644 drivers/misc/w2sg0004.c\n",
">> create mode 100644 include/linux/w2sg0004.h\n",
@@ -151,4 +179,4 @@
"Nikolaus"
]
-b33a868349627622b3bd280262f87b5bccce0a7b53579663610409f8f32c06fb
+ed37077628d1b0bda417f20382fbc044132e6b4473899fbbb40e65606713823c
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.