* [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled @ 2022-05-16 9:20 Vijaya Krishna Nivarthi [not found] ` <CGME20220523213246eucas1p2d0da08d931a996cd3410eda1c2fd48c0@eucas1p2.samsung.com> 0 siblings, 1 reply; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-05-16 9:20 UTC (permalink / raw) To: gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd, Vijaya Krishna Nivarthi For the case of console_suspend disabled, if back to back suspend/resume test is executed, at the end of test, sometimes console would appear to be frozen not responding to input. This would happen because, during resume, rx transactions can come in before system is ready, malfunction of rx happens in turn resulting in console appearing to be stuck. Do a stop_rx in suspend sequence to prevent this. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> --- v4: moved the change to serial core to apply for all drivers v3: swapped the order of conditions to be more human readable v2: restricted patch to contain only stop_rx in suspend sequence v1: intial patch contained 2 additional unrelated changes in vicinity --- drivers/tty/serial/serial_core.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 82a1770..9a85b41 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -2211,9 +2211,16 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport) } put_device(tty_dev); - /* Nothing to do if the console is not suspending */ - if (!console_suspend_enabled && uart_console(uport)) + /* + * Nothing to do if the console is not suspending + * except stop_rx to prevent any asynchronous data + * over RX line. Re-start_rx, when required, is + * done by set_termios in resume sequence + */ + if (!console_suspend_enabled && uart_console(uport)) { + uport->ops->stop_rx(uport); goto unlock; + } uport->suspended = 1; -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by the Linux Foundation. ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <CGME20220523213246eucas1p2d0da08d931a996cd3410eda1c2fd48c0@eucas1p2.samsung.com>]
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled [not found] ` <CGME20220523213246eucas1p2d0da08d931a996cd3410eda1c2fd48c0@eucas1p2.samsung.com> @ 2022-05-23 21:32 ` Marek Szyprowski [not found] ` <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com> 2022-06-07 13:22 ` Greg KH 0 siblings, 2 replies; 11+ messages in thread From: Marek Szyprowski @ 2022-05-23 21:32 UTC (permalink / raw) To: Vijaya Krishna Nivarthi, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd Hi, On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: > For the case of console_suspend disabled, if back to back suspend/resume > test is executed, at the end of test, sometimes console would appear to > be frozen not responding to input. This would happen because, during > resume, rx transactions can come in before system is ready, malfunction > of rx happens in turn resulting in console appearing to be stuck. > > Do a stop_rx in suspend sequence to prevent this. > > Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> > --- > v4: moved the change to serial core to apply for all drivers > v3: swapped the order of conditions to be more human readable > v2: restricted patch to contain only stop_rx in suspend sequence > v1: intial patch contained 2 additional unrelated changes in vicinity > --- This patch landed recently in linux-next as commit c9d2325cdb92 ("serial: core: Do stop_rx in suspend path for console if console_suspend is disabled"). Unfortunately it breaks console operation on my test systems after system suspend/resume cycle if 'no_console_suspend' kernel parameter is present. System properly resumes from suspend, the console displays all the messages and even command line prompt, but then doesn't react on any input. If I remove the 'no_console_suspend' parameter, the console is again operational after system suspend/resume cycle. Before this patch it worked fine regardless the 'no_console_suspend' parameter. If this matters, the test system is ARM 32bit Samsung Exynos5422-based Odroid XU3lite board. > drivers/tty/serial/serial_core.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index 82a1770..9a85b41 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -2211,9 +2211,16 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport) > } > put_device(tty_dev); > > - /* Nothing to do if the console is not suspending */ > - if (!console_suspend_enabled && uart_console(uport)) > + /* > + * Nothing to do if the console is not suspending > + * except stop_rx to prevent any asynchronous data > + * over RX line. Re-start_rx, when required, is > + * done by set_termios in resume sequence > + */ > + if (!console_suspend_enabled && uart_console(uport)) { > + uport->ops->stop_rx(uport); > goto unlock; > + } > > uport->suspended = 1; > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com>]
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled [not found] ` <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com> @ 2022-05-24 11:54 ` Marek Szyprowski 2022-06-01 11:24 ` Vijaya Krishna Nivarthi 0 siblings, 1 reply; 11+ messages in thread From: Marek Szyprowski @ 2022-05-24 11:54 UTC (permalink / raw) To: Vijaya Krishna Nivarthi, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd On 23.05.2022 23:32, Marek Szyprowski wrote: > Hi, > > On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >> For the case of console_suspend disabled, if back to back suspend/resume >> test is executed, at the end of test, sometimes console would appear to >> be frozen not responding to input. This would happen because, during >> resume, rx transactions can come in before system is ready, malfunction >> of rx happens in turn resulting in console appearing to be stuck. >> >> Do a stop_rx in suspend sequence to prevent this. >> >> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >> --- >> v4: moved the change to serial core to apply for all drivers >> v3: swapped the order of conditions to be more human readable >> v2: restricted patch to contain only stop_rx in suspend sequence >> v1: intial patch contained 2 additional unrelated changes in vicinity >> --- > > This patch landed recently in linux-next as commit c9d2325cdb92 > ("serial: core: Do stop_rx in suspend path for console if > console_suspend is disabled"). > > Unfortunately it breaks console operation on my test systems after > system suspend/resume cycle if 'no_console_suspend' kernel parameter > is present. System properly resumes from suspend, the console displays > all the messages and even command line prompt, but then doesn't react > on any input. If I remove the 'no_console_suspend' parameter, the > console is again operational after system suspend/resume cycle. Before > this patch it worked fine regardless the 'no_console_suspend' parameter. > > If this matters, the test system is ARM 32bit Samsung Exynos5422-based > Odroid XU3lite board. One more information. This issue can be easily reproduced with QEMU. It happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when 'no_console_suspend' is added to kernel's cmdline. > >> drivers/tty/serial/serial_core.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/tty/serial/serial_core.c >> b/drivers/tty/serial/serial_core.c >> index 82a1770..9a85b41 100644 >> --- a/drivers/tty/serial/serial_core.c >> +++ b/drivers/tty/serial/serial_core.c >> @@ -2211,9 +2211,16 @@ int uart_suspend_port(struct uart_driver *drv, >> struct uart_port *uport) >> } >> put_device(tty_dev); >> - /* Nothing to do if the console is not suspending */ >> - if (!console_suspend_enabled && uart_console(uport)) >> + /* >> + * Nothing to do if the console is not suspending >> + * except stop_rx to prevent any asynchronous data >> + * over RX line. Re-start_rx, when required, is >> + * done by set_termios in resume sequence >> + */ >> + if (!console_suspend_enabled && uart_console(uport)) { >> + uport->ops->stop_rx(uport); >> goto unlock; >> + } >> uport->suspended = 1; > > Best regards Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-05-24 11:54 ` Marek Szyprowski @ 2022-06-01 11:24 ` Vijaya Krishna Nivarthi 2022-06-01 22:25 ` Marek Szyprowski 0 siblings, 1 reply; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-06-01 11:24 UTC (permalink / raw) To: Marek Szyprowski, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd Hi, On 5/24/2022 5:24 PM, Marek Szyprowski wrote: > On 23.05.2022 23:32, Marek Szyprowski wrote: >> Hi, >> >> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >>> For the case of console_suspend disabled, if back to back suspend/resume >>> test is executed, at the end of test, sometimes console would appear to >>> be frozen not responding to input. This would happen because, during >>> resume, rx transactions can come in before system is ready, malfunction >>> of rx happens in turn resulting in console appearing to be stuck. >>> >>> Do a stop_rx in suspend sequence to prevent this. >>> >>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >>> --- >>> v4: moved the change to serial core to apply for all drivers >>> v3: swapped the order of conditions to be more human readable >>> v2: restricted patch to contain only stop_rx in suspend sequence >>> v1: intial patch contained 2 additional unrelated changes in vicinity >>> --- >> This patch landed recently in linux-next as commit c9d2325cdb92 >> ("serial: core: Do stop_rx in suspend path for console if >> console_suspend is disabled"). >> >> Unfortunately it breaks console operation on my test systems after >> system suspend/resume cycle if 'no_console_suspend' kernel parameter >> is present. System properly resumes from suspend, the console displays >> all the messages and even command line prompt, but then doesn't react >> on any input. If I remove the 'no_console_suspend' parameter, the >> console is again operational after system suspend/resume cycle. Before >> this patch it worked fine regardless the 'no_console_suspend' parameter. >> >> If this matters, the test system is ARM 32bit Samsung Exynos5422-based >> Odroid XU3lite board. > > One more information. This issue can be easily reproduced with QEMU. It > happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when > 'no_console_suspend' is added to kernel's cmdline. > Ideally, as comments indicate, the set_termios should have done stop_rx at begin and start_rx at end to take care of this issue. This is probably missing in your driver. Can we check if this can be fixed? OR other option is Add a start_rx in uart_resume_port after call to set_termios to handle this scenario for other drivers. Please let me know if there are any concerns for this options. >>> drivers/tty/serial/serial_core.c | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/tty/serial/serial_core.c >>> b/drivers/tty/serial/serial_core.c >>> index 82a1770..9a85b41 100644 >>> --- a/drivers/tty/serial/serial_core.c >>> +++ b/drivers/tty/serial/serial_core.c >>> @@ -2211,9 +2211,16 @@ int uart_suspend_port(struct uart_driver *drv, >>> struct uart_port *uport) >>> } >>> put_device(tty_dev); >>> - /* Nothing to do if the console is not suspending */ >>> - if (!console_suspend_enabled && uart_console(uport)) >>> + /* >>> + * Nothing to do if the console is not suspending >>> + * except stop_rx to prevent any asynchronous data >>> + * over RX line. Re-start_rx, when required, is >>> + * done by set_termios in resume sequence >>> + */ >>> + if (!console_suspend_enabled && uart_console(uport)) { >>> + uport->ops->stop_rx(uport); >>> goto unlock; >>> + } >>> uport->suspended = 1; >> Best regards > Best regards Thank you. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-01 11:24 ` Vijaya Krishna Nivarthi @ 2022-06-01 22:25 ` Marek Szyprowski 2022-06-02 15:42 ` Vijaya Krishna Nivarthi 0 siblings, 1 reply; 11+ messages in thread From: Marek Szyprowski @ 2022-06-01 22:25 UTC (permalink / raw) To: Vijaya Krishna Nivarthi, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd Hi, On 01.06.2022 13:24, Vijaya Krishna Nivarthi wrote: > On 5/24/2022 5:24 PM, Marek Szyprowski wrote: >> On 23.05.2022 23:32, Marek Szyprowski wrote: >>> Hi, >>> >>> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >>>> For the case of console_suspend disabled, if back to back >>>> suspend/resume >>>> test is executed, at the end of test, sometimes console would >>>> appear to >>>> be frozen not responding to input. This would happen because, during >>>> resume, rx transactions can come in before system is ready, >>>> malfunction >>>> of rx happens in turn resulting in console appearing to be stuck. >>>> >>>> Do a stop_rx in suspend sequence to prevent this. >>>> >>>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >>>> --- >>>> v4: moved the change to serial core to apply for all drivers >>>> v3: swapped the order of conditions to be more human readable >>>> v2: restricted patch to contain only stop_rx in suspend sequence >>>> v1: intial patch contained 2 additional unrelated changes in vicinity >>>> --- >>> This patch landed recently in linux-next as commit c9d2325cdb92 >>> ("serial: core: Do stop_rx in suspend path for console if >>> console_suspend is disabled"). >>> >>> Unfortunately it breaks console operation on my test systems after >>> system suspend/resume cycle if 'no_console_suspend' kernel parameter >>> is present. System properly resumes from suspend, the console displays >>> all the messages and even command line prompt, but then doesn't react >>> on any input. If I remove the 'no_console_suspend' parameter, the >>> console is again operational after system suspend/resume cycle. Before >>> this patch it worked fine regardless the 'no_console_suspend' >>> parameter. >>> >>> If this matters, the test system is ARM 32bit Samsung Exynos5422-based >>> Odroid XU3lite board. >> >> One more information. This issue can be easily reproduced with QEMU. It >> happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when >> 'no_console_suspend' is added to kernel's cmdline. >> > Ideally, as comments indicate, the set_termios should have done > stop_rx at begin and start_rx at end to take care of this issue. > > This is probably missing in your driver. Can we check if this can be > fixed? Sure, just point me what need to be added in amba-pl011.c and samsung_tty.c. I've briefly compared the suspend/resume paths of those drivers with other drivers and I don't see anything missing there. > OR other option is > > Add a start_rx in uart_resume_port after call to set_termios to handle > this scenario for other drivers. > > Please let me know if there are any concerns for this options. IMHO this looks like an issue that affects lots of drivers and it should be handled in the core. > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-01 22:25 ` Marek Szyprowski @ 2022-06-02 15:42 ` Vijaya Krishna Nivarthi 2022-06-03 18:54 ` Vijaya Krishna Nivarthi 0 siblings, 1 reply; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-06-02 15:42 UTC (permalink / raw) To: Marek Szyprowski, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd Hi, On 6/2/2022 3:55 AM, Marek Szyprowski wrote: > Hi, > > On 01.06.2022 13:24, Vijaya Krishna Nivarthi wrote: >> On 5/24/2022 5:24 PM, Marek Szyprowski wrote: >>> On 23.05.2022 23:32, Marek Szyprowski wrote: >>>> Hi, >>>> >>>> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >>>>> For the case of console_suspend disabled, if back to back >>>>> suspend/resume >>>>> test is executed, at the end of test, sometimes console would >>>>> appear to >>>>> be frozen not responding to input. This would happen because, during >>>>> resume, rx transactions can come in before system is ready, >>>>> malfunction >>>>> of rx happens in turn resulting in console appearing to be stuck. >>>>> >>>>> Do a stop_rx in suspend sequence to prevent this. >>>>> >>>>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >>>>> --- >>>>> v4: moved the change to serial core to apply for all drivers >>>>> v3: swapped the order of conditions to be more human readable >>>>> v2: restricted patch to contain only stop_rx in suspend sequence >>>>> v1: intial patch contained 2 additional unrelated changes in vicinity >>>>> --- >>>> This patch landed recently in linux-next as commit c9d2325cdb92 >>>> ("serial: core: Do stop_rx in suspend path for console if >>>> console_suspend is disabled"). >>>> >>>> Unfortunately it breaks console operation on my test systems after >>>> system suspend/resume cycle if 'no_console_suspend' kernel parameter >>>> is present. System properly resumes from suspend, the console displays >>>> all the messages and even command line prompt, but then doesn't react >>>> on any input. If I remove the 'no_console_suspend' parameter, the >>>> console is again operational after system suspend/resume cycle. Before >>>> this patch it worked fine regardless the 'no_console_suspend' >>>> parameter. >>>> >>>> If this matters, the test system is ARM 32bit Samsung Exynos5422-based >>>> Odroid XU3lite board. >>> One more information. This issue can be easily reproduced with QEMU. It >>> happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when >>> 'no_console_suspend' is added to kernel's cmdline. >>> >> Ideally, as comments indicate, the set_termios should have done >> stop_rx at begin and start_rx at end to take care of this issue. >> >> This is probably missing in your driver. Can we check if this can be >> fixed? > Sure, just point me what need to be added in amba-pl011.c and > samsung_tty.c. I've briefly compared the suspend/resume paths of those > drivers with other drivers and I don't see anything missing there. > >> OR other option is >> >> Add a start_rx in uart_resume_port after call to set_termios to handle >> this scenario for other drivers. >> >> Please let me know if there are any concerns for this options. > IMHO this looks like an issue that affects lots of drivers and it should > be handled in the core. Sure, we will look into both aspects and get back as soon as possible. Thank you. > > > ... > > Best regards ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-02 15:42 ` Vijaya Krishna Nivarthi @ 2022-06-03 18:54 ` Vijaya Krishna Nivarthi 2022-06-03 19:28 ` Doug Anderson 0 siblings, 1 reply; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-06-03 18:54 UTC (permalink / raw) To: Marek Szyprowski, gregkh, jirislaby, linux-serial, linux-kernel Cc: quic_msavaliy, dianders, mka, swboyd Hi, On 6/2/2022 9:12 PM, Vijaya Krishna Nivarthi wrote: > Hi, > > > On 6/2/2022 3:55 AM, Marek Szyprowski wrote: >> Hi, >> >> On 01.06.2022 13:24, Vijaya Krishna Nivarthi wrote: >>> On 5/24/2022 5:24 PM, Marek Szyprowski wrote: >>>> On 23.05.2022 23:32, Marek Szyprowski wrote: >>>>> Hi, >>>>> >>>>> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >>>>>> For the case of console_suspend disabled, if back to back >>>>>> suspend/resume >>>>>> test is executed, at the end of test, sometimes console would >>>>>> appear to >>>>>> be frozen not responding to input. This would happen because, during >>>>>> resume, rx transactions can come in before system is ready, >>>>>> malfunction >>>>>> of rx happens in turn resulting in console appearing to be stuck. >>>>>> >>>>>> Do a stop_rx in suspend sequence to prevent this. >>>>>> >>>>>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >>>>>> --- >>>>>> v4: moved the change to serial core to apply for all drivers >>>>>> v3: swapped the order of conditions to be more human readable >>>>>> v2: restricted patch to contain only stop_rx in suspend sequence >>>>>> v1: intial patch contained 2 additional unrelated changes in >>>>>> vicinity >>>>>> --- >>>>> This patch landed recently in linux-next as commit c9d2325cdb92 >>>>> ("serial: core: Do stop_rx in suspend path for console if >>>>> console_suspend is disabled"). >>>>> >>>>> Unfortunately it breaks console operation on my test systems after >>>>> system suspend/resume cycle if 'no_console_suspend' kernel parameter >>>>> is present. System properly resumes from suspend, the console >>>>> displays >>>>> all the messages and even command line prompt, but then doesn't react >>>>> on any input. If I remove the 'no_console_suspend' parameter, the >>>>> console is again operational after system suspend/resume cycle. >>>>> Before >>>>> this patch it worked fine regardless the 'no_console_suspend' >>>>> parameter. >>>>> >>>>> If this matters, the test system is ARM 32bit Samsung >>>>> Exynos5422-based >>>>> Odroid XU3lite board. >>>> One more information. This issue can be easily reproduced with >>>> QEMU. It >>>> happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when >>>> 'no_console_suspend' is added to kernel's cmdline. >>>> >>> Ideally, as comments indicate, the set_termios should have done >>> stop_rx at begin and start_rx at end to take care of this issue. >>> >>> This is probably missing in your driver. Can we check if this can be >>> fixed? >> Sure, just point me what need to be added in amba-pl011.c and >> samsung_tty.c. I've briefly compared the suspend/resume paths of those >> drivers with other drivers and I don't see anything missing there. >> >>> OR other option is >>> >>> Add a start_rx in uart_resume_port after call to set_termios to handle >>> this scenario for other drivers. Since start_rx is not exposed it doesn't seem like we will be able to handle it in core. In your drivers, Can we add a call to stop_rx at begin of set_termios and then undo it at end? That would ensure that set_termios functionality is unaffected while fixing the broken cases? If that's not an option we will have to go back to a previous version of limiting the change to qcom driver. Thank you. >>> >>> Please let me know if there are any concerns for this options. >> IMHO this looks like an issue that affects lots of drivers and it should >> be handled in the core. > > Sure, we will look into both aspects and get back as soon as possible. > > Thank you. > >> >> > ... >> >> Best regards ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-03 18:54 ` Vijaya Krishna Nivarthi @ 2022-06-03 19:28 ` Doug Anderson 2022-06-06 12:30 ` Vijaya Krishna Nivarthi 0 siblings, 1 reply; 11+ messages in thread From: Doug Anderson @ 2022-06-03 19:28 UTC (permalink / raw) To: Vijaya Krishna Nivarthi Cc: Marek Szyprowski, Greg Kroah-Hartman, Jiri Slaby, linux-serial, LKML, quic_msavaliy, Matthias Kaehlcke, Stephen Boyd Hi, On Fri, Jun 3, 2022 at 11:54 AM Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> wrote: > > >>> Add a start_rx in uart_resume_port after call to set_termios to handle > >>> this scenario for other drivers. > > Since start_rx is not exposed it doesn't seem like we will be able to > handle it in core. > > In your drivers, Can we add a call to stop_rx at begin of set_termios > and then undo it at end? > > That would ensure that set_termios functionality is unaffected while > fixing the broken cases? > > If that's not an option we will have to go back to a previous version of > limiting the change to qcom driver. How about this: add an optional start_rx() callback to "struct uart_ops" and then only do your stop_rx() logic in uart_suspend_port() if you'll be able to start it again (AKA if the start_rx() callback is not NULL). That keeps the logic in the core. -Doug ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-03 19:28 ` Doug Anderson @ 2022-06-06 12:30 ` Vijaya Krishna Nivarthi 0 siblings, 0 replies; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-06-06 12:30 UTC (permalink / raw) To: Doug Anderson Cc: Marek Szyprowski, Greg Kroah-Hartman, Jiri Slaby, linux-serial, LKML, quic_msavaliy, Matthias Kaehlcke, Stephen Boyd Hi, On 6/4/2022 12:58 AM, Doug Anderson wrote: > Hi, > > On Fri, Jun 3, 2022 at 11:54 AM Vijaya Krishna Nivarthi > <quic_vnivarth@quicinc.com> wrote: >>>>> Add a start_rx in uart_resume_port after call to set_termios to handle >>>>> this scenario for other drivers. >> Since start_rx is not exposed it doesn't seem like we will be able to >> handle it in core. >> >> In your drivers, Can we add a call to stop_rx at begin of set_termios >> and then undo it at end? >> >> That would ensure that set_termios functionality is unaffected while >> fixing the broken cases? >> >> If that's not an option we will have to go back to a previous version of >> limiting the change to qcom driver. > How about this: add an optional start_rx() callback to "struct > uart_ops" and then only do your stop_rx() logic in uart_suspend_port() > if you'll be able to start it again (AKA if the start_rx() callback is > not NULL). That keeps the logic in the core. This seems good. Thank you. And also conditionally call start_rx in uart_resume_port after call to set_termios? I have tested such patch and it is working fine, will upload it. -Vijay/ > -Doug ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-05-23 21:32 ` Marek Szyprowski [not found] ` <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com> @ 2022-06-07 13:22 ` Greg KH 2022-06-07 13:25 ` Vijaya Krishna Nivarthi 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2022-06-07 13:22 UTC (permalink / raw) To: Marek Szyprowski Cc: Vijaya Krishna Nivarthi, jirislaby, linux-serial, linux-kernel, quic_msavaliy, dianders, mka, swboyd On Mon, May 23, 2022 at 11:32:46PM +0200, Marek Szyprowski wrote: > Hi, > > On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: > > For the case of console_suspend disabled, if back to back suspend/resume > > test is executed, at the end of test, sometimes console would appear to > > be frozen not responding to input. This would happen because, during > > resume, rx transactions can come in before system is ready, malfunction > > of rx happens in turn resulting in console appearing to be stuck. > > > > Do a stop_rx in suspend sequence to prevent this. > > > > Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> > > --- > > v4: moved the change to serial core to apply for all drivers > > v3: swapped the order of conditions to be more human readable > > v2: restricted patch to contain only stop_rx in suspend sequence > > v1: intial patch contained 2 additional unrelated changes in vicinity > > --- > > This patch landed recently in linux-next as commit c9d2325cdb92 > ("serial: core: Do stop_rx in suspend path for console if > console_suspend is disabled"). > > Unfortunately it breaks console operation on my test systems after > system suspend/resume cycle if 'no_console_suspend' kernel parameter is > present. System properly resumes from suspend, the console displays all > the messages and even command line prompt, but then doesn't react on any > input. If I remove the 'no_console_suspend' parameter, the console is > again operational after system suspend/resume cycle. Before this patch > it worked fine regardless the 'no_console_suspend' parameter. Did this ever get resolved or do I need to revert this? thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled 2022-06-07 13:22 ` Greg KH @ 2022-06-07 13:25 ` Vijaya Krishna Nivarthi 0 siblings, 0 replies; 11+ messages in thread From: Vijaya Krishna Nivarthi @ 2022-06-07 13:25 UTC (permalink / raw) To: Greg KH, Marek Szyprowski Cc: jirislaby, linux-serial, linux-kernel, quic_msavaliy, dianders, mka, swboyd On 6/7/2022 6:52 PM, Greg KH wrote: > On Mon, May 23, 2022 at 11:32:46PM +0200, Marek Szyprowski wrote: >> Hi, >> >> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote: >>> For the case of console_suspend disabled, if back to back suspend/resume >>> test is executed, at the end of test, sometimes console would appear to >>> be frozen not responding to input. This would happen because, during >>> resume, rx transactions can come in before system is ready, malfunction >>> of rx happens in turn resulting in console appearing to be stuck. >>> >>> Do a stop_rx in suspend sequence to prevent this. >>> >>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> >>> --- >>> v4: moved the change to serial core to apply for all drivers >>> v3: swapped the order of conditions to be more human readable >>> v2: restricted patch to contain only stop_rx in suspend sequence >>> v1: intial patch contained 2 additional unrelated changes in vicinity >>> --- >> This patch landed recently in linux-next as commit c9d2325cdb92 >> ("serial: core: Do stop_rx in suspend path for console if >> console_suspend is disabled"). >> >> Unfortunately it breaks console operation on my test systems after >> system suspend/resume cycle if 'no_console_suspend' kernel parameter is >> present. System properly resumes from suspend, the console displays all >> the messages and even command line prompt, but then doesn't react on any >> input. If I remove the 'no_console_suspend' parameter, the console is >> again operational after system suspend/resume cycle. Before this patch >> it worked fine regardless the 'no_console_suspend' parameter. > Did this ever get resolved or do I need to revert this? We have a resolution and I will be uploading a Fixes: patch today. Thank you. -Vijay/ > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-06-07 13:26 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-16 9:20 [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled Vijaya Krishna Nivarthi [not found] ` <CGME20220523213246eucas1p2d0da08d931a996cd3410eda1c2fd48c0@eucas1p2.samsung.com> 2022-05-23 21:32 ` Marek Szyprowski [not found] ` <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com> 2022-05-24 11:54 ` Marek Szyprowski 2022-06-01 11:24 ` Vijaya Krishna Nivarthi 2022-06-01 22:25 ` Marek Szyprowski 2022-06-02 15:42 ` Vijaya Krishna Nivarthi 2022-06-03 18:54 ` Vijaya Krishna Nivarthi 2022-06-03 19:28 ` Doug Anderson 2022-06-06 12:30 ` Vijaya Krishna Nivarthi 2022-06-07 13:22 ` Greg KH 2022-06-07 13:25 ` Vijaya Krishna Nivarthi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).