On 02.11.2020 11:07, Lee Jones wrote:

On Fri, 30 Oct 2020, Codrin.Ciubotariu@microchip.com wrote:

quoted

On 30.10.2020 15:38, Nicolas Ferre wrote:

quoted

On 30/10/2020 at 12:07, Codrin Ciubotariu wrote:

quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel