Re: [yocto] systemd: how to enable auto-loading kernel modules

2022-11-07 Thread Merlin
Thanks Mike for your advice!

I've replaced underscore to hyphen and rerun a build from fetch, but 
unfortunately that didn't invoke auto-load.

In fact, my modules are device drivers developed in out-of-tree repositories. 
Some user-space applications depend on them, so I wanted them to be auto-loaded 
on boot. Autoload didn't occur even though I've added corresponding devicetree 
properties.

Best

Merlin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58523): https://lists.yoctoproject.org/g/yocto/message/58523
Mute This Topic: https://lists.yoctoproject.org/mt/94648966/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [linux-yocto std/rt kernel v5.15]: nxp-s32g: update to compatible with SDK BSP35 RC4

2022-11-07 Thread Zhantao Tang
Hi Bruce,

There are two new patches of linux kernel, from SDK BSP35 RC4.
Would you please help merge the two patches to the branches?
v5.15/standard/preempt-rt/nxp-sdk-5.10/nxp-s32g
v5.15/standard/nxp-sdk-5.10/nxp-s32g

Thanks,
Zhantao

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11863): 
https://lists.yoctoproject.org/g/linux-yocto/message/11863
Mute This Topic: https://lists.yoctoproject.org/mt/94885140/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 1/2] phy: s32cc-serdes: rename fsl,sys-mode to nxp,sys-mode

2022-11-07 Thread Zhantao Tang
From: Radu Pirea 

commit 5298b17e17e2aaafd19ad71e7774375769821bf5 from
https://source.codeaurora.org/external/autobsps32/linux

Issue: ALB-9137 ALB-9138

Signed-off-by: Radu Pirea 
Signed-off-by: Zhantao Tang 
---
 .../devicetree/bindings/phy/nxp,s32cc-serdes.yaml | 8 
 arch/arm64/boot/dts/freescale/s32cc.dtsi  | 4 ++--
 drivers/phy/freescale/phy-fsl-s32gen1-serdes.c| 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/nxp,s32cc-serdes.yaml 
b/Documentation/devicetree/bindings/phy/nxp,s32cc-serdes.yaml
index e397aff132aa..8106401101b1 100644
--- a/Documentation/devicetree/bindings/phy/nxp,s32cc-serdes.yaml
+++ b/Documentation/devicetree/bindings/phy/nxp,s32cc-serdes.yaml
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright 2021 NXP
+# Copyright 2021-2022 NXP
 %YAML 1.2
 ---
 $id: "http://devicetree.org/schemas/phy/nxp,s32cc-serdes.yaml#;
@@ -81,7 +81,7 @@ properties:
   - const: serdes
   - const: pcie
 
-  fsl,sys-mode:
+  nxp,sys-mode:
 $ref: /schemas/types.yaml#/definitions/uint32
 description: |
   SerDes operational mode. See above table for possible values.
@@ -107,7 +107,7 @@ required:
   - clock-names
   - resets
   - reset-names
-  - 'fsl,sys-mode'
+  - 'nxp,sys-mode'
   - reg
   - reg-names
 
@@ -131,7 +131,7 @@ examples:
 resets = < S32GEN1_SCMI_RST_SERDES1>,
  < S32GEN1_SCMI_RST_PCIE1>;
 reset-names = "serdes", "pcie";
-fsl,sys-mode = <3>;
+nxp,sys-mode = <3>;
 reg = <0x4418 0x108>,
   <0x44183008 0x10>,
   <0x44182000 0x800>,
diff --git a/arch/arm64/boot/dts/freescale/s32cc.dtsi 
b/arch/arm64/boot/dts/freescale/s32cc.dtsi
index db7aa7aa005b..7e96c1c5b4b6 100644
--- a/arch/arm64/boot/dts/freescale/s32cc.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32cc.dtsi
@@ -981,7 +981,7 @@ serdes0: serdes@4048 {
resets = < S32GEN1_SCMI_RST_SERDES0>,
 < S32GEN1_SCMI_RST_PCIE0>;
reset-names = "serdes", "pcie";
-   fsl,sys-mode = ;
+   nxp,sys-mode = ;
reg = <0x0 0x4048 0x0 0x108>,
  <0x0 0x40483008 0x0 0x10>,
  <0x0 0x40482000 0x0 0x800>,
@@ -1046,7 +1046,7 @@ serdes1: serdes@4418 {
resets = < S32GEN1_SCMI_RST_SERDES1>,
 < S32GEN1_SCMI_RST_PCIE1>;
reset-names = "serdes", "pcie";
-   fsl,sys-mode = ;
+   nxp,sys-mode = ;
reg = <0x0 0x4418 0x0 0x108>,
  <0x0 0x44183008 0x0 0x10>,
  <0x0 0x44182000 0x0 0x800>,
diff --git a/drivers/phy/freescale/phy-fsl-s32gen1-serdes.c 
b/drivers/phy/freescale/phy-fsl-s32gen1-serdes.c
index 4e8bb8d898cd..eb5fcd21da20 100644
--- a/drivers/phy/freescale/phy-fsl-s32gen1-serdes.c
+++ b/drivers/phy/freescale/phy-fsl-s32gen1-serdes.c
@@ -775,7 +775,7 @@ static int ss_dt_init(struct platform_device *pdev, struct 
serdes *serdes)
struct resource *res;
int ret;
 
-   ret = of_property_read_u32(dev->of_node, "fsl,sys-mode",
+   ret = of_property_read_u32(dev->of_node, "nxp,sys-mode",
   >ss_mode);
if (ret) {
dev_err(dev, "Failed to get SerDes subsystem mode\n");
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11861): 
https://lists.yoctoproject.org/g/linux-yocto/message/11861
Mute This Topic: https://lists.yoctoproject.org/mt/94885138/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 2/2] s32cc: qspi: Fix ahb buf size to 512 MB from 64MB

2022-11-07 Thread Zhantao Tang
From: Ciprian Costea 

commit 608d2b41dfb96ed947971cfa04cb7cbfe9e4d036 from
https://source.codeaurora.org/external/autobsps32/linux

Our S32CC QSPI controller can support AHB sizes up to 512MB.
Currently we allocate only 64MB for ahb buf size.
We fix this by allocating 512MB for AHB buf size with
size information parsed from dtb.

Issue: ALB-9442
Signed-off-by: Ciprian Costea 
Signed-off-by: Zhantao Tang 
---
 drivers/spi/spi-fsl-qspi.c | 4 ++--
 drivers/spi/spi-fsl-qspi.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index f3b5df63ae09..c0e09b64d6d2 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -99,7 +99,7 @@ static const struct fsl_qspi_devtype_data ls2080a_data = {
 static const struct fsl_qspi_devtype_data s32gen1_data = {
.rxfifo = SZ_128,
.txfifo = SZ_256,
-   .ahb_buf_size = SZ_64M,
+   .ahb_buf_size = SZ_1K,
.quirks = 0,
.little_endian = true,
 };
@@ -107,7 +107,7 @@ static const struct fsl_qspi_devtype_data s32gen1_data = {
 static const struct fsl_qspi_devtype_data s32g3_data = {
.rxfifo = SZ_128,
.txfifo = SZ_256,
-   .ahb_buf_size = SZ_64M,
+   .ahb_buf_size = SZ_1K,
.quirks = 0,
.little_endian = true,
 };
diff --git a/drivers/spi/spi-fsl-qspi.h b/drivers/spi/spi-fsl-qspi.h
index 196b16488bbd..06c99f37f101 100644
--- a/drivers/spi/spi-fsl-qspi.h
+++ b/drivers/spi/spi-fsl-qspi.h
@@ -124,8 +124,6 @@
 #define S32GEN1_QUADSPI_SFB2AD_VAL 0x1000
 #define QUADSPI_RBDR(x)(0x200 + ((x) * 4))
 
-#define QUADSPI_AHB_BASE   0x0
-
 #define QUADSPI_LUTKEY 0x300
 #define QUADSPI_LUTKEY_VALUE   0x5AF05AF0
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11862): 
https://lists.yoctoproject.org/g/linux-yocto/message/11862
Mute This Topic: https://lists.yoctoproject.org/mt/94885139/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto linux on QNX Hypervisor #yocto #os-release #native #make #yocto

2022-11-07 Thread Ayush Chauhan
Can someone guide me through the process to put custom yocto image on qnx 
hypervisor and let me know if it is supported or not?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58522): https://lists.yoctoproject.org/g/yocto/message/58522
Mute This Topic: https://lists.yoctoproject.org/mt/94884219/21656
Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native
Mute #make:https://lists.yoctoproject.org/g/yocto/mutehashtag/make
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #os-release:https://lists.yoctoproject.org/g/yocto/mutehashtag/os-release
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto-announce] [ANNOUNCEMENT] Yocto Project 4.0.5 is Released

2022-11-07 Thread Lee Chee Yang
Hi

We are pleased to announce the Yocto Project 4.0.5 Release is now available for 
download.

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/testreport.txt

Thank you for everyone's contributions to this release.

Chee Yang
chee.yang@intel.com
Yocto Project Build and Release


- --
yocto-4.0.5 Release Notes
- --


- --
Repositories/Downloads
- --

Repository Name: poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: 2e79b199114b25d81bfaa029ccfb17676946d20d
Release Artefact: poky-2e79b199114b25d81bfaa029ccfb17676946d20d
sha: 7bcf3f901d4c5677fc95944ab096e9e306f4c758a658dde5befd16861ad2b8ea
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: fbdf93f43ff4b876487e1f26752598ec8abcb46e
Release Artefact: oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e
sha: 2d9b5a8e9355b633bb57633cc8c2d319ba13fe4721f79204e61116b3faa6cbf1
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: a90614a6498c3345704e9611f2842eb933dc51c1
Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: 2.0
Tag: yocto-4.0.5
Git Revision: c90d57497b9bcd237c3ae810ee8edb5b0d2d575a
Release Artefact: bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a
sha: 5698d548ce179036e46a24f80b213124c8825a4f443fa1d6be7ab0f70b01a9ff
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a.tar.bz2

Repository Name: yocto-docs
Repository Location: https://git.yoctoproject.org/git/yocto-docs
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: 8c2f9f54e29781f4ee72e81eeaa12ceaa82dc2d3


- ---
Contributors
- ---
Adrian Freihofer
Alexander Kanavin
Alexandre Belloni
Bhabu Bindu
Bruce Ashfield
Chen Qi
Daniel McGregor
Denys Dmytriyenko
Dmitry Baryshkov
Florin Diaconescu
He Zhe
Joshua Watt
Khem Raj
Martin Jansa
Michael Halstead
Michael Opdenacker
Mikko Rapeli
Mingli Yu
Neil Horman
Pavel Zhukov
Richard Purdie
Robert Joslyn
Ross Burton
Ruiqiang Hao
Samuli Piippo
Steve Sakoman
Sundeep KOKKONDA
Teoh Jay Shen
Tim Orling
Virendra Thakur
Vyacheslav Yurkov
Xiangyu Chen
Yash Shinde
pgowda
wangmy


- ---
Known Issues
- ---
There are recent CVEs in key components such as openssl. They are not included 
in this release as it was built before the issues were known and fixes were 
available but these are now available on the kirkstone branch.


- ---
Security Fixes
- ---
qemu: fix CVE-2021-3611 CVE-2021-3750 CVE-2022-2962
binutils : Fix CVE-2022-38126 CVE-2022-38127 CVE-2022-38128
tiff: Fix CVE-2022-2867 CVE-2022-2868 CVE-2022-2869
inetutils: fix CVE-2022-39028
go: fix CVE-2022-27664


- ---
Fixes
- ---
Revert 

[yocto] [ANNOUNCEMENT] Yocto Project 4.0.5 is Released

2022-11-07 Thread Lee Chee Yang
Hi

We are pleased to announce the Yocto Project 4.0.5 Release is now available for 
download.

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/testreport.txt

Thank you for everyone's contributions to this release.

Chee Yang
chee.yang@intel.com
Yocto Project Build and Release


- --
yocto-4.0.5 Release Notes
- --


- --
Repositories/Downloads
- --

Repository Name: poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: 2e79b199114b25d81bfaa029ccfb17676946d20d
Release Artefact: poky-2e79b199114b25d81bfaa029ccfb17676946d20d
sha: 7bcf3f901d4c5677fc95944ab096e9e306f4c758a658dde5befd16861ad2b8ea
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/poky-2e79b199114b25d81bfaa029ccfb17676946d20d.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: fbdf93f43ff4b876487e1f26752598ec8abcb46e
Release Artefact: oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e
sha: 2d9b5a8e9355b633bb57633cc8c2d319ba13fe4721f79204e61116b3faa6cbf1
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/oecore-fbdf93f43ff4b876487e1f26752598ec8abcb46e.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: a90614a6498c3345704e9611f2842eb933dc51c1
Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: 2.0
Tag: yocto-4.0.5
Git Revision: c90d57497b9bcd237c3ae810ee8edb5b0d2d575a
Release Artefact: bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a
sha: 5698d548ce179036e46a24f80b213124c8825a4f443fa1d6be7ab0f70b01a9ff
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.5/bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-4.0.5/bitbake-c90d57497b9bcd237c3ae810ee8edb5b0d2d575a.tar.bz2

Repository Name: yocto-docs
Repository Location: https://git.yoctoproject.org/git/yocto-docs
Branch: kirkstone
Tag: yocto-4.0.5
Git Revision: 8c2f9f54e29781f4ee72e81eeaa12ceaa82dc2d3


- ---
Contributors
- ---
Adrian Freihofer
Alexander Kanavin
Alexandre Belloni
Bhabu Bindu
Bruce Ashfield
Chen Qi
Daniel McGregor
Denys Dmytriyenko
Dmitry Baryshkov
Florin Diaconescu
He Zhe
Joshua Watt
Khem Raj
Martin Jansa
Michael Halstead
Michael Opdenacker
Mikko Rapeli
Mingli Yu
Neil Horman
Pavel Zhukov
Richard Purdie
Robert Joslyn
Ross Burton
Ruiqiang Hao
Samuli Piippo
Steve Sakoman
Sundeep KOKKONDA
Teoh Jay Shen
Tim Orling
Virendra Thakur
Vyacheslav Yurkov
Xiangyu Chen
Yash Shinde
pgowda
wangmy


- ---
Known Issues
- ---
There are recent CVEs in key components such as openssl. They are not included 
in this release as it was built before the issues were known and fixes were 
available but these are now available on the kirkstone branch.


- ---
Security Fixes
- ---
qemu: fix CVE-2021-3611 CVE-2021-3750 CVE-2022-2962
binutils : Fix CVE-2022-38126 CVE-2022-38127 CVE-2022-38128
tiff: Fix CVE-2022-2867 CVE-2022-2868 CVE-2022-2869
inetutils: fix CVE-2022-39028
go: fix CVE-2022-27664


- ---
Fixes
- ---
Revert 

[yocto] M+ & H bugs with Milestone Movements WW45

2022-11-07 Thread Stephen Jolley
All,

YP M+ or high bugs which moved to a new milestone in WW45 are listed below: 


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


High

  14787

AB-INT: systemd.SystemdServiceTests.test_systemd_status failure

randy.macl...@windriver.com

ross.bur...@arm.com

4.1 M4

4.2 M1


Medium+

  10731

bitbake --observe-only doesn't work with memres

randy.macl...@windriver.com

pa...@zhukoff.net

4.2

4.2 M2


 

  11781

bitbake --observe-only may get KeyError

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.1 M3

4.2 M1


 

  11899

broken 'bitbake --status-only' and 'bitbake -m'

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.1 M3

4.2 M1


 

  12937

Consistent naming scheme for deployed artifacts

randy.macl...@windriver.com

martin.ja...@gmail.com

4.1 M3

4.99


 

  13808

do_task[noexec] = "" marks task noexec, which is inconsistent with docs

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.1

4.2 M1


 

  14045

git fetcher deadlock with self-referencing sub-modules

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.1 M4

4.2 M1


 

  14121

Implement sphinx switchers.js for bitbake

randy.macl...@windriver.com

michael.opdenac...@bootlin.com

4.1 M3

4.2 M1


 

  14717

OEToolchainConfig.cmake sets wrong and unsuitable compiler flags

randy.macl...@windriver.com

martin.bee...@online.de

4.1 M2

4.2 M1


 

  14745

cve-checker update to support NVD json 5.0 format

randy.macl...@windriver.com

akuster...@gmail.com

4.1 M3

4.2 M1


 

  14905

Error in compiling rustfmt does not cause do_compile to fail

randy.macl...@windriver.com

naveen.go...@windriver.com

4.1 M4

4.2 M1

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com  

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58519): https://lists.yoctoproject.org/g/yocto/message/58519
Mute This Topic: https://lists.yoctoproject.org/mt/94881212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Enhancements/Bugs closed WW45!

2022-11-07 Thread Stephen Jolley
All,

The below were the owners of enhancements or bugs closed during the last
week!


Who

Count


randy.macl...@windriver.com

5


mhalst...@linuxfoundation.org

1


michael.opdenac...@bootlin.com

1


richard.pur...@linuxfoundation.org

1


martin.ja...@gmail.com

1


Grand Total

9

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58518): https://lists.yoctoproject.org/g/yocto/message/58518
Mute This Topic: https://lists.yoctoproject.org/mt/94881199/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Current high bug count owners for Yocto Project 4.2

2022-11-07 Thread Stephen Jolley
All,

Below is the list as of top 31 bug owners as of the end of WW45 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 118
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

35


ross.bur...@arm.com

31


randy.macl...@windriver.com

26


bruce.ashfi...@gmail.com

24


david.re...@windriver.com

23


richard.pur...@linuxfoundation.org

22


sakib.sa...@windriver.com

11


jpewhac...@gmail.com

10


saul.w...@windriver.com

9


pa...@zhukoff.net

4


sundeep.kokko...@gmail.com

4


tim.orl...@konsulko.com

4


zheng@windriver.com

3


akuster...@gmail.com

2


hongxu@windriver.com

2


aeh...@gmail.com

2


jon.ma...@arm.com

2


naveen.go...@windriver.com

2


s...@bigsur.com

2


rybczyn...@gmail.com

1


ptsne...@gmail.com

1


sundeep.kokko...@windriver.com

1


anton.anto...@arm.com

1


thomas.per...@bootlin.com

1


martin.bee...@online.de

1


hummerbl...@gmail.com

1


alexandre.bell...@bootlin.com

1


qi.c...@windriver.com

1


tvgamb...@gmail.com

1


martin.ja...@gmail.com

1


mhalst...@linuxfoundation.org

1


Grand Total

230

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58517): https://lists.yoctoproject.org/g/yocto/message/58517
Mute This Topic: https://lists.yoctoproject.org/mt/94881140/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2022-11-07 Thread Stephen Jolley
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 415
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58516): https://lists.yoctoproject.org/g/yocto/message/58516
Mute This Topic: https://lists.yoctoproject.org/mt/94881105/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] undefined reference problem persists

2022-11-07 Thread Alexander Kanavin
On Mon, 7 Nov 2022 at 18:57, Ron Eggler  wrote:

> Exactly, the customer will have full access to the source code incl. the
> complete set of Yocto layers and all.
>

Then your best option is to drop meta-gplv2 layer from builds altogether.
This will update everything to current, compatible versions that are easier
to fix if needed.

Just to be on the safe side, you do need to find out why it was added
though. The reason may still hold.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58515): https://lists.yoctoproject.org/g/yocto/message/58515
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] undefined reference problem persists

2022-11-07 Thread Mistyron


On 2022-11-07 7:20 a.m., Alexander Kanavin wrote:

On Mon, 7 Nov 2022 at 16:13, Ron Eggler  wrote:

Are you able to fulfil that obligation you have under the license?

Yes, that will definitely be doable for the recepient if they chose to
do so.

I'm curious as to how though. Are you going to give them a complete
set of yocto layers and source code for everything that goes into the
image, so that they can replicate the yocto build? If they choose to
replace readline with their own version, I don't see any other way.
Exactly, the customer will have full access to the source code incl. the 
complete set of Yocto layers and all.

Note that we are not talking about the manufacturer of the device, we
are talking about the actual end users who will buy and use the device
for its intended purpose.

Yes, understood!
--


*RON EGGLER*
Firmware Engineer
(he/him/his)
www.mistywest.com
MistyWest Logo

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58514): https://lists.yoctoproject.org/g/yocto/message/58514
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][linux-yocto v5.15] kernel code for marvell octeon

2022-11-07 Thread Bruce Ashfield
In message: [linux-yocto][linux-yocto v5.15] kernel code for marvell octeon
on 07/11/2022 Ruiqiang Hao wrote:

> Hi Bruce,
> 
> Please help to merge these 5 patches into our linux-yocto repo.
> 
> repo:
> linux-yocto
> branch:
> v5.15/standard/cn-sdkv5.4/octeon
> v5.15/standard/preempt-rt/cn-sdkv5.4/octeon

merged.

Bruce

> 
> Thanks,
> Ruiqiang

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11859): 
https://lists.yoctoproject.org/g/linux-yocto/message/11859
Mute This Topic: https://lists.yoctoproject.org/mt/94862182/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [yocto-kernel-tools][PATCH] kconf_check: store some files in tmpdir

2022-11-07 Thread Bruce Ashfield
This looks reasonable to me.

I'll queue the change and do some regression testing. Once that
passes, I can put it in my next pull request.

Bruce

On Fri, Nov 4, 2022 at 7:32 PM Volodymyr Babchuk
 wrote:
>
> Some file systems, like ZFS, are very slow at appending to existing
> files. Due to Copy-On-Write nature, they create a new copy of a file
> each time we do ">>" in a shell script. This becomes very noticeable
> if shell script does lots and lots of appends, like sanitize_fragment()
> function in kconf_check. On my setup, do_kernel_configcheck task takes
> literally hours to complete.
>
> To fix this issue, we can store sanitized_list and fragment_errors.txt
> files on tmpfs, which is extremely fast at writing. As most distros
> use tmpfs for /tmp, logical step is to use `mktemp` to create
> temporary files.
>
> After completing writing to temporary locations, we can move those two
> files back to ${LOGDIR}.
>
> Also, function 'cleanup' was added to remove temporary files in case
> of abnormal exit.
>
> With this patch, do_kernel_configcheck task completes in ~2 minutes on
> my setup, which is a great improvement.
>
> Signed-off-by: Volodymyr Babchuk 
> ---
>  tools/kconf_check | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/tools/kconf_check b/tools/kconf_check
> index 57d3132..5f25f17 100755
> --- a/tools/kconf_check
> +++ b/tools/kconf_check
> @@ -195,6 +195,21 @@ function classify_options() {
>  fi
>  }
>
> +# Temporary files to store sanitized list and fragment errors.
> +# Create those files in /tmp because /tmp in most cases is stored in RAM
> +# This greatly increases performance, as we will append data to those files
> +# and some file systems (like ZFS) are very slow at appends.
> +FRAGMENT_ERRORS_TMP=`mktemp`
> +SANITIZED_LIST_TMP=`mktemp`
> +
> +# Clean temporary files from /tmp on exit
> +function cleanup {
> +rm -f $FRAGMENT_ERRORS_TMP
> +rm -f $SANITIZED_LIST_TMP
> +}
> +
> +trap cleanup EXIT
> +
>  # step #1.
>  # run merge_config.sh (without regenerating the .config), and capture its 
> output.
>  # This gets us redefined options, and a combined (but unprocessed) config.
> @@ -295,7 +310,7 @@ SED_CONFIG_EXP="s/^\(# 
> \)\{0,1\}\(CONFIG_[a-zA-Z0-9_]*\)[= ].*/\2/p"
>  rm -f ${LOGDIR}/fragment_errors.txt
>  declare -A CONFIGMAP
>  for c in ${configs_abs}; do
> -sanitize_fragment ${c} ${LOGDIR}/sanitized_list >> 
> ${LOGDIR}/fragment_errors.txt
> +sanitize_fragment ${c} $SANITIZED_LIST_TMP >> $FRAGMENT_ERRORS_TMP
>  cfg_list=$(sed -n "$SED_CONFIG_EXP" ${c})
>  for option in ${cfg_list}; do
>  if [ -z "${CONFIGMAP[${option}]}" ]; then
> @@ -310,6 +325,9 @@ for c in ${configs_abs}; do
>  fi
>  done
>
> +mv $FRAGMENT_ERRORS_TMP ${LOGDIR}/fragment_errors.txt
> +mv $SANITIZED_LIST_TMP ${LOGDIR}/sanitized_list
> +
>  # If we had meta data, we can use the classifications to group the options.
>  if [ -n "${metadata}" ]; then
>  rm -f $LOGDIR/avail_hardware.cfg
> --
> 2.38.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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11858): 
https://lists.yoctoproject.org/g/linux-yocto/message/11858
Mute This Topic: https://lists.yoctoproject.org/mt/94817916/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] v5.15 boot issue

2022-11-07 Thread Bruce Ashfield
On Fri, Nov 4, 2022 at 3:15 PM Sven Schwermer  wrote:
>
> Hi again,
>
> I played around a little and it seems like the following patch fixes the
> issue. It may be related to the following series, marking some of these
> functions __init:
> https://patchwork.kernel.org/project/linux-fsdevel/list/?series=325591=%2A=both
>

That does look very likely.

Since I wasn't seeing the same issue as you are, would you like to add
your Signed-off-by
and send the patch ? I can then queue it for regression testing.

Bruce

> diff --git a/init/main.c b/init/main.c
> index f141c69186bf..13df9fb8855e 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1573,14 +1573,13 @@ static int __ref kernel_init(void *unused)
>   void __init console_on_rootfs(void)
>   {
>   #ifndef CONFIG_BLK_DEV_INITRD
> -   /*
> -* Use /dev/console to infer if the rootfs is setup properly.
> -* In case of initrd or initramfs /dev/console might be instantiated
> -* later by /init so don't do this check for CONFIG_BLK_DEV_INITRD
> -*/
> -   struct kstat console_stat;
> -   if (vfs_lstat((char __user *) "/dev/console", (struct kstat __user *)
> _stat)
> -   || !S_ISCHR(console_stat.mode)) {
> +   /*
> +* Use /dev/console to infer if the rootfs is setup properly.
> +* In case of initrd or initramfs /dev/console might be instantiated
> +* later by /init so don't do this check for CONFIG_BLK_DEV_INITRD
> +*/
> +   struct kstat stat;
> +   if (init_stat("/dev/console", , 0) || !S_ISCHR(stat.mode)) {
> panic("/dev/console is missing or not a character 
> device!\nPlease
> ensure your rootfs is properly configured\n");
> }
>   #endif
>
>
> On 11/4/22 14:22, Bruce Ashfield wrote:
> >
> >
> > On Fri, Nov 4, 2022 at 6:30 AM Sven Schwermer  > > wrote:
> >
> > Hi,
> >
> > We're in the process of migrating from dunfell to kirkstone and noticed
> > a regression with the Linux kernel (branch: v5.15/standard/base). The
> > boot panics with
> >
> > [1.038015] Kernel panic - not syncing: /dev/console is missing!
> > [1.038015] Please ensure your rootfs is properly configured
> >
> > I have bisected the revisions between the good dunfell one and the bad
> > kirkstone one and the offending commit is:
> >
> > 0d7260ad7106 check console device file on fs when booting
> >
> >
> > the commit itself hasn't changed between those releases and kernel
> > versions, so it very well could be something else in the kernel or in
> > the generation of the rootfs that is now triggering the commit to change.
> >
> > The logic for the change is documented in the patch itself. We were
> > getting a lot (5 or more a week) questions (and blaming of the
> > kernel) when badly created rootfs were being booted. They all had
> > mangled /dev/console devices, and fixing that, fixed the boot. It was
> > much easier to just check and fail with a clearer message than the
> > other issues that happen down the boot process and that are much
> > more cryptic to debug.
> >
> > The weird thing is that vfs_lstat() fails while the subsequent
> > filp_open() in on the same file succeeds. I'm booting without
> > initramfs/initrd and with automounted devtmpfs:
> >
> > CONFIG_DEVTMPFS=y
> > CONFIG_DEVTMPFS_MOUNT=y
> > # CONFIG_BLK_DEV_INITRD is not set
> >
> > Since this commit is not part of upstream Linux, I thought I'd ask for
> > help here. What's the purpose of this extra check and why is it failing
> > even though /dev/console exists (filp_open("dev/console") works)?
> >
> >
> > That same check isn't failing in anything I've run, or the release process
> > has run (but a non initrd boot isn't as common, so it isn't impossible that
> > something slipped through).
> >
> > If there's a set of public layers that I can use to reproduce the problem,
> > I can have a closer look.  But it will be just me digging into the vfs_lstat
> > call to see if we are now misinterpreting the return from the routine, etc.
> >
> > Bruce
> >
> >
> > Best regards,
> > Sven
> >
> >
> >
> > --
> > - 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11857): 
https://lists.yoctoproject.org/g/linux-yocto/message/11857
Mute This Topic: https://lists.yoctoproject.org/mt/94802745/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [kernel-cache][master][yocto-5.19][PATCH 1/2] media-radio.cfg: switch RADIO_ADAPTERS from y to m

2022-11-07 Thread Bruce Ashfield
On Sun, Nov 6, 2022 at 9:54 PM Anuj Mittal  wrote:
>
> Hi Bruce,
>
> On Thu, 2022-11-03 at 15:20 +0800, Anuj Mittal wrote:
> > CONFIG_RADIO_ADAPTERS is now a tristate [1] which leads to problems
> > like:
> >
> > [2022-11-02T14:02:07.754Z] [NOTE]: 'CONFIG_RADIO_ADAPTERS' last
> > val (y) and .config val (m) do not match
> > [2022-11-02T14:02:07.754Z] [INFO]: CONFIG_RADIO_ADAPTERS : m ##
> > .config: 4072 :configs/v5.19/standard/preempt-
> > rt/features/media/media-radio.cfg (y)
> > [2022-11-02T14:02:07.754Z] [INFO]: raw config text:
> > [2022-11-02T14:02:07.754Z]
> > [2022-11-02T14:02:07.754Z] menuconfig RADIO_ADAPTERS
> > [2022-11-02T14:02:07.754Z]tristate "Radio Adapters"
> > [2022-11-02T14:02:07.754Z]default VIDEO_DEV
> > [2022-11-02T14:02:07.754Z]depends on VIDEO_DEV &&
> > MEDIA_RADIO_SUPPORT && MEDIA_SUPPORT
> > [2022-11-02T14:02:07.754Z]help
> > [2022-11-02T14:02:07.754Z]  Say Y here to enable
> > selecting AM/FM radio adapters.
> > [2022-11-02T14:02:07.754Z]
> > [2022-11-02T14:02:07.754Z] Config 'RADIO_ADAPTERS' has the
> > following Direct dependencies (RADIO_ADAPTERS=m):
> > [2022-11-02T14:02:07.754Z] VIDEO_DEV(=m) &&
> > MEDIA_RADIO_SUPPORT(=y) && MEDIA_SUPPORT(=m)
> > [2022-11-02T14:02:07.754Z] Parent dependencies are:
> > [2022-11-02T14:02:07.754Z]  MEDIA_RADIO_SUPPORT [y]
> > VIDEO_DEV [m] MEDIA_SUPPORT [m]
> > [2022-11-02T14:02:07.754Z]
> > [2022-11-02T14:02:07.754Z] [INFO]: selection details for
> > 'CONFIG_RADIO_ADAPTERS':
> > [2022-11-02T14:02:07.754Z] Symbols currently m-selecting this
> > symbol:
> > [2022-11-02T14:02:07.754Z]   - VIDEO_BT848
> > [2022-11-02T14:02:07.754Z]
> > [2022-11-02T14:02:07.754Z] Symbols currently n-selecting this
> > symbol (no effect):
> > [2022-11-02T14:02:07.754Z]   - SND_ES1968_RADIO
> > [2022-11-02T14:02:07.754Z]   - SND_FM801_TEA575X_BOOL
> > [2022-11-02T14:02:07.754Z]
> >
> > [1]
> > https://github.com/torvalds/linux/commit/215d49a41709610b9e82a49b27269cfaff1ef0b6
>
> This and the PATCH 2/2 in this series are not for v5.15. The changes
> are in kernel v5.19+.
>
> It looks like you mistakenly merged them in v5.15 branch too. Can you
> please revert from there?

Indeed. It looks like I misread the target branches. I now have this
on yocto-5.15:

50e12441b95 Revert "media-radio.cfg: switch RADIO_ADAPTERS from y to m"
ce5f29f07e6 Revert "vesafb.cfg: rename FB_BOOT_VESA_SUPPORT ->
BOOT_VESA_SUPPORT"

Bruce


>
>
> Thanks,
>
> Anuj
>
> 
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11856): 
https://lists.yoctoproject.org/g/linux-yocto/message/11856
Mute This Topic: https://lists.yoctoproject.org/mt/94798651/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] undefined reference problem persists

2022-11-07 Thread Alexander Kanavin
On Mon, 7 Nov 2022 at 16:13, Ron Eggler  wrote:
> > Are you able to fulfil that obligation you have under the license?
>
> Yes, that will definitely be doable for the recepient if they chose to
> do so.

I'm curious as to how though. Are you going to give them a complete
set of yocto layers and source code for everything that goes into the
image, so that they can replicate the yocto build? If they choose to
replace readline with their own version, I don't see any other way.

Note that we are not talking about the manufacturer of the device, we
are talking about the actual end users who will buy and use the device
for its intended purpose.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58513): https://lists.yoctoproject.org/g/yocto/message/58513
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] undefined reference problem persists

2022-11-07 Thread Mistyron


On 11/7/22 00:27, Alexander Kanavin wrote:

On Mon, 7 Nov 2022 at 02:35, Ron Eggler  wrote:

Are you going to ship what you're working on to other users, or is it
just experimentation?

The intent is, that's it's going to be shipped (but with full access to
the sources)

If you're shipping anything that is under gplv3 you also need to give
the recipient users a possibility to change the item under gplv3 from
the source code you have used to build it and install their modified
version to replace yours.

Are you able to fulfil that obligation you have under the license?


Yes, that will definitely be doable for the recepient if they chose to 
do so.


--

Ron


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58512): https://lists.yoctoproject.org/g/yocto/message/58512
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Installing custom yocto linux on QNX hypervisor

2022-11-07 Thread Ayush Chauhan
Hello,
Can you please guide me through the process to install custom yocto linux
on qnx hypervisor.
Need to go through the process from starting dor deploying a custom linux
on qnx hypervisor v2.2

Please guide through the steps.

Thanks & Regards,
Ayush
-- 
ayush

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58511): https://lists.yoctoproject.org/g/yocto/message/58511
Mute This Topic: https://lists.yoctoproject.org/mt/94862382/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 5/5] ptp: clockmatrix: use rsmu driver to access i2c/spi bus

2022-11-07 Thread Ruiqiang Hao
From: Min Li 

Backport of 930dfa563155179861470b2aba880eac2ae30bfb from linux-stable.

rsmu (Renesas Synchronization Management Unit ) driver is located in
drivers/mfd and responsible for creating multiple devices including
clockmatrix phc, which will then use the exposed regmap and mutex
handle to access i2c/spi bus.

Signed-off-by: Min Li 
Signed-off-by: David S. Miller 
Signed-off-by: Beniamin Sandu 
Signed-off-by: Ruiqiang Hao 
---
 drivers/ptp/idt8a340_reg.h   | 783 ---
 drivers/ptp/ptp_clockmatrix.c| 766 --
 drivers/ptp/ptp_clockmatrix.h| 117 +
 include/linux/mfd/idt8a340_reg.h |  31 +-
 4 files changed, 455 insertions(+), 1242 deletions(-)
 delete mode 100644 drivers/ptp/idt8a340_reg.h

diff --git a/drivers/ptp/idt8a340_reg.h b/drivers/ptp/idt8a340_reg.h
deleted file mode 100644
index 1c5210187110..
--- a/drivers/ptp/idt8a340_reg.h
+++ /dev/null
@@ -1,783 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/* idt8a340_reg.h
- *
- * Originally generated by regen.tcl on Thu Feb 14 19:23:44 PST 2019
- * https://github.com/richardcochran/regen
- *
- * Hand modified to include some HW registers.
- * Based on 5.2.0, Family Programming Guide (Sept 30, 2020)
- */
-#ifndef HAVE_IDT8A340_REG
-#define HAVE_IDT8A340_REG
-
-#define PAGE_ADDR_BASE0x
-#define PAGE_ADDR 0x00fc
-
-#define HW_REVISION   0x8180
-#define REV_ID0x007a
-
-#define HW_DPLL_0 (0x8a00)
-#define HW_DPLL_1 (0x8b00)
-#define HW_DPLL_2 (0x8c00)
-#define HW_DPLL_3 (0x8d00)
-#define HW_DPLL_4 (0x8e00)
-#define HW_DPLL_5 (0x8f00)
-#define HW_DPLL_6 (0x9000)
-#define HW_DPLL_7 (0x9100)
-
-#define HW_DPLL_TOD_SW_TRIG_ADDR__0   (0x080)
-#define HW_DPLL_TOD_CTRL_1(0x089)
-#define HW_DPLL_TOD_CTRL_2(0x08A)
-#define HW_DPLL_TOD_OVR__0(0x098)
-#define HW_DPLL_TOD_OUT_0__0  (0x0B0)
-
-#define HW_Q0_Q1_CH_SYNC_CTRL_0   (0xa740)
-#define HW_Q0_Q1_CH_SYNC_CTRL_1   (0xa741)
-#define HW_Q2_Q3_CH_SYNC_CTRL_0   (0xa742)
-#define HW_Q2_Q3_CH_SYNC_CTRL_1   (0xa743)
-#define HW_Q4_Q5_CH_SYNC_CTRL_0   (0xa744)
-#define HW_Q4_Q5_CH_SYNC_CTRL_1   (0xa745)
-#define HW_Q6_Q7_CH_SYNC_CTRL_0   (0xa746)
-#define HW_Q6_Q7_CH_SYNC_CTRL_1   (0xa747)
-#define HW_Q8_CH_SYNC_CTRL_0  (0xa748)
-#define HW_Q8_CH_SYNC_CTRL_1  (0xa749)
-#define HW_Q9_CH_SYNC_CTRL_0  (0xa74a)
-#define HW_Q9_CH_SYNC_CTRL_1  (0xa74b)
-#define HW_Q10_CH_SYNC_CTRL_0 (0xa74c)
-#define HW_Q10_CH_SYNC_CTRL_1 (0xa74d)
-#define HW_Q11_CH_SYNC_CTRL_0 (0xa74e)
-#define HW_Q11_CH_SYNC_CTRL_1 (0xa74f)
-
-#define SYNC_SOURCE_DPLL0_TOD_PPS  0x14
-#define SYNC_SOURCE_DPLL1_TOD_PPS  0x15
-#define SYNC_SOURCE_DPLL2_TOD_PPS  0x16
-#define SYNC_SOURCE_DPLL3_TOD_PPS  0x17
-
-#define SYNCTRL1_MASTER_SYNC_RST   BIT(7)
-#define SYNCTRL1_MASTER_SYNC_TRIG  BIT(5)
-#define SYNCTRL1_TOD_SYNC_TRIG BIT(4)
-#define SYNCTRL1_FBDIV_FRAME_SYNC_TRIG BIT(3)
-#define SYNCTRL1_FBDIV_SYNC_TRIG   BIT(2)
-#define SYNCTRL1_Q1_DIV_SYNC_TRIG  BIT(1)
-#define SYNCTRL1_Q0_DIV_SYNC_TRIG  BIT(0)
-
-#define HW_Q8_CTRL_SPARE  (0xa7d4)
-#define HW_Q11_CTRL_SPARE (0xa7ec)
-
-/**
- * Select FOD5 as sync_trigger for Q8 divider.
- * Transition from logic zero to one
- * sets trigger to sync Q8 divider.
- *
- * Unused when FOD4 is driving Q8 divider (normal operation).
- */
-#define Q9_TO_Q8_SYNC_TRIG  BIT(1)
-
-/**
- * Enable FOD5 as driver for clock and sync for Q8 divider.
- * Enable fanout buffer for FOD5.
- *
- * Unused when FOD4 is driving Q8 divider (normal operation).
- */
-#define Q9_TO_Q8_FANOUT_AND_CLOCK_SYNC_ENABLE_MASK  (BIT(0) | BIT(2))
-
-/**
- * Select FOD6 as sync_trigger for Q11 divider.
- * Transition from logic zero to one
- * sets trigger to sync Q11 divider.
- *
- * Unused when FOD7 is driving Q11 divider (normal operation).
- */
-#define Q10_TO_Q11_SYNC_TRIG  BIT(1)
-
-/**
- * Enable FOD6 as driver for clock and sync for Q11 divider.
- * Enable fanout buffer for FOD6.
- *
- * Unused when FOD7 is driving Q11 divider (normal operation).
- */
-#define Q10_TO_Q11_FANOUT_AND_CLOCK_SYNC_ENABLE_MASK  (BIT(0) | BIT(2))
-
-#define RESET_CTRL0xc000
-#define SM_RESET  0x0012
-#define SM_RESET_V520 0x0013
-#define SM_RESET_CMD  0x5A
-
-#define GENERAL_STATUS0xc014
-#define BOOT_STATUS   0x
-#define HW_REV_ID 0x000A
-#define BOND_ID   0x000B

[linux-yocto] [PATCH 3/5] ptp: ptp_clockmatrix: Add support for FW 5.2 (8A34005)

2022-11-07 Thread Ruiqiang Hao
From: Min Li 

Backport of 794c3dffacc166f7a8f7a555ff7e75fcdb644a51 from linux-stable.

So far we don't need to support new 5.2 functions but different register
addresses

Signed-off-by: Min Li 
Signed-off-by: David S. Miller 
Signed-off-by: Beniamin Sandu 
Signed-off-by: Ruiqiang Hao 
---
 drivers/ptp/idt8a340_reg.h|  61 +++-
 drivers/ptp/ptp_clockmatrix.c | 175 ++
 drivers/ptp/ptp_clockmatrix.h |  17 +++-
 3 files changed, 163 insertions(+), 90 deletions(-)

diff --git a/drivers/ptp/idt8a340_reg.h b/drivers/ptp/idt8a340_reg.h
index ac524cf0f31f..dea8e1d6edaa 100644
--- a/drivers/ptp/idt8a340_reg.h
+++ b/drivers/ptp/idt8a340_reg.h
@@ -5,7 +5,7 @@
  * https://github.com/richardcochran/regen
  *
  * Hand modified to include some HW registers.
- * Based on 4.8.0, SCSR rev C commit a03c7ae5
+ * Based on 5.2.0, Family Programming Guide (Sept 30, 2020)
  */
 #ifndef HAVE_IDT8A340_REG
 #define HAVE_IDT8A340_REG
@@ -100,6 +100,7 @@
 
 #define RESET_CTRL0xc000
 #define SM_RESET  0x0012
+#define SM_RESET_V520 0x0013
 #define SM_RESET_CMD  0x5A
 
 #define GENERAL_STATUS0xc014
@@ -130,6 +131,8 @@
 #define GPIO_USER_CONTROL 0xc160
 #define GPIO0_TO_7_OUT0x
 #define GPIO8_TO_15_OUT   0x0001
+#define GPIO0_TO_7_OUT_V520   0x0002
+#define GPIO8_TO_15_OUT_V520  0x0003
 
 #define STICKY_STATUS_CLEAR   0xc164
 
@@ -216,22 +219,27 @@
 #define DPLL_REF_MODE 0x0035
 #define DPLL_PHASE_MEASUREMENT_CFG0x0036
 #define DPLL_MODE 0x0037
+#define DPLL_MODE_V5200x003B
 
 #define DPLL_10xc400
 
 #define DPLL_20xc438
+#define DPLL_2_V520   0xc43c
 
 #define DPLL_30xc480
 
 #define DPLL_40xc4b8
+#define DPLL_4_V520   0xc4bc
 
 #define DPLL_50xc500
 
 #define DPLL_60xc538
+#define DPLL_6_V520   0xc53c
 
 #define DPLL_70xc580
 
 #define SYS_DPLL  0xc5b8
+#define SYS_DPLL_V520 0xc5bc
 
 #define DPLL_CTRL_0   0xc600
 #define DPLL_CTRL_DPLL_MANU_REF_CFG   0x0001
@@ -331,6 +339,7 @@
 #define GPIO_ALERT_OUT_CFG0x000e
 #define GPIO_TOD_NOTIFICATION_CFG 0x000f
 #define GPIO_CTRL 0x0010
+#define GPIO_CTRL_V5200x0011
 
 #define GPIO_10xc8d4
 
@@ -365,6 +374,7 @@
 #define OUT_DIV_MUX   0xca12
 
 #define OUTPUT_0  0xca14
+#define OUTPUT_0_V520 0xca20
 /* FOD frequency output divider value */
 #define OUT_DIV   0x
 #define OUT_DUTY_CYCLE_HIGH   0x0004
@@ -374,28 +384,40 @@
 #define OUT_PHASE_ADJ 0x000c
 
 #define OUTPUT_1  0xca24
+#define OUTPUT_1_V520 0xca30
 
 #define OUTPUT_2  0xca34
+#define OUTPUT_2_V520 0xca40
 
 #define OUTPUT_3  0xca44
+#define OUTPUT_3_V520 0xca50
 
 #define OUTPUT_4  0xca54
+#define OUTPUT_4_V520 0xca60
 
 #define OUTPUT_5  0xca64
+#define OUTPUT_5_V520 0xca80
 
 #define OUTPUT_6  0xca80
+#define OUTPUT_6_V520 0xca90
 
 #define OUTPUT_7  0xca90
+#define OUTPUT_7_V520 0xcaa0
 
 #define OUTPUT_8  0xcaa0
+#define OUTPUT_8_V520 0xcab0
 
 #define OUTPUT_9  0xcab0
+#define OUTPUT_9_V520 0xcac0
 
 #define OUTPUT_10 0xcac0
+#define OUTPUT_10_V520 0xcad0
 
 #define OUTPUT_11 0xcad0
+#define OUTPUT_11_V5200xcae0
 
 #define SERIAL0xcae0
+#define SERIAL_V520   0xcaf0
 
 #define PWM_ENCODER_0 0xcb00
 
@@ -416,50 +438,72 @@
 #define PWM_DECODER_0 0xcb40
 
 #define PWM_DECODER_1 0xcb48
+#define PWM_DECODER_1_V5200xcb4a
 
 #define PWM_DECODER_2 0xcb50
+#define PWM_DECODER_2_V5200xcb54
 
 #define PWM_DECODER_3 0xcb58
+#define PWM_DECODER_3_V5200xcb5e
 
 #define PWM_DECODER_4 0xcb60
+#define PWM_DECODER_4_V5200xcb68
 
 #define PWM_DECODER_5 0xcb68
+#define PWM_DECODER_5_V520  

[linux-yocto] [PATCH 4/5] ptp: ptp_clockmatrix: Add support for pll_mode=0 and manual ref switch of WF and WP

2022-11-07 Thread Ruiqiang Hao
From: Min Li 

Backport of da9facf1c1825201956c2553e06d455dea3e0313 from linux-stable.

Also correct how initialize_dco_operating_mode is called

Signed-off-by: Min Li 
Signed-off-by: David S. Miller 
Signed-off-by: Beniamin Sandu 
Signed-off-by: Ruiqiang Hao 
---
 drivers/ptp/idt8a340_reg.h|   4 +
 drivers/ptp/ptp_clockmatrix.c | 368 ++
 drivers/ptp/ptp_clockmatrix.h |  47 -
 3 files changed, 375 insertions(+), 44 deletions(-)

diff --git a/drivers/ptp/idt8a340_reg.h b/drivers/ptp/idt8a340_reg.h
index dea8e1d6edaa..1c5210187110 100644
--- a/drivers/ptp/idt8a340_reg.h
+++ b/drivers/ptp/idt8a340_reg.h
@@ -635,6 +635,10 @@
 #define STATE_MODE_SHIFT  (0)
 #define STATE_MODE_MASK   (0x7)
 
+/* Bit definitions for the DPLL_MANU_REF_CFG register */
+#define MANUAL_REFERENCE_SHIFT(0)
+#define MANUAL_REFERENCE_MASK (0x1f)
+
 /* Bit definitions for the GPIO_CFG_GBL register */
 #define SUPPLY_MODE_SHIFT (0)
 #define SUPPLY_MODE_MASK  (0x3)
diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index 72ef47972bcd..9eb6302a210c 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c
@@ -33,6 +33,8 @@ module_param(firmware, charp, 0);
 
 #define SETTIME_CORRECTION (0)
 
+static int _idtcm_adjfine(struct idtcm_channel *channel, long scaled_ppm);
+
 static int contains_full_configuration(struct idtcm *idtcm,
   const struct firmware *fw)
 {
@@ -657,8 +659,8 @@ static int idtcm_sync_pps_output(struct idtcm_channel 
*channel)
 }
 
 static int _idtcm_set_dpll_hw_tod(struct idtcm_channel *channel,
-  struct timespec64 const *ts,
-  enum hw_tod_write_trig_sel wr_trig)
+   struct timespec64 const *ts,
+   enum hw_tod_write_trig_sel wr_trig)
 {
struct idtcm *idtcm = channel->idtcm;
u8 buf[TOD_BYTE_COUNT];
@@ -920,9 +922,9 @@ static int idtcm_start_phase_pull_in(struct idtcm_channel 
*channel)
return err;
 }
 
