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: <Y25bQfVwPZDT4T5D@lunn.ch>
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