linux-kernel - Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

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]

Date:   Thu, 12 May 2022 17:35:56 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Claudiu.Beznea@...rochip.com, srinivas.kandagatla@...aro.org,
        robh+dt@...nel.org, krzk+dt@...nel.org
Cc:     linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

On 12/05/2022 17:31, Claudiu.Beznea@...rochip.com wrote:

>>
>> Macro is a nice idea if it can be stable. I understood that length of
>> packets depends on hardware, so this part could be stable. But what
>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
> 
> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
> calibration packet. This length is fixed and will not be changed.
> 
> After these 2 packets (provided by Microchip) user may further flash any
> number of packets and use them as they wish.
> 
> Driver is in charge of scanning the NVMEM for the available packets and
> prepare a list with their IDs and their starting offsets in NVMEM memory
> such that when it receives a read request it will be able to decode the
> packet offset based on packet identifier.
> 
> In case different number of packets are available in NVMEM for different
> kind of setups (boards) these could also be referenced in board specific DT
> using OTP_PKT() macro and with proper length (which will depend on what
> user flashed).
> 
>> You wrote "Boot configuration packet may vary in length", so it could be
>> changed by Microchip?
> 
> Yes, between chip revisions its length could be changed.

Chip revisions like different board compatibles thus different
bindings/macro values? If not, then maybe better skip the length out of
bindings and just provide the first macro.



Best regards,
Krzysztof