From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Dan Murphy <dmurphy@ti.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
mazziesaccount@gmail.com, Lee Jones <lee.jones@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>,
Alessandro Zummo <a.zummo@towertech.it>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-leds@vger.kernel.org, linux-rtc@vger.kernel.org
Subject: Re: [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC
Date: Thu, 17 Oct 2019 16:28:23 +0200 [thread overview]
Message-ID: <20191017142823.GF3125@piout.net> (raw)
In-Reply-To: <c1e41315-42ad-fb9b-c9db-8b07d4293166@ti.com>
On 17/10/2019 09:04:48-0500, Dan Murphy wrote:
> Matt
>
> On 10/17/19 4:53 AM, Matti Vaittinen wrote:
> > ROHM BD71828 power management IC has two LED outputs for charge status
> > and button pressing indications. The LED outputs can also be forced
> > bs SW so add driver allowing to use these LEDs for other indications
> s/bs/by
> > as well.
> >
> > Leds are controlled by SW using 'Force ON' bits. Please note the
> > constrains mentioned in data-sheet:
> > 1. If one LED is forced ON - then also the other LED is forced.
> > => You can't use SW control to force ON one LED and allow HW
> > to control the other.
> > 2. You can't force both LEDs OFF. If the FORCE bit for both LED's is
> > zero, then LEDs are controlled by HW and indicate button/charger
> > states as explained in data-sheet.
> >
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> > drivers/leds/Kconfig | 10 ++++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-bd71828.c | 97 +++++++++++++++++++++++++++++++++++++
> > 3 files changed, 108 insertions(+)
> > create mode 100644 drivers/leds/leds-bd71828.c
> >
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index b0fdeef10bd9..ec59f28bcb39 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -529,6 +529,16 @@ config LEDS_BD2802
> > This option enables support for BD2802GU RGB LED driver chips
> > accessed via the I2C bus.
> > +config LEDS_BD71828
> > + tristate "LED driver for LED pins on ROHM BD71828 PMIC"
> > + depends on LEDS_CLASS
> doesn't this have a dependency on MFD_ROHM_BD71828
> > + depends on I2C
> > + help
> > + This option enables support for LED outputs located on ROHM
> > + BD71828 power management IC. ROHM BD71828 has two led output pins
> > + which can be left to indicate HW states or controlled by SW. Say
> > + yes here if you want to enable SW control for these LEDs.
> > +
>
> Add module statement
>
>
> > config LEDS_INTEL_SS4200
> > tristate "LED driver for Intel NAS SS4200 series"
> > depends on LEDS_CLASS
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 41fb073a39c1..2a8f6a8e4c7c 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_LEDS_AN30259A) += leds-an30259a.o
> > obj-$(CONFIG_LEDS_BCM6328) += leds-bcm6328.o
> > obj-$(CONFIG_LEDS_BCM6358) += leds-bcm6358.o
> > obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
> > +obj-$(CONFIG_LEDS_BD71828) += leds-bd71828.o
> > obj-$(CONFIG_LEDS_CPCAP) += leds-cpcap.o
> > obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
> > obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
> > diff --git a/drivers/leds/leds-bd71828.c b/drivers/leds/leds-bd71828.c
> > new file mode 100644
> > index 000000000000..2427619444f5
> > --- /dev/null
> > +++ b/drivers/leds/leds-bd71828.c
> > @@ -0,0 +1,97 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2019 ROHM Semiconductors
> > +
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/leds.h>
> > +#include <linux/mfd/rohm-bd71828.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/slab.h>
> > +
> > +#define BD71828_LED_TO_DATA(l) ((l)->id == ID_GREEN_LED ? \
> > + container_of((l), struct bd71828_leds, green) : \
> > + container_of((l), struct bd71828_leds, amber))
>
> I don't think we should be defining the color as the variable. The outputs
> can drive any color LED.
>
>
> > +
> > +enum {
> > + ID_GREEN_LED,
> > + ID_AMBER_LED,
> > + ID_NMBR_OF,
> > +};
> > +
>
> Please use the color_id in linux/include/dt-bindings/leds/common.h
>
>
> > +struct bd71828_led {
> > + int id;
> > + struct led_classdev l;
> > + u8 force_mask;
> > +};
> > +
> > +struct bd71828_leds {
> > + struct rohm_regmap_dev *bd71828;
> > + struct bd71828_led green;
> > + struct bd71828_led amber;
> > +};
> > +
> > +static int bd71828_led_brightness_set(struct led_classdev *led_cdev,
> > + enum led_brightness value)
> > +{
> > + struct bd71828_led *l = container_of(led_cdev, struct bd71828_led, l);
> > + struct bd71828_leds *data;
> > + unsigned int val = BD71828_LED_OFF;
> > +
> > + data = BD71828_LED_TO_DATA(l);
> > + if (value != LED_OFF)
> > + val = BD71828_LED_ON;
> > +
> > + return regmap_update_bits(data->bd71828->regmap, BD71828_REG_LED_CTRL,
> > + l->force_mask, val);
> > +}
> > +
> > +static int bd71828_led_probe(struct platform_device *pdev)
> > +{
> > + struct rohm_regmap_dev *bd71828;
> > + struct bd71828_leds *l;
> > + struct bd71828_led *g, *a;
> > + static const char *GNAME = "bd71828-green-led";
> > + static const char *ANAME = "bd71828-amber-led";
> The LED class creates the name it can get it from the DT.
> > + int ret;
> > +
> > + pr_info("bd71828 LED driver probed\n");
> > +
> > + bd71828 = dev_get_drvdata(pdev->dev.parent);
> > + l = devm_kzalloc(&pdev->dev, sizeof(*l), GFP_KERNEL);
> > + if (!l)
> > + return -ENOMEM;
> > + l->bd71828 = bd71828;
> > + a = &l->amber;
> > + g = &l->green;
> > + a->id = ID_AMBER_LED;
> > + g->id = ID_GREEN_LED;
> > + a->force_mask = BD71828_MASK_LED_AMBER;
> > + g->force_mask = BD71828_MASK_LED_GREEN;
> > +
> > + a->l.name = ANAME;
> > + g->l.name = GNAME;
> > + a->l.brightness_set_blocking = bd71828_led_brightness_set;
> > + g->l.brightness_set_blocking = bd71828_led_brightness_set;
> > +
> > + ret = devm_led_classdev_register(&pdev->dev, &g->l);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_led_classdev_register(&pdev->dev, &a->l);
> > +}
> > +
>
> This looks different. Not sure why you register both LEDs in this probe.
>
> You can use the DT to define both LEDs and then each will be probed and
> registered separately.
>
> This is how it is commonly done.
>
> You can reference the LM36274 led driver as this is a MFD device to the
> ti-lmu.c in the MFD directory.
>
>
> > +static struct platform_driver bd71828_led_driver = {
> > + .driver = {
> > + .name = "bd71828-led",
> > + },
> > + .probe = bd71828_led_probe,
> > +};
> > +
> > +module_platform_driver(bd71828_led_driver);
> > +
> > +MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
> > +MODULE_DESCRIPTION("ROHM BD71828 LED driver");
> > +MODULE_LICENSE("GPL");
> GPL v2
GPL is fine, see bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL"
vs. "GPL v2" bogosity")
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-10-17 14:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 9:40 [RFC PATCH 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
2019-10-17 9:41 ` [RFC PATCH 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-10-17 9:42 ` [RFC PATCH 02/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-10-17 9:43 ` [RFC PATCH 03/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-10-17 9:44 ` [RFC PATCH 04/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-10-17 9:44 ` [RFC PATCH 05/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-10-17 9:48 ` [RFC PATCH 06/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-10-17 9:50 ` [RFC PATCH 07/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
2019-10-17 9:51 ` [RFC PATCH 08/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
2019-10-17 9:52 ` [RFC PATCH 09/13] mfd: rtc: support RTC on ROHM BD71828 with BD70528 driver Matti Vaittinen
2019-10-17 10:12 ` Alexandre Belloni
2019-10-17 10:36 ` Vaittinen, Matti
2019-10-17 10:48 ` Alexandre Belloni
2019-10-21 5:29 ` Vaittinen, Matti
2019-10-23 10:27 ` Vaittinen, Matti
2019-10-29 13:50 ` Alexandre Belloni
2019-10-29 14:08 ` Vaittinen, Matti
2019-10-17 9:53 ` [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-10-17 12:45 ` Bartosz Golaszewski
2019-10-21 7:00 ` Vaittinen, Matti
2019-10-21 14:36 ` Bartosz Golaszewski
2019-10-21 14:56 ` Vaittinen, Matti
2019-10-22 13:19 ` Vaittinen, Matti
2019-10-17 9:53 ` [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
2019-10-17 14:04 ` Dan Murphy
2019-10-17 14:28 ` Alexandre Belloni [this message]
2019-10-21 8:00 ` Vaittinen, Matti
2019-10-21 19:09 ` Jacek Anaszewski
2019-10-22 12:40 ` Vaittinen, Matti
2019-10-22 17:40 ` Jacek Anaszewski
2019-10-23 8:37 ` Vaittinen, Matti
2019-10-23 21:59 ` Jacek Anaszewski
2019-10-24 8:15 ` Vaittinen, Matti
2019-10-24 22:04 ` Jacek Anaszewski
2019-10-25 7:07 ` Vaittinen, Matti
2019-10-25 13:24 ` Rob Herring
2019-10-25 14:37 ` Vaittinen, Matti
2019-10-25 15:47 ` Rob Herring
2019-10-29 13:29 ` Vaittinen, Matti
2019-10-17 9:55 ` [RFC PATCH 12/13] dt-bindings: mfd: Document ROHM BD71282 bindings Matti Vaittinen
2019-10-17 14:18 ` Dan Murphy
2019-10-21 8:03 ` Vaittinen, Matti
2019-10-17 9:57 ` [RFC PATCH 13/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191017142823.GF3125@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=mturquette@baylibre.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).