From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754014AbbDJHOG (ORCPT ); Fri, 10 Apr 2015 03:14:06 -0400 Received: from down.free-electrons.com ([37.187.137.238]:51756 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752182AbbDJHOC (ORCPT ); Fri, 10 Apr 2015 03:14:02 -0400 Date: Thu, 9 Apr 2015 17:37:27 +0200 From: Andrew Lunn (by way of Boris Brezillon ) To: Boris Brezillon Message-ID: <20150409153727.GF1459@lunn.ch> References: <1428591523-1780-1-git-send-email-boris.brezillon@free-electrons.com> <20150409151846.GE1459@lunn.ch> <20150409172826.18916274@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150409172826.18916274@bbrezillon> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [PATCH 0/2] crypto: add new driver for Marvell CESA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 09, 2015 at 05:28:26PM +0200, Boris Brezillon wrote: > Hi Andrew, > > On Thu, 9 Apr 2015 17:18:46 +0200 > Andrew Lunn wrote: > > > On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: > > > Hello, > > > > > > This is an attempt to replace the mv_cesa driver by a new one to address > > > some limitations of the existing driver. > > > >From a performance and CPU load point of view the most important > > > limitation is the lack of DMA support, thus preventing us from chaining > > > crypto operations. > > > > > > I know we usually try to adapt existing drivers instead of replacing them > > > by new ones, but after trying to refactor the mv_cesa driver I realized it > > > would take longer than writing an new one from scratch. > > > > Hi Boris > > > > What is the situation with backwards compatibility? I see you have > > kept the old compatibility string, and added lots of new ones, and > > deprecated some properties. Will an old DT blob still work? > > Yep, I tried on an Orion platform, and Arnaud tried on a Kirkwood one > without any changes to the existing DT and it works. Great. It would be nice to state this in the ChangeLog or cover note. > Anyway, IMHO even those DT should be updated to use the new bindings > (sram nodes, new compatible if available, addition of clock-names > properties, ...). Agreed. Maybe you can extend the patchset to modify the relevant .dtsi files? Thanks Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn (by way of Boris Brezillon ) Subject: Re: [PATCH 0/2] crypto: add new driver for Marvell CESA Date: Thu, 9 Apr 2015 17:37:27 +0200 Message-ID: <20150409153727.GF1459@lunn.ch> References: <1428591523-1780-1-git-send-email-boris.brezillon@free-electrons.com> <20150409151846.GE1459@lunn.ch> <20150409172826.18916274@bbrezillon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20150409172826.18916274@bbrezillon> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Boris Brezillon List-Id: devicetree@vger.kernel.org On Thu, Apr 09, 2015 at 05:28:26PM +0200, Boris Brezillon wrote: > Hi Andrew, > > On Thu, 9 Apr 2015 17:18:46 +0200 > Andrew Lunn wrote: > > > On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: > > > Hello, > > > > > > This is an attempt to replace the mv_cesa driver by a new one to address > > > some limitations of the existing driver. > > > >From a performance and CPU load point of view the most important > > > limitation is the lack of DMA support, thus preventing us from chaining > > > crypto operations. > > > > > > I know we usually try to adapt existing drivers instead of replacing them > > > by new ones, but after trying to refactor the mv_cesa driver I realized it > > > would take longer than writing an new one from scratch. > > > > Hi Boris > > > > What is the situation with backwards compatibility? I see you have > > kept the old compatibility string, and added lots of new ones, and > > deprecated some properties. Will an old DT blob still work? > > Yep, I tried on an Orion platform, and Arnaud tried on a Kirkwood one > without any changes to the existing DT and it works. Great. It would be nice to state this in the ChangeLog or cover note. > Anyway, IMHO even those DT should be updated to use the new bindings > (sram nodes, new compatible if available, addition of clock-names > properties, ...). Agreed. Maybe you can extend the patchset to modify the relevant .dtsi files? Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrew@lunn.ch (Andrew Lunn) Date: Thu, 9 Apr 2015 17:37:27 +0200 Subject: [PATCH 0/2] crypto: add new driver for Marvell CESA In-Reply-To: <20150409172826.18916274@bbrezillon> References: <1428591523-1780-1-git-send-email-boris.brezillon@free-electrons.com> <20150409151846.GE1459@lunn.ch> <20150409172826.18916274@bbrezillon> Message-ID: <20150409153727.GF1459@lunn.ch> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Apr 09, 2015 at 05:28:26PM +0200, Boris Brezillon wrote: > Hi Andrew, > > On Thu, 9 Apr 2015 17:18:46 +0200 > Andrew Lunn wrote: > > > On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: > > > Hello, > > > > > > This is an attempt to replace the mv_cesa driver by a new one to address > > > some limitations of the existing driver. > > > >From a performance and CPU load point of view the most important > > > limitation is the lack of DMA support, thus preventing us from chaining > > > crypto operations. > > > > > > I know we usually try to adapt existing drivers instead of replacing them > > > by new ones, but after trying to refactor the mv_cesa driver I realized it > > > would take longer than writing an new one from scratch. > > > > Hi Boris > > > > What is the situation with backwards compatibility? I see you have > > kept the old compatibility string, and added lots of new ones, and > > deprecated some properties. Will an old DT blob still work? > > Yep, I tried on an Orion platform, and Arnaud tried on a Kirkwood one > without any changes to the existing DT and it works. Great. It would be nice to state this in the ChangeLog or cover note. > Anyway, IMHO even those DT should be updated to use the new bindings > (sram nodes, new compatible if available, addition of clock-names > properties, ...). Agreed. Maybe you can extend the patchset to modify the relevant .dtsi files? Thanks Andrew