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: <988667a4-4bc0-4594-8dfd-a7b652b149b2@foss.st.com>
Date: Wed, 26 Feb 2025 10:33:35 +0100
From: Alexandre TORGUE <alexandre.torgue@...s.st.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Clement LE GOFFIC
	<clement.legoffic@...s.st.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob
 Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor
 Dooley <conor+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Bartosz Golaszewski <brgl@...ev.pl>
CC: <linux-kernel@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 7/9] ARM: dts: stm32: add Hardware debug port (HDP) on
 stm32mp25

Hi Krzysztof

On 2/26/25 08:23, Krzysztof Kozlowski wrote:
> On 25/02/2025 17:09, Clement LE GOFFIC wrote:
>> On 2/25/25 14:05, Krzysztof Kozlowski wrote:
>>> On 25/02/2025 09:48, Clément Le Goffic wrote:
>>>> Add the hdp devicetree node for stm32mp25 SoC family
>>>>
>>>> Signed-off-by: Clément Le Goffic <clement.legoffic@...s.st.com>
>>>> ---
>>>>    arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
>>>> index f3c6cdfd7008..43aaed4fcf10 100644
>>>> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
>>>> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
>>>> @@ -918,6 +918,13 @@ package_otp@1e8 {
>>>>    			};
>>>>    		};
>>>>    
>>>> +		hdp: pinctrl@...90000 {
>>>> +			compatible = "st,stm32mp-hdp";
>>>
>>> So here again - you have stm32mp251 SoC, but use entirely different
>>> compatible.
>>
>> Ok so I will use "st,stm32mp15-hdp"
> 
> 
> This means this is stm32mp15 SoC. I do not see such SoC on list of your
> SoCs in bindings. What's more, there are no bindings for other SoC
> components for stm32mp15!

Yes stm32mp15 is not a "real SoC". I agree that at the beginning of the 
STM32 story we didn't have a clear rule/view to correctly naming our 
compatible. We tried to improve the situation to avoid compatible like 
"st,stm32", "st,stm32mp" or "st,stm32mp1". So we introduced 
"st,stm32mp13", "st,stm32mp15" or "st,stm32mp25" for new drivers. So yes 
it represents a SoC family and not a real SoC. We haven't had much 
negative feedback it.

But, if it's not clean to do it in this way, lets define SoC compatible 
for any new driver.
For the HDP case it is: "st,stm32mp157" and used for STM32MP13, 
STM32MP15 end STM32MP25 SoC families (if driver is the same for all 
those SoCs).

regards
Alex


> Something is here not matching - this change, this DTSI, top level
> bindings or all of your SoC device/blocks bindings.
> 
> 
> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