All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeroen Hofstee <jhofstee@victronenergy.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	linux-can@vger.kernel.org
Cc: Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	"moderated list:ARM/Allwinner sunXi SoC support" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] can: don't count arbitration lose as an error
Date: Sun, 29 Nov 2020 16:52:17 +0100	[thread overview]
Message-ID: <4319bb31-972c-78e1-ec20-11fdfd04d6bd@victronenergy.com> (raw)
In-Reply-To: <042ad21c-e238-511b-1282-2ea226e572ff@hartkopp.net>

Hello Oliver,

On 11/28/20 6:23 PM, Oliver Hartkopp wrote:
>
>
> On 27.11.20 12:09, Jeroen Hofstee wrote:
>> Hi,
>>
>> On 11/27/20 11:30 AM, Marc Kleine-Budde wrote:
>>> On 11/27/20 10:59 AM, Jeroen Hofstee wrote:
>>>> Losing arbitration is normal in a CAN-bus network, it means that a
>>>> higher priority frame is being send and the pending message will be
>>>> retried later. Hence most driver only increment arbitration_lost, but
>>>> the sja1000 and sun4i driver also incremeant tx_error, causing errors
>>>> to be reported on a normal functioning CAN-bus. So stop counting them
>>>> as errors.
>>> Sounds plausible.
>>>
>>>> For completeness, the Kvaser USB hybra also increments the tx_error
>>>> on arbitration lose, but it does so in single shot. Since in that
>>>> case the message is not retried, that behaviour is kept.
>>> You mean only in one shot mode?
>>
>> Yes, well at least the function is called 
>> kvaser_usb_hydra_one_shot_fail.
>>
>>
>>>   What about one shot mode on the sja1000 cores?
>>
>>
>> That is a good question. I guess it will be counted as error by:
>>
>>          if (isrc & IRQ_TI) {
>>              /* transmission buffer released */
>>              if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT &&
>>                  !(status & SR_TCS)) {
>>                  stats->tx_errors++;
>>                  can_free_echo_skb(dev, 0);
>>              } else {
>>                  /* transmission complete */
>>                  stats->tx_bytes +=
>>                      priv->read_reg(priv, SJA1000_FI) & 0xf;
>>                  stats->tx_packets++;
>>                  can_get_echo_skb(dev, 0);
>>              }
>>              netif_wake_queue(dev);
>>              can_led_event(dev, CAN_LED_EVENT_TX);
>>          }
>>
>>  From the datasheet, Transmit Interrupt:
>>
>> "set; this bit is set whenever the transmit bufferstatus
>> changes from ‘0-to-1’ (released) and the TIE bit is set
>> within the interrupt enable register".
>>
>> I cannot test it though, since I don't have a sja1000.
>
> I have a PCAN-ExpressCard 34 here, which should make it in a test 
> setup as it acts as a PCI attached SJA1000.
>
> Will take a look at that arbitration lost behaviour on Monday. A 
> really interesting detail!
>
>

Thanks, appreciated. I would be surprised if this path is not taken though.

With kind regards,

Jeroen



WARNING: multiple messages have this Message-ID (diff)
From: Jeroen Hofstee <jhofstee@victronenergy.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	linux-can@vger.kernel.org
Cc: "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	"moderated list:ARM/Allwinner sunXi SoC support"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] can: don't count arbitration lose as an error
Date: Sun, 29 Nov 2020 16:52:17 +0100	[thread overview]
Message-ID: <4319bb31-972c-78e1-ec20-11fdfd04d6bd@victronenergy.com> (raw)
In-Reply-To: <042ad21c-e238-511b-1282-2ea226e572ff@hartkopp.net>

Hello Oliver,

On 11/28/20 6:23 PM, Oliver Hartkopp wrote:
>
>
> On 27.11.20 12:09, Jeroen Hofstee wrote:
>> Hi,
>>
>> On 11/27/20 11:30 AM, Marc Kleine-Budde wrote:
>>> On 11/27/20 10:59 AM, Jeroen Hofstee wrote:
>>>> Losing arbitration is normal in a CAN-bus network, it means that a
>>>> higher priority frame is being send and the pending message will be
>>>> retried later. Hence most driver only increment arbitration_lost, but
>>>> the sja1000 and sun4i driver also incremeant tx_error, causing errors
>>>> to be reported on a normal functioning CAN-bus. So stop counting them
>>>> as errors.
>>> Sounds plausible.
>>>
>>>> For completeness, the Kvaser USB hybra also increments the tx_error
>>>> on arbitration lose, but it does so in single shot. Since in that
>>>> case the message is not retried, that behaviour is kept.
>>> You mean only in one shot mode?
>>
>> Yes, well at least the function is called 
>> kvaser_usb_hydra_one_shot_fail.
>>
>>
>>>   What about one shot mode on the sja1000 cores?
>>
>>
>> That is a good question. I guess it will be counted as error by:
>>
>>          if (isrc & IRQ_TI) {
>>              /* transmission buffer released */
>>              if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT &&
>>                  !(status & SR_TCS)) {
>>                  stats->tx_errors++;
>>                  can_free_echo_skb(dev, 0);
>>              } else {
>>                  /* transmission complete */
>>                  stats->tx_bytes +=
>>                      priv->read_reg(priv, SJA1000_FI) & 0xf;
>>                  stats->tx_packets++;
>>                  can_get_echo_skb(dev, 0);
>>              }
>>              netif_wake_queue(dev);
>>              can_led_event(dev, CAN_LED_EVENT_TX);
>>          }
>>
>>  From the datasheet, Transmit Interrupt:
>>
>> "set; this bit is set whenever the transmit bufferstatus
>> changes from ‘0-to-1’ (released) and the TIE bit is set
>> within the interrupt enable register".
>>
>> I cannot test it though, since I don't have a sja1000.
>
> I have a PCAN-ExpressCard 34 here, which should make it in a test 
> setup as it acts as a PCI attached SJA1000.
>
> Will take a look at that arbitration lost behaviour on Monday. A 
> really interesting detail!
>
>

Thanks, appreciated. I would be surprised if this path is not taken though.

With kind regards,

Jeroen



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-29 15:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27  9:59 [PATCH] can: don't count arbitration lose as an error Jeroen Hofstee
2020-11-27  9:59 ` Jeroen Hofstee
2020-11-27 10:30 ` Marc Kleine-Budde
2020-11-27 10:30   ` Marc Kleine-Budde
2020-11-27 11:09   ` Jeroen Hofstee
2020-11-27 11:09     ` Jeroen Hofstee
2020-11-27 16:02     ` Jeroen Hofstee
2020-11-28 17:23     ` Oliver Hartkopp
2020-11-28 17:23       ` Oliver Hartkopp
2020-11-29 15:52       ` Jeroen Hofstee [this message]
2020-11-29 15:52         ` Jeroen Hofstee
2020-12-02 14:35     ` Oliver Hartkopp
2020-12-02 14:35       ` Oliver Hartkopp
2020-12-02 15:37       ` Jeroen Hofstee
2020-12-02 15:37         ` Jeroen Hofstee
2020-12-02 16:22         ` Oliver Hartkopp
2020-12-02 16:22           ` Oliver Hartkopp
2020-12-02 16:31           ` Jeroen Hofstee
2020-12-02 16:31             ` Jeroen Hofstee
2020-11-30 11:50   ` Marc Kleine-Budde
2020-11-30 11:50     ` Marc Kleine-Budde

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=4319bb31-972c-78e1-ec20-11fdfd04d6bd@victronenergy.com \
    --to=jhofstee@victronenergy.com \
    --cc=jernej.skrabec@siol.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=wens@csie.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.