linux-kernel - Re: [PATCH] ARM: dts: at91: add serial MFD sub-node for usart

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: <6313146b-9b2c-097b-9852-d85fc1bf16b4@microchip.com>
Date:   Mon, 2 Nov 2020 12:41:43 +0000
From:   <Codrin.Ciubotariu@...rochip.com>
To:     <lee.jones@...aro.org>
CC:     <Nicolas.Ferre@...rochip.com>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <richard.genoud@...il.com>,
        <alexandre.belloni@...tlin.com>, <Ludovic.Desroches@...rochip.com>
Subject: Re: [PATCH] ARM: dts: at91: add serial MFD sub-node for usart

On 02.11.2020 11:07, Lee Jones wrote:
> On Fri, 30 Oct 2020, Codrin.Ciubotariu@...rochip.com wrote:
> 
>> On 30.10.2020 15:38, Nicolas Ferre wrote:
>>> On 30/10/2020 at 12:07, Codrin Ciubotariu wrote:
>>>> The "atmel,at91sam9260-usart" driver is a MFD driver, so it needs
>>>> sub-nodes
>>>> to match the registered platform device. For this reason, we add a serial
>>>> subnode to all the "atmel,at91sam9260-usart" serial compatible nods. This
>>>> will also remove the boot warning:
>>>> "atmel_usart_serial: Failed to locate of_node [id: -2]"
>>>
>>> I don't remember this warning was raised previously even if the MFD
>>> driver was added a while ago (Sept. 2018).
>>>
>>> I would say it's due to 466a62d7642f ("mfd: core: Make a best effort
>>> attempt to match devices with the correct of_nodes") which was added on
>>> mid August and corrected with 22380b65dc70 ("mfd: mfd-core: Ensure
>>> disabled devices are ignored without error") but maybe not covering our
>>> case.
>>
>> Well, it's not covering our enabled devices.
>>
>>>
>>> So, well, I don't know what's the best option to this change. Moreover,
>>> I would say that all other USART related properties go into the child
>>> not if there is a need for one.
>>>
>>> Lee, I suspect that we're not the only ones experiencing this ugly
>>> warning during the boot log: can you point us out how to deal with it
>>> for our existing atmel_serial.c users?
>>
>> My understading is that platform devices registered by MFD should have a
>> correspondig DT node. The parrent properties are also available for the
>> other usart device (usart-spi), so I think we should keep them in the
>> parrent.
> 
> Device Tree and MFD are unrelated.  MFDs don't even exist - they are a
> figment of a Linux Kernel Engineer's imagination - we made them up!
> 
> The DT should describe the hardware and nothing else.  If we wish to
> mess with devices for our own gain i.e. organise them into different
> subsystems, we have to do that in software.  That's what MFD is for.

You are right, I mixed up things. We are using the MFD here to describe 
a hardware USART IP that can also function as an SPI, but not at the 
same time. The decision of whether the IP works as a normal USART or an 
SPI is DT configurable, at this moment. It is doing more than just 
describing the HW, but I don't know how to describe it otherwise.

Best regards,
Codrin