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>, linux-can@vger.kernel.org
Cc: mkl@pengutronix.de
Subject: Re: [PATCH v3 1/4] can: dev: Consolidate and unify state change handling
Date: Wed, 26 Nov 2014 10:26:59 +0000	[thread overview]
Message-ID: <20141126102659.715.14133@shannon> (raw)
In-Reply-To: <5474ECBA.3060505@grandegger.com>

Quoting Wolfgang Grandegger (2014-11-25 20:55:22)
> On 09/26/2014 07:19 PM, Andri Yngvason wrote:
> > The handling of can error states is different between platforms.
> > This is an attempt to correct that problem.
> > 
> > I've moved this handling into a generic function for changing the
> > error state. This ensures that error state changes are handled
> > the same way everywhere (where this function is used).
> 
> I think it's also important to note that now also *decreasing* error
> states are reported.
>
Roger.
> 
> > Changes made since last proposal:
> > can: dev: remove can_errcnt_to_state
> > can: dev: reduce nesting in can_change_state
> 
> Please move the changes after the "---" line below.
> 
OK.
>
> > Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
> > ---
> >  drivers/net/can/dev.c          | 94 ++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/can/dev.h        |  4 ++
> >  include/uapi/linux/can/error.h |  1 +
> >  3 files changed, 99 insertions(+)
> > 
> > diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> > index 02492d2..a10b6ab 100644
> > --- a/drivers/net/can/dev.c
> > +++ b/drivers/net/can/dev.c
> > @@ -273,6 +273,100 @@ static int can_get_bittiming(struct net_device *dev, struct can_bittiming *bt,
> >       return err;
> >  }
> >  
> > +static void can_update_error_counters(struct net_device *dev,
> > +                                   enum can_state new_state)
> 
> s/can_update_error_counters/can_update_error_stats/ ?
> 
Yeah, that makes sense.
>
> Error counters are usually txerr/rxerr.
> 
> > +{
> > +     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?
>
> > +             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.
> 
> > +             break;
> > +     default:
> > +             netdev_warn(dev, "%s: %d is not a state", __func__, new_state);
> 
> "%d is not a valid state" ?
>
Same as above. It's meant to tell the developer that he's putting nonsense into
state.
> 
> > +             break;
> > +     };
> > +}
> > +
> > +static int can_txstate_to_frame(struct net_device *dev, enum can_state state)
> 
> s/txstate/tx_state/ ?
>
OK.
> 
> > +{
> > +     switch (state) {
> > +     case CAN_STATE_ERROR_ACTIVE:
> > +             return CAN_ERR_CRTL_ACTIVE;
> > +     case CAN_STATE_ERROR_WARNING:
> > +             return CAN_ERR_CRTL_TX_WARNING;
> > +     case CAN_STATE_ERROR_PASSIVE:
> > +             return CAN_ERR_CRTL_TX_PASSIVE;
> > +     case CAN_STATE_BUS_OFF:
> > +             netdev_warn(dev, "%s: bus-off is not handled here", __func__);
> 
> Then we may silently ignore it?
> 
> > +             return 0;
> > +     default:
> > +             netdev_warn(dev, "%s: %d is not a state", __func__, state);
> > +             return 0;
> > +     }
> > +}
> > +
> > +static int can_rxstate_to_frame(struct net_device *dev, enum can_state state)
> 
> s/rxstate/rx_state/
>
OK.
> 
> > +{
> > +     switch (state) {
> > +     case CAN_STATE_ERROR_ACTIVE:
> > +             return CAN_ERR_CRTL_ACTIVE;
> > +     case CAN_STATE_ERROR_WARNING:
> > +             return CAN_ERR_CRTL_RX_WARNING;
> > +     case CAN_STATE_ERROR_PASSIVE:
> > +             return CAN_ERR_CRTL_RX_PASSIVE;
> > +     case CAN_STATE_BUS_OFF:
> > +             netdev_warn(dev, "%s: bus-off is not handled here", __func__);
> > +             return 0;
> 
> See above.
> 
> > +     default:
> > +             netdev_warn(dev, "%s: %d is not a state", __func__, state);
> > +             return 0;
> > +     }
> > +}
> > +
> > +void can_change_state(struct net_device *dev, struct can_frame *cf,
> > +                   enum can_state new_state, enum can_state tx_state,
> > +                   enum can_state rx_state)
> > +{
> > +     struct can_priv *priv = netdev_priv(dev);
> > +
> > +     if (unlikely(new_state == priv->state)) {
> > +             netdev_warn(dev, "%s: oops, state did not change", __func__);
> > +             return;
> > +     }
> > +
> > +     can_update_error_counters(dev, new_state);
> > +     priv->state = new_state;
> > +
> > +     if (unlikely(new_state == CAN_STATE_BUS_OFF)) {
> > +             cf->can_id |= CAN_ERR_BUSOFF;
> > +             return;
> > +     }
> > +
> > +     if (unlikely(tx_state != new_state && rx_state != new_state))
> > +             netdev_warn(dev, "%s: neither rx nor tx state match new state", __func__);
> 
> Is this worth a warning or is it even an error?
> 
Same as above. If I were doing this in user-space, this would be an assert.
Should we maybe just ignore such things? In that case, passing new_state as an
argument is redundant because new_state = max(rx_state, tx_state).
>
> > +
> > +     cf->can_id |= CAN_ERR_CRTL;
> > +     cf->data[1] |= tx_state >= rx_state ?
> > +                    can_txstate_to_frame(dev, tx_state) : 0;
> > +     cf->data[1] |= tx_state <= rx_state ?
> > +                    can_rxstate_to_frame(dev, rx_state) : 0;
> 
> OK, I can live with that solution.
> 
> > +}
> > +EXPORT_SYMBOL_GPL(can_change_state);
> > +
> >  /*
> >   * Local echo of CAN messages
> >   *
> > diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> > index 6992afc..1902bff 100644
> > --- a/include/linux/can/dev.h
> > +++ b/include/linux/can/dev.h
> > @@ -121,6 +121,10 @@ void unregister_candev(struct net_device *dev);
> >  int can_restart_now(struct net_device *dev);
> >  void can_bus_off(struct net_device *dev);
> >  
> > +void can_change_state(struct net_device *dev, struct can_frame *cf,
> > +                   enum can_state new_state, enum can_state tx_state,
> > +                   enum can_state rx_state);
> > +
> >  void can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
> >                     unsigned int idx);
> >  unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
> > diff --git a/include/uapi/linux/can/error.h b/include/uapi/linux/can/error.h
> > index c247446..1c508be 100644
> > --- a/include/uapi/linux/can/error.h
> > +++ b/include/uapi/linux/can/error.h
> > @@ -71,6 +71,7 @@
> >  #define CAN_ERR_CRTL_TX_PASSIVE  0x20 /* reached error passive status TX */
> >                                     /* (at least one error counter exceeds */
> >                                     /* the protocol-defined level of 127)  */
> > +#define CAN_ERR_CRTL_ACTIVE      0x40 /* recovered to error active state */
> >  
> >  /* error in CAN protocol (type) / data[2] */
> >  #define CAN_ERR_PROT_UNSPEC      0x00 /* unspecified */
> >

  reply	other threads:[~2014-11-26 10:29 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 [this message]
2014-11-26 11:32     ` Wolfgang Grandegger
2014-11-26 14:12       ` Andri Yngvason
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=20141126102659.715.14133@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).