Messages in this thread |  | | Subject | Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings | From | Florian Fainelli <> | Date | Thu, 5 Apr 2018 09:02:38 -0700 |
| |
On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote: > From: Esben Haabendal <eha@deif.com> > > Read configration settings, to allow automatic forced speed/duplex setup > by hardware strapping.
OK but why? What problem is this solving for you? In general, we do not really want to preserve too much of what the PHY has been previously configured with, provided that the PHY driver can re-instate these configuration values.
I just wonder how this can be robust when you connect this PHY with auto-negotiation disabled to a peer that expects a set of link parameters not covered by the default advertisement values? This really looks like a recipe for disaster when you could just disable auto-negotiation with ethtool.
> > Signed-off-by: Esben Haabendal <eha@deif.com> > Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > drivers/net/phy/dp83640.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c > index 654f42d00092..01e21b4998ad 100644 > --- a/drivers/net/phy/dp83640.c > +++ b/drivers/net/phy/dp83640.c > @@ -1134,6 +1134,10 @@ static int dp83640_probe(struct phy_device *phydev) > if (!dp83640) > goto no_memory; > > + err = genphy_read_config(phydev); > + if (err) > + goto no_config; > + > dp83640->phydev = phydev; > INIT_DELAYED_WORK(&dp83640->ts_work, rx_timestamp_work); > > @@ -1166,6 +1170,7 @@ static int dp83640_probe(struct phy_device *phydev) > > no_register: > clock->chosen = NULL; > +no_config: > kfree(dp83640); > no_memory: > dp83640_clock_put(clock); >
-- Florian
|  |