[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200523150951.GK610998@lunn.ch>
Date: Sat, 23 May 2020 17:09:51 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Dan Murphy <dmurphy@...com>
Cc: Florian Fainelli <f.fainelli@...il.com>, hkallweit1@...il.com,
davem@...emloft.net, robh@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay
configuration
> > > + dp83869->tx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
> > > + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
> > > + &dp83869->tx_id_delay);
> > > + if (!ret && dp83869->tx_id_delay > dp83869_internal_delay[delay_size]) {
> > > + phydev_err(phydev,
> > > + "tx-internal-delay value of %u out of range\n",
> > > + dp83869->tx_id_delay);
> > > + return -EINVAL;
> > > + }
> > This is the kind of validation that I would be expecting from the PHY
> > library to do, in fact, since you use Device Tree standard property, I
> > would expect you only need to pass the maximum delay value and some
> > storage for your array of delays.
>
> Actually the PHY library will return either the 0th index if the value is to
> small or the max index if the value is to large
>
> based on the array passed in so maybe this check is unnecessary.
Hi Dan
I'm not sure the helper is implementing the best behaviour. Rounded to
the nearest when within the supported range is O.K. But if the request
is outside the range, i would report an error.
Any why is your PHY special, in that is does care about out of range
delays, when others using new the new core helper don't?
Andrew
Powered by blists - more mailing lists