[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fdf1b674-8e47-43ab-9608-e25dde9f3f20@lunn.ch>
Date: Tue, 10 Dec 2024 04:11:09 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
Bryan Whitehead <bryan.whitehead@...rochip.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Marcin Wojtas <marcin.s.wojtas@...il.com>, netdev@...r.kernel.org,
Paolo Abeni <pabeni@...hat.com>, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next 03/10] net: phy: add configuration of rx clock
stop mode
> @@ -2073,6 +2073,7 @@ int phy_unregister_fixup_for_id(const char *bus_id);
> int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask);
>
> int phy_eee_tx_clock_stop_capable(struct phy_device *phydev);
> +int phy_eee_rx_clock_stop(struct phy_device *phydev, bool clk_stop_enable);
Hi Russell
Do you have patches to MAC drivers using phylib, not phylink, using
these two new calls?
We see phylib users get EEE wrong. I'm worried phylib users are going
to try to use these new API methods and make an even bigger mess. If
we think these should only be used by phylink, maybe they should be
put into a header in drivers/net/phy to stop MAC drivers using them?
Andrew
Powered by blists - more mailing lists