summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-20serial: max310x: fix IO data corruption in batched operationsJan Kundrát
After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc049c ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: core: Disable uart_start() on uart_remove_one_port()Tony Lindgren
While rebinding a uart device in a loop I noticed we may see a tx related race on uart_remove_one_port(): uart_write from n_tty_write n_tty_write from file_tty_write.constprop.0 file_tty_write.constprop.0 from vfs_write vfs_write from ksys_write ksys_write from ret_fast_syscall Let's disallow tx on port->UPF_DEAD. This flag gets set before we start tearing down the port in uart_remove_one_port(). Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230419115423.59957-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: 8250: Reinit port->pm on port specific driver unbindTony Lindgren
When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230418101407.12403-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: 8250: Add missing wakeup event reportingFlorian Fainelli
An 8250 UART configured as a wake-up source would not have reported itself through sysfs as being the source of wake-up, correct that. Fixes: b3b708fa2780 ("wake up from a serial port") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230414170241.2016255-1-f.fainelli@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: fsl_lpuart: use UARTMODIR register bits for lpuart32 platformSherry Sun
For lpuart32 platforms, UARTMODIR register is used instead of UARTMODEM. So here should configure the corresponding UARTMODIR register bits to avoid confusion. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20230414022111.20896-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: fsl_lpuart: adjust buffer length to the intended sizeShenwei Wang
Based on the fls function definition provided below, we should not subtract 1 to obtain the correct buffer length: fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32. Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Link: https://lore.kernel.org/r/20230410195555.1003900-1-shenwei.wang@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: fix TIOCSRS485 lockingJohan Hovold
The RS485 multipoint addressing support for some reason added a new ADDRB termios cflag which is (only!) updated from one of the RS485 ioctls. Make sure to take the termios rw semaphore for the right ioctl (i.e. set, not get). Fixes: ae50bb275283 ("serial: take termios_rwsem for ->rs485_config() & pass termios as param") Cc: stable@vger.kernel.org # 6.0 Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20230412124811.11217-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: make SiFive serial drivers depend on ARCH_ symbolsConor Dooley
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the use of such symbols on other architectures, convert the SiFive serial driver Kconfig entries from the SOC_ symbols to ARCH_ instead. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230406-carnival-aspirate-fcf69a30078c@spud Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: synclink_gt: don't allocate and pass dummy flagsJiri Slaby (SUSE)
In synclinc_gt, the flag_buf is allocated, zeroed and passed to ldisc's receive_buf(). It is never written to, so it serves as a dummy buffer. That's unneeded because all ldiscs accept NULL as flags. That NULL resolves to the TTY_NORMAL flag. So drop all this nonsense. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093530.13133-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: simplify qcom_geni_serial_send_chunk_fifo()Jiri Slaby (SUSE)
* use memcpy() instead of the loop (removes c variable) * use remaining parameter directly (removes chunk variable) The code is simpler and easier to follow. Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093514.13055-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20leds: pwm-multicolor: Simplify an error messageChristophe JAILLET
dev_err_probe() already display the error code. There is no need to duplicate it explicitly in the error message. While at it, add a missing \n at the end of the message. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/07d35e221faaa380fd11cd4597e42354c8eb350c.1681576017.git.christophe.jaillet@wanadoo.fr
2023-04-20dt-bindings: leds: Convert PCA9532 to dtschemaWadim Egorov
Convert the PCA9532 LED Dimmer to dtschema. While at it, update the example to match recommended node names and the link to the product datasheet. Also add GPIO properties since the driver allows to use unused pins as GPIOs. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230412140552.451527-1-w.egorov@phytec.de
2023-04-20tty: n_gsm: fix redundant assignment of gsm->encodingDaniel Starke
The function gsmld_open() contains a redundant assignment of gsm->encoding. The same value of GSM_ADV_OPT is already assigned to it during the initialization of the struct in gsm_alloc_mux() a few lines earlier. Fix this by removing the redundant second assignment of gsm->encoding in gsmld_open(). Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20230420085017.7314-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20perf test: Fix maps use after putIan Rogers
Fix a use after put reference count issue. maps is copied from leader, but the leader is put on line 79 and then maps is used to read the reference count below - so a use after put, with the put of maps happening within thread__put. Fix by reversing the order of puts so that the leader is put last. To explain the reference count checker, I wrote this up as a little example here: https://perf.wiki.kernel.org/index.php/Reference_Count_Checking Note, the bug was introduced by the committer and wasn't present in the original reference count patch set. Committer notes: Yes, the bug predated your patch and is detected by the reference count checking you contributed. This was just part of splitting up your series into smaller chunks, in this case either we fix the problem detected while developing this reference counting infrastructure before the patch introducing REFCNT_CHECKING or fix it later after the merged infrastructure, when built with EXTRA_CFLAGS="-DREFCNT_CHECKING=1" detects it when running 'perf test', which is what this patch does. Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20230420030430.489243-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2023-04-20Merge branch 'for-next/mm' into for-next/coreWill Deacon
* for-next/mm: arm64: mm: always map fixmap at page granularity arm64: mm: move fixmap code to its own file arm64: add FIXADDR_TOT_{START,SIZE} Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"" arm: uaccess: Remove memcpy_page_flushcache() mm,kfence: decouple kfence from page granularity mapping judgement
2023-04-20Merge branch 'for-next/misc' into for-next/coreWill Deacon
* for-next/misc: arm64: kexec: include reboot.h arm64: delete dead code in this_cpu_set_vectors() arm64: kernel: Fix kernel warning when nokaslr is passed to commandline arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step arm64/sme: Fix some comments of ARM SME arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2() arm64/signal: Use system_supports_tpidr2() to check TPIDR2 arm64: compat: Remove defines now in asm-generic arm64: kexec: remove unnecessary (void*) conversions arm64: armv8_deprecated: remove unnecessary (void*) conversions firmware: arm_sdei: Fix sleep from invalid context BUG
2023-04-20Merge branch 'for-next/kdump' into for-next/coreWill Deacon
* for-next/kdump: arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones arm64: kdump: do not map crashkernel region specifically arm64: kdump : take off the protection on crashkernel memory region
2023-04-20Merge branch 'for-next/ftrace' into for-next/coreWill Deacon
* for-next/ftrace: arm64: ftrace: Simplify get_ftrace_plt arm64: ftrace: Add direct call support ftrace: selftest: remove broken trace_direct_tramp ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS ftrace: Store direct called addresses in their ops ftrace: Rename _ftrace_direct_multi APIs to _ftrace_direct APIs ftrace: Remove the legacy _ftrace_direct API ftrace: Replace uses of _ftrace_direct APIs with _ftrace_direct_multi ftrace: Let unregister_ftrace_direct_multi() call ftrace_free_filter()
2023-04-20Merge branch 'for-next/cpufeature' into for-next/coreWill Deacon
* for-next/cpufeature: arm64/cpufeature: Use helper macro to specify ID register for capabilites arm64/cpufeature: Consistently use symbolic constants for min_field_value arm64/cpufeature: Pull out helper for CPUID register definitions
2023-04-20Merge branch 'for-next/asm' into for-next/coreWill Deacon
* for-next/asm: arm64: uaccess: remove unnecessary earlyclobber arm64: uaccess: permit put_{user,kernel} to use zero register arm64: uaccess: permit __smp_store_release() to use zero register arm64: atomics: lse: improve cmpxchg implementation
2023-04-20Merge branch 'for-next/acpi' into for-next/coreWill Deacon
* for-next/acpi: ACPI: AGDI: Improve error reporting for problems during .remove()
2023-04-20i2c: designware: Add doorbell support for MendocinoMario Limonciello
Mendocino and later platform don't use the platform feature mailbox for communication for I2C arbitration, they rely upon ringing a doorbell. Detect the platform by the device ID of the root port and choose the appropriate method. Link: https://lore.kernel.org/linux-i2c/20220916131854.687371-3-jsd@semihalf.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20i2c: designware: Use PCI PSP driver for communicationMario Limonciello
Currently the PSP semaphore communication base address is discovered by using an MSR that is not architecturally guaranteed for future platforms. Also the mailbox that is utilized for communication with the PSP may have other consumers in the kernel, so it's better to make all communication go through a single driver. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20powerpc: Move Power10 feature PPC_MODULE_FEATURE_P10Danny Tsen
Move Power10 feature, PPC_MODULE_FEATURE_P10, definition to be in arch/powerpc/include/asm/cpufeature.h. Signed-off-by: Danny Tsen <dtsen@linux.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: p10-aes-gcm - Remove POWER10_CPU dependencyDanny Tsen
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Signed-off-by: Danny Tsen <dtsen@linux.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: testmgr - Add some test vectors for cmac(camellia)David Howells
Add some test vectors for 128-bit cmac(camellia) as found in draft-kato-ipsec-camellia-cmac96and128-01 section 6.2. The document also shows vectors for camellia-cmac-96, and for VK with a length greater than 16, but I'm not sure how to express those in testmgr. This also leaves cts(cbc(camellia)) untested, but I can't seem to find any tests for that that I could put into testmgr. Signed-off-by: David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Chuck Lever <chuck.lever@oracle.com> cc: Scott Mayhew <smayhew@redhat.com> cc: linux-nfs@vger.kernel.org cc: linux-crypto@vger.kernel.org Link: https://datatracker.ietf.org/doc/pdf/draft-kato-ipsec-camellia-cmac96and128-01 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: cryptd - Add support for cloning hashesHerbert Xu
Allow cryptd hashes to be cloned. The underlying hash will be cloned. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: cryptd - Convert hash to use modern init_tfm/exit_tfmHerbert Xu
The cryptd hash template was still using the obsolete cra_init/cra_exit interface. Make it use the modern ahash init_tfm/exit_tfm instead. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: hmac - Add support for cloningHerbert Xu
Allow hmac to be cloned. The underlying hash can be used directly with a reference count. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: hash - Add crypto_clone_ahash/shashHerbert Xu
This patch adds the helpers crypto_clone_ahash and crypto_clone_shash. They are the hash-specific counterparts of crypto_clone_tfm. This allows code paths that cannot otherwise allocate a hash tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Note that only algorithms that implement clone_tfm can be cloned. However, all keyless hashes can be cloned by simply reusing the tfm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: api - Add crypto_clone_tfmHerbert Xu
This patch adds the helper crypto_clone_tfm. The purpose is to allocate a tfm object with GFP_ATOMIC. As we cannot sleep, the object has to be cloned from an existing tfm object. This allows code paths that cannot otherwise allocate a crypto_tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: api - Add crypto_tfm_getHerbert Xu
Add a crypto_tfm_get interface to allow tfm objects to be shared. They can still be freed in the usual way. This should only be done with tfm objects with no keys. You must also not modify the tfm flags in any way once it becomes shared. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/sha - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/crc32 - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/aesni - Use local .L symbols for codeArd Biesheuvel
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/sha256 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/ghash - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/des3 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/crc32c - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/cast6 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/cast5 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/camellia - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Thomas Garnier <thgarnie@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/aria - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/aesni - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. In the GCM case, we can get rid of the oversized permutation array entirely while at it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20crypto: x86/aegis128 - Use RIP-relative addressingArd Biesheuvel
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20leds: rgb: leds-qcom-lpg: Add support for PMK8550 PWMAnjelique Melendez
Add support for pmk8550 compatible and lpg_data. Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230407223849.17623-4-quic_amelende@quicinc.com
2023-04-20leds: rgb: leds-qcom-lpg: Add support for high resolution PWMAnjelique Melendez
Certain PMICs like PMK8550 have a high resolution PWM module which can support from 8-bit to 15-bit PWM. Add support for it. Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230407223849.17623-3-quic_amelende@quicinc.com
2023-04-20dt-bindings: leds-qcom-lpg: Add qcom,pmk8550-pwm compatible stringAnjelique Melendez
Add qcom,pmk8550-pwm compatible string for the Qualcomm Technologies, Inc. PMK8550 PMIC which has two high resolution PWM channels. Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230407223849.17623-2-quic_amelende@quicinc.com
2023-04-20wifi: mac80211: remove return value check of debugfs_create_dir()Yingsha Xu
Smatch complains that: debugfs_hw_add() warn: 'statsd' is an error pointer or valid Debugfs checks are generally not supposed to be checked for errors and it is not necessary here. Just delete the dead code. Signed-off-by: Yingsha Xu <ysxu@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Link: https://lore.kernel.org/r/20230419104548.30124-1-ysxu@hust.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix RFKILL report when driver is going downAvraham Stern
When CSME takes ownership, the driver sets RFKILL on, and this triggers driver unload and sending the confirmation SAP message. However, when IWL_MVM_MEI_REPORT_RFKILL is set, RFKILL was not reported and as a result, the driver did not confirm the ownership transition. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.29ac3cd3df73.I96b32bc274bfe1e3871e54d3fa29c7ac4f40446f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.34.1) at 2025-09-20 20:51:29 +0000