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]

Message-ID: <04a95089-cd39-2628-f333-0da24e55a967@linaro.org>
Date:   Fri, 13 May 2022 09:49:20 +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 18:04, Claudiu.Beznea@...rochip.com wrote:
> 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.

In DT yes, but now you put the length in the bindings. It means DTS must
have exactly that value and cannot use anything more. It's the same as
hard-coding unit addresses in the bindings.


Best regards,
Krzysztof