v3 -> v4:
Removed tps6105 mfd patch - it was accepted (Mark Brown).
Use the new LED registration API - suggested by Jacek Anaszewski.
Updated led dt bindings to document function, color usage.
v2 -> v3:
Removed tps6105x regulator patch - it was accepted (Mark Brown).
Removed devicetree/platdata bindings for tps6105x led naming.
I can test only with a 4.19 vendor kernel, which does not have the
latest led naming infrastructure (function/color). Drop devicetree/
fwnode/pdata led naming in favour of hard-coding to "tps6105x::torch",
so the patch can be tested by me, yet remains acceptable to upstream.
v1 -> v2:
Select chip operational mode by looking at subnode name, _not_ its
compatible property. Suggested by Mark Brown.
I needed led operation for this mfd chip, so I added a very simple
driver for this.
My platform (arm imx6q) is devicetree-based, so I added optional
devicetree support for this chip and its sub-drivers.
Sven Van Asbroeck (2):
leds: tps6105x: add driver for mfd chip led mode
dt-bindings: mfd: update TI tps6105x chip bindings
.../devicetree/bindings/mfd/tps6105x.txt | 47 ++++++++++-
drivers/leds/Kconfig | 10 +++
drivers/leds/Makefile | 1 +
drivers/leds/leds-tps6105x.c | 83 +++++++++++++++++++
4 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 drivers/leds/leds-tps6105x.c
--
2.17.1
The driver has been extended to optionally get its operational
mode, regulator init data and led naming from the devicetree.
Tree: next-20191118
Signed-off-by: Sven Van Asbroeck <[email protected]>
---
.../devicetree/bindings/mfd/tps6105x.txt | 47 ++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
index 93602c7a19c8..1fc9aa3ed882 100644
--- a/Documentation/devicetree/bindings/mfd/tps6105x.txt
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -7,11 +7,56 @@ Required properties:
- compatible: "ti,tps61050" or "ti,tps61052"
- reg: Specifies the I2C slave address
-Example:
+Optional sub-node:
+
+This subnode selects the chip's operational mode.
+There can be at most one single available subnode.
+
+- regulator: presence of this sub-node puts the chip in regulator mode.
+ see Documentation/devicetree/bindings/regulator/regulator.txt
+
+- led: presence of this sub-node puts the chip in led mode.
+ Optional properties:
+ - function : see Documentation/devicetree/bindings/leds/common.txt
+ - color : see Documentation/devicetree/bindings/leds/common.txt
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ (deprecated)
+
+Example (GPIO operation only):
+
+i2c0 {
+ tps61052@33 {
+ compatible = "ti,tps61052";
+ reg = <0x33>;
+ };
+};
+
+Example (GPIO + regulator operation):
i2c0 {
tps61052@33 {
compatible = "ti,tps61052";
reg = <0x33>;
+
+ regulator {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+ };
+};
+
+Example (GPIO + led operation):
+
+#include <dt-bindings/leds/common.h>
+
+i2c0 {
+ tps61052@33 {
+ compatible = "ti,tps61052";
+ reg = <0x33>;
+
+ led {
+ color = <LED_COLOR_ID_WHITE>;
+ };
};
};
--
2.17.1
Hi Sven,
Thank you for the updated set.
For both patches:
Acked-by: Jacek Anaszewski <[email protected]>
Best regards,
Jacek Anaszewski
On 11/21/19 3:27 PM, Sven Van Asbroeck wrote:
> v3 -> v4:
> Removed tps6105 mfd patch - it was accepted (Mark Brown).
>
> Use the new LED registration API - suggested by Jacek Anaszewski.
>
> Updated led dt bindings to document function, color usage.
>
> v2 -> v3:
> Removed tps6105x regulator patch - it was accepted (Mark Brown).
>
> Removed devicetree/platdata bindings for tps6105x led naming.
> I can test only with a 4.19 vendor kernel, which does not have the
> latest led naming infrastructure (function/color). Drop devicetree/
> fwnode/pdata led naming in favour of hard-coding to "tps6105x::torch",
> so the patch can be tested by me, yet remains acceptable to upstream.
>
> v1 -> v2:
> Select chip operational mode by looking at subnode name, _not_ its
> compatible property. Suggested by Mark Brown.
>
> I needed led operation for this mfd chip, so I added a very simple
> driver for this.
>
> My platform (arm imx6q) is devicetree-based, so I added optional
> devicetree support for this chip and its sub-drivers.
>
> Sven Van Asbroeck (2):
> leds: tps6105x: add driver for mfd chip led mode
> dt-bindings: mfd: update TI tps6105x chip bindings
>
> .../devicetree/bindings/mfd/tps6105x.txt | 47 ++++++++++-
> drivers/leds/Kconfig | 10 +++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-tps6105x.c | 83 +++++++++++++++++++
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 drivers/leds/leds-tps6105x.c
>
On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
<[email protected]> wrote:
>
> For both patches:
>
> Acked-by: Jacek Anaszewski <[email protected]>
Thank you Jacek. To get accepted in a maintainer tree, does this
patch need more acks/reviews?
Should I continue to include it in new patch set versions if it doesn't
change?
On 11/22/19 2:36 PM, Sven Van Asbroeck wrote:
> On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
> <[email protected]> wrote:
>>
>> For both patches:
>>
>> Acked-by: Jacek Anaszewski <[email protected]>
>
> Thank you Jacek. To get accepted in a maintainer tree, does this
> patch need more acks/reviews?
It should get ack from Pavel Machek since he now maintains LED tree.
I'd say that it should be merged in one batch with the related change
to the MFD driver, but this is to be agreed upon by Pavel and Lee, via
which tree it will go.
> Should I continue to include it in new patch set versions if it doesn't
> change?
You can include it, and add my ack.
However, you could remove also below lines, since you switched
to using color DT property and a new LED registration API:
- init_data.devicename = "tps6105x";
- init_data.default_label = ":torch";
--
Best regards,
Jacek Anaszewski
On Thu, 21 Nov 2019 09:27:26 -0500, Sven Van Asbroeck wrote:
> The driver has been extended to optionally get its operational
> mode, regulator init data and led naming from the devicetree.
>
> Tree: next-20191118
> Signed-off-by: Sven Van Asbroeck <[email protected]>
> ---
> .../devicetree/bindings/mfd/tps6105x.txt | 47 ++++++++++++++++++-
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <[email protected]>
Hi Pavel,
On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
<[email protected]> wrote:
>
> For both patches:
> Acked-by: Jacek Anaszewski <[email protected]>
Is there anything I can do to help get these into your tree?
The other patches in the set have already been taken by their
respective maintainers.
On Thu, 21 Nov 2019, Sven Van Asbroeck wrote:
> The driver has been extended to optionally get its operational
> mode, regulator init data and led naming from the devicetree.
s/led/LED/
> Tree: next-20191118
Why is this in your commit message?
> Signed-off-by: Sven Van Asbroeck <[email protected]>
> ---
> .../devicetree/bindings/mfd/tps6105x.txt | 47 ++++++++++++++++++-
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> index 93602c7a19c8..1fc9aa3ed882 100644
> --- a/Documentation/devicetree/bindings/mfd/tps6105x.txt
> +++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> @@ -7,11 +7,56 @@ Required properties:
> - compatible: "ti,tps61050" or "ti,tps61052"
> - reg: Specifies the I2C slave address
>
> -Example:
> +Optional sub-node:
> +
> +This subnode selects the chip's operational mode.
> +There can be at most one single available subnode.
> +
> +- regulator: presence of this sub-node puts the chip in regulator mode.
> + see Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +- led: presence of this sub-node puts the chip in led mode.
> + Optional properties:
> + - function : see Documentation/devicetree/bindings/leds/common.txt
> + - color : see Documentation/devicetree/bindings/leds/common.txt
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + (deprecated)
Nit:
Could you please use relative paths here.
If you line up the ':', it would look slightly cleaner.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee, thank you for the review.
On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <[email protected]> wrote:
>
> > Tree: next-20191118
>
> Why is this in your commit message?
I have been posting patches against various maintainer trees lately, which
will not apply to mainline or next. So I have been including base tree
information in the patch itself.
Base-tree info on patches is high on developers' wish list, but not yet
standardized. This was discussed at the 2019 kernel maintainers
summit:
https://lwn.net/Articles/803619/
On Mon, 09 Dec 2019, Sven Van Asbroeck wrote:
> Hi Lee, thank you for the review.
>
> On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <[email protected]> wrote:
> >
> > > Tree: next-20191118
> >
> > Why is this in your commit message?
>
> I have been posting patches against various maintainer trees lately, which
> will not apply to mainline or next. So I have been including base tree
> information in the patch itself.
>
> Base-tree info on patches is high on developers' wish list, but not yet
> standardized. This was discussed at the 2019 kernel maintainers
> summit:
> https://lwn.net/Articles/803619/
NB: I haven't seen this discussion (or opened this link just yet).
It's no problem to have it in the submission, but it would be better
to have it *below* the '--' with the diff, such that if it is applied,
it doesn't end up in the kernel's Git history.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, 10 Dec 2019, Lee Jones wrote:
> On Mon, 09 Dec 2019, Sven Van Asbroeck wrote:
>
> > Hi Lee, thank you for the review.
> >
> > On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <[email protected]> wrote:
> > >
> > > > Tree: next-20191118
> > >
> > > Why is this in your commit message?
> >
> > I have been posting patches against various maintainer trees lately, which
> > will not apply to mainline or next. So I have been including base tree
> > information in the patch itself.
> >
> > Base-tree info on patches is high on developers' wish list, but not yet
> > standardized. This was discussed at the 2019 kernel maintainers
> > summit:
> > https://lwn.net/Articles/803619/
>
> NB: I haven't seen this discussion (or opened this link just yet).
>
> It's no problem to have it in the submission, but it would be better
> to have it *below* the '--' with the diff, such that if it is applied,
> it doesn't end up in the kernel's Git history.
Obviously that was meant to be '---'.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog