[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YbsT2G5oMoe4baCJ@lunn.ch>
Date: Thu, 16 Dec 2021 11:24:24 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Francesco Dolcini <francesco.dolcini@...adex.com>
Cc: Joakim Zhang <qiangqing.zhang@....com>,
"Russell King (Oracle)" <linux@...linux.org.uk>,
Philippe Schenker <philippe.schenker@...adex.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Fabio Estevam <festevam@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up
On Thu, Dec 16, 2021 at 08:52:16AM +0100, Francesco Dolcini wrote:
> On Thu, Dec 16, 2021 at 04:52:39AM +0000, Joakim Zhang wrote:
> > As I can see, when system suspended, PHY is totally powered down,
> > since you disable the regulator. At this situation, if you
> > assert reset signal, you mean it will increase the power
> > consumption? PHY is totally powered down, why assert reset
> > signal still affect PHY?
> In general there are *other* use cases in which the PHY is powered in
> suspend. We should not create a regression there.
Yes, this is the sticking point. We can do what you want, but
potentially, the change affects others.
I think you need to move the regulator into phylib, so the PHY driver
can do the right thing. It is really the only entity which knows what
is the correct thing to do.
Andrew
Powered by blists - more mailing lists