| Age | Commit message (Collapse) | Author |
|---|
|
The hci_dev_init_sync() failure path in hci_dev_open_sync() and the cleanup
code in hci_dev_close_sync() have a bunch of common code.
Factor this duplicate code out into a hci_dev_drop_last_cmd_req_and_close()
helper function.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The driver decodes controller packets and reports button presses and
axis positions in dc_pad_callback(), but never calls input_sync() to
signal completion of the input report frame. Consequently, events
remain pending without waking up userspace readers.
Emit an EV_SYN/SYN_REPORT event after reporting buttons and axis states.
Fixes: 01461d7e65a6 ("Input: add support for Maple controller as a joystick")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/r/20260704061045.036701F000E9@smtp.kernel.org
Assisted-by: LLM
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The driver was unconditionally enabling all possible analog axes and
hats on the input device, even if the controller reported it did not
have them in its function data.
Move the input_set_abs_params() calls inside the capability check loop
so that only actually present axes are enabled on the input device.
Also, correct the D-pad (hat) axis limits. They were initialized with
inverted limits (min=1, max=-1). Correct them to min=-1, max=1, which
matches the values (-1, 0, 1) reported by the driver.
Assisted-by: Antigravity:gemini-3.5-flash
Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-3-41e424964da5@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
sparc64 and powerpc create PCI devices from the device tree in
of_create_pci_dev(), which calls set_pcie_port_type() but not
pci_setup_device(). Since d2bd39c0456b, supported_speeds is only set in
pci_setup_device(), so it stays 0 for these devices.
pcie_get_speed_cap() then returns PCI_SPEED_UNKNOWN, the sysfs
'max_link_speed' attribute reads "Unknown", and the failed link retraining
quirk passes PCI_SPEED_UNKNOWN to pcie_set_target_speed(), which warns on a
SPARC T7-1:
WARNING: drivers/pci/pcie/bwctrl.c:125 at pcie_set_target_speed+0x284/0x2e0
Set supported_speeds in set_pcie_port_type(), which all three paths call.
Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds")
Closes: https://github.com/sparclinux/issues/issues/109
Signed-off-by: Stian Halseth <stian@itx.no>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tony Rodriguez <unixpro1970@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261007131304.309511-1-stian@itx.no
|
|
"[RAM]" means that the command line option is applicable when
"RAM disk support is enabled." However, the reserve_mem command line
option is not related to RAM disk support, so modify its build option
relevance to "[MM]" instead.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: SJ Park <sj@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20261003213457.96408-1-rdunlap@infradead.org>
|
|
wq_worker_running() increments pool->nr_running with only preemption
disabled, while kick_pool_pick() reads it via need_more_worker() under
pool->lock, so the two can run concurrently on different CPUs. KCSAN
reports:
BUG: KCSAN: data-race in kick_pool_pick / wq_worker_running
write to 0xffff888059c2af24 of 4 bytes by task 3007 on cpu 0:
wq_worker_running+0x114/0x130
schedule_timeout+0x16e/0x180
io_schedule_timeout+0x4c/0x70
submit_bio_wait+0xd7/0x110
blkdev_issue_flush+0x4c/0x70
ext4_sync_file+0x60d/0x6c0
aio_fsync_work+0x7f/0x270
process_one_work+0x4ae/0xa00
read to 0xffff888059c2af24 of 4 bytes by task 3001 on cpu 1:
kick_pool_pick+0x7a/0x3a0
__queue_work+0x72d/0xcf0
queue_work_on+0x9d/0xb0
schedule_on_each_cpu+0x11a/0x2d0
vmstat_refresh+0x23/0x140
proc_sys_call_handler+0x2b9/0x4f0
The race is benign. The increment in wq_worker_running() is the only
lockless write to nr_running; decrements and the reset are done under
pool->lock, so a reader holding the lock sees either the old or the new
count. A stale 0 costs at most a spurious wakeup of an idle worker. A
nonzero count is correct because the incrementing worker is running and
re-checks the worklist under pool->lock before it stops counting. The
increment can also go 1 -> 2, e.g. when a worker sleeping in a work item
wakes up after kick_pool() woke another worker.
The lockless increment is part of how nr_running is designed to work,
as the comment above the field documents. Mark the field __data_racy
so that every reader is covered, not just need_more_worker().
Reported-by: syzbot+8922e6b8343f70be92e8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8922e6b8343f70be92e8
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Some kernel command line descriptions mix, mingle, or conflate an
optional part of the command line with the build options that are
applicable to those command line options.
Specifically, a few command line options that use "KMG" to specify
a memory size mix that string with build options like "X86,EARLY".
These should be separate fields although they are both enclosed in
square brackets, so separate the conflated fields.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20261003213508.96424-1-rdunlap@infradead.org>
|
|
In nvme_disable_and_flr(), the PCI bar is mapped using
NVME_REG_CC + sizeof(cfg) which is (0x14 + 4 = 0x18 bytes)
However, the function later reads the controller status from
NVME_REG_CSTS - offset 0x1C, which is outside the mapped 0x18 byte
boundary. This violates the API contract.
Fix this by increasing the mapping size to include NVME_REG_CSTS. Also
change sizeof(cfg) to sizeof(u32) to make the intent clearer.
Fixes: ffb0863426eb9 ("PCI: Disable Samsung SM961/PM961 NVMe before FLR")
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex@shazbot.org>
Link: https://patch.msgid.link/20260903164615.5744-1-raizudeen.kerneldev@gmail.com
|
|
Translate the section describing Reported-by, Tested-by, Reviewed-by,
Suggested-by, and Fixes tags into Japanese.
This includes the Reviewer's Statement and the guidance on adding or
removing review and testing tags in subsequent patch versions.
Keep the Reviewer's Statement in English and add a Japanese tentative
translation in a formal style.
Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
Reviewed-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20261007004715.107860-1-weibu@redadmin.org>
|
|
The key press detection logic was using ptr instead of !ptr (where ptr is
the result of memchr searching for the new key in the old keys).
If ptr is not NULL, it means the key was already pressed in the previous
report, so it is not a new press. If ptr is NULL, it means the key was
not pressed before, so it is a new press.
Using ptr instead of !ptr caused new presses to be ignored in the first
poll cycle (only reported in the second cycle if still held, because
then it was in 'old'), and caused redundant press events to be sent
on every subsequent poll while the key was held.
Fix this by using !ptr for press detection, matching the release
detection logic.
Fixes: b11d2127c489 ("Input: add support for SEGA Dreamcast keyboard")
Assisted-by: Antigravity:gemini-3.5-flash
Tested-by: Florian Fuchs <fuchsfl@gmail.com>
Link: https://patch.msgid.link/20260703-b4-maple-cleanup-v1-2-41e424964da5@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Commit 78d979db6cef ("docs: add AI Coding Assistants documentation") asked
contributors to add an Assisted-by tag to patches developed with help from an
LLM, and commit 816d9992d9ed ("coding-assistants: simplify attribution") later
reduced the tag to "Assisted-by: LLM".
A proposal to drop the tag was turned down in July [1]. The main argument for
keeping it was that maintainers wanted a signal that a patch was LLM-assisted,
so that they could review it accordingly.
The tag came up again at the 2026 Maintainers Summit [2]. Roughly 10% of the
18,533 non-merge commits in 7.3 through -rc7 carry an Assisted-by tag, while
actual LLM use is far more widespread. Some contributors do not know about the
rule, others leave the tag off on purpose, and few maintainers ask about it. As
a result, the tag does not provide the signal it was kept for: its absence says
nothing about how a patch was made, and for developers who use these tools for
almost everything, its presence says little more. The choice was between
finding a way to enforce the requirement and dropping it, and there was a
strong, though not unanimous, consensus in the room to drop it. Greg
Kroah-Hartman, who argued for keeping the tag in July, supports removing it now
[3].
Maintainers do still want to know how a patch was created, but the view at the
Summit was that this belongs in the cover letter, where it can describe how the
tools were used, rather than in the changelog.
Documentation/process/generated-content.rst already asks contributors to be
transparent about tool use and is not changed here. The rules on the DCO and on
the submitter's responsibility for the patch stay as they are.
Remove the Assisted-by sections from coding-assistants.rst,
submitting-patches.rst, and the Italian, Brazilian Portuguese and Traditional
Chinese translations, and drop the handling of the tag from checkpatch.
[1] https://lore.kernel.org/workflows/2026070224-unholy-commode-cf45@gregkh/
[2] https://lwn.net/Articles/1099594/
[3] https://lore.kernel.org/all/2026101327-cupid-legal-6cf6@gregkh/
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: SJ Park <sj@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Daniel Pereira <danielmaraboo@gmail.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Weijie Yuan <wy@wyuan.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20261013121501.3738437-1-sashal@kernel.org>
|
|
|
|
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 updates for 7.4
* New features
- pKVM state isolation: years after pKVM started being enabled
upstream, we finally get the basics in the form of state
isolation. The vcpu state is now off-limit for the host for
protected VMs.
- pKVM also grows a hypervisor-private memory allocator, allowing it
to deal with sub-page allocation, much like everywhere else.
- pKVM also lands a trace_printk() equivalent, which hopefully will
make debugging a bit easier.
- First shot at annotating portions of the KVM/arm64 code to be
extracted and built on s390. The real fun is yet to come.
- Allow pre-faulting of stage-2 canonical mappings from userspace,
joining x86 and s390 in implementing this feature.
- Add a reverse mapping infrastructure for shadow stage-2,
significantly improving performance when MMU notifiers kick in,
and avoiding full unmap of all shadow tables for this VM.
- Next step of GICv5 enablement, adding support for the IRS block,
and providing both SPI and LPI support. This is the first point
where KVM/arm64 can support an SMP GICv5 guest.
* Improvements
- As a preliminary to eventually enabling CCA, add a bunch of
infrastructure to KVM/arm64, splitting some of the basic
operations into individual backends (normal VM, normal pKVM VM,
protected pKVM VM). This allows CCA to later slot in without
polluting the rest of KVM with its firmware-driven nonsense.
- Make ID registers immutable from the point where a vcpu is able
to run, even if it fails to run. This prevents KVM from sampling
untrusted values.
- Restore some type checking to the EL2 object. KVM/arm64 originally
had some strong type checking between the kernel and the EL2
object, but lost it along the way when the private hypercall
interface was (somewhat pointlessly) converted to SMCCC. Type
checking is back, syscall style, and with added sparse goodies.
- Expand the FFA support to FFA_NOTIFICATION_*, and add some
sanitisation of the protocol that pKVM relays to the "trusted"
runtime.
* Fixes
- Make GICv3 RD assignment more robust to userspace nonsense
- Convert the remaining MMU fault handler backends to
kvm_s2_fault_vma_info and co, fixing a number of bugs in the
process.
- Fix the SError/SEA selftests to be both more robust and less
braindead.
- Fix a smattering of documentation bugs, some of them as a result
of our AI friends spitting out credible assertions based on
non-existing symbols.
- The usual collection of low impact bug fixes (SMCCC, timers, PMU).
|
|
Under some uncommon timing conditions, a generation check and
xchg(active_asids, A1) in check_and_switch_context() on P1 can race with
an ASID roll-over on P2. If P2 has not seen the update to
active_asids[P1], it can re-allocate A1 to a new task T2 on P2. P1 ends
up waiting on the spinlock since the xchg() returned 0 while P2 can go
through a second ASID roll-over with (T2,A1,G2) active on P2. This
roll-over copies active_asids[P1] == A1,G1 into reserved_asids[P1] and
active_asids[P2] == A1,G2 into reserved_asids[P2]. A subsequent
scheduling of T1 on P1 and T2 on P2 would match reserved_asids and get
their generation bumped to G3:
P1 P2
-- --
TTBR0.BADDR = T0
TTBR0.ASID = A0
asid_generation = G1
check_and_switch_context(T1,A1,G1)
generation match
check_and_switch_context(T2,A0,G0)
new_context()
ASID roll-over
asid_generation = G2
flush_context()
active_asids[P1] = 0
asid_map[A1] = 0
reserved_asids[P1] = A0,G0
xchg(active_asids, A1)
active_asids[P1] = A1,G1
xchg returns 0
spin_lock_irqsave()
allocated ASID (T2,A1,G2)
asid_map[A1] = 1
active_asids[P2] = A1,G2
...
check_and_switch_context(T3,A0,G0)
new_context()
ASID roll-over
asid_generation = G3
flush_context()
active_asids[P1] = 0
asid_map[A1] = 1
reserved_asids[P1] = A1,G1
reserved_asids[P2] = A1,G2
allocated ASID (T3,A2,G3)
asid_map[A2] = 1
active_asids[P2] = A2,G3
new_context()
check_update_reserved_asid(A1,G1)
matches reserved_asid[P1]
reserved_asid[P1] = A1,G3
updated T1 ASID to (T1,A1,G3)
check_and_switch_context(T2,A1,G2)
new_context()
check_update_reserved_asid(A1,G2)
matches reserved_asids[P2]
reserved_asids[P2] = A1,G3
updated T2 ASID to (T2,A1,G3)
At this point, we have two tasks, T1 and T2 both using ASID A1 with the
latest generation G3. Any of them is allowed to be scheduled on the
other CPU leading to two different tasks with the same ASID on the same
CPU.
This patch changes the xchg to cmpxchg so that the active_asids is only
updated if non-zero to avoid a race with an ASID roll-over on a
different CPU.
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
show_stack() can be called for any task, but c_backtrace is always
unwinding frames based on "sp" register.
Which leads to printing backtrace of current task instead of
required task.
Try with normal TC:
==================
for_each_process(p){
sched_show_task(p);
}
[7.433271] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000
[7.433633] Call trace:
[7.433640] [<80113418>] (dump_backtrace) from [<80113510>] (show_stack+0x14/0x18)
..
[7.433676] [<8016749c>] (sched_show_task) from [<803cb324>] (meminfo_proc_show+0x6c/0x930)
[7.434019] r5:8158e300 r4:8b4882d0
[7.434024] [<803cb324>] (meminfo_proc_show) from [<80365788>] (seq_read_iter+0x148/0x4bc)
[7.434045] [<80365788>] (seq_read_iter) from [<803c044c>] (proc_reg_read_iter+0xb8/0xc4)
[7.434060] [<803c044c>] (proc_reg_read_iter) from [<80377104>] (copy_splice_read+0x228/0x308)
It should unwind frame based on passed "fp".
(CONFIG_UNWINDER_FRAME_POINTER=y)
Extra sp manipulation is needed only when c_backtrace()
is called from dump_backtrace() with "frame == fp" i.e.
NULL regs and not current task. (Suggested by Ard Biesheuvel)
Otherwise passed "fp" should be used to unwind backtraces.
With fix:
=========
[13.933732] task:kthreadd state:S stack:0 pid:2 tgid:2 ppid:0 task_flags:0x208040 flags:0x00000000
[13.934165] Call trace:
[13.934604] [<80afa1a8>] (schedule) from [<8015426c>] (kthreadd+0x124/0x208)
[13.934654] r10:8100bbf0 r4:8116f440
[13.934664] [<8015426c>] (kthreadd) from [<8010010c>] (ret_from_fork+0x14/0x28)
[13.934691] Exception stack(0xf081df9c to 0xf081dfe4)
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Onkarnath <onkarnath.1@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 7.3, round #2
- Take a reference on the last IRQ loaded into an LR to prevent it
from being freed while running the guest (Marc Zyngier)
- Ensure that the ITS MOVALL command only affects LPIs that were
previously affined to the source redistributor (Marc Zyngier)
- Fix + test for honoring the host's trap configuration when running
non-protected VMs while KVM is in protected mode (Fuad Tabba)
- Use the host stage-1 mapping granularity for VM_PFNMAP mappings at
stage-2 (Mostafa Saleh)
|
|
In BE32 configurations, endianess is always set to BE in Control
Register C1, originally to allow booting BE kernels from a LE bootloader
on IXP12xx.
To also allow the opposite and allow booting LE kernels from a BE
IXP4xx bootloader, moving this code into head-xscale.S along with the
recommended serialization sequence and flip the B bit into the correct
position regardless of its original state.
Note that both the endianess switch sequence and the cp15wait I add
here should be harmless on all supported ARMv4/v4t/v5 CPUs, but the
existing cache flush code is not actually defined on ARM720 and may
cause problems in multiplatform kernels that include both Xscale
and CLPS711x.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Defining KVM_MMIO is not flexible enough for multi-KVM systems where one
KVM implements MMIO but others do not. Therefore, remove KVM_MMIO from the
config space and use the macro __KVM_NO_MMIO instead. Define __KVM_NO_MMIO
for KVM/s390 and for HV-only 64-bit Book3s (aka pSeries/sPAPR) configurations.
In particular, for PowerPC configurations:
* KVM_BOOK3S_32 got KVM_MMIO via KVM_BOOK3S_32_HANDLER and KVM_BOOK3S_PR_POSSIBLE
* KVM_BOOK3S_64 got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE if !KVM_BOOK3S_HV_POSSIBLE
* KVM_BOOK3S_64 + KVM_BOOK3S_64_PR got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE
* likewise for KVM_BOOK3S_64 + KVM_BOOK3S_64_PR + KVM_BOOK3S_64_HV
* KVM_E500V2 and KVM_E500MC directly selected KVM_MMIO
but KVM_BOOK3S_64 + KVM_BOOK3S_64_HV didn't and therefore needs __KVM_NO_MMIO.
coalesced_mmio.c is now always compiled and linked. However, for
architectures/configurations defining __KVM_NO_MMIO this effectively
collapses to an empty object with no mmio code.
No functional changes.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Link: https://patch.msgid.link/20260930173441.66762-4-seiden@linux.ibm.com
[Simplify powerpc condition, add underscores. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
With s390 hosting multiple independent KVM implementations within the
same kernel build (native s390 KVM and arm64 on s390), global Kconfig
selections force both implementations to inherit options that only apply
to one of them.
Replace global Kconfig options which only apply to one KVM
implementation with architecture-specific opt-in defines in the
respective <asm/kvm_host.h>. Only remove Kconfig symbols that would be
different on both s390 KVM implementations
- __KVM_HAVE_INVALID_WAKEUPS (formerly HAVE_KVM_INVALID_WAKEUPS)
- __KVM_HAVE_MSI (formerly HAVE_KVM_MSI)
- __KVM_HAVE_NO_POLL (formerly HAVE_KVM_NO_POLL)
- __KVM_HAVE_READONLY_MEM (formerly HAVE_KVM_READONLY_MEM)
- __KVM_HAVE_VCPU_RUN_PID_CHANGE (formerly HAVE_KVM_VCPU_RUN_PID_CHANGE)
This allows each architecture and guest implementation to configure its
supported capabilities independently in its kvm_host header and eliminates
adding unnecessary fallback stubs across different KVM targets.
Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Link: https://patch.msgid.link/20261013121343.1997112-1-seiden@linux.ibm.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
These #defines were used for the old KVM-specific device assignment
and have had no in-tree use for more than 10 years. Drop them.
Link: https://patch.msgid.link/kvm/20261012174847.147915-1-pbonzini@redhat.com/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
mmap(MAP_HUGETLB) on 32-bit Arm can return an address which is not
aligned to the huge page size. In a QEMU virt guest, unmapping the VMA
then hits the alignment check in __unmap_hugepage_range():
kernel BUG at mm/hugetlb.c:5213!
Internal error: Oops - BUG: 0 [#1] SMP ARM
PC is at __unmap_hugepage_range+0x540/0x584
LR is at __zap_vma_range+0x13a0/0x1410
Commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through
mm_get_unmapped_area_vmflags") made hugetlb mappings use the
architecture's arch_get_unmapped_area(). The generic implementations
handle hugetlb alignment, but the Arm implementations only account for
the optional SHMLBA cache-colouring constraint. A 4 KiB-page kernel can
therefore align the mapping to 4 KiB or 16 KiB instead of the required
2 MiB.
Set the alignment mask from the file's hstate for hugetlb mappings in
both Arm implementations. Huge-page alignment also satisfies the
SHMLBA constraint.
Assisted-by: LLM
Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags")
Cc: stable@vger.kernel.org
Acked-by: Muchun Song <muchun.song@linux.dev>
Link: https://lore.kernel.org/r/20260901085740.66283-1-kmehltretter@gmail.com/
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
ARM secondary CPUs allocate cacheinfo in detect_cache_attributes(),
called from secondary_start_kernel() with interrupts disabled. With
PREEMPT_RT, the allocation takes a sleeping lock and triggers
"BUG: sleeping function called from invalid context".
Call fetch_cache_info() for each possible CPU from init_cpu_topology()
on the boot CPU, following commit 5944ce092b97 ("arch_topology: Build
cacheinfo from primary CPU"). This supplies the arrays before secondary
CPUs populate them. Suppress -ENOENT and -EOPNOTSUPP, which leave cache
detection to the existing late path.
The CLIDR fallback uses the boot CPU's cache geometry. A secondary CPU
with more cache leaves can still require late reallocation and trigger
the warning.
Assisted-by: LLM
Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support")
Cc: stable@vger.kernel.org
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260912195552.76673-5-kmehltretter@gmail.com/
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
ARM1176 and ARM11 MPCore can be reported as ARMv7 by
cpu_architecture() even though they lack CLIDR. populate_cache_leaves()
therefore needs the CTR-format check used by detect_cache_level().
DT-based early allocation bypasses init_cache_level(), so its check
no longer protects populate_cache_leaves(). A combined ARMv6/ARMv7
SMP kernel can reach this path on BCM2835, whose DT describes its
caches.
Share the CLIDR capability check between detection and population.
Return -ENOENT from population when CLIDR is unavailable, preserving
the existing absence of cacheinfo and avoiding a new topology warning.
Assisted-by: LLM
Cc: stable@vger.kernel.org
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260912195552.76673-4-kmehltretter@gmail.com/
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
early_cache_level() counts only caches described by CLIDR. An external
PL310 is absent from CLIDR, and its arm,pl310-cache compatible is not
accepted by init_of_cache_level(), so early allocation falls back to
an incomplete count. init_cache_level() later adds the DT-described
L2, forcing reallocation on the secondary CPU with interrupts disabled.
This defeats early allocation on PREEMPT_RT.
Use init_cache_level() for early sizing too, so the initial allocation
includes external caches described by the device tree.
Assisted-by: LLM
Cc: stable@vger.kernel.org
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260912195552.76673-3-kmehltretter@gmail.com/
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
populate_cache_leaves() advances its bounds-checking index once per
cache level, but split instruction/data caches consume two entries.
CLIDR-based allocation supplies enough entries. Early allocation from
the device tree can supply fewer and expose an out-of-bounds write.
Count each written leaf and stop before a split level that does not
fit. This prepares ARM for DT-based early allocation and matches
commit 875d742cf532 ("arm64: cacheinfo: Avoid out-of-bounds write to
cacheinfo array").
Assisted-by: LLM
Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support")
Cc: stable@vger.kernel.org
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260912195552.76673-2-kmehltretter@gmail.com/
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
error path
In __iommu_alloc_simple(), when IOMMU mapping creation fails, the error
path unconditionally called __free_from_pool() regardless of the
allocation path taken.
For the COHERENT case, memory is allocated via __alloc_simple_buffer(),
which does not use the atomic pool. Calling __free_from_pool() on such
memory silently returns without freeing, causing a page memory leak.
Fix this by matching the free function to the allocation path:
- COHERENT: use __dma_free_buffer(virt_to_page(addr), size)
- non-COHERENT: use __free_from_pool(addr, size)
Fixes: 565068221b905 ("ARM: 8561/4: dma-mapping: Fix the coherent case when iommu is used")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
The register-offset form of LDR/STR may apply a shift to Rm. Per
DecodeImmShift() (ARM ARM DDI0406C section A8.4.3, "Pseudocode details
of instruction-specified shifts and rotates"), an imm5 of 0 encodes a
shift of 32 for LSR and ASR; only LSL treats 0 as "no shift", and ROR
with 0 encodes RRX.
do_alignment() special-cases RRX but not LSR or ASR, and IS_SHIFT() does
not filter these encodings out, so the block is entered with
shiftval == 0 and the offset becomes Rm instead of 0 (LSR #32) or the
replicated sign of Rm (ASR #32).
do_alignment_finish_ldst() applies the offset to the base-register
writeback of the post-indexed form, so the emulated access itself uses
the correct faulting address but Rn is left holding the wrong value.
Reproduced on ARM926EJ-S (versatile_defconfig, CONFIG_ALIGNMENT_TRAP=y,
gcc 13.3.0) with a misaligned base and Rm = 0x1000:
ldr r0, [r1], r2, lsr #32 Rn advanced by 0x1000, must be unchanged
ldr r0, [r1], r2, asr #32 Rn advanced by 0x1000, must be unchanged
ldr r0, [r1], r2, asr #32 with Rm negative, Rn must decrease by 1
All three are correct with the patch applied, while a lsr #1 control
case is emulated correctly both before and after.
Assisted-by: Claude:claude-fable-5
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
The alignment handlers enable access to user memory while emulating
unaligned instructions. If a checked access faults, its exception table
fixup jumps to the handler's fault label and bypasses uaccess_restore().
This leaves DOMAIN_USER as DOMAIN_CLIENT with SW domain PAN, or leaves
TTBR0 page table walks enabled with TTBR0 PAN, while the fault is handled.
An ARM926 QEMU test using LDMIA across an unmapped page boundary reports
DOMAIN_USER=1 at TYPE_FAULT before this change and DOMAIN_USER=0 after it.
SW domain PAN is the default on ARMv5, ARMv6, and non-LPAE ARMv7 builds.
Keep the saved uaccess state at function scope and track whether it was
saved. Restore it at the fault label only when needed. Paths that did not
enable user access continue to skip the restore.
Assisted-by: Codex:gpt-5.6-sol
Fixes: 274e91b81ed2 ("ARM: alignment: fix alignment handling for uaccess changes")
Cc: stable@vger.kernel.org
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
With CONFIG_KCOV_INSTRUMENT_ALL=y, secondary CPUs fail to come online
on ARMv6K/ARMv7 SMP:
CPU1: failed to boot: -38
The compiler inserts a call to __sanitizer_cov_trace_pc() at the entry
of secondary_start_kernel(), before set_current(task). The KCOV hook
dereferences current while TPIDRURO is still uninitialized, causing a
data abort before cpu_init() has installed the exception stacks. The
secondary CPU consequently never completes startup.
Initialize current in the secondary assembly handoff, as
__mmap_switched already does for the boot CPU.
With current set in assembly, the set_current() call in
secondary_start_kernel() is redundant. Drop it together with the
function and the task argument. The hotplug resuscitate path in
arch_cpu_idle_dead() needs no hand-off either, as smp_ops.cpu_die()
can only return if the CPU kept its register state, TPIDRURO included.
Assisted-by: Claude:claude-fable-5
Fixes: 50596b7559bf ("ARM: smp: Store current pointer in TPIDRURO register if available")
Cc: stable@vger.kernel.org
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
An ARM randconfig with CONFIG_GET_FREE_REGION=y and CONFIG_WERROR=y
fails to build:
include/linux/minmax.h:86:37: error: conversion from 'long long
unsigned int' to 'resource_size_t' {aka 'unsigned int'} changes
value from '68719476735' to '4294967295' [-Werror=overflow]
Commit 14b80582c43e ("resource: Introduce alloc_free_mem_region()")
made kernel/resource.c clamp against
(1ULL << MAX_PHYSMEM_BITS) - 1. resource_size_t is 32-bit without
LPAE, but ARM's default MAX_PHYSMEM_BITS is 36.
That default was added by commit db57f88e4ccb ("ARM: 8411/1: Add
default SPARSEMEM settings") because several platforms needed at
least 36 physical address bits. !LPAE could map addresses above
32 bits only through supersections.
CONFIG_IO_36, added by commit 23bdf86aa06e ("[ARM] 3377/2: add
support for intel xsc3 core"), enabled these for XSC3 I/O. IXP23xx
placed static I/O mappings above 4GiB until its removal in 2012, and
IOP13xx ioremap()ed its PCIe windows there until its removal in 2019.
The only remaining XSC3 platform, PXA3xx, has nothing above 4GiB.
Supersection address bits overlap the descriptor domain field, so
IO_36 also renumbered the domains to make DOMAIN_IO zero. Remove
IO_36, the alternate domain numbering, and ioremap()'s supersection
path. Reject !LPAE ioremap ranges extending past 4GiB before
phys_addr_t truncation, drop the now-unneeded high static-mapping
exclusion, and reduce ioremap alignment from 16MiB to the 2MiB
covered by a PMD's pair of sections.
The other supersection user, create_36bit_mapping(), was added by
commit 0b7cd62ecdc1 ("[ARM] 3017/1: Add support for 36-bit addresses
to create_mapping()") for IXP2350 and carried IXP23xx's high static
mappings. Before this change, its only remaining call path was
efi_create_mapping() -> create_mapping_late(), for an EFI runtime
region above 4GiB.
No real-world user of this !LPAE path is known. AArch32 UEFI
requires RAM described by its memory map to be identity-mapped
during boot services, which a 32-bit virtual address space cannot
provide above 4GiB. Systems needing wider physical addressing are
expected to use LPAE.
Remove create_36bit_mapping() and the supersection definitions. If
firmware nevertheless advertises such a region on !LPAE,
efi_create_mapping() rejects it before __pfn_to_phys() truncates its
address to a low alias. EFI runtime services remain disabled, but
the kernel continues to boot. LPAE kernels are unaffected.
With no remaining !LPAE mappings above 4GiB, set MAX_PHYSMEM_BITS to
32 for !LPAE and retain 36 for LPAE, where phys_addr_t is 64-bit.
Assisted-by: Claude:claude-fable-5
Link: https://lore.kernel.org/all/3c79d2dc-8fbd-40fc-8b2d-9d1b4f8ed34e@app.fastmail.com/
Link: https://lore.kernel.org/all/CAK8P3a2MCdUbN0QSb+M3g5_6HjPsaQwtKxFjADMZWomdry4-Ww@mail.gmail.com/
Fixes: 14b80582c43e ("resource: Introduce alloc_free_mem_region()")
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Exactly 10 cores is also valid for an Immortalis configuration,
according to the public documentation:
https://support.arm.com/compute-ip/immortalis-g715
So let's report this G715 with 10 cores as Immortalis as well, as long
as it supports the ray-intersection feature. This matches what we do for
more recent GPUs as well.
Fixes: 3b1dc21d6d80 ("drm/panthor: Add support for Mali-Gx15 family of GPUs")
Signed-off-by: Erik Faye-Lund <erik.faye-lund@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20261014070902.169273-1-erik.faye-lund@arm.com
Signed-off-by: Steven Price <steven.price@arm.com>
|
|
Expose NPU device engine busy time through DRM fdinfo to enable
standardized userspace monitoring and profiling.
Add support for reporting per-engine busy time in nanoseconds via fdinfo
using the "drm-engine-npu" key. The value reflects the accumulated NPU
device execution time for a given process, allowing userspace tools to
observe NPU device utilization without driver-specific ioctls.
Signed-off-by: Max Zhen <max.zhen@amd.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20261012180808.2548697-1-max.zhen@amd.com
|
|
The TX buffer wait loop in rpmsg_send_offchannel_raw() ignores the
possibility of wait_event_interruptible_timeout() returning a
negative value, which happens when the wait is interrupted by a
signal. In that case the loop spins back around and re-arms the
wait instead of propagating the signal, which can stall a task
that is trying to be killed.
Separately, on a genuine timeout (return value 0) the function
returns -ERESTARTSYS, which is reserved for signal-interrupted
syscalls that the kernel may restart. A timeout is not a signal
and should not be treated as restartable; return -ETIMEDOUT
instead.
Handle both cases explicitly: return err directly when negative,
and return -ETIMEDOUT on timeout.
Fixes: bcabbccabffe ("rpmsg: add virtio-based remote processor messaging bus")
Signed-off-by: Atul Akella <atul.akella@gmail.com>
Link: https://lore.kernel.org/r/20261013160055.1362-1-atul.akella@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Fix a spelling mistake in the ALSA component description of the
application layer section: 'can by used' should be 'can be used'.
The same typo was fixed for the networking and V4L2 sections by
commit b114ef1efc49 ("staging: most: fix typos in driver_usage.txt"),
but this third occurrence was missed.
Signed-off-by: Wang Yibo <szwyb123@gmail.com>
Link: https://patch.msgid.link/20261013142928.443858-1-szwyb123@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In vme_slave_request(), vme_master_request(), vme_dma_request(), and
vme_lm_request(), the list iterators (slave_image, master_image,
dma_ctrlr, and lm) are accessed in the err_alloc error paths after
exiting the list_for_each_entry() loops.
While the iterator variable retains its pointer value upon hitting a
break, accessing list iterators outside the loop body violates modern
kernel coding standards.
Fix this by referencing the dedicated allocated resource pointers
(allocated_image, allocated_ctrlr, allocated_lm) in the error cleanup
blocks instead.
Signed-off-by: Riccardo Oliva <oliva.scorza@gmail.com>
Link: https://patch.msgid.link/20261012034020.100737-1-oliva.scorza@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove unused function from greybus driver to_fw_mgmt_connection.
This function is not exported or called from anywhere tree-wide.
Confirmed with git grep and cscope.
Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20261013181707.29830-1-deaner92@yahoo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Weibin Liu <liuwb@xiaopeng.com> says:
While reviewing the slave-DMA handling of the Cadence XSPI driver I
found two ways in which memory the SPI core handed to the driver can be
overrun:
1/2 both SDMA handlers copy the byte count reported by SDMA_SIZE_REG
without checking it against the requested transfer length; a
device reporting more bytes than were programmed makes the
handlers walk past the end of the transfer buffers
2/2 the Marvell b0 transfer path points the SDMA buffers at a
10-byte stack scratch area for transfers without TX data;
transfers longer than that overflow it in both directions and
clock out uninitialized stack bytes to the attached device
The two patches are independent of each other and each carries its own
Fixes: tag, so they can be queued separately.
Tested on x86_64: with both patches applied the driver builds, loads
and unloads cleanly; no xSPI controller is available in this
environment to exercise the slave-DMA paths on hardware. Details are
in the notes of the individual patches.
Link: https://patch.msgid.link/20260929081146.41041-1-liuwb@xiaopeng.com
|
|
transfer_one_message_b0() falls back to a 10-byte stack buffer for
transfers which carry no TX data and points both in_buffer and
out_buffer into it.
With a transfer longer than 10 bytes the SDMA branch of the loop moves
up to MRVL_XFER_QWORD_COUNT * MRVL_XFER_QWORD_BYTECOUNT (256) bytes
through those pointers and then advances them by the same amount, so
both directions overflow the scratch buffer: a read transaction copies
SDMA data past the end of the buffer, a write transaction sends stack
contents from beyond it to the SPI bus.
Size the scratch buffer for the largest chunk the loop can request,
keep the buffer pointers pinned to it when the message does not carry
the corresponding TX or RX data, and only advance the pointers which
reference real transfer buffers. Also zero-initialize the scratch
buffer so that padding bytes sent for TX-less transfers no longer leak
uninitialized stack contents.
Fixes: 5cb7651f78e1 ("Marvell HW overlay support for Cadence xSPI")
Cc: stable@vger.kernel.org # 6.11+
Signed-off-by: Weibin Liu <liuwb@xiaopeng.com>
Link: https://patch.msgid.link/20260929081146.41041-3-liuwb@xiaopeng.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The XSPI controller reports the size of the slave-DMA transaction
through SDMA_SIZE_REG. Both SDMA handlers take this register at face
value and copy the reported number of bytes between the SDMA FIFO and
the transfer buffers, without checking it against the length of the
transfer that was actually requested.
While cdns_xspi_adjust_mem_op_size() clamps the size of the operations
issued by the SPI core, the device can still report a bigger SDMA size
than what was programmed, which makes the handlers read from or write
to memory beyond the end of the transfer buffers.
Track the number of bytes requested for the current data phase in a new
sdma_xfer_len field, set by cdns_xspi_send_stig_command() and by the
Marvell b0 transfer path, and reject any SDMA size that exceeds it.
Fixes: a16cc8077627 ("spi: cadence: add support for Cadence XSPI controller")
Cc: stable@vger.kernel.org # 5.16+
Signed-off-by: Weibin Liu <liuwb@xiaopeng.com>
Link: https://patch.msgid.link/20260929081146.41041-2-liuwb@xiaopeng.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On SMP, migration can occur inside hvc_dcc_check() during device_initcall,
so the CPU writing the probe character and the CPU reading the TXfull
status may not be the same, which can hang the system.
Commit 4419da5d5d4b1788568b ("tty: hvc: dcc: Bind driver to CPU core0
for reads and writes") cached the DCC availability detected on core 0
during console_initcall. However, this is not sufficient: if core 0
does not detect DCC as available and another CPU later calls
hvc_dcc_check(), the check is not actually performed on core 0.
Since JTAG is not expected to be plugged or unplugged during kernel
boot, especially between console_initcall and device_initcall, checking
DCC availability multiple times is unnecessary. Cache the return value
from hvc_dcc_console_init and reuse it in hvc_dcc_init. This avoids
complex SMP-related code and ensures the result is always from core 0.
Signed-off-by: Jiannan Du <shatyuka@qq.com>
Link: https://patch.msgid.link/tencent_77968AD30F111278CBAE934BCFD0AF00E807@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use isdigit() and a while loop to simplify the backward scan.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Link: https://patch.msgid.link/20261014143034.104950-4-blum@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use isdigit() to replace the open-coded implementation.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Link: https://patch.msgid.link/20261014143034.104950-3-blum@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add the compatible for the UARTs of the Synaptics SL2610, which are
compatible with the Synopsys DesignWare APB UART.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20261014110546.415-1-jszhang@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Set FS_MGTIME on f2fs_fs_type.
f2fs meets the multigrain requirements:
- ctime updates use inode_set_ctime_current()
- f2fs_getattr() calls generic_fillattr()
- f2fs_setattr() calls setattr_copy()
- s_time_gran is 1ns
Exception: with CONFIG_F2FS_FS_POSIX_ACL, f2fs_setattr() uses a local
__setattr_copy() that sets timestamps directly, bypassing
setattr_copy_mgtime(). Make it call setattr_copy() with ATTR_MODE
cleared, then do the f2fs mode/ACL handling as before. ACL builds now
also honor ATTR_CTIME_SET via inode_set_ctime_deleg(), as non-ACL
builds already do.
Assisted-by: LLM
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
|
|
In RS485 mode the transceiver is enabled only while data is sent. A
break set with TIOCSBRK therefore never reaches the bus, and protocols
that start each frame with a break, like DMX512, do not work.
Handle an active break like a transmission. Enable the transceiver
before setting the break, after delay_rts_before_send if one is
configured. When the break ends, stop transmitting unless the TX path
is still sending data.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261013-devel-pl011-rs485-break-v2-1-31c9f80d3e3d@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The copyright and author email address of gerg@uclinux.org is no longer
valid. Change to a current valid email address, gerg@linux-m68k.org.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Link: https://patch.msgid.link/20261013120831.1046590-2-gerg@linux-m68k.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
mtk_rpmsg_match_device_subnode() returns a referenced OF child
node, which is stored in rpdev->dev.of_node.
mtk_rpmsg_release_device() later frees the containing allocation
without dropping that ref.
Release the OF node when the RPMsg device is destroyed.
Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
Link: https://lore.kernel.org/r/20261013074744.942560-1-thnkslprpt@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Only whitespace, comment, indentation and other trivial changes to
adopt signal.c to current coding style.
No functional change.
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
