[linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC

2019-10-22 Thread quanyang.wang 
From: Quanyang Wang 

The function xilinx_dpdma_chan_alloc_tx_desc can be called
from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL,
or else it will cause the calltrace as below:

BUG: sleeping function called from invalid context at mm/slab.h:418
in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null 
Preemption disabled at:
[] snd_pcm_stream_lock_irq+0x40/0x50
CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto-standard #1
Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace:
dump_backtrace+0x0/0x138
show_stack+0x24/0x30
dump_stack+0x94/0xbc
___might_sleep+0x14c/0x178
__might_sleep+0x58/0x90
kmem_cache_alloc_trace+0x1a4/0x300
xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40
xilinx_dpdma_prep_dma_cyclic+0xc0/0x208
snd_dmaengine_pcm_trigger+0xf8/0x198
soc_pcm_trigger+0xb4/0x128
snd_pcm_do_start+0x48/0x58
snd_pcm_action_single+0x4c/0xa0
snd_pcm_action+0x78/0x90
snd_pcm_action_lock_irq+0x3c/0x60
snd_pcm_common_ioctl+0x4ac/0x10c8
snd_pcm_ioctl+0x48/0x68
do_vfs_ioctl+0x6d4/0x968
ksys_ioctl+0x84/0xb8
__arm64_sys_ioctl+0x28/0x38
el0_svc_common.constprop.0+0x74/0x180
el0_svc_handler+0x70/0x90
el0_svc+0x8/0xc

Signed-off-by: Quanyang Wang 
Reviewed-by: Hyun Kwon 
---
There are two available flags which can be used here: GFP_ATOMIC
and GFP_NOWAIT. The difference is that GFP_ATOMIC may grab memory
from emergency pools but GFP_NOWAIT not. Since struct xilinx_dpdma_tx_desc
is small, use GFP_ATOMIC is better.

 drivers/dma/xilinx/xilinx_dpdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c 
b/drivers/dma/xilinx/xilinx_dpdma.c
index 1ea509e00742..89ade893f51c 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -797,7 +797,7 @@ xilinx_dpdma_chan_alloc_tx_desc(struct xilinx_dpdma_chan 
*chan)
 {
struct xilinx_dpdma_tx_desc *tx_desc;
 
-   tx_desc = kzalloc(sizeof(*tx_desc), GFP_KERNEL);
+   tx_desc = kzalloc(sizeof(*tx_desc), GFP_ATOMIC);
if (!tx_desc)
return NULL;
 
-- 
2.17.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1] [V2] xilinx-zynqmp: fix calltrace

2019-10-22 Thread quanyang.wang 
From: Quanyang Wang 

Hi Bruce,

This patch is a V2 patch but no change against V1. Just add some comments
in the temporary section of the patch.

Would you please help merge these patches to linux-yocto v5.2/standard/xlnx-soc 
branch?

Quanyang Wang (1):
  dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC

 drivers/dma/xilinx/xilinx_dpdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.17.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Bruce Ashfield 
This should already be on the branches:

Author: Takeshi Kihara 
Date:   Tue Oct 15 13:46:44 2019 +0800

arm64: dts: r8a7795: Add CPUIdle support for all CPU core

commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git

This patch enables CPUIdle (Core shutdown) support for R-Car H3.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Meng Li 
Signed-off-by: Bruce Ashfield 

:100644 100644 097538cc4b1f 7596216409cd M
arch/arm64/boot/dts/renesas/r8a7795.dtsi

On Tue, Oct 22, 2019 at 10:47 PM  wrote:
>
> From: Takeshi Kihara 
>
> commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>
> This patch enables CPUIdle (Core shutdown) support for R-Car H3.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Meng Li 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 
> 
>  1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index e8c3d5f..7fe7428 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -123,6 +123,7 @@
> power-domains = < R8A7795_PD_CA57_CPU0>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -135,6 +136,7 @@
> power-domains = < R8A7795_PD_CA57_CPU1>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -147,6 +149,7 @@
> power-domains = < R8A7795_PD_CA57_CPU2>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -159,6 +162,7 @@
> power-domains = < R8A7795_PD_CA57_CPU3>;
> next-level-cache = <_CA57>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_0>;
> clocks = < CPG_CORE R8A7795_CLK_Z>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <1024>;
> @@ -171,6 +175,7 @@
> power-domains = < R8A7795_PD_CA53_CPU0>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -182,6 +187,7 @@
> power-domains = < R8A7795_PD_CA53_CPU1>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -193,6 +199,7 @@
> power-domains = < R8A7795_PD_CA53_CPU2>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -204,6 +211,7 @@
> power-domains = < R8A7795_PD_CA53_CPU3>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> +   cpu-idle-states = <_SLEEP_1>;
> clocks = < CPG_CORE R8A7795_CLK_Z2>;
> operating-points-v2 = <_opp>;
> capacity-dmips-mhz = <535>;
> @@ -221,6 +229,30 @@
> cache-unified;
> cache-level = <2>;
> };
> +
> +   idle-states {
> +   entry-method = "psci";
> +
> +   CPU_SLEEP_0: cpu-sleep-0 {
> +   compatible = "arm,idle-state";
> +

Re: [linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Bruce Ashfield 
On Tue, Oct 22, 2019 at 10:57 PM Bruce Ashfield
 wrote:
>
> This should already be on the branches:
>

.. and I forgot the commit id:

c93bf81feabf89b5ee77838d3bb62825d04dab09

Bruce

> Author: Takeshi Kihara 
> Date:   Tue Oct 15 13:46:44 2019 +0800
>
> arm64: dts: r8a7795: Add CPUIdle support for all CPU core
>
> commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>
> This patch enables CPUIdle (Core shutdown) support for R-Car H3.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Meng Li 
> Signed-off-by: Bruce Ashfield 
>
> :100644 100644 097538cc4b1f 7596216409cd M
> arch/arm64/boot/dts/renesas/r8a7795.dtsi
>
> On Tue, Oct 22, 2019 at 10:47 PM  wrote:
> >
> > From: Takeshi Kihara 
> >
> > commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
> >
> > This patch enables CPUIdle (Core shutdown) support for R-Car H3.
> >
> > Signed-off-by: Takeshi Kihara 
> > Signed-off-by: Meng Li 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 
> > 
> >  1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > index e8c3d5f..7fe7428 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > @@ -123,6 +123,7 @@
> > power-domains = < R8A7795_PD_CA57_CPU0>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_0>;
> > clocks = < CPG_CORE R8A7795_CLK_Z>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <1024>;
> > @@ -135,6 +136,7 @@
> > power-domains = < R8A7795_PD_CA57_CPU1>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_0>;
> > clocks = < CPG_CORE R8A7795_CLK_Z>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <1024>;
> > @@ -147,6 +149,7 @@
> > power-domains = < R8A7795_PD_CA57_CPU2>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_0>;
> > clocks = < CPG_CORE R8A7795_CLK_Z>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <1024>;
> > @@ -159,6 +162,7 @@
> > power-domains = < R8A7795_PD_CA57_CPU3>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_0>;
> > clocks = < CPG_CORE R8A7795_CLK_Z>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <1024>;
> > @@ -171,6 +175,7 @@
> > power-domains = < R8A7795_PD_CA53_CPU0>;
> > next-level-cache = <_CA53>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_1>;
> > clocks = < CPG_CORE R8A7795_CLK_Z2>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <535>;
> > @@ -182,6 +187,7 @@
> > power-domains = < R8A7795_PD_CA53_CPU1>;
> > next-level-cache = <_CA53>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_1>;
> > clocks = < CPG_CORE R8A7795_CLK_Z2>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <535>;
> > @@ -193,6 +199,7 @@
> > power-domains = < R8A7795_PD_CA53_CPU2>;
> > next-level-cache = <_CA53>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_1>;
> > clocks = < CPG_CORE R8A7795_CLK_Z2>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <535>;
> > @@ -204,6 +211,7 @@
> > power-domains = < R8A7795_PD_CA53_CPU3>;
> > next-level-cache = <_CA53>;
> > enable-method = "psci";
> > +   cpu-idle-states = <_SLEEP_1>;
> > clocks = < CPG_CORE R8A7795_CLK_Z2>;
> > operating-points-v2 = <_opp>;
> > capacity-dmips-mhz = <535>;
> > @@ -221,6 +229,30 @@
> >

Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1] xilinx-zynqmp: fix calltrace

2019-10-22 Thread Bruce Ashfield 
In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/1] 
xilinx-zynqmp: fix calltrace
on 15/10/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce, Michal,
> 
> This patch fixes a calltrace when enable CONFIG_TRACING kernel option.
> 
> Would you please help review and merge these patches to linux-yocto
> v5.2/standard/xlnx-soc branch?

I've dropped this from my pending queue. Can you send a v2 (clearly
marked .. these series are starting to get tangled) with the comments
of this thread summarized in the temporary section of the patch.

