diff for duplicates of <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com>
diff --git a/a/1.txt b/N1/1.txt
index f9945d9..b48d9cb 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,87 +1,109 @@
Hi Alan,
-> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
->
+> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes =
+<gnomes@lxorguk.ukuu.org.uk>:
+>=20
> On Wed, 17 Aug 2016 20:14:42 -0500
> Rob Herring <robh@kernel.org> wrote:
->
+>=20
> This was proposed ages ago and the point clearly made that
->
-> a) the idea doesn't work because uarts are not required to use the uart
+>=20
+> a) the idea doesn't work because uarts are not required to use the =
+uart
> layer and even those that do sometimes only use half of it
->
+>=20
> b) that you should use the tty_port abstraction
->
-> So instead of just waiting some months and recycling the proposals it's
+>=20
+> So instead of just waiting some months and recycling the proposals =
+it's
> unfortunate that no listening and reworking was done.
->
+>=20
> https://lkml.org/lkml/2016/1/18/177
->
+>=20
> So I'm giving this a large neon flashing NAK, because none of the
> problems have been addressed.
->
+>=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.
->
+>=20
> For most platforms it works very nicely and out of the box. The only
> real issue I have actually seen is the bandwidth issue from early tty
> based 3G modems. That's not hard to fix with some tty buffer changes.
> Basically you need a tty port pointer that is atomic exchangable and
> points either to the usual tty queue logic or to a 'fastpath' handler
-> which just gets thrown a block of bytes and told to use them or lose them
-> - which is the interface the non n_tty ldiscs want anyway. That's exactly
+> which just gets thrown a block of bytes and told to use them or lose =
+them
+> - which is the interface the non n_tty ldiscs want anyway. That's =
+exactly
> what you would need to fix to support in kernel stuff as well. The tty
> queue mechanism for devices that can receive in blocks just becomes a
> fastpath.
->
-> There are some disgusting Android turds floating around out of tree where
-> people use things like userspace GPIO line control but you won't fix most
+>=20
+> There are some disgusting Android turds floating around out of tree =
+where
+> people use things like userspace GPIO line control but you won't fix =
+most
> of those anyway because they are generally being used for user
-> space modules including dumb GPS where the US government rules won't allow
+> space modules including dumb GPS where the US government rules won't =
+allow
> them to be open sourced anyway.
->
->> - Split out the controller for uart_ports into separate driver. Do we see
+>=20
+>> - Split out the controller for uart_ports into separate driver. Do we =
+see
>> a need for controller drivers that are not standard serial drivers?
->
+>=20
> As I told you over six months ago uart_port is not the correct
-> abstraction. You need to be working at the tty_port layer. The original
-> design of tty_port was indeed partly to push towards being able to have a
+> abstraction. You need to be working at the tty_port layer. The =
+original
+> design of tty_port was indeed partly to push towards being able to =
+have a
> serial interface that is in use but not open to user space. The rather
> nice rework that the maintainers have done to put the buffers in the
> tty_port takes it closer still.
->
+>=20
> Plenty of the classic serial port interfaces also don't use the UART
-> layer including every USB device (which is most of them these days), SDIO
+> layer including every USB device (which is most of them these days), =
+SDIO
> and others. USB has to be covered for this to be sensible.
-It looks as if you try to solve a different problem than some of us. Maybe this is
-the reason why you get the impression that nobody is listening to your proposal
+It looks as if you try to solve a different problem than some of us. =
+Maybe this is
+the reason why you get the impression that nobody is listening to your =
+proposal
(but that seems to be common for this topic - I have the impression that
nobody is listening to my proposals... so don't mind).
-I can only talk for my device where I just want to be able to write a driver that
-gets access to a low level physical UART within a SoC (a little abstracted
-by uart_port) to directly talk to a device connected to such an UART for reasons
+I can only talk for my device where I just want to be able to write a =
+driver that
+gets access to a low level physical UART within a SoC (a little =
+abstracted
+by uart_port) to directly talk to a device connected to such an UART for =
+reasons
I have explained plenty of times.
Other devices may have orthogonal needs (or suspected needs) and hence
a single solution may not fit everybody.
-
->
-> Your changes also don't work because serial uart drivers are not obliged
-> to use any of the uart buffering helpers and particularly on the rx side
+=20
+>=20
+> Your changes also don't work because serial uart drivers are not =
+obliged
+> to use any of the uart buffering helpers and particularly on the rx =
+side
> many do not do so and the performance hit would be too high.
The SoC I have, is using it.
->
+>=20
> It's been explained how to make it work with tty_port, every tty is a
-> dynamic file handle life time object bound to a tty_port. Every tty has a
+> dynamic file handle life time object bound to a tty_port. Every tty =
+has a
> tty_port, every tty driver has a tty_port.
->
+>=20
> Alan
BR, Nikolaus
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index f4814f0..023f782 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -40,91 +40,113 @@
[
"Hi Alan,\n",
"\n",
- "> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes <gnomes\@lxorguk.ukuu.org.uk>:\n",
- "> \n",
+ "> Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes =\n",
+ "<gnomes\@lxorguk.ukuu.org.uk>:\n",
+ ">=20\n",
"> On Wed, 17 Aug 2016 20:14:42 -0500\n",
"> Rob Herring <robh\@kernel.org> wrote:\n",
- "> \n",
+ ">=20\n",
"> This was proposed ages ago and the point clearly made that\n",
- "> \n",
- "> a) the idea doesn't work because uarts are not required to use the uart\n",
+ ">=20\n",
+ "> a) the idea doesn't work because uarts are not required to use the =\n",
+ "uart\n",
"> layer and even those that do sometimes only use half of it\n",
- "> \n",
+ ">=20\n",
"> b) that you should use the tty_port abstraction\n",
- "> \n",
- "> So instead of just waiting some months and recycling the proposals it's\n",
+ ">=20\n",
+ "> So instead of just waiting some months and recycling the proposals =\n",
+ "it's\n",
"> unfortunate that no listening and reworking was done.\n",
- "> \n",
+ ">=20\n",
"> https://lkml.org/lkml/2016/1/18/177\n",
- "> \n",
+ ">=20\n",
"> So I'm giving this a large neon flashing NAK, because none of the\n",
"> problems have been addressed.\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",
+ ">=20\n",
"> For most platforms it works very nicely and out of the box. The only\n",
"> real issue I have actually seen is the bandwidth issue from early tty\n",
"> based 3G modems. That's not hard to fix with some tty buffer changes.\n",
"> Basically you need a tty port pointer that is atomic exchangable and\n",
"> points either to the usual tty queue logic or to a 'fastpath' handler\n",
- "> which just gets thrown a block of bytes and told to use them or lose them\n",
- "> - which is the interface the non n_tty ldiscs want anyway. That's exactly\n",
+ "> which just gets thrown a block of bytes and told to use them or lose =\n",
+ "them\n",
+ "> - which is the interface the non n_tty ldiscs want anyway. That's =\n",
+ "exactly\n",
"> what you would need to fix to support in kernel stuff as well. The tty\n",
"> queue mechanism for devices that can receive in blocks just becomes a\n",
"> fastpath.\n",
- "> \n",
- "> There are some disgusting Android turds floating around out of tree where\n",
- "> people use things like userspace GPIO line control but you won't fix most\n",
+ ">=20\n",
+ "> There are some disgusting Android turds floating around out of tree =\n",
+ "where\n",
+ "> people use things like userspace GPIO line control but you won't fix =\n",
+ "most\n",
"> of those anyway because they are generally being used for user\n",
- "> space modules including dumb GPS where the US government rules won't allow\n",
+ "> space modules including dumb GPS where the US government rules won't =\n",
+ "allow\n",
"> them to be open sourced anyway.\n",
- "> \n",
- ">> - Split out the controller for uart_ports into separate driver. Do we see\n",
+ ">=20\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",
- "> \n",
+ ">=20\n",
"> As I told you over six months ago uart_port is not the correct\n",
- "> abstraction. You need to be working at the tty_port layer. The original\n",
- "> design of tty_port was indeed partly to push towards being able to have a\n",
+ "> abstraction. You need to be working at the tty_port layer. The =\n",
+ "original\n",
+ "> design of tty_port was indeed partly to push towards being able to =\n",
+ "have a\n",
"> serial interface that is in use but not open to user space. The rather\n",
"> nice rework that the maintainers have done to put the buffers in the\n",
"> tty_port takes it closer still.\n",
- "> \n",
+ ">=20\n",
"> Plenty of the classic serial port interfaces also don't use the UART\n",
- "> layer including every USB device (which is most of them these days), SDIO\n",
+ "> layer including every USB device (which is most of them these days), =\n",
+ "SDIO\n",
"> and others. USB has to be covered for this to be sensible.\n",
"\n",
- "It looks as if you try to solve a different problem than some of us. Maybe this is\n",
- "the reason why you get the impression that nobody is listening to your proposal\n",
+ "It looks as if you try to solve a different problem than some of us. =\n",
+ "Maybe this is\n",
+ "the reason why you get the impression that nobody is listening to your =\n",
+ "proposal\n",
"(but that seems to be common for this topic - I have the impression that\n",
"nobody is listening to my proposals... so don't mind).\n",
"\n",
- "I can only talk for my device where I just want to be able to write a driver that\n",
- "gets access to a low level physical UART within a SoC (a little abstracted\n",
- "by uart_port) to directly talk to a device connected to such an UART for reasons\n",
+ "I can only talk for my device where I just want to be able to write a =\n",
+ "driver that\n",
+ "gets access to a low level physical UART within a SoC (a little =\n",
+ "abstracted\n",
+ "by uart_port) to directly talk to a device connected to such an UART for =\n",
+ "reasons\n",
"I have explained plenty of times.\n",
"\n",
"Other devices may have orthogonal needs (or suspected needs) and hence\n",
"a single solution may not fit everybody.\n",
- " \n",
- "> \n",
- "> Your changes also don't work because serial uart drivers are not obliged\n",
- "> to use any of the uart buffering helpers and particularly on the rx side\n",
+ "=20\n",
+ ">=20\n",
+ "> Your changes also don't work because serial uart drivers are not =\n",
+ "obliged\n",
+ "> to use any of the uart buffering helpers and particularly on the rx =\n",
+ "side\n",
"> many do not do so and the performance hit would be too high.\n",
"\n",
"The SoC I have, is using it.\n",
"\n",
- "> \n",
+ ">=20\n",
"> It's been explained how to make it work with tty_port, every tty is a\n",
- "> dynamic file handle life time object bound to a tty_port. Every tty has a\n",
+ "> dynamic file handle life time object bound to a tty_port. Every tty =\n",
+ "has a\n",
"> tty_port, every tty driver has a tty_port.\n",
"\n",
- "> \n",
+ ">=20\n",
"> Alan\n",
"\n",
"BR, Nikolaus"
]
-7bdc14df0d90a8067682983536ff4beb71792819086020187b7722cb87c9a806
+8ad20821459b74ebbc8a55ef6c419bf0d4f3d727d74efe08450151d068ae094e
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.