From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up Date: Thu, 12 Jul 2018 12:53:01 -0700 Message-ID: <65c83e10-e819-85d7-7c4e-db74098345fd@gmail.com> References: <0d031081-4a7f-ddde-87c0-2c1c6be543c3@gmail.com> <407ed2cd-db27-f179-8b98-0d1e61513e07@gmail.com> <20180711205518.GJ21430@lunn.ch> <7dfcb4d5-2a0c-9244-53e4-564014b16b58@gmail.com> <28ea392b-6d3a-0efe-a0ed-ebe82fe14099@gmail.com> <0354bc0f-4bac-9715-e183-1a74b9cc6f1b@gmail.com> <20180712190945.GC10740@lunn.ch> <8857b2f4-9aab-fb90-ecad-7b27a6fa991c@gmail.com> <1ddf575d-b894-e20c-b9af-016021eaf33e@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: David Miller , "netdev@vger.kernel.org" To: Heiner Kallweit , Andrew Lunn Return-path: Received: from mail-wr1-f68.google.com ([209.85.221.68]:33898 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732204AbeGLUEI (ORCPT ); Thu, 12 Jul 2018 16:04:08 -0400 Received: by mail-wr1-f68.google.com with SMTP id c13-v6so22823048wrt.1 for ; Thu, 12 Jul 2018 12:53:05 -0700 (PDT) In-Reply-To: <1ddf575d-b894-e20c-b9af-016021eaf33e@gmail.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 07/12/2018 12:25 PM, Florian Fainelli wrote: > > > On 07/12/2018 12:10 PM, Heiner Kallweit wrote: >> On 12.07.2018 21:09, Andrew Lunn wrote: >>>> Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation >>>> to finish. Therefore, even though I share Andrew's concerns, there seem >>>> to be chips where it's safe to not wait for the renegotiation to finish >>>> (e.g. because device is in PCI D3 already and can't generate an interrupt). >>>> Having said that I'd keep the sync parameter for phy_speed_down so that >>>> the driver can decide. >>> >>> Hi Heiner >>> >>> Please put a big fat comment about the dangers of sync=false in the >>> function header. We want people to known it is dangerous by default, >>> and should only be used in special conditions, when it is known to be >>> safe. >>> Andrew >>> >> OK .. > > What part do you find dangerous? Magic Packets are UDP packets and they > are not routed (unless specifically taken care of) so there is already > some "lossy" behavior involved with waking-up an Ethernet MAC, I don't > think that is too bad to retry several times until the link comes up. I see the concern with the comment from v2, and indeed you could get an interrupt signaling the PHY auto-negotiated the link before or at the time we are suspending causing potentially an early wake-up. Not that this should be a problem though since there is usually a point of not return past which you can't do early wake-up anyway. -- Florian