That way, I'll know that I'm merging the proper version.

Bruce

> 
> Quanyang Wang (1):
>   dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC
> 
>  drivers/dma/xilinx/xilinx_dpdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [yocto-kernel-cache master/yocto-5.2][PATCH] marvell-cn96xx: Add profiling feature

2019-10-22 Thread Bruce Ashfield 
In message: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] 
marvell-cn96xx: Add profiling feature
on 21/10/2019 zhe...@windriver.com wrote:

> From: He Zhe 
> 
> Add profiling related options for convenience for perf and etc.

merged.

Bruce

> 
> Signed-off-by: He Zhe 
> ---
>  bsp/marvell-cn96xx/marvell-cn96xx.scc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.scc 
> b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> index b98c442f..08d2e721 100644
> --- a/bsp/marvell-cn96xx/marvell-cn96xx.scc
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> @@ -5,3 +5,4 @@ kconf hardware features/edac/edac.cfg
>  include cfg/usb-mass-storage.scc
>  
>  include features/hugetlb/hugetlb.scc
> +include features/profiling/profiling.scc
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH] arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Meng.Li 
From: Takeshi Kihara 

commit 3c3b44c752c4eef9a29694f4262934445c5f5da9 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git

This patch enables CPUIdle (Core shutdown) support for R-Car H3.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Meng Li 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e8c3d5f..7fe7428 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -123,6 +123,7 @@
power-domains = < R8A7795_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -135,6 +136,7 @@
power-domains = < R8A7795_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -147,6 +149,7 @@
power-domains = < R8A7795_PD_CA57_CPU2>;
next-level-cache = <_CA57>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -159,6 +162,7 @@
power-domains = < R8A7795_PD_CA57_CPU3>;
next-level-cache = <_CA57>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0>;
clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <1024>;
@@ -171,6 +175,7 @@
power-domains = < R8A7795_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -182,6 +187,7 @@
power-domains = < R8A7795_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -193,6 +199,7 @@
power-domains = < R8A7795_PD_CA53_CPU2>;
next-level-cache = <_CA53>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -204,6 +211,7 @@
power-domains = < R8A7795_PD_CA53_CPU3>;
next-level-cache = <_CA53>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_1>;
clocks = < CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
capacity-dmips-mhz = <535>;
@@ -221,6 +229,30 @@
cache-unified;
cache-level = <2>;
};
+
+   idle-states {
+   entry-method = "psci";
+
+   CPU_SLEEP_0: cpu-sleep-0 {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   local-timer-stop;
+   entry-latency-us = <400>;
+   exit-latency-us = <500>;
+   min-residency-us = <4000>;
+   status = "okay";
+   };
+
+   CPU_SLEEP_1: cpu-sleep-1 {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   local-timer-stop;
+   entry-latency-us = <700>;
+   exit-latency-us = <700>;
+   min-residency-us = <5000>;
+   status =

[linux-yocto] [linux-yocto-v5.2]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Meng.Li 
From: Limeng 

Hi Bruce,

I get below patch from SDK kernel to support cpu idle feature, and intend to 
merge it into yocto community.

0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch

Could you please merge this patch into linux-yocto, branch is 
v5.2/standard/base?

 r8a7795.dtsi |   32 
 1 file changed, 32 insertions(+)


thanks,
Limeng
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] xilinx-zyqn: Move disable_nonboot_cpus() in front of local_irq_disable()

2019-10-22 Thread Bruce Ashfield 
On Mon, Oct 21, 2019 at 11:27 PM Quanyang Wang
 wrote:
>
>
> On 10/21/19 8:05 PM, Bruce Ashfield wrote:
> > On Mon, Oct 21, 2019 at 6:45 AM Michal Simek  
> > wrote:
> >> On 21. 10. 19 10:45, Quanyang Wang wrote:
> >>> Hi Michal,
> >>>
> >>> On 10/21/19 4:16 PM, Michal Simek wrote:
>  On 21. 10. 19 7:50, quanyang.w...@windriver.com wrote:
> > From: Quanyang Wang 
> >
> > When run kdump with enabling CONFIG_DEBUG_PREEMPT, there is a calltrace
> > as below:
> >
> > BUG: using smp_processor_id() in preemptible [] code: sh/303
> > caller is machine_crash_shutdown+0x2c/0xe8
> > CPU: 0 PID: 303 Comm: sh Kdump: loaded Not tainted
> > 5.2.20-yocto-standard #1
> > Hardware name: Xilinx Zynq Platform
> > [<80112ff4>] (unwind_backtrace) from [<8010ca4c>] (show_stack+0x18/0x1c)
> > [<8010ca4c>] (show_stack) from [<809b000c>] (dump_stack+0x70/0x8c)
> > [<809b000c>] (dump_stack) from [<80549a14>]
> > (debug_smp_processor_id+0xd4/0x118)
> > [<80549a14>] (debug_smp_processor_id) from [<80111428>]
> > (machine_crash_shutdown+0x2c/0xe8)
> > [<80111428>] (machine_crash_shutdown) from [<801afe24>]
> > (__crash_kexec+0x70/0xd0)
> > [<801afe24>] (__crash_kexec) from [<801259b4>] (panic+0x110/0x324)
> > [<801259b4>] (panic) from [<805f7018>] (sysrq_handle_crash+0x18/0x1c)
> > [<805f7018>] (sysrq_handle_crash) from [<805f7584>]
> > (__handle_sysrq+0x9c/0x14c)
> > [<805f7584>] (__handle_sysrq) from [<805f79e8>]
> > (write_sysrq_trigger+0x5c/0x6c)
> > [<805f79e8>] (write_sysrq_trigger) from [<8031e850>]
> > (proc_reg_write+0x78/0x8c)
> > [<8031e850>] (proc_reg_write) from [<802b1b28>] (vfs_write+0xc0/0x154)
> > [<802b1b28>] (vfs_write) from [<802b2a64>] (ksys_write+0x6c/0xd4)
> > [<802b2a64>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54)
> > Exception stack(0xba157fa8 to 0xba157ff0)
> > 7fa0: 0002 005ab930 0001 005ab930 0002 
> > 7fc0: 0002 005ab930 76fa2290 0004 76f3d124 76f3cc8c 
> > 
> > 7fe0: 0004 7edec940 76edbfff 76e67d16
> >
> > This is because that the function disable_nonboot_cpus is called in
> > order to make sure that the crash kernel runs in the boot CPU(cpu0).
> > And it will enable local irq by calling as below:
> >
> > disable_nonboot_cpus
> >-> freeze_secondary_cpus
> > -> _cpu_down
> >  -> percpu_down_write
> >   -> rcu_sync_enter
> >-> spin_unlock_irq(>rss_lock)
> > -> local_irq_enable()
> >
> > Then the functions including smp_processor_id() behind
> > disable_nonboot_cpus
> > will run at the irq-enabled context, and this will trigger the
> > calltrace.
> >
> > So move disable_nonboot_cpus() in front of local_irq_disable() to avoid
> > it since disable_nonboot_cpus() not need run at an atomic context.
> >
> > Signed-off-by: Quanyang Wang 
> > ---
> >arch/arm/kernel/machine_kexec.c | 3 ++-
> >1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/machine_kexec.c
> > b/arch/arm/kernel/machine_kexec.c
> > index 654f2b1f9ac0..83d2025a4ab1 100644
> > --- a/arch/arm/kernel/machine_kexec.c
> > +++ b/arch/arm/kernel/machine_kexec.c
> > @@ -145,9 +145,10 @@ static void machine_kexec_mask_interrupts(void)
> >  void machine_crash_shutdown(struct pt_regs *regs)
> >{
> > -local_irq_disable();
> >disable_nonboot_cpus();
> >+local_irq_disable();
> > +
> >crash_smp_send_stop();
> >  crash_save_cpu(regs, smp_processor_id());
> >
>  ok. Can you please check before this if your usecases work without
>  disable_nonboot_cpus(). This patch was done pretty long time ago where
>  there was an issue with kexec. Long time ago I was talking to arm-soc
>  maintainers about this and they told me that mainline code should work
>  fine without any need to call disable_nonboot_cpus().
>  It means if kexec is working fine we can revert origin patch and use
>  what mainline is using.
> >>> It seems that the issue is still there. When crash at cpu1 and crash
> >>> kernel runs at cpu1,
> >>>
> >>> it will hang, the log is as below:
> >>>
> >>> root@xilinx-zynq:~# sh 1.sh
> >>> syscall kexec_file_load not available.
> >>> sysrq: Trigger a crash
> >>> Kernel panic - not syncing: sysrq triggered crash
> >>> CPU: 1 PID: 308 Comm: sh Kdump: loaded Not tainted 5.2.20-yocto-standard 
> >>> #4
> >>> Hardware name: Xilinx Zynq Platform
> >>> [<80112eb0>] (unwind_backtrace) from [<8010cc04>] (show_stack+0x18/0x1c)
> >>> [<8010cc04>] (show_stack) from [<8094f8f4>] (dump_stack+0x70/0x8c)
> >>> [<8094f8f4>] (dump_stack) from [<801256f4>] (panic+0xf8/0x320)
> >>> [<801256f4>] (panic) from [<805dbeb0>] (sysrq_handle_crash+0x18/0x1c)
> >>> [<805dbeb0>]

Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Li, Meng 



> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> Sent: Wednesday, October 23, 2019 10:39 AM
> To: Li, Meng
> Cc: linux-yocto@yoctoproject.org; He, Zhe
> Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64:
> dts: r8a7795: Add CPUIdle support for all CPU core
> 
> On Tue, Oct 22, 2019 at 8:06 AM Bruce Ashfield 
> wrote:
> >
> > On Tue, Oct 22, 2019 at 3:06 AM Li, Meng  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> > > > Sent: Saturday, October 19, 2019 12:51 PM
> > > > To: Li, Meng
> > > > Cc: linux-yocto@yoctoproject.org
> > > > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar:
> arm64:
> > > > dts: r8a7795: Add CPUIdle support for all CPU core
> > > >
> > > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar:
> arm64:
> > > > dts: r8a7795: Add CPUIdle support for all CPU core
> > > > on 15/10/2019 meng...@windriver.com wrote:
> > > >
> > > > > From: Limeng 
> > > > >
> > > > > Hi Bruce,
> > > > >
> > > > > I get below patch from SDK kernel to support cpu idle feature, and
> intend
> > > > to merge it into yocto community.
> > > > >
> > > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch
> > > > >
> > > > > Could you please merge this patch into linux-yocto-dev, branch is
> > > > standard/base?
> > > >
> > > > Looks fine to me, this is now merged.
> > > >
> > >
> > > Hi Bruce,
> > >
> > > I found a strange thing.
> > > When build project, this patch existed yesterday.
> > >  But now, the patch is missed.
> > > Could you please help to check it?
> >
> > linux-yocto-dev is now 5.4, so all existing branches are gone, support
> > and work in -dev now needs to rebased and sent as pull requests.
> >
> > >
> > > I also another similar patch that is requested to be merged into linux-
> yocto-5.2, branch is v5.2/standard/base, could you please help to check
> whether it is merged, too?
> >
> > I'll double check 5.2.
> 
> I'm not sure where the patch went .. but I just added it to
> v5.2/standard/base and merged it to the BSPs.
> 

Hi Bruce, 

Thanks! You merged my yesterday pull request for reserve memory, not the patch 
for CPU idle that I sent to you some days ago.
I will send a pull request for CPU idle feature again, wait a moment.

Regards,
Limeng

> Bruce
> 
> >
> > Bruce
> >
> > >
> > > Thanks,
> > > Limeng
> > >
> > >
> > > > Bruce
> > > >
> > > > >
> > > > >  r8a7795.dtsi |   32 
> > > > >  1 file changed, 32 insertions(+)
> > > > >
> > > > >
> > > > > thanks,
> > > > > Limeng
> >
> >
> >
> > --
> > - 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
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-v5.2/dev]: [kernel v5.2/standard/base and standard/base]: renesas-rcar: arm64: dts: r8a7795-h3ulcb: Add reserved memory regions

2019-10-22 Thread Bruce Ashfield 
merged

Bruce

On Tue, Oct 22, 2019 at 1:07 AM  wrote:
>
> From: Limeng 
>
> Hi Bruce,
>
> I get below patch from SDK kernel to support reserved memory for renesas 
> platform firmware that is integrated in bootloader, and intend to merge it 
> into yocto community.
>
> 0001-arm64-dts-r8a7795-h3ulcb-Add-reserved-memory-regions.patch
>
> Could you please merge this patch into linux-yocto and linux-yocto-dev, 
> branch are v5.2/standard/base and standard/base?
>
>  r8a7795-h3ulcb.dts |   29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
>
> thanks,
> Limeng



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Bruce Ashfield 
On Tue, Oct 22, 2019 at 8:06 AM Bruce Ashfield  wrote:
>
> On Tue, Oct 22, 2019 at 3:06 AM Li, Meng  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> > > Sent: Saturday, October 19, 2019 12:51 PM
> > > To: Li, Meng
> > > Cc: linux-yocto@yoctoproject.org
> > > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: 
> > > arm64:
> > > dts: r8a7795: Add CPUIdle support for all CPU core
> > >
> > > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: 
> > > arm64:
> > > dts: r8a7795: Add CPUIdle support for all CPU core
> > > on 15/10/2019 meng...@windriver.com wrote:
> > >
> > > > From: Limeng 
> > > >
> > > > Hi Bruce,
> > > >
> > > > I get below patch from SDK kernel to support cpu idle feature, and 
> > > > intend
> > > to merge it into yocto community.
> > > >
> > > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch
> > > >
> > > > Could you please merge this patch into linux-yocto-dev, branch is
> > > standard/base?
> > >
> > > Looks fine to me, this is now merged.
> > >
> >
> > Hi Bruce,
> >
> > I found a strange thing.
> > When build project, this patch existed yesterday.
> >  But now, the patch is missed.
> > Could you please help to check it?
>
> linux-yocto-dev is now 5.4, so all existing branches are gone, support
> and work in -dev now needs to rebased and sent as pull requests.
>
> >
> > I also another similar patch that is requested to be merged into 
> > linux-yocto-5.2, branch is v5.2/standard/base, could you please help to 
> > check whether it is merged, too?
>
> I'll double check 5.2.

I'm not sure where the patch went .. but I just added it to
v5.2/standard/base and merged it to the BSPs.

Bruce

>
> Bruce
>
> >
> > Thanks,
> > Limeng
> >
> >
> > > Bruce
> > >
> > > >
> > > >  r8a7795.dtsi |   32 
> > > >  1 file changed, 32 insertions(+)
> > > >
> > > >
> > > > thanks,
> > > > Limeng
>
>
>
> --
> - 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
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [OE-core] [prelink-cross] Bug 13529 add SPDX identifier

2019-10-22 Thread Mark Hatle 
I need to look through it further, but everything I looked at (and your comments
below) look good to me.

I'll try to get this merge soon.  (If you don't see it get merged, please ping
me.)  I'm preparing for ELC-E and am short on time right now.

--Mark

On 10/22/19 4:28 AM, Yann CARDAILLAC wrote:
> 
> 
> On Mon, Oct 21, 2019 at 4:35 PM Mark Hatle  > wrote:
> 
> On 10/21/19 4:43 AM, Yann CARDAILLAC wrote:
> > Hi Mark Hatle, Jakub Jelinek,
> 
> Jakub is no longer supporting this code, but he may have valuable 
> insights into
> licensing.
> 
> > I'm currently beginning the work on bug 13529:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13529
> >
> > The purpose is to add SPDX identifier to scripts and sources.
> >
> > Most of the sources have licences on the sources, however some of them 
> don't,
> > and I've question about others :
> >
> > - src/sha.c do not shall it be GPLV2-or-later as most of the other?
> 
> /* sha.c - Functions to compute the SHA1 hash (message-digest) of files
>    or blocks of memory.  Complies to the NIST specification FIPS-180-1.
> 
>    Copyright (C) 2000, 2001, 2003 Scott G. Miller
> 
>    Credits:
>       Robert Klep mailto:rob...@ilse.nl>>  -- Expansion
> function fix
>    NOTE: The canonical source of this file is maintained in GNU coreutils.
> */
> 
> The last line is the key.  This apparently came from GNU coreutils.
> 
> >From the SCM logs, sha.c was introduced in approx 2003-07-01 from what 
> it looks
> like.  So it's a pretty old version.  You will need to do some detective 
> work,
> and find older versions of coreutils until you find the one that 
> corresponds to
> the code that was checked in.  Start back in 2003 and work backwards as
> necessary.  (The version that matches to the original 2003-07-01 should 
> be the
> reasonable license to use.)
> 
> 
> Ok I found it ! https://github.com/coreutils/coreutils/blob/v4.5.8/lib/sha.c
> 
> from : https://github.com/coreutils/coreutils/blob/v4.5.8/COPYING it looks 
> like
> it's only GPLV2
> 
> 
> > - how to licence m4/libelf.m4 ? I'd prefer you to tell me exactly what 
> to
> add in
> > order to avoid errors
> 
> The original version of the m4/libelf.m4 was introduced 2001-09-27.  It 
> appears
> to me that it was written as part of the prelinker, so would be under the
> overall license of the prelinker.
> 
> Based on this, my assumption is that it is GPL-2.0
> 
> I do not see any 'or-later' clauses anywhere.
> 
> I have just add  "dnl SPDX-License-Identifier: GPL-2.0-only" bellow the 
> "Written
> by" comment, however should it also be in the resulting template? 
> I can add it also at first line of the resulting file if necessary ?
> 
> 
> > - what about *.C files ? They don't have licence header, they look like 
> C file
> > to me so I'd probably add :
> > // SPDX-License-Identifier: GPL-2.0-or-later
> 
> There are each simply test cases.  They would be covered by the overall
> 'COPYING' for the package.  Thus GPL-2.0
> 
> > - what about testsuite/ files ?
> 
> Same, no specifically stated license will be GPL-2.0.
> 
> Done ! 
> 
> > Shall every thing just be GPL-2.0-or-later?
> 
> Also just to be clear.  As I am NOT the original author of this work, I 
> won't
> accept a patch to remove any existing license text from the headers in 
> this
> software, but I will accept the SPDX-License-Identifier to be added in 
> addition
> to the existing license text.
>  
> 
> If an existing file does not have any License text in it, then we will 
> need to
> assume that the COPYING file covers all software unless there is some 
> indicator
> it comes from another source with a different license.  For items w/o 
> existing
> licenses, just adding the SPDX-License-Identifier will be acceptable.
> 
> So in a header similar to:
> 
> /* Copyright (C) 2001, 2002, 2003, 2007 Red Hat, Inc.
>    Written by Jakub Jelinek mailto:ja...@redhat.com>>, 
> 2001.
> 
>    This program is free software; you can redistribute it and/or modify
>    it under the terms of the GNU General Public License as published by
>    the Free Software Foundation; either version 2, or (at your option)
>    any later version.
> 
>    This program is distributed in the hope that it will be useful,
>    but WITHOUT ANY WARRANTY; without even the implied warranty of
>    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>    GNU General Public License for more details.
> 
>    You should have received a copy of the GNU General Public License
>    along with this program; if not, write to the Free Software Foundation,
>    Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
> 
> please add the header between the

[yocto] toaster - in build watching mode

2019-10-22 Thread Mark Hatle 
I'm using toaster in a build watching mode and I'm getting errors to the console
log such as:

File:
'/home/jenkins/workspace/OEBuild/build-32/oe-core/meta/classes/toaster.bbclass',
lineno: 130, function: toaster_package_dumpdata
 0126:lpkgdata = {}
 0127:datadir = os.path.join(pkgdatadir, 'runtime')
 0128:
 0129:# scan and send data for each generated package
 *** 0130:for datafile in os.listdir(datadir):
 0131:if not datafile.endswith('.packaged'):
 0132:lpkgdata = _toaster_load_pkgdatafile(datadir, datafile)
 0133:# Fire an event containing the pkg data
 0134:bb.event.fire(bb.event.MetadataEvent("SinglePackageInfo",
lpkgdata), d)
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/home/jenkins/workspace/OEBuild/builds/build-32/tmp-glibc/work/core2-64-oe-linux/libxfixes/1_5.0.3-r0/pkgdata/runtime'


Also lots of messages like:

NOTE: We did not find one recipe for theconfiguration data package libxml2
Recipe matching query does not exist.
NOTE: We did not find one recipe for theconfiguration data package libx11-6
Recipe matching query does not exist.
NOTE: We did not find one recipe for theconfiguration data package
wpa-supplicant Recipe matching query does not exist.


In the toaster itself, I see the % status of the current build (which appears to
be correct).  However, during the build I didn't get any per task information
like I remembered seeing in the past.  Has this changed, or do we have a bug
somewhere?

--Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Canceled event with note: Yocto Project Technical Team Meeting / Engineering Sync @ Tue Oct 29, 2019 8am - 9am (PDT) (yocto@yoctoproject.org)

2019-10-22 Thread theyoctoproject 
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20191029T08
DTEND;TZID=America/Los_Angeles:20191029T09
DTSTAMP:20191022T150510Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:74pj8d1h6op62b9j74omcb9kcpgjgb9oclhj0b9jcos3io9h61ijgd1nc4_R20190827T15
 0...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=kh
 em_...@comcast.com;X-NUM-GUESTS=0:mailto:khem_...@comcast.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ni
 ck.pongr...@singlewire.com;X-NUM-GUESTS=0:mailto:nick.pongratz@singlewire.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=br
 uce.ashfi...@gmail.com;X-NUM-GUESTS=0:mailto:bruce.ashfi...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=hn
 j...@triax.com;X-NUM-GUESTS=0:mailto:h...@triax.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=la
 zaros.lazari...@atos.net;X-NUM-GUESTS=0:mailto:lazaros.lazari...@atos.net
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=er
 ik.hoogev...@outlook.com;X-NUM-GUESTS=0:mailto:erik.hoogev...@outlook.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ru
 dolf.str...@gmail.com;X-NUM-GUESTS=0:mailto:rudolf.str...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ma
 nju...@xilinx.com;X-NUM-GUESTS=0:mailto:manju...@xilinx.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=kh
 em_...@cable.comcast.com;X-NUM-GUESTS=0:mailto:khem_...@cable.comcast.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ro
 b.rans...@windriver.com;X-NUM-GUESTS=0:mailto:rob.rans...@windriver.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=bi
 kram_bh...@mentor.com;X-NUM-GUESTS=0:mailto:bikram_bh...@mentor.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=yo
 c...@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=oa
 ndreas...@luxoft.com;X-NUM-GUESTS=0:mailto:oandreas...@luxoft.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ya
 nnick.koeh...@hpe.com;X-NUM-GUESTS=0:mailto:yannick.koeh...@hpe.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=st
 ephen.k.jol...@intel.com;X-NUM-GUESTS=0:mailto:stephen.k.jol...@intel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=as
 ei...@ciena.com;X-NUM-GUESTS=0:mailto:asei...@ciena.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=jd
 ma...@kudzu.us;X-NUM-GUESTS=0:mailto:jdma...@kudzu.us
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=jo
 nathan.h...@sdl.usu.edu;X-NUM-GUESTS=0:mailto:jonathan.h...@sdl.usu.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dw
 atk...@sierrawireless.com;X-NUM-GUESTS=0:mailto:dwatk...@sierrawireless.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=theyoc
 toproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproj...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ra
 j.k...@gmail.com;X-NUM-GUESTS=0:mailto:raj.k...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ra
 ymond@intel.com;X-NUM-GUESTS=0:mailto:raymond@intel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=th
 ore.boeckelm...@inoex.de;X-NUM-GUESTS=0:mailto:thore.boeckelm...@inoex.de
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=rc
 alh...@shotspotter.com;X-NUM-GUESTS=0:mailto:rcalh...@shotspotter.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=na
 ndo...@gmail.com;X-NUM-GUESTS=0:mailto:nando...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ar
 avindhlal...@embedur.com;X-NUM-GUESTS=0:mailto:aravindhlal...@embedur.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=sj
 olley.yp...@gmail.com;X-NUM-GUESTS=0:mailto:sjolley.yp...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=pa
 trick.schnei...@bhtronik.de;X-NUM-GUESTS=0:mailto:patrick.schneider@bhtroni
 k.de
RECURRENCE-ID;TZID=America/Los_Angeles:20191029T08
CREATED:20180524T181406Z
DESCRIPTION:The Yocto Project hosts a technical call. All community mem
 bers are

[yocto] Yocto Project Status WW43’19

2019-10-22 Thread Stephen K Jolley 
Current Dev Position: YP 3.1 M1

Next Deadline: YP 3.0 Final Release 25th Oct

SWAT Team Rotation:

   -

   SWAT lead is currently: Paul
   -

   SWAT team rotation: Ross -> Amanda on Oct. 25, 2019
   -

   SWAT team rotation: Amanda -> Armin on Nov. 1, 2019
   -

   https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Next Team Meetings:

   -

   Bug Triage meeting Thursday Oct. 24th at 7:30am PDT (
   https://zoom.us/j/454367603)
   -

   Monthly Project Meeting Tuesday Nov. 5th at 8am PDT (
   https://zoom.us/j/990892712) 
   -

   Weekly Engineering Sync Tuesday Oct. 22th at 8am PDT (
   https://zoom.us/j/990892712) 
   -

   Twitch - Next event is Tuesday Nov. 12th at 8am PDT (
   https://www.twitch.tv/yocto_project)


Key Status/Updates:

   -

   YP 3.0 as been approved by the TSC and should be released later this
   week. Only the final tweaks to the release notes remain.
   -

   Master has continued taking patches for post 3.0.
   -

   There are a number of intermittent failures on the autobuiler which are
   causing concern, there is a separate email about this.
   -

   YP  2.6.4 was built and submitted to QA
   -

   YP 2.7.2 was not built due to a remaining bug which needs to be resolved
   first
   -

   Next week is ELC-E and therefore may be quiet on the mailing lists with
   patch merging being delayed.
   -

   We have begun collecting ideas for YP 3.1 in this document:
   
https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjnABc/edit?usp=sharing
   -

   If anyone has any status items for the project they’d like to add to the
   weekly reports, please email Richard+Stephen.


Planned Releases for YP 3.0:

   -

   YP 3.0 Final Release 25th Oct


Planned upcoming dot releases:

   -

   YP 2.7.2 (Warrior) is planned this week (assuming the remaining bug is
   resolved).
   -

   YP 2.6.4 (Thud) is in QA..


Tracking Metrics:

   -

   WDD 2498 (last week 2528) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   Poky Patch Metrics
   -

  Total patches found: 1432 (last week 1445)
  -

  Patches in the Pending State: 578 (41%) [last week 586 (41%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

The Yocto Project’s technical governance is through its Technical Steering
Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at:
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][opkg] bug 13528 add SPDX id to opkg

2019-10-22 Thread Yann CARDAILLAC 
Hi,

I'm working on bug : https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528

I've a first patch proposal. Note that I didn't knew what to do with
m4/gpgme.m4 the license header seems pretty weird to me...

Regards,

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From 8e2c4d34a81e703df8c31163ef4bbec09f96be63 Mon Sep 17 00:00:00 2001
From: Yann CARDAILLAC 
Date: Tue, 22 Oct 2019 16:49:42 +0200
Subject: [PATCH] add SPDX License identifier

Signed-off-by: Yann CARDAILLAC 
---
 intercept/depmod | 1 +
 intercept/ldconfig   | 1 +
 intercept/update-modules | 1 +
 libopkg/cksum_list.c | 2 ++
 libopkg/cksum_list.h | 2 ++
 libopkg/conffile.c   | 2 ++
 libopkg/conffile.h   | 2 ++
 libopkg/conffile_list.c  | 2 ++
 libopkg/conffile_list.h  | 2 ++
 libopkg/file_list.c  | 2 ++
 libopkg/file_list.h  | 2 ++
 libopkg/file_util.c  | 2 ++
 libopkg/file_util.h  | 2 ++
 libopkg/hash_table.c | 2 ++
 libopkg/hash_table.h | 2 ++
 libopkg/list.h   | 2 ++
 libopkg/md5.c| 3 +++
 libopkg/md5.h| 3 +++
 libopkg/nv_pair.c| 2 ++
 libopkg/nv_pair.h| 2 ++
 libopkg/nv_pair_list.c   | 2 ++
 libopkg/nv_pair_list.h   | 2 ++
 libopkg/opkg.c   | 2 ++
 libopkg/opkg.h   | 2 ++
 libopkg/opkg_archive.c   | 2 ++
 libopkg/opkg_archive.h   | 2 ++
 libopkg/opkg_cmd.c   | 2 ++
 libopkg/opkg_cmd.h   | 2 ++
 libopkg/opkg_conf.c  | 2 ++
 libopkg/opkg_conf.h  | 2 ++
 libopkg/opkg_configure.c | 2 ++
 libopkg/opkg_configure.h | 2 ++
 libopkg/opkg_download.c  | 2 ++
 libopkg/opkg_download.h  | 2 ++
 libopkg/opkg_download_curl.c | 2 ++
 libopkg/opkg_download_wget.c | 2 ++
 libopkg/opkg_gpg.c   | 2 ++
 libopkg/opkg_gpg.h   | 2 ++
 libopkg/opkg_install.c   | 2 ++
 libopkg/opkg_install.h   | 2 ++
 libopkg/opkg_message.c   | 2 ++
 libopkg/opkg_message.h   | 2 ++
 libopkg/opkg_openssl.c   | 2 ++
 libopkg/opkg_openssl.h   | 2 ++
 libopkg/opkg_remove.c| 2 ++
 libopkg/opkg_remove.h| 2 ++
 libopkg/opkg_solver.h| 2 ++
 libopkg/opkg_utils.c | 2 ++
 libopkg/opkg_utils.h | 2 ++
 libopkg/opkg_verify.c| 2 ++
 libopkg/opkg_verify.h| 2 ++
 libopkg/parse_util.c | 2 ++
 libopkg/parse_util.h | 2 ++
 libopkg/pkg.c| 2 ++
 libopkg/pkg.h| 2 ++
 libopkg/pkg_depends.c| 2 ++
 libopkg/pkg_depends.h| 2 ++
 libopkg/pkg_dest.c   | 2 ++
 libopkg/pkg_dest.h   | 2 ++
 libopkg/pkg_dest_list.c  | 2 ++
 libopkg/pkg_dest_list.h  | 2 ++
 libopkg/pkg_extract.c| 2 ++
 libopkg/pkg_extract.h| 2 ++
 libopkg/pkg_hash.c   | 2 ++
 libopkg/pkg_hash.h   | 2 ++
 libopkg/pkg_parse.c  | 2 ++
 libopkg/pkg_parse.h  | 2 ++
 libopkg/pkg_src.c| 2 ++
 libopkg/pkg_src.h| 2 ++
 libopkg/pkg_src_list.c   | 2 ++
 libopkg/pkg_src_list.h   | 2 ++

Re: [yocto] [layerindex-web] Add SPDX Identifier

2019-10-22 Thread Yann CARDAILLAC 
On Mon, Oct 21, 2019 at 9:37 PM Paul Eggleton 
wrote:

> On Tuesday, 22 October 2019 4:15:03 AM NZDT Yann CARDAILLAC wrote:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13527
> >
> > I'm beginning the work of updating the layerindex-web repo, this one is a
> > bit tricky, how should I treat the files generated using Django ?
>
> I believe the correct license for Django-derived files is BSD-3-Clause:
>
>   https://github.com/django/django/blob/master/LICENSE
>
> > I've yet to do html, txt and sh files, do you have any advices before I
> > start?
>
> Note that some of the templates used for authentication originally came
> from
> here:
>
>   https://github.com/macdhuibh/django-registration-templates
>
> The LICENSE file indicates MIT for those though.
>
> The txt files are tricky because any stray newlines will affect
> formatting. I
> would probably avoid touching them.
>
> I did not yet add MIT to html files, I don't really know if that makes
sense or not?  I didn't do that because it seemed a bit weird to me, but I
don't know what to think of that. Most of the time you'll find copyright on
the footer of the page, but I'm not sure about Licensing those.

So here is a first iteration of the patch without htmls file licensed.

Regards,

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From e46cd0244aa8134318236a2f1aee96682e09715b Mon Sep 17 00:00:00 2001
From: Yann CARDAILLAC 
Date: Tue, 22 Oct 2019 15:17:21 +0200
Subject: [PATCH] add SPDX License identifier

Signed-off-by: Yann CARDAILLAC 
---
 __init__.py | 2 ++
 check_requirements.sh   | 1 +
 docker/connectivity_check.sh| 1 +
 docker/git-proxy| 1 +
 docker/migrate.sh   | 1 +
 docker/refreshlayers.sh | 1 +
 docker/settings.py  | 1 +
 docker/updatelayers.sh  | 1 +
 dockersetup.py  | 1 +
 layerindex/__init__.py  | 1 +
 layerindex/admin.py | 1 +
 layerindex/auth_forms.py| 1 +
 layerindex/auth_views.py| 1 +
 layerindex/bulkchange.py| 1 +
 layerindex/context_processors.py| 1 +
 layerindex/forms.py | 1 +
 layerindex/layerconfparse.py| 1 +
 layerindex/middleware.py| 1 +
 layerindex/migrations/0001_initial.py   | 1 +
 layerindex/migrations/0002_distro.py| 1 +
 layerindex/migrations/0003_auto_20161011_0304.py| 1 +
 layerindex/migrations/0004_layerdependency_required.py  | 1 +
 layerindex/migrations/0005_layerupdate.py   | 1 +
 layerindex/migrations/0006_change_branch_meta.py| 1 +
 layerindex/migrations/0007_layeritem_status_noupdate.py | 1 +
 layerindex/migrations/0008_yp_compatible.py | 1 +
 layerindex/migrations/0009_layerbranch_collection.py| 1 +
 layerindex/migrations/0010_add_dependencies.py  | 1 +
 layerindex/migrations/0011_source.py| 1 +
 layerindex/migrations/0012_layeritem_vcs_commit_url.py  | 1 +
 layerindex/migrations/0013_patch.py | 1 +
 layerindex/migrations/0014_sitenotice.py| 1 +
 layerindex/migrations/0015_comparison.py| 1 +
 layerindex/migrations/0016_classicrecipe_delete.py  | 1 +
 layerindex/migrations/0017_classicrecipe_needs_attention.py | 1 +
 layerindex/migrations/0018_layerrecipeextraurl.py   | 1 +
 layerindex/migrations/0019_layeritem_classic_comparison.py  | 1 +
 layerindex/migrations/0020_update_manual.py | 1 +
 layerindex/migrations/0021_layerupdate_add_layer_branch.py  | 1 +
 layerindex/migrations/0022_layerupdate_set_layer_branch.py  | 1 +
 layerindex/migrations/0023_layerupdate_layer_branch_finalise.py | 1 +
 layerindex/migrations/0024_layerupdate_vcs_revs.py  | 1 +

Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Bruce Ashfield 
On Tue, Oct 22, 2019 at 3:06 AM Li, Meng  wrote:
>
>
>
> > -Original Message-
> > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> > Sent: Saturday, October 19, 2019 12:51 PM
> > To: Li, Meng
> > Cc: linux-yocto@yoctoproject.org
> > Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64:
> > dts: r8a7795: Add CPUIdle support for all CPU core
> >
> > In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64:
> > dts: r8a7795: Add CPUIdle support for all CPU core
> > on 15/10/2019 meng...@windriver.com wrote:
> >
> > > From: Limeng 
> > >
> > > Hi Bruce,
> > >
> > > I get below patch from SDK kernel to support cpu idle feature, and intend
> > to merge it into yocto community.
> > >
> > > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch
> > >
> > > Could you please merge this patch into linux-yocto-dev, branch is
> > standard/base?
> >
> > Looks fine to me, this is now merged.
> >
>
> Hi Bruce,
>
> I found a strange thing.
> When build project, this patch existed yesterday.
>  But now, the patch is missed.
> Could you please help to check it?

linux-yocto-dev is now 5.4, so all existing branches are gone, support
and work in -dev now needs to rebased and sent as pull requests.

>
> I also another similar patch that is requested to be merged into 
> linux-yocto-5.2, branch is v5.2/standard/base, could you please help to check 
> whether it is merged, too?

I'll double check 5.2.

Bruce

>
> Thanks,
> Limeng
>
>
> > Bruce
> >
> > >
> > >  r8a7795.dtsi |   32 
> > >  1 file changed, 32 insertions(+)
> > >
> > >
> > > thanks,
> > > Limeng



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 0/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t

2019-10-22 Thread Bruce Ashfield 
I already have the latest 5.2 -stable and -rt under test, so I'll
finish those rather than merging this.

Bruce

On Tue, Oct 22, 2019 at 3:23 AM Yongxin Liu  wrote:
>
> Hi Bruce,
>
> Could you help to merge this patch to linux-yocto v5.2/standard/preempt-rt?
> This patch is only for RT kernel.
> It was added in v5.2 rt11.
> I know you periodically pull RT patches. But could you help to merge this 
> patch in advance?
>
>
> Liu Haitao (1):
>   kmemleak: Change the lock of kmemleak_object to raw_spinlock_t
>
>  mm/kmemleak.c | 72 
> +--
>  1 file changed, 36 insertions(+), 36 deletions(-)
>
>
> Thanks,
> Yongxin



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [PATCH] [auto-upgrade-helper] Add SPDX identifier to auto-upgrade-helper

2019-10-22 Thread Alexander Kanavin 
Thanks, patch applied and pushed.

Alex

On Mon, 21 Oct 2019 at 14:46, Yann CARDAILLAC 
wrote:

> Hi guys,
>
> I'm working on bug :
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13531
>
> I've add GPLV2-or-later to all the sources, is there any modification you
> want to add?
>
> Best regards,
>
> Yann CARDAILLAC
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Yann CARDAILLAC*
> Ingénieur Systèmes Embarqués
>
> [image: email] yann.cardail...@smile.fr
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [prelink-cross] Bug 13529 add SPDX identifier

2019-10-22 Thread Yann CARDAILLAC 
On Mon, Oct 21, 2019 at 4:35 PM Mark Hatle 
wrote:

> On 10/21/19 4:43 AM, Yann CARDAILLAC wrote:
> > Hi Mark Hatle, Jakub Jelinek,
>
> Jakub is no longer supporting this code, but he may have valuable insights
> into
> licensing.
>
> > I'm currently beginning the work on bug 13529:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13529
> >
> > The purpose is to add SPDX identifier to scripts and sources.
> >
> > Most of the sources have licences on the sources, however some of them
> don't,
> > and I've question about others :
> >
> > - src/sha.c do not shall it be GPLV2-or-later as most of the other?
>
> /* sha.c - Functions to compute the SHA1 hash (message-digest) of files
>or blocks of memory.  Complies to the NIST specification FIPS-180-1.
>
>Copyright (C) 2000, 2001, 2003 Scott G. Miller
>
>Credits:
>   Robert Klep   -- Expansion function fix
>NOTE: The canonical source of this file is maintained in GNU coreutils.
> */
>
> The last line is the key.  This apparently came from GNU coreutils.
>
> From the SCM logs, sha.c was introduced in approx 2003-07-01 from what it
> looks
> like.  So it's a pretty old version.  You will need to do some detective
> work,
> and find older versions of coreutils until you find the one that
> corresponds to
> the code that was checked in.  Start back in 2003 and work backwards as
> necessary.  (The version that matches to the original 2003-07-01 should be
> the
> reasonable license to use.)
>

