date:20181001

[yocto] Custom image type with dependencies

2018-10-01 Thread Jef Driesen


Hi,

We use a gpg signed tarball as our image format. This is implemented 
using CONVERSIONTYPES:


CONVERSIONTYPES += "gpg"
CONVERSION_CMD_gpg = "gpg --batch --yes -s ${IMAGE_NAME}.rootfs.${type}"
CONVERSION_DEPENDS_gpg = "gnupg"

And then in the image recipe:

IMAGE_FSTYPES += "tar tar.gpg"

This works, except for one thing. The above is a simplification and the 
actual signing is done by a script. It does not only sign the tarball, 
but also adds a few extra files.


But how do I fetch the script, and those extra files? I tried to use 
SRC_URI, as you would do in a regular recipe. But that doesn't work 
because image.bbclass contains:


do_fetch[noexec] = "1"

Next, I tried to create a native "gpgsign" recipe containing my script 
and its dependencies. I then added the dependency:


CONVERSION_DEPENDS_gpg = "gpgsign-native"

assuming it would put my script in the native sysroot of the image. But 
that doesn't seem to work. The only thing that happens are some 
gpgsign-native files in these directories:


./recipe-sysroot-native/installeddeps/
./recipe-sysroot-native/sysroot-providers/

But no files are added in:

./recipe-sysroot-native/

If I do the same with for example xz-native, then the xz binaries are 
added to the native sysroot, and then compressing the image works fine. 
But not for my gpg signing.


What am I doing wrong?

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

Re: [yocto] [PATCH] runtime: add BSP test case for usb storage

2018-10-01 Thread Mike Looijmans


On 24-09-18 23:01, Paul Eggleton wrote:

On Monday, 24 September 2018 3:02:28 PM NZST Hussin, Mohamad Noor Alim wrote:

...

Otherwise I agree with Mike's reply, we should avoid writing to the storage 
device as part of the test.


It is mean that just do test like mount and unmount only? To read something in 
storage device we need to write at first place?


That's true - but you can still do a read test if you make it a precondition of 
the test
that you write some known file to the storage device before running the test
(as part of setup, just as you need to set up the board/device before
running any tests - you just need to ensure this gets documented somewhere).


You're not testing the USB device, you're testing the USB stack. To do that, 
just reading some data from "/dev/sda" is sufficient. You don't even need to 
mount it. If this works, the stack is okay. If there are transfer errors or 
problems, the USB stack will tell you about it.

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

[yocto] [layerindex-web][PATCH] Fix broken regex for recipes with names containing + signs

2018-10-01 Thread Paul Eggleton

In order to show bbappends on the recipe detail page we are doing a
regex query to find any whose names match up with the recipe. In the
layer index instance at layers.openembedded.org viewing the recipe
detail page for any recipe whose name contains ++ (e.g. libsigc++-2.0 in
meta-oe) results in an invalid regex and causes a database error. Escape
any + signs in the name used within the regex in order to fix this.

(I wasn't actually able to reproduce this on my own setup despite also
using MariaDB, but I did find that the unescaped query was not correctly
matching records so it needed to be fixed anyway.)

Signed-off-by: Paul Eggleton 
---
 layerindex/views.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/layerindex/views.py b/layerindex/views.py
index 4eed0cef..5ac7ffab 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -869,6 +869,7 @@ class RecipeDetailView(DetailView):
 if recipe:
 verappendprefix = recipe.filename.split('.bb')[0]
 appendprefix = verappendprefix.split('_')[0]
+appendprefix = appendprefix.replace('+', r'\+')
 #context['verappends'] = 
BBAppend.objects.filter(layerbranch__branch=recipe.layerbranch.branch).filter(filename='%s.bbappend'
 % verappendprefix)
 context['appends'] = 
BBAppend.objects.filter(layerbranch__branch=recipe.layerbranch.branch).filter(filename__regex=r'^%s(_[^_]*)?\.bbappend'
 % appendprefix)
 verappends = []
-- 
2.17.1

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

[yocto] [yocto-docs][PATCH] kernel-dev: document the change detection of kernel feature files

2018-10-01 Thread Urs Fässler

Recommend to add recipe-space features to SRC_URI so that changes to them
are detected automatically.

Signed-off-by: Urs Fässler 
Signed-off-by: Pascal Bach 
---
 documentation/kernel-dev/kernel-dev-common.xml | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 83b02b1c1..6289ce8d4 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -2623,6 +2623,9 @@
 .scc file in the
 SRC_URI statement to reference multiple kernel
 features.
+Since BitBake only detects changes on files listed in
+SRC_URI, it is best to add all
+.cfg to SRC_URI.
 
 
 
@@ -2674,10 +2677,10 @@
 
 
 Add the Feature File to 
SRC_URI:
-Add the .scc file to the
+Add the .cfg and 
.scc file to the
 recipe's SRC_URI statement:
 
- SRC_URI_append = " file://test.scc"
+ SRC_URI_append = " file://test.cfg file://test.scc"
 
 The leading space before the path is important as the
 path is appended to the existing path.
-- 
2.19.0

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

[yocto] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am to 8:30am on the first Tuesday (PDT)

2018-10-01 Thread Jolley, Stephen K

All,

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am 
PDT tomorrow.  We will begin the YP 2.7 Planning effort at this time.

Yocto Project Technical Team Meeting: We encourage people attending the meeting 
to logon and announce themselves on the Yocto Project IRC chancel during the 
meeting (optional):
Yocto IRC: http://webchat.freenode.net/?channels=#yocto

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

