From: Pavel Machek <pavel@ucw.cz>
To: nikitos.tr@gmail.com
Cc: dmurphy@ti.com, robh+dt@kernel.org, linux-leds@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH 1/3] leds: add aw2013 driver
Date: Mon, 4 May 2020 20:00:49 +0200 [thread overview]
Message-ID: <20200504180049.GA5067@duo.ucw.cz> (raw)
In-Reply-To: <20200504162934.4693-1-nikitos.tr@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]
Hi!
> +#define AW2013_NAME "aw2013"
That's.... not really useful define. Make it NAME? Drop it?
> +#define AW2013_TIME_STEP 130
I'd add comment with /* units */.
> +#define STATE_OFF 0
> +#define STATE_KEEP 1
> +#define STATE_ON 2
We should add enum into core for this...
> +static int aw2013_chip_init(struct aw2013 *chip)
> +{
> + int i, ret;
> +
> + ret = regmap_write(chip->regmap, AW2013_GCR, AW2013_GCR_ENABLE);
> + if (ret) {
> + dev_err(&chip->client->dev, "Failed to enable the chip: %d\n",
> + ret);
> + goto error;
> + }
> +
> + for (i = 0; i < chip->num_leds; i++) {
> + ret = regmap_update_bits(chip->regmap,
> + AW2013_LCFG(chip->leds[i].num),
> + AW2013_LCFG_IMAX_MASK,
> + chip->leds[i].imax);
> + if (ret) {
> + dev_err(&chip->client->dev,
> + "Failed to set maximum current for led %d: %d\n",
> + chip->leds[i].num, ret);
> + goto error;
> + }
> + }
> +
> +error:
> + return ret;
> +}
No need for goto if you are just returning.
> +static bool aw2013_chip_in_use(struct aw2013 *chip)
> +{
> + int i;
> +
> + for (i = 0; i < chip->num_leds; i++)
> + if (chip->leds[i].cdev.brightness)
> + return true;
> +
> + return false;
> +}
How is this going to interact with ledstate == KEEP?
> +static int aw2013_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct aw2013_led *led = container_of(cdev, struct aw2013_led, cdev);
> + int ret, num;
> +
> + mutex_lock(&led->chip->mutex);
> +
> + if (aw2013_chip_in_use(led->chip)) {
> + ret = aw2013_chip_enable(led->chip);
> + if (ret)
> + return ret;
> + }
You are returning with mutex held.
> + /* Never on - just set to off */
> + if (!*delay_on)
> + return aw2013_brightness_set(&led->cdev, LED_OFF);
> +
> + /* Never off - just set to brightness */
> + if (!*delay_off)
> + return aw2013_brightness_set(&led->cdev, led->cdev.brightness);
Is this dance neccessary? Should we do it in the core somewhere?
> + } else {
> + led->imax = 1; // 5mA
> + dev_info(&client->dev,
> + "DT property led-max-microamp is missing!\n");
> + }
Lets remove the exclamation mark.
> + led->num = source;
> + led->chip = chip;
> + led->fwnode = of_fwnode_handle(child);
> +
> + if (!of_property_read_string(child, "default-state", &str)) {
> + if (!strcmp(str, "on"))
> + led->default_state = STATE_ON;
> + else if (!strcmp(str, "keep"))
> + led->default_state = STATE_KEEP;
> + else
> + led->default_state = STATE_OFF;
> + }
We should really have something in core for this. Should we support
arbitrary brightness there?
> +static void aw2013_read_current_state(struct aw2013 *chip)
> +{
> + int i, led_on;
> +
> + regmap_read(chip->regmap, AW2013_LCTR, &led_on);
> +
> + for (i = 0; i < chip->num_leds; i++) {
> + if (!(led_on & AW2013_LCTR_LE(chip->leds[i].num))) {
> + chip->leds[i].cdev.brightness = LED_OFF;
> + continue;
> + }
> + regmap_read(chip->regmap, AW2013_REG_PWM(chip->leds[i].num),
> + &chip->leds[i].cdev.brightness);
> + }
> +}
> +
> +static void aw2013_init_default_state(struct aw2013_led *led)
> +{
> + switch (led->default_state) {
> + case STATE_ON:
> + led->cdev.brightness = LED_FULL;
> + break;
> + case STATE_OFF:
> + led->cdev.brightness = LED_OFF;
> + } /* On keep - just set brightness that was retrieved previously */
> +
> + aw2013_brightness_set(&led->cdev, led->cdev.brightness);
> +}
Aha; I guess this makes "keeping" the state to work. Do you really
need that functionality?
Pretty nice driver, thanks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-05-04 18:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 16:29 [PATCH 1/3] leds: add aw2013 driver nikitos.tr
2020-05-04 16:29 ` [PATCH 2/3] dt-bindings: leds: Add binding for aw2013 nikitos.tr
2020-05-04 20:09 ` Dan Murphy
2020-05-04 16:29 ` [PATCH 3/3] dt-bindings: vendor-prefixes: Add Shanghai Awinic Technology Co., Ltd nikitos.tr
2020-05-04 18:00 ` Pavel Machek [this message]
2020-05-05 17:19 ` [PATCH 1/3] leds: add aw2013 driver Nikita Travkin
2020-05-04 19:46 ` Jacek Anaszewski
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=20200504180049.GA5067@duo.ucw.cz \
--to=pavel@ucw.cz \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=nikitos.tr@gmail.com \
--cc=robh+dt@kernel.org \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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