From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32107D16265 for ; Mon, 14 Oct 2024 13:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=meVxP/72UxtTH816mMUL0SiTexlDHbve/hY9rxQg5uA=; b=aCGgftouA5IajBxAUbiBRXcFM7 giMFNIGP/kGDSuGshbqbmqpNKe+mGE1tMODdJXbHQPYAF0wPJocz/P6KnHknMg5Pe47KjpFMNlnWB oSlsXdPdAbA29YtAMle54ZA4BcsPf2Xse5aQlJPA6o7j1GOi4PzXkM6dUM+ePD/qlNzB3Ey/A7MA4 SeTSnhnGCgiVFCxVLXoDX9Na+InagmesViR5Tllr4SXhcyMTajX1Y4kJ8e6B0nM8JPvm893752T2l Xxz4/lkqop938H1YrYu8pg87KiXRAXXgmxAMJngDc5uneiBwE7iXMxr0JJw7j9Mbnk05q1ACcUW/B R88hA2Kw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0LNd-00000005LSK-2yCY; Mon, 14 Oct 2024 13:45:01 +0000 Received: from mx08-00178001.pphosted.com ([91.207.212.93] helo=mx07-00178001.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t0KOa-0000000572J-1MJH for linux-arm-kernel@lists.infradead.org; Mon, 14 Oct 2024 12:41:58 +0000 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 49EA1LYb021364; Mon, 14 Oct 2024 14:41:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=selector1; bh= meVxP/72UxtTH816mMUL0SiTexlDHbve/hY9rxQg5uA=; b=S1L6QIFMEQcaz9px 3ku77xK3UU2Y7DIxrJZFE4j/dQGFBDrlNZItWy6CSRTht823n520KH2PspoWzSHv I2vmI50o1j8yuiD73MYRitb1LmGdvaoJM2qQMCA73twaXkdklcR8P6KhfJQKt7Xe pT+lZs830jyeGjO6J7YgRLaaiIjB2WBrdsO6LvkDx9XGrQc2M9w5d1heKpYIU4/A nrO2aegzI6J/b3LLpnBQPkzFJLVZDkrgsXVeO3628JeSKypiR/BjQhnzAqW43JJ/ ub7GHFYhZIuMEHw+KQiDGb/6LzzjENxun5ZV6/VUn1ErSvZ8bF0UvydBh7zkVx3d nY6O2w== Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 427g0bg2pt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Oct 2024 14:41:41 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 468D24004F; Mon, 14 Oct 2024 14:40:25 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 7066526B65F; Mon, 14 Oct 2024 14:36:51 +0200 (CEST) Received: from [10.252.25.66] (10.252.25.66) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Mon, 14 Oct 2024 14:36:50 +0200 Message-ID: Date: Mon, 14 Oct 2024 14:36:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] hwrng: stm32 - implement support for STM32MP25x platforms To: Marek Vasut , Olivia Mackall , Herbert Xu , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maxime Coquelin , Alexandre Torgue , Lionel Debieve CC: , , , , References: <20241011-rng-mp25-v2-v2-0-76fd6170280c@foss.st.com> <20241011-rng-mp25-v2-v2-2-76fd6170280c@foss.st.com> <318dbd5e-f547-4d78-b42e-4dcacc08d328@denx.de> <8c13b0aa-7fb1-493c-9abc-5e5cfd982855@denx.de> Content-Language: en-US From: Gatien CHEVALLIER In-Reply-To: <8c13b0aa-7fb1-493c-9abc-5e5cfd982855@denx.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.252.25.66] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241014_054156_748355_C4F5D145 X-CRM114-Status: GOOD ( 17.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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