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: <20201102090724.GG4127@dell>
Date:   Mon, 2 Nov 2020 09:07:24 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Codrin.Ciubotariu@...rochip.com
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 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. 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog