cs_etm__get_trace() returns an int, but it used to return etmq->buf_len
on success. That value comes from auxtrace_buffer::size, which is a
size_t. For a large AUX trace block, returning the byte count through an
int can overflow and make a valid buffer look like a negative error.
The callers do not need the actual byte count from cs_etm__get_trace().
The buffer length is already stored in the etmq->buf_len. The callers
only need to distinguish three states:
< 0: error
= 0: no more AUX buffers
> 0: data is available
Make cs_etm__get_trace() return 0 for all non-error cases and use
etmq->buf_len to indicate whether a new buffer was found. Then make
cs_etm__get_data_block() return 1 whenever data is available, instead of
returning the buffer length.
Also refactor cs_etm__get_data_block() to make its return value
semantics clearer.
Reported-by: Suyash Mahar <smahar@meta.com>
Fixes: 8224531cf5 ("perf cs-etm: Modularize auxtrace_buffer fetch function")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Currently the code waits for "not active" but this is not the same as
halted as there are more than two states. Match openrm here and wait for
halted instead.
Fixes: c7fea1f709 ("gpu: nova-core: add non-sec2 unload path")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-10-8e3d8bc32bb9@nvidia.com
[acourbot: s/imply/guarantee.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The current frequency calculation is done in 32 bit, causing problems
if run on a future SoC that can boost higher than 4.2GHz. Ideally, we
should use a true u64 instead of unsigned long and "knowning" that this
only runs on 64 bit machines, but the core code uses ulong everywhere,
so this should be good enough.
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Reviewed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This makes starting handles a little more efficient, since it avoids
requiring bitshifts when setting or getting the h_type and h_line_no
fields in the jbd2_journal_handle structure.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The jbd2 layer enables NOFS mode using memalloc_nofs_{save,restore}()
while a handle is active. We need to do the same in nojournal mode so
that it is safe to remove GFP_NOFS flags while a jbd2 handle is
active.
This will require that we actually allocate a real handle, but with an
h_invalid flag set, so there is a place to put the saved memalloc
context.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Commit 913bd90601 ("[PATCH] x86_64: Increase the variability of the
process stack on 64bit architectures"), merged in 2006, increased stack
randomisation from 8 MiB to an ostensible 1 GiB for 64-bit systems.
However the commit actually introduced a mask of 0x3fffff * 4 KiB pages
which provides 16 GiB of randomisation, not 1 GiB.
It appears Andi perhaps typo'd an additional 'f', as 0x3ffff would indeed
provide the stated 1 GiB.
Since this value has been in use for 20 years it seems sensible to retain
it, so correct the comment instead.
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: SJ Park <sj@kernel.org>
Link: https://patch.msgid.link/20260722-fix-x86-comment-v1-1-605080af988d@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
The mce=print_all command line option is supported but has never
been documented. Add it.
Suggested-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Shreshth Srivastava <shreshth.srivastava@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260723013730.3033-1-shreshth.srivastava@intel.com
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a
reference to `Coherent` to statically ensure that the allocation lives
long enough.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-4-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Currently, `FmcBootArgs` takes DMA handles directly, rather than
references to the `Coherent` for them. This is error prone, so instead
store lifetime'd references to the `Coherent` allocation.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Currently, `poll_msgq` will report a message of size 4 if the queue
pointers are broken. It's easy to catch this if it occurs, so have
`poll_msgq` return an error in this case.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-2-8e3d8bc32bb9@nvidia.com
[acourbot: explicitly mention the error, add paragraph separator.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
NVL-S is stable enough for us to drop force_probe requirement. Let's
do that.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260722-nvl_s-drop-force_probe-v1-1-db944d940cff@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
- don't use "/**" for non-kernel-doc comments
- use the struct keyword when describing structs
- delete one Excess struct member
to prevent the following warnings:
Warning: ./fs/ecryptfs/ecryptfs_kernel.h:14 cannot understand function
prototype: 'ECRYPTFS_KERNEL_H'
Warning: ./fs/ecryptfs/ecryptfs_kernel.h:207 This comment starts with
'/**', but isn't a kernel-doc comment.
* This is the primary struct associated with each encrypted file.
Warning: ./fs/ecryptfs/ecryptfs_kernel.h:275 cannot understand function
prototype: 'struct ecryptfs_global_auth_tok'
Warning: fs/ecryptfs/ecryptfs_kernel.h:283 Excess struct member
'global_auth_tok' description in 'ecryptfs_global_auth_tok'
Warning: ./fs/ecryptfs/ecryptfs_kernel.h:298 cannot understand function
prototype: 'struct ecryptfs_key_tfm'
Warning: ./fs/ecryptfs/ecryptfs_kernel.h:309 This comment starts with
'/**', but isn't a kernel-doc comment.
* This struct is to enable a mount-wide passphrase/salt combo. This
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tyler Hicks <code@tyhicks.com>
idr_alloc() is called with GFP_KERNEL inside idr_lock(), which holds a
spinlock. GFP_KERNEL allows the allocator to sleep, triggering a
sleeping-while-atomic bug.
Fix by using idr_preload(GFP_KERNEL) before taking the lock to
pre-allocate memory in a sleepable context, then idr_alloc() with
GFP_NOWAIT inside the spinlock-protected section.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
The duplicate routing entry check in mshv_update_routing_table() uses
guest_irq_num != 0 to detect whether a GSI slot is already occupied.
This fails for GSI 0 because its guest_irq_num is 0 both when the slot
is unused (zero-initialized) and when legitimately assigned. As a
result, duplicate entries for GSI 0 are silently accepted, with the
second entry overwriting the first — corrupting the routing table
without any error reported to userspace.
While GSI 0 (legacy timer) is unlikely to appear in MSI-based routing
in practice, the check is semantically wrong — it conflates
"uninitialized" with "GSI number 0." Use girq_entry_valid instead,
which is explicitly set to true when an entry is populated and remains
zero for unused slots regardless of the GSI number.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
vmbus_irq_initialized is only true if the registration of the per-CPU
threads succeeded. If it failed, the whole registration aborts and the
vmbus_exit() path is never called.
Remove vmbus_irq_initialized.
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
lockdep_hardirq_threaded() is supposed to be used within IRQ core code
and not within drivers. It is not obvious from within the driver, that
this is the only interrupt service routing and that it is not shared
handler.
Replace lockdep_hardirq_threaded() with a lockdep annotation limiting
threaded context on PREEMPT_RT to __vmbus_isr().
Fixes: f8e6343b7a ("Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mshv_vtl_hvcall_call() copies output_size bytes to userspace.
The output page is freshly allocated. Userspace chooses the copyout length.
If the hypercall writes less, the tail can contain stale page data.
Clear the copied range before issuing the hypercall.
Also check both bounce page allocations before either page is used.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
In current code, the coherent_dma_mask for VMBus devices is not set, so
it has the default value of 0, which essentially means "invalid". Because
drivers for VMBus devices do not use dma_alloc_*() functions, the usual
use of the coherent mask does not occur, and no errors result.
However, a valid coherent_dma_mask may be needed even though the drivers
don't use dma_alloc_*() functions. In a CoCo VM, the VMBus storvsc and
netvsc drivers must bounce buffer DMA operations through the swiotlb
because the Hyper-V host can't DMA into encrypted guest memory. If the
kernel is built with CONFIG_SWIOTLB_DYNAMIC and the initial swiotlb size
is small, swiotlb code may need to grow the swiotlb in response to a DMA
mapping request. That growth first allocates a transient pool while the
swiotlb is expanded in the background. The transient pool memory is
allocated from the DMA atomic pools, and the allocation code checks for
a valid coherent_dma_mask. With current code, this check fails, then the
DMA mapping request from the storvsc or netvsc driver fails, and finally
an I/O error occurs.
Fix this problem by setting coherent_dma_mask for VMBus devices at the
same time that dma_mask is set. Being a synthetic bus, VMBus does not
have any restrictions on coherent DMA, so the coherent mask is set to
the full 64 bits for all VMBus devices, just like with dma_mask.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mtk_hdmi_common_probe() gets the DDC adapter with
of_find_i2c_adapter_by_node() and registers a devm action to release the
adapter device reference with put_device().
The HDMI v2 remove callback also calls i2c_put_adapter() on the same DDC
adapter. This is not paired with of_find_i2c_adapter_by_node(): it drops
the adapter device reference before the devm action drops it again, and
it also puts a module reference that was never taken.
Remove the extra i2c_put_adapter() call and drop the now-empty HDMI v2
remove callback. The common devm action releases the adapter device
reference.
Fixes: 8d0f798862 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188")
Cc: stable@vger.kernel.org
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260713112957.884640-1-lgs201920130244@gmail.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
mtk_crtc_reset() destroys the current CRTC state only when crtc->state
is non-NULL, but it always converts crtc->state to struct mtk_crtc_state
and passes the result to kfree().
When reset is called without an existing state, container_of(NULL, ...)
does not produce NULL. Keep the mtk state free in the same crtc->state
guard as the helper state destruction.
This issue was found by a static analysis checker and confirmed by
manual source review.
Fixes: 2d267b8189 ("drm/mtk: Use __drm_atomic_helper_crtc_reset")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260707150528.2270739-1-ruoyuw560@gmail.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Lichee Pi 4A has 3 I2C IO expansion chips onboard, connected to the
I2C0/1/3 busses. The I2C1 one is already added to the device tree, but
the I2C0/3 ones are not yet added.
Add device tree nodes for them.
Link: https://lore.kernel.org/r/20260714074515.1959352-6-zhengxingda@iscas.ac.cn
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
[Icenowy: added commit description, enable SoC pull-up, remove I2C1 and
aliases]
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Signed-off-by: Drew Fustini <fustini@kernel.org>
Add labels for GPIOs on the IO expansion chip on the I2C1 bus.
Link: https://lore.kernel.org/r/20260714074515.1959352-5-zhengxingda@iscas.ac.cn
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
[Icenowy: Splitted off the patch adding all 3 IO expansions]
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
[fustini: align ioexp2 gpio-line-names with schematic]
Signed-off-by: Drew Fustini <fustini@kernel.org>
Although "D", "H" and "I" are earlier in the alphabet than "P", the DPU,
HDMI and I2C1 nodes were added after PADCTRL nodes in the Lichee Pi 4A
device tree; in addition the PADCTRL1 node is placed before the
PADCTRL0 one.
Sort the nodes in this device tree.
Link: https://lore.kernel.org/r/20260714074515.1959352-4-zhengxingda@iscas.ac.cn
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Signed-off-by: Drew Fustini <fustini@kernel.org>
Add nodes for the remaining five I2C controllers on the T-Head TH1520
RISCV SoC.
Link: https://lore.kernel.org/r/20260714074515.1959352-3-zhengxingda@iscas.ac.cn
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
[Icenowy: rebase and reword commit message to exclude I2C1]
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Signed-off-by: Drew Fustini <fustini@kernel.org>
The I2C1 node added previously to the th1520.dtsi file has two clocks
set -- one "ref" clock (CLK_I2C1) and one "pclk" (CLK_PERI_APB_PCLK).
However, the CLK_I2C1 clock is just a clock gate with the
CLK_PERI_APB_PCLK clock as its input. In addition, when it's gated,
reading registers from the I2C controller returns fixed value (the last
read value) for all registers. These facts indicate that the CLK_I2C1
clock is the true APB clock fed into the I2C controller instead of a
dedicated reference clock.
Leave only the CLK_I2C1 clock as the `clocks` property of the I2C1
device node and remove `clock-names` property, which represents the I2C
controller only takes a single clock both as the APB clock and the
reference clock.
Fixes: 2f60e35163 ("riscv: dts: thead: Add TH1520 I2C1 controller")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Link: https://lore.kernel.org/r/20260714074515.1959352-2-zhengxingda@iscas.ac.cn
Signed-off-by: Drew Fustini <fustini@kernel.org>
The block comment describing the GSC VM lockdep annotation uses the
kernel-doc opening marker (/**), but it is an in-function
implementation note rather than API documentation. Per
Documentation/doc-guide/kernel-doc.rst, /** is reserved for kernel-doc
comments describing functions, structs, and other API elements, and
using it for other comments can confuse kernel-doc tooling.
Switch it to a regular block comment (/*).
No functional change.
Cc: Matthew Brost <matthew.brost@intel.com>
Assisted-by: Claude:claude-opus-4.7
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260721205516.4058959-4-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
xe_vm_create() initializes vm->preempt.rebind_work twice for LR-mode
VMs: once in the LR-mode setup block before xe_svm_init(), and again
inside the xe_validation_guard() block. The second call is a no-op on
top of the first since the work is never queued between them, but
re-initializing a work item is unnecessary and makes lifetime and
ordering harder to reason about (e.g., any future change that queues
the work earlier would be silently corrupted by the second INIT_WORK).
Drop the duplicate INIT_WORK() and keep only the batch_invalidate_tlb
flag handling in the later LR-mode block. The single INIT_WORK() call
in the earlier LR-mode setup block remains the sole initialization.
No functional change.
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Assisted-by: Claude:claude-opus-4.7
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260721205516.4058959-3-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Commit 9e97874148 ("drm/xe/userptr: replace xe_hmm with gpusvm") made
xe_svm_init() unconditional in xe_vm_create() and extended it to also
initialize a "simple" gpusvm state for non-fault-mode VMs. The matching
xe_svm_fini() call in xe_vm_close_and_put() was updated to run
unconditionally, but the error unwind path in xe_vm_create() was not.
On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has
already succeeded but xe_svm_fini() is only called when
XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves
vm->svm.gpusvm partially initialized and leaks the resources allocated
by drm_gpusvm_init().
For fault-mode VMs, xe_svm_init() additionally acquires the pagemap
owner via drm_pagemap_acquire_owner() and the pagemaps via
xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(),
not xe_svm_fini(). On the same error path, xe_svm_close() is not
called either, so fault-mode VMs leak the pagemap owner and pagemaps.
Fix both leaks:
- Call xe_svm_fini() unconditionally on the err_svm_fini path, matching
the unconditional xe_svm_init() call. Move the vm->size = 0
assignment out of the conditional so the xe_vm_is_closed() assert in
xe_svm_fini() (and xe_svm_close()) holds for both modes.
- Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching
the ordering used in xe_vm_close_and_put().
Fixes: 9e97874148 ("drm/xe/userptr: replace xe_hmm with gpusvm")
Cc: Matthew Auld <matthew.auld@intel.com>
Assisted-by: Claude:claude-opus-4.7
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
The Banana Pi BPI-CM6 IO board combines the BPI-CM6 compute module with
an IO carrier board. The core module integrates the SpacemiT K1 SoC,
PMIC, DDR, eMMC, the eth0 PHY, and wireless connectivity. The companion
IO carrier board extends it by providing the eth1 PHY and exposing
standard interfaces, including dual Gigabit Ethernet, MicroSD, two USB-A
ports, a USB Type-C port, two PCIe M.2 slots, and a serial console.
The board also has two I2C EEPROMs. One is on the core module, which
stores factory manufacturing data and is marked read-only. The other is
on the carrier board, which is shipped unprogrammed and left writable
for evaluation purposes.
Add initial support for UART console, eMMC, SD card, I2C, EEPROMs,
PCIe, USB, and dual Ethernet interfaces.
Link: https://docs.banana-pi.org/en/BPI-CM6/BananaPi_BPI-CM6
Reviewed-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260712-bpi-cm6-v3-3-8d1e2045179d@pigmoral.tech
Signed-off-by: Yixun Lan <dlan@kernel.org>
The gmac_clk_ref signal is optional for the GMAC controller and is not
strictly required for all hardware designs. The pins for gmac0_clk_ref
(GPIO 45) and gmac1_clk_ref (GPIO 46) may also be used as GPIOs for
other functions even when the Ethernet controller is active.
Split the refclk pins into independent pinctrl groups so boards can
request them only when the reference clock path is actually needed.
Among the already mainlined boards, BPI-F3, Jupiter and MusePi Pro have
optional hardware paths for the GMAC refclk pins. BPI-F3 and Jupiter
route both GMAC refclk pins to the PHYs through NC/0R option resistors,
while MusePi Pro only does so for GMAC0. Keep referencing the new
clk-ref pinctrl groups on these boards so the optional hardware paths
remain usable if the option resistors are populated.
OrangePi R2S has no publicly available schematic, so also keep the
clk-ref groups there to preserve the previous pinmux behavior.
Fixes: 60775f28cf ("riscv: dts: spacemit: Add Ethernet support for K1")
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260712-bpi-cm6-v3-2-8d1e2045179d@pigmoral.tech
Signed-off-by: Yixun Lan <dlan@kernel.org>
The Banana Pi BPI-CM6 IO board consists of the BPI-CM6 compute module
plugged into an IO carrier board, which is used for evaluation and
development.
The core CM6 module is based on the SpacemiT K1 SoC and provides PMIC,
DDR, the eth0 PHY and wireless connectivity. The carrier board extends
this by adding the eth1 PHY and external interfaces including Ethernet,
PCIe M.2, USB, MicroSD, QSPI, and serial console connectivity.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260712-bpi-cm6-v3-1-8d1e2045179d@pigmoral.tech
Signed-off-by: Yixun Lan <dlan@kernel.org>
Add CPU clock properties and OPP tables for the two CPU clusters in the
SpacemiT K1 SoC. The OPP entries use voltage ranges because the CPU
supply is shared by both clusters.
Enable CPU DVFS on Banana Pi BPI-F3 by including the OPP tables and
wiring the CPU nodes to the CPU regulator supply.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Andre Heider <a.heider@gmail.com> # k1-musepi-pro
Reviewed-by: Yixun Lan <dlan@kernel.org>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Milan P. Stanić <mps@arvanta.net>
Tested-by: Gong Shuai <gsh517025@gmail.com> # OrangePi-RV2
Link: https://patch.msgid.link/20260626-shadow-deps-v4-2-bba9831f2f1d@mailbox.org
Signed-off-by: Yixun Lan <dlan@kernel.org>
Enable QSPI with proper pinmux on the Pico-ITX board, and describe the
NOR flash wired to it.
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Cody Kang <cody.kang.hk@outlook.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260711-k3-pico-itx-qspi-v3-v3-1-d6b37fc86c39@gmail.com
Signed-off-by: Yixun Lan <dlan@kernel.org>
Vendor kernel enabled ALDPS (Advanced Link Down Power Saving) on the
RTL8211F PHY to save power when link down.
Vendor kernel also disabled the 125MHz clkout clock signal, and indeed
the schematics confirms that it only goes to a test point (TP14), so
let's do the same.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Yixun Lan <dlan@kernel.org>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260623204431.498700-6-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Add i2c aliases for i2c2 and i2c8 on K3 Pico-ITX board. This is useful
to keep a stable number for the /dev entries after loading the i2c-dev
module.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260623204431.498700-5-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
The K3 Pico-ITX board includes a 24c02 eeprom, that stores the product
name, the part name, the MAC address of the network interfaces and the
board's serial number. These values are also exposed via an
onie,tlv-layout nvmem layout.
The eeprom is marked as read-only since its contents are not supposed to
be modified.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260623204431.498700-4-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Define I2C2 pinctrl properties, and enable it on the K3 Pico-ITX board.
It will be used by the 24c02 eeprom.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260623204431.498700-3-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Because the default console's baud rate is not set, defconfig kernels do
not have any serial output on this platform. Set the baud rate to
115200, matching what is used by U-Boot etc on this platform.
Fixes: 7a61318049 ("riscv: dts: spacemit: add K3 Pico-ITX board support")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Guodong Xu <docular.xu@gmail.com>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260623204431.498700-2-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly
linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no
lock. This was only safe because every caller historically held the RTNL
mutex, which serialized all rate-table lookups, inserts and frees.
That invariant no longer holds. cls_flower sets
TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false
for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through
tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() ->
tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the
RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each
adding a flower filter with a police action carrying the same rate, then
race on qdisc_rtab_list and on the non-atomic refcnt, leading to a
use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table.
qdisc_rtab_list is a single global (not per-netns), so the corrupted
object is shared system-wide.
BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160
qdisc_put_rtab+0x12f/0x160
tcf_police_init+0xda9/0x1590
tcf_action_init_1+0x460/0x6b0
tcf_action_init+0x439/0xa40
tcf_exts_validate_ex+0x42d/0x550
fl_change+0xddd/0x7da0
tc_new_tfilter+0xaa7/0x2420
rtnetlink_rcv_msg+0x95e/0xe90
which belongs to the cache kmalloc-2k of size 2048
Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The
(sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before
taking the lock; if a concurrent inserter added an identical table in the
meantime the freshly allocated one is freed under the lock, so no
duplicate is leaked. qdisc_put_rtab() now decrements the refcount and
unlinks under the same lock.
Fixes: 470502de5b ("net: sched: unlock rules update API")
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260715114114.446841-1-qwe.aldo@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The platform drvdata is not set until all IRQs have been mapped, so the
local net_device pointer is NULL when IRQ mapping fails. Remove the device
allocated by sxgbe_drv_probe() through priv instead.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260717091423.1557737-1-chenguang.zhao@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some boards feed the YT8531 PHY from an SoC-provided external
reference clock described by the common ethernet-phy "clocks" property.
Enable the optional PHY clock during probe so boards can model this
clock as a PHY input instead of keeping the clock alive from the MAC
driver.
This is needed on the Alientek DLRV1126, where the PHY reference clock
is provided by CLK_GMAC_ETHERNET_OUT.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
Link: https://patch.msgid.link/20260714-motorcomm-yt8531-clk-v3-1-10dc303ef1a5@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maxime Chevallier says:
====================
net: mdio: Rearrange Kconfig menus
In menuconfig, all MDIO controllers and muxes are listed directly under the
Device drivers -> Network device support menu.
Let's group these in their own subenu :
Device drivers ->
Network device support ->
MDIO controller drivers ->
Mdio driver A
Mdio driver B
...
MDIO Multiplexers ->
MDIO Mux driver A
MDIO Mux driver B
...
There are no functional or KConfig dependency changes in this series,
just menu reorganisation.
====================
Link: https://patch.msgid.link/20260715082226.51481-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move all MDIO muxes under the "MDIO controller drivers" submenu.
This doesn't change any dependency for KConfig options and is
purely cosmetic.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260715082226.51481-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, all inidivual drivers for MDIO bus controllers are directly
listed under Device drivers -> Network device support. Let's group them
altogether in a submenu, while keeping the dependency on PHYLIB.
No intended functional change besides the menuconfig ordering.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260715082226.51481-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
