Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jason, Gregory,

On Mon, 25 May 2015 16:46:51 +0000
Jason Cooper <jason@xxxxxxxxxxxxxx> 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 <arno@xxxxxxxxxxxx>
> > > 
> > > 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).

This leaves the following solutions:
 - avoid changing the compatible in existing orion and kirkwood dtsi
   files
 - 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)

Best Regards,

Boris
-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux