Messages in this thread | | | Date | Fri, 2 Jul 2021 20:10:12 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning to debug |
| |
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.
| |