[U-Boot] [PATCH 2/2] net: phy: Add ability to program the ksz9031 skew values from the uboot env

[Stefan Roese <sr@denx.de>]

(Added Joe Hershberger to Cc, because this discussion is "network" 
related and not really SoCFPGA related)

On 10.02.2015 19:51, Marek Vasut wrote:
>>> We already do this kind of a programming in
>>> board/altera/socfpga/socfpga.c in board_phy_config(), don't we ?
>>
>> Yes, good point. This patch series is a first in some upcoming patches to
>> make this better. The Linux implementation uses devicetree settings to set
>> the skews, so if we were to follow that same model the code in socfpga.c
>> would become deprecated in favor of setting the skews through the phy
>> driver and subsequently removed. That way other users could take advantage
>> of this through devicetree.
>
> Setting the skews in DT would indeed be preferable in my opinion.

+1 from me.

>> The other problem with the current
>> implementation is the skew values are part specific - we set the actual
>> register values in the environment when it would be better to use a skewed
>> time value (in +/- picoseconds).
>
> You mean they are specific for particular PHY model ? Or board model ? Or
> even particular board itself ?
>
>>> Also, see [1], once I apply this, the DT support (not DM) for SoCFPGA
>>> will become mandatory. Won't it make more sense to pull these values
>>> from the DT instead of poluting the board environment with those please
>>> ?
>>
>> I agree it would make more sense to pull these from devicetree - I'm
>> planning on adding that in a future patch. I thought it would be a good
>> idea to pull these values from the environment first, overriding the
>> devicetree (if present in the environment). This approach is helpful
>> during bringup & debug since it doesn't require one to change the
>> devicetree to try something quickly. I'm ok with any approach you think
>> would work for the community.
>
> You can do that with the 'mii' command as well I think, but I might be wrong.

Yes. For testing or board bringup this might really serve. Even though 
this setting via environment as proposed from Vince is more elegant and 
less hackish. And easier to adjust/tune for "normal users".

>> I'm ok with whatever the community decides considering my rationale above.
>
> +CC Stefan and Pavel, please comment.

The default values should come from the DT, once this is all in place. 
But I think that for initial board bringup / testing such a method, to 
override those values via environment variables can be quite helpful.

Joe, whats your opinion on this?

Thanks,
Stefan