On 25.09.2020 14:56, Petr Tesarik wrote:
> On Fri, 25 Sep 2020 11:52:41 +0200
> Petr Tesarik <ptesa...@suse.cz> wrote:
>
>> On Fri, 25 Sep 2020 11:44:09 +0200
>> Heiner Kallweit <hkallwe...@gmail.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 <hkallwe...@gmail.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 <hkallwe...@gmail.com>
> Signed-off-by: David S. Miller <da...@davemloft.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
>
