Re: [PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

[Bjorn Andersson]

On Fri, Feb 13, 2015 at 2:13 PM, Andy Gross <agross@xxxxxxxxxxxxxx> wrote:
> On Thu, Jan 29, 2015 at 05:51:06PM -0800, Bjorn Andersson wrote:
>> Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx>
>> ---
>
>>       #include <dt-bindings/mfd/qcom-rpm.h>
>> @@ -66,5 +237,18 @@ frequencies.
>>
>>               #address-cells = <1>;
>>               #size-cells = <0>;
>> +
>> +             pm8921_smps1: pm8921-smps1 {
>> +                     compatible = "qcom,rpm-pm8921-smps";
>> +                     reg = <QCOM_RPM_PM8921_SMPS1>;
>> +
>> +                     regulator-min-microvolt = <1225000>;
>> +                     regulator-max-microvolt = <1225000>;
>> +                     regulator-always-on;
>> +
>> +                     bias-pull-down;
>> +
>> +                     qcom,switch-mode-frequency = <3200000>;
>> +             };
>>       };
>
> My only comment here is that most (all but one) of the other mfd regulator
> devices use regulators {}.  Still wonder if that's what we should do.
>

Looking at the existing mfds they all have a list in the code of the
regulators supported on a certain mfd. Through the use of
regulator_desc.{of_match,regulators_node} these regulators are
populated with properties from of_nodes matched by name (of_match)
under the specified node (regulators_node).
But as we've discussed in other cases it's not desirable to maintain
these lists for the various variants of Qualcomm platforms, so I did
choose to go with "standalone" platform devices - with matching
through compatible and all.

But that's all implementation, looking at the binding itself a
regulator {} (clocks{} and msm_bus{}) would serve as a sort of
grouping of children based on type. Except for the implications this
has on the implementation I don't see much benefit of this (and in our
case the implementation would suffer from the extra grouping).


Let me know what you think, I based these ideas on just reading the
existing code and bindings, and might very well have missed something.

> Otherwise,
>
> Reviewed-by: Andy Gross <agross@xxxxxxxxxxxxxx>
>

Thanks

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/