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: <dfe328fc-349b-3357-a8ac-6fc363f403fc@kernel.org>
Date:   Thu, 5 Jan 2023 22:53:58 +0100
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Gatien CHEVALLIER <gatien.chevallier@...s.st.com>,
        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 3/7] dt-bindings: bus: add STM32MP15 ETZPC firewall
 bus bindings

On 04/01/2023 14:43, Gatien CHEVALLIER wrote:
> Hello Krzysztof,
> 
> On 12/22/22 14:57, Krzysztof Kozlowski wrote:
>> On 22/12/2022 14:51, Gatien CHEVALLIER wrote:
>>> Hello,
>>>
>>> On 12/22/22 11:26, Krzysztof Kozlowski wrote:
>>>> On 21/12/2022 18:30, Gatien Chevallier wrote:
>>>>> Adds the list of peripherals IDs under firewall bus on STM32MP15.
>>>>>
>>>>> Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
>>>>> ---
>>>>>    include/dt-bindings/bus/stm32mp15_sys_bus.h | 98 +++++++++++++++++++++
>>>>>    1 file changed, 98 insertions(+)
>>>>>    create mode 100644 include/dt-bindings/bus/stm32mp15_sys_bus.h
>>>>>
>>>>> diff --git a/include/dt-bindings/bus/stm32mp15_sys_bus.h b/include/dt-bindings/bus/stm32mp15_sys_bus.h
>>>>> new file mode 100644
>>>>> index 000000000000..97eacc7b5f16
>>>>> --- /dev/null
>>>>> +++ b/include/dt-bindings/bus/stm32mp15_sys_bus.h
>>>>
>>>> That's wrong in multiple ways:
>>>> 1. No underscores
>>>> 2. Missing vendor prefix
>>>> 3. Name not matching compatible.
>>>
>>> Sure, will comply in V3.
>>>
>>>>
>>>>> @@ -0,0 +1,98 @@
>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>>>> +/*
>>>>> + * Copyright (C) STMicroelectronics 2022 - All Rights Reserved
>>>>> + */
>>>>> +#ifndef _DT_BINDINGS_BUS_STM32MP15_SYS_BUS_H
>>>>> +#define _DT_BINDINGS_BUS_STM32MP15_SYS_BUS_H
>>>>> +
>>>>> +/* ETZPC IDs */
>>>>> +#define STM32MP1_ETZPC_STGENC_ID	0
>>>>> +#define STM32MP1_ETZPC_BKPSRAM_ID	1
>>>>> +#define STM32MP1_ETZPC_IWDG1_ID		2
>>>>> +#define STM32MP1_ETZPC_USART1_ID	3
>>>>> +#define STM32MP1_ETZPC_SPI6_ID		4
>>>>> +#define STM32MP1_ETZPC_I2C4_ID		5
>>>>> +/* ID 6 reserved */
>>>>
>>>> Reserved why? These are IDs so they start from 0 and go by 0. Don't
>>>> hard-code some register offsets.
>>>
>>> Here, I do define IDs. Some appear as reserved based on what I've seen
>>> in the SoC datasheet that states these as "indexes"
>>>
>>> Please see the table 94 in chapter 15.6 (ETZPC) of the STM32MP157
>>> Reference manual:
>>> [1] https://www.st.com/resource/en/reference_manual/DM00327659-.pdf
>>
>> Then why do you define them in bindings? Use raw numbers. Do you see
>> anywhere in arm/arm64 bindings for GIC_SPI interrupt numbers?
>>
> 
> What would you think of simply removing the comments that state that IDs 
> are reserved, mimicking the way it is for qcom bindings? Fundamentally, 
> they are indeed only IDs and could be raw numbers.

If these are IDs then there are no reserved numbers and they are
continuous from 0 to X. Without gaps.

> IMO, this makes reading the device tree harder. Because you'd have to 
> look what the raw number corresponds to.

Sure, but that's not the reason to put numbers to the bindings... You
mix defines with bindings.

> To take an example, it has already been done for SCMI clocks and I find 
> it eases comprehension.

You need to be a bit more specific...

Anyway, IDs should be placed in bindings. Some mapping of
internal/hardware ports, registers, offsets, values - usually not.

I don't know where exactly your case fits, but when some IDs are
reserved it is a clear sign that these are not IDs (again - IDs start
from 0 and go incrementally by one, without gaps).


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