linux-kernel - Re: [PATCH v2 2/4] hwrng: stm32 - implement support for STM32MP25x platforms

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: <d862765e-e396-4f7c-97ff-76df9aa03216@foss.st.com>
Date: Mon, 14 Oct 2024 14:36:39 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Marek Vasut <marex@...x.de>, Olivia Mackall <olivia@...enic.com>,
        Herbert
 Xu <herbert@...dor.apana.org.au>,
        Rob Herring <robh@...nel.org>,
        Krzysztof
 Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Maxime
 Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue
	<alexandre.torgue@...s.st.com>,
        Lionel Debieve <lionel.debieve@...s.st.com>
CC: <linux-crypto@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/4] hwrng: stm32 - implement support for STM32MP25x
 platforms



On 10/14/24 10:52, Marek Vasut wrote:
> On 10/14/24 10:38 AM, Gatien CHEVALLIER wrote:
>>
>>
>> On 10/11/24 18:17, Marek Vasut wrote:
>>> On 10/11/24 5:41 PM, Gatien Chevallier wrote:
>>>
>>> [...]
>>>
>>>> @@ -551,6 +565,41 @@ static int stm32_rng_probe(struct 
>>>> platform_device *ofdev)
>>>>       priv->rng.read = stm32_rng_read;
>>>>       priv->rng.quality = 900;
>>>> +    if (!priv->data->nb_clock || priv->data->nb_clock > 2)
>>>> +        return -EINVAL;
>>>> +
>>>> +    priv->clk_bulk = devm_kzalloc(dev, priv->data->nb_clock * 
>>>> sizeof(*priv->clk_bulk),
>>>> +                      GFP_KERNEL);
>>>> +    if (!priv->clk_bulk)
>>>> +        return -ENOMEM;
>>>
>>> Try this:
>>>
>>> ret = devm_clk_bulk_get(dev, priv->data->nb_clock, priv->clk_bulk);
>>> ...
>>> // Swap the clock if they are not in the right order:
>>> if (priv->data->nb_clock == 2 &&
>>>      strcmp(__clk_get_name(priv->clk_bulk[0].clk), "core"))
>>> {
>>>   const char *id = priv->clk_bulk[1].id;
>>>   struct clk *clk = priv->clk_bulk[1].clk;
>>>   priv->clk_bulk[1].id = priv->clk_bulk[0].id;
>>>   priv->clk_bulk[1].clk = priv->clk_bulk[0].clk;
>>>   priv->clk_bulk[0].id = id;
>>>   priv->clk_bulk[0].clk = clk;
>>> }
>>>
>>
>> Hi Marek,
>>
>> This won't work as the name returned by this API is clk->core->name.
>> AFAICT, it doesn't correspond to the names present in the device tree
>> under the "clock-names" property.
>> Any other idea or are you fine with what's below?
> Hmmm, it is not great, but at least it reduces the changes throughout 
> the driver, so that is an improvement.
> 
> I guess one could do some of_clk_get() and clk_is_match() in probe to 
> look up the clock in OF by name and then compare which clock is which 
> before swapping them in clk_bulk[] array, but that might be too convoluted?

Yes, probably too much. What's present in the patch is not close to
perfection but has the advantage of being straightforward. If we agree
on that, I'll send a V3 containing the modifications in the bindings
file.

Thanks for reviewing,
Gatien