[PATCH] powerpc: Add FSL SEC node to documentation

[PATCH] powerpc: Add FSL SEC node to documentation

[Kim Phillips]

Documentation: Added FSL SOC SEC node definition

Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

---
commit 97d971c1d30e77a453cacaef72c32e00381ab02a
tree 4b815caece1c05b33309f8852eeccd90f020ca49
parent c4a1745aa09fc110afdefea0e5d025043e348bae
author Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar 2006 19:31:21 -0600
committer Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar 2006 19:31:21 -0600

 Documentation/powerpc/booting-without-of.txt |   73 ++++++++++++++++++++++++++
 1 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d02c649..72f3241 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
 	};
 
 
+   g) Freescale SOC SEC Security Engines
+
+   Required properties:
+
+    - device_type : Should be "crypto"
+    - model : Model of the device.  Should be "SEC1" or "SEC2"
+    - compatible : Should be "talitos"
+    - reg : Offset and length of the register set for the device
+    - interrupts : <a b> where a is the interrupt number and b is a
+      field that represents an encoding of the sense and level
+      information for the interrupt.  This should be encoded based on
+      the information in section 2) depending on the type of interrupt
+      controller you have.
+    - interrupt-parent : the phandle for the interrupt controller that
+      services interrupts for this device.
+    - num-channels : An integer representing the number of channels
+      available.  Most modern SEC's have 4 channels.
+    - channel-fifo-len : An integer representing the number of descriptor
+      pointers each channel fetch fifo can hold.  Most modern SEC channel 
+      fetch fifos can hold 24 descriptor pointers.
+    - exec-units-mask : The bitmask representing what execution units (EUs)
+      are available. It's a single 32 bit cell. EU information should be
+      encoded following the SEC's Descriptor Header Dword EU_SEL0 field 
+      documentation, i.e. as follows:
+
+        bit 0 = reserved - should be 0
+        bit 1 = set if SEC has the ARC4 EU (AFEU)
+        bit 2 = set if SEC has the DES/3DES EU (DEU)
+        bit 3 = set if SEC has the message digest EU (MDEU)
+        bit 4 = set if SEC has the random number generator EU (RNG)
+        bit 5 = set if SEC has the public key EU (PKEU)
+        bit 6 = set if SEC has the AES EU (AESU)
+        bit 7 = set if SEC has the Kasumi EU (KEU)
+
+      bits 8 through 31 are reserved for future SEC EUs.
+
+    - descriptor-types-mask : The bitmask representing what descriptors
+      are available. It's a single 32 bit cell. Descriptor type information 
+      should be encoded as follows:
+
+        bit 0  = set if SEC supports the aesu_ctr_nonsnoop descriptor type
+        bit 1  = set if SEC supports the ipsec_esp descriptor type
+        bit 2  = set if SEC supports the common_nonsnoop descriptor type
+        bit 3  = set if SEC supports the 802.11i AES ccmp descriptor type
+        bit 4  = set if SEC supports the hmac_snoop_no_afeu descriptor type
+        bit 5  = set if SEC supports the srtp descriptor type
+        bit 6  = reserved - should be 0
+        bit 7  = set if SEC supports the pkeu_assemble descriptor type
+        bit 8  = reserved - should be 0
+        bit 9  = set if SEC supports the pkeu_ptmul descriptor type
+        bit 10 = set if SEC supports the common_nonsnoop_afeu descriptor type
+        bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+      ..and so on and so forth, following the SEC's Descriptor Header Dword
+      DESC_TYPE field definition in reference documentation.
+ 
+  Example:
+
+	/* MPC8548E */
+	crypto@30000 {
+		device_type = "crypto";
+		model = "SEC2";
+		compatible = "talitos";
+		reg = <30000 10000>;
+		interrupts = <1d 3>;
+		interrupt-parent = <40000>;
+		num-channels = <4>;
+		channel-fifo-len = <24>;
+		exec-units-mask = <000000fe>;
+		descriptor-types-mask = <073f1127>;
+	};
+
+
    More devices will be defined as this spec matures.
 
 

