netdev - Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 15 Sep 2010 11:42:48 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Wolfgang Grandegger <wg@...ndegger.com>
CC:	Masayuki Ohtake <masa-korg@....okisemi.com>,
	andrew.chih.howe.khor@...el.com, qi.wang@...el.com,
	netdev@...r.kernel.org, gregkh@...e.de, yong.y.wang@...el.com,
	socketcan-core@...ts.berlios.de,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	Morinaga <morinaga526@....okisemi.com>, meego-dev@...go.com,
	arjan@...ux.intel.com
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35

On 15.09.2010 09:42, Wolfgang Grandegger wrote:
> On 09/14/2010 02:46 AM, Masayuki Ohtake wrote:
>> Hi Marc,
>>
>>>>> - implement NAPI
>>>> Since Topcliff CAN HW register has only single rx buffer,
>>>> I think NAPI is unnecessary.
>>
>>> Doesn't matter. Please try to implement it.
>>
>> Our CAN driver must pull received data from CAN-HW rx buffer as fast as it can
>> so that the received data is not over-written by next received data.
>> In case of implemented with NAPI,
>> since NAPI has time-lagging after receiving first packet,
>> probability of over-written(discarded) buffer is to be high.
>> Thus, for our CAN HW, we should NOT implement with NAPI but normal "netif_rx".
> 
> True, if you just use one RX-Object. But it just helps a little bit and
> it would be much better to use the buffering on RX messages in the CAN
> controller hardware, either by using more than one RX object, or
> combining RX objects to a FIFO, or whatever your CAN controller supports.

Good point!

As long as the order of the received CAN frames is not shuffled (-> plain FIFO
behaviour) using more than one RX buffer is a good idea.

Just a remark:

During the IDF the informations about the Topcliff Controller Hub have been
reworked, so that some of the documentation became available for the public:

http://edc.intel.com/Platforms/Atom-E6xx/#hardware

Especially the Datasheet for the Platform Controller Hub EG20T can be found:

http://download.intel.com/embedded/chipsets/datasheet/324211.pdf

In chapter 13 there are some details about the CAN controller.

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html