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

Message-ID: <1b29f54f-80a3-4afa-aa78-09939b2d5620@microchip.com>
Date: Mon, 2 Sep 2024 06:34:19 +0000
From: <Varshini.Rajendran@...rochip.com>
To: <krzk@...nel.org>, <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

Hi Krzysztof,

On 28/08/24 5:19 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 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.
> 
Not just out of tree projects, Even upstreamed DTS files have child 
nodes for this node in [1] and [2]. I guess the best way to sort this is 
to add similar child nodes in this dts as well. I will add them in the 
next version if that is acceptable. Please let me know.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts#:~:text=okay%22%3B%0A%7D%3B-,%26tcb0%20%7B,-timer0%3A%20timer

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/microchip/at91-sam9x60ek.dts#:~:text=%3B%0A%09%7D%3B%0A%7D%3B-,%26tcb0%20%7B,-timer0%3A%20timer

> 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
> 

-- 
Thanks and Regards,
Varshini Rajendran.