Ok I found it ! https://github.com/coreutils/coreutils/blob/v4.5.8/lib/sha.c

from : https://github.com/coreutils/coreutils/blob/v4.5.8/COPYING it looks
like it's only GPLV2


> > - how to licence m4/libelf.m4 ? I'd prefer you to tell me exactly what
> to add in
> > order to avoid errors
>
> The original version of the m4/libelf.m4 was introduced 2001-09-27.  It
> appears
> to me that it was written as part of the prelinker, so would be under the
> overall license of the prelinker.
>
> Based on this, my assumption is that it is GPL-2.0
>
> I do not see any 'or-later' clauses anywhere.
>
> I have just add  "dnl SPDX-License-Identifier: GPL-2.0-only" bellow the
"Written by" comment, however should it also be in the resulting template?
I can add it also at first line of the resulting file if necessary ?


> - what about *.C files ? They don't have licence header, they look like C
> file
> > to me so I'd probably add :
> > // SPDX-License-Identifier: GPL-2.0-or-later
>
> There are each simply test cases.  They would be covered by the overall
> 'COPYING' for the package.  Thus GPL-2.0
>
> > - what about testsuite/ files ?
>
> Same, no specifically stated license will be GPL-2.0.
>
> Done !

> > Shall every thing just be GPL-2.0-or-later?
>
> Also just to be clear.  As I am NOT the original author of this work, I
> won't
> accept a patch to remove any existing license text from the headers in this
> software, but I will accept the SPDX-License-Identifier to be added in
> addition
> to the existing license text.
>
>
If an existing file does not have any License text in it, then we will need
> to
> assume that the COPYING file covers all software unless there is some
> indicator
> it comes from another source with a different license.  For items w/o
> existing
> licenses, just adding the SPDX-License-Identifier will be acceptable.
>
> So in a header similar to:
>
> /* Copyright (C) 2001, 2002, 2003, 2007 Red Hat, Inc.
>Written by Jakub Jelinek , 2001.
>
>This program is free software; you can redistribute it and/or modify
>it under the terms of the GNU General Public License as published by
>the Free Software Foundation; either version 2, or (at your option)
>any later version.
>
>This program is distributed in the hope that it will be useful,
>but WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>GNU General Public License for more details.
>
>You should have received a copy of the GNU General Public License
>along with this program; if not, write to the Free Software Foundation,
>Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
>
> please add the header between the 'Written by' and the existing license
> text,
> such as:
>
> /* Copyright (C) 2001, 2002, 2003, 2007 Red Hat, Inc.
>Written by Jakub Jelinek , 2001.
>
>SPDX-License-Identifier: GPL-2.0-or-later
>
>This program is free software; you can redistribute it and/or modify
>it under the terms of the GNU General Public License as published by
>
>
Here's the first attempt of the patch, feel free to give me any advice on
how to improve it!

Regards,

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]

[linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 0/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t

2019-10-22 Thread Yongxin Liu 
Hi Bruce,

Could you help to merge this patch to linux-yocto v5.2/standard/preempt-rt?
This patch is only for RT kernel.
It was added in v5.2 rt11.
I know you periodically pull RT patches. But could you help to merge this patch 
in advance?


Liu Haitao (1):
  kmemleak: Change the lock of kmemleak_object to raw_spinlock_t

 mm/kmemleak.c | 72 +--
 1 file changed, 36 insertions(+), 36 deletions(-)


Thanks,
Yongxin
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [linux-yocto preempt-rt v5.2][PATCH 1/1] kmemleak: Change the lock of kmemleak_object to raw_spinlock_t

2019-10-22 Thread Yongxin Liu 
From: Liu Haitao 

commit 217847f57119b5fdd377bfa3d344613ddb98d9fc upstream.

The commit ("kmemleak: Turn kmemleak_lock to raw spinlock on RT")
changed the kmemleak_lock to raw spinlock. However the
kmemleak_object->lock is held after the kmemleak_lock is held in
scan_block().

Make the object->lock a raw_spinlock_t.

Cc: stable...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190927082230.34152-1-yongxin@windriver.com
Signed-off-by: Liu Haitao 
Signed-off-by: Yongxin Liu 
Signed-off-by: Sebastian Andrzej Siewior 
---
 mm/kmemleak.c | 72 +--
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index aaee59c0306a..355dd95d0611 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -135,7 +135,7 @@ struct kmemleak_scan_area {
  * (use_count) and freed using the RCU mechanism.
  */
 struct kmemleak_object {
-   spinlock_t lock;
+   raw_spinlock_t lock;
unsigned int flags; /* object status flags */
struct list_head object_list;
struct list_head gray_list;
@@ -560,7 +560,7 @@ static struct kmemleak_object *create_object(unsigned long 
ptr, size_t size,
INIT_LIST_HEAD(>object_list);
INIT_LIST_HEAD(>gray_list);
INIT_HLIST_HEAD(>area_list);
-   spin_lock_init(>lock);
+   raw_spin_lock_init(>lock);
atomic_set(>use_count, 1);
object->flags = OBJECT_ALLOCATED;
object->pointer = ptr;
@@ -642,9 +642,9 @@ static void __delete_object(struct kmemleak_object *object)
 * Locking here also ensures that the corresponding memory block
 * cannot be freed when it is being scanned.
 */
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
object->flags &= ~OBJECT_ALLOCATED;
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
 }
 
@@ -716,9 +716,9 @@ static void paint_it(struct kmemleak_object *object, int 
color)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
__paint_it(object, color);
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 }
 
 static void paint_ptr(unsigned long ptr, int color)
