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

[Codrin.Ciubotariu]

On 02.11.2020 11:07, Lee Jones wrote:
> On Fri, 30 Oct 2020, Codrin.Ciubotariu@xxxxxxxxxxxxx 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