-- 

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Hollis Blanchard]

On Monday 20 March 2006 19:59, Kim Phillips wrote:
> diff --git a/Documentation/powerpc/booting-without-of.txt=20
b/Documentation/powerpc/booting-without-of.txt
> index d02c649..72f3241 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
> =A0=A0=A0=A0=A0=A0};
> =A0
> =A0
> + =A0 g) Freescale SOC SEC Security Engines
> +
> + =A0 Required properties:
> +
> + =A0 =A0- device_type : Should be "crypto"
> + =A0 =A0- model : Model of the device. =A0Should be "SEC1" or "SEC2"
> + =A0 =A0- compatible : Should be "talitos"
[snip]

Have you consulted with any other vendors regarding these properties? I kno=
w=20
there is no IEEE1275 binding for these sorts of devices, but we can at leas=
t=20
attempt to standardize it (even in the absence of the Open Firmware Working=
=20
Group)...

=2DHollis

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Kim Phillips]

On Mon, 20 Mar 2006 20:14:43 -0600
Hollis Blanchard <hollis@penguinppc.org> wrote:

> On Monday 20 March 2006 19:59, Kim Phillips wrote:
> > diff --git a/Documentation/powerpc/booting-without-of.txt=20
> b/Documentation/powerpc/booting-without-of.txt
> > index d02c649..72f3241 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
> > =A0=A0=A0=A0=A0=A0};
> > =A0
> > =A0
> > + =A0 g) Freescale SOC SEC Security Engines
> > +
> > + =A0 Required properties:
> > +
> > + =A0 =A0- device_type : Should be "crypto"
> > + =A0 =A0- model : Model of the device. =A0Should be "SEC1" or "SEC2"
> > + =A0 =A0- compatible : Should be "talitos"
> [snip]
>=20
> Have you consulted with any other vendors regarding these properties? I k=
now=20
> there is no IEEE1275 binding for these sorts of devices, but we can at le=
ast=20
> attempt to standardize it (even in the absence of the Open Firmware Worki=
ng=20
> Group)...
>=20
> -Hollis

I took a look at some equivalent devices, the problem is they're all so dif=
ferent, architecturally.  otoh, I'm open to collaborate with others on the =
list in an effort to standardize it.

btw, I had omitted some descriptor types.  Here's a replacement patch:


Documentation: Added FSL SOC SEC node definition

Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

---
commit 97d971c1d30e77a453cacaef72c32e00381ab02a
tree 4b815caece1c05b33309f8852eeccd90f020ca49
parent c4a1745aa09fc110afdefea0e5d025043e348bae
author Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar 2006 19:31:21 =
-0600
committer Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar 2006 19:31:=
21 -0600

 Documentation/powerpc/booting-without-of.txt |   73 ++++++++++++++++++++++=
++++
 1 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/p=
owerpc/booting-without-of.txt
index d02c649..72f3241 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
 	};
