From: "Marek Behún" <marek.behun@nic.cz>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org, jacek.anaszewski@gmail.com,
Dan Murphy <dmurphy@ti.com>
Subject: Re: [PATCH v7 2/3] leds: initial support for Turris Omnia LEDs
Date: Fri, 24 Jul 2020 14:08:29 +0200 [thread overview]
Message-ID: <20200724140829.74167055@dellmb.labs.office.nic.cz> (raw)
In-Reply-To: <20200724105825.wyorw3jr2kaa3ucr@duo.ucw.cz>
On Fri, 24 Jul 2020 12:58:25 +0200
Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > This adds basic support for LEDs on the front side of CZ.NIC's
> > Turris Omnia router.
> >
> > There are 12 RGB LEDs. The controller supports HW triggering mode
> > for the LEDs, but this driver does not support it yet, and sets all
> > the LEDs defined in device-tree into SW mode upon probe.
> >
> > This driver uses the multicolor LED framework.
> >
> > Signed-off-by: Marek Behún <marek.behun@nic.cz>
> > Reviewed-by: Dan Murphy <dmurphy@ti.com>
> > ---
> > drivers/leds/Kconfig | 11 ++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-turris-omnia.c | 295
> > +++++++++++++++++++++++++++++++ 3 files changed, 307 insertions(+)
> > create mode 100644 drivers/leds/leds-turris-omnia.c
>
> Whoever told you to use defines here was evil:
I think it was that way when it was first proposed, sometime last year,
but Dan complained about magic numbers, so I changed it to macros :D
> > +#define OMNIA_CMD_LED_COLOR_LED 1
> > +#define OMNIA_CMD_LED_COLOR_R 2
> > +#define OMNIA_CMD_LED_COLOR_G 3
> > +#define OMNIA_CMD_LED_COLOR_B 4
> > +#define OMNIA_CMD_LED_COLOR_LEN 5
>
> > +static int omnia_led_brightness_set_blocking(struct led_classdev
> > *cdev,
> > + enum led_brightness
> > brightness) +{
> > + struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(cdev);
> > + struct omnia_leds *leds =
> > dev_get_drvdata(cdev->dev->parent);
> > + struct omnia_led *led = to_omnia_led(mc_cdev);
> > + u8 buf[OMNIA_CMD_LED_COLOR_LEN], state;
> > + int ret;
> > +
> > + mutex_lock(&leds->lock);
> > +
> > + led_mc_calc_color_components(&led->mc_cdev, brightness);
> > +
> > + buf[OMNIA_CMD] = CMD_LED_COLOR;
> > + buf[OMNIA_CMD_LED_COLOR_LED] = led->reg;
> > + buf[OMNIA_CMD_LED_COLOR_R] =
> > mc_cdev->subled_info[0].brightness;
> > + buf[OMNIA_CMD_LED_COLOR_G] =
> > mc_cdev->subled_info[1].brightness;
> > + buf[OMNIA_CMD_LED_COLOR_B] =
> > mc_cdev->subled_info[2].brightness;
>
> Aha, it is LED vs LEN, but please don't obscure code with macros like
> that. It is important to see that buf[] is fully initialized, macros
> hide that.
>
> > + state = CMD_LED_STATE_LED(led->reg);
> > + if (buf[OMNIA_CMD_LED_COLOR_R] ||
> > buf[OMNIA_CMD_LED_COLOR_G] || buf[OMNIA_CMD_LED_COLOR_B])
> > + state |= CMD_LED_STATE_ON;
>
> I'd make this conditional on mc_cdev->subled_info[0].brightness[x],
> not buf, but...
>
>
> > + int ret, count;
> > +
> > + count = of_get_available_child_count(np);
> > + if (!count) {
> > + dev_err(dev, "LEDs are not defined in device
> > tree!\n");
> > + return -ENODEV;
> > + } else if (count > OMNIA_BOARD_LEDS) {
> > + dev_err(dev, "Too many LEDs defined in device
> > tree!\n");
> > + return -EINVAL;
> > + }
>
> Should count be unsigned?
>
> Or better, should we check it is _exactly_ OMNIA_BOARD_LEDS as we only
> support this known hardware?
I think it shouldn't be an error when fewer than OMNIA_BOARD_LEDS are
in device tree...
> [I suppose I'll apply it anyway; these can be fixed post-merge].
As you wish. I can sent follow-up patch afterwards for to remove those
macros...
> Best regards,
> Pavel
next prev parent reply other threads:[~2020-07-24 12:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 12:53 [PATCH v7 0/3] Add Turris Omnia LEDs driver Marek Behún
2020-07-23 12:53 ` [PATCH v7 1/3] dt-bindings: leds: add cznic,turris-omnia-leds binding Marek Behún
2020-07-28 17:49 ` Rob Herring
2020-07-23 12:53 ` [PATCH v7 2/3] leds: initial support for Turris Omnia LEDs Marek Behún
2020-07-24 10:58 ` Pavel Machek
2020-07-24 12:08 ` Marek Behún [this message]
2020-07-24 14:56 ` Dan Murphy
2020-07-23 12:53 ` [PATCH v7 3/3] Documentation: ABI: leds-turris-omnia: document sysfs attribute Marek Behún
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=20200724140829.74167055@dellmb.labs.office.nic.cz \
--to=marek.behun@nic.cz \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/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).