From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1FFAC433E1 for ; Wed, 24 Jun 2020 16:57:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9AED820738 for ; Wed, 24 Jun 2020 16:57:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="ZgOTBUbP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405239AbgFXQ5Y (ORCPT ); Wed, 24 Jun 2020 12:57:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404124AbgFXQ5Y (ORCPT ); Wed, 24 Jun 2020 12:57:24 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC4C6C061573; Wed, 24 Jun 2020 09:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L0BSl9Rz5P8GUkSvL7sI0fAZe5Hrhoqy7/0x3FiFW2Y=; b=ZgOTBUbPjta9cXrzFnnIAnab4 Dcm9pDc0Ejlq5vVTWRjyevo27fV7XGPaj06Z05BDeZRcenj/FWeWJut7lz1cg2jUDgZnf8MvLUdYM P+biZdJlriNMVb3RtYtqgt1B8ql+d+lgDKGM3OOj3i9TDJ3SIgG6/R4Rg8amZWPYlQq6fIY/e5RIH 39Hwa7ZromkrO1urRg88NKb0eQZfm104fYt7Wvq+tEViZGuPwfd3FP5JIhp40PZgkNtwizse0M5zD FpIcwGpyg+93AxBkRp7ezqMw7JKjDwcBW5nSjVKmWjVeWpHEex9JZNfJ7NiOhJ6zOdVKpd7uk/VBN B1UNRAHEg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:59222) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo8i8-0003ML-Ug; Wed, 24 Jun 2020 17:57:20 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jo8i7-00027d-Ep; Wed, 24 Jun 2020 17:57:19 +0100 Date: Wed, 24 Jun 2020 17:57:19 +0100 From: Russell King - ARM Linux admin To: Bartosz Golaszewski Cc: Bartosz Golaszewski , Andrew Lunn , Alexandre Belloni , devicetree , Vladimir Oltean , Linux Kernel Mailing List , Fabien Parent , Iyappan Subramanian , Quan Nguyen , Frank Rowand , Florian Fainelli , Jakub Kicinski , Vivien Didelot , Tom Lendacky , Andrew Perepech , Stephane Le Provost , Keyur Chudgar , Jassi Brar , Claudiu Manoil , Mark Brown , "moderated list:ARM/Mediatek SoC..." , Matthias Brugger , Linux ARM , netdev , Ilias Apalodimas , Liam Girdwood , Rob Herring , Philipp Zabel , Pedro Tsai , "David S . Miller" , Heiner Kallweit Subject: Re: [PATCH 14/15] net: phy: add PHY regulator support Message-ID: <20200624165719.GB1551@shell.armlinux.org.uk> References: <20200622093744.13685-1-brgl@bgdev.pl> <20200622093744.13685-15-brgl@bgdev.pl> <20200622132921.GI1551@shell.armlinux.org.uk> <20200623094252.GS1551@shell.armlinux.org.uk> <20200623095646.GT1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jun 23, 2020 at 06:27:06PM +0200, Bartosz Golaszewski wrote: > wt., 23 cze 2020 o 11:56 Russell King - ARM Linux admin > napisał(a): > > > > On Tue, Jun 23, 2020 at 11:46:15AM +0200, Bartosz Golaszewski wrote: > > > wt., 23 cze 2020 o 11:43 Russell King - ARM Linux admin > > > napisał(a): > > > > > > > > On Tue, Jun 23, 2020 at 11:41:11AM +0200, Bartosz Golaszewski wrote: > > > > > pon., 22 cze 2020 o 15:29 Russell King - ARM Linux admin > > > > > napisał(a): > > > > > > > > > > > > > > > > [snip!] > > > > > > > > > > > > > > > > > This is likely to cause issues for some PHY drivers. Note that we have > > > > > > some PHY drivers which register a temperature sensor in the probe > > > > > > function, which means they can be accessed independently of the lifetime > > > > > > of the PHY bound to the network driver (which may only be while the > > > > > > network device is "up".) We certainly do not want hwmon failing just > > > > > > because the network device is down. > > > > > > > > > > > > That's kind of worked around for the reset stuff, because there are two > > > > > > layers to that: the mdio device layer reset support which knows nothing > > > > > > of the PHY binding state to the network driver, and the phylib reset > > > > > > support, but it is not nice. > > > > > > > > > > > > > > > > Regulators are reference counted so if the hwmon driver enables it > > > > > using mdio_device_power_on() it will stay on even after the PHY driver > > > > > calls phy_device_power_off(), right? Am I missing something? > > > > > > > > If that is true, you will need to audit the PHY drivers to add that. > > > > > > > > > > This change doesn't have any effect on devices which don't have a > > > regulator assigned in DT though. The one I'm adding in the last patch > > > is the first to use this. > > > > It's quality of implementation. > > > > Should we wait for someone else to make use of the new regulator > > support that has been added with a PHY that uses hwmon, and they > > don't realise that it breaks hwmon on it, and several kernel versions > > go by without it being noticed. It will only be a noticable issue > > when the associated network device is down, and that network device > > driver detaches from the PHY, so _is_ likely not to be noticed. > > > > Or should we do a small amount of work now to properly implement > > regulator support, which includes a trivial grep for "hwmon" amongst > > the PHY drivers, and add the necessary call to avoid the regulator > > being shut off. > > > > I'm not sure what the correct approach is here. Provide some helper > that, when called, would increase the regulator's reference count even > more to keep it enabled from the moment hwmon is registered to when > the driver is detached? I think a PHY driver needs the utility to control this. We need to be careful here with naming, because phylib is not the only code in the kernel that uses the phy_ prefix. If we had runtime PM support for PHYs, with regulator support hooked into runtime PM, then we already have standard interfaces that drivers can use to control whether the device gets powered down. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!