From: "H. Nikolaus Schaller" <hns@goldelico.com> To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Rob Herring <robh@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>, Peter Hurley <peter@hurleysoftware.com>, NeilBrown <neil@brown.name>, Arnd Bergmann <arnd@arndb.de>, Linus Walleij <linus.walleij@linaro.org>, linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Thu, 18 Aug 2016 17:14:21 +0200 [thread overview] Message-ID: <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com> (raw) In-Reply-To: <20160818152528.569eb426@lxorguk.ukuu.org.uk> Hi Alan, > Am 18.08.2016 um 16:25 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > > On Wed, 17 Aug 2016 20:14:42 -0500 > Rob Herring <robh@kernel.org> wrote: > > 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 > layer and even those that do sometimes only use half of it > > b) that you should use the tty_port abstraction > > So instead of just waiting some months and recycling the proposals it's > unfortunate that no listening and reworking was done. > > https://lkml.org/lkml/2016/1/18/177 > > So I'm giving this a large neon flashing NAK, because none of the > problems have been addressed. > >> 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 >> utilities such as hciattach. > > 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 > 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 > of those anyway because they are generally being used for user > 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 >> a need for controller drivers that are not standard serial drivers? > > 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 > 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. > > 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 > 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 (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 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 > many do not do so and the performance hit would be too high. The SoC I have, is using it. > > 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 > tty_port, every tty driver has a tty_port. > > Alan BR, Nikolaus
WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com> To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Rob Herring <robh@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>, Peter Hurley <peter@hurleysoftware.com>, NeilBrown <neil@brown.name>, Arnd Bergmann <arnd@arndb.de>, Linus Walleij <linus.walleij@linaro.org>, linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Thu, 18 Aug 2016 17:14:21 +0200 [thread overview] Message-ID: <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com> (raw) In-Reply-To: <20160818152528.569eb426@lxorguk.ukuu.org.uk> Hi Alan, > 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 >=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 >=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 >> 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 > 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. >=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 > them to be open sourced anyway. >=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 > 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 > 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 (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 have explained plenty of times. Other devices may have orthogonal needs (or suspected needs) and hence a single solution may not fit everybody. =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 > tty_port, every tty driver has a tty_port. >=20 > Alan BR, Nikolaus
next prev parent reply other threads:[~2016-08-19 1:16 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-18 1:14 [RFC PATCH 0/3] UART slave device bus Rob Herring 2016-08-18 1:14 ` [RFC PATCH 1/3] uart bus: Introduce new bus for UART slave devices Rob Herring 2016-08-18 1:14 ` [RFC PATCH 2/3] tty: serial_core: make tty_struct optional Rob Herring 2016-08-18 10:50 ` Pavel Machek 2016-08-18 1:14 ` [RFC PATCH 3/3] tty: serial_core: add uart controller registration Rob Herring 2016-08-18 10:22 ` [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman 2016-08-18 10:22 ` Greg Kroah-Hartman 2016-08-18 10:30 ` Marcel Holtmann 2016-08-18 10:53 ` Greg Kroah-Hartman 2016-08-18 13:53 ` Rob Herring 2016-08-18 13:15 ` Rob Herring 2016-08-18 15:04 ` One Thousand Gnomes 2016-08-18 18:33 ` Rob Herring 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-25 16:40 ` Rob Herring 2016-08-25 16:40 ` Rob Herring 2016-08-26 13:12 ` One Thousand Gnomes 2016-08-18 10:39 ` H. Nikolaus Schaller 2016-08-18 10:39 ` H. Nikolaus Schaller 2016-08-18 10:47 ` Pavel Machek 2016-08-18 10:54 ` H. Nikolaus Schaller 2016-08-18 10:54 ` H. Nikolaus Schaller 2016-08-18 10:57 ` Greg Kroah-Hartman 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 14:40 ` One Thousand Gnomes 2016-08-18 14:40 ` One Thousand Gnomes 2016-08-18 14:58 ` Greg Kroah-Hartman 2016-08-18 11:27 ` H. Nikolaus Schaller 2016-08-18 10:49 ` Marcel Holtmann 2016-08-18 10:55 ` Greg Kroah-Hartman 2016-08-18 11:01 ` Marcel Holtmann 2016-08-18 11:24 ` Greg Kroah-Hartman 2016-08-18 11:42 ` Pavel Machek 2016-08-18 11:42 ` Pavel Machek 2016-08-18 11:51 ` Marcel Holtmann 2016-08-18 11:51 ` Marcel Holtmann 2016-08-18 15:14 ` One Thousand Gnomes 2016-08-18 15:13 ` One Thousand Gnomes 2016-08-18 11:10 ` Pavel Machek 2016-08-18 11:18 ` H. Nikolaus Schaller 2016-08-18 11:49 ` Marcel Holtmann 2016-08-18 12:16 ` H. Nikolaus Schaller 2016-08-18 12:16 ` H. Nikolaus Schaller 2016-08-18 15:15 ` One Thousand Gnomes 2016-08-18 11:47 ` Marcel Holtmann 2016-08-18 13:01 ` Pavel Machek 2016-08-18 15:16 ` One Thousand Gnomes 2016-08-18 11:02 ` H. Nikolaus Schaller 2016-08-18 11:02 ` H. Nikolaus Schaller 2016-08-18 11:41 ` Marcel Holtmann 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 11:02 ` Pavel Machek 2016-08-18 13:07 ` Linus Walleij 2016-08-18 17:31 ` Marcel Holtmann 2016-08-18 14:25 ` One Thousand Gnomes 2016-08-18 15:14 ` H. Nikolaus Schaller [this message] 2016-08-18 15:14 ` H. Nikolaus Schaller 2016-08-18 15:38 ` One Thousand Gnomes 2016-08-18 18:31 ` H. Nikolaus Schaller 2016-08-18 18:31 ` H. Nikolaus Schaller 2016-08-18 22:25 ` Rob Herring 2016-08-19 11:38 ` One Thousand Gnomes 2016-08-19 15:36 ` Sebastian Reichel 2016-08-18 20:29 ` Sebastian Reichel 2016-08-18 23:08 ` Rob Herring 2016-08-19 5:21 ` Sebastian Reichel 2016-08-19 7:29 ` H. Nikolaus Schaller 2016-08-19 7:49 ` Oleksij Rempel 2016-08-19 7:49 ` Oleksij Rempel 2016-08-19 17:50 ` H. Nikolaus Schaller 2016-08-19 20:19 ` Oleksij Rempel 2016-08-19 20:19 ` Oleksij Rempel 2016-08-20 13:34 ` One Thousand Gnomes 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-22 20:39 ` Sebastian Reichel 2016-08-22 21:23 ` H. Nikolaus Schaller 2016-08-22 21:43 ` Arnd Bergmann 2016-08-22 22:42 ` Sebastian Reichel 2016-08-22 22:52 ` One Thousand Gnomes 2016-08-22 23:10 ` Sebastian Reichel 2016-08-23 7:28 ` H. Nikolaus Schaller 2016-08-27 12:01 ` Michal Suchanek 2016-08-19 11:06 ` One Thousand Gnomes 2016-08-19 17:42 ` H. Nikolaus Schaller 2016-08-19 17:42 ` H. Nikolaus Schaller 2016-08-20 13:22 ` One Thousand Gnomes 2016-08-20 13:22 ` One Thousand Gnomes 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 17:09 ` One Thousand Gnomes 2016-08-21 18:23 ` H. Nikolaus Schaller 2016-08-21 18:23 ` H. Nikolaus Schaller 2016-08-22 9:09 ` One Thousand Gnomes 2016-08-22 9:33 ` Marcel Holtmann 2016-08-22 9:33 ` Marcel Holtmann 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-19 14:44 ` Sebastian Reichel 2016-08-22 12:37 ` Arnd Bergmann 2016-08-22 13:38 ` Rob Herring 2016-08-22 15:24 ` Arnd Bergmann 2016-08-22 15:28 ` Marcel Holtmann 2016-08-22 15:46 ` Arnd Bergmann 2016-08-22 15:45 ` One Thousand Gnomes 2016-08-22 21:07 ` Marcel Holtmann 2016-08-22 21:35 ` One Thousand Gnomes 2016-08-22 22:03 ` Sebastian Reichel 2016-08-22 22:46 ` One Thousand Gnomes 2016-08-22 23:41 ` Sebastian Reichel 2016-08-24 12:14 ` Linus Walleij 2016-08-22 16:44 ` Rob Herring 2016-08-22 17:02 ` One Thousand Gnomes 2016-08-22 17:30 ` Rob Herring 2016-08-22 17:30 ` Rob Herring 2016-08-22 17:38 ` One Thousand Gnomes 2016-08-22 21:16 ` Marcel Holtmann 2016-08-22 21:32 ` One Thousand Gnomes 2016-08-22 22:00 ` Pavel Machek 2016-08-22 22:54 ` One Thousand Gnomes 2016-08-22 23:57 ` Sebastian Reichel 2016-08-23 0:15 ` One Thousand Gnomes 2016-08-23 0:57 ` Sebastian Reichel 2016-08-24 13:57 ` One Thousand Gnomes 2016-08-24 13:57 ` One Thousand Gnomes 2016-08-24 14:29 ` Marcel Holtmann 2016-08-24 14:29 ` Marcel Holtmann 2016-08-23 11:42 ` Marcel Holtmann 2016-08-22 23:02 ` Sebastian Reichel 2016-08-22 20:00 ` Sebastian Reichel 2016-08-22 22:00 ` Rob Herring 2016-08-22 22:00 ` Rob Herring 2016-08-22 22:18 ` Sebastian Reichel 2016-08-23 21:04 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com \ --to=hns@goldelico.com \ --cc=arnd@arndb.de \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=gregkh@linuxfoundation.org \ --cc=jslaby@suse.com \ --cc=linus.walleij@linaro.org \ --cc=linux-bluetooth@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=marcel@holtmann.org \ --cc=neil@brown.name \ --cc=pavel@ucw.cz \ --cc=peter@hurleysoftware.com \ --cc=robh@kernel.org \ --cc=sre@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.