Re: [linux-yocto] [kernel-cache master/yocto-5.2][PATCH 0/1] xilinx-zynqmp: delete obsolete kernel options
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
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
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
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
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
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
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