Re: [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning to debug

[Yunus Bas]

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.