Slimbus devices can be allocated dynamically upon reception of
report-present messages.
Make sure to drop the reference taken when looking up already registered
devices.
Note that this requires taking an extra reference in case the device has
not yet been registered and has to be allocated.
Fixes: 46a2bb5a7f ("slimbus: core: Add slim controllers support")
Cc: stable@vger.kernel.org # 4.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251126145329.5022-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to balance the runtime PM usage count in case slimbus device
or address allocation fails on report present, which would otherwise
prevent the controller from suspending.
Fixes: 4b14e62ad3 ("slimbus: Add support for 'clock-pause' feature")
Cc: stable@vger.kernel.org # 4.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251126145329.5022-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to drop the OF node reference taken when initialising and
registering the slimbus device also on registration failure by releasing
it in the destructor as expected.
Fixes: 7588a511bd ("slimbus: core: add support to device tree helper")
Fixes: 0136085748 ("slimbus: core: Fix mismatch in of_node_get/put")
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251126145329.5022-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use a more a descriptive name for the error label that is used to put
the reference to dev.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251208153524.68637-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to drop the reference taken when looking up the th device
during output device open() on errors and on close().
Note that a recent commit fixed the leak in a couple of open() error
paths but not all of them, and the reference is still leaking on
successful open().
Fixes: 39f4034693 ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices")
Fixes: 6d5925b667 ("intel_th: Fix error handling in intel_th_output_open")
Cc: stable@vger.kernel.org # 4.4: 6d5925b667
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ma Ke <make24@iscas.ac.cn>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251208153524.68637-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `COMEDI_RANGEINFO` ioctl does not work properly for subdevice
indices above 15. Currently, the only in-tree COMEDI drivers that
support more than 16 subdevices are the "8255" driver and the
"comedi_bond" driver. Making the ioctl work for subdevice indices up to
255 is achievable. It needs minor changes to the handling of the
`COMEDI_RANGEINFO` and `COMEDI_CHANINFO` ioctls that should be mostly
harmless to user-space, apart from making them less broken. Details
follow...
The `COMEDI_RANGEINFO` ioctl command gets the list of supported ranges
(usually with units of volts or milliamps) for a COMEDI subdevice or
channel. (Only some subdevices have per-channel range tables, indicated
by the `SDF_RANGETYPE` flag in the subdevice information.) It uses a
`range_type` value and a user-space pointer, both supplied by
user-space, but the `range_type` value should match what was obtained
using the `COMEDI_CHANINFO` ioctl (if the subdevice has per-channel
range tables) or `COMEDI_SUBDINFO` ioctl (if the subdevice uses a
single range table for all channels). Bits 15 to 0 of the `range_type`
value contain the length of the range table, which is the only part that
user-space should care about (so it can use a suitably sized buffer to
fetch the range table). Bits 23 to 16 store the channel index, which is
assumed to be no more than 255 if the subdevice has per-channel range
tables, and is set to 0 if the subdevice has a single range table. For
`range_type` values produced by the `COMEDI_SUBDINFO` ioctl, bits 31 to
24 contain the subdevice index, which is assumed to be no more than 255.
But for `range_type` values produced by the `COMEDI_CHANINFO` ioctl,
bits 27 to 24 contain the subdevice index, which is assumed to be no
more than 15, and bits 31 to 28 contain the COMEDI device's minor device
number for some unknown reason lost in the mists of time. The
`COMEDI_RANGEINFO` ioctl extract the length from bits 15 to 0 of the
user-supplied `range_type` value, extracts the channel index from bits
23 to 16 (only used if the subdevice has per-channel range tables),
extracts the subdevice index from bits 27 to 24, and ignores bits 31 to
28. So for subdevice indices 16 to 255, the `COMEDI_SUBDINFO` or
`COMEDI_CHANINFO` ioctl will report a `range_type` value that doesn't
work with the `COMEDI_RANGEINFO` ioctl. It will either get the range
table for the subdevice index modulo 16, or will fail with `-EINVAL`.
To fix this, always use bits 31 to 24 of the `range_type` value to hold
the subdevice index (assumed to be no more than 255). This affects the
`COMEDI_CHANINFO` and `COMEDI_RANGEINFO` ioctls. There should not be
anything in user-space that depends on the old, broken usage, although
it may now see different values in bits 31 to 28 of the `range_type`
values reported by the `COMEDI_CHANINFO` ioctl for subdevices that have
per-channel subdevices. User-space should not be trying to decode bits
31 to 16 of the `range_type` values anyway.
Fixes: ed9eccbe89 ("Staging: add comedi core")
Cc: stable@vger.kernel.org #5.17+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The devm_kmalloc() function never returns error pointers, it returns
NULL on error. Fix the error checking.
Fixes: 4863cb2b0f ("mux: mmio: Add suspend and resume support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/aSsIP7oKrhKfCUv3@stanley.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The existing 1ms delay in sd_power_on is insufficient and causes resume
errors around 4% of the time.
Increasing the delay to 5ms resolves this issue after testing 300
s2idle cycles.
Fixes: 1f311c94aa ("mmc: rtsx: add 74 Clocks in power on flow")
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When rtsx_pci suspends, the card reader hardware powers off but the sdmmc
driver's prev_power_state remains as MMC_POWER_ON. This causes sd_power_on
to skip reinitialization on the next I/O request, leading to DMA transfer
timeouts and errors on resume 20% of the time.
Add a power_off slot callback so the PCR can notify the sdmmc driver
during suspend. The sdmmc driver resets prev_power_state, and sd_request
checks this to reinitialize the card before the next I/O.
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260105060236.400366-2-matthew.schwartz@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using MMC_CAP_AGGRESSIVE_PM on RTS525A card readers causes game
performance issues when the card reader comes back from idle into active
use. This can be observed in Hades II when loading new sections of the
game or menu after the card reader puts itself into idle, and presents
as a 1-2 second hang.
Add EXTRA_CAPS_NO_AGGRESSIVE_PM quirk to allow cardreader drivers to
opt-out of aggressive PM, and set it for RTS525A.
Closes: https://lore.kernel.org/linux-mmc/ff9a7c20-f465-4afa-bf29-708d4a52974a@linux.dev/
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260103204226.71752-1-matthew.schwartz@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drop the leading "CONFIG_" when referring to Kconfig symbols--
it is supplied by the kconfig software.
This make the default values work as (apparently) expected.
Fixes: a02509f301 ("stm class: Factor out default framing protocol")
Fixes: d69d5e8311 ("stm class: Add MIPI SyS-T protocol support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20251228190502.2480758-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In many kunit assert functions a const pointer is passed to
container_of() and out pops a non-const pointer, which really isn't the
correct thing to do at all. Fix this up by correctly marking the
casted-to pointer as const to preserve the marking.
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Cc: Rae Moar <raemoar63@gmail.com>
Cc: linux-kselftest@vger.kernel.org
Cc: kunit-dev@googlegroups.com
Reviewed-by: David Gow <davidgow@google.com>
Link: https://patch.msgid.link/2025121746-result-staleness-5a68@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the internal cmp function, a const pointer is cast out to a non-const
pointer by using container_of(). This is probably not what is intended
at all, so fix up the const marking to properly preserve what is really
happening (i.e. the const should flow through the container_of() call)
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: David Gow <davidgow@google.com>
Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Kees Cook <kees@kernel.org>
Cc: linux-kernel@vger.kernel.org
Reviewed-by: David Gow <davidgow@google.com>
Link: https://patch.msgid.link/2025121751-backtrack-manifesto-7c57@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Modify comments in fifo_icap.c to prevent all kernel-doc warnings:
Warning: fifo_icap.c:51 This comment starts with '/**', but isn't a
kernel-doc comment.
* HwIcap Device Interrupt Status/Enable Registers
Warning: fifo_icap.c:106 No description found for return value
of 'fifo_icap_fifo_read'
Warning: fifo_icap.c:160 No description found for return value
of 'fifo_icap_get_status'
Warning: fifo_icap.c:171 No description found for return value
of 'fifo_icap_busy'
Warning: fifo_icap.c:184 No description found for return value
of 'fifo_icap_write_fifo_vacancy'
Warning: fifo_icap.c:196 No description found for return value
of 'fifo_icap_read_fifo_occupancy'
Warning: fifo_icap.c:207 bad line:
Warning: fifo_icap.c:214 No description found for return value
of 'fifo_icap_set_configuration'
Warning: fifo_icap.c:290 function parameter 'frame_buffer' not described
in 'fifo_icap_get_configuration'
Warning: fifo_icap.c:290 function parameter 'num_words' not described
in 'fifo_icap_get_configuration'
Warning: fifo_icap.c:290 No description found for return value
of 'fifo_icap_get_configuration'
Warning: fifo_icap.c:357 expecting prototype for buffer_icap_reset().
Prototype was for fifo_icap_reset() instead
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20251214191750.2173225-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the function parameter parts of the struct member descriptions
to prevent kernel-doc warnings:
Warning: include/linux/eeprom_93cx6.h:64 struct member 'register_read'
not described in 'eeprom_93cx6'
Warning: ../include/linux/eeprom_93cx6.h:64 struct member 'register_write'
not described in 'eeprom_93cx6'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20251214202739.2216904-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The kgdbts_option_setup() function is invoked only once early in boot
via the __setup("kgdbts=", ...) mechanism to parse the kernel
command-line option.After init is complete, it is never called again.
Annotating it with __init places the function in the .init.text section,
enabling the kernel to free its code memory during the init memory
cleanup phase (free_initmem()). This reduces the kernel’s runtime
memory footprint with no functional side effects.
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Link: https://patch.msgid.link/20251208130525.2775885-1-pengcan@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Correct typos in 3 struct member descriptions to eliminate all
kernel-doc warnings in comedi_8254.h:
Warning: include/linux/comedi/comedi_8254.h:112 struct member 'next_div'
not described in 'comedi_8254'
Warning: include/linux/comedi/comedi_8254.h:112 struct member 'clock_src'
not described in 'comedi_8254'
Warning: include/linux/comedi/comedi_8254.h:112 struct member 'gate_src'
not described in 'comedi_8254'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251214202727.2215461-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fake "comedi_test" device currently has two subdevices: an analog
input subdevice, and an analog output subdevice. To make it a bit more
useful for testing, add a third subdevice for digital I/O.
The new DIO subdevice has 32 channels with each channel individually
programmable as an input or an output. To add a bit of interaction,
channels 0 to 15 are wired to channels 16 to 31 (0 to 16, 1 to 17,
etc.), and the state of each wire can be read back on both of the
channels connected to it. The outputs are modelled as NPN open
collector outputs with a pull-up resistor on the wire, so the state of
each wire (and the value read back from each channel connected to it)
will be logic level 1 unless either channel is configured as an output
at logic level 0.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251210124455.69131-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The main mutex in a comedi device can get held for quite a while when
processing comedi instructions, so for performance reasons, the "read",
"write", and "poll" file operations do not use it; they use the
`attach_lock` rwsemaphore to protect against the comedi device becoming
detached at an inopportune moment. As an alternative to using the
"read" and "write" operations, user-space can mmap the data buffer and
use the `COMEDI_BUFINFO` ioctl to manage data transfer through the
buffer. However, the "ioctl" file handler currently locks the main
mutex for all ioctl commands. Make the handling of the `COMEDI_BUFINFO`
an exception, using the `attach_lock` rwsemaphore during normal
operation. However, before it calls `do_become_nonbusy()` at the end of
acquisition, it does need to lock the main mutex, but it needs to unlock
the `attach_lock` rwsemaphore first to avoid deadlock. After locking
the main mutex, it needs to check that it is still in a suitable state
to become non-busy, because things may have changed while unlocked.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251205131332.16672-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix following sparse warning:
CHECK drivers/bus/fsl-mc/fsl-mc-bus.c
drivers/bus/fsl-mc/fsl-mc-bus.c:435:26: warning: symbol 'fsl_mc_bus_dpdbg_type' was not declared. Should it be static?
fsl_mc_bus_dpdbg_type is not used outside of fsl-mc-bus.c
Remove the EXPORT_SYMBOL and declare it static.
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/628c49881b3a1df76cfd2f8fd2aad976692a465a.1768566053.git.chleroy@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These are nearly identical to the respective driver callbacks. The only
difference is that .remove() returns void instead of int.
The objective is to get rid of users of struct device_driver callbacks
.probe() and .remove() to eventually remove these.
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260113145012.2379944-2-u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In ni_usb_init(), if ni_usb_setup_init() fails, the function returns
-EFAULT without freeing the allocated writes buffer, leading to a
memory leak.
Additionally, ni_usb_setup_init() returns 0 on failure, which causes
ni_usb_init() to return -EFAULT, an inappropriate error code for this
situation.
Fix the leak by freeing writes in the error path. Modify
ni_usb_setup_init() to return -EINVAL on failure and propagate this
error code in ni_usb_init().
Fixes: 4e127de14f ("staging: gpib: Add National Instruments USB GPIB driver")
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Suggested-by: Dave Penkler <dpenkler@gmail.com>
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Link: https://patch.msgid.link/20251230034546.929452-1-zilin@seu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If ni_usb_receive_bulk_msg() succeeds but without reading 16 bytes, then
the error code needs to be set. The current code returns success.
Fixes: 4e127de14f ("staging: gpib: Add National Instruments USB GPIB driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aSlMpbE4IrQuBGFS@stanley.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This accidentally returns 1 on error, but it should return negative
error codes.
Fixes: 9dde4559e9 ("staging: gpib: Add GPIB common core driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aSlMnaT1M104NJb2@stanley.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver is useful if at least one DRM driver registers an auxiliary device
for the ME interface. With the addition of Xe, this is no longer just i915.
Cc: Usyskin, Alexander <alexander.usyskin@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://patch.msgid.link/20260107182615.488194-5-Simon.Richter@hogyros.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While this is not a particularly useful configuration, the MEI code should
compile even when no drivers for a GPU containing a management engine are
built.
Cc: Usyskin, Alexander <alexander.usyskin@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://patch.msgid.link/20260107182615.488194-4-Simon.Richter@hogyros.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These are enumerated via an auxiliary bus, so there is no functional
dependency between these drivers, therefore allow compiling MEI as builtin
even when i915/xe are built as modules.
Cc: Usyskin, Alexander <alexander.usyskin@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://patch.msgid.link/20260107182615.488194-3-Simon.Richter@hogyros.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The xe driver supports dGPUs which can be plugged into non-x86 machines,
and exposes a MEI GSC interface, so this driver is no longer x86 only.
Cc: Usyskin, Alexander <alexander.usyskin@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Link: https://patch.msgid.link/20260107182615.488194-2-Simon.Richter@hogyros.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be emulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters an endless loop.
The problem is that with randomize_va_space == 0
get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not
just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used
by the stack vma.
arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and
in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
vm_unmapped_area() happily returns the high address > TASK_SIZE and then
get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)"
check.
handle_swbp() doesn't report this failure (probably it should) and silently
restarts the probed insn. Endless loop.
I think that the right fix should change the x86 get_unmapped_area() paths
to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if
CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case
because ->orig_ax = -1.
But we need a simple fix for -stable, so this patch just sets TS_COMPAT if
the probed task is 32-bit to make in_ia32_syscall() true.
Fixes: 1b028f784e ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()")
Reported-by: Paulo Andrade <pandrade@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com
Add kselftest cases for the revocable API.
The test consists of three parts:
- A kernel module (revocable_test.ko) that creates a debugfs interface
with `/provider` and `/consumer` files.
- A user-space C program (revocable_test) that uses the kselftest
harness to interact with the debugfs files.
- An orchestrating shell script (test-revocable.sh) that loads the
module, runs the C program, and unloads the module.
The test cases cover the following scenarios:
- Basic: Verifies that a consumer can successfully access the resource
provided via the provider.
- Revocation: Verifies that after the provider revokes the resource,
the consumer correctly receives a NULL pointer on a subsequent access.
- Try Access Macro: Same as "Revocation" but uses the
REVOCABLE_TRY_ACCESS_WITH() and REVOCABLE_TRY_ACCESS_SCOPED().
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260116080235.350305-4-tzungbi@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add Kunit test cases for the revocable API.
The test cases cover the following scenarios:
- Basic: Verifies that a consumer can successfully access the resource
provided via the provider.
- Revocation: Verifies that after the provider revokes the resource,
the consumer correctly receives a NULL pointer on a subsequent access.
- Try Access Macro: Same as "Revocation" but uses the
REVOCABLE_TRY_ACCESS_WITH() and REVOCABLE_TRY_ACCESS_SCOPED().
A way to run the test:
$ ./tools/testing/kunit/kunit.py run \
--kconfig_add CONFIG_REVOCABLE_KUNIT_TEST=y \
revocable_test
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260116080235.350305-3-tzungbi@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some resources can be removed asynchronously, for example, resources
provided by a hot-pluggable device like USB. When holding a reference
to such a resource, it's possible for the resource to be removed and
its memory freed, leading to use-after-free errors on subsequent access.
The "revocable" mechanism addresses this by establishing a weak reference
to a resource that might be freed at any time. It allows a resource
consumer to safely attempt to access the resource, guaranteeing that the
access is valid for the duration of its use, or it fails safely if the
resource has already been revoked.
The implementation uses a provider/consumer model built on Sleepable
RCU (SRCU) to guarantee safe memory access:
- A resource provider, such as a driver for a hot-pluggable device,
allocates a struct revocable_provider and initializes it with a pointer
to the resource.
- A resource consumer that wants to access the resource allocates a
struct revocable which acts as a handle containing a reference to the
provider.
- To access the resource, the consumer uses revocable_try_access().
This function enters an SRCU read-side critical section and returns
the pointer to the resource. If the provider has already freed the
resource, it returns NULL. After use, the consumer calls
revocable_withdraw_access() to exit the SRCU critical section. The
REVOCABLE_TRY_ACCESS_WITH() and REVOCABLE_TRY_ACCESS_SCOPED() are
convenient helpers for doing that.
- When the provider needs to remove the resource, it calls
revocable_provider_revoke(). This function sets the internal resource
pointer to NULL and then calls synchronize_srcu() to wait for all
current readers to finish before the resource can be completely torn
down.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260116080235.350305-2-tzungbi@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge fixes related to the energy model management for 6.19-rc6:
- Fix a memory leak in em_create_pd() error path (Malaya Kumar Rout)
- Fix stale description of the cost field in struct em_perf_state to
reflect the current code (Yaxiong Tian)
- Fix and revamp the energy model YNL specification added recently
along with the energy model netlink interface (Changwoo Min)
* pm-em:
PM: EM: Add dump to get-perf-domains in the EM YNL spec
PM: EM: Change cpus' type from string to u64 array in the EM YNL spec
PM: EM: Rename em.yaml to dev-energymodel.yaml
PM: EM: Fix yamllint warnings in the EM YNL spec
PM: EM: Fix memory leak in em_create_pd() error path
PM: EM: Fix incorrect description of the cost field in struct em_perf_state
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log. Since commit ad67b74d24 ("printk: hash
addresses printed with %p") the regular %p has been improved to avoid
this issue. Furthermore, restricted pointers ("%pK") were never meant
to be used through printk(). They can still unintentionally leak raw
pointers or acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through
seq_file, for which its usage is safe.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Acked-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260107-restricted-pointers-binder-v1-1-181018bf3812@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX-License-Identifier lines to some old kernel
files.
Signed-off-by: Tim Bird <tim.bird@sony.com>
Acked-by: Karim Yaghmour <karim.yaghmour@opersys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To ensure correct handling of endianness in the QMI subsystem, the
QMI_DATA_LEN field used in host-side drivers remains in CPU-native byte
order. Remove unnecessary endianness conversions, considering that
QMI_DATA_LEN is always of type `u32` on the host. On the QMI wire
interface, however, its representation is variable and may use either 1 or
2 bytes.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251119104008.3505152-4-alexander.wilhelm@westermo.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Extend the QMI byte encoding and decoding logic to support multiple basic
data type sizes (u8, u16, u32, u64) using differnet macros for each type.
Ensure correct handling of data sizes and proper byte order conversion on
big-endian platforms by consistently applying these macros during encoding
and decoding of basic elements.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251119104008.3505152-3-alexander.wilhelm@westermo.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Extend handling of QMI basic element types to also capture error codes.
This is required for big-endian platforms where a simple memcpy is not
sufficient and exact data type knowledge is necessary.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Link: https://lore.kernel.org/r/20251119104008.3505152-2-alexander.wilhelm@westermo.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add reserved memory region for audio PD dynamic loading and remote
heap requirement. Also add LPASS and ADSP_HEAP VMIDs.
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251117070819.492-1-jianping.li@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Thinkpad T14s embeds a transparent 4lanes DP->HDMI transceiver
connected to the third QMP Combo PHY 4 lanes.
Add all the data routing, disable mode switching and specify the
QMP Combo PHY should be in DP-Only mode to route the 4 lanes to
the underlying DP phy.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20251119-topic-x1e80100-hdmi-v7-3-2bee0e66cc1b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus.
The upper address space is used to support more than 32GB of memory.
This fixes issues when DMA buffers are allocated outside the 36-bit range.
Fixes: af16b00578 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251127212943.24480-1-jonathan@marek.ca
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
There is currently an inconsistency between C and Rust, which is that
when Rust requires cfg(CONFIG_COMPAT) on compat_ioctl when using the
compat_ptr_ioctl symbol because '#define compat_ptr_ioctl NULL' does not
get translated to anything by bindgen.
But it's not *just* a matter of translating the '#define' into Rust when
CONFIG_COMPAT=n. This is because when CONFIG_COMPAT=y, the type of
compat_ptr_ioctl is a non-nullable function pointer, and to seamlessly
use it regardless of the config, we need a nullable function pointer.
I think it's important to do something about this; I've seen the mistake
of accidentally forgetting '#[cfg(CONFIG_COMPAT)]' when compat_ptr_ioctl
is used multiple times now.
This explicitly declares 'bindings::compat_ptr_ioctl' as an Option that
is always defined but might be None. This matches C, but isn't ideal:
it modifies the bindings crate. But I'm not sure if there's a better way
to do it. If we just redefine in kernel/, then people may still use the
one in bindings::, since that is where you would normally find it. I am
open to suggestions.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260105-redefine-compat_ptr_ioctl-v1-1-25edb3d91acc@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The video-demo adapter also works on the Lion SoM when running
on a Haikou baseboard, so add an overlay for it.
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-6-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The pwm1 is exposed as BLT_CTRL signal on the MISC I/O pin header of the
haikou baseboard and the Qseven standard specifies this signal is only
for PWM (either for a panel backlight or generic PWM).
So enable it in the Haikou baseboard for Lion.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-5-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
i2c@0 on i2cmux2 does already have a phandle i2c_lvds_blc defined.
Use this one instead of replicating the hierarchy again, as this might
result in strange errors if the lion dtsi is changed at some point
in the future.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://patch.msgid.link/20260114230707.4175162-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
