On 05/15/2018 09:08 AM, Andrew Lunn wrote: > On Tue, May 15, 2018 at 04:25:49PM +0200, Michal Vokáč wrote: >> On 10.5.2018 16:29, Andrew Lunn wrote: >>> I would probably add code to dump all the qca8k registers. Compare the >>> values for your working setup and your non-working setup. Hopefully >>> they are not too different, and you can quickly get to the bits which >>> matter. >> >> Perfect! Thanks to your suggestion I did that again and much more carefully. >> After some tedious comparison I think I finally found the problem. >> >> The RGMII works only if I write 0x7e to the PORT0_STATUS (0x7c) register >> from setup. Then I found out that this setup is also described in >> Qualcomm QCA8334 Q&A document. When I do that, everything work as expected. > > Great. > >> >> Both PORT0 and PORT6 may be configured as xGMII, xMII and SerDes and their >> functions may be exchanged. In all cases the port status register should be >> set to 0x7X where X depends on the link speed setup. >> >> Translated into register bits this means: >> - clear BIT(12) - disable MAC flow control auto-negotiation (set by default) >> - clear BIT(7) - disable MAC Tx flow control in half-duplex (set by >> default) >> - set BIT(6) - use full-duplex >> - set BIT(5,4) - enable Rx/Tx flow control >> - set BIT(3) - enable Rx MAC - this one is tricky, the bit is described >> as >> R/O in datasheet but it does not work when not set. >> - set BIT(2) - enable Tx MAC >> - set BIT(1,0) - set speed to 1000Mb > > The Marvell devices have something similar. What we do there is for > the cpu port is to always set the port up, full duplex, and the > fastest speed it supports. This covers 95% of boards. We have a few > boards where the SoC on the other end can only do 100Mbps, not > 1G. Then we use a fixed-phy. > >> I wonder whether there are some users of this driver and what may be their >> setup that they are not affected by that? > > It could be the bootloader is setting up the CPU port? I don't really > like that.
This is unfortunately not uncommon... > >> I would like to have confirmed that I understand it correctly and that >> the problem is really in the driver not handling fixed-link. > > I would actually skip fixed-link, if you don't need it. Just hardwire > the CPU port, like the Marvell driver does: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/mv88e6xxx/chip.c#L1780 > > I would do it here: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/qca8k.c#L518 Agreed with Andrew here, though if you can implement fixed-link, this should be more future proof. As far as people using this driver, John submitted it, but we have not see many fixes/enhancements, so I am not clear who is actually using it these days... glad you are though! -- Florian