- 04 May, 2022 22 commits
-
-
Jiapeng Chong authored
Clean the following coccicheck warning: ./arch/powerpc/kernel/fadump.c:1291:34-35: WARNING opportunity for swap(). Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220129034847.76902-1-jiapeng.chong@linux.alibaba.com
-
Minghao Chi authored
Return the value from i2c_add_driver() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
CGEL ZTE <cgel.zte@gmail.com> Signed-off-by:
-
Xiang wangx authored
Static variables do not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Signed-off-by:
Xiang wangx <wangxiang@cdjrlc.com> Signed-off-by:
-
Yang Guang authored
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Reported-by:
Yang Guang <yang.guang5@zte.com.cn> Signed-off-by:
-
Randy Dunlap authored
Fix typos of 'remaining' and 'those'. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by: Matthew Wilcox <willy@infradead.org> # 'remaining' Signed-off-by:
-
Qing Wang authored
show() must not use snprintf() when formatting the value to be returned to user space. Fix the following coccicheck warning: drivers/macintosh/ams/ams-core.c:53: WARNING: use scnprintf or sprintf. Use sysfs_emit instead of scnprintf or sprintf makes more sense. Signed-off-by:
Qing Wang <wangqing@vivo.com> Signed-off-by:
-
Sohaib Mohamed authored
Remove repeated words: "the the lowest" and "this this kernel" Signed-off-by:
Sohaib Mohamed <sohaib.amhmd@gmail.com> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Jing Yangyang authored
Fix the following coccicheck warning: ./drivers/macintosh/smu.c:1089: 11-12: WARNING comparing pointer to 0, suggest !E ./drivers/macintosh/smu.c:1256:11-12: WARNING comparing pointer to 0 Reported-by:
Jing Yangyang <jing.yangyang@zte.com.cn> Signed-off-by:
-
Jason Wang authored
The strlcpy should not be used because it doesn't limit the source length. As linus says, it's a completely useless function if you can't implicitly trust the source string - but that is almost always why people think they should use it! All in all the BSD function will lead some potential bugs. But the strscpy doesn't require reading memory from the src string beyond the specified "count" bytes, and since the return value is easier to error-check than strlcpy()'s. In addition, the implementation is robust to the string changing out from underneath it, unlike the current strlcpy() implementation. Thus, We prefer using strscpy instead of strlcpy. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Jason Wang authored
Replace the 'unsigned' with 'unsigned int' which is more accurate. Signed-off-by:
-
Dwaipayan Ray authored
__FUNCTION__ exists only for backwards compatibility reasons with old gcc versions. Replace it with __func__. Signed-off-by:
Dwaipayan Ray <dwaipayanray1@gmail.com> Signed-off-by:
-
Dwaipayan Ray authored
__FUNCTION__ exists only for backwards compatibility reasons with old gcc versions. Replace it with __func__. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in the Kconfig text. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Chen Huang authored
The simple_strtoull() function is deprecated in some situation, since it does not check for the range overflow, use kstrtoull() instead. Signed-off-by:
Chen Huang <chenhuang5@huawei.com> Signed-off-by:
-
Randy Dunlap authored
Fix some pr_debug() issues in mpc52xx_pci.c: - use __func__ to print function names - use "%pr" to print struct resource entries - use "%pa" to print a resource_size_t (phys_addr_t) The latter two fix several build warnings: ../arch/powerpc/platforms/52xx/mpc52xx_pci.c: In function 'mpc52xx_pci_setup': ../include/linux/kern_levels.h:5:18: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t' {aka 'long long unsigned int'} [-Wformat=] ../arch/powerpc/platforms/52xx/mpc52xx_pci.c:277:40: note: format string is defined here 277 | pr_debug("mem_resource[1] = {.start=%x, .end=%x, .flags=%lx}\n", | ~^ | | | unsigned int | %llx ../include/linux/kern_levels.h:5:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'resource_size_t' {aka 'long long unsigned int'} [-Wformat=] ../arch/powerpc/platforms/52xx/mpc52xx_pci.c:277:49: note: format string is defined here 277 | pr_debug("mem_resource[1] = {.start=%x, .end=%x, .flags=%lx}\n", | ~^ | | | unsigned int | %llx ../arch/powerpc/platforms/52xx/mpc52xx_pci.c:299:36: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 299 | (unsigned long long)res->flags, (void*)hose->io_base_phys); | ^ ../arch/powerpc/platforms/52xx/mpc52xx_pci.c:295:2: note: in expansion of macro 'pr_debug' 295 | pr_debug(".io_resource={.start=%llx,.end=%llx,.flags=%llx} " | ^~~~~~~~ The change to print mem_resource[0] is for consistency within this source file and to use the kernel API -- there were no warnings here. Signed-off-by: -
Ye Bin authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Zucheng Zheng authored
sccdbg symbol is not used, so remove it Reported-by:
Zucheng Zheng <zhengzucheng@huawei.com> Signed-off-by:
-
Yu Kuai authored
The sparse tool complains as follow: arch/powerpc/kernel/btext.c:48:5: warning: symbol 'boot_text_mapped' was not declared. Should it be static? This symbol is not used outside of btext.c, so this commit make it static. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Signed-off-by:
-
Yu Kuai authored
Fixes gcc '-Wunused-but-set-variable' warning: arch/powerpc/kernel/btext.c:49:12: error: 'force_printk_to_btext' defined but not used. It is never used, and so can be removed. Signed-off-by:
-
zuoqilin authored
Remove unneeded variable: "ret". Signed-off-by:
zuoqilin <zuoqilin@yulong.com> Signed-off-by:
-
YueHaibing authored
commit 475028ef ("powerpc/eeh: Remove eeh_dev_phb_init_dynamic()") left behind this, so can remove it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
He Ying authored
We found these warnings in arch/powerpc/kernel/time.c as follows: warning: symbol 'decrementer_max' was not declared. Should it be static? warning: symbol 'rtc_lock' was not declared. Should it be static? warning: symbol 'dtl_consumer' was not declared. Should it be static? Declare 'decrementer_max' in powerpc asm/time.h. Include linux/mc146818rtc.h in powerpc kernel/time.c where 'rtc_lock' is declared. And remove duplicated declaration of 'rtc_lock' in powerpc platforms/chrp/time.c because it has included linux/mc146818rtc.h. Move 'dtl_consumer' definition after "include <asm/dtl.h>" because it is declared there. Reported-by:
He Ying <heying24@huawei.com> Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
- 02 May, 2022 5 commits
-
-
Yang Li authored
Fix the following coccinelle warnings: ./arch/powerpc/lib/sstep.c:1090:20-21: WARNING: sum of probable bitmasks, consider | ./arch/powerpc/lib/sstep.c:1115:20-21: WARNING: sum of probable bitmasks, consider | ./arch/powerpc/lib/sstep.c:1134:20-21: WARNING: sum of probable bitmasks, consider | Reported-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Randy Dunlap authored
Fix missing export for a loadable module build: ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined! Fixes: 1da177e4 ("Linux-2.6.12-rc") Signed-off-by:
kernel test robot <lkp@intel.com> [chleroy: Changed Fixes: tag] Signed-off-by:
-
Wang Wensheng authored
Build kernel with `C=2`: arch/powerpc/perf/isa207-common.c:24:18: warning: symbol 'isa207_pmu_format_attr' was not declared. Should it be static? arch/powerpc/perf/power9-pmu.c:101:5: warning: symbol 'p9_dd21_bl_ev' was not declared. Should it be static? arch/powerpc/perf/power9-pmu.c:115:5: warning: symbol 'p9_dd22_bl_ev' was not declared. Should it be static? Those symbols are used only in the files that define them so we declare them as static to fix the warnings. Signed-off-by:
Wang Wensheng <wangwensheng4@huawei.com> Reviewed-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by:
-
Xu Wang authored
Remove unnecassary cast in the argument to kfree(). Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Fuqian Huang authored
kmemdup is introduced to duplicate a region of memory in a neat way. Rather than kmalloc/kzalloc + memcpy, which the programmer needs to write the size twice (sometimes lead to mistakes), kmemdup improves readability, leads to smaller code and also reduce the chances of mistakes. Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. Signed-off-by:
Fuqian Huang <huangfq.daxian@gmail.com> [chleroy: Fixed parenthesis alignment] Signed-off-by:
-
- 29 Apr, 2022 1 commit
-
-
Michael Ellerman authored
Add a test for a bug we had in the 4PB address space SLB handling. It was fixed in commit 4c2de74c ("powerpc/64: Interrupts save PPR on stack rather than thread_struct"). Signed-off-by:
-
- 27 Apr, 2022 3 commits
-
-
Michael Ellerman authored
In smp_85xx_start_cpu() we are passed an address but we're unsure if it's a real or virtual address, so there's a check to determine that. The check has an off-by-one in that it tests if the address is greater than high_memory, but high_memory is the first address of high memory, so the check should be greater-or-equal. It seems this has never been a problem in practice, but it also triggers the DEBUG_VIRTUAL checks in __pa() which we would like to avoid. We can fix both issues by converting high_memory - 1 to a physical address and testing against that. Signed-off-by:
-
Alistair Popple authored
Adds a simple test of some basic matrix multiply assist (MMA) instructions. Signed-off-by:
Alistair Popple <alistair@popple.id.au> Tested-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Joel Stanley authored
Currently the boot wrapper lacks a -mcpu option, so it will be built for the toolchain's default cpu. This is a problem if the toolchain defaults to a cpu with newer instructions. We could wire in TARGET_CPU but instead use the oldest supported option so the wrapper runs anywhere. The GCC documentation stays that -mcpu=powerpc64le will give us a generic 64 bit powerpc machine: -mcpu=powerpc, -mcpu=powerpc64, and -mcpu=powerpc64le specify pure 32-bit PowerPC (either endian), 64-bit big endian PowerPC and 64-bit little endian PowerPC architecture machine types, with an appropriate, generic processor model assumed for scheduling purposes. So do that for each of the three machines. This bug was found when building the kernel with a toolchain that defaulted to powre10, resulting in a pcrel enabled wrapper which fails to link: arch/powerpc/boot/wrapper.a(crt0.o): in function `p_base': (.text+0x150): call to `platform_init' lacks nop, can't restore toc; (toc save/adjust stub) (.text+0x154): call to `start' lacks nop, can't restore toc; (toc save/adjust stub) powerpc64le-buildroot-linux-gnu-ld: final link failed: bad value Even with tha bug worked around the resulting kernel would crash on a power9 box: $ qemu-system-ppc64 -nographic -nodefaults -M powernv9 -kernel arch/powerpc/boot/zImage.epapr -serial mon:stdio [ 7.069331356,5] INIT: Starting kernel at 0x20010020, fdt at 0x3068c628 25694 bytes [ 7.130374661,3] *********************************************** [ 7.131072886,3] Fatal Exception 0xe40 at 00000000200101e4 MSR 9000000000000001 [ 7.131290613,3] CFAR : 000000002001027c MSR : 9000000000000001 [ 7.131433759,3] SRR0 : 0000000020010050 SRR1 : 9000000000000001 [ 7.131577775,3] HSRR0: 00000000200101e4 HSRR1: 9000000000000001 [ 7.131733687,3] DSISR: 00000000 DAR : 0000000000000000 [ 7.131905162,3] LR : 0000000020010280 CTR : 0000000000000000 [ 7.132068356,3] CR : 44002004 XER : 00000000 Signed-off-by:
Murilo Opsfelder Araujo <muriloo@linux.ibm.com> Reviewed-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
-
- 26 Apr, 2022 7 commits
-
-
Hari Bathini authored
Print preserved area start address in fadump_region_show() function. Signed-off-by:
Hari Bathini <hbathini@linux.ibm.com> Signed-off-by:
-
Hari Bathini authored
On crash, boot memory area is copied to a destination address by f/w. This region is setup as separate PT_LOAD segment with appropriate offset to handle the different physical address and offset in vmcore. If this destination address is not page aligned, reading the vmcore with mmap is likely to fail forcing tools like makedumpfile to fall back to regular read. Avoid mmap read failure by ensuring that the destination address is always page aligned. Signed-off-by:
-
Hari Bathini authored
Boot memory area is setup as separate PT_LOAD segment in the vmcore as it is moved by f/w, on crash, to a destination address provided by the kernel. Having separate PT_LOAD segment helps in handling the different physical address and offset for boot memory area in the vmcore. Commit ced1bf52 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") inadvertly broke this pre-condition for cases where some of the first kernel memory is available adjacent to boot memory area. This scenario is rare but possible when memory for fadump could not be reserved adjacent to boot memory area owing to memory hole or such. Reading memory from a vmcore exported in such scenario provides incorrect data. Fix it by ensuring no other region is folded into boot memory area. Fixes: ced1bf52 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") Signed-off-by:
-
Hari Bathini authored
An LPAR can be terminated by the POWER Hypervisor (PHYP) for various reasons. If FADump was configured when PHYP terminates the LPAR, platform-assisted dump is initiated to save the kernel dump. But CPU register data would not be processed/saved in the vmcore in such case because CPU mask is set in crash_fadump() at the time of kernel crash and it remains unset in this case with LPAR being terminated by PHYP abruptly. To get around the problem, initialize cpu_mask to cpu_possible_mask so as to ensure all possible CPUs' register data is processed for the vmcore generated on PHYP terminated LPAR. Also, rename the crash info member variable from online_mask to cpu_mask as it doesn't necessarily have to be online CPU mask always. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by:
-
Hari Bathini authored
Dump capture would fail if capture kernel is not of the endianess as the production kernel, because the in-memory data structure (struct opal_fadump_mem_struct) shared across production kernel and capture kernel assumes the same endianess for both the kernels, which doesn't have to be true always. Fix it by having a well-defined endianess for struct opal_fadump_mem_struct. Signed-off-by:
-
Haowen Bai authored
The function __perf_reg_mask has an unsigned return type, but returns a negative constant to indicate an error condition. So we change unsigned to int. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Signed-off-by:
-
Frank Rowand authored
The last user of find_node_by_linuxphandle() was removed in v4.18-rc1 by commit 30f4bbe0 ("powerpc/boot: Remove support for Marvell MPSC serial controller") four years ago. This function is no longer needed. Signed-off-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
-
- 23 Apr, 2022 1 commit
-
-
Bjorn Helgaas authored
Remove unused SLOW_DOWN_IO definition. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
- 21 Apr, 2022 1 commit
-
-
Hangyu Hua authored
info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path. Fixes: 75ca758a ("ocxl: Create a clear delineation between ocxl backend & frontend") Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Acked-by:
Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by:
-
