netdev - Re: Waiting for the PHY to complete auto-negotiation

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]

Date:   Wed, 6 Dec 2017 15:00:07 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Mason <slash.tmp@...e.fr>, Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: Re: Waiting for the PHY to complete auto-negotiation



On 12/06/2017 11:25 AM, Mason wrote:
> On 06/12/2017 20:07, Andrew Lunn wrote:
> 
>> By chip, you mean the Ethernet controller? Not the whole SoC?
> 
> Doh! Yes. Let me rephrase.
> 
> When we detect link down, we put the ethernet HW block in reset,
> and repeat initialization when the link comes back up.
> 
> Hmmm, however, at the moment, I only reset on an administrative
> (user-requested) link down, i.e. through ndo_stop. I would probably
> have to handle cable unplug/replug events as well.
> 
> Or just consider the quirk to make flow control too complicated
> to implement correctly...

I suppose your procedure is fine, but don't you have a better way to
resolve that by trying to place a special RX DMA ring entry that allows
your RX DMA not to be entirely stopped, but intentionally looped through
a buffer that you control? As long as you can stop the Ethernet MAC RX,
working with such a limitation is probably fine, but this really sounds
like a huge pain in the butt and a major HW flaw.
-- 
Florian