linux-kernel - Re: [PATCH v5] serial: sh-sci: Update the suspend/resume support

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVD-=n5LdRk42SicdH6MoffTfNGtAz_1AMQ1c7Mui7dFg@mail.gmail.com>
Date: Thu, 6 Feb 2025 13:47:16 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Claudiu <claudiu.beznea@...on.dev>
Cc: gregkh@...uxfoundation.org, jirislaby@...nel.org, p.zabel@...gutronix.de, 
	wsa+renesas@...g-engineering.com, prabhakar.mahadev-lad.rj@...renesas.com, 
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, 
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v5] serial: sh-sci: Update the suspend/resume support

Hi Claudiu,

On Wed, 5 Feb 2025 at 10:31, Claudiu <claudiu.beznea@...on.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>
> The Renesas RZ/G3S supports a power saving mode where power to most of the
> SoC components is turned off. When returning from this power saving mode,
> SoC components need to be re-configured.
>
> The SCIFs on the Renesas RZ/G3S need to be re-configured as well when
> returning from this power saving mode. The sh-sci code already configures
> the SCIF clocks, power domain and registers by calling uart_resume_port()
> in sci_resume(). On suspend path the SCIF UART ports are suspended
> accordingly (by calling uart_suspend_port() in sci_suspend()). The only
> missing setting is the reset signal. For this assert/de-assert the reset
> signal on driver suspend/resume.
>
> In case the no_console_suspend is specified by the user, the registers need
> to be saved on suspend path and restore on resume path. To do this the
> sci_console_save_restore() function was added. There is no need to
> cache/restore the status or FIFO registers. Only the control registers.
> The registers that will be saved/restored on suspend/resume are
> specified by the struct sci_suspend_regs data structure.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> ---
>
> The v4 of this patch was part of a series with 4 patches. As the rest of
> the patches were applied I dropped the cover letter. The v4 cover letter
> is located here:
> https://lore.kernel.org/all/20250120130936.1080069-1-claudiu.beznea.uj@bp.renesas.com
>
> Changes in v5:
> - fixed typo in patch description
> - adjusted the patch description to reflect the new patch content
> - added struct sci_suspend_regs and dropped the suspend_cacheable
>   flag introduced previously in struct plat_sci_reg; along with it
>   the updates in sci_port_params[] were also dropped;
>   also, the function (now sci_console_save_restore()) that saves
>   and restores the registers content was adjusted accordingly
> - s/sci_console_setup/sci_console_save_restore/g

Thanks for the update!

> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -3546,13 +3559,41 @@ static int sci_probe(struct platform_device *dev)
>         return 0;
>  }
>
> +static void sci_console_save_restore(struct sci_port *s, bool save)
> +{
> +       struct sci_suspend_regs *regs = &s->suspend_regs;
> +       struct uart_port *port = &s->port;
> +
> +       if (save) {
> +               regs->scsmr = sci_serial_in(port, SCSMR);
> +               regs->scscr = sci_serial_in(port, SCSCR);
> +               regs->scfcr = sci_serial_in(port, SCFCR);
> +               regs->scsptr = sci_serial_in(port, SCSPTR);
> +               regs->scbrr = sci_serial_in(port, SCBRR);
> +               regs->semr = sci_serial_in(port, SEMR);

The SCFCR, SCSPTR, and SEMR registers do not exist on all
variants.  Hence you should call sci_getreg() and check if
plat_sci_reg.size is non-zero first, else you will trigger the WARN()
in sci_serial_in().

> +       } else {
> +               sci_serial_out(port, SCSMR, regs->scsmr);
> +               sci_serial_out(port, SCSCR, regs->scscr);
> +               sci_serial_out(port, SCFCR, regs->scfcr);
> +               sci_serial_out(port, SCSPTR, regs->scsptr);
> +               sci_serial_out(port, SCBRR, regs->scbrr);
> +               sci_serial_out(port, SEMR, regs->semr);

Likewise for sci_serial_out().

> +       }
> +}

Given there's nothing really shared anymore, I would split this in
separate sci_console_save() and sci_console_restore() functions.

The rest LGTM.

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