=20
=20
+   g) Freescale SOC SEC Security Engines
+
+   Required properties:
+
+    - device_type : Should be "crypto"
+    - model : Model of the device.  Should be "SEC1" or "SEC2"
+    - compatible : Should be "talitos"
+    - reg : Offset and length of the register set for the device
+    - interrupts : <a b> where a is the interrupt number and b is a
+      field that represents an encoding of the sense and level
+      information for the interrupt.  This should be encoded based on
+      the information in section 2) depending on the type of interrupt
+      controller you have.
+    - interrupt-parent : the phandle for the interrupt controller that
+      services interrupts for this device.
+    - num-channels : An integer representing the number of channels
+      available.  Most modern SEC's have 4 channels.
+    - channel-fifo-len : An integer representing the number of descriptor
+      pointers each channel fetch fifo can hold.  Most modern SEC channel=
=20
+      fetch fifos can hold 24 descriptor pointers.
+    - exec-units-mask : The bitmask representing what execution units (EUs)
+      are available. It's a single 32 bit cell. EU information should be
+      encoded following the SEC's Descriptor Header Dword EU_SEL0 field=20
+      documentation, i.e. as follows:
+
+        bit 0 =3D reserved - should be 0
+        bit 1 =3D set if SEC has the ARC4 EU (AFEU)
+        bit 2 =3D set if SEC has the DES/3DES EU (DEU)
+        bit 3 =3D set if SEC has the message digest EU (MDEU)
+        bit 4 =3D set if SEC has the random number generator EU (RNG)
+        bit 5 =3D set if SEC has the public key EU (PKEU)
+        bit 6 =3D set if SEC has the AES EU (AESU)
+        bit 7 =3D set if SEC has the Kasumi EU (KEU)
+
+      bits 8 through 31 are reserved for future SEC EUs.
+
+    - descriptor-types-mask : The bitmask representing what descriptors
+      are available. It's a single 32 bit cell. Descriptor type informatio=
n=20
+      should be encoded as follows:
+
+        bit 0  =3D set if SEC supports the aesu_ctr_nonsnoop descriptor ty=
pe
+        bit 1  =3D set if SEC supports the ipsec_esp descriptor type
+        bit 2  =3D set if SEC supports the common_nonsnoop descriptor type
+        bit 3  =3D set if SEC supports the 802.11i AES ccmp descriptor type
+        bit 4  =3D set if SEC supports the hmac_snoop_no_afeu descriptor t=
ype
+        bit 5  =3D set if SEC supports the srtp descriptor type
+        bit 6  =3D set if SEC supports the non_hmac_snoop_no_afeu descript=
or type
+        bit 7  =3D set if SEC supports the pkeu_assemble descriptor type
+        bit 8  =3D set if SEC supports the aesu_key_expand_output descript=
or type
+        bit 9  =3D set if SEC supports the pkeu_ptmul descriptor type
+        bit 10 =3D set if SEC supports the common_nonsnoop_afeu descriptor=
 type
+        bit 11 =3D set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+      ..and so on and so forth, following the SEC's Descriptor Header Dword
+      DESC_TYPE field definition in reference documentation.
+=20
+  Example:
+
+	/* MPC8548E */
+	crypto@30000 {
+		device_type =3D "crypto";
+		model =3D "SEC2";
+		compatible =3D "talitos";
+		reg =3D <30000 10000>;
+		interrupts =3D <1d 3>;
+		interrupt-parent =3D <40000>;
+		num-channels =3D <4>;
+		channel-fifo-len =3D <24>;
+		exec-units-mask =3D <000000fe>;
+		descriptor-types-mask =3D <073f1127>;
+	};
+
+
    More devices will be defined as this spec matures.
=20
=20



--=20

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Kumar Gala]

On Mar 21, 2006, at 11:48 AM, Kim Phillips wrote:

> On Mon, 20 Mar 2006 20:14:43 -0600
> Hollis Blanchard <hollis@penguinppc.org> wrote:
>
>> On Monday 20 March 2006 19:59, Kim Phillips wrote:
>>> diff --git a/Documentation/powerpc/booting-without-of.txt
>> b/Documentation/powerpc/booting-without-of.txt
>>> index d02c649..72f3241 100644
>>> --- a/Documentation/powerpc/booting-without-of.txt
>>> +++ b/Documentation/powerpc/booting-without-of.txt
>>> @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
>>>       };
>>>
>>>
>>> +   g) Freescale SOC SEC Security Engines
>>> +
>>> +   Required properties:
>>> +
>>> +    - device_type : Should be "crypto"
>>> +    - model : Model of the device.  Should be "SEC1" or "SEC2"
>>> +    - compatible : Should be "talitos"
>> [snip]
>>
>> Have you consulted with any other vendors regarding these  
>> properties? I know
>> there is no IEEE1275 binding for these sorts of devices, but we  
>> can at least
>> attempt to standardize it (even in the absence of the Open  
>> Firmware Working
>> Group)...
>>
>> -Hollis
>
> I took a look at some equivalent devices, the problem is they're  
> all so different, architecturally.  otoh, I'm open to collaborate  
> with others on the list in an effort to standardize it.
>
> btw, I had omitted some descriptor types.  Here's a replacement patch:
>
>
> Documentation: Added FSL SOC SEC node definition
>
> Updated the documentation to include the definition of the SEC device
> node format for Freescale SOC devices.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>
> ---
> commit 97d971c1d30e77a453cacaef72c32e00381ab02a
> tree 4b815caece1c05b33309f8852eeccd90f020ca49
> parent c4a1745aa09fc110afdefea0e5d025043e348bae
> author Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar 2006  
> 19:31:21 -0600
> committer Kim Phillips <kim.phillips@freescale.com> Mon, 20 Mar  
> 2006 19:31:21 -0600
>
>  Documentation/powerpc/booting-without-of.txt |   73 +++++++++++++++ 
> +++++++++++
>  1 files changed, 73 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/ 
> Documentation/powerpc/booting-without-of.txt
> index d02c649..72f3241 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
>  	};
>
>
> +   g) Freescale SOC SEC Security Engines
> +
> +   Required properties:
> +
> +    - device_type : Should be "crypto"
> +    - model : Model of the device.  Should be "SEC1" or "SEC2"
> +    - compatible : Should be "talitos"
> +    - reg : Offset and length of the register set for the device
> +    - interrupts : <a b> where a is the interrupt number and b is a
> +      field that represents an encoding of the sense and level
> +      information for the interrupt.  This should be encoded based on
> +      the information in section 2) depending on the type of  
> interrupt
> +      controller you have.
> +    - interrupt-parent : the phandle for the interrupt controller  
> that
> +      services interrupts for this device.
> +    - num-channels : An integer representing the number of channels
> +      available.  Most modern SEC's have 4 channels.

Drop the part about Most modern... in five years when someone reads  
this it will not be modern anymore.

> +    - channel-fifo-len : An integer representing the number of  
> descriptor
> +      pointers each channel fetch fifo can hold.  Most modern SEC  
> channel
> +      fetch fifos can hold 24 descriptor pointers.

ditto about modern.

> +    - exec-units-mask : The bitmask representing what execution  
> units (EUs)
> +      are available. It's a single 32 bit cell. EU information  
> should be
> +      encoded following the SEC's Descriptor Header Dword EU_SEL0  
> field
> +      documentation, i.e. as follows:
> +
> +        bit 0 = reserved - should be 0
> +        bit 1 = set if SEC has the ARC4 EU (AFEU)
> +        bit 2 = set if SEC has the DES/3DES EU (DEU)
> +        bit 3 = set if SEC has the message digest EU (MDEU)
> +        bit 4 = set if SEC has the random number generator EU (RNG)
> +        bit 5 = set if SEC has the public key EU (PKEU)
> +        bit 6 = set if SEC has the AES EU (AESU)
> +        bit 7 = set if SEC has the Kasumi EU (KEU)
> +
> +      bits 8 through 31 are reserved for future SEC EUs.
> +
> +    - descriptor-types-mask : The bitmask representing what  
> descriptors
> +      are available. It's a single 32 bit cell. Descriptor type  
> information
> +      should be encoded as follows:
> +
> +        bit 0  = set if SEC supports the aesu_ctr_nonsnoop  
> descriptor type
> +        bit 1  = set if SEC supports the ipsec_esp descriptor type
> +        bit 2  = set if SEC supports the common_nonsnoop  
> descriptor type
> +        bit 3  = set if SEC supports the 802.11i AES ccmp  
> descriptor type
> +        bit 4  = set if SEC supports the hmac_snoop_no_afeu  
> descriptor type
> +        bit 5  = set if SEC supports the srtp descriptor type
> +        bit 6  = set if SEC supports the non_hmac_snoop_no_afeu  
> descriptor type
> +        bit 7  = set if SEC supports the pkeu_assemble descriptor  
> type
> +        bit 8  = set if SEC supports the aesu_key_expand_output  
> descriptor type
> +        bit 9  = set if SEC supports the pkeu_ptmul descriptor type
> +        bit 10 = set if SEC supports the common_nonsnoop_afeu  
> descriptor type
> +        bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor  
> type
> +
> +      ..and so on and so forth, following the SEC's Descriptor  
> Header Dword
> +      DESC_TYPE field definition in reference documentation.

Would this be a bit more clear, if you explicitly stated that the  
DESC_TYPE value directly corresponds to the bit encoding, like you  
did for EU_SEL0.

> +
> +  Example:
> +
> +	/* MPC8548E */
> +	crypto@30000 {
> +		device_type = "crypto";
> +		model = "SEC2";
> +		compatible = "talitos";
> +		reg = <30000 10000>;
> +		interrupts = <1d 3>;
> +		interrupt-parent = <40000>;
> +		num-channels = <4>;
> +		channel-fifo-len = <24>;
> +		exec-units-mask = <000000fe>;
> +		descriptor-types-mask = <073f1127>;
> +	};
> +
> +
>     More devices will be defined as this spec matures.
>
>
>
>
>
> -- 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Kumar Gala]

On Mar 20, 2006, at 8:14 PM, Hollis Blanchard wrote:

> On Monday 20 March 2006 19:59, Kim Phillips wrote:
>> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
>> index d02c649..72f3241 100644
>> --- a/Documentation/powerpc/booting-without-of.txt
>> +++ b/Documentation/powerpc/booting-without-of.txt
>> @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
>>       };
>>
>>
>> +   g) Freescale SOC SEC Security Engines
>> +
>> +   Required properties:
>> +
>> +    - device_type : Should be "crypto"
>> +    - model : Model of the device.  Should be "SEC1" or "SEC2"
>> +    - compatible : Should be "talitos"
> [snip]
>
> Have you consulted with any other vendors regarding these  
> properties? I know
> there is no IEEE1275 binding for these sorts of devices, but we can  
> at least
> attempt to standardize it (even in the absence of the Open Firmware  
> Working
> Group)...

Beyond the device_type, I'm not sure if there is much more one could  
standardize one.  The other fields that Kim spec'd are either generic  
OF fields (reg, interrupts, etc.) or specific to the Freescale devices.

- kumar

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Hollis Blanchard]

On Tue, 2006-03-21 at 12:25 -0600, Kumar Gala wrote:
> On Mar 20, 2006, at 8:14 PM, Hollis Blanchard wrote:
> 
> > On Monday 20 March 2006 19:59, Kim Phillips wrote:
> >> diff --git a/Documentation/powerpc/booting-without-of.txt
> > b/Documentation/powerpc/booting-without-of.txt
> >> index d02c649..72f3241 100644
> >> --- a/Documentation/powerpc/booting-without-of.txt
> >> +++ b/Documentation/powerpc/booting-without-of.txt
> >> @@ -1365,6 +1365,79 @@ platforms are moved over to use the flat
> >>       };
> >>
> >>
> >> +   g) Freescale SOC SEC Security Engines
> >> +
> >> +   Required properties:
> >> +
> >> +    - device_type : Should be "crypto"
> >> +    - model : Model of the device.  Should be "SEC1" or "SEC2"
> >> +    - compatible : Should be "talitos"
> > [snip]
> >
> > Have you consulted with any other vendors regarding these  
> > properties? I know
> > there is no IEEE1275 binding for these sorts of devices, but we can  
> > at least
> > attempt to standardize it (even in the absence of the Open Firmware  
> > Working
> > Group)...
> 
> Beyond the device_type, I'm not sure if there is much more one could  
> standardize one.  The other fields that Kim spec'd are either generic  
> OF fields (reg, interrupts, etc.) or specific to the Freescale devices.

The device_type and compatible properties are exactly what I'm talking
about.

-Hollis

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Paul Nasrat]

On Tue, 2006-03-21 at 13:28 -0600, Hollis Blanchard wrote:
> On Tue, 2006-03-21 at 12:25 -0600, Kumar Gala wrote:
> > On Mar 20, 2006, at 8:14 PM, Hollis Blanchard wrote:

> > > Have you consulted with any other vendors regarding these  
> > > properties? I know
> > > there is no IEEE1275 binding for these sorts of devices, but we can  
> > > at least
> > > attempt to standardize it (even in the absence of the Open Firmware  
> > > Working
> > > Group)...
> > 
> > Beyond the device_type, I'm not sure if there is much more one could  
> > standardize one.  The other fields that Kim spec'd are either generic  
> > OF fields (reg, interrupts, etc.) or specific to the Freescale devices.
> 
> The device_type and compatible properties are exactly what I'm talking
> about.

The Working Group lists still exist but are pretty dead.  I agree we
really want to ensure that both OF based and dtc based new hardware is
consistent.  I'm not sure how we want to do this, but we can document in
Documentation and then use eg SLOF to mock out the OF interfaces and
create proposals and kick some life into the OF working group.  



Paul

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Kim Phillips]

On Tue, 21 Mar 2006 12:21:47 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> Drop the part about Most modern... in five years when someone reads  
> this it will not be modern anymore.
> 
[snip]
> 
> ditto about modern.
> 
[snip]
> 
> Would this be a bit more clear, if you explicitly stated that the  
> DESC_TYPE value directly corresponds to the bit encoding, like you  
> did for EU_SEL0.
> 
[snip]

ok, here's the replacement replacement patch with the above fixes:


Documentation: Added FSL SOC SEC node definition

Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

---
commit e1e1b8f7d958d7f25a0085ec529a3ebbd6dc1fa5
tree 2e2b12fe07b6d367da4c5609971178838c9321a2
parent 6b0efd3e3b07afc9fc7222066b0b37ecd1d31e44
author Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600
committer Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600

 Documentation/powerpc/booting-without-of.txt |   72 ++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d02c649..d6626b6 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,78 @@ platforms are moved over to use the flat
        };


+   g) Freescale SOC SEC Security Engines
+
+   Required properties:
+
+    - device_type : Should be "crypto"
+    - model : Model of the device.  Should be "SEC1" or "SEC2"
+    - compatible : Should be "talitos"
+    - reg : Offset and length of the register set for the device
+    - interrupts : <a b> where a is the interrupt number and b is a
+      field that represents an encoding of the sense and level
+      information for the interrupt.  This should be encoded based on
+      the information in section 2) depending on the type of interrupt
+      controller you have.
+    - interrupt-parent : the phandle for the interrupt controller that
+      services interrupts for this device.
+    - num-channels : An integer representing the number of channels
+      available.
+    - channel-fifo-len : An integer representing the number of
+      descriptor pointers each channel fetch fifo can hold.
+    - exec-units-mask : The bitmask representing what execution units
+      (EUs) are available. It's a single 32 bit cell. EU information
+      should be encoded following the SEC's Descriptor Header Dword
+      EU_SEL0 field documentation, i.e. as follows:
+
+        bit 0 = reserved - should be 0
+        bit 1 = set if SEC has the ARC4 EU (AFEU)
+        bit 2 = set if SEC has the DES/3DES EU (DEU)
+        bit 3 = set if SEC has the message digest EU (MDEU)
+        bit 4 = set if SEC has the random number generator EU (RNG)
+        bit 5 = set if SEC has the public key EU (PKEU)
+        bit 6 = set if SEC has the AES EU (AESU)
+        bit 7 = set if SEC has the Kasumi EU (KEU)
+
+      bits 8 through 31 are reserved for future SEC EUs.
+
+    - descriptor-types-mask : The bitmask representing what descriptors
+      are available. It's a single 32 bit cell. Descriptor type
+      information should be encoded following the SEC's Descriptor
+      Header Dword DESC_TYPE field documentation, i.e. as follows:
+
+        bit 0  = set if SEC supports the aesu_ctr_nonsnoop desc. type
+        bit 1  = set if SEC supports the ipsec_esp descriptor type
+        bit 2  = set if SEC supports the common_nonsnoop desc. type
+        bit 3  = set if SEC supports the 802.11i AES ccmp desc. type
+        bit 4  = set if SEC supports the hmac_snoop_no_afeu desc. type
+        bit 5  = set if SEC supports the srtp descriptor type
+        bit 6  = set if SEC supports the non_hmac_snoop_no_afeu desc.type
+        bit 7  = set if SEC supports the pkeu_assemble descriptor type
+        bit 8  = set if SEC supports the aesu_key_expand_output desc.type
+        bit 9  = set if SEC supports the pkeu_ptmul descriptor type
+        bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
+        bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+      ..and so on and so forth.
+
+  Example:
+
+       /* MPC8548E */
+       crypto@30000 {
+               device_type = "crypto";
+               model = "SEC2";
+               compatible = "talitos";
+               reg = <30000 10000>;
+               interrupts = <1d 3>;
+               interrupt-parent = <40000>;
+               num-channels = <4>;
+               channel-fifo-len = <24>;
+               exec-units-mask = <000000fe>;
+               descriptor-types-mask = <073f1127>;
+       };
+
+
    More devices will be defined as this spec matures.

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Paul Mackerras]

Kim Phillips writes:

> ok, here's the replacement replacement patch with the above fixes:

Unfortunately your mailer wrecked the whitespace and it doesn't
apply.  Please resend with a better mailer.

Thanks,
Paul.

[PATCH] powerpc: Add FSL SEC node to documentation

[Kim Phillips]

Documentation: Added FSL SOC SEC node definition

Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

---
commit e51555b4bad3188afa02821eb4433929e4293002
tree 41d27e57f82c0f4cd93d323cca027fb995b2e508
parent dd126d5545e6e1bd584b90c0f9da35b7183e08cf
author Kim Phillips <kim.phillips@freescale.com> Wed, 22 Mar 2006 13:56:17 -0600
committer Kim Phillips <kim.phillips@freescale.com> Wed, 22 Mar 2006 13:56:17 -0600

 Documentation/powerpc/booting-without-of.txt |   72 ++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d02c649..a90dc85 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,78 @@ platforms are moved over to use the flat
 	};
 
 
