* Re: Insanely high baud rates
From: hpa @ 2018-10-11 14:14 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <20181011133134.085624af@alans-desktop>
On October 11, 2018 5:31:34 AM PDT, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> I'm mostly wondering if it is worth future-proofing for new
>transports. It sounds like we can have a consensus on leaving the upper
>4 bits of the speed fields reserved, but leave the details of
>implementation for the future?
>
>It seems reasonable, although I think the reality is that any future
>transport is not going to be a true serial link, but some kind of
>serial
>emulation layer. For those the speed really only matters to tell
>editors
>and the like not to bother being clever.
>
>I mean - what is the baud rate of a pty ?
>
>Alan
Whatever the master wants it to be...
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: Insanely high baud rates
From: Alan Cox @ 2018-10-11 12:31 UTC (permalink / raw)
To: hpa
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <16D6AB22-697E-498C-A5B2-3AD90B567E86@zytor.com>
> I'm mostly wondering if it is worth future-proofing for new transports. It sounds like we can have a consensus on leaving the upper 4 bits of the speed fields reserved, but leave the details of implementation for the future?
It seems reasonable, although I think the reality is that any future
transport is not going to be a true serial link, but some kind of serial
emulation layer. For those the speed really only matters to tell editors
and the like not to bother being clever.
I mean - what is the baud rate of a pty ?
Alan
^ permalink raw reply
* [PATCH v3 1/1] serial: imx - Add dma buffer confugration via sysfs
From: Fabien Lahoudere @ 2018-10-11 9:25 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-serial, Fabien Lahoudere
In order to optimize serial communication on imx53 and imx6, we may
need to tweak DMA period and buffer length per period.
This patch add sysfs attributes to configure thoses values before
initialising DMA.
For example, you can access values by reading/writing:
/sys/class/tty/ttymxc*/dma_buffer_size
/sys/class/tty/ttymxc*/dma_buffer_count
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
---
Changes since v2:
- Improve attribute documentation
- Fix various typo
- Remove useless debug message
- Clean code
Documentation/ABI/stable/sysfs-driver-imx-uart | 13 ++++
drivers/tty/serial/imx.c | 89 ++++++++++++++++++++++++--
2 files changed, 97 insertions(+), 5 deletions(-)
create mode 100644 Documentation/ABI/stable/sysfs-driver-imx-uart
diff --git a/Documentation/ABI/stable/sysfs-driver-imx-uart b/Documentation/ABI/stable/sysfs-driver-imx-uart
new file mode 100644
index 0000000..0a55fcf
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-imx-uart
@@ -0,0 +1,13 @@
+What: /sys/class/tty/ttymxc*/dma_buffer_count
+Date: October 2018
+Contact: Fabien Lahoudere <fabien.lahoudere@collabora.com>
+Description: imx serial use dma buffer for rx communication. The size of this
+ buffer is splited in several chunk. The number of chunk is
+ determined by the field rx_periods (in struct imx_uart). This
+ attribute allows to modify rx_periods.
+
+What: /sys/class/tty/ttymxc*/dma_buffer_size
+Date: October 2018
+Contact: Fabien Lahoudere <fabien.lahoudere@collabora.com>
+Description: Field rx_period_length (in struct imx_uart) allows us to
+ determine the size of each chunk of rx DMA buffer.
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d4e051b..9622492 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -220,6 +220,8 @@ struct imx_port {
struct scatterlist rx_sgl, tx_sgl[2];
void *rx_buf;
struct circ_buf rx_ring;
+ unsigned int rx_buf_size;
+ unsigned int rx_period_length;
unsigned int rx_periods;
dma_cookie_t rx_cookie;
unsigned int tx_bytes;
@@ -1025,8 +1027,6 @@ static void imx_uart_timeout(struct timer_list *t)
}
}
-#define RX_BUF_SIZE (PAGE_SIZE)
-
/*
* There are two kinds of RX DMA interrupts(such as in the MX6Q):
* [1] the RX DMA buffer is full.
@@ -1121,9 +1121,8 @@ static int imx_uart_start_rx_dma(struct imx_port *sport)
sport->rx_ring.head = 0;
sport->rx_ring.tail = 0;
- sport->rx_periods = RX_DMA_PERIODS;
- sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
+ sg_init_one(sgl, sport->rx_buf, sport->rx_buf_size);
ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
if (ret == 0) {
dev_err(dev, "DMA mapping error for RX.\n");
@@ -1241,7 +1240,8 @@ static int imx_uart_dma_init(struct imx_port *sport)
goto err;
}
- sport->rx_buf = kzalloc(RX_BUF_SIZE, GFP_KERNEL);
+ sport->rx_buf_size = sport->rx_period_length * sport->rx_periods;
+ sport->rx_buf = kzalloc(sport->rx_buf_size, GFP_KERNEL);
if (!sport->rx_buf) {
ret = -ENOMEM;
goto err;
@@ -1702,6 +1702,82 @@ static const char *imx_uart_type(struct uart_port *port)
return sport->port.type == PORT_IMX ? "IMX" : NULL;
}
+
+static ssize_t dma_buffer_size_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned int plen;
+ int ret;
+ struct device *port_device = dev->parent;
+ struct imx_port *sport = dev_get_drvdata(port_device);
+
+ if (sport->dma_chan_rx) {
+ dev_warn(dev, "DMA channel is not initialized\n");
+ return -EBUSY;
+ }
+ ret = kstrtou32(buf, 0, &plen);
+ if (ret == 0) {
+ sport->rx_period_length = plen;
+ ret = count;
+ }
+ return ret;
+}
+
+static ssize_t dma_buffer_size_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct device *port_device = dev->parent;
+ struct imx_port *sport = dev_get_drvdata(port_device);
+
+ return sprintf(buf, "%u\n", sport->rx_period_length);
+}
+
+static DEVICE_ATTR_RW(dma_buffer_size);
+
+static ssize_t dma_buffer_count_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned int periods;
+ int ret;
+ struct device *port_device = dev->parent;
+ struct imx_port *sport = dev_get_drvdata(port_device);
+
+ if (sport->dma_chan_rx) {
+ dev_warn(dev, "DMA channel is not initialized\n");
+ return -EBUSY;
+ }
+ ret = kstrtou32(buf, 0, &periods);
+ if (ret == 0) {
+ sport->rx_periods = periods;
+ ret = count;
+ }
+ return ret;
+}
+
+static ssize_t dma_buffer_count_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct device *port_device = dev->parent;
+ struct imx_port *sport = dev_get_drvdata(port_device);
+
+ return sprintf(buf, "%u\n", sport->rx_periods);
+}
+
+static DEVICE_ATTR_RW(dma_buffer_count);
+
+static struct attribute *imx_uart_attrs[] = {
+ &dev_attr_dma_buffer_size.attr,
+ &dev_attr_dma_buffer_count.attr,
+ NULL
+};
+static struct attribute_group imx_uart_attr_group = {
+ .attrs = imx_uart_attrs,
+};
+
/*
* Configure/autoconfigure the port.
*/
@@ -2233,6 +2309,9 @@ static int imx_uart_probe(struct platform_device *pdev)
sport->port.rs485_config = imx_uart_rs485_config;
sport->port.flags = UPF_BOOT_AUTOCONF;
timer_setup(&sport->timer, imx_uart_timeout, 0);
+ sport->rx_period_length = PAGE_SIZE / RX_DMA_PERIODS;
+ sport->rx_periods = RX_DMA_PERIODS;
+ sport->port.attr_group = &imx_uart_attr_group;
sport->gpios = mctrl_gpio_init(&sport->port, 0);
if (IS_ERR(sport->gpios))
--
1.8.3.1
^ permalink raw reply related
* Re: Insanely high baud rates
From: hpa @ 2018-10-10 20:20 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <20181010211717.30c1f052@alans-desktop>
On October 10, 2018 1:17:17 PM PDT, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>On Tue, 9 Oct 2018 12:19:04 -0700
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in
>glibc,
>> the question came up if we will ever care about baud rates in excess
>of
>> 4 Gbps, even in the relatively remote future.
>
>Even RS485 at 4MBits involves deep magic. I think we are fairly safe.
>Not
>only that but our entire tty layer isn't capable of sustaining anything
>even remotely in that range.
>
>I think its non issue.
>
>Alan
I'm mostly wondering if it is worth future-proofing for new transports. It sounds like we can have a consensus on leaving the upper 4 bits of the speed fields reserved, but leave the details of implementation for the future?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: Insanely high baud rates
From: Alan Cox @ 2018-10-10 20:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <3fcef1c1-d746-ae82-c0e6-f079b1a53ffb@zytor.com>
On Tue, 9 Oct 2018 12:19:04 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
Even RS485 at 4MBits involves deep magic. I think we are fairly safe. Not
only that but our entire tty layer isn't capable of sustaining anything
even remotely in that range.
I think its non issue.
Alan
^ permalink raw reply
* Re: [PATCH v2 0/2] tty: erase buffers when the kernel is done with it.
From: Greg Kroah-Hartman @ 2018-10-10 18:24 UTC (permalink / raw)
To: Milan Broz
Cc: linux-serial, linux-kernel, jslaby, aszlig, torvalds, w,
Daniel Zatovic
In-Reply-To: <c54d108b-729a-5866-53d1-26f2e7d0db2b@gmail.com>
On Wed, Oct 10, 2018 at 08:20:06PM +0200, Milan Broz wrote:
> On 04/10/2018 20:06, Greg Kroah-Hartman wrote:
> > azlig and Milan Broz reported that when the tty layer is done with a
> > buffer, the data can hang around in it for a very long time. That
> > sometimes can "leak" to userspace under some conditions.
> >
> > Because of this, just zero out the data after the tty layer is finished
> > with it, for buffers that we "think" should be zeroed out.
> >
> > v2 - addressed some review comments on the 2/2 patch.
>
> Hello Greg,
>
> together with our intern we re-tested both patches and it fixes the reported problem,
> so, if it helps anything, you can add
>
> Tested-by: Milan Broz <gmazyland@gmail.com>
> Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
>
> Do you plan to add this to linux-next?
Yes, I'll queue it up soon, thanks for testing!
greg k-h
^ permalink raw reply
* Re: [PATCH v2 0/2] tty: erase buffers when the kernel is done with it.
From: Milan Broz @ 2018-10-10 18:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial
Cc: linux-kernel, jslaby, aszlig, gmazyland, torvalds, w,
Daniel Zatovic
In-Reply-To: <20181004180614.25619-1-gregkh@linuxfoundation.org>
On 04/10/2018 20:06, Greg Kroah-Hartman wrote:
> azlig and Milan Broz reported that when the tty layer is done with a
> buffer, the data can hang around in it for a very long time. That
> sometimes can "leak" to userspace under some conditions.
>
> Because of this, just zero out the data after the tty layer is finished
> with it, for buffers that we "think" should be zeroed out.
>
> v2 - addressed some review comments on the 2/2 patch.
Hello Greg,
together with our intern we re-tested both patches and it fixes the reported problem,
so, if it helps anything, you can add
Tested-by: Milan Broz <gmazyland@gmail.com>
Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
Do you plan to add this to linux-next?
Thanks!
Milan
>
> Greg Kroah-Hartman (1):
> tty: wipe buffer if not echoing data
>
> Linus Torvalds (1):
> tty: wipe buffer.
>
> drivers/tty/n_tty.c | 20 +++++++++++++++++---
> drivers/tty/tty_buffer.c | 6 +++++-
> 2 files changed, 22 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* Re: Insanely high baud rates
From: H. Peter Anvin @ 2018-10-09 20:02 UTC (permalink / raw)
To: Willy Tarreau
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <20181009195139.GB30972@1wt.eu>
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about baud rates in excess of
>> 4 Gbps, even in the relatively remote future.
>>
>> If this is something we care about *at all*, I would like to suggest
>> that rather than defining yet another kernel interface, we steal some
>> bits from the MSB of the speed fields, alternatively one of the c_cc
>> bytes (all likearchitectures seem to have c_cc[18] free) or some field,
>> if we can find them, in c_cflags, to indicate an exponent.
>>
>> With 5 bits from the top of the speed fields, the current values would
>> be identical up to 248 Gbps, and values up to ~288 Pbps would be
>> encodable ±2 ppb.
>>
>> In the short term, all we would have to do in the kernel would be
>> erroring out on baud rates higher than 0x0fffffff (2^28-1 due to
>> implicit one aliasing rhe first bit of a 5-bit exponent - less than 2^27
>> are functionally denorms.) However, I'd like to put the glibc
>> infrastructure for this now if this is something we may ever be
>> interested in.
>>
>> Thoughts?
>
> Just my two cents, maybe we can conclude that for now we don't care
> thus don't implement anything, but that everything you identified as
> a possible place to steal bits should be marked "reserved for future
> use, must be sent as zero". This will leave you ample room later to
> decide how to proceed (and maybe it will not be the bps that you'll
> want to change but the number of lanes, or word size, or bit encoding,
> especially at 4 Gbps).
>
Well, it would be nice to be able to pre-enable it in glibc as much as
possible. What I'm thinking of doing is to use a 64-bit "baud_t" type
in glibc, and reserve the upper 4 bits of the speed field as must be
zero (which is de facto the case anyway.) In other to avoid a *huge*
user space ABI versioning mess we need to be able to encode the baud
rate inside a 32-bit speed_t in glibc, and given that I believe it would
be a Very Nice Thing if we could squeeze the information into 32 bits on
the kernel side as well.
So reserving the upper 4 bits I think is The Right Thing. I think that
is actually a null change.
I'm not sure if it would be a good idea to make the kernel -EINVAL on
currently-unused c_cc bytes or c_*flags; I can see pros and cons (the
latter being in no small part that that is not legacy behavior.)
-hpa
^ permalink raw reply
* Re: Insanely high baud rates
From: Willy Tarreau @ 2018-10-09 19:51 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
In-Reply-To: <3fcef1c1-d746-ae82-c0e6-f079b1a53ffb@zytor.com>
On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
>
> If this is something we care about *at all*, I would like to suggest
> that rather than defining yet another kernel interface, we steal some
> bits from the MSB of the speed fields, alternatively one of the c_cc
> bytes (all likearchitectures seem to have c_cc[18] free) or some field,
> if we can find them, in c_cflags, to indicate an exponent.
>
> With 5 bits from the top of the speed fields, the current values would
> be identical up to 248 Gbps, and values up to ~288 Pbps would be
> encodable ±2 ppb.
>
> In the short term, all we would have to do in the kernel would be
> erroring out on baud rates higher than 0x0fffffff (2^28-1 due to
> implicit one aliasing rhe first bit of a 5-bit exponent - less than 2^27
> are functionally denorms.) However, I'd like to put the glibc
> infrastructure for this now if this is something we may ever be
> interested in.
>
> Thoughts?
Just my two cents, maybe we can conclude that for now we don't care
thus don't implement anything, but that everything you identified as
a possible place to steal bits should be marked "reserved for future
use, must be sent as zero". This will leave you ample room later to
decide how to proceed (and maybe it will not be the bps that you'll
want to change but the number of lanes, or word size, or bit encoding,
especially at 4 Gbps).
Regards,
Willy
^ permalink raw reply
* Insanely high baud rates
From: H. Peter Anvin @ 2018-10-09 19:19 UTC (permalink / raw)
To: linux-serial, Linux Kernel Mailing List, Greg Kroah-Hartman,
Jiri Slaby, Johan Hovold, Alexander Viro
[Resending to a wider audience]
In trying to get the termios2 interface actually implemented in glibc,
the question came up if we will ever care about baud rates in excess of
4 Gbps, even in the relatively remote future.
If this is something we care about *at all*, I would like to suggest
that rather than defining yet another kernel interface, we steal some
bits from the MSB of the speed fields, alternatively one of the c_cc
bytes (all likearchitectures seem to have c_cc[18] free) or some field,
if we can find them, in c_cflags, to indicate an exponent.
With 5 bits from the top of the speed fields, the current values would
be identical up to 248 Gbps, and values up to ~288 Pbps would be
encodable ±2 ppb.
In the short term, all we would have to do in the kernel would be
erroring out on baud rates higher than 0x0fffffff (2^28-1 due to
implicit one aliasing rhe first bit of a 5-bit exponent – less than 2^27
are functionally denorms.) However, I'd like to put the glibc
infrastructure for this now if this is something we may ever be
interested in.
Thoughts?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH] serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA
From: Geert Uytterhoeven @ 2018-10-09 17:41 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Yoshihiro Shimoda, Ulrich Hecht, Wolfram Sang, linux-serial,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
On SCIFA and SCIFB serial ports with DMA support (i.e. some ports on
R-Car Gen2 and RZ/G1 SoCs), receive DMA operations are submitted before
the DMA channel pointer is initialized. Hence this fails, and the
driver tries to fall back to PIO. However, at this early phase in the
initialization sequence, fallback to PIO does not work, leading to a
serial port that cannot receive any data.
Fix this by calling sci_submit_rx() after initialization of the DMA
channel pointer.
Reported-by: Jinzai Solution and RVC Test Teams via Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 2c4ee23530ffc022 ("serial: sh-sci: Postpone DMA release when falling back to PIO")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Reported on r8a7790/lager using SCIFA1 on Debug Serial 1.
Tested on r8a7791/koelsch using SCIFA3 on EXIO-B.
This fixes a regression introduced in v4.19-rc1, so please queue for
v4.19.
Thanks!
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index b73b27dc45e60ffb..7e98a4f3ec77abbd 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1614,10 +1614,10 @@ static void sci_request_dma(struct uart_port *port)
hrtimer_init(&s->rx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
s->rx_timer.function = rx_timer_fn;
+ s->chan_rx_saved = s->chan_rx = chan;
+
if (port->type == PORT_SCIFA || port->type == PORT_SCIFB)
sci_submit_rx(s);
-
- s->chan_rx_saved = s->chan_rx = chan;
}
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v12 0/6] Driver for at91 usart in spi mode
From: Lee Jones @ 2018-10-09 9:04 UTC (permalink / raw)
To: Radu Pirea
Cc: Alexandre Belloni, Geert Uytterhoeven, Rob Herring, Mark Rutland,
Nicolas Ferre, Greg KH, Mark Brown, Jiri Slaby, Richard Genoud,
David S. Miller, Mauro Carvalho Chehab, Andrew Morton,
Arnd Bergmann,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <a143edd3c0de2ba98b64e642b4384edf4323be2b.camel@upb.ro>
On Wed, 12 Sep 2018, Radu Pirea wrote:
> On Wed, 2018-09-12 at 14:12 +0100, Lee Jones wrote:
> > On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> >
> > > On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > > > > But ... we can't have it both ways. *Either* it's a true
> > > > > > MFD, in
> > > > > > which case it can/should have 2 separate compatible strings
> > > > > > which can
> > > > > > be specified directly from the DT. *Or* it's not an MFD. In
> > > > > > the
> > > > > > latter case, which I think we're all agreeing on (else we'd
> > > > > > have 2
> > > > > > compatible strings), MFD is not the place to handle this (my
> > > > > > original
> > > > > > point).
> > > > > >
> > > > >
> > > > > If that is what bothers you, then let's move it out of mfd.
> > > >
> > > > As I've already mentioned. I don't just want it moved out of MFD
> > > > and
> > > > shoved somewhere else. My aim is to fix this properly.
> > > >
> > >
> > > If it is out of MFD, then I'm not sure why you would care too much
> > > about
> > > it as you won't be maintaining that code. And I still this what was
> > > done
> > > was correct but I'm open to test what you suggest.
> >
> > I care for the kernel in general, not just the areas I'm responsible
> > for. I guess I'm just that kinda guy! ;)
>
> Well, Lee, like you, I think this driver should not be a MFD driver,
> but Alex has a good point of view.
>
> >
> > > > > > So ... this is a USART device which can do SPI, right?
> > > > > >
> > > > > > My current thinking is that; as this is a USART device first
> > > > > > &
> > > > > > foremost, the USART should be probed in the first instance
> > > > > > regardless,
> > > > > > then if SPI mode is specified it (the USART driver) registers
> > > > > > the SPI
> > > > > > platform driver (as MFD does currently) and exits gracefully,
> > > > > > allowing
> > > > > > the SPI driver to take over.
> > > > > >
> > > > > > Spanner in the works: is it physically possible to change the
> > > > > > mode at
> > > > > > run-time? :s
> > > > >
> > > > > Yes it is possible but on Linux that will not happen without
> > > > > probing
> > > > > the drivers again.
> > > >
> > > > Not sure I understand what you mean.
> > >
> > > I was just commenting on changing the mode at runtime.
> >
> > Oh I see. My question was relating to whether the H/W is physically
> > capable of changing modes on-the-fly, rather than how Linux would
> > handle that. If this is something we'd wish to support, then it
> > would
> > have to be a single driver, which is why I was asking. By separating
> > the drivers this way, we are blocking that as a
> > possibility. Although
> > I guess the OP has already thought about that and made the decision
> > not to support it.
>
> Is possible to change modes on-the-fly, but you have no reason to do
> that. On the PCB you will have a SPI slave or a serial console :)
> Anyway, the current form of the driver, and through this I want to say
> "this ugly hack", allows the user to switch from serial to SPI mode by
> adding only one property to the device tree node of USART. If the
> driver were in his first form, a simple SPI driver, how you will make a
> dtsi file for an IP like this? You will add two nodes for the same IP
> in dtsi and will take care to enable correct node in dts?
> I think this driver is only a tradeoff between having an ugly hack in
> kernel or having an messy device tree.
>
> >
> > > > I'm suggesting that you use the same platform_* interfaces MFD
> > > > uses to
> > > > register the SPI driver if SPI mode has been selected. Only do
> > > > so
> > > > from the appropriate driver i.e. USART.
> > >
> > > Yeah, I understood that but I didn't comment because I'm not sure
> > > this
> > > will work yet.
> >
> > Other drivers already do this.
>
> Can you give me an example please?
Sorry for the delay, I have been on vacation.
Grep for 'platform_device_add' in drivers/
> I am open to suggestions.
>
> Sorry for that acked-by. There was a lot of "reviewed-by", "acked-by",
> etc in a single version and I messed up :).
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] of: base: Change logic in of_alias_get_alias_list()
From: Michal Simek @ 2018-10-09 7:18 UTC (permalink / raw)
To: Rob Herring, Michal Simek
Cc: linux-kernel@vger.kernel.org, Michal Simek, Geert Uytterhoeven,
Greg Kroah-Hartman, devicetree, Jiri Slaby,
open list:SERIAL DRIVERS, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqLNMM6mS1oy1voDAibRk1Srcp7i8e3pESTnM957Rxp4ow@mail.gmail.com>
On 8.10.2018 17:07, Rob Herring wrote:
> On Mon, Oct 8, 2018 at 7:19 AM Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Check compatible string first before setting up bit in bitmap to also
>> cover cases that allocated bitfield is not big enough.
>> Show warning about it but let driver to continue to work with allocated
>> bitfield to keep at least some devices (included console which
>> is commonly close to serial0) to work.
>>
>> Fixes: b1078c355d76 ("of: base: Introduce of_alias_get_alias_list() to check alias IDs")
>> Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation")
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> I have looked at it and I don't think there should be necessary to
>> report error immediately back with partially initialized bitfield.
>> The reason is that still there could be a console device which is most
>> likely below that max limit and it is worth to return at least that nbits
>> properly filled.
>> It will also enable cases that you can still continue to use aliases
>> higher then fields prepared for devices without alias.
>
> Seems reasonable. Plus if you had a new dtb which added an alias
> greater than what the OS version supports, you would break that
> system.
I was checking that with our uart ps driver before I send this patch and
I found out that there is no reason not to support these cases.
Driver will simply find out ids which are free and ready for devices
which don't have alias.
>
>>
>> To be fixed patches are present in tty-next branch.
>>
>> ---
>> drivers/of/base.c | 22 ++++++++++++----------
>> drivers/tty/serial/xilinx_uartps.c | 2 +-
>> 2 files changed, 13 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 908de45f966b..0b9611e196d1 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -1953,13 +1953,15 @@ int of_alias_get_id(struct device_node *np, const char *stem)
>> * The function travels the lookup table to record alias ids for the given
>> * device match structures and alias stem.
>> *
>> - * Return: 0 or -ENOSYS when !CONFIG_OF
>> + * Return: 0 or -ENOSYS when !CONFIG_OF or
>> + * -EINVAL if alias ID is greater then allocated nbits
>
> I think EOVERFLOW or ERANGE would be better as those are less common
> and I take EINVAL as the caller made an error.
That's a good point I was also thinking if EINVAL is good reaction on
this case. I will use EOVERFLOW if there is no issue with it.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH stable v2 2/2] termios, tty/tty_baudrate.c: simplify, auto-generate baud table
From: H. Peter Anvin @ 2018-10-08 17:29 UTC (permalink / raw)
To: Johan Hovold
Cc: linux-kernel, Tobias Klausmann, Greg Kroah-Hartman, Jiri Slaby,
Al Viro, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Alan Cox, stable
In-Reply-To: <20181008154655.GE3332@localhost>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 10/8/18 8:46 AM, Johan Hovold wrote:
>
> So we need a minimal fix for this only as this patch in particular
> should not be backported to stable.
>
> I'm not sure when I'll have time to review this one thoroughly, so
> perhaps others can chime in meanwhile.
>
> Johan
>
OK. In the past Greg has generally liked to avoid fixes which will diverge
from upstream (because code in stable which is not in upstream can make
debugging difficult), but this is the minimal patch as requested; which to
apply is up to Greg.
As far as reviewing the cleanup patch, I strongly recommend:
a) Looking at the resulting file, not at the patch. Most of the code is simply
merging the input and output rate functions into a common help function,
and restructuring the code to that the utterly bizarre coding of a for loop
using a do { ... } while() loop with the initial condition set at variable
declaration(!!) far from the loop itself.
b) Examine bmacros.h after a build.
c) Build drivers/tty/tty_baudrate.s. You can directly examine the baud_table
and verify that it is, indeed, correct for whatever architecture you build.
-hpa
[-- Attachment #2: 0002-termios-tty-tty_baudrate.c-fix-buffer-overrun.patch --]
[-- Type: text/x-patch, Size: 2051 bytes --]
>From c8195635f63508f4c75ef553b4703c4cc3c750e2 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 8 Oct 2018 09:32:00 -0700
Subject: [PATCH 02/16] termios, tty/tty_baudrate.c: fix buffer overrun
On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does
not do any limit checking on the tty_baudrate[] array, and in fact a
buffer overrun is possible on both architectures. Add a limit check to
prevent that situation.
This will be followed by a much bigger cleanup/simplification patch.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Requested-by: Cc: Johan Hovold <johan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eugene Syromiatnikov <esyr@redhat.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-serial@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
---
drivers/tty/tty_baudrate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/tty_baudrate.c b/drivers/tty/tty_baudrate.c
index 7576ceace571..f438eaa68246 100644
--- a/drivers/tty/tty_baudrate.c
+++ b/drivers/tty/tty_baudrate.c
@@ -77,7 +77,7 @@ speed_t tty_termios_baud_rate(struct ktermios *termios)
else
cbaud += 15;
}
- return baud_table[cbaud];
+ return cbaud >= n_baud_table ? 0 : baud_table[cbaud];
}
EXPORT_SYMBOL(tty_termios_baud_rate);
@@ -113,7 +113,7 @@ speed_t tty_termios_input_baud_rate(struct ktermios *termios)
else
cbaud += 15;
}
- return baud_table[cbaud];
+ return cbaud >= n_baud_table ? 0 : baud_table[cbaud];
#else /* IBSHIFT */
return tty_termios_baud_rate(termios);
#endif /* IBSHIFT */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH stable v2 1/2] arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
From: H. Peter Anvin @ 2018-10-08 16:01 UTC (permalink / raw)
To: Johan Hovold
Cc: linux-kernel, Tobias Klausmann, Greg Kroah-Hartman, Jiri Slaby,
Al Viro, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Alan Cox, stable
In-Reply-To: <20181008153840.GD3332@localhost>
On 10/8/18 8:38 AM, Johan Hovold wrote:
> On Sun, Oct 07, 2018 at 09:06:19PM -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
>>
>> Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
>> using arbitrary flags. Because BOTHER is not defined, the general
>> Linux code doesn't allow setting arbitrary baud rates, and because
>> CBAUDEX == 0, we can have an array overrun of the baud_rate[] table in
>> drivers/tty/tty_baudrate.c if (c_cflags & CBAUD) == 037.
>>
>> Resolve both problems by #defining BOTHER to 037 on Alpha.
>>
>> However, userspace still needs to know if setting BOTHER is actually
>> safe given legacy kernels (does anyone actually care about that on
>> Alpha anymore?), so enable the TCGETS2/TCSETS*2 ioctls on Alpha, even
>> though they use the same structure. Define struct termios2 just for
>> compatibility; it is the exact same structure as struct termios. In a
>> future patchset, this will be cleaned up so the uapi headers are
>> usable from libc.
>
> Is this really needed? By defining BOTHER (and IBSHIFT which you forgot
> to mention here) you are enabling arbitrary rates also through TCSETS on
> alpha, right?
>
Yes, it's needed, not because the old ioctls won't work on NEW kernels, but
because Alpha is so far behind the times, *and* the OLD kernels are severely
broken if we pass BOTHER to them, we need a new ioctl number so we can
guarantee that we won't do anything that user space doesn't intend; this is
actually made far worse because if I read the code correctly, the kernel will
still report back BOTHER and the speed field set on a legacy kernel in
response to TCGETS, but the values will be completely bogus.
This means that glibc will need a workaround for Alpha only, and the new ioctl
numbers handles support for it. gcc should be able to fold the code together,
since it should be able to detect that multiple branches of execution are
otherwise identical.
To micro-optimize, we could define TERMIOS_OLD as (CBAUDEX ? 8 : 0) in a
future (non-stable) patch.
We don't need to worry about it on PowerPC because PowerPC implemented this so
long ago, before the current glibc support threshold.
-hpa
^ permalink raw reply
* Re: [PATCH stable v2 2/2] termios, tty/tty_baudrate.c: simplify, auto-generate baud table
From: Johan Hovold @ 2018-10-08 15:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, Tobias Klausmann, Greg Kroah-Hartman, Jiri Slaby,
Al Viro, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, stable
In-Reply-To: <20181008040620.1248277-3-hpa@zytor.com>
On Sun, Oct 07, 2018 at 09:06:20PM -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
>
> Now when all architectures define BOTHER and IBSHIFT, we can
> unconditionally rely on these constants. Furthermore, the code can be
> significantly simplified in a number of places.
>
> Rather than having two tables and needing to be able to keep them in
> sync at all times, have one auto-generated table. This also lets us
> avoid the fact that architectures that have CBAUDEX == 0 have BOTHER
> in a different location that those that don't.
>
> The code for masking CBAUDEX as a fallback is never exercised on any
> architecture, because for all architectures, either the baud rate
> table is completely defined for all CBAUD values, or CBAUDEX == 0, so
> we can just remove it.
>
> Finally, this patch avoids overrunning the baud_table[] for
> architectures with CBAUDEX == 0.
So we need a minimal fix for this only as this patch in particular
should not be backported to stable.
I'm not sure when I'll have time to review this one thoroughly, so
perhaps others can chime in meanwhile.
Johan
^ permalink raw reply
* Re: [PATCH stable v2 1/2] arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
From: Johan Hovold @ 2018-10-08 15:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, Tobias Klausmann, Greg Kroah-Hartman, Jiri Slaby,
Al Viro, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, stable
In-Reply-To: <20181008040620.1248277-2-hpa@zytor.com>
On Sun, Oct 07, 2018 at 09:06:19PM -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
>
> Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
> using arbitrary flags. Because BOTHER is not defined, the general
> Linux code doesn't allow setting arbitrary baud rates, and because
> CBAUDEX == 0, we can have an array overrun of the baud_rate[] table in
> drivers/tty/tty_baudrate.c if (c_cflags & CBAUD) == 037.
>
> Resolve both problems by #defining BOTHER to 037 on Alpha.
>
> However, userspace still needs to know if setting BOTHER is actually
> safe given legacy kernels (does anyone actually care about that on
> Alpha anymore?), so enable the TCGETS2/TCSETS*2 ioctls on Alpha, even
> though they use the same structure. Define struct termios2 just for
> compatibility; it is the exact same structure as struct termios. In a
> future patchset, this will be cleaned up so the uapi headers are
> usable from libc.
Is this really needed? By defining BOTHER (and IBSHIFT which you forgot
to mention here) you are enabling arbitrary rates also through TCSETS on
alpha, right?
Johan
^ permalink raw reply
* Re: [PATCH stable v2 0/2] termios: Alpha BOTHER/IBSHIFT, tty_baudrate fix
From: Johan Hovold @ 2018-10-08 15:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, Tobias Klausmann, Greg Kroah-Hartman, Jiri Slaby,
Al Viro, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, stable
In-Reply-To: <20181008040620.1248277-1-hpa@zytor.com>
On Sun, Oct 07, 2018 at 09:06:18PM -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
>
> It turns out that Alpha is the only architecture that never
> implemented BOTHER and IBSHIFT, which is otherwise ages old. This is
> one thing that has held up glibc support for this feature (all other
> architectures have supported these for about a decade, at least before
> the current 3.2 glibc cutoff.)
>
> Furthermore, in the process of dealing with this, I discovered that
> the current code in tty_baudrate.c can read past the end of the
> baud_table[] on Alpha and PowerPC. The second patch in this series
> fixes that, but it also cleans up the code substantially by
> auto-generating the table and, since all architectures now have them,
> removing all conditionals for BOTHER and IBSHIFT existing.
>
> Tagging for stable because these are concrete and immediate
> problems.
This isn't stable material in its current form. If you want to plug the
alpha and powerpc info leaks in the stable trees, then you need a
minimal fix for that, which you can then your clean ups and new features
on.
Johan
^ permalink raw reply
* Re: [PATCH] of: base: Change logic in of_alias_get_alias_list()
From: Rob Herring @ 2018-10-08 15:07 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel@vger.kernel.org, Michal Simek, Geert Uytterhoeven,
Greg Kroah-Hartman, devicetree, Jiri Slaby,
open list:SERIAL DRIVERS, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <e879d07e97b7f7fc46543315e9fb1b4bc8b7a352.1539001154.git.michal.simek@xilinx.com>
On Mon, Oct 8, 2018 at 7:19 AM Michal Simek <michal.simek@xilinx.com> wrote:
>
> Check compatible string first before setting up bit in bitmap to also
> cover cases that allocated bitfield is not big enough.
> Show warning about it but let driver to continue to work with allocated
> bitfield to keep at least some devices (included console which
> is commonly close to serial0) to work.
>
> Fixes: b1078c355d76 ("of: base: Introduce of_alias_get_alias_list() to check alias IDs")
> Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation")
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> I have looked at it and I don't think there should be necessary to
> report error immediately back with partially initialized bitfield.
> The reason is that still there could be a console device which is most
> likely below that max limit and it is worth to return at least that nbits
> properly filled.
> It will also enable cases that you can still continue to use aliases
> higher then fields prepared for devices without alias.
Seems reasonable. Plus if you had a new dtb which added an alias
greater than what the OS version supports, you would break that
system.
>
> To be fixed patches are present in tty-next branch.
>
> ---
> drivers/of/base.c | 22 ++++++++++++----------
> drivers/tty/serial/xilinx_uartps.c | 2 +-
> 2 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 908de45f966b..0b9611e196d1 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1953,13 +1953,15 @@ int of_alias_get_id(struct device_node *np, const char *stem)
> * The function travels the lookup table to record alias ids for the given
> * device match structures and alias stem.
> *
> - * Return: 0 or -ENOSYS when !CONFIG_OF
> + * Return: 0 or -ENOSYS when !CONFIG_OF or
> + * -EINVAL if alias ID is greater then allocated nbits
I think EOVERFLOW or ERANGE would be better as those are less common
and I take EINVAL as the caller made an error.
> */
> int of_alias_get_alias_list(const struct of_device_id *matches,
> const char *stem, unsigned long *bitmap,
> unsigned int nbits)
> {
> struct alias_prop *app;
> + int ret = 0;
>
> /* Zero bitmap field to make sure that all the time it is clean */
> bitmap_zero(bitmap, nbits);
> @@ -1976,21 +1978,21 @@ int of_alias_get_alias_list(const struct of_device_id *matches,
> continue;
> }
>
> - if (app->id >= nbits) {
> - pr_debug("%s: ID %d greater then bitmap field %d\n",
> - __func__, app->id, nbits);
> - continue;
> - }
> -
> if (of_match_node(matches, app->np)) {
> pr_debug("%s: Allocated ID %d\n", __func__, app->id);
> - set_bit(app->id, bitmap);
> +
> + if (app->id >= nbits) {
> + pr_warn("%s: ID %d >= than bitmap field %d\n",
> + __func__, app->id, nbits);
> + ret = -EINVAL;
> + } else {
> + set_bit(app->id, bitmap);
> + }
> }
> - /* Alias exists but is not compatible with matches */
> }
> mutex_unlock(&of_mutex);
>
> - return 0;
> + return ret;
> }
> EXPORT_SYMBOL_GPL(of_alias_get_alias_list);
>
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index d452dceb0cb3..29a18103182d 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1393,7 +1393,7 @@ static int cdns_get_id(struct platform_device *pdev)
> if (!alias_bitmap_initialized) {
> ret = of_alias_get_alias_list(cdns_uart_of_match, "serial",
> alias_bitmap, MAX_UART_INSTANCES);
> - if (ret) {
> + if (ret && ret != -EINVAL) {
> mutex_unlock(&bitmap_lock);
> return ret;
> }
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] of: base: Change logic in of_alias_get_alias_list()
From: Michal Simek @ 2018-10-08 12:19 UTC (permalink / raw)
To: linux-kernel, monstr, geert, gregkh
Cc: devicetree, Jiri Slaby, Rob Herring, linux-serial, Frank Rowand,
linux-arm-kernel
Check compatible string first before setting up bit in bitmap to also
cover cases that allocated bitfield is not big enough.
Show warning about it but let driver to continue to work with allocated
bitfield to keep at least some devices (included console which
is commonly close to serial0) to work.
Fixes: b1078c355d76 ("of: base: Introduce of_alias_get_alias_list() to check alias IDs")
Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation")
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
I have looked at it and I don't think there should be necessary to
report error immediately back with partially initialized bitfield.
The reason is that still there could be a console device which is most
likely below that max limit and it is worth to return at least that nbits
properly filled.
It will also enable cases that you can still continue to use aliases
higher then fields prepared for devices without alias.
To be fixed patches are present in tty-next branch.
---
drivers/of/base.c | 22 ++++++++++++----------
drivers/tty/serial/xilinx_uartps.c | 2 +-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 908de45f966b..0b9611e196d1 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1953,13 +1953,15 @@ int of_alias_get_id(struct device_node *np, const char *stem)
* The function travels the lookup table to record alias ids for the given
* device match structures and alias stem.
*
- * Return: 0 or -ENOSYS when !CONFIG_OF
+ * Return: 0 or -ENOSYS when !CONFIG_OF or
+ * -EINVAL if alias ID is greater then allocated nbits
*/
int of_alias_get_alias_list(const struct of_device_id *matches,
const char *stem, unsigned long *bitmap,
unsigned int nbits)
{
struct alias_prop *app;
+ int ret = 0;
/* Zero bitmap field to make sure that all the time it is clean */
bitmap_zero(bitmap, nbits);
@@ -1976,21 +1978,21 @@ int of_alias_get_alias_list(const struct of_device_id *matches,
continue;
}
- if (app->id >= nbits) {
- pr_debug("%s: ID %d greater then bitmap field %d\n",
- __func__, app->id, nbits);
- continue;
- }
-
if (of_match_node(matches, app->np)) {
pr_debug("%s: Allocated ID %d\n", __func__, app->id);
- set_bit(app->id, bitmap);
+
+ if (app->id >= nbits) {
+ pr_warn("%s: ID %d >= than bitmap field %d\n",
+ __func__, app->id, nbits);
+ ret = -EINVAL;
+ } else {
+ set_bit(app->id, bitmap);
+ }
}
- /* Alias exists but is not compatible with matches */
}
mutex_unlock(&of_mutex);
- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(of_alias_get_alias_list);
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index d452dceb0cb3..29a18103182d 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1393,7 +1393,7 @@ static int cdns_get_id(struct platform_device *pdev)
if (!alias_bitmap_initialized) {
ret = of_alias_get_alias_list(cdns_uart_of_match, "serial",
alias_bitmap, MAX_UART_INSTANCES);
- if (ret) {
+ if (ret && ret != -EINVAL) {
mutex_unlock(&bitmap_lock);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES
From: Michal Simek @ 2018-10-08 12:17 UTC (permalink / raw)
To: linux-kernel, monstr, geert, gregkh
Cc: Jiri Slaby, linux-serial, linux-arm-kernel
Aliases >= MAX_UART_INSTANCES is no problem to find out and use but in
error path is necessary skip clearing bits in bitmap to ensure that only
bits in allocated bitmap are handled and nothing beyond that.
Without this patch when for example serial90 alias is used then in error
patch bit 90 is clear in 32bit wide bitmap.
Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation")
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Based on tty-next tree.
---
drivers/tty/serial/xilinx_uartps.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index e82d1d56399f..29a18103182d 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1673,7 +1673,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
uart_unregister_driver(cdns_uart_data->cdns_uart_driver);
err_out_id:
mutex_lock(&bitmap_lock);
- clear_bit(cdns_uart_data->id, bitmap);
+ if (cdns_uart_data->id < MAX_UART_INSTANCES)
+ clear_bit(cdns_uart_data->id, bitmap);
mutex_unlock(&bitmap_lock);
return rc;
}
@@ -1698,7 +1699,8 @@ static int cdns_uart_remove(struct platform_device *pdev)
rc = uart_remove_one_port(cdns_uart_data->cdns_uart_driver, port);
port->mapbase = 0;
mutex_lock(&bitmap_lock);
- clear_bit(cdns_uart_data->id, bitmap);
+ if (cdns_uart_data->id < MAX_UART_INSTANCES)
+ clear_bit(cdns_uart_data->id, bitmap);
mutex_unlock(&bitmap_lock);
clk_disable_unprepare(cdns_uart_data->uartclk);
clk_disable_unprepare(cdns_uart_data->pclk);
--
1.9.1
^ permalink raw reply related
* [PATCH stable v2 2/2] termios, tty/tty_baudrate.c: simplify, auto-generate baud table
From: H. Peter Anvin @ 2018-10-08 4:06 UTC (permalink / raw)
To: linux-kernel
Cc: Tobias Klausmann, H. Peter Anvin (Intel), Greg Kroah-Hartman,
Jiri Slaby, Al Viro, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, stable
In-Reply-To: <20181008040620.1248277-1-hpa@zytor.com>
From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
Now when all architectures define BOTHER and IBSHIFT, we can
unconditionally rely on these constants. Furthermore, the code can be
significantly simplified in a number of places.
Rather than having two tables and needing to be able to keep them in
sync at all times, have one auto-generated table. This also lets us
avoid the fact that architectures that have CBAUDEX == 0 have BOTHER
in a different location that those that don't.
The code for masking CBAUDEX as a fallback is never exercised on any
architecture, because for all architectures, either the baud rate
table is completely defined for all CBAUD values, or CBAUDEX == 0, so
we can just remove it.
Finally, this patch avoids overrunning the baud_table[] for
architectures with CBAUDEX == 0.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eugene Syromiatnikov <esyr@redhat.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-serial@vger.kernel.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
---
drivers/tty/.gitignore | 1 +
drivers/tty/Makefile | 16 ++++
drivers/tty/bmacros.c | 2 +
drivers/tty/tty_baudrate.c | 182 ++++++++++++++-----------------------
4 files changed, 85 insertions(+), 116 deletions(-)
create mode 100644 drivers/tty/.gitignore
create mode 100644 drivers/tty/bmacros.c
diff --git a/drivers/tty/.gitignore b/drivers/tty/.gitignore
new file mode 100644
index 000000000000..d436c18a912c
--- /dev/null
+++ b/drivers/tty/.gitignore
@@ -0,0 +1 @@
+bmacros.h
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index c72cafdf32b4..489b222ab1ce 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -35,3 +35,19 @@ obj-$(CONFIG_MIPS_EJTAG_FDC_TTY) += mips_ejtag_fdc.o
obj-$(CONFIG_VCC) += vcc.o
obj-y += ipwireless/
+
+#
+# Rules for generating the baud rate table
+#
+CFLAGS_bmacros.o += -Wp,-dM
+
+$(obj)/tty_baudrate.o: $(obj)/bmacros.h
+
+quiet_cmd_bmacros = BMACROS $@
+ cmd_bmacros = ( \
+ sed -nr -e 's/^.define B([0-9]+) .*$$/BTBL(B\1,\1)/p' $< \
+ | sort -n -k1.7 > $@ ) || (rm -f $@ ; echo false)
+
+targets += bmacros.h
+$(obj)/bmacros.h: $(obj)/bmacros.i FORCE
+ $(call if_changed,bmacros)
diff --git a/drivers/tty/bmacros.c b/drivers/tty/bmacros.c
new file mode 100644
index 000000000000..0af865ff00de
--- /dev/null
+++ b/drivers/tty/bmacros.c
@@ -0,0 +1,2 @@
+/* This file is used to extract the B... macros from header files */
+#include <linux/termios.h>
diff --git a/drivers/tty/tty_baudrate.c b/drivers/tty/tty_baudrate.c
index 7576ceace571..ec6d3d93ffac 100644
--- a/drivers/tty/tty_baudrate.c
+++ b/drivers/tty/tty_baudrate.c
@@ -9,43 +9,48 @@
#include <linux/tty.h>
#include <linux/export.h>
-
/*
- * Routine which returns the baud rate of the tty
- *
- * Note that the baud_table needs to be kept in sync with the
- * include/asm/termbits.h file.
+ * Routine which returns the baud rate of the tty. The B... constants
+ * are extracted from the appropriate header files via
+ * bmacros.c -> bmacros.h.
*/
-static const speed_t baud_table[] = {
- 0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800,
- 9600, 19200, 38400, 57600, 115200, 230400, 460800,
-#ifdef __sparc__
- 76800, 153600, 307200, 614400, 921600
-#else
- 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000,
- 2500000, 3000000, 3500000, 4000000
+
+/* CBAUD mask with CBAUDEX removed */
+#define CBAUDNX (CBAUD & ~CBAUDEX)
+
+/* Lowest bit in CBAUDEX, if any. CBAUDEX is assumed contiguous. */
+#define CBAUDEL (CBAUDEX & ~(CBAUDEX << 1))
+#if CBAUDEL & (CBAUDEL-1)
+# error "CBAUDEX is not contiguous"
#endif
-};
-#ifndef __sparc__
-static const tcflag_t baud_bits[] = {
- B0, B50, B75, B110, B134, B150, B200, B300, B600,
- B1200, B1800, B2400, B4800, B9600, B19200, B38400,
- B57600, B115200, B230400, B460800, B500000, B576000,
- B921600, B1000000, B1152000, B1500000, B2000000, B2500000,
- B3000000, B3500000, B4000000
-};
-#else
-static const tcflag_t baud_bits[] = {
- B0, B50, B75, B110, B134, B150, B200, B300, B600,
- B1200, B1800, B2400, B4800, B9600, B19200, B38400,
- B57600, B115200, B230400, B460800, B76800, B153600,
- B307200, B614400, B921600
+/* Convert from B... constant to table position */
+#define BPOS(x) (((x) & CBAUDNX) + \
+ (CBAUDEX ? ((x) & CBAUDEX)/CBAUDEL*(CBAUDNX+1) : 0))
+
+/* Convert from table position to B... constant */
+#define BVAL(x) (((x) & CBAUDNX) + (((x)/(CBAUDNX+1)*CBAUDEX) & CBAUDEX))
+
+/* Entry into the baud_table */
+#define BTBL(b,v) [BPOS(b)] = (v),
+
+static const speed_t baud_table[] = {
+#include "bmacros.h"
};
-#endif
static int n_baud_table = ARRAY_SIZE(baud_table);
+/* Helper function; will be called with cbaud already masked */
+static speed_t _tty_termios_baud_rate(unsigned int cbaud, speed_t bother_speed)
+{
+ /* Magic token for arbitrary speed via c_ispeed/c_ospeed */
+ if (cbaud == BOTHER)
+ return bother_speed;
+
+ cbaud = BPOS(cbaud);
+ return (cbaud >= n_baud_table) ? 0 : baud_table[cbaud];
+}
+
/**
* tty_termios_baud_rate
* @termios: termios structure
@@ -60,24 +65,8 @@ static int n_baud_table = ARRAY_SIZE(baud_table);
speed_t tty_termios_baud_rate(struct ktermios *termios)
{
- unsigned int cbaud;
-
- cbaud = termios->c_cflag & CBAUD;
-
-#ifdef BOTHER
- /* Magic token for arbitrary speed via c_ispeed/c_ospeed */
- if (cbaud == BOTHER)
- return termios->c_ospeed;
-#endif
- if (cbaud & CBAUDEX) {
- cbaud &= ~CBAUDEX;
-
- if (cbaud < 1 || cbaud + 15 > n_baud_table)
- termios->c_cflag &= ~CBAUDEX;
- else
- cbaud += 15;
- }
- return baud_table[cbaud];
+ return _tty_termios_baud_rate(termios->c_cflag & CBAUD,
+ termios->c_ospeed);
}
EXPORT_SYMBOL(tty_termios_baud_rate);
@@ -95,28 +84,15 @@ EXPORT_SYMBOL(tty_termios_baud_rate);
speed_t tty_termios_input_baud_rate(struct ktermios *termios)
{
-#ifdef IBSHIFT
- unsigned int cbaud = (termios->c_cflag >> IBSHIFT) & CBAUD;
-
- if (cbaud == B0)
- return tty_termios_baud_rate(termios);
-#ifdef BOTHER
- /* Magic token for arbitrary speed via c_ispeed*/
- if (cbaud == BOTHER)
- return termios->c_ispeed;
-#endif
- if (cbaud & CBAUDEX) {
- cbaud &= ~CBAUDEX;
+ unsigned int cbaud;
+ speed_t bother_speed = termios->c_ispeed;
- if (cbaud < 1 || cbaud + 15 > n_baud_table)
- termios->c_cflag &= ~(CBAUDEX << IBSHIFT);
- else
- cbaud += 15;
+ cbaud = (termios->c_cflag >> IBSHIFT) & CBAUD;
+ if (cbaud == B0) {
+ cbaud = termios->c_cflag & CBAUD;
+ bother_speed = termios->c_ospeed;
}
- return baud_table[cbaud];
-#else /* IBSHIFT */
- return tty_termios_baud_rate(termios);
-#endif /* IBSHIFT */
+ return _tty_termios_baud_rate(cbaud, bother_speed);
}
EXPORT_SYMBOL(tty_termios_input_baud_rate);
@@ -145,38 +121,27 @@ EXPORT_SYMBOL(tty_termios_input_baud_rate);
void tty_termios_encode_baud_rate(struct ktermios *termios,
speed_t ibaud, speed_t obaud)
{
- int i = 0;
- int ifound = -1, ofound = -1;
+ int i;
+ unsigned int ifound, ofound;
int iclose = ibaud/50, oclose = obaud/50;
- int ibinput = 0;
+ bool ibinput = false;
- if (obaud == 0) /* CD dropped */
+ if (obaud == 0) /* CD dropped */
ibaud = 0; /* Clear ibaud to be sure */
termios->c_ispeed = ibaud;
termios->c_ospeed = obaud;
-#ifdef IBSHIFT
- if ((termios->c_cflag >> IBSHIFT) & CBAUD)
- ibinput = 1; /* An input speed was specified */
-#endif
-#ifdef BOTHER
+ ibinput = ((termios->c_cflag >> IBSHIFT) & CBAUD) != B0;
+
/* If the user asked for a precise weird speed give a precise weird
answer. If they asked for a Bfoo speed they may have problems
digesting non-exact replies so fuzz a bit */
- if ((termios->c_cflag & CBAUD) == BOTHER) {
+ if ((termios->c_cflag & CBAUD) == BOTHER)
oclose = 0;
- if (!ibinput)
- iclose = 0;
- }
if (((termios->c_cflag >> IBSHIFT) & CBAUD) == BOTHER)
iclose = 0;
-#endif
- termios->c_cflag &= ~CBAUD;
-#ifdef IBSHIFT
- termios->c_cflag &= ~(CBAUD << IBSHIFT);
-#endif
/*
* Our goal is to find a close match to the standard baud rate
@@ -184,43 +149,28 @@ void tty_termios_encode_baud_rate(struct ktermios *termios,
* match then report back the speed as a POSIX Bxxxx value by
* preference
*/
-
- do {
+ ofound = ifound = BOTHER;
+ for (i = 0; i < n_baud_table; i++) {
if (obaud - oclose <= baud_table[i] &&
obaud + oclose >= baud_table[i]) {
- termios->c_cflag |= baud_bits[i];
- ofound = i;
+ ofound = BVAL(i);
+ break;
}
- if (ibaud - iclose <= baud_table[i] &&
- ibaud + iclose >= baud_table[i]) {
- /* For the case input == output don't set IBAUD bits
- if the user didn't do so */
- if (ofound == i && !ibinput)
- ifound = i;
-#ifdef IBSHIFT
- else {
- ifound = i;
- termios->c_cflag |= (baud_bits[i] << IBSHIFT);
+ }
+ if (!ibinput) {
+ ifound = 0;
+ } else {
+ for (i = 0; i < n_baud_table; i++) {
+ if (ibaud - iclose <= baud_table[i] &&
+ ibaud + iclose >= baud_table[i]) {
+ ifound = BVAL(i);
+ break;
}
-#endif
}
- } while (++i < n_baud_table);
+ }
- /*
- * If we found no match then use BOTHER if provided or warn
- * the user their platform maintainer needs to wake up if not.
- */
-#ifdef BOTHER
- if (ofound == -1)
- termios->c_cflag |= BOTHER;
- /* Set exact input bits only if the input and output differ or the
- user already did */
- if (ifound == -1 && (ibaud != obaud || ibinput))
- termios->c_cflag |= (BOTHER << IBSHIFT);
-#else
- if (ifound == -1 || ofound == -1)
- pr_warn_once("tty: Unable to return correct speed data as your architecture needs updating.\n");
-#endif
+ termios->c_cflag &= ~(CBAUD | (CBAUD << IBSHIFT));
+ termios->c_cflag |= ofound | (ifound << IBSHIFT);
}
EXPORT_SYMBOL_GPL(tty_termios_encode_baud_rate);
--
2.17.1
^ permalink raw reply related
* [PATCH stable v2 1/2] arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
From: H. Peter Anvin @ 2018-10-08 4:06 UTC (permalink / raw)
To: linux-kernel
Cc: Tobias Klausmann, H. Peter Anvin (Intel), Greg Kroah-Hartman,
Jiri Slaby, Al Viro, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, stable
In-Reply-To: <20181008040620.1248277-1-hpa@zytor.com>
From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
using arbitrary flags. Because BOTHER is not defined, the general
Linux code doesn't allow setting arbitrary baud rates, and because
CBAUDEX == 0, we can have an array overrun of the baud_rate[] table in
drivers/tty/tty_baudrate.c if (c_cflags & CBAUD) == 037.
Resolve both problems by #defining BOTHER to 037 on Alpha.
However, userspace still needs to know if setting BOTHER is actually
safe given legacy kernels (does anyone actually care about that on
Alpha anymore?), so enable the TCGETS2/TCSETS*2 ioctls on Alpha, even
though they use the same structure. Define struct termios2 just for
compatibility; it is the exact same structure as struct termios. In a
future patchset, this will be cleaned up so the uapi headers are
usable from libc.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eugene Syromiatnikov <esyr@redhat.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-serial@vger.kernel.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
---
arch/alpha/include/asm/termios.h | 8 +++++++-
arch/alpha/include/uapi/asm/ioctls.h | 5 +++++
arch/alpha/include/uapi/asm/termbits.h | 17 +++++++++++++++++
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 6a8c53dec57e..b7c77bb1bfd2 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -73,9 +73,15 @@
})
#define user_termios_to_kernel_termios(k, u) \
- copy_from_user(k, u, sizeof(struct termios))
+ copy_from_user(k, u, sizeof(struct termios2))
#define kernel_termios_to_user_termios(u, k) \
+ copy_to_user(u, k, sizeof(struct termios2))
+
+#define user_termios_to_kernel_termios_1(k, u) \
+ copy_from_user(k, u, sizeof(struct termios))
+
+#define kernel_termios_to_user_termios_1(u, k) \
copy_to_user(u, k, sizeof(struct termios))
#endif /* _ALPHA_TERMIOS_H */
diff --git a/arch/alpha/include/uapi/asm/ioctls.h b/arch/alpha/include/uapi/asm/ioctls.h
index 3729d92d3fa8..dc8c20ac7191 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -32,6 +32,11 @@
#define TCXONC _IO('t', 30)
#define TCFLSH _IO('t', 31)
+#define TCGETS2 _IOR('T', 42, struct termios2)
+#define TCSETS2 _IOW('T', 43, struct termios2)
+#define TCSETSW2 _IOW('T', 44, struct termios2)
+#define TCSETSF2 _IOW('T', 45, struct termios2)
+
#define TIOCSWINSZ _IOW('t', 103, struct winsize)
#define TIOCGWINSZ _IOR('t', 104, struct winsize)
#define TIOCSTART _IO('t', 110) /* start output, like ^Q */
diff --git a/arch/alpha/include/uapi/asm/termbits.h b/arch/alpha/include/uapi/asm/termbits.h
index de6c8360fbe3..4575ba34a0ea 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -26,6 +26,19 @@ struct termios {
speed_t c_ospeed; /* output speed */
};
+/* Alpha has identical termios and termios2 */
+
+struct termios2 {
+ tcflag_t c_iflag; /* input mode flags */
+ tcflag_t c_oflag; /* output mode flags */
+ tcflag_t c_cflag; /* control mode flags */
+ tcflag_t c_lflag; /* local mode flags */
+ cc_t c_cc[NCCS]; /* control characters */
+ cc_t c_line; /* line discipline (== c_cc[19]) */
+ speed_t c_ispeed; /* input speed */
+ speed_t c_ospeed; /* output speed */
+};
+
/* Alpha has matching termios and ktermios */
struct ktermios {
@@ -152,6 +165,7 @@ struct ktermios {
#define B3000000 00034
#define B3500000 00035
#define B4000000 00036
+#define BOTHER 00037
#define CSIZE 00001400
#define CS5 00000000
@@ -169,6 +183,9 @@ struct ktermios {
#define CMSPAR 010000000000 /* mark or space (stick) parity */
#define CRTSCTS 020000000000 /* flow control */
+#define CIBAUD 07600000
+#define IBSHIFT 16
+
/* c_lflag bits */
#define ISIG 0x00000080
#define ICANON 0x00000100
--
2.17.1
^ permalink raw reply related
* [PATCH stable v2 0/2] termios: Alpha BOTHER/IBSHIFT, tty_baudrate fix
From: H. Peter Anvin @ 2018-10-08 4:06 UTC (permalink / raw)
To: linux-kernel
Cc: Tobias Klausmann, H. Peter Anvin (Intel), Greg Kroah-Hartman,
Jiri Slaby, Al Viro, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Thomas Gleixner, Kate Stewart, Philippe Ombredanne,
Eugene Syromiatnikov, linux-alpha, linux-serial, Johan Hovold,
Alan Cox, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, stable
From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
It turns out that Alpha is the only architecture that never
implemented BOTHER and IBSHIFT, which is otherwise ages old. This is
one thing that has held up glibc support for this feature (all other
architectures have supported these for about a decade, at least before
the current 3.2 glibc cutoff.)
Furthermore, in the process of dealing with this, I discovered that
the current code in tty_baudrate.c can read past the end of the
baud_table[] on Alpha and PowerPC. The second patch in this series
fixes that, but it also cleans up the code substantially by
auto-generating the table and, since all architectures now have them,
removing all conditionals for BOTHER and IBSHIFT existing.
Tagging for stable because these are concrete and immediate
problems. I have a much bigger update in process, nearly done, which
will clean up a lot of duplicated code and make the uapi headers
usable for libc, but that is not critical on the same level.
Tested on x86, compile-tested on Alpha. SPARC, and PowerPC.
v2: the CBAUDEX masking-as-fallback code was wrong, but it could never
be exercised on any architecture anyway (gcc would not even emit it)
so just remove it. There are thus no object code changes from v1.
---
arch/alpha/include/asm/termios.h | 8 +-
arch/alpha/include/uapi/asm/ioctls.h | 5 +
arch/alpha/include/uapi/asm/termbits.h | 17 +++
drivers/tty/.gitignore | 1 +
drivers/tty/Makefile | 16 +++
drivers/tty/bmacros.c | 2 +
drivers/tty/tty_baudrate.c | 182 ++++++++++++---------------------
7 files changed, 114 insertions(+), 117 deletions(-)
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eugene Syromiatnikov <esyr@redhat.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-serial@vger.kernel.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: <stable@vger.kernel.org>
^ permalink raw reply
* [GIT PULL] TTY/Serial fixes for 4.19-rc7
From: Greg KH @ 2018-10-07 6:07 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Stephen Rothwell, Andrew Morton,
linux-kernel, linux-serial
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.19-rc7
for you to fetch changes up to 5b162cc4ac27ba76e576abc9090c54cf90a17980:
Revert "serial: sh-sci: Allow for compressed SCIF address" (2018-10-02 14:38:16 -0700)
----------------------------------------------------------------
Serial driver fixes for 4.19-rc7
Here are 3 small serial driver fixes for 4.19-rc7
- 2 sh-sci bugfixes for reported issues
- a revert of the PM handling for the 8250_dw code
All of these have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Geert Uytterhoeven (2):
Revert "serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE"
Revert "serial: sh-sci: Allow for compressed SCIF address"
Guenter Roeck (1):
Revert "serial: 8250_dw: Fix runtime PM handling"
drivers/tty/serial/8250/8250_dw.c | 4 ---
drivers/tty/serial/sh-sci.c | 56 ++++++++++++++++++++++++++++-----------
include/linux/serial_sci.h | 1 +
3 files changed, 42 insertions(+), 19 deletions(-)
^ 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