Date   

[meta-security][PATCH 3/7] linux-yocto-dev: drop bbappend

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-yocto-dev.bbappend | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
deleted file mode 100644
index 1d9054f..0000000
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'security', '${BPN}_security.inc', '', d)}
--
2.25.1


[meta-security][PATCH 2/7] meta-security/recipe-kernel: use sanity check

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-yocto-dev.bbappend | 4 +---
recipes-kernel/linux/linux-yocto_5.%.bbappend | 4 +---
recipes-kernel/linux/linux-yocto_security.inc | 3 +++
3 files changed, 5 insertions(+), 6 deletions(-)
create mode 100644 recipes-kernel/linux/linux-yocto_security.inc

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index fa536d0..1d9054f 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1,3 +1 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
+require ${@bb.utils.contains('DISTRO_FEATURES', 'security', '${BPN}_security.inc', '', d)}
diff --git a/recipes-kernel/linux/linux-yocto_5.%.bbappend b/recipes-kernel/linux/linux-yocto_5.%.bbappend
index fa536d0..1d9054f 100644
--- a/recipes-kernel/linux/linux-yocto_5.%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_5.%.bbappend
@@ -1,3 +1 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
+require ${@bb.utils.contains('DISTRO_FEATURES', 'security', '${BPN}_security.inc', '', d)}
diff --git a/recipes-kernel/linux/linux-yocto_security.inc b/recipes-kernel/linux/linux-yocto_security.inc
new file mode 100644
index 0000000..fa536d0
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_security.inc
@@ -0,0 +1,3 @@
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.25.1


[meta-security][PATCH 1/7] meta-security: add sanity check

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
README | 18 ++++++++++++++++++
classes/sanity-meta-security.bbclass | 10 ++++++++++
conf/layer.conf | 4 ++++
3 files changed, 32 insertions(+)
create mode 100644 classes/sanity-meta-security.bbclass

diff --git a/README b/README
index eb15366..4047b86 100644
--- a/README
+++ b/README
@@ -1,6 +1,24 @@
Meta-security
=============

+The bbappend files for some recipes (e.g. linux-yocto) in this layer need
+to have 'security' in DISTRO_FEATURES to have effect.
+To enable them, add in configuration file the following line.
+
+ DISTRO_FEATURES_append = " security"
+
+If meta-security is included, but security is not enabled as a
+distro feature a warning is printed at parse time:
+
+ You have included the meta-security layer, but
+ 'security' has not been enabled in your DISTRO_FEATURES. Some bbappend files
+ and preferred version setting may not take effect.
+
+If you know what you are doing, this warning can be disabled by setting the following
+variable in your configuration:
+
+ SKIP_META_SECURITY_SANITY_CHECK = 1
+
This layer provides security tools, hardening tools for Linux kernels
and libraries for implementing security mechanisms.

diff --git a/classes/sanity-meta-security.bbclass b/classes/sanity-meta-security.bbclass
new file mode 100644
index 0000000..b6c6b9c
--- /dev/null
+++ b/classes/sanity-meta-security.bbclass
@@ -0,0 +1,10 @@
+addhandler security_bbappend_distrocheck
+security_bbappend_distrocheck[eventmask] = "bb.event.SanityCheck"
+python security_bbappend_distrocheck() {
+ skip_check = e.data.getVar('SKIP_META_SECUIRTY_SANITY_CHECK') == "1"
+ if 'security' not in e.data.getVar('DISTRO_FEATURES').split() and not skip_check:
+ bb.warn("You have included the meta-security layer, but \
+'security' has not been enabled in your DISTRO_FEATURES. Some bbappend files \
+and preferred version setting may not take effect. See the meta-security README \
+for details on enabling security support.")
+}
diff --git a/conf/layer.conf b/conf/layer.conf
index 906e024..7853d6e 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -13,6 +13,10 @@ LAYERSERIES_COMPAT_security = "hardknott"

LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer meta-python"

+# Sanity check for meta-security layer.
+# Setting SKIP_META_SECURITY_SANITY_CHECK to "1" would skip the bbappend files check.
+INHERIT += "sanity-meta-security"
+
BBFILES_DYNAMIC += " \
rust-layer:${LAYERDIR}/dynamic-layers/meta-rust/recipes-*/*/*.bb \
"
--
2.25.1


[meta-security][PATCH 0/7] YCL cleanups

Armin Kuster
 

This series superceeds the privious set to help
pass the check-layer scrip.

Armin Kuster (7):
meta-security: add sanity check
meta-security/recipe-kernel: use sanity check
linux-yocto-dev: drop bbappend
meta-tpm: add layer sanity check
meta-tpm/linux-yocto: use sanity support
meta-integrity: add sanity check
meta-integrity/recipe-kernel: use sanity check

README | 18 ++++++++++++++++++
classes/sanity-meta-security.bbclass | 10 ++++++++++
conf/layer.conf | 4 ++++
meta-integrity/README.md | 18 +++++++++++++++++-
.../classes/sanity-meta-integrity.bbclass | 10 ++++++++++
meta-integrity/conf/layer.conf | 4 ++++
.../recipes-kernel/linux/linux-%.bbappend | 6 +-----
.../recipes-kernel/linux/linux_ima.inc | 5 +++++
meta-tpm/README | 19 +++++++++++++++++++
meta-tpm/classes/sanity-meta-tpm.bbclass | 10 ++++++++++
meta-tpm/conf/layer.conf | 4 ++++
.../linux/linux-yocto_5.%.bbappend | 18 +-----------------
.../recipes-kernel/linux/linux-yocto_tpm.inc | 17 +++++++++++++++++
recipes-kernel/linux/linux-yocto_5.%.bbappend | 4 +---
...-dev.bbappend => linux-yocto_security.inc} | 0
15 files changed, 121 insertions(+), 26 deletions(-)
create mode 100644 classes/sanity-meta-security.bbclass
create mode 100644 meta-integrity/classes/sanity-meta-integrity.bbclass
create mode 100644 meta-integrity/recipes-kernel/linux/linux_ima.inc
create mode 100644 meta-tpm/classes/sanity-meta-tpm.bbclass
create mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto_tpm.inc
rename recipes-kernel/linux/{linux-yocto-dev.bbappend => linux-yocto_security.inc} (100%)

--
2.25.1


Re: bitbake controlling memory use

Gmane Admin
 

Op 14-04-2021 om 06:59 schreef Richard Purdie:
On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:
On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:
make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)
During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237
Cheers,
Richard
I like the idea. Unfortunately the patch doesn't apply to Gatesgarth, so I couldn't test it. Any chance you would be doing a refresh?


Re: Is it a bug or it does not support device tree /delete-node/?

Quentin Schulz
 

Hi,

On June 5, 2021 12:43:19 AM UTC, JH <jupiter.hce@...> wrote:
Hi,

I am building following imx6ulz-kobs.dts file to a dtb in zeus:

$ cat imx6ulz-kobs.dts

#include "imx6ulz.dts"

/{
model = "customized imx6ull";
compatible = "fsl,imx6ull";
};

&gpmi {
/delete-node/ fsl,use-minimum-ecc;
};

The building process was fine, but that fsl,use-minimum-ecc in dtb was
not deleted, is it a bug or it does not support /delete-node/?
fsl,use-minimum-ecc is a property not a node, you need to use /delete-property/ instead, c.f. https://devicetree-specification.readthedocs.io/en/latest/chapter6-source-language.html?highlight=delete-property#node-and-property-definitions.

Cheers,
Quentin


Is it a bug or it does not support device tree /delete-node/?

JH
 

Hi,

I am building following imx6ulz-kobs.dts file to a dtb in zeus:

$ cat imx6ulz-kobs.dts

#include "imx6ulz.dts"

/{
model = "customized imx6ull";
compatible = "fsl,imx6ull";
};

&gpmi {
/delete-node/ fsl,use-minimum-ecc;
};

The building process was fine, but that fsl,use-minimum-ecc in dtb was
not deleted, is it a bug or it does not support /delete-node/?

Thank you.

- jupiter


Re: Can the Linux kernel reuse the barebox device tree? #kernel

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 5:00 AM <florian.kauer@...> wrote:

Hi,
I made the following observation in my custom Yocto system:
The device tree loaded by the Linux kernel is one that is only available in the barebox directory, but not available in the kernel sources. In fact, it is quite similar, but I made some changes to it in the device tree provided to the kernel. Especially the machine model that is shown during kernel boot is a string that can only be found in the compiled barebox image, but not in the dtb files (where I can find the correct machine model string) or anywhere else in the compilation results. But also other messages indicate that the wrong device tree is loaded.

It was correct before, and I am not really sure what triggered that (just upgraded from zeus, but it might or might not be triggered by that) and I wouldn't expect that anyone could guess what I have done wrong without debugging my setup in depth. But, my general question is: Is there any mechanism that could explain such a behavior? Any configuration that means "extract the device tree from the bootloader" or something similar?
In your upgrade, did the bootloader/initramfs/kernel version change ?
The passing of the device tree to the kernel is (commonly) part of the
bootflow, so changes to any of the components in that flow could cause
the different device tree usage you are seeing.

The bbclass and recipes involved wouldn't have been packaging up the
barebox tree and pulling it into the kernel in zeus, so while it isn't
impossible, it isn't likely to be in the build or packaging changes.

Bruce

Greetings,
Florian


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 8:37 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.
I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.
Apologies on this, I see in the follow up email you did mention the
layerindex .. I read completely over that, and had to search up the
warning myself. (my fault, not yours).


That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.
This point still stands though :D

Bruce


Bruce


Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.
I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.

That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.

Bruce


Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.

Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

On 6/4/21 2:49 PM, kai wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Please ignore it according to Martin's comment in oe-devel list.

Regards,
Kai


Signed-off-by: Kai Kang <kai.kang@...>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
 
-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"
 
 LICENSE_PATH += "${LAYERDIR}/licenses"
 




-- 
Kai Kang
Wind River Linux


Can the Linux kernel reuse the barebox device tree? #kernel

florian.kauer@...
 

Hi,
I made the following observation in my custom Yocto system:
The device tree loaded by the Linux kernel is one that is only available in the barebox directory, but not available in the kernel sources. In fact, it is quite similar, but I made some changes to it in the device tree provided to the kernel. Especially the machine model that is shown during kernel boot is a string that can only be found in the compiled barebox image, but not in the dtb files (where I can find the correct machine model string) or anywhere else in the compilation results. But also other messages indicate that the wrong device tree is loaded.

It was correct before, and I am not really sure what triggered that (just upgraded from zeus, but it might or might not be triggered by that) and I wouldn't expect that anyone could guess what I have done wrong without debugging my setup in depth. But, my general question is: Is there any mechanism that could explain such a behavior? Any configuration that means "extract the device tree from the bootloader" or something similar?

Greetings,
Florian


[meta-openssl102-fips][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 01026f0..27ddad6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5"

LAYERVERSION_meta-openssl-one-zero-two-fips = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott honister"

LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}"

--
2.17.1


[meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"

LAYERDEPENDS_gplv2 = "core"

-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"

LICENSE_PATH += "${LAYERDIR}/licenses"

--
2.17.1


[meta-openssl102][PATCH] layer.conf: support honister

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 4ea1009..ce7f99b 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two = "5"

LAYERVERSION_meta-openssl-one-zero-two = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott honister"

LAYERDEPENDS_meta-openssl-one-zero-two = " \
core \
--
2.17.1


[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

Hi Bruce,


There is an patch to fix dspi hang issue.

Would you please help to merge this patch into linux-ycoto kernel, v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx?


Thanks,
Zhantao


[PATCH] drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

On NXP S32G RDB2, there is an sja1110 switch, which can be accessed
using dspi interface, but if users use the following commands to test
the switch, the board will hang there.

$ echo 30 > /sys/class/gpio/export
$ echo out > /sys/class/gpio/gpio30/direction
$ echo 0 > /sys/class/gpio/gpio30/value
$ echo -n -e '\x02\x00\x00\x00\x00\x00\x00\x00' | spi-pipe -d /dev/spidev5.1 -b 4 | hexdump -C

The reason is that, the dspi driver wrongly sets the HALT flag in
the register, and the while loop will run forever, so the board hang
there. This patch is to fix this issue.

Signed-off-by: Zhantao Tang <zhantao.tang@...>
---
drivers/spi/spi-fsl-dspi.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 063cf4a60ed3..c20cce466bf7 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -965,10 +965,8 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
dspi->progress = 0;

regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_HALT, SPI_MCR_HALT);
- while (regmap_read(dspi->regmap, SPI_SR, &val) >= 0 &&
- val & SPI_SR_TXRXS)
- ;
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);

spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer,
dspi->progress, !dspi->irq);
@@ -987,10 +985,6 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
} while (status == -EINPROGRESS);
}
}
- regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF |
- SPI_MCR_HALT,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
if (status)
break;

--
2.25.1


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

kai
 

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show warning:

  WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott: length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch master, please?

Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?

Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.

Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

4081 - 4100 of 57807