linux-kernel - Re: [PATCH net-next 1/3] dt-bindings: dp83867: add binding for io_impedance

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: <29ddcecb-18d3-b92e-10fb-d5ea278886d6@rasmusvillemoes.dk>
Date:   Tue, 7 Jun 2022 13:54:30 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Dan Murphy <dmurphy@...com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] dt-bindings: dp83867: add binding for
 io_impedance_ctrl nvmem cell

On 06/06/2022 23.58, Andrew Lunn wrote:
>> There is no documented mapping from the 32 possible values of the
>> IO_IMPEDANCE_CTRL field to values in the range 35-70 ohms
> 
> There have been a few active TI engineers submitting patches to TI PHY
> drivers. Please could you reach out to them and ask if they can
> provide documentation.
>
> Having magic values in DT is not the preferred why to use it. Ideally
> you should store Ohms in the cell and convert to the register value.

We've already asked TI for more detailed information, but apparently the
data sheet already says all there is to know. I should have worded the
commit message differently. Something like

  There is no fixed mapping from register values to values in the range
  35-70 ohms; it varies from chip to chip, and even that target range is
  approximate.

So AFAICS the only meaningful thing to store in an nvmem cell is an
appropriate (per-board) raw value of that field.

I would think this would be very similar to how various sensors have
nvmem cells defining calibration data.

Rasmus