linux.git/drivers/misc/fastrpc.c, branch v7.3-rc2

Merge drm/drm-fixes into drm-misc-fixes

2026-09-01T07:38:51+00:00

Let's start the 7.3 drm-misc-fixes cycle.

Signed-off-by: Maxime Ripard

Merge tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2026-08-25T16:38:50+00:00

Pull char/misc/IIO/etc driver updates from Greg KH:
 "Here is the big set of char, misc, iio, counter, fpga, and other small
  driver subsystems for 7.3-rc1.

  Overall, due to some driver removals we only added a bit more code
  than removed, which was a nice change. Highlights in this merge
  request are:

   - Loads of IIO driver updates and additions

   - binder driver updates (more on that below...)

   - Removal of the SGI XP and GRU drivers as they are not used anymore
     and turn out to be pretty insecure overall

   - Removal of the obsolete ibmasm driver as it's not being used
     anymore

   - Coresight driver updates and additions

   - Mei driver udpates

   - Counter driver updates

   - FPGA driver updates

   - ICC driver updates

   - lots and lots of other tiny driver updates to resolve reported
     issues

  All of these have been in linux-next for a while"

* tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits)
  iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
  iio: adc: pac1921: fix wrong channel used in trigger handler read
  iio: light: gp2ap002: re-enable irq if runtime suspend fails
  iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
  iio: light: apds9306: fix PM reference leak in apds9306_read_data()
  iio: gyro: mpu3050: fix sign of raw angular velocity readings
  iio: srf04: fix pm_runtime handling on probe error path
  iio: adc: ad4080: configure backend data size
  iio: adc: adi-axi-adc: add data size support for AD408X backend
  iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable
  iio: dac: ad5446: fix OF module device table
  iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask
  iio: light: opt4001: Reject integration times with a non-zero seconds part
  iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem()
  iio: light: opt4001: Fix power down clearing bits of the wrong register
  iio: light: opt4060: Fix incorrect register name in threshold read error message
  iio: light: opt4060: Fix pointer type passed to div_u64_rem()
  iio: light: opt4060: Reject integration times with a non-zero seconds part
  iio: light: ltrf216a: fix runtime PM reference leak in error path
  iio: pressure: dps310: fix NULL pointer dereference on ACPI probe
  ...

misc: fastrpc: don't publish fd before copy_to_user() succeeds

2026-08-24T11:58:25+00:00

fastrpc_ioctl_alloc_dmabuf() calls dma_buf_fd() which installs the fd
into the caller's fd table before copy_to_user() copies the fd number
back to userspace.  If copy_to_user() fails, the fd is already visible
to other threads in the same process but the ioctl returns -EFAULT.
The existing comment in the code even acknowledges the problem:

  "The usercopy failed, but we can't do much about it, as dma_buf_fd()
   already called fd_install()..."

Now that dma_buf_fd_install() is available (introduced to fix the same
issue in dma-heap), apply the same pattern here: reserve the fd with
get_unused_fd_flags(), attempt copy_to_user(), and only on success call
dma_buf_fd_install() to publish it atomically with the tracepoint.  On
copy_to_user() failure, put_unused_fd() and dma_buf_put() cleanly
unwind without any user-visible side effects.

Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter")
Cc: stable@vger.kernel.org
Acked-by: Christian König 
Acked-by: Sumit Semwal 
Signed-off-by: Baineng Shou 
Link: https://lore.kernel.org/r/20260817050457.1005285-3-shoubaineng@gmail.com
Signed-off-by: Christian König

misc: Unify style of of_device_id arrays

2026-07-31T12:20:50+00:00

Update the various of_device_id arrays to conform to the most used and
generally recommended coding style. That is:

 - No comma after the list terminator;
 - A comma after an initializer if (and only if) the closing } is not
   directly following;
 - No explicit zeros in the list terminator;
 - A space after an opening { and before a closing }, a single space in
   the list terminator;

Adapt the few offenders accordingly.

Signed-off-by: Uwe Kleine-König (The Capable Hub) 
Reviewed-by: Romain Gantois 
Link: https://patch.msgid.link/fbf51b8f413c516977e2c8a81896221795df77e4.1784299069.git.u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Drop unhandled DSP PD exit notification

2026-07-31T12:15:53+00:00

Newer DSP firmware implements a PD (Protection Domain) notification
framework that sends PD state notifications upon request. The PD exit
notification is unconditionally sent by the DSP with a fixed sentinel
0xABCDABCD in the context field.

