from:"Xu, Yanfei"

Re: [linux-yocto] Warning in compiling linux-yocto 5.10

2021-11-16 Thread Xu, Yanfei




On 11/17/21 4:02 AM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Tue, Nov 16, 2021 at 11:03 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:


On Tue, Nov 16, 2021 at 1:13 AM Xu, Yanfei  wrote:




On 11/16/21 11:48 AM, Bruce Ashfield wrote:

Hi Bruce,

We encountered a warning when compiling linux-yocto 5.10 in WRlinux on
our tester's server machine. After doing some search, I found yocto also
encountered this some years
ago.[https://patchwork.openembedded.org/patch/152442/] Maybe yocto also
have this warning now? I can't figure out why this warning is introduced...

Looks like a missing depends, triggered by one of the new options.

Leave it with me, and I'll have a look at it on Monday.

Which MACHINE was triggering that working ? I have seen it in the


Our tester also trigger it with qemux86-64.


past (as the mailing list archives show), but i just did a qemux86-64
and I don't see it in the current native or on-target build of 5.15:

HOSTCC  arch/x86/tools/relocs_64.o
HOSTCC  arch/x86/tools/relocs_common.o
UPD include/generated/uapi/linux/version.h
UPD include/generated/utsrelease.h
HOSTCC  scripts/kallsyms
HOSTCC  scripts/sorttable

(or in my archived 5.14/5.10 builds).


Only on v5.10, v5.15 is all right.


I have this  "fixed", but we don't actually want the fix .. unless you
like very slow compiles.

The issue is with pkgconfig not picking up the elfutils in the native
sysroot. I have it fixed, but a clean build that normally takes
7minutes on a slow machine has now been building for 26+ minutes with
the stack protection enabled.

Which means, I'll need two changes. One to make it something we can
enable, and then some meta-data fixes to disable it :D



Attached is the WIP patch that removes the warning here, and provides
a way to disable the extra build overhead if someone really wants to.


Nice! But I have an extra question, will this be merged in oe-core 
upstream? I didn't find it in oe-core mailing list or in repo.


Thanks,
Yanfei



Bruce


Bruce



Regards,
Yanfei



I am seeing SSL 3.0 warnings, but that is a different question :D

Bruce






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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10669): 
https://lists.yoctoproject.org/g/linux-yocto/message/10669
Mute This Topic: https://lists.yoctoproject.org/mt/87061463/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] Warning in compiling linux-yocto 5.10

2021-11-15 Thread Xu, Yanfei




On 11/16/21 11:48 AM, Bruce Ashfield wrote:

Hi Bruce,

We encountered a warning when compiling linux-yocto 5.10 in WRlinux on
our tester's server machine. After doing some search, I found yocto also
encountered this some years
ago.[https://patchwork.openembedded.org/patch/152442/] Maybe yocto also
have this warning now? I can't figure out why this warning is introduced...

Looks like a missing depends, triggered by one of the new options.

Leave it with me, and I'll have a look at it on Monday.

Which MACHINE was triggering that working ? I have seen it in the


Our tester also trigger it with qemux86-64.


past (as the mailing list archives show), but i just did a qemux86-64
and I don't see it in the current native or on-target build of 5.15:

   HOSTCC  arch/x86/tools/relocs_64.o
   HOSTCC  arch/x86/tools/relocs_common.o
   UPD include/generated/uapi/linux/version.h
   UPD include/generated/utsrelease.h
   HOSTCC  scripts/kallsyms
   HOSTCC  scripts/sorttable

(or in my archived 5.14/5.10 builds).


Only on v5.10, v5.15 is all right.

Regards,
Yanfei



I am seeing SSL 3.0 warnings, but that is a different question :D

Bruce



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10664): 
https://lists.yoctoproject.org/g/linux-yocto/message/10664
Mute This Topic: https://lists.yoctoproject.org/mt/87061463/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] Warning in compiling linux-yocto 5.10

2021-11-14 Thread Xu, Yanfei




On 11/15/21 11:19 AM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Sun, Nov 14, 2021 at 9:21 PM Xu, Yanfei  wrote:


Hi Bruce,

We encountered a warning when compiling linux-yocto 5.10 in WRlinux on
our tester's server machine. After doing some search, I found yocto also
encountered this some years
ago.[https://patchwork.openembedded.org/patch/152442/] Maybe yocto also
have this warning now? I can't figure out why this warning is introduced...


Looks like a missing depends, triggered by one of the new options.

Leave it with me, and I'll have a look at it on Monday.


Thanks~

Yanfei



Bruce



The Warning is from log.do_compile:
WRAParch/x86/include/generated/uapi/asm/ipcbuf.h
WRAParch/x86/include/generated/uapi/asm/ioctls.h
WRAParch/x86/include/generated/uapi/asm/param.h
WRAParch/x86/include/generated/uapi/asm/poll.h
WRAParch/x86/include/generated/uapi/asm/resource.h
WRAParch/x86/include/generated/uapi/asm/socket.h
WRAParch/x86/include/generated/uapi/asm/sockios.h
WRAParch/x86/include/generated/uapi/asm/termios.h
WRAParch/x86/include/generated/uapi/asm/termbits.h
WRAParch/x86/include/generated/uapi/asm/types.h
HOSTCC  arch/x86/tools/relocs_32.o
HOSTCC  arch/x86/tools/relocs_64.o
HOSTCC  arch/x86/tools/relocs_common.o
WRAParch/x86/include/generated/asm/early_ioremap.h
WRAParch/x86/include/generated/asm/export.h
WRAParch/x86/include/generated/asm/mcs_spinlock.h
WRAParch/x86/include/generated/asm/irq_regs.h
WRAParch/x86/include/generated/asm/local64.h
WRAParch/x86/include/generated/asm/mm-arch-hooks.h
WRAParch/x86/include/generated/asm/mmiowb.h
WRAParch/x86/include/generated/asm/module.lds.h
WRAParch/x86/include/generated/asm/rwonce.h
UPD include/config/kernel.release
UPD include/generated/uapi/linux/version.h
HOSTCC  scripts/recordmcount
HOSTCC  scripts/kallsyms
HOSTCC  scripts/sorttable
HOSTCC  scripts/asn1_compiler
UPD include/generated/utsrelease.h
warning: Cannot use CONFIG_STACK_VALIDATION=y, please install
libelf-dev, libelf-devel or elfutils-libelf-devel
HOSTCC  scripts/extract-cert
HOSTLD  arch/x86/tools/relocs


Thanks,
Yanfei




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10650): 
https://lists.yoctoproject.org/g/linux-yocto/message/10650
Mute This Topic: https://lists.yoctoproject.org/mt/87061463/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] Warning in compiling linux-yocto 5.10

2021-11-14 Thread Xu, Yanfei


Hi Bruce,

We encountered a warning when compiling linux-yocto 5.10 in WRlinux on 
our tester's server machine. After doing some search, I found yocto also 
encountered this some years 
ago.[https://patchwork.openembedded.org/patch/152442/] Maybe yocto also 
have this warning now? I can't figure out why this warning is introduced...


The Warning is from log.do_compile:
  WRAParch/x86/include/generated/uapi/asm/ipcbuf.h
  WRAParch/x86/include/generated/uapi/asm/ioctls.h
  WRAParch/x86/include/generated/uapi/asm/param.h
  WRAParch/x86/include/generated/uapi/asm/poll.h
  WRAParch/x86/include/generated/uapi/asm/resource.h
  WRAParch/x86/include/generated/uapi/asm/socket.h
  WRAParch/x86/include/generated/uapi/asm/sockios.h
  WRAParch/x86/include/generated/uapi/asm/termios.h
  WRAParch/x86/include/generated/uapi/asm/termbits.h
  WRAParch/x86/include/generated/uapi/asm/types.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  WRAParch/x86/include/generated/asm/early_ioremap.h
  WRAParch/x86/include/generated/asm/export.h
  WRAParch/x86/include/generated/asm/mcs_spinlock.h
  WRAParch/x86/include/generated/asm/irq_regs.h
  WRAParch/x86/include/generated/asm/local64.h
  WRAParch/x86/include/generated/asm/mm-arch-hooks.h
  WRAParch/x86/include/generated/asm/mmiowb.h
  WRAParch/x86/include/generated/asm/module.lds.h
  WRAParch/x86/include/generated/asm/rwonce.h
  UPD include/config/kernel.release
  UPD include/generated/uapi/linux/version.h
  HOSTCC  scripts/recordmcount
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/sorttable
  HOSTCC  scripts/asn1_compiler
  UPD include/generated/utsrelease.h
warning: Cannot use CONFIG_STACK_VALIDATION=y, please install 
libelf-dev, libelf-devel or elfutils-libelf-devel

  HOSTCC  scripts/extract-cert
  HOSTLD  arch/x86/tools/relocs


Thanks,
Yanfei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10648): 
https://lists.yoctoproject.org/g/linux-yocto/message/10648
Mute This Topic: https://lists.yoctoproject.org/mt/87061463/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.10/standard/base][PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-10-21 Thread Xu, Yanfei




On 10/21/21 9:41 AM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

In message: [linux-yocto][v5.10/standard/base][PATCH] iommu/arm-smmu-v3: 
Ratelimit event dump
on 20/10/2021 Yanfei Xu wrote:


From: Jean-Philippe Brucker 

When a device or driver misbehaves, it is possible to receive DMA fault
events much faster than we can print them out, causing a lock up of the
system and inability to cancel the source of the problem. Ratelimit
printing of events to help recovery.

Tested-by: Aaro Koskinen 
Signed-off-by: Jean-Philippe Brucker 
Link: https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org


Has this also been proposed for -stable inclusion ?


This patch is not backported in -stable, just for linux-yocto.

Regards,
Yanfei


I've merged this regardless .. I'm just trying to determine if I
should expect a conflict in the future.

Bruce


Signed-off-by: Will Deacon 

Back ported for 5.10
Signed-off-by: Yanfei Xu 
---
  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7067b7c11626..75ce920c1a30 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1358,11 +1358,16 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void 
*dev)
   struct arm_smmu_queue *q = >evtq.q;
   struct arm_smmu_ll_queue *llq = >llq;
   u64 evt[EVTQ_ENT_DWORDS];
+ static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
+   DEFAULT_RATELIMIT_BURST);

   do {
   while (!queue_remove_raw(q, evt)) {
   u8 id = FIELD_GET(EVTQ_0_ID, evt[0]);

+ if (!__ratelimit())
+ continue;
+
   dev_info(smmu->dev, "event 0x%02x received:\n", id);
   for (i = 0; i < ARRAY_SIZE(evt); ++i)
   dev_info(smmu->dev, "\t0x%016llx\n",
--
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10568): 
https://lists.yoctoproject.org/g/linux-yocto/message/10568
Mute This Topic: https://lists.yoctoproject.org/mt/86460058/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-10-20 Thread Xu, Yanfei

From: Jean-Philippe Brucker 

When a device or driver misbehaves, it is possible to receive DMA fault
events much faster than we can print them out, causing a lock up of the
system and inability to cancel the source of the problem. Ratelimit
printing of events to help recovery.

Tested-by: Aaro Koskinen 
Signed-off-by: Jean-Philippe Brucker 
Link: https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org
Signed-off-by: Will Deacon 

Back ported for 5.10
Signed-off-by: Yanfei Xu 
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7067b7c11626..75ce920c1a30 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1358,11 +1358,16 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void 
*dev)
struct arm_smmu_queue *q = >evtq.q;
struct arm_smmu_ll_queue *llq = >llq;
u64 evt[EVTQ_ENT_DWORDS];
+   static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
 
do {
while (!queue_remove_raw(q, evt)) {
u8 id = FIELD_GET(EVTQ_0_ID, evt[0]);
 
+   if (!__ratelimit())
+   continue;
+
dev_info(smmu->dev, "event 0x%02x received:\n", id);
for (i = 0; i < ARRAY_SIZE(evt); ++i)
dev_info(smmu->dev, "\t0x%016llx\n",
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10554): 
https://lists.yoctoproject.org/g/linux-yocto/message/10554
Mute This Topic: https://lists.yoctoproject.org/mt/86460058/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10/standard/preempt-rt/base][PATCH] cgroup/cpuset: use raw_spin_lock/unlock for accessing callback_lock

2021-09-29 Thread Xu, Yanfei




On 9/29/21 8:55 PM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Wed, Sep 29, 2021 at 5:31 AM Xu, Yanfei  wrote:




On 9/28/21 9:28 PM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

I had done the same fix last Tuesday for 5.14, and hadn't gotten
around to cherry picking it yet:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.14/standard/preempt-rt/base=7630ebb9fd510cf7aa31b6f1dd472f3b0442afb3

So I've grabbed that 5.14 change I made, and I'm now up and test booting.

Thanks for the fix!


OK,thanks! And could you please help to put this patch to other bsp
branch which base on v5.10/standard/preempt-rt/base. The bsp branches
also have this compile failure.



I was still doing some final testing, but everything looks reasonable
now, so it is pushed.



Great! I saw that.

Cheers,
Yanfei



Bruce


Regards,
Yanfei



Bruce







--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10498): 
https://lists.yoctoproject.org/g/linux-yocto/message/10498
Mute This Topic: https://lists.yoctoproject.org/mt/85919622/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10/standard/preempt-rt/base][PATCH] cgroup/cpuset: use raw_spin_lock/unlock for accessing callback_lock

2021-09-29 Thread Xu, Yanfei




On 9/28/21 9:28 PM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

I had done the same fix last Tuesday for 5.14, and hadn't gotten
around to cherry picking it yet:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.14/standard/preempt-rt/base=7630ebb9fd510cf7aa31b6f1dd472f3b0442afb3

So I've grabbed that 5.14 change I made, and I'm now up and test booting.

Thanks for the fix!


OK,thanks! And could you please help to put this patch to other bsp 
branch which base on v5.10/standard/preempt-rt/base. The bsp branches 
also have this compile failure.


Regards,
Yanfei



Bruce

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10484): 
https://lists.yoctoproject.org/g/linux-yocto/message/10484
Mute This Topic: https://lists.yoctoproject.org/mt/85919622/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.10/standard/preempt-rt/base][PATCH] cgroup/cpuset: use raw_spin_lock/unlock for accessing callback_lock

2021-09-28 Thread Xu, Yanfei

Since the commit a653b0f0ab79 ("cpuset: Convert callback_lock to
raw_spinlock_t") has changed the lock type of callbak_lock to
raw_spinlock_t, we should use raw_spin_lock/unlock funciton for
accessing it.

Fixes: 10dfcfda5c6f ("cgroup/cpuset: Fix violation of cpuset locking rule")
Signed-off-by: Yanfei Xu 
---
 kernel/cgroup/cpuset.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 94e29d3e86f6..2c27d80ac59f 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2020,9 +2020,9 @@ static int update_prstate(struct cpuset *cs, int new_prs)
rebuild_sched_domains_locked();
 out:
if (!err) {
-   spin_lock_irq(_lock);
+   raw_spin_lock_irq(_lock);
cs->partition_root_state = new_prs;
-   spin_unlock_irq(_lock);
+   raw_spin_unlock_irq(_lock);
}
 
free_cpumasks(NULL, );
@@ -3088,10 +3088,10 @@ static void cpuset_hotplug_update_tasks(struct cpuset 
*cs, struct tmpmasks *tmp)
if (is_partition_root(cs) && (cpumask_empty(_cpus) ||
   (parent->partition_root_state == PRS_ERROR))) {
if (cs->nr_subparts_cpus) {
-   spin_lock_irq(_lock);
+   raw_spin_lock_irq(_lock);
cs->nr_subparts_cpus = 0;
cpumask_clear(cs->subparts_cpus);
-   spin_unlock_irq(_lock);
+   raw_spin_unlock_irq(_lock);
compute_effective_cpumask(_cpus, cs, parent);
}
 
@@ -3105,9 +3105,9 @@ static void cpuset_hotplug_update_tasks(struct cpuset 
*cs, struct tmpmasks *tmp)
 cpumask_empty(_cpus)) {
update_parent_subparts_cpumask(cs, partcmd_disable,
   NULL, tmp);
-   spin_lock_irq(_lock);
+   raw_spin_lock_irq(_lock);
cs->partition_root_state = PRS_ERROR;
-   spin_unlock_irq(_lock);
+   raw_spin_unlock_irq(_lock);
}
cpuset_force_rebuild();
}
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10471): 
https://lists.yoctoproject.org/g/linux-yocto/message/10471
Mute This Topic: https://lists.yoctoproject.org/mt/85919622/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.10/standard/base][PATCH] OF: DT-Overlay configfs interface (v7)

