[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8990f01-f6c8-4fec-b8b8-3d9fe82af51b@lunn.ch>
Date: Wed, 9 Aug 2023 15:40:48 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Wei Fang <wei.fang@....com>
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>
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.
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.
Andrew
Powered by blists - more mailing lists