Message-ID: <c2ca83c4d67a47a8e104e5c54a4920cac56312b1.camel@phytec.de>
Date:   Mon, 5 Jul 2021 07:24:36 +0000
From:   Yunus Bas <Y.Bas@...tec.de>
To:     "daniel.thompson@...aro.org" <daniel.thompson@...aro.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
CC:     "stwiss.opensource@...semi.com" <stwiss.opensource@...semi.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning
 to debug

Thank you for the clarification. I'm now aware on how to handle MFD's
in the devicetree. But given this, the default behavior of MFD's should
definitely be documented since i could see many other devicetree
examples handling this also not in the proper manner.

Regards, Yunus

Am Freitag, dem 02.07.2021 um 20:10 +0100 schrieb Daniel Thompson:
> On Fri, Jul 02, 2021 at 07:36:07PM +0100, Lee Jones wrote:
> > On Fri, 02 Jul 2021, Daniel Thompson wrote:
> > 
> > > On Thu, Jul 01, 2021 at 03:34:43PM +0000, Yunus Bas wrote:
> > > > Am Mittwoch, dem 30.06.2021 um 13:33 +0100 schrieb Lee Jones:
> > > > > On Wed, 30 Jun 2021, Daniel Thompson wrote:
> > > > > 
> > > > > > On Wed, Jun 30, 2021 at 07:27:32AM +0000, Yunus Bas wrote:
> > > > > > > Am Dienstag, dem 29.06.2021 um 14:39 +0100 schrieb Lee
> > > > > > > Jones:
> > > > > > > Imagine only required parts of the MFD is connected to
> > > > > > > the
> > > > > > > designed
> > > > > > > system and unrequired parts are not. In that case, fully
> > > > > > > describing the
> > > > > > > MFD in the devicetree wouldn't represent the system at
> > > > > > > all.
> > > > > > 
> > > > > > To describe hardware that is present but unused we would
> > > > > > normally
> > > > > > use
> > > > > > status = "disabled".
> > > > > > 
> > > > > > So if, for example, your board cannot use the RTC for some
> > > > > > reason
> > > > > > (perhaps the board has no 32KHz oscillator?) then the
> > > > > > DA9062 still
> > > > > > contains the hardware but it is useless. Such hardware
> > > > > > could be
> > > > > > described as:
> > > > > > 
> > > > > > da9062_rtc: rtc {
> > > > > >     compatible = "dlg,da9062-rtc";
> > > > > >     status = "disabled";
> > > > > > }
> > > > > > 
> > > > > > Is this sufficient to suppress the warnings when the
> > > > > > hardware is
> > > > > > not fully described?
> > > <snip>
> > > > > 
> > > > > Right.  This is a potential solution.
> > > > 
> > > > @Daniel, you hit the nail on the head :). Thank you for that.
> > > > 
> > > > This solution would indeed surpress the warnings, but what is
> > > > the
> > > > benefit of this? We would define never used device nodes just
> > > > to
> > > > satisfy the driver.
> > > 
> > > I would say that doing so resolves an awkward ambiguity of
> > > interpretation w.r.t. the bindings.
> > > 
> > > 1. The MFD device compatible "dlg,da9062" tells the OS that we
> > >    have an DA9062. An DA9062 contains six functions and this can
> > > be
> > >    inferred *entirely* from the MFD compatible string. We do not
> > >    need any subnodes to tell us that a DA9062 contains an RTC.
> > > The OS
> > >    can (and in this case, does) already know that there is an RTC
> > >    because we have a DA9062 (and a datasheet).
> > > 
> > > 2. The default behaviour when a node has no status field is to
> > >    assume that is is *enabled*.
> > > 
> > > Based on #1 and #2 above then assuming that a DT that omits the
> > > sub-nodes actually means "disable the RTC" is risky. #2 might
> > > actually make it more natural to assume that the device is
> > > present and
> > > functional because there is no status field to tell MFD *not* to
> > > initialize it.
> > 
> > Exactly.  Nicely put.
> > 
> > > That leaves us in a situation where there is no way to correctly
> > > guess
> > > the authors intent when sub-nodes are omitted from the DT.
> > 
> > > Given this is something of a corner case and the documentation is
> > > ambiguous then a warning of the author does not clearly resolve
> > > the
> > > ambiguity seems reasonable.
> > 
> > I'm having trouble parsing this part.
> 
> That's quite reasonable because was is written is nonsense!
> Perhaps s/warning of the author/warning if the author/ will help
> but there are still too many words to say something very simple.
> The whole last paragraph could simply say:
> 
>   The bindings documentation is ambiguous so is it reasonable
>   for the OS to issue a warning when the devicetree author does
>   not clearly resolve the ambiguity.
> 
> This is still a long sentence but at least it is no longer a
> complicated one!
> 
> 
> Daniel.

-- 
Mit freundlichen Grüßen
Yunus Bas

-Software Engineer-
PHYTEC Messtechnik GmbH
Robert-Koch-Str. 39
55129 Mainz
Germany
Tel.: +49 (0)6131 9221- 466
Web: www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz | St.Nr. 266500608, DE
149059855
This E-Mail may contain confidential or privileged information. If you
are not the intended recipient (or have received this E-Mail in error)
please notify the sender immediately and destroy this E-Mail. Any
unauthorized copying, disclosure or distribution of the material in
this E-Mail is strictly forbidden.

Powered by blists - more mailing lists