netdev - Re: [PATCH] can: don't count arbitration lose as an error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <042ad21c-e238-511b-1282-2ea226e572ff@hartkopp.net>
Date:   Sat, 28 Nov 2020 18:23:15 +0100
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     Jeroen Hofstee <jhofstee@...tronenergy.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can@...r.kernel.org
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        "moderated list:ARM/Allwinner sunXi SoC support" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] can: don't count arbitration lose as an error



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!

Best,
Oliver

> 
>>
>>> Signed-off-by: Jeroen Hofstee <jhofstee@...tronenergy.com>
>> I've split this into two patches, and added Fixes: lines, and pushed 
>> this for
>> now to linux-can/sja1000.
>>
> Thanks, regards,
> 
> Jeroen
> 
>