[linux-yocto] ARM: 8918/2: only build return_address() if needed
Hi Bruce,
fb033c95c94c ("ARM: 8918/2: only build return_address() if needed") fixing a
build warning is now on standard/base and v5.5/standard/base. Could you please
merge it to v5.4/standard/base too?
Zhe
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8573):
https://lists.yoctoproject.org/g/linux-yocto/message/8573
Mute This Topic: https://lists.yoctoproject.org/mt/72718459/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.2.x - stable updates comprising v5.2.36
On Wed, Apr 1, 2020 at 12:12 PM Paul Gortmaker wrote: > > Bruce, Yocto kernel folks: > > Here is the next 5.2.x stable update "extension" primarily created for > the Yocto project, as the 15th v5.2.x post-EOL release. > > The content is from an audit of what went into the v5.4.12 and v5.4.13 > releases - which left about 300 mainline commits for consideration. > > There are about 200 commits deployed here that were applicable for > this v5.2.36 release - so roughly 2/3 or 66% of the 5.4.x candidates. > Not surprising, as the 5.4-stable will statistically contain more > post-v5.2 content than our previous v5.3-stable source. > > I've put this 5.2.36 queue through the usual testing; build testing on > x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and > finally some sanity runtime tests on x86-64. > > Please find commit ID 5cb31ea41dc6f6c001a043a748a31e523bb54c2d as > the current head of linux-5.2.y branch in the repo in the kernel.org > directory here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git/?h=linux-5.2.y > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git > > for merge to standard/base in linux-yocto-5.2 and then out from there > into the other base and BSP branches. merged! Bruce > > For those who are interested, the evolution of the commits is here: > > https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-5.2.git/ > > This repo isn't needed for anything; it just exists for transparency and > so people can see the evolution of the raw commits that were originally > selected to create this 5.2.x release. > > Paul. -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8572): https://lists.yoctoproject.org/g/linux-yocto/message/8572 Mute This Topic: https://lists.yoctoproject.org/mt/72704426/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.2.x - stable updates comprising v5.2.36
Bruce, Yocto kernel folks: Here is the next 5.2.x stable update "extension" primarily created for the Yocto project, as the 15th v5.2.x post-EOL release. The content is from an audit of what went into the v5.4.12 and v5.4.13 releases - which left about 300 mainline commits for consideration. There are about 200 commits deployed here that were applicable for this v5.2.36 release - so roughly 2/3 or 66% of the 5.4.x candidates. Not surprising, as the 5.4-stable will statistically contain more post-v5.2 content than our previous v5.3-stable source. I've put this 5.2.36 queue through the usual testing; build testing on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and finally some sanity runtime tests on x86-64. Please find commit ID 5cb31ea41dc6f6c001a043a748a31e523bb54c2d as the current head of linux-5.2.y branch in the repo in the kernel.org directory here: https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git/?h=linux-5.2.y git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git for merge to standard/base in linux-yocto-5.2 and then out from there into the other base and BSP branches. For those who are interested, the evolution of the commits is here: https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-5.2.git/ This repo isn't needed for anything; it just exists for transparency and so people can see the evolution of the raw commits that were originally selected to create this 5.2.x release. Paul. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8571): https://lists.yoctoproject.org/g/linux-yocto/message/8571 Mute This Topic: https://lists.yoctoproject.org/mt/72704426/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
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
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. 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 > > -- - 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 (#8569): https://lists.yoctoproject.org/g/linux-yocto/message/8569 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] -=-=-=-=-=-=-=-=-=-=-=-
