The write_iter callback consumes data from the supplied iov_iter and
wraps it as an IovIterSource.
Its Safety docs required a valid iov_iter for writing, but the
implementation and the IovIterSource contract require one that is valid
for reading. Update the docs to match that direction.
Assisted-by: Codex:GPT-5
Signed-off-by: Yilin Chen <1479826151@qq.com>
Link: https://patch.msgid.link/tencent_8CD671E0F35223030143524D045F3BCAD506@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most processes do not use Rust Binder with epoll, so avoid paying the
synchronize_rcu() cost in drop for those that don't need it. For those
that do, we also manage to replace synchronize_rcu() with kfree_rcu(),
though we introduce an extra allocation.
In case the last ref to an Arc<Thread> is dropped outside of
deferred_release(), this also ensures that synchronize_rcu() is not
called in destructor of Arc<Thread> in other places. Theoretically that
could lead to jank by making other syscalls slow, which would be
problematic.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260707-upgrade-poll-v6-2-4b8fae7bf1d9@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rust Binder currently uses PollCondVar, but it calls synchronize_rcu()
in the destructor, which we would like to avoid. Add a variation of
PollCondVar that kfree_rcu() instead.
One could avoid the `rcu` field and allocate the rcu_head on drop using
a fallback to synchronize_rcu() on ENOMEM. However, I'd prefer to avoid
the potential for synchronize_rcu(), and Binder will only use this for a
small fraction of processes, so even if it changes which kmalloc bucket
it falls into, the extra memory is not a problem.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260707-upgrade-poll-v6-1-4b8fae7bf1d9@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Android Binder driver supports a netlink API that reports
transaction *failures* to a userspace daemon. This allows devices to
monitor processes with many failed transactions so that it can e.g. kill
misbehaving apps.
One very important thing that this monitors is when many oneway messages
are sent to a frozen process, so there is special handling to ensure
this scenario is surfaced over netlink.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260707-binder-netlink-v7-3-42b40e4b1ac8@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This implements a safe and relatively simple API over the netlink API,
that allows you to add different attributes to a netlink message and
broadcast it. As the first user of this API only makes use of broadcast,
only broadcast messages are supported here.
This API is intended to be safe and to be easy to use in *generated*
code. This is because netlink is generally used with yaml files that
describe the underlying API, and the python generator outputs C code
(or, soon, Rust code) that lets you use the API more easily. So for
example, if there is a string field, the code generator will output a
method that internall calls `put_string()` with the right attr type.
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260707-binder-netlink-v7-2-42b40e4b1ac8@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds dynamic debug logs for:
- Releasing active transactions during thread stack unwinding.
- Discarded transaction error codes when a thread exits.
- Undelivered transaction acknowledgments (TRANSACTION_COMPLETE)
upon thread exit.
- Undelivered process death and freeze notifications when processes
exit or die.
- Undelivered transactions canceled due to target process death.
We now store the process PID in `ThreadError`, `DeliverCode`, and
`FreezeMessage` to ensure the correct PID is logged on cancellation.
This is necessary because `cancel()` runs from background `kworkers`,
which would otherwise print the wrong PID.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Jahnavi MN <jahnavimn@google.com>
Link: https://patch.msgid.link/20260716-rust_binder_debug_mask-v4-7-3d7436c2d2f2@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement a dynamic debug logging mask (`debug_mask`) for the
`rust_binder` module to allow dynamic runtime configuration of log
levels. This enables parity with the legacy C driver's debug mask.
Since the Rust `module!` macro in the current kernel build does not
yet support declaring module parameters directly in Rust, we define
the `debug_mask` variable in Rust as an `Atomic<u32>` exported via
FFI using `#[no_mangle]`, and link to it as `extern` in a C companion
file to expose it to the kernel runtime.
To verify the setup, instrument process lifecycle events (open, flush,
and release) in `process.rs` under the new `BINDER_DEBUG_OPEN_CLOSE`
logging mask. These entry-point events are chosen for initial validation
because they represent the start of the Binder lifecycle and occur
at low frequency, allowing simple runtime verification of the dynamic
toggle without log noise.
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Jahnavi MN <jahnavimn@google.com>
Link: https://patch.msgid.link/20260716-rust_binder_debug_mask-v4-1-3d7436c2d2f2@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the mix between __le32 and integer by casting
the MEI_LB2_CMD constant as __le32 while using it.
Fixes sparse waring:
drivers/misc/mei/mei_lb.c:284:32: sparse: sparse: restricted __le32 degrades to integer
drivers/misc/mei/mei_lb.c:330:40: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] command_id @@ got int @@
drivers/misc/mei/mei_lb.c:330:40: sparse: expected restricted __le32 [usertype] command_id
drivers/misc/mei/mei_lb.c:330:40: sparse: got int
Fixes: 773a43b862 ("mei: lb: add late binding version 2")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605091533.79Zcv3CX-lkp@intel.com/
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://patch.msgid.link/20260709-fix_type_le-v3-1-478761151e05@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Unfortunately the ethaddr value in U-Boot environment might be enclosed
in single/double quotes or be something completely different. This can
make it different than MAC_ADDR_STR_LEN, which results in EINVAL
returned by ethaddr post process. Move the check for length earlier,
to skip post processing, so nvmem could still present ethaddr value as
a string if the value doesn't match MAC_ADDR_STR_LEN.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260530205333.117458-15-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is already an 'if NVMEM' condition wrapping NVMEM_RCAR_EFUSE,
making the 'depends on' statement a duplicate dependency (dead code).
I propose leaving the outer 'if NVMEM...endif' and removing the
individual 'depends on' statement.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260530205333.117458-14-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for SMC eFUSE on AN7581 SoC. The SoC have 2 set of 2048 bits of
eFUSE that are used to read calibration value for PCIe, Thermal, USB and
other specific info of the SoC like revision and HW device present.
eFuse value are taken by sending SMC command. ATF is responsible of
validaing the data and rejecting reading protected data (like Private
Key). In such case the SMC command will return non-zero value on a0
register.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260530205333.117458-12-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add Airoha SMC eFuses schema to document new Airoha SoC AN7581/AN7583
way of accessing the 2 eFuse bank via the SMC command.
Each eFuse bank expose 64 eFuse cells of 32 bit used to give information
on HW Revision, PHY Calibration, Device Model, Private Key and
all kind of other info specific to the SoC or the running system.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260530205333.117458-11-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case the nvmem DT node contains "wp-gpios" DT property, the device
currently defaults to read-write and the force_ro sysfs attribute reads
0. Switch to the default read-only, which is both safer, and aligned
with eMMC HW BOOT partition force_ro sysfs attribute behavior, which
also defaults to read-only.
The adjustment of nvmem->read_only value to read-only in case wp-gpios
DT property is present must be done only after the device_add() got
called because device_add() does internally call nvmem_bin_attr_get_umode(),
which configures the permissions of 'nvmem' bin attr based on the value
of nvmem->read_only that is only parsed from DT property 'read-only',
without any adjustment. This way, if DT property 'read-only' is present,
the 'nvmem' attribute is always read-only. Otherwise, if the device is
writeable, then 'nvmem' attribute is writeable, and nvmem->read_only
defaults to read-only, but can be switched to read-write at runtime via
the 'force_ro' attribute.
The updated behavior can be tested as follows:
Current content:
"
$ cat /sys/bus/nvmem/devices/logging7/force_ro
1
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 66 6f 6f 0a ff ff ff ff
"
Write into default-read-only device:
"
$ echo bar > /sys/bus/nvmem/devices/logging7/nvmem
bash: echo: write error: Operation not permitted
$ cat /sys/bus/nvmem/devices/logging7/force_ro
1
"
Unlock and write into device:
"
$ echo 0 > /sys/bus/nvmem/devices/logging7/force_ro
$ cat /sys/bus/nvmem/devices/logging7/force_ro
0
$ echo bar > /sys/bus/nvmem/devices/logging7/nvmem
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 62 61 72 0a ff ff ff ff
"
Relock and write into device, fails because device is read-only again:
"
$ echo 1 > /sys/bus/nvmem/devices/logging7/force_ro
$ echo baz > /sys/bus/nvmem/devices/logging7/nvmem
bash: echo: write error: Operation not permitted
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 62 61 72 0a ff ff ff ff
"
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260530205333.117458-4-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device before it is
fully set up.
For safety, the interrupt handler checks the dev->attached flag to
ensure the device is fully set up, but it currently does that after
dereferencing the dev->read_dev pointer which may be NULL if
dev->attached is false. Move the check to avoid the possible null
pointer dereference.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-12-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device, after setting
device registers to disable interrupt generation. The interrupt handler
should not be called prematurely unless the user-configured I/O port
base address and/or IRQ number are incorrect or the hardware is bad.
For safety, check the dev->attached flag in the interrupt handler
pcmuio_interrupt() to ensure the device has been fully set up, avoiding
a possible null pointer dereference of dev->subdevices by
pcmuio_handle_asic_interrupt().
Also make use of the IRQ_HANDLED(x) macro for the normal return path of
the interrupt handler.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-11-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device before it is
fully set up.
For safety, the interrupt handler checks the dev->attached flag to
ensure the device is fully set up, but it currently does that after
dereferencing the dev->read_dev pointer which may be NULL if
dev->attached is false. Move the check to avoid the possible null
pointer dereference.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-9-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device before it is
fully set up.
For safety, the interrupt handler checks the dev->attached flag to
ensure the device is fully set up, but it currently does that after
dereferencing the devpriv->dma pointer which may be NULL if
dev->attached is false. Move the dereference of the devpriv->dma
pointer after dev->attached has been checked to avoid the possible null
pointer dereference.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-8-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device before it is
fully set up.
For safety, the interrupt handler checks the dev->attached flag to
ensure the device is fully set up, but it currently does that after
dereferencing various pointers which may be NULL if dev->attached is
false. Move the check to avoid the possible null pointer dereferences.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-5-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver requests an interrupt handler for the device, after setting
device registers to disable interrupt generation. The interrupt handler
should not be called prematurely unless the user-configured I/O port
base address and/or IRQ number are incorrect or the hardware is bad.
For safety, the interrupt handler checks the dev->attached flag to
ensure the device is fully set up, but it currently does that after
dereferencing dev->read_subdev, which may be NULL if dev->attached is
false. Move the check to avoid the possible null pointer dereference.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260618102949.26607-4-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