WhenMonthly from 8am to 8:30am on the first Tuesday Pacific Time
Where   Zoom Meeting: https://zoom.us/j/990892712

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:  (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

[linux-yocto] [PATCH 09/10] work-simple: drop a shit statement in SWORK_EVENT_PENDING

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit 22f41ebe5579cc847a7bb6c71916be92c8926216 from linux-rt-devel.

Dan Carpenter reported
| smatch warnings:
|kernel/sched/swork.c:63 swork_kthread() warn: test_bit() takes a bit number

This is not a bug because we shift by zero (and use the same value in
both places).
Nevertheless I'm dropping that shift by zero to keep smatch quiet.

Cc: Daniel Wagner 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/sched/swork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/swork.c b/kernel/sched/swork.c
index 1950f40ca725..5559c22f664c 100644
--- a/kernel/sched/swork.c
+++ b/kernel/sched/swork.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#define SWORK_EVENT_PENDING (1 << 0)
+#define SWORK_EVENT_PENDING 1
 
 static DEFINE_MUTEX(worker_mutex);
 static struct sworker *glob_worker;
-- 
2.15.0

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

[linux-yocto] [PATCH 08/10] rcu: Use cpus_read_lock() while looking at cpu_online_mask

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit eb1987eef4f20ae92c21c50c4c75c6148a27d482 from linux-rt-devel.

It was possible that sync_rcu_exp_select_cpus() enqueued something on
CPU0 while CPU0 was offline. Such a work item wouldn't be processed
until CPU0 gets back online. This problem was addressed in commit
fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being offline"). I
don't think the issue fully addressed.

Assume grplo = 0 and grphi = 7 and sync_rcu_exp_select_cpus() is invoked
on CPU1. The preempt_disable() section on CPU1 won't ensure that CPU0
remains online between looking at cpu_online_mask and invoking
queue_work_on() on CPU1.

Use cpus_read_lock() to ensure that `cpu' is not going down between
looking at cpu_online_mask at invoking queue_work_on() and waiting for
its completion. It is added around the loop + flush_work() which is
similar to work_on_cpu_safe() (and we can have multiple jobs running on
NUMA systems).

Fixes: fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being
  offline")
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/rcu/tree_exp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 01b6ddeb4f05..a104cf91e6b9 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -479,6 +479,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
sync_exp_reset_tree(rsp);
trace_rcu_exp_grace_period(rsp->name, rcu_exp_gp_seq_endval(rsp), 
TPS("select"));
 
+   cpus_read_lock();
/* Schedule work for each leaf rcu_node structure. */
rcu_for_each_leaf_node(rsp, rnp) {
rnp->exp_need_flush = false;
@@ -493,13 +494,11 @@ static void sync_rcu_exp_select_cpus(struct rcu_state 
*rsp,
continue;
}
INIT_WORK(>rew.rew_work, sync_rcu_exp_select_node_cpus);
-   preempt_disable();
cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
/* If all offline, queue the work on an unbound CPU. */
if (unlikely(cpu > rnp->grphi))
cpu = WORK_CPU_UNBOUND;
queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
-   preempt_enable();
rnp->exp_need_flush = true;
}
 
@@ -507,6 +506,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
rcu_for_each_leaf_node(rsp, rnp)
if (rnp->exp_need_flush)
flush_work(>rew.rew_work);
+   cpus_read_unlock();
 }
 
 static void synchronize_sched_expedited_wait(struct rcu_state *rsp)
-- 
2.15.0

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

[linux-yocto] [PATCH 10/10] rt: bump localversion

2018-10-01 Thread Paul Gortmaker

We've added the equivalent updates from upstream in linux-rt-devel
as can be seen from this snippet of the commit history there:

  a7abcd43f6a7 (HEAD -> linux-4.18.y-rt, tag: v4.18.7-rt5, 
origin/linux-4.18.y-rt) v4.18.7-rt5
  22f41ebe5579 work-simple: drop a shit statement in SWORK_EVENT_PENDING
  eb1987eef4f2 rcu: Use cpus_read_lock() while looking at cpu_online_mask
  b75caf08b721 of: allocate / free phandle cache outside of the devtree_lock
  447cffcc7437 (tag: v4.18.7-rt4) v4.18.7-rt4
  a6dabcafaf68 Merge tag 'v4.18.7' into linux-4.18.y-rt
  ac0f534deae8 (tag: v4.18.5-rt3) v4.18.5-rt3
  b9fcc1867cc7 Drivers: hv: vmbus: include header for get_irq_regs()
  4a0819bb25d1 irqchip/gic-v3-its: Move pending table allocation to init time
  7bcb4eb241e3 powerpc: correct the preempt-lazy assembly
  3f1b0eab8fb3 staging: android: vsoc: use hrtimer_init_sleeper_on_stack()
  cd4d35ef8994 sched: Allow pinned user tasks to be awakened to the CPU they 
pinned
  5dd69ed1a24a (tag: v4.18.5-rt2) v4.18.5-rt2
  223076af168b Merge tag 'v4.18.5' into linux-4.18.y-rt
  ce25bc4adeb5 (tag: v4.18-rc8-rt1-rebase, tag: v4.18-rc8-rt1) Add localversion 
for -RT release

So bump the localversion to match.

Signed-off-by: Paul Gortmaker 
---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index 6f206be67cd2..0efe7ba1930e 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt1
+-rt5
-- 
2.15.0

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

[linux-yocto] [PATCH 04/10] irqchip/gic-v3-its: Move pending table allocation to init time

2018-10-01 Thread Paul Gortmaker

From: Marc Zyngier 

commit 4a0819bb25d12d39c0390636122eefba232596c1 from linux-rt-devel.

Signed-off-by: Marc Zyngier 
[bigeasy: backport commit effe377d415 ("irqchip/gic-v3-its: Move pending
  table allocation to init time")]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/irqchip/irq-gic-v3-its.c   | 94 +++---
 include/linux/irqchip/arm-gic-v3.h |  1 +
 2 files changed, 49 insertions(+), 46 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4bca2439ee7d..907e5c5169e9 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1556,7 +1556,7 @@ static void its_free_prop_table(struct page *prop_page)
   get_order(LPI_PROPBASE_SZ));
 }
 
-static int __init its_alloc_lpi_tables(void)
+static int __init its_alloc_lpi_prop_table(void)
 {
phys_addr_t paddr;
 
@@ -1854,17 +1854,15 @@ static int its_alloc_collections(struct its_node *its)
return 0;
 }
 
-static struct page *its_allocate_pending_table(unsigned int cpu)
+static struct page *its_allocate_pending_table(gfp_t gfp_flags)
 {
struct page *pend_page;
-   unsigned int order;
/*
 * The pending pages have to be at least 64kB aligned,
 * hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
 */
-   order = get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K));
-   pend_page = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL | __GFP_ZERO,
-order);
+   pend_page = alloc_pages(gfp_flags | __GFP_ZERO,
+   get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
if (!pend_page)
return NULL;
 
@@ -1880,25 +1878,31 @@ static void its_free_pending_table(struct page *pt)
   get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
 }
 
-static int its_alloc_pend_page(unsigned int cpu)
+static int __init allocate_lpi_tables(void)
 {
-   struct page *pend_page;
-   phys_addr_t paddr;
+   int err, cpu;
 
-   pend_page = gic_data_rdist_cpu(cpu)->pend_page;
-   if (pend_page)
-   return 0;
+   err = its_alloc_lpi_prop_table();
+   if (err)
+   return err;
 
-   pend_page = its_allocate_pending_table(cpu);
-   if (!pend_page) {
-   pr_err("Failed to allocate PENDBASE for CPU%d\n",
-  smp_processor_id());
-   return -ENOMEM;
+   /*
+* We allocate all the pending tables anyway, as we may have a
+* mix of RDs that have had LPIs enabled, and some that
+* don't. We'll free the unused ones as each CPU comes online.
+*/
+   for_each_possible_cpu(cpu) {
+   struct page *pend_page;
+
+   pend_page = its_allocate_pending_table(GFP_NOWAIT);
+   if (!pend_page) {
+   pr_err("Failed to allocate PENDBASE for CPU%d\n", cpu);
+   return -ENOMEM;
+   }
+
+   gic_data_rdist_cpu(cpu)->pend_page = pend_page;
}
 
-   paddr = page_to_phys(pend_page);
-   pr_info("CPU%d: using LPI pending table @%pa\n", cpu, );
-   gic_data_rdist_cpu(cpu)->pend_page = pend_page;
return 0;
 }
 
@@ -1906,13 +1910,15 @@ static void its_cpu_init_lpis(void)
 {
void __iomem *rbase = gic_data_rdist_rd_base();
struct page *pend_page;
+   phys_addr_t paddr;
u64 val, tmp;
 
-   /* If we didn't allocate the pending table yet, do it now */
-   pend_page = gic_data_rdist()->pend_page;
-   if (!pend_page)
+   if (gic_data_rdist()->lpi_enabled)
return;
 
+   pend_page = gic_data_rdist()->pend_page;
+   paddr = page_to_phys(pend_page);
+
/* set PROPBASE */
val = (page_to_phys(gic_rdists->prop_page) |
   GICR_PROPBASER_InnerShareable |
@@ -1964,6 +1970,10 @@ static void its_cpu_init_lpis(void)
 
/* Make sure the GIC has seen the above */
dsb(sy);
+   gic_data_rdist()->lpi_enabled = true;
+   pr_info("GICv3: CPU%d: using LPI pending table @%pa\n",
+   smp_processor_id(),
+   );
 }
 
 static void its_cpu_init_collection(struct its_node *its)
@@ -2744,7 +2754,7 @@ static int its_vpe_init(struct its_vpe *vpe)
return vpe_id;
 
/* Allocate VPT */
-   vpt_page = its_allocate_pending_table(raw_smp_processor_id());
+   vpt_page = its_allocate_pending_table(GFP_KERNEL);
if (!vpt_page) {
its_vpe_id_free(vpe_id);
return -ENOMEM;
@@ -3439,16 +3449,6 @@ static int redist_disable_lpis(void)
u64 timeout = USEC_PER_SEC;
u64 val;
 
-   /*
-* If coming via a CPU hotplug event, we don't need to disable
-* LPIs before trying to re-enable them. They are already
-* configured and all is well in the world. Detect this

[linux-yocto] [PATCH 03/10] powerpc: correct the preempt-lazy assembly

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit 7bcb4eb241e37d111cbca61a86ea0da180a6f2b3 from linux-rt-devel.

The powerpc port won't compile and abort with "Error: operand out of
range" because the TIF_NEED_RESCHED_LAZY uses bit 20 which is larger
than 15 which is the upper limit.
Swap it with TIF_32BIT and fixup the assembly in one assembly file to
get it to compile again.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 arch/powerpc/include/asm/thread_info.h | 4 ++--
 arch/powerpc/kernel/entry_64.S | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index 431759836861..15c2c0925b6c 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -82,7 +82,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, 
struct task_struct *src
 #define TIF_SIGPENDING 1   /* signal pending */
 #define TIF_NEED_RESCHED   2   /* rescheduling necessary */
 #define TIF_FSCHECK3   /* Check FS is USER_DS on return */
-#define TIF_32BIT  4   /* 32 bit binary */
+#define TIF_NEED_RESCHED_LAZY  4   /* lazy rescheduling necessary */
 #define TIF_RESTORE_TM 5   /* need to restore TM FP/VEC/VSX */
 #define TIF_PATCH_PENDING  6   /* pending live patching update */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
@@ -101,7 +101,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, 
struct task_struct *src
 #define TIF_ELF2ABI18  /* function descriptors must die! */
 #endif
 #define TIF_POLLING_NRFLAG 19  /* true if poll_idle() is polling 
TIF_NEED_RESCHED */
-#define TIF_NEED_RESCHED_LAZY  20   /* lazy rescheduling necessary */
+#define TIF_32BIT  20  /* 32 bit binary */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1

[linux-yocto] [PATCH 06/10] of: allocate / free phandle cache outside of the devtree_lock

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit b75caf08b721aee6f0aec7350b2136ff1e704337 from linux-rt-devel.

The phandle cache code allocates memory while holding devtree_lock which
is a raw_spinlock_t. Memory allocation (and free()) is not possible on
RT while a raw_spinlock_t is held.
Invoke the kfree() and kcalloc() while the lock is dropped.

Cc: Rob Herring 
Cc: Frank Rowand 
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/of/base.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 466e3c8582f0..7394d9dcc2a1 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -108,43 +108,49 @@ void of_populate_phandle_cache(void)
u32 cache_entries;
struct device_node *np;
u32 phandles = 0;
+   struct device_node **shadow;
 
raw_spin_lock_irqsave(_lock, flags);
-
-   kfree(phandle_cache);
+   shadow = phandle_cache;
phandle_cache = NULL;
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandles++;
 
+   raw_spin_unlock_irqrestore(_lock, flags);
+
cache_entries = roundup_pow_of_two(phandles);
phandle_cache_mask = cache_entries - 1;
 
-   phandle_cache = kcalloc(cache_entries, sizeof(*phandle_cache),
-   GFP_ATOMIC);
-   if (!phandle_cache)
-   goto out;
+   kfree(shadow);
+   shadow = kcalloc(cache_entries, sizeof(*phandle_cache), GFP_KERNEL);
+
+   if (!shadow)
+   return;
+   raw_spin_lock_irqsave(_lock, flags);
+   phandle_cache = shadow;
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandle_cache[np->phandle & phandle_cache_mask] = np;
 
-out:
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 int of_free_phandle_cache(void)
 {
unsigned long flags;
+   struct device_node **shadow;
 
raw_spin_lock_irqsave(_lock, flags);
 
-   kfree(phandle_cache);
+   shadow = phandle_cache;
phandle_cache = NULL;
 
raw_spin_unlock_irqrestore(_lock, flags);
 
+   kfree(shadow);
return 0;
 }
 #if !defined(CONFIG_MODULES)
-- 
2.15.0

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

[linux-yocto] [PATCH 05/10] Drivers: hv: vmbus: include header for get_irq_regs()

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit b9fcc1867cc7921bb8441be327ed58461ed12255 from linux-rt-devel.

On !RT the header file get_irq_regs() gets pulled in via other header files. On
RT it does not and the build fails:

drivers/hv/vmbus_drv.c:975 implicit declaration of function ‘get_irq_regs’ 
[-Werror=implicit-function-declaration]
drivers/hv/hv.c:115 implicit declaration of function ‘get_irq_regs’ 
[-Werror=implicit-function-declaration]

Add the header file for get_irq_regs() in a common header so it used by
vmbus_drv.c by hv.c for their get_irq_regs() usage.

Reported-by: Bernhard Landauer 
Reported-by: Ralf Ramsauer 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/hv/hyperv_vmbus.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3d50fc..797f07918197 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hv_trace.h"
 
-- 
2.15.0

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

[linux-yocto] [PATCH 02/10] staging: android: vsoc: use hrtimer_init_sleeper_on_stack()

2018-10-01 Thread Paul Gortmaker

From: Sebastian Andrzej Siewior 

commit 3f1b0eab8fb3d592ae2da62a62b0522b365781e0 from linux-rt-devel.

This is an update to v2 of "hrtimer: consolidate hrtimer_init() +
hrtimer_init_sleeper() calls" which also converts
hrtimer_init_on_stack() + hrtimer_init_sleeper() in the vsoc.c driver.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/staging/android/vsoc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 806beda1040b..6c7f666c0e33 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -438,12 +438,10 @@ static int handle_vsoc_cond_wait(struct file *filp, 
struct vsoc_cond_wait *arg)
 
if (!timespec_valid())
return -EINVAL;
-   hrtimer_init_on_stack(>timer, CLOCK_MONOTONIC,
- HRTIMER_MODE_ABS);
+   hrtimer_init_sleeper_on_stack(to, CLOCK_MONOTONIC,
+ HRTIMER_MODE_ABS, current);
hrtimer_set_expires_range_ns(>timer, timespec_to_ktime(ts),
 current->timer_slack_ns);
-
-   hrtimer_init_sleeper(to, current);
}
 
while (1) {
-- 
2.15.0

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

[linux-yocto] [PATCH 4.18-rt 00/10] upstream updates rt1 --> rt5

2018-10-01 Thread Paul Gortmaker

Bruce, Yocto kernel folks,

Here are the preempt-rt updates applied to the 4.18 yocto kernel.
A couple of the version bumps were just merges of the latest stable
tag from GregKH, and no preempt-rt specific changes.  The details
of the updates that did have -rt specific content are listed below:

rt3: https://marc.info/?l=linux-rt-users=153561780819025=2

rt5: https://marc.info/?l=linux-rt-users=153665816630557=2

These patches were applied onto the current Yocto 4.18 preempt-rt
base branch and sanity boot tested on x86-64 defconfig + RT_FULL.

One RCU patch is from mainline directly, and also found backported
in newer 4.18.x stable tags than we are currently running, as it
was a prerequisite for the RCU change in the preempt-rt updates.

Paul.
---

Boqun Feng (1):
  rcu: Make expedited GPs handle CPU 0 being offline

Marc Zyngier (1):
  irqchip/gic-v3-its: Move pending table allocation to init time

Mike Galbraith (1):
  sched: Allow pinned user tasks to be awakened to the CPU they pinned

Paul Gortmaker (1):
  rt: bump localversion

Sebastian Andrzej Siewior (6):
  staging: android: vsoc: use hrtimer_init_sleeper_on_stack()
  powerpc: correct the preempt-lazy assembly
  Drivers: hv: vmbus: include header for get_irq_regs()
  of: allocate / free phandle cache outside of the devtree_lock
  rcu: Use cpus_read_lock() while looking at cpu_online_mask
  work-simple: drop a shit statement in SWORK_EVENT_PENDING

 arch/powerpc/include/asm/thread_info.h |  4 +-
 arch/powerpc/kernel/entry_64.S |  2 +-
 drivers/hv/hyperv_vmbus.h  |  1 +
 drivers/irqchip/irq-gic-v3-its.c   | 94 +-
 drivers/of/base.c  | 22 +---
 drivers/staging/android/vsoc.c |  6 +--
 include/linux/irqchip/arm-gic-v3.h |  1 +
 kernel/rcu/tree_exp.h  |  9 +++-
 kernel/sched/core.c|  2 +-
 kernel/sched/swork.c   |  2 +-
 localversion-rt|  2 +-
 11 files changed, 80 insertions(+), 65 deletions(-)

-- 
2.15.0

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

[linux-yocto] [PATCH 01/10] sched: Allow pinned user tasks to be awakened to the CPU they pinned

2018-10-01 Thread Paul Gortmaker

From: Mike Galbraith 

commit cd4d35ef89948221f7cd1751cee453943967364c from linux-rt-devel.

Since commit 7af443ee16976 ("sched/core: Require cpu_active() in
select_task_rq(), for user tasks") select_fallback_rq() will BUG() if
the CPU to which a task has pinned itself and pinned becomes
!cpu_active() while it slept.
The task will continue running on the to-be-removed CPU and will remove
itself from the CPU during takedown_cpu() (while cpuhp_pin_lock will be
acquired) and move to another CPU based on its mask after the
migrate_disable() section has been left.

Cc: stable...@vger.kernel.org
Signed-off-by: Mike Galbraith 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 530118fbfe21..7d789c1b316b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -968,7 +968,7 @@ static inline bool is_cpu_allowed(struct task_struct *p, 
int cpu)
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
return false;
 
-   if (is_per_cpu_kthread(p))
+   if (is_per_cpu_kthread(p) || __migrate_disabled(p))
return cpu_online(cpu);
 
return cpu_active(cpu);
-- 
2.15.0

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

[yocto] Yocto Project Unassigned Bugs - Help Needed

2018-10-01 Thread Jolley, Stephen K

All,



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



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly five different "priority" classes right now, "2.6", 
"2.7", "2.8", "2.99" and "Future", the more pressing/urgent issues being in 
"2.6" and then "2.7".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me 
(stephen.k.jol...@intel.com) an e-mail with 
the bug number you would like and I will assign it to you (please make sure you 
have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [yocto] upgrading packages in yocto

2018-10-01 Thread Guilhem Marion


Hello,


On 01/10/2018 08:21, Pandey, Kamal wrote:

I want to upgrade some packages of poky/meta/recipes-graphics/ like 
weston_2.0.0.bb to weston_4.0.0.bb. Also I don't want any changes to be made in 
poky/meta layer. What is the best way of doing these kinds of upgradations. I 
think bbappend here will create problems as the SRC_URI and other variables use 
the PV from recipe name to fulfil some operations.
The other thing I can do is create a weston_4.0.0.bb file in my own custom 
layer and work but then I don't know how to disable the older(original) 
weston_2.0.0.bb file.
What will be the best method to upgrade packages. One thing to remind you that 
the SRC_URI is not a repository , it's a tarball repo. So I directly can't 
replace the SRC_URI in .bbappend file.
Any leads regarding this will be appreciated.
You should look at layer priorities: 
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BBFILE_PRIORITY


If you can set your layer to take precedence (higher priority) over 
poky/meta, your weston_4.0.0.bb will be picked over poky/meta's


-Original Message-
From: yocto-boun...@yoctoproject.org  On Behalf 
Of yocto-requ...@yoctoproject.org
Sent: 30 September 2018 00:30
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 96, Issue 79

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nHa2EM0=B4t2KSJ3IM1b9sK9gvCmTFe5JX-rxgD15fYh5lG11MM=Zi9dlMz5JoZfKdwcbr7eV_JK7qB8SJTPYP9LdRWnlG8=RQp-3-7SeXpR_ysQqD1qg5XYb2ycNNJlz5k63RsTovE=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Hope this helped,
Cheers,

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

Re: [yocto] upgrading packages in yocto

2018-10-01 Thread Nicolas Dechesne

On Mon, Oct 1, 2018 at 8:22 AM Pandey, Kamal  wrote:
>
> I want to upgrade some packages of poky/meta/recipes-graphics/ like 
> weston_2.0.0.bb to weston_4.0.0.bb. Also I don't want any changes to be made 
> in poky/meta layer. What is the best way of doing these kinds of 
> upgradations. I think bbappend here will create problems as the SRC_URI and 
> other variables use the PV from recipe name to fulfil some operations.
> The other thing I can do is create a weston_4.0.0.bb file in my own custom 
> layer and work but then I don't know how to disable the older(original) 
> weston_2.0.0.bb file.
> What will be the best method to upgrade packages. One thing to remind you 
> that the SRC_URI is not a repository , it's a tarball repo. So I directly 
> can't replace the SRC_URI in .bbappend file.
> Any leads regarding this will be appreciated.

You should get a new custom layer that holds the 4.0 recipe. It is a
bad idea to use a .bbappend since you are changing the version ($PV).
Note that upgrading one recipe might require that you update some
dependencies as well. You don't need to 'disable' the old recipe, it
will be overlaid anyways.

To give you an idea, this is how we manage 'backports' for our builds:
https://git.linaro.org/openembedded/meta-backports.git

>
> -Original Message-
> From: yocto-boun...@yoctoproject.org  On 
> Behalf Of yocto-requ...@yoctoproject.org
> Sent: 30 September 2018 00:30
> To: yocto@yoctoproject.org
> Subject: yocto Digest, Vol 96, Issue 79
>
> Send yocto mailing list submissions to
> yocto@yoctoproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nHa2EM0=B4t2KSJ3IM1b9sK9gvCmTFe5JX-rxgD15fYh5lG11MM=Zi9dlMz5JoZfKdwcbr7eV_JK7qB8SJTPYP9LdRWnlG8=RQp-3-7SeXpR_ysQqD1qg5XYb2ycNNJlz5k63RsTovE=
> or, via email, send a message with subject or body 'help' to
> yocto-requ...@yoctoproject.org
>
> You can reach the person managing the list at
> yocto-ow...@yoctoproject.org
>
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of yocto digest..."
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] upgrading packages in yocto

2018-10-01 Thread Pandey, Kamal

I want to upgrade some packages of poky/meta/recipes-graphics/ like 
weston_2.0.0.bb to weston_4.0.0.bb. Also I don't want any changes to be made in 
poky/meta layer. What is the best way of doing these kinds of upgradations. I 
think bbappend here will create problems as the SRC_URI and other variables use 
the PV from recipe name to fulfil some operations.
The other thing I can do is create a weston_4.0.0.bb file in my own custom 
layer and work but then I don't know how to disable the older(original) 
weston_2.0.0.bb file.
What will be the best method to upgrade packages. One thing to remind you that 
the SRC_URI is not a repository , it's a tarball repo. So I directly can't 
replace the SRC_URI in .bbappend file.
Any leads regarding this will be appreciated.

-Original Message-
From: yocto-boun...@yoctoproject.org  On Behalf 
Of yocto-requ...@yoctoproject.org
Sent: 30 September 2018 00:30
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 96, Issue 79

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nHa2EM0=B4t2KSJ3IM1b9sK9gvCmTFe5JX-rxgD15fYh5lG11MM=Zi9dlMz5JoZfKdwcbr7eV_JK7qB8SJTPYP9LdRWnlG8=RQp-3-7SeXpR_ysQqD1qg5XYb2ycNNJlz5k63RsTovE=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."

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

[yocto] Custom image type with dependencies

Re: [yocto] [PATCH] runtime: add BSP test case for usb storage

[yocto] [layerindex-web][PATCH] Fix broken regex for recipes with names containing + signs

[yocto] [yocto-docs][PATCH] kernel-dev: document the change detection of kernel feature files

[yocto] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am to 8:30am on the first Tuesday (PDT)

[linux-yocto] [PATCH 09/10] work-simple: drop a shit statement in SWORK_EVENT_PENDING

[linux-yocto] [PATCH 08/10] rcu: Use cpus_read_lock() while looking at cpu_online_mask

[linux-yocto] [PATCH 10/10] rt: bump localversion

[linux-yocto] [PATCH 04/10] irqchip/gic-v3-its: Move pending table allocation to init time

[linux-yocto] [PATCH 03/10] powerpc: correct the preempt-lazy assembly

[linux-yocto] [PATCH 06/10] of: allocate / free phandle cache outside of the devtree_lock

[linux-yocto] [PATCH 05/10] Drivers: hv: vmbus: include header for get_irq_regs()

[linux-yocto] [PATCH 02/10] staging: android: vsoc: use hrtimer_init_sleeper_on_stack()

[linux-yocto] [PATCH 4.18-rt 00/10] upstream updates rt1 --> rt5

[linux-yocto] [PATCH 01/10] sched: Allow pinned user tasks to be awakened to the CPU they pinned

[yocto] Yocto Project Unassigned Bugs - Help Needed

Re: [yocto] upgrading packages in yocto

Re: [yocto] upgrading packages in yocto

[yocto] upgrading packages in yocto

19 matches

Site Navigation

Mail list logo

Footer information