| 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: <b409fd8d-4c5e-4f1d-94fa-b37ab25095c9@tuxon.dev>
Date: Mon, 27 Jan 2025 14:23:37 +0200
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: magnus.damm@...il.com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, gregkh@...uxfoundation.org, jirislaby@...nel.org,
p.zabel@...gutronix.de, claudiu.beznea.uj@...renesas.com,
wsa+renesas@...g-engineering.com, prabhakar.mahadev-lad.rj@...renesas.com,
linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH v4 1/4] serial: sh-sci: Update the suspend/resume support
Hi, Geert,
On 27.01.2025 11:19, Geert Uytterhoeven wrote:
> Hi Claudiu,
>
> On Mon, 27 Jan 2025 at 09:44, Claudiu Beznea <claudiu.beznea@...on.dev> wrote:
>> On 24.01.2025 12:53, Geert Uytterhoeven wrote:
>>> On Mon, Jan 20, 2025 at 2:09 PM 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_setup() function was added. There is no need to cache/restore
>>>> the status or FIFO registers. Only the control registers. To differentiate
>>>> b/w these, the struct sci_port_params::regs was updated with a new member
>>>> that specifies if the register needs to be chached on suspend. Only the
>>>
>>> cached
>>>
>>>> RZ_SCIFA instances were updated with this new support as the hardware for
>>>> the rest of variants was missing for testing.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>>
>>>> --- a/drivers/tty/serial/sh-sci.c
>>>> +++ b/drivers/tty/serial/sh-sci.c
>>>> @@ -101,7 +101,7 @@ enum SCI_CLKS {
>>>> if ((_port)->sampling_rate_mask & SCI_SR((_sr)))
>>>>
>>>> struct plat_sci_reg {
>>>> - u8 offset, size;
>>>> + u8 offset, size, suspend_cacheable;
>>>
>>> This increases the size of sci_port_params[] by 300 bytes.
>>> Using bitfields would mitigate that:
>>>
>>> struct plat_sci_reg {
>>> u16 offset:8;
>>> u16 size:5;
>>> u16 suspend_cacheable:1;
>>> };
>>>
>>> (if we ever need more bits, the size member can store an enum value
>>> instead of the actual size (8 or 16 bits) of the register).
>>>
>>>> };
>>
>> OK
>>
>>>>
>>>> struct sci_port_params {
>>>> @@ -134,6 +134,8 @@ struct sci_port {
>>>> struct dma_chan *chan_tx;
>>>> struct dma_chan *chan_rx;
>>>>
>>>> + struct reset_control *rstc;
>>>> +
>>>> #ifdef CONFIG_SERIAL_SH_SCI_DMA
>>>> struct dma_chan *chan_tx_saved;
>>>> struct dma_chan *chan_rx_saved;
>>>> @@ -153,6 +155,7 @@ struct sci_port {
>>>> int rx_trigger;
>>>> struct timer_list rx_fifo_timer;
>>>> int rx_fifo_timeout;
>>>> + unsigned int console_cached_regs[SCIx_NR_REGS];
>>>
>>> u16, as all registers are 8 or 16 bit wide.
>>
>> OK.
>>
>>>
>>> We reserve space for 20 registers, but at most 6 will be used.
>>> This has a rather big impact on the size of sci_ports[], as
>>> CONFIG_SERIAL_SH_SCI_NR_UARTS defaults to 18.
>>
>> I agree, but this should keep the suspend/resume code sane in case
>> extensions will be added to the code. In general people forget about
>> suspend/resume code when extending. Please let me know if you prefer to
>> limit it (although, doing like this will complicate the code, I think).
>>
>>>
>>> Also, this space is used/needed only if:
>>> - CONFIG_PM_SLEEP=y,
>>> - CONFIG_SERIAL_CORE_CONSOLE=y (see uart_console()),
>>> - The port is actually used as a console (unfortunately the user
>>> can specify multiple console=ttySC<N> command line parameters, in
>>> addition to chosen/stdout-path).
>>
>> Would you prefer to guard the suspend/resume code with these flags?
>
> I was also thinking about console_cached_regs[].
Agree.
> But if you would
> protect that by #ifdef, you also have to protect the code that uses it,
> meaning less compile coverage.
>
> If you just add a static inline helper function to check for
> CONFIG_PM_SLEEP, !console_suspend_enabled, and
> uart_console(&sport->port):
>
> static bool sci_console_keep_alive(struct sci_port *sport)
> {
> return IS_ENABLED(CONFIG_PM_SLEEP) &&
> !console_suspend_enabled && uart_console(&sport->port);
> }
>
> then most of the code will be validated but optimized away when unused.
I wasn't aware of this approach. I'll give it a try, if any.
>
>>>> u16 hscif_tot;
>>>>
>>>> bool has_rtscts;
>>>> @@ -300,17 +303,17 @@ static const struct sci_port_params sci_port_params[SCIx_NR_REGTYPES] = {
>>>> */
>>>> [SCIx_RZ_SCIFA_REGTYPE] = {
>>>> .regs = {
>>>> - [SCSMR] = { 0x00, 16 },
>>>> - [SCBRR] = { 0x02, 8 },
>>>> - [SCSCR] = { 0x04, 16 },
>>>> + [SCSMR] = { 0x00, 16, 1 },
>>>> + [SCBRR] = { 0x02, 8, 1 },
>>>> + [SCSCR] = { 0x04, 16, 1 },
>>>> [SCxTDR] = { 0x06, 8 },
>>>> [SCxSR] = { 0x08, 16 },
>>>> [SCxRDR] = { 0x0A, 8 },
>>>> - [SCFCR] = { 0x0C, 16 },
>>>> + [SCFCR] = { 0x0C, 16, 1 },
>>>> [SCFDR] = { 0x0E, 16 },
>>>> - [SCSPTR] = { 0x10, 16 },
>>>> + [SCSPTR] = { 0x10, 16, 1 },
>>>> [SCLSR] = { 0x12, 16 },
>>>> - [SEMR] = { 0x14, 8 },
>>>> + [SEMR] = { 0x14, 8, 1 },
>>>
>>> Note that the driver always writes zero to SEMR.
>>
>> In case the IP is used on SoCs with sleep states where the resume is done
>> with the help of bootloader, the bootloader code might interact with
>> registers that the Linux code writes with zero.
>>
>> Keeping it for registers where driver writes zero should also help if the
>> serial IPs power will be off during suspend, thus registers restored to non
>> zero default values (by HW) after resume.
>
> Sure, the driver would have to write zero to the register anyway.
>
> While storing the suspend_cacheable flag wouldn't cost any storage
> space anymore using bitfields, I am wondering if it would be worthwhile
> to have explicit code to save/restore registers, instead of looping
> over all of them and checking the flag. I.e.
>
> u16 saved_scmsr;
> u16 saved_scscr;
> u8 saved_scbrr;
> ...
> u8 saved_semr;
>
> /* Save omnipresent registers */
> s->saved_scmsr = sci_serial_in(port, SCSMR);
> ...
> /* Save optional registers */
> if (sci_getreg(port, SEMR)->size)
> s->saved_semr = sci_serial_in(port, SEMR);
>
> That would make it apply to all SCI variants, not just for SCIFA,
> while increasing sci_port by only 10 bytes/port. And 10 bytes/port is
> probably not worth to be protected by an #ifdef...
That was the other approach I thought about when working on this patch. I
chose the one proposed in this patch as it looked to me simpler to extend
to other registers, if needed (just enable proper flag in
sci_port_params[]). And needed less changes for the code saving/restoring
the registers.
If you prefer your version let me know and I'll switch to it.
Thank you,
Claudiu
>
> Thoughts?
>
> Gr{oetje,eeting}s,
>
> Geert
>
Powered by blists - more mailing lists