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 20:00:42 +0100
From:   Mason <slash.tmp@...e.fr>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>
Subject: Re: Waiting for the PHY to complete auto-negotiation

On 06/12/2017 19:26, Andrew Lunn wrote:

> On 06/12/2017 19:03, Mason wrote:
>
>> The problem with this is the following mind-boggling quirk of
>> the hardware: once RX DMA is enabled, there is no supported
>> way to disable it! Thus, I'm trying to find a clean way to set
>> the control flow parameter BEFORE enabling the MAC.
> 
> There is no solution. I can pull the cable out, and plug it into a
> different computer. The first could use flow control, the second not.
> 
> If you cannot disable RX DMA, you should probably disable unloading of
> the module. Also kexec.

It is not possible to /selectively/ disable RX DMA, but after a reset,
DMA is disabled. So the solution I propose is this:

When we detect link down, we put the chip in reset, so that we will
repeat initialization when the link comes back up.

Mans has been reluctant to adopt this approach, but this is what
I implemented in my forked version. I'm trying to push my changes
upstream, to minimize the differences.

Regards.