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

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



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 ?

--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,12 +319,19 @@
 
 	init_waitqueue_head(&dev->smi_busy_wait);
 
+	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]))
+			if (!IS_ERR(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk))))
 			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);
 	if (dev->err_interrupt > 0 &&

Reply to: