From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi Date: Tue, 26 May 2015 11:10:51 +0200 Message-ID: <20150526111051.3f216970@bbrezillon> References: <1432301642-11470-1-git-send-email-boris.brezillon@free-electrons.com> <1432301642-11470-17-git-send-email-boris.brezillon@free-electrons.com> <55634221.6050504@free-electrons.com> <20150525164651.GA13641@io.lakedaemon.net> <20150525204302.7c79afbf@bbrezillon> <20150526090629.GB13641@io.lakedaemon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150526090629.GB13641@io.lakedaemon.net> Sender: linux-crypto-owner@vger.kernel.org To: Jason Cooper Cc: Gregory CLEMENT , Arnaud Ebalard , Herbert Xu , "David S. Miller" , linux-crypto@vger.kernel.org, Thomas Petazzoni , Sebastian Hesselbarth , Andrew Lunn , Tawfik Bayouk , Lior Amsalem , Nadav Haklai , Eran Ben-Avi , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org List-Id: devicetree@vger.kernel.org On Tue, 26 May 2015 09:06:29 +0000 Jason Cooper wrote: > On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote: > > Jason, Gregory, > > > > On Mon, 25 May 2015 16:46:51 +0000 > > Jason Cooper wrote: > > > > > On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote: > > > > Hi Boris, Arnaud, > > > > > > > > On 22/05/2015 15:34, Boris Brezillon wrote: > > > > > From: Arnaud Ebalard > > > > > > > > > > Add crypto related nodes to kirkwood.dtsi. > > > > > > > > Here you use a new compatible string but with an old binding > > > > to let the user chose between the old and the new driver. Am I right? > > > > That was not the intention, but you're right, that's exactly what's > > happening here. > > > > > > > > I thought we had settled on the user choosing by module load/ which driver is > > > compiled in? The DT should be describing the hardware, not which driver the > > > user chooses to use. > > > > Right, but I didn't want to add new compatible strings to the old > > driver in the first place, neither I wanted to support the new way of > > defining/referencing the crypto SRAMs. > > > > ITOH, if we want to benefit from the TDMA optimization on Kirkwood SoCs, > > we have to add a new compatible (unlike Orion SoCs, Kirkwood ones embed > > a TDMA engine). > > Ah, there's the HW difference I must have missed in my previous thousand-foot > overview scans :-/ > > So "marvell,orion-crypto" matches IP blocks without the TDMA engine, > "marvell,kirkwood-crypto" matches IP blocks *with* the TDMA engine. > > > This leaves the following solutions: > > - avoid changing the compatible in existing orion and kirkwood dtsi > > files > > no, in light of the above HW difference, it makes sense to change these. > > > - adding kirkwood compatible string support to the existing CESA > > driver (and I think supporting the new approach to retrieve SRAM > > memory region would make sense too) > > Or, old driver matches "marvell,orion-crypto", and the new driver matches > either compatible string. If dt has "marvell,kirkwood-crypto" then new driver > enables TDMA with the provided properties. > > We then update the dtsi for all but orion to "marvell,kirkwood-crypto". > > This may be what you are already doing. If so, please ignore my rambling. ;-) Yes, that's what I'm doing :-). But this means we're forcing kirkwood users to switch to the new driver, which is not really what you suggested in the first place. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com