linux-kernel - Re: [PATCH 1/3] dt-bindings: clock: s32g: add uSDHC clock IDs

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] [day] [month] [year] [list]

Message-ID: <f54d947c-58dc-498f-8871-b472f97be4a8@oss.nxp.com>
Date: Mon, 5 Feb 2024 08:34:49 +0200
From: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>
To: Conor Dooley <conor@...nel.org>
Cc: Chester Lin <chester62515@...il.com>, Andreas Farber <afaerber@...e.de>,
 Matthias Brugger <mbrugger@...e.com>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, NXP S32 Linux Team <s32@....com>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 NXP Linux Team <linux-imx@....com>, linux-arm-kernel@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-clk@...r.kernel.org, Ghennadi Procopciuc
 <ghennadi.procopciuc@....com>, Ciprian Costea <ciprianmarian.costea@....com>
Subject: Re: [PATCH 1/3] dt-bindings: clock: s32g: add uSDHC clock IDs

On 1/22/24 12:09, Ghennadi Procopciuc wrote:
> On 1/21/24 15:32, Conor Dooley wrote:
>> On Fri, Jan 19, 2024 at 11:25:57PM +0200, Ghennadi Procopciuc wrote:
>>> On 1/19/24 18:14, Conor Dooley wrote:
>>>> On Fri, Jan 19, 2024 at 04:11:37PM +0000, Conor Dooley wrote:
>>>>> On Fri, Jan 19, 2024 at 03:02:28PM +0200, Ghennadi Procopciuc (OSS) wrote:
>>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@....com>
>>>>>>
>>>>>> Add the SCMI clock IDs for the uSDHC controller present on
>>>>>> S32G SoCs.
>>>>>>
>>>>>> Signed-off-by: Ciprian Costea <ciprianmarian.costea@....com>
>>>>>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@....com>
>>>>>> ---
>>>>>>  include/dt-bindings/clock/s32g-scmi-clock.h | 14 ++++++++++++++
>>>>>>  1 file changed, 14 insertions(+)
>>>>>>  create mode 100644 include/dt-bindings/clock/s32g-scmi-clock.h
>>>>>>
>>>>>> diff --git a/include/dt-bindings/clock/s32g-scmi-clock.h b/include/dt-bindings/clock/s32g-scmi-clock.h
>>>>>> new file mode 100644
>>>>>> index 000000000000..739f98a924c3
>>>>>> --- /dev/null
>>>>>> +++ b/include/dt-bindings/clock/s32g-scmi-clock.h
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */
>>>>>> +/*
>>>>>> + * Copyright 2020-2024 NXP
>>>>>> + */
>>>>>> +#ifndef _DT_BINDINGS_SCMI_CLK_S32G_H
>>>>>> +#define _DT_BINDINGS_SCMI_CLK_S32G_H
>>>>>> +
>>>>>> +/* uSDHC */
>>>>>> +#define S32G_SCMI_CLK_USDHC_AHB		31
>>>>>> +#define S32G_SCMI_CLK_USDHC_MODULE	32
>>>>>> +#define S32G_SCMI_CLK_USDHC_CORE	33
>>>>>> +#define S32G_SCMI_CLK_USDHC_MOD32K	34
>>>>>
>>>>> Why do these numbers not start at 0?
>>>>
>>>> Ah, because these are the SCMI IDs directly. If these are numbers that
>>>> are in the TRM, just use the numbers directly - there's no need to
>>>> create bindings for that.
>>>>
>>>
>>> Hi Conor,
>>>
>>> I appreciate you taking the time to review the proposed changes. I
>>> wanted to clarify that the IDs mentioned in the header are SCMI IDs
>>> exported by the TF-A and are utilized by the second patch of this
>>> series. These IDs are for the uSDHC controller to control its clocks. As
>>> other SoCs use this model, I have included all the necessary IDs in a
>>> dedicated header file:
>>> - rk3588s     (arch/arm64/boot/dts/rockchip/rk3588s.dtsi:97 [0])
>>> - stm32mp157c (arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts:73 [1])
>>> - stm32mp131  (arch/arm/boot/dts/st/stm32mp131.dtsi:1372 [2])
>>>
>>> Should I remove the header and use raw numbers in the uSDHC node?
>>
>> IMO, yes. There's no abstraction/binding being created here if they're
>> the SCMI IDs.


I included the suggestion in the second version of this patchset.

>> Thanks,
>> conor.
> 
> Thank you for letting me know. I will make sure to include this change
> in the second version of the patchset.
> 
>>> For
>>> example:
>>>> +		usdhc0: mmc@...f0000 {
>>>> +			compatible = "nxp,s32g2-usdhc";
>>>> +			reg = <0x402f0000 0x1000>;
>>>> +			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>>> +			clocks = <&clks 32>,
>>>> +				 <&clks 31>,
>>>> +				 <&clks 33>;
>>>> +			clock-names = "ipg", "ahb", "per";
>>>> +			bus-width = <8>;
>>>> +			status = "disabled";
>>>> +		};
>>>
>>> [0]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588s.dtsi#n97
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts#n73
>>> [2]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/st/stm32mp131.dtsi#n1372
>>>
>>> -- 
>>> Regards,
>>> Ghennadi