[U-Boot] [PATCH] power: extend prefix match to regulator-name property

[Chen-Yu Tsai]

On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack <fb at ltec.ch> wrote:
> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
>> On Mon, Oct 9, 2017 at 6:04 PM, Felix Brack <fb at ltec.ch> wrote:
>>> This patch extends pmic_bind_children prefix matching. In addition to
>>> the node name the property regulator-name is used while trying to match
>>> prefixes. This allows assigning different drivers to regulator nodes
>>> named regulator at 1 and regulator at 10 for example.
>>
>> No. See the regulator bindings:
>>
>> Optional properties:
>> - regulator-name: A string used as a descriptive name for regulator outputs
>>
> The actual regulator.txt states:
>
> Optional properties:
>  - regulator-name: a string, required by the regulator uclass
>
> This was the reason for choosing the regulator-name property.

Mine was from the Linux Kernel. Are there two sets of bindings?
Shouldn't there be just one?

>> This can vary from board to board. The name should match the power rail
>> name of the board (which may not be the same as the regulator chip's
>> output name).
>>
> Exactly. I totally agree but as stated in an earlier post: I did not
> define the names for the regulators and modifying them is almost
> certainly not the right way to go. Let me explain this briefly. The
> regulator names I'm trying to match are those from tps65910.dtsi, an
> include file. The exact same file is part of the LINUX kernel. Therefore
> I resigned suggesting the modification of the node names.

First, it is an include file. Board files are free to override the
name. We did that for sunxi at first, have the .dtsi file provide
some default names, then have board .dts files override them with
names that make more sense. Later on we just dropped the default
names altogether.

The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
And also am335x-evm.dts, which the tps65910.dtsi was tested with.

Now I couldn't find the binding document for tps65910, but looking
at tps65217 instead, it says:

- regulators: list of regulators provided by this controller, must be named
  after their hardware counterparts: dcdc[1-3] and ldo[1-4]

And indeed that is what's used in the example.

So clearly the dts files aren't following the binding.

>
>> If you have multiple regulator nodes which need to be differentiated,
>> you need to use the deprecated "regulator-compatible" property, or just
>> use the standard compatible property.
>>
> Good point. I would not use a deprecated property but the compatible
> property seems reasonable to me. So you agree that the patch's concept
> could be retained while substituting the node-name property by the
> compatible property?

If you're going to modify the binding and/or device tree files, please
do it in both places. Ideally the platform should have one canonical
source for them.

Linux's standard regulator DT matching code only matches against node
names and the deprecated "regulator-compatible" property. Not even the
standard "compatible" is used, though I see a few PMICs using that.
So even if you do get them working this way in U-boot, it's still not
going to work in Linux, and you might get other comments when pushing
your changes.

Regards
ChenYu