From: Arnaud Ebalard <[email protected]>
Add crypto related nodes to kirkwood.dtsi.
Signed-off-by: Arnaud Ebalard <[email protected]>
Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/[email protected]>
---
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";
--
1.9.1
Hi Boris, Arnaud,
On 22/05/2015 15:34, Boris Brezillon wrote:
> From: Arnaud Ebalard <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Boris Brezillon <[email protected]>
> ---
> 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
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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Boris Brezillon <[email protected]>
> > ---
> > 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
Jason, Gregory,
On Mon, 25 May 2015 16:46:51 +0000
Jason Cooper <[email protected]> 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 <[email protected]>
> > >
> > > 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
On Tue, 26 May 2015 09:06:29 +0000
Jason Cooper <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > > > >
> > > > > 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
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 <[email protected]> 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 <[email protected]>
> > > >
> > > > 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.
On Tue, May 26, 2015 at 11:10:51AM +0200, Boris Brezillon wrote:
> On Tue, 26 May 2015 09:06:29 +0000
> Jason Cooper <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > > > > >
> > > > > > 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