Changelog in Linux kernel 6.17.8

Author: Qingfang Deng <[email protected]>
Date:   Thu Sep 25 13:10:59 2025 +0800

    6pack: drop redundant locking and refcounting
    
    [ Upstream commit 38b04ed7072e54086102eae2d05d03ffcdb4b695 ]
    
    The TTY layer already serializes line discipline operations with
    tty->ldisc_sem, so the extra disc_data_lock and refcnt in 6pack
    are unnecessary.
    
    Removing them simplifies the code and also resolves a lockdep warning
    reported by syzbot. The warning did not indicate a real deadlock, since
    the write-side lock was only taken in process context with hardirqs
    disabled.
    
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Qingfang Deng <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleg Nesterov <[email protected]>
Date:   Tue Aug 19 18:10:13 2025 +0200

    9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN
    
    [ Upstream commit e8fe3f07a357c39d429e02ca34f740692d88967a ]
    
    p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq)
    if list_empty(&m->req_list).
    
    However, if the pipe is full, we need to read more data and this used to
    work prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writer
    if the pipe is still full").
    
    p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before
    the commit above) triggered the unnecessary wakeup. This wakeup calls
    p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux()
    will notice EPOLLIN and schedule_work(&m->rq).
    
    This no longer happens after the optimization above, change p9_fd_request()
    to use p9_poll_mux() instead of only checking for EPOLLOUT.
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/all/[email protected]/
    Co-developed-by: K Prateek Nayak <[email protected]>
    Signed-off-by: K Prateek Nayak <[email protected]>
    Signed-off-by: Oleg Nesterov <[email protected]>
    Tested-by: K Prateek Nayak <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Dominique Martinet <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Randall P. Embry <[email protected]>
Date:   Fri Sep 26 18:27:30 2025 +0900

    9p: fix /sys/fs/9p/caches overwriting itself
    
    [ Upstream commit 86db0c32f16c5538ddb740f54669ace8f3a1f3d7 ]
    
    caches_show() overwrote its buffer on each iteration,
    so only the last cache tag was visible in sysfs output.
    
    Properly append with snprintf(buf + count, …).
    
    Signed-off-by: Randall P. Embry <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Dominique Martinet <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Randall P. Embry <[email protected]>
Date:   Fri Sep 26 18:27:31 2025 +0900

    9p: sysfs_init: don't hardcode error to ENOMEM
    
    [ Upstream commit 528f218b31aac4bbfc58914d43766a22ab545d48 ]
    
    v9fs_sysfs_init() always returned -ENOMEM on failure;
    return the actual sysfs_create_group() error instead.
    
    Signed-off-by: Randall P. Embry <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Dominique Martinet <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lizhi Hou <[email protected]>
Date:   Sun Aug 3 12:14:50 2025 -0700

    accel/amdxdna: Unify pm and rpm suspend and resume callbacks
    
    [ Upstream commit d2b48f2b30f25997a1ae1ad0cefac68c25f8c330 ]
    
    The suspend and resume callbacks for pm and runtime pm should be same.
    During suspending, it needs to stop all hardware contexts first. And
    the hardware contexts will be restarted after the device is resumed.
    
    Reviewed-by: Mario Limonciello (AMD) <[email protected]>
    Reviewed-by: Maciej Falkowski <[email protected]>
    Signed-off-by: Lizhi Hou <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vered Yavniely <[email protected]>
Date:   Tue Jun 18 19:58:30 2024 +0300

    accel/habanalabs/gaudi2: fix BMON disable configuration
    
    [ Upstream commit b4fd8e56c9a3b614370fde2d45aec1032eb67ddd ]
    
    Change the BMON_CR register value back to its original state before
    enabling, so that BMON does not continue to collect information
    after being disabled.
    
    Signed-off-by: Vered Yavniely <[email protected]>
    Reviewed-by: Koby Elbaz <[email protected]>
    Signed-off-by: Koby Elbaz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konstantin Sinyuk <[email protected]>
Date:   Tue Oct 1 15:52:27 2024 +0300

    accel/habanalabs/gaudi2: read preboot status after recovering from dirty state
    
    [ Upstream commit a0d866bab184161ba155b352650083bf6695e50e ]
    
    Dirty state can occur when the host VM undergoes a reset while the
    device does not. In such a case, the driver must reset the device before
    it can be used again. As part of this reset, the device capabilities
    are zeroed. Therefore, the driver must read the Preboot status again to
    learn the Preboot state, capabilities, and security configuration.
    
    Signed-off-by: Konstantin Sinyuk <[email protected]>
    Reviewed-by: Koby Elbaz <[email protected]>
    Signed-off-by: Koby Elbaz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomer Tayar <[email protected]>
Date:   Sun May 26 16:32:32 2024 +0300

    accel/habanalabs: return ENOMEM if less than requested pages were pinned
    
    [ Upstream commit 9f5067531c9b79318c4e48a933cb2694f53f3de2 ]
    
    EFAULT is currently returned if less than requested user pages are
    pinned. This value means a "bad address" which might be confusing to
    the user, as the address of the given user memory is not necessarily
    "bad".
    
    Modify the return value to ENOMEM, as "out of memory" is more suitable
    in this case.
    
    Signed-off-by: Tomer Tayar <[email protected]>
    Reviewed-by: Koby Elbaz <[email protected]>
    Signed-off-by: Koby Elbaz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Moti Haimovski <[email protected]>
Date:   Sun Sep 8 15:01:26 2024 +0300

    accel/habanalabs: support mapping cb with vmalloc-backed coherent memory
    
    [ Upstream commit 513024d5a0e34fd34247043f1876b6138ca52847 ]
    
    When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return
    addresses from the vmalloc range. If such an address is mapped without
    VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the
    VM_PFNMAP restriction.
    
    Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP
    in the VMA before mapping. This ensures safe mapping and avoids kernel
    crashes. The memory is still driver-allocated and cannot be accessed
    directly by userspace.
    
    Signed-off-by: Moti Haimovski  <[email protected]>
    Reviewed-by: Koby Elbaz <[email protected]>
    Signed-off-by: Koby Elbaz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kaushlendra Kumar <[email protected]>
Date:   Mon Oct 6 14:17:06 2025 +0530

    ACPI: button: Call input_free_device() on failing input device registration
    
    commit 20594cd104abaaabb676c7a2915b150ae5ff093d upstream.
    
    Make acpi_button_add() call input_free_device() when
    input_register_device() fails as required according to the
    documentation of the latter.
    
    Fixes: 0d51157dfaac ("ACPI: button: Eliminate the driver notify callback")
    Signed-off-by: Kaushlendra Kumar <[email protected]>
    Cc: 6.5+ <[email protected]> # 6.5+
    [ rjw: Subject and changelog rewrite, Fixes: tag ]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Wed Oct 8 01:41:44 2025 +0200

    ACPI: fan: Use ACPI handle when retrieving _FST
    
    commit 58764259ebe0c9efd569194444629f6b26f86583 upstream.
    
    Usage of the ACPI device should be phased out in the future, as
    the driver itself is now using the platform bus.
    
    Replace any usage of struct acpi_device in acpi_fan_get_fst() to
    allow users to drop usage of struct acpi_device.
    
    Also extend the integer check to all three package elements.
    
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Wed Oct 8 01:41:46 2025 +0200

    ACPI: fan: Use platform device for devres-related actions
    
    commit d91a1d129b63614fa4c2e45e60918409ce36db7e upstream.
    
    Device-managed resources are cleaned up when the driver unbinds from
    the underlying device. In our case this is the platform device as this
    driver is a platform driver. Registering device-managed resources on
    the associated ACPI device will thus result in a resource leak when
    this driver unbinds.
    
    Ensure that any device-managed resources are only registered on the
    platform device to ensure that they are cleaned up during removal.
    
    Fixes: 35c50d853adc ("ACPI: fan: Add hwmon support")
    Signed-off-by: Armin Wolf <[email protected]>
    Cc: 6.11+ <[email protected]> # 6.11+
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Tony Luck <[email protected]>
Date:   Wed Oct 22 13:45:23 2025 -0700

    ACPI: MRRM: Check revision of MRRM table
    
    [ Upstream commit dc131bcd8d9219f7da533918abcb0d32951b7702 ]
    
    Before trying to parse the MRRM table, check that the table revision
    is the one that is expected.
    
    Fixes: b9020bdb9f76 ("ACPI: MRRM: Minimal parse of ACPI MRRM table")
    Signed-off-by: Tony Luck <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shang song (Lenovo) <[email protected]>
Date:   Mon Aug 25 23:02:29 2025 -0400

    ACPI: PRM: Skip handlers with NULL handler_address or NULL VA
    
    [ Upstream commit 311942ce763e21dacef7e53996d5a1e19b8adab1 ]
    
    If handler_address or mapped VA is NULL, the related buffer address and
    VA can be ignored, so make acpi_parse_prmt() skip the current handler
    in those cases.
    
    Signed-off-by: Shang song (Lenovo) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sakari Ailus <[email protected]>
Date:   Wed Oct 1 13:26:36 2025 +0300

    ACPI: property: Return present device nodes only on fwnode interface
    
    [ Upstream commit d9f866b2bb3eec38b3734f1fed325ec7c55ccdfa ]
    
    fwnode_graph_get_next_subnode() may return fwnode backed by ACPI
    device nodes and there has been no check these devices are present
    in the system, unlike there has been on fwnode OF backend.
    
    In order to provide consistent behaviour towards callers,
    add a check for device presence by introducing
    a new function acpi_get_next_present_subnode(), used as the
    get_next_child_node() fwnode operation that also checks device
    node presence.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Kerneldoc comment and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sam van Kampen <[email protected]>
Date:   Fri Aug 29 14:52:22 2025 +0000

    ACPI: resource: Skip IRQ override on ASUS Vivobook Pro N6506CU
    
    [ Upstream commit 3a351de0d9c86e23b9eca25838b19468aab02f38 ]
    
    Just like the other Vivobooks here, the N6506CU has its keyboard IRQ
    described as ActiveLow in the DSDT, which the kernel overrides to
    EdgeHigh, causing the internal keyboard not to work.
    
    Add the N6506CU to the irq1_level_low_skip_override[] quirk table to fix
    this.
    
    Signed-off-by: Sam van Kampen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Fri Aug 29 16:27:48 2025 +0200

    ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[]
    
    [ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ]
    
    Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI
    device in the _DEP dependency list of the ACPI devices for the camera-
    sensors (which have flags.honor_deps set).
    
    These devices are for an Intel Vision CVS chip for which an out of tree
    driver is available [1].
    
    The camera sensor works fine without a driver being loaded for this
    ACPI device on the 2 laptops this was tested on:
    
    ThinkPad X1 Carbon Gen 12 (Meteor Lake)
    ThinkPad X1 2-in-1 Gen 10 (Arrow Lake)
    
    For now add these HIDs to acpi_ignore_dep_ids[] so that
    acpi_dev_ready_for_enumeration() will return true once the other _DEP
    dependencies are met and an i2c_client for the camera sensor will get
    instantiated.
    
    Link: https://github.com/intel/vision-drivers/ [1]
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sunil V L <[email protected]>
Date:   Mon Aug 18 09:39:12 2025 +0530

    ACPI: scan: Update honor list for RPMI System MSI
    
    [ Upstream commit 4215d1cf59e4b272755f4277a05cd5967935a704 ]
    
    The RPMI System MSI interrupt controller (just like PLIC and APLIC)
    needs to probed prior to devices like GED which use interrupts provided
    by it. Also, it has dependency on the SBI MPXY mailbox device.
    
    Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor
    list so that those dependencies are handled.
    
    Reviewed-by: Atish Patra <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Acked-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sunil V L <[email protected]>
    Signed-off-by: Anup Patel <[email protected]>
    Acked-by: Jassi Brar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Punit Agrawal <[email protected]>
Date:   Fri Oct 24 13:31:25 2025 +0100

    ACPI: SPCR: Check for table version when using precise baudrate
    
    commit 543d35004007a06ef247acf2fc55efa8388aa741 upstream.
    
    Commit 4d330fe54145 ("ACPI: SPCR: Support Precise Baud Rate field")
    added support to use the precise baud rate available since SPCR 1.09
    (revision 4) but failed to check the version of the table provided by
    the firmware.
    
    Accessing an older version of SPCR table causes accesses beyond the
    end of the table and can lead to garbage data to be used for the baud
    rate.
    
    Check the version of the firmware provided SPCR to ensure that the
    precise baudrate is vaild before using it.
    
    Fixes: 4d330fe54145 ("ACPI: SPCR: Support Precise Baud Rate field")
    Signed-off-by: Punit Agrawal <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Chen Pei <[email protected]>
Date:   Sat Sep 13 15:08:15 2025 +0800

    ACPI: SPCR: Support Precise Baud Rate field
    
    [ Upstream commit 4d330fe54145ecfbb657ac01a554fdedf3c1927e ]
    
    The Microsoft Serial Port Console Redirection (SPCR) specification
    revision 1.09 comprises additional field: Precise Baud Rate [1].
    
    It is used to describe non-traditional baud rates (such as those
    used by high-speed UARTs).
    
    It contains a specific non-zero baud rate which overrides the value
    of the Configured Baud Rate field. If this field is zero or not
    present, Configured Baud Rate is used.
    
    Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [1]
    Signed-off-by: Chen Pei <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Corrected typo in the subject ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kaushlendra Kumar <[email protected]>
Date:   Fri Aug 22 11:49:46 2025 +0530

    ACPI: sysfs: Use ACPI_FREE() for freeing an ACPI object
    
    [ Upstream commit 149139ddcb99583fdec8d1eaf7dada41e5896101 ]
    
    Since str_obj is allocated by ACPICA in acpi_evaluate_object_typed(),
    it should be free with ACPI_FREE() rather than with kfree(), so use
    the former instead of the latter for freeing it.
    
    Signed-off-by: Kaushlendra Kumar <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Subject and changelog rewrite ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yuhao Jiang <[email protected]>
Date:   Wed Oct 22 15:07:04 2025 -0500

    ACPI: video: Fix use-after-free in acpi_video_switch_brightness()
    
    commit 8f067aa59430266386b83c18b983ca583faa6a11 upstream.
    
    The switch_brightness_work delayed work accesses device->brightness
    and device->backlight, freed by acpi_video_dev_unregister_backlight()
    during device removal.
    
    If the work executes after acpi_video_bus_unregister_backlight()
    frees these resources, it causes a use-after-free when
    acpi_video_switch_brightness() dereferences device->brightness or
    device->backlight.
    
    Fix this by calling cancel_delayed_work_sync() for each device's
    switch_brightness_work in acpi_video_bus_remove_notify_handler()
    after removing the notify handler that queues the work. This ensures
    the work completes before the memory is freed.
    
    Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress")
    Cc: All applicable <[email protected]>
    Signed-off-by: Yuhao Jiang <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    [ rjw: Changelog edit ]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Wed Aug 20 12:09:26 2025 -0500

    ACPI: video: force native for Lenovo 82K8
    
    [ Upstream commit f144bc21befdcf8e54d2f19b23b4e84f13be01f9 ]
    
    Lenovo 82K8 has a broken brightness control provided by nvidia_wmi_ec.
    Add a quirk to prevent using it.
    
    Reported-by: Wilson Alvarez <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4512
    Tested-by: Wilson Alvarez <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Fri Sep 12 22:00:17 2025 +0200

    ACPICA: dispatcher: Use acpi_ds_clear_operands() in acpi_ds_call_control_method()
    
    [ Upstream commit e9dff11a7a50fcef23fe3e8314fafae6d5641826 ]
    
    When deleting the previous walkstate operand stack
    acpi_ds_call_control_method() was deleting obj_desc->Method.param_count
    operands. But Method.param_count does not necessarily match
    this_walk_state->num_operands, it may be either less or more.
    
    After correcting the for loop to check `i < this_walk_state->num_operands`
    the code is identical to acpi_ds_clear_operands(), so just outright
    replace the code with acpi_ds_clear_operands() to fix this.
    
    Link: https://github.com/acpica/acpica/commit/53fc0220
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Saket Dumbre <[email protected]>
Date:   Fri Sep 12 22:01:04 2025 +0200

    ACPICA: Update dsmethod.c to get rid of unused variable warning
    
    [ Upstream commit 761dc71c6020d6aa68666e96373342d49a7e9d0a ]
    
    All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about
    the unused variable i after the removal of its usage by PR #1031
    addressing Issue #1027
    
    Link: https://github.com/acpica/acpica/commit/6d235320
    Signed-off-by: Saket Dumbre <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Al Viro <[email protected]>
Date:   Fri Sep 12 11:20:27 2025 -0400

    allow finish_no_open(file, ERR_PTR(-E...))
    
    [ Upstream commit fe91e078b60d1beabf5cef4a37c848457a6d2dfb ]
    
    ... allowing any ->lookup() return value to be passed to it.
    
    Reviewed-by: NeilBrown <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adam Holliday <[email protected]>
Date:   Tue Sep 30 11:09:14 2025 -0400

    ALSA: hda/realtek: Add quirk for ASUS ROG Zephyrus Duo
    
    [ Upstream commit 328b80b29a6a165c47fcc04d2bef3e09ed1d28f9 ]
    
    The ASUS ROG Zephyrus Duo 15 SE (GX551QS) with ALC 289 codec requires specific
    pin configuration for proper volume control. Without this quirk, volume
    adjustments produce a muffled sound effect as only certain channels attenuate,
    leaving bass frequency at full volume.
    
    Testing with hdajackretask confirms these pin tweaks fix the issue:
    - Pin 0x17: Internal Speaker (LFE)
    - Pin 0x1e: Internal Speaker
    
    Signed-off-by: Adam Holliday <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shenghao Ding <[email protected]>
Date:   Tue Oct 7 18:37:08 2025 +0800

    ALSA: hda/tas2781: Enable init_profile_id for device initialization
    
    commit 7ddb711b6e0d33e0a673b49f69dff0d950ed60b9 upstream.
    
    Optimize the time consumption of profile switching, init_profile saves
    the common settings of different profiles, such as the dsp coefficients,
    etc, which can greatly reduce the profile switching time comsumption and
    remove the repetitive settings.
    
    Fixes: e83dcd139e77 ("ASoC: tas2781: Add keyword "init" in profile section")
    Signed-off-by: Shenghao Ding <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: John Keeping <[email protected]>
Date:   Mon Sep 15 10:42:19 2025 +0100

    ALSA: serial-generic: remove shared static buffer
    
    [ Upstream commit 84973249011fda3ff292f83439a062fec81ef982 ]
    
    If multiple instances of this driver are instantiated and try to send
    concurrently then the single static buffer snd_serial_generic_tx_work()
    will cause corruption in the data output.
    
    Move the buffer into the per-instance driver data to avoid this.
    
    Signed-off-by: John Keeping <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Roy Vegard Ovesen <[email protected]>
Date:   Sat Sep 27 17:27:30 2025 +0200

    ALSA: usb-audio: add mono main switch to Presonus S1824c
    
    [ Upstream commit 659169c4eb21f8d9646044a4f4e1bc314f6f9d0c ]
    
    The 1824c does not have the A/B switch that the 1810c has,
    but instead it has a mono main switch that sums the two
    main output channels to mono.
    
    Signed-off-by: Roy Vegard Ovesen <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: 75cdae446ddf ("ALSA: usb-audio: don't log messages meant for 1810c when initializing 1824c")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Takashi Iwai <[email protected]>
Date:   Thu Aug 21 17:17:50 2025 +0200

    ALSA: usb-audio: Add validation of UAC2/UAC3 effect units
    
    [ Upstream commit 2aec0b6a6b5395bca7d6fde9c7e9dc391d329698 ]
    
    Just add fixed struct size validations for UAC2 and UAC3 effect
    units.  The descriptor has a variable-length array, so it should be
    validated with a proper function later once when the unit is really
    parsed and used by the driver (currently only referred partially for
    the input terminal parsing).
    
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cryolitia PukNgae <[email protected]>
Date:   Wed Sep 3 13:09:48 2025 +0800

    ALSA: usb-audio: apply quirk for MOONDROP Quark2
    
    [ Upstream commit a73349c5dd27bc544b048e2e2c8ef6394f05b793 ]
    
    It reports a MIN value -15360 for volume control, but will mute when
    setting it less than -14208
    
    Tested-by: Guoli An <[email protected]>
    Signed-off-by: Cryolitia PukNgae <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Roy Vegard Ovesen <[email protected]>
Date:   Mon Sep 22 20:54:10 2025 +0200

    ALSA: usb-audio: don't apply interface quirk to Presonus S1824c
    
    [ Upstream commit d1d6ad7f6686e208aba06b7af3feef7a7cba61cf ]
    
    Testing with a Presonus STUDIO 1824c together with
    a Behringer ultragain digital ADAT device shows that
    using all 3 altno settings works fine.
    
    When selecting sample rate, the driver sets the interface
    to the correct altno setting and the correct number of
    channels is set.
    
    Selecting the correct altno setting via Ardour, Reaper or
    whatever other way to set the sample rate is more convenient
    than re-loading the driver module with device_setup to
    set altno.
    
    Signed-off-by: Roy Vegard Ovesen <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Roy Vegard Ovesen <[email protected]>
Date:   Mon Oct 20 22:15:08 2025 +0200

    ALSA: usb-audio: don't log messages meant for 1810c when initializing 1824c
    
    [ Upstream commit 75cdae446ddffe0a6a991bbb146dee51d9d4c865 ]
    
    The log messages for the PreSonus STUDIO 1810c about
    device_setup are not applicable to the 1824c, and should
    not be logged when 1824c initializes.
    
    Refactor from if statement to switch statement as there
    might be more STUDIO series devices added later.
    
    Fixes: 080564558eb1 ("ALSA: usb-audio: enable support for Presonus Studio 1824c within 1810c file")
    Signed-off-by: Roy Vegard Ovesen <[email protected]>
    Link: https://patch.msgid.link/aPaYTP7ceuABf8c7@ark
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Roy Vegard Ovesen <[email protected]>
Date:   Sat Oct 18 19:18:22 2025 +0200

    ALSA: usb-audio: fix control pipe direction
    
    [ Upstream commit 7963891f7c9c6f759cc9ab7da71406b4234f3dd6 ]
    
    Since the requesttype has USB_DIR_OUT the pipe should be
    constructed with usb_sndctrlpipe().
    
    Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c")
    Signed-off-by: Roy Vegard Ovesen <[email protected]>
    Link: https://patch.msgid.link/aPPL3tBFE_oU-JHv@ark
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yifan Zhang <[email protected]>
Date:   Wed Sep 24 23:19:14 2025 +0800

    amd/amdkfd: enhance kfd process check in switch partition
    
    [ Upstream commit 45da20e00d5da842e17dfc633072b127504f0d0e ]
    
    current switch partition only check if kfd_processes_table is empty.
    kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but
    kfd_process tear down is in kfd_process_wq_release.
    
    consider two processes:
    
    Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node member
    Process B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw
    -> kfd_node tear down.
    
    Process A and B may trigger a race as shown in dmesg log.
    
    This patch is to resolve the race by adding an atomic kfd_process counter
    kfd_processes_count, it increment as create kfd process, decrement as
    finish kfd_process_wq_release.
    
    v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds
    and bug fix. (Philip Yang)
    
    [3966658.307702] divide error: 0000 [#1] SMP NOPTI
    [3966658.350818]  i10nm_edac
    [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted
    [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]
    [3966658.362839]  nfit
    [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]
    [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00
    [3966658.380967]  x86_pkg_temp_thermal
    [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246
    [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000
    [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00
    [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4
    [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000
    [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800
    [3966658.391533] FS:  0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000
    [3966658.391534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0
    [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    [3966658.391536] PKRU: 55555554
    [3966658.391536] Call Trace:
    [3966658.391674]  deallocate_sdma_queue+0x38/0xa0 [amdgpu]
    [3966658.391762]  process_termination_cpsch+0x1ed/0x480 [amdgpu]
    [3966658.399754]  intel_powerclamp
    [3966658.402831]  kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]
    [3966658.402908]  kfd_process_wq_release+0x1a/0x1a0 [amdgpu]
    [3966658.410516]  coretemp
    [3966658.434016]  process_one_work+0x1ad/0x380
    [3966658.434021]  worker_thread+0x49/0x310
    [3966658.438963]  kvm_intel
    [3966658.446041]  ? process_one_work+0x380/0x380
    [3966658.446045]  kthread+0x118/0x140
    [3966658.446047]  ? __kthread_bind_mask+0x60/0x60
    [3966658.446050]  ret_from_fork+0x1f/0x30
    [3966658.446053] Modules linked in: kpatch_20765354(OEK)
    [3966658.455310]  kvm
    [3966658.464534]  mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)
    [3966658.473462]  idxd_mdev
    [3966658.482306]  kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqos_hotfixes(OE) rfkill uio_pci_generic uio cuse fuse nf_tables nfnetlink intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common i10nm_edac nfit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm idxd_mdev
    [3966658.491237]  vfio_pci
    [3966658.501196]  vfio_pci vfio_virqfd mdev vfio_iommu_type1 vfio iax_crypto intel_pmt_telemetry iTCO_wdt intel_pmt_class iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq
    [3966658.508537]  vfio_virqfd
    [3966658.517569]  snd_seq_device ipmi_ssif isst_if_mbox_pci isst_if_mmio pcspkr snd_pcm idxd intel_uncore ses isst_if_common intel_vsec idxd_bus enclosure snd_timer mei_me snd i2c_i801 i2c_smbus mei i2c_ismt soundcore joydev acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad vfat fat
    [3966658.526851]  mdev
    [3966658.536096]  nfsd auth_rpcgss nfs_acl lockd grace slb_vtoa(OE) sunrpc dm_mod hookers mlx5_ib(OE) ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm mlx5_core(OE) mlxfw(OE)
    [3966658.540381]  vfio_iommu_type1
    [3966658.544341]  nvme mpt3sas tls drm nvme_core pci_hyperv_intf raid_class psample libcrc32c crc32c_intel mlxdevm(OE) i2c_core
    [3966658.551254]  vfio
    [3966658.558742]  scsi_transport_sas wmi pinctrl_emmitsburg sd_mod t10_pi sg ahci libahci libata rdma_ucm(OE) ib_uverbs(OE) rdma_cm(OE) iw_cm(OE) ib_cm(OE) ib_umad(OE) ib_core(OE) ib_ucm(OE) mlx_compat(OE)
    [3966658.563004]  iax_crypto
    [3966658.570988]  [last unloaded: diagnose]
    [3966658.571027] ---[ end trace cc9dbb180f9ae537 ]---
    
    Signed-off-by: Yifan Zhang <[email protected]>
    Reviewed-by: Philip.Yang<[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yifan Zhang <[email protected]>
Date:   Tue Sep 16 21:21:15 2025 +0800

    amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw
    
    [ Upstream commit 99d7181bca34e96fbf61bdb6844918bdd4df2814 ]
    
    There is race in amdgpu_amdkfd_device_fini_sw and interrupt.
    if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and
      kfree(kfd), and KGD interrupt generated.
    
    kernel panic log:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000098
    amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP
    
    PGD d78c68067 P4D d78c68067
    
    kfd kfd: amdgpu: Allocated 3969056 bytes on gart
    
    PUD 1465b8067 PMD @
    
    Oops: @002 [#1] SMP NOPTI
    
    kfd kfd: amdgpu: Total number of KFD nodes to be created: 4
    CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K
    
    RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40
    
    Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 <fO> OF b1 17 75 Ba 4c 89 e@ 41 Sc
    
    89 c6 e8 07 38 5d
    
    RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046
    
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018
    0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098
    ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020
    0000000000000000 R11: 0000000000000000 R12: 0900000000000002
    ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00
    
    CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033
    
    CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400
    
    PKRU: 55555554
    
    Call Trace:
    
    <IRQ>
    
    kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]
    
    ? amdgpu_fence_process+0xa4/0x150 [amdgpu]
    
    kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace
    
    amdgpu_irq_dispatch+0x165/0x210 [amdgpu]
    
    amdgpu_ih_process+0x80/0x100 [amdgpu]
    
    amdgpu: Virtual CRAT table created for GPU
    
    amdgpu_irq_handler+0x1f/@x60 [amdgpu]
    
    __handle_irq_event_percpu+0x3d/0x170
    
    amdgpu: Topology: Add dGPU node [0x74a2:0x1002]
    
    handle_irq_event+0x5a/@xcO
    
    handle_edge_irq+0x93/0x240
    
    kfd kfd: amdgpu: KFD node 1 partition @ size 49148M
    
    asm_call_irq_on_stack+0xf/@x20
    
    </IRQ>
    
    common_interrupt+0xb3/0x130
    
    asm_common_interrupt+0x1le/0x40
    
    5.10.134-010.a1i5000.a18.x86_64 #1
    
    Signed-off-by: Yifan Zhang <[email protected]>
    Reviewed-by: Philip Yang<[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kees Cook <[email protected]>
Date:   Sat Aug 30 19:23:53 2025 -0700

    arc: Fix __fls() const-foldability via __builtin_clzl()
    
    [ Upstream commit a3fecb9160482367365cc384c59dd220b162b066 ]
    
    While tracking down a problem where constant expressions used by
    BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
    initializer was convincing the compiler that it couldn't track the state
    of the prior statically initialized value. Tracing this down found that
    ffs() was used in the initializer macro, but since it wasn't marked with
    __attribute__const__, the compiler had to assume the function might
    change variable states as a side-effect (which is not true for ffs(),
    which provides deterministic math results).
    
    For arc architecture with CONFIG_ISA_ARCV2=y, the __fls() function
    uses __builtin_arc_fls() which lacks GCC's const attribute, preventing
    compile-time constant folding, and KUnit testing of ffs/fls fails on
    arc[3]. A patch[2] to GCC to solve this has been sent.
    
    Add a fix for this by handling compile-time constants with the standard
    __builtin_clzl() builtin (which has const attribute) while preserving
    the optimized arc-specific builtin for runtime cases. This has the added
    benefit of skipping runtime calculation of compile-time constant values.
    Even with the GCC bug fixed (which is about "attribute const") this is a
    good change to avoid needless runtime costs, and should be done
    regardless of the state of GCC's bug.
    
    Build tested ARCH=arc allyesconfig with GCC arc-linux 15.2.0.
    
    Link: https://github.com/KSPP/linux/issues/364 [1]
    Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [3]
    Signed-off-by: Kees Cook <[email protected]>
    Acked-by: Vineet Gupta <[email protected]>
    Signed-off-by: Yury Norov (NVIDIA) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Harini T <[email protected]>
Date:   Thu Jul 10 11:43:09 2025 +0530

    arm64: versal-net: Update rtc calibration value
    
    [ Upstream commit b60b74f82e3ed4910a5f96a412e89bdd44875842 ]
    
    As per the design specification
    "The 16-bit Seconds Calibration Value represents the number of
    Oscillator Ticks that are required to measure the largest time period
    that is less than or equal to 1 second.
    For an oscillator that is 32.768kHz, this value will be 0x7FFF."
    
    Signed-off-by: Harini T <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michal Simek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Quanyang Wang <[email protected]>
Date:   Tue Sep 2 09:56:18 2025 +0200

    arm64: zynqmp: Disable coresight by default
    
    [ Upstream commit 0e3f9140ad04dca9a6a93dd6a6decdc53fd665ca ]
    
    When secure-boot mode of bootloader is enabled, the registers of
    coresight are not permitted to access that's why disable it by default.
    
    Signed-off-by: Quanyang Wang <[email protected]>
    Signed-off-by: Michal Simek <[email protected]>
    Link: https://lore.kernel.org/r/7e308b8efe977c4912079b4d1b1ab3d24908559e.1756799774.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Radhey Shyam Pandey <[email protected]>
Date:   Tue Sep 2 09:56:19 2025 +0200

    arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106
    
    [ Upstream commit 767ecf9da7b31e5c0c22c273001cb2784705fe8c ]
    
    On a few zcu106 boards USB devices (Dell MS116 USB Optical Mouse, Dell USB
    Entry Keyboard) are not enumerated on linux boot due to commit
    'b8745e7eb488 ("arm64: zynqmp: Fix usb node drive strength and slew
    rate")'.
    
    To fix it as a workaround revert to working version and then investigate
    at board level why drive strength from 12mA to 4mA and slew from fast to
    slow is not working.
    
    Signed-off-by: Radhey Shyam Pandey <[email protected]>
    Signed-off-by: Michal Simek <[email protected]>
    Link: https://lore.kernel.org/r/85a70cb014ec1f07972fccb60b875596eeaa6b5c.1756799774.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nicolas Ferre <[email protected]>
Date:   Wed Aug 27 16:54:27 2025 +0200

    ARM: at91: pm: save and restore ACR during PLL disable/enable
    
    [ Upstream commit 0c01fe49651d387776abed6a28541e80c8a93319 ]
    
    Add a new word in assembly to store ACR value during the calls
    to at91_plla_disable/at91_plla_enable macros and use it.
    
    Signed-off-by: Nicolas Ferre <[email protected]>
    [[email protected]: remove ACR_DEFAULT_PLLA loading]
    Signed-off-by: Cristian Birsan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Schwöbel <[email protected]>
Date:   Wed Sep 3 19:19:46 2025 +0300

    ARM: tegra: p880: set correct touchscreen clipping
    
    [ Upstream commit b49a73a08100ab139e07cfa7ca36e9b15787d0ab ]
    
    Existing touchscreen clipping is too small and causes problems with
    touchscreen accuracy.
    
    Signed-off-by: Jonas Schwöbel <[email protected]>
    Signed-off-by: Svyatoslav Ryhel <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Svyatoslav Ryhel <[email protected]>
Date:   Sat Sep 6 09:29:31 2025 +0300

    ARM: tegra: transformer-20: add missing magnetometer interrupt
    
    [ Upstream commit cca41614d15ce2bbc2c661362d3eafe53c9990af ]
    
    Add missing interrupt to magnetometer node.
    
    Tested-by: Winona Schroeer-Smith <[email protected]> # ASUS SL101
    Tested-by: Antoni Aloy Torrens <[email protected]> # ASUS TF101
    Signed-off-by: Svyatoslav Ryhel <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Svyatoslav Ryhel <[email protected]>
Date:   Sat Sep 6 09:29:32 2025 +0300

    ARM: tegra: transformer-20: fix audio-codec interrupt
    
    [ Upstream commit 3f973d78d176768fa7456def97f0b9824235024f ]
    
    Correct audio-codec interrupt should be PX3 while PX1 is used for external
    microphone detection.
    
    Tested-by: Winona Schroeer-Smith <[email protected]> # ASUS SL101
    Tested-by: Antoni Aloy Torrens <[email protected]> # ASUS TF101
    Signed-off-by: Svyatoslav Ryhel <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mohammad Rafi Shaik <[email protected]>
Date:   Fri Aug 15 22:53:53 2025 +0530

    ASoC: codecs: wsa883x: Handle shared reset GPIO for WSA883x speakers
    
    [ Upstream commit cf65182247761f7993737b710afe8c781699356b ]
    
    On some Qualcomm platforms such as QCS6490-RB3Gen2, the multiple
    WSA8830/WSA8835 speaker amplifiers share a common reset (shutdown) GPIO.
    
    To handle such scenario, use the reset controller framework and its
    "reset-gpio" driver to handle such case. This allows proper handling
    of all WSA883x speaker amplifiers on QCS6490-RB3Gen2 board.
    
    Signed-off-by: Mohammad Rafi Shaik <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Srinivas Kandagatla <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Richard Fitzgerald <[email protected]>
Date:   Thu Oct 16 10:48:44 2025 +0100

    ASoC: cs-amp-lib-test: Fix missing include of kunit/test-bug.h
    
    [ Upstream commit ec20584f25233bfe292c8e18f9a429dfaff58a49 ]
    
    cs-amp-lib-test uses functions from kunit/test-bug.h but wasn't
    including it.
    
    This error was found by smatch.
    
    Fixes: 177862317a98 ("ASoC: cs-amp-lib: Add KUnit test for calibration helpers")
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shimrra Shai <[email protected]>
Date:   Thu Aug 14 23:20:22 2025 -0500

    ASoC: es8323: add proper left/right mixer controls via DAPM
    
    [ Upstream commit 7e39ca4056d11fef6b90aedd9eeeb3e070d3ce9f ]
    
    Add proper DAC and mixer controls to DAPM; no initialization in
    es8323_probe.
    
    Signed-off-by: Shimrra Shai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shimrra Shai <[email protected]>
Date:   Wed Aug 13 20:49:19 2025 -0500

    ASoC: es8323: enable DAPM power widgets for playback DAC and output
    
    [ Upstream commit 258384d8ce365dddd6c5c15204de8ccd53a7ab0a ]
    
    Enable DAPM widgets for power and volume control of playback.
    
    Signed-off-by: Shimrra Shai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shimrra Shai <[email protected]>
Date:   Thu Aug 14 23:20:21 2025 -0500

    ASoC: es8323: remove DAC enablement write from es8323_probe
    
    [ Upstream commit 33bc29123d26f7caa7d11f139e153e39104afc6c ]
    
    Remove initialization of the DAC and mixer enablement bits from the
    es8323_probe routine. This really should be handled by the DAPM
    subsystem.
    
    Signed-off-by: Shimrra Shai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shengjiu Wang <[email protected]>
Date:   Thu Oct 23 14:45:38 2025 +0800

    ASoC: fsl_micfil: correct the endian format for DSD
    
    [ Upstream commit ba3a5e1aeaa01ea67067d725710a839114214fc6 ]
    
    The DSD format supported by micfil is that oldest bit is in bit 31, so
    the format should be DSD little endian format.
    
    Fixes: 21aa330fec31 ("ASoC: fsl_micfil: Add decimation filter bypass mode support")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shengjiu Wang <[email protected]>
Date:   Thu Oct 23 14:45:37 2025 +0800

    ASoC: fsl_sai: fix bit order for DSD format
    
    [ Upstream commit d9fbe5b0bf7e2d1e20d53e4e2274f9f61bdcca98 ]
    
    The DSD little endian format requires the msb first, because oldest bit
    is in msb.
    found this issue by testing with pipewire.
    
    Fixes: c111c2ddb3fd ("ASoC: fsl_sai: Add PDM daifmt support")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Maarten Zanders <[email protected]>
Date:   Fri Oct 24 15:57:15 2025 +0200

    ASoC: fsl_sai: Fix sync error in consumer mode
    
    [ Upstream commit b2dd1d0d322dce5f331961c927e775b84014d5ab ]
    
    When configured for default synchronisation (Rx syncs to Tx) and the
    SAI operates in consumer mode (clocks provided externally to Tx), a
    synchronisation error occurs on Tx on the first attempt after device
    initialisation when the playback stream is started while a capture
    stream is already active. This results in channel shift/swap on the
    playback stream.
    Subsequent streams (ie after that first failing one) always work
    correctly, no matter the order, with or without the other stream active.
    
    This issue was observed (and fix tested) on an i.MX6UL board connected
    to an ADAU1761 codec, where the codec provides both frame and bit clock
    (connected to TX pins).
    
    To fix this, always initialize the 'other' xCR4 and xCR5 registers when
    we're starting a stream which is synced to the opposite one, irregardless
    of the producer/consumer status.
    
    Fixes: 51659ca069ce ("ASoC: fsl-sai: set xCR4/xCR5/xMR for SAI master mode")
    
    Signed-off-by: Maarten Zanders <[email protected]>
    Reviewed-by: Shengjiu Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cezary Rojewski <[email protected]>
Date:   Thu Oct 23 11:23:47 2025 +0200

    ASoC: Intel: avs: Disable periods-elapsed work when closing PCM
    
    [ Upstream commit 845f716dc5f354c719f6fda35048b6c2eca99331 ]
    
    avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio
    stream while period-elapsed work services its IRQs. As the former
    frees the DAI's private context, these two operations shall be
    synchronized to avoid slab-use-after-free or worse errors.
    
    Fixes: 0dbb186c3510 ("ASoC: Intel: avs: Update stream status in a separate thread")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cezary Rojewski <[email protected]>
Date:   Mon Aug 18 12:41:25 2025 +0200

    ASoC: Intel: avs: Do not share the name pointer between components
    
    [ Upstream commit 4dee5c1cc439b0d5ef87f741518268ad6a95b23d ]
    
    By sharing 'name' directly, tearing down components may lead to
    use-after-free errors. Duplicate the name to avoid that.
    
    At the same time, update the order of operations - since commit
    cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via
    config") the framework does not override component->name if set before
    invoking the initializer.
    
    Reviewed-by: Amadeusz Sławiński <[email protected]>
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cezary Rojewski <[email protected]>
Date:   Thu Oct 23 11:23:46 2025 +0200

    ASoC: Intel: avs: Unprepare a stream when XRUN occurs
    
    [ Upstream commit cfca1637bc2b6b1e4f191d2f0b25f12402fbbb26 ]
    
    The pcm->prepare() function may be called multiple times in a row by the
    userspace, as mentioned in the documentation. The driver shall take that
    into account and prevent redundancy. However, the exact same function is
    called during XRUNs and in such case, the particular stream shall be
    reset and setup anew.
    
    Fixes: 9114700b496c ("ASoC: Intel: avs: Generic PCM FE operations")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Haotian Zhang <[email protected]>
Date:   Tue Oct 21 01:04:40 2025 +0800

    ASoC: mediatek: Fix double pm_runtime_disable in remove functions
    
    [ Upstream commit 79a6f2da168543c0431ade57428f673c19c5b72f ]
    
    Both mt8195-afe-pcm and mt8365-afe-pcm drivers use devm_pm_runtime_enable()
    in probe function, which automatically calls pm_runtime_disable() on device
    removal via devres mechanism. However, the remove callbacks explicitly call
    pm_runtime_disable() again, resulting in double pm_runtime_disable() calls.
    
    Fix by removing the redundant pm_runtime_disable() calls from remove
    functions, letting the devres framework handle it automatically.
    
    Fixes: 2ca0ec01d49c ("ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe")
    Fixes: e1991d102bc2 ("ASoC: mediatek: mt8365: Add the AFE driver support")
    Signed-off-by: Haotian Zhang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Terry Cheong <[email protected]>
Date:   Wed Jul 23 17:20:11 2025 +0800

    ASoC: mediatek: Use SND_JACK_AVOUT for HDMI/DP jacks
    
    [ Upstream commit 8ed2dca4df2297177e0edcb7e0c72ef87f3fd81a ]
    
    The SND_JACK_AVOUT is a more specific jack type for HDMI and DisplayPort.
    Updatae the MediaTek drivers to use such jack type, allowing system to
    determine the device type based on jack event.
    
    Signed-off-by: Terry Cheong <[email protected]>
    Reviewed-by: Chen-Yu Tsai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Valerio Setti <[email protected]>
Date:   Tue Oct 7 00:12:19 2025 +0200

    ASoC: meson: aiu-encoder-i2s: fix bit clock polarity
    
    [ Upstream commit 4c4ed5e073a923fb3323022e1131cb51ad8df7a0 ]
    
    According to I2S specs audio data is sampled on the rising edge of the
    clock and it can change on the falling one. When operating in normal mode
    this SoC behaves the opposite so a clock polarity inversion is required
    in this case.
    
    This was tested on an OdroidC2 (Amlogic S905 SoC) board.
    
    Signed-off-by: Valerio Setti <[email protected]>
    Reviewed-by: Jerome Brunet <[email protected]>
    Tested-by: Jerome Brunet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niranjan H Y <[email protected]>
Date:   Fri Sep 12 14:06:20 2025 +0530

    ASoC: ops: improve snd_soc_get_volsw
    
    [ Upstream commit a0ce874cfaaab9792d657440b9d050e2112f6e4d ]
    
    * clamp the values if the register value read is
      out of range
    
    Signed-off-by: Niranjan H Y <[email protected]>
    [This patch originally had two changes in it, I removed a second buggy
     one -- broonie]
    --
    v5:
     - remove clamp parameter
     - move the boundary check after sign-bit extension
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexey Klimov <[email protected]>
Date:   Thu Sep 11 16:43:40 2025 +0100

    ASoC: qcom: sc8280xp: explicitly set S16LE format in sc8280xp_be_hw_params_fixup()
    
    [ Upstream commit 9565c9d53c5b440f0dde6fa731a99c1b14d879d2 ]
    
    Setting format to s16le is required for compressed playback on compatible
    soundcards.
    
    Signed-off-by: Alexey Klimov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Srinivas Kandagatla <[email protected]>
Date:   Fri Oct 17 09:52:56 2025 +0100

    ASoC: qdsp6: q6asm: do not sleep while atomic
    
    commit fdbb53d318aa94a094434e5f226617f0eb1e8f22 upstream.
    
    For some reason we ended up kfree between spinlock lock and unlock,
    which can sleep.
    
    move the kfree out of spinlock section.
    
    Fixes: a2a5d30218fd ("ASoC: qdsp6: q6asm: Add support to memory map and unmap")
    Cc: [email protected]
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Kuninori Morimoto <[email protected]>
Date:   Thu Sep 25 05:17:21 2025 +0000

    ASoC: renesas: msiof: add .symmetric_xxx on snd_soc_dai_driver
    
    [ Upstream commit ab77fa5533e4d1dcfdd2711b9b1e166e4ed57dab ]
    
    MSIOF TX/RX are sharing same clock. Adds .symmetric_xxx flags.
    
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Tested-by: Yusuke Goda <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuninori Morimoto <[email protected]>
Date:   Thu Sep 25 05:17:17 2025 +0000

    ASoC: renesas: msiof: set SIFCTR register
    
    [ Upstream commit 130947b4681c515a5e5a7961244b502de2de85ca ]
    
    Because it uses DMAC, we would like to transfer data if there is any data.
    Set SIFCTR for it.
    
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Tested-by: Yusuke Goda <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuninori Morimoto <[email protected]>
Date:   Thu Sep 25 05:17:27 2025 +0000

    ASoC: renesas: msiof: tidyup DMAC stop timing
    
    [ Upstream commit 25aa058b5c83a3c455a2a288bb3295c0b234f093 ]
    
    Current DMAC is stopped before HW stop, but it might be cause of
    sync error. Stop HW first.
    
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Tested-by: Yusuke Goda <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuninori Morimoto <[email protected]>
Date:   Thu Sep 25 05:17:11 2025 +0000

    ASoC: renesas: msiof: use reset controller
    
    [ Upstream commit 25226abc1affd4bf4f6dd415d475b76e7a273fa8 ]
    
    MSIOF has TXRST/RXRST to reset FIFO, but it shouldn't be used during SYNC
    signal was asserted, because it will be cause of HW issue.
    
    When MSIOF is used as Sound driver, this driver is assuming it is used as
    clock consumer mode (= Codec is clock provider). This means, it can't
    control SYNC signal by itself.
    
    We need to use SW reset (= reset_control_xxx()) instead of TXRST/RXRST.
    
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Tested-by: Yusuke Goda <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Claudiu Beznea <[email protected]>
Date:   Wed Oct 29 16:11:34 2025 +0200

    ASoC: renesas: rz-ssi: Use proper dma_buffer_pos after resume
    
    commit 22897e568646de5907d4981eae6cc895be2978d1 upstream.
    
    When the driver supports DMA, it enqueues four DMA descriptors per
    substream before the substream is started. New descriptors are enqueued in
    the DMA completion callback, and each time a new descriptor is queued, the
    dma_buffer_pos is incremented.
    
    During suspend, the DMA transactions are terminated. There might be cases
    where the four extra enqueued DMA descriptors are not completed and are
    instead canceled on suspend. However, the cancel operation does not take
    into account that the dma_buffer_pos was already incremented.
    
    Previously, the suspend code reinitialized dma_buffer_pos to zero, but this
    is not always correct.
    
    To avoid losing any audio periods during suspend/resume and to prevent
    clip sound, save the completed DMA buffer position in the DMA callback and
    reinitialize dma_buffer_pos on resume.
    
    Cc: [email protected]
    Fixes: 1fc778f7c833a ("ASoC: renesas: rz-ssi: Add suspend to RAM support")
    Signed-off-by: Claudiu Beznea <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Shuming Fan <[email protected]>
Date:   Tue Oct 7 16:09:50 2025 +0800

    ASoC: rt722: add settings for rt722VB
    
    [ Upstream commit a27539810e1e61efcfdeb51777ed875dc61e9d49 ]
    
    This patch adds settings for RT722VB.
    
    Signed-off-by: Shuming Fan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bard Liao <[email protected]>
Date:   Mon Oct 27 22:00:12 2025 +0800

    ASoC: soc_sdw_utils: remove cs42l43 component_name
    
    [ Upstream commit 45f5c9eec43a9bf448f46562f146810831916cc9 ]
    
    "spk:cs42l43-spk" component string will be added conditionally by
    asoc_sdw_cs42l43_spk_rtd_init(). We should not add "spk:cs42l43"
    unconditionally.
    
    Fixes: c61da55412a0 ("ASoC: sdw_utils: Add missed component_name strings for speaker amps")
    Signed-off-by: Bard Liao <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Charles Keepax <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Ujfalusi <[email protected]>
Date:   Fri Aug 29 13:53:03 2025 +0300

    ASoC: SOF: ipc4-pcm: Add fixup for channels
    
    [ Upstream commit 6ad299a9b968e1c63988e2a327295e522cf6bbf5 ]
    
    We can have modules in path which can change the number of channels and in
    this case the BE params needs to be adjusted to configure the DAI according
    to the copier configuration.
    
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Seppo Ingalsuo <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Olivier Moysan <[email protected]>
Date:   Tue Sep 16 14:31:18 2025 +0200

    ASoC: stm32: sai: manage context in set_sysclk callback
    
    [ Upstream commit 27fa1a8b2803dfd88c39f03b0969c55f667cdc43 ]
    
    The mclk direction now needs to be specified in endpoint node with
    "system-clock-direction-out" property. However some calls to the
    set_sysclk callback, related to CPU DAI clock, result in unbalanced
    calls to clock API.
    The set_sysclk callback in STM32 SAI driver is intended only for mclk
    management. So it is relevant to ensure that calls to set_sysclk are
    related to mclk only.
    Since the master clock is handled only at runtime, skip the calls to
    set_sysclk in the initialization phase.
    
    Signed-off-by: Olivier Moysan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shenghao Ding <[email protected]>
Date:   Sun Aug 3 21:11:10 2025 +0800

    ASoC: tas2781: Add keyword "init" in profile section
    
    [ Upstream commit e83dcd139e776ebb86d5e88e13282580407278e4 ]
    
    Since version 0x105, the keyword 'init' was introduced into the profile,
    which is used for chip initialization, particularly to store common
    settings for other non-initialization profiles.
    
    Signed-off-by: Shenghao Ding <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Primoz Fiser <[email protected]>
Date:   Thu Sep 25 10:59:29 2025 +0200

    ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007
    
    [ Upstream commit 733a763dd8b3ac2858dd238a91bb3a2fdff4739e ]
    
    The problem of having class-D initialization sequence in probe using
    regmap_register_patch() is that it will do hardware register writes
    immediately after being called as it bypasses regcache. Afterwards, in
    aic3x_init() we also perform codec soft reset, rendering class-D init
    sequence pointless. This issue is even more apparent when using reset
    GPIO line, since in that case class-D amplifier initialization fails
    with "Failed to init class D: -5" message as codec is already held in
    reset state after requesting the reset GPIO and hence hardware I/O
    fails with -EIO errno.
    
    Thus move class-D amplifier initialization sequence from probe function
    to aic3x_set_power() just before the usual regcache sync. Use bypassed
    regmap_multi_reg_write_bypassed() function to make sure, class-D init
    sequence is performed in proper order as described in the datasheet.
    
    Signed-off-by: Primoz Fiser <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sven Eckelmann <[email protected]>
Date:   Sat Sep 27 19:39:08 2025 +0200

    batman-adv: Release references to inactive interfaces
    
    commit f12b69d8f22824a07f17c1399c99757072de73e0 upstream.
    
    Trying to dump the originators or the neighbors via netlink for a meshif
    with an inactive primary interface is not allowed. The dump functions were
    checking this correctly but they didn't handle non-existing primary
    interfaces and existing _inactive_ interfaces differently.
    
    (Primary) batadv_hard_ifaces hold a references to a net_device. And
    accessing them is only allowed when either being in a RCU/spinlock
    protected section or when holding a valid reference to them. The netlink
    dump functions use the latter.
    
    But because the missing specific error handling for inactive primary
    interfaces, the reference was never dropped. This reference counting error
    was only detected when the interface should have been removed from the
    system:
    
      unregister_netdevice: waiting for batadv_slave_0 to become free. Usage count = 2
    
    Cc: [email protected]
    Fixes: 6ecc4fd6c2f4 ("batman-adv: netlink: reduce duplicate code by returning interfaces")
    Reported-by: [email protected]
    Reported-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Sven Eckelmann <[email protected]>
    Signed-off-by: Simon Wunderlich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yu Kuai <[email protected]>
Date:   Tue Sep 23 15:55:20 2025 +0800

    blk-cgroup: fix possible deadlock while configuring policy
    
    [ Upstream commit 5d726c4dbeeddef612e6bed27edd29733f4d13af ]
    
    Following deadlock can be triggered easily by lockdep:
    
    WARNING: possible circular locking dependency detected
    6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted
    ------------------------------------------------------
    check/1334 is trying to acquire lock:
    ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180
    
    but task is already holding lock:
    ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}:
           blk_queue_enter+0x40b/0x470
           blkg_conf_prep+0x7b/0x3c0
           tg_set_limit+0x10a/0x3e0
           cgroup_file_write+0xc6/0x420
           kernfs_fop_write_iter+0x189/0x280
           vfs_write+0x256/0x490
           ksys_write+0x83/0x190
           __x64_sys_write+0x21/0x30
           x64_sys_call+0x4608/0x4630
           do_syscall_64+0xdb/0x6b0
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}:
           __mutex_lock+0xd8/0xf50
           mutex_lock_nested+0x2b/0x40
           wbt_init+0x17e/0x280
           wbt_enable_default+0xe9/0x140
           blk_register_queue+0x1da/0x2e0
           __add_disk+0x38c/0x5d0
           add_disk_fwnode+0x89/0x250
           device_add_disk+0x18/0x30
           virtblk_probe+0x13a3/0x1800
           virtio_dev_probe+0x389/0x610
           really_probe+0x136/0x620
           __driver_probe_device+0xb3/0x230
           driver_probe_device+0x2f/0xe0
           __driver_attach+0x158/0x250
           bus_for_each_dev+0xa9/0x130
           driver_attach+0x26/0x40
           bus_add_driver+0x178/0x3d0
           driver_register+0x7d/0x1c0
           __register_virtio_driver+0x2c/0x60
           virtio_blk_init+0x6f/0xe0
           do_one_initcall+0x94/0x540
           kernel_init_freeable+0x56a/0x7b0
           kernel_init+0x2b/0x270
           ret_from_fork+0x268/0x4c0
           ret_from_fork_asm+0x1a/0x30
    
    -> #0 (&q->sysfs_lock){+.+.}-{4:4}:
           __lock_acquire+0x1835/0x2940
           lock_acquire+0xf9/0x450
           __mutex_lock+0xd8/0xf50
           mutex_lock_nested+0x2b/0x40
           blk_unregister_queue+0x53/0x180
           __del_gendisk+0x226/0x690
           del_gendisk+0xba/0x110
           sd_remove+0x49/0xb0 [sd_mod]
           device_remove+0x87/0xb0
           device_release_driver_internal+0x11e/0x230
           device_release_driver+0x1a/0x30
           bus_remove_device+0x14d/0x220
           device_del+0x1e1/0x5a0
           __scsi_remove_device+0x1ff/0x2f0
           scsi_remove_device+0x37/0x60
           sdev_store_delete+0x77/0x100
           dev_attr_store+0x1f/0x40
           sysfs_kf_write+0x65/0x90
           kernfs_fop_write_iter+0x189/0x280
           vfs_write+0x256/0x490
           ksys_write+0x83/0x190
           __x64_sys_write+0x21/0x30
           x64_sys_call+0x4608/0x4630
           do_syscall_64+0xdb/0x6b0
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    other info that might help us debug this:
    
    Chain exists of:
      &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&q->q_usage_counter(queue)#3);
                                   lock(&q->rq_qos_mutex);
                                   lock(&q->q_usage_counter(queue)#3);
      lock(&q->sysfs_lock);
    
    Root cause is that queue_usage_counter is grabbed with rq_qos_mutex
    held in blkg_conf_prep(), while queue should be freezed before
    rq_qos_mutex from other context.
    
    The blk_queue_enter() from blkg_conf_prep() is used to protect against
    policy deactivation, which is already protected with blkcg_mutex, hence
    convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,
    consider that blkcg_mutex is held after queue is freezed from policy
    deactivation, also convert blkg_alloc() to use GFP_NOIO.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Keith Busch <[email protected]>
Date:   Wed Aug 27 07:12:51 2025 -0700

    block: check for valid bio while splitting
    
    [ Upstream commit fec2e705729dc93de5399d8b139e4746805c3d81 ]
    
    We're already iterating every segment, so check these for a valid IO
    lengths at the same time. Individual segment lengths will not be checked
    on passthrough commands. The read/write command segments must be sized
    to the dma alignment.
    
    Signed-off-by: Keith Busch <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Damien Le Moal <[email protected]>
Date:   Mon Oct 27 09:27:32 2025 +0900

    block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL
    
    commit 12a1c9353c47c0fb3464eba2d78cdf649dee1cf7 upstream.
    
    REQ_OP_ZONE_RESET_ALL is a zone management request. Fix
    op_is_zone_mgmt() to return true for that operation, like it already
    does for REQ_OP_ZONE_RESET.
    
    While no problems were reported without this fix, this change allows
    strengthening checks in various block device drivers (scsi sd,
    virtioblk, DM) where op_is_zone_mgmt() is used to verify that a zone
    management command is not being issued to a regular block device.
    
    Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations")
    Cc: [email protected]
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Damien Le Moal <[email protected]>
Date:   Mon Oct 27 09:27:33 2025 +0900

    block: make REQ_OP_ZONE_OPEN a write operation
    
    commit 19de03b312d69a7e9bacb51c806c6e3f4207376c upstream.
    
    A REQ_OP_OPEN_ZONE request changes the condition of a sequential zone of
    a zoned block device to the explicitly open condition
    (BLK_ZONE_COND_EXP_OPEN). As such, it should be considered a write
    operation.
    
    Change this operation code to be an odd number to reflect this. The
    following operation numbers are changed to keep the numbering compact.
    
    No problems were reported without this change as this operation has no
    data. However, this unifies the zone operation to reflect that they
    modify the device state and also allows strengthening checks in the
    block layer, e.g. checking if this operation is not issued against a
    read-only device.
    
    Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations")
    Cc: [email protected]
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ivan Pravdin <[email protected]>
Date:   Sat Aug 30 16:03:40 2025 -0400

    Bluetooth: bcsp: receive data only if registered
    
    [ Upstream commit ca94b2b036c22556c3a66f1b80f490882deef7a6 ]
    
    Currently, bcsp_recv() can be called even when the BCSP protocol has not
    been registered. This leads to a NULL pointer dereference, as shown in
    the following stack trace:
    
        KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
        RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
        Call Trace:
         <TASK>
         hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
         tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
         tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
         vfs_ioctl fs/ioctl.c:51 [inline]
         __do_sys_ioctl fs/ioctl.c:907 [inline]
         __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
         do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
         do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
         entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    To prevent this, ensure that the HCI_UART_REGISTERED flag is set before
    processing received data. If the protocol is not registered, return
    -EUNATCH.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da
    Tested-by: [email protected]
    Signed-off-by: Ivan Pravdin <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kiran K <[email protected]>
Date:   Thu Jul 24 17:58:24 2025 +0530

    Bluetooth: btintel: Add support for BlazarIW core
    
    [ Upstream commit 926e8bfaaa11471b3df25befc284da62b11a1e92 ]
    
    Add support for the BlazarIW Bluetooth core used in the Wildcat Lake
    platform.
    
    HCI traces:
    < HCI Command: Intel Read Version (0x3f|0x0005) plen 1
        Requested Type:
          All Supported Types(0xff)
    > HCI Event: Command Complete (0x0e) plen 122
      Intel Read Version (0x3f|0x0005) ncmd 1
        Status: Success (0x00)
        .....
        CNVi BT(18): 0x00223700 - BlazarIW(0x22)
        .....
        .....
    
    Signed-off-by: Vijay Satija <[email protected]>
    Signed-off-by: Kiran K <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chandrashekar Devegowda <[email protected]>
Date:   Thu Jul 31 16:47:11 2025 +0530

    Bluetooth: btintel_pcie: Define hdev->wakeup() callback
    
    [ Upstream commit 3e94262921990e2884ff7a49064c12fb6d3a0733 ]
    
    Implement hdev->wakeup() callback to support Wake On BT feature.
    
    Test steps:
    1. echo enabled > /sys/bus/pci/devices/0000:00:14.7/power/wakeup
    2. connect bluetooth hid device
    3. put the system to suspend - rtcwake -m mem -s 300
    4. press any key on hid to wake up the system
    
    Signed-off-by: Kiran K <[email protected]>
    Signed-off-by: Chandrashekar Devegowda <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kiran K <[email protected]>
Date:   Thu Oct 16 10:00:43 2025 +0530

    Bluetooth: btintel_pcie: Fix event packet loss issue
    
    [ Upstream commit 057b6ca5961203f16a2a02fb0592661a7a959a84 ]
    
    In the current btintel_pcie driver implementation, when an interrupt is
    received, the driver checks for the alive cause before the TX/RX cause.
    Handling the alive cause involves resetting the TX/RX queue indices.
    This flow works correctly when the causes are mutually exclusive.
    However, if both cause bits are set simultaneously, the alive cause
    resets the queue indices, resulting in an event packet drop and a
    command timeout. To fix this issue, the driver is modified to handle all
    other causes before checking for the alive cause.
    
    Test case:
    Issue is seen with stress reboot scenario - 50x run
    
    [20.337589] Bluetooth: hci0: Device revision is 0
    [20.346750] Bluetooth: hci0: Secure boot is enabled
    [20.346752] Bluetooth: hci0: OTP lock is disabled
    [20.346752] Bluetooth: hci0: API lock is enabled
    [20.346752] Bluetooth: hci0: Debug lock is disabled
    [20.346753] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
    [20.346754] Bluetooth: hci0: Bootloader timestamp 2023.43 buildtype 1 build 11631
    [20.359070] Bluetooth: hci0: Found device firmware: intel/ibt-00a0-00a1-iml.sfi
    [20.371499] Bluetooth: hci0: Boot Address: 0xb02ff800
    [20.385769] Bluetooth: hci0: Firmware Version: 166-34.25
    [20.538257] Bluetooth: hci0: Waiting for firmware download to complete
    [20.554424] Bluetooth: hci0: Firmware loaded in 178651 usecs
    [21.081588] Bluetooth: hci0: Timeout (500 ms) on tx completion
    [21.096541] Bluetooth: hci0: Failed to send frame (-62)
    [21.110240] Bluetooth: hci0: sending frame failed (-62)
    [21.138551] Bluetooth: hci0: Failed to send Intel Reset command
    [21.170153] Bluetooth: hci0: Intel Soft Reset failed (-62)
    
    Signed-off-by: Kiran K <[email protected]>
    Signed-off-by: Sai Teja Aluvala <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chris Lu <[email protected]>
Date:   Tue Sep 30 13:39:33 2025 +0800

    Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during reset
    
    [ Upstream commit 77343b8b4f87560f8f03e77b98a81ff3a147b262 ]
    
    This patch adds logic to handle power management control when the
    Bluetooth function is closed during the SDIO reset sequence.
    
    Specifically, if BT is closed before reset, the driver enables the
    SDIO function and sets driver pmctrl. After reset, if BT remains
    closed, the driver sets firmware pmctrl and disables the SDIO function.
    
    These changes ensure proper power management and device state consistency
    across the reset flow.
    
    Fixes: 8fafe702253d ("Bluetooth: mt7921s: support bluetooth reset mechanism")
    Signed-off-by: Chris Lu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Abdun Nihaal <[email protected]>
Date:   Tue Oct 28 23:26:30 2025 +0530

    Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2()
    
    [ Upstream commit 1c21cf89a66413eb04b2d22c955b7a50edc14dfa ]
    
    The memory allocated for ptr using kvmalloc() is not freed on the last
    error path. Fix that by freeing it on that error path.
    
    Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support")
    Signed-off-by: Abdun Nihaal <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chris Lu <[email protected]>
Date:   Thu Sep 4 15:58:00 2025 +0800

    Bluetooth: btusb: Add new VID/PID 13d3/3627 for MT7925
    
    [ Upstream commit 576952cf981b7d2b7d3227b246b4326e5548a133 ]
    
    Add VID 13d3 & PID 3627 for MediaTek MT7922 USB Bluetooth chip.
    
    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below.
    
    T:  Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3627 Rev= 1.00
    S:  Manufacturer=MediaTek Inc.
    S:  Product=Wireless_Device
    S:  SerialNumber=000000000
    C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
    E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
    E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
    
    Signed-off-by: Chris Lu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chris Lu <[email protected]>
Date:   Thu Sep 4 19:46:11 2025 +0800

    Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922
    
    [ Upstream commit 70cd38d22d4659ca8133c7124528c90678215dda ]
    
    Add VID 13d3 & PID 3633 for MediaTek MT7922 USB Bluetooth chip.
    
    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below.
    
    T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3633 Rev= 1.00
    S:  Manufacturer=MediaTek Inc.
    S:  Product=Wireless_Device
    S:  SerialNumber=000000000
    C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
    E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
    E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
    
    Signed-off-by: Chris Lu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arkadiusz Bokowy <[email protected]>
Date:   Wed Aug 27 18:40:16 2025 +0200

    Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames
    
    [ Upstream commit 7722d6fb54e428a8f657fccf422095a8d7e2d72c ]
    
    Some Barrot based USB Bluetooth dongles erroneously send one extra
    random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
    consequence of that is that the next HCI transfer is misaligned by one
    byte causing undefined behavior. In most cases the response event for
    the next command fails with random error code.
    
    Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
    controller initialization, the initialization fails rendering the USB
    dongle not usable.
    
    > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
    > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
    > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
    > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
    > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
    > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110
    
    This patch was tested with the 33fa:0012 device. The info from the
    /sys/kernel/debug/usb/devices is shown below:
    
    T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 12 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=33fa ProdID=0012 Rev=88.91
    S:  Product=UGREEN BT6.0 Adapter
    C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Now the device is initialized properly:
    
    > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
    > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
    > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
    > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
    > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
    > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
    > [43.750141] Bluetooth: MGMT ver 1.23
    
    Link: https://github.com/bluez/bluez/issues/1326
    Signed-off-by: Arkadiusz Bokowy <[email protected]>
    Tested-by: Arkadiusz Bokowy <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Oct 1 10:55:58 2025 -0400

    Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00
    
    [ Upstream commit 0d92808024b4e9868cef68d16f121d509843e80e ]
    
    This fixes the state tracking of advertisement set/instance 0x00 which
    is considered a legacy instance and is not tracked individually by
    adv_instances list, previously it was assumed that hci_dev itself would
    track it via HCI_LE_ADV but that is a global state not specifc to
    instance 0x00, so to fix it a new flag is introduced that only tracks the
    state of instance 0x00.
    
    Fixes: 1488af7b8b5f ("Bluetooth: hci_sync: Fix hci_resume_advertising_sync")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Oct 22 16:29:41 2025 -0400

    Bluetooth: hci_conn: Fix connection cleanup with BIG with 2 or more BIS
    
    [ Upstream commit 857eb0fabc389be5159e0e17d84bc122614b5b98 ]
    
    This fixes bis_cleanup not considering connections in BT_OPEN state
    before attempting to remove the BIG causing the following error:
    
    btproxy[20110]: < HCI Command: LE Terminate Broadcast Isochronous Group (0x08|0x006a) plen 2
            BIG Handle: 0x01
            Reason: Connection Terminated By Local Host (0x16)
    > HCI Event: Command Status (0x0f) plen 4
          LE Terminate Broadcast Isochronous Group (0x08|0x006a) ncmd 1
            Status: Unknown Advertising Identifier (0x42)
    
    Fixes: fa224d0c094a ("Bluetooth: ISO: Reassociate a socket with an active BIS")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Oct 22 16:03:19 2025 -0400

    Bluetooth: hci_core: Fix tracking of periodic advertisement
    
    [ Upstream commit 751463ceefc3397566d03c8b64ef4a77f5fd88ac ]
    
    Periodic advertising enabled flag cannot be tracked by the enabled
    flag since advertising and periodic advertising each can be
    enabled/disabled separately from one another causing the states to be
    inconsistent when for example an advertising set is disabled its
    enabled flag is set to false which is then used for periodic which has
    not being disabled.
    
    Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Raphael Pinsonneault-Thibeault <[email protected]>
Date:   Fri Oct 24 12:29:10 2025 -0400

    Bluetooth: hci_event: validate skb length for unknown CC opcode
    
    [ Upstream commit 5c5f1f64681cc889d9b13e4a61285e9e029d6ab5 ]
    
    In hci_cmd_complete_evt(), if the command complete event has an unknown
    opcode, we assume the first byte of the remaining skb->data contains the
    return status. However, parameter data has previously been pulled in
    hci_event_func(), which may leave the skb empty. If so, using skb->data[0]
    for the return status uses un-init memory.
    
    The fix is to check skb->len before using skb->data.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=a9a4bedfca6aa9d7fa24
    Tested-by: [email protected]
    Fixes: afcb3369f46ed ("Bluetooth: hci_event: Fix vendor (unknown) opcode status handling")
    Signed-off-by: Raphael Pinsonneault-Thibeault <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cen Zhang <[email protected]>
Date:   Mon Sep 29 05:30:17 2025 +0000

    Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
    
    [ Upstream commit 09b0cd1297b4dbfe736aeaa0ceeab2265f47f772 ]
    
    hci_cmd_sync_dequeue_once() does lookup and then cancel
    the entry under two separate lock sections. Meanwhile,
    hci_cmd_sync_work() can also delete the same entry,
    leading to double list_del() and "UAF".
    
    Fix this by holding cmd_sync_work_lock across both
    lookup and cancel, so that the entry cannot be removed
    concurrently.
    
    Fixes: 505ea2b29592 ("Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue")
    Reported-by: Cen Zhang <[email protected]>
    Signed-off-by: Cen Zhang <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Jun 27 11:18:29 2025 -0400

    Bluetooth: ISO: Don't initiate CIS connections if there are no buffers
    
    [ Upstream commit d79c7d01f1c8bcf9a48337c8960d618fbe31fc0c ]
    
    If the controller has no buffers left return -ENOBUFF to indicate that
    iso_cnt might be out of sync.
    
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Tue Oct 7 13:29:15 2025 -0400

    Bluetooth: ISO: Fix another instance of dst_type handling
    
    [ Upstream commit c403da5e98b04a2aec9cfb25cbeeb28d7ce29975 ]
    
    Socket dst_type cannot be directly assigned to hci_conn->type since
    there domain is different which may lead to the wrong address type being
    used.
    
    Fixes: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Sep 26 11:48:50 2025 -0400

    Bluetooth: ISO: Fix BIS connection dst_type handling
    
    [ Upstream commit f0c200a4a537f8f374584a974518b0ce69eda76c ]
    
    Socket dst_type cannot be directly assigned to hci_conn->type since
    there domain is different which may lead to the wrong address type being
    used.
    
    Fixes: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Aug 13 15:21:19 2025 -0400

    Bluetooth: ISO: Use sk_sndtimeo as conn_timeout
    
    [ Upstream commit 339a87883a14d6a818ca436fed41aa5d10e0f4bd ]
    
    This aligns the usage of socket sk_sndtimeo as conn_timeout when
    initiating a connection and then use it when scheduling the
    resulting HCI command, similar to what has been done in bf98feea5b65
    ("Bluetooth: hci_conn: Always use sk_timeo as conn_timeout").
    
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pauli Virtanen <[email protected]>
Date:   Fri Oct 3 22:07:32 2025 +0300

    Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_complete
    
    [ Upstream commit e8785404de06a69d89dcdd1e9a0b6ea42dc6d327 ]
    
    There is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due to
    memcpy from badly declared on-stack flexible array.
    
    Another crash is in set_mesh_complete() due to double list_del via
    mgmt_pending_valid + mgmt_pending_remove.
    
    Use DEFINE_FLEX to declare the flexible array right, and don't memcpy
    outside bounds.
    
    As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,
    and also report status on error.
    
    Fixes: 302a1f674c00d ("Bluetooth: MGMT: Fix possible UAFs")
    Signed-off-by: Pauli Virtanen <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilia Gavrilov <[email protected]>
Date:   Mon Oct 20 15:12:55 2025 +0000

    Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()
    
    commit 8d59fba49362c65332395789fd82771f1028d87e upstream.
    
    In the parse_adv_monitor_pattern() function, the value of
    the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).
    The size of the 'value' array in the mgmt_adv_pattern structure is 31.
    If the value of 'pattern[i].length' is set in the user space
    and exceeds 31, the 'patterns[i].value' array can be accessed
    out of bound when copied.
    
    Increasing the size of the 'value' array in
    the 'mgmt_adv_pattern' structure will break the userspace.
    Considering this, and to avoid OOB access revert the limits for 'offset'
    and 'length' back to the value of HCI_MAX_AD_LENGTH.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: db08722fc7d4 ("Bluetooth: hci_core: Fix missing instances using HCI_MAX_AD_LENGTH")
    Cc: [email protected]
    Signed-off-by: Ilia Gavrilov <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Johan Hovold <[email protected]>
Date:   Thu Oct 23 14:05:30 2025 +0200

    Bluetooth: rfcomm: fix modem control handling
    
    commit 91d35ec9b3956d6b3cf789c1593467e58855b03a upstream.
    
    The RFCOMM driver confuses the local and remote modem control signals,
    which specifically means that the reported DTR and RTS state will
    instead reflect the remote end (i.e. DSR and CTS).
    
    This issue dates back to the original driver (and a follow-on update)
    merged in 2002, which resulted in a non-standard implementation of
    TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by
    mapping them to the RI and DCD input flags, while TIOCMGET failed to
    return the actual state of DTR and RTS.
    
    Note that the bogus control of input signals in tiocmset() is just
    dead code as those flags will have been masked out by the tty layer
    since 2003.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Sep 22 13:13:13 2025 -0400

    Bluetooth: SCO: Fix UAF on sco_conn_free
    
    [ Upstream commit ecb9a843be4d6fd710d7026e359f21015a062572 ]
    
    BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]
    BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]
    BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410
    net/bluetooth/sco.c:107
    Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352
    
    CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted
    6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Workqueue: hci13 hci_cmd_sync_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0x191/0x550 mm/kasan/report.c:482
     kasan_report+0xc4/0x100 mm/kasan/report.c:595
     sco_conn_free net/bluetooth/sco.c:87 [inline]
     kref_put include/linux/kref.h:65 [inline]
     sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107
     sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441
     hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]
     hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313
     hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121
     hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147
     hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689
     hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332
     process_one_work kernel/workqueue.c:3236 [inline]
     process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319
     worker_thread+0xbee/0x1200 kernel/workqueue.c:3400
     kthread+0x3c7/0x870 kernel/kthread.c:463
     ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
     </TASK>
    
    Allocated by task 31370:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x30/0x70 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:388 [inline]
     __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __do_kmalloc_node mm/slub.c:4382 [inline]
     __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394
     kmalloc_noprof include/linux/slab.h:909 [inline]
     sk_prot_alloc+0xae/0x220 net/core/sock.c:2239
     sk_alloc+0x34/0x5a0 net/core/sock.c:2295
     bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151
     sco_sock_alloc net/bluetooth/sco.c:562 [inline]
     sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593
     bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135
     __sock_create+0x3ad/0x780 net/socket.c:1589
     sock_create net/socket.c:1647 [inline]
     __sys_socket_create net/socket.c:1684 [inline]
     __sys_socket+0xd5/0x330 net/socket.c:1731
     __do_sys_socket net/socket.c:1745 [inline]
     __se_sys_socket net/socket.c:1743 [inline]
     __x64_sys_socket+0x7a/0x90 net/socket.c:1743
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 31374:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x30/0x70 mm/kasan/common.c:68
     kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:243 [inline]
     __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2428 [inline]
     slab_free mm/slub.c:4701 [inline]
     kfree+0x199/0x3b0 mm/slub.c:4900
     sk_prot_free net/core/sock.c:2278 [inline]
     __sk_destruct+0x4aa/0x630 net/core/sock.c:2373
     sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333
     __sock_release net/socket.c:649 [inline]
     sock_close+0xb8/0x230 net/socket.c:1439
     __fput+0x3d1/0x9e0 fs/file_table.c:468
     task_work_run+0x206/0x2a0 kernel/task_work.c:227
     get_signal+0x1201/0x1410 kernel/signal.c:2807
     arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337
     exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40
     exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
     syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
     syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
     do_syscall_64+0x1dd/0x240 arch/x86/entry/syscall_64.c:100
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Reported-by: cen zhang <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bhargava Marreddy <[email protected]>
Date:   Fri Sep 19 23:17:32 2025 +0530

    bng_en: make bnge_alloc_ring() self-unwind on failure
    
    [ Upstream commit 9ee5994418bb527788e77361d338af40a126aa21 ]
    
    Ensure bnge_alloc_ring() frees any intermediate allocations
    when it fails. This enables later patches to rely on this
    self-unwinding behavior.
    
    Signed-off-by: Bhargava Marreddy <[email protected]>
    Reviewed-by: Vikas Gupta <[email protected]>
    Reviewed-by: Rajashekar Hudumula <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shruti Parab <[email protected]>
Date:   Tue Sep 16 21:08:34 2025 -0700

    bnxt_en: Add fw log trace support for 5731X/5741X chips
    
    [ Upstream commit ba1aefee2e9835fe6e07b86cb7020bd2550a81ee ]
    
    These older chips now support the fw log traces via backing store
    qcaps_v2. No other backing store memory types are supported besides
    the fw trace types.
    
    Reviewed-by: Hongguang Gao <[email protected]>
    Reviewed-by: Andy Gospodarek <[email protected]>
    Signed-off-by: Shruti Parab <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavan Chebbi <[email protected]>
Date:   Tue Aug 19 09:39:19 2025 -0700

    bnxt_en: Add Hyper-V VF ID
    
    [ Upstream commit 5be7cb805bd9a6680b863a1477dbc6e7986cc223 ]
    
    VFs of the P7 chip family created by Hyper-V will have the device ID of
    0x181b.
    
    Reviewed-by: Somnath Kotur <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Signed-off-by: Pavan Chebbi <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kashyap Desai <[email protected]>
Date:   Mon Nov 3 16:56:58 2025 -0800

    bnxt_en: Always provide max entry and entry size in coredump segments
    
    [ Upstream commit 28d9a84ef0ce56cc623da2a1ebf7583c00d52b31 ]
    
    While populating firmware host logging segments for the coredump, it is
    possible for the FW command that flushes the segment to fail.  When that
    happens, the existing code will not update the max entry and entry size
    in the segment header and this causes software that decodes the coredump
    to skip the segment.
    
    The segment most likely has already collected some DMA data, so always
    update these 2 segment fields in the header to allow the decoder to
    decode any data in the segment.
    
    Fixes: 3c2179e66355 ("bnxt_en: Add FW trace coredump segments to the coredump")
    Reviewed-by: Shruti Parab <[email protected]>
    Signed-off-by: Kashyap Desai <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kalesh AP <[email protected]>
Date:   Mon Nov 3 16:56:56 2025 -0800

    bnxt_en: Fix a possible memory leak in bnxt_ptp_init
    
    [ Upstream commit deb8eb39164382f1f67ef8e8af9176baf5e10f2d ]
    
    In bnxt_ptp_init(), when ptp_clock_register() fails, the driver is
    not freeing the memory allocated for ptp_info->pin_config.  Fix it
    to unconditionally free ptp_info->pin_config in bnxt_ptp_free().
    
    Fixes: caf3eedbcd8d ("bnxt_en: 1PPS support for 5750X family chips")
    Reviewed-by: Pavan Chebbi <[email protected]>
    Reviewed-by: Somnath Kotur <[email protected]>
    Signed-off-by: Kalesh AP <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gautam R A <[email protected]>
Date:   Mon Nov 3 16:56:57 2025 -0800

    bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()
    
    [ Upstream commit ff02be05f78399c766be68ab0b2285ff90b2aaa8 ]
    
    With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER
    for FW trace data type that has not been initialized.  This will result
    in a crash in bnxt_bs_trace_type_wrap().  Add a guard to check for a
    valid magic_byte pointer before proceeding.
    
    Fixes: 84fcd9449fd7 ("bnxt_en: Manage the FW trace context memory")
    Reviewed-by: Somnath Kotur <[email protected]>
    Reviewed-by: Shruti Parab <[email protected]>
    Signed-off-by: Gautam R A <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shantiprasad Shettar <[email protected]>
Date:   Mon Nov 3 16:56:59 2025 -0800

    bnxt_en: Fix warning in bnxt_dl_reload_down()
    
    [ Upstream commit 5204943a4c6efc832993c0fa17dec275071eeccc ]
    
    The existing code calls bnxt_cancel_reservations() after
    bnxt_hwrm_func_drv_unrgtr() in bnxt_dl_reload_down().
    bnxt_cancel_reservations() calls the FW and it will always fail since
    the driver has already unregistered, triggering this warning:
    
    bnxt_en 0000:0a:00.0 ens2np0: resc_qcaps failed
    
    Fix it by calling bnxt_clear_reservations() which will skip the
    unnecessary FW call since we have unregistered.
    
    Fixes: 228ea8c187d8 ("bnxt_en: implement devlink dev reload driver_reinit")
    Reviewed-by: Mohammad Shuab Siddique <[email protected]>
    Reviewed-by: Somnath Kotur <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Signed-off-by: Shantiprasad Shettar <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Chan <[email protected]>
Date:   Mon Nov 3 16:56:55 2025 -0800

    bnxt_en: Shutdown FW DMA in bnxt_shutdown()
    
    [ Upstream commit bc7208ca805ae6062f353a4753467d913d963bc6 ]
    
    The netif_close() call in bnxt_shutdown() only stops packet DMA.  There
    may be FW DMA for trace logging (recently added) that will continue.  If
    we kexec to a new kernel, the DMA will corrupt memory in the new kernel.
    
    Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.
    This will stop the FW DMA.  In case the call fails, call pcie_flr() to
    reset the function and stop the DMA.
    
    Fixes: 24d694aec139 ("bnxt_en: Allocate backing store memory for FW trace logs")
    Reported-by: Jakub Kicinski <[email protected]>
    Reviewed-by: Damodharam Ammepalli <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Reviewed-by: Somnath Kotur <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Amery Hung <[email protected]>
Date:   Mon Sep 22 16:33:49 2025 -0700

    bpf: Clear pfmemalloc flag when freeing all fragments
    
    [ Upstream commit 8f12d1137c2382c80aada8e05d7cc650cd4e403c ]
    
    It is possible for bpf_xdp_adjust_tail() to free all fragments. The
    kfunc currently clears the XDP_FLAGS_HAS_FRAGS bit, but not
    XDP_FLAGS_FRAGS_PF_MEMALLOC. So far, this has not caused a issue when
    building sk_buff from xdp_buff since all readers of xdp_buff->flags
    use the flag only when there are fragments. Clear the
    XDP_FLAGS_FRAGS_PF_MEMALLOC bit as well to make the flags correct.
    
    Signed-off-by: Amery Hung <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Maciej Fijalkowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Malin Jonsson <[email protected]>
Date:   Fri Oct 24 17:14:36 2025 +0200

    bpf: Conditionally include dynptr copy kfuncs
    
    [ Upstream commit 8ce93aabbf75171470e3d1be56bf1a6937dc5db8 ]
    
    Since commit a498ee7576de ("bpf: Implement dynptr copy kfuncs"), if
    CONFIG_BPF_EVENTS is not enabled, but BPF_SYSCALL and DEBUG_INFO_BTF are,
    the build will break like so:
    
      BTFIDS  vmlinux.unstripped
    WARN: resolve_btfids: unresolved symbol bpf_probe_read_user_str_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_probe_read_user_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_probe_read_kernel_str_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_probe_read_kernel_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_copy_from_user_task_str_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_copy_from_user_task_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_copy_from_user_str_dynptr
    WARN: resolve_btfids: unresolved symbol bpf_copy_from_user_dynptr
    make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 255
    make[2]: *** Deleting file 'vmlinux.unstripped'
    make[1]: *** [/repo/malin/upstream/linux/Makefile:1242: vmlinux] Error 2
    make: *** [Makefile:248: __sub-make] Error 2
    
    Guard these symbols with #ifdef CONFIG_BPF_EVENTS to resolve the problem.
    
    Fixes: a498ee7576de ("bpf: Implement dynptr copy kfuncs")
    Reported-by: Yong Gu <[email protected]>
    Acked-by: Mykyta Yatsenko <[email protected]>
    Signed-off-by: Malin Jonsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ondrej Mosnacek <[email protected]>
Date:   Tue Oct 21 14:27:58 2025 +0200

    bpf: Do not audit capability check in do_jit()
    
    [ Upstream commit 881a9c9cb7856b24e390fad9f59acfd73b98b3b2 ]
    
    The failure of this check only results in a security mitigation being
    applied, slightly affecting performance of the compiled BPF program. It
    doesn't result in a failed syscall, an thus auditing a failed LSM
    permission check for it is unwanted. For example with SELinux, it causes
    a denial to be reported for confined processes running as root, which
    tends to be flagged as a problem to be fixed in the policy. Yet
    dontauditing or allowing CAP_SYS_ADMIN to the domain may not be
    desirable, as it would allow/silence also other checks - either going
    against the principle of least privilege or making debugging potentially
    harder.
    
    Fix it by changing it from capable() to ns_capable_noaudit(), which
    instructs the LSMs to not audit the resulting denials.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2369326
    Fixes: d4e89d212d40 ("x86/bpf: Call branch history clearing sequence on exit")
    Signed-off-by: Ondrej Mosnacek <[email protected]>
    Reviewed-by: Paul Moore <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kumar Kartikeya Dwivedi <[email protected]>
Date:   Mon Sep 15 03:26:17 2025 +0000

    bpf: Do not limit bpf_cgroup_from_id to current's namespace
    
    [ Upstream commit 2c895133950646f45e5cf3900b168c952c8dbee8 ]
    
    The bpf_cgroup_from_id kfunc relies on cgroup_get_from_id to obtain the
    cgroup corresponding to a given cgroup ID. This helper can be called in
    a lot of contexts where the current thread can be random. A recent
    example was its use in sched_ext's ops.tick(), to obtain the root cgroup
    pointer. Since the current task can be whatever random user space task
    preempted by the timer tick, this makes the behavior of the helper
    unreliable.
    
    Refactor out __cgroup_get_from_id as the non-namespace aware version of
    cgroup_get_from_id, and change bpf_cgroup_from_id to make use of it.
    
    There is no compatibility breakage here, since changing the namespace
    against which the lookup is being done to the root cgroup namespace only
    permits a wider set of lookups to succeed now. The cgroup IDs across
    namespaces are globally unique, and thus don't need to be retranslated.
    
    Reported-by: Dan Schatzberg <[email protected]>
    Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Mon Aug 11 14:08:04 2025 +0200

    bpf: Don't use %pK through printk
    
    [ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ]
    
    In the past %pK was preferable to %p as it would not leak raw pointer
    values into the kernel log.
    Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
    the regular %p has been improved to avoid this issue.
    Furthermore, restricted pointers ("%pK") were never meant to be used
    through printk(). They can still unintentionally leak raw pointers or
    acquire sleeping locks in atomic contexts.
    
    Switch to the regular pointer formatting which is safer and
    easier to reason about.
    
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Noorain Eqbal <[email protected]>
Date:   Mon Oct 20 23:33:01 2025 +0530

    bpf: Sync pending IRQ work before freeing ring buffer
    
    [ Upstream commit 4e9077638301816a7d73fa1e1b4c1db4a7e3b59c ]
    
    Fix a race where irq_work can be queued in bpf_ringbuf_commit()
    but the ring buffer is freed before the work executes.
    In the syzbot reproducer, a BPF program attached to sched_switch
    triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
    is freed before this work executes, the irq_work thread may accesses
    freed memory.
    Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work
    complete before freeing the buffer.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=2617fc732430968b45d2
    Tested-by: [email protected]
    Signed-off-by: Noorain Eqbal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Paul Chaignon <[email protected]>
Date:   Wed Aug 20 15:18:06 2025 +0200

    bpf: Use tnums for JEQ/JNE is_branch_taken logic
    
    [ Upstream commit f41345f47fb267a9c95ca710c33448f8d0d81d83 ]
    
    In the following toy program (reg states minimized for readability), R0
    and R1 always have different values at instruction 6. This is obvious
    when reading the program but cannot be guessed from ranges alone as
    they overlap (R0 in [0; 0xc0000000], R1 in [1024; 0xc0000400]).
    
      0: call bpf_get_prandom_u32#7  ; R0_w=scalar()
      1: w0 = w0                     ; R0_w=scalar(var_off=(0x0; 0xffffffff))
      2: r0 >>= 30                   ; R0_w=scalar(var_off=(0x0; 0x3))
      3: r0 <<= 30                   ; R0_w=scalar(var_off=(0x0; 0xc0000000))
      4: r1 = r0                     ; R1_w=scalar(var_off=(0x0; 0xc0000000))
      5: r1 += 1024                  ; R1_w=scalar(var_off=(0x400; 0xc0000000))
      6: if r1 != r0 goto pc+1
    
    Looking at tnums however, we can deduce that R1 is always different from
    R0 because their tnums don't agree on known bits. This patch uses this
    logic to improve is_scalar_branch_taken in case of BPF_JEQ and BPF_JNE.
    
    This change has a tiny impact on complexity, which was measured with
    the Cilium complexity CI test. That test covers 72 programs with
    various build and load time configurations for a total of 970 test
    cases. For 80% of test cases, the patch has no impact. On the other
    test cases, the patch decreases complexity by only 0.08% on average. In
    the best case, the verifier needs to walk 3% less instructions and, in
    the worst case, 1.5% more. Overall, the patch has a small positive
    impact, especially for our largest programs.
    
    Signed-off-by: Paul Chaignon <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Acked-by: Shung-Hsi Yu <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/be3ee70b6e489c49881cb1646114b1d861b5c334.1755694147.git.paul.chaignon@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tom Stellard <[email protected]>
Date:   Wed Sep 17 11:38:47 2025 -0700

    bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21
    
    [ Upstream commit 5612ea8b554375d45c14cbb0f8ea93ec5d172891 ]
    
    This fixes the build with -Werror -Wall.
    
    btf_dumper.c:71:31: error: variable 'finfo' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
       71 |         info.func_info = ptr_to_u64(&finfo);
          |                                      ^~~~~
    
    prog.c:2294:31: error: variable 'func_info' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
     2294 |         info.func_info = ptr_to_u64(&func_info);
          |
    
    v2:
      - Initialize instead of using memset.
    
    Signed-off-by: Tom Stellard <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Tue Aug 12 11:02:12 2025 +0300

    bridge: Redirect to backup port when port is administratively down
    
    [ Upstream commit 3d05b24429e1de7a17c8fdccb04a04dbc8ad297b ]
    
    If a backup port is configured for a bridge port, the bridge will
    redirect known unicast traffic towards the backup port when the primary
    port is administratively up but without a carrier. This is useful, for
    example, in MLAG configurations where a system is connected to two
    switches and there is a peer link between both switches. The peer link
    serves as the backup port in case one of the switches loses its
    connection to the multi-homed system.
    
    In order to avoid flooding when the primary port loses its carrier, the
    bridge does not flush dynamic FDB entries pointing to the port upon STP
    disablement, if the port has a backup port.
    
    The above means that known unicast traffic destined to the primary port
    will be blackholed when the port is put administratively down, until the
    FDB entries pointing to it are aged-out.
    
    Given that the current behavior is quite weird and unlikely to be
    depended on by anyone, amend the bridge to redirect to the backup port
    also when the primary port is administratively down and not only when it
    does not have a carrier.
    
    The change is motivated by a report from a user who expected traffic to
    be redirected to the backup port when the primary port was put
    administratively down while debugging a network issue.
    
    Reviewed-by: Petr Machata <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Acked-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Qu Wenruo <[email protected]>
Date:   Thu Oct 23 19:44:04 2025 +1030

    btrfs: ensure no dirty metadata is written back for an fs with errors
    
    commit 2618849f31e7cf51fadd4a5242458501a6d5b315 upstream.
    
    [BUG]
    During development of a minor feature (make sure all btrfs_bio::end_io()
    is called in task context), I noticed a crash in generic/388, where
    metadata writes triggered new works after btrfs_stop_all_workers().
    
    It turns out that it can even happen without any code modification, just
    using RAID5 for metadata and the same workload from generic/388 is going
    to trigger the use-after-free.
    
    [CAUSE]
    If btrfs hits an error, the fs is marked as error, no new
    transaction is allowed thus metadata is in a frozen state.
    
    But there are some metadata modifications before that error, and they are
    still in the btree inode page cache.
    
    Since there will be no real transaction commit, all those dirty folios
    are just kept as is in the page cache, and they can not be invalidated
    by invalidate_inode_pages2() call inside close_ctree(), because they are
    dirty.
    
    And finally after btrfs_stop_all_workers(), we call iput() on btree
    inode, which triggers writeback of those dirty metadata.
    
    And if the fs is using RAID56 metadata, this will trigger RMW and queue
    new works into rmw_workers, which is already stopped, causing warning
    from queue_work() and use-after-free.
    
    [FIX]
    Add a special handling for write_one_eb(), that if the fs is already in
    an error state, immediately mark the bbio as failure, instead of really
    submitting them.
    
    Then during close_ctree(), iput() will just discard all those dirty
    tree blocks without really writing them back, thus no more new jobs for
    already stopped-and-freed workqueues.
    
    The extra discard in write_one_eb() also acts as an extra safenet.
    E.g. the transaction abort is triggered by some extent/free space
    tree corruptions, and since extent/free space tree is already corrupted
    some tree blocks may be allocated where they shouldn't be (overwriting
    existing tree blocks). In that case writing them back will further
    corrupting the fs.
    
    CC: [email protected] # 6.6+
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Shardul Bankar <[email protected]>
Date:   Sun Oct 26 01:30:21 2025 +0530

    btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation
    
    [ Upstream commit f260c6aff0b8af236084012d14f9f1bf792ea883 ]
    
    When btrfs_add_qgroup_relation() is called with invalid qgroup levels
    (src >= dst), the function returns -EINVAL directly without freeing the
    preallocated qgroup_list structure passed by the caller. This causes a
    memory leak because the caller unconditionally sets the pointer to NULL
    after the call, preventing any cleanup.
    
    The issue occurs because the level validation check happens before the
    mutex is acquired and before any error handling path that would free
    the prealloc pointer. On this early return, the cleanup code at the
    'out' label (which includes kfree(prealloc)) is never reached.
    
    In btrfs_ioctl_qgroup_assign(), the code pattern is:
    
        prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
        ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc);
        prealloc = NULL;  // Always set to NULL regardless of return value
        ...
        kfree(prealloc);  // This becomes kfree(NULL), does nothing
    
    When the level check fails, 'prealloc' is never freed by either the
    callee or the caller, resulting in a 64-byte memory leak per failed
    operation. This can be triggered repeatedly by an unprivileged user
    with access to a writable btrfs mount, potentially exhausting kernel
    memory.
    
    Fix this by freeing prealloc before the early return, ensuring prealloc
    is always freed on all error paths.
    
    Fixes: 4addc1ffd67a ("btrfs: qgroup: preallocate memory before adding a relation")
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Shardul Bankar <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: austinchang <[email protected]>
Date:   Wed Oct 29 09:35:27 2025 +0000

    btrfs: mark dirty extent range for out of bound prealloc extents
    
    [ Upstream commit 3b1a4a59a2086badab391687a6a0b86e03048393 ]
    
    In btrfs_fallocate(), when the allocated range overlaps with a prealloc
    extent and the extent starts after i_size, the range doesn't get marked
    dirty in file_extent_tree. This results in persisting an incorrect
    disk_i_size for the inode when not using the no-holes feature.
    
    This is reproducible since commit 41a2ee75aab0 ("btrfs: introduce
    per-inode file extent tree"), then became hidden since commit 3d7db6e8bd22
    ("btrfs: don't allocate file extent tree for non regular files") and then
    visible again after commit 8679d2687c35 ("btrfs: initialize
    inode::file_extent_tree after i_mode has been set"), which fixes the
    previous commit.
    
    The following reproducer triggers the problem:
    
    $ cat test.sh
    
    MNT=/mnt/test
    DEV=/dev/vdb
    
    mkdir -p $MNT
    
    mkfs.btrfs -f -O ^no-holes $DEV
    mount $DEV $MNT
    
    touch $MNT/file1
    fallocate -n -o 1M -l 2M $MNT/file1
    
    umount $MNT
    mount $DEV $MNT
    
    len=$((1 * 1024 * 1024))
    
    fallocate -o 1M -l $len $MNT/file1
    
    du --bytes $MNT/file1
    
    umount $MNT
    mount $DEV $MNT
    
    du --bytes $MNT/file1
    
    umount $MNT
    
    Running the reproducer gives the following result:
    
    $ ./test.sh
    (...)
    2097152 /mnt/test/file1
    1048576 /mnt/test/file1
    
    The difference is exactly 1048576 as we assigned.
    
    Fix by adding a call to btrfs_inode_set_file_extent_range() in
    btrfs_fallocate_update_isize().
    
    Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree")
    Signed-off-by: austinchang <[email protected]>
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vivek Pernamitta <[email protected]>
Date:   Fri Sep 12 18:18:09 2025 +0530

    bus: mhi: core: Improve mhi_sync_power_up handling for SYS_ERR state
    
    [ Upstream commit aa1a0e93ed21a06acb7ca9d4a4a9fce75ea53d0c ]
    
    Allow mhi_sync_power_up to handle SYS_ERR during power-up, reboot,
    or recovery. This is to avoid premature exit when MHI_PM_IN_ERROR_STATE is
    observed during above mentioned system states.
    
    To achieve this, treat SYS_ERR as a valid state and let its handler process
    the error and queue the next transition to Mission Mode instead of aborting
    early.
    
    Signed-off-by: Vivek Pernamitta <[email protected]>
    [mani: reworded description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Slark Xiao <[email protected]>
Date:   Tue Aug 19 10:00:13 2025 +0800

    bus: mhi: host: pci_generic: Add support for all Foxconn T99W696 SKU variants
    
    [ Upstream commit 376358bb9770e5313d22d8784511497096cdb75f ]
    
    Since there are too many variants available for Foxconn T99W696 modem, and
    they all share the same configuration, use PCI_ANY_ID as the subsystem
    device ID to match each possible SKUs and support all of them.
    
    Signed-off-by: Slark Xiao <[email protected]>
    [mani: reworded subject/description and dropped the fixes tag]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Biju Das <[email protected]>
Date:   Mon Sep 8 13:09:30 2025 +0100

    can: rcar_canfd: Update bit rate constants for RZ/G3E and R-Car Gen4
    
    [ Upstream commit 100fafc3e46138cb5a6526ddc03dcede8b020c8c ]
    
    The calculation formula for nominal bit rate of classical CAN is the same as
    that of nominal bit rate of CANFD on the RZ/G3E and R-Car Gen4 SoCs
    compared to other SoCs. Update nominal bit rate constants.
    
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [mkl: slightly improve wording of commit message]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viacheslav Dubeyko <[email protected]>
Date:   Fri Jun 6 12:04:32 2025 -0700

    ceph: add checking of wait_for_completion_killable() return value
    
    [ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ]
    
    The Coverity Scan service has detected the calling of
    wait_for_completion_killable() without checking the return
    value in ceph_lock_wait_for_completion() [1]. The CID 1636232
    defect contains explanation: "If the function returns an error
    value, the error value may be mistaken for a normal value.
    In ceph_lock_wait_for_completion(): Value returned from
    a function is not checked for errors before being used. (CWE-252)".
    
    The patch adds the checking of wait_for_completion_killable()
    return value and return the error code from
    ceph_lock_wait_for_completion().
    
    [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232
    
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Reviewed-by: Alex Markuze <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kotresh HR <[email protected]>
Date:   Thu Sep 11 15:02:35 2025 +0530

    ceph: fix multifs mds auth caps issue
    
    [ Upstream commit 22c73d52a6d05c5a2053385c0d6cd9984732799d ]
    
    The mds auth caps check should also validate the
    fsname along with the associated caps. Not doing
    so would result in applying the mds auth caps of
    one fs on to the other fs in a multifs ceph cluster.
    The bug causes multiple issues w.r.t user
    authentication, following is one such example.
    
    Steps to Reproduce (on vstart cluster):
    1. Create two file systems in a cluster, say 'fsname1' and 'fsname2'
    2. Authorize read only permission to the user 'client.usr' on fs 'fsname1'
        $ceph fs authorize fsname1 client.usr / r
    3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2'
        $ceph fs authorize fsname2 client.usr / rw
    4. Update the keyring
        $ceph auth get client.usr >> ./keyring
    
    With above permssions for the user 'client.usr', following is the
    expectation.
      a. The 'client.usr' should be able to only read the contents
         and not allowed to create or delete files on file system 'fsname1'.
      b. The 'client.usr' should be able to read/write on file system 'fsname2'.
    
    But, with this bug, the 'client.usr' is allowed to read/write on file
    system 'fsname1'. See below.
    
    5. Mount the file system 'fsname1' with the user 'client.usr'
         $sudo bin/mount.ceph [email protected]=/ /kmnt_fsname1_usr/
    6. Try creating a file on file system 'fsname1' with user 'client.usr'. This
       should fail but passes with this bug.
         $touch /kmnt_fsname1_usr/file1
    7. Mount the file system 'fsname1' with the user 'client.admin' and create a
       file.
         $sudo bin/mount.ceph [email protected]=/ /kmnt_fsname1_admin
         $echo "data" > /kmnt_fsname1_admin/admin_file1
    8. Try removing an existing file on file system 'fsname1' with the user
       'client.usr'. This shoudn't succeed but succeeds with the bug.
         $rm -f /kmnt_fsname1_usr/admin_file1
    
    For more information, please take a look at the corresponding mds/fuse patch
    and tests added by looking into the tracker mentioned below.
    
    v2: Fix a possible null dereference in doutc
    v3: Don't store fsname from mdsmap, validate against
        ceph_mount_options's fsname and use it
    v4: Code refactor, better warning message and
        fix possible compiler warning
    
    [ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]
    
    Link: https://tracker.ceph.com/issues/72167
    Signed-off-by: Kotresh HR <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viacheslav Dubeyko <[email protected]>
Date:   Fri Jun 13 11:31:08 2025 -0700

    ceph: fix potential race condition in ceph_ioctl_lazyio()
    
    [ Upstream commit 5824ccba9a39a3ad914fc9b2972a2c1119abaac9 ]
    
    The Coverity Scan service has detected potential
    race condition in ceph_ioctl_lazyio() [1].
    
    The CID 1591046 contains explanation: "Check of thread-shared
    field evades lock acquisition (LOCK_EVASION). Thread1 sets
    fmode to a new value. Now the two threads have an inconsistent
    view of fmode and updates to fields correlated with fmode
    may be lost. The data guarded by this critical section may
    be read while in an inconsistent state or modified by multiple
    racing threads. In ceph_ioctl_lazyio: Checking the value of
    a thread-shared field outside of a locked region to determine
    if a locked operation involving that thread shared field
    has completed. (CWE-543)".
    
    The patch places fi->fmode field access under ci->i_ceph_lock
    protection. Also, it introduces the is_file_already_lazy
    variable that is set under the lock and it is checked later
    out of scope of critical section.
    
    [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1591046
    
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Reviewed-by: Alex Markuze <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viacheslav Dubeyko <[email protected]>
Date:   Tue Jul 8 12:20:57 2025 -0700

    ceph: refactor wake_up_bit() pattern of calling
    
    [ Upstream commit 53db6f25ee47cb1265141d31562604e56146919a ]
    
    The wake_up_bit() is called in ceph_async_unlink_cb(),
    wake_async_create_waiters(), and ceph_finish_async_create().
    It makes sense to switch on clear_bit() function, because
    it makes the code much cleaner and easier to understand.
    More important rework is the adding of smp_mb__after_atomic()
    memory barrier after the bit modification and before
    wake_up_bit() call. It can prevent potential race condition
    of accessing the modified bit in other threads. Luckily,
    clear_and_wake_up_bit() already implements the required
    functionality pattern:
    
    static inline void clear_and_wake_up_bit(int bit, unsigned long *word)
    {
            clear_bit_unlock(bit, word);
            /* See wake_up_bit() for which memory barrier you need to use. */
            smp_mb__after_atomic();
            wake_up_bit(word, bit);
    }
    
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Reviewed-by: Alex Markuze <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zijun Hu <[email protected]>
Date:   Mon Jul 14 23:34:17 2025 +0800

    char: misc: Does not request module for miscdevice with dynamic minor
    
    [ Upstream commit 1ba0fb42aa6a5f072b1b8c0b0520b32ad4ef4b45 ]
    
    misc_open() may request module for miscdevice with dynamic minor, which
    is meaningless since:
    
    - The dynamic minor allocated is unknown in advance without registering
      miscdevice firstly.
    - Macro MODULE_ALIAS_MISCDEV() is not applicable for dynamic minor.
    
    Fix by only requesting module for miscdevice with fixed minor.
    
    Acked-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Zijun Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zijun Hu <[email protected]>
Date:   Mon Jul 14 23:34:16 2025 +0800

    char: misc: Make misc_register() reentry for miscdevice who wants dynamic minor
    
    [ Upstream commit 52e2bb5ff089d65e2c7d982fe2826dc88e473d50 ]
    
    For miscdevice who wants dynamic minor, it may fail to be registered again
    without reinitialization after being de-registered, which is illustrated
    by kunit test case miscdev_test_dynamic_reentry() newly added.
    
    There is a real case found by cascardo when a part of minor range were
    contained by range [0, 255):
    
    1) wmi/dell-smbios registered minor 122, and acpi_thermal_rel registered
       minor 123
    2) unbind "int3400 thermal" driver from its device, this will de-register
       acpi_thermal_rel
    3) rmmod then insmod dell_smbios again, now wmi/dell-smbios is using minor
       123
    4) bind the device to "int3400 thermal" driver again, acpi_thermal_rel
       fails to register.
    
    Some drivers may reuse the miscdevice structure after they are deregistered
    If the intention is to allocate a dynamic minor, if the minor number is not
    reset to MISC_DYNAMIC_MINOR before calling misc_register(), it will try to
    register a previously dynamically allocated minor number, which may have
    been registered by a different driver.
    
    One such case is the acpi_thermal_rel misc device, registered by the
    int3400 thermal driver. If the device is unbound from the driver and later
    bound, if there was another dynamic misc device registered in between, it
    would fail to register the acpi_thermal_rel misc device. Other drivers
    behave similarly.
    
    Actually, this kind of issue is prone to happen if APIs
    misc_register()/misc_deregister() are invoked by driver's
    probe()/remove() separately.
    
    Instead of fixing all the drivers, just reset the minor member to
    MISC_DYNAMIC_MINOR in misc_deregister() in case it was a dynamically
    allocated minor number, as error handling of misc_register() does.
    
    Cc: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Zijun Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xion Wang <[email protected]>
Date:   Thu Sep 4 14:37:04 2025 +0800

    char: Use list_del_init() in misc_deregister() to reinitialize list pointer
    
    [ Upstream commit e28022873c0d051e980c4145f1965cab5504b498 ]
    
    Currently, misc_deregister() uses list_del() to remove the device
    from the list. After list_del(), the list pointers are set to
    LIST_POISON1 and LIST_POISON2, which may help catch use-after-free bugs,
    but does not reset the list head.
    If misc_deregister() is called more than once on the same device,
    list_empty() will not return true, and list_del() may be called again,
    leading to undefined behavior.
    
    Replace list_del() with list_del_init() to reinitialize the list head
    after deletion. This makes the code more robust against double
    deregistration and allows safe usage of list_empty() on the miscdevice
    after deregistration.
    
    [ Note, this seems to keep broken out-of-tree drivers from doing foolish
      things.  While this does not matter for any in-kernel drivers,
      external drivers could use a bit of help to show them they shouldn't
      be doing stuff like re-registering misc devices - gregkh ]
    
    Signed-off-by: Xion Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cristian Birsan <[email protected]>
Date:   Thu Nov 21 17:47:17 2024 +0200

    clk: at91: add ACR in all PLL settings
    
    [ Upstream commit bfa2bddf6ffe0ac034d02cda20c74ef05571210e ]
    
    Add the ACR register to all PLL settings and provide the correct
    ACR value for each PLL used in different SoCs.
    
    Suggested-by: Mihai Sain <[email protected]>
    Signed-off-by: Cristian Birsan <[email protected]>
    [[email protected]: add sama7d65 and review commit message]
    Signed-off-by: Nicolas Ferre <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ryan Wanner <[email protected]>
Date:   Mon Sep 8 13:07:17 2025 -0700

    clk: at91: clk-master: Add check for divide by 3
    
    [ Upstream commit e0237f5635727d64635ec6665e1de9f4cacce35c ]
    
    A potential divider for the master clock is div/3. The register
    configuration for div/3 is MASTER_PRES_MAX. The current bit shifting
    method does not work for this case. Checking for MASTER_PRES_MAX will
    ensure the correct decimal value is stored in the system.
    
    Signed-off-by: Ryan Wanner <[email protected]>
    Signed-off-by: Nicolas Ferre <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nicolas Ferre <[email protected]>
Date:   Wed Aug 27 17:08:10 2025 +0200

    clk: at91: clk-sam9x60-pll: force write to PLL_UPDT register
    
    [ Upstream commit af98caeaa7b6ad11eb7b7c8bfaddc769df2889f3 ]
    
    This register is important for sequencing the commands to PLLs, so
    actually write the update bits with regmap_write_bits() instead of
    relying on a read/modify/write regmap command that could skip the actual
    hardware write if the value is identical to the one read.
    
    It's changed when modification is needed to the PLL, when
    read-only operation is done, we could keep the call to
    regmap_update_bits().
    
    Add a comment to the sam9x60_div_pll_set_div() function that uses this
    PLL_UPDT register so that it's used consistently, according to the
    product's datasheet.
    
    Signed-off-by: Nicolas Ferre <[email protected]>
    Tested-by: Ryan Wanner <[email protected]> # on sama7d65 and sam9x75
    Link: https://lore.kernel.org/r/[email protected]
    [claudiu.beznea: fix "Alignment should match open parenthesis"
     checkpatch.pl check]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Balamanikandan Gunasundar <[email protected]>
Date:   Tue Sep 9 16:08:17 2025 +0530

    clk: at91: sam9x7: Add peripheral clock id for pmecc
    
    [ Upstream commit 94a1274100e397a27361ae53ace37be6da42a079 ]
    
    Add pmecc instance id in peripheral clock description.
    
    Signed-off-by: Balamanikandan Gunasundar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [[email protected]: use tabs instead of spaces]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Nicolas Ferre <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shubhrajyoti Datta <[email protected]>
Date:   Fri Sep 5 14:40:02 2025 +0530

    clk: clocking-wizard: Fix output clock register offset for Versal platforms
    
    [ Upstream commit 7c2e86f7b5af93d0e78c16e4359318fe7797671d ]
    
    The output clock register offset used in clk_wzrd_register_output_clocks
    was incorrectly referencing 0x3C instead of 0x38, which caused
    misconfiguration of output dividers on Versal platforms.
    
    Correcting the off-by-one error ensures proper configuration of output
    clocks.
    
    Signed-off-by: Shubhrajyoti Datta <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Marko Mäkelä <[email protected]>
Date:   Sat Aug 2 12:55:46 2025 +0300

    clk: qcom: gcc-ipq6018: rework nss_port5 clock to multiple conf
    
    [ Upstream commit 2f7b168323c22faafb1fbf94ef93b7ce5efc15c6 ]
    
    Rework nss_port5 to use the new multiple configuration implementation
    and correctly fix the clocks for this port under some corner case.
    
    In OpenWrt, this patch avoids intermittent dmesg errors of the form
    nss_port5_rx_clk_src: rcg didn't update its configuration.
    
    This is a mechanical, straightforward port of
    commit e88f03230dc07aa3293b6aeb078bd27370bb2594
    ("clk: qcom: gcc-ipq8074: rework nss_port5/6 clock to multiple conf")
    to gcc-ipq6018, with two conflicts resolved: different frequency of the
    P_XO clock source, and only 5 Ethernet ports.
    
    This was originally developed by JiaY-shi <[email protected]>.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Marko Mäkelä <[email protected]>
    Tested-by: Marko Mäkelä <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tommaso Merciai <[email protected]>
Date:   Wed Sep 3 10:27:52 2025 +0200

    clk: renesas: rzv2h: Re-assert reset on deassert timeout
    
    [ Upstream commit f8c002165ca27d95d3d15e865dd0a47c0a1b14dd ]
    
    Prevent issues during reset deassertion by re-asserting the reset if a
    timeout occurs when trying to deassert. This ensures the reset line is in a
    known state and improves reliability for hardware that may not immediately
    clear the reset monitor bit.
    
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Tommaso Merciai <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Denzeel Oliva <[email protected]>
Date:   Sun Aug 31 12:13:16 2025 +0000

    clk: samsung: exynos990: Add missing USB clock registers to HSI0
    
    [ Upstream commit f00a5dc81744250e7a3f843adfe12d7883282c56 ]
    
    These registers are required for proper USB operation and were omitted
    in the initial clock controller setup.
    
    Signed-off-by: Denzeel Oliva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jacky Bai <[email protected]>
Date:   Mon Jul 28 15:04:46 2025 +0800

    clk: scmi: Add duty cycle ops only when duty cycle is supported
    
    [ Upstream commit 18db1ff2dea0f97dedaeadd18b0cb0a0d76154df ]
    
    For some of the SCMI based platforms, the oem extended config may be
    supported, but not for duty cycle purpose. Skip the duty cycle ops if
    err return when trying to get duty cycle info.
    
    Signed-off-by: Jacky Bai <[email protected]>
    Reviewed-by: Sudeep Holla <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chen-Yu Tsai <[email protected]>
Date:   Wed Sep 10 01:09:47 2025 +0800

    clk: sunxi-ng: sun6i-rtc: Add A523 specifics
    
    [ Upstream commit 7aa8781f379c32c31bd78f1408a31765b2297c43 ]
    
    The A523's RTC block is backward compatible with the R329's, but it also
    has a calibration function for its internal oscillator, which would
    allow it to provide a clock rate closer to the desired 32.768 KHz. This
    is useful on the Radxa Cubie A5E, which does not have an external 32.768
    KHz crystal.
    
    Add new compatible-specific data for it.
    
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Icenowy Zheng <[email protected]>
Date:   Sat Aug 16 17:11:13 2025 +0800

    clk: thead: th1520-ap: set all AXI clocks to CLK_IS_CRITICAL
    
    [ Upstream commit c567bc5fc68c4388c00e11fc65fd14fe86b52070 ]
    
    The AXI crossbar of TH1520 has no proper timeout handling, which means
    gating AXI clocks can easily lead to bus timeout and thus system hang.
    
    Set all AXI clock gates to CLK_IS_CRITICAL. All these clock gates are
    ungated by default on system reset.
    
    In addition, convert all current CLK_IGNORE_UNUSED usage to
    CLK_IS_CRITICAL to prevent unwanted clock gating.
    
    Signed-off-by: Icenowy Zheng <[email protected]>
    Reviewed-by: Drew Fustini <[email protected]>
    Signed-off-by: Drew Fustini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthias Schiffer <[email protected]>
Date:   Mon Aug 25 16:08:11 2025 +0200

    clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled
    
    [ Upstream commit 1e0d75258bd09323cb452655549e03975992b29e ]
    
    As described in AM335x Errata Advisory 1.0.42, WKUP_DEBUGSS_CLKCTRL
    can't be disabled - the clock module will just be stuck in transitioning
    state forever, resulting in the following warning message after the wait
    loop times out:
    
        l3-aon-clkctrl:0000:0: failed to disable
    
    Just add the clock to enable_init_clks, so no attempt is made to disable
    it.
    
    Signed-off-by: Matthias Schiffer <[email protected]>
    Signed-off-by: Alexander Stein <[email protected]>
    Acked-by: Kevin Hilman <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Markus Stockhausen <[email protected]>
Date:   Mon Aug 4 04:03:27 2025 -0400

    clocksource/drivers/timer-rtl-otto: Do not interfere with interrupts
    
    [ Upstream commit c445bffbf28f721e05d0ce06895045fc62aaff7c ]
    
    During normal operation the timers are reprogrammed including an
    interrupt acknowledgement. This has no effect as the whole timer
    is setup from scratch afterwards. Especially in an interrupt this
    has already been done by rttm_timer_interrupt().
    
    Change the behaviour as follows:
    
    - Use rttm_disable_timer() during reprogramming
    - Keep rttm_stop_timer() for all other use cases.
    
    Downstream has already tested and confirmed a patch. See
    https://github.com/openwrt/openwrt/pull/19468
    https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3788
    
    Signed-off-by: Markus Stockhausen <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Tested-by: Stephen Howell <[email protected]>
    Tested-by: Bjørn Mork <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Markus Stockhausen <[email protected]>
Date:   Mon Aug 4 04:03:25 2025 -0400

    clocksource/drivers/timer-rtl-otto: Work around dying timers
    
    [ Upstream commit e7a25106335041aeca4fdf50a84804c90142c886 ]
    
    The OpenWrt distribution has switched from kernel longterm 6.6 to
    6.12. Reports show that devices with the Realtek Otto switch platform
    die during operation and are rebooted by the watchdog. Sorting out
    other possible reasons the Otto timer is to blame. The platform
    currently consists of 4 targets with different hardware revisions.
    It is not 100% clear which devices and revisions are affected.
    
    Analysis shows:
    
    A more aggressive sched/deadline handling leads to more timer starts
    with small intervals. This increases the bug chances. See
    https://marc.info/?l=linux-kernel&m=175276556023276&w=2
    
    Focusing on the real issue a hardware limitation on some devices was
    found. There is a minimal chance that a timer ends without firing an
    interrupt if it is reprogrammed within the 5us before its expiration
    time. Work around this issue by introducing a bounce() function. It
    restarts the timer directly before the normal restart functions as
    follows:
    
    - Stop timer
    - Restart timer with a slow frequency.
    - Target time will be >5us
    - The subsequent normal restart is outside the critical window
    
    Downstream has already tested and confirmed a patch. See
    https://github.com/openwrt/openwrt/pull/19468
    https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3788
    
    Signed-off-by: Markus Stockhausen <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Tested-by: Stephen Howell <[email protected]>
    Tested-by: Bjørn Mork <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Lezcano <[email protected]>
Date:   Mon Aug 4 17:23:19 2025 +0200

    clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel
    
    [ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ]
    
    The driver uses the raw_readl() and raw_writel() functions. Those are
    not for MMIO devices. Replace them with readl() and writel()
    
    [ dlezcano: Fixed typo in the subject s/reald/readl/ ]
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wei Liu <[email protected]>
Date:   Tue Aug 12 19:48:45 2025 +0000

    clocksource: hyper-v: Skip unnecessary checks for the root partition
    
    [ Upstream commit 47691ced158ab3a7ce2189b857b19c0c99a9aa80 ]
    
    The HV_ACCESS_TSC_INVARIANT bit is always zero when Linux runs as the
    root partition. The root partition will see directly what the hardware
    provides.
    
    The old logic in ms_hyperv_init_platform caused the native TSC clock
    source to be incorrectly marked as unstable on x86. Fix it.
    
    Skip the unnecessary checks in code for the root partition. Add one
    extra comment in code to clarify the behavior.
    
    Reviewed-by: Nuno Das Neves <[email protected]>
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dennis Beier <[email protected]>
Date:   Sat Aug 30 16:43:59 2025 +0200

    cpufreq/longhaul: handle NULL policy in longhaul_exit
    
    [ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ]
    
    longhaul_exit() was calling cpufreq_cpu_get(0) without checking
    for a NULL policy pointer. On some systems, this could lead to a
    NULL dereference and a kernel warning or panic.
    
    This patch adds a check using unlikely() and returns early if the
    policy is NULL.
    
    Bugzilla: #219962
    
    Signed-off-by: Dennis Beier <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sohil Mehta <[email protected]>
Date:   Mon Sep 8 16:06:55 2025 -0700

    cpufreq: ondemand: Update the efficient idle check for Intel extended Families
    
    [ Upstream commit 7f3cfb7943d27a7b61bdac8db739cf0bdc28e87d ]
    
    IO time is considered busy by default for modern Intel processors. The
    current check covers recent Family 6 models but excludes the brand new
    Families 18 and 19.
    
    According to Arjan van de Ven, the model check was mainly due to a lack
    of testing on systems before INTEL_CORE2_MEROM. He suggests considering
    all Intel processors as having an efficient idle.
    
    Extend the IO busy classification to all Intel processors starting with
    Family 6, including Family 15 (Pentium 4s) and upcoming Families 18/19.
    
    Use an x86 VFM check and move the function to the header file to avoid
    using arch-specific #ifdefs in the C file.
    
    Signed-off-by: Sohil Mehta <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Added empty line after #include ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aaron Kling <[email protected]>
Date:   Thu Aug 28 21:48:13 2025 -0500

    cpufreq: tegra186: Initialize all cores to max frequencies
    
    [ Upstream commit ba6018929165fc914c665f071f8e8cdbac844a49 ]
    
    During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
    are still at reset values and not reflecting the actual frequency. This
    causes get calls to fail. Set all cores to their respective max
    frequency during probe to initialize the registers to working values.
    
    Suggested-by: Mikko Perttunen <[email protected]>
    Signed-off-by: Aaron Kling <[email protected]>
    Reviewed-by: Mikko Perttunen <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Paresh Bhagat <[email protected]>
Date:   Wed Aug 20 14:03:31 2025 +0530

    cpufreq: ti: Add support for AM62D2
    
    [ Upstream commit b5af45302ebc141662b2b60c713c9202e88c943c ]
    
    Add support for TI K3 AM62D2 SoC to read speed and revision values
    from hardware and pass to OPP layer. AM62D shares the same configuations
    as AM62A so use existing am62a7_soc_data.
    
    Signed-off-by: Paresh Bhagat <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rafael J. Wysocki <[email protected]>
Date:   Fri Sep 19 13:22:20 2025 +0200

    cpuidle: Fail cpuidle device registration if there is one already
    
    [ Upstream commit 7b1b7961170e4fcad488755e5ffaaaf9bd527e8f ]
    
    Refuse to register a cpuidle device if the given CPU has a cpuidle
    device already and print a message regarding it.
    
    Without this, an attempt to register a new cpuidle device without
    unregistering the existing one leads to the removal of the existing
    cpuidle device without removing its sysfs interface.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Nov 2 10:03:32 2025 -0500

    cpuidle: governors: menu: Rearrange main loop in menu_select()
    
    [ Upstream commit 17224c1d2574d29668c4879e1fbf36d6f68cd22b ]
    
    Reduce the indentation level in the main loop of menu_select() by
    rearranging some checks and assignments in it.
    
    No intentional functional impact.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Christian Loehle <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Stable-dep-of: db86f55bf81a ("cpuidle: governors: menu: Select polling state in some more cases")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Nov 2 10:03:33 2025 -0500

    cpuidle: governors: menu: Select polling state in some more cases
    
    [ Upstream commit db86f55bf81a3a297be05ee8775ae9a8c6e3a599 ]
    
    A throughput regression of 11% introduced by commit 779b1a1cb13a ("cpuidle:
    governors: menu: Avoid selecting states with too much latency") has been
    reported and it is related to the case when the menu governor checks if
    selecting a proper idle state instead of a polling one makes sense.
    
    In particular, it is questionable to do so if the exit latency of the
    idle state in question exceeds the predicted idle duration, so add a
    check for that, which is sufficient to make the reported regression go
    away, and update the related code comment accordingly.
    
    Fixes: 779b1a1cb13a ("cpuidle: governors: menu: Avoid selecting states with too much latency")
    Closes: https://lore.kernel.org/linux-pm/[email protected]/
    Reported-by: Doug Smythies <[email protected]>
    Tested-by: Doug Smythies <[email protected]>
    Cc: All applicable <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Christian Loehle <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Haotian Zhang <[email protected]>
Date:   Mon Oct 20 18:11:09 2025 +0800

    crypto: aspeed - fix double free caused by devm
    
    [ Upstream commit 3c9bf72cc1ced1297b235f9422d62b613a3fdae9 ]
    
    The clock obtained via devm_clk_get_enabled() is automatically managed
    by devres and will be disabled and freed on driver detach. Manually
    calling clk_disable_unprepare() in error path and remove function
    causes double free.
    
    Remove the manual clock cleanup in both aspeed_acry_probe()'s error
    path and aspeed_acry_remove().
    
    Fixes: 2f1cf4e50c95 ("crypto: aspeed - Add ACRY RSA driver")
    Signed-off-by: Haotian Zhang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gaurav Jain <[email protected]>
Date:   Fri Sep 5 15:41:48 2025 +0530

    crypto: caam - double the entropy delay interval for retry
    
    [ Upstream commit 9048beca9c5614d486e2b492c0a7867164bf56a8 ]
    
    during entropy evaluation, if the generated samples fail
    any statistical test, then, all of the bits will be discarded,
    and a second set of samples will be generated and tested.
    
    the entropy delay interval should be doubled before performing the
    retry.
    
    also, ctrlpriv->rng4_sh_init and inst_handles both reads RNG DRNG
    status register, but only inst_handles is updated before every retry.
    so only check inst_handles and removing ctrlpriv->rng4_sh_init
    
    Signed-off-by: Gaurav Jain <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yunseong Kim <[email protected]>
Date:   Wed Sep 3 22:16:43 2025 +0900

    crypto: ccp - Fix incorrect payload size calculation in psp_poulate_hsti()
    
    [ Upstream commit 2b0dc40ac6ca16ee0c489927f4856cf9cd3874c7 ]
    
    payload_size field of the request header is incorrectly calculated using
    sizeof(req). Since 'req' is a pointer (struct hsti_request *), sizeof(req)
    returns the size of the pointer itself (e.g., 8 bytes on a 64-bit system),
    rather than the size of the structure it points to. This leads to an
    incorrect payload size being sent to the Platform Security Processor (PSP),
    potentially causing the HSTI query command to fail.
    
    Fix this by using sizeof(*req) to correctly calculate the size of the
    struct hsti_request.
    
    Signed-off-by: Yunseong Kim <[email protected]>
    Reviewed-by: Mario Limonciello (AMD) <[email protected]>> ---
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ashish Kalra <[email protected]>
Date:   Mon Aug 25 21:46:38 2025 +0000

    crypto: ccp: Skip SEV and SNP INIT for kdump boot
    
    [ Upstream commit 8c571019d8a817b701888926529a5d7a826b947b ]
    
    Since SEV or SNP may already be initialized in the previous kernel,
    attempting to initialize them again in the kdump kernel can result
    in SNP initialization failures, which in turn lead to IOMMU
    initialization failures. Moreover, SNP/SEV guests are not run under a
    kdump kernel, so there is no need to initialize SEV or SNP during
    kdump boot.
    
    Skip SNP and SEV INIT if doing kdump boot.
    
    Tested-by: Sairaj Kodilkar <[email protected]>
    Signed-off-by: Ashish Kalra <[email protected]>
    Link: https://lore.kernel.org/r/d884eff5f6180d8b8c6698a6168988118cf9cba1.1756157913.git.ashish.kalra@amd.com
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Weili Qian <[email protected]>
Date:   Sat Sep 13 18:57:53 2025 +0800

    crypto: hisilicon/qm - clear all VF configurations in the hardware
    
    [ Upstream commit 64b9642fc29a14e1fe67842be9c69c7b90a3bcd6 ]
    
    When disabling SR-IOV, clear the configuration of each VF
    in the hardware. Do not exit the configuration clearing process
    due to the failure of a single VF. Additionally, Clear the VF
    configurations before decrementing the PM counter.
    
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Weili Qian <[email protected]>
Date:   Sat Sep 13 18:57:50 2025 +0800

    crypto: hisilicon/qm - invalidate queues in use
    
    [ Upstream commit 85acd1b26b8f5b838887dc965dc3aa2c0253f4d1 ]
    
    Before the device reset, although the driver has set the queue
    status to intercept doorbells sent by the task process, the reset
    thread is isolated from the user-mode task process, so the task process
    may still send doorbells. Therefore, before the reset, the queue is
    directly invalidated, and the device directly discards the doorbells
    sent by the process.
    
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Qianfeng Rong <[email protected]>
Date:   Thu Aug 21 22:20:26 2025 +0800

    crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof()
    
    [ Upstream commit 4c634b6b3c77bba237ee64bca172e73f9cee0cb2 ]
    
    As noted in the kernel documentation [1], open-coded multiplication in
    allocator arguments is discouraged because it can lead to integer overflow.
    
    Use kcalloc() to gain built-in overflow protection, making memory
    allocation safer when calculating allocation size compared to explicit
    multiplication.  Similarly, use size_add() instead of explicit addition
    for 'uobj_chunk_num + sobj_chunk_num'.
    
    Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments #1
    Signed-off-by: Qianfeng Rong <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Acked-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Harald Freudenberger <[email protected]>
Date:   Fri Oct 17 14:32:54 2025 +0200

    crypto: s390/phmac - Do not modify the req->nbytes value
    
    [ Upstream commit 3ac2939bc4341ac28700a2ed0c345ba7e7bdb6fd ]
    
    The phmac implementation used the req->nbytes field on combined
    operations (finup, digest) to track the state:
    with req->nbytes > 0 the update needs to be processed,
    while req->nbytes == 0 means to do the final operation. For
    this purpose the req->nbytes field was set to 0 after successful
    update operation. However, aead uses the req->nbytes field after a
    successful hash operation to determine the amount of data to
    en/decrypt. So an implementation must not modify the nbytes field.
    
    Fixed by a slight rework on the phmac implementation. There is
    now a new field async_op in the request context which tracks
    the (asynch) operation to process. So the 'state' via req->nbytes
    is not needed any more and now this field is untouched and may
    be evaluated even after a request is processed by the phmac
    implementation.
    
    Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac")
    Reported-by: Ingo Franzki <[email protected]>
    Signed-off-by: Harald Freudenberger <[email protected]>
    Tested-by: Ingo Franzki <[email protected]>
    Reviewed-by: Ingo Franzki <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ovidiu Panait <[email protected]>
Date:   Tue Sep 2 16:21:26 2025 +0300

    crypto: sun8i-ce - remove channel timeout field
    
    [ Upstream commit 9a23ea1f7558bdd3f8d2b35b1c2e16a2f9bf671e ]
    
    Using the number of bytes in the request as DMA timeout is really
    inconsistent, as large requests could possibly set a timeout of
    hundreds of seconds.
    
    Remove the per-channel timeout field and use a single, static DMA
    timeout of 3 seconds for all requests.
    
    Signed-off-by: Ovidiu Panait <[email protected]>
    Tested-by: Corentin LABBE <[email protected]>
    Reviewed-by: Corentin LABBE <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christoph Hellwig <[email protected]>
Date:   Mon Aug 18 06:58:21 2025 +0200

    dm error: mark as DM_TARGET_PASSES_INTEGRITY
    
    [ Upstream commit 499cbe0f2fb0641cf07a1a8ac9f7317674295fea ]
    
    Mark dm error as DM_TARGET_PASSES_INTEGRITY so that it can be stacked on
    top of PI capable devices.  The claim is strictly speaking as lie as dm
    error fails all I/O and doesn't pass anything on, but doing the same for
    integrity I/O work just fine :)
    
    This helps to make about two dozen xfstests test cases pass on PI capable
    devices.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Akash Goel <[email protected]>
Date:   Tue Oct 21 17:09:51 2025 +0100

    dma-fence: Fix safe access wrapper to call timeline name method
    
    commit 033559473dd3b55558b535aa37b8848c207b5cbb upstream.
    
    This commit fixes the wrapper function dma_fence_timeline_name(), that
    was added for safe access, to actually call the timeline name method of
    dma_fence_ops.
    
    Cc: <[email protected]> # v6.17+
    Signed-off-by: Akash Goel <[email protected]>
    Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
    Reviewed-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Devendra K Verma <[email protected]>
Date:   Thu Aug 21 17:45:05 2025 +0530

    dmaengine: dw-edma: Set status for callback_result
    
    [ Upstream commit 5e742de97c806a4048418237ef1283e7d71eaf4b ]
    
    DMA Engine has support for the callback_result which provides
    the status of the request and the residue. This helps in
    determining the correct status of the request and in
    efficient resource management of the request.
    The 'callback_result' method is preferred over the deprecated
    'callback' method.
    
    Signed-off-by: Devendra K Verma <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Anil S Keshavamurthy <[email protected]>
Date:   Fri Aug 1 14:59:35 2025 -0700

    dmaengine: idxd: Add a new IAA device ID for Wildcat Lake family platforms
    
    [ Upstream commit c937969a503ebf45e0bebafee4122db22b0091bd ]
    
    A new IAA device ID, 0xfd2d, is introduced across all Wildcat Lake
    family platforms. Add the device ID to the IDXD driver.
    
    Signed-off-by: Anil S Keshavamurthy <[email protected]>
    Signed-off-by: Vinicius Costa Gomes <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rosen Penev <[email protected]>
Date:   Thu Aug 21 15:09:42 2025 -0700

    dmaengine: mv_xor: match alloc_wc and free_wc
    
    [ Upstream commit a33e3b667d2f004fdfae6b442bd4676f6c510abb ]
    
    dma_alloc_wc is used but not dma_free_wc.
    
    Signed-off-by: Rosen Penev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Andreatta <[email protected]>
Date:   Wed Aug 27 17:24:43 2025 +0200

    dmaengine: sh: setup_xref error handling
    
    [ Upstream commit d9a3e9929452780df16f3414f0d59b5f69d058cf ]
    
    This patch modifies the type of setup_xref from void to int and handles
    errors since the function can fail.
    
    `setup_xref` now returns the (eventual) error from
    `dmae_set_dmars`|`dmae_set_chcr`, while `shdma_tx_submit` handles the
    result, removing the chunks from the queue and marking PM as idle in
    case of an error.
    
    Signed-off-by: Thomas Andreatta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mauro Carvalho Chehab <[email protected]>
Date:   Tue Jul 29 18:43:03 2025 +0200

    docs: kernel-doc: avoid script crash on ancient Python
    
    [ Upstream commit fc973dcd73f242480c61eccb1aa7306adafd2907 ]
    
    While we do need at least 3.6 for kernel-doc to work, and at least
    3.7 for it to output functions and structs with parameters at the
    right order, let the python binary be compatible with legacy
    versions.
    
    The rationale is that the Kernel build nowadays calls kernel-doc
    with -none on some places. Better not to bail out when older
    versions are found.
    
    With that, potentially this will run with python 2.7 and 3.2+,
    according with vermin:
    
            $ vermin --no-tips -v ./scripts/kernel-doc
            Detecting python files..
            Analyzing using 24 processes..
            2.7, 3.2     /new_devel/v4l/docs/scripts/kernel-doc
            Minimum required versions: 2.7, 3.2
    
    3.2 minimal requirement is due to argparse.
    
    The minimal version I could check was version 3.4
    (using anaconda). Anaconda doesn't support 3.2 or 3.3
    anymore, and 3.2 doesn't even compile (I tested compiling
    Python 3.2 on Fedora 42 and on Fedora 32 - no show).
    
    With 3.4, the script didn't crash and emitted the right warning:
    
            $ conda create -n py34 python=3.4
            $ conda activate py34
            python --version
            Python 3.4.5
            $ python ./scripts/kernel-doc --none include/media
            Error: Python 3.6 or later is required by kernel-doc
            $ conda deactivate
    
            $ python --version
            Python 3.13.5
            $ python ./scripts/kernel-doc --none include/media
            (no warnings and script ran properly)
    
    Supporting 2.7 is out of scope, as it is EOL for 5 years, and
    changing shebang to point to "python" instead of "python3"
    would have a wider impact.
    
    I did some extra checks about the differences from 3.2 and
    3.4, and didn't find anything that would cause troubles:
    
            grep -rE "yield from|asyncio|pathlib|async|await|enum" scripts/kernel-doc
    
    Also, it doesn't use "@" operator. So, I'm confident that it
    should run (producing the exit warning) since Python 3.2.
    
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Jonathan Corbet <[email protected]>
    Link: https://lore.kernel.org/r/87d55e76b0b1391cb7a83e3e965dbddb83fa9786.1753806485.git.mchehab+huawei@kernel.org
    Signed-off-by: Sasha Levin <[email protected]>

Author: Petr Oros <[email protected]>
Date:   Fri Oct 24 20:55:12 2025 +0200

    dpll: spec: add missing module-name and clock-id to pin-get reply
    
    [ Upstream commit 520ad9e96937e825a117e9f00dd35a3e199d67b5 ]
    
    The dpll.yaml spec incorrectly omitted module-name and clock-id from the
    pin-get operation reply specification, even though the kernel DPLL
    implementation has always included these attributes in pin-get responses
    since the initial implementation.
    
    This spec inconsistency caused issues with the C YNL code generator.
    The generated dpll_pin_get_rsp structure was missing these fields.
    
    Fix the spec by adding module-name and clock-id to the pin-attrs reply
    specification to match the actual kernel behavior.
    
    Fixes: 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML")
    Signed-off-by: Petr Oros <[email protected]>
    Reviewed-by: Ivan Vecera <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Meng Li <[email protected]>
Date:   Fri May 9 13:44:24 2025 +0800

    drm/amd/amdgpu: Release xcp drm memory after unplug
    
    [ Upstream commit e6c2b0f23221ed43c4cc6f636e9ab7862954d562 ]
    
    Add a new API amdgpu_xcp_drm_dev_free().
    After unplug xcp device, need to release xcp drm memory etc.
    
    Co-developed-by: Jiang Liu <[email protected]>
    Signed-off-by: Jiang Liu <[email protected]>
    Signed-off-by: Meng Li <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Reviewed-by: Lijo Lazar <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xi Ruoyao <[email protected]>
Date:   Mon Aug 25 16:52:11 2025 +0800

    drm/amd/display/dml2: Guard dml21_map_dc_state_into_dml_display_cfg with DC_FP_START
    
    [ Upstream commit c97a7dccb3ed680031011cfc1457506e6de49c9a ]
    
    dml21_map_dc_state_into_dml_display_cfg calls (the call is usually
    inlined by the compiler) populate_dml21_surface_config_from_plane_state
    and populate_dml21_plane_config_from_plane_state which may use FPU.  In
    a x86-64 build:
    
        $ objdump --disassemble=dml21_map_dc_state_into_dml_display_cfg \
        > drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_translation_helper.o |
        > grep %xmm -c
        63
    
    Thus it needs to be guarded with DC_FP_START.  But we must note that the
    current code quality of the in-kernel FPU use in AMD dml2 is very much
    problematic: we are actually calling DC_FP_START in dml21_wrapper.c
    here, and this translation unit is built with CC_FLAGS_FPU.  Strictly
    speaking this does not make any sense: with CC_FLAGS_FPU the compiler is
    allowed to generate FPU uses anywhere in the translated code, perhaps
    out of the DC_FP_START guard.  This problematic pattern also occurs in
    at least dml2_wrapper.c, dcn35_fpu.c, and dcn351_fpu.c.  Thus we really
    need a careful audit and refactor for the in-kernel FPU uses, and this
    patch is simply whacking a mole.  However per the reporter, whacking
    this mole is enough to make a 9060XT "just work."
    
    Reported-by: Asiacn <[email protected]>
    Closes: https://github.com/loongson-community/discussions/issues/102
    Tested-by: Asiacn <[email protected]>
    Signed-off-by: Xi Ruoyao <[email protected]>
    Reviewed-by: Huacai Chen <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Karthi Kandasamy <[email protected]>
Date:   Wed Sep 3 14:16:27 2025 +0200

    drm/amd/display: Add AVI infoframe copy in copy_stream_update_to_stream
    
    [ Upstream commit c8bedab2d9a1a0daa49ac20f9928a943f7205582 ]
    
    [WHY]
    Ensure AVI infoframe updates from stream updates are applied to the active
    stream so OS overrides are not lost.
    
    [HOW]
    Copy avi_infopacket to stream when valid flag is set.
    Follow existing infopacket copy pattern and perform a basic validity check before assignment.
    
    Reviewed-by: Aric Cyr <[email protected]>
    Signed-off-by: Karthi Kandasamy <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Wed Aug 27 12:17:19 2025 -0500

    drm/amd/display: Add fallback path for YCBCR422
    
    [ Upstream commit db291ed1732e02e79dca431838713bbf602bda1c ]
    
    [Why]
    DP validation may fail with multiple displays and higher color depths.
    The sink may support others though.
    
    [How]
    When DP bandwidth validation fails, progressively fallback through:
    - YUV422 8bpc (bandwidth efficient)
    - YUV422 6bpc (reduced color depth)
    - YUV420 (last resort)
    
    This resolves cases where displays would show no image due to insufficient
    DP link bandwidth for the requested RGB mode.
    
    Suggested-by: Mauri Carvalho <[email protected]>
    Reviewed-by: Wayne Lin <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Allen Li <[email protected]>
Date:   Fri Sep 5 16:58:38 2025 +0800

    drm/amd/display: Add fast sync field in ultra sleep more for DMUB
    
    [ Upstream commit b65cf4baeb24bdb5fee747679ee88f1ade5c1d6c ]
    
    [Why&How]
    We need to inform DMUB whether fast sync in ultra sleep mode is supported,
    so that it can disable desync error detection when the it is not enabled.
    This helps prevent unexpected desync errors when transitioning out of
    ultra sleep mode.
    
    Add fast sync in ultra sleep mode field in replay copy setting command.
    
    Reviewed-by: Robin Chen <[email protected]>
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Allen Li <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Hung <[email protected]>
Date:   Thu Oct 16 20:08:10 2025 -0600

    drm/amd/display: Add HDR workaround for a specific eDP
    
    commit 7d08c3b1731014dd1cfd0bf8b0cb1cef9dfd191e upstream.
    
    [WHY & HOW]
    Some eDP panels suffer from flicking when HDR is enabled in KDE or
    Gnome.
    
    This add another quirk to worksaround to skip VSC that is incompatible
    with an eDP panel.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4452
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 99441824bec63549a076cd86631d138ec9a0c71c)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Dillon Varone <[email protected]>
Date:   Mon Sep 15 11:35:37 2025 -0400

    drm/amd/display: Add missing post flip calls
    
    [ Upstream commit 54980f3c63ed3e5cca3d251416581193c90eae76 ]
    
    [WHY&HOW]
    dc_post_update_surfaces_to_stream needs to be called after a full update
    completes in order to optimize clocks and watermarks for power. Add
    missing calls before idle entry is requested to ensure optimal power.
    
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Dillon Varone <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Fri Jun 27 10:10:31 2025 -0400

    drm/amd/display: add more cyan skillfish devices
    
    [ Upstream commit 3cf06bd4cf2512d564fdb451b07de0cebe7b138d ]
    
    Add PCI IDs to support display probe for cyan skillfish
    family of SOCs.
    
    Acked-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Strauss <[email protected]>
Date:   Thu Jul 17 16:18:58 2025 -0400

    drm/amd/display: Cache streams targeting link when performing LT automation
    
    [ Upstream commit f5b69101f956f5b89605a13cb15f093a7906f2a1 ]
    
    [WHY]
    Last LT automation update can cause crash by referencing current_state and
    calling into dc_update_planes_and_stream which may clobber current_state.
    
    [HOW]
    Cache relevant stream pointers and iterate through them instead of relying
    on the current_state.
    
    Reviewed-by: Wenjing Liu <[email protected]>
    Signed-off-by: Michael Strauss <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Melissa Wen <[email protected]>
Date:   Thu Sep 11 14:21:20 2025 -0300

    drm/amd/display: change dc stream color settings only in atomic commit
    
    [ Upstream commit 51cb93aa0c4a9bb126b76f6e9fd640d88de25cee ]
    
    Don't update DC stream color components during atomic check. The driver
    will continue validating the new CRTC color state but will not change DC
    stream color components. The DC stream color state will only be
    programmed at commit time in the `atomic_setup_commit` stage.
    
    It fixes gamma LUT loss reported by KDE users when changing brightness
    quickly or changing Display settings (such as overscan) with nightlight
    on and HDR. As KWin can do a test commit with color settings different
    from those that should be applied in a non-test-only commit, if the
    driver changes DC stream color state in atomic check, this state can be
    eventually HW programmed in commit tail, instead of the respective state
    set by the non-blocking commit.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4444
    Reported-by: Xaver Hugl <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dillon Varone <[email protected]>
Date:   Thu Aug 14 12:01:15 2025 -0400

    drm/amd/display: Consider sink max slice width limitation for dsc
    
    [ Upstream commit 6b34e7ed4ba583ee77032a4c850ff97ba16ad870 ]
    
    [WHY&HOW]
    The sink max slice width limitation should be considered for DSC, but
    was removed in "refactor DSC cap calculations".
    This patch adds it back and takes the valid minimum between the sink and
    source.
    
    Signed-off-by: Dillon Varone <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Reviewed-by: Wenjing Liu <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Mon Aug 25 23:56:30 2025 +0200

    drm/amd/display: Disable VRR on DCE 6
    
    [ Upstream commit 043c87d7d56e135393f8aab927148096e2d17589 ]
    
    DCE 6 was not advertised as being able to support VRR,
    so let's mark it as unsupported for now.
    
    The VRR implementation in amdgpu_dm depends on the VUPDATE
    interrupt which is not registered for DCE 6.
    
    Signed-off-by: Timur Kristóf <[email protected]>
    Reviewed-by: Rodrigo Siqueira <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Schwartz <[email protected]>
Date:   Mon Oct 20 16:09:34 2025 -0700

    drm/amd/display: Don't program BLNDGAM_MEM_PWR_FORCE when CM low-power is disabled on DCN30
    
    commit 382bd6a792836875da555fe9a2b51222b813fed1 upstream.
    
    Before commit 33056a97ae5e ("drm/amd/display: Remove double checks for
    `debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL)
    checked the low-power debug flag before calling
    dpp3_power_on_blnd_lut(false).
    
    After commit 33056a97ae5e ("drm/amd/display: Remove double checks for
    `debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL)
    unconditionally calls dpp3_power_on_blnd_lut(false). The BLNDGAM power
    helper writes BLNDGAM_MEM_PWR_FORCE when CM low-power is disabled, causing
    immediate SRAM power toggles instead of deferring at vupdate. This can
    disrupt atomic color/LUT sequencing during transitions between
    direct scanout and composition within gamescope's DRM backend on
    Steam Deck OLED.
    
    To fix this, leave the BLNDGAM power state unchanged when low-power is
    disabled, matching dpp3_power_on_hdr3dlut and dpp3_power_on_shaper.
    
    Fixes: 33056a97ae5e ("drm/amd/display: Remove double checks for `debug.enable_mem_low_power.bits.cm`")
    Signed-off-by: Matthew Schwartz <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 13ff4f63fcddfc84ec8632f1443936b00aa26725)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Mon Aug 25 23:56:31 2025 +0200

    drm/amd/display: Don't use non-registered VUPDATE on DCE 6
    
    [ Upstream commit 6cbe6e072c5d088101cd542ad8ef8541edeea5c3 ]
    
    The VUPDATE interrupt isn't registered on DCE 6, so don't try
    to use that.
    
    This fixes a page flip timeout after sleep/resume on DCE 6.
    
    Signed-off-by: Timur Kristóf <[email protected]>
    Reviewed-by: Rodrigo Siqueira <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ausef Yousof <[email protected]>
Date:   Thu Aug 21 18:11:54 2025 -0400

    drm/amd/display: dont wait for pipe update during medupdate/highirq
    
    [ Upstream commit 895b61395eefd28376250778a741f11e12715a39 ]
    
    [why&how]
    control flag for the wait during pipe update wait for vupdate should
    be set if update type is not fast or med to prevent an invalid sleep
    operation
    
    Reviewed-by: Alvin Lee <[email protected]>
    Signed-off-by: Ausef Yousof <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wayne Lin <[email protected]>
Date:   Wed Nov 5 10:36:31 2025 +0800

    drm/amd/display: Enable mst when it's detected but yet to be initialized
    
    commit 3c6a743c6961cc2cab453b343bb157d6bbbf8120 upstream.
    
    [Why]
    drm_dp_mst_topology_queue_probe() is used under the assumption that
    mst is already initialized. If we connect system with SST first
    then switch to the mst branch during suspend, we will fail probing
    topology by calling the wrong API since the mst manager is yet to
    be initialized.
    
    [How]
    At dm_resume(), once it's detected as mst branc connected, check if
    the mst is initialized already. If not, call
    dm_helpers_dp_mst_start_top_mgr() instead to initialize mst
    
    V2: Adjust the commit msg a bit
    
    Fixes: bc068194f548 ("drm/amd/display: Don't write DP_MSTM_CTRL after LT")
    Cc: Fangzhi Zuo <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 62320fb8d91a0bddc44a228203cfa9bfbb5395bd)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Clay King <[email protected]>
Date:   Mon Jul 7 13:21:30 2025 -0400

    drm/amd/display: ensure committing streams is seamless
    
    [ Upstream commit ca74cc428f2b9d0170c56b473dbcfd7fa01daf2d ]
    
    [Why]
    When transitioning between topologies such as multi-display to single
    display ODM 2:1, pipes might not be freed before use.
    
    [How]
    In dc_commit_streams, commit an additional, minimal transition if
    original transition is not seamless to ensure pipes are freed.
    
    Reviewed-by: Alvin Lee <[email protected]>
    Signed-off-by: Clay King <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Hung <[email protected]>
Date:   Wed Oct 22 16:19:34 2025 -0600

    drm/amd/display: Fix black screen with HDMI outputs
    
    commit fdc93beeadc2439e5e85d056a8fe681dcced09da upstream.
    
    [Why & How]
    This fixes the black screen issue on certain APUs with HDMI,
    accompanied by the following messages:
    
    amdgpu 0000:c4:00.0: amdgpu: [drm] Failed to setup vendor info
                         frame on connector DP-1: -22
    amdgpu 0000:c4:00.0: [drm] Cannot find any crtc or sizes [drm]
                         Cannot find any crtc or sizes
    
    Fixes: 489f0f600ce2 ("drm/amd/display: Fix DVI-D/HDMI adapters")
    Suggested-by: Timur Kristóf <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 678c901443a6d2e909e3b51331a20f9d8f84ce82)
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Aurabindo Pillai <[email protected]>
Date:   Wed Jun 25 10:11:22 2025 -0400

    drm/amd/display: fix condition for setting timing_adjust_pending
    
    [ Upstream commit 1a6a3374ecb9899ccf0d209b5783a796bdba8cec ]
    
    timing_adjust_pending is used to defer certain programming sequences
    when OTG timing is about to be changed, like with VRR. Insufficient
    checking for timing change in this case caused a regression which
    reduces PSR Replay residency.
    
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Robin Chen <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nicholas Kazlauskas <[email protected]>
Date:   Fri Aug 8 10:26:22 2025 -0400

    drm/amd/display: Fix DMCUB loading sequence for DCN3.2
    
    [ Upstream commit 18e755155caa57a6e6c4aa4a40b0db0fba015289 ]
    
    [Why]
    New sequence from HW for reset and firmware reloading has been
    provided that aims to stabilize the reload sequence in the case the
    firmware is hung or has outstanding requests.
    
    [How]
    Update the sequence to remove the DMUIF reset and the redundant
    writes in the release.
    
    Reviewed-by: Sreeja Golui <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ausef Yousof <[email protected]>
Date:   Tue Sep 2 12:10:18 2025 -0400

    drm/amd/display: fix dml ms order of operations
    
    [ Upstream commit 02a6c2e4b28ff31f7a904c196a99fb2efe81e2cf ]
    
    [why&how]
    small error in order of operations in immediateflipbytes
    calculation on dml ms side that can result in dml ms
    and mp mismatch immediateflip support for a given pipe
    and thus an invalid hw state, correct the order to align
    with mp.
    
    Reviewed-by: Leo Chen <[email protected]>
    Signed-off-by: Ausef Yousof <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aurabindo Pillai <[email protected]>
Date:   Mon Jul 21 11:03:39 2025 -0400

    drm/amd/display: fix dmub access race condition
    
    [ Upstream commit c210b757b400959577a5a17b783b5959b82baed8 ]
    
    Accessing DC from amdgpu_dm is usually preceded by acquisition of
    dc_lock mutex. Most of the DC API that DM calls are under a DC lock.
    However, there are a few that are not. Some DC API called from interrupt
    context end up sending DMUB commands via a DC API, while other threads were
    using DMUB. This was apparent from a race between calls for setting idle
    optimization enable/disable and the DC API to set vmin/vmax.
    
    Offload the call to dc_stream_adjust_vmin_vmax() to a thread instead
    of directly calling them from the interrupt handler such that it waits
    for dc_lock.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Roman Li <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ovidiu Bunea <[email protected]>
Date:   Tue Jul 15 17:26:39 2025 -0400

    drm/amd/display: Fix dmub_cmd header alignment
    
    [ Upstream commit 327aba7f558187e451636c77a1662a2858438dc9 ]
    
    [why & how]
    Header misalignment in struct dmub_cmd_replay_copy_settings_data and
    struct dmub_alpm_auxless_data causes incorrect data read between driver
    and dmub.
    Fix the misalignment and ensure that everything is aligned to 4-byte
    boundaries.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Ovidiu Bunea <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Mon Aug 25 23:33:33 2025 +0200

    drm/amd/display: Fix DVI-D/HDMI adapters
    
    [ Upstream commit 489f0f600ce2c0dae640df9035e1d82677d2580f ]
    
    When the EDID has the HDMI bit, we should simply select
    the HDMI signal type even on DVI ports.
    
    For reference see, the legacy amdgpu display code:
    amdgpu_atombios_encoder_get_encoder_mode
    which selects ATOM_ENCODER_MODE_HDMI for the same case.
    
    This commit fixes DVI connectors to work with DVI-D/HDMI
    adapters so that they can now produce output over these
    connectors for HDMI monitors with higher bandwidth modes.
    With this change, even HDMI audio works through DVI.
    
    For testing, I used a CAA-DMDHFD3 DVI-D/HDMI adapter
    with the following GPUs:
    
    Tahiti (DCE 6) - DC can now output 4K 30 Hz over DVI
    Polaris 10 (DCE 11.2) - DC can now output 4K 60 Hz over DVI
    
    Signed-off-by: Timur Kristóf <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sridevi Arvindekar <[email protected]>
Date:   Wed Sep 10 11:04:07 2025 -0400

    drm/amd/display: Fix for test crash due to power gating
    
    [ Upstream commit 0bf6b216d4783cb51f9af05a49d3cce4fc22dc24 ]
    
    [Why/How]
    Call power gating routine only if it is defined.
    
    Reviewed-by: Alvin Lee <[email protected]>
    Signed-off-by: Sridevi Arvindekar <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ivan Lipski <[email protected]>
Date:   Wed Sep 17 11:00:02 2025 -0400

    drm/amd/display: Fix incorrect return of vblank enable on unconfigured crtc
    
    commit b3656b355b5522cef1b52a7469010009c98156db upstream.
    
    [Why&How]
    Return -EINVAL when userspace asks us to enable vblank on a crtc that is
    not yet enabled.
    
    Suggested-by: Aurabindo Pillai <[email protected]>
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1856
    Signed-off-by: Ivan Lipski <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit cb57b8cdb072dc37723b6906da1c37ff9cbc2da4)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Rong Zhang <[email protected]>
Date:   Tue Oct 14 00:47:35 2025 +0800

    drm/amd/display: Fix NULL deref in debugfs odm_combine_segments
    
    commit 6dd97ceb645c08aca9fc871a3006e47fe699f0ac upstream.
    
    When a connector is connected but inactive (e.g., disabled by desktop
    environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading
    odm_combine_segments causes kernel NULL pointer dereference.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: Oops: 0000 [#1] SMP NOPTI
     CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy)  e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6
     Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025
     RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]
     Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00>
     RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286
     RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8
     RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000
     RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0
     R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08
     R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001
     FS:  00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0
     PKRU: 55555554
     Call Trace:
      <TASK>
      seq_read_iter+0x125/0x490
      ? __alloc_frozen_pages_noprof+0x18f/0x350
      seq_read+0x12c/0x170
      full_proxy_read+0x51/0x80
      vfs_read+0xbc/0x390
      ? __handle_mm_fault+0xa46/0xef0
      ? do_syscall_64+0x71/0x900
      ksys_read+0x73/0xf0
      do_syscall_64+0x71/0x900
      ? count_memcg_events+0xc2/0x190
      ? handle_mm_fault+0x1d7/0x2d0
      ? do_user_addr_fault+0x21a/0x690
      ? exc_page_fault+0x7e/0x1a0
      entry_SYSCALL_64_after_hwframe+0x6c/0x74
     RIP: 0033:0x7f44d4031687
     Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00>
     RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000
     RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687
     RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003
     RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000
     R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000
      </TASK>
     Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x>
      snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn>
      platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp>
     CR2: 0000000000000000
     ---[ end trace 0000000000000000 ]---
     RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]
     Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00>
     RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286
     RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8
     RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000
     RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0
     R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08
     R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001
     FS:  00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0
     PKRU: 55555554
    
    Fix this by checking pipe_ctx->stream_res.tg before dereferencing.
    
    Fixes: 07926ba8a44f ("drm/amd/display: Add debugfs interface for ODM combine info")
    Signed-off-by: Rong Zhang <[email protected]>
    Reviewed-by: Mario Limoncello <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit f19bbecd34e3c15eed7e5e593db2ac0fc7a0e6d8)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Fangzhi Zuo <[email protected]>
Date:   Tue Apr 8 15:11:43 2025 -0400

    drm/amd/display: Fix pbn_div Calculation Error
    
    [ Upstream commit 12cdfb61b32a7be581ec5932e0b6a482cb098204 ]
    
    [Why]
    dm_mst_get_pbn_divider() returns value integer coming from
    the cast from fixed point, but the casted integer will then be used
    in dfixed_const to be multiplied by 4096. The cast from fixed point to integer
    causes the calculation error becomes bigger when multiplied by 4096.
    
    That makes the calculated pbn_div value becomes smaller than
    it should be, which leads to the req_slot number becomes bigger.
    
    Such error is getting reflected in 8k30 timing,
    where the correct and incorrect calculated req_slot 62.9 Vs 63.1.
    That makes the wrong calculation failed to light up 8k30
    after a dock under HBR3 x 4.
    
    [How]
    Restore the accuracy by keeping the fraction part
    calculated for the left shift operation.
    
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Fangzhi Zuo <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aurabindo Pillai <[email protected]>
Date:   Tue Aug 5 10:02:07 2025 -0400

    drm/amd/display: Fix vupdate_offload_work doc
    
    commit e9c840d4505d5049da1873acf93744d384b12a0b upstream.
    
    Fix the following warning in struct documentation:
    
    drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:168: warning: expecting prototype for struct dm_vupdate_work. Prototype was for struct vupdate_offload_work instead
    
    Fixes: c210b757b400 ("drm/amd/display: fix dmub access race condition")
    Reported-by: Stephen Rothwell <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Clay King <[email protected]>
Date:   Wed Aug 20 15:04:29 2025 -0400

    drm/amd/display: incorrect conditions for failing dto calculations
    
    [ Upstream commit 306cbcc6f687d791ab3cc8fbbe30f5286fd0d1e5 ]
    
    [Why & How]
    Previously, when calculating dto phase, we would incorrectly fail when phase
    <=0 without additionally checking for the integer value. This meant that
    calculations would incorrectly fail when the desired pixel clock was an exact
    multiple of the reference clock.
    
    Reviewed-by: Dillon Varone <[email protected]>
    Signed-off-by: Clay King <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Strauss <[email protected]>
Date:   Wed Mar 19 18:04:01 2025 -0400

    drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration
    
    [ Upstream commit e3419e1e44b87d4176fb98679a77301b1ca40f63 ]
    
    [WHY]
    In the worst case, AUX intra-hop done can take hundreds of milliseconds as
    each retimer in a link might have to wait a full AUX_RD_INTERVAL to send
    LT abort downstream.
    
    [HOW]
    Wait 300ms for each retimer in a link to allow time to propagate a LT abort
    without infinitely waiting on intra-hop done.
    For no-retimer case, keep the max duration at 10ms.
    
    Reviewed-by: Wenjing Liu <[email protected]>
    Signed-off-by: Michael Strauss <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Relja Vojvodic <[email protected]>
Date:   Thu Aug 14 11:33:22 2025 -0400

    drm/amd/display: Increase minimum clock for TMDS 420 with pipe splitting
    
    [ Upstream commit 002a612023c8b105bd3829d81862dee04368d6de ]
    
    [Why]
    -Pipe splitting allows for clocks to be reduced, but when using TMDS 420,
    reduced clocks lead to missed clocks cycles on clock resyncing
    
    [How]
    -Impose a minimum clock when using TMDS 420
    
    Reviewed-by: Chris Park <[email protected]>
    Signed-off-by: Relja Vojvodic <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Sun Aug 24 15:20:58 2025 -0500

    drm/amd/display: Indicate when custom brightness curves are in use
    
    [ Upstream commit 68f3c044f37d9f50d67417fa8018d9cf16423458 ]
    
    [Why]
    There is a `scale` sysfs attribute that can be used to indicate when
    non-linear brightness scaling is in use.  As Custom brightness curves
    work by linear interpolation of points the scale is no longer linear.
    
    [How]
    Indicate non-linear scaling when custom brightness curves in use and
    linear scaling otherwise.
    
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lo-an Chen <[email protected]>
Date:   Mon Aug 25 18:16:24 2025 +0800

    drm/amd/display: Init dispclk from bootup clock for DCN314
    
    [ Upstream commit f082daf08f2ff313bdf9cf929a28f6d888117986 ]
    
    [Why]
    Driver does not pick up and save vbios's clocks during init clocks,
    the dispclk in clk_mgr will keep 0 until the first update clocks.
    In some cases, OS changes the timing in the second set mode
    (lower the pixel clock), causing the driver to lower the dispclk
    in prepare bandwidth, which is illegal and causes grey screen.
    
    [How]
    1. Dump and save the vbios's clocks, and init the dispclk in
    dcn314_init_clocks.
    2. Fix the condition in dcn314_update_clocks, regarding a 0kHz value.
    
    Reviewed-by: Charlene Liu <[email protected]>
    Signed-off-by: Lo-an Chen <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Mon Aug 25 23:56:28 2025 +0200

    drm/amd/display: Keep PLL0 running on DCE 6.0 and 6.4
    
    [ Upstream commit 0449726b58ea64ec96b95f95944f0a3650204059 ]
    
    DC can turn off the display clock when no displays are connected
    or when all displays are off, for reference see:
    - dce*_validate_bandwidth
    
    DC also assumes that the DP clock is always on and never powers
    it down, for reference see:
    - dce110_clock_source_power_down
    
    In case of DCE 6.0 and 6.4, PLL0 is the clock source for both
    the engine clock and DP clock, for reference see:
    - radeon_atom_pick_pll
    - atombios_crtc_set_disp_eng_pll
    
    Therefore, PLL0 should be always kept running on DCE 6.0 and 6.4.
    This commit achieves that by ensuring that by setting the display
    clock to the corresponding value in low power state instead of
    zero.
    
    This fixes a page flip timeout on SI with DC which happens when
    all connected displays are blanked.
    
    Signed-off-by: Timur Kristóf <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Strauss <[email protected]>
Date:   Wed Feb 12 14:08:08 2025 -0500

    drm/amd/display: Move setup_stream_attribute
    
    [ Upstream commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414 ]
    
    [WHY]
    If symclk RCO is enabled, stream encoder may not be receiving an ungated
    clock by the time we attempt to set stream attributes when setting dpms
    on. Since the clock is gated, register writes to the stream encoder fail.
    
    [HOW]
    Move set_stream_attribute call into enable_stream, just after the point
    where symclk32_se is ungated.
    Logically there is no need to set stream attributes as early as is
    currently done in link_set_dpms_on, so this should have no impact beyond
    the RCO fix.
    
    Reviewed-by: Ovidiu (Ovi) Bunea <[email protected]>
    Signed-off-by: Michael Strauss <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Wed Sep 24 13:38:34 2025 +0200

    drm/amd/display: Reject modes with too high pixel clock on DCE6-10
    
    commit 118800b0797a046adaa2a8e9dee9b971b78802a7 upstream.
    
    Reject modes with a pixel clock higher than the maximum display
    clock. Use 400 MHz as a fallback value when the maximum display
    clock is not known. Pixel clocks that are higher than the display
    clock just won't work and are not supported.
    
    With the addition of the YUV422 fallback, DC can now accidentally
    select a mode requiring higher pixel clock than actually supported
    when the DP version supports the required bandwidth but the clock
    is otherwise too high for the display engine. DCE 6-10 don't
    support these modes but they don't have a bandwidth calculation
    to reject them properly.
    
    Fixes: db291ed1732e ("drm/amd/display: Add fallback path for YCBCR422")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Cruise Hung <[email protected]>
Date:   Wed Jul 9 19:04:31 2025 +0800

    drm/amd/display: Remove check DPIA HPD status for BW Allocation
    
    [ Upstream commit d0e164f72e6a16e64f660023dc7ad25b31b8b08d ]
    
    [Why & How]
    Link hpd_status is for embedded DPIA only.
    Do not check hpd_status for BW allocation logic.
    
    Reviewed-by: Meenakshikumar Somasundaram <[email protected]>
    Signed-off-by: Cruise Hung <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Danny Wang <[email protected]>
Date:   Thu Jul 24 13:58:21 2025 +0800

    drm/amd/display: Reset apply_eamless_boot_optimization when dpms_off
    
    [ Upstream commit ad335b5fc9ed1cdeb33fbe97d2969b3a2eedaf3e ]
    
    [WHY&HOW]
    The user closed the lid while the system was powering on and opened it
    again before the “apply_seamless_boot_optimization” was set to false,
    resulting in the eDP remaining blank.
    Reset the “apply_seamless_boot_optimization” to false when dpms off.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Danny Wang <[email protected]>
    Signed-off-by: Tom Chung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Tue Aug 26 20:18:22 2025 -0500

    drm/amd/display: Set up pixel encoding for YCBCR422
    
    [ Upstream commit 5e76bc677cb7c92b37d8bc66bb67a18922895be2 ]
    
    [Why]
    fill_stream_properties_from_drm_display_mode() will not configure pixel
    encoding to YCBCR422 when the DRM color format supports YCBCR422 but not
    YCBCR420 or YCBCR4444.  Instead it will fallback to RGB.
    
    [How]
    Add support for YCBCR422 in pixel encoding mapping.
    
    Suggested-by: Mauri Carvalho <[email protected]>
    Reviewed-by: Wayne Lin <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ivan Lipski <[email protected]>
Date:   Thu Aug 7 09:45:26 2025 -0400

    drm/amd/display: Support HW cursor 180 rot for any number of pipe splits
    
    [ Upstream commit 8a359f0f138d5ac7ceffd21b73279be50e516c0a ]
    
    [Why]
    For the HW cursor, its current position in the pipe_ctx->stream struct is
    not affected by the 180 rotation, i. e. the top left corner is still at
    0,0. However, the DPP & HUBP set_cursor_position functions require rotated
    position.
    
    The current approach is hard-coded for ODM 2:1, thus it's failing for
    ODM 4:1, resulting in a double cursor.
    
    [How]
    Instead of calculating the new cursor position relatively to the
    viewports, we calculate it using a viewavable clip_rect of each plane.
    
    The clip_rects are first offset and scaled to the same space as the
    src_rect, i. e. Stream space -> Plane space.
    
    In case of a pipe split, which divides the plane into 2 or more viewports,
    the clip_rect is the union of all the viewports of the given plane.
    
    With the assumption that the viewports in HUBP's set_cursor_position are
    in the Plane space as well, it should produce a correct cursor position
    for any number of pipe splits.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Signed-off-by: Leo Li <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Melissa Wen <[email protected]>
Date:   Thu Sep 11 14:21:19 2025 -0300

    drm/amd/display: update color on atomic commit time
    
    commit 2f9c63883730a0bfecb086e6e59246933f936ca1 upstream.
    
    Use `atomic_commit_setup` to change the DC stream state. It's a
    preparation to remove from `atomic_check` changes in CRTC color
    components of DC stream state and prevent DC to commit TEST_ONLY
    changes.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4444
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paul Hsieh <[email protected]>
Date:   Wed Jul 23 11:51:42 2025 +0800

    drm/amd/display: update dpp/disp clock from smu clock table
    
    [ Upstream commit 2e72fdba8a32ce062a86571edff4592710c26215 ]
    
    [Why]
    The reason some high-resolution monitors fail to display properly
    is that this platform does not support sufficiently high DPP and
    DISP clock frequencies
    
    [How]
    Update DISP and DPP clocks from the smu clock table then DML can
    filter these mode if not support.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Paul Hsieh <[email protected]>
    Signed-off-by: Roman Li <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ostrowski Rafal <[email protected]>
Date:   Tue Jun 24 14:13:53 2025 +0200

    drm/amd/display: Update tiled to tiled copy command
    
    [ Upstream commit 19f76f2390be5abe8d5ed986780b73564ba2baca ]
    
    [Why & How]
    Tiled command rect dimensions is 1 based, do rect_x/y - 1 internally
    
    Reviewed-by: Alvin Lee <[email protected]>
    Signed-off-by: Ostrowski Rafal <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aurabindo Pillai <[email protected]>
Date:   Thu Sep 25 10:23:59 2025 -0400

    drm/amd/display: use GFP_NOWAIT for allocation in interrupt handler
    
    commit 72a1eb3cf573ab957ae412f0efb0cf6ff0876234 upstream.
    
    schedule_dc_vmin_vmax() is called by dm_crtc_high_irq(). Hence, we
    cannot have the former sleep. Use GFP_NOWAIT for allocation in this
    function.
    
    Fixes: c210b757b400 ("drm/amd/display: fix dmub access race condition")
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Sun peng (Leo) Li <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit c04812cbe2f247a1c1e53a9b6c5e659963fe4065)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yihan Zhu <[email protected]>
Date:   Wed Aug 13 16:05:10 2025 -0400

    drm/amd/display: wait for otg update pending latch before clock optimization
    
    [ Upstream commit f382e2d0faad0e0d73f626dbd71f2a4fce03975b ]
    
    [WHY & HOW]
    OTG pending update unlatched will cause system fail, wait OTG fully disabled to
    avoid this error.
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Yihan Zhu <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: TungYu Lu <[email protected]>
Date:   Tue Jul 15 16:56:59 2025 +0800

    drm/amd/display: Wait until OTG enable state is cleared
    
    [ Upstream commit e7496c15d830689cc4fc666b976c845ed2c5ed28 ]
    
    [Why]
    Customer reported an issue that OS starts and stops device multiple times
    during driver installation. Frequently disabling and enabling OTG may
    prevent OTG from being safely disabled and cause incorrect configuration
    upon the next enablement.
    
    [How]
    Add a wait until OTG_CURRENT_MASTER_EN_STATE is cleared as a short term
    solution.
    
    Reviewed-by: Dillon Varone <[email protected]>
    Signed-off-by: TungYu Lu <[email protected]>
    Signed-off-by: Tom Chung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Smith <[email protected]>
Date:   Tue Oct 21 11:08:13 2025 +0200

    drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji
    
    [ Upstream commit 07a13f913c291d6ec72ee4fc848d13ecfdc0e705 ]
    
    Previously this was initialized with zero which represented PCIe Gen
    1.0 instead of using the
    maximum value from the speed table which is the behaviour of all other
    smumgr implementations.
    
    Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.")
    Signed-off-by: John Smith <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit c52238c9fb414555c68340cd80e487d982c1921c)
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Smith <[email protected]>
Date:   Tue Oct 21 11:09:09 2025 +0200

    drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland
    
    [ Upstream commit 501672e3c1576aa9a8364144213c77b98a31a42c ]
    
    Previously this was initialized with zero which represented PCIe Gen
    1.0 instead of using the
    maximum value from the speed table which is the behaviour of all other
    smumgr implementations.
    
    Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.")
    Signed-off-by: John Smith <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 92b0a6ae6672857ddeabf892223943d2f0e06c97)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Wang <[email protected]>
Date:   Wed Oct 22 14:12:21 2025 +0800

    drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table()
    
    [ Upstream commit 238d468d3ed18a324bb9d8c99f18c665dbac0511 ]
    
    'table_index' is a variable defined by the smu driver (kmd)
    'table_id' is a variable defined by the hw smu (pmfw)
    
    This code should use table_index as a bounds check.
    
    Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c")
    Signed-off-by: Yang Wang <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit fca0c66b22303de0d1d6313059baf4dc960a4753)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:05 2025 +0200

    drm/amd/pm: Increase SMC timeout on SI and warn (v3)
    
    [ Upstream commit 813d13524a3bdcc5f0253e06542440ca74c2653a ]
    
    The SMC can take an excessive amount of time to process some
    messages under some conditions.
    
    Background:
    Sending a message to the SMC works by writing the message into
    the mmSMC_MESSAGE_0 register and its optional parameter into
    the mmSMC_SCRATCH0, and then polling mmSMC_RESP_0. Previously
    the timeout was AMDGPU_MAX_USEC_TIMEOUT, ie. 100 ms.
    
    Increase the timeout to 200 ms for all messages and to 1 sec for
    a few messages which I've observed to be especially slow:
    PPSMC_MSG_NoForcedLevel
    PPSMC_MSG_SetEnabledLevels
    PPSMC_MSG_SetForcedLevels
    PPSMC_MSG_DisableULV
    PPSMC_MSG_SwitchToSwState
    
    This fixes the following problems on Tahiti when switching
    from a lower clock power state to a higher clock state, such
    as when DC turns on a display which was previously turned off.
    
    * si_restrict_performance_levels_before_switch would fail
      (if the user previously forced high clocks using sysfs)
    * si_set_sw_state would fail (always)
    
    It turns out that both of those failures were SMC timeouts and
    that the SMC actually didn't fail or hang, just needs more time
    to process those.
    
    Add a warning when there is an SMC timeout to make it easier to
    identify this type of problem in the future.
    
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Wang <[email protected]>
Date:   Wed Sep 3 14:29:12 2025 +0800

    drm/amd/pm: refine amdgpu pm sysfs node error code
    
    [ Upstream commit cf32515a70618c0fb2319bd4a855f4d9447940a8 ]
    
    v1:
    Returns different error codes based on the scenario to help the user app understand
    the AMDGPU device status when an exception occurs.
    
    v2:
    change -NODEV to -EBUSY.
    
    Signed-off-by: Yang Wang <[email protected]>
    Reviewed-by: Lijo Lazar <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lijo Lazar <[email protected]>
Date:   Fri Jul 11 12:15:45 2025 +0530

    drm/amd/pm: Use cached metrics data on aldebaran
    
    [ Upstream commit e87577ef6daa0cfb10ca139c720f0c57bd894174 ]
    
    Cached metrics data validity is 1ms on aldebaran. It's not reasonable
    for any client to query gpu_metrics at a faster rate and constantly
    interrupt PMFW.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Asad Kamal <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lijo Lazar <[email protected]>
Date:   Fri Jul 11 12:18:04 2025 +0530

    drm/amd/pm: Use cached metrics data on arcturus
    
    [ Upstream commit 2f3b1ccf83be83a3330e38194ddfd1a91fec69be ]
    
    Cached metrics data validity is 1ms on arcturus. It's not reasonable for
    any client to query gpu_metrics at a faster rate and constantly
    interrupt PMFW.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Asad Kamal <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Fri Jun 27 10:09:06 2025 -0400

    drm/amd: add more cyan skillfish PCI ids
    
    [ Upstream commit 1e18746381793bef7c715fc5ec5611a422a75c4c ]
    
    Add additional PCI IDs to the cyan skillfish family.
    
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Aug 11 12:00:06 2025 -0500

    drm/amd: Avoid evicting resources at S5
    
    [ Upstream commit 531df041f2a5296174abd8292d298eb62fe1ea97 ]
    
    Normally resources are evicted on dGPUs at suspend or hibernate and
    on APUs at hibernate.  These steps are unnecessary when using the S4
    callbacks to put the system into S5.
    
    Cc: AceLan Kao <[email protected]>
    Cc: Kai-Heng Feng <[email protected]>
    Cc: Mark Pearson <[email protected]>
    Cc: Denis Benato <[email protected]>
    Cc: Merthan Karakaş <[email protected]>
    Tested-by: Eric Naim <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Thu Oct 16 13:55:27 2025 -0500

    drm/amd: Check that VPE has reached DPM0 in idle handler
    
    commit ba10f8d92a2c026b1052b4c0fa2cd7538838c965 upstream.
    
    [Why]
    Newer VPE microcode has functionality that will decrease DPM level
    only when a workload has run for 2 or more seconds.  If VPE is turned
    off before this DPM decrease and the PMFW doesn't reset it when
    power gating VPE, the SOC can get stuck with a higher DPM level.
    
    This can happen from amdgpu's ring buffer test because it's a short
    quick workload for VPE and VPE is turned off after 1s.
    
    [How]
    In idle handler besides checking fences are drained check PMFW version
    to determine if it will reset DPM when power gating VPE.  If PMFW will
    not do this, then check VPE DPM level. If it is not DPM0 reschedule
    delayed work again until it is.
    
    v2: squash in return fix (Alex)
    
    Cc: [email protected]
    Reported-by: Sultan Alsawaf <[email protected]>
    Reviewed-by: Sultan Alsawaf <[email protected]>
    Tested-by: Sultan Alsawaf <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615
    Reviewed-by: Lijo Lazar <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 3ac635367eb589bee8edcc722f812a89970e14b7)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Guangshuo Li <[email protected]>
Date:   Thu Sep 18 18:57:05 2025 +0800

    drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()
    
    [ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ]
    
    kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws
    remains NULL while ectx.ws_size is set, leading to a potential NULL
    pointer dereference in atom_get_src_int() when accessing WS entries.
    
    Return -ENOMEM on allocation failure to avoid the NULL dereference.
    
    Signed-off-by: Guangshuo Li <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sathishkumar S <[email protected]>
Date:   Tue Aug 5 21:28:25 2025 +0530

    drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff
    
    [ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ]
    
    Acquire jpeg_pg_lock before changes to jpeg power state
    and release it after power off from idle work handler.
    
    Signed-off-by: Sathishkumar S <[email protected]>
    Reviewed-by: Leo Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Fri Oct 24 13:08:11 2025 -0400

    drm/amdgpu/smu: Handle S0ix for vangogh
    
    commit 7c5609b72bfe57d8c601d9561e0d2551b605c017 upstream.
    
    Fix the flows for S0ix.  There is no need to stop
    rlc or reintialize PMFW in S0ix.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4659
    Reviewed-by: Mario Limonciello <[email protected]>
    Reported-by: Antheas Kapenekakis <[email protected]>
    Tested-by: Antheas Kapenekakis <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit fd39b5a5830d8f2553e0c09d4d50bdff28b10080)
    Cc: <[email protected]> # c81f5cebe849: drm/amdgpu: Drop PMFW RLC notifier from amdgpu_device_suspend()
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Prike Liang <[email protected]>
Date:   Fri Sep 19 14:31:50 2025 +0800

    drm/amdgpu/userq: assign an error code for invalid userq va
    
    commit 883bd89d00085c2c5f1efcd25861745cb039f9e3 upstream.
    
    It should return an error code if userq VA validation fails.
    
    Fixes: 9e46b8bb0539 ("drm/amdgpu: validate userq buffer virtual address and size")
    Signed-off-by: Prike Liang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Mon Aug 25 09:35:07 2025 -0400

    drm/amdgpu/vpe: cancel delayed work in hw_fini
    
    [ Upstream commit ec813f384b1a9df332e86ff46c422e5d2d00217f ]
    
    We need to cancel any outstanding work at both suspend
    and driver teardown. Move the cancel to hw_fini which
    gets called in both cases.
    
    Reviewed-by: David (Ming Qiang) Wu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jesse.Zhang <[email protected]>
Date:   Tue Sep 16 13:11:06 2025 +0800

    drm/amdgpu: Add fallback to pipe reset if KCQ ring reset fails
    
    [ Upstream commit 7469567d882374dcac3fdb8b300e0f28cf875a75 ]
    
    Add a fallback mechanism to attempt pipe reset when KCQ reset
    fails to recover the ring. After performing the KCQ reset and
    queue remapping, test the ring functionality. If the ring test
    fails, initiate a pipe reset as an additional recovery step.
    
    v2: fix the typo (Lijo)
    v3: try pipeline reset when kiq mapping fails (Lijo)
    
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Lijo Lazar <[email protected]>
    Signed-off-by: Jesse Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tao Zhou <[email protected]>
Date:   Wed Jul 2 16:16:02 2025 +0800

    drm/amdgpu: add range check for RAS bad page address
    
    [ Upstream commit 2b17c240e8cd9ac61d3c82277fbed27edad7f002 ]
    
    Exclude invalid bad pages.
    
    Signed-off-by: Tao Zhou <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Fri Jun 27 10:21:16 2025 -0400

    drm/amdgpu: add support for cyan skillfish gpu_info
    
    [ Upstream commit fa819e3a7c1ee994ce014cc5a991c7fd91bc00f1 ]
    
    Some SOCs which are part of the cyan skillfish family
    rely on an explicit firmware for IP discovery.  Add support
    for the gpu_info firmware.
    
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vitaly Prosyak <[email protected]>
Date:   Thu Aug 7 16:37:25 2025 -0400

    drm/amdgpu: add to custom amdgpu_drm_release drm_dev_enter/exit
    
    [ Upstream commit c31f486bc8dd6f481adcb9cca4a6e1837b8cf127 ]
    
    User queues are disabled before GEM objects are released
    (protecting against user app crashes).
    No races with PCI hot-unplug (because drm_dev_enter prevents cleanup
    if iewdevice is being removed).
    
    Cc: Christian König <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Vitaly Prosyak <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Francis <[email protected]>
Date:   Wed Feb 19 10:01:32 2025 -0500

    drm/amdgpu: Allow kfd CRIU with no buffer objects
    
    [ Upstream commit 85705b18ae7674347f8675f64b2b3115fb1d5629 ]
    
    The kfd CRIU checkpoint ioctl would return an error if trying
    to checkpoint a process with no kfd buffer objects.
    
    This is a normal case and should not be an error.
    
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: David Francis <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mangesh Gadre <[email protected]>
Date:   Mon Aug 25 21:18:42 2025 +0800

    drm/amdgpu: Avoid jpeg v5.0.1 poison irq call trace on sriov guest
    
    [ Upstream commit 01152c30eef972c5ca3b3eeb14f2984fa48d18c2 ]
    
    Sriov guest side doesn't init ras feature hence the poison irq shouldn't
    be put during hw fini
    
    Signed-off-by: Mangesh Gadre <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ce Sun <[email protected]>
Date:   Sun Jul 27 12:06:55 2025 +0800

    drm/amdgpu: Avoid rma causes GPU duplicate reset
    
    [ Upstream commit 21c0ffa612c98bcc6dab5bd9d977a18d565ee28e ]
    
    Try to ensure poison creation handle is completed in time
    to set device rma value.
    
    Signed-off-by: Ce Sun <[email protected]>
    Signed-off-by: Stanley.Yang <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mangesh Gadre <[email protected]>
Date:   Mon Aug 25 21:22:30 2025 +0800

    drm/amdgpu: Avoid vcn v5.0.1 poison irq call trace on sriov guest
    
    [ Upstream commit 37551277dfed796b6749e4fa52bdb62403cfdb42 ]
    
    Sriov guest side doesn't init ras feature hence the poison irq shouldn't
    be put during hw fini
    
    Signed-off-by: Mangesh Gadre <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sathishkumar S <[email protected]>
Date:   Sun Jul 13 01:28:02 2025 +0530

    drm/amdgpu: Check vcn sram load return value
    
    [ Upstream commit faab5ea0836733ef1c8e83cf6b05690a5c9066be ]
    
    Log an error when vcn sram load fails in indirect mode
    and return the same error value.
    
    Signed-off-by: Sathishkumar S <[email protected]>
    Reviewed-by: Leo Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiang Liu <[email protected]>
Date:   Tue Sep 2 22:13:44 2025 +0800

    drm/amdgpu: Correct info field of bad page threshold exceed CPER
    
    [ Upstream commit f320ed01cf5f2259e2035a56900952cb3cc77e7a ]
    
    Correct valid_bits and ms_chk_bits of section info field for bad page
    threshold exceed CPER to match OOB's behavior.
    
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ce Sun <[email protected]>
Date:   Thu Aug 7 12:36:05 2025 +0800

    drm/amdgpu: Correct the counts of nr_banks and nr_errors
    
    [ Upstream commit 907813e5d7cadfeafab12467d748705a5309efb0 ]
    
    Correct the counts of nr_banks and nr_errors
    
    Signed-off-by: Ce Sun <[email protected]>
    Reviewed-by: Yang Wang <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ce Sun <[email protected]>
Date:   Wed Aug 20 17:18:57 2025 +0800

    drm/amdgpu: Correct the loss of aca bank reg info
    
    [ Upstream commit d8442bcad0764c5613e9f8b2356f3e0a48327e20 ]
    
    By polling, poll ACA bank count to ensure that valid
    ACA bank reg info can be obtained
    
    v2: add corresponding delay before send msg to SMU to query mca bank info
    (Stanley)
    
    v3: the loop cannot exit. (Thomas)
    
    v4: remove amdgpu_aca_clear_bank_count. (Kevin)
    
    v5: continuously inject ce. If a creation interruption
    occurs at this time, bank reg info will be lost. (Thomas)
    v5: each cycle is delayed by 100ms. (Tao)
    
    Signed-off-by: Ce Sun <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Fri Jun 27 10:25:09 2025 -0400

    drm/amdgpu: don't enable SMU on cyan skillfish
    
    [ Upstream commit 94bd7bf2c920998b4c756bc8a54fd3dbdf7e4360 ]
    
    Cyan skillfish uses different SMU firmware.
    
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ce Sun <[email protected]>
Date:   Sat Jul 26 20:16:24 2025 +0800

    drm/amdgpu: Effective health check before reset
    
    [ Upstream commit da467352296f8e50c7ab7057ead44a1df1c81496 ]
    
    Move amdgpu_device_health_check into amdgpu_device_gpu_recover to
    ensure that if the device is present can be checked before reset
    
    The reason is:
    1.During the dpc event, the device where the dpc event occurs is not
    present on the bus
    2.When both dpc event and ATHUB event occur simultaneously,the dpc thread
    holds the reset domain lock when detecting error,and the gpu recover thread
    acquires the hive lock.The device is simultaneously in the states of
    amdgpu_ras_in_recovery and occurs_dpc,so gpu recover thread will not go to
    amdgpu_device_health_check.It waits for the reset domain lock held by the
    dpc thread, but dpc thread has not released the reset domain lock.In the dpc
    callback slot_reset,to obtain the hive lock, the hive lock is held by the
    gpu recover thread at this time.So a deadlock occurred
    
    Signed-off-by: Ce Sun <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Perry Yuan <[email protected]>
Date:   Mon Jul 7 10:45:28 2025 +0800

    drm/amdgpu: Fix build error when CONFIG_SUSPEND is disabled
    
    [ Upstream commit 8e3967a71e6fca9c871f98b9289b59c82b88b729 ]
    
    The variable `pm_suspend_target_state` is conditionally defined only when
    `CONFIG_SUSPEND` is enabled (see `include/linux/suspend.h`). Directly
    referencing it without guarding by `#ifdef CONFIG_SUSPEND` causes build
    failures when suspend functionality is disabled (e.g., `CONFIG_SUSPEND=n`).
    
    Reviewed-by: Lijo Lazar <[email protected]>
    Signed-off-by: Perry Yuan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jesse.Zhang <[email protected]>
Date:   Wed Sep 24 16:00:06 2025 +0800

    drm/amdgpu: Fix fence signaling race condition in userqueue
    
    [ Upstream commit b8ae2640f9acd4f411c9227d2493755d03fe440a ]
    
    This commit fixes a potential race condition in the userqueue fence
    signaling mechanism by replacing dma_fence_is_signaled_locked() with
    dma_fence_is_signaled().
    
    The issue occurred because:
    1. dma_fence_is_signaled_locked() should only be used when holding
       the fence's individual lock, not just the fence list lock
    2. Using the locked variant without the proper fence lock could lead
       to double-signaling scenarios:
       - Hardware completion signals the fence
       - Software path also tries to signal the same fence
    
    By using dma_fence_is_signaled() instead, we properly handle the
    locking hierarchy and avoid the race condition while still maintaining
    the necessary synchronization through the fence_list_lock.
    
    v2: drop the comment (Christian)
    
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Jesse Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Srinivasan Shanmugam <[email protected]>
Date:   Sun Aug 31 15:29:56 2025 +0530

    drm/amdgpu: Fix function header names in amdgpu_connectors.c
    
    commit 38ab33dbea594700c8d6cc81eec0a54e95d3eb2f upstream.
    
    Align the function headers for `amdgpu_max_hdmi_pixel_clock` and
    `amdgpu_connector_dvi_mode_valid` with the function implementations so
    they match the expected kdoc style.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1199: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
     * Returns the maximum supported HDMI (TMDS) pixel clock in KHz.
    drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1212: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
     * Validates the given display mode on DVI and HDMI connectors.
    
    Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)")
    Cc: Christian König <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Heng Zhou <[email protected]>
Date:   Wed Aug 13 11:18:04 2025 +0800

    drm/amdgpu: fix nullptr err of vm_handle_moved
    
    [ Upstream commit 859958a7faefe5b7742b7b8cdbc170713d4bf158 ]
    
    If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL.
    So, such kind of amdgpu_bo_va should be updated separately before
    amdgpu_vm_handle_moved.
    
    Signed-off-by: Heng Zhou <[email protected]>
    Reviewed-by: Kasiviswanathan, Harish <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Wed Oct 22 09:14:55 2025 -0400

    drm/amdgpu: fix SPDX header on amd_cper.h
    
    [ Upstream commit 964f8ff276a54ad7fb09168141fb6a8d891d548a ]
    
    This should be MIT.  The driver in general is MIT and
    the license text at the top of the file is MIT so fix
    it.
    
    Fixes: 523b69c65445 ("drm/amd/include: Add amd cper header")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 72c5482cb0f3d3c772c9de50e5a4265258a53f81)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Wed Oct 22 09:17:37 2025 -0400

    drm/amdgpu: fix SPDX header on irqsrcs_vcn_5_0.h
    
    [ Upstream commit 8284a9e91722d3214aac5d54b4e0d2c91af0fdfc ]
    
    This should be MIT.  The driver in general is MIT and
    the license text at the top of the file is MIT so fix
    it.
    
    Fixes: d1bb64651095 ("drm/amdgpu: add irq source ids for VCN5_0/JPEG5_0")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 68c20d7b1779f97d600e61b9e95726c0cd609e2a)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alex Deucher <[email protected]>
Date:   Wed Oct 22 09:12:54 2025 -0400

    drm/amdgpu: fix SPDX headers on amdgpu_cper.c/h
    
    [ Upstream commit f3b37ebf2c94e3a3d7bbf5e3788ad86cf30fc7be ]
    
    These should be MIT.  The driver in general is MIT and
    the license text at the top of the files is MIT so fix
    it.
    
    Fixes: 92d5d2a09de1 ("drm/amdgpu: Introduce funcs for populating CPER")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit abd3f876404cafb107cb34bacb74706bfee11cbe)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sathishkumar S <[email protected]>
Date:   Mon Jul 28 18:27:06 2025 +0530

    drm/amdgpu: Fix unintended error log in VCN5_0_0
    
    commit 46b0e6b9d749cfa891e6969d6565be1131c53aa2 upstream.
    
    The error log is supposed to be gaurded under if failure condition.
    
    Fixes: faab5ea08367 ("drm/amdgpu: Check vcn sram load return value")
    Signed-off-by: Sathishkumar S <[email protected]>
    Reviewed-by: Leo Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Stanley.Yang <[email protected]>
Date:   Mon Jul 28 19:33:50 2025 +0800

    drm/amdgpu: Fix vcn v5.0.1 poison irq call trace
    
    [ Upstream commit b1b29aa88f5367d0367c8eeef643635bc6009a9a ]
    
    Why:
        [13014.890792] Call Trace:
        [13014.890793]  <TASK>
        [13014.890795]  ? show_trace_log_lvl+0x1d6/0x2ea
        [13014.890799]  ? show_trace_log_lvl+0x1d6/0x2ea
        [13014.890800]  ? vcn_v5_0_1_hw_fini+0xe9/0x110 [amdgpu]
        [13014.890872]  ? show_regs.part.0+0x23/0x29
        [13014.890873]  ? show_regs.cold+0x8/0xd
        [13014.890874]  ? amdgpu_irq_put+0xc6/0xe0 [amdgpu]
        [13014.890934]  ? __warn+0x8c/0x100
        [13014.890936]  ? amdgpu_irq_put+0xc6/0xe0 [amdgpu]
        [13014.890995]  ? report_bug+0xa4/0xd0
        [13014.890999]  ? handle_bug+0x39/0x90
        [13014.891001]  ? exc_invalid_op+0x19/0x70
        [13014.891003]  ? asm_exc_invalid_op+0x1b/0x20
        [13014.891005]  ? amdgpu_irq_put+0xc6/0xe0 [amdgpu]
        [13014.891065]  ? amdgpu_irq_put+0x63/0xe0 [amdgpu]
        [13014.891124]  vcn_v5_0_1_hw_fini+0xe9/0x110 [amdgpu]
        [13014.891189]  amdgpu_ip_block_hw_fini+0x3b/0x78 [amdgpu]
        [13014.891309]  amdgpu_device_fini_hw+0x3c1/0x479 [amdgpu]
    How:
        Add omitted vcn poison irq get call.
    
    Signed-off-by: Stanley.Yang <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mangesh Gadre <[email protected]>
Date:   Tue Jul 22 00:27:52 2025 +0800

    drm/amdgpu: Initialize jpeg v5_0_1 ras function
    
    [ Upstream commit 01fa9758c8498d8930df56eca36c88ba3e9493d4 ]
    
    Initialize jpeg v5_0_1 ras function
    
    Signed-off-by: Mangesh Gadre <[email protected]>
    Reviewed-by: Stanley.Yang <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiang Liu <[email protected]>
Date:   Wed Aug 27 09:40:27 2025 +0800

    drm/amdgpu: Notify pmfw bad page threshold exceeded
    
    [ Upstream commit c8d6e90abe50377110f92702fbebc6efdd22391d ]
    
    Notify pmfw when bad page threshold is exceeded, no matter the module
    parameter 'bad_page_threshold' is set or not.
    
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chenglei Xie <[email protected]>
Date:   Thu Aug 7 16:52:34 2025 -0400

    drm/amdgpu: refactor bad_page_work for corner case handling
    
    [ Upstream commit d2fa0ec6e0aea6ffbd41939d0c7671db16991ca4 ]
    
    When a poison is consumed on the guest before the guest receives the host's poison creation msg, a corner case may occur to have poison_handler complete processing earlier than it should to cause the guest to hang waiting for the req_bad_pages reply during a VF FLR, resulting in the VM becoming inaccessible in stress tests.
    
    To fix this issue, this patch refactored the mailbox sequence by seperating the bad_page_work into two parts req_bad_pages_work and handle_bad_pages_work.
    Old sequence:
      1.Stop data exchange work
      2.Guest sends MB_REQ_RAS_BAD_PAGES to host and keep polling for IDH_RAS_BAD_PAGES_READY
      3.If the IDH_RAS_BAD_PAGES_READY arrives within timeout limit, re-init the data exchange region for updated bad page info
        else timeout with error message
    New sequence:
    req_bad_pages_work:
      1.Stop data exhange work
      2.Guest sends MB_REQ_RAS_BAD_PAGES to host
    Once Guest receives IDH_RAS_BAD_PAGES_READY event
    handle_bad_pages_work:
      3.re-init the data exchange region for updated bad page info
    
    Signed-off-by: Chenglei Xie <[email protected]>
    Reviewed-by: Shravan Kumar Gande <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christian König <[email protected]>
Date:   Wed Aug 27 13:14:43 2025 +0200

    drm/amdgpu: reject gang submissions under SRIOV
    
    [ Upstream commit d7ddcf921e7d0d8ebe82e89635bc9dc26ba9540d ]
    
    Gang submission means that the kernel driver guarantees that multiple
    submissions are executed on the HW at the same time on different engines.
    
    Background is that those submissions then depend on each other and each
    can't finish stand alone.
    
    SRIOV now uses world switch to preempt submissions on the engines to allow
    sharing the HW resources between multiple VFs.
    
    The problem is now that the SRIOV world switch can't know about such inter
    dependencies and will cause a timeout if it waits for a partially running
    gang submission.
    
    To conclude SRIOV and gang submissions are fundamentally incompatible at
    the moment. For now just disable them.
    
    Signed-off-by: Christian König <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lijo Lazar <[email protected]>
Date:   Tue Sep 2 11:37:37 2025 +0530

    drm/amdgpu: Release hive reference properly
    
    [ Upstream commit c1456fadce0c99175f97e66c2b982dd051e01aa2 ]
    
    xgmi hive reference is taken on function entry, but not released
    correctly for all paths. Use __free() to release reference properly.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Ce Sun <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lijo Lazar <[email protected]>
Date:   Mon Oct 6 10:39:03 2025 +0530

    drm/amdgpu: Report individual reset error
    
    [ Upstream commit 2e97663760e5fb7ee14f399c68e57b894f01e505 ]
    
    If reinitialization of one of the GPUs fails after reset, it logs
    failure on all subsequent GPUs eventhough they have resumed
    successfully.
    
    A sample log where only device at 0000:95:00.0 had a failure -
    
            amdgpu 0000:15:00.0: amdgpu: GPU reset(19) succeeded!
            amdgpu 0000:65:00.0: amdgpu: GPU reset(19) succeeded!
            amdgpu 0000:75:00.0: amdgpu: GPU reset(19) succeeded!
            amdgpu 0000:85:00.0: amdgpu: GPU reset(19) succeeded!
            amdgpu 0000:95:00.0: amdgpu: GPU reset(19) failed
            amdgpu 0000:e5:00.0: amdgpu: GPU reset(19) failed
            amdgpu 0000:f5:00.0: amdgpu: GPU reset(19) failed
            amdgpu 0000:05:00.0: amdgpu: GPU reset(19) failed
            amdgpu 0000:15:00.0: amdgpu: GPU reset end with ret = -5
    
    To avoid confusion, report the error for each device
    separately and return the first error as the overall result.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Asad Kamal <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 16:50:36 2025 +0200

    drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)
    
    [ Upstream commit 585b2f685c56c5095cc22c7202bf74d8e9a73cdd ]
    
    Update the legacy (non-DC) display code to respect the maximum
    pixel clock for HDMI and DVI-D. Reject modes that would require
    a higher pixel clock than can be supported.
    
    Also update the maximum supported HDMI clock value depending on
    the ASIC type.
    
    For reference, see the DC code:
    check max_hdmi_pixel_clock in dce*_resource.c
    
    v2:
    Fix maximum clocks for DVI-D and DVI/HDMI adapters.
    
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yunxiang Li <[email protected]>
Date:   Fri Jul 25 12:56:35 2025 -0400

    drm/amdgpu: skip mgpu fan boost for multi-vf
    
    [ Upstream commit ba5e322b2617157edb757055252a33587b6729e0 ]
    
    On multi-vf setup if the VM have two vf assigned, perhaps from two
    different gpus, mgpu fan boost will fail.
    
    Signed-off-by: Yunxiang Li <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiang Liu <[email protected]>
Date:   Wed Jul 30 11:07:43 2025 +0800

    drm/amdgpu: Skip poison aca bank from UE channel
    
    [ Upstream commit 8e8e08c831f088ed581444c58a635c49ea1222ab ]
    
    Avoid GFX poison consumption errors logged when fatal error occurs.
    
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Tao Zhou <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiang Liu <[email protected]>
Date:   Wed Jul 23 14:28:35 2025 +0800

    drm/amdgpu: Update IPID value for bad page threshold CPER
    
    [ Upstream commit 8f0245ee95c5ba65a2fe03f60386868353c6a3a0 ]
    
    Update the IPID register value for bad page threshold CPER according to
    the latest definition.
    
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tvrtko Ursulin <[email protected]>
Date:   Thu Jun 12 11:44:27 2025 +0100

    drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl
    
    [ Upstream commit dea75df7afe14d6217576dbc28cc3ec1d1f712fb ]
    
    Replace kmalloc_array() + copy_from_user() with memdup_array_user().
    
    This shrinks the source code and improves separation between the kernel
    and userspace slabs.
    
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Prike Liang <[email protected]>
Date:   Mon Jun 23 16:29:38 2025 +0800

    drm/amdgpu: validate userq buffer virtual address and size
    
    [ Upstream commit 9e46b8bb0539d7bc9a9e7b3072fa4f6082490392 ]
    
    It needs to validate the userq object virtual address to
    determine whether it is residented in a valid vm mapping.
    
    Signed-off-by: Prike Liang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Prike Liang <[email protected]>
Date:   Wed May 14 12:43:57 2025 +0800

    drm/amdgpu: validate userq input args
    
    [ Upstream commit 219be4711a1ba788bc2a9fafc117139d133e5fea ]
    
    This will help on validating the userq input args, and
    rejecting for the invalid userq request at the IOCTLs
    first place.
    
    Signed-off-by: Prike Liang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Philip Yang <[email protected]>
Date:   Fri Oct 31 10:50:02 2025 -0400

    drm/amdkfd: Don't clear PT after process killed
    
    commit 597eb70f7ff7551ff795cd51754b81aabedab67b upstream.
    
    If process is killed. the vm entity is stopped, submit pt update job
    will trigger the error message "*ERROR* Trying to push to a killed
    entity", job will not execute.
    
    Suggested-by: Christian König <[email protected]>
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 10c382ec6c6d1e11975a11962bec21cba6360391)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Philip Yang <[email protected]>
Date:   Mon Sep 15 15:57:32 2025 -0400

    drm/amdkfd: Fix mmap write lock not release
    
    [ Upstream commit 7574f30337e19045f03126b4c51f525b84e5049e ]
    
    If mmap write lock is taken while draining retry fault, mmap write lock
    is not released because svm_range_restore_pages calls mmap_read_unlock
    then returns. This causes deadlock and system hangs later because mmap
    read or write lock cannot be taken.
    
    Downgrade mmap write lock to read lock if draining retry fault fix this
    bug.
    
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Harish Kasiviswanathan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Huang <[email protected]>
Date:   Mon Aug 18 14:22:53 2025 -0400

    drm/amdkfd: fix vram allocation failure for a special case
    
    [ Upstream commit 93aa919ca05bec544b17ee9a1bfe394ce6c94bd8 ]
    
    When it only allocates vram without va, which is 0, and a
    SVM range allocated stays in this range, the vram allocation
    returns failure. It should be skipped for this case from
    SVM usage check.
    
    Signed-off-by: Eric Huang <[email protected]>
    Reviewed-by: Harish Kasiviswanathan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kent Russell <[email protected]>
Date:   Mon Jul 21 14:06:36 2025 -0400

    drm/amdkfd: Handle lack of READ permissions in SVM mapping
    
    [ Upstream commit 0ed704d058cec7643a716a21888d58c7d03f2c3e ]
    
    HMM assumes that pages have READ permissions by default. Inside
    svm_range_validate_and_map, we add READ permissions then add WRITE
    permissions if the VMA isn't read-only. This will conflict with regions
    that only have PROT_WRITE or have PROT_NONE. When that happens,
    svm_range_restore_work will continue to retry, silently, giving the
    impression of a hang if pr_debug isn't enabled to show the retries..
    
    If pages don't have READ permissions, simply unmap them and continue. If
    they weren't mapped in the first place, this would be a no-op. Since x86
    doesn't support write-only, and PROT_NONE doesn't allow reads or writes
    anyways, this will allow the svm range validation to continue without
    getting stuck in a loop forever on mappings we can't use with HMM.
    
    Signed-off-by: Kent Russell <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geoffrey McRae <[email protected]>
Date:   Tue Jul 8 13:53:40 2025 +1000

    drm/amdkfd: return -ENOTTY for unsupported IOCTLs
    
    [ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ]
    
    Some kfd ioctls may not be available depending on the kernel version the
    user is running, as such we need to report -ENOTTY so userland can
    determine the cause of the ioctl failure.
    
    Signed-off-by: Geoffrey McRae <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Amber Lin <[email protected]>
Date:   Fri Aug 15 14:04:15 2025 -0400

    drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption
    
    [ Upstream commit f3820e9d356132e18405cd7606e22dc87ccfa6d1 ]
    
    When KFD asks CP to preempt queues, other than preempt CP queues, CP
    also requests SDMA to preempt SDMA queues with UNMAP_LATENCY timeout.
    Currently queue_preemption_timeout_ms is 9000 ms by default but can be
    configured via module parameter. KFD_UNMAP_LATENCY_MS is hard coded as
    4000 ms though. This patch ties KFD_UNMAP_LATENCY_MS to
    queue_preemption_timeout_ms so in a slow system such as emulator, both
    CP and SDMA slowness are taken into account.
    
    Signed-off-by: Amber Lin <[email protected]>
    Reviewed-by: Harish Kasiviswanathan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Zimmermann <[email protected]>
Date:   Fri Oct 24 09:35:53 2025 +0200

    drm/ast: Clear preserved bits from register output value
    
    commit a9fb41b5def8e1e0103d5fd1453787993587281e upstream.
    
    Preserve the I/O register bits in __ast_write8_i_masked() as specified
    by preserve_mask. Accidentally OR-ing the output value into these will
    overwrite the register's previous settings.
    
    Fixes display output on the AST2300, where the screen can go blank at
    boot. The driver's original commit 312fec1405dd ("drm: Initial KMS
    driver for AST (ASpeed Technologies) 2000 series (v2)") already added
    the broken code. Commit 6f719373b943 ("drm/ast: Blank with VGACR17 sync
    enable, always clear VGACRB6 sync off") triggered the bug.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Reported-by: Peter Schneider <[email protected]>
    Closes: https://lore.kernel.org/dri-devel/[email protected]/
    Tested-by: Peter Schneider <[email protected]>
    Reviewed-by: Jocelyn Falempe <[email protected]>
    Fixes: 6f719373b943 ("drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off")
    Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)")
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Nick Bowler <[email protected]>
    Cc: Douglas Anderson <[email protected]>
    Cc: Dave Airlie <[email protected]>
    Cc: Jocelyn Falempe <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v3.5+
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Tomi Valkeinen <[email protected]>
Date:   Wed Jul 23 13:05:21 2025 +0300

    drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST
    
    [ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ]
    
    While the cdns-dsi does not support DSI burst mode, the burst mode is
    essentially DSI event mode with more versatile clocking and timings.
    Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests
    MIPI_DSI_MODE_VIDEO_BURST.
    
    In my particular use case, this allows the use of ti-sn65dsi83 driver.
    
    Tested-by: Parth Pancholi <[email protected]>
    Tested-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomi Valkeinen <[email protected]>
Date:   Wed Jul 23 13:05:17 2025 +0300

    drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value
    
    [ Upstream commit eea4f89b6461294ed6bea1d3285bb3f79c09a041 ]
    
    The driver tries to calculate the value for REG_WAKEUP_TIME. However,
    the calculation itself is not correct, and to add on it, the resulting
    value is almost always larger than the field's size, so the actual
    result is more or less random.
    
    According to the docs, figuring out the value for REG_WAKEUP_TIME
    requires HW characterization and there's no way to have a generic
    algorithm to come up with the value. That doesn't help at all...
    
    However, we know that the value must be smaller than the line time, and,
    at least in my understanding, the proper value for it is quite small.
    Testing shows that setting it to 1/10 of the line time seems to work
    well. All video modes from my HDMI monitor work with this algorithm.
    
    Hopefully we'll get more information on how to calculate the value, and
    we can then update this.
    
    Tested-by: Parth Pancholi <[email protected]>
    Tested-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Aug 2 13:40:35 2025 +0300

    drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts
    
    [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ]
    
    Detecting the monitor for DisplayPort targets is more complicated than
    just reading the HPD pin level: it requires reading the DPCD in order to
    check what kind of device is attached to the port and whether there is
    an actual display attached.
    
    In order to let DRM framework handle such configurations, disable
    DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP
    driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so
    it is valid for the bridge to report HPD events.
    
    Currently inside the kernel there are only two targets which list
    hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and
    arm64/qcom/sa8295p-adp. Both should be fine with this change.
    
    Cc: Bjorn Andersson <[email protected]>
    Cc: Konrad Dybcio <[email protected]>
    Cc: [email protected]
    Acked-by: Laurent Pinchart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Sep 3 19:21:29 2025 +0300

    drm/bridge: write full Audio InfoFrame
    
    [ Upstream commit f0e7f358e72b10b01361787134ebcbd9e9aa72d9 ]
    
    Instead of writing the first byte of the infoframe (and hoping that the
    rest is default / zeroes), hook Audio InfoFrame support into the
    write_infoframe / clear_infoframes callbacks and use
    drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the
    frame.
    
    Acked-by: Maxime Ripard <[email protected]>
    Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomeu Vizoso <[email protected]>
Date:   Tue Oct 21 11:37:23 2025 +0200

    drm/etnaviv: fix flush sequence logic
    
    [ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ]
    
    The current logic uses the flush sequence from the current address
    space. This is harmless when deducing the flush requirements for the
    current submit, as either the incoming address space is the same one
    as the currently active one or we switch context, in which case the
    flush is unconditional.
    
    However, this sequence is also stored as the current flush sequence
    of the GPU. If we switch context the stored flush sequence will no
    longer belong to the currently active address space. This incoherency
    can then cause missed flushes, resulting in translation errors.
    
    Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling")
    Signed-off-by: Tomeu Vizoso <[email protected]>
    Signed-off-by: Lucas Stach <[email protected]>
    Reviewed-by: Christian Gmeiner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Auld <[email protected]>
Date:   Thu Aug 28 15:24:32 2025 +0100

    drm/gpusvm: fix hmm_pfn_to_map_order() usage
    
    [ Upstream commit c50729c68aaf93611c855752b00e49ce1fdd1558 ]
    
    Handle the case where the hmm range partially covers a huge page (like
    2M), otherwise we can potentially end up doing something nasty like
    mapping memory which is outside the range, and maybe not even mapped by
    the mm. Fix is based on the xe userptr code, which in a future patch
    will directly use gpusvm, so needs alignment here.
    
    v2:
      - Add kernel-doc (Matt B)
      - s/fls/ilog2/ (Thomas)
    
    Reported-by: Thomas Hellström <[email protected]>
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Thomas Hellström <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ville Syrjälä <[email protected]>
Date:   Wed Oct 22 13:07:16 2025 +0300

    drm/i915/dmc: Clear HRR EVT_CTL/HTP to zero on ADL-S
    
    commit dc8aa0cb87a7836b59422cc02d969c8df849ee39 upstream.
    
    On ADL-S the main DMC HRR event DMC_EVT_CTL/HTP are never
    restored to their previous values during DC6 exit. This
    angers assert_dmc_loaded(), and basically makes the HRR
    handler unusable because we don't rewrite EVT_HTP when
    enabling DMC events.
    
    Let's just clear the HRR EVT_CTL/HTP to zero from the
    beginnning so that the expected value matches the post-DC6
    reality.
    
    I suppose if we ever had actual use for HRR we'd have to both,
    reject HRR+PSR, and reprogram EVT_HTP when enabling the event.
    But for now we don't care about HRR so keeping both registers
    zeroed is fine.
    
    Cc: [email protected]
    Tested-by: Petr Vorel <[email protected]>
    Fixes: 43175c92d403 ("drm/i915/dmc: Assert DMC is loaded harder")
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15153
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Petr Vorel <[email protected]>
    Reviewed-by: Imre Deak <[email protected]>
    Tested-by: Imre Deak <[email protected]>
    (cherry picked from commit 4df3b340ff6e9f499735d8b52b96a9257fde3918)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ariel D'Alessandro <[email protected]>
Date:   Fri Oct 24 17:27:56 2025 -0300

    drm/mediatek: Disable AFBC support on Mediatek DRM driver
    
    commit 9882a40640036d5bbc590426a78981526d4f2345 upstream.
    
    Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM
    driver") added AFBC support to Mediatek DRM and enabled the
    32x8/split/sparse modifier.
    
    However, this is currently broken on Mediatek MT8188 (Genio 700 EVK
    platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by
    default since Mesa v25.0.
    
    Kernel trace reports vblank timeouts constantly, and the render is garbled:
    
    ```
    [CRTC:62:crtc-0] vblank wait timed out
    WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
    [...]
    Hardware name: MediaTek Genio-700 EVK (DT)
    Workqueue: events_unbound commit_work
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
    lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
    sp : ffff80008337bca0
    x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
    x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
    x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
    x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
    x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
    x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
    x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
    x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
    x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
    x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
    Call trace:
     drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
     drm_atomic_helper_commit_tail_rpm+0x64/0x80
     commit_tail+0xa4/0x1a4
     commit_work+0x14/0x20
     process_one_work+0x150/0x290
     worker_thread+0x2d0/0x3ec
     kthread+0x12c/0x210
     ret_from_fork+0x10/0x20
    ---[ end trace 0000000000000000 ]---
    ```
    
    Until this gets fixed upstream, disable AFBC support on this platform, as
    it's currently broken with upstream Mesa.
    
    Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver")
    Cc: [email protected]
    Signed-off-by: Ariel D'Alessandro <[email protected]>
    Reviewed-by: Daniel Stone <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Reviewed-by: Macpaul Lin <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Johan Hovold <[email protected]>
Date:   Mon Oct 6 11:39:37 2025 +0200

    drm/mediatek: Fix device use-after-free on unbind
    
    commit 926d002e6d7e2f1fd5c1b53cf6208153ee7d380d upstream.
    
    A recent change fixed device reference leaks when looking up drm
    platform device driver data during bind() but failed to remove a partial
    fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix
    kobject put for component sub-drivers").
    
    This results in a reference imbalance on component bind() failures and
    on unbind() which could lead to a user-after-free.
    
    Make sure to only drop the references after retrieving the driver data
    by effectively reverting the previous partial fix.
    
    Note that holding a reference to a device does not prevent its driver
    data from going away so there is no point in keeping the reference.
    
    Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv")
    Reported-by: Sjoerd Simons <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Cc: Ma Ke <[email protected]>
    Cc: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Sjoerd Simons <[email protected]>
    Tested-by: Sjoerd Simons <[email protected]>
    Tested-by: Ritesh Raj Sarraf <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Akhil P Oommen <[email protected]>
Date:   Thu Sep 11 02:14:05 2025 +0530

    drm/msm/a6xx: Fix GMU firmware parser
    
    [ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ]
    
    Current parser logic for GMU firmware assumes a dword aligned payload
    size for every block. This is not true for all GMU firmwares. So, fix
    this by using correct 'size' value in the calculation for the offset
    for the next block's header.
    
    Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path")
    Signed-off-by: Akhil P Oommen <[email protected]>
    Acked-by: Konrad Dybcio <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/674040/
    Message-ID: <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Akhil P Oommen <[email protected]>
Date:   Mon Sep 8 13:57:02 2025 +0530

    drm/msm/a6xx: Switch to GMU AO counter
    
    [ Upstream commit f195421318bd00151b3a111af6f315a25c3438a8 ]
    
    CP_ALWAYS_ON counter falls under GX domain which is collapsed during
    IFPC. So switch to GMU_ALWAYS_ON counter for any CPU reads since it is
    not impacted by IFPC. Both counters are clocked by same xo clock source.
    
    Signed-off-by: Akhil P Oommen <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/673373/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Akhil P Oommen <[email protected]>
Date:   Mon Sep 8 13:57:00 2025 +0530

    drm/msm/adreno: Add fenced regwrite support
    
    [ Upstream commit a27d774045566b587bfc1ae9fb122642b06677b8 ]
    
    There are some special registers which are accessible even when GX power
    domain is collapsed during an IFPC sleep. Accessing these registers
    wakes up GPU from power collapse and allow programming these registers
    without additional handshake with GMU. This patch adds support for this
    special register write sequence.
    
    Signed-off-by: Akhil P Oommen <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/673368/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Akhil P Oommen <[email protected]>
Date:   Wed Sep 3 12:49:53 2025 +0530

    drm/msm/adreno: Add speedbin data for A623 GPU
    
    [ Upstream commit 0584da4515dbb4fec69107ce837eef36a7be5d7d ]
    
    Add the speedbin mappings for Adreno 623 GPU.
    
    Signed-off-by: Akhil P Oommen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/672462/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Akhil P Oommen <[email protected]>
Date:   Fri Aug 22 00:25:26 2025 +0530

    drm/msm/adreno: Add speedbins for A663 GPU
    
    [ Upstream commit 0c5300343d0c622f7852145a763c570fbaf68a48 ]
    
    Add speedbin mappings for A663 GPU.
    
    Signed-off-by: Akhil P Oommen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/670096/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jessica Zhang <[email protected]>
Date:   Tue May 6 18:38:39 2025 -0700

    drm/msm/dpu: Filter modes based on adjusted mode clock
    
    [ Upstream commit 62b7d68352881609e237b303fa391410ebc583a5 ]
    
    Filter out modes that have a clock rate greater than the max core clock
    rate when adjusted for the perf clock factor
    
    This is especially important for chipsets such as QCS615 that have lower
    limits for the MDP max core clock.
    
    Since the core CRTC clock is at least the mode clock (adjusted for the
    perf clock factor) [1], the modes supported by the driver should be less
    than the max core clock rate.
    
    [1] https://elixir.bootlin.com/linux/v6.12.4/source/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c#L83
    
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Jessica Zhang <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/652041/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jessica Zhang <[email protected]>
Date:   Tue Sep 23 16:03:50 2025 -0700

    drm/msm/dpu: Fix adjusted mode clock check for 3d merge
    
    commit f5d079564c44baaeedf5e25f4b943aa042ea0eb1 upstream.
    
    Since 3D merge allows for larger modes to be supported across 2 layer
    mixers, filter modes based on adjusted mode clock / 2 when 3d merge is
    supported.
    
    Reported-by: Abel Vesa <[email protected]>
    Fixes: 62b7d6835288 ("drm/msm/dpu: Filter modes based on adjusted mode clock")
    Signed-off-by: Jessica Zhang <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Tested-by: Abel Vesa <[email protected]>
    Tested-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/676353/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Jun 10 16:05:44 2025 +0200

    drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL
    
    [ Upstream commit b63f008f395ca5f6bc89123db97440bdc19981c4 ]
    
    According to Hardware Programming Guide for DSI PHY, the retime buffer
    resync should be done after PLL clock users (byte_clk and intf_byte_clk)
    are enabled.  Downstream also does it as part of configuring the PLL.
    
    Driver was only turning off the resync FIFO buffer, but never bringing it
    on again.
    
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/657823/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Jun 10 16:05:47 2025 +0200

    drm/msm/dsi/phy_7nm: Fix missing initial VCO rate
    
    [ Upstream commit 5ddcb0cb9d10e6e70a68e0cb8f0b8e3a7eb8ccaf ]
    
    Driver unconditionally saves current state on first init in
    dsi_pll_7nm_init(), but does not save the VCO rate, only some of the
    divider registers.  The state is then restored during probe/enable via
    msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() ->
    dsi_7nm_pll_restore_state().
    
    Restoring calls dsi_pll_7nm_vco_set_rate() with
    pll_7nm->vco_current_rate=0, which basically overwrites existing rate of
    VCO and messes with clock hierarchy, by setting frequency to 0 to clock
    tree.  This makes anyway little sense - VCO rate was not saved, so
    should not be restored.
    
    If PLL was not configured configure it to minimum rate to avoid glitches
    and configuring entire in clock hierarchy to 0 Hz.
    
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/657827/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Clark <[email protected]>
Date:   Mon Sep 8 12:30:07 2025 -0700

    drm/msm/registers: Generate _HI/LO builders for reg64
    
    [ Upstream commit 60e9f776b7932d67c88e8475df7830cb9cdf3154 ]
    
    The upstream mesa copy of the GPU regs has shifted more things to reg64
    instead of seperate 32b HI/LO reg32's.  This works better with the "new-
    style" c++ builders that mesa has been migrating to for a6xx+ (to better
    handle register shuffling between gens), but it leaves the C builders
    with missing _HI/LO builders.
    
    So handle the special case of reg64, automatically generating the
    missing _HI/LO builders.
    
    Signed-off-by: Rob Clark <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/673559/
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Clark <[email protected]>
Date:   Wed Oct 22 15:20:38 2025 -0700

    drm/msm: Ensure vm is created in VM_BIND ioctl
    
    [ Upstream commit 00d5f09719aa6c37545be5c05d25a1eaf8f3da7e ]
    
    Since the vm is lazily created, to allow userspace to opt-in to a
    VM_BIND context, we can't assume it is already created.
    
    Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
    Signed-off-by: Rob Clark <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/682939/
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Clark <[email protected]>
Date:   Wed Aug 20 17:04:27 2025 -0700

    drm/msm: Fix 32b size truncation
    
    [ Upstream commit 6d6a29a19b232e29b61a14d58b71fefc2e003fa4 ]
    
    Somehow we never noticed this when arm64 became a thing, many years ago.
    
    v2: also fix npages
    
    Signed-off-by: Rob Clark <[email protected]>
    Tested-by: Connor Abbott <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/669785/
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Clark <[email protected]>
Date:   Tue Sep 23 07:04:40 2025 -0700

    drm/msm: Fix GEM free for imported dma-bufs
    
    [ Upstream commit c34e08ba6c0037a72a7433741225b020c989e4ae ]
    
    Imported dma-bufs also have obj->resv != &obj->_resv.  So we should
    check both this condition in addition to flags for handling the
    _NO_SHARE case.
    
    Fixes this splat that was reported with IRIS video playback:
    
        ------------[ cut here ]------------
        WARNING: CPU: 3 PID: 2040 at drivers/gpu/drm/msm/msm_gem.c:1127 msm_gem_free_object+0x1f8/0x264 [msm]
        CPU: 3 UID: 1000 PID: 2040 Comm: .gnome-shell-wr Not tainted 6.17.0-rc7 #1 PREEMPT
        pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
        pc : msm_gem_free_object+0x1f8/0x264 [msm]
        lr : msm_gem_free_object+0x138/0x264 [msm]
        sp : ffff800092a1bb30
        x29: ffff800092a1bb80 x28: ffff800092a1bce8 x27: ffffbc702dbdbe08
        x26: 0000000000000008 x25: 0000000000000009 x24: 00000000000000a6
        x23: ffff00083c72f850 x22: ffff00083c72f868 x21: ffff00087e69f200
        x20: ffff00087e69f330 x19: ffff00084d157ae0 x18: 0000000000000000
        x17: 0000000000000000 x16: ffffbc704bd46b80 x15: 0000ffffd0959540
        x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
        x11: ffffbc702e6cdb48 x10: 0000000000000000 x9 : 000000000000003f
        x8 : ffff800092a1ba90 x7 : 0000000000000000 x6 : 0000000000000020
        x5 : ffffbc704bd46c40 x4 : fffffdffe102cf60 x3 : 0000000000400032
        x2 : 0000000000020000 x1 : ffff00087e6978e8 x0 : ffff00087e6977e8
        Call trace:
         msm_gem_free_object+0x1f8/0x264 [msm] (P)
         drm_gem_object_free+0x1c/0x30 [drm]
         drm_gem_object_handle_put_unlocked+0x138/0x150 [drm]
         drm_gem_object_release_handle+0x5c/0xcc [drm]
         drm_gem_handle_delete+0x68/0xbc [drm]
         drm_gem_close_ioctl+0x34/0x40 [drm]
         drm_ioctl_kernel+0xc0/0x130 [drm]
         drm_ioctl+0x360/0x4e0 [drm]
         __arm64_sys_ioctl+0xac/0x104
         invoke_syscall+0x48/0x104
         el0_svc_common.constprop.0+0x40/0xe0
         do_el0_svc+0x1c/0x28
         el0_svc+0x34/0xec
         el0t_64_sync_handler+0xa0/0xe4
         el0t_64_sync+0x198/0x19c
        ---[ end trace 0000000000000000 ]---
        ------------[ cut here ]------------
    
    Reported-by: Stephan Gerhold <[email protected]>
    Fixes: de651b6e040b ("drm/msm: Fix refcnt underflow in error path")
    Signed-off-by: Rob Clark <[email protected]>
    Tested-by: Stephan Gerhold <[email protected]>
    Tested-by: Luca Weiss <[email protected]>
    Tested-by: Bryan O'Donoghue <[email protected]> # qrb5165-rb5
    Patchwork: https://patchwork.freedesktop.org/patch/676273/
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Anna Maniscalco <[email protected]>
Date:   Sat Oct 11 15:45:10 2025 +0200

    drm/msm: make sure last_fence is always updated
    
    [ Upstream commit 86404a9e3013d814a772ac407573be5d3cd4ee0d ]
    
    Update last_fence in the vm-bind path instead of kernel managed path.
    
    last_fence is used to wait for work to finish in vm_bind contexts but not
    used for kernel managed contexts.
    
    This fixes a bug where last_fence is not waited on context close leading
    to faults as resources are freed while in use.
    
    Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue")
    Signed-off-by: Anna Maniscalco <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/680080/
    Message-ID: <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Antonino Maniscalco <[email protected]>
Date:   Thu Aug 21 15:06:34 2025 +0200

    drm/msm: make sure to not queue up recovery more than once
    
    [ Upstream commit 10fb1b2fcaee5545a5e54db1ed4d7b15c2db50c8 ]
    
    If two fault IRQs arrive in short succession recovery work will be
    queued up twice.
    
    When recovery runs a second time it may end up killing an unrelated
    context.
    
    Prevent this by masking off interrupts when triggering recovery.
    
    Signed-off-by: Antonino Maniscalco <[email protected]>
    Reviewed-by: Akhil P Oommen <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/670023/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Herring (Arm) <[email protected]>
Date:   Thu Jul 3 13:34:41 2025 -0500

    drm/msm: Use of_reserved_mem_region_to_resource() for "memory-region"
    
    [ Upstream commit fb53e8f09fc1e1a343fd08ea4f353f81613975d7 ]
    
    Use the newly added of_reserved_mem_region_to_resource() function to
    handle "memory-region" properties.
    
    The original code did not set 'zap_available' to false if
    of_address_to_resource() failed which seems like an oversight.
    
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/662275/
    Link: https://lore.kernel.org/r/[email protected]
    [DB: dropped part related to VRAM, no longer applicable]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: James Jones <[email protected]>
Date:   Thu Oct 30 11:11:53 2025 -0700

    drm/nouveau: Advertise correct modifiers on GB20x
    
    commit 664ce10246ba00746af94a08b7fbda8ccaacd930 upstream.
    
    8 and 16 bit formats use a different layout on
    GB20x than they did on prior chips. Add the
    corresponding DRM format modifiers to the list of
    modifiers supported by the display engine on such
    chips, and filter the supported modifiers for each
    format based on its bytes per pixel in
    nv50_plane_format_mod_supported().
    
    Note this logic will need to be updated when GB10
    support is added, since it is a GB20x chip that
    uses the pre-GB20x sector layout for all formats.
    
    Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x")
    Signed-off-by: James Jones <[email protected]>
    Reviewed-by: Faith Ekstrand <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Timur Tabi <[email protected]>
Date:   Fri Aug 8 14:13:40 2025 -0500

    drm/nouveau: always set RMDevidCheckIgnore for GSP-RM
    
    [ Upstream commit 27738c3003bf3b124527c9ed75e1e0d0c013c101 ]
    
    Always set the RMDevidCheckIgnore registry key for GSP-RM so that it
    will continue support newer variants of already supported GPUs.
    
    GSP-RM maintains an internal list of PCI IDs of GPUs that it supports,
    and checks if the current GPU is on this list.  While the actual GPU
    architecture (as specified in the BOOT_0/BOOT_42 registers) determines
    how to enable the GPU, the PCI ID is used for the product name, e.g.
    "NVIDIA GeForce RTX 5090".
    
    Unfortunately, if there is no match, GSP-RM will refuse to initialize,
    even if the device is fully supported.  Nouveau will get an error
    return code, but by then it's too late.  This behavior may be corrected
    in a future version of GSP-RM, but that does not help Nouveau today.
    
    Fortunately, GSP-RM supports an undocumented registry key that tells it
    to ignore the mismatch.  In such cases, the product name returned will
    be a blank string, but otherwise GSP-RM will continue.
    
    Unlike Nvidia's proprietary driver, Nouveau cannot update to newer
    firmware versions to keep up with every new hardware release.  Instead,
    we can permanently set this registry key, and GSP-RM will continue
    to function the same with known hardware.
    
    Signed-off-by: Timur Tabi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Philipp Stanner <[email protected]>
Date:   Fri Oct 24 18:12:22 2025 +0200

    drm/nouveau: Fix race in nouveau_sched_fini()
    
    commit e0023c8a74028739643aa14bd201c41a99866ca4 upstream.
    
    nouveau_sched_fini() uses a memory barrier before wait_event().
    wait_event(), however, is a macro which expands to a loop which might
    check the passed condition several times. The barrier would only take
    effect for the first check.
    
    Replace the barrier with a function which takes the spinlock.
    
    Cc: [email protected] # v6.8+
    Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship")
    Acked-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Seyediman Seyedarab <[email protected]>
Date:   Thu Jul 24 15:59:13 2025 -0400

    drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf()
    
    [ Upstream commit 6510b62fe9303aaf48ff136ff69186bcfc32172d ]
    
    snprintf() returns the number of characters that *would* have been
    written, which can overestimate how much you actually wrote to the
    buffer in case of truncation. That leads to 'data += this' advancing
    the pointer past the end of the buffer and size going negative.
    
    Switching to scnprintf() prevents potential buffer overflows and ensures
    consistent behavior when building the output string.
    
    Signed-off-by: Seyediman Seyedarab <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christopher Orr <[email protected]>
Date:   Tue Aug 5 21:27:55 2025 -0400

    drm/panel-edp: Add SHP LQ134Z1 panel for Dell XPS 9345
    
    [ Upstream commit 754dbf164acd4d22dd7a5241b1880f54546d68f2 ]
    
    Introduce high-res OLED panel for the Dell XPS 9345
    
    These timings were selected based on Alex Vinarkskis' commit,
    (6b3815c6815f07acc7eeffa8ae734d1a1c0ee817) for the LQ134N1
    and seem to work fine for the high-res OLED panel on the 9345.
    
    The raw edid for this SHP panel is:
    
    00 ff ff ff ff ff ff 00 4d 10 8f 15 00 00 00 00
    2e 21 01 04 b5 1d 12 78 03 0f 95 ae 52 43 b0 26
    0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
    01 01 01 01 01 01 fd d7 00 a0 a0 40 fc 66 30 20
    36 00 20 b4 10 00 00 18 00 00 00 fd 00 1e 78 cc
    cc 38 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43
    37 31 4d 31 81 4c 51 31 33 34 5a 31 00 00 00 00
    00 02 41 0c 32 01 01 00 00 0b 41 0a 20 20 01 ea
    
    70 20 79 02 00 20 00 13 8c 52 19 8f 15 00 00 00
    00 2e 17 07 4c 51 31 33 34 5a 31 21 00 1d 40 0b
    08 07 00 0a 40 06 88 e1 fa 51 3d a4 b0 66 62 0f
    02 45 54 d0 5f d0 5f 00 34 13 78 26 00 09 06 00
    00 00 00 00 41 00 00 22 00 14 d9 6f 08 05 ff 09
    9f 00 2f 00 1f 00 3f 06 5d 00 02 00 05 00 25 01
    09 d9 6f 08 d9 6f 08 1e 78 80 81 00 0b e3 05 80
    00 e6 06 05 01 6a 6a 39 00 00 00 00 00 00 58 90
    
    Signed-off-by: Christopher Orr <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/aJKvm3SlhLGHW4qn@jander
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Stuebner <[email protected]>
Date:   Mon Jul 7 18:48:55 2025 +0200

    drm/panel: ilitek-ili9881c: move display_on/_off dcs calls to (un-)prepare
    
    [ Upstream commit 5efa82492066fcb32308210fb3f0b752af74334f ]
    
    At least for panel-bridges, the atomic_enable call is defined as being
    called right after the preceding element in the display pipe is enabled.
    
    It is also stated that "The bridge can assume that the display pipe (i.e.
    clocks and timing signals) feeding it is running when this callback is
    called"
    
    This means the DSI controller driving this display would have already
    switched over to video-mode from command mode and thus dcs functions
    should not be called anymore at this point.
    
    This caused a non-working display for me, when trying to enable
    the rk3576 dsi controller using a display using this controller.
    
    Therefore move the display_on/off calls the more appropriate
    prepare/unprepare callbacks.
    
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Stuebner <[email protected]>
Date:   Mon Jul 7 18:48:54 2025 +0200

    drm/panel: ilitek-ili9881c: turn off power-supply when init fails
    
    [ Upstream commit 6c66eba502709a78281333187c1add7b71f7201f ]
    
    The prepare function turns on the power-supply regulator first, when
    preparing the display. But in an error case, just returns the error
    code, but does not power off the regulator again, fix that.
    
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chia-I Wu <[email protected]>
Date:   Thu Aug 28 13:01:16 2025 -0700

    drm/panthor: check bo offset alignment in vm bind
    
    [ Upstream commit 5afa9d2a9bb1410f816e0123846047288b16e4b9 ]
    
    Fail early from panthor_vm_bind_prepare_op_ctx instead of late from
    ops->map_pages.
    
    Signed-off-by: Chia-I Wu <[email protected]>
    Reviewed-by: Boris Brezillon <[email protected]>
    Reviewed-by: Liviu Dudau <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Signed-off-by: Steven Price <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Karunika Choo <[email protected]>
Date:   Thu Aug 7 17:26:31 2025 +0100

    drm/panthor: Serialize GPU cache flush operations
    
    [ Upstream commit e322a4844811b54477b7072eb40dc9e402a1725d ]
    
    In certain scenarios, it is possible for multiple cache flushes to be
    requested before the previous one completes. This patch introduces the
    cache_flush_lock mutex to serialize these operations and ensure that
    any requested cache flushes are completed instead of dropped.
    
    Reviewed-by: Liviu Dudau <[email protected]>
    Co-developed-by: Dennis Tsiang <[email protected]>
    Signed-off-by: Dennis Tsiang <[email protected]>
    Signed-off-by: Karunika Choo <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Signed-off-by: Steven Price <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Palmer <[email protected]>
Date:   Sat Oct 18 14:44:50 2025 +0900

    drm/radeon: Do not kfree() devres managed rdev
    
    [ Upstream commit 3328443363a0895fd9c096edfe8ecd372ca9145e ]
    
    Since the allocation of the drivers main structure was changed to
    devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling
    kfree() on it.
    
    This fixes things exploding if the driver probe fails and devres cleans up
    the rdev after we already free'd it.
    
    Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc")
    Signed-off-by: Daniel Palmer <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Palmer <[email protected]>
Date:   Sat Oct 18 14:44:51 2025 +0900

    drm/radeon: Remove calls to drm_put_dev()
    
    [ Upstream commit 745bae76acdd71709773c129a69deca01036250b ]
    
    Since the allocation of the drivers main structure was changed to
    devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd
    should be done by devres.
    
    However, drm_put_dev() is still in the probe error and device remove
    paths. When the driver fails to probe warnings like the following are
    shown because devres is trying to drm_put_dev() after the driver
    already did it.
    
    [    5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22
    [    5.649605] ------------[ cut here ]------------
    [    5.649607] refcount_t: underflow; use-after-free.
    [    5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110
    
    Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc")
    Signed-off-by: Daniel Palmer <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Rosca <[email protected]>
Date:   Wed Oct 15 16:01:28 2025 +0200

    drm/sched: avoid killing parent entity on child SIGKILL
    
    commit 9e8b3201c7302d5b522ba3535630bed21cc03c27 upstream.
    
    The DRM scheduler tracks who last uses an entity and when that process
    is killed blocks all further submissions to that entity.
    
    The problem is that we didn't track who initially created an entity, so
    when a process accidently leaked its file descriptor to a child and
    that child got killed, we killed the parent's entities.
    
    Avoid that and instead initialize the entities last user on entity
    creation. This also allows to drop the extra NULL check.
    
    Signed-off-by: David Rosca <[email protected]>
    Signed-off-by: Christian König <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4568
    Reviewed-by: Alex Deucher <[email protected]>
    CC: [email protected]
    Acked-by: Philipp Stanner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Pierre-Eric Pelloux-Prayer <[email protected]>
Date:   Tue Nov 4 10:53:57 2025 +0100

    drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
    
    commit 487df8b698345dd5a91346335f05170ed5f29d4e upstream.
    
    The Mesa issue referenced below pointed out a possible deadlock:
    
    [ 1231.611031]  Possible interrupt unsafe locking scenario:
    
    [ 1231.611033]        CPU0                    CPU1
    [ 1231.611034]        ----                    ----
    [ 1231.611035]   lock(&xa->xa_lock#17);
    [ 1231.611038]                                local_irq_disable();
    [ 1231.611039]                                lock(&fence->lock);
    [ 1231.611041]                                lock(&xa->xa_lock#17);
    [ 1231.611044]   <Interrupt>
    [ 1231.611045]     lock(&fence->lock);
    [ 1231.611047]
                    *** DEADLOCK ***
    
    In this example, CPU0 would be any function accessing job->dependencies
    through the xa_* functions that don't disable interrupts (eg:
    drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
    
    CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling
    callback so in an interrupt context. It will deadlock when trying to
    grab the xa_lock which is already held by CPU0.
    
    Replacing all xa_* usage by their xa_*_irq counterparts would fix
    this issue, but Christian pointed out another issue: dma_fence_signal
    takes fence.lock and so does dma_fence_add_callback.
    
      dma_fence_signal() // locks f1.lock
      -> drm_sched_entity_kill_jobs_cb()
      -> foreach dependencies
         -> dma_fence_add_callback() // locks f2.lock
    
    This will deadlock if f1 and f2 share the same spinlock.
    
    To fix both issues, the code iterating on dependencies and re-arming them
    is moved out to drm_sched_entity_kill_jobs_work().
    
    Cc: [email protected] # v6.2+
    Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
    Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908
    Reported-by: Mikhail Gavrilov <[email protected]>
    Suggested-by: Christian König <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]>
    [phasta: commit message nits]
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Philipp Stanner <[email protected]>
Date:   Wed Oct 22 08:34:03 2025 +0200

    drm/sched: Fix race in drm_sched_entity_select_rq()
    
    commit d25e3a610bae03bffc5c14b5d944a5d0cd844678 upstream.
    
    In a past bug fix it was forgotten that entity access must be protected
    by the entity lock. That's a data race and potentially UB.
    
    Move the spin_unlock() to the appropriate position.
    
    Cc: [email protected] # v5.13+
    Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3")
    Reviewed-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Thomas Zimmermann <[email protected]>
Date:   Fri Jun 27 17:23:09 2025 +0200

    drm/sharp-memory: Do not access GEM-DMA vaddr directly
    
    [ Upstream commit 136c374d8c80378d2982a46b2adabfc007299641 ]
    
    Use DRM's shadow-plane helper to map and access the GEM object's buffer
    within kernel address space. Encapsulates the vmap logic in the GEM-DMA
    helpers.
    
    The sharp-memory driver currently reads the vaddr field from the GME
    buffer object directly. This only works because GEM code 'automagically'
    sets vaddr.
    
    Shadow-plane helpers perform the same steps, but with correct abstraction
    behind drm_gem_vmap(). The shadow-plane state provides the buffer address
    in kernel address space and the format-conversion state.
    
    v2:
    - fix typo in commit description
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Marcus Folkesson <[email protected]>
Date:   Mon Jul 21 12:43:34 2025 +0200

    drm/st7571-i2c: add support for inverted pixel format
    
    [ Upstream commit e61c35157d32b4b422f0a4cbc3c40d04d883a9c9 ]
    
    Depending on which display that is connected to the controller, an
    "1" means either a black or a white pixel.
    
    The supported formats (R1/R2/XRGB8888) expects the pixels
    to map against (4bit):
        00 => Black
        01 => Dark Gray
        10 => Light Gray
        11 => White
    
    If this is not what the display map against, make it possible to invert
    the pixels.
    
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Marcus Folkesson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Zimmermann <[email protected]>
Date:   Fri Oct 17 11:13:36 2025 +0200

    drm/sysfb: Do not dereference NULL pointer in plane reset
    
    commit 14e02ed3876f4ab0ed6d3f41972175f8b8df3d70 upstream.
    
    The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not
    deref that pointer, but forward NULL to the other plane-reset helpers.
    Clears plane->state to NULL.
    
    v2:
    - fix typo in commit description (Javier)
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: b71565022031 ("drm/gem: Export implementation of shadow-plane helpers")
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/dri-devel/[email protected]/
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Melissa Wen <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    Cc: Maxime Ripard <[email protected]>
    Cc: David Airlie <[email protected]>
    Cc: Simona Vetter <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v5.15+
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Tomi Valkeinen <[email protected]>
Date:   Wed Apr 16 14:06:30 2025 +0300

    drm/tidss: Remove early fb
    
    [ Upstream commit 942e54a372b44da3ffb0191b4d289d476256c861 ]
    
    Add a call to drm_aperture_remove_framebuffers() to drop the possible
    early fb (simplefb).
    
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jayesh Choudhary <[email protected]>
Date:   Tue Jun 24 13:34:02 2025 +0530

    drm/tidss: Set crtc modesetting parameters with adjusted mode
    
    [ Upstream commit cfb29225db20c56432a8525366321c0c09edfb2e ]
    
    TIDSS uses crtc_* fields to propagate its registers and set the
    clock rates. So set the CRTC modesetting timing parameters with
    the adjusted mode when needed, to set correct values.
    
    Cc: Tomi Valkeinen <[email protected]>
    Signed-off-by: Jayesh Choudhary <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomi Valkeinen <[email protected]>
Date:   Wed Jul 23 13:05:09 2025 +0300

    drm/tidss: Use the crtc_* timings when programming the HW
    
    [ Upstream commit 478306edc23eec4f0ec24a46222485910c66212d ]
    
    Use the crtc_* fields from drm_display_mode, instead of the "logical"
    fields. This shouldn't change anything in practice, but afaiu the crtc_*
    fields are the correct ones to use here.
    
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Tested-by: Parth Pancholi <[email protected]>
    Tested-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michal Wajdeczko <[email protected]>
Date:   Tue Jul 22 16:10:55 2025 +0200

    drm/xe/configfs: Enforce canonical device names
    
    [ Upstream commit 400a6da1e967c4f117e4757412df06dcfaea0e6a ]
    
    While we expect config directory names to match PCI device name,
    currently we are only scanning provided names for domain, bus,
    device and function numbers, without checking their format.
    This would pass slightly broken entries like:
    
      /sys/kernel/config/xe/
      ├── 0000:00:02.0000000000000
      │   └── ...
      ├── 0000:00:02.0x
      │   └── ...
      ├──  0: 0: 2. 0
      │   └── ...
      └── 0:0:2.0
          └── ...
    
    To avoid such mistakes, check if the name provided exactly matches
    the canonical PCI device address format, which we recreated from
    the parsed BDF data. Also simplify scanf format as it can't really
    catch all formatting errors.
    
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Satyanarayana K V P <[email protected]>
Date:   Mon Sep 1 12:55:41 2025 +0530

    drm/xe/guc: Add devm release action to safely tear down CT
    
    [ Upstream commit ee4b32220a6b41e71512e8804585325e685456ba ]
    
    When a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATE
    flag, the driver initiates TLB invalidation requests via the CTB mechanism
    while releasing the BO. However a premature release of the CTB BO can lead
    to system crashes, as observed in:
    
    Oops: Oops: 0000 [#1] SMP NOPTI
    RIP: 0010:h2g_write+0x2f3/0x7c0 [xe]
    Call Trace:
     guc_ct_send_locked+0x8b/0x670 [xe]
     xe_guc_ct_send_locked+0x19/0x60 [xe]
     send_tlb_invalidation+0xb4/0x460 [xe]
     xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe]
     ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe]
     ggtt_node_remove+0x110/0x140 [xe]
     xe_ggtt_node_remove+0x40/0xa0 [xe]
     xe_ggtt_remove_bo+0x87/0x250 [xe]
    
    Introduce a devm-managed release action during xe_guc_ct_init() and
    xe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement before
    resource deallocation, preventing the use-after-free scenario.
    
    Signed-off-by: Satyanarayana K V P <[email protected]>
    Cc: Michal Wajdeczko <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Cc: Summers Stuart <[email protected]>
    Reviewed-by: Michal Wajdeczko <[email protected]>
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Harrison <[email protected]>
Date:   Fri Jul 25 19:43:37 2025 -0700

    drm/xe/guc: Add more GuC load error status codes
    
    [ Upstream commit 45fbb51050e72723c2bdcedc1ce32305256c70ed ]
    
    The GuC load process will abort if certain status codes (which are
    indicative of a fatal error) are reported. Otherwise, it keeps waiting
    until the 'success' code is returned. New error codes have been added
    in recent GuC releases, so add support for aborting on those as well.
    
    v2: Shuffle HWCONFIG_START to the front of the switch to keep the
    ordering as per the enum define for clarity (review feedback by
    Jonathan). Also add a description for the basic 'invalid init data'
    code which was missing.
    
    Signed-off-by: John Harrison <[email protected]>
    Reviewed-by: Stuart Summers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michal Wajdeczko <[email protected]>
Date:   Mon Sep 8 12:20:51 2025 +0200

    drm/xe/guc: Always add CT disable action during second init step
    
    [ Upstream commit 955f3bc4af440bb950c7a1567197aaf6aa2213ae ]
    
    On DGFX, during init_post_hwconfig() step, we are reinitializing
    CTB BO in VRAM and we have to replace cleanup action to disable CT
    communication prior to release of underlying BO.
    
    But that introduces some discrepancy between DGFX and iGFX, as for
    iGFX we keep previously added disable CT action that would be called
    during unwind much later.
    
    To keep the same flow on both types of platforms, always replace old
    cleanup action and register new one.
    
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Cc: Satyanarayana K V P <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Satyanarayana K V P <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhanjun Dong <[email protected]>
Date:   Fri Aug 29 12:04:27 2025 -0400

    drm/xe/guc: Increase GuC crash dump buffer size
    
    [ Upstream commit ad83b1da5b786ee2d245e41ce55cb1c71fed7c22 ]
    
    There are platforms already have a maximum dump size of 12KB, to avoid
    data truncating, increase GuC crash dump buffer size to 16KB.
    
    Signed-off-by: Zhanjun Dong <[email protected]>
    Reviewed-by: Stuart Summers <[email protected]>
    Signed-off-by: John Harrison <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Harrison <[email protected]>
Date:   Tue Sep 9 15:41:31 2025 -0700

    drm/xe/guc: Return an error code if the GuC load fails
    
    [ Upstream commit 3b09b11805bfee32d5a0000f5ede42c07237a6c4 ]
    
    Due to multiple explosion issues in the early days of the Xe driver,
    the GuC load was hacked to never return a failure. That prevented
    kernel panics and such initially, but now all it achieves is creating
    more confusing errors when the driver tries to submit commands to a
    GuC it already knows is not there. So fix that up.
    
    As a stop-gap and to help with debug of load failures due to invalid
    GuC init params, a wedge call had been added to the inner GuC load
    function. The reason being that it leaves the GuC log accessible via
    debugfs. However, for an end user, simply aborting the module load is
    much cleaner than wedging and trying to continue. The wedge blocks
    user submissions but it seems that various bits of the driver itself
    still try to submit to a dead GuC and lots of subsequent errors occur.
    And with regards to developers debugging why their particular code
    change is being rejected by the GuC, it is trivial to either add the
    wedge back in and hack the return code to zero again or to just do a
    GuC log dump to dmesg.
    
    v2: Add support for error injection testing and drop the now redundant
    wedge call.
    
    CC: Rodrigo Vivi <[email protected]>
    Signed-off-by: John Harrison <[email protected]>
    Reviewed-by: Matt Atwood <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michal Wajdeczko <[email protected]>
Date:   Thu Sep 4 00:33:30 2025 +0200

    drm/xe/guc: Set upper limit of H2G retries over CTB
    
    [ Upstream commit 2506af5f8109a387a5e8e9e3d7c498480b8033db ]
    
    The GuC communication protocol allows GuC to send NO_RESPONSE_RETRY
    reply message to indicate that due to some interim condition it can
    not handle incoming H2G request and the host shall resend it.
    
    But in some cases, due to errors, this unsatisfied condition might
    be final and this could lead to endless retries as it was recently
    seen on the CI:
    
     [drm] GT0: PF: VF1 FLR didn't finish in 5000 ms (-ETIMEDOUT)
     [drm] GT0: PF: VF1 resource sanitizing failed (-ETIMEDOUT)
     [drm] GT0: PF: VF1 FLR failed!
     [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0
     [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0
     [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0
     [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0
    
    To avoid such dangerous loops allow only limited number of retries
    (for now 50) and add some delays (n * 5ms) to slow down the rate of
    resending this repeated request.
    
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Cc: John Harrison <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Stuart Summers <[email protected]>
    Reviewed-by: Julia Filipchuk <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Raag Jadav <[email protected]>
Date:   Mon Sep 8 11:23:20 2025 +0530

    drm/xe/i2c: Enable bus mastering
    
    [ Upstream commit fce99326c9cf5a0e57c4283a61c6b622ef5b0de8 ]
    
    Enable bus mastering for I2C controller to support device initiated
    in-band transactions.
    
    Signed-off-by: Raag Jadav <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stuart Summers <[email protected]>
Date:   Tue Aug 19 20:10:54 2025 +0000

    drm/xe/pcode: Initialize data0 for pcode read routine
    
    [ Upstream commit 2515d2b9ab4108c11a0b23935e68de27abb8b2a7 ]
    
    There are two registers filled in when reading data from
    pcode besides the mailbox itself. Currently, we allow a NULL
    value for the second of these two (data1) and assume the first
    is defined. However, many of the routines that are calling
    this function assume that pcode will ignore the value being
    passed in and so leave that first value (data0) defined but
    uninitialized. To be safe, make sure this value is always
    initialized to something (0 generally) in the event pcode
    behavior changes and starts using this value.
    
    v2: Fix sob/author
    
    Signed-off-by: Stuart Summers <[email protected]>
    Reviewed-by: Jonathan Cavitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michal Wajdeczko <[email protected]>
Date:   Fri Aug 1 16:28:22 2025 +0200

    drm/xe/pf: Don't resume device from restart worker
    
    [ Upstream commit 9fd9f221440024b7451678898facfb34af054310 ]
    
    The PF's restart worker shouldn't attempt to resume the device on
    its own, since its goal is to finish PF and VFs reprovisioning on
    the recently reset GuC. Take extra RPM reference while scheduling
    a work and release it from the worker or when we cancel a work.
    
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Reviewed-by: Piotr Piórkowski <[email protected]>
    Reviewed-by: Jonathan Cavitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Piotr Piórkowski <[email protected]>
Date:   Tue Aug 5 11:18:50 2025 +0200

    drm/xe/pf: Program LMTT directory pointer on all GTs within a tile
    
    [ Upstream commit ad69d62588cd6bf8cddaff5e3e2eb1b8dd876d35 ]
    
    Previously, the LMTT directory pointer was only programmed for primary GT
    within a tile. However, to ensure correct Local Memory access by VFs,
    the LMTT configuration must be programmed on all GTs within the tile.
    Lets program the LMTT directory pointer on every GT of the tile
    to guarantee proper LMEM access across all GTs on VFs.
    
    HSD: 18042797646
    Bspec: 67468
    Signed-off-by: Piotr Piórkowski <[email protected]>
    Cc: Michal Wajdeczko <[email protected]>
    Cc: Michał Winiarski <[email protected]>
    Reviewed-by: Stuart Summers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michał Winiarski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sk Anirban <[email protected]>
Date:   Wed Jul 16 15:46:23 2025 +0530

    drm/xe/ptl: Apply Wa_16026007364
    
    [ Upstream commit d72779c29d82c6e371cea8b427550bd6923c2577 ]
    
    As part of this WA GuC will save and restore value of two XE3_Media
    control registers that were not included in the HW power context.
    
    Signed-off-by: Sk Anirban <[email protected]>
    Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chaitanya Kumar Borah <[email protected]>
Date:   Fri Aug 22 05:55:12 2025 +0530

    drm/xe/wcl: Extend L3bank mask workaround
    
    [ Upstream commit d738e1be2b2b4364403babc43ae7343d45e99d41 ]
    
    The commit 9ab440a9d042 ("drm/xe/ptl: L3bank mask is not
    available on the media GT") added a workaround to ignore
    the fuse register that L3 bank availability as it did not
    contain valid values. Same is true for WCL therefore extend
    the workaround to cover it.
    
    Signed-off-by: Chaitanya Kumar Borah <[email protected]>
    Reviewed-by: Dnyaneshwar Bhadane <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gustavo Sousa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stuart Summers <[email protected]>
Date:   Tue Aug 26 18:29:04 2025 +0000

    drm/xe: Cancel pending TLB inval workers on teardown
    
    [ Upstream commit 76186a253a4b9eb41c5a83224c14efdf30960a71 ]
    
    Add a new _fini() routine on the GT TLB invalidation
    side to handle this worker cleanup on driver teardown.
    
    v2: Move the TLB teardown to the gt fini() routine called during
        gt_init rather than in gt_alloc. This way the GT structure stays
        alive for while we reset the TLB state.
    
    Signed-off-by: Stuart Summers <[email protected]>
    Reviewed-by: Matthew Brost <[email protected]>
    Signed-off-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Brost <[email protected]>
Date:   Tue Oct 21 17:55:37 2025 -0700

    drm/xe: Do not wake device during a GT reset
    
    commit b3fbda1a630a9439c885b2a5dc5230cc49a87e9e upstream.
    
    Waking the device during a GT reset can lead to unintended memory
    allocation, which is not allowed since GT resets occur in the reclaim
    path. Prevent this by holding a PM reference while a reset is in flight.
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Cc: [email protected]
    Signed-off-by: Matthew Brost <[email protected]>
    Reviewed-by: Matthew Auld <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 480b358e7d8ef69fd8f1b0cad6e07c7d70a36ee4)
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Xin Wang <[email protected]>
Date:   Tue Aug 26 17:06:33 2025 -0700

    drm/xe: Ensure GT is in C0 during resumes
    
    [ Upstream commit 95d0883ac8105717f59c2dcdc0d8b9150f13aa12 ]
    
    This patch ensures the gt will be awake for the entire duration
    of the resume sequences until GuCRC takes over and GT-C6 gets
    re-enabled.
    
    Before suspending GT-C6 is kept enabled, but upon resume, GuCRC
    is not yet alive to properly control the exits and some cases of
    instability and corruption related to GT-C6 can be observed.
    
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4037
    
    Suggested-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Xin Wang <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4037
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tangudu Tilak Tirumalesh <[email protected]>
Date:   Thu Jul 31 22:01:44 2025 +0000

    drm/xe: Extend wa_13012615864 to additional Xe2 and Xe3 platforms
    
    [ Upstream commit bcddb12c027434fdf0491c1a05a3fe4fd2263d71 ]
    
    Extend WA 13012615864 to Graphics Versions 20.01,20.02,20.04
    and 30.03.
    
    Signed-off-by: Tangudu Tilak Tirumalesh <[email protected]>
    Signed-off-by: Jonathan Cavitt <[email protected]>
    Cc: Matt Roper <[email protected]>
    Cc: Michal Wajdeczko <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Reviewed-by: Gustavo Sousa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tangudu Tilak Tirumalesh <[email protected]>
Date:   Wed Aug 27 12:57:55 2025 -0700

    drm/xe: Extend Wa_22021007897 to Xe3 platforms
    
    [ Upstream commit 8d6f16f1f082881aa50ea7ae537b604dec647ed6 ]
    
    WA 22021007897 should also be applied to Graphics Versions 30.00, 30.01
    and 30.03. To make it simple, simply use the range [3000, 3003] that
    should be ok as there isn't a 3002 and if it's added, the WA list would
    need to be revisited anyway.
    
    Cc: Matt Atwood <[email protected]>
    Cc: Gustavo Sousa <[email protected]>
    Signed-off-by: Tangudu Tilak Tirumalesh <[email protected]>
    Reviewed-by: Matt Atwood <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Maarten Lankhorst <[email protected]>
Date:   Tue Jul 15 17:20:58 2025 +0200

    drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.
    
    [ Upstream commit 1cda3c755bb7770be07d75949bb0f45fb88651f6 ]
    
    I saw an oops in xe_gem_fault when running the xe-fast-feedback
    testlist against the realtime kernel without debug options enabled.
    
    The panic happens after core_hotunplug unbind-rebind finishes.
    Presumably what happens is that a process mmaps, unlocks because
    of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left,
    causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, since
    there was nothing left to populate, and then oopses in
    "mem_type_is_vram(tbo->resource->mem_type)" because tbo->resource
    is NULL.
    
    It's convoluted, but fits the data and explains the oops after
    the test exits.
    
    Reviewed-by: Matthew Auld <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Auld <[email protected]>
Date:   Fri Aug 29 17:47:16 2025 +0100

    drm/xe: improve dma-resv handling for backup object
    
    [ Upstream commit edb1745fc618ba8ef63a45ce3ae60de1bdf29231 ]
    
    Since the dma-resv is shared we don't need to reserve and add a fence
    slot fence twice, plus no need to loop through the dependencies.
    
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Jonathan Cavitt <[email protected]>
    Reviewed-by: Thomas Hellström <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Simon Richter <[email protected]>
Date:   Mon Aug 18 15:47:35 2025 +0900

    drm/xe: Make page size consistent in loop
    
    [ Upstream commit b85bb2d677153d990924d31be9416166d22382eb ]
    
    If PAGE_SIZE != XE_PAGE_SIZE (which is currently locked behind
    CONFIG_BROKEN), this would generate the wrong number of PDEs.
    
    Since these PDEs are consumed by the GPU, the GPU page size needs to be
    used.
    
    Signed-off-by: Simon Richter <[email protected]>
    Reviewed-by: Matthew Brost <[email protected]>
    Signed-off-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Auld <[email protected]>
Date:   Fri Aug 8 11:34:56 2025 +0100

    drm/xe: rework PDE PAT index selection
    
    [ Upstream commit 17593a69b75f098280ad88b625f2d8c5bfe4c6a1 ]
    
    For non-leaf paging structures we end up selecting a random index
    between [0, 3], depending on the first user if the page-table is shared,
    since non-leaf structures only have two bits in the HW for encoding the
    PAT index, and here we are just passing along the full user provided
    index, which can be an index as large as ~31 on xe2+. The user provided
    index is meant for the leaf node, which maps the actual BO pages where
    we have more PAT bits, and not the non-leaf nodes which are only mapping
    other paging structures, and so only needs a minimal PAT index range.
    Also the chosen index might need to consider how the driver mapped the
    paging structures on the host side, like wc vs wb, which is separate
    from the user provided index.
    
    With that move the PDE PAT index selection under driver control. For now
    just use a coherent index on platforms with page-tables that are cached
    on host side, and incoherent otherwise. Using a coherent index could
    potentially be expensive, and would be overkill if we know the page-table
    is always uncached on host side.
    
    v2 (Stuart):
      - Add some documentation and split into separate helper.
    
    BSpec: 59510
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Stuart Summers <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Stuart Summers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Riana Tauro <[email protected]>
Date:   Tue Aug 26 12:04:10 2025 +0530

    drm/xe: Set GT as wedged before sending wedged uevent
    
    [ Upstream commit 90fdcf5f89e9288c153923f16a60e6f7da18ba76 ]
    
    Userspace should be notified after setting the device as wedged.
    Re-order function calls to set gt wedged before sending uevent.
    
    Cc: Matthew Brost <[email protected]>
    Suggested-by: Raag Jadav <[email protected]>
    Signed-off-by: Riana Tauro <[email protected]>
    Reviewed-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: James Jones <[email protected]>
Date:   Thu Oct 30 11:11:52 2025 -0700

    drm: define NVIDIA DRM format modifiers for GB20x
    
    commit 1cf52a0d4ba079fb354fa1339f5fb34142228dae upstream.
    
    The layout of bits within the individual tiles
    (referred to as sectors in the
    DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro)
    changed for 8 and 16-bit surfaces starting in
    Blackwell 2 GPUs (With the exception of GB10).
    To denote the difference, extend the sector field
    in the parametric format modifier definition used
    to generate modifier values for NVIDIA hardware.
    
    Without this change, it would be impossible to
    differentiate the two layouts based on modifiers,
    and as a result software could attempt to share
    surfaces directly between pre-GB20x and GB20x
    cards, resulting in corruption when the surface
    was accessed on one of the GPUs after being
    populated with content by the other.
    
    Of note: This change causes the
    DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro to
    evaluate its "s" parameter twice, with the side
    effects that entails. I surveyed all usage of the
    modifier in the kernel and Mesa code, and that
    does not appear to be problematic in any current
    usage, but I thought it was worth calling out.
    
    Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x")
    Signed-off-by: James Jones <[email protected]>
    Reviewed-by: Faith Ekstrand <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Antheas Kapenekakis <[email protected]>
Date:   Fri Aug 29 16:55:36 2025 +0200

    drm: panel-backlight-quirks: Make EDID match optional
    
    [ Upstream commit 9931e4be11f2129a20ffd908bc364598a63016f8 ]
    
    Currently, having a valid panel_id match is required to use the quirk
    system. For certain devices, we know that all SKUs need a certain quirk.
    Therefore, allow not specifying ident by only checking for a match
    if panel_id is non-zero.
    
    Tested-by: Philip Müller <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Antheas Kapenekakis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jie Zhang <[email protected]>
Date:   Wed Sep 3 12:49:52 2025 +0530

    dt-bindings: display/msm/gmu: Update Adreno 623 bindings
    
    [ Upstream commit c2cc1e60c1afff4f23c22561b57a5d5157dde20d ]
    
    Update Adreno 623's dt-binding to remove smmu_clk which is not required
    for this GMU.
    
    Signed-off-by: Jie Zhang <[email protected]>
    Signed-off-by: Akhil P Oommen <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/672455/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Markus Heidelberg <[email protected]>
Date:   Fri Aug 15 11:58:36 2025 +0200

    dt-bindings: eeprom: at25: use "size" for FRAMs without device ID
    
    commit 534c702c3c234665ca2fe426a9fbb12281e55d55 upstream.
    
    Not all FRAM chips have a device ID and implement the corresponding read
    command. Thus the memory size, which is contained in the device ID,
    cannot be detected and has to be set manually as it is done for EEPROMs.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Markus Heidelberg <[email protected]>
    Reviewed-by: Rob Herring (Arm) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Markus Heidelberg <[email protected]>
Date:   Fri Aug 15 11:58:37 2025 +0200

    eeprom: at25: support Cypress FRAMs without device ID
    
    [ Upstream commit 1b434ed000cd474f074e62e8ab876f87449bb4ac ]
    
    Not all FRAM chips have a device ID and implement the corresponding read
    command. For such chips this led to the following error on module
    loading:
    
        at25 spi2.0: Error: no Cypress FRAM (id 00)
    
    The device ID contains the memory size, so devices without this ID are
    supported now by setting the size manually in Devicetree using the
    "size" property.
    
    Tested with FM25L16B and "size = <2048>;":
    
        at25 spi2.0: 2 KByte fm25 fram, pagesize 4096
    
    According to Infineon/Cypress datasheets, these FRAMs have a device ID:
    
        FM25V01A
        FM25V02A
        FM25V05
        FM25V10
        FM25V20A
        FM25VN10
    
    but these do not:
    
        FM25040B
        FM25640B
        FM25C160B
        FM25CL64B
        FM25L04B
        FM25L16B
        FM25W256
    
    So all "FM25V*" FRAMs and only these have a device ID. The letter after
    "FM25" (V/C/L/W) only describes the voltage range, though.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Markus Heidelberg <[email protected]>
    Reviewed-by: Alexander Sverdlin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Palmer <[email protected]>
Date:   Sun Sep 7 15:43:49 2025 +0900

    eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP
    
    [ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ]
    
    When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range()
    and from there __pci_ioport_map() for the PCI IO space.
    If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my
    m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will
    always fail and the driver will complain it couldn't map the PIO space
    and return an error.
    
    NO_IOPORT_MAP seems to cover the case where what 8139too is trying
    to do cannot ever work so make 8139TOO_PIO depend on being it false
    and avoid creating an unusable driver.
    
    Signed-off-by: Daniel Palmer <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mohsin Bashir <[email protected]>
Date:   Mon Aug 25 13:02:02 2025 -0700

    eth: fbnic: Reset hw stats upon PCI error
    
    [ Upstream commit b1161b1863c5f3d592adba5accd6e5c79741720f ]
    
    Upon experiencing a PCI error, fbnic reset the device to recover from
    the failure. Reset the hardware stats as part of the device reset to
    ensure accurate stats reporting.
    
    Note that the reset is not really resetting the aggregate value to 0,
    which may result in a spike for a system collecting deltas in stats.
    Rather, the reset re-latches the current value as previous, in case HW
    got reset.
    
    Signed-off-by: Mohsin Bashir <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Wahren <[email protected]>
Date:   Fri Sep 12 16:03:32 2025 +0200

    ethernet: Extend device_get_mac_address() to use NVMEM
    
    [ Upstream commit d2d3f529e7b6ff2aa432b16a2317126621c28058 ]
    
    A lot of modern SoC have the ability to store MAC addresses in their
    NVMEM. So extend the generic function device_get_mac_address() to
    obtain the MAC address from an nvmem cell named 'mac-address' in
    case there is no firmware node which contains the MAC address directly.
    
    Signed-off-by: Stefan Wahren <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chi Zhiling <[email protected]>
Date:   Fri Aug 15 17:32:45 2025 +0800

    exfat: limit log print for IO error
    
    [ Upstream commit 6dfba108387bf4e71411b3da90b2d5cce48ba054 ]
    
    For exFAT filesystems with 4MB read_ahead_size, removing the storage device
    when the read operation is in progress, which cause the last read syscall
    spent 150s [1]. The main reason is that exFAT generates excessive log
    messages [2].
    
    After applying this patch, approximately 300,000 lines of log messages
    were suppressed, and the delay of the last read() syscall was reduced
    to about 4 seconds.
    
    [1]:
    write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000120>
    read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000032>
    write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000119>
    read(4, 0x7fccf28ae000, 131072)         = -1 EIO (Input/output error) <150.186215>
    
    [2]:
    [  333.696603] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    [  333.697378] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    [  333.698156] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    
    Signed-off-by: Chi Zhiling <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Namjae Jeon <[email protected]>
Date:   Sat Aug 30 14:44:35 2025 +0900

    exfat: validate cluster allocation bits of the allocation bitmap
    
    [ Upstream commit 79c1587b6cda74deb0c86fc7ba194b92958c793c ]
    
    syzbot created an exfat image with cluster bits not set for the allocation
    bitmap. exfat-fs reads and uses the allocation bitmap without checking
    this. The problem is that if the start cluster of the allocation bitmap
    is 6, cluster 6 can be allocated when creating a directory with mkdir.
    exfat zeros out this cluster in exfat_mkdir, which can delete existing
    entries. This can reallocate the allocated entries. In addition,
    the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.
    This patch adds exfat_test_bitmap_range to validate that clusters used for
    the allocation bitmap are correctly marked as in-use.
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Reviewed-by: Yuezhang Mo <[email protected]>
    Reviewed-by: Sungjong Seo <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Julian Sun <[email protected]>
Date:   Wed Aug 27 20:18:12 2025 +0800

    ext4: increase IO priority of fastcommit
    
    [ Upstream commit 46e75c56dfeafb6756773b71cabe187a6886859a ]
    
    The following code paths may result in high latency or even task hangs:
       1. fastcommit io is throttled by wbt.
       2. jbd2_fc_wait_bufs() might wait for a long time while
    JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then
    jbd2_journal_commit_transaction() waits for the
    JBD2_FAST_COMMIT_ONGOING bit for a long time while holding the write
    lock of j_state_lock.
       3. start_this_handle() waits for read lock of j_state_lock which
    results in high latency or task hang.
    
    Given the fact that ext4_fc_commit() already modifies the current
    process' IO priority to match that of the jbd2 thread, it should be
    reasonable to match jbd2's IO submission flags as well.
    
    Suggested-by: Ritesh Harjani (IBM) <[email protected]>
    Signed-off-by: Julian Sun <[email protected]>
    Reviewed-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri May 9 09:17:04 2025 +0200

    extcon: adc-jack: Cleanup wakeup source only if it was enabled
    
    commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream.
    
    Driver in the probe enables wakeup source conditionally, so the cleanup
    path should do the same - do not release the wakeup source memory if it
    was not allocated.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reported-by: Christophe JAILLET <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Thu May 1 16:33:21 2025 +0200

    extcon: adc-jack: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.  Do not use devm interface, because it would change the order of
    cleanup.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: MyungJoo Ham <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Thu May 1 16:33:22 2025 +0200

    extcon: axp288: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 93ccf3f2f22ceaa975b462156f98527febee4fe5 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Thu May 1 16:33:23 2025 +0200

    extcon: fsa9480: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 6f982d55f8c5d1e9189906a2a352dba8de421f5f ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: wangzijie <[email protected]>
Date:   Wed Sep 17 10:36:22 2025 +0800

    f2fs: fix infinite loop in __insert_extent_tree()
    
    [ Upstream commit 23361bd54966b437e1ed3eb1a704572f4b279e58 ]
    
    When we get wrong extent info data, and look up extent_node in rb tree,
    it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by
    return NULL and print some kernel messages in that case.
    
    Signed-off-by: wangzijie <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chao Yu <[email protected]>
Date:   Thu Aug 7 10:44:31 2025 +0800

    f2fs: fix to detect potential corrupted nid in free_nid_list
    
    [ Upstream commit 8fc6056dcf79937c46c97fa4996cda65956437a9 ]
    
    As reported, on-disk footer.ino and footer.nid is the same and
    out-of-range, let's add sanity check on f2fs_alloc_nid() to detect
    any potential corruption in free_nid_list.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jaegeuk Kim <[email protected]>
Date:   Tue Sep 9 00:26:06 2025 +0000

    f2fs: fix wrong layout information on 16KB page
    
    [ Upstream commit a33be64b98d0723748d2fab0832b926613e1fce0 ]
    
    This patch fixes to support different block size.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Quanmin Yan <[email protected]>
Date:   Fri Oct 10 16:16:59 2025 +0800

    fbcon: Set fb_display[i]->mode to NULL when the mode is released
    
    commit a1f3058930745d2b938b6b4f5bd9630dc74b26b7 upstream.
    
    Recently, we discovered the following issue through syzkaller:
    
    BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0
    Read of size 4 at addr ff11000001b3c69c by task syz.xxx
    ...
    Call Trace:
     <TASK>
     dump_stack_lvl+0xab/0xe0
     print_address_description.constprop.0+0x2c/0x390
     print_report+0xb9/0x280
     kasan_report+0xb8/0xf0
     fb_mode_is_equal+0x285/0x2f0
     fbcon_mode_deleted+0x129/0x180
     fb_set_var+0xe7f/0x11d0
     do_fb_ioctl+0x6a0/0x750
     fb_ioctl+0xe0/0x140
     __x64_sys_ioctl+0x193/0x210
     do_syscall_64+0x5f/0x9c0
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Based on experimentation and analysis, during framebuffer unregistration,
    only the memory of fb_info->modelist is freed, without setting the
    corresponding fb_display[i]->mode to NULL for the freed modes. This leads
    to UAF issues during subsequent accesses. Here's an example of reproduction
    steps:
    1. With /dev/fb0 already registered in the system, load a kernel module
       to register a new device /dev/fb1;
    2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);
    3. Switch console from fb to VGA (to allow normal rmmod of the ko);
    4. Unload the kernel module, at this point fb1's modelist is freed, leaving
       a wild pointer in fb_display[];
    5. Trigger the bug via system calls through fb0 attempting to delete a mode
       from fb0.
    
    Add a check in do_unregister_framebuffer(): if the mode to be freed exists
    in fb_display[], set the corresponding mode pointer to NULL.
    
    Signed-off-by: Quanmin Yan <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Aug 11 11:26:05 2025 -0500

    fbcon: Use screen info to find primary device
    
    [ Upstream commit ad90860bd10ee3ed387077aed88828b139339976 ]
    
    On systems with non VGA GPUs fbcon can't find the primary GPU because
    video_is_primary_device() only checks the VGA arbiter.
    
    Add a screen info check to video_is_primary_device() so that callers
    can get accurate data on such systems.
    
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Suggested-by: Thomas Zimmermann <[email protected]>
    Suggested-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Bjorn Helgaas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Albin Babu Varghese <[email protected]>
Date:   Fri Oct 3 03:32:09 2025 -0400

    fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
    
    [ Upstream commit 3637d34b35b287ab830e66048841ace404382b67 ]
    
    Add bounds checking to prevent writes past framebuffer boundaries when
    rendering text near screen edges. Return early if the Y position is off-screen
    and clip image height to screen boundary. Break from the rendering loop if the
    X position is off-screen. When clipping image width to fit the screen, update
    the character count to match the clipped width to prevent buffer size
    mismatches.
    
    Without the character count update, bit_putcs_aligned and bit_putcs_unaligned
    receive mismatched parameters where the buffer is allocated for the clipped
    width but cnt reflects the original larger count, causing out-of-bounds writes.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
    Suggested-by: Helge Deller <[email protected]>
    Tested-by: [email protected]
    Signed-off-by: Albin Babu Varghese <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Palmer <[email protected]>
Date:   Fri Oct 24 18:37:15 2025 +0900

    fbdev: atyfb: Check if pll_ops->init_pll failed
    
    commit 7073c7fc8d8ba47194e5fc58fcafc0efe7586e9b upstream.
    
    Actually check the return value from pll_ops->init_pll()
    as it can return an error.
    
    If the card's BIOS didn't run because it's not the primary VGA card
    the fact that the xclk source is unsupported is printed as shown
    below but the driver continues on regardless and on my machine causes
    a hard lock up.
    
    [   61.470088] atyfb 0000:03:05.0: enabling device (0080 -> 0083)
    [   61.476191] atyfb: using auxiliary register aperture
    [   61.481239] atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
    [   61.487569] atyfb: 512K SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
    [   61.496112] atyfb: Unsupported xclk source:  5.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Daniel Palmer <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Junjie Cao <[email protected]>
Date:   Mon Oct 20 21:47:01 2025 +0800

    fbdev: bitblit: bound-check glyph index in bit_putcs*
    
    commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
    
    bit_putcs_aligned()/unaligned() derived the glyph pointer from the
    character value masked by 0xff/0x1ff, which may exceed the actual font's
    glyph count and read past the end of the built-in font array.
    Clamp the index to the actual glyph count before computing the address.
    
    This fixes a global out-of-bounds read reported by syzbot.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
    Tested-by: [email protected]
    Signed-off-by: Junjie Cao <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Zsolt Kajtar <[email protected]>
Date:   Thu Aug 21 04:42:48 2025 +0200

    fbdev: core: Fix ubsan warning in pixel_to_pat
    
    [ Upstream commit aad1d99beaaf132e2024a52727c24894cdf9474a ]
    
    It could be triggered on 32 bit big endian machines at 32 bpp in the
    pattern realignment. In this case just return early as the result is
    an identity.
    
    Signed-off-by: Zsolt Kajtar <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Florian Fuchs <[email protected]>
Date:   Sun Oct 26 00:38:50 2025 +0200

    fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS
    
    commit 5f566c0ac51cd2474e47da68dbe719d3acf7d999 upstream.
    
    Commit e24cca19babe ("sh: Kill off MAX_DMA_ADDRESS leftovers.") removed
    the define ONCHIP_NR_DMA_CHANNELS. So that the leftover reference needs
    to be replaced by CONFIG_NR_ONCHIP_DMA_CHANNELS to compile successfully
    with CONFIG_PVR2_DMA enabled.
    
    Signed-off-by: Florian Fuchs <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Miaoqian Lin <[email protected]>
Date:   Mon Oct 27 16:43:37 2025 +0800

    fbdev: valkyriefb: Fix reference count leak in valkyriefb_init
    
    commit eb53368f8d6e2dfba84c8a94d245719bcf9ae270 upstream.
    
    The of_find_node_by_name() function returns a device tree node with its
    reference count incremented. The caller is responsible for calling
    of_node_put() to release this reference when done.
    
    Found via static analysis.
    
    Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Takashi Sakamoto <[email protected]>
Date:   Sat Aug 23 12:09:52 2025 +0900

    firewire: ohci: move self_id_complete tracepoint after validating register
    
    [ Upstream commit 696968262aeee51e1c0529c3c060ddd180702e02 ]
    
    The value of OHCI1394_SelfIDCount register includes an error-indicating
    bit. It is safer to place the tracepoint probe after validating the
    register value.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Val Packett <[email protected]>
Date:   Tue Jul 15 21:27:00 2025 -0300

    firmware: qcom: scm: Allow QSEECOM on Dell Inspiron 7441 / Latitude 7455
    
    [ Upstream commit 30ee285f1e3cdc88ec7010abeaba0cbed800bdcd ]
    
    Allow these machines to access efivars through qseecom/uefisecapp.
    
    Signed-off-by: Val Packett <[email protected]>
    Reviewed-by: Laurentiu Tudor <[email protected]>
    Tested-by: Bryan O'Donoghue <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mukesh Ojha <[email protected]>
Date:   Thu Aug 7 18:14:51 2025 +0530

    firmware: qcom: scm: preserve assign_mem() error return value
    
    [ Upstream commit 121fcf3c871181edce0708a49d2397cedd6ad21f ]
    
    When qcom_scm_assign_mem() fails, the error value is currently being
    overwritten after it is logged, resulting in the loss of the original
    error code. Fix this by retaining and returning the original error value
    as intended.
    
    Signed-off-by: Mukesh Ojha <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikita Travkin <[email protected]>
Date:   Mon Jul 21 18:28:03 2025 +0500

    firmware: qcom: tzmem: disable sc7180 platform
    
    [ Upstream commit 3cc9a8cadaf66e1a53e5fee48f8bcdb0a3fd5075 ]
    
    When SHM bridge is enabled, assigning RMTFS memory causes the calling
    core to hang if the system is running in EL1.
    
    Disable SHM bridge on sc7180 devices to avoid that hang.
    
    Signed-off-by: Nikita Travkin <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kendall Willis <[email protected]>
Date:   Tue Aug 19 14:54:53 2025 -0500

    firmware: ti_sci: Enable abort handling of entry to LPM
    
    [ Upstream commit 0fdd3240fe5a9bf4785e40506bf86b7e16546b83 ]
    
    The PM co-processor (device manager or DM) adds the ability to abort
    entry to a low power mode by clearing the mode selection in the
    latest version of its firmware (11.01.09) [1].
    
    Enable the ti_sci driver to support the LPM abort call which clears the
    low power mode selection of the DM. This fixes an issue where failed
    system suspend attempts would cause subsequent suspends to fail.
    
    After system suspend completes, regardless of if system suspend succeeds
    or fails, the ->complete() hook in TI SCI will be called. In the
    ->complete() hook, a message will be sent to the DM to clear the current
    low power mode selection. Clearing the low power mode selection
    unconditionally will not cause any error in the DM.
    
    [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html
    
    Signed-off-by: Kendall Willis <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Aug 11 11:26:03 2025 -0500

    Fix access to video_is_primary_device() when compiled without CONFIG_VIDEO
    
    [ Upstream commit 6e490dea61b88aac9762c9f79a54aad4ea2e6cd1 ]
    
    When compiled without CONFIG_VIDEO the architecture specific
    implementations of video_is_primary_device() include prototypes and
    assume that video-common.c will be linked. Guard against this so that the
    fallback inline implementation that returns false will be used when
    compiled without CONFIG_VIDEO.
    
    Acked-by: Thomas Zimmermann <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yikang Yue <[email protected]>
Date:   Sat May 3 20:44:34 2025 -0500

    fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink
    
    [ Upstream commit 32058c38d3b79a28963a59ac0353644dc24775cd ]
    
    The function call new_inode() is a primitive for allocating an inode in memory,
    rather than planning disk space for it. Therefore, -ENOMEM should be returned
    as the error code rather than -ENOSPC.
    
    To be specific, new_inode()'s call path looks like this:
    new_inode
      new_inode_pseudo
        alloc_inode
          ops->alloc_inode (hpfs_alloc_inode)
            alloc_inode_sb
              kmem_cache_alloc_lru
    
    Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM),
    not a lack of disk space. However, the current implementation of
    hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails.
    This patch fix this by set err to -ENOMEM before the goto statement.
    
    BTW, we also noticed that other nested calls within these four functions,
    like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure.
    But similarly, only -ENOSPC is returned. Addressing these will involve code
    modifications in other functions, and we plan to submit dedicated patches for these
    issues in the future. For this patch, we focus on new_inode().
    
    Signed-off-by: Yikang Yue <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: chuguangqing <[email protected]>
Date:   Wed Aug 6 10:28:49 2025 +0800

    fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock
    
    [ Upstream commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a ]
    
    The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag.
    
    Signed-off-by: chuguangqing <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yongpeng Yang <[email protected]>
Date:   Tue Nov 4 16:36:42 2025 -0800

    fscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT
    
    commit 1e39da974ce621ed874c6d3aaf65ad14848c9f0d upstream.
    
    When simulating an nvme device on qemu with both logical_block_size and
    physical_block_size set to 8 KiB, an error trace appears during
    partition table reading at boot time. The issue is caused by
    inode->i_blkbits being larger than PAGE_SHIFT, which leads to a left
    shift of -1 and triggering a UBSAN warning.
    
    [    2.697306] ------------[ cut here ]------------
    [    2.697309] UBSAN: shift-out-of-bounds in fs/crypto/inline_crypt.c:336:37
    [    2.697311] shift exponent -1 is negative
    [    2.697315] CPU: 3 UID: 0 PID: 274 Comm: (udev-worker) Not tainted 6.18.0-rc2+ #34 PREEMPT(voluntary)
    [    2.697317] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    [    2.697320] Call Trace:
    [    2.697324]  <TASK>
    [    2.697325]  dump_stack_lvl+0x76/0xa0
    [    2.697340]  dump_stack+0x10/0x20
    [    2.697342]  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390
    [    2.697351]  bh_get_inode_and_lblk_num.cold+0x12/0x94
    [    2.697359]  fscrypt_set_bio_crypt_ctx_bh+0x44/0x90
    [    2.697365]  submit_bh_wbc+0xb6/0x190
    [    2.697370]  block_read_full_folio+0x194/0x270
    [    2.697371]  ? __pfx_blkdev_get_block+0x10/0x10
    [    2.697375]  ? __pfx_blkdev_read_folio+0x10/0x10
    [    2.697377]  blkdev_read_folio+0x18/0x30
    [    2.697379]  filemap_read_folio+0x40/0xe0
    [    2.697382]  filemap_get_pages+0x5ef/0x7a0
    [    2.697385]  ? mmap_region+0x63/0xd0
    [    2.697389]  filemap_read+0x11d/0x520
    [    2.697392]  blkdev_read_iter+0x7c/0x180
    [    2.697393]  vfs_read+0x261/0x390
    [    2.697397]  ksys_read+0x71/0xf0
    [    2.697398]  __x64_sys_read+0x19/0x30
    [    2.697399]  x64_sys_call+0x1e88/0x26a0
    [    2.697405]  do_syscall_64+0x80/0x670
    [    2.697410]  ? __x64_sys_newfstat+0x15/0x20
    [    2.697414]  ? x64_sys_call+0x204a/0x26a0
    [    2.697415]  ? do_syscall_64+0xb8/0x670
    [    2.697417]  ? irqentry_exit_to_user_mode+0x2e/0x2a0
    [    2.697420]  ? irqentry_exit+0x43/0x50
    [    2.697421]  ? exc_page_fault+0x90/0x1b0
    [    2.697422]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [    2.697425] RIP: 0033:0x75054cba4a06
    [    2.697426] Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
    [    2.697427] RSP: 002b:00007fff973723a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000
    [    2.697430] RAX: ffffffffffffffda RBX: 00005ea9a2c02760 RCX: 000075054cba4a06
    [    2.697432] RDX: 0000000000002000 RSI: 000075054c190000 RDI: 000000000000001b
    [    2.697433] RBP: 00007fff973723c0 R08: 0000000000000000 R09: 0000000000000000
    [    2.697434] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
    [    2.697434] R13: 00005ea9a2c027c0 R14: 00005ea9a2be5608 R15: 00005ea9a2be55f0
    [    2.697436]  </TASK>
    [    2.697436] ---[ end trace ]---
    
    This situation can happen for block devices because when
    CONFIG_TRANSPARENT_HUGEPAGE is enabled, the maximum logical_block_size
    is 64 KiB. set_init_blocksize() then sets the block device
    inode->i_blkbits to 13, which is within this limit.
    
    File I/O does not trigger this problem because for filesystems that do
    not support the FS_LBS feature, sb_set_blocksize() prevents
    sb->s_blocksize_bits from being larger than PAGE_SHIFT. During inode
    allocation, alloc_inode()->inode_init_always() assigns inode->i_blkbits
    from sb->s_blocksize_bits. Currently, only xfs_fs_type has the FS_LBS
    flag, and since xfs I/O paths do not reach submit_bh_wbc(), it does not
    hit the left-shift underflow issue.
    
    Signed-off-by: Yongpeng Yang <[email protected]>
    Fixes: 47dd67532303 ("block/bdev: lift block size restrictions to 64k")
    Cc: [email protected]
    [EB: use folio_pos() and consolidate the two shifts by i_blkbits]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Vladimir Riabchun <[email protected]>
Date:   Fri Sep 12 13:28:55 2025 +0200

    ftrace: Fix softlockup in ftrace_module_enable
    
    [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ]
    
    A soft lockup was observed when loading amdgpu module.
    If a module has a lot of tracable functions, multiple calls
    to kallsyms_lookup can spend too much time in RCU critical
    section and with disabled preemption, causing kernel panic.
    This is the same issue that was fixed in
    commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY
    kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to
    ftrace_graph_set_hash()").
    
    Fix it the same way by adding cond_resched() in ftrace_module_enable.
    
    Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc
    Signed-off-by: Vladimir Riabchun <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miklos Szeredi <[email protected]>
Date:   Tue Aug 19 16:44:02 2025 +0200

    fuse: zero initialize inode private data
    
    [ Upstream commit 3ca1b311181072415b6432a169de765ac2034e5a ]
    
    This is slightly tricky, since the VFS uses non-zeroing allocation to
    preserve some fields that are left in a consistent state.
    
    Reported-by: Chunsheng Luo <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Miklos Szeredi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pranav Tyagi <[email protected]>
Date:   Mon Sep 15 23:51:54 2025 +0530

    futex: Don't leak robust_list pointer on exec race
    
    [ Upstream commit 6b54082c3ed4dc9821cdf0edb17302355cc5bb45 ]
    
    sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()
    to check if the calling task is allowed to access another task's
    robust_list pointer. This check is racy against a concurrent exec() in the
    target process.
    
    During exec(), a task may transition from a non-privileged binary to a
    privileged one (e.g., setuid binary) and its credentials/memory mappings
    may change. If get_robust_list() performs ptrace_may_access() before
    this transition, it may erroneously allow access to sensitive information
    after the target becomes privileged.
    
    A racy access allows an attacker to exploit a window during which
    ptrace_may_access() passes before a target process transitions to a
    privileged state via exec().
    
    For example, consider a non-privileged task T that is about to execute a
    setuid-root binary. An attacker task A calls get_robust_list(T) while T
    is still unprivileged. Since ptrace_may_access() checks permissions
    based on current credentials, it succeeds. However, if T begins exec
    immediately afterwards, it becomes privileged and may change its memory
    mappings. Because get_robust_list() proceeds to access T->robust_list
    without synchronizing with exec() it may read user-space pointers from a
    now-privileged process.
    
    This violates the intended post-exec access restrictions and could
    expose sensitive memory addresses or be used as a primitive in a larger
    exploit chain. Consequently, the race can lead to unauthorized
    disclosure of information across privilege boundaries and poses a
    potential security risk.
    
    Take a read lock on signal->exec_update_lock prior to invoking
    ptrace_may_access() and accessing the robust_list/compat_robust_list.
    This ensures that the target task's exec state remains stable during the
    check, allowing for consistent and synchronized validation of
    credentials.
    
    Suggested-by: Jann Horn <[email protected]>
    Signed-off-by: Pranav Tyagi <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/linux-fsdevel/[email protected]/
    Link: https://github.com/KSPP/linux/issues/119
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bartosz Golaszewski <[email protected]>
Date:   Mon Nov 3 10:35:24 2025 +0100

    gpio: swnode: don't use the swnode's name as the key for GPIO lookup
    
    [ Upstream commit e5d527be7e6984882306b49c067f1fec18920735 ]
    
    Looking up a GPIO controller by label that is the name of the software
    node is wonky at best - the GPIO controller driver is free to set
    a different label than the name of its firmware node. We're already being
    passed a firmware node handle attached to the GPIO device to
    swnode_get_gpio_device() so use it instead for a more precise lookup.
    
    Acked-by: Linus Walleij <[email protected]>
    Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bartosz Golaszewski <[email protected]>
Date:   Mon Nov 3 15:11:32 2025 +0100

    gpiolib: fix invalid pointer access in debugfs
    
    [ Upstream commit 2f6115ad8864cf3f48598f26c74c7c8e5c391919 ]
    
    If the memory allocation in gpiolib_seq_start() fails, the s->private
    field remains uninitialized and is later dereferenced without checking
    in gpiolib_seq_stop(). Initialize s->private to NULL before calling
    kzalloc() and check it before dereferencing it.
    
    Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU")
    Reviewed-by: Linus Walleij <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexandre Courbot <[email protected]>
Date:   Fri Jul 18 16:26:08 2025 +0900

    gpu: nova-core: register: allow fields named `offset`
    
    [ Upstream commit c5aeb264b6b27c52fc6c9ef3b50eaaebff5d9b60 ]
    
    `offset` is a common field name, yet using it triggers a build error due
    to the conflict between the uppercased field constant (which becomes
    `OFFSET` in this case) containing the bitrange of the field, and the
    `OFFSET` constant constaining the offset of the register.
    
    Fix this by adding `_RANGE` the field's range constant to avoid the
    name collision.
    
    [[email protected]: fix merge conflict due to switch from `as u32` to
    `u32::from`.]
    
    Reported-by: Timur Tabi <[email protected]>
    Reviewed-by: Daniel Almeida <[email protected]>
    Reviewed-by: Lyude Paul <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Courbot <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tim Hostetler <[email protected]>
Date:   Wed Oct 29 11:45:39 2025 -0700

    gve: Implement gettimex64 with -EOPNOTSUPP
    
    [ Upstream commit 6ab753b5d8e521616cd9bd10b09891cbeb7e0235 ]
    
    gve implemented a ptp_clock for sole use of do_aux_work at this time.
    ptp_clock_gettime() and ptp_sys_offset() assume every ptp_clock has
    implemented either gettimex64 or gettime64. Stub gettimex64 and return
    -EOPNOTSUPP to prevent NULL dereferencing.
    
    Fixes: acd16380523b ("gve: Add initial PTP device support")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=c8c0e7ccabd456541612
    Signed-off-by: Tim Hostetler <[email protected]>
    Reviewed-by: Harshitha Ramamurthy <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Joshua Washington <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tim Hostetler <[email protected]>
Date:   Wed Oct 29 11:45:40 2025 -0700

    gve: Implement settime64 with -EOPNOTSUPP
    
    [ Upstream commit 329d050bbe63c2999f657cf2d3855be11a473745 ]
    
    ptp_clock_settime() assumes every ptp_clock has implemented settime64().
    Stub it with -EOPNOTSUPP to prevent a NULL dereference.
    
    Fixes: acd16380523b ("gve: Add initial PTP device support")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=a546141ca6d53b90aba3
    Signed-off-by: Tim Hostetler <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Joshua Washington <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Antheas Kapenekakis <[email protected]>
Date:   Thu Aug 14 15:01:51 2025 +0200

    HID: asus: add Z13 folio to generic group for multitouch to work
    
    [ Upstream commit b595974b4afe0e171dd707da570964ff642742e3 ]
    
    The Asus Z13 folio has a multitouch touchpad that needs to bind
    to the hid-multitouch driver in order to work properly. So bind
    it to the HID_GROUP_GENERIC group to release the touchpad and
    move it to the bottom so that the comment applies to it.
    
    While at it, change the generic KEYBOARD3 name to Z13_FOLIO.
    
    Reviewed-by: Luke D. Jones <[email protected]>
    Signed-off-by: Antheas Kapenekakis <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Tue Sep 9 06:00:06 2025 -0500

    HID: i2c-hid: Resolve touchpad issues on Dell systems during S4
    
    [ Upstream commit 7d62beb102d6fa9a4e5e874be7fbf47a62fcc4f6 ]
    
    Dell systems utilize an EC-based touchpad emulation when the ACPI
    touchpad _DSM is not invoked. This emulation acts as a secondary
    master on the I2C bus, designed for scenarios where the I2C touchpad
    driver is absent, such as in BIOS menus. Typically, loading the
    i2c-hid module triggers the _DSM at initialization, disabling the
    EC-based emulation.
    
    However, if the i2c-hid module is missing from the boot kernel
    used for hibernation snapshot restoration, the _DSM remains
    uncalled, resulting in dual masters on the I2C bus and
    subsequent arbitration errors. This issue arises when i2c-hid
    resides in the rootfs instead of the kernel or initramfs.
    
    To address this, switch from using the SYSTEM_SLEEP_PM_OPS()
    macro to dedicated callbacks, introducing a specific
    callback for restoring the S4 image. This callback ensures
    the _DSM is invoked.
    
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomasz Pakuła <[email protected]>
Date:   Wed Aug 13 22:10:00 2025 +0200

    HID: pidff: PERMISSIVE_CONTROL quirk autodetection
    
    [ Upstream commit c2dc9f0b368c08c34674311cf78407718d5715a7 ]
    
    Fixes force feedback for devices built with MMOS firmware and many more
    not yet detected devices.
    
    Update quirks mask debug message to always contain all 32 bits of data.
    
    Signed-off-by: Tomasz Pakuła <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tomasz Pakuła <[email protected]>
Date:   Wed Aug 13 22:09:49 2025 +0200

    HID: pidff: Use direction fix only for conditional effects
    
    [ Upstream commit f345a4798dab800159b09d088e7bdae0f16076c3 ]
    
    The already fixed bug in SDL only affected conditional effects. This
    should fix FFB in Forza Horizion 4/5 on Moza Devices as Forza Horizon
    flips the constant force direction instead of using negative magnitude
    values.
    
    Changing the direction in the effect directly in pidff_upload_effect()
    would affect it's value in further operations like comparing to the old
    effect and/or just reading the effect values in the user application.
    
    This, in turn, would lead to constant PID_SET_EFFECT spam as the effect
    direction would constantly not match the value that's set by the
    application.
    
    This way, it's still transparent to any software/API.
    
    Only affects conditional effects now so it's better for it to explicitly
    state that in the name. If any HW ever needs fixed direction for other
    effects, we'll add more quirks.
    
    Signed-off-by: Tomasz Pakuła <[email protected]>
    Reviewed-by: Oleg Makarenko <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fan Gong <[email protected]>
Date:   Fri Sep 12 14:28:30 2025 +0800

    hinic3: Fix missing napi->dev in netif_queue_set_napi
    
    [ Upstream commit 4404f6af810829588a51968959c6b85574109c13 ]
    
    As netif_queue_set_napi checks napi->dev, if it doesn't have it and
    it will warn_on and return. So we should use netif_napi_add before
    netif_queue_set_napi because netif_napi_add has "napi->dev = dev".
    
    Co-developed-by: Zhu Yikai <[email protected]>
    Signed-off-by: Zhu Yikai <[email protected]>
    Signed-off-by: Fan Gong <[email protected]>
    Reviewed-by: Vadim Fedorenko <[email protected]>
    Link: https://patch.msgid.link/a17a5a087350eaf2e081dcd879779ca2c69b0908.1757653621.git.zhuyikai1@h-partners.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fan Gong <[email protected]>
Date:   Fri Sep 12 14:28:24 2025 +0800

    hinic3: Queue pair endianness improvements
    
    [ Upstream commit 6b822b658aafe840ffd6d7f1af5bf4f77df15a11 ]
    
    Explicitly use little-endian & big-endian structs to support big
    endian hosts.
    
    Co-developed-by: Zhu Yikai <[email protected]>
    Signed-off-by: Zhu Yikai <[email protected]>
    Signed-off-by: Fan Gong <[email protected]>
    Reviewed-by: Vadim Fedorenko <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/9b995a10f1e209a878bf98e4e1cdfb926f386695.1757653621.git.zhuyikai1@h-partners.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ben Copeland <[email protected]>
Date:   Tue Sep 23 21:26:56 2025 +0200

    hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex
    
    [ Upstream commit 584d55be66ef151e6ef9ccb3dcbc0a2155559be1 ]
    
    Some motherboards require more time to acquire the ACPI mutex,
    causing "Failed to acquire mutex" messages to appear in the kernel log.
    Increase the timeout from 500ms to 800ms to accommodate these cases.
    
    Signed-off-by: Ben Copeland <[email protected]>
    Signed-off-by: Eugene Shalygin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Wed Sep 17 20:10:36 2025 +0200

    hwmon: (dell-smm) Add support for Dell OptiPlex 7040
    
    [ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ]
    
    The Dell OptiPlex 7040 supports the legacy SMM interface for reading
    sensors and performing fan control. Whitelist this machine so that
    this driver loads automatically.
    
    Closes: https://github.com/Wer-Wolf/i8kutils/issues/15
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Wed Sep 17 20:10:33 2025 +0200

    hwmon: (dell-smm) Remove Dell Precision 490 custom config data
    
    [ Upstream commit ddb61e737f04e3c6c8299c1e00bf17a42a7f05cf ]
    
    It turns out the second fan on the Dell Precision 490 does not
    really support I8K_FAN_TURBO. Setting the fan state to 3 enables
    automatic fan control, just like on the other two fans.
    The reason why this was misinterpreted as turbo mode was that
    the second fan normally spins faster in automatic mode than
    in the previous fan states. Yet when in state 3, the fan speed
    reacts to heat exposure, exposing the automatic mode setting.
    
    Link: https://github.com/lm-sensors/lm-sensors/pull/383
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rong Zhang <[email protected]>
Date:   Sun Aug 24 02:04:41 2025 +0800

    hwmon: (k10temp) Add device ID for Strix Halo
    
    [ Upstream commit e5d1e313d7b6272d6dfda983906d99f97ad9062b ]
    
    The device ID of Strix Halo Data Fabric Function 3 has been in the tree
    since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family
    0x1a"), but is somehow missing from k10temp_id_table.
    
    Add it so that it works out of the box.
    
    Tested on Beelink GTR9 Pro Mini PC.
    
    Signed-off-by: Rong Zhang <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Avadhut Naik <[email protected]>
Date:   Tue Jul 29 00:15:43 2025 +0000

    hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models
    
    [ Upstream commit f116af2eb51ed9df24911537fda32a033f1c58da ]
    
    Add thermal info support for newer AMD Family 1Ah-based models.
    
    Signed-off-by: Avadhut Naik <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Ober <[email protected]>
Date:   Thu Aug 7 06:32:28 2025 -0400

    hwmon: (lenovo-ec-sensors) Update P8 supprt
    
    [ Upstream commit 43c056ac85b60232861005765153707f1b0354b6 ]
    
    This fixes differences for the P8 system that was initially set to
    the same thermal values as the P7, also adds in the PSU sensor for
    all of the supported systems
    
    Signed-off-by: David Ober <[email protected]>
    Signed-off-by: David Ober <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: Update subject]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chuande Chen <[email protected]>
Date:   Thu Aug 14 13:39:40 2025 +0800

    hwmon: (sbtsi_temp) AMD CPU extended temperature range support
    
    [ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ]
    
    Many AMD CPUs can support this feature now. We would get a wrong CPU DIE
    temperature if don't consider this. In low-temperature environments,
    the CPU die temperature can drop below zero. So many platforms would like
    to make extended temperature range as their default configuration.
    Default temperature range (0C to 255.875C).
    Extended temperature range (-49C to +206.875C).
    Ref Doc: AMD V3000 PPR (Doc ID #56558).
    
    Signed-off-by: Chuande Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andreas Kemnade <[email protected]>
Date:   Tue Sep 9 10:02:49 2025 +0200

    hwmon: sy7636a: add alias
    
    [ Upstream commit 80038a758b7fc0cdb6987532cbbf3f75b13e0826 ]
    
    Add module alias to have it autoloaded.
    
    Signed-off-by: Andreas Kemnade <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xichao Zhao <[email protected]>
Date:   Thu Jul 31 20:17:27 2025 +0800

    hwrng: timeriomem - Use us_to_ktime() where appropriate
    
    [ Upstream commit 817fcdbd4ca29834014a5dadbe8e11efeb12800c ]
    
    It is better to replace ns_to_ktime() with us_to_ktime(),
    which can make the code clearer.
    
    Signed-off-by: Xichao Zhao <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nuno Das Neves <[email protected]>
Date:   Wed Aug 13 11:20:57 2025 -0700

    hyperv: Add missing field to hv_output_map_device_interrupt
    
    [ Upstream commit 4cd661c248b6671914ad59e16760bb6d908dfc61 ]
    
    This field is unused, but the correct structure size is needed
    when computing the amount of space for the output argument to
    reside, so that it does not cross a page boundary.
    
    Signed-off-by: Nuno Das Neves <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Manikanta Guntupalli <[email protected]>
Date:   Wed Jul 30 20:42:07 2025 +0530

    i3c: dw: Add shutdown support to dw_i3c_master driver
    
    [ Upstream commit 17e163f3d7a5449fe9065030048e28c4087b24ce ]
    
    Add shutdown handler to the Synopsys DesignWare I3C master driver,
    ensuring the device is gracefully disabled during system shutdown.
    
    The shutdown handler cancels any pending hot-join work and disables
    interrupts.
    
    Signed-off-by: Manikanta Guntupalli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jarkko Nikula <[email protected]>
Date:   Fri Aug 8 16:17:32 2025 +0300

    i3c: mipi-i3c-hci-pci: Add support for Intel Wildcat Lake-U I3C
    
    [ Upstream commit d515503f3c8a8475b2f78782534aad09722904e1 ]
    
    Add I3C controller PCI IDs on Intel Wildcat Lake-U.
    
    Signed-off-by: Jarkko Nikula <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vlad Dumitrescu <[email protected]>
Date:   Tue Sep 16 14:11:03 2025 +0300

    IB/ipoib: Ignore L3 master device
    
    [ Upstream commit 42f993d3439827c4959ea77e60620d7ebfb3a477 ]
    
    Currently, all master upper netdevices (e.g., bond, VRF) are treated
    equally.
    
    When a VRF netdevice is used over an IPoIB netdevice, the expected
    netdev resolution is on the lower IPoIB device which has the IP address
    assigned to it and not the VRF device.
    
    The rdma_cm module (CMA) tries to match incoming requests to a
    particular netdevice. When successful, it also validates that the return
    path points to the same device by performing a routing table lookup.
    Currently, the former would resolve to the VRF netdevice, while the
    latter to the correct lower IPoIB netdevice, leading to failure in
    rdma_cm.
    
    Improve this by ignoring the VRF master netdevice, if it exists, and
    instead return the lower IPoIB device.
    
    Signed-off-by: Vlad Dumitrescu <[email protected]>
    Reviewed-by: Parav Pandit <[email protected]>
    Signed-off-by: Edward Srouji <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Mon Aug 11 11:43:18 2025 +0200

    ice: Don't use %pK through printk or tracepoints
    
    [ Upstream commit 66ceb45b7d7e9673254116eefe5b6d3a44eba267 ]
    
    In the past %pK was preferable to %p as it would not leak raw pointer
    values into the kernel log.
    Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
    the regular %p has been improved to avoid this issue.
    Furthermore, restricted pointers ("%pK") were never meant to be used
    through printk(). They can still unintentionally leak raw pointers or
    acquire sleeping locks in atomic contexts.
    
    Switch to the regular pointer formatting which is safer and
    easier to reason about.
    There are still a few users of %pK left, but these use it through seq_file,
    for which its usage is safe.
    
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Acked-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Mon Aug 18 19:59:34 2025 +0000

    idpf: do not linearize big TSO packets
    
    [ Upstream commit 02614eee26fbdfd73b944769001cefeff6ed008c ]
    
    idpf has a limit on number of scatter-gather frags
    that can be used per segment.
    
    Currently, idpf_tx_start() checks if the limit is hit
    and forces a linearization of the whole packet.
    
    This requires high order allocations that can fail
    under memory pressure. A full size BIG-TCP packet
    would require order-7 alocation on x86_64 :/
    
    We can move the check earlier from idpf_features_check()
    for TSO packets, to force GSO in this case, removing the
    cost of a big copy.
    
    This means that a linearization will eventually happen
    with sizes smaller than one MSS.
    
    __idpf_chk_linearize() is renamed to idpf_chk_tso_segment()
    and moved to idpf_lib.c
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Przemek Kitszel <[email protected]>
    Cc: Jacob Keller <[email protected]>
    Cc: Madhu Chittim <[email protected]>
    Cc: Pavan Kumar Linga <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Cc: Andrew Lunn <[email protected]>
    Reviewed-by: Joshua Hay <[email protected]>
    Tested-by: Brian Vazquez <[email protected]>
    Acked-by: Tony Nguyen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexander Lobakin <[email protected]>
Date:   Tue Aug 26 17:54:58 2025 +0200

    idpf: link NAPIs to queues
    
    [ Upstream commit bd74a86bc75d35adefbebcec7c3a743d02c06230 ]
    
    Add the missing linking of NAPIs to netdev queues when enabling
    interrupt vectors in order to support NAPI configuration and
    interfaces requiring get_rx_queue()->napi to be set (like XSk
    busy polling).
    
    As currently, idpf_vport_{start,stop}() is called from several flows
    with inconsistent RTNL locking, we need to synchronize them to avoid
    runtime assertions. Notably:
    
    * idpf_{open,stop}() -- regular NDOs, RTNL is always taken;
    * idpf_initiate_soft_reset() -- usually called under RTNL;
    * idpf_init_task -- called from the init work, needs RTNL;
    * idpf_vport_dealloc -- called without RTNL taken, needs it.
    
    Expand common idpf_vport_{start,stop}() to take an additional bool
    telling whether we need to manually take the RTNL lock.
    
    Suggested-by: Maciej Fijalkowski <[email protected]> # helper
    Signed-off-by: Alexander Lobakin <[email protected]>
    Tested-by: Ramu R <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Lechner <[email protected]>
Date:   Thu Aug 28 16:54:53 2025 -0500

    iio: adc: ad7124: do not require mclk
    
    [ Upstream commit aead8e4cc04612f74c7277de137cc995df280829 ]
    
    Make the "mclk" clock optional in the ad7124 driver. The MCLK is an
    internal counter on the ADC, so it is not something that should be
    coming from the devicetree. However, existing users may be using this
    to essentially select the power mode of the ADC from the devicetree.
    In order to not break those users, we have to keep the existing "mclk"
    handling, but now it is optional.
    
    Now, when the "mclk" clock is omitted from the devicetree, the driver
    will default to the full power mode. Support for an external clock
    and dynamic power mode switching can be added later if needed.
    
    Signed-off-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/20250828-iio-adc-ad7124-proper-clock-support-v3-2-0b317b4605e5@baylibre.com
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Haibo Chen <[email protected]>
Date:   Tue Aug 12 16:04:23 2025 +0800

    iio: adc: imx93_adc: load calibrated values even calibration failed
    
    [ Upstream commit 12c9b09e981ab14ebec8e4eefa946cbd26dd306b ]
    
    ADC calibration might fail because of the noise on reference voltage.
    To avoid calibration fail, need to meet the following requirement:
        ADC reference voltage Noise < 1.8V * 1/2^ENOB
    
    For the case which the ADC reference voltage on board do not meet
    the requirement, still load the calibrated values, so ADC can also
    work but maybe not that accurate.
    
    Signed-off-by: Haibo Chen <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Reviewed-by: Primoz Fiser <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rodrigo Gobbi <[email protected]>
Date:   Thu Jul 17 19:13:49 2025 -0300

    iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before setting register
    
    [ Upstream commit d75c7021c08e8ae3f311ef2464dca0eaf75fab9f ]
    
    avg sample info is a bit field coded inside the following
    bits: 5,6,7 and 8 of a device status register.
    
    Channel num info the same, but over bits: 1, 2 and 3.
    
    Mask both values in order to avoid touching other register bits,
    since the first info (avg sample), came from DT.
    
    Signed-off-by: Rodrigo Gobbi <[email protected]>
    Reviewed-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cryolitia PukNgae <[email protected]>
Date:   Thu Aug 21 15:52:36 2025 +0800

    iio: imu: bmi270: Match PNP ID found on newer GPD firmware
    
    [ Upstream commit dc757dc1572d579c2634c05d0a03c5676227c571 ]
    
    GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID.
    When they switched to BMI260 sensors in newer hardware, they reused
    the existing Windows driver which accepts both "BMI0160" and "BMI0260"
    IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260
    devices, causing driver mismatches in Linux.
    
    1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for
    BMI260 sensors to avoid loading the bmi160 driver on Linux. While this
    isn't Bosch's VID;
    2. Bosch's official Windows driver uses "BMI0260" as a compatible ID
    3. We're seeing real devices shipping with "BMI0260" in DSDT
    
    The DSDT excerpt of GPD G1619-04 with BIOS v0.40:
    
    Scope (_SB.I2CC)
    {
        Device (BMA2)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "BMI0260")  // _HID: Hardware ID
            Name (_CID, "BMI0260")  // _CID: Compatible ID
            Name (_DDN, "Accelerometer")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.I2CC",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */
            }
            # omit some noise
        }
    }
    
    Link: http://download.softwincn.com/WIN%20Max%202024/Max2-7840-BIOS-V0.41.zip #1
    Signed-off-by: Cryolitia PukNgae <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Acked-by: Alex Lanzano <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Coiby Xu <[email protected]>
Date:   Mon Sep 15 13:55:23 2025 +0800

    ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr
    
    [ Upstream commit 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd ]
    
    Currently when both IMA and EVM are in fix mode, the IMA signature will
    be reset to IMA hash if a program first stores IMA signature in
    security.ima and then writes/removes some other security xattr for the
    file.
    
    For example, on Fedora, after booting the kernel with "ima_appraise=fix
    evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,
    installing/reinstalling a package will not make good reference IMA
    signature generated. Instead IMA hash is generated,
    
        # getfattr -m - -d -e hex /usr/bin/bash
        # file: usr/bin/bash
        security.ima=0x0404...
    
    This happens because when setting security.selinux, the IMA_DIGSIG flag
    that had been set early was cleared. As a result, IMA hash is generated
    when the file is closed.
    
    Similarly, IMA signature can be cleared on file close after removing
    security xattr like security.evm or setting/removing ACL.
    
    Prevent replacing the IMA file signature with a file hash, by preventing
    the IMA_DIGSIG flag from being reset.
    
    Here's a minimal C reproducer which sets security.selinux as the last
    step which can also replaced by removing security.evm or setting ACL,
    
        #include <stdio.h>
        #include <sys/xattr.h>
        #include <fcntl.h>
        #include <unistd.h>
        #include <string.h>
        #include <stdlib.h>
    
        int main() {
            const char* file_path = "/usr/sbin/test_binary";
            const char* hex_string = "030204d33204490066306402304";
            int length = strlen(hex_string);
            char* ima_attr_value;
            int fd;
    
            fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
            if (fd == -1) {
                perror("Error opening file");
                return 1;
            }
    
            ima_attr_value = (char*)malloc(length / 2 );
            for (int i = 0, j = 0; i < length; i += 2, j++) {
                sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
            }
    
            if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
                perror("Error setting extended attribute");
                close(fd);
                return 1;
            }
    
            const char* selinux_value= "system_u:object_r:bin_t:s0";
            if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
                perror("Error setting extended attribute");
                close(fd);
                return 1;
            }
    
            close(fd);
    
            return 0;
        }
    
    Signed-off-by: Coiby Xu <[email protected]>
    Signed-off-by: Mimi Zohar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 10:27:36 2025 +0000

    inet_diag: annotate data-races in inet_diag_bc_sk()
    
    [ Upstream commit 4fd84a0aaf2ba125b441aa09d415022385e66bf2 ]
    
    inet_diag_bc_sk() runs with an unlocked socket,
    annotate potential races with READ_ONCE().
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Caleb Sander Mateos <[email protected]>
Date:   Thu Sep 4 11:08:59 2025 -0600

    io_uring/rsrc: respect submitter_task in io_register_clone_buffers()
    
    [ Upstream commit 2f076a453f75de691a081c89bce31b530153d53b ]
    
    io_ring_ctx's enabled with IORING_SETUP_SINGLE_ISSUER are only allowed
    a single task submitting to the ctx. Although the documentation only
    mentions this restriction applying to io_uring_enter() syscalls,
    commit d7cce96c449e ("io_uring: limit registration w/ SINGLE_ISSUER")
    extends it to io_uring_register(). Ensuring only one task interacts
    with the io_ring_ctx will be important to allow this task to avoid
    taking the uring_lock.
    There is, however, one gap in these checks: io_register_clone_buffers()
    may take the uring_lock on a second (source) io_ring_ctx, but
    __io_uring_register() only checks the current thread against the
    *destination* io_ring_ctx's submitter_task. Fail the
    IORING_REGISTER_CLONE_BUFFERS with -EEXIST if the source io_ring_ctx has
    a registered submitter_task other than the current task.
    
    Signed-off-by: Caleb Sander Mateos <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Tue Sep 16 15:28:03 2025 +0100

    io_uring/zcrx: account niov arrays to cgroup
    
    [ Upstream commit 31bf77dcc3810e08bcc7d15470e92cdfffb7f7f1 ]
    
    net_iov / freelist / etc. arrays can be quite long, make sure they're
    accounted.
    
    Signed-off-by: Pavel Begunkov <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Tue Sep 16 15:27:50 2025 +0100

    io_uring/zcrx: check all niovs filled with dma addresses
    
    [ Upstream commit d7ae46b454eb05e3df0d46c2ac9c61416a4d9057 ]
    
    Add a warning if io_populate_area_dma() can't fill in all net_iovs, it
    should never happen.
    
    Signed-off-by: Pavel Begunkov <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Thu Aug 14 15:40:57 2025 +0100

    io_uring/zctx: check chained notif contexts
    
    [ Upstream commit ab3ea6eac5f45669b091309f592c4ea324003053 ]
    
    Send zc only links ubuf_info for requests coming from the same context.
    There are some ambiguous syz reports, so let's check the assumption on
    notification completion.
    
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/fd527d8638203fe0f1c5ff06ff2e1d8fd68f831b.1755179962.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Fri Nov 7 18:41:26 2025 +0000

    io_uring: fix regbuf vector size truncation
    
    commit 146eb58629f45f8297e83d69e64d4eea4b28d972 upstream.
    
    There is a report of io_estimate_bvec_size() truncating the calculated
    number of segments that leads to corruption issues. Check it doesn't
    overflow "int"s used later. Rough but simple, can be improved on top.
    
    Cc: [email protected]
    Fixes: 9ef4cbbcb4ac3 ("io_uring: add infra for importing vectored reg buffers")
    Reported-by: Google Big Sleep <[email protected]>
    Signed-off-by: Pavel Begunkov <[email protected]>
    Reviewed-by: Günther Noack <[email protected]>
    Tested-by: Günther Noack <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Wed Nov 5 15:47:01 2025 +0000

    io_uring: fix types for region size calulation
    
    [ Upstream commit 1fd5367391bf0eeb09e624c4ab45121b54eaab96 ]
    
    ->nr_pages is int, it needs type extension before calculating the region
    size.
    
    Fixes: a90558b36ccee ("io_uring/memmap: helper for pinning region pages")
    Signed-off-by: Pavel Begunkov <[email protected]>
    [axboe: style fixup]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ashish Kalra <[email protected]>
Date:   Mon Aug 25 21:46:01 2025 +0000

    iommu/amd: Add support to remap/unmap IOMMU buffers for kdump
    
    [ Upstream commit f32fe7cb019861f585b40bff4c3daf237b9af294 ]
    
    After a panic if SNP is enabled in the previous kernel then the kdump
    kernel boots with IOMMU SNP enforcement still enabled.
    
    IOMMU completion wait buffers (CWBs), command buffers and event buffer
    registers remain locked and exclusive to the previous kernel. Attempts
    to allocate and use new buffers in the kdump kernel fail, as hardware
    ignores writes to the locked MMIO registers as per AMD IOMMU spec
    Section 2.12.2.1.
    
    This results in repeated "Completion-Wait loop timed out" errors and a
    second kernel panic: "Kernel panic - not syncing: timer doesn't work
    through Interrupt-remapped IO-APIC"
    
    The list of MMIO registers locked and which ignore writes after failed
    SNP shutdown are mentioned in the AMD IOMMU specifications below:
    
    Section 2.12.2.1.
    https://docs.amd.com/v/u/en-US/48882_3.10_PUB
    
    Reuse the pages of the previous kernel for completion wait buffers,
    command buffers, event buffers and memremap them during kdump boot
    and essentially work with an already enabled IOMMU configuration and
    re-using the previous kernel’s data structures.
    
    Reusing of command buffers and event buffers is now done for kdump boot
    irrespective of SNP being enabled during kdump.
    
    Re-use of completion wait buffers is only done when SNP is enabled as
    the exclusion base register is used for the completion wait buffer
    (CWB) address only when SNP is enabled.
    
    Reviewed-by: Vasant Hegde <[email protected]>
    Tested-by: Sairaj Kodilkar <[email protected]>
    Signed-off-by: Ashish Kalra <[email protected]>
    Link: https://lore.kernel.org/r/ff04b381a8fe774b175c23c1a336b28bc1396511.1756157913.git.ashish.kalra@amd.com
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ashish Kalra <[email protected]>
Date:   Mon Aug 25 21:46:15 2025 +0000

    iommu/amd: Reuse device table for kdump
    
    [ Upstream commit 38e5f33ee3596f37ee8d1e694073a17590904004 ]
    
    After a panic if SNP is enabled in the previous kernel then the kdump
    kernel boots with IOMMU SNP enforcement still enabled.
    
    IOMMU device table register is locked and exclusive to the previous
    kernel. Attempts to copy old device table from the previous kernel
    fails in kdump kernel as hardware ignores writes to the locked device
    table base address register as per AMD IOMMU spec Section 2.12.2.1.
    
    This causes the IOMMU driver (OS) and the hardware to reference
    different memory locations. As a result, the IOMMU hardware cannot
    process the command which results in repeated "Completion-Wait loop
    timed out" errors and a second kernel panic: "Kernel panic - not
    syncing: timer doesn't work through Interrupt-remapped IO-APIC".
    
    Reuse device table instead of copying device table in case of kdump
    boot and remove all copying device table code.
    
    Reviewed-by: Vasant Hegde <[email protected]>
    Tested-by: Sairaj Kodilkar <[email protected]>
    Signed-off-by: Ashish Kalra <[email protected]>
    Link: https://lore.kernel.org/r/3a31036fb2f7323e6b1a1a1921ac777e9f7bdddc.1756157913.git.ashish.kalra@amd.com
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ashish Kalra <[email protected]>
Date:   Mon Aug 25 21:46:53 2025 +0000

    iommu/amd: Skip enabling command/event buffers for kdump
    
    [ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ]
    
    After a panic if SNP is enabled in the previous kernel then the kdump
    kernel boots with IOMMU SNP enforcement still enabled.
    
    IOMMU command buffers and event buffer registers remain locked and
    exclusive to the previous kernel. Attempts to enable command and event
    buffers in the kdump kernel will fail, as hardware ignores writes to
    the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1.
    
    Skip enabling command buffers and event buffers for kdump boot as they
    are already enabled in the previous kernel.
    
    Reviewed-by: Vasant Hegde <[email protected]>
    Tested-by: Sairaj Kodilkar <[email protected]>
    Signed-off-by: Ashish Kalra <[email protected]>
    Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hector Martin <[email protected]>
Date:   Tue Aug 26 12:57:18 2025 +0200

    iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs
    
    [ Upstream commit ecf6508923f87e4597228f70cc838af3d37f6662 ]
    
    These registers exist and at least on the t602x variant the IRQ only
    clears when theses are cleared.
    
    Signed-off-by: Hector Martin <[email protected]>
    Signed-off-by: Janne Grunau <[email protected]>
    Reviewed-by: Sven Peter <[email protected]>
    Reviewed-by: Neal Gompa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lu Baolu <[email protected]>
Date:   Thu Sep 18 13:02:01 2025 +0800

    iommu/vt-d: Remove LPIG from page group response descriptor
    
    [ Upstream commit 4402e8f39d0bfff5c0a5edb5e1afe27a56545e11 ]
    
    Bit 66 in the page group response descriptor used to be the LPIG (Last
    Page in Group), but it was marked as Reserved since Specification 4.0.
    Remove programming on this bit to make it consistent with the latest
    specification.
    
    Existing hardware all treats bit 66 of the page group response descriptor
    as "ignored", therefore this change doesn't break any existing hardware.
    
    Signed-off-by: Lu Baolu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Seyediman Seyedarab <[email protected]>
Date:   Thu Sep 18 13:01:58 2025 +0800

    iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot()
    
    [ Upstream commit 75c02a037609f34db17e91be195cedb33b61bae0 ]
    
    snprintf() returns the number of bytes that would have been written, not
    the number actually written. Using this for offset tracking can cause
    buffer overruns if truncation occurs.
    
    Replace snprintf() with scnprintf() to ensure the offset stays within
    bounds.
    
    Since scnprintf() never returns a negative value, and zero is not possible
    in this context because 'bytes' starts at 0 and 'size - bytes' is
    DEBUG_BUFFER_SIZE in the first call, which is large enough to hold the
    string literals used, the return value is always positive. An integer
    overflow is also completely out of reach here due to the small and fixed
    buffer size. The error check in latency_show_one() is therefore
    unnecessary. Remove it and make dmar_latency_snapshot() return void.
    
    Signed-off-by: Seyediman Seyedarab <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jason Gunthorpe <[email protected]>
Date:   Wed Oct 8 15:17:18 2025 -0300

    iommufd: Don't overflow during division for dirty tracking
    
    commit cb30dfa75d55eced379a42fd67bd5fb7ec38555e upstream.
    
    If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow
    to 0 and this triggers divide by 0.
    
    In this case the index should just be 0, so reorganize things to divide
    by shift and avoid hitting any overflows.
    
    Link: https://patch.msgid.link/r/[email protected]
    Cc: [email protected]
    Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support")
    Reviewed-by: Joao Martins <[email protected]>
    Reviewed-by: Nicolin Chen <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=093a8a8b859472e6c257
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Alok Tiwari <[email protected]>
Date:   Fri Sep 12 07:14:24 2025 -0700

    ionic: use int type for err in ionic_get_module_eeprom_by_page
    
    [ Upstream commit d586676a2714176bed06cf70467c4e08ac2d4681 ]
    
    The variable 'err' is declared as u32, but it is used to store
    negative error codes such as -EINVAL.
    
    Changing the type of 'err' to int ensures proper representation of
    negative error codes and aligns with standard kernel error handling
    conventions.
    
    Also, there is no need to initialize 'err' since it is always set
    before being used.
    
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Shannon Nelson <[email protected]>
    Reviewed-by: Brett Creeley <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yue Haibing <[email protected]>
Date:   Mon Sep 1 20:37:26 2025 +0800

    ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled
    
    [ Upstream commit 3d95261eeb74958cd496e1875684827dc5d028cc ]
    
    In ipv6_rpl_srh_rcv() we use min(net->ipv6.devconf_all->rpl_seg_enabled,
    idev->cnf.rpl_seg_enabled) is intended to return 0 when either value is
    zero, but if one of the values is negative it will in fact return non-zero.
    
    Signed-off-by: Yue Haibing <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Tue Sep 16 16:09:44 2025 +0000

    ipv6: np->rxpmtu race annotation
    
    [ Upstream commit 9fba1eb39e2f74d2002c5cbcf1d4435d37a4f752 ]
    
    Add READ_ONCE() annotations because np->rxpmtu can be changed
    while udpv6_recvmsg() and rawv6_recvmsg() read it.
    
    Since this is a very rarely used feature, and that udpv6_recvmsg()
    and rawv6_recvmsg() read np->rxopt anyway, change the test order
    so that np->rxpmtu does not need to be in a hot cache line.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christian Bruel <[email protected]>
Date:   Tue Sep 2 11:10:45 2025 +0200

    irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment
    
    [ Upstream commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ]
    
    The PCI Local Bus Specification 3.0 (section 6.8.1.6) allows modifying the
    low-order bits of the MSI Message DATA register to encode nr_irqs interrupt
    numbers in the log2(nr_irqs) bits for the domain.
    
    The problem arises if the base vector (GICV2m base spi) is not aligned with
    nr_irqs; in this case, the low-order log2(nr_irqs) bits from the base
    vector conflict with the nr_irqs masking, causing the wrong MSI interrupt
    to be identified.
    
    To fix this, use bitmap_find_next_zero_area_off() instead of
    bitmap_find_free_region() to align the initial base vector with nr_irqs.
    
    Signed-off-by: Christian Bruel <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bibo Mao <[email protected]>
Date:   Mon Aug 4 16:19:45 2025 +0800

    irqchip/loongson-eiointc: Route interrupt parsed from bios table
    
    [ Upstream commit 7fb83eb664e9b3a0438dd28859e9f0fd49d4c165 ]
    
    Interrupt controller eiointc routes interrupts to CPU interface IP0 - IP7.
    
    It is currently hard-coded that eiointc routes interrupts to the CPU
    starting from IP1, but it should base that decision on the parent
    interrupt, which is provided by ACPI or DTS.
    
    Retrieve the parent's hardware interrupt number and store it in the
    descriptor of the eointc instance, so that the routing function can utilize
    it for the correct route settings.
    
    [ tglx: Massaged change log ]
    
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Wang <[email protected]>
Date:   Tue Sep 9 20:58:40 2025 +0800

    irqchip/loongson-pch-lpc: Use legacy domain for PCH-LPC IRQ controller
    
    [ Upstream commit c33c43f71bda362b292a6e57ac41b64342dc87b3 ]
    
    On certain Loongson platforms, drivers attempting to request a legacy
    ISA IRQ directly via request_irq() (e.g., IRQ 4) may fail. The
    virtual IRQ descriptor is not fully initialized and lacks a valid irqchip.
    
    This issue does not affect ACPI-enumerated devices described in DSDT,
    as their interrupts are properly mapped via the GSI translation path.
    This indicates the LPC irqdomain itself is functional but is not correctly
    handling direct VIRQ-to-HWIRQ mappings.
    
    The root cause is the use of irq_domain_create_linear(). This API sets
    up a domain for dynamic, on-demand mapping, typically triggered by a GSI
    request. It does not pre-populate the mappings for the legacy VIRQ range
    (0-15). Consequently, if no ACPI device claims a specific GSI
    (e.g., GSI 4), the corresponding VIRQ (e.g., VIRQ 4) is never mapped to
    the LPC domain. A direct call to request_irq(4, ...) then fails because
    the kernel cannot resolve this VIRQ to a hardware interrupt managed by
    the LPC controller.
    
    The PCH-LPC interrupt controller is an i8259-compatible legacy device
    that requires a deterministic, static 1-to-1 mapping for IRQs 0-15 to
    support legacy drivers.
    
    Fix this by replacing irq_domain_create_linear() with
    irq_domain_create_legacy(). This API is specifically designed for such
    controllers. It establishes the required static 1-to-1 VIRQ-to-HWIRQ
    mapping for the entire legacy range (0-15) immediately upon domain
    creation. This ensures that any VIRQ in this range is always resolvable,
    making direct calls to request_irq() for legacy IRQs function correctly.
    
    Signed-off-by: Ming Wang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Inochi Amaoto <[email protected]>
Date:   Mon Aug 11 08:26:32 2025 +0800

    irqchip/sifive-plic: Respect mask state when setting affinity
    
    [ Upstream commit adecf78df945f4c7a1d29111b0002827f487df51 ]
    
    plic_set_affinity() always calls plic_irq_enable(), which clears up the
    priority setting even the interrupt is only masked. This unmasks the
    interrupt unexpectly.
    
    Replace the plic_irq_enable/disable() with plic_irq_toggle() to avoid
    changing the priority setting.
    
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Inochi Amaoto <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Nam Cao <[email protected]> # VisionFive 2
    Tested-by: Chen Wang <[email protected]> # Pioneerbox
    Reviewed-by: Nam Cao <[email protected]>
    Reviewed-by: Chen Wang <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jedrzej Jagielski <[email protected]>
Date:   Mon Aug 4 11:41:56 2025 +0200

    ixgbe: reduce number of reads when getting OROM data
    
    [ Upstream commit 08a1af326a80b88324acd73877db81ae927b1219 ]
    
    Currently, during locating the CIVD section, the ixgbe driver loops
    over the OROM area and at each iteration reads only OROM-datastruct-size
    amount of data. This results in many small reads and is inefficient.
    
    Optimize this by reading the entire OROM bank into memory once before
    entering the loop. This significantly reduces the probing time.
    
    Without this patch probing time may exceed over 25s, whereas with this
    patch applied average time of probe is not greater than 5s.
    
    without the patch:
    [14:12:22] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
    [14:12:25] ixgbe 0000:21:00.0: Multiqueue Enabled: Rx Queue count = 63, Tx Queue count = 63 XDP Queue count = 0
    [14:12:25] ixgbe 0000:21:00.0: 63.012 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x4 link)
    [14:12:26] ixgbe 0000:21:00.0: MAC: 7, PHY: 27, PBA No: N55484-001
    [14:12:26] ixgbe 0000:21:00.0: 20:3a:43:09:3a:12
    [14:12:26] ixgbe 0000:21:00.0: Intel(R) 10 Gigabit Network Connection
    [14:12:50] ixgbe 0000:21:00.0 ens2f0np0: renamed from eth0
    
    with the patch:
    [14:18:18] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
    [14:18:19] ixgbe 0000:21:00.0: Multiqueue Enabled: Rx Queue count = 63, Tx Queue count = 63 XDP Queue count = 0
    [14:18:19] ixgbe 0000:21:00.0: 63.012 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x4 link)
    [14:18:19] ixgbe 0000:21:00.0: MAC: 7, PHY: 27, PBA No: N55484-001
    [14:18:19] ixgbe 0000:21:00.0: 20:3a:43:09:3a:12
    [14:18:19] ixgbe 0000:21:00.0: Intel(R) 10 Gigabit Network Connection
    [14:18:22] ixgbe 0000:21:00.0 ens2f0np0: renamed from eth0
    
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Signed-off-by: Jedrzej Jagielski <[email protected]>
    Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shaurya Rane <[email protected]>
Date:   Mon Aug 25 01:43:32 2025 +0530

    jfs: fix uninitialized waitqueue in transaction manager
    
    [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ]
    
    The transaction manager initialization in txInit() was not properly
    initializing TxBlock[0].waitor waitqueue, causing a crash when
    txEnd(0) is called on read-only filesystems.
    
    When a filesystem is mounted read-only, txBegin() returns tid=0 to
    indicate no transaction. However, txEnd(0) still gets called and
    tries to access TxBlock[0].waitor via tid_to_tblock(0), but this
    waitqueue was never initialized because the initialization loop
    started at index 1 instead of 0.
    
    This causes a 'non-static key' lockdep warning and system crash:
      INFO: trying to register non-static key in txEnd
    
    Fix by ensuring all transaction blocks including TxBlock[0] have
    their waitqueues properly initialized during txInit().
    
    Reported-by: [email protected]
    
    Signed-off-by: Shaurya Rane <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tetsuo Handa <[email protected]>
Date:   Fri Sep 12 23:18:44 2025 +0900

    jfs: Verify inode mode when loading from disk
    
    [ Upstream commit 7a5aa54fba2bd591b22b9b624e6baa9037276986 ]
    
    The inode mode loaded from corrupted disk can be invalid. Do like what
    commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")
    does.
    
    Reported-by: syzbot <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
    Signed-off-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dimitri John Ledkov <[email protected]>
Date:   Sun Oct 26 20:21:00 2025 +0000

    kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
    
    commit d50f21091358b2b29dc06c2061106cdb0f030d03 upstream.
    
    Previously linker scripts would always generate vmlinuz that has sections
    aligned. And thus padded (correct Authenticode calculation) and unpadded
    calculation would be same. As in https://github.com/rhboot/pesign userspace
    tool would produce the same authenticode digest for both of the following
    commands:
    
        pesign --padding --hash --in ./arch/x86_64/boot/bzImage
        pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
    
    The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
    vmlinux.unstripped") added .modinfo section of variable length. Depending
    on kernel configuration it may or may not be aligned.
    
    All userspace signing tooling correctly pads such section to calculation
    spec compliant authenticode digest.
    
    However, if bzImage is not further processed and is attempted to be loaded
    directly by EDK2 firmware, it calculates unpadded Authenticode digest and
    fails to correct accept/reject such kernel builds even when propoer
    Authenticode values are enrolled in db/dbx. One can say EDK2 requires
    aligned/padded kernels in Secureboot.
    
    Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective of
    modinfo contents can be loaded by all existing EDK2 firmware builds.
    
    Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped")
    Cc: [email protected]
    Signed-off-by: Dimitri John Ledkov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Nathan Chancellor <[email protected]>
Date:   Wed Nov 5 15:30:27 2025 -0700

    kbuild: Strip trailing padding bytes from modules.builtin.modinfo
    
    commit a26a6c93edfeee82cb73f55e87d995eea59ddfe8 upstream.
    
    After commit d50f21091358 ("kbuild: align modinfo section for Secureboot
    Authenticode EDK2 compat"), running modules_install with certain
    versions of kmod (such as 29.1 in Ubuntu Jammy) in certain
    configurations may fail with:
    
      depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
    
    The additional padding bytes to ensure .modinfo is aligned within
    vmlinux.unstripped are unexpected by kmod, as this section has always
    just been null-terminated strings.
    
    Strip the trailing padding bytes from modules.builtin.modinfo after it
    has been extracted from vmlinux.unstripped to restore the format that
    kmod expects while keeping .modinfo aligned within vmlinux.unstripped to
    avoid regressing the Authenticode calculation fix for EDK2.
    
    Cc: [email protected]
    Fixes: d50f21091358 ("kbuild: align modinfo section for Secureboot Authenticode EDK2 compat")
    Reported-by: Omar Sandoval <[email protected]>
    Reported-by: Samir M <[email protected]>
    Reported-by: Venkat Rao Bagalkote <[email protected]>
    Closes: https://lore.kernel.org/[email protected]/
    Tested-by: Omar Sandoval <[email protected]>
    Tested-by: Samir M <[email protected]>
    Tested-by: Venkat Rao Bagalkote <[email protected]>
    Reviewed-by: Nicolas Schier <[email protected]>
    Link: https://patch.msgid.link/20251105-kbuild-fix-builtin-modinfo-for-kmod-v1-1-b419d8ad4606@kernel.org
    Signed-off-by: Nathan Chancellor <[email protected]>
    [nathan: Apply to scripts/Makefile.vmlinux_o, location of
             modules.builtin.modinfo rule prior to 39cfd5b12160]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Oct 6 14:33:42 2025 +0200

    kbuild: uapi: Strip comments before size type check
    
    [ Upstream commit 66128f4287b04aef4d4db9bf5035985ab51487d5 ]
    
    On m68k, check_sizetypes in headers_check reports:
    
        ./usr/include/asm/bootinfo-amiga.h:17: found __[us]{8,16,32,64} type without #include <linux/types.h>
    
    This header file does not use any of the Linux-specific integer types,
    but merely refers to them from comments, so this is a false positive.
    As of commit c3a9d74ee413bdb3 ("kbuild: uapi: upgrade check_sizetypes()
    warning to error"), this check was promoted to an error, breaking m68k
    all{mod,yes}config builds.
    
    Fix this by stripping simple comments before looking for Linux-specific
    integer types.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Link: https://patch.msgid.link/949f096337e28d50510e970ae3ba3ec9c1342ec0.1759753998.git.geert@linux-m68k.org
    [nathan: Adjust comment and remove unnecessary escaping from slashes in
             regex]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Thu Aug 21 17:40:37 2025 +0200

    kselftest/arm64: tpidr2: Switch to waitpid() over wait4()
    
    [ Upstream commit 61a3cf7934b6da3c926cd9961860dd94eb7192ba ]
    
    wait4() is deprecated, non-standard and about to be removed from nolibc.
    
    Switch to the equivalent waitpid() call.
    
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Acked-by: Catalin Marinas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Namjae Jeon <[email protected]>
Date:   Thu Sep 25 21:12:05 2025 +0900

    ksmbd: use sock_create_kern interface to create kernel socket
    
    [ Upstream commit 3677ca67b9791481af16d86e47c3c7d1f2442f95 ]
    
    we should use sock_create_kern() if the socket resides in kernel space.
    
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Mon Sep 8 09:03:38 2025 +0200

    kunit: Enable PCI on UML without triggering WARN()
    
    [ Upstream commit 031cdd3bc3f369553933c1b0f4cb18000162c8ff ]
    
    Various KUnit tests require PCI infrastructure to work. All normal
    platforms enable PCI by default, but UML does not. Enabling PCI from
    .kunitconfig files is problematic as it would not be portable. So in
    commit 6fc3a8636a7b ("kunit: tool: Enable virtio/PCI by default on UML")
    PCI was enabled by way of CONFIG_UML_PCI_OVER_VIRTIO=y. However
    CONFIG_UML_PCI_OVER_VIRTIO requires additional configuration of
    CONFIG_UML_PCI_OVER_VIRTIO_DEVICE_ID or will otherwise trigger a WARN() in
    virtio_pcidev_init(). However there is no one correct value for
    UML_PCI_OVER_VIRTIO_DEVICE_ID which could be used by default.
    
    This warning is confusing when debugging test failures.
    
    On the other hand, the functionality of CONFIG_UML_PCI_OVER_VIRTIO is not
    used at all, given that it is completely non-functional as indicated by
    the WARN() in question. Instead it is only used as a way to enable
    CONFIG_UML_PCI which itself is not directly configurable.
    
    Instead of going through CONFIG_UML_PCI_OVER_VIRTIO, introduce a custom
    configuration option which enables CONFIG_UML_PCI without triggering
    warnings or building dead code.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Tue Sep 16 08:15:46 2025 +0200

    kunit: Extend kconfig help text for KUNIT_UML_PCI
    
    commit 285cae57a51664cc94e85de0ff994f9965b3aca8 upstream.
    
    Checkpatch.pl expects at least 4 lines of help text.
    
    Extend the help text to make checkpatch.pl happy.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 031cdd3bc3f3 ("kunit: Enable PCI on UML without triggering WARN()")
    Suggested-by: Shuah Khan <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Florian Schmaus <[email protected]>
Date:   Fri Oct 17 11:28:14 2025 +0200

    kunit: test_dev_action: Correctly cast 'priv' pointer to long*
    
    [ Upstream commit 2551a1eedc09f5a86f94b038dc1bb16855c256f1 ]
    
    The previous implementation incorrectly assumed the original type of
    'priv' was void**, leading to an unnecessary and misleading
    cast. Correct the cast of the 'priv' pointer in test_dev_action() to
    its actual type, long*, removing an unnecessary cast.
    
    As an additional benefit, this fixes an out-of-bounds CHERI fault on
    hardware with architectural capabilities. The original implementation
    tried to store a capability-sized pointer using the priv
    pointer. However, the priv pointer's capability only granted access to
    the memory region of its original long type, leading to a bounds
    violation since the size of a long is smaller than the size of a
    capability. This change ensures that the pointer usage respects the
    capabilities' bounds.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Florian Schmaus <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Horatiu Vultur <[email protected]>
Date:   Wed Nov 5 08:49:55 2025 +0100

    lan966x: Fix sleeping in atomic context
    
    [ Upstream commit 0216721ce71252f60d89af49c8dff613358058d3 ]
    
    The following warning was seen when we try to connect using ssh to the device.
    
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575
    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear
    preempt_count: 1, expected: 0
    INFO: lockdep is turned off.
    CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE
    Tainted: [W]=WARN
    Hardware name: Generic DT based system
    Call trace:
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x7c/0xac
     dump_stack_lvl from __might_resched+0x16c/0x2b0
     __might_resched from __mutex_lock+0x64/0xd34
     __mutex_lock from mutex_lock_nested+0x1c/0x24
     mutex_lock_nested from lan966x_stats_get+0x5c/0x558
     lan966x_stats_get from dev_get_stats+0x40/0x43c
     dev_get_stats from dev_seq_printf_stats+0x3c/0x184
     dev_seq_printf_stats from dev_seq_show+0x10/0x30
     dev_seq_show from seq_read_iter+0x350/0x4ec
     seq_read_iter from seq_read+0xfc/0x194
     seq_read from proc_reg_read+0xac/0x100
     proc_reg_read from vfs_read+0xb0/0x2b0
     vfs_read from ksys_read+0x6c/0xec
     ksys_read from ret_fast_syscall+0x0/0x1c
    Exception stack(0xf0b11fa8 to 0xf0b11ff0)
    1fa0:                   00000001 00001000 00000008 be9048d8 00001000 00000001
    1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001
    1fe0: 0005404c be9048c0 00018684 b6ec2cd8
    
    It seems that we are using a mutex in a atomic context which is wrong.
    Change the mutex with a spinlock.
    
    Fixes: 12c2d0a5b8e2 ("net: lan966x: add ethtool configuration and statistics")
    Signed-off-by: Horatiu Vultur <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nathan Chancellor <[email protected]>
Date:   Mon Nov 3 12:11:24 2025 -0700

    lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC
    
    commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream.
    
    Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with
    clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o
    for GCC unconditionally because clang-min-version will always evaluate
    to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying
    the workaround for GCC, which is only needed for clang-17 and older.
    
    Cc: [email protected]
    Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Link: https://lore.kernel.org/r/20251103-curve25519-hacl64-fix-kasan-workaround-v2-1-ab581cbd8035@kernel.org
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Andrii Nakryiko <[email protected]>
Date:   Mon Oct 20 13:36:43 2025 -0700

    libbpf: Fix powerpc's stack register definition in bpf_tracing.h
    
    [ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ]
    
    retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to
    wrong definition of PT_REGS_SP() macro. Looking at powerpc's
    implementation of stack unwinding in perf_callchain_user_64() clearly
    shows that stack pointer register is gpr[1].
    
    Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this.
    
      [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log
    
    Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Reviewed-by: Naveen N Rao (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiawei Zhao <[email protected]>
Date:   Wed Aug 27 05:31:27 2025 +0000

    libbpf: Fix USDT SIB argument handling causing unrecognized register error
    
    [ Upstream commit 758acb9ccfdbf854b55abaceaf1f3f229cde3d19 ]
    
    On x86-64, USDT arguments can be specified using Scale-Index-Base (SIB)
    addressing, e.g. "1@-96(%rbp,%rax,8)". The current USDT implementation
    in libbpf cannot parse this format, causing `bpf_program__attach_usdt()`
    to fail with -ENOENT (unrecognized register).
    
    This patch fixes this by implementing the necessary changes:
    - add correct handling for SIB-addressed arguments in `bpf_usdt_arg`.
    - add adaptive support to `__bpf_usdt_arg_type` and
      `__bpf_usdt_arg_spec` to represent SIB addressing parameters.
    
    Signed-off-by: Jiawei Zhao <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Nov 13 15:37:49 2025 -0500

    Linux 6.17.8
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Slade Watkins <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Jeffrin Jose T <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Tested-by: Dileep Malepu <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Tiezhu Yang <[email protected]>
Date:   Thu Oct 2 22:39:35 2025 +0800

    LoongArch: Handle new atomic instructions for probes
    
    [ Upstream commit db740f5689e61f2e75b73e5c8e7c985a3b4bc045 ]
    
    The atomic instructions sc.q, llacq.{w/d}, screl.{w/d} were newly added
    in the LoongArch Reference Manual v1.10, it is necessary to handle them
    in insns_not_supported() to avoid putting a breakpoint in the middle of
    a ll/sc atomic sequence, otherwise it will loop forever for kprobes and
    uprobes.
    
    Signed-off-by: Tiezhu Yang <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Söderlund <[email protected]>
Date:   Thu Aug 28 18:06:45 2025 +0200

    media: adv7180: Add missing lock in suspend callback
    
    [ Upstream commit 878c496ac5080f94a93a9216a8f70cfd67ace8c9 ]
    
    The adv7180_set_power() utilizes adv7180_write() which in turn requires
    the state mutex to be held, take it before calling adv7180_set_power()
    to avoid tripping a lockdep_assert_held().
    
    Signed-off-by: Niklas Söderlund <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Söderlund <[email protected]>
Date:   Thu Aug 28 18:06:52 2025 +0200

    media: adv7180: Do not write format to device in set_fmt
    
    [ Upstream commit 46c1e7814d1c3310ef23c01ed1a582ef0c8ab1d2 ]
    
    The .set_fmt callback should not write the new format directly do the
    device, it should only store it and have it applied by .s_stream.
    
    The .s_stream callback already calls adv7180_set_field_mode() so it's
    safe to remove programming of the device and just store the format and
    have .s_stream apply it.
    
    Signed-off-by: Niklas Söderlund <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Söderlund <[email protected]>
Date:   Thu Aug 28 18:06:54 2025 +0200

    media: adv7180: Only validate format in querystd
    
    [ Upstream commit 91c5d7c849273d14bc4bae1b92666bdb5409294a ]
    
    The .querystd callback should not program the device with the detected
    standard, it should only report the standard to user-space. User-space
    may then use .s_std to set the standard, if it wants to use it.
    
    All that is required of .querystd is to setup the auto detection of
    standards and report its findings.
    
    While at it add some documentation on why this can't happen while
    streaming and improve the error handling using a scoped guard.
    
    Signed-off-by: Niklas Söderlund <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Laurent Pinchart <[email protected]>
Date:   Sun Aug 10 04:29:56 2025 +0300

    media: amphion: Delete v4l2_fh synchronously in .release()
    
    [ Upstream commit 19fb9c5b815f70eb90d5b545f65b83bc9c490ecd ]
    
    The v4l2_fh initialized and added in vpu_v4l2_open() is delete and
    cleaned up when the last reference to the vpu_inst is released. This may
    happen later than at vpu_v4l2_close() time.
    
    Not deleting and cleaning up the v4l2_fh when closing the file handle to
    the video device is not ideal, as the v4l2_fh will still be present in
    the video device's fh_list, and will store a copy of events queued to
    the video device. There may also be other side effects of keeping alive
    an object that represents an open file handle after the file handle is
    closed.
    
    The v4l2_fh instance is embedded in the vpu_inst structure, and is
    accessed in two different ways:
    
    - in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2
      events to the file handle ; and
    
    - through the driver to access the v4l2_fh.m2m_ctx pointer.
    
    The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and
    v4l2_fh_exit(). It is set to NULL by the driver when closing the file
    handle, in vpu_v4l2_close().
    
    The vpu_notify_eos() and vpu_notify_source_change() functions are called
    in vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change()
    respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is
    therefore a guarantee that no new event will be queued to the v4l2_fh
    after vpu_v4l2_close() destroys the m2m_ctx.
    
    The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(),
    which is guaranteed to be called for all queued buffers when
    vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called
    later.
    
    It is therefore safe to assume that the driver will not touch the
    v4l2_fh, except to check the m2m_ctx pointer, after vpu_v4l2_close()
    destroys the m2m_ctx. We can safely delete and cleanup the v4l2_fh
    synchronously in vpu_v4l2_close().
    
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Ming Qian <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chelsy Ratnawat <[email protected]>
Date:   Wed Aug 6 23:09:36 2025 -0700

    media: fix uninitialized symbol warnings
    
    [ Upstream commit b4c441310c3baaa7c39a5457e305ca93c7a0400d ]
    
    Initialize variables to fix these smatch warnings
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'protocol'.
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'scancode'.
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'toggle'.
    drivers/media/tuners/xc4000.c:1102 xc_debug_dump() error: uninitialized
    symbol 'adc_envelope'.
    drivers/media/tuners/xc4000.c:1108 xc_debug_dump() error: uninitialized
    symbol 'lock_status'.
    drivers/media/tuners/xc4000.c:1123 xc_debug_dump() error: uninitialized
    symbol 'frame_lines'.
    drivers/media/tuners/xc4000.c:1127 xc_debug_dump() error: uninitialized
    symbol 'quality'.
    drivers/media/tuners/xc5000.c:645 xc_debug_dump() error: uninitialized
    symbol 'adc_envelope'.
    drivers/media/tuners/xc5000.c:651 xc_debug_dump() error: uninitialized
    symbol 'lock_status'.
    drivers/media/tuners/xc5000.c:665 xc_debug_dump() error: uninitialized
    symbol 'frame_lines'.
    drivers/media/tuners/xc5000.c:668 xc_debug_dump() error: uninitialized
    symbol 'quality'.
    drivers/media/tuners/xc5000.c:671 xc_debug_dump() error: uninitialized
    symbol 'snr'.
    drivers/media/tuners/xc5000.c:674 xc_debug_dump() error: uninitialized
    symbol 'totalgain'.
    
    Signed-off-by: Chelsy Ratnawat <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    [hverkuil: dropped ' = 0' from rc in ir-kbd-i2c.c, not needed]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mehdi Djait <[email protected]>
Date:   Mon Jul 14 15:23:56 2025 +0200

    media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for VIDEO_CAMERA_SENSOR
    
    [ Upstream commit 2d240b124cc9df62ccccee6054bc3d1d19018758 ]
    
    Both ACPI and DT-based systems are required to obtain the external
    camera sensor clock using the new devm_v4l2_sensor_clk_get() helper
    function.
    
    Ensure a dependency on HAVE_CLK when config VIDEO_CAMERA_SENSOR is
    enabled.
    
    Signed-off-by: Mehdi Djait <[email protected]>
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vladimir Zapolskiy <[email protected]>
Date:   Sat Aug 23 16:22:06 2025 +0300

    media: i2c: og01a1b: Specify monochrome media bus format instead of Bayer
    
    [ Upstream commit bfbd5aa5347fbd11ade188b316b800bfb27d9e22 ]
    
    The OmniVision OG01A1B image sensor is a monochrome sensor, it supports
    8-bit and 10-bit RAW output formats only.
    
    That said the planar greyscale Y8/Y10 media formats are more appropriate
    for the sensor instead of the originally and arbitrary selected SGRBG one,
    since there is no red, green or blue color components.
    
    Signed-off-by: Vladimir Zapolskiy <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tetsuo Handa <[email protected]>
Date:   Thu Jul 17 23:21:55 2025 +0900

    media: imon: make send_packet() more robust
    
    [ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ]
    
    syzbot is reporting that imon has three problems which result in
    hung tasks due to forever holding device lock [1].
    
    First problem is that when usb_rx_callback_intf0() once got -EPROTO error
    after ictx->dev_present_intf0 became true, usb_rx_callback_intf0()
    resubmits urb after printk(), and resubmitted urb causes
    usb_rx_callback_intf0() to again get -EPROTO error. This results in
    printk() flooding (RCU stalls).
    
    Alan Stern commented [2] that
    
      In theory it's okay to resubmit _if_ the driver has a robust
      error-recovery scheme (such as giving up after some fixed limit on the
      number of errors or after some fixed time has elapsed, perhaps with a
      time delay to prevent a flood of errors).  Most drivers don't bother to
      do this; they simply give up right away.  This makes them more
      vulnerable to short-term noise interference during USB transfers, but in
      reality such interference is quite rare.  There's nothing really wrong
      with giving up right away.
    
    but imon has a poor error-recovery scheme which just retries forever;
    this behavior should be fixed.
    
    Since I'm not sure whether it is safe for imon users to give up upon any
    error code, this patch takes care of only union of error codes chosen from
    modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.
    ir_toy, mceusb and igorplugusb).
    
    Second problem is that when usb_rx_callback_intf0() once got -EPROTO error
    before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always
    resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge
    hardware after early callbacks"). Move the ictx->dev_present_intf0 test
    introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes
    until intf configured") to immediately before imon_incoming_packet(), or
    the first problem explained above happens without printk() flooding (i.e.
    hung task).
    
    Third problem is that when usb_rx_callback_intf0() is not called for some
    reason (e.g. flaky hardware; the reproducer for this problem sometimes
    prevents usb_rx_callback_intf0() from being called),
    wait_for_completion_interruptible() in send_packet() never returns (i.e.
    hung task). As a workaround for such situation, change send_packet() to
    wait for completion with timeout of 10 seconds.
    
    Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1]
    Link: https://lkml.kernel.org/r/[email protected] [2]
    Signed-off-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Sean Young <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Laurent Pinchart <[email protected]>
Date:   Fri Aug 22 03:27:29 2025 +0300

    media: imx-mipi-csis: Only set clock rate when specified in DT
    
    [ Upstream commit 65673c6e33cf46f220cc5774166b373b3c087739 ]
    
    The imx-mipi-csis driver sets the rate of the wrap clock to the value
    specified in the device tree's "clock-frequency" property, and defaults
    to 166 MHz otherwise. This is a historical mistake, as clock rate
    selection should have been left to the assigned-clock-rates property.
    
    Honouring the clock-frequency property can't be removed without breaking
    backwards compatibility, and the corresponding code isn't very
    intrusive. The 166 MHz default, on the other hand, prevents
    configuration of the clock rate through assigned-clock-rates, as the
    driver immediately overwrites the rate. This behaviour is confusing and
    has cost debugging time.
    
    There is little value in a 166 MHz default. All mainline device tree
    sources that enable the CSIS specify a clock-frequency explicitly, and
    the default wrap clock configuration on supported platforms is at least
    as high as 166 MHz. Drop the default, and only set the clock rate
    manually when the clock-frequency property is specified.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sakari Ailus <[email protected]>
Date:   Wed May 21 11:06:16 2025 +0300

    media: ipu6: isys: Set embedded data type correctly for metadata formats
    
    [ Upstream commit f5a2826cd50c6fd1af803812d1d910a64ae8e0a1 ]
    
    The IPU6 ISYS driver supported metadata formats but was missing correct
    embedded data type in the receiver configuration. Add it now.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Richard Leitner <[email protected]>
Date:   Thu Aug 14 00:24:50 2025 +0300

    media: nxp: imx8-isi: Fix streaming cleanup on release
    
    [ Upstream commit 47773031a148ad7973b809cc7723cba77eda2b42 ]
    
    The current implementation unconditionally calls
    mxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This can
    lead to situations where any release call (like from a simple
    "v4l2-ctl -l") may release a currently streaming queue when called on
    such a device.
    
    This is reproducible on an i.MX8MP board by streaming from an ISI
    capture device using gstreamer:
    
            gst-launch-1.0 -v v4l2src device=/dev/videoX ! \
                video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \
                fakesink
    
    While this stream is running, querying the caps of the same device
    provokes the error state:
    
            v4l2-ctl -l -d /dev/videoX
    
    This results in the following trace:
    
    [  155.452152] ------------[ cut here ]------------
    [  155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]
    [  157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6
    [  157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT
    [  157.064369] Hardware name: imx8mp_board_01 (DT)
    [  157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]
    [  157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi]
    [  157.087126] sp : ffff800080003ee0
    [  157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000
    [  157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50
    [  157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000
    [  157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000
    [  157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000
    [  157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    [  157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38
    [  157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000
    [  157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000
    [  157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200
    [  157.161850] Call trace:
    [  157.164296]  mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)
    [  157.170319]  __handle_irq_event_percpu+0x58/0x218
    [  157.175029]  handle_irq_event+0x54/0xb8
    [  157.178867]  handle_fasteoi_irq+0xac/0x248
    [  157.182968]  handle_irq_desc+0x48/0x68
    [  157.186723]  generic_handle_domain_irq+0x24/0x38
    [  157.191346]  gic_handle_irq+0x54/0x120
    [  157.195098]  call_on_irq_stack+0x24/0x30
    [  157.199027]  do_interrupt_handler+0x88/0x98
    [  157.203212]  el0_interrupt+0x44/0xc0
    [  157.206792]  __el0_irq_handler_common+0x18/0x28
    [  157.211328]  el0t_64_irq_handler+0x10/0x20
    [  157.215429]  el0t_64_irq+0x198/0x1a0
    [  157.219009] ---[ end trace 0000000000000000 ]---
    
    Address this issue by moving the streaming preparation and cleanup to
    the vb2 .prepare_streaming() and .unprepare_streaming() operations. This
    also simplifies the driver by allowing direct usage of the
    vb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal of
    the manual cleanup from mxc_isi_video_release().
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Richard Leitner <[email protected]>
    Co-developed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Tested-by: Richard Leitner <[email protected]> # i.MX8MP
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hao Yao <[email protected]>
Date:   Fri Apr 25 12:33:25 2025 +0800

    media: ov08x40: Fix the horizontal flip control
    
    [ Upstream commit c7df6f339af94689fdc433887f9fbb480bf8a4ed ]
    
    The datasheet of ov08x40 doesn't match the hardware behavior.
    0x3821[2] == 1 is the original state and 0 the horizontal flip enabled.
    
    Signed-off-by: Hao Yao <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Tested-by: Hans de Goede <[email protected]> # ThinkPad X1 Carbon Gen 12 & Gen 13
    Reviewed-by: Stanislaw Gruszka <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Laurent Pinchart <[email protected]>
Date:   Sun Aug 10 04:29:54 2025 +0300

    media: pci: ivtv: Don't create fake v4l2_fh
    
    [ Upstream commit cc6e8d1ccea792d8550428e0831e3a35b0ccfddc ]
    
    The ivtv driver has a structure named ivtv_open_id that models an open
    file handle for the device. It embeds a v4l2_fh instance for file
    handles that correspond to a V4L2 video device, and stores a pointer to
    that v4l2_fh in struct ivtv_stream to identify which open file handle
    owns a particular stream.
    
    In addition to video devices, streams can be owned by ALSA PCM devices.
    Those devices do not make use of the v4l2_fh instance for obvious
    reasons, but the snd_ivtv_pcm_capture_open() function still initializes
    a "fake" v4l2_fh for the sole purpose of using it as an open file handle
    identifier. The v4l2_fh is not properly destroyed when the ALSA PCM
    device is closed, leading to possible resource leaks.
    
    Fortunately, the v4l2_fh instance pointed to by ivtv_stream is not
    accessed, only the pointer value is used for comparison. Replace it with
    a pointer to the ivtv_open_id structure that embeds the v4l2_fh, and
    don't initialize the v4l2_fh for ALSA PCM devices.
    
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Martin Tůma <[email protected]>
Date:   Tue Aug 26 18:28:29 2025 +0200

    media: pci: mgb4: Fix timings comparison in VIDIOC_S_DV_TIMINGS
    
    [ Upstream commit 0750649b528ff18d1d68aecb45b34ec22d5ab778 ]
    
    Compare the whole v4l2_bt_timings struct, not just the width/height when
    setting new timings. Timings with the same resolution and different
    pixelclock can now be properly set.
    
    Signed-off-by: Martin Tůma <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Loic Poulain <[email protected]>
Date:   Tue Jul 8 10:32:19 2025 +0200

    media: qcom: camss: csiphy-3ph: Add CSIPHY 2ph DPHY v2.0.1 init sequence
    
    [ Upstream commit ce63fbdf849f52584d9b5d9a4cc23cbc88746c30 ]
    
    This is the CSI PHY version found in QCS2290/QCM2290 SoCs.
    The table is extracted from downstream camera driver.
    
    Signed-off-by: Loic Poulain <[email protected]>
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Signed-off-by: Bryan O'Donoghue <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Qianfeng Rong <[email protected]>
Date:   Wed Aug 27 20:39:13 2025 +0800

    media: redrat3: use int type to store negative error codes
    
    [ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ]
    
    Change "ret" from u8 to int type in redrat3_enable_detector() to store
    negative error codes or zero returned by redrat3_send_cmd() and
    usb_submit_urb() - this better aligns with the coding standards and
    maintains code consistency.
    
    No effect on runtime.
    
    Signed-off-by: Qianfeng Rong <[email protected]>
    Signed-off-by: Sean Young <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ricardo Ribalda <[email protected]>
Date:   Tue Oct 21 10:36:17 2025 +0000

    media: uvcvideo: Use heuristic to find stream entity
    
    commit 758dbc756aad429da11c569c0d067f7fd032bcf7 upstream.
    
    Some devices, like the Grandstream GUV3100 webcam, have an invalid UVC
    descriptor where multiple entities share the same ID, this is invalid
    and makes it impossible to make a proper entity tree without heuristics.
    
    We have recently introduced a change in the way that we handle invalid
    entities that has caused a regression on broken devices.
    
    Implement a new heuristic to handle these devices properly.
    
    Reported-by: Angel4005 <[email protected]>
    Closes: https://lore.kernel.org/linux-media/CAOzBiVuS7ygUjjhCbyWg-KiNx+HFTYnqH5+GJhd6cYsNLT=DaA@mail.gmail.com/
    Fixes: 0e2ee70291e6 ("media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID")
    Cc: [email protected]
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paul Kocialkowski <[email protected]>
Date:   Thu Aug 28 15:49:18 2025 +0200

    media: verisilicon: Explicitly disable selection api ioctls for decoders
    
    [ Upstream commit 73d50aa92f28ee8414fbfde011974fce970b82cc ]
    
    Call the dedicated v4l2_disable_ioctl helper instead of manually
    checking whether the current context is an encoder for the selection
    api ioctls.
    
    Signed-off-by: Paul Kocialkowski <[email protected]>
    Reviewed-by: Nicolas Dufresne <[email protected]>
    Signed-off-by: Nicolas Dufresne <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Marek Szyprowski <[email protected]>
Date:   Thu Oct 23 16:26:34 2025 +0200

    media: videobuf2: forbid remove_bufs when legacy fileio is active
    
    commit 27afd6e066cfd80ddbe22a4a11b99174ac89cced upstream.
    
    vb2_ioctl_remove_bufs() call manipulates queue internal buffer list,
    potentially overwriting some pointers used by the legacy fileio access
    mode. Forbid that ioctl when fileio is active to protect internal queue
    state between subsequent read/write calls.
    
    CC: [email protected]
    Fixes: a3293a85381e ("media: v4l2: Add REMOVE_BUFS ioctl")
    Reported-by: Shuangpeng Bai <[email protected]>
    Closes: https://lore.kernel.org/linux-media/[email protected]/
    Signed-off-by: Marek Szyprowski <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Alexander Usyskin <[email protected]>
Date:   Thu Sep 18 16:04:32 2025 +0300

    mei: make a local copy of client uuid in connect
    
    [ Upstream commit bb29fc32ae56393269d8fe775159fd59e45682d1 ]
    
    Connect ioctl has the same memory for in and out parameters.
    Copy in parameter (client uuid) to the local stack to avoid it be
    overwritten by out parameters fill.
    
    Signed-off-by: Alexander Usyskin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiayi Li <[email protected]>
Date:   Mon Aug 4 10:48:25 2025 +0800

    memstick: Add timeout to prevent indefinite waiting
    
    [ Upstream commit b65e630a55a490a0269ab1e4a282af975848064c ]
    
    Add timeout handling to wait_for_completion calls in memstick_set_rw_addr()
    and memstick_alloc_card() to prevent indefinite blocking in case of
    hardware or communication failures.
    
    Signed-off-by: Jiayi Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bastien Curutchet <[email protected]>
Date:   Wed Aug 20 16:21:13 2025 +0200

    mfd: core: Increment of_node's refcount before linking it to the platform device
    
    [ Upstream commit 5f4bbee069836e51ed0b6d7e565a292f070ababc ]
    
    When an MFD device is added, a platform_device is allocated. If this
    device is linked to a DT description, the corresponding OF node is linked
    to the new platform device but the OF node's refcount isn't incremented.
    As of_node_put() is called during the platform device release, it leads
    to a refcount underflow.
    
    Call of_node_get() to increment the OF node's refcount when the node is
    linked to the newly created platform device.
    
    Signed-off-by: Bastien Curutchet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Charles Keepax <[email protected]>
Date:   Wed Sep 3 10:45:48 2025 +0100

    mfd: cs42l43: Move IRQ enable/disable to encompass force suspend
    
    [ Upstream commit 62aec8a0a5b61f149bbe518c636e38e484812499 ]
    
    As pm_runtime_force_suspend() will force the device state to suspend,
    the driver needs to ensure no IRQ handlers are currently running. If not
    those handlers may find they are now running on suspended hardware
    despite holding a PM runtime reference. disable_irq() will sync any
    currently running handlers, so move the IRQ disabling to cover the whole
    of the forced suspend state to avoid such race conditions.
    
    Signed-off-by: Charles Keepax <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jens Kehne <[email protected]>
Date:   Mon Aug 4 15:37:54 2025 +0200

    mfd: da9063: Split chip variant reading in two bus transactions
    
    [ Upstream commit 9ac4890ac39352ccea132109e32911495574c3ec ]
    
    We observed the initial probe of the da9063 failing in
    da9063_get_device_type in about 30% of boots on a Xilinx ZynqMP based
    board. The problem originates in da9063_i2c_blockreg_read, which uses
    a single bus transaction to turn the register page and then read a
    register. On the bus, this should translate to a write to register 0,
    followed by a read to the target register, separated by a repeated
    start. However, we found that after the write to register 0, the
    controller sometimes continues directly with the register address of
    the read request, without sending the chip address or a repeated start
    in between, which makes the read request invalid.
    
    To fix this, separate turning the page and reading the register into
    two separate transactions. This brings the initialization code in line
    with the rest of the driver, which uses register maps (which to my
    knowledge do not use repeated starts after turning the page). This has
    been included in our kernel for several months and was recently
    included in a shipped product. For us, it reliably fixes the issue,
    and we have not observed any new issues.
    
    While the underlying problem is probably with the i2c controller or
    its driver, I still propose a change here in the interest of
    robustness: First, I'm not sure this issue can be fixed on the
    controller side, since there are other issues related to repeated
    start which can't (AR# 60695, AR# 61664). Second, similar problems
    might exist with other controllers.
    
    Signed-off-by: Jens Kehne <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilpo Järvinen <[email protected]>
Date:   Mon Sep 15 14:29:36 2025 +0300

    mfd: intel-lpss: Add Intel Wildcat Lake LPSS PCI IDs
    
    [ Upstream commit c91a0e4e549d0457c61f2199fcd84d699400bee1 ]
    
    Add Intel Wildcat Lake PCI IDs.
    
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Acked-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heijligen, Thomas <[email protected]>
Date:   Thu Jul 31 14:45:00 2025 +0000

    mfd: kempld: Switch back to earlier ->init() behavior
    
    commit 309e65d151ab9be1e7b01d822880cd8c4e611dff upstream.
    
    Commit 9e36775c22c7 ("mfd: kempld: Remove custom DMI matching code")
    removes the ability to load the driver if no matching system DMI data
    is found. Before this commit the driver could be loaded using
    alternative methods such as ACPI or `force_device_id` in the absence
    of a matching system DMI entry.
    
    Restore this ability while keeping the refactored
    `platform_device_info` table.
    
    Signed-off-by: Thomas Heijligen <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Cc: Michael Brunner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Janne Grunau <[email protected]>
Date:   Thu Aug 28 16:01:37 2025 +0200

    mfd: macsmc: Add "apple,t8103-smc" compatible
    
    [ Upstream commit 9b959e525fa7e8518e57554b6e17849942938dfc ]
    
    After discussion with the devicetree maintainers we agreed to not extend
    lists with the generic compatible "apple,smc" anymore [1]. Use
    "apple,t8103-smc" as base compatible as it is the SoC the driver and
    bindings were written for.
    
    [1]: https://lore.kernel.org/asahi/[email protected]/
    
    Signed-off-by: Janne Grunau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Thu Aug 7 09:19:28 2025 +0200

    mfd: madera: Work around false-positive -Wininitialized warning
    
    [ Upstream commit 364752aa0c6ab0a06a2d5bfdb362c1ca407f1a30 ]
    
    clang-21 warns about one uninitialized variable getting dereferenced
    in madera_dev_init:
    
    drivers/mfd/madera-core.c:739:10: error: variable 'mfd_devs' is uninitialized when used here [-Werror,-Wuninitialized]
      739 |                               mfd_devs, n_devs,
          |                               ^~~~~~~~
    drivers/mfd/madera-core.c:459:33: note: initialize the variable 'mfd_devs' to silence this warning
      459 |         const struct mfd_cell *mfd_devs;
          |                                        ^
          |                                         = NULL
    
    The code is actually correct here because n_devs is only nonzero
    when mfd_devs is a valid pointer, but this is impossible for the
    compiler to see reliably.
    
    Change the logic to check for the pointer as well, to make this easier
    for the compiler to follow.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Richard Fitzgerald <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Stuebner <[email protected]>
Date:   Mon Aug 4 15:07:24 2025 +0200

    mfd: qnap-mcu: Handle errors returned from qnap_mcu_write
    
    [ Upstream commit bf2de43060d528e52e372c63182a94b95c80d305 ]
    
    qnap_mcu_write can return errors and those were not checked before.
    So do that now.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Stuebner <[email protected]>
Date:   Mon Aug 4 15:07:23 2025 +0200

    mfd: qnap-mcu: Include linux/types.h in qnap-mcu.h shared header
    
    [ Upstream commit 5e1c88679174e4bfe5d152060b06d370bd85de80 ]
    
    Relying on other components to include those basic types is unreliable
    and may cause compile errors like:
    
    ../include/linux/mfd/qnap-mcu.h:13:9: error: unknown type name ‘u32’
       13 |         u32 baud_rate;
          |         ^~~
    ../include/linux/mfd/qnap-mcu.h:17:9: error: unknown type name ‘bool’
       17 |         bool usb_led;
          |         ^~~~
    
    So make sure, the types used in the header are available.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ioana Ciornei <[email protected]>
Date:   Mon Jul 7 18:31:20 2025 +0300

    mfd: simple-mfd-i2c: Add compatible strings for Layerscape QIXIS FPGA
    
    [ Upstream commit 81a2c31257411296862487aaade98b7d9e25dc72 ]
    
    The QIXIS FPGA found on Layerscape boards such as LX2160AQDS, LS1028AQDS
    etc deals with power-on-reset timing, muxing etc. Use the simple-mfd-i2c
    as its core driver by adding its compatible string (already found in
    some dt files). By using the simple-mfd-i2c driver, any child device
    will have access to the i2c regmap created by it.
    
    Signed-off-by: Ioana Ciornei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexander Stein <[email protected]>
Date:   Fri Jul 25 09:11:50 2025 +0200

    mfd: stmpe-i2c: Add missing MODULE_LICENSE
    
    [ Upstream commit 00ea54f058cd4cb082302fe598cfe148e0aadf94 ]
    
    This driver is licensed GPL-2.0-only, so add the corresponding module flag.
    
    Signed-off-by: Alexander Stein <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexander Stein <[email protected]>
Date:   Fri Jul 25 09:07:48 2025 +0200

    mfd: stmpe: Remove IRQ domain upon removal
    
    [ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ]
    
    The IRQ domain is (optionally) added during stmpe_probe, but never removed.
    Add the call to stmpe_remove.
    
    Signed-off-by: Alexander Stein <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Parthiban Veerasooran <[email protected]>
Date:   Thu Aug 28 17:15:49 2025 +0530

    microchip: lan865x: add ndo_eth_ioctl handler to enable PHY ioctl support
    
    [ Upstream commit 34c21e91192aa1ff66f9d6cef8132717840d04e6 ]
    
    Introduce support for standard MII ioctl operations in the LAN865x
    Ethernet driver by implementing the .ndo_eth_ioctl callback. This allows
    PHY-related ioctl commands to be handled via phy_do_ioctl_running() and
    enables support for ethtool and other user-space tools that rely on ioctl
    interface to perform PHY register access using commands like SIOCGMIIREG
    and SIOCSMIIREG.
    
    This feature enables improved diagnostics and PHY configuration
    capabilities from userspace.
    
    Signed-off-by: Parthiban Veerasooran <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Mon Aug 11 15:34:13 2025 +0200

    mips: lantiq: danube: add missing device_type in pci node
    
    [ Upstream commit d66949a1875352d2ddd52b144333288952a9e36f ]
    
    This fixes the following warning:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: pci@e105400 (lantiq,pci-xway): 'device_type' is a required property
            from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Mon Aug 11 13:58:15 2025 +0200

    mips: lantiq: danube: add missing properties to cpu node
    
    [ Upstream commit e8dee66c37085dc9858eb8608bc783c2900e50e7 ]
    
    This fixes the following warnings:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#address-cells' is a required property
            from schema $id: http://devicetree.org/schemas/cpus.yaml#
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#size-cells' is a required property
            from schema $id: http://devicetree.org/schemas/cpus.yaml#
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpu@0 (mips,mips24Kc): 'reg' is a required property
            from schema $id: http://devicetree.org/schemas/mips/cpus.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Tue Aug 12 16:06:04 2025 +0200

    mips: lantiq: danube: add model to EASY50712 dts
    
    [ Upstream commit cb96fd880ef78500b34d10fa76ddd3fa070287d6 ]
    
    This fixes the following warning:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: / (lantiq,xway): 'model' is a required property
            from schema $id: http://devicetree.org/schemas/root-node.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Fri Aug 15 14:12:24 2025 +0200

    mips: lantiq: danube: rename stp node on EASY50712 reference board
    
    [ Upstream commit 2b9706ce84be9cb26be03e1ad2e43ec8bc3986be ]
    
    This fixes the following warning:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: stp@e100bb0 (lantiq,gpio-stp-xway): $nodename:0: 'stp@e100bb0' does not match '^gpio@[0-9a-f]+$'
            from schema $id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Fri Aug 15 14:12:23 2025 +0200

    mips: lantiq: xway: sysctrl: rename stp clock
    
    [ Upstream commit b0d04fe6a633ada2c7bc1b5ddd011cbd85961868 ]
    
    Bindig requires a node name matching ‘^gpio@[0-9a-f]+$’. This patch
    changes the clock name from “stp” to “gpio”.
    
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christian Bruel <[email protected]>
Date:   Mon Aug 4 19:09:14 2025 +0200

    misc: pci_endpoint_test: Skip IRQ tests if irq is out of range
    
    [ Upstream commit cc8e391067164f45f89b6132a5aaa18c33a0e32b ]
    
    The pci_endpoint_test tests the 32-bit MSI range. However, the device might
    not have all vectors configured. For example, if msi_interrupts is 8 in the
    ep function space or if the MSI Multiple Message Capable value is
    configured as 4 (maximum 16 vectors).
    
    In this case, do not attempt to run the test to avoid timeouts and directly
    return the error value.
    
    Signed-off-by: Christian Bruel <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Biju Das <[email protected]>
Date:   Sun Jun 29 21:38:56 2025 +0100

    mmc: host: renesas_sdhi: Fix the actual clock
    
    [ Upstream commit 9c174e4dacee9fb2014a4ffc953d79a5707b77e4 ]
    
    Wrong actual clock reported, if the SD clock division ratio is other
    than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111).
    
    On high speed mode, cat /sys/kernel/debug/mmc1/ios
    Without the patch:
    clock:          50000000 Hz
    actual clock:   200000000 Hz
    
    After the fix:
    clock:          50000000 Hz
    actual clock:   50000000 Hz
    
    Signed-off-by: Biju Das <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sarthak Garg <[email protected]>
Date:   Mon Sep 8 16:11:19 2025 +0530

    mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card
    
    [ Upstream commit 08b68ca543ee9d5a8d2dc406165e4887dd8f170b ]
    
    For Qualcomm SoCs which needs level shifter for SD card, extra delay is
    seen on receiver data path.
    
    To compensate this delay enable tuning for SDR50 mode for targets which
    has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets
    with level shifter on Qualcomm SOC's.
    
    Signed-off-by: Sarthak Garg <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Erick Shepherd <[email protected]>
Date:   Thu Jul 24 13:53:54 2025 -0500

    mmc: sdhci: Disable SD card clock before changing parameters
    
    [ Upstream commit 5f755ba95ae10fd4fa28d64345056ffc18d12c5a ]
    
    Per the SD Host Controller Simplified Specification v4.20 §3.2.3, change
    the SD card clock parameters only after first disabling the external card
    clock. Doing this fixes a spurious clock pulse on Baytrail and Apollo Lake
    SD controllers which otherwise breaks voltage switching with a specific
    Swissbit SD card. This change is limited to Intel host controllers to
    avoid an issue reported on ARM64 devices.
    
    Signed-off-by: Kyle Roeschley <[email protected]>
    Signed-off-by: Brad Mouring <[email protected]>
    Signed-off-by: Erick Shepherd <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Al Viro <[email protected]>
Date:   Tue Aug 19 23:54:39 2025 -0400

    move_mount(2): take sanity checks in 'beneath' case into do_lock_mount()
    
    [ Upstream commit d29da1a8f119130e6fc7d5d71029d402dabe2cb0 ]
    
    We want to mount beneath the given location.  For that operation to
    make sense, location must be the root of some mount that has something
    under it.  Currently we let it proceed if those requirements are not met,
    with rather meaningless results, and have that bogosity caught further
    down the road; let's fail early instead - do_lock_mount() doesn't make
    sense unless those conditions hold, and checking them there makes
    things simpler.
    
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Oct 28 09:16:52 2025 +0100

    mptcp: drop bogus optimization in __mptcp_check_push()
    
    commit 27b0e701d3872ba59c5b579a9e8a02ea49ad3d3b upstream.
    
    Accessing the transmit queue without owning the msk socket lock is
    inherently racy, hence __mptcp_check_push() could actually quit early
    even when there is pending data.
    
    That in turn could cause unexpected tx lock and timeout.
    
    Dropping the early check avoids the race, implicitly relaying on later
    tests under the relevant lock. With such change, all the other
    mptcp_send_head() call sites are now under the msk socket lock and we
    can additionally drop the now unneeded annotation on the transmit head
    pointer accesses.
    
    Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Tested-by: Geliang Tang <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Sun Nov 2 15:14:46 2025 -0500

    mptcp: fix MSG_PEEK stream corruption
    
    [ Upstream commit 8e04ce45a8db7a080220e86e249198fa676b83dc ]
    
    If a MSG_PEEK | MSG_WAITALL read operation consumes all the bytes in the
    receive queue and recvmsg() need to waits for more data - i.e. it's a
    blocking one - upon arrival of the next packet the MPTCP protocol will
    start again copying the oldest data present in the receive queue,
    corrupting the data stream.
    
    Address the issue explicitly tracking the peeked sequence number,
    restarting from the last peeked byte.
    
    Fixes: ca4fb892579f ("mptcp: add MSG_PEEK support")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Tested-by: Geliang Tang <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Sun Nov 2 15:14:45 2025 -0500

    mptcp: leverage skb deferral free
    
    [ Upstream commit 9aa59323f2709370cb4f01acbba599a9167f317b ]
    
    Usage of the skb deferral API is straight-forward; with multiple
    subflows actives this allow moving part of the received application
    load into multiple CPUs.
    
    Also fix a typo in the related comment.
    
    Reviewed-by: Geliang Tang <[email protected]>
    Tested-by: Geliang Tang <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20250927-net-next-mptcp-rcv-path-imp-v1-1-5da266aa9c1a@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 8e04ce45a8db ("mptcp: fix MSG_PEEK stream corruption")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Oct 28 09:16:54 2025 +0100

    mptcp: restore window probe
    
    commit a824084b98d8a1dbd6e85d0842a8eb5e73467f59 upstream.
    
    Since commit 72377ab2d671 ("mptcp: more conservative check for zero
    probes") the MPTCP-level zero window probe check is always disabled, as
    the TCP-level write queue always contains at least the newly allocated
    skb.
    
    Refine the relevant check tacking in account that the above condition
    and that such skb can have zero length.
    
    Fixes: 72377ab2d671 ("mptcp: more conservative check for zero probes")
    Cc: [email protected]
    Reported-by: Geliang Tang <[email protected]>
    Closes: https://lore.kernel.org/[email protected]
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Tested-by: Geliang Tang <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yafang Shao <[email protected]>
Date:   Tue Sep 2 14:29:33 2025 +0800

    net/cls_cgroup: Fix task_get_classid() during qdisc run
    
    [ Upstream commit 66048f8b3cc7e462953c04285183cdee43a1cb89 ]
    
    During recent testing with the netem qdisc to inject delays into TCP
    traffic, we observed that our CLS BPF program failed to function correctly
    due to incorrect classid retrieval from task_get_classid(). The issue
    manifests in the following call stack:
    
            bpf_get_cgroup_classid+5
            cls_bpf_classify+507
            __tcf_classify+90
            tcf_classify+217
            __dev_queue_xmit+798
            bond_dev_queue_xmit+43
            __bond_start_xmit+211
            bond_start_xmit+70
            dev_hard_start_xmit+142
            sch_direct_xmit+161
            __qdisc_run+102             <<<<< Issue location
            __dev_xmit_skb+1015
            __dev_queue_xmit+637
            neigh_hh_output+159
            ip_finish_output2+461
            __ip_finish_output+183
            ip_finish_output+41
            ip_output+120
            ip_local_out+94
            __ip_queue_xmit+394
            ip_queue_xmit+21
            __tcp_transmit_skb+2169
            tcp_write_xmit+959
            __tcp_push_pending_frames+55
            tcp_push+264
            tcp_sendmsg_locked+661
            tcp_sendmsg+45
            inet_sendmsg+67
            sock_sendmsg+98
            sock_write_iter+147
            vfs_write+786
            ksys_write+181
            __x64_sys_write+25
            do_syscall_64+56
            entry_SYSCALL_64_after_hwframe+100
    
    The problem occurs when multiple tasks share a single qdisc. In such cases,
    __qdisc_run() may transmit skbs created by different tasks. Consequently,
    task_get_classid() retrieves an incorrect classid since it references the
    current task's context rather than the skb's originating task.
    
    Given that dev_queue_xmit() always executes with bh disabled, we can use
    softirq_count() instead to obtain the correct classid.
    
    The simple steps to reproduce this issue:
    1. Add network delay to the network interface:
      such as: tc qdisc add dev bond0 root netem delay 1.5ms
    2. Build two distinct net_cls cgroups, each with a network-intensive task
    3. Initiate parallel TCP streams from both tasks to external servers.
    
    Under this specific condition, the issue reliably occurs. The kernel
    eventually dequeues an SKB that originated from Task-A while executing in
    the context of Task-B.
    
    It is worth noting that it will change the established behavior for a
    slightly different scenario:
    
      <sock S is created by task A>
      <class ID for task A is changed>
      <skb is created by sock S xmit and classified>
    
    prior to this patch the skb will be classified with the 'new' task A
    classid, now with the old/original one. The bpf_get_cgroup_classid_curr()
    function is a more appropriate choice for this case.
    
    Signed-off-by: Yafang Shao <[email protected]>
    Cc: Daniel Borkmann <[email protected]>
    Cc: Thomas Graf <[email protected]>
    Cc: Sebastian Andrzej Siewior <[email protected]>
    Cc: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Carolina Jubran <[email protected]>
Date:   Wed Sep 24 12:40:34 2025 +0000

    net/mlx5e: Don't query FEC statistics when FEC is disabled
    
    [ Upstream commit 6b81b8a0b1978284e007566d7a1607b47f92209f ]
    
    Update mlx5e_stats_fec_get() to check the active FEC mode and skip
    statistics collection when FEC is disabled.
    
    Signed-off-by: Carolina Jubran <[email protected]>
    Reviewed-by: Dragos Tatulea <[email protected]>
    Reviewed-by: Yael Chemla <[email protected]>
    Signed-off-by: Vadim Fedorenko <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gal Pressman <[email protected]>
Date:   Tue Nov 4 16:15:36 2025 +0200

    net/mlx5e: Fix return value in case of module EEPROM read error
    
    [ Upstream commit d1c94bc5b90c21b65469d30d4a6bc8ed715c1bfe ]
    
    mlx5e_get_module_eeprom_by_page() has weird error handling.
    
    First, it is treating -EINVAL as a special case, but it is unclear why.
    
    Second, it tries to fail "gracefully" by returning the number of bytes
    read even in case of an error. This results in wrongly returning
    success (0 return value) if the error occurs before any bytes were
    read.
    
    Simplify the error handling by returning an error when such occurs. This
    also aligns with the error handling we have in mlx5e_get_module_eeprom()
    for the old API.
    
    This fixes the following case where the query fails, but userspace
    ethtool wrongly treats it as success and dumps an output:
    
      # ethtool -m eth2
      netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5
      netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5
      Offset                Values
      ------                ------
      0x0000:               00 00 00 00 05 00 04 00 00 00 00 00 05 00 05 00
      0x0010:               00 00 00 00 05 00 06 00 50 00 00 00 67 65 20 66
      0x0020:               61 69 6c 65 64 2c 20 72 65 61 64 20 30 20 62 79
      0x0030:               74 65 73 2c 20 65 72 72 20 2d 35 00 14 00 03 00
      0x0040:               08 00 01 00 03 00 00 00 08 00 02 00 1a 00 00 00
      0x0050:               14 00 04 00 08 00 01 00 04 00 00 00 08 00 02 00
      0x0060:               0e 00 00 00 14 00 05 00 08 00 01 00 05 00 00 00
      0x0070:               08 00 02 00 1a 00 00 00 14 00 06 00 08 00 01 00
    
    Fixes: e109d2b204da ("net/mlx5: Implement get_module_eeprom_by_page()")
    Signed-off-by: Gal Pressman <[email protected]>
    Reviewed-by: Alex Lazar <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jianbo Liu <[email protected]>
Date:   Mon Sep 29 00:25:18 2025 +0300

    net/mlx5e: Prevent entering switchdev mode with inconsistent netns
    
    [ Upstream commit 06fdc45f16c392dc3394c67e7c17ae63935715d3 ]
    
    When a PF enters switchdev mode, its netdevice becomes the uplink
    representor but remains in its current network namespace. All other
    representors (VFs, SFs) are created in the netns of the devlink
    instance.
    
    If the PF's netns has been moved and differs from the devlink's netns,
    enabling switchdev mode would create a state where the OVS control
    plane (ovs-vsctl) cannot manage the switch because the PF uplink
    representor and the other representors are split across different
    namespaces.
    
    To prevent this inconsistent configuration, block the request to enter
    switchdev mode if the PF netdevice's netns does not match the netns of
    its devlink instance.
    
    As part of this change, the PF's netns is first marked as immutable.
    This prevents race conditions where the netns could be changed after
    the check is performed but before the mode transition is complete, and
    it aligns the PF's behavior with that of the final uplink representor.
    
    Signed-off-by: Jianbo Liu <[email protected]>
    Reviewed-by: Cosmin Ratiu <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Reviewed-by: Dragos Tatulea <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dragos Tatulea <[email protected]>
Date:   Tue Nov 4 08:48:35 2025 +0200

    net/mlx5e: SHAMPO, Fix header formulas for higher MTUs and 64K pages
    
    [ Upstream commit d8a7ed9586c7579a99e9e2d90988c9eceeee61ff ]
    
    The MLX5E_SHAMPO_WQ_HEADER_PER_PAGE and
    MLX5E_SHAMPO_LOG_MAX_HEADER_ENTRY_SIZE macros are used directly in
    several places under the assumption that there will always be more
    headers per WQE than headers per page. However, this assumption doesn't
    hold for 64K page sizes and higher MTUs (> 4K). This can be first
    observed during header page allocation: ksm_entries will become 0 during
    alignment to MLX5E_SHAMPO_WQ_HEADER_PER_PAGE.
    
    This patch introduces 2 additional members to the mlx5e_shampo_hd struct
    which are meant to be used instead of the macrose mentioned above.
    When the number of headers per WQE goes below
    MLX5E_SHAMPO_WQ_HEADER_PER_PAGE, clamp the number of headers per
    page and expand the header size accordingly so that the headers
    for one WQE cover a full page.
    
    All the formulas are adapted to use these two new members.
    
    Fixes: 945ca432bfd0 ("net/mlx5e: SHAMPO, Drop info array")
    Signed-off-by: Dragos Tatulea <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dragos Tatulea <[email protected]>
Date:   Tue Nov 4 08:48:33 2025 +0200

    net/mlx5e: SHAMPO, Fix header mapping for 64K pages
    
    [ Upstream commit 665a7e13c220bbde55531a24bd5524320648df10 ]
    
    HW-GRO is broken on mlx5 for 64K page sizes. The patch in the fixes tag
    didn't take into account larger page sizes when doing an align down
    of max_ksm_entries. For 64K page size, max_ksm_entries is 0 which will skip
    mapping header pages via WQE UMR. This breaks header-data split
    and will result in the following syndrome:
    
    mlx5_core 0000:00:08.0 eth2: Error cqe on cqn 0x4c9, ci 0x0, qn 0x1133, opcode 0xe, syndrome 0x4, vendor syndrome 0x32
    00000000: 00 00 00 00 04 4a 00 00 00 00 00 00 20 00 93 32
    00000010: 55 00 00 00 fb cc 00 00 00 00 00 00 07 18 00 00
    00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a
    00000030: 00 00 3b c7 93 01 32 04 00 00 00 00 00 00 bf e0
    mlx5_core 0000:00:08.0 eth2: ERR CQE on RQ: 0x1133
    
    Furthermore, the function that fills in WQE UMRs for the headers
    (mlx5e_build_shampo_hd_umr()) only supports mapping page sizes that
    fit in a single UMR WQE.
    
    This patch goes back to the old non-aligned max_ksm_entries value and it
    changes mlx5e_build_shampo_hd_umr() to support mapping a large page over
    multiple UMR WQEs.
    
    This means that mlx5e_build_shampo_hd_umr() can now leave a page only
    partially mapped. The caller, mlx5e_alloc_rx_hd_mpwqe(), ensures that
    there are enough UMR WQEs to cover complete pages by working on
    ksm_entries that are multiples of MLX5E_SHAMPO_WQ_HEADER_PER_PAGE.
    
    Fixes: 8a0ee54027b1 ("net/mlx5e: SHAMPO, Simplify UMR allocation for headers")
    Signed-off-by: Dragos Tatulea <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dragos Tatulea <[email protected]>
Date:   Tue Nov 4 08:48:34 2025 +0200

    net/mlx5e: SHAMPO, Fix skb size check for 64K pages
    
    [ Upstream commit bacd8d80181ebe34b599a39aa26bf73a44c91e55 ]
    
    mlx5e_hw_gro_skb_has_enough_space() uses a formula to check if there is
    enough space in the skb frags to store more data. This formula is
    incorrect for 64K page sizes and it triggers early GRO session
    termination because the first fragment will blow up beyond
    GRO_LEGACY_MAX_SIZE.
    
    This patch adds a special case for page sizes >= GRO_LEGACY_MAX_SIZE
    (64K) which uses the skb->len instead. Within this context,
    the check is safe from fragment overflow because the hardware
    will continuously fill the data up to the reservation size of 64K
    and the driver will coalesce all data from the same page to the same
    fragment. This means that the data will span one fragment or at most
    two for such a large page size.
    
    It is expected that the if statement will be optimized out as the
    check is done with constants.
    
    Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation")
    Signed-off-by: Dragos Tatulea <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikolay Aleksandrov <[email protected]>
Date:   Wed Nov 5 13:19:19 2025 +0200

    net: bridge: fix MST static key usage
    
    [ Upstream commit ee87c63f9b2a418f698d79c2991347e31a7d2c27 ]
    
    As Ido pointed out, the static key usage in MST is buggy and should use
    inc/dec instead of enable/disable because we can have multiple bridges
    with MST enabled which means a single bridge can disable MST for all.
    Use static_branch_inc/dec to avoid that. When destroying a bridge decrement
    the key if MST was enabled.
    
    Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode")
    Reported-by: Ido Schimmel <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#m6888d87658f94ed1725433940f4f4ebb00b5a68b
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikolay Aleksandrov <[email protected]>
Date:   Wed Nov 5 13:19:18 2025 +0200

    net: bridge: fix use-after-free due to MST port state bypass
    
    [ Upstream commit 8dca36978aa80bab9d4da130c211db75c9e00048 ]
    
    syzbot reported[1] a use-after-free when deleting an expired fdb. It is
    due to a race condition between learning still happening and a port being
    deleted, after all its fdbs have been flushed. The port's state has been
    toggled to disabled so no learning should happen at that time, but if we
    have MST enabled, it will bypass the port's state, that together with VLAN
    filtering disabled can lead to fdb learning at a time when it shouldn't
    happen while the port is being deleted. VLAN filtering must be disabled
    because we flush the port VLANs when it's being deleted which will stop
    learning. This fix adds a check for the port's vlan group which is
    initialized to NULL when the port is getting deleted, that avoids the port
    state bypass. When MST is enabled there would be a minimal new overhead
    in the fast-path because the port's vlan group pointer is cache-hot.
    
    [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be
    
    Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Petr Machata <[email protected]>
Date:   Mon Sep 22 16:14:48 2025 +0200

    net: bridge: Install FDB for bridge MAC on VLAN 0
    
    [ Upstream commit cd9a9562b2559973aa1b68c3af63021a2c5fd022 ]
    
    Currently, after the bridge is created, the FDB does not hold an FDB entry
    for the bridge MAC on VLAN 0:
    
     # ip link add name br up type bridge
     # ip -br link show dev br
     br               UNKNOWN        92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP>
     # bridge fdb show | grep 92:19:8c:4e:01:ed
     92:19:8c:4e:01:ed dev br vlan 1 master br permanent
    
    Later when the bridge MAC is changed, or in fact when the address is given
    during netdevice creation, the entry appears:
    
     # ip link add name br up address 00:11:22:33:44:55 type bridge
     # bridge fdb show | grep 00:11:22:33:44:55
     00:11:22:33:44:55 dev br vlan 1 master br permanent
     00:11:22:33:44:55 dev br master br permanent
    
    However when the bridge address is set by the user to the current bridge
    address before the first port is enslaved, none of the address handlers
    gets invoked, because the address is not actually changed. The address is
    however marked as NET_ADDR_SET. Then when a port is enslaved, the address
    is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not
    added, and it has not been added previously either:
    
     # ip link add name br up type bridge
     # ip -br link show dev br
     br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
     # ip link set dev br addr 7e:f0:a8:1a:be:c2
     # ip link add name v up type veth
     # ip link set dev v master br
     # ip -br link show dev br
     br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
     # bridge fdb | grep 7e:f0:a8:1a:be:c2
     7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent
    
    Then when the bridge MAC is used as DMAC, and br_handle_frame_finish()
    looks up an FDB entry with VLAN=0, it doesn't find any, and floods the
    traffic instead of passing it up.
    
    Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always
    on netdevice creation. This also makes the behavior consistent with how
    ports are treated: ports always have an FDB entry for each member VLAN as
    well as VLAN 0.
    
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Acked-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/415202b2d1b9b0899479a502bbe2ba188678f192.1758550408.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Wed Sep 3 17:48:10 2025 +0000

    net: call cond_resched() less often in __release_sock()
    
    [ Upstream commit 16c610162d1f1c332209de1c91ffb09b659bb65d ]
    
    While stress testing TCP I had unexpected retransmits and sack packets
    when a single cpu receives data from multiple high-throughput flows.
    
    super_netperf 4 -H srv -T,10 -l 3000 &
    
    Tcpdump extract:
    
     00:00:00.000007 IP6 clnt > srv: Flags [.], seq 26062848:26124288, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26124288:26185728, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26185728:26243072, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 57344
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26243072:26304512, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26304512:26365952, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440
     00:00:00.000007 IP6 clnt > srv: Flags [P.], seq 26365952:26423296, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 57344
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26423296:26484736, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26484736:26546176, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26546176:26603520, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 57344
     00:00:00.003932 IP6 clnt > srv: Flags [P.], seq 26603520:26619904, ack 1, win 66, options [nop,nop,TS val 651464844 ecr 3100753141], length 16384
     00:00:00.006602 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651471419 ecr 3100759716], length 4096
     00:00:00.013000 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651484421 ecr 3100772718], length 4096
     00:00:00.000416 IP6 srv > clnt: Flags [.], ack 26619904, win 1393, options [nop,nop,TS val 3100773185 ecr 651484421,nop,nop,sack 1 {24862720:24866816}], length 0
    
    After analysis, it appears this is because of the cond_resched()
    call from  __release_sock().
    
    When current thread is yielding, while still holding the TCP socket lock,
    it might regain the cpu after a very long time.
    
    Other peer TLP/RTO is firing (multiple times) and packets are retransmit,
    while the initial copy is waiting in the socket backlog or receive queue.
    
    In this patch, I call cond_resched() only once every 16 packets.
    
    Modern TCP stack now spends less time per packet in the backlog,
    especially because ACK are no longer sent (commit 133c4c0d3717
    "tcp: defer regular ACK while processing socket backlog")
    
    Before:
    
    clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK"
    TcpOutSegs                      19046186           0.0
    TcpRetransSegs                  1471               0.0
    TcpExtTCPTimeouts               1397               0.0
    TcpExtTCPLossProbes             1356               0.0
    TcpExtTCPDSACKRecv              1352               0.0
    TcpExtTCPSpuriousRTOs           114                0.0
    TcpExtTCPDSACKRecvSegs          1352               0.0
    
    After:
    
    clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK"
    TcpOutSegs                      19218936           0.0
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Aug 15 20:16:12 2025 +0000

    net: Call trace_sock_exceed_buf_limit() for memcg failure with SK_MEM_RECV.
    
    [ Upstream commit 9d85c565a7b7c78b732393c02bcaa4d5c275fe58 ]
    
    Initially, trace_sock_exceed_buf_limit() was invoked when
    __sk_mem_raise_allocated() failed due to the memcg limit or the
    global limit.
    
    However, commit d6f19938eb031 ("net: expose sk wmem in
    sock_exceed_buf_limit tracepoint") somehow suppressed the event
    only when memcg failed to charge for SK_MEM_RECV, although the
    memcg failure for SK_MEM_SEND still triggers the event.
    
    Let's restore the event for SK_MEM_RECV.
    
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Shakeel Butt <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stanislav Fomichev <[email protected]>
Date:   Wed Sep 10 09:24:29 2025 -0700

    net: devmem: expose tcp_recvmsg_locked errors
    
    [ Upstream commit 18282100d7040614b553f1cad737cb689c04e2b9 ]
    
    tcp_recvmsg_dmabuf can export the following errors:
    - EFAULT when linear copy fails
    - ETOOSMALL when cmsg put fails
    - ENODEV if one of the frags is readable
    - ENOMEM on xarray failures
    
    But they are all ignored and replaced by EFAULT in the caller
    (tcp_recvmsg_locked). Expose real error to the userspace to
    add more transparency on what specifically fails.
    
    In non-devmem case (skb_copy_datagram_msg) doing `if (!copied)
    copied=-EFAULT` is ok because skb_copy_datagram_msg can return only EFAULT.
    
    Reviewed-by: David Ahern <[email protected]>
    Reviewed-by: Mina Almasry <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: Stanislav Fomichev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Sat Nov 1 14:28:07 2025 +0100

    net: dsa: b53: fix bcm63xx RGMII port link adjustment
    
    [ Upstream commit 3e4ebdc1606adf77744cf8ed7a433d279fdc57ba ]
    
    BCM63XX's switch does not support MDIO scanning of external phys, so its
    MACs needs to be manually configured for autonegotiated link speeds.
    
    So b53_force_port_config() and b53_force_link() accordingly also when
    mode is MLO_AN_PHY for those ports.
    
    Fixes lower speeds than 1000/full on rgmii ports 4 - 7.
    
    This aligns the behaviour with the old bcm63xx_enetsw driver for those
    ports.
    
    Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Sun Nov 2 11:07:56 2025 +0100

    net: dsa: b53: fix enabling ip multicast
    
    [ Upstream commit c264294624e956a967a9e2e5fa41e3273340b089 ]
    
    In the New Control register bit 1 is either reserved, or has a different
    function:
    
        Out of Range Error Discard
    
        When enabled, the ingress port discards any frames
        if the Length field is between 1500 and 1536
        (excluding 1500 and 1536) and with good CRC.
    
    The actual bit for enabling IP multicast is bit 0, which was only
    explicitly enabled for BCM5325 so far.
    
    For older switch chips, this bit defaults to 0, so we want to enable it
    as well, while newer switch chips default to 1, and their documentation
    says "It is illegal to set this bit to zero."
    
    So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit
    also for other switch chips. While at it, rename it to (B53_)IP_MC as
    that is how it is called in Broadcom code.
    
    Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Sat Nov 1 14:28:06 2025 +0100

    net: dsa: b53: fix resetting speed and pause on forced link
    
    [ Upstream commit b6a8a5477fe9bd6be2b594a88f82f8bba41e6d54 ]
    
    There is no guarantee that the port state override registers have their
    default values, as not all switches support being reset via register or
    have a reset GPIO.
    
    So when forcing port config, we need to make sure to clear all fields,
    which we currently do not do for the speed and flow control
    configuration. This can cause flow control stay enabled, or in the case
    of speed becoming an illegal value, e.g. configured for 1G (0x2), then
    setting 100M (0x1), results in 0x3 which is invalid.
    
    For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on
    supported chips, as the bit can have different meanings on other chips,
    e.g. for BCM5389 this controls scanning PHYs for link/speed
    configuration.
    
    Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Sun Nov 2 11:07:58 2025 +0100

    net: dsa: b53: properly bound ARL searches for < 4 ARL bin chips
    
    [ Upstream commit e57723fe536f040cc2635ec1545dd0a7919a321e ]
    
    When iterating over the ARL table we stop at max ARL entries / 2, but
    this is only valid if the chip actually returns 2 results at once. For
    chips with only one result register we will stop before reaching the end
    of the table if it is more than half full.
    
    Fix this by only dividing the maximum results by two if we have a chip
    with more than one result register (i.e. those with 4 ARL bins).
    
    Fixes: cd169d799bee ("net: dsa: b53: Bound check ARL searches")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Sun Nov 2 11:07:57 2025 +0100

    net: dsa: b53: stop reading ARL entries if search is done
    
    [ Upstream commit 0be04b5fa62a82a9929ca261f6c9f64a3d0a28da ]
    
    The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it
    finished traversing the ARL table.
    
    This means that there will be no valid result, so we should not attempt
    to read and process any further entries.
    
    We only ever check the validity of the entries for 4 ARL bin chips, and
    only after having passed the first entry to the b53_fdb_copy().
    
    This means that we always pass an invalid entry at the end to the
    b53_fdb_copy(). b53_fdb_copy() does check the validity though before
    passing on the entry, so it never gets passed on.
    
    On < 4 ARL bin chips, we will even continue reading invalid entries
    until we reach the result limit.
    
    Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vladimir Oltean <[email protected]>
Date:   Wed Sep 3 16:07:26 2025 +0300

    net: dsa: felix: support phy-mode = "10g-qxgmii"
    
    [ Upstream commit 6f616757dd306fce4b55131df23737732e347d8f ]
    
    The "usxgmii" phy-mode that the Felix switch ports support on LS1028A is
    not quite USXGMII, it is defined by the USXGMII multiport specification
    document as 10G-QXGMII. It uses the same signaling as USXGMII, but it
    multiplexes 4 ports over the link, resulting in a maximum speed of 2.5G
    per port.
    
    This change is needed in preparation for the lynx-10g SerDes driver on
    LS1028A, which will make a more clear distinction between usxgmii
    (supported on lane 0) and 10g-qxgmii (supported on lane 1). These
    protocols have their configuration in different PCCR registers (PCCRB vs
    PCCR9).
    
    Continue parsing and supporting single-port-per-lane USXGMII when found
    in the device tree as usual (because it works), but add support for
    10G-QXGMII too. Using phy-mode = "10g-qxgmii" will be required when
    modifying the device trees to specify a "phys" phandle to the SerDes
    lane. The result when the "phys" phandle is present but the phy-mode is
    wrong is undefined.
    
    The only PHY driver in known use with this phy-mode, AQR412C, will gain
    logic to transition from "usxgmii" to "10g-qxgmii" in a future change.
    Prepare the driver by also setting PHY_INTERFACE_MODE_10G_QXGMII in
    supported_interfaces when PHY_INTERFACE_MODE_USXGMII is there, to
    prevent breakage with existing device trees.
    
    Signed-off-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tristram Ha <[email protected]>
Date:   Tue Nov 4 19:37:41 2025 -0800

    net: dsa: microchip: Fix reserved multicast address table programming
    
    [ Upstream commit 96baf482ca1f69f0da9d10a5bd8422c87ea9039e ]
    
    KSZ9477/KSZ9897 and LAN937X families of switches use a reserved multicast
    address table for some specific forwarding with some multicast addresses,
    like the one used in STP.  The hardware assumes the host port is the last
    port in KSZ9897 family and port 5 in LAN937X family.  Most of the time
    this assumption is correct but not in other cases like KSZ9477.
    Originally the function just setups the first entry, but the others still
    need update, especially for one common multicast address that is used by
    PTP operation.
    
    LAN937x also uses different register bits when accessing the reserved
    table.
    
    Fixes: 457c182af597 ("net: dsa: microchip: generic access to ksz9477 static and reserved table")
    Signed-off-by: Tristram Ha <[email protected]>
    Tested-by: Łukasz Majewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bastien Curutchet <[email protected]>
Date:   Thu Sep 18 10:33:52 2025 +0200

    net: dsa: microchip: Set SPI as bus interface during reset for KSZ8463
    
    [ Upstream commit a0b977a3d19368b235f2a6c06e800fb25452029b ]
    
    At reset, the KSZ8463 uses a strap-based configuration to set SPI as
    bus interface. SPI is the only bus supported by the driver. If the
    required pull-ups/pull-downs are missing (by mistake or by design to
    save power) the pins may float and the configuration can go wrong
    preventing any communication with the switch.
    
    Introduce a ksz8463_configure_straps_spi() function called during the
    device reset. It relies on the 'straps-rxd-gpios' OF property and the
    'reset' pinmux configuration to enforce SPI as bus interface.
    
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Bastien Curutchet (Schneider Electric) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Gorski <[email protected]>
Date:   Mon Oct 27 20:46:21 2025 +0100

    net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xx
    
    [ Upstream commit 3d18a84eddde169d6dbf3c72cc5358b988c347d0 ]
    
    The internal switch on BCM63XX SoCs will unconditionally add 802.1Q VLAN
    tags on egress to CPU when 802.1Q mode is enabled. We do this
    unconditionally since commit ed409f3bbaa5 ("net: dsa: b53: Configure
    VLANs while not filtering").
    
    This is fine for VLAN aware bridges, but for standalone ports and vlan
    unaware bridges this means all packets are tagged with the default VID,
    which is 0.
    
    While the kernel will treat that like untagged, this can break userspace
    applications processing raw packets, expecting untagged traffic, like
    STP daemons.
    
    This also breaks several bridge tests, where the tcpdump output then
    does not match the expected output anymore.
    
    Since 0 isn't a valid VID, just strip out the VLAN tag if we encounter
    it, unless the priority field is set, since that would be a valid tag
    again.
    
    Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags")
    Signed-off-by: Jonas Gorski <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Robert Marko <[email protected]>
Date:   Wed Sep 17 13:00:24 2025 +0200

    net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X
    
    [ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ]
    
    LAN969x switchdev support depends on the SparX-5 core,so make it selectable
    for ARCH_LAN969X.
    
    Signed-off-by: Robert Marko <[email protected]>
    Reviewed-by: Daniel Machon <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jijie Shao <[email protected]>
Date:   Thu Oct 23 21:13:37 2025 +0800

    net: hns3: return error code when function fails
    
    [ Upstream commit 03ca7c8c42be913529eb9f188278114430c6abbd ]
    
    Currently, in hclge_mii_ioctl(), the operation to
    read the PHY register (SIOCGMIIREG) always returns 0.
    
    This patch changes the return type of hclge_read_phy_reg(),
    returning an error code when the function fails.
    
    Fixes: 024712f51e57 ("net: hns3: add ioctl support for imp-controlled PHYs")
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Brahmajit Das <[email protected]>
Date:   Tue Sep 2 12:54:22 2025 +0530

    net: intel: fm10k: Fix parameter idx set but not used
    
    [ Upstream commit 99e9c5ffbbee0f258a1da4eadf602b943f8c8300 ]
    
    Variable idx is set in the loop, but is never used resulting in dead
    code. Building with GCC 16, which enables
    -Werror=unused-but-set-parameter= by default results in build error.
    This patch removes the idx parameter, since all the callers of the
    fm10k_unbind_hw_stats_q as 0 as idx anyways.
    
    Suggested-by: Vadim Fedorenko <[email protected]>
    Signed-off-by: Brahmajit Das <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mohammad Heib <[email protected]>
Date:   Fri Oct 31 17:52:02 2025 +0200

    net: ionic: add dma_wmb() before ringing TX doorbell
    
    [ Upstream commit d261f5b09c28850dc63ca1d3018596f829f402d5 ]
    
    The TX path currently writes descriptors and then immediately writes to
    the MMIO doorbell register to notify the NIC.  On weakly ordered
    architectures, descriptor writes may still be pending in CPU or DMA
    write buffers when the doorbell is issued, leading to the device
    fetching stale or incomplete descriptors.
    
    Add a dma_wmb() in ionic_txq_post() to ensure all descriptor writes are
    visible to the device before the doorbell MMIO write.
    
    Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
    Signed-off-by: Mohammad Heib <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mohammad Heib <[email protected]>
Date:   Fri Oct 31 17:52:03 2025 +0200

    net: ionic: map SKB after pseudo-header checksum prep
    
    [ Upstream commit de0337d641bfa5b6d6b489e479792f1039274e84 ]
    
    The TSO path called ionic_tx_map_skb() before preparing the TCP pseudo
    checksum (ionic_tx_tcp_[inner_]pseudo_csum()), which may perform
    skb_cow_head() and might modifies bytes in the linear header area.
    
    Mapping first and then mutating the header risks:
      - Using a stale DMA address if skb_cow_head() relocates the head, and/or
      - Device reading stale header bytes on weakly-ordered systems
        (CPU writes after mapping are not guaranteed visible without an
        explicit dma_sync_single_for_device()).
    
    Reorder the TX path to perform all header mutations (including
    skb_cow_head()) *before* DMA mapping. Mapping is now done only after the
    skb layout and header contents are final. This removes the need for any
    post-mapping dma_sync and prevents on-wire corruption observed under
    VLAN+TSO load after repeated runs.
    
    This change is purely an ordering fix; no functional behavior change
    otherwise.
    
    Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
    Signed-off-by: Mohammad Heib <[email protected]>
    Reviewed-by: Brett Creeley <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oscar Maes <[email protected]>
Date:   Tue Aug 19 19:46:41 2025 +0200

    net: ipv4: allow directed broadcast routes to use dst hint
    
    [ Upstream commit 1b8c5fa0cb35efd08f07f700e6d78a541ebabe26 ]
    
    Currently, ip_extract_route_hint uses RTN_BROADCAST to decide
    whether to use the route dst hint mechanism.
    
    This check is too strict, as it prevents directed broadcast
    routes from using the hint, resulting in poor performance
    during bursts of directed broadcast traffic.
    
    Fix this in ip_extract_route_hint and modify ip_route_use_hint
    to preserve the intended behaviour.
    
    Signed-off-by: Oscar Maes <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Charalampos Mitrodimas <[email protected]>
Date:   Tue Aug 12 15:51:25 2025 +0000

    net: ipv6: fix field-spanning memcpy warning in AH output
    
    [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ]
    
    Fix field-spanning memcpy warnings in ah6_output() and
    ah6_output_done() where extension headers are copied to/from IPv6
    address fields, triggering fortify-string warnings about writes beyond
    the 16-byte address fields.
    
      memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16)
      WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
    
    The warnings are false positives as the extension headers are
    intentionally placed after the IPv6 header in memory. Fix by properly
    copying addresses and extension headers separately, and introduce
    helper functions to avoid code duplication.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c
    Signed-off-by: Charalampos Mitrodimas <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiawen Wu <[email protected]>
Date:   Tue Nov 4 14:23:21 2025 +0800

    net: libwx: fix device bus LAN ID
    
    commit a04ea57aae375bdda1cb57034d8bcbb351e1f973 upstream.
    
    The device bus LAN ID was obtained from PCI_FUNC(), but when a PF
    port is passthrough to a virtual machine, the function number may not
    match the actual port index on the device. This could cause the driver
    to perform operations such as LAN reset on the wrong port.
    
    Fix this by reading the LAN ID from port status register.
    
    Fixes: a34b3e6ed8fb ("net: txgbe: Store PCI info")
    Cc: [email protected]
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Théo Lebrun <[email protected]>
Date:   Tue Sep 23 18:00:27 2025 +0200

    net: macb: avoid dealing with endianness in macb_set_hwaddr()
    
    [ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ]
    
    bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32
    pointer and dereferencing implies dealing manually with endianness,
    which is error-prone.
    
    Replace by calls to get_unaligned_le32|le16() helpers.
    
    This was found using sparse:
       ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o
       warning: incorrect type in assignment (different base types)
          expected unsigned int [usertype] bottom
          got restricted __le32 [usertype]
       warning: incorrect type in assignment (different base types)
          expected unsigned short [usertype] top
          got restricted __le16 [usertype]
       ...
    
    Reviewed-by: Sean Anderson <[email protected]>
    Signed-off-by: Théo Lebrun <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Haiyang Zhang <[email protected]>
Date:   Wed Sep 10 13:57:21 2025 -0700

    net: mana: Reduce waiting time if HWC not responding
    
    [ Upstream commit c4deabbc1abe452ea230b86d53ed3711e5a8a062 ]
    
    If HW Channel (HWC) is not responding, reduce the waiting time, so further
    steps will fail quickly.
    This will prevent getting stuck for a long time (30 minutes or more), for
    example, during unloading while HWC is not responding.
    
    Signed-off-by: Haiyang Zhang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alok Tiwari <[email protected]>
Date:   Fri Oct 31 09:15:53 2025 -0700

    net: mdio: Check regmap pointer returned by device_node_to_regmap()
    
    [ Upstream commit b2b526c2cf57d14ee269e012ed179081871f45a1 ]
    
    The call to device_node_to_regmap() in airoha_mdio_probe() can return
    an ERR_PTR() if regmap initialization fails. Currently, the driver
    stores the pointer without validation, which could lead to a crash
    if it is later dereferenced.
    
    Add an IS_ERR() check and return the corresponding error code to make
    the probe path more robust.
    
    Fixes: 67e3ba978361 ("net: mdio: Add MDIO bus controller for Airoha AN7583")
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Juraj Šarinay <[email protected]>
Date:   Tue Sep 2 13:36:28 2025 +0200

    net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms
    
    [ Upstream commit 21f82062d0f241e55dd59eb630e8710862cc90b4 ]
    
    An exchange with a NFC target must complete within NCI_DATA_TIMEOUT.
    A delay of 700 ms is not sufficient for cryptographic operations on smart
    cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH
    or 3072-bit RSA. To prevent brute-force attacks, passports and similar
    documents introduce even longer delays into access control protocols
    (BAC/PACE).
    
    The timeout should be higher, but not too much. The expiration allows
    us to detect that a NFC target has disappeared.
    
    Signed-off-by: Juraj Šarinay <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleksij Rempel <[email protected]>
Date:   Fri Sep 12 15:20:00 2025 +0200

    net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
    
    [ Upstream commit 0915cb22452723407ca9606b7e5cc3fe6ce767d5 ]
    
    Clear EEE runtime flags when the PHY transitions to HALTED or ERROR
    and the state machine drops the link. This avoids stale EEE state being
    reported via ethtool after the PHY is stopped or hits an error.
    
    This change intentionally only clears software runtime flags and avoids
    MDIO accesses in HALTED/ERROR. A follow-up patch will address other
    link state variables.
    
    Suggested-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Oleksij Rempel <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleksij Rempel <[email protected]>
Date:   Wed Sep 17 11:47:51 2025 +0200

    net: phy: clear link parameters on admin link down
    
    [ Upstream commit 60f887b1290b43a4f5a3497982a725687b193fa4 ]
    
    When a PHY is halted (e.g. `ip link set dev lan2 down`), several
    fields in struct phy_device may still reflect the last active
    connection. This leads to ethtool showing stale values even though
    the link is down.
    
    Reset selected fields in _phy_state_machine() when transitioning
    to PHY_HALTED and the link was previously up:
    
    - speed/duplex -> UNKNOWN, but only in autoneg mode (in forced mode
      these fields carry configuration, not status)
    - master_slave_state -> UNKNOWN if previously supported
    - mdix -> INVALID (state only, same meaning as "unknown")
    - lp_advertising -> always cleared
    
    The cleanup is skipped if the PHY is in PHY_ERROR state, so the
    last values remain available for diagnostics.
    
    Signed-off-by: Oleksij Rempel <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiner Kallweit <[email protected]>
Date:   Sat Sep 20 23:33:16 2025 +0200

    net: phy: dp83640: improve phydev and driver removal handling
    
    [ Upstream commit 42e2a9e11a1dcb81c83d50d18c547dc9a1c6d6ed ]
    
    Once the last user of a clock has been removed, the clock should be
    removed. So far orphaned clocks are cleaned up in dp83640_free_clocks()
    only. Add the logic to remove orphaned clocks in dp83640_remove().
    This allows to simplify the code, and use standard macro
    module_phy_driver(). dp83640 was the last external user of
    phy_driver_register(), so we can stop exporting this function afterwards.
    
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Maxime Chevallier <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Emanuele Ghidoli <[email protected]>
Date:   Thu Oct 23 16:48:53 2025 +0200

    net: phy: dp83867: Disable EEE support as not implemented
    
    commit 84a905290cb4c3d9a71a9e3b2f2e02e031e7512f upstream.
    
    While the DP83867 PHYs report EEE capability through their feature
    registers, the actual hardware does not support EEE (see Links).
    When the connected MAC enables EEE, it causes link instability and
    communication failures.
    
    The issue is reproducible with a iMX8MP and relevant stmmac ethernet port.
    Since the introduction of phylink-managed EEE support in the stmmac driver,
    EEE is now enabled by default, leading to issues on systems using the
    DP83867 PHY.
    
    Call phy_disable_eee during phy initialization to prevent EEE from being
    enabled on DP83867 PHYs.
    
    Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1445244/dp83867ir-dp83867-disable-eee-lpi
    Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/658638/dp83867ir-eee-energy-efficient-ethernet
    Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
    Cc: [email protected]
    Signed-off-by: Emanuele Ghidoli <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Heiner Kallweit <[email protected]>
Date:   Sat Aug 23 23:25:05 2025 +0200

    net: phy: fixed_phy: let fixed_phy_unregister free the phy_device
    
    [ Upstream commit a0f849c1cc6df0db9083b4c81c05a5456b1ed0fb ]
    
    fixed_phy_register() creates and registers the phy_device. To be
    symmetric, we should not only unregister, but also free the phy_device
    in fixed_phy_unregister(). This allows to simplify code in users.
    
    Note wrt of_phy_deregister_fixed_link():
    put_device(&phydev->mdio.dev) and phy_device_free(phydev) are identical.
    
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rohan G Thomas <[email protected]>
Date:   Sat Sep 6 10:33:31 2025 +0800

    net: phy: marvell: Fix 88e1510 downshift counter errata
    
    [ Upstream commit deb105f49879dd50d595f7f55207d6e74dec34e6 ]
    
    The 88e1510 PHY has an erratum where the phy downshift counter is not
    cleared after phy being suspended(BMCR_PDOWN set) and then later
    resumed(BMCR_PDOWN cleared). This can cause the gigabit link to
    intermittently downshift to a lower speed.
    
    Disabling and re-enabling the downshift feature clears the counter,
    allowing the PHY to retry gigabit link negotiation up to the programmed
    retry count times before downshifting. This behavior has been observed
    on copper links.
    
    Signed-off-by: Rohan G Thomas <[email protected]>
    Reviewed-by: Matthew Gerlach <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vladimir Oltean <[email protected]>
Date:   Wed Aug 13 10:44:54 2025 +0300

    net: phy: mscc: report and configure in-band auto-negotiation for SGMII/QSGMII
    
    [ Upstream commit df979273bd716a93ca9ffa8f84aeb205c9bf2ab6 ]
    
    The following Vitesse/Microsemi/Microchip PHYs, among those supported by
    this driver, have the host interface configurable as SGMII or QSGMII:
    - VSC8504
    - VSC8514
    - VSC8552
    - VSC8562
    - VSC8572
    - VSC8574
    - VSC8575
    - VSC8582
    - VSC8584
    
    All these PHYs are documented to have bit 7 of "MAC SerDes PCS Control"
    as "MAC SerDes ANEG enable".
    
    Out of these, I could test the VSC8514 quad PHY in QSGMII. This works
    both with the in-band autoneg on and off, on the NXP LS1028A-RDB and
    T1040-RDB boards.
    
    Notably, the bit is sticky (survives soft resets), so giving Linux the
    tools to read and modify this settings makes it robust to changes made
    to it by previous boot layers (U-Boot).
    
    Signed-off-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krishna Kumar <[email protected]>
Date:   Mon Aug 25 08:40:04 2025 +0530

    net: Prevent RPS table overwrite of active flows
    
    [ Upstream commit 97bcc5b6f45425ac56fb04b0893cdaa607ec7e45 ]
    
    This patch fixes an issue where two different flows on the same RXq
    produce the same hash resulting in continuous flow overwrites.
    
    Flow #1: A packet for Flow #1 comes in, kernel calls the steering
             function. The driver gives back a filter id. The kernel saves
             this filter id in the selected slot. Later, the driver's
             service task checks if any filters have expired and then
             installs the rule for Flow #1.
    Flow #2: A packet for Flow #2 comes in. It goes through the same steps.
             But this time, the chosen slot is being used by Flow #1. The
             driver gives a new filter id and the kernel saves it in the
             same slot. When the driver's service task runs, it runs through
             all the flows, checks if Flow #1 should be expired, the kernel
             returns True as the slot has a different filter id, and then
             the driver installs the rule for Flow #2.
    Flow #1: Another packet for Flow #1 comes in. The same thing repeats.
             The slot is overwritten with a new filter id for Flow #1.
    
    This causes a repeated cycle of flow programming for missed packets,
    wasting CPU cycles while not improving performance. This problem happens
    at higher rates when the RPS table is small, but tests show it still
    happens even with 12,000 connections and an RPS size of 16K per queue
    (global table size = 144x16K = 64K).
    
    This patch prevents overwriting an rps_dev_flow entry if it is active.
    The intention is that it is better to do aRFS for the first flow instead
    of hurting all flows on the same hash. Without this, two (or more) flows
    on one RX queue with the same hash can keep overwriting each other. This
    causes the driver to reprogram the flow repeatedly.
    
    Changes:
      1. Add a new 'hash' field to struct rps_dev_flow.
      2. Add rps_flow_is_active(): a helper function to check if a flow is
         active or not, extracted from rps_may_expire_flow(). It is further
         simplified as per reviewer feedback.
      3. In set_rps_cpu():
         - Avoid overwriting by programming a new filter if:
            - The slot is not in use, or
            - The slot is in use but the flow is not active, or
            - The slot has an active flow with the same hash, but target CPU
              differs.
         - Save the hash in the rps_dev_flow entry.
      4. rps_may_expire_flow(): Use earlier extracted rps_flow_is_active().
    
    Testing & results:
      - Driver: ice (E810 NIC), Kernel: net-next
      - #CPUs = #RXq = 144 (1:1)
      - Number of flows: 12K
      - Eight RPS settings from 256 to 32768. Though RPS=256 is not ideal,
        it is still sufficient to cover 12K flows (256*144 rx-queues = 64K
        global table slots)
      - Global Table Size = 144 * RPS (effectively equal to 256 * RPS)
      - Each RPS test duration = 8 mins (org code) + 8 mins (new code).
      - Metrics captured on client
    
    Legend for following tables:
    Steer-C: #times ndo_rx_flow_steer() was Called by set_rps_cpu()
    Steer-L: #times ice_arfs_flow_steer() Looped over aRFS entries
    Add:     #times driver actually programmed aRFS (ice_arfs_build_entry())
    Del:     #times driver deleted the flow (ice_arfs_del_flow_rules())
    Units:   K = 1,000 times, M = 1 million times
    
      |-------|---------|------|     Org Code    |---------|---------|
      | RPS   | Latency | CPU  | Add    |  Del   | Steer-C | Steer-L |
      |-------|---------|------|--------|--------|---------|---------|
      | 256   | 227.0   | 93.2 | 1.6M   | 1.6M   | 121.7M  | 267.6M  |
      | 512   | 225.9   | 94.1 | 11.5M  | 11.2M  | 65.7M   | 199.6M  |
      | 1024  | 223.5   | 95.6 | 16.5M  | 16.5M  | 27.1M   | 187.3M  |
      | 2048  | 222.2   | 96.3 | 10.5M  | 10.5M  | 12.5M   | 115.2M  |
      | 4096  | 223.9   | 94.1 | 5.5M   | 5.5M   | 7.2M    | 65.9M   |
      | 8192  | 224.7   | 92.5 | 2.7M   | 2.7M   | 3.0M    | 29.9M   |
      | 16384 | 223.5   | 92.5 | 1.3M   | 1.3M   | 1.4M    | 13.9M   |
      | 32768 | 219.6   | 93.2 | 838.1K | 838.1K | 965.1K  | 8.9M    |
      |-------|---------|------|   New Code      |---------|---------|
      | 256   | 201.5   | 99.1 | 13.4K  | 5.0K   | 13.7K   | 75.2K   |
      | 512   | 202.5   | 98.2 | 11.2K  | 5.9K   | 11.2K   | 55.5K   |
      | 1024  | 207.3   | 93.9 | 11.5K  | 9.7K   | 11.5K   | 59.6K   |
      | 2048  | 207.5   | 96.7 | 11.8K  | 11.1K  | 15.5K   | 79.3K   |
      | 4096  | 206.9   | 96.6 | 11.8K  | 11.7K  | 11.8K   | 63.2K   |
      | 8192  | 205.8   | 96.7 | 11.9K  | 11.8K  | 11.9K   | 63.9K   |
      | 16384 | 200.9   | 98.2 | 11.9K  | 11.9K  | 11.9K   | 64.2K   |
      | 32768 | 202.5   | 98.0 | 11.9K  | 11.9K  | 11.9K   | 64.2K   |
      |-------|---------|------|--------|--------|---------|---------|
    
    Some observations:
      1. Overall Latency improved: (1790.19-1634.94)/1790.19*100 = 8.67%
      2. Overall CPU increased:    (777.32-751.49)/751.45*100    = 3.44%
      3. Flow Management (add/delete) remained almost constant at ~11K
         compared to values in millions.
    
    Signed-off-by: Krishna Kumar <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Söderlund <[email protected]>
Date:   Tue Sep 9 10:58:49 2025 +0200

    net: sh_eth: Disable WoL if system can not suspend
    
    [ Upstream commit 9c02ea544ac35a9def5827d30594406947ccd81a ]
    
    The MAC can't facilitate WoL if the system can't go to sleep. Gate the
    WoL support callbacks in ethtool at compile time using CONFIG_PM_SLEEP.
    
    Signed-off-by: Niklas Söderlund <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tiezhu Yang <[email protected]>
Date:   Mon Aug 11 15:35:04 2025 +0800

    net: stmmac: Check stmmac_hw_setup() in stmmac_resume()
    
    [ Upstream commit 6896c2449a1858acb643014894d01b3a1223d4e5 ]
    
    stmmac_hw_setup() may return 0 on success and an appropriate negative
    integer as defined in errno.h file on failure, just check it and then
    return early if failed in stmmac_resume().
    
    Signed-off-by: Tiezhu Yang <[email protected]>
    Reviewed-by: Maxime Chevallier <[email protected]>
    Reviewed-by: Huacai Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleksij Rempel <[email protected]>
Date:   Mon Aug 18 11:02:15 2025 +0200

    net: stmmac: Correctly handle Rx checksum offload errors
    
    [ Upstream commit ee0aace5f844ef59335148875d05bec8764e71e8 ]
    
    The stmmac_rx function would previously set skb->ip_summed to
    CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled
    and the packet was of a known IP ethertype.
    
    However, this logic failed to check if the hardware had actually
    reported a checksum error. The hardware status, indicating a header or
    payload checksum failure, was being ignored at this stage. This could
    cause corrupt packets to be passed up the network stack as valid.
    
    This patch corrects the logic by checking the `csum_none` status flag,
    which is set when the hardware reports a checksum error. If this flag
    is set, skb->ip_summed is now correctly set to CHECKSUM_NONE,
    ensuring the kernel's network stack will perform its own validation and
    properly handle the corrupt packet.
    
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rohan G Thomas <[email protected]>
Date:   Thu Sep 25 22:06:13 2025 +0800

    net: stmmac: est: Drop frames causing HLBS error
    
    [ Upstream commit 7ce48d497475d7222bd8258c5c055eb7d928793c ]
    
    Drop those frames causing Head-of-Line Blocking due to Scheduling
    (HLBS) error to avoid HLBS interrupt flooding and netdev watchdog
    timeouts due to blocked packets. Tx queues can be configured to drop
    those blocked packets by setting Drop Frames causing Scheduling Error
    (DFBS) bit of EST_CONTROL register.
    
    Also, add per queue HLBS drop count.
    
    Signed-off-by: Rohan G Thomas <[email protected]>
    Reviewed-by: Matthew Gerlach <[email protected]>
    Reviewed-by: Furong Xu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Meghana Malladi <[email protected]>
Date:   Tue Nov 4 16:14:15 2025 +0530

    net: ti: icssg-prueth: Fix fdb hash size configuration
    
    [ Upstream commit ae4789affd1e181ae46e72e2b5fbe2d6d7b6616a ]
    
    The ICSSG driver does the initial FDB configuration which
    includes setting the control registers. Other run time
    management like learning is managed by the PRU's. The default
    FDB hash size used by the firmware is 512 slots, which is
    currently missing in the current driver. Update the driver
    FDB config to include FDB hash size as well.
    
    Please refer trm [1] 6.4.14.12.17 section on how the FDB config
    register gets configured. From the table 6-1404, there is a reset
    field for FDB_HAS_SIZE which is 4, meaning 1024 slots. Currently
    the driver is not updating this reset value from 4(1024 slots) to
    3(512 slots). This patch fixes this by updating the reset value
    to 512 slots.
    
    [1]: https://www.ti.com/lit/pdf/spruim2
    Fixes: abd5576b9c57f ("net: ti: icssg-prueth: Add support for ICSSG switch firmware")
    Signed-off-by: Meghana Malladi <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miaoqian Lin <[email protected]>
Date:   Mon Oct 27 00:43:16 2025 +0800

    net: usb: asix_devices: Check return value of usbnet_get_endpoints
    
    commit dc89548c6926d68dfdda11bebc1a5258bc41d887 upstream.
    
    The code did not check the return value of usbnet_get_endpoints.
    Add checks and return the error if it fails to transfer the error.
    
    Found via static anlaysis and this is similar to
    commit 07161b2416f7 ("sr9800: Add check for usbnet_get_endpoints").
    
    Fixes: 933a27d39e0e ("USB: asix - Add AX88178 support and many other changes")
    Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Qendrim Maxhuni <[email protected]>
Date:   Wed Oct 29 08:57:44 2025 +0100

    net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup
    
    [ Upstream commit e120f46768d98151ece8756ebd688b0e43dc8b29 ]
    
    Raw IP packets have no MAC header, leaving skb->mac_header uninitialized.
    This can trigger kernel panics on ARM64 when xfrm or other subsystems
    access the offset due to strict alignment checks.
    
    Initialize the MAC header to prevent such crashes.
    
    This can trigger kernel panics on ARM when running IPsec over the
    qmimux0 interface.
    
    Example trace:
    
        Internal error: Oops: 000000009600004f [#1] SMP
        CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
        Hardware name: LS1028A RDB Board (DT)
        pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : xfrm_input+0xde8/0x1318
        lr : xfrm_input+0x61c/0x1318
        sp : ffff800080003b20
        Call trace:
         xfrm_input+0xde8/0x1318
         xfrm6_rcv+0x38/0x44
         xfrm6_esp_rcv+0x48/0xa8
         ip6_protocol_deliver_rcu+0x94/0x4b0
         ip6_input_finish+0x44/0x70
         ip6_input+0x44/0xc0
         ipv6_rcv+0x6c/0x114
         __netif_receive_skb_one_core+0x5c/0x8c
         __netif_receive_skb+0x18/0x60
         process_backlog+0x78/0x17c
         __napi_poll+0x38/0x180
         net_rx_action+0x168/0x2f0
    
    Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
    Signed-off-by: Qendrim Maxhuni <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hangbin Liu <[email protected]>
Date:   Thu Oct 30 07:35:39 2025 +0000

    net: vlan: sync VLAN features with lower device
    
    [ Upstream commit c211f5d7cbd5cb34489d526648bb9c8ecc907dee ]
    
    After registering a VLAN device and setting its feature flags, we need to
    synchronize the VLAN features with the lower device. For example, the VLAN
    device does not have the NETIF_F_LRO flag, it should be synchronized with
    the lower device based on the NETIF_F_UPPER_DISABLES definition.
    
    As the dev->vlan_features has changed, we need to call
    netdev_update_features(). The caller must run after netdev_upper_dev_link()
    links the lower devices, so this patch adds the netdev_update_features()
    call in register_vlan_dev().
    
    Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
    Signed-off-by: Hangbin Liu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Haotian Zhang <[email protected]>
Date:   Wed Nov 5 11:47:16 2025 +0800

    net: wan: framer: pef2256: Switch to devm_mfd_add_devices()
    
    [ Upstream commit 4d6ec3a7932ca5b168426f7b5b40abab2b41d2da ]
    
    The driver calls mfd_add_devices() but fails to call mfd_remove_devices()
    in error paths after successful MFD device registration and in the remove
    function. This leads to resource leaks where MFD child devices are not
    properly unregistered.
    
    Replace mfd_add_devices with devm_mfd_add_devices to automatically
    manage the device resources.
    
    Fixes: c96e976d9a05 ("net: wan: framer: Add support for the Lantiq PEF2256 framer")
    Suggested-by: Herve Codina <[email protected]>
    Signed-off-by: Haotian Zhang <[email protected]>
    Acked-by: Herve Codina <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiawen Wu <[email protected]>
Date:   Thu Aug 21 10:34:06 2025 +0800

    net: wangxun: limit tx_max_coalesced_frames_irq
    
    [ Upstream commit fd4aa243f154a80bbeb3dd311d2114eeb538f479 ]
    
    Add limitation on tx_max_coalesced_frames_irq as 0 ~ 65535, because
    'wx->tx_work_limit' is declared as a member of type u16.
    
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christoph Paasch <[email protected]>
Date:   Sat Aug 16 16:12:49 2025 -0700

    net: When removing nexthops, don't call synchronize_net if it is not necessary
    
    [ Upstream commit b0ac6d3b56a2384db151696cfda2836a8a961b6d ]
    
    When removing a nexthop, commit
    90f33bffa382 ("nexthops: don't modify published nexthop groups") added a
    call to synchronize_rcu() (later changed to _net()) to make sure
    everyone sees the new nexthop-group before the rtnl-lock is released.
    
    When one wants to delete a large number of groups and nexthops, it is
    fastest to first flush the groups (ip nexthop flush groups) and then
    flush the nexthops themselves (ip -6 nexthop flush). As that way the
    groups don't need to be rebalanced.
    
    However, `ip -6 nexthop flush` will still take a long time if there is
    a very large number of nexthops because of the call to
    synchronize_net(). Now, if there are no more groups, there is no point
    in calling synchronize_net(). So, let's skip that entirely by checking
    if nh->grp_list is empty.
    
    This gives us a nice speedup:
    
    BEFORE:
    =======
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 2097152 nexthops
    
    real    1m45.345s
    user    0m0.001s
    sys     0m0.005s
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 4194304 nexthops
    
    real    3m10.430s
    user    0m0.002s
    sys     0m0.004s
    
    AFTER:
    ======
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 2097152 nexthops
    
    real    0m17.545s
    user    0m0.003s
    sys     0m0.003s
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 4194304 nexthops
    
    real    0m35.823s
    user    0m0.002s
    sys     0m0.004s
    
    Signed-off-by: Christoph Paasch <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Reviewed-by: Nikolay Aleksandrov <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sammy Hsu <[email protected]>
Date:   Thu Oct 2 10:48:41 2025 +0800

    net: wwan: t7xx: add support for HP DRMR-H01
    
    [ Upstream commit 370e98728bda92b1bdffb448d1acdcbe19dadb4c ]
    
    add support for HP DRMR-H01 (0x03f0, 0x09c8)
    
    Signed-off-by: Sammy Hsu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gustavo Luiz Duarte <[email protected]>
Date:   Wed Oct 29 13:50:24 2025 -0700

    netconsole: Acquire su_mutex before navigating configs hierarchy
    
    [ Upstream commit d7d2fcf7ae31471b4e08b7e448b8fd0ec2e06a1b ]
    
    There is a race between operations that iterate over the userdata
    cg_children list and concurrent add/remove of userdata items through
    configfs. The update_userdata() function iterates over the
    nt->userdata_group.cg_children list, and count_extradata_entries() also
    iterates over this same list to count nodes.
    
    Quoting from Documentation/filesystems/configfs.rst:
    > A subsystem can navigate the cg_children list and the ci_parent pointer
    > to see the tree created by the subsystem.  This can race with configfs'
    > management of the hierarchy, so configfs uses the subsystem mutex to
    > protect modifications.  Whenever a subsystem wants to navigate the
    > hierarchy, it must do so under the protection of the subsystem
    > mutex.
    
    Without proper locking, if a userdata item is added or removed
    concurrently while these functions are iterating, the list can be
    accessed in an inconsistent state. For example, the list_for_each() loop
    can reach a node that is being removed from the list by list_del_init()
    which sets the nodes' .next pointer to point to itself, so the loop will
    never end (or reach the WARN_ON_ONCE in update_userdata() ).
    
    Fix this by holding the configfs subsystem mutex (su_mutex) during all
    operations that iterate over cg_children.
    This includes:
    - userdatum_value_store() which calls update_userdata() to iterate over
      cg_children
    - All sysdata_*_enabled_store() functions which call
      count_extradata_entries() to iterate over cg_children
    
    The su_mutex must be acquired before dynamic_netconsole_mutex to avoid
    potential lock ordering issues, as configfs operations may already hold
    su_mutex when calling into our code.
    
    Fixes: df03f830d099 ("net: netconsole: cache userdata formatted string in netconsole_target")
    Signed-off-by: Gustavo Luiz Duarte <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Florian Westphal <[email protected]>
Date:   Fri Aug 29 17:01:02 2025 +0200

    netfilter: nf_reject: don't reply to icmp error messages
    
    [ Upstream commit db99b2f2b3e2cd8227ac9990ca4a8a31a1e95e56 ]
    
    tcp reject code won't reply to a tcp reset.
    
    But the icmp reject 'netdev' family versions will reply to icmp
    dst-unreach errors, unlike icmp_send() and icmp6_send() which are used
    by the inet family implementation (and internally by the REJECT target).
    
    Check for the icmp(6) type and do not respond if its an unreachable error.
    
    Without this, something like 'ip protocol icmp reject', when used
    in a netdev chain attached to 'lo', cause a packet loop.
    
    Same for two hosts that both use such a rule: each error packet
    will be replied to.
    
    Such situation persist until the (bogus) rule is amended to ratelimit or
    checks the icmp type before the reject statement.
    
    As the inet versions don't do this make the netdev ones follow along.
    
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Florian Westphal <[email protected]>
Date:   Fri Aug 22 10:15:38 2025 +0200

    netfilter: nf_tables: all transaction allocations can now sleep
    
    [ Upstream commit 3d95a2e016abab29ccb6f384576b2038e544a5a8 ]
    
    Now that nft_setelem_flush is not called with rcu read lock held or
    disabled softinterrupts anymore this can now use GFP_KERNEL too.
    
    This is the last atomic allocation of transaction elements, so remove
    all gfp_t arguments and the wrapper function.
    
    This makes attempts to delete large sets much more reliable, before
    this was prone to transient memory allocation failures.
    
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Asbjørn Sloth Tønnesen <[email protected]>
Date:   Tue Sep 2 15:46:35 2025 +0000

    netlink: specs: fou: change local-v6/peer-v6 check
    
    [ Upstream commit 9f9581ba74a931843c6d807ecfeaff9fb8c1b731 ]
    
    While updating the binary min-len implementation, I noticed that
    the only user, should AFAICT be using exact-len instead.
    
    In net/ipv4/fou_core.c FOU_ATTR_LOCAL_V6 and FOU_ATTR_PEER_V6
    are only used for singular IPv6 addresses, and there are AFAICT
    no known implementations trying to send more, it therefore
    appears safe to change it to an exact-len policy.
    
    This patch therefore changes the local-v6/peer-v6 attributes to
    use an exact-len check, instead of a min-len check.
    
    Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]>
    Reviewed-by: Donald Hunter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Breno Leitao <[email protected]>
Date:   Mon Nov 3 08:38:17 2025 -0800

    netpoll: Fix deadlock in memory allocation under spinlock
    
    [ Upstream commit 327c20c21d80e0d87834b392d83ae73c955ad8ff ]
    
    Fix a AA deadlock in refill_skbs() where memory allocation while holding
    skb_pool->lock can trigger a recursive lock acquisition attempt.
    
    The deadlock scenario occurs when the system is under severe memory
    pressure:
    
    1. refill_skbs() acquires skb_pool->lock (spinlock)
    2. alloc_skb() is called while holding the lock
    3. Memory allocator fails and calls slab_out_of_memory()
    4. This triggers printk() for the OOM warning
    5. The console output path calls netpoll_send_udp()
    6. netpoll_send_udp() attempts to acquire the same skb_pool->lock
    7. Deadlock: the lock is already held by the same CPU
    
    Call stack:
      refill_skbs()
        spin_lock_irqsave(&skb_pool->lock)    <- lock acquired
        __alloc_skb()
          kmem_cache_alloc_node_noprof()
            slab_out_of_memory()
              printk()
                console_flush_all()
                  netpoll_send_udp()
                    skb_dequeue()
                      spin_lock_irqsave(&skb_pool->lock)     <- deadlock attempt
    
    This bug was exposed by commit 248f6571fd4c51 ("netpoll: Optimize skb
    refilling on critical path") which removed refill_skbs() from the
    critical path (where nested printk was being deferred), letting nested
    printk being called from inside refill_skbs()
    
    Refactor refill_skbs() to never allocate memory while holding
    the spinlock.
    
    Another possible solution to fix this problem is protecting the
    refill_skbs() from nested printks, basically calling
    printk_deferred_{enter,exit}() in refill_skbs(), then, any nested
    pr_warn() would be deferred.
    
    I prefer this approach, given I _think_ it might be a good idea to move
    the alloc_skb() from GFP_ATOMIC to GFP_KERNEL in the future, so, having
    the alloc_skb() outside of the lock will be necessary step.
    
    There is a possible TOCTOU issue when checking for the pool length, and
    queueing the new allocated skb, but, this is not an issue, given that
    an extra SKB in the pool is harmless and it will be eventually used.
    
    Signed-off-by: Breno Leitao <[email protected]>
    Fixes: 248f6571fd4c51 ("netpoll: Optimize skb refilling on critical path")
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Al Viro <[email protected]>
Date:   Tue Sep 16 17:22:45 2025 +0100

    nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
    
    [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ]
    
    Theoretically it's an oopsable race, but I don't believe one can manage
    to hit it on real hardware; might become doable on a KVM, but it still
    won't be easy to attack.
    
    Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of
    put_unaligned_be64(), we can put that under ->d_lock and be done with that.
    
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chuck Lever <[email protected]>
Date:   Mon Sep 29 12:53:40 2025 -0400

    NFSD: Define actions for the new time_deleg FATTR4 attributes
    
    commit 4f76435fd517981f01608678c06ad9718a86ee98 upstream.
    
    NFSv4 clients won't send legitimate GETATTR requests for these new
    attributes because they are intended to be used only with CB_GETATTR
    and SETATTR. But NFSD has to do something besides crashing if it
    ever sees a GETATTR request that queries these attributes.
    
    RFC 8881 Section 18.7.3 states:
    
    > The server MUST return a value for each attribute that the client
    > requests if the attribute is supported by the server for the
    > target file system. If the server does not support a particular
    > attribute on the target file system, then it MUST NOT return the
    > attribute value and MUST NOT set the attribute bit in the result
    > bitmap. The server MUST return an error if it supports an
    > attribute on the target but cannot obtain its value. In that case,
    > no attribute values will be returned.
    
    Further, RFC 9754 Section 5 states:
    
    > These new attributes are invalid to be used with GETATTR, VERIFY,
    > and NVERIFY, and they can only be used with CB_GETATTR and SETATTR
    > by a client holding an appropriate delegation.
    
    Thus there does not appear to be a specific server response mandated
    by specification. Taking the guidance that querying these attributes
    via GETATTR is "invalid", NFSD will return nfserr_inval, failing the
    request entirely.
    
    Reported-by: Robert Morris <[email protected]>
    Closes: https://lore.kernel.org/linux-nfs/[email protected]/T/#t
    Fixes: 51c0d4f7e317 ("nfsd: add support for FATTR4_OPEN_ARGUMENTS")
    Cc: [email protected]
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Chuck Lever <[email protected]>
Date:   Tue Sep 30 10:05:20 2025 -0400

    NFSD: Fix crash in nfsd4_read_release()
    
    commit abb1f08a2121dd270193746e43b2a9373db9ad84 upstream.
    
    When tracing is enabled, the trace_nfsd_read_done trace point
    crashes during the pynfs read.testNoFh test.
    
    Fixes: 15a8b55dbb1b ("nfsd: call op_release, even when op_func returns an error")
    Cc: [email protected]
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Anthony Iliopoulos <[email protected]>
Date:   Wed Aug 13 11:00:47 2025 +0200

    NFSv4.1: fix mount hang after CREATE_SESSION failure
    
    [ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ]
    
    When client initialization goes through server trunking discovery, it
    schedules the state manager and then sleeps waiting for nfs_client
    initialization completion.
    
    The state manager can fail during state recovery, and specifically in
    lease establishment as nfs41_init_clientid() will bail out in case of
    errors returned from nfs4_proc_create_session(), without ever marking
    the client ready. The session creation can fail for a variety of reasons
    e.g. during backchannel parameter negotiation, with status -EINVAL.
    
    The error status will propagate all the way to the nfs4_state_manager
    but the client status will not be marked, and thus the mount process
    will remain blocked waiting.
    
    Fix it by adding -EINVAL error handling to nfs4_state_manager().
    
    Signed-off-by: Anthony Iliopoulos <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Olga Kornievskaia <[email protected]>
Date:   Mon Aug 11 14:18:48 2025 -0400

    NFSv4: handle ERR_GRACE on delegation recalls
    
    [ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ]
    
    RFC7530 states that clients should be prepared for the return of
    NFS4ERR_GRACE errors for non-reclaim lock and I/O requests.
    
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jerome Brunet <[email protected]>
Date:   Wed Jul 2 18:48:33 2025 +0200

    NTB: epf: Allow arbitrary BAR mapping
    
    [ Upstream commit 5ad865862a0fd349163243e1834ed98ba9b81905 ]
    
    The NTB epf host driver assumes the BAR number associated with a memory
    window is just incremented from the BAR number associated with MW1. This
    seems to have been enough so far but this is not really how the endpoint
    side work and the two could easily become mis-aligned.
    
    ntb_epf_mw_to_bar() even assumes that the BAR number is the memory window
    index + 2, which means the function only returns a proper result if BAR_2
    is associated with MW1.
    
    Instead, fully describe and allow arbitrary NTB BAR mapping.
    
    Signed-off-by: Jerome Brunet <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tetsuo Handa <[email protected]>
Date:   Tue Sep 2 19:43:24 2025 +0900

    ntfs3: pretend $Extend records as regular files
    
    [ Upstream commit 4e8011ffec79717e5fdac43a7e79faf811a384b7 ]
    
    Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")
    requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/
    S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.
    
    Reported-by: syzbot <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
    Signed-off-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Wagner <[email protected]>
Date:   Tue Sep 2 12:22:03 2025 +0200

    nvme-fc: use lock accessing port_state and rport state
    
    [ Upstream commit 891cdbb162ccdb079cd5228ae43bdeebce8597ad ]
    
    nvme_fc_unregister_remote removes the remote port on a lport object at
    any point in time when there is no active association. This races with
    with the reconnect logic, because nvme_fc_create_association is not
    taking a lock to check the port_state and atomically increase the
    active count on the rport.
    
    Reported-by: Shinichiro Kawasaki <[email protected]>
    Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46nwzgeo5ausc@uyrkdls2muwx
    Signed-off-by: Daniel Wagner <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alistair Francis <[email protected]>
Date:   Tue Sep 2 13:52:11 2025 +1000

    nvme: Use non zero KATO for persistent discovery connections
    
    [ Upstream commit 2e482655019ab6fcfe8865b62432c6d03f0b5f80 ]
    
    The NVMe Base Specification 2.1 states that:
    
    """
    A host requests an explicit persistent connection ... by specifying a
    non-zero Keep Alive Timer value in the Connect command.
    """
    
    As such if we are starting a persistent connection to a discovery
    controller and the KATO is currently 0 we need to update KATO to a non
    zero value to avoid continuous timeouts on the target.
    
    Signed-off-by: Alistair Francis <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hannes Reinecke <[email protected]>
Date:   Wed Oct 22 09:59:24 2025 +0200

    nvmet-auth: update sc_c in host response
    
    [ Upstream commit 60ad1de8e59278656092f56e87189ec82f078d12 ]
    
    The target code should set the sc_c bit in calculating the host response
    based on the status of the 'concat' setting, otherwise we'll get an
    authentication mismatch for hosts setting that bit correctly.
    
    Fixes: 7e091add9c43 ("nvme-auth: update sc_c in host response")
    Signed-off-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Wagner <[email protected]>
Date:   Tue Sep 2 12:22:01 2025 +0200

    nvmet-fc: avoid scheduling association deletion twice
    
    [ Upstream commit f2537be4f8421f6495edfa0bc284d722f253841d ]
    
    When forcefully shutting down a port via the configfs interface,
    nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and
    then nvmet_disable_port(). Both functions will eventually schedule all
    remaining associations for deletion.
    
    The current implementation checks whether an association is about to be
    removed, but only after the work item has already been scheduled. As a
    result, it is possible for the first scheduled work item to free all
    resources, and then for the same work item to be scheduled again for
    deletion.
    
    Because the association list is an RCU list, it is not possible to take
    a lock and remove the list entry directly, so it cannot be looked up
    again. Instead, a flag (terminating) must be used to determine whether
    the association is already in the process of being deleted.
    
    Reported-by: Shinichiro Kawasaki <[email protected]>
    Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2ih5aregghax5@mhr7v3eryci3/
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Daniel Wagner <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hariprasad Kelam <[email protected]>
Date:   Wed Aug 20 12:16:25 2025 +0530

    Octeontx2-af: Broadcast XON on all channels
    
    [ Upstream commit a7bd72158063740212344fad5d99dcef45bc70d6 ]
    
    The NIX block receives traffic from multiple channels, including:
    
    MAC block (RPM)
    Loopback module (LBK)
    CPT block
    
                         RPM
                          |
                    -----------------
           LBK   --|     NIX         |
                    -----------------
                         |
                        CPT
    
    Due to a hardware errata,  CN10k and earlier Octeon silicon series,
    the hardware may incorrectly assert XOFF on certain channels during
    reset. As a workaround, a write operation to the NIX_AF_RX_CHANX_CFG
    register can be performed to broadcast XON signals on the affected
    channels
    
    Signed-off-by: Hariprasad Kelam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dan Carpenter <[email protected]>
Date:   Sat Nov 1 16:26:42 2025 +0300

    octeontx2-pf: Fix devm_kcalloc() error checking
    
    [ Upstream commit 2e25935ed24daee37c4c2e8e29e478ce6e1f72c7 ]
    
    The devm_kcalloc() function never return error pointers, it returns NULL
    on failure.  Also delete the netdev_err() printk.  These allocation
    functions already have debug output built-in some the extra error message
    is not required.
    
    Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: chenmiao <[email protected]>
Date:   Fri Sep 5 18:12:56 2025 +0000

    openrisc: Add R_OR1K_32_PCREL relocation type module support
    
    [ Upstream commit 9d0cb6d00be891586261a35da7f8c3c956825c39 ]
    
    To ensure the proper functioning of the jump_label test module, this patch
    adds support for the R_OR1K_32_PCREL relocation type for any modules. The
    implementation calculates the PC-relative offset by subtracting the
    instruction location from the target value and stores the result at the
    specified location.
    
    Signed-off-by: chenmiao <[email protected]>
    Signed-off-by: Stafford Horne <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mike Marshall <[email protected]>
Date:   Mon Sep 15 17:40:46 2025 -0400

    orangefs: fix xattr related buffer overflow...
    
    [ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ]
    
    Willy Tarreau <[email protected]> forwarded me a message from
    Disclosure <[email protected]> with the following
    warning:
    
    > The helper `xattr_key()` uses the pointer variable in the loop condition
    > rather than dereferencing it. As `key` is incremented, it remains non-NULL
    > (until it runs into unmapped memory), so the loop does not terminate on
    > valid C strings and will walk memory indefinitely, consuming CPU or hanging
    > the thread.
    
    I easily reproduced this with setfattr and getfattr, causing a kernel
    oops, hung user processes and corrupted orangefs files. Disclosure
    sent along a diff (not a patch) with a suggested fix, which I based
    this patch on.
    
    After xattr_key started working right, xfstest generic/069 exposed an
    xattr related memory leak that lead to OOM. xattr_key returns
    a hashed key.  When adding xattrs to the orangefs xattr cache, orangefs
    used hash_add, a kernel hashing macro. hash_add also hashes the key using
    hash_log which resulted in additions to the xattr cache going to the wrong
    hash bucket. generic/069 tortures a single file and orangefs does a
    getattr for the xattr "security.capability" every time. Orangefs
    negative caches on xattrs which includes a kmalloc. Since adds to the
    xattr cache were going to the wrong bucket, every getattr for
    "security.capability" resulted in another kmalloc, none of which were
    ever freed.
    
    I changed the two uses of hash_add to hlist_add_head instead
    and the memory leak ceased and generic/069 quit throwing furniture.
    
    Signed-off-by: Mike Marshall <[email protected]>
    Reported-by: Stanislav Fort of Aisle Research <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Amir Goldstein <[email protected]>
Date:   Wed Aug 27 19:55:26 2025 +0200

    ovl: make sure that ovl_create_real() returns a hashed dentry
    
    [ Upstream commit ad1423922781e6552f18d055a5742b1cff018cdc ]
    
    e8bd877fb76bb9f3 ("ovl: fix possible double unlink") added a sanity
    check of !d_unhashed(child) to try to verify that child dentry was not
    unlinked while parent dir was unlocked.
    
    This "was not unlink" check has a false positive result in the case of
    casefolded parent dir, because in that case, ovl_create_temp() returns
    an unhashed dentry after ovl_create_real() gets an unhashed dentry from
    ovl_lookup_upper() and makes it positive.
    
    To avoid returning unhashed dentry from ovl_create_temp(), let
    ovl_create_real() lookup again after making the newdentry positive,
    so it always returns a hashed positive dentry (or an error).
    
    This fixes the error in ovl_parent_lock() in ovl_check_rename_whiteout()
    after ovl_create_temp() and allows mount of overlayfs with casefolding
    enabled layers.
    
    Reported-by: André Almeida <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Suggested-by: Neil Brown <[email protected]>
    Reviewed-by: Neil Brown <[email protected]>
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jakub Kicinski <[email protected]>
Date:   Fri Sep 12 09:17:03 2025 -0700

    page_pool: always add GFP_NOWARN for ATOMIC allocations
    
    [ Upstream commit f3b52167a0cb23b27414452fbc1278da2ee884fc ]
    
    Driver authors often forget to add GFP_NOWARN for page allocation
    from the datapath. This is annoying to users as OOMs are a fact
    of life, and we pretty much expect network Rx to hit page allocation
    failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations
    by default.
    
    Reviewed-by: Mina Almasry <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dragos Tatulea <[email protected]>
Date:   Fri Sep 26 16:16:05 2025 +0300

    page_pool: Clamp pool size to max 16K pages
    
    [ Upstream commit a1b501a8c6a87c9265fd03bd004035199e2e8128 ]
    
    page_pool_init() returns E2BIG when the page_pool size goes above 32K
    pages. As some drivers are configuring the page_pool size according to
    the MTU and ring size, there are cases where this limit is exceeded and
    the queue creation fails.
    
    The page_pool size doesn't have to cover a full queue, especially for
    larger ring size. So clamp the size instead of returning an error. Do
    this in the core to avoid having each driver do the clamping.
    
    The current limit was deemed to high [1] so it was reduced to 16K to avoid
    page waste.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Signed-off-by: Dragos Tatulea <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Helge Deller <[email protected]>
Date:   Mon Nov 3 22:38:26 2025 +0100

    parisc: Avoid crash due to unaligned access in unwinder
    
    commit fd9f30d1038ee1624baa17a6ff11effe5f7617cb upstream.
    
    Guenter Roeck reported this kernel crash on his emulated B160L machine:
    
    Starting network: udhcpc: started, v1.36.1
     Backtrace:
      [<104320d4>] unwind_once+0x1c/0x5c
      [<10434a00>] walk_stackframe.isra.0+0x74/0xb8
      [<10434a6c>] arch_stack_walk+0x28/0x38
      [<104e5efc>] stack_trace_save+0x48/0x5c
      [<105d1bdc>] set_track_prepare+0x44/0x6c
      [<105d9c80>] ___slab_alloc+0xfc4/0x1024
      [<105d9d38>] __slab_alloc.isra.0+0x58/0x90
      [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0
      [<105b8e54>] __anon_vma_prepare+0x60/0x280
      [<105a823c>] __vmf_anon_prepare+0x68/0x94
      [<105a8b34>] do_wp_page+0x8cc/0xf10
      [<105aad88>] handle_mm_fault+0x6c0/0xf08
      [<10425568>] do_page_fault+0x110/0x440
      [<10427938>] handle_interruption+0x184/0x748
      [<11178398>] schedule+0x4c/0x190
      BUG: spinlock recursion on CPU#0, ifconfig/2420
      lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0
    
    While creating the stack trace, the unwinder uses the stack pointer to guess
    the previous frame to read the previous stack pointer from memory.  The crash
    happens, because the unwinder tries to read from unaligned memory and as such
    triggers the unalignment trap handler which then leads to the spinlock
    recursion and finally to a deadlock.
    
    Fix it by checking the alignment before accessing the memory.
    
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Cc: [email protected] # v6.12+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Vernon Yang <[email protected]>
Date:   Fri Sep 5 02:25:27 2025 +0800

    PCI/AER: Fix NULL pointer access by aer_info
    
    [ Upstream commit 0a27bdb14b028fed30a10cec2f945c38cb5ca4fa ]
    
    The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx
    will result in kernel panic. Fix it.
    
    Signed-off-by: Vernon Yang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lukas Wunner <[email protected]>
Date:   Wed Aug 13 07:11:04 2025 +0200

    PCI/ERR: Update device error_state already after reset
    
    [ Upstream commit 45bc82563d5505327d97963bc54d3709939fa8f8 ]
    
    After a Fatal Error has been reported by a device and has been recovered
    through a Secondary Bus Reset, AER updates the device's error_state to
    pci_channel_io_normal before invoking its driver's ->resume() callback.
    
    By contrast, EEH updates the error_state earlier, namely after resetting
    the device and before invoking its driver's ->slot_reset() callback.
    Commit c58dc575f3c8 ("powerpc/pseries: Set error_state to
    pci_channel_io_normal in eeh_report_reset()") explains in great detail
    that the earlier invocation is necessitated by various drivers checking
    accessibility of the device with pci_channel_offline() and avoiding
    accesses if it returns true.  It returns true for any other error_state
    than pci_channel_io_normal.
    
    The device should be accessible already after reset, hence the reasoning
    is that it's safe to update the error_state immediately afterwards.
    
    This deviation between AER and EEH seems problematic because drivers
    behave differently depending on which error recovery mechanism the
    platform uses.  Three drivers have gone so far as to update the
    error_state themselves, presumably to work around AER's behavior.
    
    For consistency, amend AER to update the error_state at the same recovery
    steps as EEH.  Drop the now unnecessary workaround from the three drivers.
    
    Keep updating the error_state before ->resume() in case ->error_detected()
    or ->mmio_enabled() return PCI_ERS_RESULT_RECOVERED, which causes
    ->slot_reset() to be skipped.  There are drivers doing this even for Fatal
    Errors, e.g. mhi_pci_error_detected().
    
    Signed-off-by: Lukas Wunner <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/4517af6359ffb9d66152b827a5d2833459144e3f.1755008151.git.lukas@wunner.de
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sungho Kim <[email protected]>
Date:   Wed Aug 20 19:57:14 2025 +0900

    PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call
    
    [ Upstream commit 6238784e502b6a9fbeb3a6b77284b29baa4135cc ]
    
    The error handling path in pci_p2pdma_add_resource() contains a bug in its
    `pgmap_free` label.
    
    Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored
    in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`,
    which is a pointer to a member field within the `p2p_pgmap` struct, not the
    base pointer of the allocation.
    
    Correct the bug by passing the correct base pointer, `p2p_pgmap`, to
    devm_kfree().
    
    Signed-off-by: Sungho Kim <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Mon Sep 8 22:19:15 2025 -0500

    PCI/PM: Skip resuming to D0 if device is disconnected
    
    [ Upstream commit 299fad4133677b845ce962f78c9cf75bded63f61 ]
    
    When a device is surprise-removed (e.g., due to a dock unplug), the PCI
    core unconfigures all downstream devices and sets their error state to
    pci_channel_io_perm_failure. This marks them as disconnected via
    pci_dev_is_disconnected().
    
    During device removal, the runtime PM framework may attempt to resume the
    device to D0 via pm_runtime_get_sync(), which calls into pci_power_up().
    Since the device is already disconnected, this resume attempt is
    unnecessary and results in a predictable errors like this, typically when
    undocking from a TBT3 or USB4 dock with PCIe tunneling:
    
      pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
    
    Avoid powering up disconnected devices by checking their status early in
    pci_power_up() and returning -EIO.
    
    Suggested-by: Lukas Wunner <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    [bhelgaas: add typical message]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Lukas Wunner <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Acked-by: Rafael J. Wysocki <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chen Wang <[email protected]>
Date:   Fri Sep 12 10:36:01 2025 +0800

    PCI: cadence: Check for the existence of cdns_pcie::ops before using it
    
    [ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ]
    
    cdns_pcie::ops might not be populated by all the Cadence glue drivers. This
    is going to be true for the upcoming Sophgo platform which doesn't set the
    ops.
    
    Hence, add a check to prevent NULL pointer dereference.
    
    Signed-off-by: Chen Wang <[email protected]>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Marcos Del Sol Vives <[email protected]>
Date:   Sun Jul 6 01:32:08 2025 +0200

    PCI: Disable MSI on RDC PCI to PCIe bridges
    
    [ Upstream commit ebc7086b39e5e4f3d3ca82caaea20538c9b62d42 ]
    
    RDC PCI to PCIe bridges, present on Vortex86DX3 and Vortex86EX2 SoCs, do
    not support MSIs. If enabled, interrupts generated by PCIe devices never
    reach the processor.
    
    I have contacted the manufacturer (DM&P) and they confirmed that PCI MSIs
    need to be disabled for them.
    
    Signed-off-by: Marcos Del Sol Vives <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Cassel <[email protected]>
Date:   Mon Sep 8 18:59:15 2025 +0200

    PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify()
    
    [ Upstream commit 09fefb24ed5e15f3b112f6c04b21a90ea23eaf8b ]
    
    dw_pcie_edma_irq_verify() is supposed to verify the eDMA IRQs in devicetree
    by fetching them using either 'dma' or 'dmaX' IRQ names. Former is used
    when the platform uses a single IRQ for all eDMA channels and latter is
    used when the platform uses separate IRQ per channel. But currently,
    dw_pcie_edma_irq_verify() bails out early if edma::nr_irqs is 1, i.e., when
    a single IRQ is used. This gives an impression that the driver could work
    with any single IRQ in devicetree, not necessarily with name 'dma'.
    
    But dw_pcie_edma_irq_vector(), which actually requests the IRQ, does
    require the single IRQ to be named as 'dma'. So this creates inconsistency
    between dw_pcie_edma_irq_verify() and dw_pcie_edma_irq_vector().
    
    Thus, to fix this inconsistency, make sure dw_pcie_edma_irq_verify() also
    verifies the single IRQ name by removing the bail out code.
    
    Signed-off-by: Niklas Cassel <[email protected]>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    [bhelgaas: fix typos]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Marek Vasut <[email protected]>
Date:   Fri Sep 5 20:42:10 2025 +0200

    PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs
    
    [ Upstream commit d5f6bd3ee3f5048f272182dc91675c082773999e ]
    
    Currently, the test allocates BAR sizes according to fixed table bar_size.
    This does not work with controllers which have fixed size BARs that are
    smaller than the requested BAR size. One such controller is Renesas R-Car
    V4H PCIe controller, which has BAR4 size limited to 256 bytes, which is
    much less than one of the BAR size, 131072 currently requested by this
    test. A lot of controllers drivers in-tree have fixed size BARs, and they
    do work perfectly fine, but it is only because their fixed size is larger
    than the size requested by pci-epf-test.c
    
    Adjust the test such that in case a fixed size BAR is detected, the fixed
    BAR size is used, as that is the only possible option.
    
    This helps with test failures reported as follows:
    
      pci_epf_test pci_epf_test.0: requested BAR size is larger than fixed size
      pci_epf_test pci_epf_test.0: Failed to allocate space for BAR4
    
    Signed-off-by: Marek Vasut <[email protected]>
    [mani: reworded description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Niklas Cassel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Richard Zhu <[email protected]>
Date:   Wed Aug 20 10:23:28 2025 +0800

    PCI: imx6: Enable the Vaux supply if available
    
    [ Upstream commit c221cbf8dc547eb8489152ac62ef103fede99545 ]
    
    When the 3.3Vaux supply is present, fetch it at the probe time and keep it
    enabled for the entire PCIe controller lifecycle so that the link can enter
    L2 state and the devices can signal wakeup using either Beacon or WAKE#
    mechanisms.
    
    Signed-off-by: Richard Zhu <[email protected]>
    [mani: reworded the subject, description and error message]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dapeng Mi <[email protected]>
Date:   Wed Oct 15 13:18:28 2025 +0800

    perf/core: Fix system hang caused by cpu-clock usage
    
    commit eb3182ef0405ff2f6668fd3e5ff9883f60ce8801 upstream.
    
    cpu-clock usage by the async-profiler tool can trigger a system hang,
    which got bisected back to the following commit by Octavia Togami:
    
      18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage") causes this issue
    
    The root cause of the hang is that cpu-clock is a special type of SW
    event which relies on hrtimers. The __perf_event_overflow() callback
    is invoked from the hrtimer handler for cpu-clock events, and
    __perf_event_overflow() tries to call cpu_clock_event_stop()
    to stop the event, which calls htimer_cancel() to cancel the hrtimer.
    
    But that's a recursion into the hrtimer code from a hrtimer handler,
    which (unsurprisingly) deadlocks.
    
    To fix this bug, use hrtimer_try_to_cancel() instead, and set
    the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer()
    to stop the event once it sees the PERF_HES_STOPPED flag.
    
    [ mingo: Fixed the comments and improved the changelog. ]
    
    Closes: https://lore.kernel.org/all/CAHPNGSQpXEopYreir+uDDEbtXTBvBvi8c6fYXJvceqtgTPao3Q@mail.gmail.com/
    Fixes: 18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage")
    Reported-by: Octavia Togami <[email protected]>
    Suggested-by: Peter Zijlstra <[email protected]>
    Signed-off-by: Dapeng Mi <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Octavia Togami <[email protected]>
    Cc: [email protected]
    Link: https://github.com/lucko/spark/issues/530
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Dapeng Mi <[email protected]>
Date:   Tue Oct 28 14:42:14 2025 +0800

    perf/x86/intel: Fix KASAN global-out-of-bounds warning
    
    commit 0ba6502ce167fc3d598c08c2cc3b4ed7ca5aa251 upstream.
    
    When running "perf mem record" command on CWF, the below KASAN
    global-out-of-bounds warning is seen.
    
      ==================================================================
      BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0
      Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
    
      Call Trace:
    
       kasan_report+0xb8/0xf0
       cmt_latency_data+0x176/0x1b0
       setup_arch_pebs_sample_data+0xf49/0x2560
       intel_pmu_drain_arch_pebs+0x577/0xb00
       handle_pmi_common+0x6c4/0xc80
    
    The issue is caused by below code in __grt_latency_data(). The code
    tries to access x86_hybrid_pmu structure which doesn't exist on
    non-hybrid platform like CWF.
    
            WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
    
    So add is_hybrid() check before calling this WARN_ON_ONCE to fix the
    global-out-of-bounds access issue.
    
    Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions")
    Reported-by: Xudong Hao <[email protected]>
    Signed-off-by: Dapeng Mi <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Zide Chen <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Harikrishna Shenoy <[email protected]>
Date:   Thu Aug 7 10:50:02 2025 +0530

    phy: cadence: cdns-dphy: Enable lower resolutions in dphy
    
    [ Upstream commit 43bd2c44515f8ee5c019ce6e6583f5640387a41b ]
    
    Enable support for data lane rates between 80-160 Mbps cdns dphy
    as mentioned in TRM [0] by setting the pll_opdiv field to 16.
    This change enables lower resolutions like 640x480 at 60Hz.
    
    [0]: https://www.ti.com/lit/zip/spruil1
    (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions)
    
    Reviewed-by: Udit Kumar <[email protected]>
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Signed-off-by: Harikrishna Shenoy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Dege <[email protected]>
Date:   Thu Jul 3 13:07:24 2025 +0200

    phy: renesas: r8a779f0-ether-serdes: add new step added to latest datasheet
    
    [ Upstream commit e4a8db93b5ec9bca1cc66b295544899e3afd5e86 ]
    
    R-Car S4-8 datasheet Rev.1.20 describes some additional register
    settings at the end of the initialization.
    
    Signed-off-by: Michael Dege <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Riesch <[email protected]>
Date:   Wed Sep 3 19:04:52 2025 +0200

    phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0
    
    [ Upstream commit 8c7c19466c854fa86b82d2148eaa9bf0e6531423 ]
    
    The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset
    value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF
    this offset is perfectly fine (in fact, register 0 is the only one in
    this register file).
    Introduce a boolean variable to indicate valid registers and allow writes
    to register 0.
    
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Michael Riesch <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bartosz Golaszewski <[email protected]>
Date:   Tue Sep 2 13:59:17 2025 +0200

    pinctrl: keembay: release allocated memory in detach path
    
    [ Upstream commit aae7a2876c3b39d07aa7655ea082af8e7862f3a5 ]
    
    Unlike all the other allocations in this driver, the memory for storing
    the pin function descriptions allocated with kcalloc() and later resized
    with krealloc() is never freed. Use devres like elsewhere to handle
    that. While at it - replace krealloc() with more suitable
    devm_krealloc_array().
    
    Note: the logic in this module is pretty convoluted and could probably
    use some revisiting, we should probably be able to calculate the exact
    amount of memory needed in advance or even skip the allocation
    altogether and just add each function to the radix tree separately.
    
    Tested-by: Neil Armstrong <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Biju Das <[email protected]>
Date:   Tue Aug 19 09:40:20 2025 +0100

    pinctrl: renesas: rzg2l: Add suspend/resume support for Schmitt control registers
    
    [ Upstream commit 837afa592c6234be82acb5d23e0a39e9befdaa85 ]
    
    Renesas RZ/G3E supports a power-saving mode where power to most of the
    SoC components is lost, including the PIN controller.  Save and restore
    the Schmitt control register contents to ensure the functionality is
    preserved after a suspend/resume cycle.
    
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Claudiu Beznea <[email protected]>
    Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chi Zhang <[email protected]>
Date:   Thu Aug 7 14:20:38 2025 +0800

    pinctrl: single: fix bias pull up/down handling in pin_config_set
    
    [ Upstream commit 236152dd9b1675a35eee912e79e6c57ca6b6732f ]
    
    In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or
    PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias()
    which writes the register. However, the subsequent operations continue
    using the stale 'data' value from before the register write, effectively
    causing the bias clear operation to be overwritten and not take effect.
    
    Fix this by reading the 'data' value from the register after calling
    pcs_pinconf_clear_bias().
    
    This bug seems to have existed when this code was first merged in commit
    9dddb4df90d1 ("pinctrl: single: support generic pinconf").
    
    Signed-off-by: Chi Zhang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shyam Sundar S K <[email protected]>
Date:   Mon Sep 1 16:31:33 2025 +0530

    platform/x86/amd/pmf: Fix the custom bios input handling mechanism
    
    [ Upstream commit d82e3d2dd0ba019ac6cdd81e47bf4c8ac895cfa0 ]
    
    Originally, the 'amd_pmf_get_custom_bios_inputs()' function was written
    under the assumption that the BIOS would only send a single pending
    request for the driver to process. However, following OEM enablement, it
    became clear that multiple pending requests for custom BIOS inputs might
    be sent at the same time, a scenario that the current code logic does not
    support when it comes to handling multiple custom BIOS inputs.
    
    To address this, the code logic needs to be improved to not only manage
    multiple simultaneous custom BIOS inputs but also to ensure it is scalable
    for future additional inputs.
    
    Co-developed-by: Patil Rajesh Reddy <[email protected]>
    Signed-off-by: Patil Rajesh Reddy <[email protected]>
    Tested-by: Yijun Shen <[email protected]>
    Signed-off-by: Shyam Sundar S K <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Srinivas Pandruvada <[email protected]>
Date:   Tue Aug 19 14:10:34 2025 -0700

    platform/x86/intel-uncore-freq: Fix warning in partitioned system
    
    [ Upstream commit 6d47b4f08436cb682fb2644e6265a3897fd42a77 ]
    
    A partitioned system configured with only one package and one compute
    die, warning will be generated for duplicate sysfs entry. This typically
    occurs during the platform bring-up phase.
    
    Partitioned systems expose dies, equivalent to TPMI compute domains,
    through the CPUID. Each partitioned system must contains at least one
    compute die per partition, resulting in a minimum of two dies per
    package. Hence the function topology_max_dies_per_package() returns at
    least two, and the condition "topology_max_dies_per_package() > 1"
    prevents the creation of a root domain.
    
    In this case topology_max_dies_per_package() will return 1 and root
    domain will be created for partition 0 and a duplicate sysfs warning
    for partition 1 as both partitions have same package ID.
    
    To address this also check for non zero partition in addition to
    topology_max_dies_per_package() > 1.
    
    Signed-off-by: Srinivas Pandruvada <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Srinivas Pandruvada <[email protected]>
Date:   Wed Sep 3 12:11:54 2025 -0700

    platform/x86/intel-uncore-freq: Present unique domain ID per package
    
    [ Upstream commit a191224186ec16a4cb1775b2a647ea91f5c139e1 ]
    
    In partitioned systems, the domain ID is unique in the partition and a
    package can have multiple partitions.
    
    Some user-space tools, such as turbostat, assume the domain ID is unique
    per package. These tools map CPU power domains, which are unique to a
    package. However, this approach does not work in partitioned systems.
    
    There is no architectural definition of "partition" to present to user
    space.
    
    To support these tools, set the domain_id to be unique per package. For
    compute die IDs, uniqueness can be achieved using the platform info
    cdie_mask, mirroring the behavior observed in non-partitioned systems.
    
    For IO dies, which lack a direct CPU relationship, any unique logical
    ID can be assigned. Here domain IDs for IO dies are configured after all
    compute domain IDs. During the probe, keep the index of the next IO
    domain ID after the last IO domain ID of the current partition. Since
    CPU packages are symmetric, partition information is same for all
    packages.
    
    The Intel Speed Select driver has already implemented a similar change
    to make the domain ID unique, with compute dies listed first, followed
    by I/O dies.
    
    Signed-off-by: Srinivas Pandruvada <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Qiu Wenbo <[email protected]>
Date:   Tue Oct 28 14:30:09 2025 +0800

    platform/x86: int3472: Fix double free of GPIO device during unregister
    
    commit f0f7a3f542c1698edb69075f25a3f846207facba upstream.
    
    regulator_unregister() already frees the associated GPIO device. On
    ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
    random failures when other drivers (typically Intel THC) attempt to
    allocate interrupts. The root cause is that the reference count of the
    pinctrl_intel_platform module unexpectedly drops to zero when this
    driver defers its probe.
    
    This behavior can also be reproduced by unloading the module directly.
    
    Fix the issue by removing the redundant release of the GPIO device
    during regulator unregistration.
    
    Cc: [email protected]
    Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
    Signed-off-by: Qiu Wenbo <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Sakari Ailus <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Reviewed-by: Daniel Scally <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mark Pearson <[email protected]>
Date:   Wed Sep 3 13:38:14 2025 -0400

    platform/x86: think-lmi: Add extra TC BIOS error messages
    
    [ Upstream commit a0d6959c345d89d811288a718e3f6b145dcadc8c ]
    
    Add extra error messages that are used by ThinkCenter platforms.
    
    Signed-off-by: Kean Ren <[email protected]>
    Signed-off-by: Mark Pearson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Sat Sep 20 22:07:13 2025 +0200

    platform/x86: x86-android-tablets: Stop using EPROBE_DEFER
    
    [ Upstream commit 01fd7cf3534aa107797d130f461ba7bcad30414d ]
    
    Since the x86-android-tablets code uses platform_create_bundle() it cannot
    use EPROBE_DEFER and the driver-core will translate EPROBE_DEFER to ENXIO.
    
    Stop using EPROBE_DEFER instead log an error and return ENODEV, or for
    non-fatal cases log a warning and return 0.
    
    Reviewed-by: Dmitry Torokhov <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Nov 2 09:25:45 2025 -0500

    PM: hibernate: Combine return paths in power_down()
    
    [ Upstream commit 1f5bcfe91ffce71bdd1022648b9d501d46d20c09 ]
    
    To avoid code duplication and improve clarity, combine the code
    paths in power_down() leading to a return from that function.
    
    No intentional functional impact.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Mario Limonciello (AMD) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Changed the new label name to "exit" ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: 35e4a69b2003 ("PM: sleep: Allow pm_restrict_gfp_mask() stacking")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Nov 2 09:25:46 2025 -0500

    PM: sleep: Allow pm_restrict_gfp_mask() stacking
    
    [ Upstream commit 35e4a69b2003f20a69e7d19ae96ab1eef1aa8e8d ]
    
    Allow pm_restrict_gfp_mask() to be called many times in a row to avoid
    issues with calling dpm_suspend_start() when the GFP mask has been
    already restricted.
    
    Only the first invocation of pm_restrict_gfp_mask() will actually
    restrict the GFP mask and the subsequent calls will warn if there is
    a mismatch between the expected allowed GFP mask and the actual one.
    
    Moreover, if pm_restrict_gfp_mask() is called many times in a row,
    pm_restore_gfp_mask() needs to be called matching number of times in
    a row to actually restore the GFP mask.  Calling it when the GFP mask
    has not been restricted will cause it to warn.
    
    This is necessary for the GFP mask restriction starting in
    hibernation_snapshot() to continue throughout the entire hibernation
    flow until it completes or it is aborted (either by a wakeup event or
    by an error).
    
    Fixes: 449c9c02537a1 ("PM: hibernate: Restrict GFP mask in hibernation_snapshot()")
    Fixes: 469d80a3712c ("PM: hibernate: Fix hybrid-sleep")
    Reported-by: Askar Safin <[email protected]>
    Closes: https://lore.kernel.org/linux-pm/[email protected]/
    Link: https://lore.kernel.org/linux-pm/[email protected]/
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Mario Limonciello (AMD) <[email protected]>
    Tested-by: Mario Limonciello (AMD) <[email protected]>
    Cc: 6.16+ <[email protected]> # 6.16+
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Janne Grunau <[email protected]>
Date:   Thu Aug 28 16:01:22 2025 +0200

    pmdomain: apple: Add "apple,t8103-pmgr-pwrstate"
    
    [ Upstream commit 442816f97a4f84cb321d3359177a3b9b0ce48a60 ]
    
    After discussion with the devicetree maintainers we agreed to not extend
    lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use
    "apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC the
    driver and bindings were written for.
    
    [1]: https://lore.kernel.org/asahi/[email protected]/
    
    Signed-off-by: Janne Grunau <[email protected]>
    Acked-by: Ulf Hansson <[email protected]>
    Reviewed-by: Neal Gompa <[email protected]>
    Acked-by: Rob Herring (Arm) <[email protected]>
    Signed-off-by: Sven Peter <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christopher Ruehl <[email protected]>
Date:   Mon Aug 11 17:22:09 2025 +0200

    power: supply: qcom_battmgr: add OOI chemistry
    
    [ Upstream commit fee0904441325d83e7578ca457ec65a9d3f21264 ]
    
    The ASUS S15 xElite model report the Li-ion battery with an OOI, hence this
    update the detection and return the appropriate type.
    
    Signed-off-by: Christopher Ruehl <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fenglin Wu <[email protected]>
Date:   Fri Sep 19 11:18:51 2025 +0800

    power: supply: qcom_battmgr: handle charging state change notifications
    
    [ Upstream commit 41307ec7df057239aae3d0f089cc35a0d735cdf8 ]
    
    The X1E80100 battery management firmware sends a notification with
    code 0x83 when the battery charging state changes, such as switching
    between fast charge, taper charge, end of charge, or any other error
    charging states.
    
    The same notification code is used with bit[8] set when charging stops
    because the charge control end threshold is reached. Additionally,
    a 2-bit value is included in bit[10:9] with the same code to indicate
    the charging source capability, which is determined by the calculated
    power from voltage and current readings from PDOs: 2 means a strong
    charger over 60W, 1 indicates a weak charger, and 0 means there is no
    charging source.
    
    These 3-MSB [10:8] in the notification code is not much useful for now,
    hence just ignore them and trigger a power supply change event whenever
    0x83 notification code is received. This helps to eliminate the unknown
    notification error messages.
    
    Reported-by: Sebastian Reichel <[email protected]>
    Closes: https://lore.kernel.org/all/r65idyc4of5obo6untebw4iqfj2zteiggnnzabrqtlcinvtddx@xc4aig5abesu/
    Signed-off-by: Fenglin Wu <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fabien Proriol <[email protected]>
Date:   Mon Jul 7 17:55:08 2025 +0200

    power: supply: sbs-charger: Support multiple devices
    
    [ Upstream commit 3ec600210849cf122606e24caab85f0b936cf63c ]
    
    If we have 2 instances of sbs-charger in the DTS, the driver probe for the second instance will fail:
    
    [    8.012874] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered
    [    8.039094] sbs-charger 18-0009: ltc4100: smart charger device registered
    [    8.112911] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered
    [    8.134533] sysfs: cannot create duplicate filename '/class/power_supply/sbs-charger'
    [    8.143871] CPU: 3 PID: 295 Comm: systemd-udevd Tainted: G           O      5.10.147 #22
    [    8.151974] Hardware name: ALE AMB (DT)
    [    8.155828] Call trace:
    [    8.158292]  dump_backtrace+0x0/0x1d4
    [    8.161960]  show_stack+0x18/0x6c
    [    8.165280]  dump_stack+0xcc/0x128
    [    8.168687]  sysfs_warn_dup+0x60/0x7c
    [    8.172353]  sysfs_do_create_link_sd+0xf0/0x100
    [    8.176886]  sysfs_create_link+0x20/0x40
    [    8.180816]  device_add+0x270/0x7a4
    [    8.184311]  __power_supply_register+0x304/0x560
    [    8.188930]  devm_power_supply_register+0x54/0xa0
    [    8.193644]  sbs_probe+0xc0/0x214 [sbs_charger]
    [    8.198183]  i2c_device_probe+0x2dc/0x2f4
    [    8.202196]  really_probe+0xf0/0x510
    [    8.205774]  driver_probe_device+0xfc/0x160
    [    8.209960]  device_driver_attach+0xc0/0xcc
    [    8.214146]  __driver_attach+0xc0/0x170
    [    8.218002]  bus_for_each_dev+0x74/0xd4
    [    8.221862]  driver_attach+0x24/0x30
    [    8.225444]  bus_add_driver+0x148/0x250
    [    8.229283]  driver_register+0x78/0x130
    [    8.233140]  i2c_register_driver+0x4c/0xe0
    [    8.237250]  sbs_driver_init+0x20/0x1000 [sbs_charger]
    [    8.242424]  do_one_initcall+0x50/0x1b0
    [    8.242434]  do_init_module+0x44/0x230
    [    8.242438]  load_module+0x2200/0x27c0
    [    8.242442]  __do_sys_finit_module+0xa8/0x11c
    [    8.242447]  __arm64_sys_finit_module+0x20/0x30
    [    8.242457]  el0_svc_common.constprop.0+0x64/0x154
    [    8.242464]  do_el0_svc+0x24/0x8c
    [    8.242474]  el0_svc+0x10/0x20
    [    8.242481]  el0_sync_handler+0x108/0x114
    [    8.242485]  el0_sync+0x180/0x1c0
    [    8.243847] sbs-charger 20-0009: Failed to register power supply
    [    8.287934] sbs-charger: probe of 20-0009 failed with error -17
    
    This is mainly because the "name" field of power_supply_desc is a constant.
    This patch fixes the issue by reusing the same approach as sbs-battery.
    With this patch, the result is:
    [    7.819532] sbs-charger 18-0009: ltc4100: smart charger device registered
    [    7.825305] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered
    [    7.887423] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered
    [    7.893501] sbs-charger 20-0009: ltc4100: smart charger device registered
    
    Signed-off-by: Fabien Proriol <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Niklas Schnelle <[email protected]>
Date:   Thu Aug 7 15:55:40 2025 +0200

    powerpc/eeh: Use result of error_detected() in uevent
    
    [ Upstream commit 704e5dd1c02371dfc7d22e1520102b197a3b628b ]
    
    Ever since uevent support was added for AER and EEH with commit
    856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume"), it
    reported PCI_ERS_RESULT_NONE as uevent when recovery begins.
    
    Commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for
    udev") subsequently amended AER to report the actual return value of
    error_detected().
    
    Make the same change to EEH to align it with AER and s390.
    
    Suggested-by: Lukas Wunner <[email protected]>
    Link: https://lore.kernel.org/linux-pci/[email protected]/
    Signed-off-by: Niklas Schnelle <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Lukas Wunner <[email protected]>
    Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
    Acked-by: Mahesh Salgaonkar <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miroslav Lichvar <[email protected]>
Date:   Thu Aug 28 12:32:53 2025 +0200

    ptp: Limit time setting of PTP clocks
    
    [ Upstream commit 5a8c02a6bf52b1cf9cfb7868a8330f7c3c6aebe9 ]
    
    Networking drivers implementing PTP clocks and kernel socket code
    handling hardware timestamps use the 64-bit signed ktime_t type counting
    nanoseconds. When a PTP clock reaches the maximum value in year 2262,
    the timestamps returned to applications will overflow into year 1667.
    The same thing happens when injecting a large offset with
    clock_adjtime(ADJ_SETOFFSET).
    
    The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting
    CLOCK_REALTIME") limited the maximum accepted value setting the system
    clock to 30 years before the maximum representable value (i.e. year
    2232) to avoid the overflow, assuming the system will not run for more
    than 30 years.
    
    Enforce the same limit for PTP clocks. Don't allow negative values and
    values closer than 30 years to the maximum value. Drivers may implement
    an even lower limit if the hardware registers cannot represent the whole
    interval between years 1970 and 2262 in the required resolution.
    
    Signed-off-by: Miroslav Lichvar <[email protected]>
    Cc: Richard Cochran <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: John Stultz <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Reviewed-by: Vadim Fedorenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vadim Fedorenko <[email protected]>
Date:   Thu Sep 18 13:11:46 2025 +0000

    ptp_ocp: make ptp_ocp driver compatible with PTP_EXTTS_REQUEST2
    
    [ Upstream commit d3ca2ef0c915d219e0d958e0bdcc4be6c02c210b ]
    
    Originally ptp_ocp driver was not strictly checking flags for external
    timestamper and was always activating rising edge timestamping as it's
    the only supported mode. Recent changes to ptp made it incompatible with
    PTP_EXTTS_REQUEST2 ioctl. Adjust ptp_clock_info to provide supported
    mode and be compatible with new infra.
    
    While at here remove explicit check of periodic output flags from the
    driver and provide supported flags for ptp core to check.
    
    Signed-off-by: Vadim Fedorenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Uwe Kleine-König <[email protected]>
Date:   Tue Jul 29 12:36:01 2025 +0200

    pwm: pca9685: Use bulk write to atomicially update registers
    
    [ Upstream commit de5855613263b426ee697dd30224322f2e634dec ]
    
    The output of a PWM channel is configured by four register values. Write
    them in a single i2c transaction to ensure glitch free updates.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/bfa8c0267c9ec059d0d77f146998d564654c75ca.1753784092.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: ChunHao Lin <[email protected]>
Date:   Thu Sep 18 10:34:25 2025 +0800

    r8169: set EEE speed down ratio to 1
    
    [ Upstream commit bf7154ffb1c65a201906296a9d3eb22e9daa5ffc ]
    
    EEE speed down means speed down MAC MCU clock. It is not from spec.
    It is kind of Realtek specific power saving feature. But enable it
    may cause some issues, like packet drop or interrupt loss. Different
    hardware may have different issues.
    
    EEE speed down ratio (mac ocp 0xe056[7:4]) is used to set EEE speed
    down rate. The larger this value is, the more power can save. But it
    actually save less power then we expected. And, as mentioned above,
    will impact compatibility. So set it to 1 (mac ocp 0xe056[7:4] = 0)
    , which means not to speed down, to improve compatibility.
    
    Signed-off-by: ChunHao Lin <[email protected]>
    Reviewed-by: Heiner Kallweit <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: YanLong Dai <[email protected]>
Date:   Wed Sep 24 14:14:44 2025 +0800

    RDMA/bnxt_re: Fix a potential memory leak in destroy_gsi_sqp
    
    [ Upstream commit 88de89f184661ebb946804a5abdf2bdec7f0a7ab ]
    
    The current error handling path in bnxt_re_destroy_gsi_sqp() could lead
    to a resource leak. When bnxt_qplib_destroy_qp() fails, the function
    jumps to the 'fail' label and returns immediately, skipping the call
    to bnxt_qplib_free_qp_res().
    
    Continue the resource teardown even if bnxt_qplib_destroy_qp() fails,
    which aligns with the driver's general error handling strategy and
    prevents the potential leak.
    
    Fixes: 8dae419f9ec73 ("RDMA/bnxt_re: Refactor queue pair creation code")
    Signed-off-by: YanLong Dai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chengchang Tang <[email protected]>
Date:   Thu Oct 16 19:40:48 2025 +0800

    RDMA/hns: Fix recv CQ and QP cache affinity
    
    [ Upstream commit c4b67b514af8c2d73c64b36e0cd99e9b26b9ac82 ]
    
    Currently driver enforces affinity between QP cache and send CQ
    cache, which helps improve the performance of sending, but doesn't
    set affinity with recv CQ cache, resulting in suboptimal performance
    of receiving.
    
    Use one CQ bank per context to ensure the affinity among QP, send CQ
    and recv CQ. For kernel ULP, CQ bank is fixed to 0.
    
    Fixes: 9e03dbea2b06 ("RDMA/hns: Fix CQ and QP cache affinity")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: wenglianfa <[email protected]>
Date:   Thu Oct 16 19:40:49 2025 +0800

    RDMA/hns: Fix the modification of max_send_sge
    
    [ Upstream commit f5a7cbea5411668d429eb4ffe96c4063fe8dac9e ]
    
    The actual sge number may exceed the value specified in init_attr->cap
    when HW needs extra sge to enable inline feature. Since these extra
    sges are not expected by ULP, return the user-specified value to ULP
    instead of the expanded sge number.
    
    Fixes: 0c5e259b06a8 ("RDMA/hns: Fix incorrect sge nums calculation")
    Signed-off-by: wenglianfa <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Junxian Huang <[email protected]>
Date:   Thu Oct 16 19:40:50 2025 +0800

    RDMA/hns: Fix wrong WQE data when QP wraps around
    
    [ Upstream commit fe9622011f955e35ba84d3af7b2f2fed31cf8ca1 ]
    
    When QP wraps around, WQE data from the previous use at the same
    position still remains as driver does not clear it. The WQE field
    layout differs across different opcodes, causing that the fields
    that are not explicitly assigned for the current opcode retain
    stale values, and are issued to HW by mistake. Such fields are as
    follows:
    
    * MSG_START_SGE_IDX field in ATOMIC WQE
    * BLOCK_SIZE and ZBVA fields in FRMR WQE
    * DirectWQE fields when DirectWQE not used
    
    For ATOMIC WQE, always set the latest sge index in MSG_START_SGE_IDX
    as required by HW.
    
    For FRMR WQE and DirectWQE, clear only those unassigned fields
    instead of the entire WQE to avoid performance penalty.
    
    Fixes: 68a997c5d28c ("RDMA/hns: Add FRMR support for hip08")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jacob Moroni <[email protected]>
Date:   Tue Sep 23 19:08:50 2025 +0000

    RDMA/irdma: Fix SD index calculation
    
    [ Upstream commit 8d158f47f1f33d8747e80c3afbea5aa337e59d41 ]
    
    In some cases, it is possible for pble_rsrc->next_fpm_addr to be
    larger than u32, so remove the u32 cast to avoid unintentional
    truncation.
    
    This fixes the following error that can be observed when registering
    massive memory regions:
    
    [  447.227494] (NULL ib_device): cqp opcode = 0x1f maj_err_code = 0xffff min_err_code = 0x800c
    [  447.227505] (NULL ib_device): [Update PE SDs Cmd Error][op_code=21] status=-5 waiting=1 completion_err=1 maj=0xffff min=0x800c
    
    Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager")
    Signed-off-by: Jacob Moroni <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Acked-by: Tatyana Nikolova <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jacob Moroni <[email protected]>
Date:   Tue Sep 23 14:21:28 2025 +0000

    RDMA/irdma: Remove unused struct irdma_cq fields
    
    [ Upstream commit 880245fd029a8f8ee8fd557c2681d077c1b1a959 ]
    
    These fields were set but not used anywhere, so remove them.
    
    Link: https://patch.msgid.link/r/[email protected]
    Signed-off-by: Jacob Moroni <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Stable-dep-of: 5575b7646b94 ("RDMA/irdma: Set irdma_cq cq_num field during CQ create")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jacob Moroni <[email protected]>
Date:   Tue Sep 23 14:24:39 2025 +0000

    RDMA/irdma: Set irdma_cq cq_num field during CQ create
    
    [ Upstream commit 5575b7646b94c0afb0f4c0d86e00e13cf3397a62 ]
    
    The driver maintains a CQ table that is used to ensure that a CQ is
    still valid when processing CQ related AEs. When a CQ is destroyed,
    the table entry is cleared, using irdma_cq.cq_num as the index. This
    field was never being set, so it was just always clearing out entry
    0.
    
    Additionally, the cq_num field size was increased to accommodate HW
    supporting more than 64K CQs.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Jacob Moroni <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Acked-by: Tatyana Nikolova <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tatyana Nikolova <[email protected]>
Date:   Wed Aug 27 10:25:45 2025 -0500

    RDMA/irdma: Update Kconfig
    
    [ Upstream commit 060842fed53f77a73824c9147f51dc6746c1267a ]
    
    Update Kconfig to add dependency on idpf module and
    add IPU E2000 to the list of supported devices.
    
    Signed-off-by: Tatyana Nikolova <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Tested-by: Jacob Moroni <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konstantin Taranov <[email protected]>
Date:   Tue Jul 29 02:00:18 2025 -0700

    RDMA/mana_ib: Drain send wrs of GSI QP
    
    [ Upstream commit 44d69d3cf2e8047c279cbb9708f05e2c43e33234 ]
    
    Drain send WRs of the GSI QP on device removal.
    
    In rare servicing scenarios, the hardware may delete the
    state of the GSI QP, preventing it from generating CQEs
    for pending send WRs. Since WRs submitted to the GSI QP
    hold CM resources, the device cannot be removed until
    those WRs are completed. This patch marks all pending
    send WRs as failed, allowing the GSI QP to release the CM
    resources and enabling safe device removal.
    
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shuhao Fu <[email protected]>
Date:   Fri Oct 10 10:55:17 2025 +0800

    RDMA/uverbs: Fix umem release in UVERBS_METHOD_CQ_CREATE
    
    [ Upstream commit d8713158faad0fd4418cb2f4e432c3876ad53a1f ]
    
    In `UVERBS_METHOD_CQ_CREATE`, umem should be released if anything goes
    wrong. Currently, if `create_cq_umem` fails, umem would not be
    released or referenced, causing a possible leak.
    
    In this patch, we release umem at `UVERBS_METHOD_CQ_CREATE`, the driver
    should not release umem if it returns an error code.
    
    Fixes: 1a40c362ae26 ("RDMA/uverbs: Add a common way to create CQ with umem")
    Signed-off-by: Shuhao Fu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ujwal Kundur <[email protected]>
Date:   Wed Aug 20 23:25:49 2025 +0530

    rds: Fix endianness annotation for RDS_MPATH_HASH
    
    [ Upstream commit 77907a068717fbefb25faf01fecca553aca6ccaa ]
    
    jhash_1word accepts host endian inputs while rs_bound_port is a be16
    value (sockaddr_in6.sin6_port). Use ntohs() for consistency.
    
    Flagged by Sparse.
    
    Signed-off-by: Ujwal Kundur <[email protected]>
    Reviewed-by: Allison Henderson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shawn Guo <[email protected]>
Date:   Fri Oct 24 16:23:44 2025 +0800

    regmap: irq: Correct documentation of wake_invert flag
    
    commit 48cbf50531d8eca15b8a811717afdebb8677de9b upstream.
    
    Per commit 9442490a0286 ("regmap: irq: Support wake IRQ mask inversion")
    the wake_invert flag is to support enable register, so cleared bits are
    wake disabled.
    
    Fixes: 68622bdfefb9 ("regmap: irq: document mask/wake_invert flags")
    Cc: [email protected]
    Signed-off-by: Shawn Guo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Alexey Klimov <[email protected]>
Date:   Wed Oct 22 21:10:12 2025 +0100

    regmap: slimbus: fix bus_context pointer in regmap init calls
    
    commit 434f7349a1f00618a620b316f091bd13a12bc8d2 upstream.
    
    Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in
    wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.
    That commit breaks audio playback, for instance, on sdm845 Thundercomm
    Dragonboard 845c board:
    
     Unable to handle kernel paging request at virtual address ffff8000847cbad4
     ...
     CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT
     Hardware name: Thundercomm Dragonboard 845c (DT)
     ...
     Call trace:
      slim_xfer_msg+0x24/0x1ac [slimbus] (P)
      slim_read+0x48/0x74 [slimbus]
      regmap_slimbus_read+0x18/0x24 [regmap_slimbus]
      _regmap_raw_read+0xe8/0x174
      _regmap_bus_read+0x44/0x80
      _regmap_read+0x60/0xd8
      _regmap_update_bits+0xf4/0x140
      _regmap_select_page+0xa8/0x124
      _regmap_raw_write_impl+0x3b8/0x65c
      _regmap_bus_raw_write+0x60/0x80
      _regmap_write+0x58/0xc0
      regmap_write+0x4c/0x80
      wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]
      snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]
      __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]
      dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]
      dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]
      snd_pcm_hw_params+0x124/0x464 [snd_pcm]
      snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]
      snd_pcm_ioctl+0x34/0x4c [snd_pcm]
      __arm64_sys_ioctl+0xac/0x104
      invoke_syscall+0x48/0x104
      el0_svc_common.constprop.0+0x40/0xe0
      do_el0_svc+0x1c/0x28
      el0_svc+0x34/0xec
      el0t_64_sync_handler+0xa0/0xf0
      el0t_64_sync+0x198/0x19c
    
    The __devm_regmap_init_slimbus() started to be used instead of
    __regmap_init_slimbus() after the commit mentioned above and turns out
    the incorrect bus_context pointer (3rd argument) was used in
    __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal
    to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or
    the first user of devm_regmap_init_slimbus() but we should fix it till
    the point where __devm_regmap_init_slimbus() was introduced therefore
    two "Fixes" tags.
    
    While at this, also correct the same argument in __regmap_init_slimbus().
    
    Fixes: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()")
    Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support")
    Cc: [email protected]
    Cc: Dmitry Baryshkov <[email protected]>
    Cc: Ma Ke <[email protected]>
    Cc: Steev Klimaszewski <[email protected]>
    Cc: Srinivas Kandagatla <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Signed-off-by: Alexey Klimov <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Stephan Gerhold <[email protected]>
Date:   Wed Aug 20 18:02:34 2025 +0200

    remoteproc: qcom: q6v5: Avoid handling handover twice
    
    [ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ]
    
    A remoteproc could theoretically signal handover twice. This is unexpected
    and would break the reference counting for the handover resources (power
    domains, clocks, regulators, etc), so add a check to prevent that from
    happening.
    
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Stephan Gerhold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andrew Davis <[email protected]>
Date:   Thu Aug 14 10:39:37 2025 -0500

    remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper
    
    [ Upstream commit 461edcf73eec57bc0006fbb5209f5012c514c58b ]
    
    Use device life-cycle managed runtime enable function to simplify probe
    and exit paths.
    
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Frédéric Danis <[email protected]>
Date:   Mon Oct 6 10:35:44 2025 +0200

    Revert "Bluetooth: L2CAP: convert timeouts to secs_to_jiffies()"
    
    commit 76e20da0bd00c556ed0a1e7250bdb6ac3e808ea8 upstream.
    
    This reverts commit c9d84da18d1e0d28a7e16ca6df8e6d47570501d4. It
    replaces in L2CAP calls to msecs_to_jiffies() to secs_to_jiffies()
    and updates the constants accordingly. But the constants are also
    used in LCAP Configure Request and L2CAP Configure Response which
    expect values in milliseconds.
    This may prevent correct usage of L2CAP channel.
    
    To fix it, keep those constants in milliseconds and so revert this
    change.
    
    Fixes: c9d84da18d1e ("Bluetooth: L2CAP: convert timeouts to secs_to_jiffies()")
    Signed-off-by: Frédéric Danis <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Chuck Lever <[email protected]>
Date:   Thu Oct 2 10:00:51 2025 -0400

    Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"
    
    commit 3e7f011c255582d7c914133785bbba1990441713 upstream.
    
    I've found that pynfs COMP6 now leaves the connection or lease in a
    strange state, which causes CLOSE9 to hang indefinitely. I've dug
    into it a little, but I haven't been able to root-cause it yet.
    However, I bisected to commit 48aab1606fa8 ("NFSD: Remove the cap on
    number of operations per NFSv4 COMPOUND").
    
    Tianshuo Han also reports a potential vulnerability when decoding
    an NFSv4 COMPOUND. An attacker can place an arbitrarily large op
    count in the COMPOUND header, which results in:
    
    [   51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total
    pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO),
    nodemask=(null),cpuset=/,mems_allowed=0
    
    when NFSD attempts to allocate the COMPOUND op array.
    
    Let's restore the operation-per-COMPOUND limit, but increased to 200
    for now.
    
    Reported-by: tianshuo han <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Cc: [email protected]
    Tested-by: Tianshuo Han <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Baochen Qiang <[email protected]>
Date:   Mon Oct 27 09:49:12 2025 +0800

    Revert "wifi: ath10k: avoid unnecessary wait for service ready message"
    
    commit 2469bb6a6af944755a7d7daf66be90f3b8decbf9 upstream.
    
    This reverts commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a.
    
    Although this commit benefits QCA6174, it breaks QCA988x and
    QCA9984 [1][2]. Since it is not likely to root cause/fix this
    issue in a short time, revert it to get those chips back.
    
    Compile tested only.
    
    Fixes: 51a73f1b2e56 ("wifi: ath10k: avoid unnecessary wait for service ready message")
    Link: https://lore.kernel.org/ath10k/[email protected] # [1]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220671 # [2]
    Signed-off-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/20251027-ath10k-revert-polling-first-change-v1-1-89aaf3bcbfa1@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Miaoqing Pan <[email protected]>
Date:   Tue Oct 28 14:07:44 2025 +0800

    Revert "wifi: ath12k: Fix missing station power save configuration"
    
    [ Upstream commit 9222582ec524707fbb9d076febead5b6a07611ed ]
    
    This reverts commit 4b66d18918f8e4d85e51974a9e3ce9abad5c7c3d.
    
    In [1], Ross Brown reports poor performance of WCN7850 after enabling
    power save. Temporarily revert the fix; it will be re-enabled once
    the issue is resolved.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00011-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
    
    Fixes: 4b66d18918f8 ("wifi: ath12k: Fix missing station power save configuration")
    Reported-by: Ross Brown <[email protected]>
    Closes: https://lore.kernel.org/all/CAMn66qZENLhDOcVJuwUZ3ir89PVtVnQRq9DkV5xjJn1p6BKB9w@mail.gmail.com/ # [1]
    Signed-off-by: Miaoqing Pan <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Steven Rostedt <[email protected]>
Date:   Thu Oct 16 13:28:48 2025 -0400

    ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up
    
    commit aa997d2d2a0b2e76f4df0f1f12829f02acb4fb6b upstream.
    
    The function ring_buffer_map_get_reader() is a bit more strict than the
    other get reader functions, and except for certain situations the
    rb_get_reader_page() should not return NULL. If it does, it triggers a
    warning.
    
    This warning was triggering but after looking at why, it was because
    another acceptable situation was happening and it wasn't checked for.
    
    If the reader catches up to the writer and there's still data to be read
    on the reader page, then the rb_get_reader_page() will return NULL as
    there's no new page to get.
    
    In this situation, the reader page should not be updated and no warning
    should trigger.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Cc: Vincent Donnefort <[email protected]>
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/[email protected]
    Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions")
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Chenghao Duan <[email protected]>
Date:   Mon Sep 22 14:22:44 2025 +0800

    riscv: bpf: Fix uninitialized symbol 'retval_off'
    
    [ Upstream commit d0bf7cd5df18466d969bb60e8890b74cf96081ca ]
    
    In the __arch_prepare_bpf_trampoline() function, retval_off is only
    meaningful when save_ret is true, so the current logic is correct.
    However, in the original logic, retval_off is only initialized under
    certain conditions; for example, in the fmod_ret logic, the compiler is
    not aware that the flags of the fmod_ret program (prog) have set
    BPF_TRAMP_F_CALL_ORIG, which results in an uninitialized symbol
    compilation warning.
    
    So initialize retval_off unconditionally to fix it.
    
    Signed-off-by: Chenghao Duan <[email protected]>
    Reviewed-by: Pu Lehui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miaoqian Lin <[email protected]>
Date:   Mon Oct 27 11:40:44 2025 -0600

    riscv: Fix memory leak in module_frob_arch_sections()
    
    commit c42458fcf54b3d0bc2ac06667c98dceb43831889 upstream.
    
    The current code directly overwrites the scratch pointer with the
    return value of kvrealloc(). If kvrealloc() fails and returns NULL,
    the original buffer becomes unreachable, causing a memory leak.
    
    Fix this by using a temporary variable to store kvrealloc()'s return
    value and only update the scratch pointer on success.
    
    Found via static anlaysis and this is similar to commit 42378a9ca553
    ("bpf, verifier: Fix memory leak in array reallocation for stack state")
    
    Fixes: be17c0df6795 ("riscv: module: Optimize PLT/GOT entry counting")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Josephine Pfeiffer <[email protected]>
Date:   Mon Oct 27 11:40:43 2025 -0600

    riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro
    
    [ Upstream commit a74f038fa50e0d33b740f44f862fe856f16de6a8 ]
    
    The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of
    seq_puts(). This is both a performance issue and conceptually wrong,
    as the macro name suggests plain string output (puts) but the
    implementation uses formatted output (printf).
    
    The macro is used in ptdump.c:301 to output a newline character. Using
    seq_printf() adds unnecessary overhead for format string parsing when
    outputting this constant string.
    
    This bug was introduced in commit 59c4da8640cc ("riscv: Add support to
    dump the kernel page tables") in 2020, which copied the implementation
    pattern from other architectures that had the same bug.
    
    Fixes: 59c4da8640cc ("riscv: Add support to dump the kernel page tables")
    Signed-off-by: Josephine Pfeiffer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chunyan Zhang <[email protected]>
Date:   Mon Oct 27 11:40:43 2025 -0600

    riscv: stacktrace: Disable KASAN checks for non-current tasks
    
    [ Upstream commit 060ea84a484e852b52b938f234bf9b5503a6c910 ]
    
    Unwinding the stack of a task other than current, KASAN would report
    "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"
    
    There is a same issue on x86 and has been resolved by the commit
    84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks")
    The solution could be applied to RISC-V too.
    
    This patch also can solve the issue:
    https://seclists.org/oss-sec/2025/q4/23
    
    Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
    Co-developed-by: Jiakai Xu <[email protected]>
    Signed-off-by: Jiakai Xu <[email protected]>
    Signed-off-by: Chunyan Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [[email protected]: clean up checkpatch issues]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andrew Davis <[email protected]>
Date:   Thu Jun 19 15:57:22 2025 -0500

    rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table
    
    [ Upstream commit 6e29c30d8ddea6109ea7e0b9f17e7841df0794ea ]
    
    Module aliases are used by userspace to identify the correct module to
    load for a detected hardware. The currently supported RPMSG device IDs for
    this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev".
    
    Use the helper macro MODULE_DEVICE_TABLE(rpmsg) to export the correct
    supported IDs. And while here, to keep backwards compatibility we also add
    the other ID "rpmsg_chrdev" so that it is also still exported as an alias.
    
    This has the side benefit of adding support for some legacy firmware
    which still uses the original "rpmsg_chrdev" ID. This was the ID used for
    this driver before it was upstreamed (as reflected by the module alias).
    
    Signed-off-by: Andrew Davis <[email protected]>
    Acked-by: Hari Nagalla <[email protected]>
    Tested-by: Hari Nagalla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Josua Mayer <[email protected]>
Date:   Mon Aug 25 19:54:09 2025 +0200

    rtc: pcf2127: clear minute/second interrupt
    
    [ Upstream commit a6f1a4f05970664004a9370459c6799c1b2f2dcf ]
    
    PCF2127 can generate interrupt every full second or minute configured
    from control and status register 1, bits MI (1) and SI (0).
    
    On interrupt control register 2 bit MSF (7) is set and must be cleared
    to continue normal operation.
    
    While the driver never enables this interrupt on its own, users or
    firmware may do so - e.g. as an easy way to test the interrupt.
    
    Add preprocessor definition for MSF bit and include it in the irq
    bitmask to ensure minute and second interrupts are cleared when fired.
    
    This fixes an issue where the rtc enters a test mode and becomes
    unresponsive after a second interrupt has fired and is not cleared in
    time. In this state register writes to control registers have no
    effect and the interrupt line is kept asserted [1]:
    
    [1] userspace commands to put rtc into unresponsive state:
    $ i2cget -f -y 2 0x51 0x00
    0x04
    $ i2cset -f -y 2 0x51 0x00 0x05 # set bit 0 SI
    $ i2cget -f -y 2 0x51 0x00
    0x84 # bit 8 EXT_TEST set
    $ i2cset -f -y 2 0x51 0x00 0x05 # try overwrite control register
    $ i2cget -f -y 2 0x51 0x00
    0x84 # no change
    
    Signed-off-by: Josua Mayer <[email protected]>
    Reviewed-by: Bruno Thomsen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bruno Thomsen <[email protected]>
Date:   Tue Sep 2 20:22:35 2025 +0200

    rtc: pcf2127: fix watchdog interrupt mask on pcf2131
    
    [ Upstream commit 87064da2db7be537a7da20a25c18ba912c4db9e1 ]
    
    When using interrupt pin (INT A) as watchdog output all other
    interrupt sources need to be disabled to avoid additional
    resets. Resulting INT_A_MASK1 value is 55 (0x37).
    
    Signed-off-by: Bruno Thomsen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yuta Hayama <[email protected]>
Date:   Wed Oct 15 12:07:05 2025 +0900

    rtc: rx8025: fix incorrect register reference
    
    commit 162f24cbb0f6ec596e7e9f3e91610d79dc805229 upstream.
    
    This code is intended to operate on the CTRL1 register, but ctrl[1] is
    actually CTRL2. Correctly, ctrl[0] is CTRL1.
    
    Signed-off-by: Yuta Hayama <[email protected]>
    Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035")
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Harini T <[email protected]>
Date:   Wed Jul 30 19:51:10 2025 +0530

    rtc: zynqmp: Restore alarm functionality after kexec transition
    
    [ Upstream commit e22f4d1321e0055065f274e20bf6d1dbf4b500f5 ]
    
    During kexec reboots, RTC alarms that are fired during the kernel
    transition experience delayed execution. The new kernel would eventually
    honor these alarms, but the interrupt handlers would only execute after
    the driver probe is completed rather than at the intended alarm time.
    
    This is because pending alarm interrupt status from the previous kernel
    is not properly cleared during driver initialization, causing timing
    discrepancies in alarm delivery.
    
    To ensure precise alarm timing across kexec transitions, enhance the
    probe function to:
    1. Clear any pending alarm interrupt status from previous boot.
    2. Detect existing valid alarms and preserve their state.
    3. Re-enable alarm interrupts for future alarms.
    
    Signed-off-by: Harini T <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miguel Ojeda <[email protected]>
Date:   Wed Oct 29 08:33:44 2025 +0100

    rust: condvar: fix broken intra-doc link
    
    commit 09b1704f5b02c18dd02b21343530463fcfc92c54 upstream.
    
    The future move of pin-init to `syn` uncovers the following broken
    intra-doc link:
    
        error: unresolved link to `crate::pin_init`
          --> rust/kernel/sync/condvar.rs:39:40
           |
        39 | /// instances is with the [`pin_init`](crate::pin_init!) and [`new_condvar`] macros.
           |                                        ^^^^^^^^^^^^^^^^ no item named `pin_init` in module `kernel`
           |
           = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
           = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]`
    
    Currently, when rendered, the link points to a literal `crate::pin_init!`
    URL.
    
    Thus fix it.
    
    Cc: [email protected]
    Fixes: 129e97be8e28 ("rust: pin-init: fix documentation links")
    Reviewed-by: Alice Ryhl <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Miguel Ojeda <[email protected]>
Date:   Wed Oct 29 08:14:06 2025 +0100

    rust: devres: fix private intra-doc link
    
    commit ff4d2ef3874773c9c6173b0f099372bf62252aaf upstream.
    
    The future move of pin-init to `syn` uncovers the following private
    intra-doc link:
    
        error: public documentation for `Devres` links to private item `Self::inner`
           --> rust/kernel/devres.rs:106:7
            |
        106 | /// [`Self::inner`] is guaranteed to be initialized and is always accessed read-only.
            |       ^^^^^^^^^^^ this item is private
            |
            = note: this link will resolve properly if you pass `--document-private-items`
            = note: `-D rustdoc::private-intra-doc-links` implied by `-D warnings`
            = help: to override `-D warnings` add `#[allow(rustdoc::private_intra_doc_links)]`
    
    Currently, when rendered, the link points to "nowhere" (an inexistent
    anchor for a "method").
    
    Thus fix it.
    
    Cc: [email protected]
    Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")
    Acked-by: Danilo Krummrich <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Miguel Ojeda <[email protected]>
Date:   Sun Nov 2 22:28:52 2025 +0100

    rust: kbuild: treat `build_error` and `rustdoc` as kernel objects
    
    commit 16c43a56b79e2c3220b043236369a129d508c65a upstream.
    
    Even if normally `build_error` isn't a kernel object, it should still
    be treated as such so that we pass the same flags. Similarly, `rustdoc`
    targets are never kernel objects, but we need to treat them as such.
    
    Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc`
    will complain about missing sanitizer flags since `-Zsanitizer` is a
    target modifier too [1]:
    
        error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error`
         --> rust/build_error.rs:3:1
          |
        3 | //! Build-time error.
          | ^
          |
          = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
          = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core`
          = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core`
          = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error
    
    Thus explicitly mark them as kernel objects.
    
    Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs).
    Link: https://github.com/rust-lang/rust/pull/138736 [1]
    Reviewed-by: Alice Ryhl <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Miguel Ojeda <[email protected]>
Date:   Sun Nov 2 22:28:53 2025 +0100

    rust: kbuild: workaround `rustdoc` doctests modifier bug
    
    commit fad472efab0a805dd939f017c5b8669a786a4bcf upstream.
    
    The `rustdoc` modifiers bug [1] was fixed in Rust 1.90.0 [2], for which
    we added a workaround in commit abbf9a449441 ("rust: workaround `rustdoc`
    target modifiers bug").
    
    However, `rustdoc`'s doctest generation still has a similar issue [3],
    being fixed at [4], which does not affect us because we apply the
    workaround to both, and now, starting with Rust 1.91.0 (released
    2025-10-30), `-Zsanitizer` is a target modifier too [5], which means we
    fail with:
    
          RUSTDOC TK rust/kernel/lib.rs
        error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `kernel`
         --> rust/kernel/lib.rs:3:1
          |
        3 | //! The `kernel` crate.
          | ^
          |
          = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
          = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core`
          = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core`
          = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error
    
    A simple way around is to add the sanitizer to the list in the existing
    workaround (especially if we had not started to pass the sanitizer
    flags in the previous commit, since in that case that would not be
    necessary). However, that still applies the workaround in more cases
    than necessary.
    
    Instead, only modify the doctests flags to ignore the check for
    sanitizers, so that it is more local (and thus the compiler keeps checking
    it for us in the normal `rustdoc` calls). Since the previous commit
    already treated the `rustdoc` calls as kernel objects, this should allow
    us in the future to easily remove this workaround when the time comes.
    
    By the way, the `-Cunsafe-allow-abi-mismatch` flag overwrites previous
    ones rather than appending, so it needs to be all done in the same flag.
    Moreover, unknown modifiers are rejected, and thus we have to gate based
    on the version too.
    
    Finally, `-Zsanitizer-cfi-normalize-integers` is not affected (in Rust
    1.91.0), so it is not needed in the workaround for the moment.
    
    Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs).
    Link: https://github.com/rust-lang/rust/issues/144521 [1]
    Link: https://github.com/rust-lang/rust/pull/144523 [2]
    Link: https://github.com/rust-lang/rust/issues/146465 [3]
    Link: https://github.com/rust-lang/rust/pull/148068 [4]
    Link: https://github.com/rust-lang/rust/pull/138736 [5]
    Reviewed-by: Alice Ryhl <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Kaibo Ma <[email protected]>
Date:   Mon Sep 15 22:12:56 2025 -0400

    rust: kunit: allow `cfg` on `test`s
    
    [ Upstream commit c652dc44192d96820d73a7ecd89d275ca7e4355d ]
    
    The `kunit_test` proc macro only checks for the `test` attribute
    immediately preceding a `fn`. If the function is disabled via a `cfg`,
    the generated code would result in a compile error referencing a
    non-existent function [1].
    
    This collects attributes and specifically cherry-picks `cfg` attributes
    to be duplicated inside KUnit wrapper functions such that a test function
    disabled via `cfg` compiles and is marked as skipped in KUnit correctly.
    
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/rust-for-linux/CANiq72==48=69hYiDo1321pCzgn_n1_jg=ez5UYXX91c+g5JVQ@mail.gmail.com/ [1]
    Closes: https://github.com/Rust-for-Linux/linux/issues/1185
    Suggested-by: Miguel Ojeda <[email protected]>
    Suggested-by: David Gow <[email protected]>
    Signed-off-by: Kaibo Ma <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miaoqian Lin <[email protected]>
Date:   Mon Oct 27 23:08:38 2025 +0800

    s390/mm: Fix memory leak in add_marker() when kvrealloc() fails
    
    commit 07ad45e06b4039adf96882aefcb1d3299fb7c305 upstream.
    
    The function has a memory leak when kvrealloc() fails.
    The function directly assigns NULL to the markers pointer, losing the
    reference to the previously allocated memory. This causes kvfree() in
    pt_dump_init() to free NULL instead of the leaked memory.
    
    Fix by:
    1. Using kvrealloc() uniformly for all allocations
    2. Using a temporary variable to preserve the original pointer until
       allocation succeeds
    3. Removing the error path that sets markers_cnt=0 to keep
       consistency between markers and markers_cnt
    
    Found via static analysis and this is similar to commit 42378a9ca553
    ("bpf, verifier: Fix memory leak in array reallocation for stack state")
    
    Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Gerd Bayer <[email protected]>
Date:   Thu Oct 16 11:27:03 2025 +0200

    s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump
    
    commit 0fd20f65df6aa430454a0deed8f43efa91c54835 upstream.
    
    Do not block PCI config accesses through pci_cfg_access_lock() when
    executing the s390 variant of PCI error recovery: Acquire just
    device_lock() instead of pci_dev_lock() as powerpc's EEH and
    generig PCI AER processing do.
    
    During error recovery testing a pair of tasks was reported to be hung:
    
    mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working
    INFO: task kmcheck:72 blocked for more than 122 seconds.
          Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:kmcheck         state:D stack:0     pid:72    tgid:72    ppid:2      flags:0x00000000
    Call Trace:
     [<000000065256f030>] __schedule+0x2a0/0x590
     [<000000065256f356>] schedule+0x36/0xe0
     [<000000065256f572>] schedule_preempt_disabled+0x22/0x30
     [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8
     [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core]
     [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]
     [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398
     [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0
    INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.
          Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:kworker/u1664:6 state:D stack:0     pid:1514  tgid:1514  ppid:2      flags:0x00000000
    Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
    Call Trace:
     [<000000065256f030>] __schedule+0x2a0/0x590
     [<000000065256f356>] schedule+0x36/0xe0
     [<0000000652172e28>] pci_wait_cfg+0x80/0xe8
     [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88
     [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]
     [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]
     [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]
     [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168
     [<0000000652513212>] devlink_health_report+0x19a/0x230
     [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]
    
    No kernel log of the exact same error with an upstream kernel is
    available - but the very same deadlock situation can be constructed there,
    too:
    
    - task: kmcheck
      mlx5_unload_one() tries to acquire devlink lock while the PCI error
      recovery code has set pdev->block_cfg_access by way of
      pci_cfg_access_lock()
    - task: kworker
      mlx5_crdump_collect() tries to set block_cfg_access through
      pci_cfg_access_lock() while devlink_health_report() had acquired
      the devlink lock.
    
    A similar deadlock situation can be reproduced by requesting a
    crdump with
      > devlink health dump show pci/<BDF> reporter fw_fatal
    
    while PCI error recovery is executed on the same <BDF> physical function
    by mlx5_core's pci_error_handlers. On s390 this can be injected with
      > zpcictl --reset-fw <BDF>
    
    Tests with this patch failed to reproduce that second deadlock situation,
    the devlink command is rejected with "kernel answers: Permission denied" -
    and we get a kernel log message of:
    
    mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5
    
    because the config read of VSC_SEMAPHORE is rejected by the underlying
    hardware.
    
    Two prior attempts to address this issue have been discussed and
    ultimately rejected [see link], with the primary argument that s390's
    implementation of PCI error recovery is imposing restrictions that
    neither powerpc's EEH nor PCI AER handling need. Tests show that PCI
    error recovery on s390 is running to completion even without blocking
    access to PCI config space.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Cc: [email protected]
    Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery")
    Reviewed-by: Niklas Schnelle <[email protected]>
    Signed-off-by: Gerd Bayer <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Farhan Ali <[email protected]>
Date:   Wed Oct 22 09:47:26 2025 -0700

    s390/pci: Restore IRQ unconditionally for the zPCI device
    
    commit b45873c3f09153d1ad9b3a7bf9e5c0b0387fd2ea upstream.
    
    Commit c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()"),
    introduced the zpci_set_irq() and zpci_clear_irq(), to be used while
    resetting a zPCI device.
    
    Commit da995d538d3a ("s390/pci: implement reset_slot for hotplug
    slot"), mentions zpci_clear_irq() being called in the path for
    zpci_hot_reset_device().  But that is not the case anymore and these
    functions are not called outside of this file. Instead
    zpci_hot_reset_device() relies on zpci_disable_device() also clearing
    the IRQs, but misses to reset the zdev->irqs_registered flag.
    
    However after a CLP disable/enable reset, the device's IRQ are
    unregistered, but the flag zdev->irq_registered does not get cleared. It
    creates an inconsistent state and so arch_restore_msi_irqs() doesn't
    correctly restore the device's IRQ. This becomes a problem when a PCI
    driver tries to restore the state of the device through
    pci_restore_state(). Restore IRQ unconditionally for the device and remove
    the irq_registered flag as its redundant.
    
    Fixes: c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()")
    Cc: [email protected]
    Reviewed-by: Niklas Schnelle <[email protected]>
    Reviewed-by: Matthew Rosato <[email protected]>
    Signed-off-by: Farhan Ali <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Niklas Schnelle <[email protected]>
Date:   Thu Aug 7 15:55:39 2025 +0200

    s390/pci: Use pci_uevent_ers() in PCI recovery
    
    [ Upstream commit dab32f2576a39d5f54f3dbbbc718d92fa5109ce9 ]
    
    Issue uevents on s390 during PCI recovery using pci_uevent_ers() as done by
    EEH and AER PCIe recovery routines.
    
    Signed-off-by: Niklas Schnelle <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Lukas Wunner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Carstens <[email protected]>
Date:   Thu Oct 30 15:55:05 2025 +0100

    s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
    
    commit 64e2f60f355e556337fcffe80b9bcff1b22c9c42 upstream.
    
    As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible
    crashes. The problem is that kernel page tables are modified without
    flushing corresponding TLB entries.
    
    Even if it looks like the empty flush_tlb_all() implementation on s390 is
    the problem, it is actually a different problem: on s390 it is not allowed
    to replace an active/valid page table entry with another valid page table
    entry without the detour over an invalid entry. A direct replacement may
    lead to random crashes and/or data corruption.
    
    In order to invalidate an entry special instructions have to be used
    (e.g. ipte or idte). Alternatively there are also special instructions
    available which allow to replace a valid entry with a different valid
    entry (e.g. crdte or cspg).
    
    Given that the HVO code currently does not provide the hooks to allow for
    an implementation which is compliant with the s390 architecture
    requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is
    basically a revert of the original patch which enabled it.
    
    Reported-by: Luiz Capitulino <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: 00a34d5a99c0 ("s390: select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP")
    Cc: [email protected]
    Tested-by: Luiz Capitulino <[email protected]>
    Reviewed-by: Gerald Schaefer <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Oct 6 15:35:36 2025 -1000

    sched_ext: Mark scx_bpf_dsq_move_set_[slice|vtime]() with KF_RCU
    
    commit 54e96258a6930909b690fd7e8889749231ba8085 upstream.
    
    scx_bpf_dsq_move_set_slice() and scx_bpf_dsq_move_set_vtime() take a DSQ
    iterator argument which has to be valid. Mark them with KF_RCU.
    
    Fixes: 4c30f5ce4f7a ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()")
    Cc: [email protected] # v6.12+
    Acked-by: Andrea Righi <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Bart Van Assche <[email protected]>
Date:   Tue Oct 14 15:02:43 2025 -0700

    scsi: core: Fix the unit attention counter implementation
    
    [ Upstream commit d54c676d4fe0543d1642ab7a68ffdd31e8639a5d ]
    
    scsi_decide_disposition() may call scsi_check_sense().
    scsi_decide_disposition() calls are not serialized. Hence, counter
    updates by scsi_check_sense() must be serialized. Hence this patch that
    makes the counters updated by scsi_check_sense() atomic.
    
    Cc: Kai Mäkisara <[email protected]>
    Fixes: a5d518cd4e3e ("scsi: core: Add counters for New Media and Power On/Reset UNIT ATTENTIONs")
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Ewan D. Milne <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alok Tiwari <[email protected]>
Date:   Mon Sep 15 11:37:57 2025 -0700

    scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill()
    
    [ Upstream commit 072fdd4b0be9b9051bdf75f36d0227aa705074ba ]
    
    The fc_ct_ms_fill() helper currently formats the OS name and version
    into entry->value using "%s v%s". Since init_utsname()->sysname and
    ->release are unbounded strings, snprintf() may attempt to write more
    than FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN bytes, triggering a
    -Wformat-truncation warning with W=1.
    
    In file included from drivers/scsi/libfc/fc_elsct.c:18:
    drivers/scsi/libfc/fc_encode.h: In function ‘fc_ct_ms_fill.constprop’:
    drivers/scsi/libfc/fc_encode.h:359:30: error: ‘%s’ directive output may
    be truncated writing up to 64 bytes into a region of size between 62
    and 126 [-Werror=format-truncation=]
      359 |                         "%s v%s",
          |                              ^~
      360 |                         init_utsname()->sysname,
      361 |                         init_utsname()->release);
          |                         ~~~~~~~~~~~~~~~~~~~~~~~
    drivers/scsi/libfc/fc_encode.h:357:17: note: ‘snprintf’ output between
    3 and 131 bytes into a destination of size 128
      357 |                 snprintf((char *)&entry->value,
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      358 |                         FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN,
          |                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      359 |                         "%s v%s",
          |                         ~~~~~~~~~
      360 |                         init_utsname()->sysname,
          |                         ~~~~~~~~~~~~~~~~~~~~~~~~
      361 |                         init_utsname()->release);
          |                         ~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by using "%.62s v%.62s", which ensures sysname and release are
    truncated to fit within the 128-byte field defined by
    FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN.
    
    [mkp: clarified commit description]
    
    Signed-off-by: Alok Tiwari <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:03 2025 -0700

    scsi: lpfc: Check return status of lpfc_reset_flush_io_context during TGT_RESET
    
    [ Upstream commit f408dde2468b3957e92b25e7438f74c8e9fb9e73 ]
    
    If lpfc_reset_flush_io_context fails to execute, then the wrong return
    status code may be passed back to upper layers when issuing a target
    reset TMF command.  Fix by checking the return status from
    lpfc_reset_flush_io_context() first in order to properly return FAILED
    or FAST_IO_FAIL.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:00 2025 -0700

    scsi: lpfc: Clean up allocated queues when queue setup mbox commands fail
    
    [ Upstream commit 803dfd83df33b7565f23aef597d5dd036adfa792 ]
    
    lpfc_sli4_queue_setup() does not allocate memory and is used for
    submitting CREATE_QUEUE mailbox commands.  Thus, if such mailbox
    commands fail we should clean up by also freeing the memory allocated
    for the queues with lpfc_sli4_queue_destroy().  Change the intended
    clean up label for the lpfc_sli4_queue_setup() error case to
    out_destroy_queue.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:02 2025 -0700

    scsi: lpfc: Decrement ndlp kref after FDISC retries exhausted
    
    [ Upstream commit b5bf6d681fce69cd1a57bfc0f1bdbbb348035117 ]
    
    The kref for Fabric_DID ndlps is not decremented after repeated FDISC
    failures and exhausting maximum allowed retries.  This can leave the
    ndlp lingering unnecessarily.  Add a test and set bit operation for the
    NLP_DROPPED flag. If not previously set, then a kref is decremented. The
    ndlp is freed when the remaining reference for the completing ELS is
    put.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:05 2025 -0700

    scsi: lpfc: Define size of debugfs entry for xri rebalancing
    
    [ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ]
    
    To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs
    entry is used.  The debugfs file operations for xri rebalancing have
    been previously implemented, but lack definition for its information
    buffer size.  Similar to other pre-existing debugfs entry buffers,
    define LPFC_HDWQINFO_SIZE as 8192 bytes.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:04 2025 -0700

    scsi: lpfc: Ensure PLOGI_ACC is sent prior to PRLI in Point to Point topology
    
    [ Upstream commit 2bf81856a403c92a4ce375288f33fba82ca2ccc6 ]
    
    There is a timing race condition when a PRLI may be sent on the wire
    before PLOGI_ACC in Point to Point topology.  Fix by deferring REG_RPI
    mbox completion handling to after PLOGI_ACC's CQE completion.  Because
    the discovery state machine only sends PRLI after REG_RPI mbox
    completion, PRLI is now guaranteed to be sent after PLOGI_ACC.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Justin Tee <[email protected]>
Date:   Mon Sep 15 11:08:01 2025 -0700

    scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in lpfc_cleanup
    
    [ Upstream commit a4809b98eb004fcbf7c4d45eb5a624d1c682bb73 ]
    
    In lpfc_cleanup, there is an extraneous nlp_put for NPIV ports on the
    F_Port_Ctrl ndlp object.  In cases when an ABTS is issued, the
    outstanding kref is needed for when a second XRI_ABORTED CQE is
    received.  The final kref for the ndlp is designed to be decremented in
    lpfc_sli4_els_xri_aborted instead.  Also, add a new log message to allow
    for future diagnostics when debugging related issues.
    
    Signed-off-by: Justin Tee <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chandrakanth Patil <[email protected]>
Date:   Wed Aug 20 14:11:34 2025 +0530

    scsi: mpi3mr: Fix controller init failure on fault during queue creation
    
    [ Upstream commit 829fa1582b6ff607b0e2fe41ba1c45c77f686618 ]
    
    Firmware can enter a transient fault while creating operational queues.
    The driver fails the load immediately.
    
    Add a retry loop that checks controller status and history bit after
    queue creation. If either indicates a fault, retry init up to a set
    limit before failing.
    
    Signed-off-by: Chandrakanth Patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chandrakanth Patil <[email protected]>
Date:   Wed Aug 20 14:11:33 2025 +0530

    scsi: mpi3mr: Fix device loss during enclosure reboot due to zero link speed
    
    [ Upstream commit d6c8e8b7c98c3cb326515ef4bc5c57e16ac5ae4e ]
    
    During enclosure reboot or expander reset, firmware may report a link
    speed of 0 in "Device Add" events while the link is still coming up.
    The driver drops such devices, leaving them missing even after the link
    recovers.
    
    Fix this by treating link speed 0 as 1.5 Gbps during device addition so
    the device is exposed to the OS. The actual link speed will be updated
    later when link-up events arrive.
    
    Signed-off-by: Chandrakanth Patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chandrakanth Patil <[email protected]>
Date:   Wed Aug 20 14:11:35 2025 +0530

    scsi: mpi3mr: Fix I/O failures during controller reset
    
    [ Upstream commit b7b2176e30fc8e57664e5a8a23387af66eb7f72b ]
    
    I/Os can race with controller reset and fail.
    
    Block requests at the mid layer when reset starts using
    scsi_host_block(), and resume with scsi_host_unblock() after reset
    completes.
    
    Signed-off-by: Chandrakanth Patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ranjan Kumar <[email protected]>
Date:   Mon Sep 22 15:21:12 2025 +0530

    scsi: mpt3sas: Add support for 22.5 Gbps SAS link rate
    
    [ Upstream commit 4be7599d6b27bade41bfccca42901b917c01c30c ]
    
    Add handling for MPI26_SAS_NEG_LINK_RATE_22_5 in
    _transport_convert_phy_link_rate(). This maps the new 22.5 Gbps
    negotiated rate to SAS_LINK_RATE_22_5_GBPS, to get correct PHY link
    speeds.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Qianfeng Rong <[email protected]>
Date:   Tue Aug 26 17:32:42 2025 +0800

    scsi: pm8001: Use int instead of u32 to store error codes
    
    [ Upstream commit bee3554d1a4efbce91d6eca732f41b97272213a5 ]
    
    Use int instead of u32 for 'ret' variable to store negative error codes
    returned by PM8001_CHIP_DISP->set_nvmd_req().
    
    Signed-off-by: Qianfeng Rong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Francisco Gutierrez <[email protected]>
Date:   Wed Jul 23 18:35:43 2025 +0000

    scsi: pm80xx: Fix race condition caused by static variables
    
    [ Upstream commit d6477ee38ccfbeaed885733c13f41d9076e2f94a ]
    
    Eliminate the use of static variables within the log pull implementation
    to resolve a race condition and prevent data gaps when pulling logs from
    multiple controllers in parallel, ensuring each operation is properly
    isolated.
    
    Signed-off-by: Francisco Gutierrez <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adrian Hunter <[email protected]>
Date:   Fri Oct 24 11:59:16 2025 +0300

    scsi: ufs: core: Add a quirk to suppress link_startup_again
    
    commit d34caa89a132cd69efc48361d4772251546fdb88 upstream.
    
    ufshcd_link_startup() has a facility (link_startup_again) to issue
    DME_LINKSTARTUP a 2nd time even though the 1st time was successful.
    
    Some older hardware benefits from that, however the behaviour is
    non-standard, and has been found to cause link startup to be unreliable
    for some Intel Alder Lake based host controllers.
    
    Add UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress
    link_startup_again, in preparation for setting the quirk for affected
    controllers.
    
    Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 24 17:16:19 2025 +0800

    scsi: ufs: core: Change MCQ interrupt enable flow
    
    [ Upstream commit 253757797973c54ea967f8fd8f40d16e4a78e6d4 ]
    
    Move the MCQ interrupt enable process to
    ufshcd_mcq_make_queues_operational() to ensure that interrupts are set
    correctly when making queues operational, similar to
    ufshcd_make_hba_operational(). This change addresses the issue where
    ufshcd_mcq_make_queues_operational() was not fully operational due to
    missing interrupt enablement.
    
    This change only affects host drivers that call
    ufshcd_mcq_make_queues_operational(), i.e. ufs-mediatek.
    
    Signed-off-by: Peter Wang <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bart Van Assche <[email protected]>
Date:   Tue Sep 9 12:06:07 2025 -0700

    scsi: ufs: core: Disable timestamp functionality if not supported
    
    [ Upstream commit fb1f4568346153d2f80fdb4ffcfa0cf4fb257d3c ]
    
    Some Kioxia UFS 4 devices do not support the qTimestamp attribute.  Set
    the UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT for these devices such that no
    error messages appear in the kernel log about failures to set the
    qTimestamp attribute.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Tested-by: Nitin Rawat <[email protected]> # on SM8650-QRD
    Reviewed-by: Nitin Rawat <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bart Van Assche <[email protected]>
Date:   Tue Oct 14 13:00:53 2025 -0700

    scsi: ufs: core: Fix a race condition related to the "hid" attribute group
    
    [ Upstream commit c74dc8ab47c1ec3927f63ca83b542c363249b3d8 ]
    
    ufs_sysfs_add_nodes() is called concurrently with ufs_get_device_desc().
    This may cause the following code to be called before
    ufs_sysfs_add_nodes():
    
            sysfs_update_group(&hba->dev->kobj, &ufs_sysfs_hid_group);
    
    If this happens, ufs_sysfs_add_nodes() triggers a kernel warning and
    fails. Fix this by calling ufs_sysfs_add_nodes() before SCSI LUNs are
    scanned since the sysfs_update_group() call happens from the context of
    thread that executes ufshcd_async_scan(). This patch fixes the following
    kernel warning:
    
    sysfs: cannot create duplicate filename '/devices/platform/3c2d0000.ufs/hid'
    Workqueue: async async_run_entry_fn
    Call trace:
     dump_backtrace+0xfc/0x17c
     show_stack+0x18/0x28
     dump_stack_lvl+0x40/0x104
     dump_stack+0x18/0x3c
     sysfs_warn_dup+0x6c/0xc8
     internal_create_group+0x1c8/0x504
     sysfs_create_groups+0x38/0x9c
     ufs_sysfs_add_nodes+0x20/0x58
     ufshcd_init+0x1114/0x134c
     ufshcd_pltfrm_init+0x728/0x7d8
     ufs_google_probe+0x30/0x84
     platform_probe+0xa0/0xe0
     really_probe+0x114/0x454
     __driver_probe_device+0xa4/0x160
     driver_probe_device+0x44/0x23c
     __device_attach_driver+0x15c/0x1f4
     bus_for_each_drv+0x10c/0x168
     __device_attach_async_helper+0x80/0xf8
     async_run_entry_fn+0x4c/0x17c
     process_one_work+0x26c/0x65c
     worker_thread+0x33c/0x498
     kthread+0x110/0x134
     ret_from_fork+0x10/0x20
    ufshcd 3c2d0000.ufs: ufs_sysfs_add_nodes: sysfs groups creation failed (err = -17)
    
    Cc: Daniel Lee <[email protected]>
    Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible")
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adrian Hunter <[email protected]>
Date:   Fri Oct 24 11:59:18 2025 +0300

    scsi: ufs: core: Fix invalid probe error return value
    
    commit a2b32bc1d9e359a9f90d0de6af16699facb10935 upstream.
    
    After DME Link Startup, the error return value is set to the MIPI UniPro
    GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE).  Upon failure
    during driver probe, the error code 1 is propagated back to the driver
    probe function which must return a negative value to indicate an error,
    but 1 is not negative, so the probe is considered to be successful even
    though it failed.  Subsequently, removing the driver results in an oops
    because it is not in a valid state.
    
    This happens because none of the callers of ufshcd_init() expect a
    non-negative error code.
    
    Fix the return value and documentation to match actual usage.
    
    Fixes: 69f5eb78d4b0 ("scsi: ufs: core: Move the ufshcd_device_init(hba, true) call")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Hoyoung Seo <[email protected]>
Date:   Tue Sep 30 15:14:28 2025 +0900

    scsi: ufs: core: Include UTP error in INT_FATAL_ERRORS
    
    [ Upstream commit 558ae4579810fa0fef011944230c65a6f3087f85 ]
    
    When a UTP error occurs in isolation, UFS is not currently recoverable.
    This is because the UTP error is not considered fatal in the error
    handling code, leading to either an I/O timeout or an OCS error.
    
    Add the UTP error flag to INT_FATAL_ERRORS so the controller will be
    reset in this situation.
    
      sd 0:0:0:0: [sda] tag#38 UNKNOWN(0x2003) Result: hostbyte=0x07
      driverbyte=DRIVER_OK cmd_age=0s
      sd 0:0:0:0: [sda] tag#38 CDB: opcode=0x28 28 00 00 51 24 e2 00 00 08 00
      I/O error, dev sda, sector 42542864 op 0x0:(READ) flags 0x80700 phys_seg
      8 prio class 2
      OCS error from controller = 9 for tag 39
      pa_err[1] = 0x80000010 at 2667224756 us
      pa_err: total cnt=2
      dl_err[0] = 0x80000002 at 2667148060 us
      dl_err[1] = 0x80002000 at 2667282844 us
      No record of nl_err
      No record of tl_err
      No record of dme_err
      No record of auto_hibern8_err
      fatal_err[0] = 0x804 at 2667282836 us
    
      ---------------------------------------------------
                    REGISTER
      ---------------------------------------------------
                                 NAME             OFFSET             VALUE
                          STD HCI SFR         0xfffffff0               0x0
                                 AHIT               0x18             0x814
                     INTERRUPT STATUS               0x20            0x1000
                     INTERRUPT ENABLE               0x24           0x70ef5
    
    [mkp: commit desc]
    
    Signed-off-by: Hoyoung Seo <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wonkon Kim <[email protected]>
Date:   Mon Oct 20 15:15:38 2025 +0900

    scsi: ufs: core: Initialize value of an attribute returned by uic cmd
    
    [ Upstream commit 6fe4c679dde3075cb481beb3945269bb2ef8b19a ]
    
    If ufshcd_send_cmd() fails, *mib_val may have a garbage value. It can
    get an unintended value of an attribute.
    
    Make ufshcd_dme_get_attr() always initialize *mib_val.
    
    Fixes: 12b4fdb4f6bc ("[SCSI] ufs: add dme configuration primitives")
    Signed-off-by: Wonkon Kim <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bart Van Assche <[email protected]>
Date:   Tue Oct 28 15:24:24 2025 -0700

    scsi: ufs: core: Revert "Make HID attributes visible"
    
    [ Upstream commit f838d624fd1183e07db86f3138bcd05fd7630a1e ]
    
    Patch "Make HID attributes visible" is needed for older kernel versions
    (e.g. 6.12) where ufs_get_device_desc() is called from ufshcd_probe_hba().
    In these older kernel versions ufshcd_get_device_desc() may be called
    after the sysfs attributes have been added. In the upstream kernel however
    ufshcd_get_device_desc() is called before ufs_sysfs_add_nodes(). See also
    the ufshcd_device_params_init() call from ufshcd_init(). Hence, calling
    sysfs_update_group() is not necessary.
    
    See also commit 69f5eb78d4b0 ("scsi: ufs: core: Move the
    ufshcd_device_init(hba, true) call") in kernel v6.13.
    
    This patch fixes the following kernel warning:
    
    sysfs: cannot create duplicate filename '/devices/platform/3c2d0000.ufs/hid'
    Workqueue: async async_run_entry_fn
    Call trace:
     dump_backtrace+0xfc/0x17c
     show_stack+0x18/0x28
     dump_stack_lvl+0x40/0x104
     dump_stack+0x18/0x3c
     sysfs_warn_dup+0x6c/0xc8
     internal_create_group+0x1c8/0x504
     sysfs_create_groups+0x38/0x9c
     ufs_sysfs_add_nodes+0x20/0x58
     ufshcd_init+0x1114/0x134c
     ufshcd_pltfrm_init+0x728/0x7d8
     ufs_google_probe+0x30/0x84
     platform_probe+0xa0/0xe0
     really_probe+0x114/0x454
     __driver_probe_device+0xa4/0x160
     driver_probe_device+0x44/0x23c
     __device_attach_driver+0x15c/0x1f4
     bus_for_each_drv+0x10c/0x168
     __device_attach_async_helper+0x80/0xf8
     async_run_entry_fn+0x4c/0x17c
     process_one_work+0x26c/0x65c
     worker_thread+0x33c/0x498
     kthread+0x110/0x134
     ret_from_fork+0x10/0x20
    ufshcd 3c2d0000.ufs: ufs_sysfs_add_nodes: sysfs groups creation failed (err = -17)
    
    Cc: Daniel Lee <[email protected]>
    Cc: Peter Wang <[email protected]>
    Cc: Bjorn Andersson <[email protected]>
    Cc: Neil Armstrong <[email protected]>
    Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible")
    Signed-off-by: Bart Van Assche <[email protected]>
    
    Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible")
    Acked-by: Neil Armstrong <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bharat Uppal <[email protected]>
Date:   Thu Aug 21 11:09:23 2025 +0530

    scsi: ufs: exynos: fsd: Gate ref_clk and put UFS device in reset on suspend
    
    [ Upstream commit 6d55af0f0740bf3d77943425fdafb77dc0fa6bb9 ]
    
    On FSD platform, gating the reference clock (ref_clk) and putting the
    UFS device in reset by asserting the reset signal during UFS suspend,
    improves the power savings and ensures the PHY is fully turned off.
    
    These operations are added as FSD specific suspend hook to avoid
    unintended side effects on other SoCs supported by this driver.
    
    Co-developed-by: Nimesh Sati <[email protected]>
    Signed-off-by: Nimesh Sati <[email protected]>
    Signed-off-by: Bharat Uppal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alice Chao <[email protected]>
Date:   Mon Aug 11 21:11:22 2025 +0800

    scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change
    
    [ Upstream commit 979feee0cf43b32d288931649d7c6d9a5524ea55 ]
    
    Assign power mode userdata settings before transitioning to FASTAUTO
    power mode. This ensures that default timeout values are set for various
    parameters, enhancing the reliability and performance of the power mode
    change process.
    
    Signed-off-by: Alice Chao <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Mon Aug 11 21:11:25 2025 +0800

    scsi: ufs: host: mediatek: Change reset sequence for improved stability
    
    [ Upstream commit 878ed88c50bfb14d972dd3b86a1c8188c58de4e5 ]
    
    Modify the reset sequence to ensure that the device reset pin is set low
    before the host is disabled. This change enhances the stability of the
    reset process by ensuring the correct order of operations.
    
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 3 10:44:39 2025 +0800

    scsi: ufs: host: mediatek: Correct system PM flow
    
    [ Upstream commit 77b96ef70b6ba46e3473e5e3a66095c4bc0e93a4 ]
    
    Refine the system power management (PM) flow by skipping low power mode
    (LPM) and MTCMOS settings if runtime PM is already applied. Prevent
    redundant operations to ensure a more efficient PM process.
    
    Signed-off-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 3 10:44:42 2025 +0800

    scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode changes
    
    [ Upstream commit f5ca8d0c7a6388abd5d8023cc682e1543728cc73 ]
    
    Disable auto-hibern8 during power mode transitions to prevent unintended
    entry into auto-hibern8. Restore the original auto-hibern8 timer value
    after completing the power mode change to maintain system stability and
    prevent potential issues during power state transitions.
    
    Signed-off-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 3 10:44:37 2025 +0800

    scsi: ufs: host: mediatek: Enhance recovery on hibernation exit failure
    
    [ Upstream commit faac32d4ece30609f1a0930ca0ae951cf6dc1786 ]
    
    Improve the recovery process for hibernation exit failures. Trigger the
    error handler and break the suspend operation to ensure effective
    recovery from hibernation errors. Activate the error handling mechanism
    by ufshcd_force_error_recovery and scheduling the error handler work.
    
    Signed-off-by: Peter Wang <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 3 10:44:38 2025 +0800

    scsi: ufs: host: mediatek: Enhance recovery on resume failure
    
    [ Upstream commit 15ef3f5aa822f32524cba1463422a2c9372443f0 ]
    
    Improve the recovery process for failed resume operations. Log the
    device's power status and return 0 if both resume and recovery fail to
    prevent I/O hang.
    
    Signed-off-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alice Chao <[email protected]>
Date:   Wed Sep 3 10:44:44 2025 +0800

    scsi: ufs: host: mediatek: Fix adapt issue after PA_Init
    
    [ Upstream commit d73836cb8535b3078e4d2a57913f301baec58a33 ]
    
    Address the issue where the host does not send adapt to the device after
    PA_Init success. Ensure the adapt process is correctly initiated for
    devices with IP version MT6899 and above, resolving communication issues
    between the host and device.
    
    Signed-off-by: Alice Chao <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Signed-off-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Mon Aug 11 21:11:18 2025 +0800

    scsi: ufs: host: mediatek: Fix auto-hibern8 timer configuration
    
    [ Upstream commit aa86602a483ba48f51044fbaefa1ebbf6da194a4 ]
    
    Move the configuration of the Auto-Hibern8 (AHIT) timer from the
    post-link stage to the 'fixup_dev_quirks' function. This change allows
    setting the AHIT based on the vendor requirements:
    
       (a) Samsung: 3.5 ms
       (b) Micron: 2 ms
       (c) Others: 1 ms
    
    Additionally, the clock gating timer is adjusted based on the AHIT
    scale, with a maximum setting of 10 ms. This ensures that the clock
    gating delay is appropriately configured to match the AHIT settings.
    
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alice Chao <[email protected]>
Date:   Mon Aug 11 21:11:26 2025 +0800

    scsi: ufs: host: mediatek: Fix invalid access in vccqx handling
    
    [ Upstream commit 5863638598f5e4f64d2f85b03f376383ca1f2ab7 ]
    
    Add a NULL check before accessing the 'vccqx' pointer to prevent invalid
    memory access. This ensures that the function safely handles cases where
    'vccq' and 'vccq2' are not initialized, improving the robustness of the
    power management code.
    
    Signed-off-by: Alice Chao <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Mon Aug 11 21:11:21 2025 +0800

    scsi: ufs: host: mediatek: Fix PWM mode switch issue
    
    [ Upstream commit 7212d624f8638f8ea8ad1ecbb80622c7987bc7a1 ]
    
    Address a failure in switching to PWM mode by ensuring proper
    configuration of power modes and adaptation settings. The changes
    include checks for SLOW_MODE and adjustments to the desired working mode
    and adaptation configuration based on the device's power mode and
    hardware version.
    
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Wang <[email protected]>
Date:   Wed Sep 3 10:44:45 2025 +0800

    scsi: ufs: host: mediatek: Fix unbalanced IRQ enable issue
    
    [ Upstream commit 91cad911edd1612ed28f5cfb2d4c53a8824951a5 ]
    
    Resolve the issue of unbalanced IRQ enablement by setting the
    'is_mcq_intr_enabled' flag after the first successful IRQ enablement.
    Ensure proper tracking of the IRQ state and prevent potential mismatches
    in IRQ handling.
    
    Signed-off-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adrian Hunter <[email protected]>
Date:   Fri Oct 24 11:59:15 2025 +0300

    scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers
    
    commit bb44826c3bdbf1fa3957008a04908f45e5666463 upstream.
    
    Intel platforms with UFS, can support Suspend-to-Idle (S0ix) and
    Suspend-to-RAM (S3).  For S0ix the link state should be HIBERNATE.  For
    S3, state is lost, so the link state must be OFF.  Driver policy,
    expressed by spm_lvl, can be 3 (link HIBERNATE, device SLEEP) for S0ix
    but must be changed to 5 (link OFF, device POWEROFF) for S3.
    
    Fix support for S0ix/S3 by switching spm_lvl as needed.  During suspend
    ->prepare(), if the suspend target state is not Suspend-to-Idle, ensure
    the spm_lvl is at least 5 to ensure that resume will be possible from
    deep sleep states.  During suspend ->complete(), restore the spm_lvl to
    its original value that is suitable for S0ix.
    
    This fix is first needed in Intel Alder Lake based controllers.
    
    Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Adrian Hunter <[email protected]>
Date:   Fri Oct 24 11:59:17 2025 +0300

    scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL
    
    commit d968e99488c4b08259a324a89e4ed17bf36561a4 upstream.
    
    Link startup becomes unreliable for Intel Alder Lake based host
    controllers when a 2nd DME_LINKSTARTUP is issued unnecessarily.  Employ
    UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress that from happening.
    
    Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Palash Kambar <[email protected]>
Date:   Mon Aug 18 09:39:05 2025 +0530

    scsi: ufs: ufs-qcom: Align programming sequence of Shared ICE for UFS controller v5
    
    [ Upstream commit 3126b5fd02270380cce833d06f973a3ffb33a69b ]
    
    Disabling the AES core in Shared ICE is not supported during power
    collapse for UFS Host Controller v5.0, which may lead to data errors
    after Hibern8 exit. To comply with hardware programming guidelines and
    avoid this issue, issue a sync reset to ICE upon power collapse exit.
    
    Hence follow below steps to reset the ICE upon exiting power collapse
    and align with Hw programming guide.
    
    a. Assert the ICE sync reset by setting both SYNC_RST_SEL and
       SYNC_RST_SW bits in UFS_MEM_ICE_CFG
    
    b. Deassert the reset by clearing SYNC_RST_SW in  UFS_MEM_ICE_CFG
    
    Signed-off-by: Palash Kambar <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Palash Kambar <[email protected]>
Date:   Tue Sep 9 11:21:49 2025 +0530

    scsi: ufs: ufs-qcom: Disable lane clocks during phy hibern8
    
    [ Upstream commit c1553fc105dff28f79bef90fab207235f5f2d977 ]
    
    Currently, the UFS lane clocks remain enabled even after the link enters
    the Hibern8 state and are only disabled during runtime/system
    suspend.This patch modifies the behavior to disable the lane clocks
    during ufs_qcom_setup_clocks(), which is invoked shortly after the link
    enters Hibern8 via gate work.
    
    While hibern8_notify() offers immediate control, toggling clocks on
    every transition isn't ideal due to varied contexts like clock scaling.
    Since setup_clocks() manages PHY/controller resources and is invoked
    soon after Hibern8 entry, it serves as a central and stable point for
    clock gating.
    
    Signed-off-by: Palash Kambar <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Wiehler <[email protected]>
Date:   Tue Oct 28 17:12:26 2025 +0100

    sctp: Hold RCU read lock while iterating over address list
    
    [ Upstream commit 38f50242bf0f237cdc262308d624d333286ec3c5 ]
    
    With CONFIG_PROVE_RCU_LIST=y and by executing
    
      $ netcat -l --sctp &
      $ netcat --sctp localhost &
      $ ss --sctp
    
    one can trigger the following Lockdep-RCU splat(s):
    
      WARNING: suspicious RCU usage
      6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted
      -----------------------------
      net/sctp/diag.c:76 RCU-list traversed in non-reader section!!
    
      other info that might help us debug this:
    
      rcu_scheduler_active = 2, debug_locks = 1
      2 locks held by ss/215:
       #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0
       #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200
    
      stack backtrace:
      CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary)
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x90
       lockdep_rcu_suspicious.cold+0x4e/0xa3
       inet_sctp_diag_fill.isra.0+0x4b1/0x5d0
       sctp_sock_dump+0x131/0x200
       sctp_transport_traverse_process+0x170/0x1b0
       ? __pfx_sctp_sock_filter+0x10/0x10
       ? __pfx_sctp_sock_dump+0x10/0x10
       sctp_diag_dump+0x103/0x140
       __inet_diag_dump+0x70/0xb0
       netlink_dump+0x148/0x490
       __netlink_dump_start+0x1f3/0x2b0
       inet_diag_handler_cmd+0xcd/0x100
       ? __pfx_inet_diag_dump_start+0x10/0x10
       ? __pfx_inet_diag_dump+0x10/0x10
       ? __pfx_inet_diag_dump_done+0x10/0x10
       sock_diag_rcv_msg+0x18e/0x320
       ? __pfx_sock_diag_rcv_msg+0x10/0x10
       netlink_rcv_skb+0x4d/0x100
       netlink_unicast+0x1d7/0x2b0
       netlink_sendmsg+0x203/0x450
       ____sys_sendmsg+0x30c/0x340
       ___sys_sendmsg+0x94/0xf0
       __sys_sendmsg+0x83/0xf0
       do_syscall_64+0xbb/0x390
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
       ...
       </TASK>
    
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Acked-by: Xin Long <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Wiehler <[email protected]>
Date:   Tue Oct 28 17:12:28 2025 +0100

    sctp: Hold sock lock while iterating over address list
    
    [ Upstream commit f1fc201148c7e684c10a72b6a3375597f28d1ef6 ]
    
    Move address list traversal in inet_assoc_attr_size() under the sock
    lock to avoid holding the RCU read lock.
    
    Suggested-by: Xin Long <[email protected]>
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <[email protected]>
    Acked-by: Xin Long <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Wiehler <[email protected]>
Date:   Tue Oct 28 17:12:27 2025 +0100

    sctp: Prevent TOCTOU out-of-bounds write
    
    [ Upstream commit 95aef86ab231f047bb8085c70666059b58f53c09 ]
    
    For the following path not holding the sock lock,
    
      sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()
    
    make sure not to exceed bounds in case the address list has grown
    between buffer allocation (time-of-check) and write (time-of-use).
    
    Suggested-by: Kuniyuki Iwashima <[email protected]>
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Acked-by: Xin Long <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alessandro Zanni <[email protected]>
Date:   Thu Sep 25 15:28:23 2025 +0200

    selftest: net: Fix error message if empty variable
    
    [ Upstream commit 81dcfdd21dbd7067068c7c341ee448c3f0d6f115 ]
    
    Fix to avoid cases where the `res` shell variable is
    empty in script comparisons.
    The comparison has been modified into string comparison to
    handle other possible values the variable could assume.
    
    The issue can be reproduced with the command:
    make kselftest TARGETS=net
    
    It solves the error:
    ./tfo_passive.sh: line 98: [: -eq: unary operator expected
    
    Signed-off-by: Alessandro Zanni <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Saket Kumar Bhaskar <[email protected]>
Date:   Sat Sep 13 14:43:37 2025 +0530

    selftests/bpf: Fix arena_spin_lock selftest failure
    
    [ Upstream commit a9d4e9f0e871352a48a82da11a50df7196fe567a ]
    
    For systems having CONFIG_NR_CPUS set to > 1024 in kernel config
    the selftest fails as arena_spin_lock_irqsave() returns EOPNOTSUPP.
    (eg - incase of powerpc default value for CONFIG_NR_CPUS is 8192)
    
    The selftest is skipped incase bpf program returns EOPNOTSUPP,
    with a descriptive message logged.
    
    Tested-by: Venkat Rao Bagalkote <[email protected]>
    Signed-off-by: Saket Kumar Bhaskar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ricardo B. Marlière <[email protected]>
Date:   Thu Aug 28 10:12:33 2025 -0300

    selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2
    
    [ Upstream commit 98857d111c53954aa038fcbc4cf48873e4240f7c ]
    
    Commit e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level
    APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt
    the usage in test_lirc_mode2_user.c.
    
    Signed-off-by: Ricardo B. Marlière <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mykyta Yatsenko <[email protected]>
Date:   Thu Sep 25 22:52:30 2025 +0100

    selftests/bpf: Fix flaky bpf_cookie selftest
    
    [ Upstream commit 105eb5dc74109a9f53c2f26c9a918d9347a73595 ]
    
    bpf_cookie can fail on perf_event_open(), when it runs after the task_work
    selftest. The task_work test causes perf to lower
    sysctl_perf_event_sample_rate, and bpf_cookie uses sample_freq,
    which is validated against that sysctl. As a result,
    perf_event_open() rejects the attr if the (now tighter) limit is
    exceeded.
    
    >From perf_event_open():
    if (attr.freq) {
            if (attr.sample_freq > sysctl_perf_event_sample_rate)
                    return -EINVAL;
    } else {
            if (attr.sample_period & (1ULL << 63))
                    return -EINVAL;
    }
    
    Switch bpf_cookie to use sample_period, which is not checked against
    sysctl_perf_event_sample_rate.
    
    Signed-off-by: Mykyta Yatsenko <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiayuan Chen <[email protected]>
Date:   Tue Sep 9 20:47:04 2025 +0800

    selftests/bpf: Fix incorrect array size calculation
    
    [ Upstream commit f85981327a90c51e76f60e073cb6648b2f167226 ]
    
    The loop in bench_sockmap_prog_destroy() has two issues:
    
    1. Using 'sizeof(ctx.fds)' as the loop bound results in the number of
       bytes, not the number of file descriptors, causing the loop to iterate
       far more times than intended.
    
    2. The condition 'ctx.fds[0] > 0' incorrectly checks only the first fd for
       all iterations, potentially leaving file descriptors unclosed. Change
       it to 'ctx.fds[i] > 0' to check each fd properly.
    
    These fixes ensure correct cleanup of all file descriptors when the
    benchmark exits.
    
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Jiayuan Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yonghong Song <[email protected]>
Date:   Fri Sep 19 21:58:05 2025 -0700

    selftests/bpf: Fix selftest verifier_arena_large failure
    
    [ Upstream commit 5a427fddec5e76360725a0f03df3a2a003efbe2e ]
    
    With latest llvm22, I got the following verification failure:
    
      ...
      ; int big_alloc2(void *ctx) @ verifier_arena_large.c:207
      0: (b4) w6 = 1                        ; R6_w=1
      ...
      ; if (err) @ verifier_arena_large.c:233
      53: (56) if w6 != 0x0 goto pc+62      ; R6=0
      54: (b7) r7 = -4                      ; R7_w=-4
      55: (18) r8 = 0x7f4000000000          ; R8_w=scalar()
      57: (bf) r9 = addr_space_cast(r8, 0, 1)       ; R8_w=scalar() R9_w=arena
      58: (b4) w6 = 5                       ; R6_w=5
      ; pg = page[i]; @ verifier_arena_large.c:238
      59: (bf) r1 = r7                      ; R1_w=-4 R7_w=-4
      60: (07) r1 += 4                      ; R1_w=0
      61: (79) r2 = *(u64 *)(r9 +0)         ; R2_w=scalar() R9_w=arena
      ; if (*pg != i) @ verifier_arena_large.c:239
      62: (bf) r3 = addr_space_cast(r2, 0, 1)       ; R2_w=scalar() R3_w=arena
      63: (71) r3 = *(u8 *)(r3 +0)          ; R3_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff))
      64: (5d) if r1 != r3 goto pc+51       ; R1_w=0 R3_w=0
      ; bpf_arena_free_pages(&arena, (void __arena *)pg, 2); @ verifier_arena_large.c:241
      65: (18) r1 = 0xff11000114548000      ; R1_w=map_ptr(map=arena,ks=0,vs=0)
      67: (b4) w3 = 2                       ; R3_w=2
      68: (85) call bpf_arena_free_pages#72675      ;
      69: (b7) r1 = 0                       ; R1_w=0
      ; page[i + 1] = NULL; @ verifier_arena_large.c:243
      70: (7b) *(u64 *)(r8 +8) = r1
      R8 invalid mem access 'scalar'
      processed 61 insns (limit 1000000) max_states_per_insn 0 total_states 6 peak_states 6 mark_read 2
      =============
      #489/5   verifier_arena_large/big_alloc2:FAIL
    
    The main reason is that 'r8' in insn '70' is not an arena pointer.
    Further debugging at llvm side shows that llvm commit ([1]) caused
    the failure. For the original code:
      page[i] = NULL;
      page[i + 1] = NULL;
    the llvm transformed it to something like below at source level:
      __builtin_memset(&page[i], 0, 16)
    Such transformation prevents llvm BPFCheckAndAdjustIR pass from
    generating proper addr_space_cast insns ([2]).
    
    Adding support in llvm BPFCheckAndAdjustIR pass should work, but
    not sure that such a pattern exists or not in real applications.
    At the same time, simply adding a memory barrier between two 'page'
    assignment can fix the issue.
    
      [1] https://github.com/llvm/llvm-project/pull/155415
      [2] https://github.com/llvm/llvm-project/pull/84410
    
    Cc: Eduard Zingerman <[email protected]>
    Signed-off-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ricardo B. Marlière <[email protected]>
Date:   Thu Aug 28 15:48:30 2025 -0300

    selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh
    
    [ Upstream commit 2a912258c90e895363c0ffc0be8a47f112ab67b7 ]
    
    Currently, even if some subtests fails, the end result will still yield
    "ok 1 selftests: bpf: test_xsk.sh". Fix it by exiting with 1 if there are
    any failures.
    
    Signed-off-by: Ricardo B. Marlière <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nai-Chen Cheng <[email protected]>
Date:   Wed Sep 10 19:30:32 2025 +0800

    selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to clean net/lib dependency
    
    [ Upstream commit d3f7457da7b9527a06dbcbfaf666aa51ac2eeb53 ]
    
    The selftests 'make clean' does not clean the net/lib because it only
    processes $(TARGETS) and ignores $(INSTALL_DEP_TARGETS). This leaves
    compiled objects in net/lib after cleaning, requiring manual cleanup.
    
    Include $(INSTALL_DEP_TARGETS) in clean target to ensure net/lib
    dependency is properly cleaned.
    
    Signed-off-by: Nai-Chen Cheng <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Simon Horman <[email protected]> # build-tested
    Acked-by: Shuah Khan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wake Liu <[email protected]>
Date:   Sat Aug 9 14:20:13 2025 +0800

    selftests/net: Ensure assert() triggers in psock_tpacket.c
    
    [ Upstream commit bc4c0a48bdad7f225740b8e750fdc1da6d85e1eb ]
    
    The get_next_frame() function in psock_tpacket.c was missing a return
    statement in its default switch case, leading to a compiler warning.
    
    This was caused by a `bug_on(1)` call, which is defined as an
    `assert()`, being compiled out because NDEBUG is defined during the
    build.
    
    Instead of adding a `return NULL;` which would silently hide the error
    and could lead to crashes later, this change restores the original
    author's intent. By adding `#undef NDEBUG` before including <assert.h>,
    we ensure the assertion is active and will cause the test to abort if
    this unreachable code is ever executed.
    
    Signed-off-by: Wake Liu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Anubhav Singh <[email protected]>
Date:   Thu Oct 30 06:28:18 2025 +0000

    selftests/net: fix out-of-order delivery of FIN in gro:tcp test
    
    [ Upstream commit 02d064de05b1fcca769391fa82d205bed8bb9bf0 ]
    
    Due to the gro_sender sending data packets and FIN packets
    in very quick succession, these are received almost simultaneously
    by the gro_receiver. FIN packets are sometimes processed before the
    data packets leading to intermittent (~1/100) test failures.
    
    This change adds a delay of 100ms before sending FIN packets
    in gro:tcp test to avoid the out-of-order delivery. The same
    mitigation already exists for the gro:ip test.
    
    Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test")
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Anubhav Singh <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wake Liu <[email protected]>
Date:   Thu Aug 7 16:09:32 2025 +0800

    selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8
    
    [ Upstream commit c36748e8733ef9c5f4cd1d7c4327994e5b88b8df ]
    
    The `__WORDSIZE` macro, defined in the non-standard `<bits/wordsize.h>`
    header, is a GNU extension and not universally available with all
    toolchains, such as Clang when used with musl libc.
    
    This can lead to build failures in environments where this header is
    missing.
    
    The intention of the code is to determine the bit width of a C `long`.
    Replace the non-portable `__WORDSIZE` with the standard and portable
    `sizeof(long) * 8` expression to achieve the same result.
    
    This change also removes the inclusion of the now-unused
    `<bits/wordsize.h>` header.
    
    Signed-off-by: Wake Liu <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Anubhav Singh <[email protected]>
Date:   Thu Oct 30 06:04:36 2025 +0000

    selftests/net: use destination options instead of hop-by-hop
    
    [ Upstream commit f8e8486702abb05b8c734093aab1606af0eac068 ]
    
    The GRO self-test, gro.c, currently constructs IPv6 packets containing a
    Hop-by-Hop Options header (IPPROTO_HOPOPTS) to ensure the GRO path
    correctly handles IPv6 extension headers.
    
    However, network elements may be configured to drop packets with the
    Hop-by-Hop Options header (HBH). This causes the self-test to fail
    in environments where such network elements are present.
    
    To improve the robustness and reliability of this test in diverse
    network environments, switch from using IPPROTO_HOPOPTS to
    IPPROTO_DSTOPTS (Destination Options).
    
    The Destination Options header is less likely to be dropped by
    intermediate routers and still serves the core purpose of the test:
    validating GRO's handling of an IPv6 extension header. This change
    ensures the test can execute successfully without being incorrectly
    failed by network policies outside the kernel's control.
    
    Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test")
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Anubhav Singh <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>