[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2022 17:34:05 +0000
From: Ian Abbott <abbotti@....co.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] option to use proper skew timings for Micrel KSZ9021
On 11/11/2022 14:25, Andrew Lunn wrote:
>> 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.
Yes, but you've convinced me that it is slightly more involved than I
initially thought!
> 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.
Perhaps it could allow the renamed properties for the KSZ9131 to be
used. (They have similar names to the KSZ9021/KSZ9031 properties, but
change the `-ps` suffix to `-psec`.) Those are already absolute
timings. There would need to be a decision on what to do if the node
contains a mixture of `foo-ps` and `foo-psec` properties.
> 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.
Yes, some min/max clamping of skew values would be good. The code for
KSZ9131 does that already.
--
-=( Ian Abbott <abbotti@....co.uk> || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Powered by blists - more mailing lists