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

Open Source and information security mailing list archives

Message-ID: <706eb7b4-07ce-ffd2-3366-5656ddba21d6@microchip.com>
Date:   Thu, 12 May 2022 16:04:48 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <krzysztof.kozlowski@...aro.org>, <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 18:35, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 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?

Not necessarily. It may happen that only ROM code to be updated (1st stage
bootloader) end everything else on Linux side to be able to run as is. Or
to just fix some bugs in different IPs. Things that will not necessarily
need adding new compatibles for the new chip. And it may happen that new
chip revisions to be populated on previous board revisions.

> Chip revisions like different board compatibles thus different
> *macro* values?

If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
established that will remain fixed b/w revisions. This is the length of the
2nd packet in NVMEM (that is of interest for thermal management).

Only the length of the 1st packet may change. And addressing the NVMEM with
packet id based index should take care of temperature calibration NVMEM DT
binding to work all the time.

> If not, then maybe better skip the length out of
> bindings and just provide the first macro.

As far as I know the length is part of the way the NVMEM cells are
described in DT: it needs the offset in memory (for the data to be
retrieved) and its length.

Thank you,
Claudiu Beznea

> 
> 
> 
> Best regards,
> Krzysztof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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