[linux-yocto] [PATCH] samples: fix pidfd-metadata compilation
From: Guenter Roeck
commit 7c33277b9a9ada187f805b41ffbebe6c51622fb6 upstream.
Define __NR_pidfd_send_signal if it isn't to prevent a compilation error.
To make pidfd-metadata compile on all arches, irrespective of whether
or not syscall numbers are assigned, define the syscall number to -1.
If it isn't defined this will cause the kernel to return -ENOSYS.
Fixes: 43c6afee48d4 ("samples: show race-free pidfd metadata access")
Reported-by: Arnd Bergmann
Reported-by: Guenter Roeck
Cc: Christian Brauner
Signed-off-by: Guenter Roeck
[christ...@brauner.io: tweak commit message]
Signed-off-by: Christian Brauner
Signed-off-by: He Zhe
---
This is for standard/base
samples/pidfd/pidfd-metadata.c | 4
1 file changed, 4 insertions(+)
diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
index 640f5f7..14b4544 100644
--- a/samples/pidfd/pidfd-metadata.c
+++ b/samples/pidfd/pidfd-metadata.c
@@ -21,6 +21,10 @@
#define CLONE_PIDFD 0x1000
#endif
+#ifndef __NR_pidfd_send_signal
+#define __NR_pidfd_send_signal -1
+#endif
+
static int do_child(void *args)
{
printf("%d\n", getpid());
--
2.7.4
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] samples: fix pidfd-metadata compilation
Please ignore.
On 6/11/19 11:38 AM, zhe...@windriver.com wrote:
> From: Guenter Roeck
>
> Define __NR_pidfd_send_signal if it isn't to prevent a compilation error.
>
> To make pidfd-metadata compile on all arches, irrespective of whether
> or not syscall numbers are assigned, define the syscall number to -1.
> If it isn't defined this will cause the kernel to return -ENOSYS.
>
> Fixes: 43c6afee48d4 ("samples: show race-free pidfd metadata access")
> Reported-by: Arnd Bergmann
> Reported-by: Guenter Roeck
> Cc: Christian Brauner
> Signed-off-by: Guenter Roeck
> [christ...@brauner.io: tweak commit message]
> Signed-off-by: Christian Brauner
> ---
> samples/pidfd/pidfd-metadata.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
> index 640f5f7..14b4544 100644
> --- a/samples/pidfd/pidfd-metadata.c
> +++ b/samples/pidfd/pidfd-metadata.c
> @@ -21,6 +21,10 @@
> #define CLONE_PIDFD 0x1000
> #endif
>
> +#ifndef __NR_pidfd_send_signal
> +#define __NR_pidfd_send_signal -1
> +#endif
> +
> static int do_child(void *args)
> {
> printf("%d\n", getpid());
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] samples: fix pidfd-metadata compilation
From: Guenter Roeck
Define __NR_pidfd_send_signal if it isn't to prevent a compilation error.
To make pidfd-metadata compile on all arches, irrespective of whether
or not syscall numbers are assigned, define the syscall number to -1.
If it isn't defined this will cause the kernel to return -ENOSYS.
Fixes: 43c6afee48d4 ("samples: show race-free pidfd metadata access")
Reported-by: Arnd Bergmann
Reported-by: Guenter Roeck
Cc: Christian Brauner
Signed-off-by: Guenter Roeck
[christ...@brauner.io: tweak commit message]
Signed-off-by: Christian Brauner
---
samples/pidfd/pidfd-metadata.c | 4
1 file changed, 4 insertions(+)
diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
index 640f5f7..14b4544 100644
--- a/samples/pidfd/pidfd-metadata.c
+++ b/samples/pidfd/pidfd-metadata.c
@@ -21,6 +21,10 @@
#define CLONE_PIDFD 0x1000
#endif
+#ifndef __NR_pidfd_send_signal
+#define __NR_pidfd_send_signal -1
+#endif
+
static int do_child(void *args)
{
printf("%d\n", getpid());
--
2.7.4
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Hi Bruce, I just finished insane check to build xilinx-zynqmp machine with core-image-sato, all passed with boot process. Could you please help me to create a branch like that standard/xilinx-zynqmp in the following git repo. in convenient your time, just directly branch out from origin/standard/base, thanks~ git://git.yoctoproject.org/linux-yocto-dev Cheers, Zumeng On 6/11/19 7:37 AM, Zumeng Chen wrote: On 6/10/19 9:37 PM, Bruce Ashfield wrote: On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen wrote: Sounds I like mean, no, I just talk the reality, Xilinx did like the following: https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp I think they have a reason to share zynq-7000 series hardware, which gears to the related hardware features, and the way to create dts(a relative complicated process) corresponding to the hdl related features partly as well. And they just want to put zynqmp(arm64) into recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, As you can see, they have almost little in common in hardware features. The reality here I said is about yocto project has not these related ecosystem to create these whole thing for xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, BOOT.BIN etc. there really are a bunch of Xilinx things. So do we still want to following their SDK? If yes, fine, just help me to merge zynqmp part from meta-xilinx, I'll take care the rest. I'm actually fine with an approach like we are taking here. Come up with something that works purely with linux-yocto, and then we can start factoring and grouping the fragments with the help of people closer to the h/w. In particular as more Xilinx proprietary parts are open sourced, we'll have the opportunity to tweak the configuration fragments to support them properly/fully. We do want the fragments in the centralized kernel-cache, just as long as they are appropriated factored/grouped under a xilinx/ subdir where it makes sense, and have more generic feature groupings available to be shared in the more common directories. What we have is a good start to that goal, so I'll get it merged and we can start iterating on it in tree. Thanks Bruce, highly appreciated :) Cheers, Zumeng Bruce Cheers, Zumeng On 6/6/19 2:55 PM, Zumeng Chen wrote: Yes, I checked it, it seems only for zynq 7000 and its special interfaces. I bet the original author didn't mean to share something for both arm64 and 32 :) When I created the structure I had intended for it to include the zynqmp related configs. I even had some yocto-kernel-cache patches for it at the time, but zynqmp has changed quite a bit since those initial patches. Most of those configs still live in meta-xilinx though (some are specific to the linux-xlnx kernel). http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta I would highly recommend keeping the xilinx bsp configs together under the bsp/xilinx/ directory. And try to reuse the existing configs where possible or splitting some parts of them out to make common configs since zynq and zynqmp share a number of common drivers. Negative, try to see what had done in the past, a very little can re-used. And I suspect did you even how many features they are sharing. I don't think it's worth. To be honestly, they have totally the different app scenario. Cheers, Zumeng Regards, Nathan And for those common things, I guess some of them might be included by our rootfs build system. sense to locate these fragments there, and to factor out some common configs. I see some of the issues I'm pointing out here are in the existing fragments as well, so there's an opportunity for some low effort fixups. + +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_PCI_MSI_IRQ_DOMAIN=y +CONFIG_PCIE_XILINX_NWL=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCIE_XDMA_PL=y + +#CPU ilde and freq +CONFIG_CPU_IDLE=y +CONFIG_ARM_CPUIDLE=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPUFREQ_DT=y +CONFIG_CPUFREQ_DT_PLATDEV=y These are also not tied to h/w. We already have a features/power/intel.cfg fragment. Can you relocate these to a zynqmp or xilinx fragment and put it along side of the existing ones ? I'll try it with a nice way. + +# CAN Device Drivers +# +CONFIG_CAN=y +CONFIG_CAN_DEV=y +CONFIG_CAN_XILINXCAN=y + +CONFIG_MTD=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_SPI_NOR=y +# CONFIG_JFFS2_FS_WRITEBUFFER is not set +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set + +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_AHCI_CEVA=y +CONFIG_NETDEVICES=y + +CONFIG_OF=y +CONFIG_OF_MDIO=y +CONFIG_ETHERNET=y +CONFIG_NET_CADENCE=y +CONFIG_MACB=y +CONFIG_MACB_EXT_BD=y + +CONFIG_PHYLIB=y +CONFIG_XILINX_PHY=y + +CONFIG_PHY_XILINX_ZYNQMP=y +CONFIG_FIXED_PHY=y +CONFIG_DEVMEM=y + +CONFIG_SERIAL_EARLYC
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On 6/10/19 9:37 PM, Bruce Ashfield wrote: On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen wrote: Sounds I like mean, no, I just talk the reality, Xilinx did like the following: https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp I think they have a reason to share zynq-7000 series hardware, which gears to the related hardware features, and the way to create dts(a relative complicated process) corresponding to the hdl related features partly as well. And they just want to put zynqmp(arm64) into recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, As you can see, they have almost little in common in hardware features. The reality here I said is about yocto project has not these related ecosystem to create these whole thing for xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, BOOT.BIN etc. there really are a bunch of Xilinx things. So do we still want to following their SDK? If yes, fine, just help me to merge zynqmp part from meta-xilinx, I'll take care the rest. I'm actually fine with an approach like we are taking here. Come up with something that works purely with linux-yocto, and then we can start factoring and grouping the fragments with the help of people closer to the h/w. In particular as more Xilinx proprietary parts are open sourced, we'll have the opportunity to tweak the configuration fragments to support them properly/fully. We do want the fragments in the centralized kernel-cache, just as long as they are appropriated factored/grouped under a xilinx/ subdir where it makes sense, and have more generic feature groupings available to be shared in the more common directories. What we have is a good start to that goal, so I'll get it merged and we can start iterating on it in tree. Thanks Bruce, highly appreciated :) Cheers, Zumeng Bruce Cheers, Zumeng On 6/6/19 2:55 PM, Zumeng Chen wrote: Yes, I checked it, it seems only for zynq 7000 and its special interfaces. I bet the original author didn't mean to share something for both arm64 and 32 :) When I created the structure I had intended for it to include the zynqmp related configs. I even had some yocto-kernel-cache patches for it at the time, but zynqmp has changed quite a bit since those initial patches. Most of those configs still live in meta-xilinx though (some are specific to the linux-xlnx kernel). http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta I would highly recommend keeping the xilinx bsp configs together under the bsp/xilinx/ directory. And try to reuse the existing configs where possible or splitting some parts of them out to make common configs since zynq and zynqmp share a number of common drivers. Negative, try to see what had done in the past, a very little can re-used. And I suspect did you even how many features they are sharing. I don't think it's worth. To be honestly, they have totally the different app scenario. Cheers, Zumeng Regards, Nathan And for those common things, I guess some of them might be included by our rootfs build system. sense to locate these fragments there, and to factor out some common configs. I see some of the issues I'm pointing out here are in the existing fragments as well, so there's an opportunity for some low effort fixups. + +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_PCI_MSI_IRQ_DOMAIN=y +CONFIG_PCIE_XILINX_NWL=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCIE_XDMA_PL=y + +#CPU ilde and freq +CONFIG_CPU_IDLE=y +CONFIG_ARM_CPUIDLE=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPUFREQ_DT=y +CONFIG_CPUFREQ_DT_PLATDEV=y These are also not tied to h/w. We already have a features/power/intel.cfg fragment. Can you relocate these to a zynqmp or xilinx fragment and put it along side of the existing ones ? I'll try it with a nice way. + +# CAN Device Drivers +# +CONFIG_CAN=y +CONFIG_CAN_DEV=y +CONFIG_CAN_XILINXCAN=y + +CONFIG_MTD=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_SPI_NOR=y +# CONFIG_JFFS2_FS_WRITEBUFFER is not set +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set + +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_AHCI_CEVA=y +CONFIG_NETDEVICES=y + +CONFIG_OF=y +CONFIG_OF_MDIO=y +CONFIG_ETHERNET=y +CONFIG_NET_CADENCE=y +CONFIG_MACB=y +CONFIG_MACB_EXT_BD=y + +CONFIG_PHYLIB=y +CONFIG_XILINX_PHY=y + +CONFIG_PHY_XILINX_ZYNQMP=y +CONFIG_FIXED_PHY=y +CONFIG_DEVMEM=y + +CONFIG_SERIAL_EARLYCON=y +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +CONFIG_SERIAL_XILINX_PS_UART=y +CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y +# +CONFIG_I2C=y +CONFIG_I2C_MUX=y +CONFIG_I2C_MUX_PCA954x=y +CONFIG_I2C_MUX_REG +CONFIG_I2C_CADENCE=y +CONFIG_I2C_XILINX=y +CONFIG_EEPROM_AT24=y + + +CONFIG_SPI=y +CONFIG_SPI_MASTER=y +CONFIG_SPI_CADENCE=y +CONFIG_SPI_XILINX=y +CONFIG_SPI_ZYNQMP_GQSPI=y + +CONFIG_GPIOLIB=y +CONFIG_GPIO_DEVRES=y +CONFIG_OF_
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen wrote: > > Sounds I like mean, no, I just talk the reality, Xilinx did like the > following: > > https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp > > I think they have a reason to share zynq-7000 series hardware, which > gears to the related hardware > > features, and the way to create dts(a relative complicated process) > corresponding to the hdl related > > features partly as well. And they just want to put zynqmp(arm64) into > recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, > > As you can see, they have almost little in common in hardware features. > > > The reality here I said is about yocto project has not these related > ecosystem to create these whole thing for > > xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, > BOOT.BIN etc. there really are a bunch > > of Xilinx things. > > > So do we still want to following their SDK? If yes, fine, just help me > to merge zynqmp part from meta-xilinx, I'll take care the rest. I'm actually fine with an approach like we are taking here. Come up with something that works purely with linux-yocto, and then we can start factoring and grouping the fragments with the help of people closer to the h/w. In particular as more Xilinx proprietary parts are open sourced, we'll have the opportunity to tweak the configuration fragments to support them properly/fully. We do want the fragments in the centralized kernel-cache, just as long as they are appropriated factored/grouped under a xilinx/ subdir where it makes sense, and have more generic feature groupings available to be shared in the more common directories. What we have is a good start to that goal, so I'll get it merged and we can start iterating on it in tree. Bruce > > > Cheers, > > Zumeng > > > On 6/6/19 2:55 PM, Zumeng Chen wrote: > > > >>> > >>> Yes, I checked it, it seems only for zynq 7000 and its special > >>> interfaces. I bet > >>> > >>> the original author didn't mean to share something for both arm64 > >>> and 32 :) > >> When I created the structure I had intended for it to include the > >> zynqmp related configs. I even had some yocto-kernel-cache patches for > >> it at the time, but zynqmp has changed quite a bit since those initial > >> patches. Most of those configs still live in meta-xilinx though (some > >> are specific to the linux-xlnx kernel). > >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta > >> > >> > >> I would highly recommend keeping the xilinx bsp configs together under > >> the bsp/xilinx/ directory. And try to reuse the existing configs where > >> possible or splitting some parts of them out to make common configs > >> since zynq and zynqmp share a number of common drivers. > > > > > > Negative, try to see what had done in the past, a very little can > > re-used. And I suspect > > > > did you even how many features they are sharing. > > > > I don't think it's worth. To be honestly, they have totally the > > different app scenario. > > > > Cheers, > > > > Zumeng > > > >> > >> Regards, > >> Nathan > >> > >>> And for those common things, I guess some of them might be included > >>> by our > >>> > >>> rootfs build system. > >>> > >>> > sense to locate these fragments there, and to factor out some common > configs. I see some of the issues I'm pointing out here are in the > existing fragments as well, so there's an opportunity for some low > effort fixups. > >>> > > + > > +CONFIG_PCI=y > > +CONFIG_PCI_MSI=y > > +CONFIG_PCI_MSI_IRQ_DOMAIN=y > > +CONFIG_PCIE_XILINX_NWL=y > > +CONFIG_PCIEPORTBUS=y > > +CONFIG_PCIE_XDMA_PL=y > > + > > +#CPU ilde and freq > > +CONFIG_CPU_IDLE=y > > +CONFIG_ARM_CPUIDLE=y > > +CONFIG_CPU_FREQ=y > > +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > +CONFIG_CPU_FREQ_GOV_USERSPACE=y > > +CONFIG_CPUFREQ_DT=y > > +CONFIG_CPUFREQ_DT_PLATDEV=y > These are also not tied to h/w. We already have a > features/power/intel.cfg fragment. Can you relocate these to a zynqmp > or xilinx fragment and put it along side of the existing ones ? > >>> > >>> I'll try it with a nice way. > >>> > > > + > > +# CAN Device Drivers > > +# > > +CONFIG_CAN=y > > +CONFIG_CAN_DEV=y > > +CONFIG_CAN_XILINXCAN=y > > + > > +CONFIG_MTD=y > > +CONFIG_MTD_OF_PARTS=y > > +CONFIG_MTD_BLKDEVS=y > > +CONFIG_MTD_BLOCK=y > > +CONFIG_MTD_M25P80=y > > +CONFIG_MTD_SPI_NOR=y > > +# CONFIG_JFFS2_FS_WRITEBUFFER is not set > > +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > > + > > +CONFIG_BLK_DEV_SD=y > > +CONFIG_ATA=y > > +CONFIG_SATA_AHCI=y > > +CONFIG_AHCI_CEVA=y > > +CONFIG_NETDEVICES=y > > + > > +CONFIG_OF=y > > +CONFIG_OF_MDIO=y > > +CONFIG_ETHERNET=y > > +CONFIG_NET_CADENCE=y > > +CONFIG_MACB=y > > +CONFIG_MACB_EXT_
