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:25:50 -0700 Message-ID: <1ddf575d-b894-e20c-b9af-016021eaf33e@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> 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-f65.google.com ([209.85.221.65]:41969 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726443AbeGLTgu (ORCPT ); Thu, 12 Jul 2018 15:36:50 -0400 Received: by mail-wr1-f65.google.com with SMTP id j5-v6so16274250wrr.8 for ; Thu, 12 Jul 2018 12:25:53 -0700 (PDT) In-Reply-To: <8857b2f4-9aab-fb90-ecad-7b27a6fa991c@gmail.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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. -- Florian