[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce0bb513-045c-aa7f-6437-fdc77e9ecab1@gmail.com>
Date: Thu, 17 Sep 2020 09:19:03 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>
Cc: netdev@...r.kernel.org, opendmb@...il.com,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
"open list:BROADCOM ETHERNET PHY DRIVERS"
<bcm-kernel-feedback-list@...adcom.com>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: phy: bcm7xxx: request and manage GPHY
clock
On 9/17/2020 6:11 AM, Andrew Lunn wrote:
> On Wed, Sep 16, 2020 at 07:04:13PM -0700, Florian Fainelli wrote:
>> The internal Gigabit PHY on Broadcom STB chips has a digital clock which
>> drives its MDIO interface among other things, the driver now requests
>> and manage that clock during .probe() and .remove() accordingly.
>>
>> Because the PHY driver can be probed with the clocks turned off we need
>> to apply the dummy BMSR workaround during the driver probe function to
>> ensure subsequent MDIO read or write towards the PHY will succeed.
>
> Hi Florian
>
> Is it worth mentioning this in the DT binding? It is all pretty much
> standard lego pieces, but it has taken you a while to assemble them in
> the correct way. So giving hits to others who might want to uses these
> STB chips could be nice.
In some respect this does not really belong in the DT binding because we
are describing how Linux will be matching a given compatible string with
its driver, but it is certainly worth mentioning somewhere, like in the
PHY document.
Are you fine with the changes though?
--
Florian
Powered by blists - more mailing lists