@@ -778,7 +778,7 @@ static void add_scan_area(unsigned long ptr, size_t size, 
gfp_t gfp)
goto out;
}
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
if (size == SIZE_MAX) {
size = object->pointer + object->size - ptr;
} else if (ptr + size > object->pointer + object->size) {
@@ -794,7 +794,7 @@ static void add_scan_area(unsigned long ptr, size_t size, 
gfp_t gfp)
 
hlist_add_head(>node, >area_list);
 out_unlock:
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 out:
put_object(object);
 }
@@ -817,9 +817,9 @@ static void object_set_excess_ref(unsigned long ptr, 
unsigned long excess_ref)
return;
}
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
object->excess_ref = excess_ref;
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
 }
 
@@ -839,9 +839,9 @@ static void object_no_scan(unsigned long ptr)
return;
}
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
object->flags |= OBJECT_NO_SCAN;
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
put_object(object);
 }
 
@@ -902,11 +902,11 @@ static void early_alloc(struct early_log *log)
   log->min_count, GFP_ATOMIC);
if (!object)
goto out;
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
for (i = 0; i < log->trace_len; i++)
object->trace[i] = log->trace[i];
object->trace_len = log->trace_len;
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 out:
rcu_read_unlock();
 }
@@ -1096,9 +1096,9 @@ void __ref kmemleak_update_trace(const void *ptr)
return;
}
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
object->trace_len = __save_stack_trace(object->trace);
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 
put_object(object);
 }
