Messages in this thread | | | From | Yunus Bas <> | Subject | Re: [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning to debug | Date | Mon, 5 Jul 2021 07:24:36 +0000 |
| |
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.
| |