netdev - Re: i.MX6S/DL and QCA8334 switch using DSA driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180515160824.GJ27867@lunn.ch>
Date:   Tue, 15 May 2018 18:08:24 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michal Vokáč <vokac.m@...il.com>
Cc:     netdev@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not
 working

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.

> 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

	Andrew