[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Aug 2010 08:17:16 +0300
From: Daniel Baluta <daniel.baluta@...il.com>
To: "Wang, Qi" <qi.wang@...el.com>
Cc: Masayuki Ohtak <masa-korg@....okisemi.com>,
"meego-dev@...go.com" <meego-dev@...go.com>,
Wolfgang Grandegger <wg@...ndegger.com>,
"socketcan-core@...ts.berlios.de" <socketcan-core@...ts.berlios.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Khor, Andrew Chih Howe" <andrew.chih.howe.khor@...el.com>,
"gregkh@...e.de" <gregkh@...e.de>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"Wang, Yong Y" <yong.y.wang@...el.com>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
I want in the near future to write a Socket-CAN based driver for CAN EP80579.
As far as I've seen from your implementation there are a lot of
similarities between these
two drivers. Perhaps we can built a core part to both benefit from it.
>> 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.
Inded, the kfifo infrastructure has suffered great reworkings in the
latest kernel versions, but this
is not an excuse to not use it.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about implementing it with the next version?
In my opinion, as it looks now your code will never be accepted by the
SocketCAN maintainers.
thanks,
Daniel.
--
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
Powered by blists - more mailing lists