This is a note to let you know that I've just added the patch titled
serial: stm32: fix clearing interrupt error flags
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the tty-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 Mon Sep 17 00:00:00 2001
From: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Date: Thu, 21 Nov 2019 09:10:49 +0100
Subject: serial: stm32: fix clearing interrupt error flags
The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
simple write to clear TC (transfer complete) flag.
Fixes: 4f01d833fdcd ("serial: stm32: fix rx error handling")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/stm32-usart.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index df90747ee3a8..2f72514d63ed 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -240,8 +240,8 @@ static void stm32_receive_chars(struct uart_port *port, bool threaded)
* cleared by the sequence [read SR - read DR].
*/
if ((sr & USART_SR_ERR_MASK) && ofs->icr != UNDEF_REG)
- stm32_clr_bits(port, ofs->icr, USART_ICR_ORECF |
- USART_ICR_PECF | USART_ICR_FECF);
+ writel_relaxed(sr & USART_SR_ERR_MASK,
+ port->membase + ofs->icr);
c = stm32_get_char(port, &sr, &stm32_port->last_res);
port->icount.rx++;
@@ -435,7 +435,7 @@ static void stm32_transmit_chars(struct uart_port *port)
if (ofs->icr == UNDEF_REG)
stm32_clr_bits(port, ofs->isr, USART_SR_TC);
else
- stm32_set_bits(port, ofs->icr, USART_ICR_TCCF);
+ writel_relaxed(USART_ICR_TCCF, port->membase + ofs->icr);
if (stm32_port->tx_ch)
stm32_transmit_chars_dma(port);
--
2.24.0
On Thu, Nov 21, 2019 at 10:08:03PM +0800, Yama Modo wrote:
> Hi Greg ,
>
> Thanks for your response!
>
> > Greg KH <greg(a)kroah.com>於 2019年11月21日 週四,下午7:54寫道:
>
> > On Thu, Nov 21, 2019 at 07:47:37PM +0800, Yama Modo wrote:
> > >> Dear Linus Walleij,
> > >>
> > >> I want to backport commit ff2b13592299 "gpio: make the gpiochip a real
> > >> device" to linux 4.4.y. Could you please review the following patch? I
> > >> will improve this later if something need to take care. Thanks!
> >
> > >> Why do you want to do that? What does it "fix" and who needs it for the
> > old 4.4.y kernel tree?
> >
>
> Sorry I should take care about that patch must fix the issue directly and
> then it can be backported to stable kernel. We use Linux 4.4.y-cip for our
> MOXA products, such as UC8410A, for a super long term kernel, and it’s
> based on Linux 4.4.y.
If your device works properly on 4.9 or newer, you really really really
should use that instead. That way you always have support, and proper
fixes, unlike what will, and is already, happening with 4.4.y.
> We suffer a kernel panic issue because of of_node inconsistency and
> gpio-reserved-ranges with no gpio device, and we find mainline、4.9.y、4.14.y
> and 4.19.y have no this gpio problem, and there are have gpio device.
Great, why not use 4.19.y? That was said to be the next "super long
term kernel", right?
> Many gpio patches are based on gpio device. If we want to backport these
> gpio patches to Linux 4.4.y-cip, it will suffer more problems than having
> gpio device’s kernels. Besides, in house patches in Linux 4.4.y-cip are
> harder to upstream mainline because subsystem of Linux 4.4.y-cip is far
> from mainline’s.
I have no idea what is in the -cip 4.4.y tree. You are on your own
there. And honestly, I think the model of what they are trying to do
there is totally wrong and will fail horribly :(
Use 4.19.y. Or even better yet, 5.4.y Your device is "alive", keep it
alive by giving it the latest kernel updates so that you know it is in
good health. To rely on an old kernel like that, you can not guarantee
how alive it will be.
good luck!
greg k-h
The layout of struct timeval is different on sparc64 from
anything else, and the patch I did long ago failed to take
this into account.
Change it now to handle sparc64 user space correctly again.
Quite likely nobody cares about parallel ports on sparc64,
but there is no reason not to fix it.
Cc: stable(a)vger.kernel.org
Fixes: 9a450484089d ("lp: support 64-bit time_t user space")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/char/lp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/char/lp.c b/drivers/char/lp.c
index 7c9269e3477a..bd95aba1f9fe 100644
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -713,6 +713,10 @@ static int lp_set_timeout64(unsigned int minor, void __user *arg)
if (copy_from_user(karg, arg, sizeof(karg)))
return -EFAULT;
+ /* sparc64 suseconds_t is 32-bit only */
+ if (IS_ENABLED(CONFIG_SPARC64) && !in_compat_syscall())
+ karg[1] >>= 32;
+
return lp_set_timeout(minor, karg[0], karg[1]);
}
--
2.20.0
Going through the uses of timeval in the user space API,
I noticed two bugs in ppdev that were introduced in the y2038
conversion:
* The range check was accidentally moved from ppsettime to
ppgettime
* On sparc64, the microseconds are in the other half of the
64-bit word.
Fix both, and mark the fix for stable backports.
Cc: stable(a)vger.kernel.org
Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/char/ppdev.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index c86f18aa8985..34bb88fe0b0a 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -619,20 +619,27 @@ static int pp_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
if (copy_from_user(time32, argp, sizeof(time32)))
return -EFAULT;
+ if ((time32[0] < 0) || (time32[1] < 0))
+ return -EINVAL;
+
return pp_set_timeout(pp->pdev, time32[0], time32[1]);
case PPSETTIME64:
if (copy_from_user(time64, argp, sizeof(time64)))
return -EFAULT;
+ if ((time64[0] < 0) || (time64[1] < 0))
+ return -EINVAL;
+
+ if (IS_ENABLED(CONFIG_SPARC64) && !in_compat_syscall())
+ time64[1] >>= 32;
+
return pp_set_timeout(pp->pdev, time64[0], time64[1]);
case PPGETTIME32:
jiffies_to_timespec64(pp->pdev->timeout, &ts);
time32[0] = ts.tv_sec;
time32[1] = ts.tv_nsec / NSEC_PER_USEC;
- if ((time32[0] < 0) || (time32[1] < 0))
- return -EINVAL;
if (copy_to_user(argp, time32, sizeof(time32)))
return -EFAULT;
@@ -643,8 +650,9 @@ static int pp_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
jiffies_to_timespec64(pp->pdev->timeout, &ts);
time64[0] = ts.tv_sec;
time64[1] = ts.tv_nsec / NSEC_PER_USEC;
- if ((time64[0] < 0) || (time64[1] < 0))
- return -EINVAL;
+
+ if (IS_ENABLED(CONFIG_SPARC64) && !in_compat_syscall())
+ time64[1] <<= 32;
if (copy_to_user(argp, time64, sizeof(time64)))
return -EFAULT;
--
2.20.0