linux-kernel - Re: [V1 2/2] drivers soc: add support for ST stm32mp13xx family

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: <9846275b-8841-4bbc-88a6-fd6360a7f638@linaro.org>
Date: Wed, 21 May 2025 18:37:21 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Rodolfo Giometti <giometti@...eenne.com>,
 Yann Gautier <yann.gautier@...s.st.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Eric Fourmont <eric.fourmont-ext@...com>, linux-kernel@...r.kernel.org
Subject: Re: [V1 2/2] drivers soc: add support for ST stm32mp13xx family

On 21/05/2025 17:44, Rodolfo Giometti wrote:
> On 20/05/25 18:58, Yann Gautier wrote:
>> On 5/19/25 15:08, Rodolfo Giometti wrote:
> 
> [snip]
> 
>>> +static int __init stm32mp13_soc_get_rpn_uid(u32 *rpn, u32 uid[3])
>>> +{
>>> +    struct device_node *np;
>>> +    void __iomem *regs;
>>> +    static const struct of_device_id devids[] = {
>>> +        { .compatible = "st,stm32mp13-bsec" },
>>> +        { },
>>> +    };
>>
>> As said by Krzysztof, you cannot access the OTP fuses this way.
>> There is already a driver for that: drivers/nvmem/stm32-romem.c.
>> And the information there should be accessed through nvmem framework.
>>
>> For the UID, you should add this in your first patch:
>>              uid_otp: uid-otp@34 {
>>                  reg = <0x34 0xc>;
>>              };
>>
>> And add &part_number_otp and &uid_otp to your driver nvmem-cells property:
>> nvmem-cells = <&cfg0_otp>, <&part_number_otp>, <&uid_otp>;
> 
> I see, but since the device is called by the device_initcall(), when I try to 
> use the nvmem framework I always get the EPROBE_DEFER error. :(

.... for a reason.

I already said, this must not be device_initcall(), at least not without
proper arguments which were not given. IMHO, these should be also
documented, but we have poor history of doing that.

In any case manual probe ordering is fragile and should be avoided.

Best regards,
Krzysztof