[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <265dbcdb-6a56-0db8-73f9-7b643f5d95cf@gmail.com>
Date: Wed, 2 Sep 2020 14:38:32 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: netdev@...r.kernel.org
Cc: andrew@...n.ch, adam.rudzinski@....net.pl, m.felsch@...gutronix.de,
hkallweit1@...il.com, richard.leitner@...data.com,
zhengdejin5@...il.com, devicetree@...r.kernel.org,
kernel@...gutronix.de, kuba@...nel.org, robh+dt@...nel.org
Subject: Re: [RFC net-next 1/2] net: phy: Support enabling clocks prior to bus
probe
On 9/2/2020 2:33 PM, Florian Fainelli wrote:
> Some Ethernet PHYs may require that their clock, which typically drives
> their logic to respond to reads on the MDIO bus be enabled before
> issusing a MDIO bus scan.
>
> We have a chicken and egg problem though which is that we cannot enable
> a given Ethernet PHY's device clock until we have a phy_device instance
> create and called the driver's probe function. This will not happen
> unless we are successful in probing the PHY device, which requires its
> clock(s) to be turned on.
>
> For DT based systems we can solve this by using of_clk_get() which
> operates on a device_node reference, and make sure that all clocks
> associaed with the node are enabled prior to doing any reads towards the
> device. In order to avoid drivers having to know the a priori reference
> count of the resources, we drop them back to 0 right before calling
> ->probe() which is then supposed to manage the resources normally.
That last part is actually not in this patch series, I had it in an
intermediate version, but after chasing a clock enabling/disabling race
that appears specific to the platforms I am using, I eventually removed
it but left that part in the commit message.
--
Florian
Powered by blists - more mailing lists