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

On Tue, 26 May 2015 09:06:29 +0000
Jason Cooper [off-list ref] wrote:

On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:

quoted

Jason, Gregory,

On Mon, 25 May 2015 16:46:51 +0000
Jason Cooper [off-list ref] wrote:

quoted

On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:

quoted

Hi Boris, Arnaud,

On 22/05/2015 15:34, Boris Brezillon wrote:

quoted

From: Arnaud Ebalard <redacted>

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.

quoted

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.

quoted

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.

quoted

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.

quoted

 - 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