* [powerpc:next-test] BUILD SUCCESS 278f4532318c176ef8a22a78f45a8c8a30abe40b
From: kernel test robot @ 2020-11-28 1:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 278f4532318c176ef8a22a78f45a8c8a30abe40b powerpc/vdso: Cleanup vdso.h
elapsed time: 783m
configs tested: 154
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm efm32_defconfig
powerpc sam440ep_defconfig
m68k m5475evb_defconfig
xtensa smp_lx200_defconfig
arm mv78xx0_defconfig
powerpc ppc6xx_defconfig
powerpc eiger_defconfig
parisc allyesconfig
mips workpad_defconfig
powerpc arches_defconfig
mips gpr_defconfig
m68k sun3_defconfig
nds32 allnoconfig
sh se7206_defconfig
arm lpc18xx_defconfig
arm keystone_defconfig
sh sh7785lcr_32bit_defconfig
arm imote2_defconfig
arm qcom_defconfig
m68k atari_defconfig
arm omap1_defconfig
mips pistachio_defconfig
powerpc mpc85xx_cds_defconfig
mips loongson1c_defconfig
alpha defconfig
arm s3c2410_defconfig
powerpc cell_defconfig
sh rts7751r2dplus_defconfig
xtensa cadence_csp_defconfig
arm aspeed_g5_defconfig
arc nsim_700_defconfig
arm xcep_defconfig
powerpc skiroot_defconfig
m68k m5407c3_defconfig
mips cu1000-neo_defconfig
x86_64 alldefconfig
nds32 defconfig
powerpc ppc40x_defconfig
arm dove_defconfig
arm jornada720_defconfig
powerpc mpc837x_rdb_defconfig
powerpc akebono_defconfig
arm socfpga_defconfig
riscv allyesconfig
arm cm_x300_defconfig
mips malta_defconfig
arm pxa168_defconfig
openrisc simple_smp_defconfig
powerpc mpc834x_itx_defconfig
sh polaris_defconfig
arm pleb_defconfig
powerpc mpc834x_mds_defconfig
arm simpad_defconfig
s390 zfcpdump_defconfig
arc nsimosci_hs_smp_defconfig
arm hisi_defconfig
sh sh2007_defconfig
powerpc mpc512x_defconfig
mips malta_kvm_defconfig
c6x dsk6455_defconfig
arm h5000_defconfig
powerpc ppa8548_defconfig
powerpc mpc8315_rdb_defconfig
powerpc tqm8xx_defconfig
mips ip27_defconfig
powerpc64 defconfig
arm ep93xx_defconfig
mips ath25_defconfig
microblaze mmu_defconfig
mips rt305x_defconfig
sh sh03_defconfig
sparc64 defconfig
arm colibri_pxa300_defconfig
arm corgi_defconfig
sh kfr2r09_defconfig
sh sdk7786_defconfig
mips ip22_defconfig
sh se7722_defconfig
powerpc linkstation_defconfig
arm oxnas_v6_defconfig
riscv rv32_defconfig
sh rsk7201_defconfig
h8300 h8s-sim_defconfig
arm pxa3xx_defconfig
ia64 alldefconfig
sh se7721_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201127
i386 randconfig-a003-20201127
i386 randconfig-a002-20201127
i386 randconfig-a005-20201127
i386 randconfig-a001-20201127
i386 randconfig-a006-20201127
x86_64 randconfig-a015-20201127
x86_64 randconfig-a011-20201127
x86_64 randconfig-a014-20201127
x86_64 randconfig-a016-20201127
x86_64 randconfig-a012-20201127
x86_64 randconfig-a013-20201127
i386 randconfig-a012-20201127
i386 randconfig-a013-20201127
i386 randconfig-a011-20201127
i386 randconfig-a016-20201127
i386 randconfig-a014-20201127
i386 randconfig-a015-20201127
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201127
x86_64 randconfig-a003-20201127
x86_64 randconfig-a004-20201127
x86_64 randconfig-a005-20201127
x86_64 randconfig-a002-20201127
x86_64 randconfig-a001-20201127
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 2551450071df2dabd7134e548ac209688ac6741d
From: kernel test robot @ 2020-11-28 1:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 2551450071df2dabd7134e548ac209688ac6741d Automatic merge of 'master' into merge (2020-11-27 00:11)
elapsed time: 2160m
configs tested: 176
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc axs101_defconfig
mips pic32mzda_defconfig
arm imx_v6_v7_defconfig
powerpc64 alldefconfig
sh sh7724_generic_defconfig
m68k m5307c3_defconfig
csky alldefconfig
xtensa iss_defconfig
arm efm32_defconfig
powerpc sam440ep_defconfig
m68k m5475evb_defconfig
xtensa smp_lx200_defconfig
arm mv78xx0_defconfig
powerpc ep88xc_defconfig
powerpc fsp2_defconfig
powerpc acadia_defconfig
arc allyesconfig
powerpc mpc8313_rdb_defconfig
powerpc mpc83xx_defconfig
arm viper_defconfig
s390 defconfig
sh ap325rxa_defconfig
powerpc pasemi_defconfig
mips bigsur_defconfig
mips omega2p_defconfig
xtensa common_defconfig
powerpc kilauea_defconfig
xtensa xip_kc705_defconfig
parisc generic-32bit_defconfig
arm magician_defconfig
powerpc currituck_defconfig
powerpc tqm8548_defconfig
sh migor_defconfig
powerpc skiroot_defconfig
powerpc mpc832x_mds_defconfig
sh se7712_defconfig
mips jmr3927_defconfig
powerpc makalu_defconfig
mips loongson1c_defconfig
alpha defconfig
arm s3c2410_defconfig
powerpc cell_defconfig
sh rts7751r2dplus_defconfig
xtensa cadence_csp_defconfig
powerpc mpc5200_defconfig
powerpc chrp32_defconfig
arm tct_hammer_defconfig
powerpc rainier_defconfig
m68k mvme147_defconfig
sh sdk7786_defconfig
powerpc sequoia_defconfig
arm lpc32xx_defconfig
powerpc akebono_defconfig
arm davinci_all_defconfig
powerpc bluestone_defconfig
mips rb532_defconfig
mips ip32_defconfig
c6x evmc6474_defconfig
arm prima2_defconfig
powerpc arches_defconfig
x86_64 alldefconfig
sh shx3_defconfig
mips decstation_r4k_defconfig
powerpc mpc8315_rdb_defconfig
powerpc tqm8xx_defconfig
mips ip27_defconfig
powerpc64 defconfig
arm ep93xx_defconfig
mips ath25_defconfig
microblaze mmu_defconfig
arm ebsa110_defconfig
arm corgi_defconfig
mips rbtx49xx_defconfig
sh sh7757lcr_defconfig
arm pxa3xx_defconfig
powerpc tqm8540_defconfig
arm trizeps4_defconfig
arm nhk8815_defconfig
powerpc mpc8272_ads_defconfig
xtensa defconfig
mips lemote2f_defconfig
mips decstation_defconfig
arc hsdk_defconfig
powerpc ppc40x_defconfig
sh dreamcast_defconfig
arm spear13xx_defconfig
um kunit_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20201126
x86_64 randconfig-a003-20201126
x86_64 randconfig-a004-20201126
x86_64 randconfig-a005-20201126
x86_64 randconfig-a001-20201126
x86_64 randconfig-a002-20201126
i386 randconfig-a004-20201126
i386 randconfig-a003-20201126
i386 randconfig-a002-20201126
i386 randconfig-a005-20201126
i386 randconfig-a001-20201126
i386 randconfig-a006-20201126
i386 randconfig-a004-20201127
i386 randconfig-a003-20201127
i386 randconfig-a002-20201127
i386 randconfig-a005-20201127
i386 randconfig-a001-20201127
i386 randconfig-a006-20201127
x86_64 randconfig-a015-20201127
x86_64 randconfig-a011-20201127
x86_64 randconfig-a014-20201127
x86_64 randconfig-a016-20201127
x86_64 randconfig-a012-20201127
x86_64 randconfig-a013-20201127
i386 randconfig-a012-20201127
i386 randconfig-a013-20201127
i386 randconfig-a011-20201127
i386 randconfig-a016-20201127
i386 randconfig-a014-20201127
i386 randconfig-a015-20201127
i386 randconfig-a012-20201126
i386 randconfig-a013-20201126
i386 randconfig-a011-20201126
i386 randconfig-a016-20201126
i386 randconfig-a014-20201126
i386 randconfig-a015-20201126
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201127
x86_64 randconfig-a003-20201127
x86_64 randconfig-a004-20201127
x86_64 randconfig-a005-20201127
x86_64 randconfig-a002-20201127
x86_64 randconfig-a001-20201127
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 10f78fd0dabbc3856ddd67b09a46abdedb045913
From: kernel test robot @ 2020-11-28 1:10 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 10f78fd0dabbc3856ddd67b09a46abdedb045913 powerpc/numa: Fix a regression on memoryless node 0
elapsed time: 772m
configs tested: 149
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm efm32_defconfig
powerpc sam440ep_defconfig
m68k m5475evb_defconfig
xtensa smp_lx200_defconfig
arm mv78xx0_defconfig
powerpc mpc836x_rdk_defconfig
mips db1xxx_defconfig
arc haps_hs_defconfig
powerpc ppc6xx_defconfig
powerpc eiger_defconfig
parisc allyesconfig
mips workpad_defconfig
nds32 allnoconfig
powerpc arches_defconfig
mips gpr_defconfig
m68k sun3_defconfig
sh se7206_defconfig
arm lpc18xx_defconfig
arm keystone_defconfig
sh sh7785lcr_32bit_defconfig
arm imote2_defconfig
arm qcom_defconfig
m68k atari_defconfig
arm omap1_defconfig
mips pistachio_defconfig
powerpc mpc85xx_cds_defconfig
mips loongson1c_defconfig
alpha defconfig
arm s3c2410_defconfig
powerpc cell_defconfig
sh rts7751r2dplus_defconfig
xtensa cadence_csp_defconfig
arm aspeed_g5_defconfig
arc nsim_700_defconfig
arm xcep_defconfig
powerpc skiroot_defconfig
m68k m5407c3_defconfig
mips cu1000-neo_defconfig
x86_64 alldefconfig
nds32 defconfig
powerpc ppc40x_defconfig
arm dove_defconfig
arm jornada720_defconfig
powerpc mpc837x_rdb_defconfig
arm cm_x300_defconfig
mips malta_defconfig
arm pxa168_defconfig
openrisc simple_smp_defconfig
powerpc mpc834x_itx_defconfig
sh polaris_defconfig
arm pleb_defconfig
powerpc mpc834x_mds_defconfig
arm simpad_defconfig
powerpc tqm8xx_defconfig
mips ip27_defconfig
powerpc64 defconfig
arm ep93xx_defconfig
mips ath25_defconfig
microblaze mmu_defconfig
mips rt305x_defconfig
sh sh03_defconfig
sparc64 defconfig
m68k m5208evb_defconfig
arm h3600_defconfig
sh edosk7760_defconfig
powerpc klondike_defconfig
arm colibri_pxa300_defconfig
arm corgi_defconfig
sh kfr2r09_defconfig
sh sdk7786_defconfig
mips ip22_defconfig
sh se7722_defconfig
powerpc linkstation_defconfig
arm oxnas_v6_defconfig
riscv rv32_defconfig
sh rsk7201_defconfig
h8300 h8s-sim_defconfig
arm pxa3xx_defconfig
ia64 alldefconfig
sh se7721_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201127
i386 randconfig-a003-20201127
i386 randconfig-a002-20201127
i386 randconfig-a005-20201127
i386 randconfig-a001-20201127
i386 randconfig-a006-20201127
x86_64 randconfig-a015-20201127
x86_64 randconfig-a011-20201127
x86_64 randconfig-a014-20201127
x86_64 randconfig-a016-20201127
x86_64 randconfig-a012-20201127
x86_64 randconfig-a013-20201127
i386 randconfig-a012-20201127
i386 randconfig-a013-20201127
i386 randconfig-a011-20201127
i386 randconfig-a016-20201127
i386 randconfig-a014-20201127
i386 randconfig-a015-20201127
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201127
x86_64 randconfig-a003-20201127
x86_64 randconfig-a004-20201127
x86_64 randconfig-a005-20201127
x86_64 randconfig-a002-20201127
x86_64 randconfig-a001-20201127
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] ALSA: ppc: remove redundant checks in PS3 driver probe
From: Leonard Goehrs @ 2020-11-27 15:22 UTC (permalink / raw)
To: u.kleine-koenig, geoff, perex, tiwai, mpe
Cc: alsa-devel, paulus, kernel, Geert Uytterhoeven, Leonard Goehrs,
linuxppc-dev
In-Reply-To: <20201127094547.4zcyeycfrriitkqx@pengutronix.de>
The check for the FW_FEATURE_PS3_LV1 firmware feature is already performed
in ps3_system_bus_init() before registering the driver. So if the probe
function is actually used, this feature is already known to be available.
The check for the match id is also superfluous; the condition is always
true because the bus' match function (ps3_system_bus_match()) only
considers this driver for devices having:
dev->match_id == snd_ps3_bus_driver_info.match_id.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Leonard Goehrs <l.goehrs@pengutronix.de>
---
sound/ppc/snd_ps3.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
index 58bb49fff184..b6e4aa3df870 100644
--- a/sound/ppc/snd_ps3.c
+++ b/sound/ppc/snd_ps3.c
@@ -896,11 +896,6 @@ static int snd_ps3_driver_probe(struct ps3_system_bus_device *dev)
u64 lpar_addr, lpar_size;
static u64 dummy_mask;
- if (WARN_ON(!firmware_has_feature(FW_FEATURE_PS3_LV1)))
- return -ENODEV;
- if (WARN_ON(dev->match_id != PS3_MATCH_ID_SOUND))
- return -ENODEV;
-
the_card.ps3_dev = dev;
ret = ps3_open_hv_device(dev);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ALSA: ppc: remove redundant checks in PS3 driver probe
From: Geoff Levand @ 2020-11-27 19:39 UTC (permalink / raw)
To: Leonard Goehrs, u.kleine-koenig, perex, tiwai, mpe
Cc: alsa-devel, paulus, kernel, Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20201127152259.1470079-1-l.goehrs@pengutronix.de>
On 11/27/20 7:22 AM, Leonard Goehrs wrote:
> The check for the FW_FEATURE_PS3_LV1 firmware feature is already performed
> in ps3_system_bus_init() before registering the driver. So if the probe
> function is actually used, this feature is already known to be available.
>
> The check for the match id is also superfluous; the condition is always
> true because the bus' match function (ps3_system_bus_match()) only
> considers this driver for devices having:
> dev->match_id == snd_ps3_bus_driver_info.match_id.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Leonard Goehrs <l.goehrs@pengutronix.de>
Seems OK with v5.9 on PS3.
Tested by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void
From: Geoff Levand @ 2020-11-27 19:39 UTC (permalink / raw)
To: Uwe Kleine-König, Jaroslav Kysela, Takashi Iwai,
Michael Ellerman, Jens Axboe, Jim Paris, Arnd Bergmann,
Greg Kroah-Hartman, David S. Miller, Jakub Kicinski,
James E.J. Bottomley, Martin K. Petersen, Alan Stern,
Bartlomiej Zolnierkiewicz
Cc: alsa-devel, linux-scsi, linux-usb, linux-fbdev, dri-devel,
linux-block, Paul Mackerras, netdev, linuxppc-dev
In-Reply-To: <20201126165950.2554997-2-u.kleine-koenig@pengutronix.de>
On 11/26/20 8:59 AM, Uwe Kleine-König wrote:
> The driver core ignores the return value of struct device_driver::remove
> because there is only little that can be done. For the shutdown callback
> it's ps3_system_bus_shutdown() which ignores the return value.
>
> To simplify the quest to make struct device_driver::remove return void,
> let struct ps3_system_bus_driver::remove return void, too. All users
> already unconditionally return 0, this commit makes it obvious that
> returning an error code is a bad idea and ensures future users behave
> accordingly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Seems OK with v5.9 on PS3.
Tested by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH 1/2] ALSA: ppc: drop if block with always false condition
From: Geoff Levand @ 2020-11-27 19:37 UTC (permalink / raw)
To: Uwe Kleine-König, Jaroslav Kysela, Takashi Iwai,
Michael Ellerman, Jens Axboe, Jim Paris, Arnd Bergmann,
Greg Kroah-Hartman, David S. Miller, Jakub Kicinski,
James E.J. Bottomley, Martin K. Petersen, Alan Stern,
Bartlomiej Zolnierkiewicz, Leonard Goehrs
Cc: alsa-devel, linux-scsi, linux-usb, linux-fbdev, dri-devel,
linux-block, Paul Mackerras, netdev, Geert Uytterhoeven,
linuxppc-dev
In-Reply-To: <20201126165950.2554997-1-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On 11/26/20 8:59 AM, Uwe Kleine-König wrote:
> The remove callback is only called for devices that were probed
> successfully before. As the matching probe function cannot complete
> without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to
> check this here.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
I tested your two patches plus Leonard's patch 'ALSA: ppc: remove
redundant checks in PS3 driver probe' applied to v5.9 on the PS3,
and they seem to work fine.
Thanks for both your efforts.
Tested by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.10-4 tag
From: pr-tracker-bot @ 2020-11-27 19:19 UTC (permalink / raw)
To: Michael Ellerman
Cc: sfr, Linus Torvalds, linux-kernel, npiggin, oss, clg,
linuxppc-dev
In-Reply-To: <877dq7x91s.fsf@mpe.ellerman.id.au>
The pull request you sent on Fri, 27 Nov 2020 23:45:35 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.10-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/95e1c7b1dd4a91451040ff0f41c5b5173503a38e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 13/13] ibmvfc: register Sub-CRQ handles with VIOS during channel setup
From: Brian King @ 2020-11-27 17:50 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-14-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 12/13] ibmvfc: send commands down HW Sub-CRQ when channelized
From: Brian King @ 2020-11-27 17:50 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-13-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 10/13] ibmvfc: advertise client support for using hardware channels
From: Brian King @ 2020-11-27 17:49 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-11-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 11/13] ibmvfc: set and track hw queue in ibmvfc_event struct
From: Brian King @ 2020-11-27 17:50 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-12-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 09/13] ibmvfc: implement channel enquiry and setup commands
From: Brian King @ 2020-11-27 17:49 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-10-tyreld@linux.ibm.com>
On 11/25/20 7:48 PM, Tyrel Datwyler wrote:
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -4462,6 +4464,118 @@ static void ibmvfc_discover_targets(struct ibmvfc_host *vhost)
> ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
> }
>
> +static void ibmvfc_channel_setup_done(struct ibmvfc_event *evt)
> +{
> + struct ibmvfc_host *vhost = evt->vhost;
> + u32 mad_status = be16_to_cpu(evt->xfer_iu->channel_setup.common.status);
> + int level = IBMVFC_DEFAULT_LOG_LEVEL;
> +
> + ibmvfc_free_event(evt);
> +
> + switch (mad_status) {
> + case IBMVFC_MAD_SUCCESS:
> + ibmvfc_dbg(vhost, "Channel Setup succeded\n");
> + vhost->do_enquiry = 0;
> + break;
> + case IBMVFC_MAD_FAILED:
> + level += ibmvfc_retry_host_init(vhost);
> + ibmvfc_log(vhost, level, "Channel Setup failed\n");
> + fallthrough;
> + case IBMVFC_MAD_DRIVER_FAILED:
> + return;
> + default:
> + dev_err(vhost->dev, "Invalid Channel Setup response: 0x%x\n",
> + mad_status);
> + ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
> + return;
> + }
> +
> + ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_QUERY);
> + wake_up(&vhost->work_wait_q);
> +}
> +
> +static void ibmvfc_channel_setup(struct ibmvfc_host *vhost)
> +{
> + struct ibmvfc_channel_setup_mad *mad;
> + struct ibmvfc_channel_setup *setup_buf = vhost->channel_setup_buf;
> + struct ibmvfc_event *evt = ibmvfc_get_event(vhost);
> +
> + memset(setup_buf, 0, sizeof(*setup_buf));
> + setup_buf->flags = cpu_to_be32(IBMVFC_CANCEL_CHANNELS);
> +
> + ibmvfc_init_event(evt, ibmvfc_channel_setup_done, IBMVFC_MAD_FORMAT);
> + mad = &evt->iu.channel_setup;
> + memset(mad, 0, sizeof(*mad));
> + mad->common.version = cpu_to_be32(1);
> + mad->common.opcode = cpu_to_be32(IBMVFC_CHANNEL_SETUP);
> + mad->common.length = cpu_to_be16(sizeof(*mad));
> + mad->buffer.va = cpu_to_be64(vhost->channel_setup_dma);
> + mad->buffer.len = cpu_to_be32(sizeof(*vhost->channel_setup_buf));
> +
> + ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_INIT_WAIT);
> +
> + if (!ibmvfc_send_event(evt, vhost, default_timeout))
> + ibmvfc_dbg(vhost, "Sent channel setup\n");
> + else
> + ibmvfc_link_down(vhost, IBMVFC_LINK_DOWN);
> +}
> +
> +static void ibmvfc_channel_enquiry_done(struct ibmvfc_event *evt)
> +{
> + struct ibmvfc_host *vhost = evt->vhost;
> + struct ibmvfc_channel_enquiry *rsp = &evt->xfer_iu->channel_enquiry;
> + u32 mad_status = be16_to_cpu(rsp->common.status);
> + int level = IBMVFC_DEFAULT_LOG_LEVEL;
> +
> + switch (mad_status) {
> + case IBMVFC_MAD_SUCCESS:
> + ibmvfc_dbg(vhost, "Channel Enquiry succeeded\n");
> + vhost->max_vios_scsi_channels = be32_to_cpu(rsp->num_scsi_subq_channels);
You need a ibmvfc_free_event(evt) here so you don't leak events.
> + break;
> + case IBMVFC_MAD_FAILED:
> + level += ibmvfc_retry_host_init(vhost);
> + ibmvfc_log(vhost, level, "Channel Enquiry failed\n");
> + ibmvfc_free_event(evt);
Looks like you are freeing this event twice due to the fallthrough...
> + fallthrough;
> + case IBMVFC_MAD_DRIVER_FAILED:
> + ibmvfc_free_event(evt);
> + return;
> + default:
> + dev_err(vhost->dev, "Invalid Channel Enquiry response: 0x%x\n",
> + mad_status);
> + ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
> + ibmvfc_free_event(evt);
> + return;
> + }
> +
> + ibmvfc_channel_setup(vhost);
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 08/13] ibmvfc: map/request irq and register Sub-CRQ interrupt handler
From: Brian King @ 2020-11-27 17:48 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-9-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 07/13] ibmvfc: define Sub-CRQ interrupt handler routine
From: Brian King @ 2020-11-27 17:48 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-8-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 06/13] ibmvfc: add handlers to drain and complete Sub-CRQ responses
From: Brian King @ 2020-11-27 17:47 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-7-tyreld@linux.ibm.com>
On 11/25/20 7:48 PM, Tyrel Datwyler wrote:
> The logic for iterating over the Sub-CRQ responses is similiar to that
> of the primary CRQ. Add the necessary handlers for processing those
> responses.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 72 ++++++++++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 6eaedda4917a..a8730522920e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -3371,6 +3371,78 @@ static int ibmvfc_toggle_scrq_irq(struct ibmvfc_sub_queue *scrq, int enable)
> return rc;
> }
>
> +static void ibmvfc_handle_scrq(struct ibmvfc_crq *crq, struct ibmvfc_host *vhost)
> +{
> + struct ibmvfc_event *evt = (struct ibmvfc_event *)be64_to_cpu(crq->ioba);
> +
> + switch (crq->valid) {
> + case IBMVFC_CRQ_CMD_RSP:
> + break;
> + default:
> + dev_err(vhost->dev, "Got and invalid message type 0x%02x\n", crq->valid);
Is this correct? Can't we get transport events here as well?
> + return;
> + }
> +
> + /* The only kind of payload CRQs we should get are responses to
> + * things we send. Make sure this response is to something we
> + * actually sent
> + */
> + if (unlikely(!ibmvfc_valid_event(&vhost->pool, evt))) {
> + dev_err(vhost->dev, "Returned correlation_token 0x%08llx is invalid!\n",
> + crq->ioba);
> + return;
> + }
> +
> + if (unlikely(atomic_read(&evt->free))) {
> + dev_err(vhost->dev, "Received duplicate correlation_token 0x%08llx!\n",
> + crq->ioba);
> + return;
> + }
> +
> + del_timer(&evt->timer);
> + list_del(&evt->queue);
> + ibmvfc_trc_end(evt);
> + evt->done(evt);
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 05/13] ibmvfc: add Sub-CRQ IRQ enable/disable routine
From: Brian King @ 2020-11-27 17:47 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-6-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 04/13] ibmvfc: add alloc/dealloc routines for SCSI Sub-CRQ Channels
From: Brian King @ 2020-11-27 17:46 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-5-tyreld@linux.ibm.com>
On 11/25/20 7:48 PM, Tyrel Datwyler wrote:
> Allocate a set of Sub-CRQs in advance. During channel setup the client
> and VIOS negotiate the number of queues the VIOS supports and the number
> that the client desires to request. Its possible that the final channel
> resources allocated is less than requested, but the client is still
> responsible for sending handles for every queue it is hoping for.
>
> Also, provide deallocation cleanup routines.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 115 +++++++++++++++++++++++++++++++++
> drivers/scsi/ibmvscsi/ibmvfc.h | 1 +
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 260b82e3cc01..571abdb48384 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -4983,6 +4983,114 @@ static int ibmvfc_init_crq(struct ibmvfc_host *vhost)
> return retrc;
> }
>
> +static int ibmvfc_register_scsi_channel(struct ibmvfc_host *vhost,
> + int index)
> +{
> + struct device *dev = vhost->dev;
> + struct vio_dev *vdev = to_vio_dev(dev);
> + struct ibmvfc_sub_queue *scrq = &vhost->scsi_scrqs.scrqs[index];
> + int rc = -ENOMEM;
> +
> + ENTER;
> +
> + scrq->msgs = (struct ibmvfc_sub_crq *)get_zeroed_page(GFP_KERNEL);
> + if (!scrq->msgs)
> + return rc;
> +
> + scrq->size = PAGE_SIZE / sizeof(*scrq->msgs);
> + scrq->msg_token = dma_map_single(dev, scrq->msgs, PAGE_SIZE,
> + DMA_BIDIRECTIONAL);
> +
> + if (dma_mapping_error(dev, scrq->msg_token))
> + goto dma_map_failed;
> +
> + rc = h_reg_sub_crq(vdev->unit_address, scrq->msg_token, PAGE_SIZE,
> + &scrq->cookie, &scrq->hw_irq);
> +
> + if (rc) {
> + dev_warn(dev, "Error registering sub-crq: %d\n", rc);
> + dev_warn(dev, "Firmware may not support MQ\n");
> + goto reg_failed;
> + }
> +
> + scrq->hwq_id = index;
> + scrq->vhost = vhost;
> +
> + LEAVE;
> + return 0;
> +
> +reg_failed:
> + dma_unmap_single(dev, scrq->msg_token, PAGE_SIZE, DMA_BIDIRECTIONAL);
> +dma_map_failed:
> + free_page((unsigned long)scrq->msgs);
> + LEAVE;
> + return rc;
> +}
> +
> +static void ibmvfc_deregister_scsi_channel(struct ibmvfc_host *vhost, int index)
> +{
> + struct device *dev = vhost->dev;
> + struct vio_dev *vdev = to_vio_dev(dev);
> + struct ibmvfc_sub_queue *scrq = &vhost->scsi_scrqs.scrqs[index];
> + long rc;
> +
> + ENTER;
> +
> + do {
> + rc = plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address,
> + scrq->cookie);
> + } while (rc == H_BUSY || H_IS_LONG_BUSY(rc));
> +
> + if (rc)
> + dev_err(dev, "Failed to free sub-crq[%d]: rc=%ld\n", index, rc);
> +
> + dma_unmap_single(dev, scrq->msg_token, PAGE_SIZE, DMA_BIDIRECTIONAL);
> + free_page((unsigned long)scrq->msgs);
> + LEAVE;
> +}
> +
> +static int ibmvfc_init_sub_crqs(struct ibmvfc_host *vhost)
> +{
> + int i, j;
> +
> + ENTER;
> +
> + vhost->scsi_scrqs.scrqs = kcalloc(vhost->client_scsi_channels,
> + sizeof(*vhost->scsi_scrqs.scrqs),
> + GFP_KERNEL);
> + if (!vhost->scsi_scrqs.scrqs)
> + return -1;
> +
> + for (i = 0; i < vhost->client_scsi_channels; i++) {
> + if (ibmvfc_register_scsi_channel(vhost, i)) {
> + for (j = i; j > 0; j--)
> + ibmvfc_deregister_scsi_channel(vhost, j - 1);
> + kfree(vhost->scsi_scrqs.scrqs);
> + LEAVE;
> + return -1;
> + }
> + }
> +
> + LEAVE;
> + return 0;
> +}
> +
> +static void ibmvfc_release_sub_crqs(struct ibmvfc_host *vhost)
> +{
> + int i;
> +
> + ENTER;
> + if (!vhost->scsi_scrqs.scrqs)
> + return;
> +
> + for (i = 0; i < vhost->client_scsi_channels; i++)
> + ibmvfc_deregister_scsi_channel(vhost, i);
> +
> + vhost->scsi_scrqs.active_queues = 0;
> + kfree(vhost->scsi_scrqs.scrqs);
Do you want to NULL this out after you free it do you don't keep
a reference to a freed page around?
> + LEAVE;
> +}
> +
> /**
> * ibmvfc_free_mem - Free memory for vhost
> * @vhost: ibmvfc host struct
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 03/13] ibmvfc: add Subordinate CRQ definitions
From: Brian King @ 2020-11-27 17:46 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-4-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 02/13] ibmvfc: define hcall wrapper for registering a Sub-CRQ
From: Brian King @ 2020-11-27 17:45 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-3-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 01/13] ibmvfc: add vhost fields and defaults for MQ enablement
From: Brian King @ 2020-11-27 17:45 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20201126014824.123831-2-tyreld@linux.ibm.com>
On 11/25/20 7:48 PM, Tyrel Datwyler wrote:
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h
> index 9d58cfd774d3..8225bdbb127e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.h
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.h
> @@ -41,6 +41,11 @@
> #define IBMVFC_DEFAULT_LOG_LEVEL 2
> #define IBMVFC_MAX_CDB_LEN 16
> #define IBMVFC_CLS3_ERROR 0
> +#define IBMVFC_MQ 0
Given that IBMVFC_MQ is getting set to 0 here, that means mq_enabled is also
always zero, so am I correct that a lot of this code being added is not
yet capable of being executed?
> +#define IBMVFC_SCSI_CHANNELS 0
Similar comment here...
> +#define IBMVFC_SCSI_HW_QUEUES 1
I don't see any subsequent patches in this series that would ever result
in nr_hw_queues getting set to anything other than 1. Is that future work
planned or am I missing something?
> +#define IBMVFC_MIG_NO_SUB_TO_CRQ 0
> +#define IBMVFC_MIG_NO_N_TO_M 0
>
> /*
> * Ensure we have resources for ERP and initialization:
> @@ -826,6 +831,10 @@ struct ibmvfc_host {
> int delay_init;
> int scan_complete;
> int logged_in;
> + int mq_enabled;
> + int using_channels;
> + int do_enquiry;
> + int client_scsi_channels;
> int aborting_passthru;
> int events_to_log;
> #define IBMVFC_AE_LINKUP 0x0001
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/8] Rid W=1 warnings in Net
From: Jakub Kicinski @ 2020-11-27 17:39 UTC (permalink / raw)
To: Lee Jones
Cc: Paul Durrant, Kurt Kanzenbach, Alexei Starovoitov,
Gustavo A. R. Silva, Peter Cammaert, Paul Mackerras,
Sukadev Bhattiprolu, Wei Liu, Daniel Borkmann, John Fastabend,
Santiago Leon, xen-devel, Grygorii Strashko, Thomas Falcon,
Jesper Dangaard Brouer, Jens Osterkamp, Rusty Russell,
Daris A Nevil, Lijun Pan, Ivan Khoronzhuk, Nicolas Pitre,
Geoff Levand, netdev, linux-kernel, Erik Stahlman, John Allen,
Utz Bacher, Dany Madden, bpf, linuxppc-dev, David S. Miller,
Russell King
In-Reply-To: <20201126133853.3213268-1-lee.jones@linaro.org>
On Thu, 26 Nov 2020 13:38:45 +0000 Lee Jones wrote:
> Resending the stragglers.
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
This set doesn't apply to net-next, please rebase.
^ permalink raw reply
* Re: [PATCH] ALSA: ppc: remove redundant checks in PS3 driver probe
From: Uwe Kleine-König @ 2020-11-27 17:34 UTC (permalink / raw)
To: Leonard Goehrs
Cc: alsa-devel, geoff, tiwai, perex, paulus, kernel,
Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20201127152259.1470079-1-l.goehrs@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
Hallo Leonard,
On Fri, Nov 27, 2020 at 04:22:59PM +0100, Leonard Goehrs wrote:
> The check for the FW_FEATURE_PS3_LV1 firmware feature is already performed
> in ps3_system_bus_init() before registering the driver. So if the probe
> function is actually used, this feature is already known to be available.
>
> The check for the match id is also superfluous; the condition is always
> true because the bus' match function (ps3_system_bus_match()) only
> considers this driver for devices having:
> dev->match_id == snd_ps3_bus_driver_info.match_id.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Leonard Goehrs <l.goehrs@pengutronix.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks for picking this up.
Best regards and have a nice week-end,
Uwe Kleine-König
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: powerpc 5.10-rcN boot failures with RCU_SCALE_TEST=m
From: Uladzislau Rezki @ 2020-11-27 16:41 UTC (permalink / raw)
To: Daniel Axtens; +Cc: rcu, linuxppc-dev
In-Reply-To: <87eekfh80a.fsf@dja-thinkpad.axtens.net>
> Hi all,
>
> I'm having some difficulty tracking down a bug.
>
> Some configurations of the powerpc kernel since somewhere in the 5.10
> merge window fail to boot on some ppc64 systems. They hang while trying
> to bring up SMP. It seems to depend on the RCU_SCALE/PERF_TEST option.
> (It was renamed in the 5.10 merge window.)
>
> I can reproduce it as follows with qemu tcg:
>
> make -j64 pseries_le_defconfig
> scripts/config -m RCU_SCALE_TEST
> scripts/config -m RCU_PERF_TEST
> make -j 64 vmlinux CC="ccache gcc"
>
> qemu-system-ppc64 -cpu power9 -M pseries -m 1G -nographic -vga none -smp 4 -kernel vmlinux
>
> ...
> [ 0.036284][ T0] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
> [ 0.036481][ T0] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
> [ 0.148168][ T1] POWER9 performance monitor hardware support registered
> [ 0.151118][ T1] rcu: Hierarchical SRCU implementation.
> [ 0.186660][ T1] smp: Bringing up secondary CPUs ...
> <hangs>
>
I am not sure if that is helpful but i checked it on my x86_64 system
using the cross compiled for powerpc Linux kernel:
<snip>
urezki@pc638:~/data/coding/linux-rcu.git$ powerpc64-linux-gnu-gcc
--version
powerpc64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
urezki@pc638:~/data/coding/linux-rcu.git$
<snip>
with ARCH=powerpc make -j64 pseries_defconfig configuration. I used the 5.10.0-rc1 kernel.
<snip>
urezki@pc638:~/data/coding/linux-rcu.git$ qemu-system-ppc64 --version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
urezki@pc638:~/data/coding/linux-rcu.git$
<snip>
On my setup i can run the kernel with and without the modules which are
in question. So
qemu-system-ppc64 -cpu power9 -M pseries -m 1G -nographic -vga none -smp 4 -kernel ./vmlinux
works for both cases, with RCU_SCALE and without.
Just in case, maybe this information can be useful also.
--
Vlad Rezki
^ permalink raw reply
* [powerpc:next-test 89/109] arch/powerpc/kernel/vdso.c:192:1-3: WARNING: PTR_ERR_OR_ZERO can be used
From: kernel test robot @ 2020-11-27 15:38 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 278f4532318c176ef8a22a78f45a8c8a30abe40b
commit: 08bbcbede11f0a75d620799ef8fc1f081ac66c79 [89/109] powerpc/vdso: Move to _install_special_mapping() and remove arch_vma_name()
config: powerpc-randconfig-c003-20201127 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"coccinelle warnings: (new ones prefixed by >>)"
>> arch/powerpc/kernel/vdso.c:192:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21031 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox