Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
On Tue, 20 Nov 2018 at 14:29, Peter Kjellerstedt
wrote:
> Actually, why mess with an unnecessary meta package. Just use the
> empty ${PN} package for that. That works for the GStreamer packages
> as well these days (since commit 8e1009a3), even though they do it
> by depending on the meta packages for backwards compatibility.
Yes, please.
Having a u-boot-tools-meta will mean we're constantly explaining why
installing u-boot-tools either doesn't install anything, or produces
an error.
Ross
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
(hit sent too early) Of course how big are these tools, and is it really useful splitting them up? If we're talking a 10k binary, is putting them in separate packages worth the complication? Ross ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Otavio Salvador
> Sent: den 19 november 2018 20:22
> To: Tom Rini
> Cc: Marek Vasut ; linux-snps-arc@lists.infradead.org;
> Alexey Brodkin ; Otavio Salvador
> ; Patches and discussions about the oe-core
> layer
> Subject: Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
>
> On Mon, Nov 19, 2018 at 5:08 PM Tom Rini wrote:
> >
> > On Mon, Nov 19, 2018 at 01:51:41PM +0100, Marek Vasut wrote:
> > > On 11/19/2018 11:04 AM, Alexey Brodkin wrote:
> > > > This utility is used for creation of images containing
> > > > usable in run-time U-Boot environment.
> > > >
> > > > As of today this utility is added per-board like here [1]
> > > > for Intel Edison board.
> > > >
> > > > [1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-
> edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-
> tools_2014.04.bb
> > > >
> > > > Given there're quite some U-Boot tools that we may want to add
> later
> > > > this recipe name switch from "u-boot-mkimage" to generic "u-boot-
> tools"
> > > > still for compatibility we provide "u-boot-mkimage" with help
> > > > of PROVIDES as well as proposed "u-boot-mkenvimage".
> > > >
> > > > Signed-off-by: Alexey Brodkin
> > > > Cc: Richard Purdie
> > > > Cc: Otavio Salvador
> > > > Cc: Martin Jansa
> > > > Cc: Ross Burton
> > > > Cc: Marek Vasut
> > >
> > > Do we want to generate one package per tool or not ?
> >
> > I think so, yes. Not all places will want all tools.
>
> And a bonus to add a u-boot-tools-meta which rdepends on all. You can
> copy code to do that from gstreamer-plugins packages.
Actually, why mess with an unnecessary meta package. Just use the
empty ${PN} package for that. That works for the GStreamer packages
as well these days (since commit 8e1009a3), even though they do it
by depending on the meta packages for backwards compatibility.
//Peter
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
On Tue, Nov 20, 2018 at 1:40 PM Burton, Ross wrote: > > (hit sent too early) > > Of course how big are these tools, and is it really useful splitting > them up? If we're talking a 10k binary, is putting them in separate > packages worth the complication? I think it makes sense to split; we are building an embedded system build system and granular installation is a must have. Using PN to install all tools is a win win combination. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
On Tue, Nov 20, 2018 at 01:48:40PM -0200, Otavio Salvador wrote: > On Tue, Nov 20, 2018 at 1:40 PM Burton, Ross wrote: > > > > (hit sent too early) > > > > Of course how big are these tools, and is it really useful splitting > > them up? If we're talking a 10k binary, is putting them in separate > > packages worth the complication? > > I think it makes sense to split; we are building an embedded system > build system and granular installation is a must have. Using PN to > install all tools is a win win combination. Agreed. The common use cases won't need all of the possible tools so lets not grow sizes we don't need to grow. -- Tom signature.asc Description: PGP signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
Hi Otavio, > -Original Message- > From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] > Sent: Tuesday, November 20, 2018 6:49 PM > To: Burton, Ross > Cc: Peter Kjellerstedt ; Marek Vasut > ; Tom Rini ; Otavio > Salvador ; Alexey Brodkin > ; Patches and discussions about the oe-core > layer ; > linux-snps-arc@lists.infradead.org > Subject: Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool > > On Tue, Nov 20, 2018 at 1:40 PM Burton, Ross wrote: > > > > (hit sent too early) > > > > Of course how big are these tools, and is it really useful splitting > > them up? If we're talking a 10k binary, is putting them in separate > > packages worth the complication? > > I think it makes sense to split; we are building an embedded system > build system and granular installation is a must have. Using PN to > install all tools is a win win combination. Please note we're discussing _host_ tools here! So do we really care if there's one more utility installed on development host? And if someone installs those U-Boot host utilities on the target then most probably this target is not super embedded any longer. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: [devboards] Add support of NFSv3 ACL
By default NFSv3 doesn't support ACL (Access Control Lists) which might be quite convenient to have so that mounted NFS behaves exactly as any other local file-system. In particular missing support of ACL makes umask useless. This among other thigs fixes Glibc's "nptl/tst-umask1". Signed-off-by: Alexey Brodkin Cc: Cupertino Miranda Cc: sta...@vger.kernel.org --- arch/arc/configs/axs101_defconfig | 1 + arch/arc/configs/axs103_defconfig | 1 + arch/arc/configs/axs103_smp_defconfig | 1 + arch/arc/configs/hsdk_defconfig| 1 + arch/arc/configs/nps_defconfig | 1 + arch/arc/configs/nsimosci_defconfig| 1 + arch/arc/configs/nsimosci_hs_defconfig | 1 + arch/arc/configs/nsimosci_hs_smp_defconfig | 1 + arch/arc/configs/vdk_hs38_defconfig| 1 + arch/arc/configs/vdk_hs38_smp_defconfig| 1 + 10 files changed, 10 insertions(+) diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig index 41bc08be6a3b..8c23bd086cd0 100644 --- a/arch/arc/configs/axs101_defconfig +++ b/arch/arc/configs/axs101_defconfig @@ -95,6 +95,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig index 1e1c4a8011b5..666314fffc60 100644 --- a/arch/arc/configs/axs103_defconfig +++ b/arch/arc/configs/axs103_defconfig @@ -94,6 +94,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig index 6b0c0cfd5c30..429832b8560b 100644 --- a/arch/arc/configs/axs103_smp_defconfig +++ b/arch/arc/configs/axs103_smp_defconfig @@ -97,6 +97,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig index 1dec2b4bc5e6..2a1d2cbfee1a 100644 --- a/arch/arc/configs/hsdk_defconfig +++ b/arch/arc/configs/hsdk_defconfig @@ -65,6 +65,7 @@ CONFIG_EXT3_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig index 31ba224bbfb4..ae7a0d8be98d 100644 --- a/arch/arc/configs/nps_defconfig +++ b/arch/arc/configs/nps_defconfig @@ -73,6 +73,7 @@ CONFIG_PROC_KCORE=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_ROOT_NFS=y CONFIG_DEBUG_INFO=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/nsimosci_defconfig b/arch/arc/configs/nsimosci_defconfig index f14eeff7d308..ad77f20e5aa6 100644 --- a/arch/arc/configs/nsimosci_defconfig +++ b/arch/arc/configs/nsimosci_defconfig @@ -66,5 +66,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set diff --git a/arch/arc/configs/nsimosci_hs_defconfig b/arch/arc/configs/nsimosci_hs_defconfig index 025298a48305..1638e5bc9672 100644 --- a/arch/arc/configs/nsimosci_hs_defconfig +++ b/arch/arc/configs/nsimosci_hs_defconfig @@ -65,5 +65,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set diff --git a/arch/arc/configs/nsimosci_hs_smp_defconfig b/arch/arc/configs/nsimosci_hs_smp_defconfig index df7b77b13b82..11cfbdb0f441 100644 --- a/arch/arc/configs/nsimosci_hs_smp_defconfig +++ b/arch/arc/configs/nsimosci_hs_smp_defconfig @@ -76,6 +76,7 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_TMPFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FTRACE=y diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig index db47c3541f15..1e59a2e9c602 100644 --- a/arch/arc/configs/vdk_hs38_defconfig +++ b/arch/arc/configs/vdk_hs38_defconfig @@ -85,6 +85,7 @@ CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_ENABLE_WARN_DEPRECATED is not set diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig index a8ac5e917d9a..b5c3f6c54b03 100644 --- a/arch/arc/configs/vdk_hs38_smp_defconfig +++ b/arch/arc/configs/vdk_hs38_smp_defconfig @@ -90,6 +90,7 @@ CONFIG_NTFS_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y CO
Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
On Tue, Nov 20, 2018 at 1:52 PM Alexey Brodkin wrote: > > -Original Message- > > From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] > > Sent: Tuesday, November 20, 2018 6:49 PM > > To: Burton, Ross > > Cc: Peter Kjellerstedt ; Marek Vasut > > ; Tom Rini ; Otavio > > Salvador ; Alexey Brodkin > > ; Patches and discussions about the oe-core > > layer ; > > linux-snps-arc@lists.infradead.org > > Subject: Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool > > > > On Tue, Nov 20, 2018 at 1:40 PM Burton, Ross wrote: > > > > > > (hit sent too early) > > > > > > Of course how big are these tools, and is it really useful splitting > > > them up? If we're talking a 10k binary, is putting them in separate > > > packages worth the complication? > > > > I think it makes sense to split; we are building an embedded system > > build system and granular installation is a must have. Using PN to > > install all tools is a win win combination. > > Please note we're discussing _host_ tools here! > So do we really care if there's one more utility installed on development > host? > > And if someone installs those U-Boot host utilities on the target then most > probably > this target is not super embedded any longer. The tools are commonly used on host but this is not a limitation and there are use cases where we may want to include it on target. Also, it can be installed on SDK (nativesdk packages) and being able to install what will be used is a must for me. I am not concerned about the space used by it but for the choice of me pick the right pieces I need, and not putting it all together. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool
On 11/20/2018 04:52 PM, Alexey Brodkin wrote: > Hi Otavio, > >> -Original Message- >> From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] >> Sent: Tuesday, November 20, 2018 6:49 PM >> To: Burton, Ross >> Cc: Peter Kjellerstedt ; Marek Vasut >> ; Tom Rini ; Otavio >> Salvador ; Alexey Brodkin >> ; Patches and discussions about the oe-core >> layer ; >> linux-snps-arc@lists.infradead.org >> Subject: Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool >> >> On Tue, Nov 20, 2018 at 1:40 PM Burton, Ross wrote: >>> >>> (hit sent too early) >>> >>> Of course how big are these tools, and is it really useful splitting >>> them up? If we're talking a 10k binary, is putting them in separate >>> packages worth the complication? >> >> I think it makes sense to split; we are building an embedded system >> build system and granular installation is a must have. Using PN to >> install all tools is a win win combination. > > Please note we're discussing _host_ tools here! > So do we really care if there's one more utility installed on development > host? > > And if someone installs those U-Boot host utilities on the target then most > probably > this target is not super embedded any longer. You can use mkenvimage on target, I had to do that a few times. -- Best regards, Marek Vasut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3] u-boot: Add mkenvimage tool
On Mon, 2018-11-19 at 13:04 +0300, Alexey Brodkin wrote: > This utility is used for creation of images containing > usable in run-time U-Boot environment. > > As of today this utility is added per-board like here [1] > for Intel Edison board. > > [1] > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb > > Given there're quite some U-Boot tools that we may want to add later > this recipe name switch from "u-boot-mkimage" to generic "u-boot- > tools" > still for compatibility we provide "u-boot-mkimage" with help > of PROVIDES as well as proposed "u-boot-mkenvimage". > > Signed-off-by: Alexey Brodkin > Cc: Richard Purdie > Cc: Otavio Salvador > Cc: Martin Jansa > Cc: Ross Burton > Cc: Marek Vasut > --- I know others are talking about splitting the packaging and I'm ok with deferring that to a separate patch. This patch did break the build in oe-selftest as you renamed a recipe and didn't update conf/distro/include/maintainers.inc. Could you send a new version with that tweak please? (grep https://autobuilder.yoctoproject.org/typhoon/#/builders/28/builds/242/steps/7/logs/step2d for the recipe name to see the test that failed) Cheers, Richard ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v4] u-boot: Add mkenvimage tool
This utility is used for creation of images containing
usable in run-time U-Boot environment.
As of today this utility is added per-board like here [1]
for Intel Edison board.
[1]
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb
Given there're quite some U-Boot tools that we may want to add later
this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
still for compatibility we provide "u-boot-mkimage" with help
of PROVIDES as well as proposed "u-boot-mkenvimage".
Signed-off-by: Alexey Brodkin
Cc: Richard Purdie
Cc: Otavio Salvador
Cc: Martin Jansa
Cc: Ross Burton
Cc: Marek Vasut
---
I may "git grep u-boot-mkimage" in more places:
1. meta/classes/image_types.bbclass:311:CONVERSION_DEPENDS_u-boot =
"u-boot-mkimage-native"
2. meta/classes/kernel-fitimage.bbclass:7:depends = "%s
u-boot-mkimage-native dtc-native" % depends
3. meta/classes/kernel-uimage.bbclass:6:depends = "%s
u-boot-mkimage-native" % depends
4.
meta/conf/distro/include/distro_alias.inc:357:DISTRO_PN_ALIAS_pn-u-boot-mkimage
= "Ubuntu=uboot-mkimage Debian=uboot-mkimage"
But that's not clear for me if it's required to swap "u-boot-mkimage"
to "u-boot-tools" see:
1. "u-boot-mkimage" is still a valid recipe as we export ot via PROVIDES
(or I'm mixing package name with recipe name which very well might be
the case)
2. I don't fully understand a mening of "DISTRO_PN_ALIAS".
If that's a name of a package from some big Linux distro or how target
utility is named in that distro. For example in Debian Sid there's
a package named "u-boot-tools" which includes "mkimage", "mkenvimage",
"fw_printenv", "fw_setenv" and many more while in "distro_alias.inc"
we still have:
>8
DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage
Debian=uboot-mkimage"
>8
Changes v3 -> v4:
* Updated maintainer info to make Yocto autobuilder happy again
Changes v2 -> v3:
* Recipe renamed to "u-boot-tools" to better match its contents
(especially in the future as we add more tools there)
* Existing "u-boot-mkimage" and newly introduced "u-boot-mkenvimage"
made avaialble via PROVIDES
Changes v1 -> v2:
* Got rid of a separate recipe and instead added mkenvimage
to u-boot mkimage recipe
meta/conf/distro/include/maintainers.inc | 2 +-
.../{u-boot-mkimage_2018.07.bb => u-boot-tools_2018.07.bb} | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2018.07.bb =>
u-boot-tools_2018.07.bb} (83%)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 0889c1c429..825c24a3f8 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -654,7 +654,7 @@ RECIPE_MAINTAINER_pn-tzcode-native = "Armin Kuster
"
RECIPE_MAINTAINER_pn-tzdata = "Armin Kuster "
RECIPE_MAINTAINER_pn-u-boot = "Marek Vasut "
RECIPE_MAINTAINER_pn-u-boot-fw-utils = "Marek Vasut "
-RECIPE_MAINTAINER_pn-u-boot-mkimage = "Marek Vasut "
+RECIPE_MAINTAINER_pn-u-boot-tools = "Marek Vasut "
RECIPE_MAINTAINER_pn-udev-extraconf = "Ross Burton "
RECIPE_MAINTAINER_pn-unfs3 = "Ross Burton "
RECIPE_MAINTAINER_pn-unifdef = "Ross Burton "
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
similarity index 83%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
index 08bff1d161..140afa8dfe 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
@@ -1,7 +1,8 @@
require u-boot-common_${PV}.inc
-SUMMARY = "U-Boot bootloader image creation tool"
+SUMMARY = "U-Boot bootloader tools"
DEPENDS += "openssl"
+PROVIDES = "u-boot-mkimage u-boot-mkenvimage"
EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1'
@@ -20,8 +21,14 @@ do_compile () {
do_install () {
install -d ${D}${bindir}
+
+ # mkimage
install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
ln -sf uboot-mkimage ${D}${bindir}/mkimage
+
+ # mkenvimage
+ install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
+ ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
}
RDEPENDS_${PN} += "dtc"
--
2.16.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/15] Prepare for PTRACE_GET_SYSCALL_INFO
On Mon, Nov 19, 2018 at 7:11 PM Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO > request. > > The primary intent is that the triple (audit_arch, syscall_nr, arg1..arg6) > should describe what system call is being called and what its arguments are. No real comment from me, most of this is arch specific code so I'll let the individual arch folks comment on that; they know far better than I do what is correct. That said, anything that gets us closer to being able to offer syscall auditing for these arches gets a big thumbs up from me - thanks! > Dmitry V. Levin (15): > Move EM_HEXAGON to uapi/linux/elf-em.h > Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h > Move EM_UNICORE to uapi/linux/elf-em.h > elf-em.h: add EM_NDS32 > elf-em.h: add EM_XTENSA > m68k: define syscall_get_arch() > arc: define syscall_get_arch() > c6x: define syscall_get_arch() > h8300: define syscall_get_arch() > hexagon: define syscall_get_arch() > nds32: define syscall_get_arch() > nios2: define syscall_get_arch() > riscv: define syscall_get_arch() > unicore32: define syscall_get_arch() > xtensa: define syscall_get_arch() > > arch/arc/include/asm/elf.h | 6 +- > arch/arc/include/asm/syscall.h | 10 ++ > arch/c6x/include/asm/syscall.h | 7 +++ > arch/h8300/include/asm/syscall.h | 5 + > arch/hexagon/include/asm/elf.h | 6 +- > arch/hexagon/include/asm/syscall.h | 8 > arch/m68k/include/asm/syscall.h | 12 > arch/nds32/include/asm/syscall.h | 8 > arch/nios2/include/asm/syscall.h | 6 ++ > arch/riscv/include/asm/syscall.h | 10 ++ > arch/unicore32/include/asm/elf.h | 3 +-- > arch/unicore32/include/asm/syscall.h | 12 > arch/xtensa/include/asm/syscall.h| 7 +++ > include/uapi/linux/audit.h | 15 +++ > include/uapi/linux/elf-em.h | 7 +++ > 15 files changed, 110 insertions(+), 12 deletions(-) > create mode 100644 arch/m68k/include/asm/syscall.h > create mode 100644 arch/unicore32/include/asm/syscall.h -- paul moore www.paul-moore.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4] u-boot: Add mkenvimage tool
On 11/20/2018 09:21 PM, Alexey Brodkin wrote: > This utility is used for creation of images containing > usable in run-time U-Boot environment. > > As of today this utility is added per-board like here [1] > for Intel Edison board. > > [1] > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb > > Given there're quite some U-Boot tools that we may want to add later > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools" > still for compatibility we provide "u-boot-mkimage" with help > of PROVIDES as well as proposed "u-boot-mkenvimage". > > Signed-off-by: Alexey Brodkin > Cc: Richard Purdie > Cc: Otavio Salvador > Cc: Martin Jansa > Cc: Ross Burton > Cc: Marek Vasut > --- > > I may "git grep u-boot-mkimage" in more places: > 1. meta/classes/image_types.bbclass:311:CONVERSION_DEPENDS_u-boot = > "u-boot-mkimage-native" > 2. meta/classes/kernel-fitimage.bbclass:7:depends = "%s > u-boot-mkimage-native dtc-native" % depends > 3. meta/classes/kernel-uimage.bbclass:6:depends = "%s > u-boot-mkimage-native" % depends > 4. > meta/conf/distro/include/distro_alias.inc:357:DISTRO_PN_ALIAS_pn-u-boot-mkimage > = "Ubuntu=uboot-mkimage Debian=uboot-mkimage" > > But that's not clear for me if it's required to swap "u-boot-mkimage" > to "u-boot-tools" see: > 1. "u-boot-mkimage" is still a valid recipe as we export ot via PROVIDES > (or I'm mixing package name with recipe name which very well might be > the case) > 2. I don't fully understand a mening of "DISTRO_PN_ALIAS". > If that's a name of a package from some big Linux distro or how target > utility is named in that distro. For example in Debian Sid there's > a package named "u-boot-tools" which includes "mkimage", "mkenvimage", > "fw_printenv", "fw_setenv" and many more while in "distro_alias.inc" > we still have: > >8 > DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage > Debian=uboot-mkimage" > >8 Just make u-boot-tools RPROVIDE the u-boot-mkimage, and make it generate a u-boot-mkimage package , no ? -- Best regards, Marek Vasut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v4] u-boot: Add mkenvimage tool
Hi Marek, > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Tuesday, November 20, 2018 11:23 PM > To: Alexey Brodkin ; > openembedded-c...@lists.openembedded.org > Cc: Ross Burton ; Khem Raj ; > linux-snps-arc@lists.infradead.org; Richard Purdie > ; Otavio Salvador > ; Martin Jansa > Subject: Re: [PATCH v4] u-boot: Add mkenvimage tool > > On 11/20/2018 09:21 PM, Alexey Brodkin wrote: > > This utility is used for creation of images containing > > usable in run-time U-Boot environment. > > > > As of today this utility is added per-board like here [1] > > for Intel Edison board. > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.org_cgit_cgit.cgi_meta-2Dintel-2Dedison_tree_meta- > 2Dintel-2Dedison-2Dbsp_recipes-2Dbsp_u-2Dboot_u-2Dboot-2Dtools- > 5F2014.04.bb&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=nj37jjvGHLwnN1 > dG2F_IclB3hs-QGaHNS6Z30MOVzGg&s=ReoeMoga0WNrEzYviKd1GBckgNDpZ1E6fs9XguZmy7k&e= > > > > Given there're quite some U-Boot tools that we may want to add later > > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools" > > still for compatibility we provide "u-boot-mkimage" with help > > of PROVIDES as well as proposed "u-boot-mkenvimage". > > > > Signed-off-by: Alexey Brodkin > > Cc: Richard Purdie > > Cc: Otavio Salvador > > Cc: Martin Jansa > > Cc: Ross Burton > > Cc: Marek Vasut > > --- > > > > I may "git grep u-boot-mkimage" in more places: > > 1. meta/classes/image_types.bbclass:311:CONVERSION_DEPENDS_u-boot = > > "u-boot-mkimage-native" > > 2. meta/classes/kernel-fitimage.bbclass:7:depends = "%s > > u-boot-mkimage-native dtc-native" % depends > > 3. meta/classes/kernel-uimage.bbclass:6:depends = "%s > > u-boot-mkimage-native" % depends > > 4. > > meta/conf/distro/include/distro_alias.inc:357:DISTRO_PN_ALIAS_pn-u-boot-mkimage > > = "Ubuntu=uboot-mkimage > Debian=uboot-mkimage" > > > > But that's not clear for me if it's required to swap "u-boot-mkimage" > > to "u-boot-tools" see: > > 1. "u-boot-mkimage" is still a valid recipe as we export ot via PROVIDES > > (or I'm mixing package name with recipe name which very well might be > > the case) > > 2. I don't fully understand a mening of "DISTRO_PN_ALIAS". > > If that's a name of a package from some big Linux distro or how target > > utility is named in that distro. For example in Debian Sid there's > > a package named "u-boot-tools" which includes "mkimage", "mkenvimage", > > "fw_printenv", "fw_setenv" and many more while in "distro_alias.inc" > > we still have: > > >8 > > DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage > > Debian=uboot-mkimage" > > >8 > > Just make u-boot-tools RPROVIDE the u-boot-mkimage, and make it generate > a u-boot-mkimage package , no ? Sorry I'm still a bit confused with all those complexities of OE so pls pardon my silly questions. What are we going to solve with RPROVIDE and how it differs from PROVIDES I already added in the recipe? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4] u-boot: Add mkenvimage tool
On Tue, 2018-11-20 at 23:21 +0300, Alexey Brodkin wrote:
> This utility is used for creation of images containing
> usable in run-time U-Boot environment.
>
> As of today this utility is added per-board like here [1]
> for Intel Edison board.
>
> [1]
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb
>
> Given there're quite some U-Boot tools that we may want to add later
> this recipe name switch from "u-boot-mkimage" to generic "u-boot-
> tools"
> still for compatibility we provide "u-boot-mkimage" with help
> of PROVIDES as well as proposed "u-boot-mkenvimage".
>
> Signed-off-by: Alexey Brodkin
> Cc: Richard Purdie
> Cc: Otavio Salvador
> Cc: Martin Jansa
> Cc: Ross Burton
> Cc: Marek Vasut
> ---
>
> I may "git grep u-boot-mkimage" in more places:
> 1. meta/classes/image_types.bbclass:311:CONVERSION_DEPENDS_u-boot =
> "u-boot-mkimage-native"
> 2. meta/classes/kernel-fitimage.bbclass:7:depends = "%s u-
> boot-mkimage-native dtc-native" % depends
> 3. meta/classes/kernel-uimage.bbclass:6:depends = "%s u-
> boot-mkimage-native" % depends
> 4. meta/conf/distro/include/distro_alias.inc:357:DISTRO_PN_ALIAS_pn-
> u-boot-mkimage = "Ubuntu=uboot-mkimage Debian=uboot-mkimage"
>
> But that's not clear for me if it's required to swap "u-boot-mkimage"
> to "u-boot-tools" see:
> 1. "u-boot-mkimage" is still a valid recipe as we export ot via
> PROVIDES
> (or I'm mixing package name with recipe name which very well
> might be
> the case)
> 2. I don't fully understand a mening of "DISTRO_PN_ALIAS".
> If that's a name of a package from some big Linux distro or how
> target
> utility is named in that distro. For example in Debian Sid
> there's
> a package named "u-boot-tools" which includes "mkimage",
> "mkenvimage",
> "fw_printenv", "fw_setenv" and many more while in
> "distro_alias.inc"
> we still have:
> >8
> DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage
> Debian=uboot-mkimage"
> >8
Sorry, the tests in meta-oe have exposed another issue:
https://8n1.org/14048/3f99
which means the PROVIDES isn't quite right. The reason is there is
magic in the recipe which extends it to the native and nativesdk cases
but its not quite working.
I think the easiest way to address this may be
PROVIDES = "${MLPREFIX}u-boot-mkimage ${MLPREFIX}u-boot-mkenvimage"
PROVIDES_class-native = "u-boot-mkimage-native u-boot-mkenvimage-
native"
since in the nativesdk case, MLPREFIX expands to nativesdk-. The second
class-native line may not be needed. You could check with:
bitbake u-boot-tools -e | grep ^PROVIDES=
and see if it computes the value without manually overriding it.
Cheers,
Richard
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4] u-boot: Add mkenvimage tool
On Tue, 2018-11-20 at 23:21 +0300, Alexey Brodkin wrote: > This utility is used for creation of images containing > usable in run-time U-Boot environment. > > As of today this utility is added per-board like here [1] > for Intel Edison board. > > [1] > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb > > Given there're quite some U-Boot tools that we may want to add later > this recipe name switch from "u-boot-mkimage" to generic "u-boot- > tools" > still for compatibility we provide "u-boot-mkimage" with help > of PROVIDES as well as proposed "u-boot-mkenvimage". > > Signed-off-by: Alexey Brodkin > Cc: Richard Purdie > Cc: Otavio Salvador > Cc: Martin Jansa > Cc: Ross Burton > Cc: Marek Vasut > --- > > I may "git grep u-boot-mkimage" in more places: > 1. meta/classes/image_types.bbclass:311:CONVERSION_DEPENDS_u-boot = > "u-boot-mkimage-native" > 2. meta/classes/kernel-fitimage.bbclass:7:depends = "%s u- > boot-mkimage-native dtc-native" % depends > 3. meta/classes/kernel-uimage.bbclass:6:depends = "%s u- > boot-mkimage-native" % depends > 4. meta/conf/distro/include/distro_alias.inc:357:DISTRO_PN_ALIAS_pn- > u-boot-mkimage = "Ubuntu=uboot-mkimage Debian=uboot-mkimage" > > But that's not clear for me if it's required to swap "u-boot-mkimage" > to "u-boot-tools" see: > 1. "u-boot-mkimage" is still a valid recipe as we export ot via > PROVIDES > (or I'm mixing package name with recipe name which very well > might be > the case) > 2. I don't fully understand a mening of "DISTRO_PN_ALIAS". > If that's a name of a package from some big Linux distro or how > target > utility is named in that distro. For example in Debian Sid > there's > a package named "u-boot-tools" which includes "mkimage", > "mkenvimage", > "fw_printenv", "fw_setenv" and many more while in > "distro_alias.inc" > we still have: > >8 > DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage > Debian=uboot-mkimage" > >8 I meant to say, for cleanliness, all the references you mentioned should also be converted in this patch. Most will work with PROVIDES mapping but we should improve them. Cheers, Richard ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument
This argument is required to extend the generic ptrace API
with PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going to be
called from ptrace_request() along with other syscall_get_* functions
with a tracee as their argument.
This change partially reverts commit 5e937a9ae913 ("syscall_get_arch:
remove useless function arguments").
Cc: linux-al...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-au...@redhat.com
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: sparcli...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: x...@kernel.org
Signed-off-by: Dmitry V. Levin
---
arch/alpha/include/asm/syscall.h | 2 +-
arch/arc/include/asm/syscall.h| 2 +-
arch/arm/include/asm/syscall.h| 2 +-
arch/arm64/include/asm/syscall.h | 4 ++--
arch/c6x/include/asm/syscall.h| 2 +-
arch/h8300/include/asm/syscall.h | 2 +-
arch/hexagon/include/asm/syscall.h| 2 +-
arch/ia64/include/asm/syscall.h | 2 +-
arch/m68k/include/asm/syscall.h | 2 +-
arch/microblaze/include/asm/syscall.h | 2 +-
arch/mips/include/asm/syscall.h | 8
arch/mips/kernel/ptrace.c | 2 +-
arch/nds32/include/asm/syscall.h | 2 +-
arch/nios2/include/asm/syscall.h | 2 +-
arch/openrisc/include/asm/syscall.h | 2 +-
arch/parisc/include/asm/syscall.h | 4 ++--
arch/powerpc/include/asm/syscall.h| 10 --
arch/riscv/include/asm/syscall.h | 2 +-
arch/s390/include/asm/syscall.h | 4 ++--
arch/sh/include/asm/syscall_32.h | 2 +-
arch/sh/include/asm/syscall_64.h | 2 +-
arch/sparc/include/asm/syscall.h | 5 +++--
arch/unicore32/include/asm/syscall.h | 2 +-
arch/x86/include/asm/syscall.h| 8 +---
arch/x86/um/asm/syscall.h | 2 +-
arch/xtensa/include/asm/syscall.h | 2 +-
include/asm-generic/syscall.h | 3 ++-
kernel/auditsc.c | 4 ++--
kernel/seccomp.c | 4 ++--
29 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/arch/alpha/include/asm/syscall.h b/arch/alpha/include/asm/syscall.h
index d73a6fcb519c..11c688c1d7ec 100644
--- a/arch/alpha/include/asm/syscall.h
+++ b/arch/alpha/include/asm/syscall.h
@@ -4,7 +4,7 @@
#include
-static inline int syscall_get_arch(void)
+static inline int syscall_get_arch(struct task_struct *task)
{
return AUDIT_ARCH_ALPHA;
}
diff --git a/arch/arc/include/asm/syscall.h b/arch/arc/include/asm/syscall.h
index 10b2e7523bc8..7834baa61de8 100644
--- a/arch/arc/include/asm/syscall.h
+++ b/arch/arc/include/asm/syscall.h
@@ -69,7 +69,7 @@ syscall_get_arguments(struct task_struct *task, struct
pt_regs *regs,
}
}
-static inline int syscall_get_arch(void)
+static inline int syscall_get_arch(struct task_struct *task)
{
return IS_ENABLED(CONFIG_ISA_ARCOMPACT)
? (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
index 06dea6bce293..3940ceac0bdc 100644
--- a/arch/arm/include/asm/syscall.h
+++ b/arch/arm/include/asm/syscall.h
@@ -104,7 +104,7 @@ static inline void syscall_set_arguments(struct task_struct
*task,
memcpy(®s->ARM_r0 + i, args, n * sizeof(args[0]));
}
-static inline int syscall_get_arch(void)
+static inline int syscall_get_arch(struct task_struct *task)
{
/* ARM tasks don't change audit architectures on the fly. */
return AUDIT_ARCH_ARM;
diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index ad8be16a39c9..1870df03f774 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -117,9 +117,9 @@ static inline void syscall_set_arguments(struct task_struct
*task,
* We don't care about endianness (__AUDIT_ARCH_LE bit) here because
* AArch64 has the same system calls both on little- and big- endian.
*/
-static inline int syscall_get_arch(void)
+static inline int syscall_get_arch(struct task_struct *task)
{
- if (is_compat_task())
+ if (is_compat_thread(task_thread_info(task)))
return AUDIT_ARCH_ARM;
return AUDIT_ARCH_AARCH64;
diff --git a/arch/c6x/include/asm/syscall.h b/arch/c6x/include/asm/syscall.h
index 39dbd1ef994c..595057191c9c 100644
--- a/arch/c6x/include/asm/syscall.h
+++ b/arch/c6x/include/asm/syscall.h
@@ -121,7 +121,7 @@ static inline void syscall_set_arguments(struct task_struct
*task,
}
}
-static inline int sys
kisskb: OK linus/axs103_smp_defconfig/arcv2 Wed Nov 21, 17:35
OK linus/axs103_smp_defconfig/arcv2 Wed Nov 21, 17:35
http://kisskb.ellerman.id.au/kisskb/buildresult/13592939/
Commit: Merge tag 'media/v4.20-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
06e68fed32826b44aa9ffcf282c14d3c58918a70
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1
20160824
Possible errors
---
arch/arc/boot/dts/axs103_idu.dtb: Warning (i2c_bus_reg):
/axs10x_mb/i2c@0x1f000/eeprom@0x54: I2C bus unit address format error, expected
"54"
arch/arc/boot/dts/axs103_idu.dtb: Warning (i2c_bus_reg):
/axs10x_mb/i2c@0x1f000/eeprom@0x57: I2C bus unit address format error, expected
"57"
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
Possible warnings (82)
--
arch/arc/boot/dts/axs103_idu.dtb: Warning (i2c_bus_reg):
/axs10x_mb/i2c@0x1f000/eeprom@0x54: I2C bus unit address format error, expected
"54"
arch/arc/boot/dts/axs103_idu.dtb: Warning (i2c_bus_reg):
/axs10x_mb/i2c@0x1f000/eeprom@0x57: I2C bus unit address format error, expected
"57"
arch/arc/mm/tlb.c:914:2: warning: ISO C90 forbids variable length array 'pd0'
[-Wvla]
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
kernel/dma/direct.c:47:5: warning: format '%zu' expects argument of type
'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
fs/ext4/inode.c:3653:12: warning: format '%zd' expects argument of type 'signed
size_t', but argument 6 has type 'ssize_t {aka int}' [-Wformat=]
drivers/base/regmap/regmap.c:1531:22: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
drivers/base/regmap/regcache.c:719:20: warning: format '%zu' expects argument
of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1382:17: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1382:17: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
mm/percpu.c:1948:27: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1948:32: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1948:37: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1948:42: warning: format '%zu' expects argument of type 'size_t',
but argument 6 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1948:52: warning: format '%zu' expects argument of type 'size_t',
but argument 7 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1948:56: warning: format '%zu' expects argument of type 'size_t',
but argument 8 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 7 has type 'unsigned int' [-Wformat=]
drivers/base/component.c:174:24: warning: format '%zu' expects argument of type
'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kernel.h:845:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
kisskb: OK linus/axs101_defconfig/arcompact Wed Nov 21, 17:35
OK linus/axs101_defconfig/arcompact Wed Nov 21, 17:35 http://kisskb.ellerman.id.au/kisskb/buildresult/13592940/ Commit: Merge tag 'media/v4.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 06e68fed32826b44aa9ffcf282c14d3c58918a70 Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 Possible errors --- arch/arc/boot/dts/axs101.dtb: Warning (i2c_bus_reg): /axs10x_mb/i2c@0x1f000/eeprom@0x54: I2C bus unit address format error, expected "54" arch/arc/boot/dts/axs101.dtb: Warning (i2c_bus_reg): /axs10x_mb/i2c@0x1f000/eeprom@0x57: I2C bus unit address format error, expected "57" Possible warnings (6) -- arch/arc/boot/dts/axs101.dtb: Warning (i2c_bus_reg): /axs10x_mb/i2c@0x1f000/eeprom@0x54: I2C bus unit address format error, expected "54" arch/arc/boot/dts/axs101.dtb: Warning (i2c_bus_reg): /axs10x_mb/i2c@0x1f000/eeprom@0x57: I2C bus unit address format error, expected "57" arch/arc/mm/tlb.c:914:2: warning: variable length array 'pd0' is used [-Wvla] include/linux/kernel.h:845:29: warning: comparison of distinct pointer types lacks a cast [enabled by default] net/ipv4/tcp_input.c:4311:49: warning: array subscript is above array bounds [-Warray-bounds] arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
