Re: [PATCH RESEND] add led driver for Bachmann's ot200

[Christian Gmeiner]

Hi Andrew

2011/12/13 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
> On Tue, 13 Dec 2011 10:57:30 +0100
> Christian Gmeiner <christian.gmeiner@xxxxxxxxx> wrote:
>
>> >From a7fecf3426ef98fdd19e9d2610665b9d1ce358a0 Mon Sep 17 00:00:00 2001
>> From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
>> Date: Fri, 18 Nov 2011 10:21:48 +0100
>> Subject: [PATCH] add led driver for Bachmann's ot200
>>
>> This patch adds support for leds on Bachmann's ot200 visualisation device.
>> The device has three leds on the back panel (led_err, led_init and led_run)
>> and can handle up to seven leds on the front panel.
>>
>> The driver was written by Linutronix on behalf of
>> Bachmann electronic GmbH.
>
> The code uses no tabs and indents with seven-spaces. ÂPlease convert it
> to use hard tabs in the conventional fashion? ÂIn the Makefile and
> Kconfig, too.

okay

>
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index ff203a4..6cf0dd6 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -387,6 +387,14 @@ config LEDS_RENESAS_TPU
>> Â Â Â Â Âpin function. The latter to support brightness control.
>> Â Â Â Â ÂBrightness control is supported but hardware blinking is not.
>>
>> +config LEDS_OT200
>> + Â Â Â tristate "LED support for Bachmann OT200"
>> + Â Â Â depends on LEDS_CLASS
>> + Â Â Â help
>> + Â Â Â Â This option enables support for the LEDs on the Bachmann OT200. The
>> + Â Â Â Â LEDs are controlled through LPC bus.
>> + Â Â Â Â Say Y to enable LEDs on the Bachmann OT200.
>> +
>> Âconfig LEDS_TRIGGERS
>> Â Â Â Âbool "LED Trigger support"
>> Â Â Â Âdepends on LEDS_CLASS
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index e4f6bf5..0814d42 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -43,6 +43,7 @@ obj-$(CONFIG_LEDS_NS2) Â Â Â Â Â Â Â Â Â Â Â Â+= leds-ns2.o
>> Âobj-$(CONFIG_LEDS_NETXBIG) Â Â Â Â Â Â += leds-netxbig.o
>> Âobj-$(CONFIG_LEDS_ASIC3) Â Â Â Â Â Â Â += leds-asic3.o
>> Âobj-$(CONFIG_LEDS_RENESAS_TPU) Â Â Â Â += leds-renesas-tpu.o
>> +obj-$(CONFIG_LEDS_OT200) Â Â Â Â Â Â Â += leds-ot200.o
>>
>> Â# LED SPI Drivers
>> Âobj-$(CONFIG_LEDS_DAC124S085) Â Â Â Â Â+= leds-dac124s085.o
>> diff --git a/drivers/leds/leds-ot200.c b/drivers/leds/leds-ot200.c
>> new file mode 100644
>> index 0000000..60f118b
>> --- /dev/null
>> +++ b/drivers/leds/leds-ot200.c
>> @@ -0,0 +1,204 @@
>> +/*
>> + * Bachmann ot200 leds driver.
>> + *
>> + * Author: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
>> + * License: GPL as published by the FSF.
>> + */
>> +
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/leds.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +
>> +struct ot200_led {
>> + Â Â Â struct led_classdev cdev;
>> + Â Â Â char name[8];
>> + Â Â Â unsigned int num;
>> +};
>> +
>> +static u8 old_val;
>> +static u8 old_val_back;
>
> What's going on here? ÂThe driver is using eight bits to store the
> current control setting, but the changelog says the driver can handle
> ten LEDs.
>
> <looks>
>
> OK, so we're using seven bits in old_val and three in old_val_back.
>

Exactly.. I have not found a better way to store the led state. Any
recommendations?


>> +DEFINE_SPINLOCK(value_lock);
>
> Should be static.
>

okay

>> +static void ot200_led_set(struct led_classdev *led_cdev,
>> + Â Â Â Â Â Â Â Â Â Â Â enum led_brightness value)
>> +{
>> + Â Â Â struct ot200_led *led = container_of(led_cdev, struct ot200_led, cdev);
>> + Â Â Â u8 val;
>> + Â Â Â u8 mask;
>> + Â Â Â unsigned long flags;
>> +
>> + Â Â Â mask = 1 << led->num;
>> +
>> + Â Â Â spin_lock_irqsave(&value_lock, flags);
>> + Â Â Â val = old_val;
>> +
>> + Â Â Â if (value == LED_OFF)
>> + Â Â Â Â Â Â Â val &= ~mask;
>> + Â Â Â else
>> + Â Â Â Â Â Â Â val |= mask;
>> +
>> + Â Â Â old_val = val;
>> + Â Â Â spin_unlock_irqrestore(&value_lock, flags);
>> + Â Â Â outb(val, 0x49);
>> +}
>
> It's a bit worrisome doing the outb() outside the locked section, but
> all the races I can think of result from userspace doing things which
> were unavoidably indeterminate anyway.
>

