netdev - Re: RTL8402 stops working after hibernate/resume

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]

Message-ID: <30969885-9611-06d8-d50a-577897fcab29@gmail.com>
Date:   Fri, 25 Sep 2020 16:47:54 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Petr Tesarik <ptesarik@...e.cz>
Cc:     Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        netdev@...r.kernel.org
Subject: Re: RTL8402 stops working after hibernate/resume

On 25.09.2020 14:56, Petr Tesarik wrote:
> On Fri, 25 Sep 2020 11:52:41 +0200
> Petr Tesarik <ptesarik@...e.cz> wrote:
> 
>> On Fri, 25 Sep 2020 11:44:09 +0200
>> Heiner Kallweit <hkallweit1@...il.com> wrote:
>>
>>> On 25.09.2020 10:54, Petr Tesarik wrote:  
>> [...]
>>>> Does it make sense to bisect the change that broke the driver for me, or should I rather dispose of this waste^Wlaptop in an environmentally friendly manner? I mean, would you eventually accept a workaround for a few machines with a broken BIOS?
>>>>     
>>> If the workaround is small and there's little chance to break other stuff: then usually yes.
>>> If you can spend the effort to bisect the issue, this would be appreciated.  
>>
>> OK, then I'm going to give it a try.
> 
> Done. The system freezes when this commit is applied:
> 
> commit 9f0b54cd167219266bd3864570ae8f4987b57520
> Author: Heiner Kallweit <hkallweit1@...il.com>
> Date:   Wed Jun 17 22:55:40 2020 +0200
> 
>     r8169: move switching optional clock on/off to pll power functions
> 
This sounds weird. On your system tp->clk should be NULL, making
clk_prepare_enable() et al no-ops. Please check whether tp->clk
is NULL after the call to rtl_get_ether_clk().

    
>     Relevant chip clocks are disabled in rtl_pll_power_down(), therefore
>     move calling clk_disable_unprepare() there. Similar for enabling the
>     clock.
>     
>     Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>     Signed-off-by: David S. Miller <davem@...emloft.net>
> 
> I cannot be sure this is related to the malfunction after resume reported earlier, but it again touches the suspend/resume path...
> 
> Anything else I should try?
> 
> Petr T
>