netdev - Re: [BUG] mv88e6xxx: tx regression in v5.3

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: <87bls5sjq1.fsf@tarshish>
Date:   Wed, 18 Dec 2019 18:04:54 +0200
From:   Baruch Siach <baruch@...s.co.il>
To:     Marek Behún <marek.behun@....cz>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        netdev@...r.kernel.org,
        Denis Odintsov <d.odintsov@...viangames.com>,
        Hubert Feurstein <h.feurstein@...il.com>
Subject: Re: [BUG] mv88e6xxx: tx regression in v5.3

Hi Marek,

On Wed, Dec 18 2019, Marek Behún wrote:
> On Sun, 15 Dec 2019 12:13:25 +0200
> Baruch Siach <baruch@...s.co.il> wrote:
>
>> Thanks. That is enough to fix the phylink issue triggered by commit
>> 7fb5a711545 ("net: dsa: mv88e6xxx: drop adjust_link to enabled
>> phylink").
>> 
>> The Clearfog GT-8K DT has also this on the cpu side:
>> 
>> &cp1_eth2 {
>>         status = "okay";
>>         phy-mode = "2500base-x";
>>         phys = <&cp1_comphy5 2>;
>>         fixed-link {
>>                 speed = <2500>;
>>                 full-duplex;
>>         };
>> };
>> 
>> Should I drop fixed-link here as well?
>
> I would think yes. phy-mode = 2500base-x should already force 2500mbps,
> the fixed-link should be irrelevant. Whether this is truly the case I
> do not know, but on Turris Mox I do not use fixed-link with these.

OK. I'll test that.

>> The call to mv88e6341_port_set_cmode() introduced in commit
>> 7a3007d22e8 ("net: dsa: mv88e6xxx: fully support SERDES on Topaz
>> family") still breaks port 5 (cpu) configuration. When called, its
>> mode parameter is set to PHY_INTERFACE_MODE_2500BASEX (19).
>> 
>> Any idea?
>
> I shall look into this. On Turris Mox this works, so I will have to do
> some experiments.

I have made some progress on this issue. See my other messages on this
thread. My latest suggestion is here:

  https://lore.kernel.org/netdev/20191217182643.augknhx57pafnelv@sapphire.tkos.co.il/

I now think that the force_cmode field is not necessary. We should just
add a 'force' parameter to mv88e6xxx_port_set_cmode(), and set it true
in mv88e6341_port_set_cmode().

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@...s.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -