[PATCH dunfell] cryptodev: Move to 1.12 revision

[PATCH dunfell] cryptodev: Move to 1.12 revision

[Nishanth Menon]

Cryptodev out of kernel module and suite has yet another set of
challenge with broken API compatibility. However, the complete list of
patches beteween dunfell's default 1.10 and current latest 1.12 revisions:
 e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12
 55c6315058fc Fix build for Linux 5.11-rc1
 2f5e08aebf92 Fix build for Linux 5.9-rc1
 e8263d2d682b remove VLA usage from authenc.c
 dafa42cadc86 Fix for change in Kernel 4.4.168
 f4d3653c8dcb Release version 1.11
 9e765068582a Fix build for Linux 5.8-rc1
 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1
 98b163a23f6b cryptlib.c: fix build on kernel v5.5+
 a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment
 f971e0cd4a0e Fix module loading with Linux v5.0-rc5

We have the following choices
1) just cherry-pick minimum set of kernel patches relevant for kernel
compatibility
OR
2) switch to a newer version with richer set of fixups

Attempting to switch to 1.12 version with minimal changes as a better
option to get a wider swath of kernel compatibility.

Signed-off-by: Nishanth Menon <nm@ti.com>
---

DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to
suggestions.

NOTE:
a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the
moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master

b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer
kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth

c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell

 .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend     | 5 +++++
 .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend    | 5 +++++
 .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend     | 6 ++++++
 3 files changed, 16 insertions(+)
 create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
 create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend

diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
new file mode 100644
index 000000000000..a3fb634463fd
--- /dev/null
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
@@ -0,0 +1,5 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+PR = "1.12"
+PR_append = ".arago0"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
index f8a35cd73765..602ada0daf3a 100644
--- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
@@ -1,3 +1,8 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+
+PR = "1.12"
 PR_append = ".arago0"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
 
 KERNEL_MODULE_AUTOLOAD += "cryptodev"
diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
new file mode 100644
index 000000000000..dee8f40862cb
--- /dev/null
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
@@ -0,0 +1,6 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+
+PR = "1.12"
+PR_append = ".arago0"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
-- 
2.25.1.377.g2d2118b814c1

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko]

On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote:
> Cryptodev out of kernel module and suite has yet another set of
> challenge with broken API compatibility. However, the complete list of
> patches beteween dunfell's default 1.10 and current latest 1.12 revisions:
>  e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12
>  55c6315058fc Fix build for Linux 5.11-rc1
>  2f5e08aebf92 Fix build for Linux 5.9-rc1
>  e8263d2d682b remove VLA usage from authenc.c
>  dafa42cadc86 Fix for change in Kernel 4.4.168
>  f4d3653c8dcb Release version 1.11
>  9e765068582a Fix build for Linux 5.8-rc1
>  7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1
>  98b163a23f6b cryptlib.c: fix build on kernel v5.5+
>  a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment
>  f971e0cd4a0e Fix module loading with Linux v5.0-rc5
> 
> We have the following choices
> 1) just cherry-pick minimum set of kernel patches relevant for kernel
> compatibility
> OR
> 2) switch to a newer version with richer set of fixups
> 
> Attempting to switch to 1.12 version with minimal changes as a better
> option to get a wider swath of kernel compatibility.
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> 
> DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to
> suggestions.

It is still probably the cleanest - just 2 vars in 3 bbappends. You might want 
to mention that you need this for 5.10 (or 5.9+) kernel upgrade.

The issue is due to upgrading the kernel from one LTS to the next, while 
staying on the older Yocto LTS, which was 5.4-specific... BTW, I haven't yet 
reviewed your meta-ti patches, will do that next.


> NOTE:
> a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the
> moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master
> 
> b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer
> kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth
> 
> c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell
> 
>  .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend     | 5 +++++
>  .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend    | 5 +++++
>  .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend     | 6 ++++++
>  3 files changed, 16 insertions(+)
>  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
>  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> 
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> new file mode 100644
> index 000000000000..a3fb634463fd
> --- /dev/null
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> @@ -0,0 +1,5 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +PR = "1.12"

PV here. Stands for Package Version. And PR is for Package Revision (i.e. 
repackaging of the same version)


> +PR_append = ".arago0"

Not necessarily needed, if PV is set correctly _and_ SRCREV matches the one 
from OE-Core master for 1.12.


> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> index f8a35cd73765..602ada0daf3a 100644
> --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> @@ -1,3 +1,8 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +
> +PR = "1.12"

Same.


>  PR_append = ".arago0"

This one was already there due to KERNEL_MODULE_AUTOLOAD below.


> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
>  
>  KERNEL_MODULE_AUTOLOAD += "cryptodev"
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> new file mode 100644
> index 000000000000..dee8f40862cb
> --- /dev/null
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> @@ -0,0 +1,6 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +
> +PR = "1.12"

Same.


> +PR_append = ".arago0"

Same.


> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> -- 
> 2.25.1.377.g2d2118b814c1
> 
> _______________________________________________
> meta-arago mailing list
> meta-arago@arago-project.org
> http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
> 

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko]

BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect 
current 5.4-based builds and/or releases. I'm sure it will build fine against 
this older kernel (most of Makefile changes), but concerned about any run-time 
regressions (the actual code changes).


On Thu, Mar 04, 2021 at 01:48:11PM -0500, Denys Dmytriyenko wrote:
> On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote:
> > Cryptodev out of kernel module and suite has yet another set of
> > challenge with broken API compatibility. However, the complete list of
> > patches beteween dunfell's default 1.10 and current latest 1.12 revisions:
> >  e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12
> >  55c6315058fc Fix build for Linux 5.11-rc1
> >  2f5e08aebf92 Fix build for Linux 5.9-rc1
> >  e8263d2d682b remove VLA usage from authenc.c
> >  dafa42cadc86 Fix for change in Kernel 4.4.168
> >  f4d3653c8dcb Release version 1.11
> >  9e765068582a Fix build for Linux 5.8-rc1
> >  7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1
> >  98b163a23f6b cryptlib.c: fix build on kernel v5.5+
> >  a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment
> >  f971e0cd4a0e Fix module loading with Linux v5.0-rc5
> > 
> > We have the following choices
> > 1) just cherry-pick minimum set of kernel patches relevant for kernel
> > compatibility
> > OR
> > 2) switch to a newer version with richer set of fixups
> > 
> > Attempting to switch to 1.12 version with minimal changes as a better
> > option to get a wider swath of kernel compatibility.
> > 
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > 
> > DISCLAIMER: This is probably a dumb way of switching to 1.12.. open to
> > suggestions.
> 
> It is still probably the cleanest - just 2 vars in 3 bbappends. You might want 
> to mention that you need this for 5.10 (or 5.9+) kernel upgrade.
> 
> The issue is due to upgrading the kernel from one LTS to the next, while 
> staying on the older Yocto LTS, which was 5.4-specific... BTW, I haven't yet 
> reviewed your meta-ti patches, will do that next.
> 
> 
> > NOTE:
> > a) master is already on 1.12 -> So, I am suggesting this only for dunfell at the
> > moment: http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=master
> > 
> > b) gatesgarth is on 1.11 -> we wont get the fixes needed for newer
> > kernel, so a variant of this will be needed.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=gatesgarth
> > 
> > c) dunfell is still on 1.10 -> Same story as gatesgarth.. http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/cryptodev?h=dunfell
> > 
> >  .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend     | 5 +++++
> >  .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend    | 5 +++++
> >  .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend     | 6 ++++++
> >  3 files changed, 16 insertions(+)
> >  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> >  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> > 
> > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> > new file mode 100644
> > index 000000000000..a3fb634463fd
> > --- /dev/null
> > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> > @@ -0,0 +1,5 @@
> > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> > +# just pull 1.12 revision, everything else remains the same.
> > +PR = "1.12"
> 
> PV here. Stands for Package Version. And PR is for Package Revision (i.e. 
> repackaging of the same version)
> 
> 
> > +PR_append = ".arago0"
> 
> Not necessarily needed, if PV is set correctly _and_ SRCREV matches the one 
> from OE-Core master for 1.12.
> 
> 
> > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> > index f8a35cd73765..602ada0daf3a 100644
> > --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> > @@ -1,3 +1,8 @@
> > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> > +# just pull 1.12 revision, everything else remains the same.
> > +
> > +PR = "1.12"
> 
> Same.
> 
> 
> >  PR_append = ".arago0"
> 
> This one was already there due to KERNEL_MODULE_AUTOLOAD below.
> 
> 
> > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> >  
> >  KERNEL_MODULE_AUTOLOAD += "cryptodev"
> > diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> > new file mode 100644
> > index 000000000000..dee8f40862cb
> > --- /dev/null
> > +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> > @@ -0,0 +1,6 @@
> > +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> > +# just pull 1.12 revision, everything else remains the same.
> > +
> > +PR = "1.12"
> 
> Same.
> 
> 
> > +PR_append = ".arago0"
> 
> Same.
> 
> 
> > +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> > -- 
> > 2.25.1.377.g2d2118b814c1
> > 
> > _______________________________________________
> > meta-arago mailing list
> > meta-arago@arago-project.org
> > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
> > 
> 
> -- 
> Regards,
> Denys Dmytriyenko <denis@denix.org>
> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
> Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964
> _______________________________________________
> meta-arago mailing list
> meta-arago@arago-project.org
> http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
> 

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Nishanth Menon]

On 14:48-20210304, Denys Dmytriyenko wrote:
> BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect 
> current 5.4-based builds and/or releases. I'm sure it will build fine against 
> this older kernel (most of Makefile changes), but concerned about any run-time 
> regressions (the actual code changes).

Thank you, actually you bring out a very good point here. While I know
we can create our own internal private fork of arago for upstream
component testing, I am starting to wonder if creating either of:

a) meta-ti-mainline that builds on top of meta-ti
OR
b) meta-arago-mainline on top of meta-arago

is a smarter approach - personally, I prefer (a)? While, I don't want
to end up creating too many layers, but your point is valid that I
should also be careful to not mess with folks using the meta-arago in
production environments having to deal with challenges we are trying
to flush out by testing the bleeding edge of kernel - and I'd like to
make sure TI ecosystem is able to leverage/contribute as well (an
internal fork will not be that useful)..

Any thoughts?

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Nishanth Menon]

On 13:48-20210304, Denys Dmytriyenko wrote:
> On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote:
> > Cryptodev out of kernel module and suite has yet another set of

[...]

> > +PR_append = ".arago0"
> 
> Same.

Thanks.. Subject to our thread continuing in parallel if a new layer is
needed... just posting for reference a v2 - inline:

-- >8 --
From 7a345806bda670973300e64e32affcf0ceab2d01 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm@ti.com>
Date: Thu, 4 Mar 2021 00:26:29 -0600
Subject: [PATCH V2 master/dunfell] cryptodev: Move to 1.12 revision

Cryptodev out of kernel module and suite has yet another set of
challenge with broken API compatibility. However, the complete list of
patches beteween dunfell's default 1.10 and current latest 1.12 revisions:
 e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12
 55c6315058fc Fix build for Linux 5.11-rc1
 2f5e08aebf92 Fix build for Linux 5.9-rc1
 e8263d2d682b remove VLA usage from authenc.c
 dafa42cadc86 Fix for change in Kernel 4.4.168
 f4d3653c8dcb Release version 1.11
 9e765068582a Fix build for Linux 5.8-rc1
 7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1
 98b163a23f6b cryptlib.c: fix build on kernel v5.5+
 a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment
 f971e0cd4a0e Fix module loading with Linux v5.0-rc5

We have the following choices
1) just cherry-pick minimum set of kernel patches relevant for kernel
compatibility
OR
2) switch to a newer version with richer set of fixups

Attempting to switch to 1.12 version with minimal changes as a better
option to get a wider swath of kernel compatibility (v5.5 to v5.11), vs
the default of v5.4 kernel in dunfell vanilla.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend      | 5 +++++
 .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend     | 5 +++++
 .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend      | 5 +++++
 3 files changed, 15 insertions(+)
 create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
 create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend

diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
new file mode 100644
index 000000000000..a4ae187d4082
--- /dev/null
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
@@ -0,0 +1,5 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+
+PV = "1.12"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
index f8a35cd73765..a1e1c91978c4 100644
--- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
@@ -1,3 +1,8 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+
+PV = "1.12"
 PR_append = ".arago0"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
 
 KERNEL_MODULE_AUTOLOAD += "cryptodev"
diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
new file mode 100644
index 000000000000..a4ae187d4082
--- /dev/null
+++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
@@ -0,0 +1,5 @@
+# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
+# just pull 1.12 revision, everything else remains the same.
+
+PV = "1.12"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
-- 
2.25.1.377.g2d2118b814c1

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko]

On Thu, Mar 04, 2021 at 05:18:45PM -0600, Nishanth Menon wrote:
> On 13:48-20210304, Denys Dmytriyenko wrote:
> > On Thu, Mar 04, 2021 at 12:52:00AM -0600, Nishanth Menon wrote:
> > > Cryptodev out of kernel module and suite has yet another set of
> 
> [...]
> 
> > > +PR_append = ".arago0"
> > 
> > Same.
> 
> Thanks.. Subject to our thread continuing in parallel if a new layer is
> needed... just posting for reference a v2 - inline:

Overall looks fine - thanks for addressing all my comments.
We'll see in the other thread if this is needed.


> -- >8 --
> From 7a345806bda670973300e64e32affcf0ceab2d01 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon <nm@ti.com>
> Date: Thu, 4 Mar 2021 00:26:29 -0600
> Subject: [PATCH V2 master/dunfell] cryptodev: Move to 1.12 revision
> 
> Cryptodev out of kernel module and suite has yet another set of
> challenge with broken API compatibility. However, the complete list of
> patches beteween dunfell's default 1.10 and current latest 1.12 revisions:
>  e0c25e289d6b (tag: cryptodev-linux-1.12) Release version 1.12
>  55c6315058fc Fix build for Linux 5.11-rc1
>  2f5e08aebf92 Fix build for Linux 5.9-rc1
>  e8263d2d682b remove VLA usage from authenc.c
>  dafa42cadc86 Fix for change in Kernel 4.4.168
>  f4d3653c8dcb Release version 1.11
>  9e765068582a Fix build for Linux 5.8-rc1
>  7e72f6758f2d enabled the support for TLS1.1 - AES128-SHA1 - AES256-SHA1
>  98b163a23f6b cryptlib.c: fix build on kernel v5.5+
>  a1e738aef624 tests: cipher-aead-srtp: Fix cao->dst alignment
>  f971e0cd4a0e Fix module loading with Linux v5.0-rc5
> 
> We have the following choices
> 1) just cherry-pick minimum set of kernel patches relevant for kernel
> compatibility
> OR
> 2) switch to a newer version with richer set of fixups
> 
> Attempting to switch to 1.12 version with minimal changes as a better
> option to get a wider swath of kernel compatibility (v5.5 to v5.11), vs
> the default of v5.4 kernel in dunfell vanilla.
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  .../recipes-kernel/cryptodev/cryptodev-linux_%.bbappend      | 5 +++++
>  .../recipes-kernel/cryptodev/cryptodev-module_%.bbappend     | 5 +++++
>  .../recipes-kernel/cryptodev/cryptodev-tests_%.bbappend      | 5 +++++
>  3 files changed, 15 insertions(+)
>  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
>  create mode 100644 meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> 
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> new file mode 100644
> index 000000000000..a4ae187d4082
> --- /dev/null
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-linux_%.bbappend
> @@ -0,0 +1,5 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +
> +PV = "1.12"
> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> index f8a35cd73765..a1e1c91978c4 100644
> --- a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-module_%.bbappend
> @@ -1,3 +1,8 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +
> +PV = "1.12"
>  PR_append = ".arago0"
> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
>  
>  KERNEL_MODULE_AUTOLOAD += "cryptodev"
> diff --git a/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> new file mode 100644
> index 000000000000..a4ae187d4082
> --- /dev/null
> +++ b/meta-arago-distro/recipes-kernel/cryptodev/cryptodev-tests_%.bbappend
> @@ -0,0 +1,5 @@
> +# Bring in fixes including https://github.com/cryptodev-linux/cryptodev-linux/pull/55
> +# just pull 1.12 revision, everything else remains the same.
> +
> +PV = "1.12"
> +SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
> -- 
> 2.25.1.377.g2d2118b814c1
> 
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
> 

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko]

