netdev - Re: [PATCH 1/1] can: sja1000: clear interrupts on start

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]

Date:	Wed, 11 Nov 2015 13:37:12 +0100
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Mirza Krak <mirza.krak@...tmobility.com>
Cc:	wg@...ndegger.com, andri.yngvason@...el.com,
	"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
	netdev@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christian Magnusson <Christian.Magnusson@...con.com>
Subject: Re: [PATCH 1/1] can: sja1000: clear interrupts on start

On 11/11/2015 01:29 PM, Mirza Krak wrote:
>> Can you put a scope on the interrupt pin and see if it's a problem of
>> the SoC and/or Linux or the SJA1000 not pulling the IRQ line.
> 
> A little demonstration on what it looks like when the system is
> resumed (added a printk in sja1000_start without my patch, though my
> printk also clears IR register):
> 
> root@...-vcc:/opt/hm# ip -det link show can0
> 33: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state
> UNKNOWN mode DEFAULT qlen 10
>     link/can
>     can state ERROR-ACTIVE (berr-counter tx 0 rx 128) restart-ms 0
>     bitrate 500000 sample-point 0.875
>     tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1
>     sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>     clock 12000000
> root@...-vcc:/opt/hm# ifconfig can0 down
> root@...-vcc:/opt/hm# ifconfig can0 up
> [ 1612.621187] sja1000: MOD: 0x1
> [ 1612.640992] sja1000: SR: 0x7c
> [ 1612.660039] sja1000: IR: 0x24
> 
> Also did a measurement with the scope, it is the SJA1000 chip not
> pulling the IRQ line.
> 
> I can actually send one frame when the controller is in this state but
> never get a TI interrupt.

Thanks for testing.

[...]

>>> Yes, resume code should be implemented to handle this and other
>>> problems (receive data). But still a DOWN/UP procedure should clear
>>> any previous state that could exist in the controller registers.
>>
>> I'll add your patch to can/master and add stable on Cc. Looking forward
>> for some suspend/resume code :)
> 
> Looking forward to writing suspend/resume code :).
> 
> Some cred should go to Christian (added him to CC) for finding this
> problem and reporting it to me.

I'll add a

Reported-by: Christian Magnusson <Christian.Magnusson@...con.com>

to the patch.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)