[powerpc:next] BUILD SUCCESS 4958b3a7bb0f6669e569684e3cd90e413f450ba8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 4958b3a7bb0f6669e569684e3cd90e413f450ba8 powerpc/xics: Check return value of kasprintf in icp_native_map_one_cpu elapsed time: 2113m configs tested: 53 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc arm allnoconfig gcc arm defconfig clang arm64 allnoconfig gcc arm64 defconfig gcc csky allnoconfig gcc cskydefconfig gcc hexagon allnoconfig clang hexagon defconfig clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze defconfig gcc mips allnoconfig clang mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2 defconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc parisc allmodconfig gcc parisc allyesconfig gcc powerpc allmodconfig clang powerpc allyesconfig clang riscvallmodconfig gcc riscvallyesconfig gcc riscv rv32_defconfig clang s390 allmodconfig gcc s390 allyesconfig gcc sh allmodconfig gcc sh allyesconfig gcc sparcallmodconfig gcc sparc64 allmodconfig gcc sparc64 allyesconfig gcc um allmodconfig clang um allyesconfig clang x86_64allnoconfig gcc x86_64 allyesconfig clang x86_64 defconfig gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[powerpc:next-test] BUILD SUCCESS 5a0756654f337bc86a5a85e50bcf8a3a070ade42
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 5a0756654f337bc86a5a85e50bcf8a3a070ade42 powerpc/lib: Avoid array bounds warnings in vec ops elapsed time: 2068m configs tested: 63 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig clang arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc hexagon allnoconfig clang hexagon defconfig clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allnoconfig clang nios2 allnoconfig gcc nios2 defconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc powerpc allmodconfig clang powerpc allyesconfig clang riscvallmodconfig gcc riscvallyesconfig gcc riscv rv32_defconfig clang s390 allmodconfig gcc s390 allyesconfig gcc sh allmodconfig gcc sh allyesconfig gcc sparcallmodconfig gcc sparc64 allmodconfig gcc sparc64 allyesconfig gcc um allmodconfig clang um allyesconfig clang x86_64allnoconfig gcc x86_64 allyesconfig clang x86_64 defconfig gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH 0/8] devm_led_classdev_register() usage problem
Hello Andy
Thanks for the review.
On 11/24/23 18:28, Andy Shevchenko wrote:
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead to a problem due to led_classdev_unregister()
implementation calls led_set_brightness() to turn off the led.
led_set_brightness() may call one of the module's brightness_set callbacks.
If that callback uses module's resources allocated without using devm funcs()
then those resources will be already freed at module's remove() callback and
we may have use-after-free situation.
Here is an example:
module_probe()
{
devm_led_classdev_register(module_brightness_set_cb);
mutex_init();
}
module_brightness_set_cb()
{
mutex_lock();
do_set_brightness();
mutex_unlock();
}
module_remove()
{
mutex_destroy();
}
at rmmod:
module_remove()
->mutex_destroy();
devres_release_all()
->led_classdev_unregister();
->led_set_brightness();
->module_brightness_set_cb();
->mutex_lock(); /* use-after-free */
I think it's an architectural issue and should be discussed thoroughly.
Some thoughts about fixing it as a start:
1) drivers can use devm_led_classdev_unregister() to explicitly free leds before
dependend resources are freed. devm_led_classdev_register() remains being useful
to simplify probe implementation.
As a proof of concept I examined all drivers from drivers/leds and prepared
patches where it's needed. Sometimes it was not as clean as just calling
devm_led_classdev_unregister() because several drivers do not track
their leds object at all - they can call devm_led_classdev_register() and drop
the
returned pointer. In that case I used devres group API.
Drivers outside drivers/leds should be checked too after discussion.
2) remove led_set_brightness from led_classdev_unregister() and force the
drivers
to turn leds off at shutdown. May be add check that led's brightness is 0
at led_classdev_unregister() and put a warning to dmesg if it's not.
Actually in many cases it doesn't really need to turn off the leds manually
one-by-one
if driver shutdowns whole led controller. For the last case to disable the
warning
new flag can be brought in e.g LED_AUTO_OFF_AT_SHUTDOWN (similar to
LED_RETAIN_AT_SHUTDOWN).
NAK.
Just fix the drivers by wrapping mutex_destroy() into devm, There are many
doing so. You may be brave enough to introduce devm_mutex_init() somewhere
in include/linux/device*
Just one thing about mutex_destroy(). It seems like there's no single
opinion on should it be called in 100% cases e.g. in remove() paths.
For example in iio subsystem Jonathan suggests it can be dropped in
simple cases: https://www.spinics.net/lists/linux-iio/msg73423.html
So the question is can we just drop mutex_destroy() in module's remove()
callback here if that mutex is needed for devm subsequent callbacks?
--
Best regards
George
Re: [PATCH v1] powerpc: Add PVN support for HeXin C2000 processor
On Thu Nov 23, 2023 at 7:36 PM AEST, Zhao Ke wrote:
> HeXin Tech Co. has applied for a new PVN from the OpenPower Community
> for its new processor C2000. The OpenPower has assigned a new PVN
> and this newly assigned PVN is 0x0066, add pvr register related
> support for this PVN.
>
> Signed-off-by: Zhao Ke
> Link:
> https://discuss.openpower.foundation/t/how-to-get-a-new-pvr-for-processors-follow-power-isa/477/10
> ---
> v0 -> v1:
> - Fix .cpu_name with the correct description
> ---
> ---
> arch/powerpc/include/asm/reg.h| 1 +
> arch/powerpc/kernel/cpu_specs_book3s_64.h | 15 +++
> arch/powerpc/kvm/book3s_pr.c | 1 +
> arch/powerpc/mm/book3s64/pkeys.c | 3 ++-
> arch/powerpc/platforms/powernv/subcore.c | 3 ++-
> drivers/misc/cxl/cxl.h| 3 ++-
> 6 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 4ae4ab9090a2..7fd09f25452d 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -1361,6 +1361,7 @@
> #define PVR_POWER8E 0x004B
> #define PVR_POWER8NVL0x004C
> #define PVR_POWER8 0x004D
> +#define PVR_HX_C2000 0x0066
> #define PVR_POWER9 0x004E
> #define PVR_POWER10 0x0080
> #define PVR_BE 0x0070
> diff --git a/arch/powerpc/kernel/cpu_specs_book3s_64.h
> b/arch/powerpc/kernel/cpu_specs_book3s_64.h
> index c370c1b804a9..367c9f6d9be5 100644
> --- a/arch/powerpc/kernel/cpu_specs_book3s_64.h
> +++ b/arch/powerpc/kernel/cpu_specs_book3s_64.h
> @@ -238,6 +238,21 @@ static struct cpu_spec cpu_specs[] __initdata = {
> .machine_check_early= __machine_check_early_realmode_p8,
> .platform = "power8",
> },
> + { /* 2.07-compliant processor, HeXin C2000 processor */
> + .pvr_mask = 0x,
> + .pvr_value = 0x0066,
> + .cpu_name = "POWER8 (raw)",
If this is a raw mode, it should go with the raw POWER8 entry.
The raw vs architected entries are already out of order with
POWER6, but we should fix that too.
You may want your PVR mask to follow the other raw examples too,
but it depends on how you foresee PVR being used. Using 0x
allows you to increment the low part of the PVR and existing
kernels will continue to match it. You can then add a specific
match for the older version if you need to add special handling
for it (e.g., see how POWER9 is handled).
Do you want .cpu_name to be "POWER8 (raw)"? You could call it
"HX-C2000", as Michael suggested earlier.
> + .cpu_features = CPU_FTRS_POWER8,
> + .cpu_user_features = COMMON_USER_POWER8,
> + .cpu_user_features2 = COMMON_USER2_POWER8,
> + .mmu_features = MMU_FTRS_POWER8,
> + .icache_bsize = 128,
> + .dcache_bsize = 128,
> + .cpu_setup = __setup_cpu_power8,
> + .cpu_restore= __restore_cpu_power8,
> + .machine_check_early= __machine_check_early_realmode_p8,
> + .platform = "power8",
> + },
> { /* 3.00-compliant processor, i.e. Power9 "architected" mode */
> .pvr_mask = 0x,
> .pvr_value = 0x0f05,
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 9118242063fb..5b92619a05fd 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -604,6 +604,7 @@ static void kvmppc_set_pvr_pr(struct kvm_vcpu *vcpu, u32
> pvr)
> case PVR_POWER8:
> case PVR_POWER8E:
> case PVR_POWER8NVL:
> + case PVR_HX_C2000:
> case PVR_POWER9:
> vcpu->arch.hflags |= BOOK3S_HFLAG_MULTI_PGSIZE |
> BOOK3S_HFLAG_NEW_TLBIE;
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c
> b/arch/powerpc/mm/book3s64/pkeys.c
> index 125733962033..c38f378e1942 100644
> --- a/arch/powerpc/mm/book3s64/pkeys.c
> +++ b/arch/powerpc/mm/book3s64/pkeys.c
> @@ -89,7 +89,8 @@ static int __init scan_pkey_feature(void)
> unsigned long pvr = mfspr(SPRN_PVR);
>
> if (PVR_VER(pvr) == PVR_POWER8 || PVR_VER(pvr) ==
> PVR_POWER8E ||
> - PVR_VER(pvr) == PVR_POWER8NVL || PVR_VER(pvr) ==
> PVR_POWER9)
> + PVR_VER(pvr) == PVR_POWER8NVL || PVR_VER(pvr) ==
> PVR_POWER9 ||
> + PVR_VER(pvr) == PVR_HX_C2000)
> pkeys_total = 32;
> }
> }
> diff --git a/arch/powerpc/platforms/powernv/subcore.c
> b/arch/powerpc/platforms/powernv/subcore.c
> index 191424468f10..58e7331e1e7e 100644
> --- a/arch/powerpc/platforms/powernv/subcore.c
> +++ b/arch/powerpc/platforms/powernv/subcore.c
> @@ -425,7
Re: [RFC] UBUNTU: [Config] y2038: Disable COMPAT and COMPAT_32BIT_TIME on ppc64le
On Fri, 24 Nov 2023 at 04:59, Michael Ellerman wrote:
>
> Dimitri John Ledkov writes:
> > BugLink: https://bugs.launchpad.net/bugs/2038587
> >
> > ppc64le is exclusively little endian and 64-bit, thus there is no need
> > for COMPAT_32BIT_TIME, nor COMPAT.
>
> To be pedantic, the ppc64le kernel does support running 32-bit little
> endian userspace in compat mode (CONFIG_COMPAT=y). It's a distro choice
> as to whether you support COMPAT. Notably there are two other major
> distros that don't support COMPAT for ppc64le, and the set of 32-bit LE
> software is effectively empty.
勞
>
> > diffconfig result of these changes is:
> >
> > -ARCH_MMAP_RND_COMPAT_BITS 13
> > -ARCH_WANT_COMPAT_IPC_PARSE_VERSION y
> > -ARCH_WANT_OLD_COMPAT_IPC y
> > -COMPAT_BINFMT_ELF y
> > -COMPAT_NETLINK_MESSAGES y
> > -COMPAT_OLD_SIGACTION y
> > -HAVE_ARCH_MMAP_RND_COMPAT_BITS y
> > -KVM_COMPAT y
> > -NETFILTER_XTABLES_COMPAT y
> > -SYSVIPC_COMPAT y
> > -VDSO32 y
> > COMPAT y -> n
> > COMPAT_32BIT_TIME y -> n
> > +ARCH_HAS_SYSCALL_WRAPPER y
> > +INTERRUPT_SANITIZE_REGISTERS y
> >
> > What confused me, if the above combination is even valid or just pure
> > dead code.
>
> I don't entirely understand what that diff is saying, but I'll try and
> answer anyway.
This is output from diffconfig, lines with "y -> n" are changes to a key
that is available as a choice.
Lines prefixed with minus ('-') become unavailable.
Lines prefixed with plus ('+') are NEW options that become available.
So the effect of turning COMPAT off removes lots of compat things in other
places, and makes INTERRUPT_SANITIZE_REGISTERS available.
>
> > Is it really possible to run 32bit big-endian KVM on a 64bit
> > little-endian POWER?
>
> Are you referring to KVM_COMPAT being disabled?
>
> That's nothing to do with big-endian. It's just controlling whether the
> KVM ioctls (which qemu calls) support compat handling, ie. whether you
> can run a 32-bit qemu under a 64-bit kernel.
>
Thank you for the explanation. And also "no thank you, do not want 32-bit
qemu".
> It's entirely expected that when COMPAT is turned off KVM_COMPAT also
> gets turned off.
>
> > Or is Kconfig slightly buggy and should be fixed up to prevent
> > offering COMPAT options when little-endian 64bit POWER kernel is being
> > configured?
>
> No. Like I said at the top, the kernel does support 32-bit LE compat,
> eventhough it's not very widely used.
>
Thank you for explaining all of this.
--
okurrr,
Dimitri
Re: [PATCH] powerpc/85xx: Fix typo in code comment
On Fri, Nov 24, 2023 at 2:08 PM Christophe Leroy
wrote:
>
>
>
> Le 24/11/2023 à 11:02, Dario Binacchi a écrit :
> > s/singals/signals/
>
> Is that really worth it to spend time on such a change ?
>
> By sending such a patch, you require people to spend time reviewing your
> patch, then maintainer has to spend time handling your patch.
> Furthermore, as you added a Fixes: tag, LTS maintainers will have to
> spend time handling that too.
>
> Do you really think that this typo is worth a patch ?
>
> This kind of tiny error should be fixed through a more significant patch
> adressing this file. But it is not worth a patch on its own.
It's not the first time I've submitted patches of this kind, and no one has
ever complained before. However, if it has become an issue, I won't do
it anymore.
Thanks and regards,
Dario
>
> Christophe
>
>
> >
> > Fixes: 04e358d896a7 ("powerpc/85xx: Add Quicc Engine support for p1025rdb")
> > Signed-off-by: Dario Binacchi
> > ---
> >
> > arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > index ec9f60fbebc7..e0cec670d8db 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > @@ -76,7 +76,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
> > /* P1025 has pins muxed for QE and other functions. To
> > * enable QE UEC mode, we need to set bit QE0 for UCC1
> > * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
> > - * and QE12 for QE MII management singals in PMUXCR
> > + * and QE12 for QE MII management signals in PMUXCR
> > * register.
> > */
> > setbits32(>pmuxcr, MPC85xx_PMUXCR_QE(0)
> > |
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binac...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes
On Wed, Nov 08, 2023 at 01:58:36PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The VDSO functions are defined as globals in the kernel sources but intended
> to be called from userspace, so there is no need to declare them in a kernel
> side header.
This is in -next as commit 42874e4eb35bdfc54f8514685e50434098ba4f6c and
breaks an arm64 defconfig build, the 32 bit vDSO build is broken:
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:10:5: error: conflic
ting types for ‘__vdso_clock_gettime’; have ‘int(clockid_t, struct old_timespec
32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
10 | int __vdso_clock_gettime(clockid_t clock,
| ^~~~
In file included from /build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.
c:8:
/build/stage/linux/include/vdso/gettime.h:16:5: note: previous declaration of
‘__vdso_clock_gettime’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
16 | int __vdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts);
| ^~~~
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:28:5: error:
conflicting types for ‘__vdso_clock_getres’; have ‘int(clockid_t, struct
old_timespec32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
28 | int __vdso_clock_getres(clockid_t clock_id,
| ^~~
/build/stage/linux/include/vdso/gettime.h:15:5: note: previous declaration of
‘__vdso_clock_getres’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
15 | int __vdso_clock_getres(clockid_t clock, struct __kernel_timespec *res);
| ^~~
signature.asc
Description: PGP signature
[PATCH] powerpc/85xx: Fix typo in code comment
s/singals/signals/
Fixes: 04e358d896a7 ("powerpc/85xx: Add Quicc Engine support for p1025rdb")
Signed-off-by: Dario Binacchi
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index ec9f60fbebc7..e0cec670d8db 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -76,7 +76,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
/* P1025 has pins muxed for QE and other functions. To
* enable QE UEC mode, we need to set bit QE0 for UCC1
* in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
- * and QE12 for QE MII management singals in PMUXCR
+ * and QE12 for QE MII management signals in PMUXCR
* register.
*/
setbits32(>pmuxcr, MPC85xx_PMUXCR_QE(0) |
--
2.42.0
Re: [PATCH v2 0/4] eventfd: simplify signal helpers
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> significantly. They can be made void and not take any unnecessary
> arguments.
>
> I've added a few more simplifications based on Sean's suggestion.
>
> [...]
Applied to the vfs.misc branch of the vfs/vfs.git tree.
Patches in the vfs.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.misc
[1/4] i915: make inject_virtual_interrupt() void
https://git.kernel.org/vfs/vfs/c/858848719210
[2/4] eventfd: simplify eventfd_signal()
https://git.kernel.org/vfs/vfs/c/ded0f31f825f
[3/4] eventfd: simplify eventfd_signal_mask()
https://git.kernel.org/vfs/vfs/c/45ee1c990e88
[4/4] eventfd: make eventfd_signal{_mask}() void
https://git.kernel.org/vfs/vfs/c/37d5d473e749
Re: [PATCH v3] powerpc: Adjust config HOTPLUG_CPU dependency
On 24/11/23 8:09 am, Michael Ellerman wrote: > Hi Vishal, > > I think our wires got crossed here somewhere :) > > Vishal Chourasia writes: >> Changed HOTPLUG_CPU dependency to SMP and either ARCH_HIBERNATION_POSSIBLE or >> ARCH_SUSPEND_POSSIBLE, aligning with systems' suspend/hibernation >> capabilities. >> This update link CPU hotplugging more logically with platforms' capabilities. >> >> configs ARCH_HIBERNATION_POSSIBLE and ARCH_SUSPEND_POSSIBLE are now selected >> only if required platform dependencies are met. >> >> Reported-by: Srikar Dronamraju >> Suggested-by: Aneesh Kumar K V >> Suggested-by: Michael Ellerman >> Signed-off-by: Vishal Chourasia >> >> v2: https://lore.kernel.org/all/20231122092303.223719-1-vish...@linux.ibm.com >> v1: https://lore.kernel.org/all/20231114082046.6018-1-vish...@linux.ibm.com >> --- >> During the configuration process with 'make randconfig' followed by >> 'make olddefconfig', we observed a warning indicating an unmet direct >> dependency for the HOTPLUG_CPU option. The dependency in question relates to >> various PowerPC configurations (PPC_PSERIES, PPC_PMAC, PPC_POWERNV, >> FSL_SOC_BOOKE) which were not enabled, yet the HOTPLUG_CPU was being >> erroneously selected due to an implicit assumption by the PM_SLEEP_SMP >> option. >> This misalignment in dependencies could potentially lead to inconsistent >> kernel >> configuration states, especially when considering the necessary hardware >> support for CPU hot-plugging on PowerPC platforms. The patch aims to correct >> this by ensuring that ARCH_HIBERNATION_POSSIBLE is contingent upon the >> appropriate PowerPC configurations being active. >> >> steps to reproduce (before applying the patch): >> >> Run 'make pseries_le_defconfig' >> Run 'make menuconfig' >> Enable hibernation [ Kernel options -> Hibernation (aka 'suspend to disk') ] >> Disable [ Platform support -> IBM PowerNV (Non-Virtualized) platform support >> ] >> Disable [ Platform support -> IBM pSeries & new (POWER5-based) iSeries ] >> Enable SMP [ Processor support -> Symmetric multi-processing support ] >> Save the config >> Run 'make olddefconfig' >> >> arch/powerpc/Kconfig | 11 --- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 6f105ee4f3cf..87c8134da3da 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -166,6 +167,7 @@ config PPC >> select ARCH_STACKWALK >> select ARCH_SUPPORTS_ATOMIC_RMW >> select ARCH_SUPPORTS_DEBUG_PAGEALLOCif PPC_BOOK3S || PPC_8xx || 40x >> +select ARCH_SUSPEND_POSSIBLEif (ADB_PMU || PPC_EFIKA || >> PPC_LITE5200 || PPC_83xx || (PPC_85xx && !PPC_E500MC) || PPC_86xx || >> PPC_PSERIES || 44x || 40x) > > I know Aneesh suggested moving symbols to under PPC, but I think this is > too big and complicated to be under PPC. > >> @@ -381,13 +383,9 @@ config DEFAULT_UIMAGE >> >> config ARCH_HIBERNATION_POSSIBLE >> bool >> -default y >> config ARCH_SUSPEND_POSSIBLE >> -def_bool y >> -depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \ >> - (PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \ >> - || 44x || 40x >> +bool >> >> config ARCH_SUSPEND_NONZERO_CPU >> def_bool y >> @@ -568,8 +566,7 @@ config ARCH_USING_PATCHABLE_FUNCTION_ENTRY >> >> config HOTPLUG_CPU >> bool "Support for enabling/disabling CPUs" >> -depends on SMP && (PPC_PSERIES || \ >> -PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE) >> +depends on SMP && (ARCH_HIBERNATION_POSSIBLE || ARCH_SUSPEND_POSSIBLE) > > It's good to fix these warnings, but IMHO the result is that the > dependencies are now backward. > > HOTPLUG_CPU should retain its original dependency list. It's easier to > reason directly about "what platforms support CPU hotplug?", oh it's > pseries/powernv/powermac/85xx, because they implement cpu_disable(). > > If there's some dependency from suspend/hibernate on CPU hotplug, then > those symbols (suspend/hibernate) should depend on something to do with > CPU hotplug. > > Can you try the patch below? > > Though, going back to your original reproduction case, that kernel is > configured for Book3S 64, but with no platforms enabled, which is a > non-sensical configuration (it can't boot on any actual machines). So > possibly the real root cause is that, and we should find some way to > block creating a config that has no platforms enabled. > > cheers > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 6f105ee4f3cf..9fe656a17017 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -380,11 +380,12 @@ config DEFAULT_UIMAGE > Used to allow a board to specify it wants a uImage built by default > > config ARCH_HIBERNATION_POSSIBLE > - bool > - default y > + def_bool y > + depends on !SMP || HAVE_HOTPLUG_CPU > > config ARCH_SUSPEND_POSSIBLE > def_bool y >
Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
Hi, Christophe, Michael, Aneesh,
[I'll reply altogether here]
On Fri, Nov 24, 2023 at 07:03:11AM +, Christophe Leroy wrote:
> I added that code with commit e17eae2b8399 ("mm: pagewalk: fix walk for
> hugepage tables") because I was getting crazy displays when dumping
> /sys/kernel/debug/pagetables
>
> Huge pages can be used for many thing.
>
> On powerpc 8xx, there are 4 possible page size: 4k, 16k, 512k and 8M.
> Each PGD entry addresses 4M areas, so hugepd is used for anything using
> 8M pages. Could have used regular page tables instead, but it is not
> worth allocating a 4k table when the HW will only read first entry.
>
> At the time being, linear memory mapping is performed with 8M pages, so
> ptdump_walk_pgd() will walk into huge page directories.
>
> Also, huge pages can be used in vmalloc() and in vmap(). At the time
> being we support 512k pages there on the 8xx. 8M pages will be supported
> once vmalloc() and vmap() support hugepd, as explained in commit
> a6a8f7c4aa7e ("powerpc/8xx: add support for huge pages on VMAP and VMALLOC")
>
> So yes as a conclusion hugepd is used outside hugetlbfs, hope it
> clarifies things.
Yes it does, thanks a lot for all of your replies.
So I think this is what I missed: on Freescale ppc 8xx there's a special
hugepd_populate_kernel() defined to install kernel pgtables for hugepd.
Obviously I didn't check further than hugepd_populate() when I first
looked, and stopped at the first instance of hugepd_populate() definition
on the 64 bits ppc.
For this specific patch: I suppose the change is still all fine to reuse
the fast-gup function, because it is still true when there's a VMA present
(GUP applies only to user mappings, nothing like KASAN should ever pop up).
So AFAIU it's still true that hugepd is only used in hugetlb pages in this
case even for Freescale 8xx, and nothing should yet explode. So maybe I
can still keep the code changes.
However the comment at least definitely needs fixing (that I'm going to add
some, which hch requested and I agree), that is not yet in the patch I
posted here but I'll refine them locally.
For the whole work: the purpose of it is to start merging hugetlb pgtable
processing with generic mm. That is my take of previous lsfmm discussions
in the community on how we should move forward with hugetlb in the future,
to avoid code duplications against generic mm. Hugetlb is kind of blocked
on adding new (especially, large) features in general because of such
complexity. This is all about that, but a small step towards it.
I see that it seems a trend to make hugepd more general. Christophe's fix
on dump pgtable is exactly what I would also look for if keep going. I
hope that's the right way to go.
I'll also need to think more on how this will affect my plan, currently it
seems all fine: I won't ever try to change any kernel mapping specific
code. I suppose any hugetlbfs based test should still cover all codes I
will touch on hugepd. Then it should just work for kernel mappings on
Freescales; it'll be great if e.g. Christophe can help me double check that
if the series can stablize in a few versions. If any of you have any hint
on testing it'll be more than welcomed, either specific test case or hints;
currently I'm still at a phase looking for a valid ppc systems - QEMU tcg
ppc64 emulation on x86 is slow enough to let me give up already.
Considering hugepd's specialty in ppc and the possibility that I'll break
it, there's yet another option which is I only apply the new logic into
archs with !ARCH_HAS_HUGEPD. It'll make my life easier, but that also
means even if my attempt would work out anything new will by default rule
ppc out. And we'll have a bunch of "#ifdef ARCH_HAS_HUGEPD" in generic
code, which is not preferred either. For gup, it might be relatively easy
when comparing to the rest. I'm still hesitating for the long term plan.
Please let me know if you have any thoughts on any of above.
Thanks!
--
Peter Xu
Re: [PATCH v5 4/5] tty: Add SBI debug console support to HVC SBI driver
On Fri, Nov 24, 2023 at 12:39:04PM +0530, Anup Patel wrote:
> From: Atish Patra
>
> RISC-V SBI specification supports advanced debug console
> support via SBI DBCN extension.
>
> Extend the HVC SBI driver to support it.
>
> Signed-off-by: Atish Patra
> Signed-off-by: Anup Patel
> ---
> drivers/tty/hvc/Kconfig | 2 +-
> drivers/tty/hvc/hvc_riscv_sbi.c | 37 ++---
> 2 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> index 4f9264d005c0..6e05c5c7bca1 100644
> --- a/drivers/tty/hvc/Kconfig
> +++ b/drivers/tty/hvc/Kconfig
> @@ -108,7 +108,7 @@ config HVC_DCC_SERIALIZE_SMP
>
> config HVC_RISCV_SBI
> bool "RISC-V SBI console support"
> - depends on RISCV_SBI_V01
> + depends on RISCV_SBI
> select HVC_DRIVER
> help
> This enables support for console output via RISC-V SBI calls, which
> diff --git a/drivers/tty/hvc/hvc_riscv_sbi.c b/drivers/tty/hvc/hvc_riscv_sbi.c
> index 31f53fa77e4a..2f3571f17ecd 100644
> --- a/drivers/tty/hvc/hvc_riscv_sbi.c
> +++ b/drivers/tty/hvc/hvc_riscv_sbi.c
> @@ -39,21 +39,44 @@ static int hvc_sbi_tty_get(uint32_t vtermno, char *buf,
> int count)
> return i;
> }
>
> -static const struct hv_ops hvc_sbi_ops = {
> +static const struct hv_ops hvc_sbi_v01_ops = {
> .get_chars = hvc_sbi_tty_get,
> .put_chars = hvc_sbi_tty_put,
> };
>
> -static int __init hvc_sbi_init(void)
> +static int hvc_sbi_dbcn_tty_put(uint32_t vtermno, const char *buf, int count)
> {
> - return PTR_ERR_OR_ZERO(hvc_alloc(0, 0, _sbi_ops, 16));
> + return sbi_debug_console_write(buf, count);
> }
> -device_initcall(hvc_sbi_init);
>
> -static int __init hvc_sbi_console_init(void)
> +static int hvc_sbi_dbcn_tty_get(uint32_t vtermno, char *buf, int count)
> {
> - hvc_instantiate(0, 0, _sbi_ops);
> + return sbi_debug_console_read(buf, count);
> +}
> +
> +static const struct hv_ops hvc_sbi_dbcn_ops = {
> + .put_chars = hvc_sbi_dbcn_tty_put,
> + .get_chars = hvc_sbi_dbcn_tty_get,
> +};
> +
> +static int __init hvc_sbi_init(void)
> +{
> + int err;
> +
> + if (sbi_debug_console_available) {
> + err = PTR_ERR_OR_ZERO(hvc_alloc(0, 0, _sbi_dbcn_ops, 256));
> + if (err)
> + return err;
> + hvc_instantiate(0, 0, _sbi_dbcn_ops);
> + } else if (IS_ENABLED(CONFIG_RISCV_SBI_V01)) {
> + err = PTR_ERR_OR_ZERO(hvc_alloc(0, 0, _sbi_v01_ops, 256));
> + if (err)
> + return err;
> + hvc_instantiate(0, 0, _sbi_v01_ops);
> + } else {
> + return -ENODEV;
> + }
>
> return 0;
> }
> -console_initcall(hvc_sbi_console_init);
> +device_initcall(hvc_sbi_init);
> --
> 2.34.1
>
Reviewed-by: Andrew Jones
Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
On Fri, Nov 24, 2023 at 09:06:01AM +, Ryan Roberts wrote: > I don't have any micro-benchmarks for GUP though, if that's your question. Is > there an easy-to-use test I can run to get some numbers? I'd be happy to try > it out. Thanks Ryan. Then nothing is needed to be tested if gup is not yet touched from your side, afaict. I'll see whether I can provide some rough numbers instead in the next post (I'll probably only be able to test it in a VM, though, but hopefully that should still reflect mostly the truth). -- Peter Xu
Re: Please backport feea65a338e5 ("powerpc/powernv: Fix fortify source warnings in opal-prd.c")
On Mon, Nov 20, 2023 at 10:20:13AM +1100, Michael Ellerman wrote:
> Hi,
>
> Please backport feea65a338e5 ("powerpc/powernv: Fix fortify source
> warnings in opal-prd.c") to the 6.5, 6.1, 5.15, 5.10 stable trees.
Now queued up, thanks.
greg k-h
Re: [PATCH] powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
Le 22/11/2023 à 10:00, Kunwu Chan a écrit :
> [Vous ne recevez pas souvent de courriers de chen...@kylinos.cn. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
Are you sure this is needed ? Did you check what happens what name is NULL ?
If I followed stuff correctly, I end up in function
sysfs_do_create_link_sd() which already handles the NULL name case which
a big hammer warning.
>
> Signed-off-by: Kunwu Chan
> ---
> arch/powerpc/mm/init-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
> index 119ef491f797..0884fc601c46 100644
> --- a/arch/powerpc/mm/init-common.c
> +++ b/arch/powerpc/mm/init-common.c
> @@ -139,6 +139,8 @@ void pgtable_cache_add(unsigned int shift)
>
> align = max_t(unsigned long, align, minalign);
> name = kasprintf(GFP_KERNEL, "pgtable-2^%d", shift);
> + if (!name)
> + return;
> new = kmem_cache_create(name, table_size, align, 0, ctor(shift));
> if (!new)
> panic("Could not allocate pgtable cache for order %d",
> shift);
> --
> 2.34.1
>
Re: [PATCH 0/8] devm_led_classdev_register() usage problem
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_set_brightness() to turn off the led.
> led_set_brightness() may call one of the module's brightness_set callbacks.
> If that callback uses module's resources allocated without using devm funcs()
> then those resources will be already freed at module's remove() callback and
> we may have use-after-free situation.
>
> Here is an example:
>
> module_probe()
> {
> devm_led_classdev_register(module_brightness_set_cb);
> mutex_init();
> }
>
> module_brightness_set_cb()
> {
> mutex_lock();
> do_set_brightness();
> mutex_unlock();
> }
>
> module_remove()
> {
> mutex_destroy();
> }
>
> at rmmod:
> module_remove()
> ->mutex_destroy();
> devres_release_all()
> ->led_classdev_unregister();
> ->led_set_brightness();
> ->module_brightness_set_cb();
> ->mutex_lock(); /* use-after-free */
>
> I think it's an architectural issue and should be discussed thoroughly.
> Some thoughts about fixing it as a start:
> 1) drivers can use devm_led_classdev_unregister() to explicitly free leds
> before
> dependend resources are freed. devm_led_classdev_register() remains being
> useful
> to simplify probe implementation.
> As a proof of concept I examined all drivers from drivers/leds and prepared
> patches where it's needed. Sometimes it was not as clean as just calling
> devm_led_classdev_unregister() because several drivers do not track
> their leds object at all - they can call devm_led_classdev_register() and
> drop the
> returned pointer. In that case I used devres group API.
>
> Drivers outside drivers/leds should be checked too after discussion.
>
> 2) remove led_set_brightness from led_classdev_unregister() and force the
> drivers
> to turn leds off at shutdown. May be add check that led's brightness is 0
> at led_classdev_unregister() and put a warning to dmesg if it's not.
> Actually in many cases it doesn't really need to turn off the leds manually
> one-by-one
> if driver shutdowns whole led controller. For the last case to disable the
> warning
> new flag can be brought in e.g LED_AUTO_OFF_AT_SHUTDOWN (similar to
> LED_RETAIN_AT_SHUTDOWN).
NAK.
Just fix the drivers by wrapping mutex_destroy() into devm, There are many
doing so. You may be brave enough to introduce devm_mutex_init() somewhere
in include/linux/device*
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/8] devm_led_classdev_register() usage problem
On Sat, Nov 4, 2023 at 9:17 AM George Stark wrote: > > Hello Andy > > Could you please take a look at this patch series? > > I've just found your post on habr about devres API misusing and I think > this is just another case. Just had a look, sorry for the delay. By quickly reading it seems to be a wrong approach (or wrong end to start solving the issue from). -- With Best Regards, Andy Shevchenko
[powerpc:merge] BUILD SUCCESS 9a15ae60f2c9707433b01e55815cd9142be102b2
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 9a15ae60f2c9707433b01e55815cd9142be102b2 Automatic merge of 'master' into merge (2023-11-22 00:21) elapsed time: 4375m configs tested: 239 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alpha defconfig gcc arc allnoconfig gcc arc axs101_defconfig gcc arc defconfig gcc arc randconfig-001-20231122 gcc arc randconfig-001-20231123 gcc arc randconfig-002-20231122 gcc arc randconfig-002-20231123 gcc arm allmodconfig gcc arm allnoconfig gcc armclps711x_defconfig gcc arm defconfig clang arm lpc18xx_defconfig gcc armmps2_defconfig gcc armmulti_v5_defconfig clang armmulti_v7_defconfig gcc armmvebu_v7_defconfig gcc arm nhk8815_defconfig gcc arm randconfig-001-20231123 gcc arm randconfig-002-20231123 gcc arm randconfig-003-20231123 gcc arm randconfig-004-20231123 gcc arm rpc_defconfig gcc arm sama5_defconfig gcc arm sunxi_defconfig gcc armvexpress_defconfig clang arm64allmodconfig clang arm64 allnoconfig gcc arm64allyesconfig clang arm64 defconfig gcc arm64 randconfig-001-20231123 gcc arm64 randconfig-002-20231123 gcc arm64 randconfig-003-20231123 gcc arm64 randconfig-004-20231123 gcc csky allnoconfig gcc cskydefconfig gcc csky randconfig-001-20231122 gcc csky randconfig-001-20231123 gcc csky randconfig-002-20231122 gcc csky randconfig-002-20231123 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386defconfig gcc i386 randconfig-011-20231122 gcc i386 randconfig-011-20231123 clang i386 randconfig-012-20231122 gcc i386 randconfig-012-20231123 clang i386 randconfig-013-20231122 gcc i386 randconfig-013-20231123 clang i386 randconfig-014-20231122 gcc i386 randconfig-014-20231123 clang i386 randconfig-015-20231122 gcc i386 randconfig-015-20231123 clang i386 randconfig-016-20231122 gcc i386 randconfig-016-20231123 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch loongson3_defconfig gcc loongarch randconfig-001-20231122 gcc loongarch randconfig-001-20231123 gcc loongarch randconfig-002-20231122 gcc loongarch randconfig-002-20231123 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68k apollo_defconfig gcc m68k bvme6000_defconfig gcc m68kdefconfig gcc m68k m5208evb_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allyesconfig gcc mipsbcm47xx_defconfig gcc mips bigsur_defconfig gcc mips
Re: [RFC] UBUNTU: [Config] y2038: Disable COMPAT and COMPAT_32BIT_TIME on ppc64le
On Fri, 24 Nov 2023 at 08:25, Michal Suchánek wrote: > > On Fri, Nov 24, 2023 at 03:59:04PM +1100, Michael Ellerman wrote: > > Dimitri John Ledkov writes: > > > BugLink: https://bugs.launchpad.net/bugs/2038587 > > > > > > ppc64le is exclusively little endian and 64-bit, thus there is no need > > > for COMPAT_32BIT_TIME, nor COMPAT. > > > > To be pedantic, the ppc64le kernel does support running 32-bit little > > endian userspace in compat mode (CONFIG_COMPAT=y). It's a distro choice > > as to whether you support COMPAT. Notably there are two other major > > distros that don't support COMPAT for ppc64le, and the set of 32-bit LE > > software is effectively empty. > > I have seen software that does not work when compiled 64bit so it would > build 32bit binary even on ppc64le and abuse the compat layer to run. > > It quite rare, though. Thank you! And yes, do not want =) -- okurrr, Dimitri
Re: [PATCH] powerpc/85xx: Fix typo in code comment
Le 24/11/2023 à 11:02, Dario Binacchi a écrit :
> s/singals/signals/
Is that really worth it to spend time on such a change ?
By sending such a patch, you require people to spend time reviewing your
patch, then maintainer has to spend time handling your patch.
Furthermore, as you added a Fixes: tag, LTS maintainers will have to
spend time handling that too.
Do you really think that this typo is worth a patch ?
This kind of tiny error should be fixed through a more significant patch
adressing this file. But it is not worth a patch on its own.
Christophe
>
> Fixes: 04e358d896a7 ("powerpc/85xx: Add Quicc Engine support for p1025rdb")
> Signed-off-by: Dario Binacchi
> ---
>
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index ec9f60fbebc7..e0cec670d8db 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -76,7 +76,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
> /* P1025 has pins muxed for QE and other functions. To
> * enable QE UEC mode, we need to set bit QE0 for UCC1
> * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
> - * and QE12 for QE MII management singals in PMUXCR
> + * and QE12 for QE MII management signals in PMUXCR
> * register.
> */
> setbits32(>pmuxcr, MPC85xx_PMUXCR_QE(0) |
Re: [PATCH] powerpc/lib: Avoid array bounds warnings in vec ops
On Thu, Nov 23, 2023 at 09:17:54AM -0600, Gustavo A. R. Silva wrote: > > > > To be honest I don't know how paranoid we want to get, we could end up > > > putting WARN's all over the kernel :) > > > > > > In this case I guess if the size is too large we overflow the buffer on > > > the kernel stack, so we should at least check the size. > > > > > > But does it need a WARN? I'm not sure. If we had a case that was passing > > > a out-of-bound size hopefully we would notice in testing? :) > > > > You're right, a simpler check should suffice. I will send an updated > > patch. > > This[1] patch indeed also makes those -Wstringop-overflow warnings go away. :) > > I'm not subscribed to the list but here are my > > Reviewed-by: Gustavo A. R. Silva > Build-tested-by: Gustavo A. R. Silva Thanks for testing. I intended my patch to go atop Michael's patch since do_fp_load()/do_fp_store() also clamp down the size passed to do_byte_reverse(). While the use of min() isn't strictly necessary with the added check for 'size' at the beginning of the function, it doesn't hurt to have it and Michael's patch does have a better description for the change :) - Naveen
[PATCH v2 03/10] i2c: pasemi: Don't let i2c adapters declare I2C_CLASS_SPD support if they support I2C_CLASS_HWMON
After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Series was created supported by Coccinelle and its splitpatch. Signed-off-by: Heiner Kallweit --- drivers/i2c/busses/i2c-pasemi-pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pasemi-pci.c b/drivers/i2c/busses/i2c-pasemi-pci.c index cfc89e04e..77f90c743 100644 --- a/drivers/i2c/busses/i2c-pasemi-pci.c +++ b/drivers/i2c/busses/i2c-pasemi-pci.c @@ -56,7 +56,7 @@ static int pasemi_smb_pci_probe(struct pci_dev *dev, if (!smbus->ioaddr) return -EBUSY; - smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD; + smbus->adapter.class = I2C_CLASS_HWMON; error = pasemi_i2c_common_probe(smbus); if (error) return error;
[PATCH v2 00/10] Don't let i2c adapters declare I2C_CLASS_SPD support if they support I2C_CLASS_HWMON
After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Series was created supported by Coccinelle and its splitpatch. v2: - fix style issue in patch 4 - add ack in patch 2 - set proper subject prefix for all patches Signed-off-by: Heiner Kallweit --- drivers/i2c/busses/i2c-ali1535.c |2 +- drivers/i2c/busses/i2c-ali1563.c |2 +- drivers/i2c/busses/i2c-ali15x3.c |2 +- drivers/i2c/busses/i2c-amd756.c |2 +- drivers/i2c/busses/i2c-amd8111.c |2 +- drivers/i2c/busses/i2c-elektor.c |2 +- drivers/i2c/busses/i2c-gpio.c |2 +- drivers/i2c/busses/i2c-ibm_iic.c |2 +- drivers/i2c/busses/i2c-iop3xx.c |2 +- drivers/i2c/busses/i2c-isch.c |2 +- drivers/i2c/busses/i2c-kempld.c |3 +-- drivers/i2c/busses/i2c-mlxcpld.c |2 +- drivers/i2c/busses/i2c-nforce2.c |2 +- drivers/i2c/busses/i2c-pasemi-pci.c |2 +- drivers/i2c/busses/i2c-piix4.c|2 +- drivers/i2c/busses/i2c-scmi.c |2 +- drivers/i2c/busses/i2c-sh7760.c |2 +- drivers/i2c/busses/i2c-sibyte.c |4 ++-- drivers/i2c/busses/i2c-sis5595.c |2 +- drivers/i2c/busses/i2c-sis630.c |2 +- drivers/i2c/busses/i2c-sis96x.c |2 +- drivers/i2c/busses/i2c-via.c |2 +- drivers/i2c/busses/i2c-viapro.c |2 +- drivers/i2c/busses/scx200_acb.c |2 +- drivers/i2c/i2c-stub.c|2 +- drivers/media/pci/netup_unidvb/netup_unidvb_i2c.c |2 +- drivers/staging/greybus/i2c.c |2 +- 27 files changed, 28 insertions(+), 29 deletions(-)
[PATCH 2/6] powerpc/fsl-pci: Use PCI_HEADER_TYPE_MASK instead of literal
Replace 0x7f literals with PCI_HEADER_TYPE_MASK.
Signed-off-by: Ilpo Järvinen
---
arch/powerpc/sysdev/fsl_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 3868483fbe29..ef7707ea0db7 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -54,7 +54,7 @@ static void quirk_fsl_pcie_early(struct pci_dev *dev)
/* if we aren't in host mode don't bother */
pci_read_config_byte(dev, PCI_HEADER_TYPE, _type);
- if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ if ((hdr_type & PCI_HEADER_TYPE_MASK) != PCI_HEADER_TYPE_BRIDGE)
return;
dev->class = PCI_CLASS_BRIDGE_PCI_NORMAL;
@@ -581,7 +581,7 @@ static int fsl_add_bridge(struct platform_device *pdev, int
is_primary)
hose->ops = _indirect_pcie_ops;
/* For PCIE read HEADER_TYPE to identify controller mode */
early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, _type);
- if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ if ((hdr_type & PCI_HEADER_TYPE_MASK) != PCI_HEADER_TYPE_BRIDGE)
goto no_bridge;
} else {
--
2.30.2
Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
On 23/11/2023 19:46, Peter Xu wrote: > On Thu, Nov 23, 2023 at 07:11:19PM +, Ryan Roberts wrote: >> Hi, >> >> I'm not sure I've 100% understood the crossover between this series and my >> work >> to support arm64's contpte mappings generally for anonymous and file-backed >> memory. > > No worry, there's no confliction. If you worked on that it's only be > something nice on top. Also, I'm curious if you have performance numbers, I have perf numbers for high level use cases (kernel compilation and Speedometer Java Script benchmarks) at https://lore.kernel.org/linux-arm-kernel/20230622144210.2623299-1-ryan.robe...@arm.com/ I don't have any micro-benchmarks for GUP though, if that's your question. Is there an easy-to-use test I can run to get some numbers? I'd be happy to try it out. > because I'm going to do some test for hugetlb cont_ptes (which is only the > current plan), and if you got those it'll be a great baseline for me, > because it should be similar in you case even though the goal is slightly > different. > >> >> My approach is to transparently use contpte mappings when core-mm request pte >> mappings that meet the requirements; and its all based around intercepting >> the >> normal (non-hugetlb) helpers (e.g. set_ptes(), ptep_get() and friends). >> There is >> no semantic change to the core-mm. See [1]. It relies on 1) the page cache >> using >> large folios and 2) my "small-sized THP" series which starts using arbitrary >> sized large folios for anonymous memory [2]. >> >> If I've understood this conversation correctly there is an object called >> hugepd, >> which today is only supported by powerpc, but which could allow the core-mm >> to >> control the mapping granularity? I can see some value in exposing that >> control >> to core-mm in the (very) long term. > > For me it's needed immediately, because hugetlb_follow_page_mask() will be > gone after the last patch. > >> >> [1] >> https://lore.kernel.org/all/20231115163018.1303287-1-ryan.robe...@arm.com/ >> [2] >> https://lore.kernel.org/linux-mm/20231115132734.931023-1-ryan.robe...@arm.com/ > > AFAICT you haven't yet worked on gup then, after I glimpsed the above > series. No, I haven't touched GUP at all. The approach is fully inside the arm64 arch code (except 1 patch to core-mm which enables an optimization). So as far as GUP and the rest of the core-mm is concerned, there are still only page-sized ptes and they can all be iterated over and accessed as normal. > > It's a matter of whether one follow_page_mask() call can fetch more than > one page* for a cont_pte entry on aarch64 for a large non-hugetlb folio > (and if this series lands, it'll be the same to hugetlb or non-hugetlb). > Now the current code can only fetch one page I think. > > Thanks, >
Re: [powerpc] Lockups seen during/just after boot (bisected)
> On 24-Nov-2023, at 2:25 PM, Vlastimil Babka wrote: > > On 11/23/23 15:35, Chengming Zhou wrote: >> On 2023/11/23 19:27, Sachin Sant wrote: >>> While booting recent -next kernel on IBM Power server, I have observed >>> lockups >>> either during boot or just after. >>> >>> [ 3631.015775] watchdog: CPU 3 self-detected hard LOCKUP @ >>> __update_freelist_slow+0x74/0x90 >> >> Sorry, the bug can be fixed by this patch from Vlastimil Babka: >> >> https://lore.kernel.org/all/83ff4b9e-94f1-8b35-1233-3dd414ea4...@suse.cz/ > > The current -next should be fixed, the fix was folded to the preparatory > commit, which is now: > Thanks. Yes the problem is fixed with today’s next. - Sachin
Re: [powerpc] Lockups seen during/just after boot (bisected)
On 11/23/23 15:35, Chengming Zhou wrote:
> On 2023/11/23 19:27, Sachin Sant wrote:
>> While booting recent -next kernel on IBM Power server, I have observed
>> lockups
>> either during boot or just after.
>>
>> [ 3631.015775] watchdog: CPU 3 self-detected hard LOCKUP @
>> __update_freelist_slow+0x74/0x90
>
> Sorry, the bug can be fixed by this patch from Vlastimil Babka:
>
> https://lore.kernel.org/all/83ff4b9e-94f1-8b35-1233-3dd414ea4...@suse.cz/
The current -next should be fixed, the fix was folded to the preparatory
commit, which is now:
8a399e2f6003 ("slub: Keep track of whether slub is on the per-node partial
list")
> Thanks!
Re: [PATCH v1] powerpc: Add PVN support for HeXin C2000 processor
Hi Michael and Greg, On 2023/11/23 19:02, Michael Ellerman wrote: Greg KH writes: On Thu, Nov 23, 2023 at 05:36:11PM +0800, Zhao Ke wrote: HeXin Tech Co. has applied for a new PVN from the OpenPower Community for its new processor C2000. The OpenPower has assigned a new PVN and this newly assigned PVN is 0x0066, add pvr register related support for this PVN. Signed-off-by: Zhao Ke Link: https://discuss.openpower.foundation/t/how-to-get-a-new-pvr-for-processors-follow-power-isa/477/10 --- v0 -> v1: - Fix .cpu_name with the correct description --- --- arch/powerpc/include/asm/reg.h| 1 + arch/powerpc/kernel/cpu_specs_book3s_64.h | 15 +++ arch/powerpc/kvm/book3s_pr.c | 1 + arch/powerpc/mm/book3s64/pkeys.c | 3 ++- arch/powerpc/platforms/powernv/subcore.c | 3 ++- drivers/misc/cxl/cxl.h| 3 ++- 6 files changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 4ae4ab9090a2..7fd09f25452d 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1361,6 +1361,7 @@ #define PVR_POWER8E 0x004B #define PVR_POWER8NVL 0x004C #define PVR_POWER80x004D +#define PVR_HX_C2000 0x0066 #define PVR_POWER90x004E #define PVR_POWER10 0x0080 #define PVR_BE0x0070 Why is this not in sorted order? It's semantically sorted :D ie. HX_C2000 is most similar to POWER8, but is newer than it. Yes. This is what I mean. If you prefer to sort in another order, please tell me and I will update this. PVR_BE is out of place, I'll fix that. cheers
Re: [PATCH v2 2/7] kexec_file: print out debugging message if required
On 11/23/23 at 11:16pm, Joe Perches wrote:
> On Fri, 2023-11-24 at 11:36 +0800, Baoquan He wrote:
> > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
>
> trivia for pr_debug -> kexec_dprintk conversions for
> the entire patch set:
OK, will check all patchset and adjust the indendation, thanks.
>
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> []
> > @@ -551,9 +551,12 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,
> > int need_kernel_map,
> > phdr->p_filesz = phdr->p_memsz = mend - mstart + 1;
> > phdr->p_align = 0;
> > ehdr->e_phnum++;
> > - pr_debug("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx,
> > paddr=0x%llx, sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
> > +#ifdef CONFIG_KEXEC_FILE
> > + kexec_dprintk("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx,
> > paddr=0x%llx, "
> > + "sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
> > phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
> > ehdr->e_phnum, phdr->p_offset);
>
> It's good form to rewrap continuation lines to the open parenthesis
>
> > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> []
> > @@ -389,11 +391,12 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int,
> > initrd_fd,
> > if (ret)
> > goto out;
> >
> > + kexec_dprintk("nr_segments = %lu\n", image->nr_segments);
> > for (i = 0; i < image->nr_segments; i++) {
> > struct kexec_segment *ksegment;
> >
> > ksegment = >segment[i];
> > - pr_debug("Loading segment %d: buf=0x%p bufsz=0x%zx mem=0x%lx
> > memsz=0x%zx\n",
> > + kexec_dprintk("segment[%d]: buf=0x%p bufsz=0x%zx mem=0x%lx
> > memsz=0x%zx\n",
> > i, ksegment->buf, ksegment->bufsz, ksegment->mem,
> > ksegment->memsz);
>
> here too etc...
>
Re: [RFC] UBUNTU: [Config] y2038: Disable COMPAT and COMPAT_32BIT_TIME on ppc64le
On Fri, Nov 24, 2023 at 03:59:04PM +1100, Michael Ellerman wrote: > Dimitri John Ledkov writes: > > BugLink: https://bugs.launchpad.net/bugs/2038587 > > > > ppc64le is exclusively little endian and 64-bit, thus there is no need > > for COMPAT_32BIT_TIME, nor COMPAT. > > To be pedantic, the ppc64le kernel does support running 32-bit little > endian userspace in compat mode (CONFIG_COMPAT=y). It's a distro choice > as to whether you support COMPAT. Notably there are two other major > distros that don't support COMPAT for ppc64le, and the set of 32-bit LE > software is effectively empty. I have seen software that does not work when compiled 64bit so it would build 32bit binary even on ppc64le and abuse the compat layer to run. It quite rare, though. Thanks Michal