@@ -1346,7 +1346,7 @@ static void scan_block(void *_start, void *_end,
 * previously acquired in scan_object(). These locks are
 * enclosed by scan_mutex.
 */
-   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+

[linux-yocto] Next Sync-up

2019-10-22 Thread He Zhe 
Hi Bruce,

When will the next sync-up with stable and RT trees happen?

Thanks,
Zhe
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64: dts: r8a7795: Add CPUIdle support for all CPU core

2019-10-22 Thread Li, Meng 



> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> Sent: Saturday, October 19, 2019 12:51 PM
> To: Li, Meng
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64:
> dts: r8a7795: Add CPUIdle support for all CPU core
> 
> In message: [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: arm64:
> dts: r8a7795: Add CPUIdle support for all CPU core
> on 15/10/2019 meng...@windriver.com wrote:
> 
> > From: Limeng 
> >
> > Hi Bruce,
> >
> > I get below patch from SDK kernel to support cpu idle feature, and intend
> to merge it into yocto community.
> >
> > 0001-arm64-dts-r8a7795-Add-CPUIdle-support-for-all-CPU-co.patch
> >
> > Could you please merge this patch into linux-yocto-dev, branch is
> standard/base?
> 
> Looks fine to me, this is now merged.
>

Hi Bruce,

I found a strange thing.
When build project, this patch existed yesterday. 
 But now, the patch is missed.
Could you please help to check it?

I also another similar patch that is requested to be merged into 
linux-yocto-5.2, branch is v5.2/standard/base, could you please help to check 
whether it is merged, too?

Thanks,
Limeng

 
> Bruce
> 
> >
> >  r8a7795.dtsi |   32 
> >  1 file changed, 32 insertions(+)
> >
> >
> > thanks,
> > Limeng
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] dma: xilinx: dpdma: alloc xilinx_dpdma_tx_desc using GFP_ATOMIC

2019-10-22 Thread Quanyang Wang 


On 10/18/19 10:42 PM, Radhey Shyam Pandey wrote:

-Original Message-
From: Hyun Kwon 
Sent: Thursday, October 17, 2019 11:01 PM
To: Quanyang Wang 
Cc: Hyun Kwon ; Michal Simek ;
Bruce ; linux-yocto@yoctoproject.org; Radhey
Shyam Pandey 
Subject: Re: [linux-yocto][PATCH 1/1] dma: xilinx: dpdma: alloc
xilinx_dpdma_tx_desc using GFP_ATOMIC

Hi Quanyang,

+ Radhey

On Wed, 2019-10-16 at 20:11:39 -0700, Quanyang Wang wrote:

On 10/17/19 1:01 AM, Hyun Kwon wrote:

Hi Quanyang,

Thanks for the patch.

On Tue, 2019-10-15 at 22:49:41 -0700, Michal Simek wrote:

+Hyun,

On 15. 10. 19 16:56, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

The function xilinx_dpdma_chan_alloc_tx_desc can be called
from atomic context, hence use GFP_ATOMIC instead of GFP_KERNEL,
or else it will cause the calltrace as below:

BUG: sleeping function called from invalid context at mm/slab.h:418
in_atomic(): 1, irqs_disabled(): 128, pid: 416, name: alsa-sink-(null

Preemption disabled at:

[] snd_pcm_stream_lock_irq+0x40/0x50
CPU: 2 PID: 416 Comm: alsa-sink-(null Tainted: G O 5.2.17-yocto-

standard #1

Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Call trace:
dump_backtrace+0x0/0x138
show_stack+0x24/0x30
dump_stack+0x94/0xbc
___might_sleep+0x14c/0x178
__might_sleep+0x58/0x90
kmem_cache_alloc_trace+0x1a4/0x300
xilinx_dpdma_chan_alloc_tx_desc.isra.0+0x24/0x40
xilinx_dpdma_prep_dma_cyclic+0xc0/0x208
snd_dmaengine_pcm_trigger+0xf8/0x198
soc_pcm_trigger+0xb4/0x128
snd_pcm_do_start+0x48/0x58
snd_pcm_action_single+0x4c/0xa0
snd_pcm_action+0x78/0x90
snd_pcm_action_lock_irq+0x3c/0x60
snd_pcm_common_ioctl+0x4ac/0x10c8
snd_pcm_ioctl+0x48/0x68
do_vfs_ioctl+0x6d4/0x968
ksys_ioctl+0x84/0xb8
__arm64_sys_ioctl+0x28/0x38
el0_svc_common.constprop.0+0x74/0x180
el0_svc_handler+0x70/0x90
el0_svc+0x8/0xc

Signed-off-by: Quanyang Wang 

Maybe the 'nonatomic' can be set to true in xilinx_dp_dai_links? But I

don't

know much about the flag, ex what's required, and I don't see any

problem with

this change. So,

   Reviewed-by: Hyun Kwon 

Hi Hyun,

Thank you for looking this patch over.

I test and the "nonatomic" can also eliminate the calltrace.  But I
don't know if there is any

problem with alsa driver running in a nonatomic context.

Me neither, so maybe changing gfp flag seems safer in that aspect. :-)


And do you think it's better using GFP_NOWAIT instead of GFP_ATOMIC ?
This can save some atomic memory.

In my limited view, GFP_ATOMIC seems better as the allocation is relatively
small but related to IO, rather than relying only on page reclaim. I see both
are quite commonly used for dma descriptor allocation, so it doesn't seem
like
one is clearly better than the other. But I may be wrong. Radhey may have
better answer.

_NOWAIT is like _ATOMIC except that no wait will not fall back to emergency
pools. http://lkml.iu.edu/hypermail/linux/kernel/0911.1/02316.html
IMO if allocation is in critical path and small then GFP_ATOMIC can be used
else switching to _NOWAIT might be preferred.


Hi Radhey,

Thank you for your suggestion.

Since xilinx_dpdma_tx_desc is small, it seems that GFP_ATOMIC is better.

Thanks,

Quanyang




Thanks,
-hyun

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto