Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit : > Martin Michlmayr <[email protected]> writes: >> * Matthieu CERDA <[email protected]> [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. >>> * 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: > > struct clk *of_clk_get(struct device_node *np, int index) > { > return __of_clk_get(np, index, np->full_name, NULL); > } > > afair in systems without DT, of_node is null, np->full_name has high > chances to crash. Again, as noted by the bug, it's likely coming from > 96cb4342382290c935d933a08feb57d6d0183071 which is replacing > the devm_clk_get() call to of_clk_get(). > > Might worth trying to build a kernel with code looking like > (not even compile tested): > > 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(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk)))) > ... > > else { > dev->clk[0] = clk_get(&pdev->dev, NULL); > if (!IS_ERR(dev->clk[0])) > clk_prepare_enable(dev->clk[0]); > } > > > 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)