On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote:
> On 14:48-20210304, Denys Dmytriyenko wrote:
> > BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect 
> > current 5.4-based builds and/or releases. I'm sure it will build fine against 
> > this older kernel (most of Makefile changes), but concerned about any run-time 
> > regressions (the actual code changes).
> 
> Thank you, actually you bring out a very good point here. While I know
> we can create our own internal private fork of arago for upstream
> component testing, I am starting to wonder if creating either of:
> 
> a) meta-ti-mainline that builds on top of meta-ti
> OR
> b) meta-arago-mainline on top of meta-arago
> 
> is a smarter approach - personally, I prefer (a)? While, I don't want
> to end up creating too many layers, but your point is valid that I
> should also be careful to not mess with folks using the meta-arago in
> production environments having to deal with challenges we are trying
> to flush out by testing the bleeding edge of kernel - and I'd like to
> make sure TI ecosystem is able to leverage/contribute as well (an
> internal fork will not be that useful)..

First of all, an internal fork was an unintended consequence. But since we are 
discussing this in a public forum, I won't go into more details. :)

Creating yet another layer is certainly an option. For mainline purposes (a) 
is definitely a better choice. And I assume that would be public...

On the other hand, if you only need this for couple of recipes, you can do 
this with alternative providers. E.g. instead of altering existing recipes 
with bbappends (e.g. cryptodev), you can have many providers for the same 
package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from 
OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot 
from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot 
bootloader, like virtual/bootloaader). Those can be switched with a global 
PREFERRED_PROVIDER_<pkg> variable:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13

In other words, if cryptodev is the only such case right now, it's less 
involved to create cryptodev-ti-mainline recipes, set those to corresponding 
PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me 
know if you need help with that.


> Any thoughts?
> 
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
> 

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Nishanth Menon]

On 19:58-20210304, Denys Dmytriyenko wrote:
> On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote:
> > On 14:48-20210304, Denys Dmytriyenko wrote:
> > > BTW, you'd need to ensure updating cryptodev from 1.10 to 1.12 does not affect 
> > > current 5.4-based builds and/or releases. I'm sure it will build fine against 
> > > this older kernel (most of Makefile changes), but concerned about any run-time 
> > > regressions (the actual code changes).
> > 
> > Thank you, actually you bring out a very good point here. While I know
> > we can create our own internal private fork of arago for upstream
> > component testing, I am starting to wonder if creating either of:
> > 
> > a) meta-ti-mainline that builds on top of meta-ti
> > OR
> > b) meta-arago-mainline on top of meta-arago
> > 
> > is a smarter approach - personally, I prefer (a)? While, I don't want
> > to end up creating too many layers, but your point is valid that I
> > should also be careful to not mess with folks using the meta-arago in
> > production environments having to deal with challenges we are trying
> > to flush out by testing the bleeding edge of kernel - and I'd like to
> > make sure TI ecosystem is able to leverage/contribute as well (an
> > internal fork will not be that useful)..
> 
> First of all, an internal fork was an unintended consequence. But since we are 
> discussing this in a public forum, I won't go into more details. :)

:) understood :)

> 
> Creating yet another layer is certainly an option. For mainline purposes (a) 
> is definitely a better choice. And I assume that would be public...

yes, that is my thought.

> 
> On the other hand, if you only need this for couple of recipes, you can do 
> this with alternative providers. E.g. instead of altering existing recipes 
> with bbappends (e.g. cryptodev), you can have many providers for the same 
> package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from 
> OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot 
> from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot 
> bootloader, like virtual/bootloaader). Those can be switched with a global 
> PREFERRED_PROVIDER_<pkg> variable:
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13
> 
> In other words, if cryptodev is the only such case right now, it's less 
> involved to create cryptodev-ti-mainline recipes, set those to corresponding 
> PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me 
> know if you need help with that.


Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow,
in addition, I need to expand from purely kernel and u-boot upstream
components alone to TF-A, linux-firmware upstream and eventually few
additional packages etc. Mostly as a forward looking layer to uncover
issues ahead of time. My thoughts on this is as follows: While the
provider view can easily fit as well, it is a little less distracting
or in some cases, un-intended usage to keep a "experimental" and
"forward looking" layer away from users of production layer - then the
distinction is very clearcut and risks(essentially "you are on your
own") associated with the same would be clear as well. Who knows, some
day, we might be even be able to delete such a layer since upstream will
be rocksolid (touch wood)..


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Denys Dmytriyenko]

On Thu, Mar 04, 2021 at 07:24:11PM -0600, Nishanth Menon wrote:
> On 19:58-20210304, Denys Dmytriyenko wrote:
> > On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote:
> > > Thank you, actually you bring out a very good point here. While I know
> > > we can create our own internal private fork of arago for upstream
> > > component testing, I am starting to wonder if creating either of:
> > > 
> > > a) meta-ti-mainline that builds on top of meta-ti
> > > OR
> > > b) meta-arago-mainline on top of meta-arago
> > > 
> > > is a smarter approach - personally, I prefer (a)? While, I don't want
> > > to end up creating too many layers, but your point is valid that I
> > > should also be careful to not mess with folks using the meta-arago in
> > > production environments having to deal with challenges we are trying
> > > to flush out by testing the bleeding edge of kernel - and I'd like to
> > > make sure TI ecosystem is able to leverage/contribute as well (an
> > > internal fork will not be that useful)..
> > 
> > First of all, an internal fork was an unintended consequence. But since we are 
> > discussing this in a public forum, I won't go into more details. :)
> 
> :) understood :)
> 
> > 
> > Creating yet another layer is certainly an option. For mainline purposes (a) 
> > is definitely a better choice. And I assume that would be public...
> 
> yes, that is my thought.

Good, anything BSP-specific is meta-ti, hence meta-ti-mainline.

While meta-arago is for anything Apps or Distro-specific. It was also used 
as a dumping ground for anything un-upstreamable or with non-standard 
dependencies.

As meta-ti used to depend on OE-Core only at first, now it's OE-Core plus 
meta-arm. So, if you have a component that depends on anything else, you can't 
have it in meta-ti or meta-ti-mainline layers. We can talk about Yocto Project 
compatibility requirements separately...


> > On the other hand, if you only need this for couple of recipes, you can do 
> > this with alternative providers. E.g. instead of altering existing recipes 
> > with bbappends (e.g. cryptodev), you can have many providers for the same 
> > package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from 
> > OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot 
> > from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot 
> > bootloader, like virtual/bootloaader). Those can be switched with a global 
> > PREFERRED_PROVIDER_<pkg> variable:
> > 
> > https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13
> > 
> > In other words, if cryptodev is the only such case right now, it's less 
> > involved to create cryptodev-ti-mainline recipes, set those to corresponding 
> > PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me 
> > know if you need help with that.
> 
> 
> Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow,
> in addition, I need to expand from purely kernel and u-boot upstream
> components alone to TF-A, linux-firmware upstream and eventually few
> additional packages etc. Mostly as a forward looking layer to uncover
> issues ahead of time. My thoughts on this is as follows: While the
> provider view can easily fit as well, it is a little less distracting
> or in some cases, un-intended usage to keep a "experimental" and
> "forward looking" layer away from users of production layer - then the
> distinction is very clearcut and risks(essentially "you are on your
> own") associated with the same would be clear as well. Who knows, some
> day, we might be even be able to delete such a layer since upstream will
> be rocksolid (touch wood)..

Ah, that would the most glorious day for sure! :)

Anyway, if you intend to have cryptodev, atf/tf-a, optee, linux-firmware and 
such, then sure, a separate mainline-only layer would be the best. BTW, things 
like SGX and RGX will also fit there nicely.

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [PATCH dunfell] cryptodev: Move to 1.12 revision

[Nishanth Menon]

