From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: Waiting for the PHY to complete auto-negotiation Date: Wed, 6 Dec 2017 15:00:07 -0800 Message-ID: <31ba2a2d-99f4-64d7-b9e3-057cdaa1618c@gmail.com> References: <20171206165903.GM27063@lunn.ch> <20171206182633.GP27063@lunn.ch> <20171206190728.GC28774@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: netdev , David Miller To: Mason , Andrew Lunn Return-path: Received: from mail-ot0-f173.google.com ([74.125.82.173]:46437 "EHLO mail-ot0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbdLFXAK (ORCPT ); Wed, 6 Dec 2017 18:00:10 -0500 Received: by mail-ot0-f173.google.com with SMTP id j2so4816992ota.13 for ; Wed, 06 Dec 2017 15:00:10 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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