arm-soc boot: 620 boots: 103 failed, 491 passed with 3 offline, 23 conflicts (v4.7-rc4-679-g0477eff1bea3)
arm-soc boot: 620 boots: 103 failed, 491 passed with 3 offline, 23 conflicts (v4.7-rc4-679-g0477eff1bea3)
Full Boot Summary: https://kernelci.org/boot/all/job/arm-soc/kernel/v4.7-rc4-679-g0477eff1bea3/ Full Build Summary: https://kernelci.org/build/arm-soc/kernel/v4.7-rc4-679-g0477eff1bea3/
Tree: arm-soc Branch: local/for-next Git Describe: v4.7-rc4-679-g0477eff1bea3 Git Commit: 0477eff1bea39b5b3610e5a928c99629d80de9ab Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git Tested: 107 unique boards, 25 SoC families, 39 builds out of 143
Boot Failures Detected: https://kernelci.org/boot/?v4.7-rc4-679-g0477eff1bea3&fail
arm64:
defconfig: apm-mustang-kvm-guest: 1 failed lab apm-mustang-kvm-uefi-guest: 1 failed lab juno-kvm-guest: 1 failed lab juno-kvm-uefi-guest: 1 failed lab
arm:
multi_v7_defconfig+CONFIG_EFI=y: alpine-db: 1 failed lab am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab bcm4708-smartrg-sr400ac: 1 failed lab bcm72521-bcm97252sffe: 1 failed lab exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab meson8b-odroidc1: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab socfpga_cyclone5_de0_sockit: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab vf610-colibri-eval-v3: 1 failed lab
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed lab
tegra_defconfig: tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: alpine-db: 1 failed lab am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab bcm4708-smartrg-sr400ac: 1 failed lab bcm72521-bcm97252sffe: 1 failed lab exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab meson8b-odroidc1: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab socfpga_cyclone5_de0_sockit: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab vf610-colibri-eval-v3: 1 failed lab
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab
imx_v6_v7_defconfig: vf610-colibri-eval-v3: 1 failed lab
multi_v7_defconfig: alpine-db: 1 failed lab am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab bcm4708-smartrg-sr400ac: 1 failed lab bcm72521-bcm97252sffe: 1 failed lab exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab meson8b-odroidc1: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab socfpga_cyclone5_de0_sockit: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab vf610-colibri-eval-v3: 1 failed lab
omap2plus_defconfig: am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab
multi_v7_defconfig+CONFIG_LKDTM=y: alpine-db: 1 failed lab am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab bcm4708-smartrg-sr400ac: 1 failed lab bcm72521-bcm97252sffe: 1 failed lab exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab meson8b-odroidc1: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab socfpga_cyclone5_de0_sockit: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab vf610-colibri-eval-v3: 1 failed lab
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: alpine-db: 1 failed lab am335x-pepper: 1 failed lab am437x-gp-evm: 1 failed lab bcm4708-smartrg-sr400ac: 1 failed lab bcm72521-bcm97252sffe: 1 failed lab exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab meson8b-odroidc1: 1 failed lab omap4-duovero-parlor: 1 failed lab omap4-panda: 1 failed lab qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab socfpga_cyclone5_de0_sockit: 1 failed lab tegra20-iris-512: 1 failed lab tegra30-beaver: 1 failed lab vf610-colibri-eval-v3: 1 failed lab
socfpga_defconfig: socfpga_cyclone5_de0_sockit: 1 failed lab
qcom_defconfig: qcom-apq8074-dragonboard: 1 failed lab qcom-msm8974-sony-xperia-honami: 1 failed lab
exynos_defconfig: exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab
multi_v7_defconfig+CONFIG_ARM_LPAE=y: exynos5410-odroidxu: 1 failed lab exynos5420-arndale-octa: 1 failed lab omap5-uevm_rootfs:mmc: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: hip04-d01: 1 offline lab
multi_v7_defconfig+CONFIG_EFI=y: hip04-d01: 1 offline lab
omap2plus_defconfig: am335x-boneblack: 1 offline lab
Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm:
multi_v7_defconfig+CONFIG_EFI=y: omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL omap3-beagle-xm: lab-baylibre-seattle: FAIL lab-free-electrons: PASS am335x-boneblack: lab-cambridge: PASS lab-free-electrons: PASS lab-baylibre-seattle: FAIL lab-baylibre: PASS
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS am335x-boneblack: lab-cambridge: PASS lab-free-electrons: PASS lab-baylibre-seattle: FAIL lab-baylibre: PASS
multi_v7_defconfig: exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL am335x-boneblack: lab-cambridge: PASS lab-free-electrons: PASS lab-baylibre-seattle: FAIL lab-baylibre: PASS omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS omap3-beagle-xm: lab-baylibre-seattle: FAIL lab-free-electrons: PASS
omap2plus_defconfig: omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS omap3-beagle-xm: lab-baylibre-seattle: FAIL lab-free-electrons: PASS
multi_v7_defconfig+CONFIG_LKDTM=y: omap3-beagle-xm: lab-baylibre-seattle: FAIL lab-free-electrons: PASS exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS am335x-boneblack: lab-cambridge: PASS lab-free-electrons: PASS lab-baylibre-seattle: FAIL lab-baylibre: PASS
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: omap4-panda-es: lab-baylibre-seattle: FAIL lab-baylibre: PASS exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL am335x-boneblack: lab-cambridge: PASS lab-free-electrons: PASS lab-baylibre-seattle: FAIL lab-baylibre: PASS omap3-beagle-xm: lab-baylibre-seattle: FAIL lab-free-electrons: PASS
exynos_defconfig: exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: exynos5250-arndale: lab-cambridge: PASS lab-baylibre-seattle: FAIL
--- For more info write to info@kernelci.org
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed lab
Well, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
On Thursday, July 7, 2016 9:32:08 AM CEST Alexandre Belloni wrote:
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed labWell, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
I added the patch, but I don't know why kernelci decided to try booting it on those platforms. I guess we don't even have anyone with rm9200 machines for kernelci, or interest in adding that, right?
Arnd
On 07/07/2016 at 10:07:44 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 9:32:08 AM CEST Alexandre Belloni wrote:
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed labWell, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
I added the patch, but I don't know why kernelci decided to try booting it on those platforms. I guess we don't even have anyone with rm9200 machines for kernelci, or interest in adding that, right?
An at91rm9200ek should be up in our lab soon. For what I understand, the main issue is getting an armv4 rootfs from kci and it also has to boot over nfs instead of initramfs because of the limited RAM space.
On Thursday, July 7, 2016 10:43:23 AM CEST Alexandre Belloni wrote:
On 07/07/2016 at 10:07:44 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 9:32:08 AM CEST Alexandre Belloni wrote:
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed labWell, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
I added the patch, but I don't know why kernelci decided to try booting it on those platforms. I guess we don't even have anyone with rm9200 machines for kernelci, or interest in adding that, right?
An at91rm9200ek should be up in our lab soon. For what I understand, the main issue is getting an armv4 rootfs from kci and it also has to boot over nfs instead of initramfs because of the limited RAM space.
Ok, good to know.
Once that is added, I guess we have the opposite problem with kernelci running multi_v5_defconfig on rm9200.
While I don't know what code implements it, I guess there is something that currently matches CONFIG_ARCH_AT91 to booting on all at91sam9 boards, and we have to replace that with CONFIG_SOC_AT91SAM9, and add a similar trigger to boot on rm9200 when CONFIG_SOC_AT91RM9200 is set.
Arnd
On 07/07/2016 at 10:51:15 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 10:43:23 AM CEST Alexandre Belloni wrote:
On 07/07/2016 at 10:07:44 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 9:32:08 AM CEST Alexandre Belloni wrote:
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed labWell, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
I added the patch, but I don't know why kernelci decided to try booting it on those platforms. I guess we don't even have anyone with rm9200 machines for kernelci, or interest in adding that, right?
An at91rm9200ek should be up in our lab soon. For what I understand, the main issue is getting an armv4 rootfs from kci and it also has to boot over nfs instead of initramfs because of the limited RAM space.
Ok, good to know.
Once that is added, I guess we have the opposite problem with kernelci running multi_v5_defconfig on rm9200.
While I don't know what code implements it, I guess there is something that currently matches CONFIG_ARCH_AT91 to booting on all at91sam9 boards, and we have to replace that with CONFIG_SOC_AT91SAM9, and add a similar trigger to boot on rm9200 when CONFIG_SOC_AT91RM9200 is set.
I've submitted PR #51 that should solve it: https://github.com/kernelci/lava-ci/pull/51
Arnd Bergmann arnd@arndb.de writes:
On Thursday, July 7, 2016 10:43:23 AM CEST Alexandre Belloni wrote:
On 07/07/2016 at 10:07:44 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 9:32:08 AM CEST Alexandre Belloni wrote:
On 06/07/2016 at 15:17:14 -0700, kernelci.org bot wrote :
multi_v4t_defconfig: at91sam9261ek: 1 failed lab at91sam9m10g45ek: 1 failed lab at91sam9x25ek: 1 failed lab at91sam9x35ek: 1 failed labWell, it would have been useful to be in copy of the patch adding that configuration. It will never boot on those SoCs so this can be ignored.
I added the patch, but I don't know why kernelci decided to try booting it on those platforms. I guess we don't even have anyone with rm9200 machines for kernelci, or interest in adding that, right?
An at91rm9200ek should be up in our lab soon. For what I understand, the main issue is getting an armv4 rootfs from kci and it also has to boot over nfs instead of initramfs because of the limited RAM space.
Ok, good to know.
Once that is added, I guess we have the opposite problem with kernelci running multi_v5_defconfig on rm9200.
While I don't know what code implements it, I guess there is something that currently matches CONFIG_ARCH_AT91 to booting on all at91sam9 boards, and we have to replace that with CONFIG_SOC_AT91SAM9, and add a similar trigger to boot on rm9200 when CONFIG_SOC_AT91RM9200 is set.
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Kevin
On Thursday, July 7, 2016 3:18:55 PM CEST Kevin Hilman wrote:
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Sounds good. Alexandre, does the change below look right to you?
Signed-off-by: Arnd Bergmann arnd@arndb.de
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index edbd32571e07..f091a4c39d73 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -7,9 +7,10 @@ dtb-$(CONFIG_MACH_ARTPEC6) += \ dtb-$(CONFIG_MACH_ASM9260) += \ alphascale-asm9260-devkit.dtb # Keep at91 dtb files sorted alphabetically for each SoC -dtb-$(CONFIG_SOC_SAM_V4_V5) += \ +dtb-$(CONFIG_SOC_AT91RM9200) += \ at91rm9200ek.dtb \ - mpa1600.dtb \ + mpa1600.dtb +dtb-$(CONFIG_SOC_AT91SAM9) += \ animeo_ip.dtb \ at91-qil_a9260.dtb \ aks-cdu.dtb \
On 08/07/2016 at 11:45:19 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 3:18:55 PM CEST Kevin Hilman wrote:
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Sounds good. Alexandre, does the change below look right to you?
Yes, that is what I had. Still, I was wondering whether we should split SOC_SAM_V7 using SOC_SAMA5D2, SOC_SAMA5D3 and SOC_SAMA5D4. We don't have any configuration enabling one without the others yet and I don't expect we will.
Signed-off-by: Arnd Bergmann arnd@arndb.de
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index edbd32571e07..f091a4c39d73 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -7,9 +7,10 @@ dtb-$(CONFIG_MACH_ARTPEC6) += \ dtb-$(CONFIG_MACH_ASM9260) += \ alphascale-asm9260-devkit.dtb # Keep at91 dtb files sorted alphabetically for each SoC -dtb-$(CONFIG_SOC_SAM_V4_V5) += \ +dtb-$(CONFIG_SOC_AT91RM9200) += \ at91rm9200ek.dtb \
- mpa1600.dtb \
- mpa1600.dtb
+dtb-$(CONFIG_SOC_AT91SAM9) += \ animeo_ip.dtb \ at91-qil_a9260.dtb \ aks-cdu.dtb \
On Friday, July 8, 2016 12:01:50 PM CEST Alexandre Belloni wrote:
On 08/07/2016 at 11:45:19 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 3:18:55 PM CEST Kevin Hilman wrote:
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Sounds good. Alexandre, does the change below look right to you?
Yes, that is what I had.
Ok. Are you sending this along with your next pull requests for 4.8?
Still, I was wondering whether we should split SOC_SAM_V7 using SOC_SAMA5D2, SOC_SAMA5D3 and SOC_SAMA5D4. We don't have any configuration enabling one without the others yet and I don't expect we will.
We are not consistent there, but I think the platforms that split it up are in the majority.
You could also ask the reverse question whether it makes sense to have three separate options instead of just SOC_SAMA5 to cover all of them. The differences seem very minimal from the kernel's perspective:
SOC_SAMA5D2 selects HAVE_AT91_GENERATED_CLK and PINCTRL_AT91PIO4 but not HAVE_AT91_SMD and PINCTRL_AT91 SOC_SAMA5D3 does not select CACHE_L2X0 or HAVE_AT91_H32MX
CACHE_L2X0 has some noticeable impact but is already user-selectable, the other options have no effect other than kernel size when enabled but unused, and the total difference for the five options is less than 20kb.
Arnd
On 08/07/2016 at 12:40:44 +0200, Arnd Bergmann wrote :
On Friday, July 8, 2016 12:01:50 PM CEST Alexandre Belloni wrote:
On 08/07/2016 at 11:45:19 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 3:18:55 PM CEST Kevin Hilman wrote:
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Sounds good. Alexandre, does the change below look right to you?
Yes, that is what I had.
Ok. Are you sending this along with your next pull requests for 4.8?
Well, if it is still time, I'd like to send an ultimate pull request for 4.8 with that fix and some of the dtc warning fixed. I think the PMC ones will have to wait 4.9.
If you think it is too late in the cycle, feel free to submit your patch and take it directly through arm-soc.
Still, I was wondering whether we should split SOC_SAM_V7 using SOC_SAMA5D2, SOC_SAMA5D3 and SOC_SAMA5D4. We don't have any configuration enabling one without the others yet and I don't expect we will.
We are not consistent there, but I think the platforms that split it up are in the majority.
You could also ask the reverse question whether it makes sense to have three separate options instead of just SOC_SAMA5 to cover all of them. The differences seem very minimal from the kernel's perspective:
SOC_SAMA5D2 selects HAVE_AT91_GENERATED_CLK and PINCTRL_AT91PIO4 but not HAVE_AT91_SMD and PINCTRL_AT91 SOC_SAMA5D3 does not select CACHE_L2X0 or HAVE_AT91_H32MX
CACHE_L2X0 has some noticeable impact but is already user-selectable, the other options have no effect other than kernel size when enabled but unused, and the total difference for the five options is less than 20kb.
Well, the size was the main reason. I'm not sure it is worth changing now but it is easy enough to do if necessary.
kernel-build-reports@lists.linaro.org
-
Alexandre Belloni -
Arnd Bergmann -
kernelci.org bot -
Kevin Hilman