On 21:26-20210304, Denys Dmytriyenko wrote:
> On Thu, Mar 04, 2021 at 07:24:11PM -0600, Nishanth Menon wrote:
> > On 19:58-20210304, Denys Dmytriyenko wrote:
> > > On Thu, Mar 04, 2021 at 05:14:34PM -0600, Nishanth Menon wrote:
> > > > Thank you, actually you bring out a very good point here. While I know
> > > > we can create our own internal private fork of arago for upstream
> > > > component testing, I am starting to wonder if creating either of:
> > > > 
> > > > a) meta-ti-mainline that builds on top of meta-ti
> > > > OR
> > > > b) meta-arago-mainline on top of meta-arago
> > > > 
> > > > is a smarter approach - personally, I prefer (a)? While, I don't want
> > > > to end up creating too many layers, but your point is valid that I
> > > > should also be careful to not mess with folks using the meta-arago in
> > > > production environments having to deal with challenges we are trying
> > > > to flush out by testing the bleeding edge of kernel - and I'd like to
> > > > make sure TI ecosystem is able to leverage/contribute as well (an
> > > > internal fork will not be that useful)..
> > > 
> > > First of all, an internal fork was an unintended consequence. But since we are 
> > > discussing this in a public forum, I won't go into more details. :)
> > 
> > :) understood :)
> > 
> > > 
> > > Creating yet another layer is certainly an option. For mainline purposes (a) 
> > > is definitely a better choice. And I assume that would be public...
> > 
> > yes, that is my thought.
> 
> Good, anything BSP-specific is meta-ti, hence meta-ti-mainline.
> 
> While meta-arago is for anything Apps or Distro-specific. It was also used 
> as a dumping ground for anything un-upstreamable or with non-standard 
> dependencies.
> 
> As meta-ti used to depend on OE-Core only at first, now it's OE-Core plus 
> meta-arm. So, if you have a component that depends on anything else, you can't 
> have it in meta-ti or meta-ti-mainline layers. We can talk about Yocto Project 
> compatibility requirements separately...

Thank you for your guidance here.
> 
> 
> > > On the other hand, if you only need this for couple of recipes, you can do 
> > > this with alternative providers. E.g. instead of altering existing recipes 
> > > with bbappends (e.g. cryptodev), you can have many providers for the same 
> > > package (e.g. linux-ti-staging, linux-ti-mainline, even linux-yocto from 
> > > OE-core all provide the Linux kernel, or virtual/kernel; same with u-boot 
> > > from OE-core and u-boot-ti-staging plus u-boot-ti-mainline provide U-boot 
> > > bootloader, like virtual/bootloaader). Those can be switched with a global 
> > > PREFERRED_PROVIDER_<pkg> variable:
> > > 
> > > https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/k3.inc#n13
> > > 
> > > In other words, if cryptodev is the only such case right now, it's less 
> > > involved to create cryptodev-ti-mainline recipes, set those to corresponding 
> > > PROVIDES, as well as PREFERRED_PROVIDER_ in necessary config files. Let me 
> > > know if you need help with that.
> > 
> > 
> > Hmm.. Thanks.. yeah, it is cryptodev today, something else tomorrow,
> > in addition, I need to expand from purely kernel and u-boot upstream
> > components alone to TF-A, linux-firmware upstream and eventually few
> > additional packages etc. Mostly as a forward looking layer to uncover
> > issues ahead of time. My thoughts on this is as follows: While the
> > provider view can easily fit as well, it is a little less distracting
> > or in some cases, un-intended usage to keep a "experimental" and
> > "forward looking" layer away from users of production layer - then the
> > distinction is very clearcut and risks(essentially "you are on your
> > own") associated with the same would be clear as well. Who knows, some
> > day, we might be even be able to delete such a layer since upstream will
> > be rocksolid (touch wood)..
> 
> Ah, that would the most glorious day for sure! :)
> 
> Anyway, if you intend to have cryptodev, atf/tf-a, optee, linux-firmware and 
> such, then sure, a separate mainline-only layer would be the best. BTW, things 
> like SGX and RGX will also fit there nicely.
> 

Thanks for your feedback. I have to take it internally to get all the
blessings I need to make things move forward..

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D