Three master drivers (dw-i3c-master, i3c-master-cdns, svc-i3c-master)
each carry an essentially identical Hot-Join handler: a struct
work_struct embedded in their private state, a work function that just
calls i3c_master_do_daa() on the embedded i3c_master_controller, plus
matching INIT_WORK()/cancel_work_sync() boilerplate in probe/remove (and
shutdown for dw-i3c). The IBI/ISR paths then queue that work onto
master->wq, which already lives in the core.
Move this pattern into the I3C core:
- Add struct work_struct hj_work to struct i3c_master_controller and
initialise it in i3c_master_register() with a core-provided handler
i3c_master_hj_work_fn() that performs i3c_master_do_daa().
- Cancel the work in i3c_master_unregister() so all controllers get
correct teardown ordering against the workqueue for free.
- Export i3c_master_queue_hotjoin() as the single entry point drivers
call from their Hot-Join IBI handler.
Convert the three existing users to the new API: drop their private
hj_work fields, work functions, INIT_WORK() and cancel_work_sync()
calls, and replace the queue_work(master->wq, &drv->hj_work) call sites
with i3c_master_queue_hotjoin(&drv->base). The dw-i3c shutdown path
still needs to flush pending Hot-Join work before tearing down the
hardware, so it is updated to cancel master->base.hj_work directly.
No functional change intended: the work is still queued on the same
master->wq, runs the same i3c_master_do_daa(), and is cancelled at
controller teardown. Future Hot-Join improvements now only need to
be made in one place.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260608054312.10604-4-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
i3c_set_hotjoin() dispatches the controller's enable_hotjoin() or
disable_hotjoin() op and updates master->hotjoin under
i3c_bus_normaluse_lock(). That lock is a read-side acquisition of
bus->lock (down_read()), so it does not exclude concurrent callers.
The hotjoin sysfs attribute can be opened multiple times, and writes
through different opens are not serialized. Two concurrent writers
to "hotjoin" can therefore race in i3c_set_hotjoin(), with the
controller op and the master->hotjoin store from one call interleaving
with the other. The hardware enable/disable state and the value reported
by hotjoin_show() can end up out of sync.
Take i3c_bus_maintenance_lock() instead. Toggling Hot Join enable
changes bus state and is conceptually a maintenance operation, so the
write-side acquisition of bus->lock is the appropriate lock and
serializes concurrent callers against each other and against other
maintenance operations.
Fixes: 317bacf960 ("i3c: master: add enable(disable) hot join in sys entry")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260608054312.10604-3-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The I3C master workqueue (master->wq) is used to defer work that needs
thread context and the bus maintenance lock, most notably Hot Join
processing (which calls i3c_master_do_daa() to assign dynamic addresses
to newly joined devices).
Currently the workqueue keeps running across system suspend, which can
race with the suspend path:
- do_daa() may execute after the controller has been suspended,
issuing bus transactions on a powered-down or otherwise unusable
controller.
- New I3C devices can be enumerated and added to the bus mid-suspend,
registering driver model objects at a point where the I3C subsystem
and its consumers are not prepared to handle them.
Mark the workqueue WQ_FREEZABLE so its workers are frozen for the
duration of system suspend/hibernate and resumed afterwards. This
naturally defers any pending or newly queued Hot Join work until the
system (and the controller) is fully resumed, closing both races
without adding explicit suspend/resume synchronization in the master
drivers.
Update the kerneldoc for struct i3c_master_controller::wq to reflect
that the workqueue is freezable.
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260608054312.10604-2-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Make sure that these calls return EINVAL.
Test coverage for security/landlock is 91.6% of 2347 lines according to
LLVM 22.
Assisted-by: GitHub-Copilot:claude-opus-4.8
Signed-off-by: Tingmao Wang <m@maowtm.org>
Link: https://patch.msgid.link/9401d5c6468675863d944d6c26640d97db1a1f31.1781228815.git.m@maowtm.org
[mic: Add test coverage]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Tests that:
- Quiet flag works on network rules
- Quiet flag applied to unrelated ports has no effect
- Denied access not in quiet_access_net is still logged
This is not as thorough as the fs tests, but given the shared logic it
should be sufficient. There is also no "optional" access for network
rules.
Signed-off-by: Tingmao Wang <m@maowtm.org>
Assisted-by: GitHub-Copilot:claude-opus-4.7 copilot-review
Link: https://patch.msgid.link/364fbd08081318d64bc23049d3a7721f0a3a3624.1781228815.git.m@maowtm.org
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Test various interactions of the quiet flag with filesystem rules:
- Non-optional access (tested with open and rename).
- Optional access (tested with truncate and ioctl).
- Behaviour around mounts matches with normal Landlock rules.
- Behaviour around disconnected directories matches with normal Landlock
rules (test expected behaviour of 9a868cdbe66a ("landlock: Fix
handling of disconnected directories") applied to the collected quiet
flag).
- Multiple layers works as expected.
Assisted-by: GitHub-Copilot:claude-opus-4.6 copilot-review
Signed-off-by: Tingmao Wang <m@maowtm.org>
Link: https://patch.msgid.link/0f304507dd3ebccc753e1580456bdfc909012357.1781228815.git.m@maowtm.org
[mic: Fix comment formatting]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Adds ability to set which access bits to quiet via LL_*_QUIET_ACCESS
(FS, NET or SCOPED), and attach quiet flags to individual objects via
LL_*_QUIET for FS and NET.
Assisted-by: GitHub-Copilot:claude-opus-4.8 copilot-reviepickw
Signed-off-by: Tingmao Wang <m@maowtm.org>
Link: https://patch.msgid.link/59b94997565032bc9870044f021214a2ed6df213.1781228815.git.m@maowtm.org
[mic: Fix comment formatting]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
The quietness behaviour is as documented in the previous patch.
For optional accesses, since the existing deny_masks can only store
2x4bit of layer index, with no way to represent "no layer", we need to
either expand it or have another field to correctly handle quieting of
those. This commit uses the latter approach - we add another field to
store which optional access (of the 2) are covered by quiet rules in
their respective layers as stored in deny_masks.
Assisted-by: GitHub-Copilot:claude-opus-4.8 copilot-review
Signed-off-by: Tingmao Wang <m@maowtm.org>
Link: https://patch.msgid.link/2510a357a94183683eefc49917dcb2240d67be96.1781228815.git.m@maowtm.org
[mic: Cosmetic fixes]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Adds the UAPI for the quiet flags feature (but not the implementation
yet).
Even though currently LANDLOCK_ADD_RULE_QUIET only affects audit
logging, in the future this can also be used as part of a supervisor
mechanism, where it will also suppress denial notifications on a
per-object basis. Thus the name is deliberately generic, as opposed to
e.g. LANDLOCK_ADD_RULE_LOG_QUIET.
According to pahole, even after adding the struct access_masks
quiet_masks in struct landlock_hierarchy, the u32 log_* bitfield still
only has a size of 2 bytes, so there's minimal wasted space.
Assisted-by: GitHub-Copilot:claude-opus-4.8
Signed-off-by: Tingmao Wang <m@maowtm.org>
[mic: Update date, fix comment formatting]
Link: https://patch.msgid.link/031184748a8e74c0bb02f1fa13d7a3f10918c627.1781228815.git.m@maowtm.org
Signed-off-by: Mickaël Salaün <mic@digikod.net>
To avoid unnecessarily increasing the size of struct landlock_layer, we
make the layer level a u8 and use the space to store the flags struct.
struct layer_access_masks is renamed to struct layer_masks, and a new
field is added to track whether a quiet flag rule is seen for each
layer. Through use of bitfields, this does not increase the size of the
struct.
Cc: Justin Suess <utilityemal77@gmail.com>
Assisted-by: GitHub-Copilot:claude-opus-4.8 copilot-review
Signed-off-by: Tingmao Wang <m@maowtm.org>
Co-developed-by: Justin Suess <utilityemal77@gmail.com>
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
Tested-by: Justin Suess <utilityemal77@gmail.com>
Link: https://patch.msgid.link/be3fec3927bc9faaacd4ce0e7f0d1ff5474e2210.1781228815.git.m@maowtm.org
[mic: Fix comment formatting]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Add example of UDP usage, without detailing the two access right.
Slightly change the example used in code blocks: build a ruleset for a
DNS client, so that it uses both TCP and UDP.
Test coverage for security/landlock is 91.3% of 2245 lines according to
LLVM 22.
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
Link: https://patch.msgid.link/20260611162107.49278-7-matthieu@buffet.re
[mic: Fix doc formatting, update audit doc, add test coverage]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Add basic support for the k230 SoC, which has been sitting in linux-next
for a long time waiting for the clock driver to reach an acceptable
state.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
This patch describes the clock controller integrated in K230 SoC
and replace dummy clocks with the real ones for UARTs.
For k230-canmv and k230-evb, they provide an additional external
pulse input through a pin to serve as clock source.
Co-developed-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Add the reset controller node for the K230 SoC. Also add the reset
properties for all UART nodes.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
"b" is ratified (Apr/2024) much later than its components zba/zbb/zbs
(Jun/2021). With "b" added into riscv/extensions.yaml, a dependency
checking rule is now enforced, which requires that when zba, zbb, and zbs
are all specified, "b" must be added as well. Failing to do this will
cause dtbs_check schema check warnings.
According to uabi.rst, as a single-letter extension, "b" should be added
after "c" in canonical order.
Update k230.dtsi to conform to this rule. Also synchronize "riscv,isa"
with "riscv,isa-extensions".
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Correct the errors in the spacing format, and move the aliases from
the SoC's dtsi to the board's dts, since it's more standard.
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
K230 SoC [1].
Some key consideration:
- Only place BigCore which is 1.6GHz RV64GCBV
The existence of cache coherence between the two cores remains unknown
since they have dedicated L2 caches. And the factory SDK uses it for
other OS by default. I don't know whether the two CPUs on K230 SoC
can be used in one system. So only place BigCore here.
Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
CPU1, the CSR.MHARTID of this core is 0.
- Support for "zba" "zbb" "zbc" "zbs" are tested by hand
The user manual of C908 from T-Head does not document it specifically.
It just said it supports B extension V1.0. [2]
I have tested it by using this [3] which attempts to execute "add.uw",
"andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
"clmulr" and "bclr" will trap.
- Support for "zicbom" is tested by hand
Have tested with some out-of-tree drivers from [4] that need DMA and they
do not come to the dts currently.
- Support for "zicboz" is tested by hand
Have tested with my own bare mental M-Mode program [5] which tries to use
zicboz to clear a 64B aligned block and got output[6] shows it supports
zicboz.
- Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]
L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L2: 256KB, PIPT 16-way set-associative, 64B Cacheline
The numbers of cache sets are calculated from these parameters.
- MMU only supports Sv39
The T-Head docs [2] say the C908 core can be configured to support Sv48 and
Sv39 or only Sv39. On K230, I tried to write "riscv,sv48" on mmu-type in
dts and boot the mainline kernel. However, it failed during the kernel
probe and fell back to Sv39. I also tested it on M-Mode software, writing
Sv48 to satp.mode will not trap but will leave the CSR unchanged. While
writing Sv39, it will take effect. It shows that this CPU does not support
Sv48.
- Svpbmt and T-Head MAEE both supported
T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
attributes and is controlled by BIT(21) on CSR.MXSTATUS. The Svpbmt is used
here for mainline kernel support for K230. If the kernel wants to use
Svpbmt, the M-Mode software should unset BIT(21) of CSR.MXSTATUS before
entering the S-Mode kernel. Otherwise, the kernel will not boot, as 0 on
T-Head MAEE is NonCachable Memory. Once the kernel switches from bare metal
to Sv39, It will lose dirty cache line modifications that haven't been
written back to the memory.
[1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
[2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
[3] https://github.com/cyyself/rvb_test
[4] https://github.com/cyyself/linux/tree/k230-mainline
[5] 32657d807d
[6] https://gist.github.com/cyyself/aa98b07b8c77bb1d53b5a4c5e67a37cf
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Since K230 was released, K210 is no longer the only SoC in the Kendryte
series, so remove the K210 string from the description. Also, add two
boards based on k230 to compatible strings to allow them to be used in the
dt.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Although we've covered the races around the timer object assignment
and release for timer instances, there are still races at starting or
stopping the timer instance. They refer to timeri->timer without
lock, hence they can still trigger UAFs.
For addressing it, this patch changes the existing slave_active_lock
spinlock to timeri_lock rwlock. It's a global rwlock applied as
read-lock when snd_timer_start() & co are called as well as
snd_timeri_timer_get() is called. In turn, the places where
timeri->timer is assigned or released are covered by the write-lock.
The patch replaces spinlock_irqsave with spinlock in a couple of
spaces because they are now already protected by timeri_lock, too.
Reported-by: Kyle Zeng <kylebot@openai.com>
Link: https://patch.msgid.link/20260614090714.773216-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_power_ref_and_wait() takes the power refcount and doesn't leave it
no matter whether it returns an error or not. However, the majority
of callers don't expect but just returns without unreferencing in the
caller side upon errors.
For addressing the potential refcount unbalance, rather correct the
behavior of snd_power_ref_wait() to unreference upon returning an
error.
Note that the problem above is likely negligible; the function returns
an error only when the sound card is being shutdown, hence it doesn't
matter about the power refcount any longer at such a state.
Fixes: e94fdbd7b2 ("ALSA: control: Track in-flight control read/write/tlv accesses")
Reported-by: WenTao Liang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/20260612022121.14329-1-vulab@iscas.ac.cn
Link: https://patch.msgid.link/20260614090507.772540-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The DMA transfer ring is currently limited to 16 entries, despite the
MIPI I3C HCI supporting up to 32 devices. When the ring lacks space for a
new transfer list, the driver returns -EBUSY, which can be unexpected
for clients.
Increase the DMA transfer ring size to the maximum supported value of
255 entries. This effectively eliminates ring-space exhaustion in
practice and avoids the complexity of adding secondary queuing
mechanisms.
Even at the maximum size, the memory overhead remains small
(approximately 24 bytes per entry by default).
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-18-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
dma_alloc_coherent() allocates memory in whole pages, which can waste
space when command and response queues are allocated separately.
Allocate the DMA command and response queues from a single coherent
allocation instead, while preserving the required 4-byte alignment.
This reduces memory overhead without changing behavior.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-17-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Transfer timeouts are currently measured from the point where a transfer
list is queued to the controller. This can cause transfers to time out
before they have actually started, if earlier queued transfers consume
the timeout interval.
Fix this by recording when a transfer reaches the head of the queue and
adjusting the timeout calculation to start from that point. The existing
low-overhead completion-based timeout mechanism is preserved, but care is
taken to ensure the transfer start time is consistently recorded for both
PIO and DMA paths.
This prevents premature timeouts while retaining efficient timeout
handling.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-16-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
When a transfer list is only partially completed due to an error,
hci_dma_dequeue_xfer() overwrites the remaining DMA ring entries with
NoOp commands and restarts the ring to flush them out.
While NoOp commands are expected to complete successfully, they may still
fail to complete if the DMA ring is stuck. Explicitly wait for the NoOp
commands to finish, and trigger controller recovery if they do not
complete or report an error.
This ensures that partially completed transfer lists are reliably
resolved and that a stuck ring is recovered promptly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-15-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Handle internal I3C HCI errors when operating in DMA mode by adding a
simple recovery mechanism.
On detection of an internal controller error, mark recovery as needed and
attempt to restore operation by performing a software reset followed by
state restore. To keep recovery straightforward on this unlikely error
path, all currently queued transfers are terminated and completed with an
error.
This allows the controller to resume operation after internal failures
rather than remaining permanently stuck.
Note, internal errors indicated by INTR_HC_INTERNAL_ERR, cause the
controller to stop.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-14-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Factor the reset-and-restore sequence out of i3c_hci_rpm_resume() into
a separate helper.
This allows the same logic to be reused for recovery paths in subsequent
changes without duplicating suspend/resume handling.
No functional change.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-13-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
DMA rings can be aborted either per-ring via RING_CONTROL or globally
via HC_CONTROL_ABORT. The driver currently relies on the per-ring
mechanism.
Some Intel I3C HCI controllers require HC_CONTROL_ABORT to be asserted
before a DMA ring abort is effective. This behavior is non-standard.
Introduce a controller quirk to select the required abort method and
enable it for Intel LPSS I3C controllers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-12-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Factor out hci_dma_abort() from hci_dma_dequeue_xfer() in preparation
for further changes.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-11-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Some Intel I3C HCI controllers cannot reliably restart a DMA ring after an
ABORT. Additional queue resets are required to recover, and must be
performed using PIO reset bits even while operating in DMA mode.
This behavior is non-standard. Introduce a controller quirk to opt into
the required PIO queue resets after a DMA ring abort, and enable it for
Intel LPSS I3C controllers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-10-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Software ABORT of the DMA ring is used to recover from transfer list
timeouts, but it is inherently racy. The intended transfer list may
complete just before the ABORT takes effect, causing the subsequent
transfer list to be aborted instead.
In this case, an incomplete transfer list may remain in the ring and has
not yet been processed by hci_dma_dequeue_xfer(). Restarting the DMA
ring at that point can lead to unpredictable results.
Detect when the next queued transfer is not the first entry of a transfer
list and does not belong to the list currently being dequeued. In that
case, skip restarting the DMA ring and defer recovery until a subsequent
call to hci_dma_dequeue_xfer(), which will safely restart the ring once
the incomplete list is handled.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-9-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
In DMA mode, transfer lists are currently completed only when the final
transfer in the list completes. If an earlier transfer fails, the list is
left incomplete and callers wait until timeout.
There is no need to wait for a timeout, as the completion path in
i3c_hci_process_xfer() already checks for error status. Complete the
transfer list as soon as any transfer in the list reports an error.
This avoids unnecessary delays and spurious timeouts on error.
Complete a transfer list completion immediately there is an error.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-8-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
hci_dma_dequeue_xfer() relies on state normally updated by the DMA
interrupt handler. Ensure that state is current by explicitly invoking
hci_dma_xfer_done() from the dequeue path.
This handles cases where the interrupt handler has not (yet) run.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-7-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Move hci_dma_xfer_done() earlier in the file to avoid a forward
declaration needed by a subsequent change.
No functional change.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-6-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Although hci_dma_dequeue_xfer() is serialized against itself via
control_mutex, this does not guarantee that a DMA ring restart
triggered by a previous invocation has fully completed.
When the function is called again in rapid succession, the DMA ring may
still be transitioning back to the running state, which may confound or
disrupt further state changes.
Address this by waiting for the DMA ring restart to complete before
continuing.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-5-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Block the DMA enqueue path while a Ring abort is in progress or after an
error condition has been detected.
Previously, new transfers could be enqueued while the DMA Ring was being
aborted or while error handling was underway. This allowed enqueue and
error-recovery paths to run concurrently, potentially interfering with
each other and corrupting Ring state.
Introduce explicit enqueue blocking and a wait queue to serialize access:
enqueue operations now wait until abort or error handling has completed
before proceeding. Enqueue is unblocked once the Ring is safely restarted.
Note, there is only 1 ring bundle configured, and a transfer error causes
the controller to halt ring (bundle) operation, so there is only ever 1
outstanding error at a time. Furthermore, a later patch ensures that only
the currently active transfer list can time out. Consequently, the DMA
queue will not be unblocked while there are outstanding transfer errors or
timeouts.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-4-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The MIPI I3C HCI specification does not require the DMA ring RUN bit
(RUN_STOP) to be cleared when issuing an ABORT. That allows the DMA ring
to continue to receive IBIs, although an IBI is anyway not lost because it
can be received once the ring restarts if the I3C device has not given up.
Note, currently ABORT is only used on a timeout error path so the change
has very little effect in practice. In the more common case of a transfer
error, the ring (bundle) operation is halted by the controller anyway.
Adjust the RING_CONTROL handling to set ABORT without clearing RUN_STOP,
bringing the driver into alignment with the specification.
Fixes: b795e68bf3 ("i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-3-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Software reset was introduced as a fallback if bus disable failed. The
change was made in 2 places: the cleanup path and the suspend path.
For the cleanup path (i3c_hci_bus_cleanup()), after software reset the
function continues to do cleanup for the current I/O mode. For the
suspend path (i3c_hci_rpm_suspend()), after software reset the function
returns early. However software reset does not reset any Ring Headers in
the Host Controller, so returning early is not the right thing to do.
Instead, continue to call suspend for the current I/O mode, which for DMA
mode will reset any Ring Headers.
Note, although Ring Headers should not be active at this stage, performing
this reset follows the procedure defined by the specification and keeps
the suspend path consistent with the cleanup path.
Note also, i3c_hci_sync_irq_inactive() is still called via the PIO and DMA
hci->io->suspend() callbacks.
Always return 0 because the device is quiesced as much as possible and
returning a negative error code would unnecessarily prevent system suspend.
Fixes: 9a258d1336 ("i3c: mipi-i3c-hci: Fallback to software reset when bus disable fails")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260603090754.16252-2-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Three fixes:
- Avoid KASAN instrumentation of half-word IO
- Use a byte load for KASAN shadow stack
- Fix kexec and hibernation with PAN
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuNNh8scc2k/wOAE+9OeQG+StrGQFAmousPYACgkQ9OeQG+St
rGREqQ/+OdeNlX8q7h7Hv5kOXsrjsD/UMjsunzP/RKeZUYskF0zxJyK+qc6BjW1g
+5zxSikZ+cZZT0rrGma5gOBpNG0FtJSF02CyCSjlKyb6nu09wc1aMZ/DiAMQkZ/u
wunswFeR3pO97YT6QxJMcv2MVabH4FvWg7aym5KmJycWwRYzDwd1id0b/aEDyP6n
bEnspk1RnAgp12mC4IjK+dKlsd9wgbrCNBXCyGw35cqEuqaVG021Jkprwxk3jdK/
sunFPQVZebewiQFQOTQP6jNudYOfV6Uf+7wu67C7inLdffe7r+OW+Z2aFuHXJmXo
lbpQvmgzHMzpFq5nNQaMFO3cwe6HwPwwDJbXf6eDWvbKPaaU6AQf+Ywcbj/P6Aj6
7+ellXuSkErTKZSVrJ/wdLB2I1CGHkWbMX6VSXizuZJ5H07E40urkEqIALyw3Q4z
+8RxnOrfsrlVeE1m+rm5FpOSxokD8kbSn66fP2EwIG1lRbbmFw402nj51a7Vuc8e
RcSqPt3Y8L9vHCh9c2hxc/IzYTyE21wKeWWP9qPsvR79xyJLLgPbAwvk6sxGLDEY
Fcourk96GROJ1RQxNXLzjgexrVCVBgZgW+qeOwVcxzejWZbkx7i/9UFCokTHO0bg
4UrMJ6+XWH49PwDTlxjHBn+HFgAwLlZyFNIbee6fQNqxvYgxo68=
=aiHy
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux
Pull ARM fixes from Russell King:
- Avoid KASAN instrumentation of half-word IO
- Use a byte load for KASAN shadow stack
- Fix kexec and hibernation with PAN
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux:
ARM: 9476/1: mm: fix kexec and hibernation with CONFIG_CPU_TTBR0_PAN
ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow
ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O
GRO_LEGACY_MAX_SIZE = 65536; total_len being 65536 is too big to fit
into a u16. As can be seen in skb_gro_receive, packets bigger or equal
to gro_max_size (or GRO_LEGACY_MAX_SIZE) are dropped with -E2BIG. Apply
the same boundary to geneve_post_decap_hint to avoid writing 65536 to a
16-bit iph->tot_len field with an overflow.
Fixes: fd0dd79657 ("geneve: use GRO hint option in the RX path")
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260611192955.604661-3-alice.kernel@fastmail.im
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Similar to commit add641e7de ("sched: act_csum: don't mangle TCP and
UDP GSO packets"), UDP tunnel GSO packets going through act_csum
shouldn't have their checksum calculated at this point, because it will
be done after segmentation. Setting the checksum in act_csum modifies
skb->ip_summed and prevents inner IP csum offload from kicking in,
resulting in a packet with a bad checksum.
Add UDP tunnel GSO packets to the exceptions, and also add UDP GSO
(SKB_GSO_UDP_L4), as the same logic as in the commit mentioned above
applies to UDP GSO too.
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Reviewed-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260611192955.604661-2-alice.kernel@fastmail.im
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* for-next/selftests:
kselftest/arm64: Add 2025 dpISA coverage to hwcaps
kselftest/arm64: Add tests for POR_EL0 save/reset/restore
kselftest/arm64: Move/add POE helpers to test_signals_utils.h
kselftest/arm64: Add POE as a feature in the signal tests
selftests/mm: Fix resv_sz when parsing arm64 signal frame
