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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210630105557.eaktwdz5p6yzuron@maple.lan>
Date:   Wed, 30 Jun 2021 11:55:57 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Yunus Bas <Y.Bas@...tec.de>
Cc:     "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "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

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:
> > On Tue, 29 Jun 2021, Yunus Bas wrote:
> > > Interestingly, all subdevices defined in the driver are registered
> > > as platform devices from the MFD framework, regardless of a
> > > devicetree entry or not. The preceding code checks the subdevice
> > > cells with an additional compatible. In case a device has no
> > > devicetree entry, an irritating failed-message is printed on the
> > > display. I'm not sure if this was the intention but the framework
> > > somehow forces the users to describe all subdevices of an MFD. I
> > > think the info print is not needed. It makes more sense to set it
> > > as a debug print.
> > 
> > Actually, this has served to highlight that your DTS is not correct.
> > 
> > Why are some devices represented in DT and some aren't?
> > 
> > If anything, I'm tempted to upgrade the info() print to warn().
> 
> 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?

There is almost certainly a problem here since there is a mismatch
between mfd-core and the DA9062 DT bindings. mfd-core warns when the
hardware description is incomplete and the DA9062 (and generic mfd) DT
bindings are ambiguous about whether sub-nodes are mandatory and include
an example that contains missing compatibles rather than disabled nodes
like the above.

However it is not entirely clear to me at this point whether this should
be fixed in mfd-core or by improving the bindings documentation.


Daniel.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