* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 7:57 ` Michael Riesch
0 siblings, 0 replies; 49+ messages in thread
From: Michael Riesch @ 2021-08-30 7:57 UTC (permalink / raw)
To: wens
Cc: netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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.
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 :-)
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.
> ChenYu
Best regards,
Michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 7:57 ` Michael Riesch
0 siblings, 0 replies; 49+ messages in thread
From: Michael Riesch @ 2021-08-30 7:57 UTC (permalink / raw)
To: wens
Cc: netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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.
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 :-)
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.
> ChenYu
Best regards,
Michael
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-08-30 7:57 ` Michael Riesch
(?)
@ 2021-08-30 13:49 ` Punit Agrawal
-1 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-08-30 13:49 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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 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?
Also, other than the warning "Unbalanced pm_runtime_enable!" do you
notice any other ill-effects without your patch?
If this affects all RK3399 boards as ChenYu suggests quite a few users
are going to miss the network once they upgrade.
Punit
[...]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 13:49 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-08-30 13:49 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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 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?
Also, other than the warning "Unbalanced pm_runtime_enable!" do you
notice any other ill-effects without your patch?
If this affects all RK3399 boards as ChenYu suggests quite a few users
are going to miss the network once they upgrade.
Punit
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 13:49 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-08-30 13:49 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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 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?
Also, other than the warning "Unbalanced pm_runtime_enable!" do you
notice any other ill-effects without your patch?
If this affects all RK3399 boards as ChenYu suggests quite a few users
are going to miss the network once they upgrade.
Punit
[...]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-08-30 13:49 ` Punit Agrawal
(?)
@ 2021-08-30 14:10 ` Michael Riesch
-1 siblings, 0 replies; 49+ messages in thread
From: Michael Riesch @ 2021-08-30 14:10 UTC (permalink / raw)
To: Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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].
> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
> notice any other ill-effects without your patch?
No, not as such.
Best regards,
Michael
> If this affects all RK3399 boards as ChenYu suggests quite a few users
> are going to miss the network once they upgrade.>
> Punit
>
> [...]
>
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 14:10 ` Michael Riesch
0 siblings, 0 replies; 49+ messages in thread
From: Michael Riesch @ 2021-08-30 14:10 UTC (permalink / raw)
To: Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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].
> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
> notice any other ill-effects without your patch?
No, not as such.
Best regards,
Michael
> If this affects all RK3399 boards as ChenYu suggests quite a few users
> are going to miss the network once they upgrade.>
> Punit
>
> [...]
>
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 14:10 ` Michael Riesch
0 siblings, 0 replies; 49+ messages in thread
From: Michael Riesch @ 2021-08-30 14:10 UTC (permalink / raw)
To: Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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].
> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
> notice any other ill-effects without your patch?
No, not as such.
Best regards,
Michael
> If this affects all RK3399 boards as ChenYu suggests quite a few users
> are going to miss the network once they upgrade.>
> Punit
>
> [...]
>
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-08-30 14:10 ` Michael Riesch
(?)
@ 2021-09-17 2:22 ` Qu Wenruo
-1 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 2:22 UTC (permalink / raw)
To: Michael Riesch, Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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...
Thanks,
Qu
>
>> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
>> notice any other ill-effects without your patch?
>
> No, not as such.
>
> Best regards,
> Michael
>
>> If this affects all RK3399 boards as ChenYu suggests quite a few users
>> are going to miss the network once they upgrade.>
>> Punit
>>
>> [...]
>>
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 2:22 ` Qu Wenruo
0 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 2:22 UTC (permalink / raw)
To: Michael Riesch, Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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...
Thanks,
Qu
>
>> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
>> notice any other ill-effects without your patch?
>
> No, not as such.
>
> Best regards,
> Michael
>
>> If this affects all RK3399 boards as ChenYu suggests quite a few users
>> are going to miss the network once they upgrade.>
>> Punit
>>
>> [...]
>>
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 2:22 ` Qu Wenruo
0 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 2:22 UTC (permalink / raw)
To: Michael Riesch, Punit Agrawal
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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...
Thanks,
Qu
>
>> Also, other than the warning "Unbalanced pm_runtime_enable!" do you
>> notice any other ill-effects without your patch?
>
> No, not as such.
>
> Best regards,
> Michael
>
>> If this affects all RK3399 boards as ChenYu suggests quite a few users
>> are going to miss the network once they upgrade.>
>> Punit
>>
>> [...]
>>
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-09-17 2:22 ` Qu Wenruo
(?)
@ 2021-09-17 7:18 ` Punit Agrawal
-1 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 7:18 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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.
[...]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 7:18 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 7:18 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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.
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 7:18 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 7:18 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
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.
[...]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-09-17 7:18 ` Punit Agrawal
(?)
@ 2021-09-17 8:02 ` Qu Wenruo
-1 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 8:02 UTC (permalink / raw)
To: Punit Agrawal
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
On 2021/9/17 15:18, Punit Agrawal wrote:
> 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.
Thanks, currently I have seen other distros like ManjaroARM is already
reverting that commit.
But even with that commit reverted, I still get some other strange
network behavior.
The most weird one is distcc, when the RK3399 board is the client and
x86_64 desktop acts as a volunteer, after compiling hundreds of files,
it suddenly no longer work.
All work can no longer be distributed to the same volunteer.
But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
binary is the same), the same distro (Manjaro ARM), the same distcc
setup, the setup works flawless.
Not sure if this is related, but it looks like a network related
problem, and considering both boards are using the same kernel, just
different ethernet driver, I guess there is something more problematic
here in recent RK3399 code.
Thanks,
Qu
>
> [...]
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 8:02 ` Qu Wenruo
0 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 8:02 UTC (permalink / raw)
To: Punit Agrawal
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
On 2021/9/17 15:18, Punit Agrawal wrote:
> 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.
Thanks, currently I have seen other distros like ManjaroARM is already
reverting that commit.
But even with that commit reverted, I still get some other strange
network behavior.
The most weird one is distcc, when the RK3399 board is the client and
x86_64 desktop acts as a volunteer, after compiling hundreds of files,
it suddenly no longer work.
All work can no longer be distributed to the same volunteer.
But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
binary is the same), the same distro (Manjaro ARM), the same distcc
setup, the setup works flawless.
Not sure if this is related, but it looks like a network related
problem, and considering both boards are using the same kernel, just
different ethernet driver, I guess there is something more problematic
here in recent RK3399 code.
Thanks,
Qu
>
> [...]
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 8:02 ` Qu Wenruo
0 siblings, 0 replies; 49+ messages in thread
From: Qu Wenruo @ 2021-09-17 8:02 UTC (permalink / raw)
To: Punit Agrawal
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, sashal
On 2021/9/17 15:18, Punit Agrawal wrote:
> 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.
Thanks, currently I have seen other distros like ManjaroARM is already
reverting that commit.
But even with that commit reverted, I still get some other strange
network behavior.
The most weird one is distcc, when the RK3399 board is the client and
x86_64 desktop acts as a volunteer, after compiling hundreds of files,
it suddenly no longer work.
All work can no longer be distributed to the same volunteer.
But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
binary is the same), the same distro (Manjaro ARM), the same distcc
setup, the setup works flawless.
Not sure if this is related, but it looks like a network related
problem, and considering both boards are using the same kernel, just
different ethernet driver, I guess there is something more problematic
here in recent RK3399 code.
Thanks,
Qu
>
> [...]
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-09-17 8:02 ` Qu Wenruo
(?)
@ 2021-09-17 15:11 ` Punit Agrawal
-1 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 15:11 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro, Jose Abreu,
David S . Miller, Jakub Kicinski, Maxime Coquelin, sashal
Qu Wenruo <wqu@suse.com> writes:
> On 2021/9/17 15:18, Punit Agrawal wrote:
>> 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.
>
> Thanks, currently I have seen other distros like ManjaroARM is already
> reverting that commit.
>
> But even with that commit reverted, I still get some other strange
> network behavior.
>
> The most weird one is distcc, when the RK3399 board is the client and
> x86_64 desktop acts as a volunteer, after compiling hundreds of files,
> it suddenly no longer work.
I haven't seen something like this - but then I am not a heavy user of
the network on the board.
Is it just the network that dies or the whole system freezes? Sometimes
I've seen the board lock up if it's under heavy load.
> All work can no longer be distributed to the same volunteer.
>
>
> But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
> binary is the same), the same distro (Manjaro ARM), the same distcc
> setup, the setup works flawless.
>
>
> Not sure if this is related, but it looks like a network related
> problem, and considering both boards are using the same kernel, just
> different ethernet driver, I guess there is something more problematic
> here in recent RK3399 code.
If you are only seeing the problem with recent kernels, maybe a bisect
might help narrow things down.
[...]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 15:11 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 15:11 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro, Jose Abreu,
David S . Miller, Jakub Kicinski, Maxime Coquelin, sashal
Qu Wenruo <wqu@suse.com> writes:
> On 2021/9/17 15:18, Punit Agrawal wrote:
>> 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.
>
> Thanks, currently I have seen other distros like ManjaroARM is already
> reverting that commit.
>
> But even with that commit reverted, I still get some other strange
> network behavior.
>
> The most weird one is distcc, when the RK3399 board is the client and
> x86_64 desktop acts as a volunteer, after compiling hundreds of files,
> it suddenly no longer work.
I haven't seen something like this - but then I am not a heavy user of
the network on the board.
Is it just the network that dies or the whole system freezes? Sometimes
I've seen the board lock up if it's under heavy load.
> All work can no longer be distributed to the same volunteer.
>
>
> But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
> binary is the same), the same distro (Manjaro ARM), the same distcc
> setup, the setup works flawless.
>
>
> Not sure if this is related, but it looks like a network related
> problem, and considering both boards are using the same kernel, just
> different ethernet driver, I guess there is something more problematic
> here in recent RK3399 code.
If you are only seeing the problem with recent kernels, maybe a bisect
might help narrow things down.
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-09-17 15:11 ` Punit Agrawal
0 siblings, 0 replies; 49+ messages in thread
From: Punit Agrawal @ 2021-09-17 15:11 UTC (permalink / raw)
To: Qu Wenruo
Cc: Michael Riesch, wens, netdev,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro, Jose Abreu,
David S . Miller, Jakub Kicinski, Maxime Coquelin, sashal
Qu Wenruo <wqu@suse.com> writes:
> On 2021/9/17 15:18, Punit Agrawal wrote:
>> 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.
>
> Thanks, currently I have seen other distros like ManjaroARM is already
> reverting that commit.
>
> But even with that commit reverted, I still get some other strange
> network behavior.
>
> The most weird one is distcc, when the RK3399 board is the client and
> x86_64 desktop acts as a volunteer, after compiling hundreds of files,
> it suddenly no longer work.
I haven't seen something like this - but then I am not a heavy user of
the network on the board.
Is it just the network that dies or the whole system freezes? Sometimes
I've seen the board lock up if it's under heavy load.
> All work can no longer be distributed to the same volunteer.
>
>
> But on RPI CM4 board, the same kernel (both upstream 5.14.2, even the
> binary is the same), the same distro (Manjaro ARM), the same distcc
> setup, the setup works flawless.
>
>
> Not sure if this is related, but it looks like a network related
> problem, and considering both boards are using the same kernel, just
> different ethernet driver, I guess there is something more problematic
> here in recent RK3399 code.
If you are only seeing the problem with recent kernels, maybe a bisect
might help narrow things down.
[...]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-08-30 7:57 ` Michael Riesch
(?)
@ 2021-08-30 16:03 ` Chen-Yu Tsai
-1 siblings, 0 replies; 49+ messages in thread
From: Chen-Yu Tsai @ 2021-08-30 16:03 UTC (permalink / raw)
To: Michael Riesch
Cc: netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, Sasha Levin
Hi,
On Mon, Aug 30, 2021 at 3:57 PM Michael Riesch
<michael.riesch@wolfvision.net> wrote:
>
> 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.
>
> 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 :-)
I hit this on an ROC-RK3399-PC first, then bisected it on a NanoPi M4V2.
They both should be easy to get from their respective vendors. AFAIK
all the RK3399 devices have pretty much the same setup for Ethernet.
BTW, Don't get the Nanopi in the M4V2 variant. Get the original M4, or
the M4B (but the WiFi on the M4B doesn't seem to work lately).
> 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.
My gut is telling me (without looking at the code) that maybe the GRF
access was not going through, and so the RGMII delays and stuff weren't
set properly, hence no traffic getting to/from the PHY. Otherwise there
were no error messages. I don't think I'll be able to squeeze out more
cycles to track down what actually went wrong though.
Regards
ChenYu
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 16:03 ` Chen-Yu Tsai
0 siblings, 0 replies; 49+ messages in thread
From: Chen-Yu Tsai @ 2021-08-30 16:03 UTC (permalink / raw)
To: Michael Riesch
Cc: netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, Sasha Levin
Hi,
On Mon, Aug 30, 2021 at 3:57 PM Michael Riesch
<michael.riesch@wolfvision.net> wrote:
>
> 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.
>
> 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 :-)
I hit this on an ROC-RK3399-PC first, then bisected it on a NanoPi M4V2.
They both should be easy to get from their respective vendors. AFAIK
all the RK3399 devices have pretty much the same setup for Ethernet.
BTW, Don't get the Nanopi in the M4V2 variant. Get the original M4, or
the M4B (but the WiFi on the M4B doesn't seem to work lately).
> 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.
My gut is telling me (without looking at the code) that maybe the GRF
access was not going through, and so the RGMII delays and stuff weren't
set properly, hence no traffic getting to/from the PHY. Otherwise there
were no error messages. I don't think I'll be able to squeeze out more
cycles to track down what actually went wrong though.
Regards
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 16:03 ` Chen-Yu Tsai
0 siblings, 0 replies; 49+ messages in thread
From: Chen-Yu Tsai @ 2021-08-30 16:03 UTC (permalink / raw)
To: Michael Riesch
Cc: netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin, Sasha Levin
Hi,
On Mon, Aug 30, 2021 at 3:57 PM Michael Riesch
<michael.riesch@wolfvision.net> wrote:
>
> 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.
>
> 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 :-)
I hit this on an ROC-RK3399-PC first, then bisected it on a NanoPi M4V2.
They both should be easy to get from their respective vendors. AFAIK
all the RK3399 devices have pretty much the same setup for Ethernet.
BTW, Don't get the Nanopi in the M4V2 variant. Get the original M4, or
the M4B (but the WiFi on the M4B doesn't seem to work lately).
> 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.
My gut is telling me (without looking at the code) that maybe the GRF
access was not going through, and so the RGMII delays and stuff weren't
set properly, hence no traffic getting to/from the PHY. Otherwise there
were no error messages. I don't think I'll be able to squeeze out more
cycles to track down what actually went wrong though.
Regards
ChenYu
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
2021-08-30 7:57 ` Michael Riesch
(?)
@ 2021-08-30 19:22 ` Sasha Levin
-1 siblings, 0 replies; 49+ messages in thread
From: Sasha Levin @ 2021-08-30 19:22 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin
On Mon, Aug 30, 2021 at 09:57:51AM +0200, Michael Riesch wrote:
>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.
>
>Cc: Sasha as this patch has just been applied to 5.13-stable.
I'll drop it for now, thanks for letting me know!
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 19:22 ` Sasha Levin
0 siblings, 0 replies; 49+ messages in thread
From: Sasha Levin @ 2021-08-30 19:22 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin
On Mon, Aug 30, 2021 at 09:57:51AM +0200, Michael Riesch wrote:
>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.
>
>Cc: Sasha as this patch has just been applied to 5.13-stable.
I'll drop it for now, thanks for letting me know!
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings
@ 2021-08-30 19:22 ` Sasha Levin
0 siblings, 0 replies; 49+ messages in thread
From: Sasha Levin @ 2021-08-30 19:22 UTC (permalink / raw)
To: Michael Riesch
Cc: wens, netdev, moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Rockchip SoC...,
linux-arm-kernel, linux-kernel, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S . Miller, Jakub Kicinski,
Maxime Coquelin
On Mon, Aug 30, 2021 at 09:57:51AM +0200, Michael Riesch wrote:
>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.
>
>Cc: Sasha as this patch has just been applied to 5.13-stable.
I'll drop it for now, thanks for letting me know!
--
Thanks,
Sasha
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 49+ messages in thread