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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23e33ae8-3cd0-cd4b-4648-5ffb07329efa@mev.co.uk>
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 )=-