From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Subject: Re: [PATCH v4 1/1] can: add pruss CAN driver. Date: Thu, 12 May 2011 09:13:40 +0200 Message-ID: <4DCB88A4.2010901@grandegger.com> References: <1303474267-6344-1-git-send-email-subhasish@mistralsolutions.com> <2BFFDAA0A0DE4820876E5549867938EC@subhasishg> <201105112331.47954.arnd@arndb.de> <201105112344.44171.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org, davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org, Subhasish Ghosh , nsekhar-l0cyMroinI0@public.gmane.org, open list , CAN NETWORK DRIVERS , Marc Kleine-Budde , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, m-watkins-l0cyMroinI0@public.gmane.org, Alan Cox To: Arnd Bergmann Return-path: In-Reply-To: <201105112344.44171.arnd-r2nGTMty4D4@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org Errors-To: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org List-Id: netdev.vger.kernel.org On 05/11/2011 11:44 PM, Arnd Bergmann wrote: > On Wednesday 11 May 2011, Arnd Bergmann wrote: >> If that interpretation is right, I would seriously recommend rethinking >> the design of the CAN firmware for pruss, so you can start doing something >> useful with the offload engine that fits into the Socket CAN API, or that >> would be a useful extension to Socket CAN that is also implementable in >> the kernel for all other drivers in a meaningful way. > > I've looked some more into the CAN socket implementation, and I suppose that > the idea of the pruss driver was really to help do the work from the > can_rcv_filter function in hardware. That software filter is per socket while the hardware filter will be per device. > Doing this right would really mean supporting both a mode where any new > filter that gets added to socket can ends up being added to the hardware > as long as it fits, similar to how we can add additional unicast mac > addresses to an ethernet NIC. However, when the filters from all user > sockets combined can not be represented in the hardware driver, the hardware > needs to be put into a less efficient mode where all packets are returned > to the kernel and processed in software. Well, that seems sophisticated resulting in a complex implementation (may code line) also because hardware filters are very hardware dependent. Usually just one global filter can be defined. I think that's overkill. A simple interface using: ip link set can0 type can filter : [: ...] would just be fine. Wolfgang.