All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Jeroen Hofstee <jhofstee@victronenergy.com>,
	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: Wed, 2 Dec 2020 17:22:56 +0100	[thread overview]
Message-ID: <b08226a0-bd96-637f-954d-fb8dedc0017b@hartkopp.net> (raw)
In-Reply-To: <405f9e1a-e653-e82d-6d45-a1e5298b5c82@victronenergy.com>

Hello Jeroen,

On 02.12.20 16:37, Jeroen Hofstee wrote:
> On 12/2/20 3:35 PM, Oliver Hartkopp wrote:

>> Do we agree that in one-shot mode both the tx_errors and the 
>> arbitration_lost counters are increased in the arbitration-lost case?
>>
>> At least this would fit to the Kvaser USB behaviour.
> 
> 
> I have no opinion about that. I just kept existing behavior.

That's ok for me either.

>> And btw. I wondered if we should remove the check for 
>> CAN_CTRLMODE_ONE_SHOT here, as we ALWAYS should count a tx_error and 
>> drop the echo_skb when we have a TX-interrupt and TX-complete flag is 
>> zero.
>>
>> So replace:
>>
>> if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT &&
>>                   !(status & SR_TCS)) {
>>
>> with:
>>
>> if (!(status & SR_TCS)) {
>>
>> Any suggestions?
>>
> 
> In theory, yes. But I can't think of a reason you would end
> up there without CAN_CTRLMODE_ONE_SHOT being set.

Right. Me too. But for that reason I would remove that extra check to 
catch this error even if CAN_CTRLMODE_ONE_SHOT is not enabled.

> Aborting the current transmission in non single shot mode
> will get you there and incorrectly report the message as
> transmitted, but that is not implemented afaik.

Ahem, no. If you get there the echo_skb is deleted and the tx_errors 
counter is increased. Just as it should be.

Regards,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Jeroen Hofstee <jhofstee@victronenergy.com>,
	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: Wed, 2 Dec 2020 17:22:56 +0100	[thread overview]
Message-ID: <b08226a0-bd96-637f-954d-fb8dedc0017b@hartkopp.net> (raw)
In-Reply-To: <405f9e1a-e653-e82d-6d45-a1e5298b5c82@victronenergy.com>

Hello Jeroen,

On 02.12.20 16:37, Jeroen Hofstee wrote:
> On 12/2/20 3:35 PM, Oliver Hartkopp wrote:

>> Do we agree that in one-shot mode both the tx_errors and the 
>> arbitration_lost counters are increased in the arbitration-lost case?
>>
>> At least this would fit to the Kvaser USB behaviour.
> 
> 
> I have no opinion about that. I just kept existing behavior.

That's ok for me either.

>> And btw. I wondered if we should remove the check for 
>> CAN_CTRLMODE_ONE_SHOT here, as we ALWAYS should count a tx_error and 
>> drop the echo_skb when we have a TX-interrupt and TX-complete flag is 
>> zero.
>>
>> So replace:
>>
>> if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT &&
>>                   !(status & SR_TCS)) {
>>
>> with:
>>
>> if (!(status & SR_TCS)) {
>>
>> Any suggestions?
>>
> 
> In theory, yes. But I can't think of a reason you would end
> up there without CAN_CTRLMODE_ONE_SHOT being set.

Right. Me too. But for that reason I would remove that extra check to 
catch this error even if CAN_CTRLMODE_ONE_SHOT is not enabled.

> Aborting the current transmission in non single shot mode
> will get you there and incorrectly report the message as
> transmitted, but that is not implemented afaik.

Ahem, no. If you get there the echo_skb is deleted and the tx_errors 
counter is increased. Just as it should be.

Regards,
Oliver

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

  reply	other threads:[~2020-12-02 16:26 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
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 [this message]
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=b08226a0-bd96-637f-954d-fb8dedc0017b@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=jernej.skrabec@siol.net \
    --cc=jhofstee@victronenergy.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --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.