fastrpc_rpmsg_callback() treats every inbound message as an invoke
response, so the sentinel is masked and shifted like any real response
((0xABCDABCD & 0xFF0) >> 4 == 188) and looked up in the channel's
context idr.

This is not merely cosmetic. In the common case idr slot 188 is empty,
the lookup fails, and the driver only logs a spurious "No context ID
matches response" error on every teardown. But the context idr is shared
by every protection domain and the listener thread on the channel and is
filled cyclically over [1, FASTRPC_CTX_MAX]. If slot 188 holds a live
context when the sentinel arrives, the sentinel's return value is written
into that unrelated in-flight invocation and it is completed early.

Since neither the fastrpc library nor the driver supports the DSP PD
notification framework, it is safe to drop the PD exit notification
before it is ever turned into a context lookup. This removes both the
log spam and the mis-completion race. A genuine response can never be
masked: a real context is (idr_index << 4) | pd (at most 0xFF3) and
can never equal the sentinel.

Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Ekansh Gupta 
Signed-off-by: Shawn Guo 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Add polling mode support for fastRPC driver

2026-07-31T12:15:53+00:00

For any remote call to DSP, after sending an invocation message,
the fastRPC driver waits for a glink response, during which the CPU
can enter low power modes. This adds latency to the fastRPC call
due to CPU wakeup and scheduling overhead. Add polling mode support
where the fastRPC driver polls a shared memory location for
completion after sending the invocation, avoiding CPU wakeup and
scheduling latency and reducing fastRPC overhead. If the poll times
out, the call falls back to the normal interrupt/glink-based
completion path.

Poll mode is only applied to dynamic modules running in a user PD
(handle > FASTRPC_MAX_STATIC_HANDLE), since static/root-PD handles
are not expected to benefit from, or require, this optimization.
Support is advertised per SoC via fastrpc_soc_data, with a closed
exception list for older platforms whose DSP firmware is known to
support polling but which otherwise use the default soc_data.

Poll mode can be enabled by userspace via the FASTRPC_IOCTL_SET_OPTION
ioctl with the FASTRPC_POLL_MODE request id.

Since context IDs (ctxid) are allocated from a fixed-size, per-channel
cyclic IDR shared by all processes on a DSP, a context ID can be
recycled for a new request soon after it is freed. In poll mode the
context can be considered complete (and released) as soon as the poll
memory is updated, while the corresponding glink COMPLETE response
from the DSP may still be in flight. If that response arrives after
the ctxid has been reused, it would otherwise match the new context
and incorrectly signal completion for it while the DSP may still be
operating on the new context's buffers. To prevent this, embed a
monotonically increasing per-channel sequence number in the unused
upper bits of the ctxid/message context and validate it in the
rpmsg callback, dropping any response whose sequence number does not
match the current owner of that ctxid slot.

Signed-off-by: Ekansh Gupta 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-8-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Expand context ID mask for DSP polling mode support

2026-07-31T12:15:53+00:00

Current FastRPC context uses a 12-bit mask:
  [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)

This works for normal calls but fails for DSP polling mode.
Polling mode expects a 16-bit layout:
  [15:8] = context ID (8 bits)
  [7:5]  = reserved
  [4]    = async mode bit
  [3:0]  = PD type (4 bits)

If async bit (bit 4) is set, DSP disables polling. With current
mask, odd IDs can set this bit, causing DSP to skip poll updates.

Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
byte and lower byte is left for DSP flags and PD type.

Reserved bits remain unused. This change is compatible with
polling mode and does not break non-polling behavior.

Bit layout:
  [15:8] = CCCCCCCC (context ID)
  [7:5]  = xxx (reserved)
  [4]    = A (async mode)
  [3:0]  = PPPP (PD type)

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-7-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Replace hardcoded ctxid mask with GENMASK

2026-07-31T12:15:53+00:00

Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to
improve readability and follow kernel bitfield conventions. Use
FIELD_PREP and FIELD_GET instead of manual shifts for setting and
extracting ctxid values.

Reviewed-by: Konrad Dybcio 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-6-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Move fdlist to invoke context structure

2026-07-31T12:15:52+00:00

The fdlist is currently part of the meta buffer which is set during
fastrpc_get_args(), this fdlist is getting recalculated during
fastrpc_put_args().

Move fdlist to the invoke context structure to improve maintainability
and reduce redundancy. This centralizes its handling and simplifies
meta buffer preparation and reading logic.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-5-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Allow fastrpc_buf_free() to accept NULL

2026-07-31T12:15:52+00:00

Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing
callers to avoid open-coded NULL checks.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Jianping Li 
Signed-off-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20260729094352.111065-3-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman