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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4C90A60E.5040900@grandegger.com>
Date:	Wed, 15 Sep 2010 12:55:10 +0200
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
CC:	andrew.chih.howe.khor@...el.com, socketcan-core@...ts.berlios.de,
	qi.wang@...el.com, netdev@...r.kernel.org, gregkh@...e.de,
	yong.y.wang@...el.com, Masayuki Ohtake <masa-korg@....okisemi.com>,
	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 09/15/2010 11:42 AM, Oliver Hartkopp wrote:
> 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.

Ah, thanks for the link. The CAN controller seems then to be similar to
the OKI MSM9225B.

Wolfgang.

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