* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Andy Shevchenko @ 2017-04-03 21:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Tom Zanussi
Cc: Stuart Longland, Nicolas Pitre, Andi Kleen, Greg Kroah-Hartman,
Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdUTW7Fh+3kWKFCToqhaz-+58--=Sx1Zv0KRnVY4bDKOGQ@mail.gmail.com>
+Cc: Tom
Summon Tom to the discussion. He tried once hard to shrink a Linux
kernel to something working in 1M+ RAM on x86.
Tom, sorry, I recall this a bit late, perhaps you might be interested
in reading discussion from the beginning.
On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> <stuartl@longlandclan.id.au> wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here? The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> Of course with swap enabled. And swapping like hell.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Uwe Kleine-König @ 2017-04-03 20:54 UTC (permalink / raw)
To: Rob Herring, Fabio Estevam
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAL_JsqL8EQWoqyeyVb5Uj9ZaoB3Uz3yzbo114OR-FRrMEu8s=A@mail.gmail.com>
Hello,
On Mon, Apr 03, 2017 at 03:25:23PM -0500, Rob Herring wrote:
> On Mon, Apr 3, 2017 at 10:01 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi Uwe,
> >
> > On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
> > <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> >> A part of my machine looks as follows (simplified):
> >>
> >> ,------------------------.
> >> | ,---------. |
> >> | | imx25 o--RX----◁---o---
> >> | | o--GPIO--' |
> >> | `---------' |
> >> `------------------------'
> >>
> >> that is, there is a driver on the RX line that must be enabled before
> >> the UART can be used. (That is necessary because the default mux of the
> >> RX pad after reset is an output.)
> >>
> >> To represent this in the device tree I do:
> >>
> >> pinctrl_uart5: uart5 {
> >> fsl,pins = <
> >> ...
> >> MX25_PAD_LBA__UART5_RXD 0x00000000
> >> MX25_PAD_CS5__GPIO_3_21 0x00002001
> >> ...
> >> };
> >>
> >> &uart5 {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&pinctrl_uart5>;
> >>
> >> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
>
> enable-gpios
ack.
> I imagine you already know this needs documentation. Make it common please.
Sure, I first wanted to collect some feedback to get an idea if this
would be accepted at all.
The only candidate for common code to add this functionality would be
uart_add_one_port. I wonder if this is early enough in every case.
> >> ...
> >> };
> >>
> >> This way it's ensured that the gpio is only enabled when the LBA pad is
> >> muxed as RX (together with the bootloader that sets the GPIO high).
> >>
> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > Since this is not imx serial specific it could be made more generic.
> >
> > What about extending
> > Documentation/devicetree/bindings/serial/slave-device.txt to handle
> > this GPIO, or maybe a regulator?
I could add a regulator that would do the right thing, that would not
match the hardware though.
> This is more like a phy than a device you talk to. It could also be
> something like an RS-232 xcvr enable (no one has done that already?).
> I think it belongs in the uart's node. You could additionally have an
> enable-gpios for a slave device.
Yes, I agree here, it is better defined in the uart's node, not in the
slave node.
Is xcvr-enable-gpios or xceiver-enable-gpios a better name?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Adam Borowski @ 2017-04-03 20:32 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Andi Kleen, Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <alpine.LFD.2.20.1704031603160.1847@knanqh.ubzr>
On Mon, Apr 03, 2017 at 04:09:38PM -0400, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Adam Borowski wrote:
>
> > On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > > Except for that (and possibly VT) it is unlikely that people really
> > > rely on the obsolete terminal features from the 70ies. So it's a kind
> > > of cleanup.
> >
> > But... but... but what shall we do without OLCUC?!?
> >
> > I guess sending these features to the pasture would be nice even in
> > mainstream TTY. Probably even without a Kconfig option to restore them.
>
> Thing is... those arcane features don't take much code at all:
>
> if (O_OLCUC(tty))
> c = toupper(c);
>
> That's it. I didn't make the minitty code 5x smaller just by omitting
> those. ;-)
Except, those two lines have two bugs:
* it mangles most non-ASCII (kernel's toupper() hard-codes ISO-8859-1
which no one uses anymore)
* it mangles a number of ANSI codes, making them unusable on any vt100ish
terminal (ie, any post-1980)
I just happened to send an April Fools pull request
(https://github.com/kilobyte/linux.git runes) in which the first commit
fixes these:
https://github.com/kilobyte/linux/commit/268cde7c6dde54fcbc81df68d66b2389d77d01f2
Even though it's a real fix (unlike the subsequent fun), guess why I'm not
sending it to Greg and Jiri...
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Rob Herring @ 2017-04-03 20:25 UTC (permalink / raw)
To: Fabio Estevam
Cc: Uwe Kleine-König,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <CAOMZO5A4e7H-6feNN-cTABOKv+CUCU9Em_yFMhorZwXfeA-h0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 3, 2017 at 10:01 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Uwe,
>
> On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> A part of my machine looks as follows (simplified):
>>
>> ,------------------------.
>> | ,---------. |
>> | | imx25 o--RX----◁---o---
>> | | o--GPIO--' |
>> | `---------' |
>> `------------------------'
>>
>> that is, there is a driver on the RX line that must be enabled before
>> the UART can be used. (That is necessary because the default mux of the
>> RX pad after reset is an output.)
>>
>> To represent this in the device tree I do:
>>
>> pinctrl_uart5: uart5 {
>> fsl,pins = <
>> ...
>> MX25_PAD_LBA__UART5_RXD 0x00000000
>> MX25_PAD_CS5__GPIO_3_21 0x00002001
>> ...
>> };
>>
>> &uart5 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_uart5>;
>>
>> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
enable-gpios
I imagine you already know this needs documentation. Make it common please.
>> ...
>> };
>>
>> This way it's ensured that the gpio is only enabled when the LBA pad is
>> muxed as RX (together with the bootloader that sets the GPIO high).
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Since this is not imx serial specific it could be made more generic.
>
> What about extending
> Documentation/devicetree/bindings/serial/slave-device.txt to handle
> this GPIO, or maybe a regulator?
This is more like a phy than a device you talk to. It could also be
something like an RS-232 xcvr enable (no one has done that already?).
I think it belongs in the uart's node. You could additionally have an
enable-gpios for a slave device.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-03 20:09 UTC (permalink / raw)
To: Adam Borowski
Cc: Andi Kleen, Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <20170403195756.xitzpei2knmwt3sx@angband.pl>
On Mon, 3 Apr 2017, Adam Borowski wrote:
> On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > Except for that (and possibly VT) it is unlikely that people really
> > rely on the obsolete terminal features from the 70ies. So it's a kind
> > of cleanup.
>
> But... but... but what shall we do without OLCUC?!?
>
> I guess sending these features to the pasture would be nice even in
> mainstream TTY. Probably even without a Kconfig option to restore them.
Thing is... those arcane features don't take much code at all:
if (O_OLCUC(tty))
c = toupper(c);
That's it. I didn't make the minitty code 5x smaller just by omitting
those. ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Adam Borowski @ 2017-04-03 19:57 UTC (permalink / raw)
To: Andi Kleen
Cc: Andy Shevchenko, Nicolas Pitre, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <20170403153103.GB22592@two.firstfloor.org>
On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsolete terminal features from the 70ies. So it's a kind
> of cleanup.
But... but... but what shall we do without OLCUC?!?
I guess sending these features to the pasture would be nice even in
mainstream TTY. Probably even without a Kconfig option to restore them.
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-03 19:50 UTC (permalink / raw)
To: Alan Cox
Cc: Andy Shevchenko, Rob Herring, Peter Hurley, Ard Biesheuvel,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm Mailing List
In-Reply-To: <1491242719.3704.33.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4526 bytes --]
On Mon, 3 Apr 2017, Alan Cox wrote:
> > evertheless very convenient to be able to use a standard
> > shell
> > with it.
>
> A standard shell will work over things other than a tty device. It
> really doesn't care so long as it gets a stream of data punctuated by
> end of statement symbols. It'll work over pipes, sockets, from files.
But no job control. No line editing with echo when the shell is busy,
etc.
And actually it is not the TTY support per se that takes the most code.
Just the chardev read/write/poll/open/release stuff is rather
significant. Removing canonical support makes it 7.3K down from 8K.
Removing echo support makes it down to 7.2K. Removing baudrate support =
7.0K. Copying termios to/from user space is horrid: removing that and
we're down to 5.6K. At which point there's only a raw device interface
to serial hardware.
> > I beg to disagree here. First, before you call my code "totally
> > unmaintainable" I'd politely ask you to have a look at it first.
>
> I said the combination makes it more unmaintainable. If you have two
> tty layers one of them faking the API of the other at various interface
> points then if the core tty layer wants to make a major change it no
> longer can - because it'll break the other tty layer. In addition I
> worry it won't be long before someone wants kgdb, gdbstubs and sysrq
> over the cut down console and on it will go.
sysrq is already there. It is handled directly at the UART driver level.
I didn't have to do anything for it.
Isn't kgdb and gdbstubs the same thing? In any case the TTY layer is
also already completely bypassed in that case. Those are in fact just
like kernel console targets that also can read and not just write.
Again, what I'm using is the same low-level UART interface as
drivers/tty/serial/serial_core.c is using to interact with UART drivers.
If someone wants to make a change to that interface, the 30 or so UART
drivers will have to be changed as well. I don't think that would be a
big deal to change the minitty code to follow suit. And I won't hide
under a rock while this happens.
If you're making a change in any of the rest of the existing TTY stack,
then my code won't care as it does not interact with it. I'm not even
using tty_struct at all!
> The uart layer is also known broken as an API - it is itself bloated
> and over-locking (for example if it was being written today kfifo would
> be used). What happens if we want to abolish it or encourage people to
> move away from it (as we IMHO should be) ?
Same answer as above.
> The serio code started with exactly the same problem, but now at least
> talks tty layer. In your case you are tying it to something we
> eventually ought to get rid of.
You won't get rid of UART drivers, right?
> I also find the large scale need for it hard to believe. If you are
> within 64K of running out of memory on your debug/devel device how are
> you going to have space to fix security holes and do upgrades as they
> occur in production (where presumably you don't need the tty driver) ?
Some production devices can do it all in much less RAM than that and
they are being connected to the net. Don't worry, that's not where I see
any Linux derivative go.
Some devices, though, have 256K of on-chip RAM. Those devices will make
it into your surrounding. Having so much more RAM (no pun intended)
they'll be capable of even more damage. Would you be more confident,
when a security issue arises (because it will), to know that some Linux
code base is used rather than any random RTOS out there with only one
hundredth of the actual Linux following? If so please indulge me a bit.
> The kernel doesn't exactly get smaller each release.
No kidding.
This is why a slight shift in the Linux model has to be accommodated
for. We cannot just have a single subsystem to scale to both extremes
all the time anymore. We already have different memory allocators for
different sizes and needs so precedents do exist.
The greatest value in Linux his its interfaces. Doesn't matter if the
kernel internal interfaces change, the value is in having common
interfaces for all Linux developers available anywhere. We should allow
for parallel implementations of subsystems as long as they remain
interchangeable. Hence this mini TTY alternative, and that's only the
beginning.
I'd invite you to read more of the rationale for that here:
https://lkml.org/lkml/2017/3/24/634
It's rather long and I don't want to repeat it all.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Geert Uytterhoeven @ 2017-04-03 19:46 UTC (permalink / raw)
To: Rob Herring
Cc: Stuart Longland, Nicolas Pitre, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Andi Kleen,
linux-serial@vger.kernel.org, Jiri Slaby,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqJh-X_5Dq81vwNWo5txZSC8uQETPTAPS4DPeTh2bDKkwg@mail.gmail.com>
On Mon, Apr 3, 2017 at 8:57 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
>> <stuartl@longlandclan.id.au> wrote:
>>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>>> No PTYs seems like a big limitation. This means no sshd?
>>>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>>> Otherwise you most probably have sufficient resources to run the regular
>>>> TTY code.
>>>
>>> Are we talking small microcontrollers here? The smallest machine in
>>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>>> RAM, and that had a MMU.
>>
>> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
>> Of course with swap enabled. And swapping like hell.
>
> These are different target uses. We're talking about fixed function,
> statically linked user space at the minimum (some may want no
> userspace even). Applications that could use an RTOS instead but
> benefit from the Linux hardware support, features and ecosystem. It's
> not a whole new code base or environment to learn. Maybe Zephyr will
> have traction and improve things, but projects I've been involved with
> using RTOSs generally have discussions around needing to re-write the
> crappy RTOS.
Sure. I just wanted to point out that there was a time you could have
_more_ than you need for small fixed function embedded systems in
2 MiB of RAM.
> The absolute amount of RAM target is not so important. What's
> important is getting to a size feasible for onchip RAM. That's always
> moving (up), but has generally been out of reach for Linux.
DigiKey shows 39 ARM SoCs with 1 MiB or more of RAM.
But once you want 3 MiB or more, the lone winner is Renesas' RZ/A1 (up to
10 MiB).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Rob Herring @ 2017-04-03 18:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stuart Longland, Nicolas Pitre, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Andi Kleen,
linux-serial@vger.kernel.org, Jiri Slaby,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdUTW7Fh+3kWKFCToqhaz-+58--=Sx1Zv0KRnVY4bDKOGQ@mail.gmail.com>
On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> <stuartl@longlandclan.id.au> wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here? The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> Of course with swap enabled. And swapping like hell.
These are different target uses. We're talking about fixed function,
statically linked user space at the minimum (some may want no
userspace even). Applications that could use an RTOS instead but
benefit from the Linux hardware support, features and ecosystem. It's
not a whole new code base or environment to learn. Maybe Zephyr will
have traction and improve things, but projects I've been involved with
using RTOSs generally have discussions around needing to re-write the
crappy RTOS.
The absolute amount of RAM target is not so important. What's
important is getting to a size feasible for onchip RAM. That's always
moving (up), but has generally been out of reach for Linux.
Rob
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Geert Uytterhoeven @ 2017-04-03 18:14 UTC (permalink / raw)
To: Stuart Longland
Cc: Nicolas Pitre, Andi Kleen, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <92fb1e4a-d6df-f55b-c0a1-9c1eb78e3943@longlandclan.id.au>
On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
<stuartl@longlandclan.id.au> wrote:
> On 03/04/17 07:41, Nicolas Pitre wrote:
>>> No PTYs seems like a big limitation. This means no sshd?
>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>> really doubt you'll be able to fit an SSH server in there even if PTYs
>> were supported, unless sshd (or dropbear) can be made really tiny.
>> Otherwise you most probably have sufficient resources to run the regular
>> TTY code.
>
> Are we talking small microcontrollers here? The smallest machine in
> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
> RAM, and that had a MMU.
Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
Of course with swap enabled. And swapping like hell.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Alan Cox @ 2017-04-03 18:05 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Andy Shevchenko, Rob Herring, Peter Hurley, Ard Biesheuvel,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm Mailing List
In-Reply-To: <alpine.LFD.2.20.1704031121520.1847@knanqh.ubzr>
> evertheless very convenient to be able to use a standard
> shell
> with it.
A standard shell will work over things other than a tty device. It
really doesn't care so long as it gets a stream of data punctuated by
end of statement symbols. It'll work over pipes, sockets, from files.
> I beg to disagree here. First, before you call my code "totally
> unmaintainable" I'd politely ask you to have a look at it first.
I said the combination makes it more unmaintainable. If you have two
tty layers one of them faking the API of the other at various interface
points then if the core tty layer wants to make a major change it no
longer can - because it'll break the other tty layer. In addition I
worry it won't be long before someone wants kgdb, gdbstubs and sysrq
over the cut down console and on it will go.
The uart layer is also known broken as an API - it is itself bloated
and over-locking (for example if it was being written today kfifo would
be used). What happens if we want to abolish it or encourage people to
move away from it (as we IMHO should be) ?
The serio code started with exactly the same problem, but now at least
talks tty layer. In your case you are tying it to something we
eventually ought to get rid of.
I also find the large scale need for it hard to believe. If you are
within 64K of running out of memory on your debug/devel device how are
you going to have space to fix security holes and do upgrades as they
occur in production (where presumably you don't need the tty driver) ?
The kernel doesn't exactly get smaller each release.
Alan
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-03 17:27 UTC (permalink / raw)
To: Andi Kleen
Cc: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <20170403153103.GB22592@two.firstfloor.org>
On Mon, 3 Apr 2017, Andi Kleen wrote:
> I like the idea of mintty (if it supported ptys).
In fact PTYs could probably be implemented like another UART driver for
the master side.
But that may come later.
> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsolete terminal features from the 70ies. So it's a kind
> of cleanup.
I wouldn't push for replacing the existing code though. It is stable and
full featured. The mini version may well never be fully standard
compliant to keep the code small.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-03 16:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andi Kleen, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <CAHp75VdgEcyXPxENS87nHLtCEHqB5Z-1_T_W1opSiKqqNpeU2A@mail.gmail.com>
On Mon, 3 Apr 2017, Andy Shevchenko wrote:
> On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Sun, 2 Apr 2017, Andi Kleen wrote:
> >> No PTYs seems like a big limitation. This means no sshd?
>
> > Again, my ultimate system target is in the sub-megabyte of RAM. I
> > really doubt you'll be able to fit an SSH server in there even if PTYs
> > were supported, unless sshd (or dropbear) can be made really tiny.
>
> Are you sure you need Linux there? There is a nice Zephyr project
> (OpenSource RTOS, POSIX compatible) exactly for microcontrollers.
I know that Zephyr is LF endorsed, aim to slow fragmentation in that
space, etc. But it is in itself yet another RTOS. It doesn't look like
it is really POSIX compatible yet, and is certainly not Linux
compatible.
I don't pretend that Linux should always be preferred to Zephyr. For
example, I don't think Linux could ever be used with 32KB of RAM while
Zephyr easily can. However, in the hundreds of KB of RAM, given the
choice between Linux and anything else, I can tell you that many people
would go with Linux.
The goal is really to be able to leverage the existing Linux knowledge
and ecosystem. Be able to develop your application on your PC
workstation, singlestep it, strace it, validate the tiny version of
those kernel subsystems there too with existing fuzers, etc. If a
security issue turns up in your product, you have plenty of people who
are already familiar with the Linux environment, much more than Zephyr
or any other RTOSes.
> While I can agree on making Linux stuff less fatty, I can't agree on
> doing this way. We have for now two subsystems to serve for serial
> devices, you are proposing third one for only narrow class of devices.
> From my point of view is better to achive your goal with existing
> system (as a proof of concept maybe even with ugly #ifdef:fery).
Been there already. It doesn't work. The #ifdef:fery in the existing
code simply doesn't cut it. Because of its flexibility, the existing
code constitutes a stack of many layers each with its own interface and
buffering. It uses much more runtime memory simply because it can afford
it on all existing systems supported by Linux. It can drive a large bank
of modems without a single hiccup if you're still into running a BBS.
That's why the existing code is how it is.
I don't want a proof of concept. I want something that is maintainable.
Adding #ifdef's to the existing code will make the end result way less
maintainable, either for the standard or the mini use case. By being
really small, the maintenance cost of a parallel implementation isn't
very high, certainly much less than trying to maintain a single version
that can scale to both extremes.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-03 16:06 UTC (permalink / raw)
To: Alan Cox
Cc: Rob Herring, Peter Hurley, Ard Biesheuvel, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Andy Shevchenko,
linux-serial@vger.kernel.org, Jiri Slaby, linux-arm Mailing List
In-Reply-To: <1491224186.3704.11.camel@linux.intel.com>
On Mon, 3 Apr 2017, Alan Cox wrote:
> If you need a tiny tiny tty layer console for some kind of not quite
> mini-Linux please just steal the one from Fuzix or something similar
> thats only a couple of K in size and only needs extremely simple send
> byte/rx byte type handlers.
This, however, requires that every UART driver be rewritten to suit this
code. I don't want to lose one of Linux's best advantage which is
extensive hardware support. I want to reuse as much of the existing
hardware drivers as possible unchanged.
I already have code that fits the Linux model and it weights
only 8K.
> Alternatively just compile out tty support entirely. What do you
> actually need ? Console doesn't need tty layer and if you have a
> debug/management interface that doesn't have to be tty and text based
> either.
It is nevertheless very convenient to be able to use a standard shell
with it. I can easily remove canonical mode support and then it is down
to 7.3K. Modem line control and runtime baudrate handling could also
trivially be configured out for yet more saving.
> Being able to compile out tty support would be useful, having two tty
> layers that are intertwined and now both totally unmaintable is not
> IMHO progress.
I beg to disagree here. First, before you call my code "totally
unmaintainable" I'd politely ask you to have a look at it first.
There is also very little intertwining here. My code does not rely on
the existing TTY code (except for the termios baudrate handling which I
factored out). I'm creating my own char devices on one end and
interacting with UART drivers using the same low-level call interface
used by the existing code at the other end. And given that it is much
simpler in termps of capabilities, it is also very easy to maintain.
Nicolas
^ permalink raw reply
* Re: [PATCH v3 0/4] tty/serial: meson_uart: add support for core clock handling
From: Kevin Hilman @ 2017-04-03 15:44 UTC (permalink / raw)
To: Helmut Klein
Cc: devicetree, linux-kernel, linux-serial, linux-amlogic, linux-clk,
linux-arm-kernel
In-Reply-To: <20170331165437.26227-1-hgkr.klein@gmail.com>
Helmut Klein <hgkr.klein@gmail.com> writes:
> To be able to use the three none AO uarts of the meson gx SoCs (uart_A,
s/none/non/
> uart_B & uart_C), the core clock has to be enabled (see chapter 22.3 of
> the public s905 data sheet).
> At least the u-boot of my s905 based media player (netxeon minimx-g)
> doesn't do this. so the driver must enable the clock.
FYI: even if a booloader enablesq clocks, it's important that the kernel
enable clocks that it uses so the kernel can be independent of any
bootloader.
> This patch set does:
> - exposes the UART clock ids to the dtb
> - adds documentation for the dt-bindings of meson_uart
> - adds the core clock handling to the driver
> - adds the core clock handling to meson-gxbb.dtsi and meson-gxl.dtsi
>
> The patchset is based on the branch "master" of the repository in [1]
The master branch in my tree just tracks mainline master branch.
To avoid conflicts with other on-going DT changes, the DT patches should
probably be based on top of my v4.12/dt64 branch.
Kevin
^ permalink raw reply
* Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver
From: Kevin Hilman @ 2017-04-03 15:31 UTC (permalink / raw)
To: Jerome Brunet
Cc: Greg Kroah-Hartman, lkml, Helmut Klein, linux-serial,
Carlo Caione, linux-amlogic, linux-arm-kernel
In-Reply-To: <1491231478.3480.12.camel@baylibre.com>
On Mon, Apr 3, 2017 at 7:57 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote:
>> This patch gets the core clock as provided by the DT and enables it.
>> The code was taken from Amlogic's serial driver, and was tested on my
>> board.
>>
>> Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
>> ---
>> drivers/tty/serial/meson_uart.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
>> index 60f16795d16b..cb99112288eb 100644
>> --- a/drivers/tty/serial/meson_uart.c
>> +++ b/drivers/tty/serial/meson_uart.c
>> @@ -600,6 +600,7 @@ static int meson_uart_probe(struct platform_device *pdev)
>> struct resource *res_mem, *res_irq;
>> struct uart_port *port;
>> struct clk *clk;
>> + struct clk *core_clk;
>> int ret = 0;
>>
>> if (pdev->dev.of_node)
>> @@ -625,6 +626,15 @@ static int meson_uart_probe(struct platform_device *pdev)
>> if (!port)
>> return -ENOMEM;
>>
>> + core_clk = devm_clk_get(&pdev->dev, "core");
>> + if (!IS_ERR(core_clk)) {
>> + ret = clk_prepare_enable(core_clk);
>
> This needs to be balanced with a clk_disable_unprepare() in remove.
>
> You could try play with devm_add_action_or_reset, maybe like this:
>
> devm_add_action_or_reset(dev,
> (void(*)(void *))clk_disable_unprepare,
> core_clk);
>
> Sorry I did not notice it on the v2.
>
>
>> + if (ret) {
>> + dev_err(&pdev->dev, "couldn't enable clkc\n");
>> + return ret;
>> + }
>> + }
>> +
>> clk = clk_get(&pdev->dev, NULL);
>
> I still think you should name this one. Otherwise, what the non AO UART will get
> here will depends on the order it was declared in DT.
Unfortunately, it has to be even a little more complicated.
This driver will need to work with current DT (no clock-names) as well
as newer DT using clock-names for "core" and "xtal". So, you'll have
to first try for "xtal" here, and if it fails, then try NULL.
> To answer your question from the v2, yes I think it is ok to add clock-names to
> the AO-UART. You are doing it for non AO ones so, why not ?
Agreed. And another good reason the driver needs to handle with and
without clock-names.
Kevin
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Andi Kleen @ 2017-04-03 15:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Nicolas Pitre, Andi Kleen, Greg Kroah-Hartman, Jiri Slaby,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm Mailing List
In-Reply-To: <CAHp75VdgEcyXPxENS87nHLtCEHqB5Z-1_T_W1opSiKqqNpeU2A@mail.gmail.com>
> While I can agree on making Linux stuff less fatty, I can't agree on
> doing this way. We have for now two subsystems to serve for serial
> devices, you are proposing third one for only narrow class of devices.
It should be actually most (all?) real serial ones.
> From my point of view is better to achive your goal with existing
> system (as a proof of concept maybe even with ugly #ifdef:fery).
I like the idea of mintty (if it supported ptys).
Except for that (and possibly VT) it is unlikely that people really
rely on the obsolete terminal features from the 70ies. So it's a kind
of cleanup.
-Andi
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Fabio Estevam @ 2017-04-03 15:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <1468400495-10471-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Uwe,
On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> A part of my machine looks as follows (simplified):
>
> ,------------------------.
> | ,---------. |
> | | imx25 o--RX----◁---o---
> | | o--GPIO--' |
> | `---------' |
> `------------------------'
>
> that is, there is a driver on the RX line that must be enabled before
> the UART can be used. (That is necessary because the default mux of the
> RX pad after reset is an output.)
>
> To represent this in the device tree I do:
>
> pinctrl_uart5: uart5 {
> fsl,pins = <
> ...
> MX25_PAD_LBA__UART5_RXD 0x00000000
> MX25_PAD_CS5__GPIO_3_21 0x00002001
> ...
> };
>
> &uart5 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart5>;
>
> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
> ...
> };
>
> This way it's ensured that the gpio is only enabled when the LBA pad is
> muxed as RX (together with the bootloader that sets the GPIO high).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Since this is not imx serial specific it could be made more generic.
What about extending
Documentation/devicetree/bindings/serial/slave-device.txt to handle
this GPIO, or maybe a regulator?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver
From: Jerome Brunet @ 2017-04-03 14:57 UTC (permalink / raw)
To: Helmut Klein, gregkh, carlo, khilman
Cc: linux-serial, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20170331165437.26227-4-hgkr.klein@gmail.com>
On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote:
> This patch gets the core clock as provided by the DT and enables it.
> The code was taken from Amlogic's serial driver, and was tested on my
> board.
>
> Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
> ---
> drivers/tty/serial/meson_uart.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index 60f16795d16b..cb99112288eb 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -600,6 +600,7 @@ static int meson_uart_probe(struct platform_device *pdev)
> struct resource *res_mem, *res_irq;
> struct uart_port *port;
> struct clk *clk;
> + struct clk *core_clk;
> int ret = 0;
>
> if (pdev->dev.of_node)
> @@ -625,6 +626,15 @@ static int meson_uart_probe(struct platform_device *pdev)
> if (!port)
> return -ENOMEM;
>
> + core_clk = devm_clk_get(&pdev->dev, "core");
> + if (!IS_ERR(core_clk)) {
> + ret = clk_prepare_enable(core_clk);
This needs to be balanced with a clk_disable_unprepare() in remove.
You could try play with devm_add_action_or_reset, maybe like this:
devm_add_action_or_reset(dev,
(void(*)(void *))clk_disable_unprepare,
core_clk);
Sorry I did not notice it on the v2.
> + if (ret) {
> + dev_err(&pdev->dev, "couldn't enable clkc\n");
> + return ret;
> + }
> + }
> +
> clk = clk_get(&pdev->dev, NULL);
I still think you should name this one. Otherwise, what the non AO UART will get
here will depends on the order it was declared in DT.
To answer your question from the v2, yes I think it is ok to add clock-names to
the AO-UART. You are doing it for non AO ones so, why not ?
> if (IS_ERR(clk))
> return PTR_ERR(clk);
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Uwe Kleine-König @ 2017-04-03 14:51 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1468400495-10471-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Jul 13, 2016 at 11:01:35AM +0200, Uwe Kleine-König wrote:
> A part of my machine looks as follows (simplified):
>
> ,------------------------.
> | ,---------. |
> | | imx25 o--RX----◁---o---
> | | o--GPIO--' |
> | `---------' |
> `------------------------'
>
> that is, there is a driver on the RX line that must be enabled before
> the UART can be used. (That is necessary because the default mux of the
> RX pad after reset is an output.)
>
> To represent this in the device tree I do:
>
> pinctrl_uart5: uart5 {
> fsl,pins = <
> ...
> MX25_PAD_LBA__UART5_RXD 0x00000000
> MX25_PAD_CS5__GPIO_3_21 0x00002001
> ...
> };
>
> &uart5 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart5>;
>
> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
> ...
> };
>
> This way it's ensured that the gpio is only enabled when the LBA pad is
> muxed as RX (together with the bootloader that sets the GPIO high).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Hello,
>
> I'm not sure about the naming. Do you have a better suggestion how to handle
> this situation?
>
> Best regards
> Uwe
>
> drivers/tty/serial/imx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 0df2b1c091ae..56eaa18aa5be 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -39,6 +39,7 @@
> #include <linux/of_device.h>
> #include <linux/io.h>
> #include <linux/dma-mapping.h>
> +#include <linux/gpio/consumer.h>
>
> #include <asm/irq.h>
> #include <linux/platform_data/serial-imx.h>
> @@ -1987,7 +1988,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
> if (of_get_property(np, "fsl,dte-mode", NULL))
> sport->dte_mode = 1;
>
> - return 0;
> + ret = PTR_ERR_OR_ZERO(devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_HIGH));
> + dev_info(&pdev->dev, "Tralala: ret = %d\n", ret);
That line is a debug left over and obviously should be removed. Other
than taht I still wonder if this patch is good enough for mainline as it
solves a real problem.
Best regards
Uwe
> + return ret;
> }
> #else
> static inline int serial_imx_probe_dt(struct imx_port *sport,
> --
> 2.8.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Rob Herring @ 2017-04-03 14:25 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Jeremy Kerr,
linux-serial, linux-kernel, openbmc, devicetree,
Benjamin Herrenschmidt
In-Reply-To: <20170328054458.29341-3-joel@jms.id.au>
On Tue, Mar 28, 2017 at 04:14:58PM +1030, Joel Stanley wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> Documentation/devicetree/bindings/serial/8250.txt | 2 +
For the binding:
Acked-by: Rob Herring <robh@kernel.org>
> drivers/tty/serial/Kconfig | 10 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/aspeed-vuart.c | 335 ++++++++++++++++++++++
> 4 files changed, 348 insertions(+)
> create mode 100644 drivers/tty/serial/aspeed-vuart.c
^ permalink raw reply
* Re: [PATCH v3 2/3] serial: samsung: Add missing checks for dma_map_single failure
From: Shuah Khan @ 2017-04-03 13:50 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-serial, Sylwester Nawrocki,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Seung-Woo Kim, Joonyoung Shim, Inki Dae,
stable, shuahkh
In-Reply-To: <1491200468-28463-2-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
On Mon, Apr 3, 2017 at 12:21 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> This patch adds missing checks for dma_map_single() failure and proper error
> reporting. Although this issue was harmless on ARM architecture, it is always
> good to use the DMA mapping API in a proper way. This patch fixes the following
> DMA API debug warning:
>
> WARNING: CPU: 1 PID: 3785 at lib/dma-debug.c:1171 check_unmap+0x8a0/0xf28
> dma-pl330 121a0000.pdma: DMA-API: device driver failed to check map error[device address=0x000000006e0f9000] [size=4096 bytes] [mapped as single]
> Modules linked in:
> CPU: 1 PID: 3785 Comm: (agetty) Tainted: G W 4.11.0-rc1-00137-g07ca963-dirty #59
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [<c011aaa4>] (unwind_backtrace) from [<c01127c0>] (show_stack+0x20/0x24)
> [<c01127c0>] (show_stack) from [<c06ba5d8>] (dump_stack+0x84/0xa0)
> [<c06ba5d8>] (dump_stack) from [<c0139528>] (__warn+0x14c/0x180)
> [<c0139528>] (__warn) from [<c01395a4>] (warn_slowpath_fmt+0x48/0x50)
> [<c01395a4>] (warn_slowpath_fmt) from [<c072a114>] (check_unmap+0x8a0/0xf28)
> [<c072a114>] (check_unmap) from [<c072a834>] (debug_dma_unmap_page+0x98/0xc8)
> [<c072a834>] (debug_dma_unmap_page) from [<c0803874>] (s3c24xx_serial_shutdown+0x314/0x52c)
> [<c0803874>] (s3c24xx_serial_shutdown) from [<c07f5124>] (uart_port_shutdown+0x54/0x88)
> [<c07f5124>] (uart_port_shutdown) from [<c07f522c>] (uart_shutdown+0xd4/0x110)
> [<c07f522c>] (uart_shutdown) from [<c07f6a8c>] (uart_hangup+0x9c/0x208)
> [<c07f6a8c>] (uart_hangup) from [<c07c426c>] (__tty_hangup+0x49c/0x634)
> [<c07c426c>] (__tty_hangup) from [<c07c78ac>] (tty_ioctl+0xc88/0x16e4)
> [<c07c78ac>] (tty_ioctl) from [<c03b5f2c>] (do_vfs_ioctl+0xc4/0xd10)
> [<c03b5f2c>] (do_vfs_ioctl) from [<c03b6bf4>] (SyS_ioctl+0x7c/0x8c)
> [<c03b6bf4>] (SyS_ioctl) from [<c010b4a0>] (ret_fast_syscall+0x0/0x3c)
>
> Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions")
> CC: stable@vger.kernel.org # v4.10+
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
Looks good.
Reviewed-by: shuahkh@osg.samsung.com
thanks,
-- Shuah
> This issue was there since adding DMA support, but this patch applies cleanly
> only to v4.10+ kernels due to other changes in the surrounding code.
>
> v3:
> - moved spinlock removal to separate patch, extended commit message
>
> v2:
> - fixed commit id in 'fixes' tag, added 'reviewed-by' tag
> ---
> drivers/tty/serial/samsung.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index 9f3759bdb44f..ca0bcd7fd61f 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -859,7 +859,7 @@ static void s3c24xx_serial_break_ctl(struct uart_port *port, int break_state)
> static int s3c24xx_serial_request_dma(struct s3c24xx_uart_port *p)
> {
> struct s3c24xx_uart_dma *dma = p->dma;
> - unsigned long flags;
> + int ret;
>
> /* Default slave configuration parameters */
> dma->rx_conf.direction = DMA_DEV_TO_MEM;
> @@ -884,8 +884,8 @@ static int s3c24xx_serial_request_dma(struct s3c24xx_uart_port *p)
>
> dma->tx_chan = dma_request_chan(p->port.dev, "tx");
> if (IS_ERR(dma->tx_chan)) {
> - dma_release_channel(dma->rx_chan);
> - return PTR_ERR(dma->tx_chan);
> + ret = PTR_ERR(dma->tx_chan);
> + goto err_release_rx;
> }
>
> dmaengine_slave_config(dma->tx_chan, &dma->tx_conf);
> @@ -894,15 +894,17 @@ static int s3c24xx_serial_request_dma(struct s3c24xx_uart_port *p)
> dma->rx_size = PAGE_SIZE;
>
> dma->rx_buf = kmalloc(dma->rx_size, GFP_KERNEL);
> -
> if (!dma->rx_buf) {
> - dma_release_channel(dma->rx_chan);
> - dma_release_channel(dma->tx_chan);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto err_release_tx;
> }
>
> dma->rx_addr = dma_map_single(p->port.dev, dma->rx_buf,
> dma->rx_size, DMA_FROM_DEVICE);
> + if (dma_mapping_error(p->port.dev, dma->rx_addr)) {
> + ret = -EIO;
> + goto err_free_rx;
> + }
>
> spin_lock_irqsave(&p->port.lock, flags);
>
> @@ -911,8 +913,23 @@ static int s3c24xx_serial_request_dma(struct s3c24xx_uart_port *p)
> UART_XMIT_SIZE, DMA_TO_DEVICE);
>
> spin_unlock_irqrestore(&p->port.lock, flags);
> + if (dma_mapping_error(p->port.dev, dma->tx_addr)) {
> + ret = -EIO;
> + goto err_unmap_rx;
> + }
>
> return 0;
> +
> +err_unmap_rx:
> + dma_unmap_single(p->port.dev, dma->rx_addr, dma->rx_size,
> + DMA_FROM_DEVICE);
> +err_free_rx:
> + kfree(dma->rx_buf);
> +err_release_tx:
> + dma_release_channel(dma->tx_chan);
> +err_release_rx:
> + dma_release_channel(dma->rx_chan);
> + return ret;
> }
>
> static void s3c24xx_serial_release_dma(struct s3c24xx_uart_port *p)
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 1/3] serial: samsung: Use right device for DMA-mapping calls
From: Shuah Khan @ 2017-04-03 13:42 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-serial, Sylwester Nawrocki,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Seung-Woo Kim, Joonyoung Shim, Inki Dae,
stable, shuahkh
In-Reply-To: <1491200468-28463-1-git-send-email-m.szyprowski@samsung.com>
On Mon, Apr 3, 2017 at 12:20 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Driver should provide its own struct device for all DMA-mapping calls instead
> of extracting device pointer from DMA engine channel. Although this is harmless
> from the driver operation perspective on ARM architecture, it is always good
> to use the DMA mapping API in a proper way. This patch fixes following DMA API
> debug warning:
>
> WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1241 check_sync+0x520/0x9f4
> samsung-uart 12c20000.serial: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006df0f580] [size=64 bytes]
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00137-g07ca963 #51
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [<c011aaa4>] (unwind_backtrace) from [<c01127c0>] (show_stack+0x20/0x24)
> [<c01127c0>] (show_stack) from [<c06ba5d8>] (dump_stack+0x84/0xa0)
> [<c06ba5d8>] (dump_stack) from [<c0139528>] (__warn+0x14c/0x180)
> [<c0139528>] (__warn) from [<c01395a4>] (warn_slowpath_fmt+0x48/0x50)
> [<c01395a4>] (warn_slowpath_fmt) from [<c0729058>] (check_sync+0x520/0x9f4)
> [<c0729058>] (check_sync) from [<c072967c>] (debug_dma_sync_single_for_device+0x88/0xc8)
> [<c072967c>] (debug_dma_sync_single_for_device) from [<c0803c10>] (s3c24xx_serial_start_tx_dma+0x100/0x2f8)
> [<c0803c10>] (s3c24xx_serial_start_tx_dma) from [<c0804338>] (s3c24xx_serial_tx_chars+0x198/0x33c)
>
> Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions")
> CC: stable@vger.kernel.org # v4.0+
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
The change looks good.
Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
-- Shuah
> ---
> v3:
> - extended commit message
>
> v2:
> - fixed commit id in 'fixes' tag, added 'reviewed-by' tag
> ---
> drivers/tty/serial/samsung.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index 7a17aedbf902..9f3759bdb44f 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -901,14 +901,13 @@ static int s3c24xx_serial_request_dma(struct s3c24xx_uart_port *p)
> return -ENOMEM;
> }
>
> - dma->rx_addr = dma_map_single(dma->rx_chan->device->dev, dma->rx_buf,
> + dma->rx_addr = dma_map_single(p->port.dev, dma->rx_buf,
> dma->rx_size, DMA_FROM_DEVICE);
>
> spin_lock_irqsave(&p->port.lock, flags);
>
> /* TX buffer */
> - dma->tx_addr = dma_map_single(dma->tx_chan->device->dev,
> - p->port.state->xmit.buf,
> + dma->tx_addr = dma_map_single(p->port.dev, p->port.state->xmit.buf,
> UART_XMIT_SIZE, DMA_TO_DEVICE);
>
> spin_unlock_irqrestore(&p->port.lock, flags);
> @@ -922,7 +921,7 @@ static void s3c24xx_serial_release_dma(struct s3c24xx_uart_port *p)
>
> if (dma->rx_chan) {
> dmaengine_terminate_all(dma->rx_chan);
> - dma_unmap_single(dma->rx_chan->device->dev, dma->rx_addr,
> + dma_unmap_single(p->port.dev, dma->rx_addr,
> dma->rx_size, DMA_FROM_DEVICE);
> kfree(dma->rx_buf);
> dma_release_channel(dma->rx_chan);
> @@ -931,7 +930,7 @@ static void s3c24xx_serial_release_dma(struct s3c24xx_uart_port *p)
>
> if (dma->tx_chan) {
> dmaengine_terminate_all(dma->tx_chan);
> - dma_unmap_single(dma->tx_chan->device->dev, dma->tx_addr,
> + dma_unmap_single(p->port.dev, dma->tx_addr,
> UART_XMIT_SIZE, DMA_TO_DEVICE);
> dma_release_channel(dma->tx_chan);
> dma->tx_chan = NULL;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH RFC v4 07/10] dt-bindings: net: add binding for QCA7000 UART
From: Rob Herring @ 2017-04-03 13:23 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9a094176-ebe7-d906-ca9c-967285e53b07-eS4NqCHxEME@public.gmane.org>
On Tue, Mar 28, 2017 at 06:18:03PM +0200, Stefan Wahren wrote:
> Am 27.03.2017 um 22:30 schrieb Rob Herring:
> > On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> >> This is the serdev binding for the QCA7000 UART driver (Ethernet over UART).
> >>
> >> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> >> ---
> >>
> >> According to this binding are still some questions:
> >>
> >> Where should be the optional hardware flow control defined (at master or slave side)?
> > Probably should be in the slave side. We already have uart-has-rtscts
> > and rts/cts-gpios for the UART. Those mean we have RTS/CTS, but not
> > necessarily that we want to enable them.
> >
> > In many cases, the driver may know what it needs.
>
> Like all the other UART settings the hardware flow control can be
> configured in the QCA7000 firmware and the driver can't detect it.
>
> Property suggestion for the slave side:
>
> use-rtscts
Okay.
> >> Is it okay to have two bindings (qca-qca7000-spi and qca-qca7000-uart) or should they be merged?
> > Are they mutually-exclusive or both are used at the same time?
>
> They are mutually-exclusive because they use the same pins.
>
> > What
> > are the dependencies between the interfaces?
>
> Except they uses the same pins of the QCA7000, i can't see any dependency.
I think they should be a single doc.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Alan Cox @ 2017-04-03 12:56 UTC (permalink / raw)
To: Nicolas Pitre, Andy Shevchenko
Cc: Rob Herring, Peter Hurley, Ard Biesheuvel, Greg Kroah-Hartman,
Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm Mailing List
In-Reply-To: <alpine.LFD.2.20.1704021149550.1847@knanqh.ubzr>
On Sun, 2017-04-02 at 11:55 -0400, Nicolas Pitre wrote:
> On Sun, 2 Apr 2017, Andy Shevchenko wrote:
>
> >
> > +Cc people, who have a key roles in all TTY stuff (btw, why you did
> > miss them?
>
> I used what MAINTAINERS and get_maintainer.pl gave me.
>
I didn't see this until now as I'm mid house move so not following a
lot of l/k.
If you need a tiny tiny tty layer console for some kind of not quite
mini-Linux please just steal the one from Fuzix or something similar
thats only a couple of K in size and only needs extremely simple send
byte/rx byte type handlers.
Alternatively just compile out tty support entirely. What do you
actually need ? Console doesn't need tty layer and if you have a
debug/management interface that doesn't have to be tty and text based
either.
Being able to compile out tty support would be useful, having two tty
layers that are intertwined and now both totally unmaintable is not
IMHO progress.
Alan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox