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: <21fc20c7-77d2-cba0-8f58-6bacb41f0970@gmail.com>
Date:   Tue, 15 May 2018 09:17:00 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Michal Vokáč <vokac.m@...il.com>
Cc:     netdev@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not
 working

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