Hi Joe! ... > > +1 from me as well. ... > > Joe, whats your opinion on this? ... > Do we really think this is a strong use-case? This seem like the type of > thing I > would expect to tweak for testing through mii / mdio commands and then > configure the device tree based on that. This is pretty much a one-time > thing for a > given board it seems to me. > > If we really want a polished interface to it, we should define a sub-command / > new command that phy drivers can implement. I'm not sure an > undiscoverable, un-"help"-able list of env vars will be apparent to users. > Do you have a > feeling for how close to universal any of these parameters are across phys?
I don't believe this is a strong use case for debugged and working boards. The intent was to support our downstream customers, that do develop their own boards and could use a method to help them with initial bringup. Many of these engineers in bringup are hardware/board developers and are not as comfortable as we are using uboot. It helps to support skewing these signals, especially if it can save a board spin (having said this - this capability is not a substitute for a well designed board). The debug/bringup use case can be supported by describing to non-expert users how to make use of the mii command as Marek had originally suggested, so I'm fine with that solution. On the question of how universal these parameters are across phys? Not so much. I've only encountered these on the two Micrel phys - the ksz9021 and ksz9031. And these have different signals that can be skewed. Thanks for the comments and feedback! I'll focus on working out a solution through devicetree, and a README type of description of how to skew the signals for debug/bringup purposes using the mii command. All the best! Vince _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
