Re: [RFC] option to use proper skew timings for Micrel KSZ9021

[Andrew Lunn <andrew@lunn.ch>]

> 1. Forward planning to replace KSZ9021 with KSZ9031 in a future hardware
> iteration.  As long as the device tree and kernel driver (and possibly the
> bootloader if it uses the same device tree blob as the kernel internally)
> are upgraded at the same time, software upgrades of existing hardware with
> KSZ9021 will continue to work correctly.  Upgraded hardware with KSZ9031
> will work properly with the updated software.
> 
> 2. Due to KSZ9031 chip shortages, it may be useful to replace KSZ9031 with
> KSZ9021 for a few manufacturing runs.  This can be done as long as the
> device tree and driver are updated to know about the new property in time
> for those manufacturing runs.
> 
> In both cases, the skew timings chosen would need to apply to both KSZ9021
> and KSZ9031.

So you are saying that as it is pin compatible ( i assume), you can
swap the PHY and still call it the same board, and still use the same
device tree blob.

If you are going to do this, i think you really should fix all the
bugs, not just the step. KSZ9021 has an offset of -840ps. KSZ9031 has
an offset of -900ps. So both are broke, in that the skew is expected
to be a signed value, 0 meaning 0.

I would suggest a bool property something like:

micrel,skew-equals-real-picoseconds

and you need to update the documentation in a way it is really clear
what is going on.

I would also consider adding a phydev_dbg() which prints the actual ps
skew being used, with/without the bug.

And since you are adding more foot guns, please validate the values in
DT as strictly as possible, without breaking the existing binding.

   Andrew