I think that it is really no problem to do outb() in the looked area.
Will change
this for v2 of this patch.

>> +static void ot200_led_back_set(struct led_classdev *led_cdev,
>> + Â Â Â Â Â Â Â Â Â Â Â enum led_brightness value)
>> +{
>> + Â Â Â struct ot200_led *led = container_of(led_cdev, struct ot200_led, cdev);
>> + Â Â Â u8 val;
>> + Â Â Â u8 mask;
>> + Â Â Â unsigned long flags;
>> +
>> + Â Â Â mask = 1 << led->num;
>> +
>> + Â Â Â spin_lock_irqsave(&value_lock, flags);
>> + Â Â Â val = old_val_back;
>> +
>> + Â Â Â if (value == LED_OFF)
>> + Â Â Â Â Â Â Â val &= ~mask;
>> + Â Â Â else
>> + Â Â Â Â Â Â Â val |= mask;
>> +
>> + Â Â Â old_val_back = val;
>> + Â Â Â spin_unlock_irqrestore(&value_lock, flags);
>> + Â Â Â outb(val, 0x5a);
>> +}
>> +
>> +static int __devinit create_ot200_led(struct platform_device *pdev, int num,
>> + Â Â Â Â Â Â Â struct ot200_led *led)
>> +{
>> + Â Â Â int ret;
>> +
>> + Â Â Â num += 1;
>> + Â Â Â snprintf(led->name, sizeof(led->name), "led%d", num);
>> + Â Â Â led->num = 7 - num;
>> + Â Â Â led->cdev.name = led->name;
>> + Â Â Â led->cdev.default_trigger = NULL;
>> + Â Â Â led->cdev.blink_set = NULL;
>> + Â Â Â led->cdev.brightness_set = ot200_led_set;
>> +
>> + Â Â Â ret = led_classdev_register(&pdev->dev, &led->cdev);
>> + Â Â Â if (ret < 0)
>> + Â Â Â Â Â Â Â goto out;
>> +
>> + Â Â Â dev_set_drvdata(led->cdev.dev, led);
>> + Â Â Â return 0;
>> +
>> + Â Â Â led_classdev_unregister(&led->cdev);
>> +out:
>> + Â Â Â return ret;
>> +}
>> +
>> +static int __devinit create_ot200_led_back(struct platform_device *pdev,
>> + Â Â Â Â Â Â Â int num, struct ot200_led *led)
>> +{
>> + Â Â Â char *led_name;
>> + Â Â Â int ret;
>> +
>> + Â Â Â switch (num) {
>> + Â Â Â case 0:
>> + Â Â Â Â Â Â Â led_name = "run";
>> + Â Â Â Â Â Â Â break;
>> + Â Â Â case 1:
>> + Â Â Â Â Â Â Â led_name = "init";
>> + Â Â Â Â Â Â Â break;
>> + Â Â Â case 2:
>> + Â Â Â Â Â Â Â led_name = "err";
>> + Â Â Â Â Â Â Â break;
>> + Â Â Â default:
>> + Â Â Â Â Â Â Â BUG();
>> + Â Â Â };
>> +
>> + Â Â Â snprintf(led->name, sizeof(led->name), "led_%s", led_name);
>> + Â Â Â led->num = num;
>> + Â Â Â led->cdev.name = led->name;
>> + Â Â Â led->cdev.blink_set = NULL;
>> + Â Â Â led->cdev.brightness_set = ot200_led_back_set;
>> +
>> + Â Â Â ret = led_classdev_register(&pdev->dev, &led->cdev);
>> + Â Â Â if (ret < 0)
>> + Â Â Â Â Â Â Â goto out;
>> +
>> + Â Â Â dev_set_drvdata(led->cdev.dev, led);
>> + Â Â Â return 0;
>> +
>> + Â Â Â led_classdev_unregister(&led->cdev);
>> +out:
>> + Â Â Â return ret;
>> +
>> +}
>
> This is implementing a userspace API (led_run, led_init, led_err) but
> that API isn't documented anywhere. ÂCan we add a few words of
> Documentation so our users know how to use this driver?

To be exact the driver uses the led subsystem - led_classdev_register() - and
creates these led devices. So we are not creating any new API, which should
be documented - or?

# ls /sys/class/leds/ -l
total 0
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led1 ->
../../devices/platform/leds-ot200.0/leds/led1
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led2 ->
../../devices/platform/leds-ot200.0/leds/led2
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led3 ->
../../devices/platform/leds-ot200.0/leds/led3
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led4 ->
../../devices/platform/leds-ot200.0/leds/led4
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led5 ->
../../devices/platform/leds-ot200.0/leds/led5
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led6 ->
../../devices/platform/leds-ot200.0/leds/led6
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led7 ->
../../devices/platform/leds-ot200.0/leds/led7
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led_err ->
../../devices/platform/leds-ot200.0/leds/led_err
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led_ini ->
../../devices/platform/leds-ot200.0/leds/led_ini
lrwxrwxrwx 1 root root 0 Dec 14 07:57 led_run ->
../../devices/platform/leds-ot200.0/leds/led_run

Thanks for your review.
--
Christian Gmeiner, MSc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/