Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings

[Punit Agrawal <punitagrawal@gmail.com>]

Hi Qu,

Qu Wenruo <wqu@suse.com> writes:

> On 2021/8/30 22:10, Michael Riesch wrote:
>> Hi Punit,
>> On 8/30/21 3:49 PM, Punit Agrawal wrote:
>>> Hi Michael,
>>>
>>> Michael Riesch <michael.riesch@wolfvision.net> writes:
>>>
>>>> Hi ChenYu,
>>>>
>>>> On 8/29/21 7:48 PM, Chen-Yu Tsai wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, Aug 23, 2021 at 10:39 PM Michael Riesch
>>>>> <michael.riesch@wolfvision.net> wrote:
>>>>>>
>>>>>> This reverts commit 2c896fb02e7f65299646f295a007bda043e0f382
>>>>>> "net: stmmac: dwmac-rk: add pd_gmac support for rk3399" and fixes
>>>>>> unbalanced pm_runtime_enable warnings.
>>>>>>
>>>>>> In the commit to be reverted, support for power management was
>>>>>> introduced to the Rockchip glue code. Later, power management support
>>>>>> was introduced to the stmmac core code, resulting in multiple
>>>>>> invocations of pm_runtime_{enable,disable,get_sync,put_sync}.
>>>>>>
>>>>>> The multiple invocations happen in rk_gmac_powerup and
>>>>>> stmmac_{dvr_probe, resume} as well as in rk_gmac_powerdown and
>>>>>> stmmac_{dvr_remove, suspend}, respectively, which are always called
>>>>>> in conjunction.
>>>>>>
>>>>>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
>>>>>
>>>>> I just found that Ethernet stopped working on my RK3399 devices,
>>>>> and I bisected it down to this patch.
>>>>
>>>> Oh dear. First patch in a kernel release for a while and I already break
>>>> things.
>>>
>>> I am seeing the same failure symptoms reported by ChenYu on my RockPro64
>>> with v5.14. Reverting the revert i.e., 2d26f6e39afb ("net: stmmac:
>>> dwmac-rk: fix unbalanced pm_runtime_enable warnings") brings back the
>>> network.
>>>
>>>> Cc: Sasha as this patch has just been applied to 5.13-stable.
>>>>
>>>>> The symptom I see is no DHCP responses, either because the request
>>>>> isn't getting sent over the wire, or the response isn't getting
>>>>> received. The PHY seems to be working correctly.
>>>>
>>>> Unfortunately I don't have any RK3399 hardware. Is this a custom
>>>> board/special hardware or something that is readily available in the
>>>> shops? Maybe this is a good reason to buy a RK3399 based single-board
>>>> computer :-)
>>>
>>> Not sure about the other RK3399 boards but RockPro64 is easily
>>> available.
>> I was thinking to get one of those anyway ;-)
>> 
>>>> I am working on the RK3568 EVB1 and have not encountered faulty
>>>> behavior. DHCP works fine and I can boot via NFS. Therefore, not sure
>>>> whether I can be much of help in this matter, but in case you want to
>>>> discuss this further please do not hesitate to contact me off-list.
>>>
>>> I tried to look for the differences between RK3568 and RK3399 but the
>>> upstream device tree doesn't seem to carry a gmac node in the device
>>> tree for EK3568 EVB1. Do you have a pointer for the dts you're using?
>> The gmac nodes have been added recently and should enter
>> 5.15-rc1. Until
>> then, you can check out the dts from linux-rockchip/for-next [0].
>
> Do you have the upstream commit?
>
> As I compiled v5.15-rc1 and still can't get the ethernet work.
>
> Not sure if it's my Uboot->systemd-boot->customer kernel setup not
> passing the device tree correctly or something else...

For the RK3568 device tree changes, I think the pull request got delayed
to the next cycle. So likely to land in v5.16.

In case you're after ethernet on RK3399, there's no solution
yet. Reverting 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced
pm_runtime_enable warnings") gets you there in the meanwhile.

[...]