From patchwork Thu Mar 16 07:46:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roger Quadros X-Patchwork-Id: 739744 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3vkPdC5p0Fz9s03 for ; Thu, 16 Mar 2017 21:21:03 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="xOHeJlx0"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751612AbdCPKUx (ORCPT ); Thu, 16 Mar 2017 06:20:53 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:60741 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751487AbdCPKUv (ORCPT ); Thu, 16 Mar 2017 06:20:51 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id v2G7kwxO016474; Thu, 16 Mar 2017 02:46:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1489650418; bh=nE92w92K5Lz4PikTsdeWd4BcYax0ddLlFVVgM3y7Qwg=; h=Subject:To:References:CC:From:Date:In-Reply-To; b=xOHeJlx0Pzaze3QtBnYTDy1xC2UFQ/fTpTl2rq15GFl+Ah/Rxnpr3b7V18kDhLmNC jFXMa1rRSoROZvv+gHhVzWUTEeaULPr8KzjCh3NuZcon7A3QKGnbqCUJATmpuIFqKf N2nBAY0RXu6qGAJqeUHVipwXVJuDuA/zuOHZUasQ= Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id v2G7kqMZ015232; Thu, 16 Mar 2017 02:46:52 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.294.0; Thu, 16 Mar 2017 02:46:52 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id v2G7ko1g013780; Thu, 16 Mar 2017 02:46:51 -0500 Subject: Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for PHYs with interrupts To: Andrew Lunn References: <1489585887-8683-1-git-send-email-rogerq@ti.com> <20170315140811.GD21021@lunn.ch> <6ec42ad7-0be3-f6c5-2ded-27bf3adbab23@ti.com> <20170315154912.GE21021@lunn.ch> CC: , , , , From: Roger Quadros Message-ID: <6d3f2d3c-69e0-43a4-9862-126a7c173934@ti.com> Date: Thu, 16 Mar 2017 09:46:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170315154912.GE21021@lunn.ch> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 15/03/17 17:49, Andrew Lunn wrote: > On Wed, Mar 15, 2017 at 05:00:08PM +0200, Roger Quadros wrote: >> Andrew, >> >> On 15/03/17 16:08, Andrew Lunn wrote: >>> On Wed, Mar 15, 2017 at 03:51:27PM +0200, Roger Quadros wrote: >>>> Since commit 3c293f4e08b5 ("net: phy: Trigger state machine on state change and not polling.") >>>> phy_suspend() doesn't get called as part of phy_stop() for PHYs using >>>> interrupts because the phy state machine is never triggered after a phy_stop(). >>>> >>>> Explicitly trigger the PHY state machine so that it can >>>> see the new PHY state (HALTED) and suspend the PHY. >>>> >>>> Signed-off-by: Roger Quadros >>> >>> Hi Roger >>> >>> This seems sensible. It mirrors what phy_start() does. >>> >>> Reviewed-by: Andrew Lunn >> >> The reason for this being an RFC was the following comment just before >> where I add the phy_trigger_machine() >> >> /* Cannot call flush_scheduled_work() here as desired because >> * of rtnl_lock(), but PHY_HALTED shall guarantee phy_change() >> * will not reenable interrupts. >> */ >> >> Is this comment still applicable? If yes, is it OK to call >> phy_trigger_machine() there? > > Humm, good question. > > My _guess_ would be, calling it with sync=True could > deadlock. sync=False is probably safe. But lets see what Florian says. I agree that we should use phy_trigger_machine() with sync=False. > >> >>> >>> It does however lead to a follow up question. Are there other places >>> phydev->state is changed and it is missing a phy_trigger_machine()? >>> >> >> One other place I think we should add phy_trigger_machine() is phy_start_aneg(). > > Humm, that might get us into a tight loop. > > phy_start_aneg() kicks the phy driver to start autoneg and sets > phydev->state = PHY_AN. > > phy_trigger_machine() triggers the state machine immediately. > > In state PHY_AN, we check if aneg is done. If not, it sets needs_aneg > = true. At the end of the state machine, this then calls > phy_start_aneg(), and it all starts again. > > We are missing the 1s delay we have with polling. So for > phy_start_aneg(), we might need a phy_delayed_trigger_machine(), which > waits a second before doing anything? I think that should do the trick. How about this? diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 8fef03b..162061c 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -630,6 +630,10 @@ int phy_start_aneg(struct phy_device *phydev) out_unlock: mutex_unlock(&phydev->lock); + + if (!err) + queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, HZ); + return err; } EXPORT_SYMBOL(phy_start_aneg);