[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200907073723.oz6cvgohy37by4nk@pengutronix.de>
Date: Mon, 7 Sep 2020 09:37:23 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: netdev@...r.kernel.org, andrew@...n.ch, adam.rudzinski@....net.pl,
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: [PATCH net-next 3/3] net: phy: bcm7xxx: request and manage GPHY
clock
On 20-09-04 08:38, Florian Fainelli wrote:
>
>
> On 9/3/2020 11:18 PM, Marco Felsch wrote:
> > On 20-09-02 21:39, 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.
> >
> > Hi Florian,
> >
> > Seems like you added the same support here like I did for the smsc
> > driver. So should I go with my proposed patch which can be adapted later
> > after you guys figured out who to enable the required resources?
>
> That seems fine to me, on your platform there appears to be an assumption
> that we will be able to probe the SMSC PHY because everything we need is
> already enabled, right? If so, this patch series does not change that state.
Unfortunately yes.. The imx-fec driver enables all DT-specified clock
and then the mdio-bus probe is initiated. The good point is that my
patchset do not require a clock-id so the generic way can replace my
work later.
Regards,
Marco
Powered by blists - more mailing lists