[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<AM5PR04MB313940F68C4817BEEC2377E78813A@AM5PR04MB3139.eurprd04.prod.outlook.com>
Date: Thu, 10 Aug 2023 03:38:16 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Oleksij Rempel <o.rempel@...gutronix.de>, Marek Vasut <marex@...x.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Heiner Kallweit
<hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>, Oleksij Rempel
<linux@...pel-privat.de>, Paolo Abeni <pabeni@...hat.com>, Russell King
<linux@...linux.org.uk>, Clark Wang <xiaoning.wang@....com>
Subject: RE: [PATCH] net: phy: at803x: Improve hibernation support on start up
> > > Hm.. how about officially defining this PHY as the clock provider
> > > and disable PHY automatic hibernation as long as clock is acquired?
> > >
> > Sorry, I don't know much about the clock provider/consumer, but I
> > think there will be more changes if we use clock provider/consume
> mechanism.
>
> Less changes is not always best. What happens when a different PHY is used?
> By having a clock provider in the PHY, you are defining a clear API that any
> PHY needs to provide to work with this MAC.
>
Yes, as Russell mentioned the issue of suspend/resume, that i.MX platform uses
the RTL8211 PHY. But now I don't have a clear idea to solve this issue on dwmac
IP, the design of this IP is so different.
Cc to Clark to aware of this issue on dwmac IP.
> As Russell has point out, this is not the first time we have run into this
> problem. So far, it seems everybody has tried to solve it for just their system.
> So maybe now we should look at the whole picture and put in place a
> generic solution which can be made to work for any PHY.
Powered by blists - more mailing lists