Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35

[Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>]

Hi Ohtake,

On 08/20/2010 08:01 AM, Masayuki Ohtake wrote:
> Hi Wolfgang,
> 
>>>>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
>>>>> Just take a look at kfifo.h. This structure has been changed. I remembered
>>>> there was a spin_lock from kfifo previously. Currently it's been removed, good.
>>>>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
>>>> use this structure and APIs?
>>>>
>>>> As I see it, the code related to that fifo is not used (== dead code)?
>>> I'm not familiar with kfifo structure, and I didn't like it because there need a spin_lock to use it.
> 
> We are about to study kfifo infra structure.
> I have a question.
> 
> It seems all CAN drivers accepted by upstream don't use kfifo infrastructure, right ?

Right!

> (I couldn't see message with "grep kfifo * in drivers/net/can")
> 
> If yes, why should we use the kfifo ?
> If no, please show me the kfifo reference driver

Sorry, nobody (of the socketcan core developers) said that kfifo should
be used. We believe, that an additional queuing of CAN messages is *not*
needed at all. Just eliminate the related code and follow more closely
the existing mainline drivers.

Wolfgang.