-static int idtcm_do_phase_pull_in(struct idtcm_channel *channel,
- s32 offset_ns,
- u32 max_ffo_ppb)
+static int do_phase_pull_in_fw(struct idtcm_channel *channel,
+  s32 offset_ns,
+  u32 max_ffo_ppb)
 {
int err;
 
@@ -991,7 +993,7 @@ static int _idtcm_adjtime_deprecated(struct idtcm_channel 
*channel, s64 delta)
s64 now;
 
if (abs(delta) < PHASE_PULL_IN_THRESHOLD_NS_DEPRECATED) {
-   err = idtcm_do_phase_pull_in(channel, delta, 0);
+   err = channel->do_phase_pull_in(channel, delta, 0);
} else {
idtcm->calculate_overhead_flag = 1;
 
@@ -1220,7 +1222,7 @@ static int idtcm_load_firmware(struct idtcm *idtcm,
if (firmware) /* module parameter */
snprintf(fname, sizeof(fname), "%s", firmware);
 
-   dev_dbg(>client->dev, "requesting firmware '%s'", fname);
+   dev_info(>client->dev, "firmware '%s'", fname);
 
err = request_firmware(, fname, dev);
if (err) {
@@ -1354,7 +1356,7 @@ static int idtcm_perout_enable(struct idtcm_channel 
*channel,
 }
 
 static int idtcm_get_pll_mode(struct idtcm_channel *channel,
- enum pll_mode *pll_mode)
+ enum pll_mode *mode)
 {
struct idtcm *idtcm = channel->idtcm;
int err;
@@ -1366,13 +1368,13 @@ static int idtcm_get_pll_mode(struct idtcm_channel 
*channel,
if (err)
return err;
 
-   *pll_mode = (dpll_mode >> PLL_MODE_SHIFT) & PLL_MODE_MASK;
+   *mode = (dpll_mode >> PLL_MODE_SHIFT) & PLL_MODE_MASK;
 
return 0;
 }
 
 static int idtcm_set_pll_mode(struct idtcm_channel *channel,
- enum pll_mode pll_mode)
+ enum pll_mode mode)
 {
struct idtcm *idtcm = channel->idtcm;
int err;
@@ -1386,24 +1388,299 @@ static int idtcm_set_pll_mode(struct idtcm_channel 
*channel,
 
dpll_mode &= ~(PLL_MODE_MASK << PLL_MODE_SHIFT);
 
-   dpll_mode |= (pll_mode << PLL_MODE_SHIFT);
-
-   channel->pll_mode = pll_mode;
+   dpll_mode |= (mode << PLL_MODE_SHIFT);
 
err = idtcm_write(idtcm, channel->dpll_n,
  IDTCM_FW_REG(idtcm->fw_ver, V520, DPLL_MODE),
  _mode, sizeof(dpll_mode));
+   return err;
+}
+
+static int idtcm_get_manual_reference(struct idtcm_channel *channel,
+ enum manual_reference *ref)
+{
+   struct idtcm *idtcm = channel->idtcm;
+   u8 dpll_manu_ref_cfg;
+   int err;
+
+   err = idtcm_read(idtcm, channel->dpll_ctrl_n,
+DPLL_CTRL_DPLL_MANU_REF_CFG,
+_manu_ref_cfg, 

[linux-yocto][linux-yocto v5.15] kernel code for marvell octeon

2022-11-07 Thread Ruiqiang Hao
Hi Bruce,

Please help to merge these 5 patches into our linux-yocto repo.

repo:
linux-yocto
branch:
v5.15/standard/cn-sdkv5.4/octeon
v5.15/standard/preempt-rt/cn-sdkv5.4/octeon

Thanks,
Ruiqiang

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11851): 
https://lists.yoctoproject.org/g/linux-yocto/message/11851
Mute This Topic: https://lists.yoctoproject.org/mt/94862182/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 2/5] ptp: ptp_clockmatrix: Remove idtcm_enable_tod_sync()

2022-11-07 Thread Ruiqiang Hao
From: Min Li 

Backport of c70aae139d3940a0ae0922ed52384e14f092a963 from linux-stable.

Not need since TCS firmware file will configure it properlly.

Signed-off-by: Min Li 
Signed-off-by: David S. Miller 
Signed-off-by: Beniamin Sandu 
Signed-off-by: Ruiqiang Hao 
---
 drivers/ptp/ptp_clockmatrix.c | 229 +-
 1 file changed, 2 insertions(+), 227 deletions(-)

diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index fa636951169e..9b1c6b2c221c 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c
@@ -353,8 +353,8 @@ static int wait_for_sys_apll_dpll_lock(struct idtcm *idtcm)
apll &= SYS_APLL_LOSS_LOCK_LIVE_MASK;
dpll &= DPLL_SYS_STATE_MASK;
 
-   if (apll == SYS_APLL_LOSS_LOCK_LIVE_LOCKED &&
-   dpll == DPLL_STATE_LOCKED) {
+   if (apll == SYS_APLL_LOSS_LOCK_LIVE_LOCKED
+   && dpll == DPLL_STATE_LOCKED) {
return 0;
} else if (dpll == DPLL_STATE_FREERUN ||
   dpll == DPLL_STATE_HOLDOVER ||
@@ -1675,222 +1675,6 @@ static int idtcm_enable(struct ptp_clock_info *ptp,
return -EOPNOTSUPP;
 }
 
-static int _enable_pll_tod_sync(struct idtcm *idtcm,
-   u8 pll,
-   u8 sync_src,
-   u8 qn,
-   u8 qn_plus_1)
-{
-   int err;
-   u8 val;
-   u16 dpll;
-   u16 out0 = 0, out1 = 0;
-
-   if (qn == 0 && qn_plus_1 == 0)
-   return 0;
-
-   switch (pll) {
-   case 0:
-   dpll = DPLL_0;
-   if (qn)
-   out0 = OUTPUT_0;
-   if (qn_plus_1)
-   out1 = OUTPUT_1;
-   break;
-   case 1:
-   dpll = DPLL_1;
-   if (qn)
-   out0 = OUTPUT_2;
-   if (qn_plus_1)
-   out1 = OUTPUT_3;
-   break;
-   case 2:
-   dpll = DPLL_2;
-   if (qn)
-   out0 = OUTPUT_4;
-   if (qn_plus_1)
-   out1 = OUTPUT_5;
-   break;
-   case 3:
-   dpll = DPLL_3;
-   if (qn)
-   out0 = OUTPUT_6;
-   if (qn_plus_1)
-   out1 = OUTPUT_7;
-   break;
-   case 4:
-   dpll = DPLL_4;
-   if (qn)
-   out0 = OUTPUT_8;
-   break;
-   case 5:
-   dpll = DPLL_5;
-   if (qn)
-   out0 = OUTPUT_9;
-   if (qn_plus_1)
-   out1 = OUTPUT_8;
-   break;
-   case 6:
-   dpll = DPLL_6;
-   if (qn)
-   out0 = OUTPUT_10;
-   if (qn_plus_1)
-   out1 = OUTPUT_11;
-   break;
-   case 7:
-   dpll = DPLL_7;
-   if (qn)
-   out0 = OUTPUT_11;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   /*
-* Enable OUTPUT OUT_SYNC.
-*/
-   if (out0) {
-   err = idtcm_read(idtcm, out0, OUT_CTRL_1, , sizeof(val));
-   if (err)
-   return err;
-
-   val &= ~OUT_SYNC_DISABLE;
-
-   err = idtcm_write(idtcm, out0, OUT_CTRL_1, , sizeof(val));
-   if (err)
-   return err;
-   }
-
-   if (out1) {
-   err = idtcm_read(idtcm, out1, OUT_CTRL_1, , sizeof(val));
-   if (err)
-   return err;
-
-   val &= ~OUT_SYNC_DISABLE;
-
-   err = idtcm_write(idtcm, out1, OUT_CTRL_1, , sizeof(val));
-   if (err)
-   return err;
-   }
-
-   /* enable dpll sync tod pps, must be set before dpll_mode */
-   err = idtcm_read(idtcm, dpll, DPLL_TOD_SYNC_CFG, , sizeof(val));
-   if (err)
-   return err;
-
-   val &= ~(TOD_SYNC_SOURCE_MASK << TOD_SYNC_SOURCE_SHIFT);
-   val |= (sync_src << TOD_SYNC_SOURCE_SHIFT);
-   val |= TOD_SYNC_EN;
-
-   return idtcm_write(idtcm, dpll, DPLL_TOD_SYNC_CFG, , sizeof(val));
-}
-
-static int idtcm_enable_tod_sync(struct idtcm_channel *channel)
-{
-   struct idtcm *idtcm = channel->idtcm;
-   u8 pll;
-   u8 sync_src;
-   u8 qn;
-   u8 qn_plus_1;
-   u8 cfg;
-   int err = 0;
-   u16 output_mask = channel->output_mask;
-   u8 out8_mux = 0;
-   u8 out11_mux = 0;
-   u8 temp;
-
-   /*
-* set tod_out_sync_enable to 0.
-*/
-   err = idtcm_read(idtcm, channel->tod_n, TOD_CFG, , sizeof(cfg));
-   if (err)
-   return err;
-
-   cfg &= ~TOD_OUT_SYNC_ENABLE;
-
-   err = idtcm_write(idtcm, 

[linux-yocto] [PATCH 1/5] fix Renesas SMU cdev drivers to use the updated MFD interfaces

2022-11-07 Thread Ruiqiang Hao
From: Beniamin Sandu 

Signed-off-by: Beniamin Sandu 
Signed-off-by: Ruiqiang Hao 
---
 drivers/misc/rsmu_cdev.c  | 185 +-
 drivers/misc/rsmu_cdev.h  |  17 ++--
 drivers/misc/rsmu_cm.c|  14 ++-
 drivers/misc/rsmu_sabre.c |   8 +-
 4 files changed, 62 insertions(+), 162 deletions(-)

diff --git a/drivers/misc/rsmu_cdev.c b/drivers/misc/rsmu_cdev.c
index c44fcebe3abb..0b1a15bb8d45 100644
--- a/drivers/misc/rsmu_cdev.c
+++ b/drivers/misc/rsmu_cdev.c
@@ -27,14 +27,13 @@
 
 #include "rsmu_cdev.h"
 
-#define DRIVER_NAME"rsmu"
-#define DRIVER_MAX_DEV BIT(MINORBITS)
+#define DRIVER_NAME"rsmu-cdev"
+
+static DEFINE_IDA(rsmu_cdev_map);
 
-static struct class *rsmu_class;
-static dev_t rsmu_cdevt;
 static struct rsmu_ops *ops_array[] = {
-   [RSMU_CM] = _ops,
-   [RSMU_SABRE] = _ops,
+   [0] = _ops,
+   [1] = _ops,
 };
 
 static int
@@ -115,11 +114,8 @@ rsmu_reg_read(struct rsmu_cdev *rsmu, void __user *arg)
return -EFAULT;
 
mutex_lock(rsmu->lock);
-   //err = regmap_bulk_read(rsmu->regmap, data.offset, [0], 
data.byte_count);
-   err = rsmu_read(rsmu->mfd, data.offset, [0], 
data.byte_count);
+   err = regmap_bulk_read(rsmu->regmap, data.offset, [0], 
data.byte_count);
mutex_unlock(rsmu->lock);
-if (err)
-   return err;
 
if (copy_to_user(arg, , sizeof(data)))
return -EFAULT;
@@ -136,55 +132,25 @@ rsmu_reg_write(struct rsmu_cdev *rsmu, void __user *arg)
if (copy_from_user(, arg, sizeof(data)))
return -EFAULT;
 
-mutex_lock(rsmu->lock);
-//err = regmap_bulk_write(rsmu->regmap, data.offset, [0], 
data.byte_count);
-err = rsmu_write(rsmu->mfd, data.offset, [0], data.byte_count);
+   mutex_lock(rsmu->lock);
+   err = regmap_bulk_write(rsmu->regmap, data.offset, [0], 
data.byte_count);
mutex_unlock(rsmu->lock);
 
-   if (copy_to_user(arg, , sizeof(data)))
-   return -EFAULT;
-
return err;
 }
 
-
-static int
-rsmu_open(struct inode *iptr, struct file *fptr)
-{
-   struct rsmu_cdev *rsmu;
-
-   rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
-   if (!rsmu)
-   return -EAGAIN;
-
-   fptr->private_data = rsmu;
-   return 0;
-}
-
-static int
-rsmu_release(struct inode *iptr, struct file *fptr)
+static struct rsmu_cdev *file2rsmu(struct file *file)
 {
-   struct rsmu_cdev *rsmu;
-
-   rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
-   if (!rsmu)
-   return -EAGAIN;
-
-   return 0;
+   return container_of(file->private_data, struct rsmu_cdev, miscdev);
 }
 
-
-
 static long
 rsmu_ioctl(struct file *fptr, unsigned int cmd, unsigned long data)
 {
-   struct rsmu_cdev *rsmu = fptr->private_data;
+   struct rsmu_cdev *rsmu = file2rsmu(fptr);
void __user *arg = (void __user *)data;
int err = 0;
 
-   if (!rsmu)
-   return -EINVAL;
-
switch (cmd) {
case RSMU_SET_COMBOMODE:
err = rsmu_set_combomode(rsmu, arg);
@@ -203,7 +169,6 @@ rsmu_ioctl(struct file *fptr, unsigned int cmd, unsigned 
long data)
break;
default:
/* Should not get here */
-pr_err("%lu %u",  RSMU_REG_READ, cmd);
dev_err(rsmu->dev, "Undefined RSMU IOCTL");
err = -EINVAL;
break;
@@ -220,8 +185,6 @@ static long rsmu_compat_ioctl(struct file *fptr, unsigned 
int cmd,
 
 static const struct file_operations rsmu_fops = {
.owner = THIS_MODULE,
-   .open = rsmu_open,
-   .release = rsmu_release,
.unlocked_ioctl = rsmu_ioctl,
.compat_ioctl = rsmu_compat_ioctl,
 };
@@ -244,90 +207,65 @@ static int rsmu_init_ops(struct rsmu_cdev *rsmu)
 static int
 rsmu_probe(struct platform_device *pdev)
 {
-   struct rsmu_pdata *pdata = dev_get_platdata(>dev);
+   struct rsmu_ddata *ddata = dev_get_drvdata(pdev->dev.parent);
struct rsmu_cdev *rsmu;
-   struct device *rsmu_cdev;
int err;
 
rsmu = devm_kzalloc(>dev, sizeof(*rsmu), GFP_KERNEL);
if (!rsmu)
return -ENOMEM;
 
-   rsmu->dev = >dev;
-   rsmu->mfd = pdev->dev.parent;
-   rsmu->type = pdata->type;
-   rsmu->lock = pdata->lock;
-   rsmu->index = pdata->index;
-
/* Save driver private data */
platform_set_drvdata(pdev, rsmu);
 
-   cdev_init(>rsmu_cdev, _fops);
-   rsmu->rsmu_cdev.owner = THIS_MODULE;
-   err = cdev_add(>rsmu_cdev,
-  MKDEV(MAJOR(rsmu_cdevt), 0), 1);
-   if (err < 0) {
-   dev_err(rsmu->dev, "cdev_add failed");
-   err = -EIO;
-   goto err_rsmu_dev;
-   }
-
-   if (!rsmu_class) {
-   err = -EIO;
-   dev_err(rsmu->dev, "rsmu class not created correctly");
-   goto err_rsmu_cdev;
+   rsmu->dev = 

Re: [yocto] undefined reference problem persists

2022-11-07 Thread Alexander Kanavin
On Mon, 7 Nov 2022 at 03:19, Ron Eggler  wrote:
> > On Sun, 6 Nov 2022 at 18:36, Mistyron  wrote:
> >> I'll attempt to "just drop" meta-gplv2, then. However I see that there are 
> >> other dependencies on readline too, i.e. it might be easier to just 
> >> replace the existing 5.2 version in meta-gplv2 with 8.2 from here: 
> >> https://git.yoctoproject.org/poky/plain/meta/recipes-core/readline/
> > No. You cannot 'just replace' it, as they are under different
> > licenses, and meta-gplv2 specifically collects versions under gpl
> > version 2 only.
> https://www.gnu.org/licenses/rms-why-gplv3.en.html specifies:
>
> "When we say that GPLv2 and GPLv3 are incompatible, it means there is no
> legal way to combine code under GPLv2 with code under GPLv3 in a single
> program." - What is a single program though? Readline would still be a
> single program within the bitbake build, would it not? I'm not
> "stealing" nor editing its code but compile it as is.

Combining gpl2 and gpl3 is not an issue here. The issue is that if you
ship gpl3 items to users as a part of some product, you have an
obligation to allow them to change those items and install the changes
on the product. This is why meta-gplv2 was created: it effectively
reverts everything that is nowadays gpl3 licensed to older versions
which are still under gpl2.

Single program is commonly interpreted as a runtime process with its
own virtual address space. E.g. all linked libraries, even 3rd party
ones, are a part of the single program.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58510): https://lists.yoctoproject.org/g/yocto/message/58510
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] undefined reference problem persists

2022-11-07 Thread Alexander Kanavin
On Mon, 7 Nov 2022 at 02:35, Ron Eggler  wrote:
> > Are you going to ship what you're working on to other users, or is it
> > just experimentation?
> The intent is, that's it's going to be shipped (but with full access to
> the sources)

If you're shipping anything that is under gplv3 you also need to give
the recipient users a possibility to change the item under gplv3 from
the source code you have used to build it and install their modified
version to replace yours.

Are you able to fulfil that obligation you have under the license?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58509): https://lists.yoctoproject.org/g/yocto/message/58509
Mute This Topic: https://lists.yoctoproject.org/mt/94840876/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-