RE: [PATCH V1 net-next 0/3] net: stmmac: implement clocks

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: 2021年2月24日 9:55
To: Joakim Zhang <redacted>
Cc: peppe.cavallaro@st.com; alexandre.torgue@st.com;
joabreu@synopsys.com; davem@davemloft.net; netdev@vger.kernel.org;
dl-linux-imx [off-list ref]
Subject: Re: [PATCH V1 net-next 0/3] net: stmmac: implement clocks

On Wed, 24 Feb 2021 01:45:40 +0000 Joakim Zhang wrote:

quoted

quoted

I'm not an expert on this stuff, but is there a reason you're not
integrating this functionality with the power management subsystem?

Do you mean that implement runtime power management for driver? If
yes, I think that is another feature, we can support later.

Runtime is a strong word, IIUC you can just implement the PM callbacks, and
always resume in .open and always suspend in .close. Pretty much what you
have already.

quoted

quoted

I don't think it'd change the functionality, but it'd feel more
idiomatic to fit in the standard Linux framework.

Yes, there is no functionality change, this patch set just adds clocks

management.

quoted

In the driver now, we manage clocks at two point side:
1. enable clocks when probe driver, disable clocks when remove driver.
2. disable clocks when system suspend, enable clocks when system resume

back.

quoted

This should not be enough, such as, even we close the NIC, the clocks still

enabled. So this patch improve below:

quoted

Keep clocks disabled after driver probe, enable clocks when NIC up, and then

disable clocks when NIC down.

quoted

The aim is to enable clocks when it needs, others keep clocks disabled.

Understood. Please double check ethtool callbacks work fine. People often
forget about those when disabling clocks in .close.

Hi Jakub,

If NIC is open then clocks are always enabled, so all ethtool callbacks should be okay.

Could you point me which ethtool callbacks could be invoked when NIC is closed? I'm not very familiar with ethtool use case. Thanks.

Best Regards,
Joakim Zhang