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: <Y2vi/IxoTpfwR65T@lunn.ch>
Date:   Wed, 9 Nov 2022 18:27:24 +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

> I would like to add an optional boolean property to indicate that the skew
> timing properties are to be interpreted as "proper" skew timings (in 120ps
> steps) rather than fake skew timings.  When this property is true, the
> driver can divide the specified skew timing values by 120 instead of 200.
> The advantage of this is that the same skew timing property values can be
> used in the device node and will apply to both KSZ9021 and KSZ9031 as long
> as the values are in range for both chips.

Hi Ian

I don't see why this is an advantage. Yes, it is all messed up, but it
is a well defined and documented mess. All this boolean will do is
make it a more complex mess, leading it more errors with the wrong
value set.

      Andrew