diff mbox

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

Message ID 1432301642-11470-17-git-send-email-boris.brezillon@free-electrons.com (mailing list archive)
State Changes Requested
Delegated to: Herbert Xu
Headers show

Commit Message

Boris BREZILLON May 22, 2015, 1:34 p.m. UTC 
From: Arnaud Ebalard <arno@natisbad.org>

Add crypto related nodes to kirkwood.dtsi.

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Gregory CLEMENT May 25, 2015, 3:39 p.m. UTC | #1 
Hi Boris, Arnaud,

On 22/05/2015 15:34, Boris Brezillon wrote:
> From: Arnaud Ebalard <arno@natisbad.org>
> 
> 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?

Thanks,

Gregory


> 
> Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>  arch/arm/boot/dts/kirkwood.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 464f09a..1700b2b 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -41,7 +41,7 @@
>  		pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */
>  
>  		cesa: crypto@0301 {
> -			compatible = "marvell,orion-crypto";
> +			compatible = "marvell,kirkwood-crypto";
>  			reg = <MBUS_ID(0xf0, 0x01) 0x30000 0x10000>,
>  			      <MBUS_ID(0x03, 0x01) 0 0x800>;
>  			reg-names = "regs", "sram";
>
Jason Cooper May 25, 2015, 4:46 p.m. UTC | #2 
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@natisbad.org>
> > 
> > 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?

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.

thx,

Jason.

> > Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> >  arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> > index 464f09a..1700b2b 100644
> > --- a/arch/arm/boot/dts/kirkwood.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood.dtsi
> > @@ -41,7 +41,7 @@
> >  		pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */
> >  
> >  		cesa: crypto@0301 {
> > -			compatible = "marvell,orion-crypto";
> > +			compatible = "marvell,kirkwood-crypto";
> >  			reg = <MBUS_ID(0xf0, 0x01) 0x30000 0x10000>,
> >  			      <MBUS_ID(0x03, 0x01) 0 0x800>;
> >  			reg-names = "regs", "sram";
> > 
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Boris BREZILLON May 25, 2015, 6:43 p.m. UTC | #3 
Jason, Gregory,

On Mon, 25 May 2015 16:46:51 +0000
Jason Cooper <jason@lakedaemon.net> 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@natisbad.org>
> > > 
> > > 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
Jason Cooper May 26, 2015, 9:06 a.m. UTC | #4 
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 <jason@lakedaemon.net> 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@natisbad.org>
> > > > 
> > > > 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. ;-)

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Boris BREZILLON May 26, 2015, 9:10 a.m. UTC | #5 
On Tue, 26 May 2015 09:06:29 +0000
Jason Cooper <jason@lakedaemon.net> 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 <jason@lakedaemon.net> 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@natisbad.org>
> > > > > 
> > > > > 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.
Jason Cooper May 26, 2015, 9:42 a.m. UTC | #6 
On Tue, May 26, 2015 at 11:10:51AM +0200, Boris Brezillon wrote:
> On Tue, 26 May 2015 09:06:29 +0000
> Jason Cooper <jason@lakedaemon.net> 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 <jason@lakedaemon.net> 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@natisbad.org>
> > > > > > 
> > > > > > 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.

well, I suppose I'm still clinging to the DT-as-stable-abi fantasy where
the dtb isn't locked to the kernel version.  :-P  If you're comfortable
with the change adding "marvell,kirkwood-crypto" to the old driver, then
go ahead.  It would indeed make everyone's lives easier.

thx,

Jason.


> 
> 
> -- 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 464f09a..1700b2b 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -41,7 +41,7 @@ 
 		pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */
 
 		cesa: crypto@0301 {
-			compatible = "marvell,orion-crypto";
+			compatible = "marvell,kirkwood-crypto";
 			reg = <MBUS_ID(0xf0, 0x01) 0x30000 0x10000>,
 			      <MBUS_ID(0x03, 0x01) 0 0x800>;
 			reg-names = "regs", "sram";