linux-kernel - Re: [RFC PATCH 6/7] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18d0eca0-838e-92c3-4188-d8dcf480ef6e@foss.st.com>
Date:   Thu, 22 Dec 2022 16:57:01 +0100
From:   Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>,
        <alexandre.torgue@...s.st.com>, <robh+dt@...nel.org>,
        <Oleksii_Moisieiev@...m.com>, <linus.walleij@...aro.org>,
        <gregkh@...uxfoundation.org>
CC:     <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <loic.pallardy@...com>,
        <devicetree@...r.kernel.org>, <mark.rutland@....com>,
        <arnd@...db.de>
Subject: Re: [RFC PATCH 6/7] ARM: dts: stm32: add ETZPC as a system bus for
 STM32MP15x boards



On 12/22/22 16:21, Krzysztof Kozlowski wrote:
> On 22/12/2022 15:42, Gatien CHEVALLIER wrote:
>> Hello,
>>
>>
>> On 12/22/22 11:30, Krzysztof Kozlowski wrote:
>>> On 21/12/2022 18:30, Gatien Chevallier wrote:
>>>> The STM32 System Bus is an internal bus on which devices are connected.
>>>> ETZPC is a peripheral overseeing the firewall bus that configures
>>>> and control access to the peripherals connected on it.
>>>>
>>>> For more information on which peripheral is securable, please read
>>>> the STM32MP15 reference manual.
>>>>
>>>> Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
>>>> ---
>>>>    arch/arm/boot/dts/stm32mp151.dtsi | 2737 +++++++++++++++--------------
>>>>    1 file changed, 1406 insertions(+), 1331 deletions(-)
>>>>    
>>>> -		lptimer1: timer@...09000 {
>>>> +		etzpc: etzpc@...07000 {
>>>
>>> Node names should be generic.
>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>
>> Will change to etzpc: bus@...07000 in V3
>>
>>>
>>>> +			compatible = "st,stm32mp15-sys-bus";
>>>> +			reg = <0x5c007000 0x400>;
>>>>    			#address-cells = <1>;
>>>> -			#size-cells = <0>;
>>>> -			compatible = "st,stm32-lptimer";
>>>> -			reg = <0x40009000 0x400>;
>>>> -			interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
>>>> -			clocks = <&rcc LPTIM1_K>;
>>>> -			clock-names = "mux";
>>>> -			wakeup-source;
>>>> -			status = "disabled";
>>>
>>> Why entire bus is disabled? What resources do you miss?
>>
>> Here, I did not want to modify the status of the nodes in the device
> 
> By making it disabled you actually modify the status of any enabled
> node. By making it enabled you do not cause any change.
> 
>> tree. Nodes that are default enabled in the SoC device tree stay enabled
>> and vice-versa.
> 
> No, because parent is disabled.
> 
>> IMO think this patch should not include these kind of
>> changes in its scope. I describe the bus and the peripherals connected
>> to it, nothing more :)
> 
> I am not proposing to change existing nodes. I am asking why new node is
> being disabled (because it is a new node, isn't it?).

I'm sorry but the ETZPC node is not disabled. The patch is quite hard to 
read as I'm moving all securable/MCU isolation capable peripheral nodes 
under ETZPC.

 >>>> -			#size-cells = <0>;
 >>>> -			compatible = "st,stm32-lptimer";
 >>>> -			reg = <0x40009000 0x400>;
 >>>> -			interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
 >>>> -			clocks = <&rcc LPTIM1_K>;
 >>>> -			clock-names = "mux";
 >>>> -			wakeup-source;
 >>>> -			status = "disabled";

are part of lptimer1 node, which is moved under ETZPC. ETZPC node is 
default enabled.

Result after patch is:

etzpc: etzpc@...07000 {
	compatible = "st,stm32mp15-sys-bus";
	reg = <0x5c007000 0x400>;
	#address-cells = <1>;
	#size-cells = <1>;
	feature-domain-controller;
	#feature-domain-cells = <2>;
	ranges;

	timers2: timer@...00000 {
(...)

Or do I misunderstand you comment?

> 
> Best regards,
> Krzysztof
>