2021-08-17 Thread Xu, Yanfei

From: Pantelis Antoniou 

commit  ba900332d141bf2d1d3b6aa7da8f01fe4b9fb256 from
https://github.com/altera-opensource/linux-socfpga.git

Add a runtime interface to using configfs for generic device tree overlay
usage. With it its possible to use device tree overlays without having
to use a per-platform overlay manager.

Please see Documentation/devicetree/configfs-overlays.txt for more info.

Changes since v6:
- Default groups properties API changed.

Changes since v5:
- New style configfs.

Changes since v4:
- Loading fix for multiple overlays as found out by
  Geert Uytterhoeven 

Changes since v3:
- Fixed compilation on SPARC & Xtensa

Changes since v2:
- Removed ifdef CONFIG_OF_OVERLAY (since for now it's required)
- Created a documentation entry
- Slight rewording in Kconfig

Changes since v1:
- of_resolve() -> of_resolve_phandles().

Signed-off-by: Pantelis Antoniou 
[geert: Use %zu to format size_t]
[geert: Rebase to v4.15-rc1]
[geert: Make cfs_overlay_item_dtbo_{read,write}() and
of_cfs_overlay_group static]
[geert: Let OF_CONFIGFS select OF_FLATTREE to fix sparc all*config]
[geert: Spelling/grammar s/rationalle of/rationale for/]
[geert: Rebase on top of commit 39a751a4cb7e4798 ("of: change overlay apply 
input data from unflattened to FDT")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Meng Li 
Signed-off-by: Yanfei Xu 
---
 .../devicetree/configfs-overlays.txt  |  31 ++
 drivers/of/Kconfig|   8 +
 drivers/of/Makefile   |   1 +
 drivers/of/configfs.c | 284 ++
 4 files changed, 324 insertions(+)
 create mode 100644 Documentation/devicetree/configfs-overlays.txt
 create mode 100644 drivers/of/configfs.c

diff --git a/Documentation/devicetree/configfs-overlays.txt 
b/Documentation/devicetree/configfs-overlays.txt
new file mode 100644
index ..185d85ef52e4
--- /dev/null
+++ b/Documentation/devicetree/configfs-overlays.txt
@@ -0,0 +1,31 @@
+Howto use the configfs overlay interface.
+
+A device-tree configfs entry is created in /config/device-tree/overlays
+and and it is manipulated using standard file system I/O.
+Note that this is a debug level interface, for use by developers and
+not necessarily something accessed by normal users due to the
+security implications of having direct access to the kernel's device tree.
+
+* To create an overlay you mkdir the directory:
+
+   # mkdir /config/device-tree/overlays/foo
+
+* Either you echo the overlay firmware file to the path property file.
+
+   # echo foo.dtbo >/config/device-tree/overlays/foo/path
+
+* Or you cat the contents of the overlay to the dtbo file
+
+   # cat foo.dtbo >/config/device-tree/overlays/foo/dtbo
+
+The overlay file will be applied, and devices will be created/destroyed
+as required.
+
+To remove it simply rmdir the directory.
+
+   # rmdir /config/device-tree/overlays/foo
+
+The rationale for the dual interface (firmware & direct copy) is that each is
+better suited to different use patterns. The firmware interface is what's
+intended to be used by hardware managers in the kernel, while the copy 
interface
+make sense for developers (since it avoids problems with namespaces).
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 37c2ccbefecd..0968b8da9f36 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -100,6 +100,14 @@ config OF_OVERLAY
  While this option is selected automatically when needed, you can
  enable it manually to improve device tree unit test coverage.
 
+config OF_CONFIGFS
+   bool "Device Tree Overlay ConfigFS interface"
+   select CONFIGFS_FS
+   select OF_FLATTREE
+   depends on OF_OVERLAY
+   help
+ Enable a simple user-space driven DT overlay interface.
+
 config OF_NUMA
bool
 
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 663a4af0cccd..b00a95adf519 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y = base.o device.o platform.o property.o
 obj-$(CONFIG_OF_KOBJ) += kobj.o
+obj-$(CONFIG_OF_CONFIGFS) += configfs.o
 obj-$(CONFIG_OF_DYNAMIC) += dynamic.o
 obj-$(CONFIG_OF_FLATTREE) += fdt.o
 obj-$(CONFIG_OF_EARLY_FLATTREE) += fdt_address.o
diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
new file mode 100644
index ..7a6cae074381
--- /dev/null
+++ b/drivers/of/configfs.c
@@ -0,0 +1,284 @@
+/*
+ * Configfs entries for device-tree
+ *
+ * Copyright (C) 2013 - Pantelis Antoniou 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+

Re: [linux-yocto] [meta-realtime][PATCH] meta-realtime: convert to new override syntax

2021-08-10 Thread Xu, Yanfei




On 8/10/21 6:30 PM, Bruce Ashfield wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

I already have the same automated conversion locally, but since I'm out 
of the office, I haven't pushed it yet.


I see that I didn't push it to master-next, so I'll do that shortly.



Got it. Thanks

Yanfei


Bruce

On Tue, Aug 10, 2021 at 2:39 AM Yanfei Xu > wrote:


This is the result of automated script conversion:

scripts/contrib/convert-overrides.py




converting the metadata to use ":" as the override character instead of
"_".

Signed-off-by: Yanfei Xu mailto:yanfei...@windriver.com>>
---
  recipes-tools/rt-app/rt-app.bb
 
            | 2 +-

  recipes-tools/schedtool-dl/schedtool-dl.bb


| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-tools/rt-app/rt-app.bb


b/recipes-tools/rt-app/rt-app.bb


index c532aea..f298d51 100644
--- a/recipes-tools/rt-app/rt-app.bb


+++ b/recipes-tools/rt-app/rt-app.bb


@@ -18,6 +18,6 @@ do_install() {
         install -m 0755 src/rt-app ${D}${bindir}
  }

-FILES_{PN} = "${bindir}/rt-app"
+FILES:{PN} = "${bindir}/rt-app"

  PARALLEL_MAKE = ""
diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb


b/recipes-tools/schedtool-dl/schedtool-dl.bb


index 20c8919..79ffb09 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb


+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb


@@ -23,6 +23,6 @@ do_install() {
         install -m 0755 schedtool ${D}${bindir}
  }

-FILES_{PN} = "${bindir}/schedtool"
+FILES:{PN} = "${bindir}/schedtool"

  PARALLEL_MAKE = ""
-- 
2.27.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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10251): 
https://lists.yoctoproject.org/g/linux-yocto/message/10251
Mute This Topic: https://lists.yoctoproject.org/mt/84788009/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [meta-realtime][PATCH] meta-realtime: convert to new override syntax

2021-08-10 Thread Xu, Yanfei

This is the result of automated script conversion:

scripts/contrib/convert-overrides.py 

converting the metadata to use ":" as the override character instead of
"_".

Signed-off-by: Yanfei Xu 
---
 recipes-tools/rt-app/rt-app.bb | 2 +-
 recipes-tools/schedtool-dl/schedtool-dl.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-tools/rt-app/rt-app.bb b/recipes-tools/rt-app/rt-app.bb
index c532aea..f298d51 100644
--- a/recipes-tools/rt-app/rt-app.bb
+++ b/recipes-tools/rt-app/rt-app.bb
@@ -18,6 +18,6 @@ do_install() {
install -m 0755 src/rt-app ${D}${bindir}
 }
 
-FILES_{PN} = "${bindir}/rt-app" 
+FILES:{PN} = "${bindir}/rt-app"
 
 PARALLEL_MAKE = ""
diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb 
b/recipes-tools/schedtool-dl/schedtool-dl.bb
index 20c8919..79ffb09 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -23,6 +23,6 @@ do_install() {
install -m 0755 schedtool ${D}${bindir}
 }
 
-FILES_{PN} = "${bindir}/schedtool" 
+FILES:{PN} = "${bindir}/schedtool"
 
 PARALLEL_MAKE = ""
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10247): 
https://lists.yoctoproject.org/g/linux-yocto/message/10247
Mute This Topic: https://lists.yoctoproject.org/mt/84788009/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.10/standard/preempt-rt/base][PATCH] aufs: fix compile failure when accessing rw_sem.owner in rt-kernel

2021-06-21 Thread Xu, Yanfei

rw_semaphore is implemented with rt-mutex in rt-kernel which is
different from the standard kernel. Compatible with these two
implementations on aufs by adding a "#ifndef" statement.

The compile failure log as blow:

|   CC  drivers/char/hw_random/virtio-rng.o
|   CC  kernel/task_work.o
|
/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:
In function 'au_pin_hdir_set_owner':
|
/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:636:52:
error: 'struct rw_semaphore' has no member named 'owne
r'
|   636 | atomic_long_set(>hdir->hi_inode->i_rwsem.owner,
(long)task);
|   |^
|   CC  arch/x86/video/fbdev.o
| make[3]: ***
[/tmp-glibc/work-shared/intel-x86-64/kernel-source/scripts/Makefile.build:279:
fs/aufs/i_op.o] Error 1
| make[3]: *** Waiting for unfinished jobs
|   CC  drivers/acpi/acpica/nsinit.o
|   CC  kernel/extable.o
|   AR  net/ipv4/built-in.a

Signed-off-by: Yanfei Xu 
---
 fs/aufs/i_op.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index 2d09f80153b2..6c76562d3c80 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -633,7 +633,11 @@ int au_pin_hdir_relock(struct au_pin *p)
 
 static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
 {
+#ifndef CONFIG_PREEMPT_RT
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
+#else
+   p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
+#endif
 }
 
 void au_pin_hdir_acquire_nest(struct au_pin *p)
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9982): 
https://lists.yoctoproject.org/g/linux-yocto/message/9982
Mute This Topic: https://lists.yoctoproject.org/mt/83685219/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.10/standard/preempt-rt/base][PATCH] Revert "net/xfrm: fixup 5.10.30 -stable merge"

2021-06-16 Thread Xu, Yanfei

The commit b7a01a10d2f9 ("net: xfrm: Use sequence counter with
associated spinlock") change the type of xfrm_state_hash_generation
from "seqcount_t" to "seqcount_spinlock_t". Revert this commit
for fixing compile failure of "incompatible pointer type".

This reverts commit ac98a75ef2bc550f67454bd738ede581c8846ff3.

Signed-off-by: Yanfei Xu 
---
 net/xfrm/xfrm_state.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 6dbb7a46c66a..e0152019db6f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -44,6 +44,7 @@ static void xfrm_state_gc_task(struct work_struct *work);
  */
 
 static unsigned int xfrm_state_hashmax __read_mostly = 1 * 1024 * 1024;
+static __read_mostly seqcount_spinlock_t xfrm_state_hash_generation;
 static struct kmem_cache *xfrm_state_cache __ro_after_init;
 
 static DECLARE_WORK(xfrm_state_gc_work, xfrm_state_gc_task);
@@ -2668,7 +2669,8 @@ int __net_init xfrm_state_init(struct net *net)
net->xfrm.state_num = 0;
INIT_WORK(>xfrm.state_hash_work, xfrm_hash_resize);
spin_lock_init(>xfrm.xfrm_state_lock);
-   seqcount_init(>xfrm.xfrm_state_hash_generation);
+   seqcount_spinlock_init(>xfrm.xfrm_state_hash_generation,
+  >xfrm.xfrm_state_lock);
return 0;
 
 out_byspi:
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9969): 
https://lists.yoctoproject.org/g/linux-yocto/message/9969
Mute This Topic: https://lists.yoctoproject.org/mt/83597014/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][yocto-kernel-cache yocto-5.4 yocto-5.10 master][PATCH] arm-versatile-926ejs: fix config check warning of CONFIG_CC_OPTIMIZE_FOR_SIZE

2021-03-10 Thread Xu, Yanfei

From: Yanfei Xu 

CONFIG_CC_OPTIMIZE_FOR_SIZE should be disabled when enable
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE. They are mutually exclusive.

This change can fix the following warning:

WARNING: linux-yocto-5.10.19+gitAUTOINC+67e74d52f2_5b86278250-r0
do_kernel_configcheck: [kernel config]: specified values did not make it
into the kernel's final configuration:

[NOTE]: 'CONFIG_CC_OPTIMIZE_FOR_SIZE' last val (y) and .config val
(n) do not match
[INFO]: CONFIG_CC_OPTIMIZE_FOR_SIZE : n ## .config: 160
:configs/v5.10/standard/ktypes/standard/standard.cfg (n)
configs/v5.10/standard/arch/arm/arm.cfg (y)
[INFO]: raw config text:

config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size (-Os)"
depends on 
help
  Choosing this option will pass "-Os" to your compiler
resulting
  in a smaller kernel.

Config 'CC_OPTIMIZE_FOR_SIZE' has the following Direct
dependencies (CC_OPTIMIZE_FOR_SIZE=y):

Parent dependencies are:
 choice [y]

Fixes: 1d1506195a95("arm-versatile-926ejs: Optimize for performance -O2 to fix 
runtime error")

Signed-off-by: Yanfei Xu 
---
 bsp/arm-versatile-926ejs/arm-versatile-926ejs.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsp/arm-versatile-926ejs/arm-versatile-926ejs.cfg 
b/bsp/arm-versatile-926ejs/arm-versatile-926ejs.cfg
index 0dbd105e..8f4ceb45 100644
--- a/bsp/arm-versatile-926ejs/arm-versatile-926ejs.cfg
+++ b/bsp/arm-versatile-926ejs/arm-versatile-926ejs.cfg
@@ -74,6 +74,7 @@ CONFIG_FRAME_POINTER=y
 # CONFIG_NO_HZ is not set
 # CONFIG_HIGH_RES_TIMERS is not set
 
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
 
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9535): 
https://lists.yoctoproject.org/g/linux-yocto/message/9535
Mute This Topic: https://lists.yoctoproject.org/mt/81222699/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.4/standard/nxp-s32g2xx][PATCH] s32: flexcan: integrate two patches that fix the same bug

2021-02-01 Thread Xu, Yanfei

From: Yanfei Xu 

Commit:621e14659f37("can: flexcan: drop repetitive execution
can_rx_offload_add_timestamp") and commit:3713ba3e41db("s32: flexcan:
Remove duplicated code as part of kernel 5.4-rt initial merge") fix the
same flexcan bug in different way, and both of them are contained in
codes, that causes the flexcan_open() always run failed.

Here we remove the commit:621e14659f37 and intergrate codes, and revert
a relevant commit:26f171fbcbe1("s32: flexcan: Remove unused function
flexcan_mailbox_read()")

Signed-off-by: Yanfei Xu 
---
 drivers/net/can/flexcan.c | 133 ++
 1 file changed, 133 insertions(+)

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 9cf016f7021a..38c6041d3b65 100755
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1051,6 +1051,117 @@ static inline struct flexcan_priv 
*rx_offload_to_priv(struct can_rx_offload *off
return container_of(offload, struct flexcan_priv, offload);
 }
 
+static unsigned int flexcan_mailbox_read(struct can_rx_offload *offload,
+bool drop, struct sk_buff **skb,
+u32 *timestamp, unsigned int n)
+{
+   struct flexcan_priv *priv = rx_offload_to_priv(offload);
+   struct flexcan_regs __iomem *regs = priv->regs;
+   struct flexcan_mb __iomem *mb;
+   struct canfd_frame *cf;
+   u32 reg_ctrl, reg_id, reg_iflag1;
+   int i, j;
+   unsigned long flags;
+
+   mb = flexcan_get_mb(priv, n);
+
+   spin_lock_irqsave(>timer_access, flags);
+   if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
+   u32 code;
+
+   do {
+   reg_ctrl = priv->read(>can_ctrl);
+   } while (reg_ctrl & FLEXCAN_MB_CODE_RX_BUSY_BIT);
+
+   /* is this MB empty? */
+   code = reg_ctrl & FLEXCAN_MB_CODE_MASK;
+   if ((code != FLEXCAN_MB_CODE_RX_FULL) &&
+   (code != FLEXCAN_MB_CODE_RX_OVERRUN)) {
+   spin_unlock_irqrestore(>timer_access, flags);
+   return 0;
+   }
+
+   if (code == FLEXCAN_MB_CODE_RX_OVERRUN) {
+   /* This MB was overrun, we lost data */
+   offload->dev->stats.rx_over_errors++;
+   offload->dev->stats.rx_errors++;
+   }
+   } else {
+   reg_iflag1 = priv->read(>iflag1);
+   if (!(reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE)) {
+   spin_unlock_irqrestore(>timer_access, flags);
+   return 0;
+   }
+
+   reg_ctrl = priv->read(>can_ctrl);
+   }
+
+   if (!drop) {
+   if (reg_ctrl & FLEXCAN_MB_CNT_EDL)
+   *skb = alloc_canfd_skb(offload->dev, );
+   else
+   *skb = alloc_can_skb(offload->dev,
+(struct can_frame **));
+
+   if (!*skb)
+   goto ack_mailbox;
+
+   /* increase timstamp to full 32 bit */
+   *timestamp = reg_ctrl << 16;
+
+   reg_id = priv->read(>can_id);
+   if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
+   cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) |
+CAN_EFF_FLAG;
+   else
+   cf->can_id = (reg_id >> 18) & CAN_SFF_MASK;
+
+   if (reg_ctrl & FLEXCAN_MB_CNT_EDL) {
+   cf->len = can_dlc2len((reg_ctrl >> 16) & 0x0F);
+
+
+   if (reg_ctrl & FLEXCAN_MB_CNT_BRS)
+   cf->flags |= CANFD_BRS;
+   } else {
+   cf->len = get_can_dlc((reg_ctrl >> 16) & 0x0F);
+
+   if (reg_ctrl & FLEXCAN_MB_CNT_RTR)
+   cf->can_id |= CAN_RTR_FLAG;
+   }
+
+   if (reg_ctrl & FLEXCAN_MB_CNT_ESI) {
+   cf->flags |= CANFD_ESI;
+   netdev_warn(priv->can.dev, "ESI Error\n");
+   }
+
+   for (i = 0, j = 0; i < cf->len; i += sizeof(u32), j++) {
+   __be32 data = cpu_to_be32(priv->read(>data[j]));
+   *(__be32 *)(cf->data + i) = data;
+   }
+   }
+
+ack_mailbox:   
+   /* mark as read */
+   if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
+   /* Clear IRQ */
+   if (n < 32)
+   priv->write(BIT(n), >iflag1);
+   else
+   priv->write(BIT(n - 32), >iflag2);
+   } else {
+   priv->write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, >iflag1);
+   }
+
+   /* Read the Free Running Timer. It is optional but recommended
+* to unlock Mailbox as soon as possible and make it available

[linux-yocto][linux-yocto v5.4/standard/nxp-s32g2xx][PATCH] s32: flexcan: Remove unused function flexcan_mailbox_read()

2021-01-20 Thread Xu, Yanfei

From: Yanfei Xu 

After the commit 83521390e("s32: flexcan: Remove duplicated code as part
of kernel 5.4-rt initial merge"), the flexcan_mailbox_read() is not
invoked anymore. To avoid the below compile-time warning, let's remove it.

warning: 'flexcan_mailbox_read' defined but not used[-Wunused-function]

Signed-off-by: Yanfei Xu 
---
 drivers/net/can/flexcan.c | 111 --
 1 file changed, 111 deletions(-)

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 69d055127406..9cf016f7021a 100755
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1051,117 +1051,6 @@ static inline struct flexcan_priv 
*rx_offload_to_priv(struct can_rx_offload *off
return container_of(offload, struct flexcan_priv, offload);
 }
 
-static unsigned int flexcan_mailbox_read(struct can_rx_offload *offload,
-bool drop, struct sk_buff **skb,
-u32 *timestamp, unsigned int n)
-{
-   struct flexcan_priv *priv = rx_offload_to_priv(offload);
-   struct flexcan_regs __iomem *regs = priv->regs;
-   struct flexcan_mb __iomem *mb;
-   struct canfd_frame *cf;
-   u32 reg_ctrl, reg_id, reg_iflag1;
-   int i, j;
-   unsigned long flags;
-
-   mb = flexcan_get_mb(priv, n);
-
-   spin_lock_irqsave(>timer_access, flags);
-   if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
-   u32 code;
-
-   do {
-   reg_ctrl = priv->read(>can_ctrl);
-   } while (reg_ctrl & FLEXCAN_MB_CODE_RX_BUSY_BIT);
-
-   /* is this MB empty? */
-   code = reg_ctrl & FLEXCAN_MB_CODE_MASK;
-   if ((code != FLEXCAN_MB_CODE_RX_FULL) &&
-   (code != FLEXCAN_MB_CODE_RX_OVERRUN)) {
-   spin_unlock_irqrestore(>timer_access, flags);
-   return 0;
-   }
-
-   if (code == FLEXCAN_MB_CODE_RX_OVERRUN) {
-   /* This MB was overrun, we lost data */
-   offload->dev->stats.rx_over_errors++;
-   offload->dev->stats.rx_errors++;
-   }
-   } else {
-   reg_iflag1 = priv->read(>iflag1);
-   if (!(reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE)) {
-   spin_unlock_irqrestore(>timer_access, flags);
-   return 0;
-   }
-
-   reg_ctrl = priv->read(>can_ctrl);
-   }
-
-   if (!drop) {
-   if (reg_ctrl & FLEXCAN_MB_CNT_EDL)
-   *skb = alloc_canfd_skb(offload->dev, );
-   else
-   *skb = alloc_can_skb(offload->dev,
-(struct can_frame **));
-
-   if (!*skb)
-   goto ack_mailbox;
-
-   /* increase timstamp to full 32 bit */
-   *timestamp = reg_ctrl << 16;
-
-   reg_id = priv->read(>can_id);
-   if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
-   cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) |
-CAN_EFF_FLAG;
-   else
-   cf->can_id = (reg_id >> 18) & CAN_SFF_MASK;
-
-   if (reg_ctrl & FLEXCAN_MB_CNT_EDL) {
-   cf->len = can_dlc2len((reg_ctrl >> 16) & 0x0F);
-
-
-   if (reg_ctrl & FLEXCAN_MB_CNT_BRS)
-   cf->flags |= CANFD_BRS;
-   } else {
-   cf->len = get_can_dlc((reg_ctrl >> 16) & 0x0F);
-
-   if (reg_ctrl & FLEXCAN_MB_CNT_RTR)
-   cf->can_id |= CAN_RTR_FLAG;
-   }
-
-   if (reg_ctrl & FLEXCAN_MB_CNT_ESI) {
-   cf->flags |= CANFD_ESI;
-   netdev_warn(priv->can.dev, "ESI Error\n");
-   }
-
-   for (i = 0, j = 0; i < cf->len; i += sizeof(u32), j++) {
-   __be32 data = cpu_to_be32(priv->read(>data[j]));
-   *(__be32 *)(cf->data + i) = data;
-   }
-   }
-
-ack_mailbox:   
-   /* mark as read */
-   if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
-   /* Clear IRQ */
-   if (n < 32)
-   priv->write(BIT(n), >iflag1);
-   else
-   priv->write(BIT(n - 32), >iflag2);
-   } else {
-   priv->write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, >iflag1);
-   }
-
-   /* Read the Free Running Timer. It is optional but recommended
-* to unlock Mailbox as soon as possible and make it available
-* for reception.
-*/
-   priv->read(>timer);
-   spin_unlock_irqrestore(>timer_access, flags);
-
-   return 1;
-}
-
 static inline u64 flexcan_read_reg_iflag_rx(struct

[linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] qemuppc: configure the CONFIG_SCSI to '=y'

2020-11-24 Thread Xu, Yanfei

From: Yanfei Xu 

Changing CONFIG_SCSI from '=m' to '=y' to be consistent with its
direct dependency, which is 'CONFIG_SCSI_VIRTIO=y' in virtio.cfg.

Signed-off-by: Yanfei Xu 
---
 bsp/qemu-ppc32/qemu-ppc32.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp/qemu-ppc32/qemu-ppc32.cfg b/bsp/qemu-ppc32/qemu-ppc32.cfg
index 39a71e5d..ed7ec330 100644
--- a/bsp/qemu-ppc32/qemu-ppc32.cfg
+++ b/bsp/qemu-ppc32/qemu-ppc32.cfg
@@ -34,7 +34,7 @@ CONFIG_INPUT_ADBHID=y
 CONFIG_INPUT_KEYBOARD=y
 CONFIG_INPUT_MOUSE=y
 
-CONFIG_SCSI=m
+CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=m
 
 CONFIG_USB_MON=y
-- 
2.18.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9185): 
https://lists.yoctoproject.org/g/linux-yocto/message/9185
Mute This Topic: https://lists.yoctoproject.org/mt/78474086/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-28 Thread Xu, Yanfei




On 9/9/20 12:02 PM, Bruce Ashfield wrote:

On Tue, Sep 8, 2020 at 8:23 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:


On Tue, Sep 8, 2020 at 5:15 AM Xu, Yanfei  wrote:




On 9/8/20 10:26 AM, Xu, Yanfei wrote:



On 9/8/20 10:01 AM, Bruce Ashfield wrote:

On Mon, Sep 7, 2020 at 11:43 AM Xu, Yanfei 
wrote:




On 9/7/20 7:53 PM, Bruce Ashfield wrote:

On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei 
wrote:


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file didn,t
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""



Which machine and configuration are you seeing that in ? I've modified
devsrc several times to remove the triggers that cause that behaviour,
and would like to see how it crept back in.


Firstly， the commit：'kernel.bbclass: Configuration for environment
with
HOSTCXX' expose this problem. After revert it， everything will be
normal.

Secondly， the mechine is qemuarm64. Which configuration you mean？ The


yes, which machine and image type.


project's configuration is normal and only with ""IMAGE_INSTALL +=
"packagegroup-core-buildessential".  The configurations of Kconfig for
choosing is as the blow log messages.


I assume you are also installing kernel-devsrc on the target ?
Yes.





With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by
who
want to use it. So how about disable it by defualt in
ktypes/base/base.cfg file? Do you think it is appropriate?


I don't disagree, but also, the configuration phase shouldn't be
triggered on target, so I'll fix that behaviour first.


That's great！


I was just able to build master, with kernel 5.8 and run the scripts
prepare target without triggering this:

scripts/Makefile.build:415: warning: overriding recipe for target
'modules.order'
Makefile:1371: warning: ignoring old recipe for target 'modules.order'
CC  arch/arm64/kernel/vdso/vgettimeofday.o
AS  arch/arm64/kernel/vdso/note.o
AS  arch/arm64/kernel/vdso/sigreturn.o
LD  arch/arm64/kernel/vdso/vdso.so.dbg
VDSOSYM include/generated/vdso-offsets.h
make: Leaving directory '/lib/modules/5.8.5-yocto-standard/build'
root@qemuarm64:/usr/src/kernel#

Which is what I expected, since this is an effort I made when
introducing the 5.8 kernel. I'll retest with
5.4 now.

I'm sorry for omitting an imformation about that my project added many
nativesdks. I will ensure if the issue was triggered by these soon.


These nativesdks are irrelevant to the result.

I separately build projects with kernel5.4 and kernel5.8. There are some
differences about CONFIG_GCC_PLUGINS of /usr/src/kernel/.config on
target machine.

---5.4-
CONFIG_PLUGIN_HOSTCC=""
CONFIG_HAVE_GCC_PLUGINS=y
# end of General architecture-dependent options

---5.8-
CONFIG_HAVE_GCC_PLUGINS=y
CONFIG_GCC_PLUGINS=y
# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
# CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
# end of General architecture-dependent options


Also, with the 5.4 kernel, I was able to trigger one on-target
configuration run. I'll look into that first, and then get back to the
gcc plugins config question.


I have a fix for this now, and it will work for both 5.8 and 5.4 kernels.

I need to test it a bit more, but I'll send the patch on my Wednesday
(since it is already Wednesday for you :)

Bruce


Hi Bruce,

With your fix, the problem is still here when I test it these day. And 
It only occur on 5.4 kernel.


message as blow:

root@qemuarm64:/module_path/module_example#
root@qemuarm64:/module_path/module_example# cat /proc/version
Linux version 5.4.65-yocto-standard (oe-user@oe-host) (gcc version 
10.2.0 (GCC)) #1 SMP PREEMPT Mon Sep 28 04:05:32 UTC 2020

root@qemuarm64:/module_path/module_example#
root@qemuarm64:/module_path/module_example#
aret@qemuarm64:/module_path/module_example# make -C /usr/src/kernel 
scripts prepa

make: Entering directory '/lib/modules/5.4.65-yocto-standard/build'
scripts/kconfig/conf  --syncconfig Kconfig
*
* Restart config...
*
*
* GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) Y
  Generate some entropy during boot and runtime 
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
  Randomize layout of sensitive kernel structures 
(GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW) y
Use cacheline-aware structure randomization 
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y

Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-09 Thread Xu, Yanfei




On 9/9/20 12:02 PM, Bruce Ashfield wrote:

On Tue, Sep 8, 2020 at 8:23 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:


On Tue, Sep 8, 2020 at 5:15 AM Xu, Yanfei  wrote:




On 9/8/20 10:26 AM, Xu, Yanfei wrote:



On 9/8/20 10:01 AM, Bruce Ashfield wrote:

On Mon, Sep 7, 2020 at 11:43 AM Xu, Yanfei 
wrote:




On 9/7/20 7:53 PM, Bruce Ashfield wrote:

On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei 
wrote:


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file didn,t
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""



Which machine and configuration are you seeing that in ? I've modified
devsrc several times to remove the triggers that cause that behaviour,
and would like to see how it crept back in.


Firstly， the commit：'kernel.bbclass: Configuration for environment
with
HOSTCXX' expose this problem. After revert it， everything will be
normal.

Secondly， the mechine is qemuarm64. Which configuration you mean？ The


yes, which machine and image type.


project's configuration is normal and only with ""IMAGE_INSTALL +=
"packagegroup-core-buildessential".  The configurations of Kconfig for
choosing is as the blow log messages.


I assume you are also installing kernel-devsrc on the target ?
Yes.





With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by
who
want to use it. So how about disable it by defualt in
ktypes/base/base.cfg file? Do you think it is appropriate?


I don't disagree, but also, the configuration phase shouldn't be
triggered on target, so I'll fix that behaviour first.


That's great！


I was just able to build master, with kernel 5.8 and run the scripts
prepare target without triggering this:

scripts/Makefile.build:415: warning: overriding recipe for target
'modules.order'
Makefile:1371: warning: ignoring old recipe for target 'modules.order'
CC  arch/arm64/kernel/vdso/vgettimeofday.o
AS  arch/arm64/kernel/vdso/note.o
AS  arch/arm64/kernel/vdso/sigreturn.o
LD  arch/arm64/kernel/vdso/vdso.so.dbg
VDSOSYM include/generated/vdso-offsets.h
make: Leaving directory '/lib/modules/5.8.5-yocto-standard/build'
root@qemuarm64:/usr/src/kernel#

Which is what I expected, since this is an effort I made when
introducing the 5.8 kernel. I'll retest with
5.4 now.

I'm sorry for omitting an imformation about that my project added many
nativesdks. I will ensure if the issue was triggered by these soon.


These nativesdks are irrelevant to the result.

I separately build projects with kernel5.4 and kernel5.8. There are some
differences about CONFIG_GCC_PLUGINS of /usr/src/kernel/.config on
target machine.

---5.4-
CONFIG_PLUGIN_HOSTCC=""
CONFIG_HAVE_GCC_PLUGINS=y
# end of General architecture-dependent options

---5.8-
CONFIG_HAVE_GCC_PLUGINS=y
CONFIG_GCC_PLUGINS=y
# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
# CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
# end of General architecture-dependent options


Also, with the 5.4 kernel, I was able to trigger one on-target
configuration run. I'll look into that first, and then get back to the
gcc plugins config question.


I have a fix for this now, and it will work for both 5.8 and 5.4 kernels.

I need to test it a bit more, but I'll send the patch on my Wednesday
(since it is already Wednesday for you :)

Bruce



Get it. Thanks for quick fixing it and your reminding.

Cheers,
Yanfei



Cheers,

Bruce




Yanfei



Thanks,
Yanfei



Bruce



Thanks，
Yanfei




Bruce





Regards,
Yanfei


=

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures
(GCC_PLUGIN_RANDSTRUCT)
[N/y/?] (NEW) y
Use cacheline-aware structure randomization
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y
*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak)
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong)
(GCC_PLUGIN_STRUCT

Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-08 Thread Xu, Yanfei




On 9/8/20 10:26 AM, Xu, Yanfei wrote:



On 9/8/20 10:01 AM, Bruce Ashfield wrote:
On Mon, Sep 7, 2020 at 11:43 AM Xu, Yanfei  
wrote:




On 9/7/20 7:53 PM, Bruce Ashfield wrote:
On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei  
wrote:


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file didn,t
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""



Which machine and configuration are you seeing that in ? I've modified
devsrc several times to remove the triggers that cause that behaviour,
and would like to see how it crept back in.

Firstly， the commit：'kernel.bbclass: Configuration for environment 
with

HOSTCXX' expose this problem. After revert it， everything will be
normal.

Secondly， the mechine is qemuarm64. Which configuration you mean？ The


yes, which machine and image type.


project's configuration is normal and only with ""IMAGE_INSTALL +=
"packagegroup-core-buildessential".  The configurations of Kconfig for
choosing is as the blow log messages.


I assume you are also installing kernel-devsrc on the target ?
Yes.





With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by 
who

want to use it. So how about disable it by defualt in
ktypes/base/base.cfg file? Do you think it is appropriate?


I don't disagree, but also, the configuration phase shouldn't be
triggered on target, so I'll fix that behaviour first.


That's great！


I was just able to build master, with kernel 5.8 and run the scripts
prepare target without triggering this:

scripts/Makefile.build:415: warning: overriding recipe for target
'modules.order'
Makefile:1371: warning: ignoring old recipe for target 'modules.order'
   CC  arch/arm64/kernel/vdso/vgettimeofday.o
   AS  arch/arm64/kernel/vdso/note.o
   AS  arch/arm64/kernel/vdso/sigreturn.o
   LD  arch/arm64/kernel/vdso/vdso.so.dbg
   VDSOSYM include/generated/vdso-offsets.h
make: Leaving directory '/lib/modules/5.8.5-yocto-standard/build'
root@qemuarm64:/usr/src/kernel#

Which is what I expected, since this is an effort I made when
introducing the 5.8 kernel. I'll retest with
5.4 now.

I'm sorry for omitting an imformation about that my project added many
nativesdks. I will ensure if the issue was triggered by these soon.


These nativesdks are irrelevant to the result.

I separately build projects with kernel5.4 and kernel5.8. There are some
differences about CONFIG_GCC_PLUGINS of /usr/src/kernel/.config on
target machine.

---5.4-
CONFIG_PLUGIN_HOSTCC=""
CONFIG_HAVE_GCC_PLUGINS=y
# end of General architecture-dependent options

---5.8-
CONFIG_HAVE_GCC_PLUGINS=y
CONFIG_GCC_PLUGINS=y
# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
# CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
# end of General architecture-dependent options


Yanfei



Thanks,
Yanfei



Bruce



Thanks，
Yanfei




Bruce





Regards,
Yanfei


=

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures 
(GCC_PLUGIN_RANDSTRUCT)

[N/y/?] (NEW) y
Use cacheline-aware structure randomization
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y
*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
   > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak)
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]: 1
Poison kernel stack before returning from syscalls
(GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) y
Minimum stack frame size of functions tracked by STACKLEAK
(STACKLEAK_TRACK_MIN_SIZE) [100] (NEW)
Show STACKLEAK metrics in the /proc file system (STACKLEAK_METRICS)
[N/y/?] (NEW) y
Allow runtime disabling of kernel stack erasing
(STACKLEAK_RUNTIME_DISABLE) [N/y/?] (NEW) y
Enable heap memory zeroing on allocation by default
(INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default 
(INIT_ON_FREE_DEFAULT_ON)

[N/y/?] n

HOSTCC scripts/dtc/dtc.o
..
==
then build the module,
==
$ ma

Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-07 Thread Xu, Yanfei




On 9/7/20 10:42 PM, Xu, Yanfei wrote:



On 9/7/20 7:53 PM, Bruce Ashfield wrote:
On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei  
wrote:


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file didn,t
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""



Which machine and configuration are you seeing that in ? I've modified
devsrc several times to remove the triggers that cause that behaviour,
and would like to see how it crept back in.


Firstly， the commit：'kernel.bbclass: Configuration for environment with
HOSTCXX' expose this problem. After revert it， everything will be
normal.

Secondly， the mechine is qemuarm64. Which configuration you mean？ The
project's configuration is normal and only with ""IMAGE_INSTALL +=
"packagegroup-core-buildessential".  The configurations of Kconfig for
choosing is as the blow log messages.


Add the target kernel's version.
cat /proc/version
Linux version 5.4.59-yocto-standard (oe-user@oe-host) (gcc version 
10.2.0 (GCC)) #1 SMP PREEMPT Thu Sep 3 06:59:55 UTC 2020

With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by who
want to use it. So how about disable it by defualt in
ktypes/base/base.cfg file? Do you think it is appropriate?


I don't disagree, but also, the configuration phase shouldn't be
triggered on target, so I'll fix that behaviour first.


That's great！

Thanks，
Yanfei




Bruce





Regards,
Yanfei


=

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT)
[N/y/?] (NEW) y
Use cacheline-aware structure randomization
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y
*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
  > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak)
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]: 1
Poison kernel stack before returning from syscalls
(GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) y
Minimum stack frame size of functions tracked by STACKLEAK
(STACKLEAK_TRACK_MIN_SIZE) [100] (NEW)
Show STACKLEAK metrics in the /proc file system (STACKLEAK_METRICS)
[N/y/?] (NEW) y
Allow runtime disabling of kernel stack erasing
(STACKLEAK_RUNTIME_DISABLE) [N/y/?] (NEW) y
Enable heap memory zeroing on allocation by default
(INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON)
[N/y/?] n

HOSTCC scripts/dtc/dtc.o
..
==
then build the module,
==
$ make -C /usr/src/kernel M=/module_path/module_example modules
Build external kernel module ...
make: Entering directory '/lib/modules/5.4.57-yocto-standard/build'
CC [M] /module_path/module_example/hello.o
Building modules, stage 2.
MODPOST 1 modules
ERROR: "module_layout" [/module_path/module_example/hello.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make: *** [Makefile:1630: modules] Error 2
make: Leaving directory '/lib/modules/5.4.57-yocto-standard/build'
==








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9032): 
https://lists.yoctoproject.org/g/linux-yocto/message/9032
Mute This Topic: https://lists.yoctoproject.org/mt/76682606/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-07 Thread Xu, Yanfei




On 9/7/20 7:53 PM, Bruce Ashfield wrote:

On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei  wrote:


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file didn,t
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""



Which machine and configuration are you seeing that in ? I've modified
devsrc several times to remove the triggers that cause that behaviour,
and would like to see how it crept back in.


Firstly， the commit：'kernel.bbclass: Configuration for environment with
HOSTCXX' expose this problem. After revert it， everything will be
normal.

Secondly， the mechine is qemuarm64. Which configuration you mean？ The
project's configuration is normal and only with ""IMAGE_INSTALL +=
"packagegroup-core-buildessential".  The configurations of Kconfig for
choosing is as the blow log messages.


With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by who
want to use it. So how about disable it by defualt in
ktypes/base/base.cfg file? Do you think it is appropriate?


I don't disagree, but also, the configuration phase shouldn't be
triggered on target, so I'll fix that behaviour first.


That's great！

Thanks，
Yanfei




Bruce





Regards,
Yanfei


=

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT)
[N/y/?] (NEW) y
Use cacheline-aware structure randomization
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y
*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
  > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak)
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong)
(GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]: 1
Poison kernel stack before returning from syscalls
(GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) y
Minimum stack frame size of functions tracked by STACKLEAK
(STACKLEAK_TRACK_MIN_SIZE) [100] (NEW)
Show STACKLEAK metrics in the /proc file system (STACKLEAK_METRICS)
[N/y/?] (NEW) y
Allow runtime disabling of kernel stack erasing
(STACKLEAK_RUNTIME_DISABLE) [N/y/?] (NEW) y
Enable heap memory zeroing on allocation by default
(INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON)
[N/y/?] n

HOSTCC scripts/dtc/dtc.o
..
==
then build the module,
==
$ make -C /usr/src/kernel M=/module_path/module_example modules
Build external kernel module ...
make: Entering directory '/lib/modules/5.4.57-yocto-standard/build'
CC [M] /module_path/module_example/hello.o
Building modules, stage 2.
MODPOST 1 modules
ERROR: "module_layout" [/module_path/module_example/hello.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make: *** [Makefile:1630: modules] Error 2
make: Leaving directory '/lib/modules/5.4.57-yocto-standard/build'
==




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9031): 
https://lists.yoctoproject.org/g/linux-yocto/message/9031
Mute This Topic: https://lists.yoctoproject.org/mt/76682606/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-07 Thread Xu, Yanfei


Hi Bruce,

When I excuted "make -C /usr/src/kernel scripts prepare" on target
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
other configurations depend on "GCC_PLUGINS" (The .config file doesn't
contain 'GCC_PLUGINS is not set')

But there were never be asked for these before yocto add the
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""

With these, I met a failure during compiling an external module on
target mechine after I enabled the GCC_PLUGINS and
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
below. There might be some other unexpected situations with GCC_PLUGIN
enabled.

In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by who
want to use it. So how about disable it by defualt in ktypes/base
/base.cfg file? Do you think it is appropriate?

==cut here===

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime 
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) 
[N/y/?] (NEW) y
Use cacheline-aware structure randomization 
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y

*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) 
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) 
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) 
(GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)

choice[1-4?]: 1
Poison kernel stack before returning from syscalls 
(GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) y
Minimum stack frame size of functions tracked by STACKLEAK 
(STACKLEAK_TRACK_MIN_SIZE) [100] (NEW)
Show STACKLEAK metrics in the /proc file system (STACKLEAK_METRICS) 
[N/y/?] (NEW) y
Allow runtime disabling of kernel stack erasing 
(STACKLEAK_RUNTIME_DISABLE) [N/y/?] (NEW) y
Enable heap memory zeroing on allocation by default 
(INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) 
[N/y/?] n


HOSTCC scripts/dtc/dtc.o
..
==
then build the module,
==
$ make -C /usr/src/kernel M=/module_path/module_example modules
Build external kernel module ...
make: Entering directory '/lib/modules/5.4.57-yocto-standard/build'
CC [M] /module_path/module_example/hello.o
Building modules, stage 2.
MODPOST 1 modules
ERROR: "module_layout" [/module_path/module_example/hello.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make: *** [Makefile:1630: modules] Error 2
make: Leaving directory '/lib/modules/5.4.57-yocto-standard/build'
==


Regards,
Yanfei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9029): 
https://lists.yoctoproject.org/g/linux-yocto/message/9029
Mute This Topic: https://lists.yoctoproject.org/mt/76682672/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-07 Thread Xu, Yanfei


Hi Bruce,


When I excuted "make -C /usr/src/kernel scripts prepare" on target 
mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and 
other configurations depend on "GCC_PLUGINS" (The .config file didn,t 
contain 'GCC_PLUGINS is not set')
But there were never be asked for these before yocto add the 
configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} 
${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""


With these, I met a failure during compiling an external module on 
target mechine after I enabled the GCC_PLUGINS and 
CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as 
below. There might be some other unexpected situations with GCC_PLUGIN 
enabled.


In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by who 
want to use it. So how about disable it by defualt in 
ktypes/base/base.cfg file? Do you think it is appropriate?




Regards,
Yanfei


=

$ make -C /usr/src/kernel scripts prepare
..
\ * GCC plugins
*
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) y
Generate some entropy during boot and runtime 
(GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) y
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) 
[N/y/?] (NEW) y
Use cacheline-aware structure randomization 
(GCC_PLUGIN_RANDSTRUCT_PERFORMANCE) [N/y/?] (NEW) y

*
\ * Memory initialization
*
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) 
(GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) 
(GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) 
(GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)

choice[1-4?]: 1
Poison kernel stack before returning from syscalls 
(GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) y
Minimum stack frame size of functions tracked by STACKLEAK 
(STACKLEAK_TRACK_MIN_SIZE) [100] (NEW)
Show STACKLEAK metrics in the /proc file system (STACKLEAK_METRICS) 
[N/y/?] (NEW) y
Allow runtime disabling of kernel stack erasing 
(STACKLEAK_RUNTIME_DISABLE) [N/y/?] (NEW) y
Enable heap memory zeroing on allocation by default 
(INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) 
[N/y/?] n


HOSTCC scripts/dtc/dtc.o
..
==
then build the module,
==
$ make -C /usr/src/kernel M=/module_path/module_example modules
Build external kernel module ...
make: Entering directory '/lib/modules/5.4.57-yocto-standard/build'
CC [M] /module_path/module_example/hello.o
Building modules, stage 2.
MODPOST 1 modules
ERROR: "module_layout" [/module_path/module_example/hello.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make: *** [Makefile:1630: modules] Error 2
make: Leaving directory '/lib/modules/5.4.57-yocto-standard/build'
==
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9028): 
https://lists.yoctoproject.org/g/linux-yocto/message/9028
Mute This Topic: https://lists.yoctoproject.org/mt/76682606/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][PATCH 1/1] Fix compiling warnings of file arm64/kernel/perf_callchain.c

2020-06-10 Thread Xu, Yanfei

From: Jiping Ma 

arch/arm64/kernel/perf_callchain.c:107:6: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
 if ((u32)tail + 4 >= buftail.fp)
  ^
arch/arm64/kernel/perf_callchain.c:110:9: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]
  return (struct compat_frame_tail __user *)(buftail.fp - 4);
 ^

Signed-off-by: Jiping Ma 
---
 arch/arm64/kernel/perf_callchain.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/perf_callchain.c 
b/arch/arm64/kernel/perf_callchain.c
index 1be96e3631ea..b00408445674 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -97,10 +97,11 @@ compat_user_backtrace(struct compat_frame_tail __user *tail,
 * Frame pointers should strictly progress back up the stack
 * (towards higher addresses).
 */
-   if ((u32)tail + 4 >= buftail.fp)
+   if ((u32)(u64)tail + 4 >= buftail.fp)
return NULL;
 
-   return (struct compat_frame_tail __user *)(buftail.fp - 4);
+
+   return (struct compat_frame_tail __user *)((u64)buftail.fp - 4);
 }
 #endif /* CONFIG_COMPAT */
 
-- 
2.18.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8741): 
https://lists.yoctoproject.org/g/linux-yocto/message/8741
Mute This Topic: https://lists.yoctoproject.org/mt/74792094/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto-dev standard/base][PATCH 0/1]Fix compiling warnings of file arm64/kernel/perf_callchain.c

2020-06-10 Thread Xu, Yanfei

From: Yanfei Xu 

Hi Bruce,

This patch fix compiling warnings which are introduced by an previous 
patch. It should merge to both [linux-yocto-dev standard/base] and 
[linux-yocto v5.4/standard/base]

https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch

Regards,
Yanfei

Jiping Ma (1):
  Fix compiling warnings of file arm64/kernel/perf_callchain.c

 arch/arm64/kernel/perf_callchain.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.18.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8740): 
https://lists.yoctoproject.org/g/linux-yocto/message/8740
Mute This Topic: https://lists.yoctoproject.org/mt/74792080/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 1/1] arm64/perf: fix backtrace for AAPCS with FP enabled

2020-05-06 Thread Xu, Yanfei

From: Fang Jia 

This change is for arm64 platform compat mode.
The change for arm32 platform has been included in this commit "perf: fix
backtrace for AAPCS with FP enabled".

This change replaces code designed for the obsolete ARM APCS ABI, which
causes failures of the perf backtrace logic unless the gcc option
-mapcs-frame is used to build all binaries on the platform.  This
obsolete gcc option forces the compiler to include the stack pointer
along with the frame pointer and link register in the stack frame
for each funciton call. The current AAPCS ABI document, doesn't
explicitly describe the frame structure when the gcc frame pointer
option, -fno-omit-frame-pointer, is enabled. However, with this option
enabled, examination of the emitted prologue instructions shows that
1) R11 is used as the frame pointer,
2) only the R11 and LR are saved onto the stack, not the stack pointer,
3) after this prologue setup, the frame pointer, R11 points to the
saved location of LR on the stack.

The use of unsigned int arithmetic in the commit is required since
the gcc emitted pointer arithmetic uses 8-byte pointer sizes, which are
incorrect addresses for the 4-byte stack address size.

Signed-off-by: Fang Jia 
Reviewed-by: Jiwei Sun 
Signed-off-by: De Huo 

This change is for arm64 platform compat mode.

--[cut here: not apply patch]
 Samples: 119K of event 'cycles'
 Event count (approx.): 114092698680

 Children  Self  CommandShared Object   Symbol
     .  ..

99.85% 0.00%  perf-test  [unknown]   [.]
0xff80f4ec
|
---0xff80f4ec
   |
   |--37.68%--__aeabi_idivmod
   |
   |--25.35%--calculate_meaning_of_life
   |
   |--20.06%--aeabi_idivmod_from_thumb
   |
   |--7.25%--0
   |  |
   |  |--1.76%--0xf543df9c
   |  |  __gettimeofday

--[cut here: apply patch]
 Samples: 114K of event 'cycles'
 Event count (approx.): 109799966925

 Children  Self  CommandShared Object   Symbol
     .  ..

99.91% 0.00%  perf-test  perf-test   [.] main
|
---main
   |
   |--57.49%--pthread_create@@GLIBC_2.4
   |  |
   |   --57.44%--0xf7cf2f88
   | |
   | |--20.16%--__aeabi_idivmod
   | |
   |
|--13.79%--calculate_meaning_of_life
   | |
   |
|--10.89%--aeabi_idivmod_from_thumb
   | |
   | |--8.99%--current_timestamp
   | |  |
   | |   --8.98%--__gettimeofday

Signed-off-by: Yanfei Xu 
---
 arch/arm64/kernel/perf_callchain.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/perf_callchain.c 
b/arch/arm64/kernel/perf_callchain.c
index b0e03e052dd1..1be96e3631ea 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -54,16 +54,22 @@ user_backtrace(struct frame_tail __user *tail,
 
 #ifdef CONFIG_COMPAT
 /*
- * The registers we're interested in are at the end of the variable
- * length saved register structure. The fp points at the end of this
- * structure so the address of this struct is:
- * (struct compat_frame_tail *)(xxx->fp)-1
+ * The AAPCS ABI, the most current replacing the obsolete APCS ABI,
+ * does not specifically describe the stack frame with respect to the
+ * frame pointer.  However, the examination of emitted prologue
+ * instructions for ARM implies that with -fno-omit-framepointer,
+ * register R11 is used as the frame pointer register and saved on the
+ * stack, with LR.
  *
- * This code has been adapted from the ARM OProfile support.
+ * After the prolog, the FP points to the location of the saved LR and
+ * FP+4 points to the previous frames FP as shown below:
+ *  Stack Hi Mem
+ *  (Value of FP)+4  Saved FP for caller
+ *  (Value of FP)LR set by caller
+ *  Stack Lo Mem
  */
 struct compat_frame_tail {
compat_uptr_t   fp; /* a (struct compat_frame_tail *) in compat mode */
-   u32 sp;
u32 lr;
 } __attribute__((packed));
 
@@ -91,11 +97,10 @@ compat_user_backtrace(struct compat_frame_tail __user *tail,
 * Frame pointers should strictly progress back up the stack
 * (towards higher addresses).
 */
-   if (tail + 1 >= (struct compat_frame_tail __user *)
-   compat_ptr(buftail.fp))
+   if ((u32)tail + 4 >= buftail.fp)
return NULL;
 
-   return (struct compat_frame_tail

[V2][linux-yocto][linux-yocto-dev standard/base][PATCH 0/1] arm64/perf: fix backtrace for AAPCS with FP enabled

2020-05-06 Thread Xu, Yanfei

From: Yanfei Xu 

Hi Bruce,

This patch should be merged to [linux-yocto-dev standard/base] and 
[linux-yocto v5.4/standard/base]

V1-->V2

1.send this patch to linux-yocto and linux-yocto-dev instead of 
cache repo.

Best regards,
Yanfei

Fang Jia (1):
  arm64/perf: fix backtrace for AAPCS with FP enabled

 arch/arm64/kernel/perf_callchain.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

-- 
2.18.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8638): 
https://lists.yoctoproject.org/g/linux-yocto/message/8638
Mute This Topic: https://lists.yoctoproject.org/mt/74024246/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/624485779/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled

2020-05-05 Thread Xu, Yanfei


No, you didn't miss any things. I just know that the patches are
generated from your scripts. And I will resend the patch against
linux-yocto.

Yanfei

On 5/2/20 11:19 PM, Bruce Ashfield wrote:

Did I miss applying this to the kernel-cache previously ? or did
I miss a patch against the linux-yocto repo itself ?

The reason I ask, is that it is awkward to apply patches like this
to the tree.

If you send the patch against linux-yocto, I'll apply it and then
commit the change to the kernel-cache via my scripts.

Bruce

In message: [linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] 
arm64/perf: fix backtrace for AAPCS with FP enabled
on 27/04/2020 yanfei...@windriver.com wrote:


From: Yanfei Xu 

This change is for arm64 platform compat mode.

--[cut here: not apply patch]
  Samples: 119K of event 'cycles'
  Event count (approx.): 114092698680

  Children  Self  CommandShared Object   Symbol
      .  ..

 99.85% 0.00%  perf-test  [unknown]   [.]
0xff80f4ec
 |
 ---0xff80f4ec
|
|--37.68%--__aeabi_idivmod
|
|--25.35%--calculate_meaning_of_life
|
|--20.06%--aeabi_idivmod_from_thumb
|
|--7.25%--0
|  |
|  |--1.76%--0xf543df9c
|  |  __gettimeofday

--[cut here: apply patch]
  Samples: 114K of event 'cycles'
  Event count (approx.): 109799966925

  Children  Self  CommandShared Object   Symbol
      .  ..

 99.91% 0.00%  perf-test  perf-test   [.] main
 |
 ---main
|
|--57.49%--pthread_create@@GLIBC_2.4
|  |
|   --57.44%--0xf7cf2f88
| |
| |--20.16%--__aeabi_idivmod
| |
|
|--13.79%--calculate_meaning_of_life
| |
|
|--10.89%--aeabi_idivmod_from_thumb
| |
| |--8.99%--current_timestamp
| |  |
| |   --8.98%--__gettimeofday

1/1 [
Author: Fang Jia
Email: fang@windriver.com
Subject: arm64/perf: fix backtrace for AAPCS with FP enabled
Date: Fri, 28 Dec 2018 16:28:34 +0800

This change is for arm64 platform compat mode.
The change for arm32 platform has been included in this commit "perf:
fix backtrace for AAPCS with FP enabled".

This change replaces code designed for the obsolete ARM APCS ABI, which
causes failures of the perf backtrace logic unless the gcc option
-mapcs-frame is used to build all binaries on the platform.  This
obsolete gcc option forces the compiler to include the stack pointer
along with the frame pointer and link register in the stack frame
for each funciton call. The current AAPCS ABI document, doesn't
explicitly describe the frame structure when the gcc frame pointer
option, -fno-omit-frame-pointer, is enabled. However, with this option
enabled, examination of the emitted prologue instructions shows that
1) R11 is used as the frame pointer,
2) only the R11 and LR are saved onto the stack, not the stack pointer,
3) after this prologue setup, the frame pointer, R11 points to the
saved location of LR on the stack.

The use of unsigned int arithmetic in the commit is required since
the gcc emitted pointer arithmetic uses 8-byte pointer sizes, which are
incorrect addresses for the 4-byte stack address size.

Signed-off-by: Fang Jia 
Reviewed-by: Jiwei Sun 
Signed-off-by: De Huo 
]

Signed-off-by: Yanfei Xu 
---
  ...-backtrace-for-AAPCS-with-FP-enabled.patch | 93 +++
  patches/misc/misc.scc |  1 +
  2 files changed, 94 insertions(+)
  create mode 100644 
patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch

diff --git 
a/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch 
b/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch
new file mode 100644
index ..4c1e78cf
--- /dev/null
+++ b/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch
@@ -0,0 +1,93 @@
+From cbbce37ccc6041d3ae3d3cb3b1918a61a39820a0 Mon Sep 17 00:00:00 2001
+From: Fang Jia 
+Date: Fri, 28 Dec 2018 16:28:34 +0800
+Subject: [PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled
+
+This change is for arm64 platform compat mode.
+The change for arm32 platform has been included in this commit "perf: fix
+backtrace for AAPCS with FP enabled".
+
+This change replaces code designed for the obsolete ARM APCS ABI, which
+causes failures of the perf backtrace logic unless the gcc

[linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled

2020-04-27 Thread Xu, Yanfei

From: Yanfei Xu 

This change is for arm64 platform compat mode.

--[cut here: not apply patch]
 Samples: 119K of event 'cycles'
 Event count (approx.): 114092698680

 Children  Self  CommandShared Object   Symbol
     .  ..

99.85% 0.00%  perf-test  [unknown]   [.]
0xff80f4ec
|
---0xff80f4ec
   |
   |--37.68%--__aeabi_idivmod
   |
   |--25.35%--calculate_meaning_of_life
   |
   |--20.06%--aeabi_idivmod_from_thumb
   |
   |--7.25%--0
   |  |
   |  |--1.76%--0xf543df9c
   |  |  __gettimeofday

--[cut here: apply patch]
 Samples: 114K of event 'cycles'
 Event count (approx.): 109799966925

 Children  Self  CommandShared Object   Symbol
     .  ..

99.91% 0.00%  perf-test  perf-test   [.] main
|
---main
   |
   |--57.49%--pthread_create@@GLIBC_2.4
   |  |
   |   --57.44%--0xf7cf2f88
   | |
   | |--20.16%--__aeabi_idivmod
   | |
   |
|--13.79%--calculate_meaning_of_life
   | |
   |
|--10.89%--aeabi_idivmod_from_thumb
   | |
   | |--8.99%--current_timestamp
   | |  |
   | |   --8.98%--__gettimeofday

1/1 [
Author: Fang Jia
Email: fang@windriver.com
Subject: arm64/perf: fix backtrace for AAPCS with FP enabled
Date: Fri, 28 Dec 2018 16:28:34 +0800

This change is for arm64 platform compat mode.
The change for arm32 platform has been included in this commit "perf:
fix backtrace for AAPCS with FP enabled".

This change replaces code designed for the obsolete ARM APCS ABI, which
causes failures of the perf backtrace logic unless the gcc option
-mapcs-frame is used to build all binaries on the platform.  This
obsolete gcc option forces the compiler to include the stack pointer
along with the frame pointer and link register in the stack frame
for each funciton call. The current AAPCS ABI document, doesn't
explicitly describe the frame structure when the gcc frame pointer
option, -fno-omit-frame-pointer, is enabled. However, with this option
enabled, examination of the emitted prologue instructions shows that
1) R11 is used as the frame pointer,
2) only the R11 and LR are saved onto the stack, not the stack pointer,
3) after this prologue setup, the frame pointer, R11 points to the
saved location of LR on the stack.

The use of unsigned int arithmetic in the commit is required since
the gcc emitted pointer arithmetic uses 8-byte pointer sizes, which are
incorrect addresses for the 4-byte stack address size.

Signed-off-by: Fang Jia 
Reviewed-by: Jiwei Sun 
Signed-off-by: De Huo 
]

Signed-off-by: Yanfei Xu 
---
 ...-backtrace-for-AAPCS-with-FP-enabled.patch | 93 +++
 patches/misc/misc.scc |  1 +
 2 files changed, 94 insertions(+)
 create mode 100644 
patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch

diff --git 
a/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch 
b/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch
new file mode 100644
index ..4c1e78cf
--- /dev/null
+++ b/patches/misc/arm64-perf-fix-backtrace-for-AAPCS-with-FP-enabled.patch
@@ -0,0 +1,93 @@
+From cbbce37ccc6041d3ae3d3cb3b1918a61a39820a0 Mon Sep 17 00:00:00 2001
+From: Fang Jia 
+Date: Fri, 28 Dec 2018 16:28:34 +0800
+Subject: [PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled
+
+This change is for arm64 platform compat mode.
+The change for arm32 platform has been included in this commit "perf: fix
+backtrace for AAPCS with FP enabled".
+
+This change replaces code designed for the obsolete ARM APCS ABI, which
+causes failures of the perf backtrace logic unless the gcc option
+-mapcs-frame is used to build all binaries on the platform.  This
+obsolete gcc option forces the compiler to include the stack pointer
+along with the frame pointer and link register in the stack frame
+for each funciton call. The current AAPCS ABI document, doesn't
+explicitly describe the frame structure when the gcc frame pointer
+option, -fno-omit-frame-pointer, is enabled. However, with this option
+enabled, examination of the emitted prologue instructions shows that
+1) R11 is used as the frame pointer,
+2) only the R11 and LR are saved onto the stack, not the stack pointer,
+3) after this prologue setup, the frame pointer, R11 points to the
+saved location of LR on the stack.
+
+The use of unsigned int arithmetic

