netdev - Re: [PATCH v2 4/4] net: macb: Add support for suspend/resume with full power down

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 27 Nov 2018 10:31:57 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <harinik@...inx.com>
CC:     <harini.katakam@...inx.com>, <Nicolas.Ferre@...rochip.com>,
        <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <michal.simek@...inx.com>,
        <appanad@...inx.com>
Subject: Re: [PATCH v2 4/4] net: macb: Add support for suspend/resume with
 full power down

Hi Harini,

On 27.11.2018 08:25, Harini Katakam wrote:
> Hi Claudiu,
> 
> On Mon, Nov 26, 2018 at 8:16 PM <Claudiu.Beznea@...rochip.com> wrote:
>>
>>
>>
>> On 26.11.2018 09:07, Harini Katakam wrote:
> <snip>
>>
>> In the previous version you said you encountered some crashes while
>> stressing this part if macb_open()/macb_close() was used in here. Could you
>> share the tests so that I can debug it on my side?
> 
> Sure, my tests include doing a series of suspend/resume -- it is done
> as part of a
> random regression script. On ZynqMP, it includes the following to do an
> FPD off suspend and then use either UART or WOL as a wake source and
> repeat the same, sometimes pinging in between:
> 
> echo pm_request_wakeup 8 1 0 1 > /sys/kernel/debug/zynqmp-firmware/pm
> echo pm_force_powerdown 6 > /sys/kernel/debug/zynqmp-firmware/pm
> echo enabled > /sys/devices/platform/amba/ff000000.serial/tty/ttyPS0/power/wakeup
> echo enabled > /sys/devices/platform/amba/ff0e0000.ethernet/net/eth0/power/wakeup
> echo mem > /sys/power/state
> 
> ping does not work sometimes and after a few iterations (sometimes
> 20), a crash can be
> observed tracing from "kfree_skb_list" to "macb_free_consistent". From
> the flow, the
> only explanation I could come up with was that there was an attempt to
> free buffers that
> may not have been allocated. Also, this was time consuming in the
> suspend/resume path.

Thank you for all these. I will try it on my side to see if I can reproduce it.

> 
> <snip>
>>> +     } else {
>>> +             macb_writel(bp, NCR, MACB_BIT(MPE));
>>
>> Just asking... shouldn't other registers be restored here after SoC power
>> is cut off?
> Ideally yes. But in this series, I'm just attempting to re-initialize
> to a working
> state. I can try context save/restore later.

I see. I have tried it on my own with SAMA5D2 backup and self-refresh mode
where the core is shut down and it doesn't resume OK. Anyway, no issue, I
can add my context save/restore after this is accepted.

The idea with macb_open()/macb_close() was that it is doing everything for
you and every time new things are implemented you wouldn't have to add them
also in suspend/resume functions.

Thank you,
Claudiu Beznea

> Regards,
> Harini
>