+   g) Freescale SOC SEC Security Engines
+
+   Required properties:
+
+    - device_type : Should be "crypto"
+    - model : Model of the device.  Should be "SEC1" or "SEC2"
+    - compatible : Should be "talitos"
+    - reg : Offset and length of the register set for the device
+    - interrupts : <a b> where a is the interrupt number and b is a
+      field that represents an encoding of the sense and level
+      information for the interrupt.  This should be encoded based on
+      the information in section 2) depending on the type of interrupt
+      controller you have.
+    - interrupt-parent : the phandle for the interrupt controller that
+      services interrupts for this device.
+    - num-channels : An integer representing the number of channels
+      available.
+    - channel-fifo-len : An integer representing the number of
+      descriptor pointers each channel fetch fifo can hold.
+    - exec-units-mask : The bitmask representing what execution units
+      (EUs) are available. It's a single 32 bit cell. EU information
+      should be encoded following the SEC's Descriptor Header Dword
+      EU_SEL0 field documentation, i.e. as follows:
+
+        bit 0 = reserved - should be 0
+        bit 1 = set if SEC has the ARC4 EU (AFEU)
+        bit 2 = set if SEC has the DES/3DES EU (DEU)
+        bit 3 = set if SEC has the message digest EU (MDEU)
+        bit 4 = set if SEC has the random number generator EU (RNG)
+        bit 5 = set if SEC has the public key EU (PKEU)
+        bit 6 = set if SEC has the AES EU (AESU)
+        bit 7 = set if SEC has the Kasumi EU (KEU)
+
+      bits 8 through 31 are reserved for future SEC EUs.
+
+    - descriptor-types-mask : The bitmask representing what descriptors
+      are available. It's a single 32 bit cell. Descriptor type
+      information should be encoded following the SEC's Descriptor
+      Header Dword DESC_TYPE field documentation, i.e. as follows:
+
+        bit 0  = set if SEC supports the aesu_ctr_nonsnoop desc. type
+        bit 1  = set if SEC supports the ipsec_esp descriptor type
+        bit 2  = set if SEC supports the common_nonsnoop desc. type
+        bit 3  = set if SEC supports the 802.11i AES ccmp desc. type
+        bit 4  = set if SEC supports the hmac_snoop_no_afeu desc. type
+        bit 5  = set if SEC supports the srtp descriptor type
+        bit 6  = set if SEC supports the non_hmac_snoop_no_afeu desc.type
+        bit 7  = set if SEC supports the pkeu_assemble descriptor type
+        bit 8  = set if SEC supports the aesu_key_expand_output desc.type
+        bit 9  = set if SEC supports the pkeu_ptmul descriptor type
+        bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
+        bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+      ..and so on and so forth.
+
+   Example:
+
+       /* MPC8548E */
+       crypto@30000 {
+               device_type = "crypto";
+               model = "SEC2";
+               compatible = "talitos";
+               reg = <30000 10000>;
+               interrupts = <1d 3>;
+               interrupt-parent = <40000>;
+               num-channels = <4>;
+               channel-fifo-len = <24>;
+               exec-units-mask = <000000fe>;
+               descriptor-types-mask = <073f1127>;
+       };
+
+
    More devices will be defined as this spec matures.
 
 

Re: [PATCH] powerpc: Add FSL SEC node to documentation

[Doug Maxey]

On Tue, 21 Mar 2006 16:23:41 EST, Paul Nasrat wrote:
>On Tue, 2006-03-21 at 13:28 -0600, Hollis Blanchard wrote:
>> On Tue, 2006-03-21 at 12:25 -0600, Kumar Gala wrote:
>> > On Mar 20, 2006, at 8:14 PM, Hollis Blanchard wrote:
>
>> > > Have you consulted with any other vendors regarding these  
>> > > properties? I know
>> > > there is no IEEE1275 binding for these sorts of devices, but we can  
>> > > at least
>> > > attempt to standardize it (even in the absence of the Open Firmware  
>> > > Working
>> > > Group)...
>> > 
>> > Beyond the device_type, I'm not sure if there is much more one could  
>> > standardize one.  The other fields that Kim spec'd are either generic  
>> > OF fields (reg, interrupts, etc.) or specific to the Freescale devices.
>> 
>> The device_type and compatible properties are exactly what I'm talking
>> about.
>
>The Working Group lists still exist but are pretty dead.  I agree we
>really want to ensure that both OF based and dtc based new hardware is
>consistent.  I'm not sure how we want to do this, but we can document in
>Documentation and then use eg SLOF to mock out the OF interfaces and
>create proposals and kick some life into the OF working group.  

Sorry for the delayed reply, my procmail filter was pumping mails to
the old list name without telling me. :)

Other than IBM, Motorola, and possibly Sun, what groups are using 
OFW on new platforms anymore?  

Power.org may be a vehicle to publish.  

The Power TSC leader indicated a willingness to look into a process to 
get out some purely internal bindings (at the moment) that _really_ 
need some fresh air to flourish.

++doug