All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Fabio Baltieri <fabio.baltieri@gmail.com>, linux-can@vger.kernel.org
Subject: Re: [RFC PATCH] can: add tx/rx led trigger support
Date: Thu, 12 Apr 2012 08:16:41 +0200	[thread overview]
Message-ID: <4F867349.9070008@hartkopp.net> (raw)
In-Reply-To: <4F85D46B.9050704@grandegger.com>

On 11.04.2012 20:58, Wolfgang Grandegger wrote:

> On 04/11/2012 08:29 PM, Oliver Hartkopp wrote:
>> On 11.04.2012 19:58, Fabio Baltieri wrote:
>>
>>
>>> On Wed, Apr 11, 2012 at 8:14 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>
>>>> I wonder if it makes more sense to add the LED trigger stuff into
>>>> drivers/net/can/dev.c ?!?
>>>
>>> Of course that seems to be the obvious (=correct) place to trap this
>>> stuff. The reason why I worked on upper layer is that I did not found
>>> any generic place to trap tx/rx events in the dev file without
>>> modifying every device driver, as while tx can be trapped in
>>> can_get_echo_skb(), rx frames are handled directly to the network
>>> layer.
>>
>>
>> I think that depends heavily on the driver and therefore adding the
>> can_led_tx() and can_led_rx() calls to the appropriate places is the most
>> transparent implementation.
> 
> I would prefer to implement can_led_trigger (or can_led_event) passing a
> mask defining the event (RX, TX or event something else).
> 


Yes. Good idea.

What about passing the pointer to some kind of can_led_handler struct, e.g.

struct can_led_handler {
	struct timer_list off_timer;
	struct led_trigger *led;
	char led_name[32];
}

which is part of struct can_priv then:

+#ifdef CONFIG_CAN_LEDS
+	struct can_led_handler can_tx_led, can_rx_lead;
+#endif

Then we could use in the interrupt:

(..)
	can_led_trigger(&priv->can_tx_led)
(..)

This would omit the check for flags and directly work on the correct LEDs.


Regards,
Oliver

  reply	other threads:[~2012-04-12  6:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-10 21:39 [RFC PATCH] can: add tx/rx led trigger support Fabio Baltieri
2012-04-11  6:14 ` Oliver Hartkopp
2012-04-11 17:58   ` Fabio Baltieri
2012-04-11 18:29     ` Oliver Hartkopp
2012-04-11 18:58       ` Wolfgang Grandegger
2012-04-12  6:16         ` Oliver Hartkopp [this message]
2012-04-11 19:02     ` Oliver Hartkopp
2012-04-11 19:36       ` Fabio Baltieri
2012-04-12  6:05         ` Oliver Hartkopp
2012-04-12  6:32         ` Alexander Stein
2012-04-12 15:52           ` Oliver Hartkopp
2012-04-12 18:30             ` Fabio Baltieri
2012-04-13 19:00               ` Oliver Hartkopp
2012-04-12  7:37         ` Wolfgang Grandegger
2012-04-12 11:07           ` Martin Gysel
2012-04-12 16:02             ` Oliver Hartkopp
2012-04-12 16:13               ` Wolfgang Grandegger
2012-04-12 17:28                 ` Fabio Baltieri
2012-04-12 18:47                   ` Wolfgang Grandegger
2012-04-12 17:46           ` Fabio Baltieri
2012-04-12 18:53             ` Wolfgang Grandegger
2012-04-11  6:29 ` Alexander Stein
2012-04-11 18:03   ` Fabio Baltieri
2012-04-11 14:45 ` Wolfgang Grandegger
2012-04-11 16:24   ` Oliver Hartkopp
2012-04-11 19:11   ` 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=4F867349.9070008@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=fabio.baltieri@gmail.com \
    --cc=linux-can@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.