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
| ||
|
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