| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <OSBPR01MB359025D3AF694A169844F5FDAAC80@OSBPR01MB3590.jpnprd01.prod.outlook.com>
Date: Tue, 31 Mar 2020 18:10:48 +0000
From: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Prabhakar <prabhakar.csengg@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Hao Bui <hao.bui.yg@...esas.com>,
KAZUMI HARADA <kazumi.harada.rh@...esas.com>,
Sasha Levin <sashal@...nel.org>,
Chris Brandt <Chris.Brandt@...esas.com>
Subject: RE: [PATCH] serial: sh-sci: Make sure status register SCxSR is read
in correct sequence
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@...ux-m68k.org>
> Sent: 31 March 2020 18:38
> To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
> Cc: Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>; Greg Kroah-Hartman <gregkh@...uxfoundation.org>; Jiri Slaby <jslaby@...e.com>;
> open list:SERIAL DRIVERS <linux-serial@...r.kernel.org>; Linux-Renesas <linux-renesas-soc@...r.kernel.org>; Prabhakar
> <prabhakar.csengg@...il.com>; Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; Hao Bui <hao.bui.yg@...esas.com>; KAZUMI
> HARADA <kazumi.harada.rh@...esas.com>; Sasha Levin <sashal@...nel.org>; Chris Brandt <Chris.Brandt@...esas.com>
> Subject: Re: [PATCH] serial: sh-sci: Make sure status register SCxSR is read in correct sequence
>
> Hi Prabhakar,
>
> On Tue, Mar 31, 2020 at 5:58 PM Prabhakar Mahadev Lad
> <prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> > > -----Original Message-----
> > > From: Geert Uytterhoeven <geert@...ux-m68k.org>
> > > Sent: 31 March 2020 16:18
> > > To: Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>
> > > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; Jiri Slaby <jslaby@...e.com>; open list:SERIAL DRIVERS <linux-
> > > serial@...r.kernel.org>; Linux-Renesas <linux-renesas-soc@...r.kernel.org>; Prabhakar <prabhakar.csengg@...il.com>; Linux Kernel
> > > Mailing List <linux-kernel@...r.kernel.org>; Hao Bui <hao.bui.yg@...esas.com>; KAZUMI HARADA <kazumi.harada.rh@...esas.com>;
> > > Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>; Sasha Levin <sashal@...nel.org>; Chris Brandt
> > > <Chris.Brandt@...esas.com>
> > > Subject: Re: [PATCH] serial: sh-sci: Make sure status register SCxSR is read in correct sequence
> >> > On Fri, Mar 27, 2020 at 7:17 PM Kazuhiro Fujita
> > > <kazuhiro.fujita.jg@...esas.com> wrote:
> > > > For SCIF and HSCIF interfaces the SCxSR register holds the status of
> > > > data that is to be read next from SCxRDR register, But where as for
> > > > SCIFA and SCIFB interfaces SCxSR register holds status of data that is
> > > > previously read from SCxRDR register.
> > > >
> > > > This patch makes sure the status register is read depending on the port
> > > > types so that errors are caught accordingly.
> > > >
> > > > Cc: <stable@...r.kernel.org>
> > > > Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>
> > > > Signed-off-by: Hao Bui <hao.bui.yg@...esas.com>
> > > > Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@...esas.com>
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/tty/serial/sh-sci.c
> > > > +++ b/drivers/tty/serial/sh-sci.c
> > > > @@ -870,9 +870,16 @@ static void sci_receive_chars(struct uart_port *port)
> > > > tty_insert_flip_char(tport, c, TTY_NORMAL);
> > > > } else {
> > > > for (i = 0; i < count; i++) {
> > > > - char c = serial_port_in(port, SCxRDR);
> > > > -
> > > > - status = serial_port_in(port, SCxSR);
> > > > + char c;
> > > > +
> > > > + if (port->type == PORT_SCIF ||
> > > > + port->type == PORT_HSCIF) {
> > > > + status = serial_port_in(port, SCxSR);
> > > > + c = serial_port_in(port, SCxRDR);
> > > > + } else {
> > > > + c = serial_port_in(port, SCxRDR);
> > > > + status = serial_port_in(port, SCxSR);
> > > > + }
> > > > if (uart_handle_sysrq_char(port, c)) {
> > > > count--; i--;
> > > > continue;
> > >
> > > I can confirm that the documentation for the Serial Status Register on
> > > 1. (H)SCIF on R-Car Gen1/2/3 says the framing/error flag applies to
> > > the data that is "to be read next" from the FIFO., and that the
> > > "Sample Flowchart for Serial Reception (2)" confirms this,
> > > 2. SCIF[AB] on R-Car Gen2, SH-Mobile AG5, R-Mobile A1 and APE6 says
> > > the framing/error flag applies to the receive data that is "read"
> > > from the FIFO, and that the "Example of Flow for Serial Reception
> > > (2)" confirms this,
> > > 3. SCIF on RZ/A1H says something similar as for (H)SCIF above, using
> > > slightly different wording, also confirmed by the "Sample Flowchart
> > > for Receiving Serial Data (2)".
> > >
> > > However, the documentation for "SCIFA" on RZ/A2 (for which we use
> > > PORT_SCIF, not PORT_SCIFA, in the driver) has conflicting information:
> > > 1. Section 17.2.7 "Serial Status Register (FSR)" says:
> > > - A receive framing/parity error occurred in the "next receive
> > > data read" from the FIFO,
> > > - Indicates whether there is a framing/parity error in the data
> > > "read" from the FIFO.
> > > 2. Figure 17.8 "Sample Flowchart for Receiving Serial Data in
> > > Asynchronous Mode (2)".
> > > - Whether a framing error or parity error has occurred in the
> > > received data that is "read" from the FIFO.
> > >
> > > So while the change looks OK for most Renesas ARM SoCs, the situation
> > > for RZ/A2 is unclear.
> > > Note that the above does not take into account variants used on SuperH
> > > SoCs.
> > >
> > I'll dig out some documentation wrt RZ/A2 & SuperH. Also H8300 needs to be considered.
>
For SuperH,
tango@...go:~/work/mainline/linux-next/arch/sh$ grep -nr PORT_SCIFA
kernel/cpu/sh4a/setup-sh7724.c:355:.type = PORT_SCIFA,
kernel/cpu/sh4a/setup-sh7724.c:375:.type = PORT_SCIFA,
kernel/cpu/sh4a/setup-sh7724.c:395:.type = PORT_SCIFA,
kernel/cpu/sh4a/setup-sh7723.c:88:.type = PORT_SCIFA,
kernel/cpu/sh4a/setup-sh7723.c:108:.type = PORT_SCIFA,
kernel/cpu/sh4a/setup-sh7723.c:128:.type = PORT_SCIFA,
And rest use PORT_SCIF, referring to [1] page 564 this behaves similar to SCIFA/B atleast sh7760.
But I couldn’t find datasheet for rest of the family ☹
> AFAIK, H8/300 has SCI only, so is not affected.
>
That’s one less thing to worry.
> > By any chance do you have RZ/A2 to test .
>
> Actually I do.
>
Great, could you please do the needy 😃
[1] https://datasheet.octopart.com/D17760BP200AD-Renesas-datasheet-124679.pdf
Cheers,
--Prabhakar
> > > Nevertheless, this patch will need some testing on various hardware.
> > > Do you have a test case to verify the broken/fixed behavior?
> > >
> > Agreed, its been tested on RZ/G2x & RZ/G1x by doing a loopback test, configure one interface as CS8 mode(8-bits data, No parity) and
> other as CS7 mode (7-bits data, 1-bit Parity) and parity errors should be detected.
>
> Thanks, that's good to know!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
Powered by blists - more mailing lists