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


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arch: arm64: dts: add overlay dts file

2019-10-15 Thread Bruce Ashfield
On Mon, Oct 14, 2019 at 6:19 AM Quanyang Wang
 wrote:
>
>
> On 10/14/19 6:00 PM, Michal Simek wrote:
> > On 14. 10. 19 11:34, Quanyang Wang wrote:
> >> On 10/14/19 3:58 PM, Michal Simek wrote:
> >>> On 14. 10. 19 9:55, Quanyang Wang wrote:
>  On 10/14/19 2:05 PM, Michal Simek wrote:
> > On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:
> >> From: MengLi 
> >>
> >> Add overlay dts file for updating FPGA bitstream file on
> >> zynqmp platform.
> >>
> >> Signed-off-by: Meng Li 
> >> Signed-off-by: Quanyang Wang 
> >> ---
> >>arch/arm64/boot/dts/xilinx/Makefile|  1 +
> >>.../dts/xilinx/zynqmp-zcu102-fpga-update.dts   | 18
> >> ++
> >>2 files changed, 19 insertions(+)
> >>create mode 100644
> >> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
> >>
> >> diff --git a/arch/arm64/boot/dts/xilinx/Makefile
> >> b/arch/arm64/boot/dts/xilinx/Makefile
> >> index bec4746fe721..d56c449988d0 100644
> >> --- a/arch/arm64/boot/dts/xilinx/Makefile
> >> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
> >> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-fpga-update.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
> >>dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
> >> diff --git
> >> a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
> >> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
> >> new file mode 100644
> >> index ..f1e1506b6210
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-fpga-update.dts
> >> @@ -0,0 +1,18 @@
> >> +// overlay dts file.
> >> +/dts-v1/;
> >> +/plugin/;
> >> +
> >> +/ {
> >> +fragment@0 {
> >> +target-path = "/fpga-full";
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +
> >> +__overlay__ {
> >> +#address-cells = <2>;
> >> +#size-cells = <2>;
> >> +
> >> +firmware-name = "system.bit.bin";
> >> +};
> >> +};
> >> +};
> >>
> > I understand what you want to do but not sure why you think that
> > this is
> > the best way how to do it.
>  Hi Michal,
> 
>  This patch is based on the url:
> 
>  https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841847/Solution+ZynqMP+PL+Programming#x-Programming+the+PL+through+Linux
> 
> 
>  "FPGA programming using Device Tree Overlay (DTO)".
> 
>  We will describe how to programming FPGA by using 2 methods in README
>  for our customer:
> 
>  one is FPGA programming using sysfs attributes
>  
> 
> 
>  And the other is FPGA programming using Device Tree Overlay (DTO)
>  
> 
> 
>  This patch is used for the second method.
> 
>  Is there any better way to do it?
> 
> >>> It is not about that using fragments is incorrect. It is about reasons
> >>> to include this dts file to Linux source code. Because this fragment is
> >>> just doing programming without anything else. It means it is coupled
> >>> with also description what it is in DT which is missing here.
> >>> It means this is just part A (with system.bit.bin generic name - which
> >>> is not fully accurate) and part B is missing.
> >>> In part B there should be what you are including with clock/reset and IP
> >>> part.
> >>> That's why my question remains if make even sense to merge part A
> >>> without any details about part B.
> >> Hi Michal,
> >>
> >> The target for this patch is to just simply test the FPGA programming
> >> function. So it changes nothing.
> >>
> >> It seems to be improper to add such a dts file to kernel source.
> >>
> >> I will transform the dts file to a text description in README or make it
> >> to be a more detailed and integral dts file in a V2 patch.
> > ok. let's see where you want to add this readme. If this targets
> > "Documentation" folder then not a problem at all.
>
> Hi Michal,
>
> Sorry for making you confuse. The README which I said about is not in
> kernel source but in WRLinux project.
>
> I mean that maybe I can just describe how to test FPGA programming in
> some place of our own Product Document

Just 

Re: [linux-yocto] [PATCH v5.2] pci: octeontx2: Use a more lightweight API to get the root bus

2019-10-14 Thread Bruce Ashfield
On Mon, Oct 14, 2019 at 4:56 AM Kevin Hao  wrote:
>
> In the current code, the API pci_get_domain_bus_and_slot() is used to
> get the root bus. But we would get the below call trace on rt kernel
> due to the spin_lock is used in the klist.
>   BUG: sleeping function called from invalid context at 
> kernel/locking/rtmutex.c:968
>   in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
>   3 locks held by swapper/0/1:
>#0: (ptrval) (per_cpu_ptr(_lock.lock, cpu)){}, at: 
> __device_driver_lock+0x34/0x60
>#1: (ptrval) (pci_lock){}, at: 
> pci_bus_write_config_word+0x40/0xa8
>#2: (ptrval) (>k_lock){+.+.}, at: klist_next+0x24/0x110
>   irq event stamp: 1293008
>   hardirqs last  enabled at (1293007): [] 
> _raw_spin_unlock_irqrestore+0xa8/0xb8
>   hardirqs last disabled at (1293008): [] 
> _raw_spin_lock_irqsave+0x38/0x80
>   softirqs last  enabled at (1032902): [] 
> raw_unhash_sk+0x74/0xb0
>   softirqs last disabled at (1032891): [] 
> raw_unhash_sk+0x0/0xb0
>   Preemption disabled at:
>   [] pci_bus_write_config_word+0x40/0xa8
>   CPU: 8 PID: 1 Comm: swapper/0 Not tainted 5.2.20-rt9-yocto-preempt-rt+ #12
>   Hardware name: Marvell OcteonTX CN96XX board (DT)
>   Call trace:
>dump_backtrace+0x0/0x140
>show_stack+0x24/0x30
>dump_stack+0xbc/0x104
>___might_sleep+0x16c/0x1d0
>rt_spin_lock+0x64/0x78
>klist_next+0x24/0x110
>bus_find_device+0x70/0xe0
>pci_get_dev_by_id+0x60/0x88
>pci_get_domain_bus_and_slot+0x5c/0xb0
>octeontx2_pem_config_write+0x84/0x3e0
>pci_bus_write_config_word+0x64/0xa8
>pci_write_config_word+0x44/0x68
>pci_setup_device+0x214/0x718
>pci_scan_single_device+0xb4/0xf8
>pci_scan_slot+0x44/0x108
>pci_scan_child_bus_extend+0x58/0x290
>pci_scan_bridge_extend+0x350/0x4f8
>pci_scan_child_bus_extend+0x1e4/0x290
>pci_scan_root_bus_bridge+0x60/0xd0
>pci_host_probe+0x20/0xb8
>pci_host_common_probe+0xf4/0x1f0
>octeontx2_pem_probe+0x2c/0x38
>platform_drv_probe+0x58/0xa8
>really_probe+0xe0/0x288
>driver_probe_device+0x5c/0xf0
>device_driver_attach+0x74/0x80
>__driver_attach+0x64/0xe0
>bus_for_each_dev+0x84/0xd8
>driver_attach+0x30/0x40
>bus_add_driver+0x190/0x1f0
>driver_register+0x64/0x110
>__platform_driver_register+0x54/0x60
>octeontx2_pem_driver_init+0x20/0x28
>do_one_initcall+0xa8/0x468
>kernel_init_freeable+0x514/0x5b8
>kernel_init+0x18/0x108
>ret_from_fork+0x10/0x1c
>
> Actually we can use a more lightweight API to get the rootbus without
> acquiring any lock, then fix this issue.
>
> Signed-off-by: Kevin Hao 
> ---
>
> Hi Bruce,
>
> Please help merge this to the following branches:
>
> linux-yocto:
>   v5.2/standard/cn96xx
>   v5.2/standard/preempt-rt/cn96xx

merged

>
> linux-yocto-dev:
>   standard/cn96xx

.. and merged. But I'm about a day away from replacing linux-yocto-dev
with v5.4-rc3, so be prepared that this will change shortly.

Bruce

>
>  drivers/pci/controller/pci-octeontx2-pem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-octeontx2-pem.c 
> b/drivers/pci/controller/pci-octeontx2-pem.c
> index 90b5537e8cdb..1e14dc065322 100644
> --- a/drivers/pci/controller/pci-octeontx2-pem.c
> +++ b/drivers/pci/controller/pci-octeontx2-pem.c
> @@ -335,10 +335,10 @@ static void octeontx2_be_workaround_init(struct pci_bus 
> *bus)
>  static void octeontx2_be_workaround(struct pci_bus *bus, int where,
> int size, u32 val)
>  {
> -   struct pci_dev *rc;
> +   struct pci_host_bridge *rc;
> u32 reg, be = 0;
>
> -   rc = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
> +   rc = pci_find_host_bridge(bus);
>
> /* Setup RAS to inject one error */
> octeontx2_be_workaround_init(rc->bus);
> --
> 2.14.4
>


-- 
- 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] [PATCH v5.2 rt] mmc: cavium-thunderx: Drop the IRQF_NO_THREAD constraint

2019-10-13 Thread Bruce Ashfield
In message: [PATCH v5.2 rt] mmc: cavium-thunderx: Drop the IRQF_NO_THREAD 
constraint
on 10/10/2019 Kevin Hao wrote:

> The IRQF_NO_THREAD is added by a Marvell SDK patch 238e623e1024 ("mmc:
> cavium: fix swiotlb buffer is full") in order to get back some of the
> performance loss. But in some cases (such as rt kernel), we do need the
> capability to thread irq handler. Otherwise we would get warnings because
> the normal spin lock is used in the irq handler. So drop this constraint.
> 
> Signed-off-by: Kevin Hao 
> ---
> Hi Bruce,
> 
> Please merge this to v5.2/standard/preempt-rt/cn96xx

merged

Bruce

> 
>  drivers/mmc/host/cavium-thunderx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/cavium-thunderx.c 
> b/drivers/mmc/host/cavium-thunderx.c
> index 7fbf33e34217..3afe788d0d9e 100644
> --- a/drivers/mmc/host/cavium-thunderx.c
> +++ b/drivers/mmc/host/cavium-thunderx.c
> @@ -49,7 +49,7 @@ static int thunder_mmc_register_interrupts(struct 
> cvm_mmc_host *host,
>   /* register interrupts */
>   for (i = 0; i < nvec; i++) {
>   ret = devm_request_irq(>dev, pci_irq_vector(pdev, i),
> -cvm_mmc_interrupt, IRQF_NO_THREAD,
> +cvm_mmc_interrupt, 0,
>  cvm_mmc_irq_names[i], host);
>   if (ret)
>   return ret;
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] tracing/arm64: Have max stack tracer handle the case of return address after data

2019-10-13 Thread Bruce Ashfield
merged

Bruce

In message: [PATCH v5.2] tracing/arm64: Have max stack tracer handle the 
case of return address after data
on 10/10/2019 Kevin Hao wrote:

> From: "Steven Rostedt (VMware)" 
> 
> commit f7edb451fa51e44e62177347ea7850aa0e901ea5 upstream
> 
> Most archs (well at least x86) store the function call return address on the
> stack before storing the local variables for the function. The max stack
> tracer depends on this in its algorithm to display the stack size of each
> function it finds in the back trace.
> 
> Some archs (arm64), may store the return address (from its link register)
> just before calling a nested function. There's no reason to save the link
> register on leaf functions, as it wont be updated. This breaks the algorithm
> of the max stack tracer.
> 
> Add a new define ARCH_FTRACE_SHIFT_STACK_TRACER that an architecture may set
> if it stores the return address (link register) after it stores the
> function's local variables, and have the stack trace shift the values of the
> mapped stack size to the appropriate functions.
> 
> Link: 20190802094103.163576-1-jiping@windriver.com
> 
> Reported-by: Jiping Ma 
> Acked-by: Will Deacon 
> Signed-off-by: Steven Rostedt (VMware) 
> Signed-off-by: Kevin Hao 
> ---
> Hi Bruce,
> 
> This fixes the issue that the stack usage can't be got from ftrace on
> arm64 arch.
> 
>  arch/arm64/include/asm/ftrace.h | 13 +
>  kernel/trace/trace_stack.c  | 14 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index 5ab5200b2bdc..d48667b04c41 100644
> --- a/arch/arm64/include/asm/ftrace.h
> +++ b/arch/arm64/include/asm/ftrace.h
> @@ -14,6 +14,19 @@
>  #define MCOUNT_ADDR  ((unsigned long)_mcount)
>  #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
>  
> +/*
> + * Currently, gcc tends to save the link register after the local variables
> + * on the stack. This causes the max stack tracer to report the function
> + * frame sizes for the wrong functions. By defining
> + * ARCH_FTRACE_SHIFT_STACK_TRACER, it will tell the stack tracer to expect
> + * to find the return address on the stack after the local variables have
> + * been set up.
> + *
> + * Note, this may change in the future, and we will need to deal with that
> + * if it were to happen.
> + */
> +#define ARCH_FTRACE_SHIFT_STACK_TRACER 1
> +
>  #ifndef __ASSEMBLY__
>  #include 
>  
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index 5d16f73898db..642a850af81a 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -158,6 +158,20 @@ static void check_stack(unsigned long ip, unsigned long 
> *stack)
>   i++;
>   }
>  
> +#ifdef ARCH_FTRACE_SHIFT_STACK_TRACER
> + /*
> +  * Some archs will store the link register before calling
> +  * nested functions. This means the saved return address
> +  * comes after the local storage, and we need to shift
> +  * for that.
> +  */
> + if (x > 1) {
> + memmove(_trace_index[0], _trace_index[1],
> + sizeof(stack_trace_index[0]) * (x - 1));
> + x--;
> + }
> +#endif
> +
>   stack_trace_nr_entries = x;
>  
>   if (task_stack_end_corrupted(current)) {
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] arm64: Remove unneeded rcu_read_lock from debug handlers

2019-10-13 Thread Bruce Ashfield
merged.

Bruce

In message: [PATCH v5.2] arm64: Remove unneeded rcu_read_lock from debug 
handlers
on 09/10/2019 Kevin Hao wrote:

> From: Masami Hiramatsu 
> 
> commit 760d8ed069c4e32a92e2ba251a3b0d9a87a3e771 upstream
> 
> Remove rcu_read_lock()/rcu_read_unlock() from debug exception
> handlers since we are sure those are not preemptible and
> interrupts are off.
> 
> Acked-by: Paul E. McKenney 
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Will Deacon 
> Signed-off-by: Kevin Hao 
> ---
> 
> This fixes a call trace when running the kgdb testcase.
> 
>  arch/arm64/kernel/debug-monitors.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/debug-monitors.c 
> b/arch/arm64/kernel/debug-monitors.c
> index f8719bd30850..48222a4760c2 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -207,16 +207,16 @@ static int call_step_hook(struct pt_regs *regs, 
> unsigned int esr)
>  
>   list = user_mode(regs) ? _step_hook : _step_hook;
>  
> - rcu_read_lock();
> -
> + /*
> +  * Since single-step exception disables interrupt, this function is
> +  * entirely not preemptible, and we can use rcu list safely here.
> +  */
>   list_for_each_entry_rcu(hook, list, node)   {
>   retval = hook->fn(regs, esr);
>   if (retval == DBG_HOOK_HANDLED)
>   break;
>   }
>  
> - rcu_read_unlock();
> -
>   return retval;
>  }
>  NOKPROBE_SYMBOL(call_step_hook);
> @@ -305,14 +305,16 @@ static int call_break_hook(struct pt_regs *regs, 
> unsigned int esr)
>  
>   list = user_mode(regs) ? _break_hook : _break_hook;
>  
> - rcu_read_lock();
> + /*
> +  * Since brk exception disables interrupt, this function is
> +  * entirely not preemptible, and we can use rcu list safely here.
> +  */
>   list_for_each_entry_rcu(hook, list, node) {
>   unsigned int comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
>  
>   if ((comment & ~hook->mask) == hook->imm)
>   fn = hook->fn;
>   }
> - rcu_read_unlock();
>  
>   return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
>  }
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] arm64: Remove unneeded rcu_read_lock from debug handlers

2019-10-13 Thread Bruce Ashfield
merged.

Bruce

In message: [PATCH v5.2] arm64: Remove unneeded rcu_read_lock from debug 
handlers
on 09/10/2019 Kevin Hao wrote:

> From: Masami Hiramatsu 
> 
> commit 760d8ed069c4e32a92e2ba251a3b0d9a87a3e771 upstream
> 
> Remove rcu_read_lock()/rcu_read_unlock() from debug exception
> handlers since we are sure those are not preemptible and
> interrupts are off.
> 
> Acked-by: Paul E. McKenney 
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Will Deacon 
> Signed-off-by: Kevin Hao 
> ---
> 
> This fixes a call trace when running the kgdb testcase.
> 
>  arch/arm64/kernel/debug-monitors.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/debug-monitors.c 
> b/arch/arm64/kernel/debug-monitors.c
> index f8719bd30850..48222a4760c2 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -207,16 +207,16 @@ static int call_step_hook(struct pt_regs *regs, 
> unsigned int esr)
>  
>   list = user_mode(regs) ? _step_hook : _step_hook;
>  
> - rcu_read_lock();
> -
> + /*
> +  * Since single-step exception disables interrupt, this function is
> +  * entirely not preemptible, and we can use rcu list safely here.
> +  */
>   list_for_each_entry_rcu(hook, list, node)   {
>   retval = hook->fn(regs, esr);
>   if (retval == DBG_HOOK_HANDLED)
>   break;
>   }
>  
> - rcu_read_unlock();
> -
>   return retval;
>  }
>  NOKPROBE_SYMBOL(call_step_hook);
> @@ -305,14 +305,16 @@ static int call_break_hook(struct pt_regs *regs, 
> unsigned int esr)
>  
>   list = user_mode(regs) ? _break_hook : _break_hook;
>  
> - rcu_read_lock();
> + /*
> +  * Since brk exception disables interrupt, this function is
> +  * entirely not preemptible, and we can use rcu list safely here.
> +  */
>   list_for_each_entry_rcu(hook, list, node) {
>   unsigned int comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
>  
>   if ((comment & ~hook->mask) == hook->imm)
>   fn = hook->fn;
>   }
> - rcu_read_unlock();
>  
>   return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
>  }
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [linux-yocto v5.2][PATCH 0/3] iwlwifi/mvm related patches from mainline kernel

2019-10-09 Thread Bruce Ashfield


In message: [linux-yocto][linux-yocto v5.2][PATCH 0/3] iwlwifi/mvm related 
patches from mainline kernel
on 09/10/2019 Yongxin Liu wrote:

> Hi Bruce,
> 
> Those three patches are from mainline kernel without any change.
> They exist since v5.3-rc4. Please help to backport to linux-yocto v5.2.
> 
> The second commit fixes the following calltrace.
> 
>   Call Trace:
> dump_stack+0x4f/0x6a
> ? worker_thread+0xd9/0x3e0
> ___might_sleep.cold+0xd1/0xe2
> __might_sleep+0x4b/0x80
> mutex_lock+0x21/0x50
> iwl_mvm_rs_rate_init+0x87/0xc50 [iwlmvm]

merged.

Bruce

> 
> Gregory Greenman (3):
>   iwlwifi: mvm: add a wrapper around rs_tx_status to handle locks
>   iwlwifi: mvm: replace RS mutex with a spin_lock
>   iwlwifi: mvm: fix possible out-of-bounds read when accessing lq_info
> 
>  drivers/net/wireless/intel/iwlwifi/mvm/rs.c  | 542 
> ++-
>  drivers/net/wireless/intel/iwlwifi/mvm/rs.h  |   6 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/sta.c |   6 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/sta.h |   1 -
>  4 files changed, 275 insertions(+), 280 deletions(-)
> 
> -- 
> 2.14.4
> 
> 
> Thanks,
> Yongxin
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] arm: dts: zynq: update coresight device node

2019-10-09 Thread Bruce Ashfield
On Wed, Oct 9, 2019 at 9:39 AM Michal Simek  wrote:
>
> Hi,
>
> On 09. 10. 19 4:38, quanyang.w...@windriver.com wrote:
> > From: Quanyang Wang 
> >
> > Using new compatible value for funnel and replicator device nodes,
> > and use correct unit-address.
> >
> > Signed-off-by: Quanyang Wang 
> > ---
> >  arch/arm/boot/dts/zynq-7000.dtsi | 14 +++---
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi 
> > b/arch/arm/boot/dts/zynq-7000.dtsi
> > index 5602f4f3ad1c..9b8f46d25d38 100644
> > --- a/arch/arm/boot/dts/zynq-7000.dtsi
> > +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> > @@ -447,8 +447,8 @@
> >   };
> >   };
> >
> > - funnel@0,f8804000 {
> > - compatible = "arm,coresight-funnel", "arm,primecell";
> > + funnel@f8804000 {
> > + compatible = "arm,coresight-static-funnel", 
> > "arm,primecell";
> >   reg = <0xf8804000 0x1000>;
> >   clocks = < 27>, < 46>, < 47>;
> >   clock-names = "apb_pclk", "dbg_trc", "dbg_apb";
> > @@ -503,7 +503,7 @@
> >   };
> >
> >   replicator {
> > - compatible = "arm,coresight-replicator";
> > + compatible = "arm,coresight-static-replicator";
> >   clocks = < 27>, < 46>, < 47>;
> >   clock-names = "apb_pclk", "dbg_trc", "dbg_apb";
> >
> > @@ -536,8 +536,8 @@
> >   };
> >   };
> >
> > - itm@0,f8805000 {
> > - compatible = "arm,coresight-etm3x", "arm,primecell";
> > + /* ITM is not supported by kernel, only leave device node 
> > here */
> > + itm@f8805000 {
> >   reg = <0xf8805000 0x1000>;
> >   clocks = < 27>, < 46>, < 47>;
> >   clock-names = "apb_pclk", "dbg_trc", "dbg_apb";
> > @@ -549,7 +549,7 @@
> >   };
> >   };
> >
> > - ptm@0,f889c000 {
> > + ptm@f889c000 {
> >   compatible = "arm,coresight-etm3x", "arm,primecell";
> >   reg = <0xf889c000 0x1000>;
> >   clocks = < 27>, < 46>, < 47>;
> > @@ -562,7 +562,7 @@
> >   };
> >   };
> >
> > - ptm@0,f889d000 {
> > + ptm@f889d000 {
> >   compatible = "arm,coresight-etm3x", "arm,primecell";
> >   reg = <0xf889d000 0x1000>;
> >   clocks = < 27>, < 46>, < 47>;
> >
>
>
> I don't think this is enough. I have attached the patch against mainline
> how I think it should look like.

Crap. I was a minute too early. I've reverted what I queued and will
wait for a v2.

Bruce

>
> M
>


-- 
- 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] [kernel v5.2/standard/xlnx-soc][PATCH 0/2] patches for zynq

2019-10-09 Thread Bruce Ashfield


In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/2] patches for 
zynq
on 09/10/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce, Michal,
> 
> There are 2 patches. One is fixing compile warning which is triggered by
> new version gcc 9.2.0. And the other is changed according to Michal's
> suggestions.
> 
> Would you please help review and merge these patches to linux-yocto 
> v5.2/standard/xlnx-soc branch?

They look fine to me, so I've pushed them to the branch.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (2):
>   arm: zynq: delete AFLAGS_suspend.o to fix compile warning
>   arm: dts: zynq: update coresight device node
> 
>  arch/arm/boot/dts/zynq-7000.dtsi | 14 +++---
>  arch/arm/mach-zynq/Makefile  |  1 -
>  2 files changed, 7 insertions(+), 8 deletions(-)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH][v5.2/standard/preempt-rt/base] printk: devkmsg: read: Return EPIPE when the first message user-space wants has gone

2019-10-02 Thread Bruce Ashfield
I didn't merge this directly, but instead updated the -rt branches to
-rt9 .. so I got your change that way.

Cheers,

Bruce

On Sun, Sep 29, 2019 at 5:36 AM  wrote:
>
> From: He Zhe 
>
> This fixes ltp failure,
> kmsg01.c:444: FAIL: read returned: 56: SUCCESS
>
> When user-space wants to read the first message, that is when user->seq
> is 0, and that message has gone, it currently automatically resets
> user->seq to current first seq. This mis-aligns with mainline kernel.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/dev-kmsg#n39
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n899
>
> We should inform user-space that what it wants has gone by returning EPIPE
> in such scenario.
>
> Link: https://lore.kernel.org/linux-rt-users/8736gls1aj@linutronix.de/T/#t
>
> Signed-off-by: He Zhe 
> ---
>  kernel/printk/printk.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e3fa33f..58c545a 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -703,14 +703,10 @@ static ssize_t devkmsg_read(struct file *file, char 
> __user *buf,
> goto out;
> }
>
> -   if (user->seq == 0) {
> -   user->seq = seq;
> -   } else {
> -   user->seq++;
> -   if (user->seq < seq) {
> -   ret = -EPIPE;
> -   goto restore_out;
> -   }
> +   user->seq++;
> +   if (user->seq < seq) {
> +   ret = -EPIPE;
> +   goto restore_out;
> }
>
> msg = (struct printk_log *)>msgbuf[0];
> --
> 2.7.4
>


-- 
- 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] [PATCH] powerpc/603: Fix handling of the DIRTY flag

2019-09-24 Thread Bruce Ashfield


In message: [linux-yocto][PATCH] powerpc/603: Fix handling of the DIRTY flag
on 24/09/2019 zhe...@windriver.com wrote:

> From: Christophe Leroy 
> 
> commit 415480dce2ef03bb8335deebd2f402f475443ce0 upstream
> 
> If a page is already mapped RW without the DIRTY flag, the DIRTY
> flag is never set and a TLB store miss exception is taken forever.
> 
> This is easily reproduced with the following app:
> 
> void main(void)
> {
>   volatile char *ptr = mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED | 
> MAP_ANONYMOUS, -1, 0);
> 
>   *ptr = *ptr;
> }
> 
> When DIRTY flag is not set, bail out of TLB miss handler and take
> a minor page fault which will set the DIRTY flag.
> 
> Fixes: f8b58c64eaef ("powerpc/603: let's handle PAGE_DIRTY directly")
> Cc: sta...@vger.kernel.org # v5.1+
> Reported-by: Doug Crawford 
> Signed-off-by: Christophe Leroy 
> Signed-off-by: Michael Ellerman 
> Link: 
> https://lore.kernel.org/r/80432f71194d7ee75b2f5043ecf1501cf1cca1f3.1566196646.git.christophe.le...@c-s.fr
> Signed-off-by: He Zhe 
> ---
> This is for v5.2/standard/fsl-mpc8315e-rdb. It fixes potential system hang
> without any direct warning or error which has not been observed on qemuppc.
> 
> It has not been ported to stable tree.

but at least is has been cc'd to stable. I'll watch for it to show up in my
future 5.2 -stabe updates.

Cheers,

Bruce

> 
>  arch/powerpc/kernel/head_32.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> index f255e22..534dd27 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -557,9 +557,9 @@ DataStoreTLBMiss:
>   cmplw   0,r1,r3
>   mfspr   r2, SPRN_SPRG_PGDIR
>  #ifdef CONFIG_SWAP
> - li  r1, _PAGE_RW | _PAGE_PRESENT | _PAGE_ACCESSED
> + li  r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED
>  #else
> - li  r1, _PAGE_RW | _PAGE_PRESENT
> + li  r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT
>  #endif
>   bge-112f
>   lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
> use */
> -- 
> 2.7.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/3] patches for zynq7000

2019-09-24 Thread Bruce Ashfield


In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/3] patches for 
zynq7000
on 23/09/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce,
> 
> Would you please help merge these patches to linux-yocto 
> v5.2/standard/xlnx-soc branch?

These are now merged.

Are these changes already done upstream, or applicable to upstream ? I just
want to make sure we aren't only fixes these in the yocto kernel when there
are other places that we can fix as well.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (2):
>   ARM: dts: zc702: Fix I2C bus warnings
>   mmc: sdhci-of-arasan: Fix the incorrect soft reset operation when
> runtime resuming
> 
> Zumeng Chen (1):
>   arm: dts: zynq: enablement of coresight topology
> 
>  arch/arm/boot/dts/zynq-7000.dtsi   | 155 +
>  arch/arm/boot/dts/zynq-zc702.dts   |  12 +--
>  drivers/mmc/host/sdhci-of-arasan.c |   2 +-
>  3 files changed, 162 insertions(+), 7 deletions(-)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] cn96xx: Another patch series for the cn96xx SoC support

2019-09-24 Thread Bruce Ashfield


In message: [PATCH v5.2] cn96xx: Another patch series for the cn96xx SoC support
on 23/09/2019 Kevin Hao wrote:

> Hi Bruce,
> 
> Here is another patch series got from Marvell for the cn96xx SoC support.
> It mainly include some fixes for the mmc and Ethernet. Please help me
> merge this into both v5.2/standard/cn96xx and v5.2/standard/preempt-rt/cn96xx 
> branch.
> 
> The following changes since commit d186856ba1914ca0fbf715fe9b0f31067dd517a4:
> 
>   mmc: cavium: Drop the aligned check for the dma address (2019-09-20 
> 00:23:49 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/haokexin/linux v5.2/standard/cn96xx

merged

To ssh://git.yoctoproject.org/linux-yocto.git
   d186856ba191..8ddd7904ae8f  v5.2/standard/cn96xx -> v5.2/standard/cn96xx
   11c5ad93ebda..07da8f9ebdf6  v5.2/standard/preempt-rt/cn96xx -> 
v5.2/standard/preempt-rt/cn96xx
  
Bruce

> 
> for you to fetch changes up to 8ddd7904ae8f42c95c7b13bb877e663d39e802ac:
> 
>   octeontx2-af: Add T98 devid to PTP id table (2019-09-23 17:02:17 +0800)
> 
> 
> Christina Jacob (2):
>   octeontx2-pf: Disply the link detected status in ethtool command
>   net: thunderx: Do a PCS reset upon SGMII link toggle
> 
> Geetha sowjanya (1):
>   octeontx2-pf: Ignore NPC parser layer errors
> 
> Hao Zheng (2):
>   octeontx2-af: add parser support for DSA, extended DSA and eDSA
>   octeontx2-af: combine LB_STAG and LB_QINQ to one LB ltype
> 
> Peter Swain (4):
>   mmc: cavium: reorganize before vqmmc switching
>   mmc: cavium: slot switch by vqmmc/gpio
>   mmc: cavium: do not drop bus lock in tuning
>   mmc: cavium: use calibrated timing taps
> 
> Subbaraya Sundeep (8):
>   octeontx2-pf: Fix memory leaks
>   octeontx2-af: Change message level to debug
>   octeontx2-af: Enable odd number of AF VFs also
>   octeontx2-pf: Use helper function for LBK VF
>   octeontx2-af: Use nix_smq_flush function
>   octeontx2-af: Always enable mcam rules for TX
>   octeontx2-af: Transmit packets during SMQ flush
>   octeontx2-pf: Add barrier to sync interface status
> 
> Sunil Goutham (8):
>   octeontx2-af: Fix programming and logical issues
>   octeontx2-pf: Fix VF id in the FLR handler
>   octeontx2-pf: Fix interface init and shutdown sequence
>   octeontx2-pf: Use post increment STP to free pointers to Aura
>   octeontx2-pf: Add debug messages for MSIX alloc failure
>   arm64: Increase NR_IRQS to a large number
>   octeontx2-af: Fix compilation issue
>   octeontx2-pf: Fix memory leak while freeing SQBs
> 
> Tomasz Michalec (1):
>   octeontx2-af: Add T98 devid to PTP id table
> 
> Vidhya Vidhyaraman (1):
>   octeontx2-af: Add programmed macaddr to RVU pfvf
> 
>  Documentation/devicetree/bindings/mmc/cavium-mmc.txt  |  10 +-
>  arch/arm64/include/asm/irq.h  |   9 ++
>  drivers/mmc/host/cavium-thunderx.c|  97 ++---
>  drivers/mmc/host/cavium.c | 227 
> -
>  drivers/mmc/host/cavium.h |   7 +-
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.c |  35 ++---
>  drivers/net/ethernet/marvell/octeontx2/af/cgx.c   |   6 +-
>  drivers/net/ethernet/marvell/octeontx2/af/mbox.c  |   2 +-
>  drivers/net/ethernet/marvell/octeontx2/af/npc.h   |   9 +-
>  drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h   | 731 
> +---
>  drivers/net/ethernet/marvell/octeontx2/af/ptp.c   |   4 +
>  drivers/net/ethernet/marvell/octeontx2/af/rvu.c   |  12 --
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c   |  26 ++--
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c   |  23 ++-
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_fixes.c |  14 ++
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_fixes.h |  21 +++
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c   |  26 ++--
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c   |  17 +--
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c|  15 +-
>  drivers/net/ethernet/marvell/octeontx2/nic/Makefile   |   2 +-
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c  |  49 ++-
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h  |  29 ++--
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c |  33 -
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c  |  57 +---
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_smqvf.c   | 291 
> +
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c|   9 ++
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h|   6 +-
>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c  |  32 ++--
>  28 

Re: [linux-yocto] [kernel-cache][PATCH 0/1] xilinx-zynq: enable coresight and xadc kernel options for xilinx-zynq bsp

2019-09-24 Thread Bruce Ashfield


In message: [linux-yocto][kernel-cache][PATCH 0/1] xilinx-zynq: enable 
coresight and xadc kernel options for xilinx-zynq bsp
on 23/09/2019 quanyang.w...@windriver.com wrote:

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

merged.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (1):
>   xilinx-zynq: enable coresight and xadc kernel options for xilinx-zynq
> bsp
> 
>  bsp/xilinx-zynq/xilinx-zynq.cfg | 9 +
>  1 file changed, 9 insertions(+)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.45

2019-09-23 Thread Bruce Ashfield
On Sat, Sep 21, 2019 at 2:37 PM Paul Gortmaker 
wrote:

> Bruce, Yocto kernel folks:
>
> Here is the *final* 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.44 release.
>
> This final release closes out a run of 25 releases and about 4600
> backports since GregKH stopped maintenance at v4.18.20, just under a
> year ago.  I hope people have found the update extentsions useful during
> that period; both Yocto users and "vanilla" 4.18.x users alike.
>
> I didn't send an announce for 4.18.44, since I wanted to finish this
> 4.18.x run with the addition of the recent spectre-v1 (swapgs) variant
> fixes.  But I wanted to also keep them separate to ease testing and
> evaluation for integrators.  So the 44 is "normal" content, and the 45
> is specific to spectre-v1/swapgs content, basically.
>
> More specifically, the 4.18.44 release contains about 235 mainline
> commits based on what was found in 4.19.51 --> 4.19.55 stable content.
>
> The 4.18.45 release contains the swapgs (CVE-2019-1125) content, plus a
> couple powerpc CVE fixes that caught my eye.  The x86 users can check:
>
>  # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
>  Mitigation: usercopy/swapgs barriers and __user pointer sanitization
>
> Check Documentation/admin-guide/hw-vuln/spectre.rst for more info.
>
> I've put this *final* 4.18.45 queue through the usual testing; build
>

final tag merged!!

Bruce



> testing on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> and finally some sanity runtime tests on x86-64.  The 4.18.44 release
> also got the same independent testing prior to starting 4.18.45.
>
> I did the signed tag just as per the previously released versions.
> Please find a signed v4.18.45 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
>
> for merge to standard/base in linux-yocto-4.18 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.18.x release.
>
> Paul.
>


-- 
- 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] : [kernel v5.2/standard/bcm-2xxx-rpi]: bcm-2xxx-rpi: add patches for improving raspberrypi 4b platform

2019-09-19 Thread Bruce Ashfield


In message: [linux-yocto]: [kernel v5.2/standard/bcm-2xxx-rpi]: bcm-2xxx-rpi: 
add patches for improving raspberrypi 4b platform
on 17/09/2019 meng...@windriver.com wrote:

> From: Limeng 
> 
> Hi Bruce,
> 
> I am working on BSP bcm-2xxx-rpi platform, and intend to merge this BSP 
> supporting into yocto community.
> Some days ago, I submit a pull request for this BSP.
> Now, there are still 81 below patches for improve this BSP
> 
> Could you please help to merge the 81 patches into linux-ycoto-5.2 kernel, 
> branch v5.2/standard/bcm-2xxx-rpi?

I've pulled the branch into linux-yocto v5.2/standard/bcm-2xxx-rpi.

I assume that this branch contains the contents of your other pull request as
well, so I haven't done anything more that fetch and merge what you have
in this request.

If that is not correct, send more patches and pull requests to the list.

Bruce


> 
> 
> The following changes since commit 69ce9ac46cd152ce73456e8cca5520e3cb0d6157:
> 
>   build/arm64: Add rules for .dtbo files for dts overlays (2019-09-16 
> 14:50:55 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/limeng-linux/linux-yocto-5.2.git 
> v5.2/standard/bcm-2xxx-rpi
> 
> for you to fetch changes up to 4b7ea76eac44bb3d07b53d24cbe578c47a074b93:
> 
>   arm64: dma-mapping: Fix IOMMU breakage (2019-09-17 18:49:42 +0800)
> 
> 
> Aman Gupta (2):
>   staging: bcm2835-codec: add support for 
> V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
>   staging: bcm2835-codec: remove unnecessary padding on encoder input
> 
> Chen-Yu Tsai (3):
>   staging: bcm2835-codec: switch to multi-planar API
>   staging: bcm2835-codec: implement V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
>   staging: bcm2835-codec: set device_caps in struct video_device
> 
> Dave Stevenson (24):
>   staging: bcm2835_camera: Ensure all buffers are returned on disable
>   drm/vc4: Query firmware for custom HDMI mode
>   drm/vc4: Pass the drm vrefresh to the firmware on mode set
>   drm/vc4: Add support for margins to fkms
>   drm/vc4: Ensure zpos is always initialised
>   drm/vc4: Add "Broadcast RGB" connector property
>   drm/vc4: fkms: Set default state margin at reset
>   drm/modes: Don't apply cmdline's rotation if it wasn't specified
>   configs: Add CONFIG_FRAMEBUFFER_CONSOLE_ROTATION to Pi configs
>   drm/vc4: Resolve the vblank warnings on mode switching
>   drm/vc4: Remove unused mode variable
>   staging:bcm2835-codec: Expand logging on format setting
>   staging: bcm2835-codec: Correct bytesperline on format changed
>   drm/vc4: Add missing NULL check to vc4_crtc_consume_event
>   media: dt-bindings: Add binding for the Sony IMX219 sensor
>   media: i2c: Add driver for Sony IMX219 sensor
>   defconfigs: Add Sony IMX219 driver to RPi defconfigs
>   dtoverlays: Add overlay for the Sony IMX219 image sensor.
>   overlays: mcp23017: rename the GPIO pins node with the device
>   overlays: mcp23017: Add option for not connecting the int GPIO
>   v4l2: Add a Greyworld AWB mode.
>   staging: bcm2835-camera: Add greyworld AWB mode
>   staging: bcm2835-codec: Allow height of 1920.
>   staging: bcm2835-codec: Correct g/s_selection API MPLANE support
> 
> James Hughes (3):
>   Fixup FKMS interrupt handing for non-existent display
>   Add HDMI1 facility to the driver.
>   drm/vc4: Fix for margins in composite/SDTV mode (#3223)
> 
> Joerg Schambacher (1):
>   adds the Hifiberry DAC+ADC PRO version
> 
> Jonathan Bell (3):
>   dts: bcm2838: add missing properties for pmu and gic nodes
>   hid: usb: Add device quirks for Freeway Airmouse T3 and MX3
>   xhci: Use more event ring segment table entries
> 
> Jörg Schambacher (1):
>   Add Hifiberry DAC+DSP soundcard driver (#3224)
> 
> Kieran Bingham (7):
>   staging: bcm2835-codec: Fix non-documentation comment block
>   staging: bcm2835-codec: Fix declaration of roles
>   staging: bcm2835-codec: Add role to device name
>   staging: bcm2835-codec: Pass driver context to create entities
>   staging: bcm2835-codec: add media controller support
>   media: bcm2835: unicam: Reduce scope of local function
>   media: bcm2835: unicam: add media controller support
> 
> Maxime Ripard (8):
>   drm/connector: Add documentation for drm_cmdline_mode
>   drm/modes: Rewrite the command line parser
>   drm/modes: Support modes names on the command line
>   drm/modes: Allow to specify rotation and reflection on the commandline
>   drm/connector: Introduce a TV margins structure
>   drm/modes: Parse overscan properties
>   drm/atomic: Add a function to reset connector TV properties
>   drm/vc4: hdmi: Set default state margin at reset
> 
> P33M (1):
>   dwc_otg: use align_buf for small IN control transfers (#3150)
> 
> Phil Elwell (20):
>   overlays: audremap: Support GPIOs 18 & 

Re: [linux-yocto] [PATCH 0/2 v5.2] Add the RT support for the cn96xx

2019-09-19 Thread Bruce Ashfield
In message: [PATCH 0/2 v5.2] Add the RT support for the cn96xx
on 19/09/2019 Kevin Hao wrote:

> From: Kevin Hao 
> 
> This patch series adds the RT support for the Marvell cn96xx SoC. It
> includes the kernel and kernel cache patches. All the kernel patches
> except the following have already been merged into the v5.2/standard/cn96xx 
> branch.
> 
> 1. The patch 77eaa178a3f8 ("mmc: cavium: Drop the aligned check for the dma 
> address")
>This is a new patch and also has been sent to the linux-yocto for the
>merging into v5.2/standard/cn96xx branch.
> 
> 2. The patch 088d9e94823e ("arm64: Enlarge the FORCE_MAX_ZONEORDER on the 
> Cavium SoC for RT:)
>This is a workaround for the bootloader setting a too big coheret_pool
>for the kernel.

My tree was in a slightly different state, so it was easier for me
to manually create the new branch, and then merge the standard kernel
BSP into it.

That included the patch you sent earlier, and I've cherry picked the
other from your github branch.

Cheers,

Bruce

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


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/2] fix compile warning

2019-09-19 Thread Bruce Ashfield


In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/2] fix compile 
warning
on 19/09/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce,
> 
> Would you please help me merge the two patches into
> linux-ycoto-5.2 kernel, branch v5.2/standard/xlnx-soc ?

These are now merged.

Bruce

> 
> Thanks,
> Quanyang
> 
> Quanyang Wang (2):
>   mtd: spi-nor: change flash_info.flags from u16 to u32 to avoid compile
> warning
>   spi: spi-mem: zynq-qspi: add is-dual support for zc706 board
> 
>  drivers/mtd/spi-nor/spi-nor.c |  2 +-
>  drivers/spi/spi-zynq-qspi.c   | 43 +--
>  2 files changed, 42 insertions(+), 3 deletions(-)
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH v5.2] mmc: cavium: Drop the aligned check for the dma address

2019-09-19 Thread Bruce Ashfield


In message: [PATCH v5.2] mmc: cavium: Drop the aligned check for the dma 
address
on 19/09/2019 Kevin Hao wrote:

> From: Kevin Hao 
> 
> In commit 73c1489f17e8 ("mmc: cavium: forbid unaligned DMA"), the codes
> are added to check the unaligned dma request. But at that time,
> we still don't do the dma map for the scatterlist yet. So it is
> meaningless to check the dma address. So drop of it.
> 
> Signed-off-by: Kevin Hao 
> ---
> 
> Hi Bruce,
> 
> This targets for standard/cn96xx branch.

Merged to v5.2 and linux-yocto-dev

Bruce

> 
>  drivers/mmc/host/cavium.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
> index fc6464957df9..d724155d7eb6 100644
> --- a/drivers/mmc/host/cavium.c
> +++ b/drivers/mmc/host/cavium.c
> @@ -853,7 +853,7 @@ static void cvm_mmc_dma_request(struct mmc_host *mmc,
>   /* unaligned multi-block DMA has problems, so forbid all unaligned */
>   for (seg = 0; seg < mrq->data->sg_len; seg++) {
>   struct scatterlist *sg = >data->sg[seg];
> - u64 align = (sg->offset | sg->length | sg->dma_address);
> + u64 align = (sg->offset | sg->length);
>  
>   if (!(align & 7))
>   continue;
> -- 
> 2.14.4
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [kernel-cache master] ti-am335x: add CPU freq/idle support and correct arch bits

2019-09-19 Thread Bruce Ashfield
In message: [linux-yocto] [kernel-cache master] ti-am335x: add CPU freq/idle 
support and correct arch bits
on 16/09/2019 Jun Miao wrote:

> 
> 
> Hi Bruce.
>Please help me merge the two patches to master branch of yocto-kernel-cache


merged to master.

Bruce

> 
>5721cc33a0511c5964e96f439b61b97d20e500d7 ti-am335x: add CPU Freq/Idle 
> support
>15fed008b84b8ef7ae760227d750f8840d635e43 ti-am335x: correct the arch 
> 64-bit to 32-bit
> 
> 
> Jun Miao (2):
>   ti-am335x: correct the arch 64-bit to 32-bit
>   ti-am335x: add CPU Freq/Idle support
> 
>  bsp/ti-am335x/ti-am335x-standard.scc |  2 +-
>  bsp/ti-am335x/ti-am335x.cfg  | 21 +
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> -- 
> 2.22.0
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] : [kernel-cache master/yocto-5.2]: bcm-2xxx-rpi: add configure file for bcm-2xxx-rpi BSP in kernel-cache

2019-09-19 Thread Bruce Ashfield
In message: [linux-yocto]: [kernel-cache master/yocto-5.2]: bcm-2xxx-rpi: add 
configure file for bcm-2xxx-rpi BSP in kernel-cache
on 16/09/2019 meng...@windriver.com wrote:

> From: Limeng 
> 
> Hi Bruce,
> 
> I am working on BSP bcm-2xxx-rpi platform, and intend to merge this BSP 
> supporting into yocto community.
> Below patch includes scc and cfg files for Raspberrypi 4b platform.
> 
> Could you please merge this patch into yocto-kernel-cache, branch is master 
> and yocto-5.2?

The baseline configuration looks sane to me (I checked for obvious errors and
non hardware configs).

So I've gone ahead and merged this to the 5.2 and master branches.

Bruce

> 
> 0001-bcm-2xxx-rpi-add-configure-file-for-bcm-2xxx-rpi-BSP.patch
> 
>  bcm-2xxx-rpi.cfg |  268 
> +++
>  bcm-2xxx-rpi.scc |   13 ++
>  bcm-2xxx-rpi4-preempt-rt.scc |8 +
>  bcm-2xxx-rpi4-standard.scc   |9 +
>  4 files changed, 298 insertions(+)
> 
> 
> thanks,
> Limeng
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.43

2019-09-14 Thread Bruce Ashfield
On Thu, Sep 12, 2019 at 5:06 PM Paul Gortmaker
 wrote:
>
> Bruce, Yocto kernel folks:
>
> Here is the next 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.42 release.
>
> There are about 125 commits here, based on the commits that were used
> in the 4.19.[48/49/50] linux-stable releases.
>
> A note to distro builders - normally there are no new Kconfig options
> in stable, but here there is a new "NOUVEAU_LEGACY_CTX_SUPPORT" option.
> The upstream decided that the easiest solution to avoid potential
> security issues with the legacy code was to provide a way for distro
> builders to opt out.  But it remains enabled by default so as to not
> break any exising users who rely on it.
>
> I suspect I'll have time to do one more final 4.18 stable backport
> release.  Hopefully with the EOL messaging being in the last few
> releases, this is no surprise to anyone, and people have their own
> maintenance or migration plans in place and rolled out.

Thanks Paul,

We'll see if anyone else reads this part of the release message :D

This is now merged.

Bruce

>
> I've put this 4.18.x queue through the usual testing; build testing
> on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> and finally some sanity runtime tests on x86-64.
>
> I did the signed tag just as per the previously released versions.
> Please find a signed v4.18.43 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
>
> for merge to standard/base in linux-yocto-4.18 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.18.x release.
>
> Paul.



-- 
- 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] [kernel-cache][yocto-5.2] Add NUMA node number and enable NUMA balancing

2019-09-09 Thread Bruce Ashfield
On Fri, Sep 6, 2019 at 3:12 AM Yongxin Liu  wrote:
>
> Hi Bruce,
>
> The follow two patches were merged to master branch of yocto-kernel-cache.
>
> 07aeebc4cefbfa4f56a640917355ada547586b60 bsp/intel-x86: Enable NUMA balancing 
> for intel-x86-64
> 09126d352f7092f8bfe0f79128d7d1aa3b262c53 bsp/intel-x86: Set 
> CONFIG_NODES_SHIFT to 6
>
> Please help to merge them to yocto-5.2 branch.

These are now merged.

I'll send SRCREV updates along with the 5.2 -stable updates I have pending.

Bruce

>
>
> 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: [linux-yocto] [kernel-cache yocto-5.2] nxp-ls20xx: add kernel-cache configuration files for BSP nxp-ls20xx

2019-09-05 Thread Bruce Ashfield
merged.

Bruce

In message: [linux-yocto] [kernel-cache yocto-5.2] nxp-ls20xx: add kernel-cache 
configuration files for BSP nxp-ls20xx
on 04/09/2019 Xulin Sun wrote:

> This adds the cfg & scc files to support the LS2088A-RDB.
> 
> Signed-off-by: Xulin Sun 
> ---
>  bsp/nxp-ls20xx/nxp-ls20xx-standard.scc |   8 ++
>  bsp/nxp-ls20xx/nxp-ls20xx.cfg  | 162 +
>  bsp/nxp-ls20xx/nxp-ls20xx.scc  |   7 ++
>  3 files changed, 177 insertions(+)
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx.cfg
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx.scc
> 
> diff --git a/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc 
> b/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
> new file mode 100755
> index ..e0d9b2b7
> --- /dev/null
> +++ b/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
> @@ -0,0 +1,8 @@
> +define KMACHINE nxp-ls20xx
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard/standard.scc
> +branch nxp-ls20xx
> +
> +include nxp-ls20xx.scc
> diff --git a/bsp/nxp-ls20xx/nxp-ls20xx.cfg b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
> new file mode 100755
> index ..f554c916
> --- /dev/null
> +++ b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
> @@ -0,0 +1,162 @@
> +..
> +.WARNING
> +.
> +. This file is a kernel configuration fragment, and not a full kernel
> +. configuration file.  The final kernel configuration is made up of
> +. an assembly of processed fragments, each of which is designed to
> +. capture a specific part of the final configuration (e.g. platform
> +. configuration, feature configuration, and board specific hardware
> +. configuration).  For more information on kernel configuration, please
> +. consult the product documentation.
> +.
> +..
> +
> +CONFIG_ARM64=y
> +CONFIG_ARM64_VA_BITS_48=y
> +CONFIG_ARCH_LAYERSCAPE=y
> +CONFIG_SCHED_MC=y
> +CONFIG_ARM_SMMU=y
> +CONFIG_ARM_SMMU_V3=y
> +
> +CONFIG_PCI=y
> +CONFIG_PCI_LAYERSCAPE=y
> +CONFIG_PCI_HOST_GENERIC=y
> +CONFIG_PCI_XGENE=y
> +CONFIG_PCI_MSI=y
> +
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_STAT=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +CONFIG_CPUFREQ_DT=y
> +CONFIG_QORIQ_CPUFREQ=y
> +
> +CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_CFI=y
> +CONFIG_MTD_CFI_ADV_OPTIONS=y
> +CONFIG_MTD_CFI_INTELEXT=y
> +CONFIG_MTD_CFI_AMDSTD=y
> +CONFIG_MTD_CFI_STAA=y
> +CONFIG_MTD_DATAFLASH=y
> +CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SST25L=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_MTD_NAND_FSL_IFC=y
> +CONFIG_SPI_FSL_QUADSPI=y
> +CONFIG_SCSI_SAS_ATA=y
> +CONFIG_SCSI_HISI_SAS=y
> +CONFIG_ATA=y
> +CONFIG_SATA_AHCI=y
> +CONFIG_SATA_AHCI_PLATFORM=y
> +CONFIG_AHCI_CEVA=y
> +CONFIG_AHCI_XGENE=y
> +CONFIG_AHCI_QORIQ=y
> +CONFIG_SATA_SIL24=y
> +
> +CONFIG_FSL_XGMAC_MDIO=y
> +CONFIG_HNS_DSAF=y
> +CONFIG_HNS_ENET=y
> +CONFIG_E1000=y
> +CONFIG_E1000E=y
> +
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_DW=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_FSL_LPUART=y
> +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
> +
> +CONFIG_SPI=y
> +CONFIG_SPI_FSL_DSPI=y
> +CONFIG_SPI_PL022=y
> +CONFIG_SPI_NXP_FLEXSPI=y
> +
> +CONFIG_POWER_RESET_XGENE=y
> +CONFIG_POWER_RESET_SYSCON=y
> +CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> +
> +CONFIG_THERMAL=y
> +CONFIG_THERMAL_OF=y
> +CONFIG_CPU_THERMAL=y
> +CONFIG_THERMAL_EMULATION=y
> +CONFIG_WATCHDOG=y
> +CONFIG_ARM_SP805_WATCHDOG=y
> +
> +CONFIG_USB=y
> +CONFIG_USB_OTG=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC2=y
> +CONFIG_USB_GADGET=y
> +
> +CONFIG_MMC=y
> +CONFIG_MMC_ARMMMCI=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_PLTFM=y
> +CONFIG_MMC_SDHCI_OF_ARASAN=y
> +CONFIG_MMC_SDHCI_OF_ESDHC=y
> +CONFIG_MMC_SDHCI_CADENCE=y
> +CONFIG_MMC_SPI=y
> +CONFIG_MMC_DW=y
> +
> +CONFIG_GPIOLIB=y
> +CONFIG_OF_GPIO=y
> +
> +CONFIG_MDIO_DEVICE=y
> +CONFIG_MDIO_BITBANG=y
> +CONFIG_PHYLIB=y
> +CONFIG_AQUANTIA_PHY=y
> +CONFIG_CORTINA_PHY=y
> +
> +#
> +# I2C support
> +#
> +CONFIG_I2C=y
> +CONFIG_I2C_MUX=y
> +CONFIG_I2C_IMX=y
> +CONFIG_I2C_MUX_PCA954x=y
> +
> +CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_DS3232=y
> +CONFIG_RTC_DRV_PL031=y
> +CONFIG_RTC_DRV_PCF2127=y
> +
> +CONFIG_DMADEVICES=y
> +CONFIG_FSL_EDMA=y
> +CONFIG_CMA=y
> +CONFIG_DMA_CMA=y
> +
> +CONFIG_VFIO=y
> +CONFIG_VFIO_PCI=y
> +
> +CONFIG_STAGING=y
> +CONFIG_FSL_MC_BUS=y
> +CONFIG_FSL_MC_DPIO=y
> +
> +CONFIG_CLK_QORIQ=y
> +
> +CONFIG_PHY_XGENE=y
> +
> +CONFIG_CRYPTO_DEV_FSL_CAAM=y
> +CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=y
> +CONFIG_ARM64_CRYPTO=y
> +CONFIG_CRYPTO_SHA1_ARM64_CE=y
> +CONFIG_CRYPTO_SHA2_ARM64_CE=y
> +CONFIG_CRYPTO_GHASH_ARM64_CE=y
> +CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
> +CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
> +# 

Re: [linux-yocto] [kernel-cache v5.2] ti-am335x: add base support

2019-09-05 Thread Bruce Ashfield
In message: [linux-yocto][kernel-cache v5.2] ti-am335x: add base support
on 04/09/2019 Jun Miao wrote:

> Hi Bruce, 
>  
>  I am working ti boards(AM335x evm/sk/BBB) with am335x soc.   
> 
>  Could you help me add scc/cfg to yocto-kernel-cache v5.2 branch.

Looks good to me. This is now merged.

Bruce

> 
> 
> Jun Miao (1):
>   ti-am335x: add the basic scc/cfg enablement
> 
>  bsp/ti-am335x/ti-am335x-standard.scc |   7 +
>  bsp/ti-am335x/ti-am335x.cfg  | 230 +++
>  bsp/ti-am335x/ti-am335x.scc  |   7 +
>  3 files changed, 244 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
> 
> -- 
> 2.22.0
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [kernel-cache yocto-5.2][PATCH 0/1] xilinx-zynq: add kernel-cache support for zc702 and zc706 boards

2019-09-05 Thread Bruce Ashfield
In message: [linux-yocto][kernel-cache yocto-5.2][PATCH 0/1] xilinx-zynq: add 
kernel-cache support for zc702 and zc706 boards
on 05/09/2019 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Hi Bruce,
> 
> The patch as below includes scc and cfg files for xilinx zc702/zc706 boards.
> 
> Could you please merge this patch into yocto-kernel-cache, branch is 
> yocto-5.2?

merged.

Bruce

> 
> Quanyang Wang (1):
>   xilinx-zynq: add the support for xlinx-zynq bsp
> 
>  bsp/xilinx-zynq/xilinx-zynq-standard.scc |   7 +
>  bsp/xilinx-zynq/xilinx-zynq.cfg  | 199 +++
>  bsp/xilinx-zynq/xilinx-zynq.scc  |   8 +
>  3 files changed, 214 insertions(+)
>  create mode 100644 bsp/xilinx-zynq/xilinx-zynq-standard.scc
>  create mode 100644 bsp/xilinx-zynq/xilinx-zynq.cfg
>  create mode 100644 bsp/xilinx-zynq/xilinx-zynq.scc
> 
> -- 
> 2.17.1
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH] spp: optimize strip_common_prefix function

2019-09-05 Thread Bruce Ashfield
I have this queued for testing now.

Bruce

On Fri, Aug 30, 2019 at 1:09 AM Zhaolong Zhang  wrote:
>
> strip_common_prefix() is the hot path that executes on every input file.
> This patch sorts and uniqs the $include_paths by length descreasingly.
> And with the sorted $include_paths, the for-loop inside strip_common_prefix
> can break earlier, thus kernel_metadata task can be sped up by multiple times.
>
> Signed-off-by: Zhaolong Zhang 
> ---
>  tools/spp | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/tools/spp b/tools/spp
> index 1150ff3..cba52bb 100755
> --- a/tools/spp
> +++ b/tools/spp
> @@ -125,6 +125,7 @@ strip_common_prefix()
> if [ $this_len -lt $out_len ]; then
> relocated_name=$t
> out_len=$this_len
> +   break
> fi
> # add a trailing slash to get corner cases where one may
> # have been added or not dropped
> @@ -133,6 +134,7 @@ strip_common_prefix()
> if [ $this_len -lt $out_len ]; then
> relocated_name=$t
> out_len=$this_len
> +   break
> fi
>  done
>
> @@ -297,6 +299,16 @@ infiles=$@
>
>  processed_files=""
>
> +# this function also removes duplicated lines by `sort -u`
> +sort_by_len_dec()
> +{
> +for i in $@; do
> +echo $i
> +done | sort -u | awk '{ print length($0) " " $0; }' | sort -nr | cut 
> -d ' ' -f 2-
> +}
> +
> +include_paths=$(sort_by_len_dec $include_paths)
> +
>  ##
>  ## create variables for use in scripts
>  ##
> --
> 1.9.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
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH] [for all x86 branches] x86/boot: Save fields explicitly, zero out everything else

2019-09-05 Thread Bruce Ashfield
Since this is destined for -stable, I'm not going to merge the individual patch.

I'm holding nearly all 5.2 updates until the last introduction issues
are fixed. By that time, I'll have the next round of -stable updates
ready to go as well.

Cheers,

Bruce

On Thu, Sep 5, 2019 at 6:02 AM  wrote:
>
> From: John Hubbard 
>
> commit a90118c445cc7f07781de26a9684d4ec58bfcfd1 upstream.
>
> Recent gcc compilers (gcc 9.1) generate warnings about an out of bounds
> memset, if the memset goes accross several fields of a struct. This
> generated a couple of warnings on x86_64 builds in sanitize_boot_params().
>
> Fix this by explicitly saving the fields in struct boot_params
> that are intended to be preserved, and zeroing all the rest.
>
> [ tglx: Tagged for stable as it breaks the warning free build there as well ]
>
> Suggested-by: Thomas Gleixner 
> Suggested-by: H. Peter Anvin 
> Signed-off-by: John Hubbard 
> Signed-off-by: Thomas Gleixner 
> Cc: sta...@vger.kernel.org
> Link: https://lkml.kernel.org/r/20190731054627.5627-2-jhubb...@nvidia.com
> Signed-off-by: Greg Kroah-Hartman 
> ---
> Fix the following build warning. It has been merge to 5.2.11.
> Please consider merging if it's worth.
>
> ./arch/x86/include/asm/bootparam_utils.h:40:3: warning: ‘memset’ offset [197, 
> 448] from the object at ‘boot_params’ is out of the bounds of referenced 
> subobject ‘ext_ramdisk_image’ with type
>  ‘unsigned int’ at offset 192 [-Warray-bounds]
>
> ./arch/x86/include/asm/bootparam_utils.h:43:3: warning: ‘memset’ offset [493, 
> 497] from the object at ‘boot_params’ is out of the bounds of referenced 
> subobject ‘kbd_status’ with type ‘unsig
> ned char’ at offset 491 [-Warray-bounds]
>
>  arch/x86/include/asm/bootparam_utils.h | 63 
> ++
>  1 file changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/include/asm/bootparam_utils.h 
> b/arch/x86/include/asm/bootparam_utils.h
> index f6f6ef4..7fed0fc 100644
> --- a/arch/x86/include/asm/bootparam_utils.h
> +++ b/arch/x86/include/asm/bootparam_utils.h
> @@ -18,6 +18,20 @@
>   * Note: efi_info is commonly left uninitialized, but that field has a
>   * private magic, so it is better to leave it unchanged.
>   */
> +
> +#define sizeof_mbr(type, member) ({ sizeof(((type *)0)->member); })
> +
> +#define BOOT_PARAM_PRESERVE(struct_member) \
> +   {   \
> +   .start = offsetof(struct boot_params, struct_member),   \
> +   .len   = sizeof_mbr(struct boot_params, struct_member), \
> +   }
> +
> +struct boot_params_to_save {
> +   unsigned int start;
> +   unsigned int len;
> +};
> +
>  static void sanitize_boot_params(struct boot_params *boot_params)
>  {
> /*
> @@ -35,21 +49,40 @@ static void sanitize_boot_params(struct boot_params 
> *boot_params)
>  * problems again.
>  */
> if (boot_params->sentinel) {
> -   /* fields in boot_params are left uninitialized, clear them */
> -   boot_params->acpi_rsdp_addr = 0;
> -   memset(_params->ext_ramdisk_image, 0,
> -  (char *)_params->efi_info -
> -   (char *)_params->ext_ramdisk_image);
> -   memset(_params->kbd_status, 0,
> -  (char *)_params->hdr -
> -  (char *)_params->kbd_status);
> -   memset(_params->_pad7[0], 0,
> -  (char *)_params->edd_mbr_sig_buffer[0] -
> -   (char *)_params->_pad7[0]);
> -   memset(_params->_pad8[0], 0,
> -  (char *)_params->eddbuf[0] -
> -   (char *)_params->_pad8[0]);
> -   memset(_params->_pad9[0], 0, sizeof(boot_params->_pad9));
> +   static struct boot_params scratch;
> +   char *bp_base = (char *)boot_params;
> +   char *save_base = (char *)
> +   int i;
> +
> +   const struct boot_params_to_save to_save[] = {
> +   BOOT_PARAM_PRESERVE(screen_info),
> +   BOOT_PARAM_PRESERVE(apm_bios_info),
> +   BOOT_PARAM_PRESERVE(tboot_addr),
> +   BOOT_PARAM_PRESERVE(ist_info),
> +   BOOT_PARAM_PRESERVE(acpi_rsdp_addr),
> +   BOOT_PARAM_PRESERVE(hd0_info),
> +   BOOT_PARAM_PRESERVE(hd1_info),
> +   BOOT_PARAM_PRESERVE(sys_desc_table),
> +   BOOT_PARAM_PRESERVE(olpc_ofw_header),
> +   BOOT_PARAM_PRESERVE(efi_info),
> +   BOOT_PARAM_PRESERVE(alt_mem_k),
> +   BOOT_PARAM_PRESERVE(scratch),
> +   BOOT_PARAM_PRESERVE(e820_entries),
> +   BOOT_PARAM_PRESERVE(eddbuf_entries),
> +   BOOT_PARAM_PRESERVE(edd_mbr_sig_buf_entries),
> + 

Re: [linux-yocto] [kernel-cache master/yocto-5.0][PATCH] intel-x86: add MGA G200 series VGA support

2019-09-03 Thread Bruce Ashfield
Indeed. I appear to have messed it up .. I had a lot of merges to do
today, so I was sure to get something wrong.

This is now really merged.

Bruce

On Tue, Sep 3, 2019 at 9:57 PM Liwei Song  wrote:
>
> Hi Bruce,
>
> It seems that this patch was missed by master branch, so does 5.2 branch also 
> miss it.
> Could you help merge it to both master and yocto-5.2 branch?
>
>
> Thanks,
> Liwei.
>
>
> On 07/08/2019 04:22 PM, Liwei Song wrote:
> > Enable CONFIG_DRM_MGAG200=m to support Matrox Electronics MGA G200
> > and include it in intel-x86 bsp.
> >
> > Signed-off-by: Liwei Song 
> > ---
> >  bsp/intel-x86/intel-x86.scc  | 1 +
> >  features/mgag200/mgag200.cfg | 1 +
> >  features/mgag200/mgag200.scc | 4 
> >  3 files changed, 6 insertions(+)
> >  create mode 100644 features/mgag200/mgag200.cfg
> >  create mode 100644 features/mgag200/mgag200.scc
> >
> > diff --git a/bsp/intel-x86/intel-x86.scc b/bsp/intel-x86/intel-x86.scc
> > index aee6d5e93db3..a93319d483a5 100644
> > --- a/bsp/intel-x86/intel-x86.scc
> > +++ b/bsp/intel-x86/intel-x86.scc
> > @@ -39,6 +39,7 @@ include features/tpm/tpm.scc
> >  include features/mfd/mfd-intel-lpss.scc
> >  include features/mmc/mmc-realtek.scc
> >  include features/intel-pinctrl/intel-pinctrl.scc
> > +include features/mgag200/mgag200.scc
> >
> >  kconf hardware intel-x86.cfg
> >  kconf hardware intel-x86-mga.cfg
> > diff --git a/features/mgag200/mgag200.cfg b/features/mgag200/mgag200.cfg
> > new file mode 100644
> > index ..48b6c6106fe0
> > --- /dev/null
> > +++ b/features/mgag200/mgag200.cfg
> > @@ -0,0 +1 @@
> > +CONFIG_DRM_MGAG200=m
> > diff --git a/features/mgag200/mgag200.scc b/features/mgag200/mgag200.scc
> > new file mode 100644
> > index ..6bb0e79608e9
> > --- /dev/null
> > +++ b/features/mgag200/mgag200.scc
> > @@ -0,0 +1,4 @@
> > +define KFEATURE_DESCRIPTION "Matrox Electronics Systems Ltd. MGA G200e 
> > support"
> > +define KFEATURE_COMPATIBILITY board
> > +
> > +kconf hardware mgag200.cfg
> >



-- 
- 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] [PATCH 1/2 linux-yocto-dev all branches] aufs: bugfix, opts: Fix missing break statement

2019-09-03 Thread Bruce Ashfield
merged to linux-yocto-dev

Bruce

On Tue, Sep 3, 2019 at 3:28 AM  wrote:
>
> From: He Zhe 
>
> commit 4a80018d718f6be2e862d0c70bb11cd6e6d1fae5 upstream
>
> Add missing break statement for case Opt_wsum in au_opt_simple.
>
> Signed-off-by: He Zhe 
> See-also: 
> https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05684.html
> (cherry picked from commit 9e7d29356ab57fa5db7e92e51267176e50c1497c)
> ---
>  fs/aufs/opts.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c
> index a089b8e..d370108 100644
> --- a/fs/aufs/opts.c
> +++ b/fs/aufs/opts.c
> @@ -1373,6 +1373,7 @@ static int au_opt_simple(struct super_block *sb, struct 
> au_opt *opt,
> case Opt_wsum:
> au_opt_clr(sbinfo->si_mntflags, SUM);
> au_opt_set(sbinfo->si_mntflags, SUM_W);
> +   break;
> case Opt_nosum:
> au_opt_clr(sbinfo->si_mntflags, SUM);
> au_opt_clr(sbinfo->si_mntflags, SUM_W);
> --
> 2.7.4
>


-- 
- 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] [PATCH 2/2 linux-yocto-dev all branches] aufs: opts: Fix missing fallthrough

2019-09-03 Thread Bruce Ashfield
merged to linux-yocto-dev.

Bruce

On Tue, Sep 3, 2019 at 3:28 AM  wrote:
>
> From: He Zhe 
>
> commit 8d7b6374d5af2c31ce9501d3502808e3c7a9ea68 upstream
>
> A compilation -Wimplicit-fallthrough warning was enabled by commit
> a035d552a93b ("Makefile: Globally enable fall-through warning")
> and triggers the following warning.
>
> fs/aufs/opts.h:78:11:
> warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> This patch adds comments according GNU manual.
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
>
> Signed-off-by: He Zhe 
> See-also: 
> https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05685.html
> (cherry picked from commit e7619996b014c5d8fd2f6ad89542c545a207667f)
> ---
>  fs/aufs/opts.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c
> index d370108..01fae8b 100644
> --- a/fs/aufs/opts.c
> +++ b/fs/aufs/opts.c
> @@ -1499,8 +1499,10 @@ static int au_opt_br(struct super_block *sb, struct 
> au_opt *opt,
> if (opt->add.bindex < 0)
> opt->add.bindex = 0;
> goto add;
> +   /* Always goto add, not fallthrough */
> case Opt_prepend:
> opt->add.bindex = 0;
> +   /* fallthrough */
> add: /* indented label */
> case Opt_add:
> err = au_br_add(sb, >add,
> --
> 2.7.4
>


-- 
- 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] [kernel-cache] [all branches] [PATCH] net_sched: Add FQ Controlled Delay packet scheduling algorithm

2019-09-03 Thread Bruce Ashfield
merged to 4.19/5.0/5.2 and master of the kernel-cache.

SRCREV bumps will follow in the next few days.

Bruce

On Tue, Sep 3, 2019 at 3:00 AM  wrote:
>
> From: He Zhe 
>
> It has been widely used and selected by systemd as defalut scheduling 
> algorithm
> since v217.
> https://github.com/systemd/systemd/blob/master/NEWS#L5861
>
> Signed-off-by: He Zhe 
> ---
>  features/net_sched/net_sched.cfg | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/features/net_sched/net_sched.cfg 
> b/features/net_sched/net_sched.cfg
> index 49cd7d7..8ac740a 100644
> --- a/features/net_sched/net_sched.cfg
> +++ b/features/net_sched/net_sched.cfg
> @@ -19,6 +19,7 @@ CONFIG_NET_SCH_DSMARK=m
>  CONFIG_NET_SCH_NETEM=m
>  CONFIG_NET_SCH_INGRESS=m
>  CONFIG_NET_SCH_CODEL=m
> +CONFIG_NET_SCH_FQ_CODEL=m
>
>  #
>  # Classification
> --
> 2.7.4
>


-- 
- 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]: [kernel standard/base]: renesas-rcar: add some patches to improve features on renesas-rcar platform

2019-09-03 Thread Bruce Ashfield
These look fine to me. All four patches are on v5.2/standard/base

Bruce

On Tue, Sep 3, 2019 at 2:53 AM  wrote:
>
> From: Limeng 
>
> Hi Bruce,
>
> I am working on BSP renesas-rcar platform, and intend to merge this BSP 
> supporting into yocto community.
> Below 4 patches are used to improve gpio, CAN BUS, audio and PCIe features
> This first patch is from mainline upstream, the other 3 patches merged into 
> linux-yocto-dev(standard/base) some days ago.
>
> 0001-arm64-dts-renesas-ulcb-kf-Add-support-for-TI-WL1837.patch
> 0002-arch-arm64-dts-Set-gpio5-pin9-as-input-by-default.patch
> 0003-driver-net-can-disable-clock-when-it-is-in-enable-st.patch
> 0004-pci-pcie-rcar-add-regulators-support.patch
>
> Could you please merge the 4 patches into linux-yocto, branch is 
> v5.2/standard/base?
>
>  arch/arm64/boot/dts/renesas/ulcb-kf.dtsi |  105 
> +++
>  drivers/net/can/rcar/rcar_can.c  |5 +
>  drivers/pci/controller/pcie-rcar.c   |   64 ++
>  3 files changed, 173 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] : [kernel-cache yocto-5.2]: renesas-rcar: add configure file for renesas BSP in kernel-cache

2019-09-03 Thread Bruce Ashfield
This is now in the 5.2 branch of the kernel-cache.

Bruce

On Fri, Aug 30, 2019 at 5:19 AM  wrote:
>
> From: Limeng 
>
> Hi Bruce,
>
> I am working on BSP renesas-rcar platform, and intend to merge this BSP 
> supporting into yocto community.
> Below patch includes scc and cfg files for renesas-rcar platform.
>
> Could you please merge this patch into yocto-kernel-cache, branch is 
> yocto-5.2?
> This patch was merged into master some days ago. It also need to be merged 
> into yocto-5.2 branch
>
> 0001-renesas-rcar-add-configure-file-for-renesas-BSP-in-k.patch
>
>  renesas-rcar-h3-standard.scc |7 +
>  renesas-rcar-m3-standard.scc |7 +
>  renesas-rcar.cfg |  252 
> +++
>  renesas-rcar.scc |8 +
>  4 files changed, 274 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] [kernel-meta] bsp: Add the support for the marvell-cn96xx BSP

2019-09-03 Thread Bruce Ashfield
On Tue, Sep 3, 2019 at 3:40 AM Kevin Hao  wrote:
>
> This adds the cfg files to support the Marvell OCTEON TX2
> CN96XX multicore arm64 SoC.

merged to yocto-5.2 of the kernel-cache.

Bruce

>
> Signed-off-by: Kevin Hao 
> ---
>  bsp/marvell-cn96xx/marvell-cn96xx-standard.scc |   7 ++
>  bsp/marvell-cn96xx/marvell-cn96xx.cfg  | 107 
> +
>  bsp/marvell-cn96xx/marvell-cn96xx.scc  |   6 ++
>  3 files changed, 120 insertions(+)
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx.cfg
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx.scc
>
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc 
> b/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
> new file mode 100644
> index ..8d92dc15f87b
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
> @@ -0,0 +1,7 @@
> +define KMACHINE marvell-cn96xx
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard
> +
> +include marvell-cn96xx.scc
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.cfg 
> b/bsp/marvell-cn96xx/marvell-cn96xx.cfg
> new file mode 100644
> index ..7dc73ac245f5
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx.cfg
> @@ -0,0 +1,107 @@
> +..
> +.WARNING
> +.
> +. This file is a kernel configuration fragment, and not a full kernel
> +. configuration file.  The final kernel configuration is made up of
> +. an assembly of processed fragments, each of which is designed to
> +. capture a specific part of the final configuration (e.g. platform
> +. configuration, feature configuration, and board specific hardware
> +. configuration).  For more information on kernel configuration, please
> +. consult the product documentation.
> +.
> +..
> +
> +CONFIG_ARM64=y
> +CONFIG_ARM64_VA_BITS_48=y
> +CONFIG_ARM_SMMU_V3=y
> +CONFIG_NR_CPUS=24
> +CONFIG_ARCH_THUNDER=y
> +
> +# uboot set "coherent_pool=16M" kernel parameter by default, so we need to
> +# make sure CONFIG_FORCE_MAX_ZONEORDER is big enough
> +CONFIG_ARM64_64K_PAGES=y
> +CONFIG_TRANSPARENT_HUGEPAGE=y
> +
> +# PCIe
> +CONFIG_PCI=y
> +CONFIG_PCIEPORTBUS=y
> +CONFIG_HOTPLUG_PCI=y
> +CONFIG_HOTPLUG_PCI_PCIE=y
> +CONFIG_PCI_IOV=y
> +
> +CONFIG_PCI_HOST_GENERIC=y
> +CONFIG_PCI_HOST_THUNDER_PEM=y
> +CONFIG_PCI_HOST_OCTEONTX2_PEM=y
> +
> +# Ethernet
> +CONFIG_OCTEONTX2_AF=y
> +CONFIG_OCTEONTX2_PF=y
> +CONFIG_OCTEONTX2_VF=y
> +CONFIG_USB_USBNET=y
> +CONFIG_USB_NET_AX88179_178A=y
> +
> +# NVMe
> +CONFIG_BLK_DEV_NVME=y
> +
> +# DMA
> +CONFIG_OCTEONTX2_DPI_PF=y
> +
> +# MTD
> +CONFIG_MTD=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_M25P80=y
> +CONFIG_MTD_BLOCK=y
> +
> +# USB
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +
> +# SPI
> +CONFIG_SPI=y
> +CONFIG_SPI_OCTEONTX2=y
> +
> +# I2C
> +CONFIG_I2C=y
> +CONFIG_I2C_THUNDERX=y
> +
> +# Serial
> +CONFIG_SERIAL_AMBA_PL011=y
> +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
> +
> +# Watchdog
> +CONFIG_ARM_SBSA_WATCHDOG=y
> +
> +# SD
> +CONFIG_MMC=y
> +CONFIG_MMC_CAVIUM_THUNDERX=y
> +
> +# GPIO
> +CONFIG_GPIOLIB=y
> +CONFIG_GPIO_THUNDERX=y
> +
> +# HWMON
> +CONFIG_SENSORS_MAX6697=y
> +CONFIG_SENSORS_JC42=y
> +
> +# RTC
> +CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_DS1307=y
> +
> +# Regulator
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> +CONFIG_REGULATOR_GPIO=y
> +
> +# VFIO
> +CONFIG_VFIO=y
> +CONFIG_VFIO_PCI=y
> +
> +# Misc
> +CONFIG_EEPROM_AT24=y
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_CAVIUM=y
> +CONFIG_OCTEONTX2_RM=y
> +CONFIG_OCTEONTX2_RM_DOM_SYSFS=y
> +
> +# BPHY
> +CONFIG_MARVELL_OTX_BPHY_CTR=y
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.scc 
> b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> new file mode 100644
> index ..0d104fad583b
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> @@ -0,0 +1,6 @@
> +kconf hardware marvell-cn96xx.cfg
> +kconf hardware features/edac/edac.cfg
> +
> +include cfg/usb-mass-storage.scc
> +
> +include features/hugetlb/hugetlb.scc
> --
> 2.14.4
>


-- 
- 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] [kernel] The kernel patches for the Marvell cn96xx support

2019-09-03 Thread Bruce Ashfield
On Tue, Sep 3, 2019 at 3:40 AM Kevin Hao  wrote:
>
> The following changes since commit 35276d20c01a78ee3640a074446b0c15c486c5d0:
>
>   selftests/bpf: structure test_{progs, maps, verifier} test runners 
> uniformly (2019-08-30 00:33:44 -0400)
>
> are available in the Git repository at:
>
>   https://github.com/haokexin/linux.git v5.2/standard/cn96xx

v5.2/standard/cn96xx has been created in linux-yocto.git

Bruce

>
> for you to fetch changes up to a075be8d6f3bacea9a7ccc36f80bac2e3276c5e2:
>
>   octeontx2-af: Fix the using of variable length arrays (2019-09-03 14:40:25 
> +0800)
>
> 
> Aleksey Makarov (6):
>   octeontx2-pf: Set irq affinity hints for CQ interrupts
>   octeontx2-pf: Implement ndo_tx_timeout callback
>   octeontx2-pf: Support queue interrupts
>   octeontx2-pf: Add reset count to stats
>   octeontx2-af: Add low level support for Marvell PTP coprocessor
>   octeontx2-pf: Add support for PTP clock
>
> Alex Belits (2):
>   arm64: Add support for ASID locking
>   kernel/exit.c: Add task cleanup callbacks
>
> Angela Czubak (2):
>   octeontx2-af: fix rvu_sso_ggrp_taq_flush
>   octeontx2-af: fix cgx_lmac_rx_tx_enable
>
> Chandrakala Chavva (1):
>   mmc: cavium_thunderx: Use proper register to clear interrupts
>
> Christina Jacob (22):
>   octeontx2-pf: BQL support.
>   octeontx2-pf: IRQ coalescing config and tuning via ethtool
>   octeontx2-af: Dump current resource provisioning status
>   octeontx2-pf: Adding ethtool support for link status information.
>   octeontx2-af: Patch to prevent redundant message from pf to af.
>   octeontx2-pf: Fix redundant message from AF to PF
>   octeontx2-af: Support to get link info like current speed, fec etc
>   octeontx2-pf: Ethtool support for fec configuration
>   octeontx2-pf: Fix smmuv3 messages while deferring pf driver probe.
>   octeontx2-af: Move to rvu_fwdata version 1.
>   octeontx2-pf: Add ethtool -m option support.
>   octeontx2-af: Extend fwdata structure with additional information.
>   octeontx2-af: Update fwadata structure with few more reserved fields.
>   octeontx2-af: Fetch FEC stats of the physical link
>   octeontx2-pf: Support to display fec counters also in ethtool stats.
>   octeontx2-af: sync ATF and Kernel firmware data structure.
>   octeontx2-pf: Support to display current settings of a vf network 
> interface via ethtool
>   net:thunderx: fix memory leak in nicvf driver.
>   soc: octeontx2: Add mdio command interface using debugfs
>   soc: octeontx2: Add mdio command interface using debugfs
>   octeontx2-af: Introduce SET_LINK_MODE command to change various 
> configurations of a network interface.
>   octeontx2-pf: support to change link speed and autoneg
>
> Felix Manlunas (2):
>   octeontx2-af: Add new CGX_CMDs to set and get PHY modulation type
>   octeontx2-pf: Add ethtool priv flag to control PAM4 on/off
>
> Geetha sowjanya (26):
>   octeontx2-af: Sync hw mbox with bounce buffer.
>   octeontx2-pf: Add mailbox bounce buffer
>   octeontx2-pf: Add interface stats to ndo_get_stats64
>   octeontx2-af: Config receive and transmission of pause frames
>   octeontx2-af: Add mbox message to enable/disable pause frames.
>   octeontx2-af: Add mbox messages to configure backpressure for an 
> interface.
>   octeontx2-pf: Add ethtool support to enable/disable pause frames
>   octeontx2-pf: Configure RED drop levels for packet reception.
>   octeontx2-pf: Configure backpressure level for packet reception
>   octeontx2-pf: Skip CQ_STATUS read if pending CQEs greater than budget
>   octeontx2-pf: Set RVU PF/VF watchdog timeout
>   octeontx2-af: Check SQ counters to detect the deadlock
>   octeontx2-af: Enable pci bus mastering
>   octeontx2-af: Fix rvu probe on cgx disable
>   octeontx2-pf: Add VF function level reset (FLR) support
>   octeontx2-vf: Configure backpressure level for packet reception
>   octeontx2-af: Support configurable NDC cache way_mask
>   octeontx2: Fix mbox driver compilation dependency.
>   octeontx2-pf: Set minimum MTU size to 64 bytes
>   octeontx2-pf: Schedule work to refill RQ if buffer alloc fails in 
> atomic context.
>   octeontx2-pf: Free HW resources on PF/VF initialization failure
>   octeontx2-af: Update hardware workarounds for 95xx A1 silicon
>   octeontx2-pf: Update hardware workarounds for 95xx A1 silicon
>   PCI: quirks : Apply ACS quirk for all devices
>   octeontx2-pf: Enable CQ interrupt coalescing
>   octeontx2-pf: Fix RQ CQ RED and DROP levels for 96xx B0
>
> Hao Zheng (10):
>   octeontx2-af: change NPC KPU profile format
>   octeontx2-af: NPC KPU profile update (ver 1.3.0):
>   octeontx2-af: NPC KPU profile fix
>   octeontx2-af: add NPC parser support for QinQ with TPID of 0x8100
> 

Re: [linux-yocto] [kernel-cache master] bsp: Add the support for the marvell-cn96xx BSP

2019-09-03 Thread Bruce Ashfield
merged to master

Bruce

On Tue, Aug 20, 2019 at 7:32 AM Kevin Hao  wrote:
>
> This adds the cfg files to support the Marvell OCTEON TX2
> CN96XX multicore arm64 SoC.
>
> Signed-off-by: Kevin Hao 
> ---
>  bsp/marvell-cn96xx/marvell-cn96xx-standard.scc |   7 ++
>  bsp/marvell-cn96xx/marvell-cn96xx.cfg  | 104 
> +
>  bsp/marvell-cn96xx/marvell-cn96xx.scc  |   6 ++
>  3 files changed, 117 insertions(+)
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx.cfg
>  create mode 100644 bsp/marvell-cn96xx/marvell-cn96xx.scc
>
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc 
> b/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
> new file mode 100644
> index ..8d92dc15f87b
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx-standard.scc
> @@ -0,0 +1,7 @@
> +define KMACHINE marvell-cn96xx
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard
> +
> +include marvell-cn96xx.scc
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.cfg 
> b/bsp/marvell-cn96xx/marvell-cn96xx.cfg
> new file mode 100644
> index ..6b83cd0659aa
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx.cfg
> @@ -0,0 +1,104 @@
> +..
> +.WARNING
> +.
> +. This file is a kernel configuration fragment, and not a full kernel
> +. configuration file.  The final kernel configuration is made up of
> +. an assembly of processed fragments, each of which is designed to
> +. capture a specific part of the final configuration (e.g. platform
> +. configuration, feature configuration, and board specific hardware
> +. configuration).  For more information on kernel configuration, please
> +. consult the product documentation.
> +.
> +..
> +
> +CONFIG_ARM64=y
> +CONFIG_ARM64_VA_BITS_48=y
> +CONFIG_ARM_SMMU_V3=y
> +CONFIG_NR_CPUS=24
> +CONFIG_ARCH_THUNDER=y
> +
> +# uboot set "coherent_pool=16M" kernel parameter by default, so we need to
> +# make sure CONFIG_FORCE_MAX_ZONEORDER is big enough
> +CONFIG_ARM64_64K_PAGES=y
> +CONFIG_TRANSPARENT_HUGEPAGE=y
> +
> +# PCIe
> +CONFIG_PCI=y
> +CONFIG_PCIEPORTBUS=y
> +CONFIG_HOTPLUG_PCI=y
> +CONFIG_HOTPLUG_PCI_PCIE=y
> +CONFIG_PCI_IOV=y
> +
> +CONFIG_PCI_HOST_GENERIC=y
> +CONFIG_PCI_HOST_THUNDER_PEM=y
> +CONFIG_PCI_HOST_OCTEONTX2_PEM=y
> +
> +# Ethernet
> +CONFIG_OCTEONTX2_AF=y
> +CONFIG_OCTEONTX2_PF=y
> +CONFIG_OCTEONTX2_VF=y
> +CONFIG_USB_USBNET=y
> +CONFIG_USB_NET_AX88179_178A=y
> +
> +# NVMe
> +CONFIG_BLK_DEV_NVME=y
> +
> +# DMA
> +CONFIG_OCTEONTX2_DPI_PF=y
> +
> +# MTD
> +CONFIG_MTD=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_M25P80=y
> +CONFIG_MTD_BLOCK=y
> +
> +# USB
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +
> +# SPI
> +CONFIG_SPI=y
> +CONFIG_SPI_OCTEONTX2=y
> +
> +# I2C
> +CONFIG_I2C=y
> +CONFIG_I2C_THUNDERX=y
> +
> +# Serial
> +CONFIG_SERIAL_AMBA_PL011=y
> +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
> +
> +# Watchdog
> +CONFIG_ARM_SBSA_WATCHDOG=y
> +
> +# SD
> +CONFIG_MMC=y
> +CONFIG_MMC_CAVIUM_THUNDERX=y
> +
> +# GPIO
> +CONFIG_GPIOLIB=y
> +CONFIG_GPIO_THUNDERX=y
> +
> +# HWMON
> +CONFIG_SENSORS_MAX6697=y
> +CONFIG_SENSORS_JC42=y
> +
> +# RTC
> +CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_DS1307=y
> +
> +# Regulator
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> +CONFIG_REGULATOR_GPIO=y
> +
> +# VFIO
> +CONFIG_VFIO=y
> +CONFIG_VFIO_PCI=y
> +
> +# Misc
> +CONFIG_EEPROM_AT24=y
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_CAVIUM=y
> +CONFIG_OCTEONTX2_RM=y
> +CONFIG_OCTEONTX2_RM_DOM_SYSFS=y
> diff --git a/bsp/marvell-cn96xx/marvell-cn96xx.scc 
> b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> new file mode 100644
> index ..0d104fad583b
> --- /dev/null
> +++ b/bsp/marvell-cn96xx/marvell-cn96xx.scc
> @@ -0,0 +1,6 @@
> +kconf hardware marvell-cn96xx.cfg
> +kconf hardware features/edac/edac.cfg
> +
> +include cfg/usb-mass-storage.scc
> +
> +include features/hugetlb/hugetlb.scc
> --
> 2.14.4
>


-- 
- 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] Add the support for the Marvell cn96xx SoC

2019-09-03 Thread Bruce Ashfield
On Tue, Aug 20, 2019 at 7:25 AM Kevin Hao  wrote:
>
> Hi Bruce,
>
> This patch series adds the support for the Marvell cn96xx SoC. The OCTEON TX2
> cn96xx SoC is a scalable architecture that integrates high performance 64-bit
> Armv8.2 processors, a cache-coherent interconnect, hardware accelerators,
> virtualized networking, and scalable I/O. It support the following
> industry-standard I/O interfaces:
> DDR4 DRAM
> PCI Express 4.0 version 1.0
> SGMII
> QSGMII
> XAUI
> XFI
> CAUI
>
> Most of the patches are for the Marvell specific drivers. So in theory, it
> should be safe to merge these patches to the standard/base branch. But I
> prefer to stage them to the specific standard/cn96xx branch. The reason is
> that we plan to support other Marvell SoCs, and the SDK for them may be
> based on different SDK versions. They will definitely touch some common
> files affect by this patch series. So it would be a nightmare for us to
> support them if these patches are merged to the standard/base branch.
>
> The following changes since commit ce4ec6ff9589e3b1dcc4e3a0b192b02823631c3e:
>
>   Merge tag 'v5.3-rc5' into standard/base (2019-08-18 22:40:47 -0400)
>
> are available in the Git repository at:
>
>   git://github.com/haokexin/linux standard/cn96xx

standard/cn96xx now exists in linux-yocto-dev.

Bruce

>
> for you to fetch changes up to 4fae437f7ea88d2aab10cac684e11d94b12114bd:
>
>   octeontx2-af: Fix the using of variable length arrays (2019-08-20 11:25:36 
> +0800)
>
> 
> Aleksey Makarov (6):
>   octeontx2-pf: Set irq affinity hints for CQ interrupts
>   octeontx2-pf: Implement ndo_tx_timeout callback
>   octeontx2-pf: Support queue interrupts
>   octeontx2-pf: Add reset count to stats
>   octeontx2-af: Add low level support for Marvell PTP coprocessor
>   octeontx2-pf: Add support for PTP clock
>
> Angela Czubak (2):
>   octeontx2-af: fix rvu_sso_ggrp_taq_flush
>   octeontx2-af: fix cgx_lmac_rx_tx_enable
>
> Chandrakala Chavva (1):
>   mmc: cavium_thunderx: Use proper register to clear interrupts
>
> Christina Jacob (21):
>   octeontx2-pf: BQL support.
>   octeontx2-pf: IRQ coalescing config and tuning via ethtool
>   octeontx2-af: Dump current resource provisioning status
>   octeontx2-pf: Adding ethtool support for link status information.
>   octeontx2-af: Patch to prevent redundant message from pf to af.
>   octeontx2-pf: Fix redundant message from AF to PF
>   octeontx2-af: Support to get link info like current speed, fec etc
>   octeontx2-pf: Ethtool support for fec configuration
>   octeontx2-pf: Fix smmuv3 messages while deferring pf driver probe.
>   octeontx2-af: Move to rvu_fwdata version 1.
>   octeontx2-pf: Add ethtool -m option support.
>   octeontx2-af: Extend fwdata structure with additional information.
>   octeontx2-af: Update fwadata structure with few more reserved fields.
>   octeontx2-af: Fetch FEC stats of the physical link
>   octeontx2-pf: Support to display fec counters also in ethtool stats.
>   octeontx2-af: sync ATF and Kernel firmware data structure.
>   octeontx2-pf: Support to display current settings of a vf network 
> interface via ethtool
>   net:thunderx: fix memory leak in nicvf driver.
>   soc: octeontx2: Add mdio command interface using debugfs
>   octeontx2-af: Introduce SET_LINK_MODE command to change various 
> configurations of a network interface.
>   octeontx2-pf: support to change link speed and autoneg
>
> Felix Manlunas (2):
>   octeontx2-af: Add new CGX_CMDs to set and get PHY modulation type
>   octeontx2-pf: Add ethtool priv flag to control PAM4 on/off
>
> Geetha sowjanya (26):
>   octeontx2-af: Sync hw mbox with bounce buffer.
>   octeontx2-pf: Add mailbox bounce buffer
>   octeontx2-pf: Add interface stats to ndo_get_stats64
>   octeontx2-af: Config receive and transmission of pause frames
>   octeontx2-af: Add mbox message to enable/disable pause frames.
>   octeontx2-af: Add mbox messages to configure backpressure for an 
> interface.
>   octeontx2-pf: Add ethtool support to enable/disable pause frames
>   octeontx2-pf: Configure RED drop levels for packet reception.
>   octeontx2-pf: Configure backpressure level for packet reception
>   octeontx2-pf: Skip CQ_STATUS read if pending CQEs greater than budget
>   octeontx2-pf: Set RVU PF/VF watchdog timeout
>   octeontx2-af: Check SQ counters to detect the deadlock
>   octeontx2-af: Enable pci bus mastering
>   octeontx2-af: Fix rvu probe on cgx disable
>   octeontx2-pf: Add VF function level reset (FLR) support
>   octeontx2-vf: Configure backpressure level for packet reception
>   octeontx2-af: Support configurable NDC cache way_mask
>   octeontx2: Fix mbox driver compilation dependency.
> 

Re: [linux-yocto] [linux-yocto v5.2] Add the support for the Marvell cn96xx SoC

2019-09-03 Thread Bruce Ashfield
On Tue, Sep 3, 2019 at 3:39 AM Kevin Hao  wrote:
>
> Hi Bruce,
>
> This patch series adds the kernel and kernel meta for the support of the
> Marvell cn96xx SoC support. These patches are almost the same as what I
> have sent for the linux-yocto-dev [1] [2]. The major difference between

I assume that you still also want the linux-yocto-dev changes merged ?
That is mhy plan.

> them is that the BPHY driver is added. The BPHY driver handles ioctl to
> set/clear irq handlers in EL3 using SMC calls. The purpose of this is to
> handle some BPHY interrupts in userspace directly. In order to support this,
> we have to make some ugly hack to some core files like arch/arm64/mm/context.c
> or arch/arm64/mm/context.c, but the change is pretty simple and are protected
> with the specific kernel option.

perfect. Sounds safe for standard/base, so I'll look at merging it there.

Bruce

>
> [1] 
> https://lists.yoctoproject.org/pipermail/linux-yocto/2019-August/007886.html
> [2] 
> https://lists.yoctoproject.org/pipermail/linux-yocto/2019-August/007887.html
>
> Thanks,
> Kevin



-- 
- 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] Add the support for the Marvell cn96xx SoC

2019-09-03 Thread Bruce Ashfield
On Fri, Aug 30, 2019 at 1:01 AM Kevin Hao  wrote:
>
> On Tue, Aug 20, 2019 at 07:21:04PM +0800, Kevin Hao wrote:
> > Hi Bruce,
> >
> > This patch series adds the support for the Marvell cn96xx SoC. The OCTEON 
> > TX2
> > cn96xx SoC is a scalable architecture that integrates high performance 
> > 64-bit
> > Armv8.2 processors, a cache-coherent interconnect, hardware accelerators,
> > virtualized networking, and scalable I/O. It support the following
> > industry-standard I/O interfaces:
> >   DDR4 DRAM
> >   PCI Express 4.0 version 1.0
> >   SGMII
> >   QSGMII
> >   XAUI
> >   XFI
> >   CAUI
> >
> > Most of the patches are for the Marvell specific drivers. So in theory, it
> > should be safe to merge these patches to the standard/base branch. But I
> > prefer to stage them to the specific standard/cn96xx branch. The reason is
> > that we plan to support other Marvell SoCs, and the SDK for them may be
> > based on different SDK versions. They will definitely touch some common
> > files affect by this patch series. So it would be a nightmare for us to
> > support them if these patches are merged to the standard/base branch.
>
> Ping...

Sorry. I managed to miss this after my vacation. Once I have the
current critical issues in master (around the 5.2 kernel) sorted out,
I'll get this merged. I hope to have that done today.

Bruce

>
> Thanks,
> Kevin
>
> >
> > The following changes since commit ce4ec6ff9589e3b1dcc4e3a0b192b02823631c3e:
> >
> >   Merge tag 'v5.3-rc5' into standard/base (2019-08-18 22:40:47 -0400)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/haokexin/linux standard/cn96xx
> >
> > for you to fetch changes up to 4fae437f7ea88d2aab10cac684e11d94b12114bd:
> >
> >   octeontx2-af: Fix the using of variable length arrays (2019-08-20 
> > 11:25:36 +0800)
> >
> > 
> > Aleksey Makarov (6):
> >   octeontx2-pf: Set irq affinity hints for CQ interrupts
> >   octeontx2-pf: Implement ndo_tx_timeout callback
> >   octeontx2-pf: Support queue interrupts
> >   octeontx2-pf: Add reset count to stats
> >   octeontx2-af: Add low level support for Marvell PTP coprocessor
> >   octeontx2-pf: Add support for PTP clock
> >
> > Angela Czubak (2):
> >   octeontx2-af: fix rvu_sso_ggrp_taq_flush
> >   octeontx2-af: fix cgx_lmac_rx_tx_enable
> >
> > Chandrakala Chavva (1):
> >   mmc: cavium_thunderx: Use proper register to clear interrupts
> >
> > Christina Jacob (21):
> >   octeontx2-pf: BQL support.
> >   octeontx2-pf: IRQ coalescing config and tuning via ethtool
> >   octeontx2-af: Dump current resource provisioning status
> >   octeontx2-pf: Adding ethtool support for link status information.
> >   octeontx2-af: Patch to prevent redundant message from pf to af.
> >   octeontx2-pf: Fix redundant message from AF to PF
> >   octeontx2-af: Support to get link info like current speed, fec etc
> >   octeontx2-pf: Ethtool support for fec configuration
> >   octeontx2-pf: Fix smmuv3 messages while deferring pf driver probe.
> >   octeontx2-af: Move to rvu_fwdata version 1.
> >   octeontx2-pf: Add ethtool -m option support.
> >   octeontx2-af: Extend fwdata structure with additional information.
> >   octeontx2-af: Update fwadata structure with few more reserved fields.
> >   octeontx2-af: Fetch FEC stats of the physical link
> >   octeontx2-pf: Support to display fec counters also in ethtool stats.
> >   octeontx2-af: sync ATF and Kernel firmware data structure.
> >   octeontx2-pf: Support to display current settings of a vf network 
> > interface via ethtool
> >   net:thunderx: fix memory leak in nicvf driver.
> >   soc: octeontx2: Add mdio command interface using debugfs
> >   octeontx2-af: Introduce SET_LINK_MODE command to change various 
> > configurations of a network interface.
> >   octeontx2-pf: support to change link speed and autoneg
> >
> > Felix Manlunas (2):
> >   octeontx2-af: Add new CGX_CMDs to set and get PHY modulation type
> >   octeontx2-pf: Add ethtool priv flag to control PAM4 on/off
> >
> > Geetha sowjanya (26):
> >   octeontx2-af: Sync hw mbox with bounce buffer.
> >   octeontx2-pf: Add mailbox bounce buffer
> >   octeontx2-pf: Add interface stats to ndo_get_stats64
> >   octeontx2-af: Config receive and transmission of pause frames
> >   octeontx2-af: Add mbox message to enable/disable pause frames.
> >   octeontx2-af: Add mbox messages to configure backpressure for an 
> > interface.
> >   octeontx2-pf: Add ethtool support to enable/disable pause frames
> >   octeontx2-pf: Configure RED drop levels for packet reception.
> >   octeontx2-pf: Configure backpressure level for packet reception
> >   octeontx2-pf: Skip CQ_STATUS read if pending CQEs greater than budget
> >   octeontx2-pf: Set RVU PF/VF watchdog 

Re: [linux-yocto] [kernel-meta v5.2 0/2] Fix the kernel_configcheck warnings for the v5.2 kernel

2019-08-29 Thread Bruce Ashfield
Thanks Kevin,

I now have these merged and they'll be part of my next 5.2 recipe revision.

Bruce

On Thu, Aug 29, 2019 at 4:30 AM Kevin Hao  wrote:
>
> These two patches fix the kernel_configcheck warnings when building the
> v5.2 kernel.
>
> Kevin Hao (2):
>   fsl-mpc8315e-rdb/beaglebone: Replace CONFIG_MTD_NAND with
> CONFIG_MTD_RAW_NAND
>   beaglebone: Drop the stale kernel options
>
>  bsp/beaglebone/beaglebone.cfg | 4 +---
>  bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg | 2 +-
>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> --
> 2.14.4
>


-- 
- 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] [kernel-cache master] nxp-ls20xx: add kernel-cache configuration files for BSP nxp-ls20xx

2019-08-29 Thread Bruce Ashfield
merged

Bruce

On Thu, Aug 29, 2019 at 3:08 AM Xulin Sun  wrote:
>
> This adds the cfg & scc files to support the LS2088A-RDB.
>
> Signed-off-by: Xulin Sun 
> ---
>  bsp/nxp-ls20xx/nxp-ls20xx-standard.scc |   8 ++
>  bsp/nxp-ls20xx/nxp-ls20xx.cfg  | 162 +
>  bsp/nxp-ls20xx/nxp-ls20xx.scc  |   7 ++
>  3 files changed, 177 insertions(+)
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx.cfg
>  create mode 100755 bsp/nxp-ls20xx/nxp-ls20xx.scc
>
> diff --git a/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc 
> b/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
> new file mode 100755
> index ..e0d9b2b7
> --- /dev/null
> +++ b/bsp/nxp-ls20xx/nxp-ls20xx-standard.scc
> @@ -0,0 +1,8 @@
> +define KMACHINE nxp-ls20xx
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard/standard.scc
> +branch nxp-ls20xx
> +
> +include nxp-ls20xx.scc
> diff --git a/bsp/nxp-ls20xx/nxp-ls20xx.cfg b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
> new file mode 100755
> index ..f554c916
> --- /dev/null
> +++ b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
> @@ -0,0 +1,162 @@
> +..
> +.WARNING
> +.
> +. This file is a kernel configuration fragment, and not a full kernel
> +. configuration file.  The final kernel configuration is made up of
> +. an assembly of processed fragments, each of which is designed to
> +. capture a specific part of the final configuration (e.g. platform
> +. configuration, feature configuration, and board specific hardware
> +. configuration).  For more information on kernel configuration, please
> +. consult the product documentation.
> +.
> +..
> +
> +CONFIG_ARM64=y
> +CONFIG_ARM64_VA_BITS_48=y
> +CONFIG_ARCH_LAYERSCAPE=y
> +CONFIG_SCHED_MC=y
> +CONFIG_ARM_SMMU=y
> +CONFIG_ARM_SMMU_V3=y
> +
> +CONFIG_PCI=y
> +CONFIG_PCI_LAYERSCAPE=y
> +CONFIG_PCI_HOST_GENERIC=y
> +CONFIG_PCI_XGENE=y
> +CONFIG_PCI_MSI=y
> +
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_STAT=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +CONFIG_CPUFREQ_DT=y
> +CONFIG_QORIQ_CPUFREQ=y
> +
> +CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_CFI=y
> +CONFIG_MTD_CFI_ADV_OPTIONS=y
> +CONFIG_MTD_CFI_INTELEXT=y
> +CONFIG_MTD_CFI_AMDSTD=y
> +CONFIG_MTD_CFI_STAA=y
> +CONFIG_MTD_DATAFLASH=y
> +CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SST25L=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_MTD_NAND_FSL_IFC=y
> +CONFIG_SPI_FSL_QUADSPI=y
> +CONFIG_SCSI_SAS_ATA=y
> +CONFIG_SCSI_HISI_SAS=y
> +CONFIG_ATA=y
> +CONFIG_SATA_AHCI=y
> +CONFIG_SATA_AHCI_PLATFORM=y
> +CONFIG_AHCI_CEVA=y
> +CONFIG_AHCI_XGENE=y
> +CONFIG_AHCI_QORIQ=y
> +CONFIG_SATA_SIL24=y
> +
> +CONFIG_FSL_XGMAC_MDIO=y
> +CONFIG_HNS_DSAF=y
> +CONFIG_HNS_ENET=y
> +CONFIG_E1000=y
> +CONFIG_E1000E=y
> +
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_DW=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_FSL_LPUART=y
> +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
> +
> +CONFIG_SPI=y
> +CONFIG_SPI_FSL_DSPI=y
> +CONFIG_SPI_PL022=y
> +CONFIG_SPI_NXP_FLEXSPI=y
> +
> +CONFIG_POWER_RESET_XGENE=y
> +CONFIG_POWER_RESET_SYSCON=y
> +CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> +
> +CONFIG_THERMAL=y
> +CONFIG_THERMAL_OF=y
> +CONFIG_CPU_THERMAL=y
> +CONFIG_THERMAL_EMULATION=y
> +CONFIG_WATCHDOG=y
> +CONFIG_ARM_SP805_WATCHDOG=y
> +
> +CONFIG_USB=y
> +CONFIG_USB_OTG=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC2=y
> +CONFIG_USB_GADGET=y
> +
> +CONFIG_MMC=y
> +CONFIG_MMC_ARMMMCI=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_PLTFM=y
> +CONFIG_MMC_SDHCI_OF_ARASAN=y
> +CONFIG_MMC_SDHCI_OF_ESDHC=y
> +CONFIG_MMC_SDHCI_CADENCE=y
> +CONFIG_MMC_SPI=y
> +CONFIG_MMC_DW=y
> +
> +CONFIG_GPIOLIB=y
> +CONFIG_OF_GPIO=y
> +
> +CONFIG_MDIO_DEVICE=y
> +CONFIG_MDIO_BITBANG=y
> +CONFIG_PHYLIB=y
> +CONFIG_AQUANTIA_PHY=y
> +CONFIG_CORTINA_PHY=y
> +
> +#
> +# I2C support
> +#
> +CONFIG_I2C=y
> +CONFIG_I2C_MUX=y
> +CONFIG_I2C_IMX=y
> +CONFIG_I2C_MUX_PCA954x=y
> +
> +CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_DS3232=y
> +CONFIG_RTC_DRV_PL031=y
> +CONFIG_RTC_DRV_PCF2127=y
> +
> +CONFIG_DMADEVICES=y
> +CONFIG_FSL_EDMA=y
> +CONFIG_CMA=y
> +CONFIG_DMA_CMA=y
> +
> +CONFIG_VFIO=y
> +CONFIG_VFIO_PCI=y
> +
> +CONFIG_STAGING=y
> +CONFIG_FSL_MC_BUS=y
> +CONFIG_FSL_MC_DPIO=y
> +
> +CONFIG_CLK_QORIQ=y
> +
> +CONFIG_PHY_XGENE=y
> +
> +CONFIG_CRYPTO_DEV_FSL_CAAM=y
> +CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=y
> +CONFIG_ARM64_CRYPTO=y
> +CONFIG_CRYPTO_SHA1_ARM64_CE=y
> +CONFIG_CRYPTO_SHA2_ARM64_CE=y
> +CONFIG_CRYPTO_GHASH_ARM64_CE=y
> +CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
> +CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
> +# CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is not set
> +
> +# EDAC
> +CONFIG_EDAC_LAYERSCAPE=y
> +
> +CONFIG_SENSORS_LM90=y
> 

Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/base]: renesas-rcar: add some patches to improve features on renesas-rcar platform

2019-08-29 Thread Bruce Ashfield
all three are now merged to linux-yocto-dev.

Bruce

On Thu, Aug 29, 2019 at 2:31 AM  wrote:
>
> From: Limeng 
>
> Hi Bruce,
>
> I am working on BSP renesas-rcar platform, and intend to merge this BSP 
> supporting into yocto community.
> Below 3 patches are used to improve gpio, CAN BUS, audio and PCIe features
>
> 0001-arch-arm64-dts-Set-gpio5-pin9-as-input-by-default.patch
> 0002-driver-net-can-disable-clock-when-it-is-in-enable-st.patch
> 0003-pci-pcie-rcar-add-regulators-support.patch
>
> Could you please merge the 3 patches into linux-yocto-dev, branch is 
> standard/base?
>
>  arch/arm64/boot/dts/renesas/ulcb-kf.dtsi |   56 +++
>  drivers/net/can/rcar/rcar_can.c  |5 +-
>  drivers/pci/controller/pcie-rcar.c   |   64 
> +++
>  3 files changed, 124 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] [PATCH] renesas-rcar: enable PCM3168A-I2C codec drvier

2019-08-29 Thread Bruce Ashfield
merged to master.

Bruce

On Tue, Aug 27, 2019 at 4:59 AM  wrote:
>
> From: Limeng 
>
> On KingFisher board, there is PCM3168A codec chip, so enable
> PCM3168A-I2C codec driver by setting configure
> CONFIG_SND_SOC_PCM3168A_I2C
>
> Signed-off-by: Meng Li 
> ---
>  bsp/renesas-rcar/renesas-rcar.cfg | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/bsp/renesas-rcar/renesas-rcar.cfg 
> b/bsp/renesas-rcar/renesas-rcar.cfg
> index 102441ab..cc896276 100644
> --- a/bsp/renesas-rcar/renesas-rcar.cfg
> +++ b/bsp/renesas-rcar/renesas-rcar.cfg
> @@ -96,6 +96,7 @@ CONFIG_SND_SOC_AK4613=y
>  CONFIG_SND_SOC_HDMI_CODEC=y
>  CONFIG_SND_SIMPLE_CARD=y
>  CONFIG_SND_AUDIO_GRAPH_CARD=y
> +CONFIG_SND_SOC_PCM3168A_I2C=y
>
>  # Clock configuration
>  CONFIG_COMMON_CLK=y
> --
> 2.17.1
>


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


Re: [linux-yocto] [PATCH] aufs: for v5.3-rc3, update UAPI SPDX

2019-08-29 Thread Bruce Ashfield
merged

Bruce

On Thu, Aug 29, 2019 at 9:52 AM  wrote:
>
> From: "J. R. Okajima" 
>
> Simply follows the commit in mainline,
> 622445541b75 2019-07-29 kbuild: detect missing "WITH
> Linux-syscall-note" for uapi headers
>
> Signed-off-by: J. R. Okajima 
>
> Backport from git://github.com/sfjro/aufs5-linux.git
> 90ff497cebbb ("aufs: for v5.3-rc3, update UAPI SPDX")
> to fix,
> error: kernel-source/include/uapi/linux/aufs_type.h: missing "WITH 
> Linux-syscall-note" for SPDX-License-Identifier
>
> Signed-off-by: He Zhe 
> ---
> This is for linux-yocto-dev all branches.
>
>  include/uapi/linux/aufs_type.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/aufs_type.h b/include/uapi/linux/aufs_type.h
> index 0e3e2b1..59f050c 100644
> --- a/include/uapi/linux/aufs_type.h
> +++ b/include/uapi/linux/aufs_type.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>  /*
>   * Copyright (C) 2005-2019 Junjiro R. Okajima
>   *
> --
> 2.7.4
>


-- 
- 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] [PATCH] module: Fix build failure due to cracked commit

2019-08-26 Thread Bruce Ashfield
oops. Sorry about that, I forgot to push the resolution I did earlier
today for this. It should be in the tree now.

Bruce

On Mon, Aug 26, 2019 at 10:14 PM  wrote:
>
> From: He Zhe 
>
> This is the missing half of the following commit that is cracked during 
> merging,
> which causes build failure.
> 3b5be16c7e90 ("modules: page-align module section allocations only for arches 
> supporting strict module rwx")
>
> Signed-off-by: He Zhe 
> ---
> This is for every branches of linux-yocto-dev.
>
>  kernel/module.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 92e3c2e..9ee9342 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -69,6 +69,9 @@
>   */
>  #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
>  # define debug_align(X) ALIGN(X, PAGE_SIZE)
> +#else
> +# define debug_align(X) (X)
> +#endif
>
>  /* If this is set, the section belongs in the init part of the module */
>  #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
> --
> 2.7.4
>


-- 
- 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] Merge tag 'v5.3-rc6' into standard/base

2019-08-26 Thread Bruce Ashfield
On Mon, Aug 26, 2019 at 6:50 AM Jun Miao  wrote:
>
> Hi Bruce,
>
>I am sorry to trouble you .
>
>When you merge tag 'v5.3-rc6' into standard/base, why you delete  "define 
> debug_align(X) (X)" and lose the "#endif" (#ifend ... #endif)  ?
>

Hmm. That wasn't on purpose. My builds ran overnight, so I'll have a
look and fix it up.

Bruce

>
> --
>
> commit b73b90b1d2cc6b4ba740e66479ab054482174f94
> Merge: ce4ec6f a55aa89
> Author: Bruce Ashfield 
> Date:   Sun Aug 25 22:28:04 2019 -0400
>
> Merge tag 'v5.3-rc6' into standard/base
>
> Linux 5.3-rc6
>
> Signed-off-by: Bruce Ashfield 
>
> diff --cc kernel/module.c
> index cd8df51,9ee9342..92e3c2e
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@@ -64,9 -64,14 +64,11 @@@
>
>   /*
>* Modules' sections will be aligned on page boundaries
> -  * to ensure complete separation of code and data
> +  * to ensure complete separation of code and data, but
> +  * only when CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
>*/
> + #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
>   # define debug_align(X) ALIGN(X, PAGE_SIZE)
>  -#else
>  -# define debug_align(X) (X)
>  -#endif
>
>
> --
> Thanks
> Jun



-- 
- 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] : [kernel-cache master]: renesas-rcar: add configure file for renesas BSP in kernel-cache

2019-08-25 Thread Bruce Ashfield
On Wed, Aug 21, 2019 at 6:15 AM  wrote:
>
> From: Limeng 
>
> Hi Bruce,
>
> I am working on BSP renesas-rcar platform, and intend to merge this BSP 
> supporting into yocto community.
> Below patch includes scc and cfg files for renesas-rcar platform.
>
> Could you please merge this patch into yocto-kernel-cache, branch is master?
>

Merged!

Bruce

>
> 0001-renesas-rcar-add-configure-file-for-renesas-BSP-in-k.patch
>
>  renesas-rcar-h3-standard.scc |7 +
>  renesas-rcar-m3-standard.scc |7 +
>  renesas-rcar.cfg |  251 
> +++
>  renesas-rcar.scc |8 +
>  4 files changed, 273 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] v4.18.x - stable updates comprising v4.18.42

2019-08-25 Thread Bruce Ashfield
On Sun, Aug 18, 2019 at 10:14 AM Paul Gortmaker
 wrote:
>
> Bruce, Yocto kernel folks:
>
> Here is the next 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.41 release.
>
> There are about 150 commits here, based on the remaining commits that
> were used in the 4.19.46/47 stable releases -- but not put into the
> previous 4.10.40 release in order to keep the commit count reasonable.
>
> These 4.18 stable backport releases will be ending in September, as I
> will be moving to working on newer kernels.  Hopefully with the same
> messaging being in the last few releases, this is no surprise to anyone,
> and people are in the final stages of getting their own maintenance or
> migration plans in place and rolled out.
>
> I've put this 4.18.x queue through the usual testing; build testing
> on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> and finally some sanity runtime tests on x86-64.
>
> I did the signed tag just as per the previously released versions.
> Please find a signed v4.18.42 tag using this key:
>

Hey Paul,

I was merging this tonight and ran into a nasty -rt merge conflict in
kernel/irq_work.c. Can you take a look and send a resolution ? When I
compared the 4.19-rt and 5.x-rt branches, I didn't see an obvious way
to resolve things.

Bruce

> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
>
> for merge to standard/base in linux-yocto-4.18 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.18.x release.
>
> Paul.



-- 
- 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] [PATCH] modules: always page-align module section allocations

2019-08-18 Thread Bruce Ashfield
On Fri, Aug 16, 2019 at 12:01 PM  wrote:
>
>
> 在 2019年8月16日 23:29,Paul Gortmaker  写下:
> >
> > [[linux-yocto] [PATCH] modules: always page-align module section 
> > allocations] On 16/08/2019 (Fri 15:36) zhe...@windriver.com wrote:
> >
> > It helps maintainers if the version is embedded in the subject, like:
> >
> >   [PATCH v4.18] modules: always page-align module section
> >
> > > From: Jessica Yu 
> > >
> > > Some arches (e.g., arm64, x86) have moved towards non-executable
> > > module_alloc() allocations for security hardening reasons. That means
> > > that the module loader will need to set the text section of a module to
> > > executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
> > >
> > > When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
> > > page-aligned to handle memory rwx permissions. On some arches with
> > > CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
> > > executable, the BUG_ON() in frob_text() gets triggered since module
> > > section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
> > > Since the set_memory_* API works with pages, and since we need to call
> > > set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
> > > might as well page-align all module section allocations for ease of
> > > managing rwx permissions of module sections (text, rodata, etc).
> > >
> > > Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
> > > Reported-by: Martin Kaiser 
> > > Reported-by: Bartosz Golaszewski 
> > > Tested-by: David Lechner 
> > > Tested-by: Martin Kaiser 
> > > Tested-by: Bartosz Golaszewski 
> > > Signed-off-by: Jessica Yu 
> > >
> > > commit 38f054d549a869f22a02224cd276a27bf14b6171 upstream
> >
> > Normally we put this right at the top of the long log.  Also this commit
> > ID appears bogus - it does not exist in mainline.
>
> Yes, it's from modules-next,
> https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/commit/?h=modules-next

I went ahead and cleaned up the commit log, since we never say "commit
 upstream", if "upstream" is not linus' main git repo. I've
pointed at modules-next, and hopefully it is well behaved and won't be
rebased.

I didn't see it in -rc5, so hopefully it makes it upstream soon.

>
> I can't wait as It blocks something.
>
> >
> > Also it seems very odd that the block of Signed-off lines are stuck in
> > the middle of the long log.
> >
> > >
> > > When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
> > > CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
> > > not be page-aligned and cause the following BUG during frob_text.
> > >
> > > [ cut here ]
> > > kernel BUG at kernel/module.c:1907!
> > > Internal error: Oops - BUG: 0 [#1] ARM
> > > Modules linked in:
> > > CPU: 0 PID: 89 Comm: systemd-modules Not tainted 5.3.0-rc2 #1
> > > Hardware name: ARM-Versatile (Device Tree Support)
> > > PC is at frob_text.constprop.0+0x2c/0x40
> > > LR is at load_module+0x14b4/0x1d28
> > > pc : []lr : []psr: 2013
> > > sp : ce44fe58  ip :   fp : 
> > > r10:   r9 : ce44feb8  r8 : 
> > > r7 : 0001  r6 : bf00032c  r5 : ce44ff40  r4 : bf000320
> > > r3 : bf000400  r2 : 0fff  r1 : 0220  r0 : bf00
> > > Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> > > Control: 00093177  Table: 0e4c  DAC: 0051
> > > Process systemd-modules (pid: 89, stack limit = 0x9fccc8dc)
> > > Stack: (0xce44fe58 to 0xce45)
> > > fe40:    
> > > cf1b05b8
> > > fe60: 0001 ce47cf08 bf002754 c07ae5d8 d0a2a484 bf002060 bf0004f8 
> > > 
> > > fe80: b6d17910 c017cf1c ce47cf00 d0a29000 ce47cf00 ce44ff34 14fc 
> > > 
> > > fea0:   bf00025c 0001   6e72656b 
> > > 6c65
> > > fec0:        
> > > 
> > > fee0:      c0ac9048 7fff 
> > > 
> > > ff00: b6d17910 0005 017b c0009208 ce44e000  b6ebfe54 
> > > c008562c
> > > ff20: 7fff  0003 cefd28f8 0001 d0a29000 14fc 
> > > 
> > > ff40: d0a292cb d0a29380 d0a29000 14fc d0a29f0c d0a29d90 d0a29a60 
> > > 0520
> > > ff60: 0710 0718 0826    0708 
> > > 0023
> > > ff80: 0024 001c  0016  c0ac9048 0041c620 
> > > 
> > > ffa0:  c0009000 0041c620  0005 b6d17910  
> > > 
> > > ffc0: 0041c620   017b 0041f078  004098b0 
> > > b6ebfe54
> > > ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0 6010 0005  
> > > 
> > > [] (frob_text.constprop.0) from [] 
> > > (load_module+0x14b4/0x1d28)
> > > [] (load_module) from [] (sys_finit_module+0xa0/0xc4)
> > > [] 

Re: [linux-yocto] [kernel-cache master][PATCH 1/1] ti-am335x: enable kernel options for PMIC support

2019-08-18 Thread Bruce Ashfield
merged

Bruce

On Thu, Aug 15, 2019 at 5:29 AM Jun Miao  wrote:
>
> add Power Management IC support.
> TPS65910: am335x EVM/SK
> TPS65217: am335x BBB
>
> Signed-off-by: Jun Miao 
> ---
>  bsp/ti-am335x/ti-am335x.cfg | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
> index 77085326..bd2711c8 100644
> --- a/bsp/ti-am335x/ti-am335x.cfg
> +++ b/bsp/ti-am335x/ti-am335x.cfg
> @@ -32,6 +32,8 @@ CONFIG_NEON=y
>  CONFIG_PM=y
>  CONFIG_REGMAP_IRQ=y
>
> +CONFIG_REGULATOR_TPS65910=y
> +CONFIG_REGULATOR_TPS65217=y
>  #
>  # RAM/ROM/Flash chip drivers
>  #
> --
> 2.22.0
>


-- 
- 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] [PATCH 0/4] More security fragments

2019-08-12 Thread Bruce Ashfield
I've merged these to the 4.19/5.0/5.2 and master branches.

SRCREV updates will follow this week, once I get some more test cycles
completed.

Bruce

On Sun, Aug 11, 2019 at 12:29 PM Armin Kuster  wrote:

> It is time to move the kernel fragments out of meta-security to cache.
> It should make maintenance easier.
>
> Armin Kuster (4):
>   kernel-cache: add apparmor fragments
>   kernel-cache: add smack
>   kernel-cache: add ima fragments
>   kernel-cache: add yama security fragments
>
>  features/apparmor/apparmor.cfg |  7 +++
>  features/apparmor/apparmor.scc |  5 +
>  features/apparmor/apparmor_on_boot.cfg |  1 +
>  features/ima/ima.cfg   | 18 ++
>  features/ima/ima.scc   |  4 
>  features/ima/ima_evm_root_ca.cfg   |  3 +++
>  features/ima/modsign.cfg   |  3 +++
>  features/ima/modsign.scc   |  6 ++
>  features/smack/smack.cfg   | 10 ++
>  features/smack/smack.scc   |  4 
>  features/yama/yama.cfg |  1 +
>  features/yama/yama.scc |  4 
>  12 files changed, 66 insertions(+)
>  create mode 100644 features/apparmor/apparmor.cfg
>  create mode 100644 features/apparmor/apparmor.scc
>  create mode 100644 features/apparmor/apparmor_on_boot.cfg
>  create mode 100644 features/ima/ima.cfg
>  create mode 100644 features/ima/ima.scc
>  create mode 100644 features/ima/ima_evm_root_ca.cfg
>  create mode 100644 features/ima/modsign.cfg
>  create mode 100644 features/ima/modsign.scc
>  create mode 100644 features/smack/smack.cfg
>  create mode 100644 features/smack/smack.scc
>  create mode 100644 features/yama/yama.cfg
>  create mode 100644 features/yama/yama.scc
>
> --
> 2.17.1
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>


-- 
- 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] [kernel-cache] Question about profiling.scc

2019-08-07 Thread Bruce Ashfield
On Wed, Aug 7, 2019 at 10:03 PM Hongzhi, Song 
wrote:

> Hi Bruce,
>
>
> profiling.cfg is just designed for powertop and oprofile.
>

that comment is a bit misleading. Things like perf events, rely on
config_profiling .. so it is more of a base config than just for those two.

bruce



>
>1 # for oprofile and powertop
>2 CONFIG_PROFILING=y
>3 CONFIG_OPROFILE=y
>4 CONFIG_FRAME_POINTER=y
>5 CONFIG_X86_LOCAL_APIC=y
>
> Maybe split profiling.cfg and move them to their recipe is a good way.
>
>
> --Hongzhi
>
>
>
> On 8/7/19 10:43 AM, Bruce Ashfield wrote:
> >
> >
> > On Mon, Aug 5, 2019 at 11:44 PM Hongzhi, Song
> > mailto:hongzhi.s...@windriver.com>> wrote:
> >
> > Hi Bruce,
> >
> > I see profiling.scc is included by kernel-cache/bsp/*, such as
> > bsp/intel-x86 bsp/common-pc/ ... .
> >
> >
> > My question is that is it necessary to open profiling.cfg defaultly?
> >
> >
> > We left profiling as a per-BSP decision, since production machine
> > configurations don't want the overhead that it brings.
> >
> > Not all BSPs follow the split between developer and production, but
> > see how it is used in:
> >
> > bsp/common-pc-64/common-pc-64-developer.scc:include
> > features/profiling/profiling.scc
> > bsp/common-pc-64/common-pc-64-preempt-rt.scc:include
> > features/profiling/profiling.scc
> >
> > If it was enabled by default, it really should be in the developer
> > ktype and then BSPs could have the split between production and
> > developer/debug in their definitions .. with the developer ones
> > getting profiling by default.
> >
> > Bruce
> >
> >
> >
> > --Hongzhi
> >
> >
> >
> > --
> > - 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] v4.18.x - stable updates comprising v4.18.41

2019-08-07 Thread Bruce Ashfield
On Fri, Aug 2, 2019 at 11:43 PM Paul Gortmaker 
wrote:

> Bruce, Yocto kernel folks:
>
> Here is the next 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.40 release.
>
> There are about 220 commits here, based on commits chosen from what were
> used in the 4.19.46/47 stable releases -- plus some TCP related commits
> that were of interest to reach ahead and source from newer 4.19 now.
> Not all the 47 content was processed here, in order to keep the release
> size sane.  The remainder will be considered for the 4.18.42 release.
>
> And as we enter August, I need to again remind people that the creation
> of these 4.18 stable backport releases will be ending relatively soon,
> as I'll expect to be moving to newer kernels used in newer Yocto
> releases.  So people need to get their own maintenance or migration
> plans in place as soon as possible, if they have not yet done so.
>
> I've put this 4.18.x queue through the usual testing; build testing
> on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> and finally some sanity runtime tests on x86-64.
>
> I did the signed tag just as per the previously released versions.
> Please find a signed v4.18.41 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
>
> for merge to standard/base in linux-yocto-4.18 and then out from there
> into the other base and BSP branches.
>

Thanks Paul, this is now merged!

Bruce



>
> For those who are interested, the evolution of the commits is here:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.18.x release.
>
> Paul.
>


-- 
- 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] [kernel-cache master][PATCH][V2] ti-am335x: add the basic scc/cfg enablement

2019-08-07 Thread Bruce Ashfield
I've merged v2, and created the standard/ti-am335x in linux-yocto-dev.

Bruce


On Wed, Aug 7, 2019 at 3:54 AM Jun Miao  wrote:

> Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black
> boards all with am335x soc
>
> Signed-off-by: Jun Miao 
> ---
>  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
>  bsp/ti-am335x/ti-am335x.cfg  | 236 +++
>  bsp/ti-am335x/ti-am335x.scc  |   8 +
>  cfg/remoteproc.cfg   |   3 +
>  4 files changed, 255 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
>  create mode 100644 cfg/remoteproc.cfg
>
> diff --git a/bsp/ti-am335x/ti-am335x-standard.scc
> b/bsp/ti-am335x/ti-am335x-standard.scc
> new file mode 100644
> index ..d357a729
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x-standard.scc
> @@ -0,0 +1,8 @@
> +define KMACHINE ti-am335x
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard/standard.scc
> +branch ti-am335x
> +
> +include ti-am335x.scc
> diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
> new file mode 100644
> index ..77085326
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x.cfg
> @@ -0,0 +1,236 @@
> +#.
> +#WARNING
> +#
> +# This file is a kernel configuration fragment, and not a full kernel
> +# configuration file.  The final kernel configuration is made up of
> +# an assembly of processed fragments, each of which is designed to
> +# capture a specific part of the final configuration (e.g. platform
> +# configuration, feature configuration, and board specific hardware
> +# configuration).  For more information on kernel configuration, please
> +# consult the product documentation.
> +#
> +#.
> +
> +CONFIG_ARM=y
> +CONFIG_ARCH_OMAP=y
> +CONFIG_OMAP_DM_TIMER=y
> +CONFIG_SOC_AM33XX=y
> +CONFIG_ARCH_OMAP2PLUS=y
> +
> +
> +#
> +# At least one emulation must be selected
> +#
> +CONFIG_VFP=y
> +CONFIG_VFPv3=y
> +CONFIG_NEON=y
> +
> +#
> +# Power management options
> +#
> +
> +CONFIG_PM=y
> +CONFIG_REGMAP_IRQ=y
> +
> +#
> +# RAM/ROM/Flash chip drivers
> +#
> +CONFIG_OMAP_OCP2SCP=y
> +CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> +CONFIG_MTD_BLKDEVS=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_NAND_ECC=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_MTD_CFI=y
> +CONFIG_MTD_CFI_INTELEXT=y
> +
> +CONFIG_MTD_NAND=y
> +CONFIG_MTD_NAND_OMAP2=y
> +CONFIG_MTD_NAND_OMAP_BCH=y
> +CONFIG_MTD_NAND_OMAP_BCH_BUILD=y
> +
> +# Misc devices
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SENSORS_LIS3_I2C=y
> +CONFIG_BLK_DEV_SD=y
> +
> +CONFIG_ETHERNET=y
> +CONFIG_NET_VENDOR_TI=y
> +CONFIG_TI_DAVINCI_MDIO=y
> +CONFIG_TI_DAVINCI_CPDMA=y
> +CONFIG_TI_CPSW_PHY_SEL=y
> +CONFIG_TI_CPSW_ALE=y
> +CONFIG_TI_CPSW=y
> +CONFIG_TI_CPTS=y
> +CONFIG_PHYLIB=y
> +
> +CONFIG_SMSC_PHY=y
> +CONFIG_FIXED_PHY=y
> +
> +#
> +# Input Device Drivers
> +#
> +
> +CONFIG_INPUT=y
> +CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_INPUT_EVDEV=y
> +CONFIG_INPUT_KEYBOARD=y
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_MATRIX=y
> +CONFIG_INPUT_TOUCHSCREEN=y
> +CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_TPS65218_PWRBUTTON=m
> +CONFIG_SERIAL_EARLYCON=y
> +
> +#
> +# 8250 serial port support
> +#
> +
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_8250_OMAP=y
> +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
> +
> +CONFIG_SERIAL_CORE=y
> +CONFIG_SERIAL_CORE_CONSOLE=y
> +
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_OMAP=y
> +
> +# I2C support
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_OMAP=y
> +CONFIG_SENSORS_TSL2550=y
> +CONFIG_GPIO_TWL4030=y
> +CONFIG_PTP_1588_CLOCK=y
> +CONFIG_GPIO_PCF857X=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_SINGLE=y
> +
> +CONFIG_GPIOLIB=y
> +CONFIG_OF_GPIO=y
> +CONFIG_GPIOLIB_IRQCHIP=y
> +CONFIG_GPIO_SYSFS=y
> +
> +CONFIG_GPIO_OMAP=y
> +CONFIG_GPIO_PCA953X=m
> +CONFIG_GPIO_TPS65910=y
> +
> +CONFIG_WATCHDOG=y
> +CONFIG_WATCHDOG_CORE=y
> +CONFIG_OMAP_WATCHDOG=m
> +
> +CONFIG_MFD_SYSCON=y
> +CONFIG_MFD_TI_AM335X_TSCADC=y
> +CONFIG_MFD_OMAP_USB_HOST=y
> +CONFIG_MFD_TPS65217=y
> +CONFIG_MFD_TPS65218=y
> +CONFIG_MFD_TPS65910=y
> +CONFIG_TWL6040_CORE=y
> +
> +#
> +# LCD
> +#
> +CONFIG_DRM=y
> +CONFIG_DRM_OMAP=y
> +CONFIG_OMAP2_DSS_DPI=y
> +CONFIG_DRM_TILCDC=y
> +CONFIG_DRM_OMAP_PANEL_DPI=y
> +CONFIG_DRM_I2C_NXP_TDA998X=y
> +
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_LCD_CLASS_DEVICE=y
> +CONFIG_LCD_PLATFORM=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_GENERIC=y
> +CONFIG_PWM=y
> +CONFIG_BACKLIGHT_PWM=y
> +CONFIG_BACKLIGHT_GPIO=y
> +
> +
> +CONFIG_SOUND=m
> +CONFIG_SND=m
> +CONFIG_SND_SOC=m
> +CONFIG_SND_DAVINCI_SOC_MCASP=m
> +CONFIG_SND_SIMPLE_CARD=m
> +
> +
> +#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +#CONFIG_USB_MON=m
> +
> +#
> +# 

Re: [linux-yocto] [kernel-cache master]: ti-am335x

2019-08-07 Thread Bruce Ashfield
On Wed, Aug 7, 2019 at 2:01 AM Jun Miao  wrote:

>
> On 8/7/19 10:45 AM, Bruce Ashfield wrote:
> > On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:
> >
> >> Hi Bruce,
> >>
> >>  I am working ti boards(AM335x evm/sk/BBB) with am335x soc.
> >>
> >>  1.This patch add scc/cfg to yocto-kernel-cache master branch.
> >>
> > #1 shouldn't be a problem.
> >
> >  2.Could you help me build a new branch "ti-am335x" in
> >> linux-yocto-dev?
> >>
> >>
> > but #2 raises a question.  I try and limit the number of BSP specific
> > branches. What type of patches are you expecting to put on that branch,
> and
> > do you expect that they won't be safe for other boards ?
> >
> > Bruce
> >
> hi Bruce ,
>
> This branch is prepared for ti-am335x CI/CD development,and there will
> be some TI SDK patches into.
>
> i am afraid that those patches for ti-am335x(evm/sk/bbb) boards will
> influence other boards.
>

We should always try and keep patches clean .. but I  understand the
reality. I'll create the branch as I merge the kernel-cache parts and we
can revisit how long we need a BSP branch in the future.

Bruce



>
>
> Thanks
> Jun
>
> >
> >> Thanks
> >>
> >>
> >>
> >> Jun Miao (1):
> >>ti-am335x: add the basic scc/cfg enablement
> >>
> >>   bsp/ti-am335x/ti-am335x-standard.scc |   8 +
> >>   bsp/ti-am335x/ti-am335x.cfg  | 242 +++
> >>   bsp/ti-am335x/ti-am335x.scc  |   7 +
> >>   3 files changed, 257 insertions(+)
> >>   create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
> >>   create mode 100644 bsp/ti-am335x/ti-am335x.cfg
> >>   create mode 100644 bsp/ti-am335x/ti-am335x.scc
> >>
> >> --
> >> 2.22.0
> >>
> >>
>


-- 
- 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] [kernel-cache][master][PATCH 1/2] bsp/intel-x86: Set CONFIG_NODES_SHIFT to 6

2019-08-07 Thread Bruce Ashfield
I'm not sure if the intel folks are using these fragments and object to the
different behaviour, but they look ok to me. I've merged them for now, but
will reconsider if they cause problems in other configs.

Bruce

On Wed, Aug 7, 2019 at 3:27 AM Yongxin Liu 
wrote:

> This config specifies the maximum number (as a power of 2) of NUMA
> Nodes available on the target. 2^6 is big enough for most current
> systems.
>
> Signed-off-by: Yongxin Liu 
> ---
>  bsp/intel-x86/intel-x86.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg
> index 0056be44..c7682a71 100644
> --- a/bsp/intel-x86/intel-x86.cfg
> +++ b/bsp/intel-x86/intel-x86.cfg
> @@ -20,7 +20,7 @@ CONFIG_SCHED_SMT=y
>
>  CONFIG_NUMA=y
>  CONFIG_ACPI_NUMA=y
> -CONFIG_NODES_SHIFT=2
> +CONFIG_NODES_SHIFT=6
>
>  CONFIG_EXPERT=y
>  CONFIG_PROCESSOR_SELECT=y
> --
> 2.14.4
>
>

-- 
- 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] [PATCH] nfsd: Move nfsd patch from nfsd-enable.scc to new created nfs.scc

2019-08-07 Thread Bruce Ashfield
On Wed, Aug 7, 2019 at 3:25 AM  wrote:

> From: He Zhe 
>
> Remove nfsd patch from nfsd-enable.scc which can be included directly or by
> other features, and thus cause re-application of the patch.
>
> Create nfs.scc to include both configuration and patches for potential
> inclusion
> for BSPs and/or KTYPEs.
>

So clearly you are enabling this via a KERNEL_FEATURE, and triggered the
double patch.

I have no objection to moving it around this way, so this is now merged.

Bruce



>
> Signed-off-by: He Zhe 
> ---
>  features/nfsd/nfsd-enable.scc | 1 -
>  features/nfsd/nfsd.scc| 5 +
>  2 files changed, 5 insertions(+), 1 deletion(-)
>  create mode 100644 features/nfsd/nfsd.scc
>
> diff --git a/features/nfsd/nfsd-enable.scc b/features/nfsd/nfsd-enable.scc
> index ee85152..8a7835d 100644
> --- a/features/nfsd/nfsd-enable.scc
> +++ b/features/nfsd/nfsd-enable.scc
> @@ -2,4 +2,3 @@ define KFEATURE_DESCRIPTION "Enable NFS server support"
>  define KFEATURE_COMPATIBILITY all
>
>  kconf non-hardware nfsd.cfg
> -patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch
> diff --git a/features/nfsd/nfsd.scc b/features/nfsd/nfsd.scc
> new file mode 100644
> index 000..ee85152
> --- /dev/null
> +++ b/features/nfsd/nfsd.scc
> @@ -0,0 +1,5 @@
> +define KFEATURE_DESCRIPTION "Enable NFS server support"
> +define KFEATURE_COMPATIBILITY all
> +
> +kconf non-hardware nfsd.cfg
> +patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch
> --
> 2.7.4
>
>

-- 
- 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] [kernel-tools][PATCH] Add SPDX license headers to source files

2019-08-06 Thread Bruce Ashfield
Looks fine to me.

I'm traveling right now, so it will be a few days until I get this merged
and can send SRCREV updates to oe-core.

Bruce

On Tue, Aug 6, 2019 at 3:06 PM William Bourque  wrote:

> Kconfiglib/* were under ISC license before they were imported
> here from https://github.com/ulfalizer/Kconfiglib
> Adjusting SPDX header to reflect that fact.
>
> tools/* all have some sort of GPLv2 headers; adding SPDX header
> to make it obvious.
>
> This address bug #13334 :
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13334
>
> Change-Id: I243f2dd266a398f982798b771e74a67be70ecb52
> Signed-off-by: William Bourque 
> ---
>  Kconfiglib/examples/allnoconfig_walk.py| 2 ++
>  Kconfiglib/examples/defconfig.py   | 2 ++
>  Kconfiglib/examples/defconfig_oldconfig.py | 2 ++
>  Kconfiglib/examples/eval_expr.py   | 2 ++
>  Kconfiglib/examples/find_symbol.py | 2 ++
>  Kconfiglib/examples/help_grep.py   | 2 ++
>  Kconfiglib/examples/list_undefined.py  | 2 ++
>  Kconfiglib/examples/menuconfig_example.py  | 2 ++
>  Kconfiglib/examples/merge_config.py| 2 ++
>  Kconfiglib/examples/print_config_tree.py   | 2 ++
>  Kconfiglib/examples/print_sym_info.py  | 2 ++
>  Kconfiglib/examples/print_tree.py  | 2 ++
>  Kconfiglib/setup.py| 4 
>  Kconfiglib/tests/reltest   | 1 +
>  tools/buildall | 1 +
>  tools/get_defconfig| 1 +
>  tools/kconf_check  | 1 +
>  tools/kgit | 1 +
>  tools/kgit-checkpoint  | 1 +
>  tools/kgit-clean   | 1 +
>  tools/kgit-config-cleaner  | 1 +
>  tools/kgit-feature | 1 +
>  tools/kgit-init| 1 +
>  tools/kgit-meta| 1 +
>  tools/kgit-publish | 1 +
>  tools/kgit-s2q | 1 +
>  tools/kgit-scc | 1 +
>  tools/scc  | 1 +
>  tools/spp  | 1 +
>  tools/symbol_why.py| 2 ++
>  30 files changed, 46 insertions(+)
>
> diff --git a/Kconfiglib/examples/allnoconfig_walk.py
> b/Kconfiglib/examples/allnoconfig_walk.py
> index b94a169..05ec7b5 100644
> --- a/Kconfiglib/examples/allnoconfig_walk.py
> +++ b/Kconfiglib/examples/allnoconfig_walk.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # This is tree-walking version of allnoconfig.py, for demonstration
> purposes.
>  # Verified by the test suite to generate identical output to 'make
> allnoconfig'
>  # for all ARCHes.
> diff --git a/Kconfiglib/examples/defconfig.py
> b/Kconfiglib/examples/defconfig.py
> index cc3f12d..6797890 100644
> --- a/Kconfiglib/examples/defconfig.py
> +++ b/Kconfiglib/examples/defconfig.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Works like entering "make menuconfig" and immediately saving and exiting
>  #
>  # Usage:
> diff --git a/Kconfiglib/examples/defconfig_oldconfig.py
> b/Kconfiglib/examples/defconfig_oldconfig.py
> index 3735ee1..bf34e94 100644
> --- a/Kconfiglib/examples/defconfig_oldconfig.py
> +++ b/Kconfiglib/examples/defconfig_oldconfig.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Produces exactly the same output as the following script:
>  #
>  # make defconfig
> diff --git a/Kconfiglib/examples/eval_expr.py
> b/Kconfiglib/examples/eval_expr.py
> index 6d8695e..3eb49fb 100644
> --- a/Kconfiglib/examples/eval_expr.py
> +++ b/Kconfiglib/examples/eval_expr.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Evaluates an expression (e.g. "X86_64 || (X86_32 && X86_LOCAL_APIC)")
> in the
>  # context of a configuration. Note that this always yields a tristate
> value (n,
>  # m, or y).
> diff --git a/Kconfiglib/examples/find_symbol.py
> b/Kconfiglib/examples/find_symbol.py
> index 0d3c968..2e22fd7 100644
> --- a/Kconfiglib/examples/find_symbol.py
> +++ b/Kconfiglib/examples/find_symbol.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Prints all menu nodes that reference a given symbol any of their
> properties
>  # or property conditions, along with their parent menu nodes.
>  #
> diff --git a/Kconfiglib/examples/help_grep.py
> b/Kconfiglib/examples/help_grep.py
> index 20a4911..0e60512 100644
> --- a/Kconfiglib/examples/help_grep.py
> +++ b/Kconfiglib/examples/help_grep.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Does a case-insensitive search for a regular expression in the help
> texts of
>  # symbols and choices and the prompts of menus and comments. Prints the
>  # matching items together with their locations and the matching text.
> diff --git a/Kconfiglib/examples/list_undefined.py
> b/Kconfiglib/examples/list_undefined.py
> index 0207975..f531777 100644
> --- a/Kconfiglib/examples/list_undefined.py
> +++ 

Re: [linux-yocto] [PATCH] nfsd4: Fix kernel crash when reading proc file reply_cache_stats

2019-08-06 Thread Bruce Ashfield
On Tue, Aug 6, 2019 at 6:49 AM  wrote:

> From: He Zhe 
>
> reply_cache_stats uses wrong parameter as seq file private structure and
> thus causes the following kernel crash when users read
> /proc/fs/nfsd/reply_cache_stats
>
> BUG: kernel NULL pointer dereference, address: 01f9
> PGD 0 P4D 0
> Oops:  [#3] SMP PTI
> CPU: 6 PID: 1502 Comm: cat Tainted: G  D   5.3.0-rc3+ #1
> Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge,
> BIOS BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
> RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
> Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88
> 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8
> 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
> RSP: 0018:aa520106fe08 EFLAGS: 00010246
> RAX: 00cfe1a77123 RBX:  RCX: 00291b46
> RDX: 00cf RSI: 0006 RDI: 00291b28
> RBP: aa520106fe20 R08: 0006 R09: 00cfe17e55dd
> R10: a424e47c R11: 030b R12: 0001
> R13: a424e5697000 R14: 0001 R15: a424e5697000
> FS:  7f805735f580() GS:a424f8f8()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01f9 CR3: 655ce005 CR4: 003606e0
> Call Trace:
>  seq_read+0x194/0x3e0
>  __vfs_read+0x1b/0x40
>  vfs_read+0x95/0x140
>  ksys_read+0x61/0xe0
>  __x64_sys_read+0x1a/0x20
>  do_syscall_64+0x4d/0x120
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f805728b861
> Code: fe ff ff 50 48 8d 3d 86 b4 09 00 e8 79 e0 01 00 66 0f 1f 84 00 00 00
> 00 00 48 8d 05 d9 19 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff
> ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
> RSP: 002b:7ffea1ce3c38 EFLAGS: 0246 ORIG_RAX: 
> RAX: ffda RBX: 0002 RCX: 7f805728b861
> RDX: 0002 RSI: 7f8057183000 RDI: 0003
> RBP: 7f8057183000 R08: 7f8057182010 R09: 
> R10: 0022 R11: 0246 R12: 559a60e8ff10
> R13: 0003 R14: 0002 R15: 0002
> Modules linked in:
> CR2: 01f9
> ---[ end trace 01613595153f0cba ]---
> RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
> Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88
> 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8
> 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
> RSP: 0018:aa52004b3e08 EFLAGS: 00010246
> RAX: 002bab45a7c6 RBX:  RCX: 00291b4c
> RDX: 002b RSI: 0004 RDI: 00291b28
> RBP: aa52004b3e20 R08: 0004 R09: 002bab1c8c7a
> R10: a424e550 R11: 02a9 R12: 0001
> R13: a424e4475000 R14: 0001 R15: a424e4475000
> FS:  7f805735f580() GS:a424f8f8()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01f9 CR3: 655ce005 CR4: 003606e0
> Killed
>
> Fixes: 3ba75830ce17 ("nfsd4: drc containerization")
> Signed-off-by: He Zhe 
> ---
> This is for all branches and has also been sent to mainline.
> Please consider if it's worth merging in linux-yocto-dev for this moment.
> Thanks.
>

Looks fine to me.

For patches like this, it is helpful if you also put a patch to the
upstream submission. So on my next updates to the kernel, I'll be able to
easily drop (or carry) it.

This is now merged.

Bruce



>
>  fs/nfsd/nfscache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c
> index 26ad75a..96352ab 100644
> --- a/fs/nfsd/nfscache.c
> +++ b/fs/nfsd/nfscache.c
> @@ -571,7 +571,7 @@ nfsd_cache_append(struct svc_rqst *rqstp, struct kvec
> *data)
>   */
>  static int nfsd_reply_cache_stats_show(struct seq_file *m, void *v)
>  {
> -   struct nfsd_net *nn = v;
> +   struct nfsd_net *nn = m->private;
>
> seq_printf(m, "max entries:   %u\n", nn->max_drc_entries);
> seq_printf(m, "num entries:   %u\n",
> --
> 2.7.4
>
>

-- 
- 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] [PATCH 1/1] ti-am335x: add the basic scc/cfg enablement

2019-08-06 Thread Bruce Ashfield
On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:

> Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black
> boards all with am335x soc
>
> Signed-off-by: Jun Miao 
> ---
>  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
>  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
>  bsp/ti-am335x/ti-am335x.scc  |   7 +
>  3 files changed, 257 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
>
> diff --git a/bsp/ti-am335x/ti-am335x-standard.scc
> b/bsp/ti-am335x/ti-am335x-standard.scc
> new file mode 100644
> index ..d357a729
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x-standard.scc
> @@ -0,0 +1,8 @@
> +define KMACHINE ti-am335x
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard/standard.scc
> +branch ti-am335x
> +
> +include ti-am335x.scc
> diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
> new file mode 100644
> index ..bb5b6653
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x.cfg
> @@ -0,0 +1,242 @@
> +#.
> +#WARNING
> +#
> +# This file is a kernel configuration fragment, and not a full kernel
> +# configuration file.  The final kernel configuration is made up of
> +# an assembly of processed fragments, each of which is designed to
> +# capture a specific part of the final configuration (e.g. platform
> +# configuration, feature configuration, and board specific hardware
> +# configuration).  For more information on kernel configuration, please
> +# consult the product documentation.
> +#
> +#.
> +
> +CONFIG_ARM=y
> +CONFIG_ARCH_OMAP=y
> +CONFIG_OMAP_DM_TIMER=y
> +CONFIG_SOC_AM33XX=y
> +CONFIG_ARCH_OMAP2PLUS=y
> +
> +
> +#
> +# At least one emulation must be selected
> +#
> +CONFIG_VFP=y
> +CONFIG_VFPv3=y
> +CONFIG_NEON=y
> +
> +#
> +# Power management options
> +#
> +
> +CONFIG_PM=y
> +CONFIG_REGMAP_IRQ=y
> +
> +#
> +# RAM/ROM/Flash chip drivers
> +#
> +CONFIG_OMAP_OCP2SCP=y
> +CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> +CONFIG_MTD_BLKDEVS=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_NAND_ECC=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_MTD_CFI=y
> +CONFIG_MTD_CFI_INTELEXT=y
> +
> +CONFIG_MTD_NAND=y
> +CONFIG_MTD_NAND_OMAP2=y
> +CONFIG_MTD_NAND_OMAP_BCH=y
> +CONFIG_MTD_NAND_OMAP_BCH_BUILD=y
> +
> +# Misc devices
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SENSORS_LIS3_I2C=y
> +CONFIG_BLK_DEV_SD=y
> +
> +CONFIG_ETHERNET=y
> +CONFIG_NET_VENDOR_TI=y
> +CONFIG_TI_DAVINCI_MDIO=y
> +CONFIG_TI_DAVINCI_CPDMA=y
> +CONFIG_TI_CPSW_PHY_SEL=y
> +CONFIG_TI_CPSW_ALE=y
> +CONFIG_TI_CPSW=y
> +CONFIG_TI_CPTS=y
> +CONFIG_PHYLIB=y
> +
> +CONFIG_SMSC_PHY=y
> +CONFIG_FIXED_PHY=y
> +
> +#
> +# Input Device Drivers
> +#
> +
> +CONFIG_INPUT=y
> +CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_INPUT_EVDEV=y
> +CONFIG_INPUT_KEYBOARD=y
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_MATRIX=y
> +CONFIG_INPUT_TOUCHSCREEN=y
> +CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_TPS65218_PWRBUTTON=m
> +CONFIG_SERIAL_EARLYCON=y
> +
> +#
> +# 8250 serial port support
> +#
> +
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_8250_OMAP=y
> +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
> +
> +CONFIG_SERIAL_CORE=y
> +CONFIG_SERIAL_CORE_CONSOLE=y
> +
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_OMAP=y
> +
> +# I2C support
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_OMAP=y
> +CONFIG_SENSORS_TSL2550=y
> +CONFIG_GPIO_TWL4030=y
> +CONFIG_PTP_1588_CLOCK=y
> +CONFIG_GPIO_PCF857X=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_SINGLE=y
> +
> +CONFIG_GPIOLIB=y
> +CONFIG_OF_GPIO=y
> +CONFIG_GPIOLIB_IRQCHIP=y
> +CONFIG_GPIO_SYSFS=y
> +
> +CONFIG_GPIO_OMAP=y
> +CONFIG_GPIO_PCA953X=m
> +CONFIG_GPIO_TPS65910=y
> +
> +CONFIG_WATCHDOG=y
> +CONFIG_WATCHDOG_CORE=y
> +CONFIG_OMAP_WATCHDOG=m
> +
> +CONFIG_MFD_SYSCON=y
> +CONFIG_MFD_TI_AM335X_TSCADC=y
> +CONFIG_MFD_OMAP_USB_HOST=y
> +CONFIG_MFD_TPS65217=y
> +CONFIG_MFD_TPS65218=y
> +CONFIG_MFD_TPS65910=y
> +CONFIG_TWL6040_CORE=y
> +
> +#
> +# LCD
> +#
> +CONFIG_DRM=y
> +CONFIG_DRM_OMAP=y
> +CONFIG_OMAP2_DSS_DPI=y
> +CONFIG_DRM_TILCDC=y
> +CONFIG_DRM_OMAP_PANEL_DPI=y
> +CONFIG_DRM_I2C_NXP_TDA998X=y
> +
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_LCD_CLASS_DEVICE=y
> +CONFIG_LCD_PLATFORM=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_GENERIC=y
> +CONFIG_PWM=y
> +CONFIG_BACKLIGHT_PWM=y
> +CONFIG_BACKLIGHT_GPIO=y
> +
> +
> +CONFIG_SOUND=m
> +CONFIG_SND=m
> +CONFIG_SND_SOC=m
> +CONFIG_SND_DAVINCI_SOC_MCASP=m
> +CONFIG_SND_SIMPLE_CARD=m
> +
> +
> +#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +#CONFIG_USB_MON=m
> +
> +#
> +# USB Host Controller Drivers
> +#
> +CONFIG_USB=y
> +CONFIG_USB_SUPPORT=y
> +
> +CONFIG_USB_EHCI_HCD=m
> +CONFIG_USB_EHCI_TT_NEWSCHED=y
> +CONFIG_USB_EHCI_HCD_OMAP=m
> 

Re: [linux-yocto] [kernel-cache master]: ti-am335x

2019-08-06 Thread Bruce Ashfield
On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:

> Hi Bruce,
>
> I am working ti boards(AM335x evm/sk/BBB) with am335x soc.
>
> 1.This patch add scc/cfg to yocto-kernel-cache master branch.
>

#1 shouldn't be a problem.

2.Could you help me build a new branch "ti-am335x" in
> linux-yocto-dev?
>
>
but #2 raises a question.  I try and limit the number of BSP specific
branches. What type of patches are you expecting to put on that branch, and
do you expect that they won't be safe for other boards ?

Bruce



> Thanks
>
>
>
> Jun Miao (1):
>   ti-am335x: add the basic scc/cfg enablement
>
>  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
>  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
>  bsp/ti-am335x/ti-am335x.scc  |   7 +
>  3 files changed, 257 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
>
> --
> 2.22.0
>
>

-- 
- 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] [kernel-cache] Question about profiling.scc

2019-08-06 Thread Bruce Ashfield
On Mon, Aug 5, 2019 at 11:44 PM Hongzhi, Song 
wrote:

> Hi Bruce,
>
> I see profiling.scc is included by kernel-cache/bsp/*, such as
> bsp/intel-x86 bsp/common-pc/ ... .
>
>
> My question is that is it necessary to open profiling.cfg defaultly?
>

We left profiling as a per-BSP decision, since production machine
configurations don't want the overhead that it brings.

Not all BSPs follow the split between developer and production, but see how
it is used in:

bsp/common-pc-64/common-pc-64-developer.scc:include
features/profiling/profiling.scc
bsp/common-pc-64/common-pc-64-preempt-rt.scc:include
features/profiling/profiling.scc

If it was enabled by default, it really should be in the developer ktype
and then BSPs could have the split between production and developer/debug
in their definitions .. with the developer ones getting profiling by
default.

Bruce



>
>
> --Hongzhi
>
>

-- 
- 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 falls back to v5.2

2019-08-01 Thread Bruce Ashfield
I've sorted out the issues that I had with the libc-headers and the 5.3
kernel .. and it wasn't a kernel issue. So I've put linux-yocto-dev back to
5.3-rc2 and have sent a patch to bump the recipe version in core. At this
point, I expect it should build and boot on all the arches.

Bruce

On Tue, Jul 30, 2019 at 10:12 AM Bruce Ashfield 
wrote:

> See the email on the poky/oe-core list. I was having some issues with 5.3
> and the new libc-headers. So I wasn't able to send the PV bump patch for
> linux-yocto. I've temporarily gone back to a building configuration, but I
> expect that I'll have it back to 5.3 in the next day or so.
>
> Bruce
>
> On Tue, Jul 30, 2019 at 2:58 AM He Zhe  wrote:
>
>> Hi Bruce,
>>
>> Why do we merge v5.2.3 to linux-yocto-dev? which is now almost the same
>> as linux-yocto.
>>
>> Regards,
>> Zhe
>>
>
>
> --
> - 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-dev falls back to v5.2

2019-07-30 Thread Bruce Ashfield
See the email on the poky/oe-core list. I was having some issues with 5.3
and the new libc-headers. So I wasn't able to send the PV bump patch for
linux-yocto. I've temporarily gone back to a building configuration, but I
expect that I'll have it back to 5.3 in the next day or so.

Bruce

On Tue, Jul 30, 2019 at 2:58 AM He Zhe  wrote:

> Hi Bruce,
>
> Why do we merge v5.2.3 to linux-yocto-dev? which is now almost the same as
> linux-yocto.
>
> Regards,
> Zhe
>


-- 
- 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] [PATCH] btrfs: Fix build error while LIBCRC32C is module

2019-07-25 Thread Bruce Ashfield
On Thu, Jul 25, 2019 at 9:43 PM He Zhe  wrote:

>
>
> On 7/25/19 9:04 PM, Bruce Ashfield wrote:
> > On Thu, Jul 25, 2019 at 9:03 AM Bruce Ashfield 
> wrote:
> >> On Thu, Jul 25, 2019 at 4:54 AM  wrote:
> >>> From: YueHaibing 
> >>>
> >>> If CONFIG_BTRFS_FS is y and CONFIG_LIBCRC32C is m,
> >>> building fails:
> >> I've already fixed this by changing the configuration in the
> kernel-cache. I'll
> >> pick this up in linux-yocto-dev once it makes a -rc release.
> > i.e. make sure you have this commit from the kernel-cache master:
>
> You mean you're going to merge it soon, right? I can't find it for the
> moment.
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/log/?h=master


It should be there, I pushed things on Wednesday. I'll double check to see
what has happened.

Bruce



>
>
> Zhe
>
> >
> > commit 578e0f7fef5a0772460e3c4bcae1200d35a70b21
> > Author: Bruce Ashfield 
> > Date:   Mon Jul 22 23:41:42 2019 -0400
> >
> > config: set CONFIG_LIBCRC32C=y
> >
> > Since commit d5178578bcd461cc79118c7a139882350fe505aa
> >
> > Author: Johannes Thumshirn 
> > Date:   Mon Jun 3 16:58:57 2019 +0200
> >
> > btrfs: directly call into crypto framework for checksumming
> >
> > We now have a dependency on crc32 in crypto, and it must be built
> > into the kernel to avoid:
> >
> > | x86_64-poky-linux-ld.bfd: fs/btrfs/super.o: in function
> > `btrfs_mount_root':
> > | super.c:(.text+0xb9b6): undefined reference to `crc32c_impl'
> > | x86_64-poky-linux-ld.bfd: fs/btrfs/super.o: in function
> > `init_btrfs_fs':
> > | super.c:(.init.text+0x362b): undefined reference to
> `crc32c_impl'
> > | x86_64-poky-linux-ld.bfd: fs/btrfs/extent-tree.o: in function
> > `hash_extent_data_ref':
> > | extent-tree.c:(.text+0xdfa): undefined reference to `crc32c'
> > | x86_64-poky-linux-ld.bfd: extent-tree.c:(.text+0xe13):
> undefined
> > reference to `crc32c'
> > | x86_64-poky-linux-ld.bfd: extent-tree.c:(.text+0xe27):
> undefined
> > reference to `crc32c'
> > | x86_64-poky-linux-ld.bfd: fs/btrfs/dir-item.o: in function
> > `btrfs_insert_xattr_item':
> > | dir-item.c:(.text+0x286): undefined reference to `crc32c'
> >
> > So we set our defaults to cover the btrfs build cases without error.
> >
> > Signed-off-by: Bruce Ashfield 
> >
> >
> >> Bruce
> >>
> >>>   fs/btrfs/super.o: In function `btrfs_mount_root':
> >>>   super.c:(.text+0xb7f9): undefined reference to `crc32c_impl'
> >>>   fs/btrfs/super.o: In function `init_btrfs_fs':
> >>>   super.c:(.init.text+0x3465): undefined reference to `crc32c_impl'
> >>>   fs/btrfs/extent-tree.o: In function `hash_extent_data_ref':
> >>>   extent-tree.c:(.text+0xe60): undefined reference to `crc32c'
> >>>   extent-tree.c:(.text+0xe78): undefined reference to `crc32c'
> >>>   extent-tree.c:(.text+0xe8b): undefined reference to `crc32c'
> >>>   fs/btrfs/dir-item.o: In function `btrfs_insert_xattr_item':
> >>>   dir-item.c:(.text+0x291): undefined reference to `crc32c'
> >>>   fs/btrfs/dir-item.o: In function `btrfs_insert_dir_item':
> >>>   dir-item.c:(.text+0x429): undefined reference to `crc32c'
> >>>
> >>> Select LIBCRC32C to fix it.
> >>>
> >>> Reported-by: Hulk Robot 
> >>> Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for
> checksumming")
> >>> Reviewed-by: Johannes Thumshirn 
> >>> Signed-off-by: YueHaibing 
> >>> Reviewed-by: David Sterba 
> >>> Signed-off-by: David Sterba 
> >>>
> >>> commit 314c4cd6d9e60b9412dcd1b1783a66532f91ea2d upstream
> >>>
> >>> Signed-off-by: He Zhe 
> >>> ---
> >>>  fs/btrfs/Kconfig | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> >>> index 212b4a8..38651fa 100644
> >>> --- a/fs/btrfs/Kconfig
> >>> +++ b/fs/btrfs/Kconfig
> >>> @@ -4,6 +4,7 @@ config BTRFS_FS
> >>> tristate "Btrfs filesystem support"
> >>> select CRYPTO
> >>> select CRYPTO_CRC32C
> >>> +   select LIBCRC32C
> >>> select ZLIB_INFLATE
> >>> select ZLIB_DEFLATE
> >>> select LZO_COMPRESS
> >>> --
> >>> 2.7.4
> >>>
> >>
> >> --
> >> - 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-dev standard/xlnx-soc][PATCH 0/1] correct the code position

2019-07-25 Thread Bruce Ashfield
It is now merged.

Bruce

On Wed, Jul 24, 2019 at 10:25 AM qwang2  wrote:
>
> Hi Bruce,
>
> Could this patch be merged to linux-yocto-dev now?
>
> Thanks,
>
> Quanyang
>
> On 2019/7/23 上午11:11, quanyang.w...@windriver.com wrote:
> > From: Quanyang Wang 
> >
> > Hi Bruce,
> >
> > Would you please help to merge this patch to
> > linux-yocto-dev standard/xlnx-soc
> > linux-yocto v5.2/standard/xlnx-soc
> >
> > Thanks,
> > Quanyang
> >
> > Quanyang Wang (1):
> >net: phy: dp83867: correct the code postion
> >
> >   drivers/net/phy/dp83867.c | 38 +++---
> >   1 file changed, 19 insertions(+), 19 deletions(-)
> >



-- 
- 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] [PATCH] btrfs: Fix build error while LIBCRC32C is module

2019-07-25 Thread Bruce Ashfield
On Thu, Jul 25, 2019 at 9:03 AM Bruce Ashfield  wrote:
>
> On Thu, Jul 25, 2019 at 4:54 AM  wrote:
> >
> > From: YueHaibing 
> >
> > If CONFIG_BTRFS_FS is y and CONFIG_LIBCRC32C is m,
> > building fails:
>
> I've already fixed this by changing the configuration in the kernel-cache. 
> I'll
> pick this up in linux-yocto-dev once it makes a -rc release.

i.e. make sure you have this commit from the kernel-cache master:

commit 578e0f7fef5a0772460e3c4bcae1200d35a70b21
Author: Bruce Ashfield 
Date:   Mon Jul 22 23:41:42 2019 -0400

config: set CONFIG_LIBCRC32C=y

Since commit d5178578bcd461cc79118c7a139882350fe505aa

Author: Johannes Thumshirn 
Date:   Mon Jun 3 16:58:57 2019 +0200

btrfs: directly call into crypto framework for checksumming

We now have a dependency on crc32 in crypto, and it must be built
into the kernel to avoid:

| x86_64-poky-linux-ld.bfd: fs/btrfs/super.o: in function
`btrfs_mount_root':
| super.c:(.text+0xb9b6): undefined reference to `crc32c_impl'
| x86_64-poky-linux-ld.bfd: fs/btrfs/super.o: in function
`init_btrfs_fs':
| super.c:(.init.text+0x362b): undefined reference to `crc32c_impl'
| x86_64-poky-linux-ld.bfd: fs/btrfs/extent-tree.o: in function
`hash_extent_data_ref':
| extent-tree.c:(.text+0xdfa): undefined reference to `crc32c'
| x86_64-poky-linux-ld.bfd: extent-tree.c:(.text+0xe13): undefined
reference to `crc32c'
| x86_64-poky-linux-ld.bfd: extent-tree.c:(.text+0xe27): undefined
reference to `crc32c'
| x86_64-poky-linux-ld.bfd: fs/btrfs/dir-item.o: in function
`btrfs_insert_xattr_item':
| dir-item.c:(.text+0x286): undefined reference to `crc32c'

So we set our defaults to cover the btrfs build cases without error.

Signed-off-by: Bruce Ashfield 


>
> Bruce
>
> >
> >   fs/btrfs/super.o: In function `btrfs_mount_root':
> >   super.c:(.text+0xb7f9): undefined reference to `crc32c_impl'
> >   fs/btrfs/super.o: In function `init_btrfs_fs':
> >   super.c:(.init.text+0x3465): undefined reference to `crc32c_impl'
> >   fs/btrfs/extent-tree.o: In function `hash_extent_data_ref':
> >   extent-tree.c:(.text+0xe60): undefined reference to `crc32c'
> >   extent-tree.c:(.text+0xe78): undefined reference to `crc32c'
> >   extent-tree.c:(.text+0xe8b): undefined reference to `crc32c'
> >   fs/btrfs/dir-item.o: In function `btrfs_insert_xattr_item':
> >   dir-item.c:(.text+0x291): undefined reference to `crc32c'
> >   fs/btrfs/dir-item.o: In function `btrfs_insert_dir_item':
> >   dir-item.c:(.text+0x429): undefined reference to `crc32c'
> >
> > Select LIBCRC32C to fix it.
> >
> > Reported-by: Hulk Robot 
> > Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for 
> > checksumming")
> > Reviewed-by: Johannes Thumshirn 
> > Signed-off-by: YueHaibing 
> > Reviewed-by: David Sterba 
> > Signed-off-by: David Sterba 
> >
> > commit 314c4cd6d9e60b9412dcd1b1783a66532f91ea2d upstream
> >
> > Signed-off-by: He Zhe 
> > ---
> >  fs/btrfs/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> > index 212b4a8..38651fa 100644
> > --- a/fs/btrfs/Kconfig
> > +++ b/fs/btrfs/Kconfig
> > @@ -4,6 +4,7 @@ config BTRFS_FS
> > tristate "Btrfs filesystem support"
> > select CRYPTO
> > select CRYPTO_CRC32C
> > +   select LIBCRC32C
> > select ZLIB_INFLATE
> > select ZLIB_DEFLATE
> > select LZO_COMPRESS
> > --
> > 2.7.4
> >
>
>
> --
> - 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] [PATCH] btrfs: Fix build error while LIBCRC32C is module

2019-07-25 Thread Bruce Ashfield
On Thu, Jul 25, 2019 at 4:54 AM  wrote:
>
> From: YueHaibing 
>
> If CONFIG_BTRFS_FS is y and CONFIG_LIBCRC32C is m,
> building fails:

I've already fixed this by changing the configuration in the kernel-cache. I'll
pick this up in linux-yocto-dev once it makes a -rc release.

Bruce

>
>   fs/btrfs/super.o: In function `btrfs_mount_root':
>   super.c:(.text+0xb7f9): undefined reference to `crc32c_impl'
>   fs/btrfs/super.o: In function `init_btrfs_fs':
>   super.c:(.init.text+0x3465): undefined reference to `crc32c_impl'
>   fs/btrfs/extent-tree.o: In function `hash_extent_data_ref':
>   extent-tree.c:(.text+0xe60): undefined reference to `crc32c'
>   extent-tree.c:(.text+0xe78): undefined reference to `crc32c'
>   extent-tree.c:(.text+0xe8b): undefined reference to `crc32c'
>   fs/btrfs/dir-item.o: In function `btrfs_insert_xattr_item':
>   dir-item.c:(.text+0x291): undefined reference to `crc32c'
>   fs/btrfs/dir-item.o: In function `btrfs_insert_dir_item':
>   dir-item.c:(.text+0x429): undefined reference to `crc32c'
>
> Select LIBCRC32C to fix it.
>
> Reported-by: Hulk Robot 
> Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for 
> checksumming")
> Reviewed-by: Johannes Thumshirn 
> Signed-off-by: YueHaibing 
> Reviewed-by: David Sterba 
> Signed-off-by: David Sterba 
>
> commit 314c4cd6d9e60b9412dcd1b1783a66532f91ea2d upstream
>
> Signed-off-by: He Zhe 
> ---
>  fs/btrfs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 212b4a8..38651fa 100644
> --- a/fs/btrfs/Kconfig
> +++ b/fs/btrfs/Kconfig
> @@ -4,6 +4,7 @@ config BTRFS_FS
> tristate "Btrfs filesystem support"
> select CRYPTO
> select CRYPTO_CRC32C
> +   select LIBCRC32C
> select ZLIB_INFLATE
> select ZLIB_DEFLATE
> select LZO_COMPRESS
> --
> 2.7.4
>


-- 
- 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 standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread Bruce Ashfield
On Tue, Jul 23, 2019 at 9:20 AM Yunguo Wei  wrote:
>
>
>
> 在 2019/7/23 21:03, qwang2 写道:
> >
> > On 7/23/19 8:41 PM, Bruce Ashfield wrote:
> >> On Tue, Jul 23, 2019 at 1:29 AM qwang2 
> >> wrote:
> >>>
> >>> On 7/22/19 11:34 PM, Bruce Ashfield wrote:
> >>>> On Mon, Jul 22, 2019 at 1:24 AM  wrote:
> >>>>> From: Quanyang Wang 
> >>>>>
> >>>>> Hi Bruce,
> >>>>>
> >>>>> Would you please help merge these 2 patches to linux-yocto-dev
> >>>>> standard/xlnx-soc branch?
> >>>> I've merged the patches.
> >>>>
> >>>> Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
> >>>> created a set of v5.2 branches in the main linux-yocto repository, and
> >>>> I have merged the xlnx-soc work there.
> >>>>
> >>>> So if you can try switching to:
> >>>>
> >>>> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc
> >>>>
> >>>>
> >>>> The content is the same as the linux-yocto-dev branch.
> >>>>
> >>>> I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
> >>>> quite ready yet. Contact me if you have trouble building that branch
> >>>> without the recipes and I  can send you the in progress ones.
> >>>>
> >>>> Also, if you do a port to 5.3, let me know and we can re-establish the
> >>>> branch in linux-yocto-dev.
> >>> Hi Bruce,
> >>>
> >>> I will do a port to 5.3.  But before I finish porting, I hope we can
> >>> retain the branch standard/xlnx-soc
> >> I have 5.3-rc1 building and booting with the base set of features now.
> >>
> >> Is there a reason why the branch I created in linux-yocto/5.2 won't
> >> work while you are doing the port ? I'd like to push the 5.3 kernel
> >> changes in the next day or so, and they will clobber that branch.
> >
> > Hi Bruce,
> >
> > For me, I plan to begin porting to 5.3 after I fix bugs and enable the
> > remaining
> >
> > features. So I hope to maintain this branch in linux-yocto-dev but not
> > only linux-yocto.
> >
> > But if retaining this branch bring inconvience, you can delete it.
> >
> > I will switch to linux-yocto/5.2 to do the fixing bug.
> Bruce,
>
> Another reason is we have some test always tracking on
> linux-yocto-dev/standard/xlnx-soc, rather than
> linux-yocto/v5.2/standard/xlnx-soc.
> There might be a gap between 5.3 changes is pushed and port for v5.3 is
> done. So the xlnx SDK full features can't be tested during that time.
>
> But anyway, please go ahead with your change if that is a standard
> procedure, we will tune our internal plan accordingly. And we will do

Outside of the repo being different, and the branch having a v5.2/
prefix, the content is identical between linux-yocto-dev and the
linux-yocto tree. So hopefully, outside of updating which recipe you
use to build the BSP, that's the only difference. As I mentioned, I
can provide you with the linux-yocto_5.2 recipes before I complete all
my system level testing on them, if not having the recipes is a
problem for using that branch.

I always move linux-yocto-dev forward as soon as I can, and those
jumps are rebases/non-fastforward.

That being said, I can keep the old branch in -dev around on 5.2
content, while the rest of the tree is v5.3. There just won't be the
branch prefixes to keep things straight. Since you are likely the only
developers using that -soc branch, it shouldn't be a problem.

Let me know what is easiest for you, since I do want to support your
development efforts.

Bruce

> the v5.3 port ASAP.
>
> Regards,
> Yunguo
>
> >
> > Thanks,
> >
> > Quanyang
> >
> >>
> >> Bruce
> >>
> >>> and don't delete it.
> >>>
> >>> Thanks,
> >>>
> >>> Quanyang
> >>>
> >>>> Bruce
> >>>>
> >>>>> Limeng (1):
> >>>>> driver: pcie: reset pcie device with MIO31 on xilinx-zcu102
> >>>>> platform
> >>>>>
> >>>>> Quanyang Wang (1):
> >>>>> drm: xlnx: zynqmp_dp: initialize delayed work before enable
> >>>>> interrupts
> >>>>>
> >>>>>.../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
> >>>>>drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
> >>>>>drivers/pci/controller/pcie-xilinx-nwl.c  | 35
> >>>>> +++
> >>>>>3 files changed, 38 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> --
> >>>>> 2.17.1
> >>>>>
> >>
> >>
>


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


Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread Bruce Ashfield
On Tue, Jul 23, 2019 at 1:29 AM qwang2  wrote:
>
>
> On 7/22/19 11:34 PM, Bruce Ashfield wrote:
> > On Mon, Jul 22, 2019 at 1:24 AM  wrote:
> >> From: Quanyang Wang 
> >>
> >> Hi Bruce,
> >>
> >> Would you please help merge these 2 patches to linux-yocto-dev 
> >> standard/xlnx-soc branch?
> > I've merged the patches.
> >
> > Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
> > created a set of v5.2 branches in the main linux-yocto repository, and
> > I have merged the xlnx-soc work there.
> >
> > So if you can try switching to:
> >
> > https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc
> >
> > The content is the same as the linux-yocto-dev branch.
> >
> > I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
> > quite ready yet. Contact me if you have trouble building that branch
> > without the recipes and I  can send you the in progress ones.
> >
> > Also, if you do a port to 5.3, let me know and we can re-establish the
> > branch in linux-yocto-dev.
>
> Hi Bruce,
>
> I will do a port to 5.3.  But before I finish porting, I hope we can
> retain the branch standard/xlnx-soc

I have 5.3-rc1 building and booting with the base set of features now.

Is there a reason why the branch I created in linux-yocto/5.2 won't
work while you are doing the port ? I'd like to push the 5.3 kernel
changes in the next day or so, and they will clobber that branch.

Bruce

>
> and don't delete it.
>
> Thanks,
>
> Quanyang
>
> >
> > Bruce
> >
> >>
> >> Limeng (1):
> >>driver: pcie: reset pcie device with MIO31 on xilinx-zcu102 platform
> >>
> >> Quanyang Wang (1):
> >>drm: xlnx: zynqmp_dp: initialize delayed work before enable interrupts
> >>
> >>   .../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
> >>   drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
> >>   drivers/pci/controller/pcie-xilinx-nwl.c  | 35 +++
> >>   3 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> --
> >> 2.17.1
> >>
> >



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


Re: [linux-yocto] [kernel-cache master][PATCH 0/1] xilinx-zynqmp: update xilinx-zynqmp to support SDK xlnx_rebase_v4.19

2019-07-22 Thread Bruce Ashfield
merged to master and yocto-5.2 branches.

Bruce

On Mon, Jul 22, 2019 at 7:35 AM  wrote:
>
> From: Quanyang Wang 
>
> Hi Bruce,
>
> Would you please help to merge this patch to yocto-kernel-cache master?
>
> --LOG
> Booting Linux on physical CPU 0x00 [0x410fd034]
> Linux version 5.2.0-yoctodev-standard (wrsadmin@pek-qwang2-d1) (gcc version 
> 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb9
> Machine model: ZynqMP ZCU102 Rev1.0
> earlycon: cdns0 at MMIO 0xff00 (options '')
> printk: bootconsole [cdns0] enabled
> efi: Getting EFI parameters from FDT:
> efi: UEFI not found.
> crashkernel reserved: 0x5fe0 - 0x7fe0 (512 MB)
> cma: Reserved 256 MiB at 0x4fc0
> psci: probing for conduit method from DT.
> psci: PSCIv1.1 detected in firmware.
> psci: Using standard PSCI v0.2 function IDs
> psci: MIGRATE_INFO_TYPE not supported.
> psci: SMC Calling Convention v1.1
> percpu: Embedded 30 pages/cpu s85208 r8192 d29480 u122880
> Detected VIPT I-cache on CPU0
> CPU features: detected: ARM erratum 845719
> Speculative Store Bypass Disable mitigation not required
> Built 1 zonelists, mobility grouping on.  Total pages: 1031940
> Kernel command line: console=ttyPS0,115200n8 earlycon=cdns,0xFF00 
> clk_ignore_unused root=/dev/nfs rw rootwait 
> nfsroot=128.224.162.137:/home/wrsadmM
> Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> software IO TLB: mapped [mem 0x4bc0-0x4fc0] (64MB)
> Memory: 3240236K/4193280K available (12348K kernel code, 1292K rwdata, 3260K 
> rodata, 2112K init, 774K bss, 690900K reserved, 262144K cma-reserved)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> ftrace: allocating 40981 entries in 161 pages
> rcu: Preemptible hierarchical RCU implementation.
> rcu:RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
> Tasks RCU enabled.
> rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> GIC: Adjusting CPU interface base to 0xf902f000
> GIC: Using split EOI/Deactivate mode
> random: get_random_bytes called from start_kernel+0x32c/0x4dc with crng_init=0
> arch_timer: cp15 timer(s) running at 99.99MHz (phys).
> clocksource: arch_sys_counter: mask: 0xff max_cycles: 
> 0x170f8de2d3, max_idle_ns: 440795206112 ns
> sched_clock: 56 bits at 99MHz, resolution 10ns, wraps every 4398046511101ns
> Console: colour dummy device 80x25
> Calibrating delay loop (skipped), value calculated using timer frequency.. 
> 199.98 BogoMIPS (lpj=399960)
> pid_max: default: 32768 minimum: 301
> LSM: Security Framework initializing
> Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
> Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
> ASID allocator initialised with 32768 entries
> rcu: Hierarchical SRCU implementation.
> EFI services will not be available.
> smp: Bringing up secondary CPUs ...
> Detected VIPT I-cache on CPU1
> CPU1: Booted secondary processor 0x01 [0x410fd034]
> Detected VIPT I-cache on CPU2
> CPU2: Booted secondary processor 0x02 [0x410fd034]
> Detected VIPT I-cache on CPU3
> CPU3: Booted secondary processor 0x03 [0x410fd034]
> smp: Brought up 1 node, 4 CPUs
> SMP: Total of 4 processors activated.
> CPU features: detected: 32-bit EL0 Support
> CPU features: detected: CRC32 instructions
> CPU: All CPU(s) started at EL2
> alternatives: patching kernel code
> devtmpfs: initialized
> clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
> 764504178510 ns
> futex hash table entries: 1024 (order: 4, 65536 bytes)
> xor: measuring software checksum speed
>8regs :  2292.000 MB/sec
>32regs:  2811.000 MB/sec
>arm64_neon:  2130.000 MB/sec
> xor: using function: 32regs (2811.000 MB/sec)
> pinctrl core: initialized pinctrl subsystem
> DMI not present or invalid.
> NET: Registered protocol family 16
> cpuidle: using governor ladder
> hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> DMA: preallocated 256 KiB pool for atomic allocations
> HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
> HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
> HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
> HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
> raid6: neonx8   gen()  1649 MB/s
> raid6: neonx8   xor()  1511 MB/s
> raid6: neonx4   gen()  1500 MB/s
> raid6: neonx4   xor()  1434 MB/s
> raid6: neonx2   gen()  1159 MB/s
> raid6: neonx2   xor()  1204 MB/s
> raid6: neonx1   gen()   728 MB/s
> raid6: neonx1   xor()   857 MB/s
> raid6: int64x8  gen()   985 MB/s
> raid6: int64x8  xor()   753 MB/s
> raid6: int64x4  gen()  1043 MB/s
> raid6: int64x4  xor()   770 MB/s
> raid6: int64x2  gen()   684 MB/s
> raid6: 

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-22 Thread Bruce Ashfield
On Mon, Jul 22, 2019 at 1:24 AM  wrote:
>
> From: Quanyang Wang 
>
> Hi Bruce,
>
> Would you please help merge these 2 patches to linux-yocto-dev 
> standard/xlnx-soc branch?

I've merged the patches.

Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
created a set of v5.2 branches in the main linux-yocto repository, and
I have merged the xlnx-soc work there.

So if you can try switching to:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc

The content is the same as the linux-yocto-dev branch.

I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
quite ready yet. Contact me if you have trouble building that branch
without the recipes and I  can send you the in progress ones.

Also, if you do a port to 5.3, let me know and we can re-establish the
branch in linux-yocto-dev.

Bruce

>
>
> Limeng (1):
>   driver: pcie: reset pcie device with MIO31 on xilinx-zcu102 platform
>
> Quanyang Wang (1):
>   drm: xlnx: zynqmp_dp: initialize delayed work before enable interrupts
>
>  .../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
>  drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
>  drivers/pci/controller/pcie-xilinx-nwl.c  | 35 +++
>  3 files changed, 38 insertions(+), 1 deletion(-)
>
> --
> 2.17.1
>


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


Re: [linux-yocto] [PATCH 0/3] Enable more kernel configs

2019-07-19 Thread Bruce Ashfield
On Tue, Jul 16, 2019 at 3:01 AM Anuj Mittal  wrote:
>
> Hi Bruce,
>
> Could you merge in 4.19, 5.0 and master if these look okay? Thank you.
>

They look fine to me, and are now on those three branches.

Bruce

> Anuj Mittal (3):
>   security.cfg: unset HARDENED_USERCOPY_FALLBACK
>   features: add support for RANDOM_TRUST_CPU
>   intel-common-drivers: enable RANDOM_TRUST_CPU for Intel BSPs
>
>  bsp/intel-common/intel-common-drivers.scc | 1 +
>  features/random/random.cfg| 1 +
>  features/random/random.scc| 4 
>  features/security/security.cfg| 1 +
>  4 files changed, 7 insertions(+)
>  create mode 100644 features/random/random.cfg
>  create mode 100644 features/random/random.scc
>
> --
> 2.20.1
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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] [PATCH 0000/1228] xilinx-zynqmp: add sdk patches

2019-07-19 Thread Bruce Ashfield
On Thu, Jul 18, 2019 at 9:36 AM Bruce Ashfield  wrote:
>
> On Thu, Jul 18, 2019 at 8:30 AM Michal Simek  wrote:
> >
> > On 16. 07. 19 21:44, Bruce Ashfield wrote:
> > > On Mon, Jul 15, 2019 at 2:19 AM Wei, Yunguo  
> > > wrote:
> > >>
> > >>
> > >> On 7/8/2019 9:14 PM, Bruce Ashfield wrote:
> > >>> On Thu, Jul 4, 2019 at 5:59 AM  wrote:
> > >>>> From: Quanyang Wang 
> > >>>>
> > >>>> Hi Bruce,
> > >>>>
> > >>>> I am working on BSP xilinx-zynqmp.
> > >>>>
> > >>>> Could you please help to merge these patches to:
> > >>>>
> > >>>> linux-yocto-dev standard/xilinx-zynqmp
> > >>>>
> > >>>> These patches are picked from:
> > >>>>
> > >>>> https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v4.19
> > >>> We already have a 4.19 branch based on Michal's tree, which was
> > >>> curated and selected for the soc support.
> > >>> Did you you look at the one in linux-yocto 4.19 ? Since it is a
> > >>> specifically selected set of patches and might be a better starting
> > >>> point.
> > >>>
> > >>> Before I introduce a 5.x branch, I'd want to hear his opinion on the
> > >>> branch and the selections that you made, versus what he would have
> > >>> done.
> > >>
> > >> Hi Bruce, Michal,
> > >>
> > >> Any further comments on it?
> > >>
> > >
> > > I'll try getting comments from Michal via another method, he may be on
> > > vacation. I'd still like to hear from him.
> > >
> > > But generally speaking, since the base is the same, I have no issues
> > > with the branch. I'll likely call the branch the same as we have in
> > > 4.19, but otherwise, will leave things as they are.
> >
> > Xilinx is going to stay at 4.19 for the whole 2019 and new patches are
> > coming to our master branch and then they will be propagated to rebased
> > branch. After the initial patchset adding new patches is easy.
> > It means at some point in future I will sync current master with rebase
> > branch and ask you for adding these patches to yocto tree too.
> > If there is any immediate need to add/fix something there we can do it
> > earlier.
> > Please let me know what you think. I should be back in August.
>
> No issues on my end, that strategy works for me.
>
> I'll create the -dev (5.2) branches and stage the patches there.
> Incremental updates are fine, and we can handle them as they come.

See the standard/xlnx-soc branch in the -dev kernel for the results of
the merge.

Bruce

>
> Cheers,
>
> Bruce
>
> >
> > Thanks,
> > Michal
> >
>
>
> --
> - 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] [PATCH 0000/1228] xilinx-zynqmp: add sdk patches

2019-07-18 Thread Bruce Ashfield
On Thu, Jul 18, 2019 at 8:30 AM Michal Simek  wrote:
>
> On 16. 07. 19 21:44, Bruce Ashfield wrote:
> > On Mon, Jul 15, 2019 at 2:19 AM Wei, Yunguo  
> > wrote:
> >>
> >>
> >> On 7/8/2019 9:14 PM, Bruce Ashfield wrote:
> >>> On Thu, Jul 4, 2019 at 5:59 AM  wrote:
> >>>> From: Quanyang Wang 
> >>>>
> >>>> Hi Bruce,
> >>>>
> >>>> I am working on BSP xilinx-zynqmp.
> >>>>
> >>>> Could you please help to merge these patches to:
> >>>>
> >>>> linux-yocto-dev standard/xilinx-zynqmp
> >>>>
> >>>> These patches are picked from:
> >>>>
> >>>> https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v4.19
> >>> We already have a 4.19 branch based on Michal's tree, which was
> >>> curated and selected for the soc support.
> >>> Did you you look at the one in linux-yocto 4.19 ? Since it is a
> >>> specifically selected set of patches and might be a better starting
> >>> point.
> >>>
> >>> Before I introduce a 5.x branch, I'd want to hear his opinion on the
> >>> branch and the selections that you made, versus what he would have
> >>> done.
> >>
> >> Hi Bruce, Michal,
> >>
> >> Any further comments on it?
> >>
> >
> > I'll try getting comments from Michal via another method, he may be on
> > vacation. I'd still like to hear from him.
> >
> > But generally speaking, since the base is the same, I have no issues
> > with the branch. I'll likely call the branch the same as we have in
> > 4.19, but otherwise, will leave things as they are.
>
> Xilinx is going to stay at 4.19 for the whole 2019 and new patches are
> coming to our master branch and then they will be propagated to rebased
> branch. After the initial patchset adding new patches is easy.
> It means at some point in future I will sync current master with rebase
> branch and ask you for adding these patches to yocto tree too.
> If there is any immediate need to add/fix something there we can do it
> earlier.
> Please let me know what you think. I should be back in August.

No issues on my end, that strategy works for me.

I'll create the -dev (5.2) branches and stage the patches there.
Incremental updates are fine, and we can handle them as they come.

Cheers,

Bruce

>
> Thanks,
> Michal
>


-- 
- 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] [kernel-cache][master and yocto-5.0][PATCH] features/intel-persistent-memory: add pmem support for intel-x86-64

2019-07-18 Thread Bruce Ashfield
On Wed, Jul 17, 2019 at 7:36 PM Liu, Yongxin  wrote:
>
> Hi Bruce,
>
> Any comment about my issue?

argh. Sorry about that. gmail threaded your follow up in a way that I
didn't see it.

It appears that I either replied to the wrong email, or I rebased the
configuration change away when I was doing some cleanup before the
push.

Sorry for the delay, but it is now really merged.

Bruce

>
> Thanks,
> Yongxin
>
> > -Original Message-
> > From: Liu, Yongxin
> > Sent: Thursday, July 11, 2019 18:49
> > To: 'Bruce Ashfield'
> > Cc: Development list for the linux-yocto repositories
> > Subject: RE: [linux-yocto][kernel-cache][master and yocto-5.0][PATCH]
> > features/intel-persistent-memory: add pmem support for intel-x86-64
> >
> > Hi Bruce,
> >
> > I still cannot see the commit.
> > Is there any delay before it is visible in repo?
> >
> >
> > Thanks,
> > Yongxin
> >
> >
> > > -Original Message-
> > > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
> > > Sent: Wednesday, July 10, 2019 03:26
> > > To: Liu, Yongxin
> > > Cc: Development list for the linux-yocto repositories
> > > Subject: Re: [linux-yocto][kernel-cache][master and yocto-5.0][PATCH]
> > > features/intel-persistent-memory: add pmem support for intel-x86-64
> > >
> > > merged
> > >
> > > Bruce
> > >
> > > On Tue, Jul 9, 2019 at 3:51 AM Yongxin Liu 
> > > wrote:
> > > >
> > > > Because CONFIG_DEV_DAX* are not supported in preempt-rt kernel, use
> > > > two scc files for Non-RT kerel and RT kernel separately.
> > > >
> > > > Signed-off-by: Yongxin Liu 
> > > > ---
> > > >  .../intel-persistent-memory/intel-x86-64-dax.cfg   |  7 +
> > > >  .../intel-x86-64-pmem-preempt-rt.scc   |  3 +++
> > > >  .../intel-persistent-memory/intel-x86-64-pmem.cfg  | 31
> > > ++
> > > >  .../intel-persistent-memory/intel-x86-64-pmem.scc  |  4 +++
> > > >  4 files changed, 45 insertions(+)
> > > >  create mode 100644 features/intel-persistent-memory/intel-x86-64-
> > > dax.cfg
> > > >  create mode 100644 features/intel-persistent-memory/intel-x86-64-
> > pmem-
> > > preempt-rt.scc
> > > >  create mode 100644 features/intel-persistent-memory/intel-x86-64-
> > > pmem.cfg
> > > >  create mode 100644 features/intel-persistent-memory/intel-x86-64-
> > > pmem.scc
> > > >
> > > > diff --git a/features/intel-persistent-memory/intel-x86-64-dax.cfg
> > > b/features/intel-persistent-memory/intel-x86-64-dax.cfg
> > > > new file mode 100644
> > > > index ..6b4d2ff6
> > > > --- /dev/null
> > > > +++ b/features/intel-persistent-memory/intel-x86-64-dax.cfg
> > > > @@ -0,0 +1,7 @@
> > > > +#
> > > > +# Device Drivers
> > > > +#
> > > > +CONFIG_DEV_DAX=m
> > > > +CONFIG_DEV_DAX_PMEM=m
> > > > +CONFIG_DEV_DAX_KMEM=m
> > > > +CONFIG_DEV_DAX_PMEM_COMPAT=m
> > > > diff --git a/features/intel-persistent-memory/intel-x86-64-pmem-
> > > preempt-rt.scc b/features/intel-persistent-memory/intel-x86-64-pmem-
> > > preempt-rt.scc
> > > > new file mode 100644
> > > > index ..e42341f7
> > > > --- /dev/null
> > > > +++ b/features/intel-persistent-memory/intel-x86-64-pmem-preempt-
> > rt.scc
> > > > @@ -0,0 +1,3 @@
> > > > +define KFEATURE_DESCRIPTION "Enable persistent memory support for
> > > intel-x86-64 preempt-rt"
> > > > +
> > > > +kconf hardware intel-x86-64-pmem.cfg
> > > > diff --git a/features/intel-persistent-memory/intel-x86-64-pmem.cfg
> > > b/features/intel-persistent-memory/intel-x86-64-pmem.cfg
> > > > new file mode 100644
> > > > index ..914e38a6
> > > > --- /dev/null
> > > > +++ b/features/intel-persistent-memory/intel-x86-64-pmem.cfg
> > > > @@ -0,0 +1,31 @@
> > > > +#
> > > > +# Processor type and features
> > > > +#
> > > > +CONFIG_X86_PMEM_LEGACY=m
> > > > +
> > > > +#
> > > > +# Memory Management options
> > > > +#
> > > > +CONFIG_MEMORY_HOTPLUG=y
> > > > +CONFIG_MEMORY_HOTREMOVE=y
> > > > +CONFIG_ZONE_DEVICE=y
> > > > +
> > > > +#
> > > > +# Device Drivers

Re: [linux-yocto] [kernel-cache][master and yocto-5.0][PATCH] features/intel-persistent-memory: add pmem support for intel-x86-64

2019-07-09 Thread Bruce Ashfield
merged

Bruce

On Tue, Jul 9, 2019 at 3:51 AM Yongxin Liu  wrote:
>
> Because CONFIG_DEV_DAX* are not supported in preempt-rt kernel, use
> two scc files for Non-RT kerel and RT kernel separately.
>
> Signed-off-by: Yongxin Liu 
> ---
>  .../intel-persistent-memory/intel-x86-64-dax.cfg   |  7 +
>  .../intel-x86-64-pmem-preempt-rt.scc   |  3 +++
>  .../intel-persistent-memory/intel-x86-64-pmem.cfg  | 31 
> ++
>  .../intel-persistent-memory/intel-x86-64-pmem.scc  |  4 +++
>  4 files changed, 45 insertions(+)
>  create mode 100644 features/intel-persistent-memory/intel-x86-64-dax.cfg
>  create mode 100644 
> features/intel-persistent-memory/intel-x86-64-pmem-preempt-rt.scc
>  create mode 100644 features/intel-persistent-memory/intel-x86-64-pmem.cfg
>  create mode 100644 features/intel-persistent-memory/intel-x86-64-pmem.scc
>
> diff --git a/features/intel-persistent-memory/intel-x86-64-dax.cfg 
> b/features/intel-persistent-memory/intel-x86-64-dax.cfg
> new file mode 100644
> index ..6b4d2ff6
> --- /dev/null
> +++ b/features/intel-persistent-memory/intel-x86-64-dax.cfg
> @@ -0,0 +1,7 @@
> +#
> +# Device Drivers
> +#
> +CONFIG_DEV_DAX=m
> +CONFIG_DEV_DAX_PMEM=m
> +CONFIG_DEV_DAX_KMEM=m
> +CONFIG_DEV_DAX_PMEM_COMPAT=m
> diff --git 
> a/features/intel-persistent-memory/intel-x86-64-pmem-preempt-rt.scc 
> b/features/intel-persistent-memory/intel-x86-64-pmem-preempt-rt.scc
> new file mode 100644
> index ..e42341f7
> --- /dev/null
> +++ b/features/intel-persistent-memory/intel-x86-64-pmem-preempt-rt.scc
> @@ -0,0 +1,3 @@
> +define KFEATURE_DESCRIPTION "Enable persistent memory support for 
> intel-x86-64 preempt-rt"
> +
> +kconf hardware intel-x86-64-pmem.cfg
> diff --git a/features/intel-persistent-memory/intel-x86-64-pmem.cfg 
> b/features/intel-persistent-memory/intel-x86-64-pmem.cfg
> new file mode 100644
> index ..914e38a6
> --- /dev/null
> +++ b/features/intel-persistent-memory/intel-x86-64-pmem.cfg
> @@ -0,0 +1,31 @@
> +#
> +# Processor type and features
> +#
> +CONFIG_X86_PMEM_LEGACY=m
> +
> +#
> +# Memory Management options
> +#
> +CONFIG_MEMORY_HOTPLUG=y
> +CONFIG_MEMORY_HOTREMOVE=y
> +CONFIG_ZONE_DEVICE=y
> +
> +#
> +# Device Drivers
> +#
> +CONFIG_LIBNVDIMM=m
> +CONFIG_BLK_DEV_PMEM=m
> +CONFIG_ND_BLK=m
> +CONFIG_BTT=y
> +CONFIG_NVDIMM_PFN=y
> +CONFIG_NVDIMM_DAX=y
> +
> +#
> +# Power management and ACPI options
> +#
> +CONFIG_ACPI_NFIT=m
> +
> +#
> +# File systems
> +#
> +CONFIG_FS_DAX=y
> diff --git a/features/intel-persistent-memory/intel-x86-64-pmem.scc 
> b/features/intel-persistent-memory/intel-x86-64-pmem.scc
> new file mode 100644
> index ..1f67c6a9
> --- /dev/null
> +++ b/features/intel-persistent-memory/intel-x86-64-pmem.scc
> @@ -0,0 +1,4 @@
> +define KFEATURE_DESCRIPTION "Enable persistent memory support for 
> intel-x86-64"
> +
> +kconf hardware intel-x86-64-pmem.cfg
> +kconf hardware intel-x86-64-dax.cfg
> --
> 2.14.4
>


-- 
- 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] [kernel-cache master/yocto-5.0][PATCH] intel-x86: add MGA G200 series VGA support

2019-07-09 Thread Bruce Ashfield
merged

Bruce

On Mon, Jul 8, 2019 at 4:24 AM Liwei Song  wrote:
>
> Enable CONFIG_DRM_MGAG200=m to support Matrox Electronics MGA G200
> and include it in intel-x86 bsp.
>
> Signed-off-by: Liwei Song 
> ---
>  bsp/intel-x86/intel-x86.scc  | 1 +
>  features/mgag200/mgag200.cfg | 1 +
>  features/mgag200/mgag200.scc | 4 
>  3 files changed, 6 insertions(+)
>  create mode 100644 features/mgag200/mgag200.cfg
>  create mode 100644 features/mgag200/mgag200.scc
>
> diff --git a/bsp/intel-x86/intel-x86.scc b/bsp/intel-x86/intel-x86.scc
> index aee6d5e93db3..a93319d483a5 100644
> --- a/bsp/intel-x86/intel-x86.scc
> +++ b/bsp/intel-x86/intel-x86.scc
> @@ -39,6 +39,7 @@ include features/tpm/tpm.scc
>  include features/mfd/mfd-intel-lpss.scc
>  include features/mmc/mmc-realtek.scc
>  include features/intel-pinctrl/intel-pinctrl.scc
> +include features/mgag200/mgag200.scc
>
>  kconf hardware intel-x86.cfg
>  kconf hardware intel-x86-mga.cfg
> diff --git a/features/mgag200/mgag200.cfg b/features/mgag200/mgag200.cfg
> new file mode 100644
> index ..48b6c6106fe0
> --- /dev/null
> +++ b/features/mgag200/mgag200.cfg
> @@ -0,0 +1 @@
> +CONFIG_DRM_MGAG200=m
> diff --git a/features/mgag200/mgag200.scc b/features/mgag200/mgag200.scc
> new file mode 100644
> index ..6bb0e79608e9
> --- /dev/null
> +++ b/features/mgag200/mgag200.scc
> @@ -0,0 +1,4 @@
> +define KFEATURE_DESCRIPTION "Matrox Electronics Systems Ltd. MGA G200e 
> support"
> +define KFEATURE_COMPATIBILITY board
> +
> +kconf hardware mgag200.cfg
> --
> 2.7.4
>


-- 
- 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] [kernel-cache][PATCH] feature/net: Create a config variant of net.scc to for features

2019-07-05 Thread Bruce Ashfield
On Wed, Jul 3, 2019 at 10:54 AM  wrote:
>
> From: He Zhe 
>
> Since b5776165c9d3 ("netfilter: Fix remainder of pseudo-header protocol 0"),
> net.scc includes a patch which would be reapplied when included by other
> features.
>
> This patches create a config variant net-enable.scc for features and leaves
> net.scc to BSPs as is.

merged to kernel-cache master, let me know if other branches need this as well.

Bruce

>
> Signed-off-by: He Zhe 
> ---
>  features/net/net-all.scc| 2 +-
>  features/net/net-enable.scc | 1 +
>  features/net/team/team.scc  | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>  create mode 100644 features/net/net-enable.scc
>
> diff --git a/features/net/net-all.scc b/features/net/net-all.scc
> index ea42023..5cdde4a 100644
> --- a/features/net/net-all.scc
> +++ b/features/net/net-all.scc
> @@ -1,3 +1,3 @@
>
> -include features/net/net.scc
> +include features/net/net-enable.scc
>  include features/net/stmicro/stmicro.scc
> diff --git a/features/net/net-enable.scc b/features/net/net-enable.scc
> new file mode 100644
> index 000..79e0dce
> --- /dev/null
> +++ b/features/net/net-enable.scc
> @@ -0,0 +1 @@
> +kconf hardware net.cfg
> diff --git a/features/net/team/team.scc b/features/net/team/team.scc
> index ee3a641..cf5bb9d 100644
> --- a/features/net/team/team.scc
> +++ b/features/net/team/team.scc
> @@ -1,3 +1,3 @@
> -include features/net/net.scc
> +include features/net/net-enable.scc
>
>  kconf non-hardware team.cfg
> --
> 2.7.4
>


-- 
- 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] [kernel-cache][yocto-4.19][PATCH 0/1] include core scsi support

2019-07-04 Thread Bruce Ashfield
On Thu, Jul 4, 2019 at 3:01 PM Mariano López
 wrote:
>
> The warning thrown by the kernel configuration task when building an
> ARM kernel when scsi-debug was enabled was addressed by Bruce for
> yocto-5.0. For completeness, adding the same configuration to yocto-4.19
> which also have the scsi-debug configuration fragment.
>
> Bruce, please let me know if you bump the version in OE-Core.
> Alternatively, I can work on the patch for the linux-yocto recipe once
> this patch is integrated.

I'll do a 4.19-stables series in the next day or so,  I can test this
and do the SRCREV bump at the same time.

Bruce

>
> Thanks!
>
> The following changes since commit 3017e92fcba81a1724c811825ad8835793972a04:
>
>   features/security: Add more kernel hardening fragments (2019-06-27 23:37:17 
> -0400)
>
> are available in the Git repository at:
>
>   git://github.com/justanotherboy/yocto-kernel-cache yocto-4.19-scsi
>   https://github.com/justanotherboy/yocto-kernel-cache/tree/yocto-4.19-scsi
>
> Bruce Ashfield (1):
>   scsi-debug: include core scsi support for standalone inclusion
>
>  features/scsi/scsi-debug.scc | 4 
>  1 file changed, 4 insertions(+)
>
> --
> 2.21.0
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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] [kernel-cache][PATCH 1/2] Revert "netfilter: Fix remainder of pseudo-header protocol 0"

2019-07-02 Thread Bruce Ashfield
On Tue, Jul 2, 2019 at 12:17 PM He Zhe  wrote:
>
>
>
> On 7/2/19 9:16 PM, He Zhe wrote:
> >
> > On 7/2/19 9:04 PM, Bruce Ashfield wrote:
> >> On Tue, Jul 2, 2019 at 4:54 AM  wrote:
> >>> From: He Zhe 
> >>>
> >>> The patch has already been applied on the tree. This would trigger
> >>> re-application when features/net/net.scc included.
> >> Nothing should be including net.scc directly from a KERNEL_FEATURES.
> >> It is a patch + config block.
> >> So we won't be reverting this. Whatever is triggering that extra
> >> patching is using the wrong feature
> >> fragment.
> >>
> >> How exactly are you triggering the issue ?
> > I'm triggering the issue from features/net/team/team.scc which includes 
> > net.scc.
>
> Would team.scc be considered an acceptable usage?

Possibly.

But since there's no description in the .scc file, it is hard to say
:D But going by the git history, it is possible that it is useful as
an optional feature.

In situations such as this, we break the included .scc file into an
"-enable" and a "config" variant. team.scc should include the config
variant, leaving the standard/base, and BSPs to include the full .scc
which is both patches and the config.

Bruce

>
> Thanks,
> Zhe
>
> >
> > Zhe
> >
> >> Bruce
> >>
> >>> This reverts commit b5776165c9d346c30356b9d95debd69588d58323.
> >>> ---
> >>>  features/net/net.scc   |  1 -
> >>>  ...Fix-remainder-of-pseudo-header-protocol-0.patch | 92 
> >>> --
> >>>  2 files changed, 93 deletions(-)
> >>>  delete mode 100644 
> >>> features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> >>>
> >>> diff --git a/features/net/net.scc b/features/net/net.scc
> >>> index 722b320..4a4e0fb 100644
> >>> --- a/features/net/net.scc
> >>> +++ b/features/net/net.scc
> >>> @@ -1,3 +1,2 @@
> >>>
> >>>  kconf hardware net.cfg
> >>> -patch netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> >>> diff --git 
> >>> a/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch 
> >>> b/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> >>> deleted file mode 100644
> >>> index d1fdbf9..000
> >>> --- 
> >>> a/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> >>> +++ /dev/null
> >>> @@ -1,92 +0,0 @@
> >>> -From b383959122e464ccdc21f6b37af88152d29cdf95 Mon Sep 17 00:00:00 2001
> >>> -From: He Zhe 
> >>> -Date: Tue, 25 Jun 2019 18:15:50 +0800
> >>> -Subject: [PATCH] netfilter: Fix remainder of pseudo-header protocol 0
> >>> -MIME-Version: 1.0
> >>> -Content-Type: text/plain; charset=UTF-8
> >>> -Content-Transfer-Encoding: 8bit
> >>> -
> >>> -Since v5.1-rc1, some types of packets do not get unreachable reply with 
> >>> the
> >>> -following iptables setting. Fox example,
> >>> -
> >>> -$ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> >>> -$ ping 127.0.0.1 -c 1
> >>> -PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> >>> -— 127.0.0.1 ping statistics —
> >>> -1 packets transmitted, 0 received, 100% packet loss, time 0ms
> >>> -
> >>> -We should have got the following reply from command line, but we did not.
> >>> -From 127.0.0.1 icmp_seq=1 Destination Port Unreachable
> >>> -
> >>> -Yi Zhao reported it and narrowed it down to:
> >>> -7fc38225363d ("netfilter: reject: skip csum verification for protocols 
> >>> that don't support it"),
> >>> -
> >>> -This is because nf_ip_checksum still expects pseudo-header protocol type 
> >>> 0 for
> >>> -packets that are of neither TCP or UDP, and thus ICMP packets are 
> >>> mistakenly
> >>> -treated as TCP/UDP.
> >>> -
> >>> -This patch corrects the conditions in nf_ip_checksum and all other 
> >>> places that
> >>> -still call it with protocol 0.
> >>> -
> >>> -Fixes: 7fc38225363d ("netfilter: reject: skip csum verification for 
> >>> protocols that don't support it")
> >>> -Reported-by: Yi Zhao 
> >>> -Signed-off-by: He Zhe 
> >>> -Signed-off-by: Bruce Ashfield 
> >>> 
&

Re: [linux-yocto] [kernel-cache][PATCH 1/2] Revert "netfilter: Fix remainder of pseudo-header protocol 0"

2019-07-02 Thread Bruce Ashfield
On Tue, Jul 2, 2019 at 4:54 AM  wrote:
>
> From: He Zhe 
>
> The patch has already been applied on the tree. This would trigger
> re-application when features/net/net.scc included.

Nothing should be including net.scc directly from a KERNEL_FEATURES.
It is a patch + config block.
So we won't be reverting this. Whatever is triggering that extra
patching is using the wrong feature
fragment.

How exactly are you triggering the issue ?

Bruce

>
> This reverts commit b5776165c9d346c30356b9d95debd69588d58323.
> ---
>  features/net/net.scc   |  1 -
>  ...Fix-remainder-of-pseudo-header-protocol-0.patch | 92 
> --
>  2 files changed, 93 deletions(-)
>  delete mode 100644 
> features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
>
> diff --git a/features/net/net.scc b/features/net/net.scc
> index 722b320..4a4e0fb 100644
> --- a/features/net/net.scc
> +++ b/features/net/net.scc
> @@ -1,3 +1,2 @@
>
>  kconf hardware net.cfg
> -patch netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> diff --git 
> a/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch 
> b/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> deleted file mode 100644
> index d1fdbf9..000
> --- a/features/net/netfilter-Fix-remainder-of-pseudo-header-protocol-0.patch
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -From b383959122e464ccdc21f6b37af88152d29cdf95 Mon Sep 17 00:00:00 2001
> -From: He Zhe 
> -Date: Tue, 25 Jun 2019 18:15:50 +0800
> -Subject: [PATCH] netfilter: Fix remainder of pseudo-header protocol 0
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -Since v5.1-rc1, some types of packets do not get unreachable reply with the
> -following iptables setting. Fox example,
> -
> -$ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> -$ ping 127.0.0.1 -c 1
> -PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> -— 127.0.0.1 ping statistics —
> -1 packets transmitted, 0 received, 100% packet loss, time 0ms
> -
> -We should have got the following reply from command line, but we did not.
> -From 127.0.0.1 icmp_seq=1 Destination Port Unreachable
> -
> -Yi Zhao reported it and narrowed it down to:
> -7fc38225363d ("netfilter: reject: skip csum verification for protocols that 
> don't support it"),
> -
> -This is because nf_ip_checksum still expects pseudo-header protocol type 0 
> for
> -packets that are of neither TCP or UDP, and thus ICMP packets are mistakenly
> -treated as TCP/UDP.
> -
> -This patch corrects the conditions in nf_ip_checksum and all other places 
> that
> -still call it with protocol 0.
> -
> -Fixes: 7fc38225363d ("netfilter: reject: skip csum verification for 
> protocols that don't support it")
> -Reported-by: Yi Zhao 
> -Signed-off-by: He Zhe 
> -Signed-off-by: Bruce Ashfield 
> 
> - net/netfilter/nf_conntrack_proto_icmp.c | 2 +-
> - net/netfilter/nf_nat_proto.c| 2 +-
> - net/netfilter/utils.c   | 5 +++--
> - 3 files changed, 5 insertions(+), 4 deletions(-)
> -
> -diff --git a/net/netfilter/nf_conntrack_proto_icmp.c 
> b/net/netfilter/nf_conntrack_proto_icmp.c
> -index a824367ed518..dd53e2b20f6b 100644
>  a/net/netfilter/nf_conntrack_proto_icmp.c
> -+++ b/net/netfilter/nf_conntrack_proto_icmp.c
> -@@ -218,7 +218,7 @@ int nf_conntrack_icmpv4_error(struct nf_conn *tmpl,
> -   /* See ip_conntrack_proto_tcp.c */
> -   if (state->net->ct.sysctl_checksum &&
> -   state->hook == NF_INET_PRE_ROUTING &&
> --  nf_ip_checksum(skb, state->hook, dataoff, 0)) {
> -+  nf_ip_checksum(skb, state->hook, dataoff, IPPROTO_ICMP)) {
> -   icmp_error_log(skb, state, "bad hw icmp checksum");
> -   return -NF_ACCEPT;
> -   }
> -diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
> -index 07da07788f6b..83a24cc5753b 100644
>  a/net/netfilter/nf_nat_proto.c
> -+++ b/net/netfilter/nf_nat_proto.c
> -@@ -564,7 +564,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
> -
> -   if (!skb_make_writable(skb, hdrlen + sizeof(*inside)))
> -   return 0;
> --  if (nf_ip_checksum(skb, hooknum, hdrlen, 0))
> -+  if (nf_ip_checksum(skb, hooknum, hdrlen, IPPROTO_ICMP))
> -   return 0;
> -
> -   inside = (void *)skb->data + hdrlen;
> -diff --git a/net/netfilter/utils.c b/net/netfilter/utils.c
> -index 06dc55590441..51b454d8fa9c 100644
>  a/net/netfilter/utils.c
> -+++ b/net/netfilter/utils.c
> -@@ -17,7 +17,8 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 

Re: [linux-yocto] [PATCH v2] features/security: Add more kernel hardening fragments

2019-06-27 Thread Bruce Ashfield
On Wed, Jun 26, 2019 at 11:02 PM  wrote:
>
> From: He Zhe 
>
> Signed-off-by: He Zhe 
> ---
> v2: Add a note for people using uvesafb or other similar things.
>

merged.

Bruce

>  features/security/security.cfg | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/features/security/security.cfg b/features/security/security.cfg
> index 87408b6..0a4e246 100644
> --- a/features/security/security.cfg
> +++ b/features/security/security.cfg
> @@ -11,6 +11,7 @@ CONFIG_SLAB_FREELIST_HARDENED=y
>
>  # Stack Protector is for buffer overflow detection and hardening
>  CONFIG_STACKPROTECTOR=y
> +CONFIG_STACKPROTECTOR_STRONG=y
>
>  # Perform extensive checks on reference counting
>  CONFIG_REFCOUNT_FULL=y
> @@ -34,6 +35,8 @@ CONFIG_LEGACY_VSYSCALL_NONE=y
>  # CONFIG_INET_DIAG is not set
>
>  # Do not allow direct physical memory access (enable only STRICT mode...)
> +# Note that drivers like uvesafb/v86d depending on direct physical memory
> +# access would be affected.
>  # CONFIG_DEVMEM is not set
>  CONFIG_STRICT_DEVMEM=y
>  CONFIG_IO_STRICT_DEVMEM=y
> @@ -44,3 +47,18 @@ CONFIG_DEBUG_LIST=y
>  CONFIG_DEBUG_SG=y
>  CONFIG_DEBUG_NOTIFIERS=y
>  CONFIG_DEBUG_CREDENTIALS=y
> +
> +# Information exposure
> +CONFIG_PAGE_POISONING=y
> +
> +# Kernel Address Space Layout Randomization (KASLR)
> +CONFIG_RANDOMIZE_BASE=y
> +CONFIG_RANDOMIZE_MEMORY=y
> +
> +# Direct kernel overwrite
> +CONFIG_STRICT_KERNEL_RWX=y
> +CONFIG_STRICT_MODULE_RWX=y
> +
> +# Meltdown and Spectre
> +CONFIG_PAGE_TABLE_ISOLATION=y
> +CONFIG_RETPOLINE=y
> --
> 2.7.4
>


-- 
- 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] [PATCH] netfilter: Fix remainder of pseudo-header protocol 0

2019-06-27 Thread Bruce Ashfield
On Tue, Jun 25, 2019 at 11:03 PM He Zhe  wrote:
>
>
>
> On 6/26/19 11:00 AM, Bruce Ashfield wrote:
> > On Tue, Jun 25, 2019 at 6:15 AM  wrote:
> >> From: He Zhe 
> >>
> >> Since v5.1-rc1, some types of packets do not get unreachable reply with the
> >> following iptables setting. Fox example,
> > So what's the upstream status of this ? (I haven't checked netdev yet).
>
> It hasn't got reply yet. Maybe will be handled in next version.
> https://lore.kernel.org/lkml/1561346258-272481-1-git-send-email-zhe...@windriver.com/
>

I've gone ahead and merged the change.

If there are any updates, send incremental patches.

I'll have another look when I'm doing the 5.2+ official kernel, but
you'll know sooner than I will if there are changes required.

Bruce

> Zhe
>
> >
> > Bruce
> >
> >> $ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> >> $ ping 127.0.0.1 -c 1
> >> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> >> — 127.0.0.1 ping statistics —
> >> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
> >>
> >> We should have got the following reply from command line, but we did not.
> >> From 127.0.0.1 icmp_seq=1 Destination Port Unreachable
> >>
> >> Yi Zhao reported it and narrowed it down to:
> >> 7fc38225363d ("netfilter: reject: skip csum verification for protocols 
> >> that don't support it"),
> >>
> >> This is because nf_ip_checksum still expects pseudo-header protocol type 0 
> >> for
> >> packets that are of neither TCP or UDP, and thus ICMP packets are 
> >> mistakenly
> >> treated as TCP/UDP.
> >>
> >> This patch corrects the conditions in nf_ip_checksum and all other places 
> >> that
> >> still call it with protocol 0.
> >>
> >> Fixes: 7fc38225363d ("netfilter: reject: skip csum verification for 
> >> protocols that don't support it")
> >> Reported-by: Yi Zhao 
> >> Signed-off-by: He Zhe 
> >> ---
> >> This has been sent to upstream and would probably be handled next around. 
> >> It's
> >> worth merging it before that.
> >>
> >>  net/netfilter/nf_conntrack_proto_icmp.c | 2 +-
> >>  net/netfilter/nf_nat_proto.c| 2 +-
> >>  net/netfilter/utils.c   | 5 +++--
> >>  3 files changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/net/netfilter/nf_conntrack_proto_icmp.c 
> >> b/net/netfilter/nf_conntrack_proto_icmp.c
> >> index a824367..dd53e2b 100644
> >> --- a/net/netfilter/nf_conntrack_proto_icmp.c
> >> +++ b/net/netfilter/nf_conntrack_proto_icmp.c
> >> @@ -218,7 +218,7 @@ int nf_conntrack_icmpv4_error(struct nf_conn *tmpl,
> >> /* See ip_conntrack_proto_tcp.c */
> >> if (state->net->ct.sysctl_checksum &&
> >> state->hook == NF_INET_PRE_ROUTING &&
> >> -   nf_ip_checksum(skb, state->hook, dataoff, 0)) {
> >> +   nf_ip_checksum(skb, state->hook, dataoff, IPPROTO_ICMP)) {
> >> icmp_error_log(skb, state, "bad hw icmp checksum");
> >> return -NF_ACCEPT;
> >> }
> >> diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
> >> index 07da077..83a24cc 100644
> >> --- a/net/netfilter/nf_nat_proto.c
> >> +++ b/net/netfilter/nf_nat_proto.c
> >> @@ -564,7 +564,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
> >>
> >> if (!skb_make_writable(skb, hdrlen + sizeof(*inside)))
> >> return 0;
> >> -   if (nf_ip_checksum(skb, hooknum, hdrlen, 0))
> >> +   if (nf_ip_checksum(skb, hooknum, hdrlen, IPPROTO_ICMP))
> >> return 0;
> >>
> >> inside = (void *)skb->data + hdrlen;
> >> diff --git a/net/netfilter/utils.c b/net/netfilter/utils.c
> >> index 06dc555..51b454d 100644
> >> --- a/net/netfilter/utils.c
> >> +++ b/net/netfilter/utils.c
> >> @@ -17,7 +17,8 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 
> >> hook,
> >> case CHECKSUM_COMPLETE:
> >> if (hook != NF_INET_PRE_ROUTING && hook != 
> >> NF_INET_LOCAL_IN)
> >> break;
> >> -   if ((protocol == 0 && !csum_fold(skb->csum)) ||
> >> +   if ((protocol != IPPROTO_TCP && protocol != IPPROTO_UDP &&
> &

Re: [linux-yocto] failed to boot qemu with security.scc

2019-06-26 Thread Bruce Ashfield
On Tue, Jun 25, 2019 at 10:55 PM He Zhe  wrote:
>
>
>
> On 6/26/19 10:49 AM, Bruce Ashfield wrote:
> > On Tue, Jun 25, 2019 at 10:25 AM He Zhe  wrote:
> >> Hi Bruce,
> >>
> >> Have you ever met the following error with features/security/security.scc, 
> >> when running qemux86?
> > Hmm. No, I haven't seen that.
> >
> > My old builds were using sysvinit, so I didn't have a recent build
> > ready to go. But I just started a new one, and will do a boot test on
> > (my) Tuesday.
>
> Coming together with endless:
> "uvesafb: 5000 ms task timeout, infinitely waiting."
> I found it was stuck on loading uvesafb and should be related Yocto #8245
> I'm reading the history.

My build completed overnight. I assume with your updated security
fragment you were able to boot again ?

Bruce

>
> Thanks,
> Zhe
>
> >
> > Bruce
> >
> >> ...
> >> [**] A start job is running for Load Kernel Modules (7min 26s / 7min 
> >> 31s)
> >>
> >>
> >> * systemd-modules-load.service - Load Kernel Modules
> >>Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; 
> >> static; vendor preset: disabled)
> >>Active: failed (Result: timeout) since Tue 2019-06-25 13:55:28 UTC; 
> >> 6min ago
> >>  Docs: man:systemd-modules-load.service(8)
> >>man:modules-load.d(5)
> >>  Main PID: 110
> >> Tasks: 1 (limit: 570)
> >>Memory: 968.0K
> >>CGroup: /system.slice/systemd-modules-load.service
> >>`-110 /lib/systemd/systemd-modules-load
> >>
> >> Jun 25 13:47:58 qemux86 systemd-modules-load[110]: Inserted module 
> >> 'openvswitch'
> >> Jun 25 13:49:27 qemux86 systemd[1]: systemd-modules-load.service: Start 
> >> operation timed out. Terminating.
> >> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: State 
> >> 'stop-sigterm' timed out. Killing.
> >> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: Killing 
> >> process 110 (systemd-modules) with signal SIGKILL.
> >> Jun 25 13:52:28 qemux86 systemd[1]: systemd-modules-load.service: 
> >> Processes still around after SIGKILL. Ignoring.
> >> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: State 
> >> 'stop-final-sigterm' timed out. Killing.
> >> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: Killing 
> >> process 110 (systemd-modules) with signal SIGKILL.
> >> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: 
> >> Processes still around after final SIGKILL. Entering failed mode.
> >> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: Failed 
> >> with result 'timeout'.
> >> Jun 25 13:55:28 qemux86 systemd[1]: Failed to start Load Kernel Modules.
> >>
> >>
> >> Zhe
> >
> >
>


-- 
- 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] [PATCH] netfilter: Fix remainder of pseudo-header protocol 0

2019-06-25 Thread Bruce Ashfield
On Tue, Jun 25, 2019 at 11:00 PM Bruce Ashfield
 wrote:
>
> On Tue, Jun 25, 2019 at 6:15 AM  wrote:
> >
> > From: He Zhe 
> >
> > Since v5.1-rc1, some types of packets do not get unreachable reply with the
> > following iptables setting. Fox example,
>
> So what's the upstream status of this ? (I haven't checked netdev yet).
>

I should have just checked and saved an email. I found your submission
of the change, but don't see any feedback. I'll follow along on netdev
and see where it goes.

Bruce

> Bruce
>
> >
> > $ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> > $ ping 127.0.0.1 -c 1
> > PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> > — 127.0.0.1 ping statistics —
> > 1 packets transmitted, 0 received, 100% packet loss, time 0ms
> >
> > We should have got the following reply from command line, but we did not.
> > From 127.0.0.1 icmp_seq=1 Destination Port Unreachable
> >
> > Yi Zhao reported it and narrowed it down to:
> > 7fc38225363d ("netfilter: reject: skip csum verification for protocols that 
> > don't support it"),
> >
> > This is because nf_ip_checksum still expects pseudo-header protocol type 0 
> > for
> > packets that are of neither TCP or UDP, and thus ICMP packets are mistakenly
> > treated as TCP/UDP.
> >
> > This patch corrects the conditions in nf_ip_checksum and all other places 
> > that
> > still call it with protocol 0.
> >
> > Fixes: 7fc38225363d ("netfilter: reject: skip csum verification for 
> > protocols that don't support it")
> > Reported-by: Yi Zhao 
> > Signed-off-by: He Zhe 
> > ---
> > This has been sent to upstream and would probably be handled next around. 
> > It's
> > worth merging it before that.
> >
> >  net/netfilter/nf_conntrack_proto_icmp.c | 2 +-
> >  net/netfilter/nf_nat_proto.c| 2 +-
> >  net/netfilter/utils.c   | 5 +++--
> >  3 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_proto_icmp.c 
> > b/net/netfilter/nf_conntrack_proto_icmp.c
> > index a824367..dd53e2b 100644
> > --- a/net/netfilter/nf_conntrack_proto_icmp.c
> > +++ b/net/netfilter/nf_conntrack_proto_icmp.c
> > @@ -218,7 +218,7 @@ int nf_conntrack_icmpv4_error(struct nf_conn *tmpl,
> > /* See ip_conntrack_proto_tcp.c */
> > if (state->net->ct.sysctl_checksum &&
> > state->hook == NF_INET_PRE_ROUTING &&
> > -   nf_ip_checksum(skb, state->hook, dataoff, 0)) {
> > +   nf_ip_checksum(skb, state->hook, dataoff, IPPROTO_ICMP)) {
> > icmp_error_log(skb, state, "bad hw icmp checksum");
> > return -NF_ACCEPT;
> > }
> > diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
> > index 07da077..83a24cc 100644
> > --- a/net/netfilter/nf_nat_proto.c
> > +++ b/net/netfilter/nf_nat_proto.c
> > @@ -564,7 +564,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
> >
> > if (!skb_make_writable(skb, hdrlen + sizeof(*inside)))
> > return 0;
> > -   if (nf_ip_checksum(skb, hooknum, hdrlen, 0))
> > +   if (nf_ip_checksum(skb, hooknum, hdrlen, IPPROTO_ICMP))
> > return 0;
> >
> > inside = (void *)skb->data + hdrlen;
> > diff --git a/net/netfilter/utils.c b/net/netfilter/utils.c
> > index 06dc555..51b454d 100644
> > --- a/net/netfilter/utils.c
> > +++ b/net/netfilter/utils.c
> > @@ -17,7 +17,8 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 
> > hook,
> > case CHECKSUM_COMPLETE:
> > if (hook != NF_INET_PRE_ROUTING && hook != NF_INET_LOCAL_IN)
> > break;
> > -   if ((protocol == 0 && !csum_fold(skb->csum)) ||
> > +   if ((protocol != IPPROTO_TCP && protocol != IPPROTO_UDP &&
> > +   !csum_fold(skb->csum)) ||
> > !csum_tcpudp_magic(iph->saddr, iph->daddr,
> >skb->len - dataoff, protocol,
> >skb->csum)) {
> > @@ -26,7 +27,7 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 
> > hook,
> > }
> > /* fall through */
> > case CHECKSUM_NONE:
> > -   if (protocol == 0)
> > +   if (protocol != IPPROTO_TCP && protocol != IPPROTO_UDP)
> > skb->csum = 0;
> > else
> > skb->csum = csum_tcpudp_nofold(iph->saddr, 
> > iph->daddr,
> > --
> > 2.7.4
> >
>
>
> --
> - 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] [PATCH] netfilter: Fix remainder of pseudo-header protocol 0

2019-06-25 Thread Bruce Ashfield
On Tue, Jun 25, 2019 at 6:15 AM  wrote:
>
> From: He Zhe 
>
> Since v5.1-rc1, some types of packets do not get unreachable reply with the
> following iptables setting. Fox example,

So what's the upstream status of this ? (I haven't checked netdev yet).

Bruce

>
> $ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> $ ping 127.0.0.1 -c 1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> — 127.0.0.1 ping statistics —
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>
> We should have got the following reply from command line, but we did not.
> From 127.0.0.1 icmp_seq=1 Destination Port Unreachable
>
> Yi Zhao reported it and narrowed it down to:
> 7fc38225363d ("netfilter: reject: skip csum verification for protocols that 
> don't support it"),
>
> This is because nf_ip_checksum still expects pseudo-header protocol type 0 for
> packets that are of neither TCP or UDP, and thus ICMP packets are mistakenly
> treated as TCP/UDP.
>
> This patch corrects the conditions in nf_ip_checksum and all other places that
> still call it with protocol 0.
>
> Fixes: 7fc38225363d ("netfilter: reject: skip csum verification for protocols 
> that don't support it")
> Reported-by: Yi Zhao 
> Signed-off-by: He Zhe 
> ---
> This has been sent to upstream and would probably be handled next around. It's
> worth merging it before that.
>
>  net/netfilter/nf_conntrack_proto_icmp.c | 2 +-
>  net/netfilter/nf_nat_proto.c| 2 +-
>  net/netfilter/utils.c   | 5 +++--
>  3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_proto_icmp.c 
> b/net/netfilter/nf_conntrack_proto_icmp.c
> index a824367..dd53e2b 100644
> --- a/net/netfilter/nf_conntrack_proto_icmp.c
> +++ b/net/netfilter/nf_conntrack_proto_icmp.c
> @@ -218,7 +218,7 @@ int nf_conntrack_icmpv4_error(struct nf_conn *tmpl,
> /* See ip_conntrack_proto_tcp.c */
> if (state->net->ct.sysctl_checksum &&
> state->hook == NF_INET_PRE_ROUTING &&
> -   nf_ip_checksum(skb, state->hook, dataoff, 0)) {
> +   nf_ip_checksum(skb, state->hook, dataoff, IPPROTO_ICMP)) {
> icmp_error_log(skb, state, "bad hw icmp checksum");
> return -NF_ACCEPT;
> }
> diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
> index 07da077..83a24cc 100644
> --- a/net/netfilter/nf_nat_proto.c
> +++ b/net/netfilter/nf_nat_proto.c
> @@ -564,7 +564,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
>
> if (!skb_make_writable(skb, hdrlen + sizeof(*inside)))
> return 0;
> -   if (nf_ip_checksum(skb, hooknum, hdrlen, 0))
> +   if (nf_ip_checksum(skb, hooknum, hdrlen, IPPROTO_ICMP))
> return 0;
>
> inside = (void *)skb->data + hdrlen;
> diff --git a/net/netfilter/utils.c b/net/netfilter/utils.c
> index 06dc555..51b454d 100644
> --- a/net/netfilter/utils.c
> +++ b/net/netfilter/utils.c
> @@ -17,7 +17,8 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 
> hook,
> case CHECKSUM_COMPLETE:
> if (hook != NF_INET_PRE_ROUTING && hook != NF_INET_LOCAL_IN)
> break;
> -   if ((protocol == 0 && !csum_fold(skb->csum)) ||
> +   if ((protocol != IPPROTO_TCP && protocol != IPPROTO_UDP &&
> +   !csum_fold(skb->csum)) ||
> !csum_tcpudp_magic(iph->saddr, iph->daddr,
>skb->len - dataoff, protocol,
>skb->csum)) {
> @@ -26,7 +27,7 @@ __sum16 nf_ip_checksum(struct sk_buff *skb, unsigned int 
> hook,
> }
> /* fall through */
> case CHECKSUM_NONE:
> -   if (protocol == 0)
> +   if (protocol != IPPROTO_TCP && protocol != IPPROTO_UDP)
> skb->csum = 0;
> else
> skb->csum = csum_tcpudp_nofold(iph->saddr, iph->daddr,
> --
> 2.7.4
>


-- 
- 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] failed to boot qemu with security.scc

2019-06-25 Thread Bruce Ashfield
On Tue, Jun 25, 2019 at 10:25 AM He Zhe  wrote:
>
> Hi Bruce,
>
> Have you ever met the following error with features/security/security.scc, 
> when running qemux86?

Hmm. No, I haven't seen that.

My old builds were using sysvinit, so I didn't have a recent build
ready to go. But I just started a new one, and will do a boot test on
(my) Tuesday.

Bruce

>
> ...
> [**] A start job is running for Load Kernel Modules (7min 26s / 7min 31s)
>
>
> * systemd-modules-load.service - Load Kernel Modules
>Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; 
> vendor preset: disabled)
>Active: failed (Result: timeout) since Tue 2019-06-25 13:55:28 UTC; 6min 
> ago
>  Docs: man:systemd-modules-load.service(8)
>man:modules-load.d(5)
>  Main PID: 110
> Tasks: 1 (limit: 570)
>Memory: 968.0K
>CGroup: /system.slice/systemd-modules-load.service
>`-110 /lib/systemd/systemd-modules-load
>
> Jun 25 13:47:58 qemux86 systemd-modules-load[110]: Inserted module 
> 'openvswitch'
> Jun 25 13:49:27 qemux86 systemd[1]: systemd-modules-load.service: Start 
> operation timed out. Terminating.
> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: State 
> 'stop-sigterm' timed out. Killing.
> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: Killing 
> process 110 (systemd-modules) with signal SIGKILL.
> Jun 25 13:52:28 qemux86 systemd[1]: systemd-modules-load.service: Processes 
> still around after SIGKILL. Ignoring.
> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: State 
> 'stop-final-sigterm' timed out. Killing.
> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: Killing 
> process 110 (systemd-modules) with signal SIGKILL.
> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: Processes 
> still around after final SIGKILL. Entering failed mode.
> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: Failed with 
> result 'timeout'.
> Jun 25 13:55:28 qemux86 systemd[1]: Failed to start Load Kernel Modules.
>
>
> Zhe



-- 
- 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] [kernel-cache][PATCHv2 0/1] qemu support for ARM devices

2019-06-24 Thread Bruce Ashfield
On Sun, Jun 16, 2019 at 11:45 AM Adrian Freihofer
 wrote:
>
> Hi, Bruce,
>
> Compared to v1, this is more or less a rewrite. It is now very similar to the 
> qemuarma15 BSP as suggested by you.
>
> The qemuarm15 BSP generates a kernel of 7046128 bytes.
> The current Beaglebone yocto configuration produces a kernel of 6451976 bytes.
>
> In addition to the configuration flags already set in the Beaglebone 
> configuration, the qemuarm15 configuration includes cfg/virtio.scc and 
> qemuarma15.scc. The virtio.scc is well suited for both. The qemuarma15.scc is 
> too heavy for the Beaglebone, mainly due to SMP and NEON.
>
> The kernel configuration with this patch results in a Beaglebone kernel with 
> a size of 6623704 bytes, which is a plus of ~170k. But this makes it possible 
> to start the Beaglebone images in Qemu with graphics.
>

The re-work looks good to me. I can't argue with the results and the
minimal duplication between the two configurations.

I've gone ahead and merged this, and it will show up in my next pull
request to oe-core.

Bruce

> Adrian Freihofer (1):
>   bsp/beaglebone: support qemu -machine virt
>
>  bsp/beaglebone/beaglebone.scc | 5 +
>  bsp/beaglebone/qemu-bb.cfg| 9 +
>  bsp/beaglebone/qemu-bb.scc| 1 +
>  3 files changed, 15 insertions(+)
>  create mode 100644 bsp/beaglebone/qemu-bb.cfg
>  create mode 100644 bsp/beaglebone/qemu-bb.scc
>
> --
> 2.11.0
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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] [kernel-cache][PATCHv2 0/1] qemu support for ARM devices

2019-06-24 Thread Bruce Ashfield
Sorry for the delay.

I was out of the office for a bit, and I'm having a look at this now.

Bruce

On Sun, Jun 16, 2019 at 11:45 AM Adrian Freihofer
 wrote:
>
> Hi, Bruce,
>
> Compared to v1, this is more or less a rewrite. It is now very similar to the 
> qemuarma15 BSP as suggested by you.
>
> The qemuarm15 BSP generates a kernel of 7046128 bytes.
> The current Beaglebone yocto configuration produces a kernel of 6451976 bytes.
>
> In addition to the configuration flags already set in the Beaglebone 
> configuration, the qemuarm15 configuration includes cfg/virtio.scc and 
> qemuarma15.scc. The virtio.scc is well suited for both. The qemuarma15.scc is 
> too heavy for the Beaglebone, mainly due to SMP and NEON.
>
> The kernel configuration with this patch results in a Beaglebone kernel with 
> a size of 6623704 bytes, which is a plus of ~170k. But this makes it possible 
> to start the Beaglebone images in Qemu with graphics.
>
> Adrian Freihofer (1):
>   bsp/beaglebone: support qemu -machine virt
>
>  bsp/beaglebone/beaglebone.scc | 5 +
>  bsp/beaglebone/qemu-bb.cfg| 9 +
>  bsp/beaglebone/qemu-bb.scc| 1 +
>  3 files changed, 15 insertions(+)
>  create mode 100644 bsp/beaglebone/qemu-bb.cfg
>  create mode 100644 bsp/beaglebone/qemu-bb.scc
>
> --
> 2.11.0
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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] [PATCH] Revert "fuse: require /dev/fuse reads to have enough buffer capacity"

2019-06-24 Thread Bruce Ashfield
I had queued -rc6 this morning .. and then noticed this.

I've pushed the changes, so we are covered, now that the -dev kernel is updated.

Bruce

On Mon, Jun 24, 2019 at 5:39 AM  wrote:
>
> From: Miklos Szeredi 
>
> This reverts commit d4b13963f217dd947da5c0cabd1569e914d21699.
>
> The commit introduced a regression in glusterfs-fuse.
>
> Reported-by: Sander Eikelenboom 
> Signed-off-by: Miklos Szeredi 
> ---
> This fixes failure to mount glusterfs and is from v5.2-rc6.
> If we're not going to merge v5.2-rc6 soon, please kindly consider merging this
> first, thanks.
>
>  fs/fuse/dev.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 24ea19c..ea82375 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -1317,16 +1317,6 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, 
> struct file *file,
> unsigned reqsize;
> unsigned int hash;
>
> -   /*
> -* Require sane minimum read buffer - that has capacity for fixed part
> -* of any request header + negotated max_write room for data. If the
> -* requirement is not satisfied return EINVAL to the filesystem server
> -* to indicate that it is not following FUSE server/client contract.
> -* Don't dequeue / abort any request.
> -*/
> -   if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + 
> fc->max_write))
> -   return -EINVAL;
> -
>   restart:
> spin_lock(>waitq.lock);
> err = -EAGAIN;
> --
> 2.7.4
>


-- 
- 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] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp

2019-06-13 Thread Bruce Ashfield
Sorry about that. I was traveling this week, and kept forgetting to
create the branch.

It should be in place now.

Bruce

On Thu, Jun 13, 2019 at 3:48 AM Zumeng Chen  wrote:
>
> Ping 
>
> On 6/11/19 9:40 AM, Zumeng Chen wrote:
>
> Hi Bruce,
>
> I just finished insane check to build xilinx-zynqmp machine with 
> core-image-sato, all passed with boot process.
>
> Could you please help me to create a branch like that standard/xilinx-zynqmp 
> in the following git repo. in convenient your time, just directly branch out 
> from origin/standard/base, thanks~
>
> git://git.yoctoproject.org/linux-yocto-dev
>
>
> Cheers,
>
> Zumeng
>
> On 6/11/19 7:37 AM, Zumeng Chen wrote:
>
>
> On 6/10/19 9:37 PM, Bruce Ashfield wrote:
>
> On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen  wrote:
>
> Sounds I like mean, no, I just talk the reality, Xilinx did like the
> following:
>
> https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp
>
> I think they have a reason to share zynq-7000 series hardware, which
> gears to the related hardware
>
> features, and the way to create dts(a relative complicated process)
> corresponding to the hdl related
>
> features partly as well. And they just want to put zynqmp(arm64) into
> recipes-kernel/linux/xilinx-kmeta/bsp/xilinx,
>
> As you can see, they have almost little in common in hardware features.
>
>
> The reality here I said is about yocto project has not these related
> ecosystem to create these whole thing for
>
> xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl,
> BOOT.BIN etc. there really are a bunch
>
> of Xilinx things.
>
>
> So do we still want to following their SDK? If yes, fine, just help me
> to merge zynqmp part from meta-xilinx, I'll take care the rest.
>
> I'm actually fine with an approach like we are taking here. Come up
> with something that works purely with linux-yocto, and then we can
> start factoring and grouping the fragments with the help of people
> closer to the h/w.
>
> In particular as more Xilinx proprietary parts are open sourced, we'll
> have the opportunity to tweak the configuration fragments to support
> them properly/fully.
>
> We do want the fragments in the centralized kernel-cache, just as long
> as they are appropriated factored/grouped under a xilinx/ subdir where
> it makes sense, and have more generic feature groupings available to
> be shared in the more common directories.
>
> What we have is a good start to that goal, so I'll get it merged and
> we can start iterating on it in tree.
>
>
>
> Thanks Bruce, highly appreciated :)
>
>
> Cheers,
>
> Zumeng
>
>
> Bruce
>
>
> Cheers,
>
> Zumeng
>
>
> On 6/6/19 2:55 PM, Zumeng Chen wrote:
>
> Yes, I checked it, it seems only for zynq 7000 and its special
> interfaces. I bet
>
> the original author didn't mean to share something for both arm64
> and 32 :)
>
> When I created the structure I had intended for it to include the
> zynqmp related configs. I even had some yocto-kernel-cache patches for
> it at the time, but zynqmp has changed quite a bit since those initial
> patches. Most of those configs still live in meta-xilinx though (some
> are specific to the linux-xlnx kernel).
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta
>
>
> I would highly recommend keeping the xilinx bsp configs together under
> the bsp/xilinx/ directory. And try to reuse the existing configs where
> possible or splitting some parts of them out to make common configs
> since zynq and zynqmp share a number of common drivers.
>
>
> Negative, try to see what had done in the past, a very little can
> re-used. And I suspect
>
> did you even how many features they are sharing.
>
> I don't think it's worth. To be honestly, they have totally the
> different app scenario.
>
> Cheers,
>
> Zumeng
>
> Regards,
> Nathan
>
> And for those common things, I guess some of them might be included
> by our
>
> rootfs build system.
>
>
> sense to locate these fragments there, and to factor out some common
> configs. I see some of the issues I'm pointing out here are in the
> existing fragments as well, so there's an opportunity for some low
> effort fixups.
>
> +
> +CONFIG_PCI=y
> +CONFIG_PCI_MSI=y
> +CONFIG_PCI_MSI_IRQ_DOMAIN=y
> +CONFIG_PCIE_XILINX_NWL=y
> +CONFIG_PCIEPORTBUS=y
> +CONFIG_PCIE_XDMA_PL=y
> +
> +#CPU ilde and freq
> +CONFIG_CPU_IDLE=y
> +CONFIG_ARM_CPUIDLE=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
> +CONFIG_CPU_FRE

Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp

2019-06-10 Thread Bruce Ashfield
On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen  wrote:
>
> Sounds I like mean, no, I just talk the reality, Xilinx did like the
> following:
>
> https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp
>
> I think they have a reason to share zynq-7000 series hardware, which
> gears to the related hardware
>
> features, and the way to create dts(a relative complicated process)
> corresponding to the hdl related
>
> features partly as well. And they just want to put zynqmp(arm64) into
> recipes-kernel/linux/xilinx-kmeta/bsp/xilinx,
>
> As you can see, they have almost little in common in hardware features.
>
>
> The reality here I said is about yocto project has not these related
> ecosystem to create these whole thing for
>
> xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl,
> BOOT.BIN etc. there really are a bunch
>
> of Xilinx things.
>
>
> So do we still want to following their SDK? If yes, fine, just help me
> to merge zynqmp part from meta-xilinx, I'll take care the rest.

I'm actually fine with an approach like we are taking here. Come up
with something that works purely with linux-yocto, and then we can
start factoring and grouping the fragments with the help of people
closer to the h/w.

In particular as more Xilinx proprietary parts are open sourced, we'll
have the opportunity to tweak the configuration fragments to support
them properly/fully.

We do want the fragments in the centralized kernel-cache, just as long
as they are appropriated factored/grouped under a xilinx/ subdir where
it makes sense, and have more generic feature groupings available to
be shared in the more common directories.

What we have is a good start to that goal, so I'll get it merged and
we can start iterating on it in tree.

Bruce

>
>
> Cheers,
>
> Zumeng
>
>
> On 6/6/19 2:55 PM, Zumeng Chen wrote:
> >
> >>>
> >>> Yes, I checked it, it seems only for zynq 7000 and its special
> >>> interfaces. I bet
> >>>
> >>> the original author didn't mean to share something for both arm64
> >>> and 32 :)
> >> When I created the structure I had intended for it to include the
> >> zynqmp related configs. I even had some yocto-kernel-cache patches for
> >> it at the time, but zynqmp has changed quite a bit since those initial
> >> patches. Most of those configs still live in meta-xilinx though (some
> >> are specific to the linux-xlnx kernel).
> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta
> >>
> >>
> >> I would highly recommend keeping the xilinx bsp configs together under
> >> the bsp/xilinx/ directory. And try to reuse the existing configs where
> >> possible or splitting some parts of them out to make common configs
> >> since zynq and zynqmp share a number of common drivers.
> >
> >
> > Negative, try to see what had done in the past, a very little can
> > re-used. And I suspect
> >
> > did you even how many features they are sharing.
> >
> > I don't think it's worth. To be honestly, they have totally the
> > different app scenario.
> >
> > Cheers,
> >
> > Zumeng
> >
> >>
> >> Regards,
> >> Nathan
> >>
> >>> And for those common things, I guess some of them might be included
> >>> by our
> >>>
> >>> rootfs build system.
> >>>
> >>>
>  sense to locate these fragments there, and to factor out some common
>  configs. I see some of the issues I'm pointing out here are in the
>  existing fragments as well, so there's an opportunity for some low
>  effort fixups.
> >>>
> > +
> > +CONFIG_PCI=y
> > +CONFIG_PCI_MSI=y
> > +CONFIG_PCI_MSI_IRQ_DOMAIN=y
> > +CONFIG_PCIE_XILINX_NWL=y
> > +CONFIG_PCIEPORTBUS=y
> > +CONFIG_PCIE_XDMA_PL=y
> > +
> > +#CPU ilde and freq
> > +CONFIG_CPU_IDLE=y
> > +CONFIG_ARM_CPUIDLE=y
> > +CONFIG_CPU_FREQ=y
> > +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
> > +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > +CONFIG_CPUFREQ_DT=y
> > +CONFIG_CPUFREQ_DT_PLATDEV=y
>  These are also not tied to h/w. We already have a
>  features/power/intel.cfg fragment. Can you relocate these to a zynqmp
>  or xilinx fragment and put it along side of the existing ones ?
> >>>
> >>> I'll try it with a nice way.
> >>>
> 
> > +
> > +# CAN Device Drivers
> > +#
> > +CONFIG_CAN=y
> > +CONFIG_CAN_DEV=y
> > +CONFIG_CAN_XILINXCAN=y
> > +
> > +CONFIG_MTD=y
> > +CONFIG_MTD_OF_PARTS=y
> > +CONFIG_MTD_BLKDEVS=y
> > +CONFIG_MTD_BLOCK=y
> > +CONFIG_MTD_M25P80=y
> > +CONFIG_MTD_SPI_NOR=y
> > +# CONFIG_JFFS2_FS_WRITEBUFFER is not set
> > +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
> > +
> > +CONFIG_BLK_DEV_SD=y
> > +CONFIG_ATA=y
> > +CONFIG_SATA_AHCI=y
> > +CONFIG_AHCI_CEVA=y
> > +CONFIG_NETDEVICES=y
> > +
> > +CONFIG_OF=y
> > +CONFIG_OF_MDIO=y
> > +CONFIG_ETHERNET=y
> > +CONFIG_NET_CADENCE=y
> > +CONFIG_MACB=y
> > 

Re: [linux-yocto] [kernel-cache][PATCH 1/2] features: add qemu-guest

2019-06-09 Thread Bruce Ashfield
On Sun, Jun 9, 2019 at 8:49 AM Adrian Freihofer
 wrote:
>
> Purpose: Provide an easy way to add ARCH_VIRT=y to the kernel configuration.
> This allows to boot ARM images compiled for real hardware in Qemu as well.
> Including this feature e.g. into the Beaglebone BSP allows to:

We already have the qemuarma15 BSP, and calling it that  for the purposes of
qemu booting was entirely on purpose.

History has shown us many times that maintaining a BSP for both h/w and
virtual boots eventually leads to conflicting requirements and compromise on
both the h/w and virtual variant.

i.e. there's not a lot of benefit outside of asking for the qemu* machines to
be used when someone wants to do a virtual boot . .and yes, I understand the
request and justification for it, I've been asked many times for something
similar to this.

That being said, if we do take something like this, the CONFIG_ARCH_VIRT, etc
of this fragment should be used by qemuarma15 as well, since that is the variant
that gets regular boot testing.

So the summary is, with some refactoring, I don't see why this can't merge.

>
>   export MACHINE="beaglebone-yocto"
>   bitbake core-image-minimale
>   runqemu
>
> This also works with the eSDK. Whithout this feature usually two different
> SDKs need to be compiled and maintained. One SDK is used for development
> in Qemu, another one is used to develop for the real target hardware.
>
> Note: For newer aarch64 devices a pci variant of this config snipped
>   might be beneficial.
>
> [Yocto #13384]
>
> Signed-off-by: Adrian Freihofer 
> ---
>  features/qemu-guest/qemu-arm-virt.cfg | 10 ++
>  features/qemu-guest/qemu-arm-virt.scc |  4 
>  2 files changed, 14 insertions(+)
>  create mode 100644 features/qemu-guest/qemu-arm-virt.cfg
>  create mode 100644 features/qemu-guest/qemu-arm-virt.scc
>
> diff --git a/features/qemu-guest/qemu-arm-virt.cfg 
> b/features/qemu-guest/qemu-arm-virt.cfg
> new file mode 100644
> index ..7aec61de
> --- /dev/null
> +++ b/features/qemu-guest/qemu-arm-virt.cfg
> @@ -0,0 +1,10 @@
> +CONFIG_ARCH_VIRT=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_VIRTIO_BLK_SCSI=y
> +CONFIG_VIRTIO_NET=y
> +CONFIG_SERIAL_AMBA_PL011=y
> +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_VIRTIO=y
> +CONFIG_VIRTIO_MMIO=y
> +CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y

We already have configuration blocks for virtio, and they should be
reused here. If
there are issues with those config fragments, we should refactor them
so they can be
reused.

Cheers,

Bruce

> diff --git a/features/qemu-guest/qemu-arm-virt.scc 
> b/features/qemu-guest/qemu-arm-virt.scc
> new file mode 100644
> index ..54682dcf
> --- /dev/null
> +++ b/features/qemu-guest/qemu-arm-virt.scc
> @@ -0,0 +1,4 @@
> +define KFEATURE_DESCRIPTION "Enable options for ARM images in Qemu"
> +define KFEATURE_COMPATIBILITY board
> +
> +kconf hardware qemu-arm-virt.cfg
> --
> 2.11.0
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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] [kernel-cache][PATCH 0/2] qemu support for ARM devices

2019-06-09 Thread Bruce Ashfield
On Sun, Jun 9, 2019 at 8:49 AM Adrian Freihofer
 wrote:
>
> The purpose/idea is documented here:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13384

Just cut and paste the reasons into the cover letter + patches. Not
all reviews are done online
and having the info quickly available for git queries is handy.

Bruce

>
> Adrian Freihofer (2):
>   features: add qemu-guest
>   bsp/beaglebone: include qemu-guest feature
>
>  bsp/beaglebone/beaglebone.scc |  1 +
>  features/qemu-guest/qemu-arm-virt.cfg | 10 ++
>  features/qemu-guest/qemu-arm-virt.scc |  4 
>  3 files changed, 15 insertions(+)
>  create mode 100644 features/qemu-guest/qemu-arm-virt.cfg
>  create mode 100644 features/qemu-guest/qemu-arm-virt.scc
>
> --
> 2.11.0
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto



-- 
- 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


  1   2   3   4   5   6   7   8   9   10   >