[linux-yocto] [linux-yocto v5.4/standard/base] [PATCH] arm64: dts: ti: k3-am65-mcu:Update the power domain cells

2020-04-03 Thread Xu, Yanfei

From: Yanfei Xu 

Before the last commit, it updated the power-domain cells to 2.
However, the last commit added some codes without right power-domain
cells.
So, update OSPI power domain cells to 2 here to avoid warning when
compile dts.

Signed-off-by: Yanfei Xu 
---
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index e32a7d13a72e..0d6b3d08628c 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -115,7 +115,7 @@
assigned-clocks = <_clks 55 5>;
assigned-clock-parents = <_clks 55 7>;
assigned-clock-rates = <1>;
-   power-domains = <_pds 55>;
+   power-domains = <_pds 55 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <1>;
#size-cells = <0>;
dma-coherent;
@@ -130,7 +130,7 @@
cdns,fifo-width = <4>;
cdns,trigger-address = <0x5800>;
clocks = <_clks 55 16>;
-   power-domains = <_pds 55>;
+   power-domains = <_pds 55 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <1>;
#size-cells = <0>;
dma-coherent;
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8577): 
https://lists.yoctoproject.org/g/linux-yocto/message/8577
Mute This Topic: https://lists.yoctoproject.org/mt/72744242/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.4/standard/base][PATCH] fixup! yaffs: Fix build failure by handling inode i_version with proper atomic API

2020-04-01 Thread Xu, Yanfei



On 4/1/20 8:37 PM, Bruce Ashfield wrote:

On Tue, Mar 31, 2020 at 11:07 PM Xu, Yanfei  wrote:

Hi Bruce,

Not a build failure, but a compile warning. when I built 
v5.4/standard/xilinx-zynq kernel, It
occured the blow warning in log.do_compile.

# work-shared/xilinx-zynq/kernel-source/fs/yaffs2/yaffs_vfs.c:1829:6: warning: 
unused variable 'i_version' [-Wunused-variable]
# 1829 | u64 i_version; ^
# CC fs/ubifs/replay.o



Aha. Thanks, that helps.

I squashed a bunch of those errors when updating the support, but one
must have slipped through.


Then I took a look at the previous commits about yaffs2 in 
linux-yocto/v5.4/standard/base
kernel and found the yaffs2 code was been updated recently. Some defferences 
about yaffs_readdir（）
in yaffs_vfs.c than before. It causes the following patch[yaffs: Fix build 
failure...1fffb37acca0]
appled 'u64 i_version' at a wrong place. Maybe there is a glable i_version 
variable somewhere，
hence it didn't occur a build failure.

Agreed. I'll fixup the header slightly and merge the patch.

Have you tried linux-yocto-dev ? I also had to update yaffs2 there,
and may need a similar fix.


Yep， I have tried it. Yaffs2 in linux-yocto-dev was not updated as in 
linux-yocto, hence it


doesn't have the issue. However， you should pay attention to this 
place，if you update


yaffs2 in linux-yocto-dev someday.


Regards，

Yanfei


Bruce


Regards,

Yanfei

On 3/31/20 11:17 PM, Bruce Ashfield wrote:

What configuration is showing this build failure ? All my 5.4 builds
come back green, with yaffs2 enabled. Do you have some different
options enabled ? I'd like to reproduce it locally.

root@qemuarm64:~# uname -a
Linux qemuarm64 5.4.28-yocto-standard #1 SMP PREEMPT Mon Mar 30
14:29:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
root@qemuarm64:~# zcat /proc/config.gz | grep YAFFS2
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
root@qemuarm64:~#

Bruce

On Mon, Mar 30, 2020 at 11:09 PM  wrote:

From: Yanfei Xu 

Signed-off-by: Yanfei Xu 
---
  fs/yaffs2/yaffs_vfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index 4fbd0a42ff3d..7a951baaf043 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -1826,7 +1826,6 @@ static int yaffs_iterate(struct file *f, struct 
dir_context *dc)
 int ret_val = 0;

 char name[YAFFS_MAX_NAME_LENGTH + 1];
-   u64 i_version;

 obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
 dev = obj->my_dev;
@@ -1900,6 +1899,7 @@ static int yaffs_readdir(struct file *f, void *dirent, 
filldir_t filldir)
 int ret_val = 0;

 char name[YAFFS_MAX_NAME_LENGTH + 1];
+   u64 i_version;

 obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
 dev = obj->my_dev;
--
2.18.2




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8570): 
https://lists.yoctoproject.org/g/linux-yocto/message/8570
Mute This Topic: https://lists.yoctoproject.org/mt/72670043/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.4/standard/base][PATCH] fixup! yaffs: Fix build failure by handling inode i_version with proper atomic API

2020-03-31 Thread Xu, Yanfei


Hi Bruce,

Not a build failure, but a compile warning. when I built 
v5.4/standard/xilinx-zynq kernel, It

occured the blow warning in log.do_compile.

/# work-shared/xilinx-zynq/kernel-source/fs/yaffs2/yaffs_vfs.c:1829:6: 
warning: unused variable 'i_version' //[-Wunused-variable]/

/# 1829 | u64 i_version;//^/
/# CC fs/ubifs/replay.o/


Then I took a look at the previous commits about yaffs2 in 
linux-yocto/v5.4/standard/base
kernel and found the yaffs2 code was been updated recently. Some 
defferences about yaffs_readdir（）
in yaffs_vfs.c than before. It causes the following patch[yaffs: Fix 
build failure...1fffb37acca0]
appled 'u64 i_version' at a wrong place. Maybe there is a glable 
i_version variable somewhere，

hence it didn't occur a build failure.

Regards,

Yanfei

On 3/31/20 11:17 PM, Bruce Ashfield wrote:

What configuration is showing this build failure ? All my 5.4 builds
come back green, with yaffs2 enabled. Do you have some different
options enabled ? I'd like to reproduce it locally.

root@qemuarm64:~# uname -a
Linux qemuarm64 5.4.28-yocto-standard #1 SMP PREEMPT Mon Mar 30
14:29:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
root@qemuarm64:~# zcat /proc/config.gz | grep YAFFS2
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
root@qemuarm64:~#

Bruce

On Mon, Mar 30, 2020 at 11:09 PM  wrote:

From: Yanfei Xu 

Signed-off-by: Yanfei Xu 
---
  fs/yaffs2/yaffs_vfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index 4fbd0a42ff3d..7a951baaf043 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -1826,7 +1826,6 @@ static int yaffs_iterate(struct file *f, struct 
dir_context *dc)
 int ret_val = 0;

 char name[YAFFS_MAX_NAME_LENGTH + 1];
-   u64 i_version;

 obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
 dev = obj->my_dev;
@@ -1900,6 +1899,7 @@ static int yaffs_readdir(struct file *f, void *dirent, 
filldir_t filldir)
 int ret_val = 0;

 char name[YAFFS_MAX_NAME_LENGTH + 1];
+   u64 i_version;

 obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
 dev = obj->my_dev;
--
2.18.2



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8568): 
https://lists.yoctoproject.org/g/linux-yocto/message/8568
Mute This Topic: https://lists.yoctoproject.org/mt/72670043/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.4/standard/base][PATCH] fixup! yaffs: Fix build failure by handling inode i_version with proper atomic API

2020-03-30 Thread Xu, Yanfei

From: Yanfei Xu 

Signed-off-by: Yanfei Xu 
---
 fs/yaffs2/yaffs_vfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index 4fbd0a42ff3d..7a951baaf043 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -1826,7 +1826,6 @@ static int yaffs_iterate(struct file *f, struct 
dir_context *dc)
int ret_val = 0;
 
char name[YAFFS_MAX_NAME_LENGTH + 1];
-   u64 i_version;
 
obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
dev = obj->my_dev;
@@ -1900,6 +1899,7 @@ static int yaffs_readdir(struct file *f, void *dirent, 
filldir_t filldir)
int ret_val = 0;
 
char name[YAFFS_MAX_NAME_LENGTH + 1];
+   u64 i_version;
 
obj = yaffs_dentry_to_obj(Y_GET_DENTRY(f));
dev = obj->my_dev;
-- 
2.18.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8566): 
https://lists.yoctoproject.org/g/linux-yocto/message/8566
Mute This Topic: https://lists.yoctoproject.org/mt/72670043/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][yocto-kernel-cache yocto-5.4 master][PATCH] bsp/ti-am65x: remove duplicate config option CONFIG_NETDEVICES

2020-03-23 Thread Xu, Yanfei

From: Yanfei Xu 

CONFIG_NETDEVICES is set twice, remove one of them.

Signed-off-by: Yanfei Xu 
---
 bsp/ti-am65x/ti-am65x.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bsp/ti-am65x/ti-am65x.cfg b/bsp/ti-am65x/ti-am65x.cfg
index ec680ebe..008d388b 100644
--- a/bsp/ti-am65x/ti-am65x.cfg
+++ b/bsp/ti-am65x/ti-am65x.cfg
@@ -94,7 +94,6 @@ CONFIG_USB_DWC3_KEYSTONE=y
 #
 CONFIG_USB_NET_DRIVERS=y
 CONFIG_USB_USBNET=y
-CONFIG_NETDEVICES=y
 CONFIG_USB_NET_AX8817X=y
 
 #
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8544): 
https://lists.yoctoproject.org/g/linux-yocto/message/8544
Mute This Topic: https://lists.yoctoproject.org/mt/72487563/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][yocto-kernel-cache yocto-5.4 master][PATCH] bsp/ti-am335x: drop some invalid cfg options

2020-03-20 Thread Xu, Yanfei

From: Yanfei Xu 

drop TI_DAVINCI_CPDMA option removed from v5.2 kernel
https://github.com/torvalds/linux/commit/99f629718272974405e8d180d2fa70c03c06d61f

drop SND_DAVINCI_SOC_MCASP option removed from v5.0 kernel
https://github.com/torvalds/linux/commit/f2055e145f2975a75dace8e386fad9364828cdb4

drop MMC_UNSAFE_RESUME option removed from v3.16 kernel
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/m
mc/core/Kconfig?h=v3.16.82=2501c9179dff2add6aadd3898cd729e94e777d3a

drop DRM_OMAP_PANEL_DPI option removed from v5.2 kernel.
https://github.com/torvalds/linux/commit/8bf4b1621178ef05bde5b9a14a117ff951dd1260

MTD_NAND option was renamed MTD_RAW_NAND in v5.2 kernel
https://github.com/torvalds/linux/commit/72c5af00272339af6bbed6fe7275cd731f57be2d

MTD_NAND_ECC was renamed MTD_NAND_ECC_SW_HAMMING in v5.2 kernel
https://github.com/torvalds/linux/commit/9bb94643b94115990ffec18c8129f1ab970765c1

drop BACKLIGHT_LCD_SUPPORT option removed from v5.2 kernel
https://github.com/torvalds/linux/commit/8c5dc8d9f19c7992b5ed557b865127a80149041b

drop TI_CPSW_ALE option removed from v5.2 kernel
https://github.com/torvalds/linux/commit/16f54164828b253d7792b67b05c07540f236ece5

drop MMC_BLOCK_BOUNCE removed from v4.13 kernel
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/m
mc/core/Kconfig?h=linux-4.13.y=c3dccb74be28a345a2ebcc224e41b774529b8b8f

Signed-off-by: Yanfei Xu 
---
 bsp/ti-am335x/ti-am335x.cfg | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
index 190cb876..d091279c 100644
--- a/bsp/ti-am335x/ti-am335x.cfg
+++ b/bsp/ti-am335x/ti-am335x.cfg
@@ -64,12 +64,11 @@ CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLKDEVS=y
 CONFIG_MTD_BLOCK=y
-CONFIG_MTD_NAND_ECC=y
+CONFIG_MTD_NAND_ECC_SW_HAMMING=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
@@ -82,9 +81,7 @@ 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
@@ -163,10 +160,8 @@ 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
@@ -179,7 +174,6 @@ 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
 
 
@@ -217,10 +211,8 @@ CONFIG_USB_TI_CPPI41_DMA=y
 # MMC/SD/SDIO Card Drivers
 #
 CONFIG_MMC=y
-CONFIG_MMC_UNSAFE_RESUME=y
 CONFIG_MMC_BLOCK=y
 CONFIG_MMC_BLOCK_MINORS=8
-CONFIG_MMC_BLOCK_BOUNCE=y
 
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8530): 
https://lists.yoctoproject.org/g/linux-yocto/message/8530
Mute This Topic: https://lists.yoctoproject.org/mt/72094803/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/base][PATCH] arm64: dts: ti: k3-am65-mcu:Update the power domain cells

2020-03-20 Thread Xu, Yanfei



On 3/20/20 6:48 AM, Bruce Ashfield wrote:

On Wed, Mar 18, 2020 at 11:44 PM  wrote:

From: Yanfei Xu 

Before the last commit, it updated the power-domain cells to 2.
However, the last commit added some codes without right power-domain
cells.
So, update OSPI power domain cells to 2 here to avoid warning when
compile dts.


This doesn't apply for me, can you double check the latest
linux-yocto-dev standard/base ?


Sorry, I find the linux-yocto-dev standard/base has been fixed about 
this place recently.


Please ignore this patch.

//Yanfei


Bruce


Signed-off-by: Yanfei Xu 
---
  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index e32a7d13a72e..0d6b3d08628c 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -115,7 +115,7 @@
 assigned-clocks = <_clks 55 5>;
 assigned-clock-parents = <_clks 55 7>;
 assigned-clock-rates = <1>;
-   power-domains = <_pds 55>;
+   power-domains = <_pds 55 TI_SCI_PD_EXCLUSIVE>;
 #address-cells = <1>;
 #size-cells = <0>;
 dma-coherent;
@@ -130,7 +130,7 @@
 cdns,fifo-width = <4>;
 cdns,trigger-address = <0x5800>;
 clocks = <_clks 55 16>;
-   power-domains = <_pds 55>;
+   power-domains = <_pds 55 TI_SCI_PD_EXCLUSIVE>;
 #address-cells = <1>;
 #size-cells = <0>;
 dma-coherent;
--
2.18.1



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8533): 
https://lists.yoctoproject.org/g/linux-yocto/message/8533
Mute This Topic: https://lists.yoctoproject.org/mt/72067333/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][yocto-kernel-cache master][PATCH] bsp/nxp-ls20xx: Enable CONFIG_ENERGY_MODEL

2020-03-18 Thread Xu, Yanfei

From: Yanfei Xu 

1)CONFIG_ENERGY_MODEL is a default configure items of arm64
defconfig.
Reference: https://patchwork.kernel.org/patch/10944391/

2)THERMAL_GOV_POWER_ALLOCATOR is set to y in nxp-ls20xx.cfg, but
from v5.5 kernel, the THERMAL_GOV_POWER_ALLOCATOR depends on
ENERGY_MODEL. So we enable it for THERMAL_GOV_POWER_ALLOCATOR
can take effect.
Reference: 
https://github.com/torvalds/linux/commit/a4e893e802e6a807df2e2f3f660f7399bc7e104e

