linux-kernel - Re: [PATCH V4 2/6] dt-bindings: regulator: Add pm8008 regulator bindings

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]

Message-ID: <30ec6b4c-f2a8-d80e-a542-1c2b3f30c049@quicinc.com>
Date:   Mon, 20 Dec 2021 18:14:00 +0530
From:   "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@...cinc.com>
To:     Mark Brown <broonie@...nel.org>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>, <swboyd@...omium.org>,
        <collinsd@...eaurora.org>, <subbaram@...eaurora.org>,
        Das Srinagesh <gurus@...eaurora.org>,
        <linux-arm-msm@...r.kernel.org>,
        "Lee Jones" <lee.jones@...aro.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V4 2/6] dt-bindings: regulator: Add pm8008 regulator
 bindings


On 12/6/2021 7:17 PM, Mark Brown wrote:
> On Mon, Dec 06, 2021 at 07:13:02PM +0530, Satya Priya Kakitapalli (Temp) wrote:
>> On 11/25/2021 8:54 PM, Mark Brown wrote:
>>> On Fri, Nov 19, 2021 at 03:12:29PM +0530, Satya Priya wrote:
>>>> +properties:
>>>> +  compatible:
>>>> +    const: qcom,pm8008-regulators
>>> Why are we adding a separate compatible for this when we already know
>>> that this is a pm8008 based on the parent?
>> For the regulator driver to be probed we do need a separate compatible
>> right? may be I didn't get your question..
>> My understanding is we should have a separate compatible for each peripheral
>> under the parent mfd node.. like gpios, temp alarm, regulators etc..
> No, the MFD can register whatever children it likes without needing any
> help from the DT.

I think this is possible by using of_platform_bus_probe() API. But, the 
mfd driver uses of_platform_populate() API, this needs all device nodes 
to have a 'compatible' property unlike the of_platform_bus_probe() API.

All other MFD upstream drivers are also using the same API and 
registering the child regulators by using separate compatible strings.


>>>> +  vdd_l1_l2-supply:
>>>> +    description: Input supply phandle of ldo1 and ldo2 regulators.
>>> These supply nodes should be chip level, they're going into the chip and
>>> in general the expectation is that you should be able to describe the
>>> supplies going into a device without worrying about how or if any
>>> particular OS splits things up.
>> So, if i understand correctly, we don't have to mention these in the
>> documentation as these are handled at framework level?
> No.  I'm saying you should document these at the chip level, they do
> need to be documented though.

By chip level do you mean "pm8008.yaml" documentation? If so, yes, I can 
move these to pm8008.yaml and change DT accordingly.