From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Fabio Baltieri <fabio.baltieri@gmail.com>,
linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
Oliver Hartkopp <socketcan@hartkopp.net>
Subject: Re: [PATCH can-next v3 1/2] can: add tx/rx LED trigger support
Date: Tue, 31 Jul 2012 12:12:59 +0200 [thread overview]
Message-ID: <5017AFAB.1040609@pengutronix.de> (raw)
In-Reply-To: <50179B81.3040907@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 8727 bytes --]
On 07/31/2012 10:46 AM, Wolfgang Grandegger wrote:
> Hi Fabio,
>
> On 07/30/2012 09:20 PM, Fabio Baltieri wrote:
>> This patch implements the functions to add two LED triggers, named
>> <ifname>-tx and <ifname>-rx, to a canbus device driver.
>>
>> Triggers are called from specific handlers by each CAN device driver and
>> can be disabled altogether with a Kconfig option.
>>
>> The implementation keeps the LED on when the interface is UP and blinks
>> the LED on network activity at a configurable rate.
>>
>> This only supports can-dev based drivers, as it uses some support field
>> in the can_priv structure.
>>
>> Supported drivers should call can_led_init(), can_led_exit() and
>> can_led_event() as needed.
>>
>> Supported events are:
>> - CAN_LED_EVENT_OPEN: turn on tx/rx LEDs
>> - CAN_LED_EVENT_STOP: turn off tx/rx LEDs
>> - CAN_LED_EVENT_TX: trigger tx LED blink
>> - CAN_LED_EVENT_RX: trigger tx LED blink
>>
>> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
>> Cc: Wolfgang Grandegger <wg@grandegger.com>
>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>> Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
>> ---
>>
>> Hi all!
>>
>> This is the v3 of my CAN LED trigger patch. It's a major refactoring of the v2
>> that was discussed about three months ago concluding with the idea that
>> implementing the oneshot triggering code in the LED framework would be a better
>> solution.
>>
>> This is the old thread for reference:
>> http://marc.info/?l=linux-can&m=133521499002898&w=2
>>
>> So, generic oneshot trigger code is now merged in mainline (see 5bb629c), and
>> these are the changes in the v3:
>
> Nice, thanks for your patience (and not giving up).
>
>>
>> - use the new led_trigger_blink_oneshot() function for LED triggering
>> - use kasprintf() and led_trigger_{un}register_simple for LED allocation
>> - add some usage note in the comments
>>
>> The resulting code is quite simple now and - I think - a bit less intrusive.
>> Still, I hope on some feedback from the community as I don't have that much
>> hardware to test it - this version has been tested mainly on an x86 with a
>> custom usb-can interface.
>>
>> In 2/2 there is a sample implementation for the flexcan driver, which is
>> basically unchanged from the old version.
>>
>> Any comments?
>> Fabio
>>
>> drivers/net/can/Kconfig | 12 ++++++
>> drivers/net/can/Makefile | 2 +
>> drivers/net/can/led.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/can/dev.h | 8 ++++
>> include/linux/can/led.h | 38 +++++++++++++++++++
>> 5 files changed, 159 insertions(+)
>> create mode 100644 drivers/net/can/led.c
>> create mode 100644 include/linux/can/led.h
>>
>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
>> index bb709fd..19dec19 100644
>> --- a/drivers/net/can/Kconfig
>> +++ b/drivers/net/can/Kconfig
>> @@ -54,6 +54,18 @@ config CAN_CALC_BITTIMING
>> arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
>> If unsure, say Y.
>>
>> +config CAN_LEDS
>> + bool "Enable LED triggers for Netlink based drivers"
>> + depends on CAN_DEV
>> + depends on LEDS_CLASS
>> + select LEDS_TRIGGERS
>> + ---help---
>> + This option adds two LED triggers for packet receive and transmit
>> + events on each supported CAN device.
>> +
>> + Say Y here if you are working on a system with led-class supported
>> + LEDs and you want to use them as canbus activity indicators.
>> +
>> config CAN_AT91
>> tristate "Atmel AT91 onchip CAN controller"
>> depends on CAN_DEV && (ARCH_AT91SAM9263 || ARCH_AT91SAM9X5)
>> diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
>> index 938be37..24ee98b 100644
>> --- a/drivers/net/can/Makefile
>> +++ b/drivers/net/can/Makefile
>> @@ -8,6 +8,8 @@ obj-$(CONFIG_CAN_SLCAN) += slcan.o
>> obj-$(CONFIG_CAN_DEV) += can-dev.o
>> can-dev-y := dev.o
>>
>> +can-dev-$(CONFIG_CAN_LEDS) += led.o
>> +
>> obj-y += usb/
>> obj-y += softing/
>>
>> diff --git a/drivers/net/can/led.c b/drivers/net/can/led.c
>> new file mode 100644
>> index 0000000..68c4f30
>> --- /dev/null
>> +++ b/drivers/net/can/led.c
>> @@ -0,0 +1,99 @@
>> +/*
>> + * Copyright 2012, Fabio Baltieri <fabio.baltieri@gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/slab.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/can/dev.h>
>> +
>> +#include <linux/can/led.h>
>> +
>> +static unsigned long led_delay = 50;
>> +module_param(led_delay, ulong, 0644);
>> +MODULE_PARM_DESC(led_delay,
>> + "blink delay time for activity leds (msecs, default: 50).");
>> +
>> +/*
>> + * Trigger a LED event in response to a CAN device event
>> + */
>> +void can_led_event(struct net_device *netdev, enum can_led_event event)
>> +{
>> + struct can_priv *priv = netdev_priv(netdev);
>> +
>> + switch (event) {
>> + case CAN_LED_EVENT_OPEN:
>> + led_trigger_event(priv->tx_led_trig, LED_FULL);
>> + led_trigger_event(priv->rx_led_trig, LED_FULL);
>> + break;
>> + case CAN_LED_EVENT_STOP:
>> + led_trigger_event(priv->tx_led_trig, LED_OFF);
>> + led_trigger_event(priv->rx_led_trig, LED_OFF);
>> + break;
>> + case CAN_LED_EVENT_TX:
>> + if (led_delay)
>> + led_trigger_blink_oneshot(priv->tx_led_trig,
>> + &led_delay, &led_delay, 1);
>> + break;
>> + case CAN_LED_EVENT_RX:
>> + if (led_delay)
>> + led_trigger_blink_oneshot(priv->rx_led_trig,
>> + &led_delay, &led_delay, 1);
>> + break;
>> + }
>> +}
>> +EXPORT_SYMBOL_GPL(can_led_event);
>> +
>> +/*
>> + * Register CAN LED triggers for a CAN device
>> + *
>> + * This is normally called from a driver's probe function
>> + */
>> +void can_led_init(struct net_device *netdev)
>> +{
>> + struct can_priv *priv = netdev_priv(netdev);
>> +
>> + priv->tx_led_trig_name = kasprintf(GFP_KERNEL, "%s-tx", netdev->name);
>> + if (!priv->tx_led_trig_name)
>> + goto tx_led_failed;
>
> Just return here?
>
>> + priv->rx_led_trig_name = kasprintf(GFP_KERNEL, "%s-rx", netdev->name);
>> + if (!priv->rx_led_trig_name)
>> + goto rx_led_failed;
>> +
>> + led_trigger_register_simple(priv->tx_led_trig_name,
>> + &priv->tx_led_trig);
>> + led_trigger_register_simple(priv->rx_led_trig_name,
>> + &priv->rx_led_trig);
>> +
>> + return;
>> +
>> +rx_led_failed:
>> + kfree(priv->tx_led_trig_name);
>> + priv->tx_led_trig_name = NULL;
>> +tx_led_failed:
>> + return;
>
> In case of error the function returns silently. Is this by purpose? What
> happens if CAN_LEDS is enabled but no LEDs are assigned?
It's a bit strange, but led_trigger_register_simple() can fail silently,
too. Or better it has no return value, but does a warning printk in case
of an error.
>
>> +}
>> +EXPORT_SYMBOL_GPL(can_led_init);
>> +
>> +/*
>> + * Unregister CAN LED triggers for a CAN device
>> + *
>> + * This is normally called from a driver's remove function
>> + */
>> +void can_led_exit(struct net_device *netdev)
>> +{
>> + struct can_priv *priv = netdev_priv(netdev);
>> +
>> + led_trigger_unregister_simple(priv->tx_led_trig);
>> + led_trigger_unregister_simple(priv->rx_led_trig);
>> +
>> + kfree(priv->tx_led_trig_name);
>> + kfree(priv->rx_led_trig_name);
>> +}
>> +EXPORT_SYMBOL_GPL(can_led_exit);
>> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
>> index 2b2fc34..167b04a 100644
>> --- a/include/linux/can/dev.h
>> +++ b/include/linux/can/dev.h
>> @@ -16,6 +16,7 @@
>> #include <linux/can.h>
>> #include <linux/can/netlink.h>
>> #include <linux/can/error.h>
>> +#include <linux/can/led.h>
>>
>> /*
>> * CAN mode
>> @@ -52,6 +53,13 @@ struct can_priv {
>>
>> unsigned int echo_skb_max;
>> struct sk_buff **echo_skb;
>> +
>> +#ifdef CONFIG_CAN_LEDS
>> + struct led_trigger *tx_led_trig;
>> + char *tx_led_trig_name;
>> + struct led_trigger *rx_led_trig;
>> + char *rx_led_trig_name;
>> +#endif
>
> Do we need to store the names?
Yes, Seems, so the name is not copied:
http://lxr.free-electrons.com/source/drivers/leds/led-triggers.c#L253
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-07-31 10:13 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-30 19:20 [PATCH can-next v3 1/2] can: add tx/rx LED trigger support Fabio Baltieri
2012-07-30 19:20 ` [PATCH can-next v3 2/2] can: flexcan: add " Fabio Baltieri
2012-07-30 21:17 ` [PATCH can-next v3 1/2] can: add tx/rx " Marc Kleine-Budde
2012-07-31 6:57 ` Fabio Baltieri
2012-07-31 7:10 ` Marc Kleine-Budde
2012-07-31 11:57 ` Fabio Baltieri
2012-07-31 12:00 ` Marc Kleine-Budde
2012-07-31 22:05 ` [PATCH can-next v4] " Fabio Baltieri
2012-08-01 9:36 ` Marc Kleine-Budde
2012-08-01 10:07 ` Marc Kleine-Budde
2012-08-01 10:30 ` Fabio Baltieri
2012-08-01 11:37 ` Marc Kleine-Budde
2012-08-01 11:49 ` [PATCH can-next v5 1/2] " Fabio Baltieri
2012-08-01 11:49 ` [PATCH can-next v5 2/2] can: flexcan: add " Fabio Baltieri
2012-08-01 11:53 ` Marc Kleine-Budde
2012-08-01 12:24 ` Fabio Baltieri
2012-08-01 12:30 ` Marc Kleine-Budde
2012-08-01 21:02 ` Marc Kleine-Budde
2012-08-01 11:59 ` [PATCH can-next v5 1/2] can: add tx/rx " Marc Kleine-Budde
2012-08-01 12:06 ` Oliver Hartkopp
2012-08-01 12:18 ` Marc Kleine-Budde
2012-08-01 18:21 ` [PATCH can-next v6] " Fabio Baltieri
2012-08-01 21:00 ` Marc Kleine-Budde
2012-08-01 22:38 ` Fabio Baltieri
2012-08-01 21:05 ` Oliver Hartkopp
2012-08-24 5:10 ` Kurt Van Dijck
2012-08-24 11:28 ` Marc Kleine-Budde
2012-08-24 12:42 ` Kurt Van Dijck
2012-08-24 22:01 ` Fabio Baltieri
2012-08-25 20:25 ` Kurt Van Dijck
2012-09-03 12:40 ` Marc Kleine-Budde
2012-09-03 18:13 ` Kurt Van Dijck
2012-09-03 18:29 ` Fabio Baltieri
2012-09-03 20:54 ` Oliver Hartkopp
2012-09-04 7:11 ` Kurt Van Dijck
2012-09-04 9:29 ` [PATCH] can: rename LED trigger name on netdev renames Kurt Van Dijck
2012-09-06 18:59 ` Fabio Baltieri
2012-09-06 19:31 ` Oliver Hartkopp
2012-09-06 20:46 ` Fabio Baltieri
2012-09-07 7:19 ` Kurt Van Dijck
2012-09-09 16:17 ` [PATCH v2] " Fabio Baltieri
2012-09-10 14:25 ` [PATCH] can: export a safe netdev_priv wrapper for candev Kurt Van Dijck
2012-09-10 18:22 ` Oliver Hartkopp
2012-09-10 18:29 ` Fabio Baltieri
2012-09-10 19:55 ` [PATCH v2] " Kurt Van Dijck
2012-09-10 14:28 ` [PATCH v3] can: rename LED trigger name on netdev renames Kurt Van Dijck
2012-09-10 18:25 ` Oliver Hartkopp
2012-09-10 18:40 ` Fabio Baltieri
2012-09-10 19:01 ` Oliver Hartkopp
2012-09-10 20:08 ` Kurt Van Dijck
2012-09-11 5:42 ` Oliver Hartkopp
2012-09-11 7:13 ` Fabio Baltieri
2012-09-12 7:22 ` Kurt Van Dijck
2012-09-11 8:05 ` Kurt Van Dijck
2012-09-10 20:06 ` [PATCH v4] " Kurt Van Dijck
2012-09-11 21:04 ` Fabio Baltieri
2012-09-04 20:15 ` [PATCH can-next v6] can: add tx/rx LED trigger support Fabio Baltieri
2012-09-06 10:33 ` Kurt Van Dijck
2012-09-06 11:17 ` Fabio Baltieri
2012-09-06 15:11 ` Kurt Van Dijck
2012-09-06 20:57 ` Fabio Baltieri
2012-09-07 7:04 ` Kurt Van Dijck
2012-09-07 18:59 ` Fabio Baltieri
2012-07-31 8:46 ` [PATCH can-next v3 1/2] " Wolfgang Grandegger
2012-07-31 10:12 ` Marc Kleine-Budde [this message]
2012-07-31 11:55 ` Fabio Baltieri
2012-07-31 12:14 ` Fabio Baltieri
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=5017AFAB.1040609@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=fabio.baltieri@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=socketcan@hartkopp.net \
--cc=wg@grandegger.com \
/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).