linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andri Yngvason <andri.yngvason@marel.com>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: linux-can@vger.kernel.org, mkl@pengutronix.de
Subject: Re: [PATCH v3 1/4] can: dev: Consolidate and unify state change  handling
Date: Wed, 26 Nov 2014 14:12:25 +0000	[thread overview]
Message-ID: <20141126141225.18934.71620@shannon> (raw)
In-Reply-To: <9d8fa00c692b72a6b8308839b9cb253a@grandegger.com>

Quoting Wolfgang Grandegger (2014-11-26 11:32:56)
> On Wed, 26 Nov 2014 10:26:59 +0000, Andri Yngvason
> <andri.yngvason@marel.com> wrote:
> > Quoting Wolfgang Grandegger (2014-11-25 20:55:22)
> >> On 09/26/2014 07:19 PM, Andri Yngvason wrote:
...
> >> > +     struct can_priv *priv = netdev_priv(dev);
> >> > +
> >> > +     if (new_state <= priv->state)
> >> > +             return;
> >> > +
> >> > +     switch (new_state) {
> >> > +     case CAN_STATE_ERROR_ACTIVE:
> >> > +             netdev_warn(dev, "%s: did we come from a state less
> than
> >> > error-active?",
> >> > +                         __func__);
> >> 
> >> Please remove __func__ here and below and use a more meaningful warning
> >> message. Such messages should make sense to non-experts as well...
> >> at least a little bit.
> >> 
> > This is actually a warning for the developer. It's means to tell him
> he's
> > doing
> > something seriously wrong. Maybe this should be an error then?
>
Any thoughts on this? Should I drop it or make a bigger bang?
>
> >>
> >> > +             break;
> >> > +     case CAN_STATE_ERROR_WARNING:
> >> > +             priv->can_stats.error_warning++;
> >> > +             break;
> >> > +     case CAN_STATE_ERROR_PASSIVE:
> >> > +             priv->can_stats.error_passive++;
> >> > +             break;
> >> > +     case CAN_STATE_BUS_OFF:
> >> > +             priv->can_stats.bus_off++;
> >> 
> >> Be careful here. This counter will also be incremented in
> can_bus_off().
> >>
> > Ooops.
> 
> I think it should be moved out of can_bus_off(). This requires a separate
> patch moving the line back to the drivers using can_bus_off().
> 
Thinking the same thing. We can do that later, though; right?

--
Andri

  reply	other threads:[~2014-11-26 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26 17:19 [PATCH v3 1/4] can: dev: Consolidate and unify state change handling Andri Yngvason
2014-11-25 20:55 ` Wolfgang Grandegger
2014-11-26 10:26   ` Andri Yngvason
2014-11-26 11:32     ` Wolfgang Grandegger
2014-11-26 14:12       ` Andri Yngvason [this message]
2014-11-26 14:55         ` Wolfgang Grandegger
2014-11-26 15:38           ` Andri Yngvason
2014-11-26 20:39             ` Wolfgang Grandegger

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=20141126141225.18934.71620@shannon \
    --to=andri.yngvason@marel.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --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).