[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2022 15:25:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Ian Abbott <abbotti@....co.uk>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] option to use proper skew timings for Micrel KSZ9021
> 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
Powered by blists - more mailing lists