Signed-off-by: Yanfei Xu 
---
 bsp/nxp-ls20xx/nxp-ls20xx.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bsp/nxp-ls20xx/nxp-ls20xx.cfg b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
index 534d0897..36e34e77 100755
--- a/bsp/nxp-ls20xx/nxp-ls20xx.cfg
+++ b/bsp/nxp-ls20xx/nxp-ls20xx.cfg
@@ -25,6 +25,8 @@ CONFIG_PCI_HOST_GENERIC=y
 CONFIG_PCI_XGENE=y
 CONFIG_PCI_MSI=y
 
+CONFIG_ENERGY_MODEL=y
+
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
-- 
2.18.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8521): 
https://lists.yoctoproject.org/g/linux-yocto/message/8521
Mute This Topic: https://lists.yoctoproject.org/mt/72044950/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [kernel-cache][PATCH 2/3] features/intel-pinctrl: remove CONFIG_GPIO_LYNXPOINT

2020-03-17 Thread Xu, Yanfei


Hi Bruce,

I find PINCTRL_LYNXPOINT is actually removed from v5.6 kernel. And v5.4 
kernel

is still using GPIO_LYNXPOINT.

Would you please revert it on v5.4 kernel-cache?
Reference: 
https://github.com/torvalds/linux/commit/eb83479e18999e34b3b800f54aa31137f7f41c33


Thanks,
Yanfei


On 1/21/20 5:43 AM, Bruce Ashfield wrote:

On Sun, Jan 19, 2020 at 9:34 PM Liu, Yongxin  wrote:

Hi Bruce,

I see you also merged this patch to branch yocto-5.2 of kernel-cache.
However, I found no corresponding kernel changes in linux-yocto v5.2.

So, currently kernel v5.2 uses GPIO_LYNXPOINT, and yocto-kernel-cache
uses PINCTRL_LYNXPOINT.

I reverted the change on 5.2, it should be ok now

Bruce



Thanks,
Yongxin


-Original Message-
From: linux-yocto@lists.yoctoproject.org [mailto:linux-
yo...@lists.yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Thursday, January 16, 2020 03:19
To: Tim Orling
Cc: Naveen Saini; Linux Yocto
Subject: Re: [linux-yocto] [kernel-cache][PATCH 2/3] features/intel-
pinctrl: remove CONFIG_GPIO_LYNXPOINT

Sorry for the delay, 5.4 and 5.5 were consuming a lot of my time.

This is now merged. My SRCREV updates will follow, but since you have
your own .. you can pickup the changes whenever you want.

Bruce

On Thu, Jan 9, 2020 at 10:09 PM Tim Orling
 wrote:




On Jan 9, 2020, at 6:12 PM, Naveen Saini

 wrote:

Lynxpoint GPIO driver moved under Intel pin control umbrella for
further transformation to a real pin control driver.

CONFIG_GPIO_LYNXPOINT renamed to PINCTRL_LYNXPOINT

https://github.com/intel/linux-intel-lts/commit/cb81404ffe750270f072
d1fc839a4afe288046f3


Thank you. This was on my TODO list,.


Signed-off-by: Naveen Saini 

Acked-by: Tim Orling 


---
features/intel-pinctrl/intel-pinctrl.cfg | 1 +
features/soc/skylake/skylake.cfg | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/features/intel-pinctrl/intel-pinctrl.cfg
b/features/intel-pinctrl/intel-pinctrl.cfg
index 6d46eec7..406cf3ce 100644
--- a/features/intel-pinctrl/intel-pinctrl.cfg
+++ b/features/intel-pinctrl/intel-pinctrl.cfg
@@ -11,3 +11,4 @@ CONFIG_PINCTRL_DENVERTON=y
CONFIG_PINCTRL_GEMINILAKE=y CONFIG_PINCTRL_ICELAKE=y
CONFIG_PINCTRL_LEWISBURG=y
+CONFIG_PINCTRL_LYNXPOINT=m
diff --git a/features/soc/skylake/skylake.cfg
b/features/soc/skylake/skylake.cfg
index b2140b05..34066635 100644
--- a/features/soc/skylake/skylake.cfg
+++ b/features/soc/skylake/skylake.cfg
@@ -24,7 +24,6 @@ CONFIG_CRC8=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_INTEL=y
CONFIG_USB_EHCI_PCI=y
-CONFIG_GPIO_LYNXPOINT=m

# Other misc support
CONFIG_INTEL_MEI_TXE=m
--
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





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8504): 
https://lists.yoctoproject.org/g/linux-yocto/message/8504
Mute This Topic: https://lists.yoctoproject.org/mt/69593269/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][yocto-kernel-cache yocto-5.4 master][PATCH] bsp/intel-x86: remove invalid config item CRYPTO_AES_X86_64

2020-03-17 Thread Xu, Yanfei

From: Yanfei Xu 

Item CONFIG_CRYPTO_AES_X86_64 has been dropped from v5.4 kernel,
therefore, we drop it too.

Reference: 
https://github.com/torvalds/linux/commit/1d2c3279311e4f03fcf164e1366f2fda9f4bfccf

Signed-off-by: Yanfei Xu 
---
 bsp/intel-x86/intel-x86-64.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg
index e5fcc853..0e03c6de 100644
--- a/bsp/intel-x86/intel-x86-64.cfg
+++ b/bsp/intel-x86/intel-x86-64.cfg
@@ -10,7 +10,6 @@ CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
 #
 CONFIG_X86_64_ACPI_NUMA=y
 CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
-CONFIG_CRYPTO_AES_X86_64=m
 CONFIG_CRYPTO_SHA1_SSSE3=m
 CONFIG_CRYPTO_SHA256_SSSE3=m
 CONFIG_CRYPTO_SHA512_SSSE3=m
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8503): 
https://lists.yoctoproject.org/g/linux-yocto/message/8503
Mute This Topic: https://lists.yoctoproject.org/mt/72019662/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [PATCH 0/1] [v2][linux-yocto][linux-yocto v5.4/standard/preempt-rt] aufs5:fix:avoid to access rw_sem.owner in RT kernel

2020-03-12 Thread Xu, Yanfei


Hi Bruce,

Would you please help merge this patch to preempt branch? This compile 
issue is a bit urgent.


Thanks!
Yanfei
On 3/12/20 12:57 AM, Xu, Yanfei wrote:

is From: Yanfei Xu 

Hi Bruce,

v1--->v2

1. Add a if statement to separately operate the owner member
between standard and RT kernel.

Also I have completed the smoke test about aufs before this email.

Yanfei Xu (1):
   aufs5:fix:avoid to access rw_sem.owner in RT kernel

  fs/aufs/i_op.c | 4 
  1 file changed, 4 insertions(+)



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8480): 
https://lists.yoctoproject.org/g/linux-yocto/message/8480
Mute This Topic: https://lists.yoctoproject.org/mt/71883579/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[PATCH 0/1] [v2][linux-yocto][linux-yocto v5.4/standard/preempt-rt] aufs5:fix:avoid to access rw_sem.owner in RT kernel

2020-03-11 Thread Xu, Yanfei

From: Yanfei Xu 

Hi Bruce,

v1--->v2

1. Add a if statement to separately operate the owner member 
   between standard and RT kernel.

Also I have completed the smoke test about aufs before this email.

Yanfei Xu (1):
  aufs5:fix:avoid to access rw_sem.owner in RT kernel

 fs/aufs/i_op.c | 4 
 1 file changed, 4 insertions(+)

-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8474): 
https://lists.yoctoproject.org/g/linux-yocto/message/8474
Mute This Topic: https://lists.yoctoproject.org/mt/71883579/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 1/1] aufs5:fix:avoid to access rw_sem.owner in RT kernel

2020-03-11 Thread Xu, Yanfei

From: Yanfei Xu 

Fix build failure.

owner member is now made a permanent member of the rw_semaphore in
v5.6 kernel(commitid:c71fd893f). But the rw_semaphore in RT kernel
had been implemented with rt_mutex in rwsem-rt.h. Add if statment
to distinguish the two cases.

-Error messages-
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:
In function 'au_pin_hdir_set_owner':
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:643:45:
error: 'struct rw_semaphore' has no member named 'owner'
|   643 |  atomic_long_set(>hdir->hi_inode->i_rwsem.owner,
(long)task);
|   | ^
|   CC  fs/btrfs/zstd.o
|   AR  fs/kernfs/built-in.a
|   CC  arch/x86/kernel/io_delay.o
|   CC  net/ipv6/udplite.o
| make[3]: ***
[/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/scripts/Makefile.build:265:
fs/aufs/i_op.o] Error 1
| make[3]: *** Waiting for unfinished jobs
--

Signed-off-by: Yanfei Xu 
---
 fs/aufs/i_op.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index ef1e08c7ca10..926795a0101c 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -640,7 +640,11 @@ int au_pin_hdir_relock(struct au_pin *p)
 
 static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
 {
+#if !defined(CONFIG_PREEMPT_RT)
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
+#else
+p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
+#endif
 }
 
 void au_pin_hdir_acquire_nest(struct au_pin *p)
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8475): 
https://lists.yoctoproject.org/g/linux-yocto/message/8475
Mute This Topic: https://lists.yoctoproject.org/mt/71883581/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.4/standard/preempt-rt/base v5.4/standard/preempt-rt/intel-x86 v5.4/standard/preempt-rt/bcm-2xxx-rpi][PATCH] aufs5:fix:avoid to access rw_sem.owner at rt kernel

2020-03-11 Thread Xu, Yanfei



On 3/11/20 12:14 PM, He Zhe wrote:


On 3/10/20 2:50 PM, Xu, Yanfei wrote:

From: Yanfei Xu 

Fix build failure.

Even though owner member is now made a permanent member of the
rw_semaphore. The rw_semaphore in rwsem-rt.h doesn't have owner
field still.

-Error messages-
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:
In function 'au_pin_hdir_set_owner':
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:643:45:
error: 'struct rw_semaphore' has no member named 'owner'
|   643 |  atomic_long_set(>hdir->hi_inode->i_rwsem.owner,
(long)task);
|   | ^
|   CC  fs/btrfs/zstd.o
|   AR  fs/kernfs/built-in.a
|   CC  arch/x86/kernel/io_delay.o
|   CC  net/ipv6/udplite.o
| make[3]: ***
[/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/scripts/Makefile.build:265:
fs/aufs/i_op.o] Error 1
| make[3]: *** Waiting for unfinished jobs
--

Signed-off-by: Yanfei Xu 
---
  fs/aufs/i_op.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index ef1e08c7ca10..b6b316b12144 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -640,7 +640,9 @@ int au_pin_hdir_relock(struct au_pin *p)
  
  static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)

  {
+#if !defined(CONFIG_PREEMPT_RT)
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
+#endif

This doesn't seem to work as it gives a no-op for RT kernel.

The following diff should work, since rwsem in RT kernel had been implemented 
with rt_mutex.
But I haven't validated it.

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index ef1e08c7ca10..37b535d19060 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -640,7 +640,7 @@ int au_pin_hdir_relock(struct au_pin *p)
  
  static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)

  {
-   atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
+   p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
  }


Good suggestion， and I think "#if !defined(CONFIG_PREEMPT_RT)" should be 
reserved to avoid compile


failure if someone compiles a kernel without CONFIG_PREEMPT_RT with 
preempt_rt branchs.


I will send a v2 patch soon.

// Yanfei



  
  void au_pin_hdir_acquire_nest(struct au_pin *p)



Zhe


  }
  
  void au_pin_hdir_acquire_nest(struct au_pin *p)





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8465): 
https://lists.yoctoproject.org/g/linux-yocto/message/8465
Mute This Topic: https://lists.yoctoproject.org/mt/71852365/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.4/standard/preempt-rt/base v5.4/standard/preempt-rt/intel-x86 v5.4/standard/preempt-rt/bcm-2xxx-rpi][PATCH] aufs5:fix:avoid to access rw_sem.owner at rt kernel

2020-03-10 Thread Xu, Yanfei

From: Yanfei Xu 

Fix build failure.

Even though owner member is now made a permanent member of the
rw_semaphore. The rw_semaphore in rwsem-rt.h doesn't have owner
field still.

-Error messages-
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:
In function 'au_pin_hdir_set_owner':
|
/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/fs/aufs/i_op.c:643:45:
error: 'struct rw_semaphore' has no member named 'owner'
|   643 |  atomic_long_set(>hdir->hi_inode->i_rwsem.owner,
(long)task);
|   | ^
|   CC  fs/btrfs/zstd.o
|   AR  fs/kernfs/built-in.a
|   CC  arch/x86/kernel/io_delay.o
|   CC  net/ipv6/udplite.o
| make[3]: ***
[/buildarea1/nightly/WRLINUX_MASTER_WR/build_dir/OVP/GIT_202003/lxbuilds/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build_linux/tmp-glibc/work-shared/intel-x86-64/kernel-source/scripts/Makefile.build:265:
fs/aufs/i_op.o] Error 1
| make[3]: *** Waiting for unfinished jobs
--

Signed-off-by: Yanfei Xu 
---
 fs/aufs/i_op.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index ef1e08c7ca10..b6b316b12144 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -640,7 +640,9 @@ int au_pin_hdir_relock(struct au_pin *p)
 
 static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
 {
+#if !defined(CONFIG_PREEMPT_RT)
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
+#endif
 }
 
 void au_pin_hdir_acquire_nest(struct au_pin *p)
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8448): 
https://lists.yoctoproject.org/g/linux-yocto/message/8448
Mute This Topic: https://lists.yoctoproject.org/mt/71852365/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] temp: mips: undo vdso reverts

2020-03-04 Thread Xu, Yanfei


Thanks for your imformation. I have tested it that apply this
commit to linux-yocto-dev and it works well.
Will you apply it to linux-yocto-dev too?

Regards,
//Yanfei
On 3/4/20 12:01 AM, Bruce Ashfield wrote:

On Tue, Mar 3, 2020 at 10:30 AM Xu, Yanfei  wrote:

OK！ So If I understand correctly, this failure will disappear after you bring

the Makefile patch to linux-yocto recently？

It is there, and passing all of our autobuilder tests (or we never
would have made 5.4 the default for qemu*).

It is currently on all the v5.4 branches:

commit 239eea7ef5dd5ec7ce6712ea6fc8e9ba9bd49ece
Author: Victor Kamensky 
Date:   Fri Jan 31 09:39:44 2020 -0800

 mips: vdso: fix 'jalr $t9' crash in vdso code

 Observed that when kernel is built with Yocto mips64-poky-linux-gcc,
 and mips64-poky-linux-gnun32-gcc toolchain, resuling vdso contains
 'jalr $t9' instructions in its code and since in vdso case nobody
 sets GOT table code crashes when instruction reached. On other hand
 observed that when kernel is built mips-poky-linux-gcc toolchain, the
 same 'jalr $t9' instruction are replaced with PC relative function
 calls using 'bal' instructions.

 The difference boils down to -mrelax-pic-calls and -mexplicit-relocs
 gcc options that gets different default values depending on gcc
 target triplets and corresponding binutils. -mrelax-pic-calls got
 enabled by default only in mips-poky-linux-gcc case. MIPS binuitls
 ld relies on R_MIPS_JALR relocation to convert 'jalr $t9' into 'bal'
 and such relocation is generated only if -mrelax-pic-calls option
 is on.

 Solution call out -mrelax-pic-calls and -mexplicit-relocs options
 explicitely while compiling MIPS vdso code. That would get correct
 and consitent between different toolchains behavior.

 Reported-by: Bruce Ashfield 
 Signed-off-by: Victor Kamensky 

:100644 100644 996a934ece7d 25b5adee5ade M  arch/mips/vdso/Makefile

Cheers,

Bruce



Regards，

Yanfei


On 3/3/20 10:09 PM, Bruce Ashfield wrote:

On Tue, Mar 3, 2020 at 5:44 AM Xu, Yanfei  wrote:

Hi Bruce,

Do you still remember this issue about vDSO of mips boot failure.The
linux-yocto-dev

still have this problem, even though the mips kernel have some fixes
after that.

Any new progress in it？

Yes, it is fixed in both mainline and linux-yocto itself. It turned
out to be a code generation issue, and I'm carrying a Makefile patch
to address it in linux-yocto.

Bruce


Regards，

Yanfei


On 3/3/20 5:28 PM, He Zhe wrote:

FYI


 Forwarded Message 
Subject:  Re: temp: mips: undo vdso reverts
Date: Fri, 20 Dec 2019 15:41:41 -0500
From: Bruce Ashfield 
To:   He Zhe 



FYI: I managed to get it booting today. I have a hack/temp patch that
I'm cleaning up now.

Bruce

On Fri, Dec 20, 2019 at 5:31 AM He Zhe  wrote:

Thanks for your effort and information.

Zhe

On 12/20/19 6:17 AM, Bruce Ashfield wrote:

On Thu, Dec 19, 2019 at 8:45 AM Bruce Ashfield  wrote:

On Thu, Dec 19, 2019 at 5:28 AM He Zhe  wrote:

Hi Bruce,

I saw your "temp: mips: undo vdso reverts". Any trick in it solving the boot 
failure before the revert? Though I haven't finished the validation. Thanks.

I had to step away from it for a couple of weeks, but am back
debugging the problem now.

I still don't have a solution to booting with those reverts undone.

I emailed the mips kernel mailing list, since I can see this with a
pure mainline kernel, and linux-yocto-dev. But no one was able to
reproduce the problem there, and the idea was that this was
configuration related.

I haven't isolated any config option that is causing this (but yes,
there are those VDSO changes in 5.4+) .. I still say that if a new
option was created, and it has a default that breaks the boot ..
that's a bug .. but I haven't proven that yet.

I'll email again at the end of my day with an update on my progress.

The upstream mips developers suggested that GENERIC_COMPAT_VDSO needs
to be set, but isn't in our .config .. since that isn't an option that
can be specified in a fragment, I forced it on in my local builds.

The result is the same, an immediate segfault on hand over to userspace.

I'm currently hacking gettimeofday() to isolate the issue and will do
more on Friday.

Bruce

Bruce

[   22.850343] Run /sbin/init as init process
[   23.355137] do_page_fault(): sending SIGSEGV to init for invalid read access 
from 0330
[   23.484206] epc = 0330 in systemd[aaab5ce000+12e000]
[   23.546202] ra  = 00fffd95c4fc in
[   23.616964] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   23.748041] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b ]---

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







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to thi

Re: [linux-yocto] temp: mips: undo vdso reverts

2020-03-03 Thread Xu, Yanfei

OK！ So If I understand correctly, this failure will disappear after you 
bring


the Makefile patch to linux-yocto recently？


Regards，

Yanfei


On 3/3/20 10:09 PM, Bruce Ashfield wrote:

On Tue, Mar 3, 2020 at 5:44 AM Xu, Yanfei  wrote:

Hi Bruce,

Do you still remember this issue about vDSO of mips boot failure.The
linux-yocto-dev

still have this problem, even though the mips kernel have some fixes
after that.

Any new progress in it？

Yes, it is fixed in both mainline and linux-yocto itself. It turned
out to be a code generation issue, and I'm carrying a Makefile patch
to address it in linux-yocto.

Bruce



Regards，

Yanfei


On 3/3/20 5:28 PM, He Zhe wrote:

FYI


 Forwarded Message 
Subject:  Re: temp: mips: undo vdso reverts
Date: Fri, 20 Dec 2019 15:41:41 -0500
From: Bruce Ashfield 
To:   He Zhe 



FYI: I managed to get it booting today. I have a hack/temp patch that
I'm cleaning up now.

Bruce

On Fri, Dec 20, 2019 at 5:31 AM He Zhe  wrote:

Thanks for your effort and information.

Zhe

On 12/20/19 6:17 AM, Bruce Ashfield wrote:

On Thu, Dec 19, 2019 at 8:45 AM Bruce Ashfield  wrote:

On Thu, Dec 19, 2019 at 5:28 AM He Zhe  wrote:

Hi Bruce,

I saw your "temp: mips: undo vdso reverts". Any trick in it solving the boot 
failure before the revert? Though I haven't finished the validation. Thanks.


I had to step away from it for a couple of weeks, but am back
debugging the problem now.

I still don't have a solution to booting with those reverts undone.

I emailed the mips kernel mailing list, since I can see this with a
pure mainline kernel, and linux-yocto-dev. But no one was able to
reproduce the problem there, and the idea was that this was
configuration related.

I haven't isolated any config option that is causing this (but yes,
there are those VDSO changes in 5.4+) .. I still say that if a new
option was created, and it has a default that breaks the boot ..
that's a bug .. but I haven't proven that yet.

I'll email again at the end of my day with an update on my progress.

The upstream mips developers suggested that GENERIC_COMPAT_VDSO needs
to be set, but isn't in our .config .. since that isn't an option that
can be specified in a fragment, I forced it on in my local builds.

The result is the same, an immediate segfault on hand over to userspace.

I'm currently hacking gettimeofday() to isolate the issue and will do
more on Friday.

Bruce


Bruce


[   22.850343] Run /sbin/init as init process
[   23.355137] do_page_fault(): sending SIGSEGV to init for invalid read access 
from 0330
[   23.484206] epc = 0330 in systemd[aaab5ce000+12e000]
[   23.546202] ra  = 00fffd95c4fc in
[   23.616964] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   23.748041] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b ]---

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





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8432): 
https://lists.yoctoproject.org/g/linux-yocto/message/8432
Mute This Topic: https://lists.yoctoproject.org/mt/71697594/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] temp: mips: undo vdso reverts

2020-03-03 Thread Xu, Yanfei


Hi Bruce,

Do you still remember this issue about vDSO of mips boot failure.The 
linux-yocto-dev


still have this problem, even though the mips kernel have some fixes 
after that.


Any new progress in it？


Regards，

Yanfei


On 3/3/20 5:28 PM, He Zhe wrote:

FYI


 Forwarded Message 
Subject:Re: temp: mips: undo vdso reverts
Date:   Fri, 20 Dec 2019 15:41:41 -0500
From:   Bruce Ashfield 
To: He Zhe 



FYI: I managed to get it booting today. I have a hack/temp patch that
I'm cleaning up now.

Bruce

On Fri, Dec 20, 2019 at 5:31 AM He Zhe  wrote:

Thanks for your effort and information.

Zhe

On 12/20/19 6:17 AM, Bruce Ashfield wrote:

On Thu, Dec 19, 2019 at 8:45 AM Bruce Ashfield  wrote:

On Thu, Dec 19, 2019 at 5:28 AM He Zhe  wrote:

Hi Bruce,

I saw your "temp: mips: undo vdso reverts". Any trick in it solving the boot 
failure before the revert? Though I haven't finished the validation. Thanks.


I had to step away from it for a couple of weeks, but am back
debugging the problem now.

I still don't have a solution to booting with those reverts undone.

I emailed the mips kernel mailing list, since I can see this with a
pure mainline kernel, and linux-yocto-dev. But no one was able to
reproduce the problem there, and the idea was that this was
configuration related.

I haven't isolated any config option that is causing this (but yes,
there are those VDSO changes in 5.4+) .. I still say that if a new
option was created, and it has a default that breaks the boot ..
that's a bug .. but I haven't proven that yet.

I'll email again at the end of my day with an update on my progress.

The upstream mips developers suggested that GENERIC_COMPAT_VDSO needs
to be set, but isn't in our .config .. since that isn't an option that
can be specified in a fragment, I forced it on in my local builds.

The result is the same, an immediate segfault on hand over to userspace.

I'm currently hacking gettimeofday() to isolate the issue and will do
more on Friday.

Bruce


Bruce


[   22.850343] Run /sbin/init as init process
[   23.355137] do_page_fault(): sending SIGSEGV to init for invalid read access 
from 0330
[   23.484206] epc = 0330 in systemd[aaab5ce000+12e000]
[   23.546202] ra  = 00fffd95c4fc in
[   23.616964] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   23.748041] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b ]---

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




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8430): 
https://lists.yoctoproject.org/g/linux-yocto/message/8430
Mute This Topic: https://lists.yoctoproject.org/mt/71697594/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[V2][linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] features: avoid enabling edac for most of mips boards

2019-12-06 Thread Xu, Yanfei

From: Yanfei Xu 

When some layer include the edac feature and bitbake kernel ARCH
=mips, that will cause some warning masseges.

CONFIG_EDAC and CONFIG_EDAC_DEBUG depend on CONFIG_EDAC_SUPPORT,
but CONFIG_EDAC_SUPPORT isn't enabled in most of mips boards(except
CAVIUM_OCTEON_SOC, and edgerouter board is based on CAVIUM_OCTEON_SOC.)

Signed-off-by: Yanfei Xu 
---
 features/edac/edac-enable.scc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/features/edac/edac-enable.scc b/features/edac/edac-enable.scc
index c60d2790..17daf486 100644
--- a/features/edac/edac-enable.scc
+++ b/features/edac/edac-enable.scc
@@ -2,4 +2,6 @@
 define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
 define KFEATURE_COMPATIBILITY board
 
-kconf hardware edac.cfg
+if [ "$KARCH" != "mips" ] || [ "$KMACHINE" = "edgerouter" ]; then
+kconf hardware edac.cfg
+fi
-- 
2.23.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8179): 
https://lists.yoctoproject.org/g/linux-yocto/message/8179
Mute This Topic: https://lists.yoctoproject.org/mt/67466198/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] features: avoid enabling edac feature in mips

2019-12-05 Thread Xu, Yanfei



On 12/3/19 11:14 PM, Bruce Ashfield wrote:

On Tue, Dec 3, 2019 at 4:38 AM Xu, Yanfei  wrote:


On 12/2/19 12:28 PM, Bruce Ashfield wrote:

In message: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] features: 
avoid enabling edac feature in mips
on 27/11/2019 yanfei...@windriver.com wrote:

From: Yanfei Xu 

When some layer include this edac feature and bitbake kernel ARCH
=mips, that will cause some warning masseges.

CONFIG_EDAC and CONFIG_EDAC_DEBUG depend on CONFIG_EDAC_SUPPORT,
but CONFIG_EDAC_SUPPORT isn't enabled in most of mips bsps(except
CAVIUM_OCTEON_SOC, however CAVIUM_OCTEON_SOC is not defined in
bsps)

Signed-off-by: Yanfei Xu 
---
  features/edac/edac-enable.scc | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/features/edac/edac-enable.scc b/features/edac/edac-enable.scc
index c60d2790..f9a56af0 100644
--- a/features/edac/edac-enable.scc
+++ b/features/edac/edac-enable.scc
@@ -1,5 +1,7 @@
  # SPDX-License-Identifier: MIT
-define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
-define KFEATURE_COMPATIBILITY board
+if [ "$KARCH" != "mips" ]; then
+define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
+define KFEATURE_COMPATIBILITY board

We should leave the feature descriptions outside of the if statement.

Yes, you are right.

That being said, this fragment isn't included directly by any of the common
features/kernel types or other fragments.

We already have the compatibility tagged as "board", so really, only boards
with the right hardware should be including this fragment. Which leads me
to this question: how is this feature being included by those mips boards ?
Is it via KERNEL_FEATURES or some other mechanism ?

We include this feature via KERNEL_FEATURES.

I have a qestion about KFEATURE_COMPATIBILITY. Is this tag only a prompt for
user when using the features that contained KFEATURE_COMPATIBILITY? (Because I
didn't find any file that parses it.)
If that, I am agree with you that we should do an exclude on layers with
referencing KFEATURE_COMPATIBILITY.

There are (old) tools that used to use the values in those variables
to present kernel configuration options to a developer.  We could
start using them again in a more direct way, but as they currently
stand they are mostly documentation and a reference in the kernel
configuration meta-data.

So I'm good with these being fixed in two places, both in the
meta-data with the if based exclusion and also in the boards using a
architecture based bitbake OVERRIDE variable to not include the
feature for mips boards.

Bruce


Thanks for your suggestion. Now I have fixed it, both in meta-data and in
our mips boards meta-data. The new patch has been sent to you.
 
V1-->V2:

1.leave the feature descriptions outside of if statement.
2.add a situation in if statement to allow edgerouter to be configured
with edac. Because edgerouter is based on CAVIUM_OCTEON_SOC.

Yanfei


Yanfei

The reason I ask, is that we should probably do an architecture level
exclude on those boards/layers versus adding an if statement to the
feature fragment (or best case, it should be done in both places).

Bruce


-kconf hardware edac.cfg
+kconf hardware edac.cfg
+fi
--
2.23.0



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8178): 
https://lists.yoctoproject.org/g/linux-yocto/message/8178
Mute This Topic: https://lists.yoctoproject.org/mt/63635414/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] features: avoid enabling edac feature in mips

2019-12-03 Thread Xu, Yanfei



On 12/2/19 12:28 PM, Bruce Ashfield wrote:

In message: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] features: 
avoid enabling edac feature in mips
on 27/11/2019 yanfei...@windriver.com wrote:


From: Yanfei Xu 

When some layer include this edac feature and bitbake kernel ARCH
=mips, that will cause some warning masseges.

CONFIG_EDAC and CONFIG_EDAC_DEBUG depend on CONFIG_EDAC_SUPPORT,
but CONFIG_EDAC_SUPPORT isn't enabled in most of mips bsps(except
CAVIUM_OCTEON_SOC, however CAVIUM_OCTEON_SOC is not defined in
bsps)

Signed-off-by: Yanfei Xu 
---
  features/edac/edac-enable.scc | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/features/edac/edac-enable.scc b/features/edac/edac-enable.scc
index c60d2790..f9a56af0 100644
--- a/features/edac/edac-enable.scc
+++ b/features/edac/edac-enable.scc
@@ -1,5 +1,7 @@
  # SPDX-License-Identifier: MIT
-define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
-define KFEATURE_COMPATIBILITY board
+if [ "$KARCH" != "mips" ]; then
+define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
+define KFEATURE_COMPATIBILITY board

We should leave the feature descriptions outside of the if statement.


Yes, you are right.



That being said, this fragment isn't included directly by any of the common
features/kernel types or other fragments.

We already have the compatibility tagged as "board", so really, only boards
with the right hardware should be including this fragment. Which leads me
to this question: how is this feature being included by those mips boards ?
Is it via KERNEL_FEATURES or some other mechanism ?


We include this feature via KERNEL_FEATURES.

I have a qestion about KFEATURE_COMPATIBILITY. Is this tag only a prompt for
user when using the features that contained KFEATURE_COMPATIBILITY? (Because I
didn't find any file that parses it.)
If that, I am agree with you that we should do an exclude on layers with
referencing KFEATURE_COMPATIBILITY.

Yanfei



The reason I ask, is that we should probably do an architecture level
exclude on those boards/layers versus adding an if statement to the
feature fragment (or best case, it should be done in both places).

Bruce

  
-kconf hardware edac.cfg

+kconf hardware edac.cfg
+fi
--
2.23.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8163): 
https://lists.yoctoproject.org/g/linux-yocto/message/8163
Mute This Topic: https://lists.yoctoproject.org/mt/63635414/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

52 matches

Mail list logo