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: <ff5d44d1-3bfe-8dae-2aaa-561ab0cb989c@timesys.com>
Date:   Fri, 17 Mar 2017 14:28:42 -0400
From:   Akshay Bhat <akshay.bhat@...esys.com>
To:     Wolfgang Grandegger <wg@...ndegger.com>,
        Akshay Bhat <nodeax@...il.com>
Cc:     mkl@...gutronix.de, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

Hi Wolfgang,

On 03/17/2017 01:04 PM, Wolfgang Grandegger wrote:
> 
> Hm, that's unusual. Cable disconnected and then send a message:
> 
> $ grep /proc/interrupts; sleep 10; /proc/interrupts
> 
> should make things clear. But maybe it's a clever chip and it does stop
> sending error messages if the error counter does not change any more.
> After bus-off, the chip is quiet, of course. Should have a closer look
> to the CAN standard.
>

The interrupt count does not increment after device reaches
tx-error-passive (with cable disconnected).

# while true; do grep -i hi3110 /proc/interrupts; sleep 10; done &
[1] 793
#
111:          0          0  gpio-mxc  12 Edge      hi3110
# candump -t d -e any,0:0,#FFFFFFF &
[2] 798
# cansend can0 123#
#
 (000.000000)  can0  20000004   [8]  00 08 00 00 00 00 60 00   ERRORFRAME
	controller-problem{tx-error-warning}
	error-counter-tx-rx{{96}{0}}
 (000.002122)  can0  20000004   [8]  00 20 00 00 00 00 80 00   ERRORFRAME
	controller-problem{tx-error-passive}
	error-counter-tx-rx{{128}{0}}
111:         10          0  gpio-mxc  12 Edge      hi3110
111:         10          0  gpio-mxc  12 Edge      hi3110
111:         10          0  gpio-mxc  12 Edge      hi3110

>>> So far using NAPI was mandatory. There is the problem of out-of-order
>>> message reception if handled in the isr on multi processor systems.
>>> Marc, what is the current policy?
>>>
>>
>> Since this is a SPI based CAN, I am wary for any additional latencies
>> NAPI might introduce. The RX handling is being done at the very
>> beginning of the ISR for this reason.
>>
>> Can we go ahead with the existing implementation and re-visit this at a
>> later time?
> 
> Likely yes, as Marc has already reviewed the driver once.
> 

Thanks, I will go ahead and submit v4 patch.

> BTW: what system board/processor are you using?
> 

It is a custom board using Phytec phyFLEX-i.MX6 Dual SOM.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