linux-kernel - Re: [PATCH v6 2/8] regulator: dt-bindings: Document max8997-pmic nodes

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 08 Jan 2021 15:16:48 +0000
From:   Timon Baetz <timon.baetz@...tonmail.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Lee Jones <lee.jones@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-pm@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v6 2/8] regulator: dt-bindings: Document max8997-pmic nodes

On Wed, 6 Jan 2021 14:59:31 +0000, Mark Brown wrote:
> On Tue, Jan 05, 2021 at 05:55:29PM +0100, Krzysztof Kozlowski wrote:
> > On Mon, Jan 04, 2021 at 09:24:49PM +0000, Mark Brown wrote:  
> 
> > > I'm not sure I follow, sorry?  Either the core driver can parse the
> > > bindings enough to know what children it has or (probably better) it can
> > > instantiate the children unconditionally and then the function drivers
> > > can figure out if they need to do anything.  
> 
> > Currently the MFD parent/core driver will instantiate children
> > unconditionally.  It would have to be adapted. With proposed bindings -
> > nothing to change.  MFD core already does the thing.  
> 
> We're not talking massive amounts of code here, but we are talking ABI
> for a DT update.
> 
> > The point is that function drivers should not be even bound, should not
> > start to probe. Otherwise if they probe and fail, they will pollute the
> > dmesg/probe log with failure. With the failure coming from looking for
> > missing of_node or any other condition from parent/core driver.  
> 
> There will only be an error message if one is printed, if we can do a
> definitive -ENODEV there should be no need to print an error.
> 
> > > > Another point, is that this reflects the real hardware. The same as we
> > > > model entire SoC as multiple children of soc node (with their own
> > > > properties), here we represent smaller chip which also has
> > > > sub-components.  
> 
> > > Components we're calling things like "extcon"...  
> 
> > I am rather thinking about charger, but yes, extcon as well. Either you
> > have USB socket (and want to use associated logic) or not.  
> 
> Right, I'm just saying we don't need to add new device nodes reflecting
> implementation details into the DT to do that.

I'm not sure I can contribute that much to this discussion (this is my
first proper kernel patch, also I don't really understand the argument).
FWIW I looked at other MFD devices while implementing this like max77836, 
max77693, max77650, max77843 (just to name a few). 
Assigning of_node to sub-devices using sub-nodes with compatible strings 
seemed to be a common pattern for MFD devices.
Muic needs a node to be used with extcon_get_edev_by_phandle().
Charger needs a node to reference a regulator.