All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Baltieri <fabio.baltieri@gmail.com>
To: linux-can@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/2] can: add tx/rx LED trigger support
Date: Tue, 24 Apr 2012 22:22:00 +0200	[thread overview]
Message-ID: <20120424202200.GA1672@gmail.com> (raw)
In-Reply-To: <20120424083806.GB420@vandijck-laurijssen.be>

On Tue, Apr 24, 2012 at 10:38:06AM +0200, Kurt Van Dijck wrote:
> On Mon, Apr 23, 2012 at 11:02:45PM +0200, Fabio Baltieri wrote:
> > This patch implements the functions to add two LED triggers, named
> > <ifname>-tx and <ifname>-rx, to a canbus device driver.
> > 
> [...]

Hello Kurt,

> If I understand well, this function is subject to maximal optimization.
> > +void can_led_event(struct net_device *netdev, enum can_led_event event)
> > +{
> > +	struct can_priv *priv = netdev_priv(netdev);
> If the assignment is postponed to withing the differenct cases, thereby
> repeating this statement 3 times (not 4!), both for RX & TX path a single
> assignment could be saved.
> For stack usage, I'm not an expert, but I suspect a little less stack use.
> I'm not sure wether it's worth the pain of extra lines of code.
> I tried to illustrate my point here:

I'm looking at the disassembled function for both cases on ARM.  Your
version uses some less instructions but I think the optimizer is
crunching the whoole thing in some funny way and I'm not sure if it's
going to make a difference at all in the end.

Do you know if there are any other part of the kernel which are using
similar optimiziations?

> > +++	struct can_led_data *tx_led, *rx_led;
> > +
> > +	switch (event) {
> > +	case CAN_LED_EVENT_OPEN:
> > +++		tx_led = priv->tx_led_data;
> > +		if (likely(tx_led))
> > +			led_trigger_event(&tx_led->trig, LED_FULL);
> > +++		rx_led = priv->rx_led_data;
> > +		if (likely(rx_led))
> > +			led_trigger_event(&rx_led->trig, LED_FULL);
> > +		break;
> > +	case CAN_LED_EVENT_STOP:
> > +++		tx_led = priv->tx_led_data;
> > +		if (likely(tx_led)) {
> > +			del_timer_sync(&tx_led->timer);
> > +			led_trigger_event(&tx_led->trig, LED_OFF);
> > +		}
> > +++		rx_led = priv->rx_led_data;
> > +		if (likely(rx_led)) {
> > +			del_timer_sync(&rx_led->timer);
> > +			led_trigger_event(&rx_led->trig, LED_OFF);
> > +		}
> > +		break;
> > +	case CAN_LED_EVENT_TX:
> > +++		tx_led = priv->tx_led_data;
> > +		if (led_delay && likely(tx_led) &&
> > +		    !timer_pending(&tx_led->timer))
> > +			mod_timer(&tx_led->timer,
> > +				jiffies + msecs_to_jiffies(led_delay));
> > +		break;
> > +	case CAN_LED_EVENT_RX:
> > +++		rx_led = priv->rx_led_data;
> > +		if (led_delay && likely(rx_led) &&
> > +		    !timer_pending(&rx_led->timer))
> > +			mod_timer(&rx_led->timer,
> > +				jiffies + msecs_to_jiffies(led_delay));
> > +		break;
> > +	}
> > +}
> > +EXPORT_SYMBOL_GPL(can_led_event);
> 
> Apart from this tiny question, the patch looks very clean, as Wolfgang already
> mentioned.

Thanks.

Regards,
Fabio

  reply	other threads:[~2012-04-24 20:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23 21:02 [RFC PATCH v2 1/2] can: add tx/rx LED trigger support Fabio Baltieri
2012-04-23 21:02 ` [RFC PATCH v2 2/2] can: flexcan: add " Fabio Baltieri
2012-04-24  5:16 ` [RFC PATCH v2 1/2] can: add tx/rx " Oliver Hartkopp
2012-04-24 19:10   ` Fabio Baltieri
2012-04-24  6:46 ` Wolfgang Grandegger
2012-04-24 15:41   ` Oliver Hartkopp
2012-04-24 18:08     ` Wolfgang Grandegger
2012-04-24 18:57       ` Oliver Hartkopp
2012-04-25  7:05         ` Wolfgang Grandegger
2012-04-24 19:02   ` Fabio Baltieri
2012-04-25  7:26     ` Wolfgang Grandegger
2012-04-25  7:41       ` Marc Kleine-Budde
2012-04-25 10:04         ` Wolfgang Grandegger
2012-05-03 21:49           ` Fabio Baltieri
2012-05-04  7:03             ` Oliver Hartkopp
2012-05-04  7:30             ` Wolfgang Grandegger
2012-04-24  8:38 ` Kurt Van Dijck
2012-04-24 20:22   ` Fabio Baltieri [this message]
2012-04-25  7:50     ` Kurt Van Dijck
2012-04-24  8:45 ` Kurt Van Dijck
2012-04-24 20:34   ` Fabio Baltieri
2012-04-25  8:00     ` Kurt Van Dijck
2012-04-25 20:39       ` Fabio Baltieri
2012-04-26  8:21         ` Kurt Van Dijck

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=20120424202200.GA1672@gmail.com \
    --to=fabio.baltieri@gmail.com \
    --cc=linux-can@vger.kernel.org \
    /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.