linux-kernel - Re: [PATCH v6 25/27] ARM: dts: at91: sam9x7: add device tree for SoC

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: <fe4c8c72-1f7b-4274-a910-4ad803487951@kernel.org>
Date: Wed, 28 Aug 2024 13:49:54 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Varshini.Rajendran@...rochip.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, Nicolas.Ferre@...rochip.com,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 25/27] ARM: dts: at91: sam9x7: add device tree for SoC

On 28/08/2024 10:25, Varshini.Rajendran@...rochip.com wrote:
> On 27/08/24 6:18 pm, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 27/08/2024 11:50, Varshini.Rajendran@...rochip.com wrote:
>>> Hi Krzysztof,
>>>
>>> Apologies for the delay in response.
>>>
>>> On 31/07/24 2:00 pm, Krzysztof Kozlowski wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> On 29/07/2024 09:09, Varshini Rajendran wrote:
>>>>> Add device tree file for SAM9X7 SoC family.
>>>>>
>>>>> Co-developed-by: Nicolas Ferre <nicolas.ferre@...rochip.com>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@...rochip.com>
>>>>> Signed-off-by: Varshini Rajendran <varshini.rajendran@...rochip.com>
>>>>
>>>> ...
>>>>
>>>>> +
>>>>> +             can1: can@...04000 {
>>>>> +                     compatible = "bosch,m_can";
>>>>> +                     reg = <0xf8004000 0x100>, <0x300000 0xbc00>;
>>>>> +                     reg-names = "m_can", "message_ram";
>>>>> +                     interrupts = <30 IRQ_TYPE_LEVEL_HIGH 0>,
>>>>> +                                  <69 IRQ_TYPE_LEVEL_HIGH 0>;
>>>>> +                     interrupt-names = "int0", "int1";
>>>>> +                     clocks = <&pmc PMC_TYPE_PERIPHERAL 30>, <&pmc PMC_TYPE_GCK 30>;
>>>>> +                     clock-names = "hclk", "cclk";
>>>>> +                     assigned-clocks = <&pmc PMC_TYPE_CORE PMC_UTMI>, <&pmc PMC_TYPE_GCK 30>;
>>>>> +                     assigned-clock-rates = <480000000>, <40000000>;
>>>>> +                     assigned-clock-parents = <&pmc PMC_TYPE_CORE PMC_UTMI>, <&pmc PMC_TYPE_CORE PMC_UTMI>;
>>>>> +                     bosch,mram-cfg = <0x7800 0 0 64 0 0 32 32>;
>>>>> +                     status = "disabled";
>>>>> +             };
>>>>> +
>>>>> +             tcb: timer@...08000 {
>>>>> +                     compatible = "microchip,sam9x7-tcb","atmel,sama5d2-tcb", "simple-mfd", "syscon";
>>>>
>>>> Why this is simple-mfd without children?
>>>
>>> The tcb node will have each TC (Timer Counter) Block as a child when it
>>> is configured to be used as either one of the following modes Timer or
>>> Counter / Capture / PWM.
>>
>> And where are these children? What does it mean "will have", in context
>> when? DTS is static, if you do not have here children then this is not a
>> simple-mfd.
>>
> I understand your concern. But the thing is that, each tc block is 
> configured as a child and it can be configured in 3 different modes with 
> different compatibles. In the current dts (i.e., sam9x75_curiosity 
> board) we don't have a use case for the tcb, hence there are no child 
> nodes defined. But there are instances where it can be defined in the 
> dts, say for a custom board using sam9x7 SoC. In that case the 

Where are these instances? Can you point me to DTS?

> simple-mfd usage is justified, if I am not wrong. If this justification 
> doesn't suffice, then declaring child nodes with one mode as default 

If I understand correctly: some out of tree, non-upstream project wants
this. Sorry, but out of tree does not matter. So it is not a correct
justification.

With such argument you could claim that everything needs simple-mfd
because some broken out-of-tree code adds there children.

> which can be overridden in the dts and kept disabled in the dtsi should 
> be the other plausible way. Please let me know your suggestions.

No clue, please post complete binding and complete DTS so we can review
these.

Best regards,
Krzysztof