Re: [linux-yocto] [kernel-cache master/yocto-5.2][PATCH 0/1] xilinx-zynqmp: delete obsolete kernel options

2019-10-18 Thread Bruce Ashfield
In message: [linux-yocto][kernel-cache master/yocto-5.2][PATCH 0/1] 
xilinx-zynqmp: delete obsolete kernel options
on 15/10/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce, Michal,
> 
> This patch is to delete some obsolete kernel options. Now delete them
> or else yocto will throw out build warning infos.
> 
> Could you please merge this patch into yocto-kernel-cache, branch is master 
> and yocto-5.2?

merged.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (1):
>   xilinx-zynqmp: delete obsolete kernel options
> 
>  bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> -- 
> 2.17.1
> 
-- 
___
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-18 Thread Bruce Ashfield
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.

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] [kernel-cache][PATCH 0/1] xilinx-zynqmp: add kernel options for ZynqMP PL Programming

2019-10-18 Thread Bruce Ashfield


In message: [linux-yocto][kernel-cache][PATCH 0/1] xilinx-zynqmp: add kernel 
options for ZynqMP PL Programming
on 17/10/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce, Michal,
> 
> Would you please help review and merge this patch to
> yocto-kernel-cache's branch yocto-5.2 and master?

merged.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (1):
>   xilinx-zynqmp: add kernel options for ZynqMP PL Programming
> 
>  bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 4 
>  1 file changed, 4 insertions(+)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] nvme-pci: Set the prp2 correctly when using more than 4k page

2019-10-18 Thread Bruce Ashfield
In message: [PATCH v5.2] nvme-pci: Set the prp2 correctly when using more than 
4k page
on 19/10/2019 Kevin Hao wrote:

> commit a4f40484e7f1dff56bb9f286cc59ffa36e0259eb from
> git://git.infradead.org/nvme.git
> 
> In the current code, the nvme is using a fixed 4k PRP entry size,
> but if the kernel use a page size which is more than 4k, we should
> consider the situation that the bv_offset may be larger than the
> dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
> cause the command can't be executed correctly.
> 
> Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment 
> requests")
> Cc: sta...@vger.kernel.org
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Kevin Hao 
> Signed-off-by: Keith Busch 
> ---
> Hi Bruce,
> 
> This patch has already been merged into nvme-5.4 and I also CCed 
> sta...@vger.kernel.org,
> so in theory it could propagate to linux-yocto via the stable update.
> But this issue cause a critical malfunction for the nvme interface and
> block our validation for it. So I would like to pick this patch ASAP.
> We should merge this into v5.2/standard/base branch.

No problem. I was just looking at the queue, and since this was already
reviewed upstream and safe .. I jumped it to the front and have merged
and pushed it to the repo.

Bruce

> 
>  drivers/nvme/host/pci.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 4b181969c432..869f462e6b6e 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -773,7 +773,8 @@ static blk_status_t nvme_setup_prp_simple(struct nvme_dev 
> *dev,
>   struct bio_vec *bv)
>  {
>   struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> - unsigned int first_prp_len = dev->ctrl.page_size - bv->bv_offset;
> + unsigned int offset = bv->bv_offset & (dev->ctrl.page_size - 1);
> + unsigned int first_prp_len = dev->ctrl.page_size - offset;
>  
>   iod->first_dma = dma_map_bvec(dev->dev, bv, rq_dma_dir(req), 0);
>   if (dma_mapping_error(dev->dev, iod->first_dma))
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH v5.2] nvme-pci: Set the prp2 correctly when using more than 4k page

2019-10-18 Thread Kevin Hao
commit a4f40484e7f1dff56bb9f286cc59ffa36e0259eb from
git://git.infradead.org/nvme.git

In the current code, the nvme is using a fixed 4k PRP entry size,
but if the kernel use a page size which is more than 4k, we should
consider the situation that the bv_offset may be larger than the
dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
cause the command can't be executed correctly.

Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment 
requests")
Cc: sta...@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Kevin Hao 
Signed-off-by: Keith Busch 
---
Hi Bruce,

This patch has already been merged into nvme-5.4 and I also CCed 
sta...@vger.kernel.org,
so in theory it could propagate to linux-yocto via the stable update.
But this issue cause a critical malfunction for the nvme interface and
block our validation for it. So I would like to pick this patch ASAP.
We should merge this into v5.2/standard/base branch.

 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 4b181969c432..869f462e6b6e 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -773,7 +773,8 @@ static blk_status_t nvme_setup_prp_simple(struct nvme_dev 
*dev,
struct bio_vec *bv)
 {
struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
-   unsigned int first_prp_len = dev->ctrl.page_size - bv->bv_offset;
+   unsigned int offset = bv->bv_offset & (dev->ctrl.page_size - 1);
+   unsigned int first_prp_len = dev->ctrl.page_size - offset;
 
iod->first_dma = dma_map_bvec(dev->dev, bv, rq_dma_dir(req), 0);
if (dma_mapping_error(dev->dev, iod->first_dma))
-- 
2.14.4

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


Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add kernel options for ZynqMP PL Programming

2019-10-18 Thread Quanyang Wang



On 10/18/19 2:16 PM, Michal Simek wrote:

On 17. 10. 19 16:58, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

Add kernel options for zynqmp FPGA programming.

Signed-off-by: Quanyang Wang 
---
  bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 4 
  1 file changed, 4 insertions(+)

diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg 
b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
index fe8ae24d..b87c2892 100644
--- a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
+++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
@@ -234,3 +234,7 @@ CONFIG_RESET_CONTROLLER=y
  
  CONFIG_PMBUS=y

  CONFIG_SENSORS_MAX20751=y
+
+CONFIG_OF_OVERLAY=y
+CONFIG_OF_CONFIGFS=y
+CONFIG_FPGA_MGR_DEBUG_FS=y


Just keep in your mind that configfs is out of mainline and it should be
used carefully.


Hi Michal,

OK. Thanks for your reminding.

Quanyang


M

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


Re: [linux-yocto] [PATCH 1/1] clk: zynqmp: fix memory leak in zynqmp_register_clocks

2019-10-18 Thread Quanyang Wang

Hi MIchal,

The steps are:

(1)

I use kernel source https://github.com/Xilinx/linux-xlnx.git 
xlnx_rebase_v4.19.


(2)

Enable kernel option:

Kernel hacking  ---> Memory Debugging  --->

[*] Kernel memory leak detector

(9000) Maximum kmemleak early log entries.

(3)

When the board boots, run the command as below:

echo scan > /sys/kernel/debug/kmemleak

Then cat /sys/kernel/debug/kmemleak.


I attached the log as zcu102.log. Using mainline and linux-yocto with 
enabling kmemleak can also reproduce the memory leak.


Thanks,

Quanyang

On 10/18/19 2:33 PM, Michal Simek wrote:

Hi,

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

From: Quanyang Wang 

This is detected by kmemleak running on zcu102 board:

unreferenced object 0xffc877e48180 (size 128):
comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s)
hex dump (first 32 bytes):
64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div
31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1...
backtrace:
[] __kmalloc_track_caller+0x200/0x380
[] kvasprintf+0x7c/0x100
[] kasprintf+0x60/0x80
[<92298b05>] zynqmp_register_clocks+0x29c/0x398
[] zynqmp_clock_probe+0x3cc/0x4c0
[<5f5986f0>] platform_drv_probe+0x58/0xa8
[] really_probe+0xd8/0x2a8
[] driver_probe_device+0x5c/0x100
[<38f91fcf>] __device_attach_driver+0x98/0xb8
[<8a3f2ac2>] bus_for_each_drv+0x74/0xd8
[<1cb2783d>] __device_attach+0xe0/0x140
[] device_initial_probe+0x24/0x30
[<6998de4b>] bus_probe_device+0x9c/0xa8
[<647ae6ff>] device_add+0x3c0/0x610
[<71c14bb8>] of_device_add+0x40/0x50
[<4bb5d132>] of_platform_device_create_pdata+0xbc/0x138

This is because that when num_nodes is larger than 1, clk_out is
allocated using kasprintf for these nodes but only the last node's
clk_out is freed.

Signed-off-by: Quanyang Wang 
---
  drivers/clk/zynqmp/clkc.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
index 64355fd07f6b..536f68c98e97 100644
--- a/drivers/clk/zynqmp/clkc.c
+++ b/drivers/clk/zynqmp/clkc.c
@@ -563,7 +563,7 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
  {
int j;
u32 num_nodes, clk_dev_id;
-   char *clk_out = NULL;
+   char *clk_out[MAX_NODES];
struct clock_topology *nodes;
struct clk_hw *hw = NULL;
  
@@ -577,16 +577,16 @@ static struct clk_hw *zynqmp_register_clk_topology(int clk_id, char *clk_name,

 * Intermediate clock names are postfixed with type of clock.
 */
if (j != (num_nodes - 1)) {
-   clk_out = kasprintf(GFP_KERNEL, "%s%s", clk_name,
+   clk_out[j] = kasprintf(GFP_KERNEL, "%s%s", clk_name,
clk_type_postfix[nodes[j].type]);
} else {
-   clk_out = kasprintf(GFP_KERNEL, "%s", clk_name);
+   clk_out[j] = kasprintf(GFP_KERNEL, "%s", clk_name);
}
  
  		if (!clk_topology[nodes[j].type])

continue;
  
-		hw = (*clk_topology[nodes[j].type])(clk_out, clk_dev_id,

+   hw = (*clk_topology[nodes[j].type])(clk_out[j], clk_dev_id,
parent_names,
num_parents,
&nodes[j]);
@@ -595,9 +595,12 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
 __func__,  clk_dev_id, clk_name,
 PTR_ERR(hw));
  
-		parent_names[0] = clk_out;

+   parent_names[0] = clk_out[j];
}
-   kfree(clk_out);
+
+   for (j = 0; j < num_nodes; j++)
+   kfree(clk_out[j]);
+
return hw;
  }
  


I have tried to replicated but didn't see this issue. Can you please
send me full boot log with steps you have done?

Thanks,
Michal
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 4.19.0-00085-gf0be99aa3709 (wrsadmin@pek-qwang2-d1) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ec9
[0.00] Machine model: ZynqMP ZCU102 Rev1.0
[0.00] earlycon: cdns0 at MMIO 0xff00 (options '')
[0.00] bootconsole [cdns0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 256 MiB at 0x6fc0
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling C