linux-kernel - Re: [PATCH v2] net: stmmac: correct MAC propagation delay

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: <ZMJxbrXBeE3WnEUn@hoboy.vegasvil.org>
Date:   Thu, 27 Jul 2023 06:30:22 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Johannes Zink <j.zink@...gutronix.de>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>,
        kernel test robot <lkp@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Jose Abreu <joabreu@...opsys.com>,
        linux-arm-kernel@...ts.infradead.org, kernel@...gutronix.de,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        linux-stm32@...md-mailman.stormreply.com,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        patchwork-jzi@...gutronix.de
Subject: Re: [PATCH v2] net: stmmac: correct MAC propagation delay

On Thu, Jul 27, 2023 at 08:40:51AM +0200, Johannes Zink wrote:
> Hi Richard,
> 
> On 7/26/23 17:34, Richard Cochran wrote:
> > That is great, until they change the data sheet.  Really, this happens.
> 
> I think I don't get your point here.
> 
> That's true for literally any register of any peripheral in a datasheet.
> I think we can just stop doing driver development if we wait for a final
> revision that is not changed any more. Datasheets change, and if they do we
> update the driver.

This is different than normal registers, because the values are a
guess as to what the latency in the hardware design is.

Here is how it works in practice:  Vendor first asks a summer intern to
measure the latency.  Intern does some kind of random measurement, and
that goes into silicon.  One year later, customers discover that the
values are bogus.  Vendor doesn't spin a new silicon revision just for
that.  If vendor is honest, a footnote appears in the errata that the
corrections are wrong.

Thanks,
Richard