| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
knav_queue_probe() creates the global qmss debugfs file whose show
callback reads the global knav_qdev state. knav_queue_remove() tears
down the queue manager resources but leaves the debugfs file published.
Save the debugfs dentry in struct knav_device and remove it during
teardown before the resources used by the show callback are released.
While touching the debugfs_create_file() call, spell the unchanged read-
only file mode as 0444.
Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260706144706.96313-1-pengpeng@iscas.ac.cn
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Remove the 'supports-clkreq' property from PCIe1 as the standard PCIe
slot on i.MX943 EVK may not have CLKREQ# signal wired, causing
compatibility issues with some PCIe cards.
Fixes: 9a8f11f6f786 ("arm64: dts: imx943-evk: Add pcie[0,1] and pcie-ep[0,1] support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
On the i.MX91 9x9 QSB, CAN1 and MICFIL share pins. A TMUX1574RSVR
analog mux controls the routing: when SEL is driven high, CAN1 is
selected; when SEL is driven low, MICFIL is selected. By default,
SEL is kept low.
To enable CAN1, SEL must be driven high. This is done via the can_fun
function defined in the pinctrl-gpiomux node. CAN1 uses the
TJA1057GT/3 PHY.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add device tree support for the Variscite Symphony carrier board with
the VAR-SOM-MX8 QuadMax system on module.
The Symphony board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
- PCIE support
Link: https://variscite.com/carrier-boards/symphony-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add device tree support for the Variscite VAR-SOM-MX8 QuadMax
system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX8 QuadMax MPU processor
- Up to 8GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and
Variscite Symphony development carrier Board.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
In atomic_check, damage handling is not fully evaluated. Another
atomic_check helper could trigger a full modeset and thus invalidate
damage clips.
Allocation of the request/response buffers in appletbdrm depends on
correct damage information. Otherwise it might allocate incorrectly
sized buffers. Allocate the buffers in the driver's begin_fb_access
helper. It runs early during the commit when damage clipping has been
fully evaluated.
v5:
- pass plane state as the old damage-iterator state
v2:
- allocate before drm_gem_begin_shadow_fb_access() to avoid leak on error
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Aditya Garg <gargaditya08@proton.me>
Acked-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260610152505.260172-6-tzimmermann@suse.de
|
|
Disable the internal SNVS RTC on the Symphony carrier board and use the
external DS1337 RTC instead.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Enable PWM1 on the Symphony carrier board and add the corresponding
pinctrl configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Keep the RGB_SEL line driven low on the Symphony carrier board.
This avoids leaving the line floating and ensures the board remains in
the expected display configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Mark the Symphony carrier board GPIO keys and capacitive touchscreen as
wakeup sources.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Enable I2C4 on the Symphony carrier and add pinctrl configuration,
including GPIO-based bus recovery support.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add support for the TPM2 device on the VAR-SOM Symphony carrier board.
The ST33K TPM2 is connected over I2C, and A PCA6408 GPIO expander is
used to control the reset signal required to release the TPM from reset.
Add the PCA6408 GPIO expander and the ST33K TPM2 device node.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Enable the FlexSPI controller on the VAR-SOM-MX8MN and add the
corresponding pin multiplexing configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
The VAR-SOM-MX8MN module does not provide an onboard USB connector.
The complete USB OTG description, including the Type-C role switch
configuration, is already provided by the Symphony carrier board device
tree. Remove the duplicate USB OTG node from the SOM dtsi to avoid
describing the same hardware in two places.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
The VAR-SOM-MX8MN currently integrates the NXP IW61x wireless module,
providing WiFi over SDIO and Bluetooth over UART.
Move the wireless module configuration out of the base
imx8mn-var-som.dtsi and provide dedicated variant includes.
The IW61x configuration is moved to imx8mn-var-som-wifi-bt-iw61x.dtsi
and used by the Symphony evaluation board device tree.
A separate imx8mn-var-som-wifi-brcm-legacy.dtsi include is added to keep
the configuration for the legacy Broadcom SDIO WiFi module used on
earlier SOM revisions.
To preserve compatibility with older SOM revisions, add a separate
imx8mn-var-som-symphony-legacy.dtb, which disables the IW61x setup and
applies the Broadcom-specific configuration.
The Broadcom-based SOM revision is no longer in production, but support
is kept for existing users.
This keeps the VAR-SOM-MX8MN support aligned with the existing
VAR-SOM-MX8MM implementation.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add support for the Microchip MCP251xFD CAN-FD controller connected
to the SPI bus on the i.MX8MN VAR-SOM.
The controller uses a 40 MHz external oscillator and requires an
interrupt line and a dedicated RX interrupt GPIO.
Add the fixed clock, the MCP251xFD device node with the required
properties, and the corresponding pinctrl configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
The VAR-SOM-MX8MN can integrate the WM8904, a high-performance
ultra-low-power stereo codec optimized for portable audio applications.
Add the WM8904 device to the appropriate I2C bus, enable the SAI
peripheral, and introduce the sound node to expose the sound card to the
system.
Add I2C3 recovery gpio properties.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Update the FEC Ethernet controller on the i.MX8MN VAR-SOM to match the
latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.
Add the PHY VDDIO supply regulator and adjust reset timings.
The PHY LED signals originate on the SOM, but the actual LEDs are part
of the carrier implementation (RJ45 connector). Move the LED
configuration to the Symphony carrier device tree, matching the
evaluation board LED wiring.
Wake-on-LAN via magic packet is not supported at the VAR-SOM level and
is therefore not enabled in the SOM device tree nor in the official
evaluation carrier board configuration (symphony).
Designs requiring WoL support may enable it in their own carrier-specific
device trees if properly integrated at the hardware level.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Reformat the fsl,pins tables in the i.MX8MN VAR-SOM device tree to use
consistent column alignment across all pinctrl groups.
Align the entries to match the formatting already used in the
pinctrl_fec1 group, which contains the longest pin definitions,
for improved readability and consistency.
No functional changes intended.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
The VAR-SOM-MX8MN module does not provide an onboard SD card slot.
USDHC2 is routed to the SD card slot on the carrier boards.
Move the USDHC2 node and pinctrl configuration from the SOM device tree
to imx8mn-var-som-symphony.dts and imx8mn-rve-gateway.dts, keeping the
SOM dtsi limited to hardware present on the module itself.
Add the required off-on-delay-us property for the USDHC2 regulator on
the Symphony carrier board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
The VAR-SOM-MX8MN module does not provide an onboard debug console.
UART4 is routed and exposed only on the Symphony carrier board, while
custom carrier designs may choose to expose a different UART.
Move the UART4 node from the SOM device tree to the
imx8mn-var-som-symphony.dts, keeping the SOM dtsi limited to hardware
present on the module itself.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Double the fractional part of the horizontal scale factor
for the purposes of min_cdck calculation. This bumps the min
CDCLK sufficiently to overcome some kind of 2 PPC granularity
issue. Without this CDCLK may end up being too low and we get
underruns with certain horizontal downscale factors.
The current Bspec formula calls for doubling only the
fractional part below 0.5, and rounding it down to a
unit fraction. But that formula does not result in a
sufficient CDCLK bump in a lot of cases. Empirical evidence
supports doubling the entire fractional part, so let's just
do that while we wait for further analysis from the hardware
team.
Also note that the position of the scaler output window also
seems to matter. If the output is near the left edge of the
screen then lower CDCLK is sufficient, but moving the output
window further to the right causes underruns unless CDCLK is
also bumped. Some prefill happening during hblank already?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-5-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
|
|
We'll need to do additional adjustments to the pipe pixel rate
for the purposes of min CDCLK calculations. Add a new
crtc_state->pixel_rate_cdclk for that purpose. We'll leave the
original crtc_state->pixel_rate for data rate related calculations
since we presumably don't need those extra adjustments there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-4-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
|
|
We'll need to check for the "does the platform do 2 pixels per clock?"
thing in a few places. Add a feature macro for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-3-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
|
|
ecryptfs_exorcise_daemon() drops queued messages from a dying daemon
without holding ecryptfs_msg_ctx_lists_mux, but
ecryptfs_msg_ctx_alloc_to_free() requires that lock.
Take the list lock while moving the queued contexts back to the free
list to avoid racing with other global msg ctx list users.
Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
|
ecryptfs_send_message_locked() moves a message context from the free
list to the allocated list before sending the request to the userspace
daemon.
If ecryptfs_send_miscdev() fails, the context is left on the
allocated list and cannot be reused. Move it back to the free list on
failure and clear the caller's pointer.
Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
|
parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body
without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When
encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key()
sets decrypted_key_size = encrypted_key_size and performs two
out-of-bounds writes:
1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into
decrypted_key[64] via scatterlist, overflowing into the parent
ecryptfs_auth_tok struct.
2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes
into crypt_stat->key[64], corrupting root_iv, keysig_list, and
mutexes in ecryptfs_crypt_stat.
Only AES-192 (cipher code 0x08) enables this because it sets
crypt_stat->key_size = 24 independently of encrypted_key_size,
allowing crypto_skcipher_setkey() to succeed while encrypted_key_size
exceeds ECRYPTFS_MAX_KEY_BYTES.
The PKI decryption path (parse_tag_65_packet) already validates
decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path
omits this check.
Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather
than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also
protects the 512-byte encrypted_key[] buffer, so the former 512-byte
check is removed as redundant.
Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
Cc: <stable@vger.kernel.org>
Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com>
[tyhicks: Adjust the code comment to refer to macros representing the
buffer sizes rather than mentioning the buffer size values since they
may change in the future]
Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
|
Replace the hand roller intel_cdclk_ppc() with the real thing
in intel_modeset_readout_hw_state().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-2-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
|
|
vfio_msi_cap_len() lazily allocates the per-device MSI permission table:
vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT);
if (!vdev->msi_perm)
return -ENOMEM;
ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags);
if (ret) {
kfree(vdev->msi_perm);
return ret; /* vdev->msi_perm left dangling */
}
When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the
error path frees vdev->msi_perm but leaves the freed pointer stored in
it. vdev->msi_perm is not re-zeroed later because struct
vfio_pci_core_device is per-device and persists across open/close cycles,
and the vfio_config_init() error path returns without calling
vfio_config_free(). So the dangling pointer outlives the failed open.
That leads to two use-after-frees on the same device:
1. Reuse. The next vfio_config_init() sees the stale pointer at
"if (vdev->msi_perm) return len;" and reuses the freed object. MSI
config accesses in vfio_pci_config_rw_single() then dereference and
call the freed perm->readfn / perm->writefn function pointers.
2. Double free. A later vfio_config_free() runs free_perm_bits() and
kfree() on the already-freed object.
Fix it by NULLing vdev->msi_perm after the kfree(), matching the
NULL-after-free discipline already used in free_perm_bits() and
vfio_config_free().
BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
Read of size 8 at addr ffff88800fcc88d0 by task exploit/143
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986)
vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599)
vfs_read (fs/read_write.c:572)
__x64_sys_pread64 (fs/read_write.c:764)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Followed on device close by a double free of the same object:
Oops: general protection fault, probably for non-canonical address
0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:kfree (mm/slub.c:6711)
Call Trace:
vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861)
vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685)
vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777)
vfio_df_close (drivers/vfio/vfio_main.c:602)
vfio_device_fops_release (drivers/vfio/vfio_main.c:648)
__fput (fs/file_table.c:512)
__x64_sys_close (fs/open.c:1496)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Kernel panic - not syncing: Fatal exception
Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Allocate VFIO ioctl requests dynamically instead of using VLAs. GCC 11.5.0
rejects initialized VLAs with:
error: variable-sized object may not be initialized
The replaced stack u8 arrays also do not guarantee native struct alignment
for the aliased pointers.
Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests")
Fixes: 20face8c75ff ("vfio: selftests: Add helper to set/override a vf_token")
Assisted-by: Codex:gpt-5.5-high
Reviewed-by: Vipin Sharma <vipinsh@google.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Mastro <amastro@fb.com>
Link: https://lore.kernel.org/r/20260617-scratch-amastro-vfio-selftests-avoid-vlas-v4-2-b9f52f1e2c5a@fb.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Add {malloc,calloc}_assert() helpers alongside the existing *_assert()
helpers.
Use them for VFIO selftest allocations that immediately assert a
non-NULL result.
Assisted-by: Codex:gpt-5.5-high
Signed-off-by: Alex Mastro <amastro@fb.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20260617-scratch-amastro-vfio-selftests-avoid-vlas-v4-1-b9f52f1e2c5a@fb.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Add a new VFIO PCI driver for NVIDIA GPUs that enables DMA testing
via the Falcon (Fast Logic Controller) microcontrollers. This driver
extracts and adapts the DMA test functionality from NVIDIA's
gpu-admin-tools project and integrates it into the existing VFIO
selftest framework.
Falcons are general-purpose microcontrollers present on NVIDIA GPUs
that can perform DMA operations between system memory and device
memory. By leveraging Falcon DMA, this driver allows NVIDIA GPUs to
be tested alongside Intel IOAT and DSA devices using the same
selftest infrastructure.
The driver is named 'nv_falcon' to reflect that it specifically
controls the Falcon microcontrollers for DMA operations, rather
than exposing general GPU functionality.
Reference implementation:
https://github.com/NVIDIA/gpu-admin-tools
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Acked-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-5-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Allow drivers that cannot trigger MSI interrupts to leave the send_msi
callback NULL. Add an fcntl_set_msi_nonblock() wrapper that only sets
nonblocking mode when send_msi is available, and update ASSERT_NO_MSI()
to skip when the driver lacks MSI support. The send_msi test SKIPs and
mix_and_match skips the MSI portion per iteration.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-4-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Add vfio_pci_cmd_set()/vfio_pci_cmd_clear() read-modify-write macros
for PCI_COMMAND in vfio_pci_device.h.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-3-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Add a chunking loop to vfio_pci_driver_memcpy() so that it breaks up
large memcpy requests into max_memcpy_size-sized chunks. This allows
callers to request any size without worrying about per-driver limits.
The memcpy_start()/memcpy_wait() semantics are unchanged.
Update the test to use 4x max_memcpy_size so it exercises the new
chunking path (4 iterations) while keeping execution fast for drivers
with small DMA transfer sizes.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-2-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://patch.msgid.link/20260710105318.376496-4-panchuang@vivo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://patch.msgid.link/20260710105318.376496-3-panchuang@vivo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() and dev_err_probe() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Link: https://patch.msgid.link/20260710105318.376496-2-panchuang@vivo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
hwicap_module_init() registers icap_class before reserving the
character-device region and registering the platform driver. If either
of those later steps fails, the init path must undo the successful class
registration before returning an error.
Route the chrdev registration failure through a class unwind label, and
let the platform-driver registration failure fall through the existing
chrdev unwind before unregistering the class. The normal module exit path
is unchanged.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: ef141a0bb0dc ("[POWERPC] Xilinx: hwicap driver")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://patch.msgid.link/20260623085604.89284-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There are a couple of prints in handle_control_message() which should
have converted cpkt->id through virtio32_to_cpu() before passing to
a print.
This fixes the following (prototype) sparse warnings:
drivers/char/virtio_console.c:1538:17: warning: incorrect type in argument 4 (different base types)
drivers/char/virtio_console.c:1538:17: expected unsigned int
drivers/char/virtio_console.c:1538:17: got restricted __virtio32 [usertype] id
drivers/char/virtio_console.c:1553:25: warning: incorrect type in argument 3 (different base types)
drivers/char/virtio_console.c:1553:25: expected unsigned int
drivers/char/virtio_console.c:1553:25: got restricted __virtio32 [usertype] id
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Amit Shah <amit@kernel.org>
Link: https://patch.msgid.link/20260623092141.631355-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add a check to see if devm_kasprintf() is not NULL in
mchp_ipc_get_cluster_aggr_irq(), returning -ENOMEM if the function
failed.
Assisted-by: gkh_clanker_t1000
CC: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260709131640.210914-1-griffin@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The header itself also includes <linux/types.h> and additional to that
doesn't make use of any symbol defined (transitively) by
<linux/mod_devicetable.h>. Also the .c files that include that header
don't need it (there is no direct include, only via <linux/greybus.h>):
$ git grep -l greybus\\.h | xargs grep -E "\<(acpi_device_id|amba_id|ap_device_id|apr_device_id|auxiliary_device_id|bcma_device_id|ccw_device_id|cdx_device_id|coreboot_device_id|css_device_id|dfl_device_id|dmi_(device|system)_id|eisa_device_id|fsl_mc_device_id|hda_device_id|hid_device_id|hv_vmbus_device_id|i2c_device_id|i3c_device_id|ieee1394_device_id|input_device_id|ipack_device_id|isapnp_device_id|ishtp_device_id|mcb_device_id|mdio_device_id|mei_cl_device_id|mhi_device_id|mips_cdmm_device_id|of_device_id|parisc_device_id|pci_device_id|pci_epf_device_id|pcmcia_device_id|platform_device_id|pnp_(card_)?device_id|rio_device_id|rpmsg_device_id|sdio_device_id|sdw_device_id|serio_device_id|slim_device_id|spi_device_id|spmi_device_id|ssam_device_id|ssb_device_id|tb_service_id|tee_client_device_id|typec_device_id|ulpi_device_id|usb_device_id|vchiq_device_id|virtio_device_id|wmi_device_id|x86_(cpu|device)_id|zorro_device_id|cpu_feature)\>"
drivers/greybus/es2.c:static const struct usb_device_id id_table[] = {
drivers/greybus/es2.c: const struct usb_device_id *id)
drivers/greybus/gb-beagleplay.c:static const struct of_device_id gb_beagleplay_of_match[] = {
drivers/staging/greybus/arche-platform.c:static const struct of_device_id arche_platform_of_match[] = {
drivers/greybus/es2.c includes <linux/usb.h>,
drivers/greybus/gb-beagleplay.c includes <linux/serdev.h> which provides
of_device_id via <linux/device.h>, similar
drivers/staging/greybus/arche-platform.c includes
<linux/platform_device.h> which also provides of_device_id.
So the #include can go away without further adaption.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/80964227feede2d8f1978f13f4219fcf9e63d8d0.1783354012.git.u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
identify_descriptor() computes a string descriptor size from
desc->string.length.
Require the descriptor to contain the fixed string descriptor header
before reading the variable string length. The existing descriptor-size
check then reports the short descriptor.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Wine mailing lists were moved from winehq.org to list.winehq.org in December
2025. The old address no longer works.
Signed-off-by: Elizabeth Figura <zfigura@codeweavers.com>
Link: https://patch.msgid.link/20260701183214.13973-1-zfigura@codeweavers.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The "removed" flag check in each tty op has a TOCTOU race with
__ipoctal_remove(): the device could be removed between the flag
check and the subsequent access to hardware resources (channel
registers via iowrite8, or xmit_buf in write_tty).
Close this race by introducing a read-write semaphore (remove_sem).
The tty ops acquire the read lock via guard(rwsem_read) for the
full duration of the operation, while __ipoctal_remove() acquires
the write lock via scoped_guard(rwsem_write) when setting the
removed flag. This ensures that once removed is true, no in-flight
tty op can still be accessing resources that are about to be freed
by the remove path.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/fbce75010a0f0a3a3709a5e06fd0ffd19ca0a0ed.1782870760.git.xiaopei01@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Three issues arise when the device is removed while a tty session is
still active:
1. UAF of struct ipoctal: the remove callback frees ipoctal via
kfree() while tty ops may still access it. Fix by introducing
kref-based lifetime management — kref is taken in install() when
a tty is opened and released in cleanup() when the tty is finally
destroyed; remove() uses kref_put() instead of kfree().
2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove()
frees xmit_buf via tty_port_free_xmit_buf() while a userspace
process may still hold the tty fd and call write(). Fix by
checking for NULL xmit_buf in ipoctal_write_tty().
3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev)
dereferences ipoctal->dev after the ipack_device has been freed
by ipack_device_del(). Fix by caching ipoctal->carrier_owner
during probe() and calling module_put() on the cached pointer
directly in cleanup(), avoiding any access to ipoctal->dev.
Also introduce a "removed" flag in struct ipoctal, set at the start
of __ipoctal_remove(), and checked in every tty op that accesses
hardware resources (port_activate, write_tty, set_termios, hangup,
shutdown). This prevents page faults when devm_ioremap() regions
are unmapped after remove() returns.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Closes: https://lore.kernel.org/lkml/178144969601.60470.1257088106279546587@gmail.com/
Fixes: 05e5027efc9c ("Staging: ipack: move out of staging")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/e3b0a90b07f079c5bcd5ca90d1dd3b79bb29adb5.1782870760.git.xiaopei01@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The position pointer is only advanced if the return value of the write
operation is positive at ksys_write(). Therefore no need to manually
reset it when doing error handling.
Assisted-by: coccinelle # to find it
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260717094519.20656-1-fmancera@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
PPSETTIME64 supplies the timeval fields as s64 values, but
pp_set_timeout() narrows tv_usec to int and calculates tv_sec * HZ in a
signed long. Large positive values can therefore be truncated or overflow
and install an unintended timeout.
Keep both fields as s64, reject a non-canonical microsecond value, and
use timespec64_to_jiffies() to cap excessively large timeouts at
MAX_JIFFY_OFFSET. This is a behavior change because both PPSETTIME
ioctls could previously accept values with tv_usec >= USEC_PER_SEC.
The validation follows the precedent set by sock_set_timeout().
Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260716013923.19494-1-lilinmao@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
cache_setup_properties() sets use_arch_info = true when DT/ACPI
provide no cache nodes and the arch can derive the topology from
CPU registers (e.g. arm64 reading CLIDR_EL1), but still returns the
original -ENOENT. cache_shared_cpu_map_setup() bails on that error
before the new flag can take effect, so the first CPU brought online
always trips a misleading warning:
cacheinfo: Unable to detect cache hierarchy for CPU 0
Subsequent CPUs skip cache_setup_properties() entirely because
use_arch_info is now true, which is why only CPU0 hits it. This is
reproducible on arm64 with the QEMU 'virt' machine, whose default DT
has no cache nodes.
Clear ret after setting use_arch_info so the caller proceeds and
populates the shared cpu map via the arch-supplied leaves.
Fixes: ef9f643a9f8b ("cacheinfo: Add use_arch[|_cache]_info field/function")
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Link: https://patch.msgid.link/20260611-cacheinfo-v2-1-6069ef066cf3@debian.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Pengpeng Hou
Richard Zhu
Haibo Chen
Stefano Radaelli
Thomas Zimmermann
Ville Syrjälä
Yichong Chen
HanQuan
Xiang Mei
Alex Mastro
Rubin Du
Pan Chuang
Myeonghun Pak
Ben Dooks
Griffin Kroah-Hartman
Uwe Kleine-König (The Capable Hub)
Elizabeth Figura
Pei Xiao
Fernando Fernandez Mancera
Linmao Li
Breno Leitao