aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-29Merge branch 'thermal-core'Rafael J. Wysocki1-9/+9
Merge changes that make the thermal core use ida_alloc()/free() directly instead of ida_simple_get()/ida_simple_remove() that have been deprecated. * thermal-core: thermal: Directly use ida_alloc()/free()
2022-07-29Merge tag 'powerpc-5.19-6' of ↵Linus Torvalds3-1/+6
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Re-enable the new amdgpu display engine for powerpc, as long as the compiler is correctly configured. - Disable stack variable initialisation in prom_init to fix GCC 12 allmodconfig. Thanks to Dan Horák and Sudip Mukherjee. * tag 'powerpc-5.19-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: drm/amdgpu: Re-enable DCN for 64-bit powerpc powerpc/64s: Disable stack variable initialisation for prom_init
2022-07-29MAINTAINERS: add spi support to GXPNick Hawkins1-0/+2
Add the spi driver and dt-binding documentation Signed-off-by: Nick Hawkins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-07-29spi: dt-bindings: add documentation for hpe,gxp-spifiNick Hawkins1-0/+56
Create documentation for the hpe,gxp-spifi binding to support access to the SPI parts Signed-off-by: Nick Hawkins <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-07-29spi: spi-gxp: Add support for HPE GXP SoCsNick Hawkins3-0/+333
The GXP supports 3 separate SPI interfaces to accommodate the system flash, core flash, and other functions. The SPI engine supports variable clock frequency, selectable 3-byte or 4-byte addressing and a configurable x1, x2, and x4 command/address/data modes. The memory buffer for reading and writing ranges between 256 bytes and 8KB. This driver supports access to the core flash and bios part. Signed-off-by: Nick Hawkins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2022-07-29Merge back cpuidle material for 5.20.Rafael J. Wysocki3-23/+33
2022-07-29pwm: lpc18xx: Fix period handlingUwe Kleine-König1-16/+31
The calculation: val = (u64)NSEC_PER_SEC * LPC18XX_PWM_TIMER_MAX; do_div(val, lpc18xx_pwm->clk_rate); lpc18xx_pwm->max_period_ns = val; is bogus because with NSEC_PER_SEC = 1000000000, LPC18XX_PWM_TIMER_MAX = 0xffffffff and clk_rate < NSEC_PER_SEC this overflows the (on lpc18xx (i.e. ARM32) 32 bit wide) unsigned int .max_period_ns. This results (dependant of the actual clk rate) in an arbitrary limitation of the maximal period. E.g. for clkrate = 333333333 (Hz) we get max_period_ns = 9 instead of 12884901897. So make .max_period_ns an u64 and pass period and duty as u64 to not discard relevant digits. And also make use of mul_u64_u64_div_u64() which prevents all overflows assuming clk_rate < NSEC_PER_SEC. Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: lpc18xx: Convert to use dev_err_probe()Uwe Kleine-König1-11/+9
This has various upsides: - It emits the symbolic name of the error code - It is silent in the EPROBE_DEFER case and properly sets the defer reason - It reduces the number of code lines slightly Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: twl-led: Document some limitations and link to the reference manualUwe Kleine-König1-0/+16
I found these just from reading the reference manual and the driver source. It's unclear to me if there are glitches when updating the ON and OFF registers. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29MAINTAINERS: Remove myself as PWM maintainerLee Jones1-1/+0
Thierry and Uwe are doing a fine job, leaving me surplus to requirement. Happy to pop back on-board if anything changes in the future. Cc: Thierry Reding <[email protected]> Cc: Uwe Kleine-König <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Lee Jones <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29MAINTAINERS: Add include/dt-bindings/pwm to PWM SUBSYSTEMLukas Bulwahn1-0/+1
Maintainers of the directory Documentation/devicetree/bindings/pwm are also the maintainers of the corresponding directory include/dt-bindings/pwm. Add the file entry for include/dt-bindings/pwm to the appropriate section in MAINTAINERS. Signed-off-by: Lukas Bulwahn <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29dt-bindings: pwm: mediatek: Add compatible string for MT8195Fabien Parent1-0/+1
MT8195's PWM IP is compatible with the MT8183 PWM IP. Signed-off-by: Fabien Parent <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: Add clock based PWM output driverNikita Travkin3-0/+159
Some systems have clocks exposed to external devices. If the clock controller supports duty-cycle configuration, such clocks can be used as pwm outputs. In fact PWM and CLK subsystems are interfaced with in a similar way and an "opposite" driver already exists (clk-pwm). Add a driver that would enable pwm devices to be used via clk subsystem. Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Nikita Travkin <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29dt-bindings: pwm: Document clk based PWM controllerNikita Travkin1-0/+46
Add YAML devicetree binding for clk based PWM controller Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Nikita Travkin <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Shut down hardware only after pwmchip_remove() completedUwe Kleine-König1-2/+3
The PWMs are expected to be functional until pwmchip_remove() is called. So disable the clks only afterwards. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Ensure the clk is enabled exactly once per running PWMUwe Kleine-König1-9/+37
.apply() assumes the clk to be for a given PWM iff the PWM is enabled. So make sure this is the case when .probe() completes. And in .remove() disable the according number of times. This fixes a clk enable/disable imbalance, if some PWMs are already running at probe time. Fixes: 9e37a53eb051 (pwm: sifive: Add a driver for SiFive SoC PWM) Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Simplify clk handlingUwe Kleine-König1-13/+13
The clk is necessary for both register access and (enabled) operation of the PWM. Instead of clk_enable() update_hw() if pwm_got_enabled(): clk_enable() elif pwm_got_disabled(): clk_disable() clk_disable() which is some cases only calls clk_enable() to immediately afterwards call clk_disable again, do: if (!prev_state.enabled) clk_enable() # clk enabled exactly once update_hw() if (!next_state.enabled) clk_disable() which is much easier. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Enable clk only after period check in .apply()Uwe Kleine-König1-10/+8
For the period check and the initial calculations of register values there is no hardware access needed. So delay enabling the clk a bit to simplify the code flow a bit. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Reduce time the controller lock is heldUwe Kleine-König1-3/+5
The lock is only to serialize access and update to user_count and approx_period between different PWMs served by the same pwm_chip. So the lock needs only to be taken during the check if the (chip global) period can and/or needs to be changed. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Fold pwm_sifive_enable() into its only callerUwe Kleine-König1-20/+8
There is only a single caller of pwm_sifive_enable() which only enables or disables the clk. Put this implementation directly into pwm_sifive_apply() which allows further simplification in the next change. There is no change in behaviour. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Simplify offset calculation for PWMCMP registersUwe Kleine-König1-7/+3
Instead of explicitly using PWM_SIFIVE_PWMCMP0 + pwm->hwpwm * PWM_SIFIVE_SIZE_PWMCMP for each access to one of the PWMCMP registers, introduce a macro that takes the hwpwm id as parameter. For the register definition using a plain 4 instead of the cpp constant PWM_SIFIVE_SIZE_PWMCMP is easier to read, so define the offset macro without the constant. The latter can then be dropped as there are no users left. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29crypto: tcrypt - Remove the static variable initialisations to NULLJason Wang1-1/+1
Initialise global and static variable to NULL is always unnecessary. Remove the unnecessary initialisations. Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: arm64/poly1305 - fix a read out-of-boundGUO Zihua1-1/+1
A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace: dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e"; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash("poly1305", 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1); crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE("GPL"); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first "block" that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes. The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead of poly1305_init_arch(). This is also the implementation for the same algorithm on arm platform. Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: [email protected] Signed-off-by: GUO Zihua <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: hisilicon/zip - Use the bitmap API to allocate bitmapsChristophe JAILLET1-5/+5
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them. It is less verbose and it improves the semantic. While at it, add an explicit include <linux/bitmap.h>. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: hisilicon/sec - fix auth key size errorKai Ye2-3/+4
The authentication algorithm supports a maximum of 128-byte keys. The allocated key memory is insufficient. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Kai Ye <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: ccree - Remove a useless dma_supported() callChristophe JAILLET1-10/+3
There is no point in calling dma_supported() before calling dma_set_coherent_mask(). This function already calls dma_supported() and returns an error (-EIO) if it fails. So remove the superfluous dma_supported() call. Moreover, setting a larger DMA mask will never fail when setting a smaller one will succeed, so the whole "while" loop can be removed as well. (see [1]) While at it, fix the name of the function reported in a dev_err(). [1]: https://lore.kernel.org/all/[email protected]/ Suggested-by: Christoph Hellwig <[email protected]> Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: ccp - Add support for new CCP/PSP device IDMario Limonciello1-0/+7
Add a new CCP/PSP PCI device ID. This uses same register offsets as the previously supported structure. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Tom Lendacky <[email protected]> Acked-by: Rijo Thomas <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: inside-secure - Add missing MODULE_DEVICE_TABLE for ofPali Rohár1-0/+2
Without MODULE_DEVICE_TABLE, crypto_safexcel.ko module is not automatically loaded on platforms where inside-secure crypto HW is specified in device tree (e.g. Armada 3720). So add missing MODULE_DEVICE_TABLE for of. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Pali Rohár <[email protected]> Acked-by: Marek Behún <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirqZhengchao Shao1-1/+1
The hpre encryption driver may be used to encrypt and decrypt packets during the rx softirq, it is not allowed to use GFP_KERNEL. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-07-29LoongArch: Fix wrong "ROM Size" of boardinfoTiezhu Yang1-1/+1
We can see the "ROM Size" is different in the following outputs: [root@linux loongson]# cat /sys/firmware/loongson/boardinfo BIOS Information Vendor : Loongson Version : vUDK2018-LoongArch-V2.0.pre-beta8 ROM Size : 63 KB Release Date : 06/15/2022 Board Information Manufacturer : Loongson Board Name : Loongson-LS3A5000-7A1000-1w-A2101 Family : LOONGSON64 [root@linux loongson]# dmidecode | head -11 ... Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: Loongson Version: vUDK2018-LoongArch-V2.0.pre-beta8 Release Date: 06/15/2022 ROM Size: 4 MB According to "BIOS Information (Type 0) structure" in the SMBIOS Reference Specification [1], it shows 64K * (n+1) is the size of the physical device containing the BIOS if the size is less than 16M. Additionally, we can see the related code in dmidecode [2]: u64 s = { .l = (code1 + 1) << 6 }; So the output of dmidecode is correct, the output of boardinfo is wrong, fix it. By the way, at present no need to consider the size is 16M or greater on LoongArch, because it is usually 4M or 8M which is enough to use. [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.6.0.pdf [2] https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/dmidecode.c#n347 Fixes: 628c3bb40e9a ("LoongArch: Add boot and setup routines") Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Fix missing fcsr in ptrace's fpr_setQi Hu1-5/+7
In file ptrace.c, function fpr_set does not copy fcsr data from ubuf to kbuf. That's the reason why fcsr cannot be modified by ptrace. This patch fixs this problem and allows users using ptrace to modify the fcsr. Co-developed-by: Xu Li <[email protected]> Signed-off-by: Qi Hu <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Fix shared cache size calculationHuacai Chen1-2/+9
Current calculation of shared cache size is from the node (die) scope, but we hope 'lscpu' to show the shared cache size of the whole package for multi-die chips (e.g., Loongson-3C5000L, which contains 4 dies in one package). So fix it by multiplying nodes_per_package. Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Disable executable stack by defaultHuacai Chen1-2/+0
Disable executable stack for LoongArch by default, as all modern architectures do. Reported-by: Andreas Schwab <[email protected]> Suggested-by: WANG Xuerui <[email protected]> Link: https://sourceware.org/pipermail/binutils/2022-July/121992.html Tested-by: WANG Xuerui <[email protected]> Tested-by: Xi Ruoyao <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Remove unused variablesBibo Mao2-32/+0
There are some variables never used or referenced, this patch removes these varaibles and make the code cleaner. Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Remove clock setting during cpu hotplug stageBibo Mao2-101/+13
On physical machine we can save power by disabling clock of hot removed cpu. However as different platforms require different methods to configure clocks, the code is platform-specific, and probably belongs to firmware/pmu or cpu regulator, rather than generic arch/loongarch code. Also, there is no such register on QEMU virt machine since the clock/frequency regulation is not emulated. This patch removes the hard-coded clock register accesses in generic LoongArch cpu hotplug flow. Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Remove useless header compiler.hJun Yi8-32/+6
The content of LoongArch's compiler.h is trivial, with some unused anywhere, so inline the definitions and remove the header. Signed-off-by: Jun Yi <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Remove several syntactic sugar macros for branchesWANG Xuerui1-12/+0
These syntactic sugars have been supported by upstream binutils from the beginning, so no need to patch them locally. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Re-tab the assembly filesWANG Xuerui7-163/+163
Reflow the *.S files for better stylistic consistency, namely hard tabs after mnemonic position, and vertical alignment of the first operand with hard tabs. Tab width is obviously 8. Some pre-existing intra-block vertical alignments are preserved. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Simplify "BGT foo, zero" with BGTZWANG Xuerui2-2/+2
Support for the syntactic sugar is present in upstream binutils port from the beginning. Use it for shorter lines and better consistency. Generated code should be identical. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Simplify "BLT foo, zero" with BLTZWANG Xuerui2-7/+7
Support for the syntactic sugar is present in upstream binutils port from the beginning. Use it for shorter lines and better consistency. Generated code should be identical. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Simplify "BEQ/BNE foo, zero" with BEQZ/BNEZWANG Xuerui4-22/+22
While B{EQ,NE}Z and B{EQ,NE} are different instructions, and the vastly expanded range for branch destination does not really matter in the few cases touched, use the B{EQ,NE}Z where possible for shorter lines and better consistency (e.g. some places used "BEQ foo, zero", while some used "BEQ zero, foo"). Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Use the "move" pseudo-instruction where applicableWANG Xuerui5-8/+8
Some of the assembly code in the LoongArch port likely originated from a time when the assembler did not support pseudo-instructions like "move" or "jr", so the desugared form was used and readability suffers (to a minor degree) as a result. As the upstream toolchain supports these pseudo-instructions from the beginning, migrate the existing few usages to them for better readability. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Use the "jr" pseudo-instruction where applicableWANG Xuerui5-15/+15
Some of the assembly code in the LoongArch port likely originated from a time when the assembler did not support pseudo-instructions like "move" or "jr", so the desugared form was used and readability suffers (to a minor degree) as a result. As the upstream toolchain supports these pseudo-instructions from the beginning, migrate the existing few usages to them for better readability. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29LoongArch: Use ABI names of registers where appropriateWANG Xuerui7-55/+55
Some of the assembly in the LoongArch port seem to come from a prehistoric time, when the assembler didn't even have support for the ABI names we all come to know and love, thus used raw register numbers which hampered readability. The usages are found with a regex match inside arch/loongarch, then manually adjusted for those non-definitions. Signed-off-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-07-29ARM: findbit: fix overflowing offsetRussell King (Oracle)1-8/+8
When offset is larger than the size of the bit array, we should not attempt to access the array as we can perform an access beyond the end of the array. Fix this by changing the pre-condition. Using "cmp r2, r1; bhs ..." covers us for the size == 0 case, since this will always take the branch when r1 is zero, irrespective of the value of r2. This means we can fix this bug without adding any additional code! Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2022-07-29x86/bugs: Do not enable IBPB at firmware entry when IBPB is not availableThadeu Lima de Souza Cascardo1-0/+1
Some cloud hypervisors do not provide IBPB on very recent CPU processors, including AMD processors affected by Retbleed. Using IBPB before firmware calls on such systems would cause a GPF at boot like the one below. Do not enable such calls when IBPB support is not present. EFI Variables Facility v0.08 2004-May-17 general protection fault, maybe for address 0x1: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 24 Comm: kworker/u2:1 Not tainted 5.19.0-rc8+ #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Workqueue: efi_rts_wq efi_call_rts RIP: 0010:efi_call_rts Code: e8 37 33 58 ff 41 bf 48 00 00 00 49 89 c0 44 89 f9 48 83 c8 01 4c 89 c2 48 c1 ea 20 66 90 b9 49 00 00 00 b8 01 00 00 00 31 d2 <0f> 30 e8 7b 9f 5d ff e8 f6 f8 ff ff 4c 89 f1 4c 89 ea 4c 89 e6 48 RSP: 0018:ffffb373800d7e38 EFLAGS: 00010246 RAX: 0000000000000001 RBX: 0000000000000006 RCX: 0000000000000049 RDX: 0000000000000000 RSI: ffff94fbc19d8fe0 RDI: ffff94fbc1b2b300 RBP: ffffb373800d7e70 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000b R11: 000000000000000b R12: ffffb3738001fd78 R13: ffff94fbc2fcfc00 R14: ffffb3738001fd80 R15: 0000000000000048 FS: 0000000000000000(0000) GS:ffff94fc3da00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff94fc30201000 CR3: 000000006f610000 CR4: 00000000000406f0 Call Trace: <TASK> ? __wake_up process_one_work worker_thread ? rescuer_thread kthread ? kthread_complete_and_exit ret_from_fork </TASK> Modules linked in: Fixes: 28a99e95f55c ("x86/amd: Use IBPB for firmware calls") Reported-by: Dimitri John Ledkov <[email protected]> Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28dm: verity-loadpin: Drop use of dm_table_get_num_targets()Matthias Kaehlcke1-1/+2
Commit 2aec377a2925 ("dm table: remove dm_table_get_num_targets() wrapper") in linux-dm/for-next removed the function dm_table_get_num_targets() which is used by verity-loadpin. Access table->num_targets directly instead of using the defunct wrapper. Fixes: b6c1c5745ccc ("dm: Add verity helpers for LoadPin") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20220728085412.1.I242d21b378410eb6f9897a3160efb56e5608c59d@changeid
2022-07-28Merge tag 'drm-fixes-2022-07-29' of git://anongit.freedesktop.org/drm/drmLinus Torvalds5-79/+103
Pull drm fix from Dave Airlie: "Quiet extra week, just a single fix for i915 workaround with execlist backend. i915: - Further reset robustness improvements for execlists [Wa_22011802037]" * tag 'drm-fixes-2022-07-29' of git://anongit.freedesktop.org/drm/drm: drm/i915/reset: Add additional steps for Wa_22011802037 for execlist backend
2022-07-29Merge tag 'drm-intel-fixes-2022-07-28-1' of ↵Dave Airlie5-79/+103
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Further reset robustness improvements for execlists [Wa_22011802037] (Umesh Nerlige Ramappa) Signed-off-by: Dave Airlie <[email protected]> From: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/YuJIWaEbKcs/q0NY@tursulin-desk
2022-07-28dm: fix dm-raid crash if md_handle_request() splits bioMike Snitzer4-9/+15
Commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") introduced the optimization to _not_ perform bio_associate_blkg()'s relatively costly work when DM core clones its bio. But in doing so it exposed the possibility for DM's cloned bio to alter DM target behavior (e.g. crash) if a target were to issue IO without first calling bio_set_dev(). The DM raid target can trigger an MD crash due to its need to split the DM bio that is passed to md_handle_request(). The split will recurse to submit_bio_noacct() using a bio with an uninitialized ->bi_blkg. This NULL bio->bi_blkg causes blk_throtl_bio() to dereference a NULL blkg_to_tg(bio->bi_blkg). Fix this in DM core by adding a new 'needs_bio_set_dev' target flag that will make alloc_tio() call bio_set_dev() on behalf of the target. dm-raid is the only target that requires this flag. bio_set_dev() initializes the DM cloned bio's ->bi_blkg, using bio_associate_blkg, before passing the bio to md_handle_request(). Long-term fix would be to audit and refactor MD code to rely on DM to split its bio, using dm_accept_partial_bio(), but there are MD raid personalities (e.g. raid1 and raid10) whose implementation are tightly coupled to handling the bio splitting inline. Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Cc: [email protected] Signed-off-by: Mike Snitzer <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.