[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel quirks on QNAP TS-109 (Marvell orion)



Matthieu CERDA <kegeruneku+debianarm@ironflake.org> writes:

[ Adding bug #908712 in Cc: ]

> Hello again !
>
> Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :
>> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>>> Martin Michlmayr <tbm@cyrius.com> writes:
>>>> * Matthieu CERDA <kegeruneku+debianarm@ironflake.org> [2019-07-26 00:17]:
>>>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>>>>     does nothing, and the status led stays red/green after system has
>>>>>     booted.
>>>> There are different potential causes for this but I think I've seen
>>>> this before myself and this particular issue hasn't been reported.
>> I'll open a bug report on the Debian package to discuss the issue there.
> Done: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=qcontrol
>>>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>>>     not work as well, and more annoyingly, no Ethernet interface gets
>>>>>     initialized. dmesg shows a kernel oops. (copy attached)
>>>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
>> Yep, I looks like the exact same issue. I'll be happy to help if I can,
>> at least by testing the fix that Arnaud proposed below :)
>>> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
>>> devices without device tree and I'm curious to see how the kernel handle
>>> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
>>> of_clk_get() is coded like this:
>>> (...)
>>>
>>> Arnaud.
>> All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
>> the patch.
>>
>> I will also try building a linux master-based kernel, to test if
>> https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
>> solves the issue.
>>
>> Thank you for the help to both of you :) (and also, thank you Martin for
>> the highly detailed website and instructions about QNAP devices)
>
> Well, good news. the fix Arnaud proposed seems to work! (cf patch joined
> to this mail)
>
> ---8<---
> [   35.281494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> [   35.348374] libphy: PHY orion-mdio-mii:08 not found
> [   35.696124] libphy: PHY orion-mdio-mii:08 not found
> (...)
> [   35.780513] libphy: orion_mdio_bus: probed
> (...)
> [   35.998946] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
> address 00:08:9b:ac:e2:f4
> (...)
> [   46.105299] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
> [   49.537051] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
> Mb/s, full duplex, flow control enabled
> ---8<---
>
> I'll send a copy to Andrew, if that's okay with you Arnaud ?

As promised, please fix the updated patch. Please note that there are 2
patches, one for linux HEAD and one for 4.19. I had to make two patches
as there are changes in HEAD not present in 4.19. btw, your version of
the 4.19 patch is possibly broken with OF platforms, that's why your
patches and mine are different. For your case on orion5x, it should not
make any difference.


Arnaud
drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in 
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Index: linux-next/drivers/net/ethernet/marvell/mvmdio.c
===================================================================
--- linux-next.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ linux-next/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,20 +319,33 @@ static int orion_mdio_probe(struct platf
 
 	init_waitqueue_head(&dev->smi_busy_wait);
 
-	for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
-		dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
-		if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+	if (pdev->dev.of_node) {
+		for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+			dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+			if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+				ret = -EPROBE_DEFER;
+				goto out_clk;
+			}
+			if (IS_ERR(dev->clk[i]))
+				break;
+			clk_prepare_enable(dev->clk[i]);
+		}
+
+		if (!IS_ERR(of_clk_get(pdev->dev.of_node,
+				       ARRAY_SIZE(dev->clk))))
+			dev_warn(&pdev->dev,
+				 "unsupported number of clocks, limiting to the first "
+				 __stringify(ARRAY_SIZE(dev->clk)) "\n");
+	} else {
+		dev->clk[0] = clk_get(&pdev->dev, NULL);
+		if (PTR_ERR(dev->clk[0]) == -EPROBE_DEFER) {
 			ret = -EPROBE_DEFER;
 			goto out_clk;
 		}
-		if (IS_ERR(dev->clk[i]))
-			break;
-		clk_prepare_enable(dev->clk[i]);
+		if (!IS_ERR(dev->clk[0]))
+			clk_prepare_enable(dev->clk[0]);
 	}
 
-	if (!IS_ERR(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk))))
-		dev_warn(&pdev->dev, "unsupported number of clocks, limiting to the first "
-			 __stringify(ARRAY_SIZE(dev->clk)) "\n");
 
 	dev->err_interrupt = platform_get_irq(pdev, 0);
 	if (dev->err_interrupt > 0 &&
[PATCH 4.19] drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in 
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>

Index: 4.19/drivers/net/ethernet/marvell/mvmdio.c
===================================================================
--- 4.19.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ 4.19/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,11 +319,18 @@ static int orion_mdio_probe(struct platf
 
 	init_waitqueue_head(&dev->smi_busy_wait);
 
-	for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
-		dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
-		if (IS_ERR(dev->clk[i]))
-			break;
-		clk_prepare_enable(dev->clk[i]);
+	if (pdev->dev.of_node) {
+		for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+			dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+			if (IS_ERR(dev->clk[i]))
+				break;
+			clk_prepare_enable(dev->clk[i]);
+		}
+	} else {
+		dev->clk[0] = clk_get(&pdev->dev, NULL);
+		if (!IS_ERR(dev->clk[0]))
+			clk_prepare_enable(dev->clk[0]);
+
 	}
 
 	dev->err_interrupt = platform_get_irq(pdev, 0);

Reply to: