linux-kernel - Re: [PATCH v1 1/4] tps6105x: add optional devicetree support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAGngYiXLx8rkkKPyALYyCHFyst2Ft8bCkP4uqmzXAHHqXhUvkQ@mail.gmail.com>
Date:   Mon, 18 Nov 2019 13:13:24 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Grigoryev Denis <grigoryev@...twel.ru>,
        Axel Lin <axel.lin@...ics.com>, Dan Murphy <dmurphy@...com>,
        Mark Rutland <mark.rutland@....com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH v1 1/4] tps6105x: add optional devicetree support

On Mon, Nov 18, 2019 at 12:45 PM Mark Brown <broonie@...nel.org> wrote:
>
> So this is one device that has two separate modes?  This sounds like you
> need a property specifying how the device is wired up, or possibly just
> different compatibles at the root of the device though that's not quite
> idiomatic.  Splitting this up with different devices is a bit of a Linux
> specific implementation detail.

Yes, that does make sense and sounds elegant. However, bear with me:

This mfd chip can be wired up as one of the following:
- gpio only
- gpio + regulator
- gpio + led
- gpio + flash

So I need a way to indicate this in the dt.

Imagine I do this with a text/value property, like this:

i2c0 {
        tps61052@33 {
                compatible = "ti,tps61050";
                reg = <0x33>;
                mode = "regulator"; // or
                mode = <TPS6105X_REGULATOR_MODE>;
        };
};

in this case, there is no elegant way to specify the regulator properties in
the devicetree. Except by grabbing a reference to a subnode perhaps. And then
I'd have to somehow make sure that the sub driver's device->of_node points
at this subnode, which the mfd core doesn't do automatically.

Now imagine I use a reference property:

i2c0 {
        tps61052@33 {
                compatible = "ti,tps61050";
                reg = <0x33>;
                mode = <&tps_reg>;

                tps_reg: regulator {
                        regulator-min-microvolt = <5000000>;
                        regulator-max-microvolt = <5000000>;
                        regulator-always-on;
                };
        };
};

However for this to work, I need to make sure the regulator subdriver gets a
valid dev->of_node, which the mfd core doesn't do automatically. So I'd have
to follow the 'mode' node, check that its compatible is correct, and then
manually assign the of_node to the mfd child driver (not sure how to even
do that).

So I arrived at the following:

i2c0 {
        tps61052@33 {
                compatible = "ti,tps61050";
                reg = <0x33>;

                regulator {
                        compatible = "ti,tps6105x-regulator";
                        regulator-min-microvolt = <5000000>;
                        regulator-max-microvolt = <5000000>;
                        regulator-always-on;
                };
        };
};

In this case, I only need to verify that there is at most one single subnode.
And when I specify of_compatible = "ti,tps6105x-regulator" in the mfd cell,
the mfd core will automatically assign the child driver's of_node. Nice 'n
elegant?

Would you be able to suggest a way forward?