From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH net-next 0/2] net: phy: improve PM handling of PHY/MDIO Date: Mon, 4 Jun 2018 15:06:12 -0700 Message-ID: <63d113bd-be64-beeb-114a-48081e920837@gmail.com> References: <20180604214829.GA14873@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: David Miller , "netdev@vger.kernel.org" To: Andrew Lunn , Heiner Kallweit Return-path: Received: from mail-qt0-f193.google.com ([209.85.216.193]:37998 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751509AbeFDWGW (ORCPT ); Mon, 4 Jun 2018 18:06:22 -0400 Received: by mail-qt0-f193.google.com with SMTP id x34-v6so316402qtk.5 for ; Mon, 04 Jun 2018 15:06:21 -0700 (PDT) In-Reply-To: <20180604214829.GA14873@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 06/04/2018 02:48 PM, Andrew Lunn wrote: > On Sat, Jun 02, 2018 at 10:33:36PM +0200, Heiner Kallweit wrote: >> Current implementation of MDIO bus PM ops doesn't actually implement >> bus-specific PM ops but just calls PM ops defined on a device level >> what doesn't seem to be fully in line with the core PM model. >> >> When looking e.g. at __device_suspend() the PM core looks for PM ops >> of a device in a specific order: >> 1. device PM domain >> 2. device type >> 3. device class >> 4. device bus >> >> I think it has good reason that there's no PM ops on device level. >> The situation can be improved by modeling PHY's as device type of >> a MDIO device. If for some other type of MDIO device PM ops are >> needed, it could be modeled as struct device_type as well. > > Hi Heiner > > I tested that the files in /sys/class/bus/mdio/devices/* are still > there. And also not there for MDIO devices which are not PHYs, > e.g. Ethernet switches. > > I don't have any boards which do PM. So i cannot test suspend/resume. > > I also took a look at drivers/net/dsa/qca8k.c. This is an MDIO switch > which has PM operations. I don't think this change will break it. I don't think so, but I will give it a spin on a board that has system wide suspend/resume support. Might take a few hours. > > I would prefer a bit more testing, but i guess that is what -rc > kernels are for. > > Tested-by: Andrew Lunn > > Andrew > -- Florian