netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, adam.rudzinski@arf.net.pl,
	m.felsch@pengutronix.de, hkallweit1@gmail.com,
	richard.leitner@skidata.com, zhengdejin5@gmail.com,
	devicetree@vger.kernel.org, kernel@pengutronix.de,
	kuba@kernel.org, robh+dt@kernel.org
Subject: Re: [RFC net-next 2/2] net: phy: bcm7xxx: request and manage GPHY clock
Date: Wed, 2 Sep 2020 19:13:30 -0700	[thread overview]
Message-ID: <7696bf30-9d7b-ecc9-041d-7d899dd07915@gmail.com> (raw)
In-Reply-To: <20200902222030.GJ3050651@lunn.ch>



On 9/2/2020 3:20 PM, Andrew Lunn wrote:
>> +	priv->clk = devm_clk_get_optional(&phydev->mdio.dev, "sw_gphy");
>> +	if (IS_ERR(priv->clk))
>> +		return PTR_ERR(priv->clk);
>> +
>> +	/* To get there, the mdiobus registration logic already enabled our
>> +	 * clock otherwise we would not have probed this device since we would
>> +	 * not be able to read its ID. To avoid artificially bumping up the
>> +	 * clock reference count, only do the clock enable from a phy_remove ->
>> +	 * phy_probe path (driver unbind, then rebind).
>> +	 */
>> +	if (!__clk_is_enabled(priv->clk))
>> +		ret = clk_prepare_enable(priv->clk);
> 
> This i don't get. The clock subsystem does reference counting. So what
> i would expect to happen is that during scanning of the bus, phylib
> enables the clock and keeps it enabled until after probe. To keep
> things balanced, phylib would disable the clock after probe.

That would be fine, although it assumes that the individual PHY drivers 
have obtained the clocks and called clk_prepare_enable(), which is a 
fair assumption I suppose.

> 
> If the driver wants the clock enabled all the time, it can enable it
> in the probe method. The common clock framework will then have two
> reference counts for the clock, so that when the probe exists, and
> phylib disables the clock, the CCF keeps the clock ticking. The PHY
> driver can then disable the clock in .remove.

But then the lowest count you will have is 1, which will lead to the 
clock being left on despite having unbound the PHY driver from the 
device (->remove was called). This does not allow saving any power 
unfortunately.

> 
> There are some PHYs which will enumerate with the clock disabled. They
> only need it ticking for packet transfer. Such PHY drivers can enable
> the clock only when needed in order to save some power when the
> interface is administratively down.

Then the best approach would be for the OF scanning code to enable all 
clocks reference by the Ethernet PHY node (like it does in the proposed 
patch), since there is no knowledge of which clock is necessary and all 
must be assumed to be critical for MDIO bus scanning. Right before 
drv->probe() we drop all resources reference counts, and from there on 
->probe() is assumed to manage the necessary clocks.

It looks like another solution may be to use the assigned-clocks 
property which will take care of assigning clock references to devices 
and having those applied as soon as the clock provider is available.
-- 
Florian

  reply	other threads:[~2020-09-03  2:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 21:33 [RFC net-next 0/2] net: phy: Support enabling clocks prior to bus probe Florian Fainelli
2020-09-02 21:33 ` [RFC net-next 1/2] " Florian Fainelli
2020-09-02 21:38   ` Florian Fainelli
2020-09-02 22:11   ` Andrew Lunn
2020-09-02 21:33 ` [RFC net-next 2/2] net: phy: bcm7xxx: request and manage GPHY clock Florian Fainelli
2020-09-02 22:20   ` Andrew Lunn
2020-09-03  2:13     ` Florian Fainelli [this message]
2020-09-03  6:00       ` Adam Rudziński
2020-09-03 15:21         ` Florian Fainelli
2020-09-03 17:13           ` Adam Rudziński
2020-09-03 17:17             ` Florian Fainelli
2020-09-03 19:21               ` Adam Rudziński
2020-09-03 19:35                 ` Florian Fainelli
2020-09-03 20:09                   ` Adam Rudziński
2020-09-03 20:17                     ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7696bf30-9d7b-ecc9-041d-7d899dd07915@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=adam.rudzinski@arf.net.pl \
    --cc=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=richard.leitner@skidata.com \
    --cc=robh+dt@kernel.org \
    --cc=zhengdejin5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).