Messages in this thread | | | Subject | Re: [PATCH V4 2/6] dt-bindings: regulator: Add pm8008 regulator bindings | From | "Satya Priya Kakitapalli (Temp)" <> | Date | Mon, 20 Dec 2021 18:14:00 +0530 |
| |
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.
| |