netdev - Re: can: c_can: TX delivery

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: <4D8B169B.60401@pengutronix.de>
Date:	Thu, 24 Mar 2011 11:02:03 +0100
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Jan Altenberg <jan@...utronix.de>
CC:	Kurt Van Dijck <kurt.van.dijck@....be>, bhupesh.sharma@...com,
	wg@...ndegger.com, b.spranger@...utronix.de, netdev@...r.kernel.org
Subject: Re: can: c_can: TX delivery

On 03/23/2011 04:32 PM, Jan Altenberg wrote:
> Hi,
> 
>> I split your 2 questions in 2 replies.
> 
> Thanks :)
> 
>> not sure if I made my point.  Note that this will eliminate the need
>> for explicit wrap-around.  It's done implicitely.
> 
> Hmmm, I double-checked the datasheet, which gives the following statement:
> "The receive/transmit priority for the Message Objects is attached to
> the message number.  Message Object 1 has the highest priority, while
> Message Object 32 has the lowest priority. If more than one
> transmission request is pending, they are serviced due to the priority
> of the corresponding Message Object."
> 
> So, we shouldn't run into the scenario I described in my previous mail

ACK - the tx implementation is borrowed from the at91 driver. There we
have a prio field per mailbox (which is _not_ the CAN id), and the
mailbox number itself. If two mailboxes have the same prio the mailbox
with the lower number is send first. So we start with the highest prio
in mailbox 0, until the last mb, then decrease the prio and start with
mb 0. Special care is taken in prio wrap around and all mailboxes full.

Please recheck if this is implemented on the c_can driver correctly.

> and the existing implementation should be OK, right?!  I'm quite sure
> I've seen a situation where msg_obj 17 "seemed" to be pending, while
> msg_obj 18 and 19 already have been transmitted. But in that case, I
> enabled ONESHOT for the can interface, which enables the DA mode
> (automatic
> retransmission is disabled). The errata sheet for c_can covers that

Oh...Oneshot means if TX fails (due to higher prio frame on the bus) it
won't be tx'ed again. IIRC in the at91 there's a bit signalling that TX
has been aborted due to oneshot. Maybe an interrupt can be enabled, too.

Hmm....the driver advertised it supports oneshot mode. Has this been
tested? If oneshot isn't working we should disable it in the driver
until it has been fixed.

> mode. There's a problem with "Concurrent transmission requests" and I'm
> quite sure my test-case hit that problem.
> 
> I'm quite new to Bosch's c_can, so maybe Bhupesh can give some feedback
> (or beat me for causing some confusion ;-)).

cheers, 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" (263 bytes)