linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).