[driver-core:driver-core-linus] BUILD SUCCESS cdb4f26a63c391317e335e6e683a614358e70aeb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus branch HEAD: cdb4f26a63c391317e335e6e683a614358e70aeb kobject: kobj_type: remove default_attrs elapsed time: 743m configs tested: 137 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm64 defconfig arm64allyesconfig arm allmodconfig arm defconfig arm allyesconfig i386 randconfig-c001 riscvallmodconfig mips allyesconfig um i386_defconfig mips allmodconfig riscvallyesconfig um x86_64_defconfig m68k allyesconfig powerpc allmodconfig powerpc allyesconfig m68k allmodconfig s390 allmodconfig s390 allyesconfig m68km5407c3_defconfig powerpc pq2fads_defconfig sparc64 alldefconfig sparc sparc32_defconfig powerpc storcenter_defconfig archsdk_defconfig riscvnommu_k210_defconfig arm jornada720_defconfig arm imx_v6_v7_defconfig sh magicpanelr2_defconfig openrisc or1klitex_defconfig mipsvocore2_defconfig m68kq40_defconfig arm tegra_defconfig armshmobile_defconfig m68kmvme16x_defconfig mips maltasmvp_eva_defconfig sh se7722_defconfig powerpc tqm8xx_defconfig powerpc tqm8548_defconfig i386 alldefconfig armspear6xx_defconfig m68k bvme6000_defconfig m68k m5249evb_defconfig ia64generic_defconfig arm viper_defconfig powerpc tqm8541_defconfig xtensasmp_lx200_defconfig arm exynos_defconfig openriscdefconfig shshmin_defconfig shmigor_defconfig sh rts7751r2d1_defconfig sparc sparc64_defconfig arm iop32x_defconfig riscv nommu_k210_sdcard_defconfig armmvebu_v7_defconfig sh kfr2r09-romimage_defconfig mips xway_defconfig arm pxa_defconfig mips decstation_64_defconfig h8300 h8s-sim_defconfig arm sama5_defconfig xtensaxip_kc705_defconfig mips rb532_defconfig m68km5307c3_defconfig x86_64randconfig-c001 arm randconfig-c002-20220405 ia64 allmodconfig ia64 allyesconfig ia64defconfig m68kdefconfig nios2 defconfig arc allyesconfig cskydefconfig nios2allyesconfig alpha defconfig alphaallyesconfig h8300allyesconfig xtensa allyesconfig arc defconfig sh allmodconfig s390defconfig parisc defconfig parisc64defconfig parisc allyesconfig sparc defconfig i386 allyesconfig sparcallyesconfig i386defconfig i386 debian-10.3-kselftests i386 debian-10.3 powerpc allnoconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 riscv
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > Sure, that would technically work. But I just think it's cleaner to use > -rc1 (or later) as the baseline for an immutable branch. If the baseline > is an arbitrary commit somewhere within merge windows commits, it's more > work for everyone to verify the branch is suitable. > > Also in general I would also prefer to base -next trees to -rc1 or newer > to make the bisect cleaner. The less we need to test kernels from the > merge window (ie. commits after the final release and before -rc1) the > better. > > But this is just a small wish from me, I fully understand that it might > be too much changes to your process. Wanted to point out this anyway. Forwarded! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jakub Kicinski writes: > On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: >> On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: >> > Dave&Jakub, once you guys open net-next will it be based on -rc1? >> >> Not normally. We usually let net feed net-next so it'd get -rc1 this >> Thursday. But we should be able to fast-forward, let me confirm with >> Dave. > > Wait, why is -rc1 magic? If you based the branch on whatever > the merge-base of net-next and staging-next is, would that be > an aberration? Sure, that would technically work. But I just think it's cleaner to use -rc1 (or later) as the baseline for an immutable branch. If the baseline is an arbitrary commit somewhere within merge windows commits, it's more work for everyone to verify the branch is suitable. Also in general I would also prefer to base -next trees to -rc1 or newer to make the bisect cleaner. The less we need to test kernels from the merge window (ie. commits after the final release and before -rc1) the better. But this is just a small wish from me, I fully understand that it might be too much changes to your process. Wanted to point out this anyway. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
