Linux 6.8.2

 
ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors [+ + +]
Author: Perry Yuan <[email protected]>
Date:   Thu Feb 8 11:46:28 2024 +0800

    ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors
    
    [ Upstream commit a51ab63b297ce9e26e3ffb9be896018a42d5f32f ]
    
    As there are some AMD processors which only support CPPC V2 firmware and
    BIOS implementation, the amd_pstate driver will be failed to load when
    system booting with below kernel warning message:
    
    [    0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
    
    To make the amd_pstate driver can be loaded on those TR40 processors, it
    needs to match x86_model from 0x30 to 0x7F for family 17H.
    With the change, the system can load amd_pstate driver as expected.
    
    Reviewed-by: Mario Limonciello <[email protected]>
    Reported-by: Gino Badouri <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
    Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")
    Signed-off-by: Perry Yuan <[email protected]>
    Reviewed-by: Gautham R. Shenoy <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: HMAT: Remove register of memory node for generic target [+ + +]
Author: Dave Jiang <[email protected]>
Date:   Fri Mar 8 14:59:20 2024 -0700

    ACPI: HMAT: Remove register of memory node for generic target
    
    [ Upstream commit 54b9460b0a28c4c76a7b455ec1b3b61a13e97291 ]
    
    For generic targets, there's no reason to call
    register_memory_node_under_compute_node() with the access levels that are
    only visible to HMAT handling code. Only update the attributes and rename
    hmat_register_generic_target_initiators() to hmat_update_generic_target().
    
    The original call path ends up triggering register_memory_node_under_compute_node().
    Although the access level would be "3" and not impact any current node arrays, it
    introduces unwanted data into the numa node access_coordinate array.
    
    Fixes: a3a3e341f169 ("acpi: numa: Add setting of generic port system locality attributes")
    Cc: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Tested-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Dave Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Tue Feb 13 01:41:58 2024 +0100

    ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
    
    [ Upstream commit e18afcb7b2a12b635ac10081f943fcf84ddacc51 ]
    
    After unregistering the CPU idle device, the memory associated with
    it is not freed, leading to a memory leak:
    
    unreferenced object 0xffff896282f6c000 (size 1024):
      comm "swapper/0", pid 1, jiffies 4294893170
      hex dump (first 32 bytes):
        00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc 8836a742):
        [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
        [<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0
        [<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0
        [<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50
        [<ffffffff99805872>] really_probe+0xe2/0x480
        [<ffffffff99805c98>] __driver_probe_device+0x78/0x160
        [<ffffffff99805daf>] driver_probe_device+0x1f/0x90
        [<ffffffff9980601e>] __driver_attach+0xce/0x1c0
        [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
        [<ffffffff99804822>] bus_add_driver+0x112/0x210
        [<ffffffff99807245>] driver_register+0x55/0x100
        [<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0
        [<ffffffff990012d1>] do_one_initcall+0x41/0x300
        [<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470
        [<ffffffff99b231f6>] kernel_init+0x16/0x1b0
        [<ffffffff99042e6d>] ret_from_fork+0x2d/0x50
    
    Fix this by freeing the CPU idle device after unregistering it.
    
    Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure")
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override [+ + +]
Author: Maxim Kudinov <[email protected]>
Date:   Fri Feb 23 19:24:08 2024 +0300

    ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override
    
    [ Upstream commit 021a67d096154893cd1d883c7be0097e2ee327fd ]
    
    A known issue on some Zen laptops, keyboard stopped working due to commit
    9946e39fe8d0 [email protected]("ACPI: resource: skip IRQ override on AMD
    Zen platforms") on kernel 5.19.10.
    
    The ACPI IRQ override is required for this board due to buggy DSDT, thus
    adding the board vendor and name to irq1_edge_low_force_override fixes
    the issue.
    
    Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217394
    Link: https://lore.kernel.org/linux-acpi/[email protected]/
    Tested-by: Maxim Trofimov <[email protected]>
    Signed-off-by: Maxim Kudinov <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: resource: Do IRQ override on Lunnen Ground laptops [+ + +]
Author: Alexey I. Froloff <[email protected]>
Date:   Fri Feb 16 12:30:09 2024 +0000

    ACPI: resource: Do IRQ override on Lunnen Ground laptops
    
    [ Upstream commit e23ad54fef186aa66007895be1382c88f1ee2bf7 ]
    
    The Lunnen Ground 15 and 16 needs IRQ overriding for the keyboard to
    work.
    
    Adding an entries for these laptops to the override_table makes the
    internal keyboard functional.
    
    Signed-off-by: Alexey I. Froloff <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: 021a67d09615 ("ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override")
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: scan: Fix device check notification handling [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Feb 26 17:35:27 2024 +0100

    ACPI: scan: Fix device check notification handling
    
    [ Upstream commit 793551c965116d9dfaf0550dacae1396a20efa69 ]
    
    It is generally invalid to fail a Device Check notification if the scan
    handler has not been attached to the given device after a bus rescan,
    because there may be valid reasons for the scan handler to refuse
    attaching to the device (for example, the device is not ready).
    
    For this reason, modify acpi_scan_device_check() to return 0 in that
    case without printing a warning.
    
    While at it, reduce the log level of the "already enumerated" message
    in the same function, because it is only interesting when debugging
    notification handling
    
    Fixes: 443fc8202272 ("ACPI / hotplug: Rework generic code to handle suprise removals")
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_unix: Annotate data-race of gc_in_progress in wait_for_unix_gc(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jan 23 09:08:52 2024 -0800

    af_unix: Annotate data-race of gc_in_progress in wait_for_unix_gc().
    
    [ Upstream commit 31e03207119a535d0b0e3b3a7f91983aeb2cb14d ]
    
    gc_in_progress is changed under spin_lock(&unix_gc_lock),
    but wait_for_unix_gc() reads it locklessly.
    
    Let's use READ_ONCE().
    
    Fixes: 5f23b734963e ("net: Fix soft lockups/OOM issues w/ unix garbage collector")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
afs: Don't cache preferred address [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Mar 13 08:15:02 2024 +0000

    afs: Don't cache preferred address
    
    [ Upstream commit 83505bde45e347f1451d007b3ddd7f06cee4c269 ]
    
    In the AFS fileserver rotation algorithm, don't cache the preferred address
    for the server as that will override the explicit preference if a
    non-preferred address responds first.
    
    Fixes: 495f2ae9e355 ("afs: Fix fileserver rotation")
    Signed-off-by: David Howells <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Marc Dionne <[email protected]>
    cc: Marc Dionne <[email protected]>
    cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

afs: Fix occasional rmdir-then-VNOVNODE with generic/011 [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Mar 13 08:15:03 2024 +0000

    afs: Fix occasional rmdir-then-VNOVNODE with generic/011
    
    [ Upstream commit b74c02a37987d3ea755f96119c527f5e91950592 ]
    
    Sometimes generic/011 causes kafs to follow up an FS.RemoveDir RPC call by
    spending around a second sending a slew of FS.FetchStatus RPC calls to the
    directory just deleted that then abort with VNOVNODE, indicating deletion
    of the target directory.
    
    This seems to stem from userspace attempting to stat the directory or
    something in it:
    
        afs_select_fileserver+0x46d/0xaa2
        afs_wait_for_operation+0x12/0x17e
        afs_fetch_status+0x56/0x75
        afs_validate+0xfb/0x240
        afs_permission+0xef/0x1b0
        inode_permission+0x90/0x139
        link_path_walk.part.0.constprop.0+0x6f/0x2f0
        path_lookupat+0x4c/0xfa
        filename_lookup+0x63/0xd7
        vfs_statx+0x62/0x13f
        vfs_fstatat+0x72/0x8a
    
    The issue appears to be that afs_dir_remove_subdir() marks the callback
    promise as being cancelled by setting the expiry time to AFS_NO_CB_PROMISE
    - which then confuses afs_validate() which sends the FetchStatus to try and
    get a new one before it checks for the AFS_VNODE_DELETED flag which
    indicates that we know the directory got deleted.
    
    Fix this by:
    
     (1) Make afs_check_validity() return true if AFS_VNODE_DELETED is set, and
         then tweak the return from afs_validate() if the DELETED flag is set.
    
     (2) Move the AFS_VNODE_DELETED check in afs_validate() up above the
         expiration check to immediately after we've grabbed the validate_lock.
    
    Fixes: 453924de6212 ("afs: Overhaul invalidation handling to better support RO volumes")
    Signed-off-by: David Howells <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Marc Dionne <[email protected]>
    cc: Marc Dionne <[email protected]>
    cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

afs: Revert "afs: Hide silly-rename files from userspace" [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Mar 13 11:08:41 2024 +0000

    afs: Revert "afs: Hide silly-rename files from userspace"
    
    [ Upstream commit 0aec3847d044273733285dcff90afda89ad461d2 ]
    
    This reverts commit 57e9d49c54528c49b8bffe6d99d782ea051ea534.
    
    This undoes the hiding of .__afsXXXX silly-rename files.  The problem with
    hiding them is that rm can't then manually delete them.
    
    This also reverts commit 5f7a07646655fb4108da527565dcdc80124b14c4 ("afs: Fix
    endless loop in directory parsing") as that's a bugfix for the above.
    
    Fixes: 57e9d49c5452 ("afs: Hide silly-rename files from userspace")
    Reported-by: Markus Suvanto <[email protected]>
    Link: https://lists.infradead.org/pipermail/linux-afs/2024-February/008102.html
    Signed-off-by: David Howells <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Jeffrey E Altman <[email protected]>
    cc: Marc Dionne <[email protected]>
    cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: hda/realtek: fix ALC285 issues on HP Envy x360 laptops [+ + +]
Author: Athaariq Ardhiansyah <[email protected]>
Date:   Sun Mar 10 20:58:44 2024 +0700

    ALSA: hda/realtek: fix ALC285 issues on HP Envy x360 laptops
    
    [ Upstream commit c062166995c9e57d5cd508b332898f79da319802 ]
    
    Realtek codec on HP Envy laptop series are heavily modified by vendor.
    Therefore, need intervention to make it work properly. The patch fixes:
    
    - B&O soundbar speakers (between lid and keyboard) activation
    - Enable LED on mute button
    - Add missing process coefficient which affects the output amplifier
    - Volume control synchronization between B&O soundbar and side speakers
    - Unmute headset output on several HP Envy models
    - Auto-enable headset mic when plugged
    
    This patch was tested on HP Envy x360 13-AR0107AU with Realtek ALC285
    
    The only unsolved problem is output amplifier of all built-in speakers
    is too weak, which causes volume of built-in speakers cannot be loud
    as vendor's proprietary driver due to missing _DSD parameter in the
    firmware. The solution is currently on research. Expected to has another
    patch in the future.
    
    Potential fix to related issues, need test before close those issues:
    
    - https://bugzilla.kernel.org/show_bug.cgi?id=189331
    - https://bugzilla.kernel.org/show_bug.cgi?id=216632
    - https://bugzilla.kernel.org/show_bug.cgi?id=216311
    - https://bugzilla.kernel.org/show_bug.cgi?id=213507
    
    Signed-off-by: Athaariq Ardhiansyah <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tas2781: add lock to system_suspend [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:41 2024 +0100

    ALSA: hda/tas2781: add lock to system_suspend
    
    [ Upstream commit c58e6ed55a1bb9811d6d936d001b068bb0419467 ]
    
    Add the missing lock around tasdevice_tuning_switch().
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    Signed-off-by: Gergo Koteles <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <c666da13d4bc48cd1ab1357479e0c6096541372c.1709918447.git.soyer@irl.hu>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tas2781: do not call pm_runtime_force_* in system_resume/suspend [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:43 2024 +0100

    ALSA: hda/tas2781: do not call pm_runtime_force_* in system_resume/suspend
    
    [ Upstream commit 5f51de7e30c7282162a631af8a425b54a4576346 ]
    
    The runtime_resume function calls prmg_load and apply_calibration
    functions, but system_resume also calls them, so calling
    pm_runtime_force_resume before reset is unnecessary.
    
    For consistency, do not call the pm_runtime_force_suspend in
    system_suspend, as runtime_suspend does the same.
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    Signed-off-by: Gergo Koteles <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <d0b4cc1248b9d375d59c009563da42d60d69eac3.1709918447.git.soyer@irl.hu>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tas2781: do not reset cur_* values in runtime_suspend [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:42 2024 +0100

    ALSA: hda/tas2781: do not reset cur_* values in runtime_suspend
    
    [ Upstream commit bec7760a6c5fa59593dac264fa0c628e46815986 ]
    
    The amplifier doesn't loose register state in software shutdown mode, so
    there is no need to reset the cur_* values.
    
    Without these resets, the amplifier can be turned on after
    runtime_suspend without waiting for the program and
    profile to be restored.
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    Signed-off-by: Gergo Koteles <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <aa27ae084150988bf6a0ead7e3403bc485d790f8.1709918447.git.soyer@irl.hu>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tas2781: restore power state after system_resume [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:44 2024 +0100

    ALSA: hda/tas2781: restore power state after system_resume
    
    [ Upstream commit 9fc91a6fe37c78ef301aed4251f7e50b8524e72d ]
    
    After system_resume the amplifers will remain off, even if they were on
    before system_suspend.
    
    Use playback_started bool to save the playback state, and restore power
    state based on it.
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    Signed-off-by: Gergo Koteles <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <1742b61901781826f6e6212ffe1d21af542d134a.1709918447.git.soyer@irl.hu>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tas2781: use dev_dbg in system_resume [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:40 2024 +0100

    ALSA: hda/tas2781: use dev_dbg in system_resume
    
    [ Upstream commit c850c9121cc8de867ce3ac36b9ae9d05f62bef14 ]
    
    The system_resume function uses dev_info for tracing, but the other pm
    functions use dev_dbg.
    
    Use dev_dbg as the other pm functions.
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    Signed-off-by: Gergo Koteles <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <140f3c689c9eb5874e6eb48a570fcd8207f06a41.1709918447.git.soyer@irl.hu>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda: cs35l41: Set Channel Index correctly when system is missing _DSD [+ + +]
Author: Stefan Binding <[email protected]>
Date:   Fri Jan 26 16:40:02 2024 +0000

    ALSA: hda: cs35l41: Set Channel Index correctly when system is missing _DSD
    
    [ Upstream commit 135096ebfab656823d0037102a00776f3914fee3 ]
    
    Current method to set Channel Index when the system is missing _DSD
    assumes that the channels alternate, which is not guaranteed.
    Instead use the same methodology as the main driver does when _DSD
    exists.
    
    Fixes: 8c4c216db8fb ("ALSA: hda: cs35l41: Add config table to support many laptops without _DSD")
    
    Signed-off-by: Stefan Binding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Fix Scarlett 4th Gen 4i4 low-voltage detection [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Sun Mar 10 21:04:27 2024 +1030

    ALSA: scarlett2: Fix Scarlett 4th Gen 4i4 low-voltage detection
    
    [ Upstream commit 6ef1f08b53fdb6f5f00f17f85a60b3247d77fa54 ]
    
    The value currently being read to determine the low-voltage state is
    actually the front panel state. Fix the code to use the correct offset
    for the low-voltage state.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: d7cfa2fdfc8a ("ALSA: scarlett2: Add power status control")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Fix Scarlett 4th Gen autogain status values [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Sun Mar 10 21:04:41 2024 +1030

    ALSA: scarlett2: Fix Scarlett 4th Gen autogain status values
    
    [ Upstream commit be157c4683a91857d3fdf319117c9b9dc6e8a849 ]
    
    The meanings of the raw_auto_gain_status values were originally
    guessed through experimentation, but the official names have now been
    discovered. Update the autogain status control strings accordingly.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 0a995e38dc44 ("ALSA: scarlett2: Add support for software-controllable input gain")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Fix Scarlett 4th Gen input gain range [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Sun Mar 10 21:04:59 2024 +1030

    ALSA: scarlett2: Fix Scarlett 4th Gen input gain range
    
    [ Upstream commit a45cf0a0834779c741ac204c0320469e9aaef006 ]
    
    The input gain range TLV was declared as -70dB to 0dB, but the preamp
    gain range is actually 0dB to +70dB. Rename SCARLETT2_GAIN_BIAS to
    SCARLETT2_MAX_GAIN and update the TLV to fix.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 0a995e38dc44 ("ALSA: scarlett2: Add support for software-controllable input gain")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Fix Scarlett 4th Gen input gain range again [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Mon Mar 11 19:56:08 2024 +1030

    ALSA: scarlett2: Fix Scarlett 4th Gen input gain range again
    
    [ Upstream commit 6719cd5e45111449f4021e08f2e488f17a9b292b ]
    
    The 4th Gen input preamp gain range is 0dB to +69dB, although the
    control values range from 0 to 70. Replace SCARLETT2_MAX_GAIN with
    SCARLETT2_MAX_GAIN_VALUE and SCARLETT2_MAX_GAIN_DB, and update the TLV
    again.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: a45cf0a08347 ("ALSA: scarlett2: Fix Scarlett 4th Gen input gain range")
    Message-ID: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: seq: fix function cast warnings [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Feb 13 14:53:43 2024 +0100

    ALSA: seq: fix function cast warnings
    
    [ Upstream commit d7bf73809849463f76de42aad62c850305dd6c5d ]
    
    clang-16 points out a control flow integrity (kcfi) issue when event
    callbacks get converted to incompatible types:
    
    sound/core/seq/seq_midi.c:135:30: error: cast from 'int (*)(struct snd_rawmidi_substream *, const char *, int)' to 'snd_seq_dump_func_t' (aka 'int (*)(void *, void *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      135 |                 snd_seq_dump_var_event(ev, (snd_seq_dump_func_t)dump_midi, substream);
          |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    sound/core/seq/seq_virmidi.c:83:31: error: cast from 'int (*)(struct snd_rawmidi_substream *, const unsigned char *, int)' to 'snd_seq_dump_func_t' (aka 'int (*)(void *, void *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       83 |                         snd_seq_dump_var_event(ev, (snd_seq_dump_func_t)snd_rawmidi_receive, vmidi->substream);
          |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    For addressing those errors, introduce wrapper functions that are used
    for callbacks and bridge to the actual function call with pointer
    cast.
    
    The code was originally added with the initial ALSA merge in linux-2.5.4.
    
    [ the patch description shamelessly copied from Arnd's original patch
      -- tiwai ]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Stop parsing channels bits when all channels are found. [+ + +]
Author: Johan Carlsson <[email protected]>
Date:   Wed Mar 13 09:15:09 2024 +0100

    ALSA: usb-audio: Stop parsing channels bits when all channels are found.
    
    [ Upstream commit a39d51ff1f52cd0b6fe7d379ac93bd8b4237d1b7 ]
    
    If a usb audio device sets more bits than the amount of channels
    it could write outside of the map array.
    
    Signed-off-by: Johan Carlsson <[email protected]>
    Fixes: 04324ccc75f9 ("ALSA: usb-audio: add channel map support")
    Message-ID: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts [+ + +]
Author: Chun-Yi Lee <[email protected]>
Date:   Tue Mar 5 16:20:48 2024 +0800

    aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
    
    [ Upstream commit f98364e926626c678fb4b9004b75cacf92ff0662 ]
    
    This patch is against CVE-2023-6270. The description of cve is:
    
      A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
      kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
      `struct net_device`, and a use-after-free can be triggered by racing
      between the free on the struct and the access through the `skbtxq`
      global queue. This could lead to a denial of service condition or
      potential code execution.
    
    In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
    code is finished. But the net_device ifp will still be used in
    later tx()->dev_queue_xmit() in kthread. Which means that the
    dev_put(ifp) should NOT be called in the success path of skb
    initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
    use-after-free because the net_device is freed.
    
    This patch removed the dev_put(ifp) in the success path in
    aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
    
    Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270
    Fixes: 7562f876cd93 ("[NET]: Rework dev_base via list_head (v3)")
    Signed-off-by: Chun-Yi Lee <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: allwinner: h6: Add RX DMA channel for SPDIF [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Sun Jan 28 00:32:45 2024 +0800

    arm64: dts: allwinner: h6: Add RX DMA channel for SPDIF
    
    [ Upstream commit 7b59348c11f3355e284d77bbe3d33632ddadcfc2 ]
    
    The SPDIF hardware found on the H6 supports both transmit and receive
    functions. However it is missing the RX DMA channel.
    
    Add the SPDIF hardware block's RX DMA channel. Also remove the
    by-default pinmux, since the end device can choose to implement
    either or both functionalities.
    
    Fixes: f95b598df419 ("arm64: dts: allwinner: Add SPDIF node for Allwinner H6")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: Andre Przywara <[email protected]>
    Reviewed-by: Jernej Skrabec <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: broadcom: bcmbca: bcm4908: drop invalid switch cells [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Thu Jan 11 12:56:36 2024 +0100

    arm64: dts: broadcom: bcmbca: bcm4908: drop invalid switch cells
    
    [ Upstream commit 27058b95fbb784406ea4c40b20caa3f04937140c ]
    
    Ethernet switch does not have addressable subnodes.
    
    This fixes:
    arch/arm64/boot/dts/broadcom/bcmbca/bcm4908-asus-gt-ac5300.dtb: ethernet-switch@0: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/net/dsa/brcm,sf2.yaml#
    
    Fixes: 527a3ac9bdf8 ("arm64: dts: broadcom: bcm4908: describe internal switch")
    Signed-off-by: Rafał Miłecki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL board [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:03 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL board
    
    [ Upstream commit 008820524844326ffb3123cebceba1960c0ad0dc ]
    
    Some signals have external pullup resistors on the board and don't need
    the internal ones to be enabled. Due to silicon errata ERR050080 let's
    disable the internal pull resistors whererever possible and prevent
    any unwanted behavior in case they wear out.
    
    Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL OSM-S board [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:02 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL OSM-S board
    
    [ Upstream commit 5a940ba3e4d7c8710c9073ff5d0ca4644d4da9db ]
    
    Some signals have external pullup resistors on the board and don't need
    the internal ones to be enabled. Due to silicon errata ERR050080 let's
    disable the internal pull resistors whererever possible and prevent
    any unwanted behavior in case they wear out.
    
    Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S i.MX8MM [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:48:58 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S i.MX8MM
    
    [ Upstream commit 96293af54f6aa859015d8ca40a1437d3115ad50c ]
    
    There are external pullup resistors on the board and due to silicon
    errata ERR050080 let's disable the internal ones to prevent any
    unwanted behavior in case they wear out.
    
    Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL i.MX8MM [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:48:59 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL i.MX8MM
    
    [ Upstream commit f19e5bb91d53264d7dac5d845a4825afadf72440 ]
    
    There are external pullup resistors on the board and due to silicon
    errata ERR050080 let's disable the internal ones to prevent any
    unwanted behavior in case they wear out.
    
    Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL board [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:01 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL board
    
    [ Upstream commit 162aadaa0df8217b0cc49d919dd00022fef65e78 ]
    
    These signals are actively driven by the SoC or by the onboard
    transceiver. There's no need to enable the internal pull resistors
    and due to silicon errata ERR050080 let's disable the internal ones
    to prevent any unwanted behavior in case they wear out.
    
    Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL OSM-S board [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:00 2024 +0100

    arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL OSM-S board
    
    [ Upstream commit c6d9b5672a0e2c4b1079a50d2fc8780c40cfd3eb ]
    
    These signals are actively driven by the SoC or by the onboard
    transceiver. There's no need to enable the internal pull resistors
    and due to silicon errata ERR050080 let's disable the internal ones
    to prevent any unwanted behavior in case they wear out.
    
    Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM module [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:04 2024 +0100

    arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM module
    
    [ Upstream commit 8d0f39b7d04d864e89b84063b124fd10aa4b8809 ]
    
    The level of the interrupt signal is active low instead. Fix this.
    
    Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
    Signed-off-by: Frieder Schrempf <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS [+ + +]
Author: Tim Harvey <[email protected]>
Date:   Wed Dec 20 15:30:46 2023 -0800

    arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS
    
    [ Upstream commit ec2cb52fcfef5d58574f2cfbc9a99ffc20ae5a9d ]
    
    The GW71xx does not have a gpio controlled vbus regulator but it does
    require some pinctrl. Remove the regulator and move the valid pinctrl
    into the usbotg1 node.
    
    Fixes: bd306fdb4e60 ("arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS")
    Signed-off-by: Tim Harvey <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mp-evk: Fix hdmi@3d node [+ + +]
Author: Liu Ying <[email protected]>
Date:   Fri Feb 23 10:57:38 2024 +0800

    arm64: dts: imx8mp-evk: Fix hdmi@3d node
    
    [ Upstream commit 0ff08803eca417dfa9372194bebf3d1b1f501f98 ]
    
    The hdmi@3d node's compatible string is "adi,adv7535" instead of
    "adi,adv7533" or "adi,adv751*".
    
    Fix the hdmi@3d node by means of:
    * Use default register addresses for "cec", "edid" and "packet", because
      there is no need to use a non-default address map.
    * Add missing interrupt related properties.
    * Drop "adi,input-*" properties which are only valid for adv751*.
    * Add VEXT_3V3 fixed regulator.
    * Add "*-supply" properties, since most are required.
    * Fix label names - s/adv7533/adv7535/.
    
    Fixes: 65344b9bed3a ("arm64: dts: imx8mp-evk: Add HDMI support")
    Signed-off-by: Liu Ying <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mp: Set SPI NOR to max 40 MHz on Data Modul i.MX8M Plus eDM SBC [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Sat Feb 17 22:33:30 2024 +0100

    arm64: dts: imx8mp: Set SPI NOR to max 40 MHz on Data Modul i.MX8M Plus eDM SBC
    
    [ Upstream commit 13ab6f174a6b577bd7d09124b47ec8ace2682e42 ]
    
    The SPI NOR bus routing on this board cannot go above 50 MHz,
    set the clock frequency to maximum of 40 MHz to be within a
    safe margin. Remove the comment as well.
    
    Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8qm: Align edma3 power-domains resources indentation [+ + +]
Author: Frank Li <[email protected]>
Date:   Thu Dec 14 14:46:54 2023 -0500

    arm64: dts: imx8qm: Align edma3 power-domains resources indentation
    
    [ Upstream commit 7edee2b297e5a4f805e5b945c0c0e6f4f8f719b5 ]
    
    <&pd IMX_SC_R_DMA_1_CH*> is now properly aligned with the previous line
    for improved code readability.
    
    Signed-off-by: Frank Li <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Stable-dep-of: 5136ea6b109d ("arm64: dts: imx8qm: Correct edma3 power-domains and interrupt numbers")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8qm: Correct edma3 power-domains and interrupt numbers [+ + +]
Author: Frank Li <[email protected]>
Date:   Thu Dec 14 14:46:55 2023 -0500

    arm64: dts: imx8qm: Correct edma3 power-domains and interrupt numbers
    
    [ Upstream commit 5136ea6b109de66b1327a3069f88ad8f5efb37b2 ]
    
    It is eDMA1 at QM, which have the same register with eDMA3 at qxp.
    
    The below commit fix panic problem.
    commit b37e75bddc35 ("arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic during startup")
    
    This fixes the IRQ and DMA channel numbers. While QM eDMA1 technically has
    32 channels, only 10 channels are likely used for I2C. The exact IRQ
    numbers for the remaining channels were unclear in the reference manual.
    
    Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
    Signed-off-by: Frank Li <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: marvell: reorder crypto interrupts on Armada SoCs [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Tue Jan 23 13:22:58 2024 +0100

    arm64: dts: marvell: reorder crypto interrupts on Armada SoCs
    
    [ Upstream commit ec55a22149d64f9ac41845d923b884d4a666bf4d ]
    
    Match order specified in binding documentation. It says "mem" should be
    the last interrupt.
    
    This fixes:
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:0: 'ring0' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:1: 'ring1' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:2: 'ring2' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:3: 'ring3' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:4: 'eip' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:5: 'mem' was expected
            from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodes [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Mon Jan 22 14:23:57 2024 +0100

    arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodes
    
    [ Upstream commit 99d100e00144bc01b49a697f4bc4398f2f7e7ce4 ]
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: /: memory@40000000: 'device_type' is a required property
            from schema $id: http://devicetree.org/schemas/memory.yaml#
    arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: /: memory@40000000: 'device_type' is a required property
            from schema $id: http://devicetree.org/schemas/memory.yaml#
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfg [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Mon Jan 1 19:20:40 2024 +0100

    arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfg
    
    [ Upstream commit d993daff5962b2dd08f32a83bb1c0e5fa75732ea ]
    
    MT7986's Infrastructure System Configuration Controller includes reset
    controller. It can reset blocks as specified in the
    include/dt-bindings/reset/mt7986-resets.h . Add #reset-cells so it can
    be referenced properly.
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: infracfg@10001000: '#reset-cells' is a required property
            from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#
    
    Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a")
    Cc: Sam Shih <[email protected]>
    Signed-off-by: Rafał Miłecki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: drop "#clock-cells" from PWM [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Mon Jan 1 19:20:39 2024 +0100

    arm64: dts: mediatek: mt7986: drop "#clock-cells" from PWM
    
    [ Upstream commit 0b721691f0c80af682d0ef3aa4a177c23d41b072 ]
    
    PWM is not a clock provider and its binding doesn't specify
    "#clock-cells" property.
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm@10048000: '#clock-cells' does not match any of the regexes: 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/pwm/mediatek,mt2712-pwm.yaml#
    
    Fixes: eabb04df46c6 ("arm64: dts: mt7986: add PWM")
    Cc: Daniel Golle <[email protected]>
    Signed-off-by: Rafał Miłecki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Thu Nov 16 14:24:11 2023 +0100

    arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name
    
    [ Upstream commit bb69d19c649669f700149df309245cd925612f7c ]
    
    According to the "inside-secure,safexcel-eip97" binding "clock-names" is
    required only if there are two clocks specified. If present the first
    name must by "core".
    
    Name "infra_eip97_ck" is invalid and was probably just a typo. Drop it.
    
    Fixes: ecc5287cfe53 ("arm64: dts: mt7986: add crypto related device nodes")
    Cc: Sam Shih <[email protected]>
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: fix reference to PWM in fan node [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Thu Nov 16 14:08:16 2023 +0100

    arm64: dts: mediatek: mt7986: fix reference to PWM in fan node
    
    [ Upstream commit 7865abbbdf1e1ee57a0bb8ec83079f8840c16854 ]
    
    This fixes typo and resolves following validation error:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[54, 0, 10000], [0]] is too long
            from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml#
    
    Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts")
    Cc: Daniel Golle <[email protected]>
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: fix SPI bus width properties [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Thu Nov 16 14:09:51 2023 +0100

    arm64: dts: mediatek: mt7986: fix SPI bus width properties
    
    [ Upstream commit 4e7dc18a753cec130b06f1ddbae10ea9dcfb1723 ]
    
    This fixes SPI setup and resolves following validation errors:
    arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected)
            from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
    arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected)
            from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
    
    Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes")
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986: fix SPI nodename [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Thu Nov 16 14:09:52 2023 +0100

    arm64: dts: mediatek: mt7986: fix SPI nodename
    
    [ Upstream commit bbe266c70e1343ee3e71ca31138141b3da265085 ]
    
    This fixes following validation errors:
    arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$'
            from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
    arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$'
            from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
    
    Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes")
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186: Add missing clocks to ssusb power domains [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue Feb 13 10:02:37 2024 -0500

    arm64: dts: mediatek: mt8186: Add missing clocks to ssusb power domains
    
    [ Upstream commit a00d4a98af44e025891e97c490b2545368a25e08 ]
    
    The ssusb power domains currently don't list any clocks, despite
    depending on some, and thus rely on the bootloader leaving the required
    clocks on in order to work.
    
    When booting with the upstream arm64 defconfig, the power domain
    controller will defer probe until modules have loaded since it has an
    indirect dependency on CONFIG_MTK_CMDQ, which is configured as a module.
    However at the point where modules are loaded, unused clocks are also
    disabled, causing the ssusb domains to fail to be enabled and
    consequently the controller to fail probe:
    
    mtk-power-controller 10006000.syscon:power-controller: /soc/syscon@10006000/power-controller/power-domain@4: failed to power on domain: -110
    mtk-power-controller: probe of 10006000.syscon:power-controller failed with error -110
    
    Add the missing clocks for the ssusb power domains so that they can
    successfully probe without relying on the bootloader state.
    
    Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/20240213-mt8186-ssusb-domain-clk-fix-v2-1-1f981d35f3fd@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186: Add missing xhci clock to usb controllers [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue Feb 13 10:02:38 2024 -0500

    arm64: dts: mediatek: mt8186: Add missing xhci clock to usb controllers
    
    [ Upstream commit 1af98c3e53da5a8f627855cecd68b017e753ffd3 ]
    
    The mtu3 usb controllers don't list the xhci clock, though they require
    it, and thus rely on the bootloader leaving it on in order to work.
    
    When booting with the upstream arm64 defconfig, the usb controllers will
    defer probe until modules have loaded since they have an indirect
    dependency on CONFIG_MTK_CMDQ, which is configured as a module. However
    at the point where modules are loaded, unused clocks are also disabled,
    causing the usb controllers to probe without the xhci clock enabled and
    fail to probe:
    
    mtu3 11201000.usb: clks of sts1 are not stable!
    mtu3 11201000.usb: device enable failed -110
    mtu3 11201000.usb: mtu3 hw init failed:-110
    mtu3 11201000.usb: failed to initialize gadget
    mtu3: probe of 11201000.usb failed with error -110
    
    (and same for the one at 11281000)
    
    Add the missing clock for the usb controllers so that they can
    successfully probe without relying on the bootloader state.
    
    Fixes: f6c3e61c5486 ("arm64: dts: mediatek: mt8186: Add MTU3 nodes")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/20240213-mt8186-ssusb-domain-clk-fix-v2-2-1f981d35f3fd@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186: fix VENC power domain clocks [+ + +]
Author: Eugen Hristev <[email protected]>
Date:   Thu Dec 28 13:32:44 2023 +0200

    arm64: dts: mediatek: mt8186: fix VENC power domain clocks
    
    [ Upstream commit 09860910c589a3bb3b5268ff6f704cf6b18ada73 ]
    
    The larb clock is in fact a subsys clock, so it must be prefixed by
    'subsys-' to be correctly identified in the driver.
    
    Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller")
    Signed-off-by: Eugen Hristev <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection node [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Wed Feb 7 15:08:42 2024 -0500

    arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection node
    
    [ Upstream commit 9b49cabe631b0a25aaf8fc2ba81b5b9ea6ff01b7 ]
    
    The commit adding the ChromeOS EC to the Asurada Devicetree mistakenly
    added a base detection node. While tablet mode detection is supported by
    CrosEC and used by Hayato, it is done through the cros-ec-keyb driver.
    The base detection node, which is handled by the hid-google-hammer
    driver, also provides tablet mode detection but by checking base
    attachment status on the CrosEC, which is not supported for Asurada.
    
    Hence, remove the unused CrosEC base detection node for Asurada.
    
    Fixes: eb188a2aaa82 ("arm64: dts: mediatek: asurada: Add ChromeOS EC")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/20240207-mt8192-asurada-cbas-remove-v1-1-04cb65951975@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8192: fix vencoder clock name [+ + +]
Author: Eugen Hristev <[email protected]>
Date:   Thu Dec 28 13:32:42 2023 +0200

    arm64: dts: mediatek: mt8192: fix vencoder clock name
    
    [ Upstream commit 76aac0f2a46847ed4a7a4fdd848dd66023c19ad1 ]
    
    Clock name should be `venc_sel` as per binding.
    Fix the warning message :
    arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec@17020000: clock-names:0: 'venc_sel' was expected
            from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml#
    
    Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node")
    Signed-off-by: Eugen Hristev <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTs [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue Jan 16 18:38:34 2024 -0300

    arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTs
    
    [ Upstream commit 04bd6411f506357fd1faedc2b2156e7ef206aa9a ]
    
    The cbas node is used to describe base detection functionality in the
    ChromeOS EC, which is used for units that have a detachable keyboard and
    thus rely on this functionality to switch between tablet and laptop
    mode.
    
    Despite the original commit having added the cbas node to the
    mt8183-kukui.dtsi, not all machines that include it are detachables. In
    fact all machines that include from mt8183-kukui-jacuzzi.dtsi are either
    clamshells (ie normal laptops) or convertibles, meaning the keyboard can
    be flipped but not detached. The detection for the keyboard getting
    flipped is handled by the driver bound to the keyboard-controller node
    in the EC.
    
    Move the base detection node from the base kukui dtsi to the dtsis where
    all machines are detachables, and thus actually make use of the node.
    
    Fixes: 4fa8492d1e5b ("arm64: dts: mt8183: add cbas node under cros_ec")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/20240116-mt8183-kukui-cbas-remove-v3-1-055e21406e86@collabora.com
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mt8195-cherry-tomato: change watchdog reset boot flow [+ + +]
Author: Hsin-Te Yuan <[email protected]>
Date:   Wed Jan 24 07:51:57 2024 +0000

    arm64: dts: mt8195-cherry-tomato: change watchdog reset boot flow
    
    [ Upstream commit ef569d5db50e7edd709e482157769a5b3c367e22 ]
    
    The external output reset signal was originally disabled and sent from
    firmware. However, an unfixed bug in the firmware on tomato prevents
    the signal from being sent, causing the device to fail to boot. To fix
    this, enable external output reset signal to allow the device to reboot
    normally.
    
    Fixes: 5eb2e303ec6b ("arm64: dts: mediatek: Introduce MT8195 Cherry platform's Tomato")
    Signed-off-by: Hsin-Te Yuan <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: qcm2290: declare VLS CLAMP register for USB3 PHY [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jan 17 16:04:26 2024 +0200

    arm64: dts: qcom: qcm2290: declare VLS CLAMP register for USB3 PHY
    
    [ Upstream commit acb94d67f5a23dbb2e0021b6c30609ed05d7d6a5 ]
    
    The USB3 PHY on the QCM2290 platform doesn't have built-in
    PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately
    via the register in the TCSR space. Declare corresponding register.
    
    Fixes: 0c55f6229bc3 ("arm64: dts: qcom: qcm2290: Add USB3 PHY")
    Signed-off-by: Dmitry Baryshkov <[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]>

arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Fri Dec 29 13:53:17 2023 +0100

    arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory
    
    [ Upstream commit 5dbbe7e0a2b91ac5901ee188724a997004759171 ]
    
    It seems we also need to reserve a region of 81 MiB called "removed_mem"
    otherwise we can easily hit the following error with higher RAM usage:
    
      [ 1467.809274] Internal error: synchronous external abort: 0000000096000010 [#2] SMP
    
    Fixes: eee9602ad649 ("arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5")
    Signed-off-by: Luca Weiss <[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]>

arm64: dts: qcom: qcm6490-idp: Correct the voltage setting for vph_pwr [+ + +]
Author: Komal Bajaj <[email protected]>
Date:   Wed Dec 20 16:30:14 2023 +0530

    arm64: dts: qcom: qcm6490-idp: Correct the voltage setting for vph_pwr
    
    [ Upstream commit aa56130e88de50773f84de4039c7de81ab783744 ]
    
    Min and max voltages for vph_pwr should be same, otherwise rpmh
    will not probe, so correcting the min and max voltages for vph_pwr.
    
    Fixes: 9af6a9f32ad0 ("arm64: dts: qcom: Add base qcm6490 idp board dts")
    Signed-off-by: Komal Bajaj <[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]>

arm64: dts: qcom: qcs6490-rb3gen2: Correct the voltage setting for vph_pwr [+ + +]
Author: Komal Bajaj <[email protected]>
Date:   Wed Dec 20 16:30:15 2023 +0530

    arm64: dts: qcom: qcs6490-rb3gen2: Correct the voltage setting for vph_pwr
    
    [ Upstream commit 05f439c0e64b877c1f9cc7f0bed894b6df45d43d ]
    
    Min and max voltages for vph_pwr should be same, otherwise rpmh
    will not probe, so correcting the min and max voltages for vph_pwr.
    
    Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts")
    Signed-off-by: Komal Bajaj <[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]>

arm64: dts: qcom: rename PM2250 to PM4125 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Jan 28 03:32:45 2024 +0200

    arm64: dts: qcom: rename PM2250 to PM4125
    
    [ Upstream commit 39e62f41c3ce210554cc054f345d4135ef4e587b ]
    
    It seems, the only actual mentions of PM2250 can be found are related to
    the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a
    PMIC name. Rename PM2250 to PM4125 to follow the documentation.
    
    Note, this doesn't change the compatible strings. There was a previous
    argument regarding renaming of compat strings.
    
    Fixes: c309b9a54039 ("arm64: dts: qcom: Add initial PM2250 device tree")
    Acked-by: Konrad Dybcio <[email protected]>
    Signed-off-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]>

arm64: dts: qcom: sa8540p: Drop gfx.lvl as power-domain for gpucc [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Thu Jan 25 13:05:11 2024 -0800

    arm64: dts: qcom: sa8540p: Drop gfx.lvl as power-domain for gpucc
    
    [ Upstream commit fd5821a1a83c969ed2dcc72fef885f3a82c1d978 ]
    
    The SA8295P and SA8540P uses an external regulator (max20411), and
    gfx.lvl is not provided by rpmh. Drop the power-domains property of the
    gpucc node to reflect this.
    
    Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7280: Add static properties to cryptobam [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Fri Dec 29 09:51:37 2023 +0100

    arm64: dts: qcom: sc7280: Add static properties to cryptobam
    
    [ Upstream commit 40ec6a2817d927367461fb0335b42b0d494ff927 ]
    
    When the properties num-channels & qcom,num-ees are not specified, the
    driver tries to read the values from registers, but this read fails and
    resets the device if the interconnect from the qcom,qce node is not
    already active when that happens.
    
    Add the static properties to not touch any registers during probe, the
    rest of the time when the BAM is used by QCE then the interconnect will
    be active already.
    
    Fixes: d488f903a860 ("arm64: dts: qcom: sc7280: add QCrypto nodes")
    Signed-off-by: Luca Weiss <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc8180x: Add missing CPU off state [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:05 2023 +0100

    arm64: dts: qcom: sc8180x: Add missing CPU off state
    
    [ Upstream commit 07b600dfdfea65d58dd80ea25becd8cff69bfafc ]
    
    The CPUs can be powered off without pulling the plug from the rest of
    the system. Describe the idle state responsible for this.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Add missing CPU<->MDP_CFG path [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:09 2023 +0100

    arm64: dts: qcom: sc8180x: Add missing CPU<->MDP_CFG path
    
    [ Upstream commit f0cd5a0ebd419bd151ed79baf5f044da797521ac ]
    
    To guarantee the required resources are enabled, describe the
    interconnect path between the MDSS and the CPU.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Don't hold MDP core clock at FMAX [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:07 2023 +0100

    arm64: dts: qcom: sc8180x: Don't hold MDP core clock at FMAX
    
    [ Upstream commit 309b5774f45aafd002efdb2656673542419abd6f ]
    
    There's an OPP table to handle this, drop the permanent vote.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Fix eDP PHY power-domains [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:06 2023 +0100

    arm64: dts: qcom: sc8180x: Fix eDP PHY power-domains
    
    [ Upstream commit 24e98cb3d5e2c86565680e00008a794b4eac0040 ]
    
    The (e)DP PHYs are powered by the MX line, not through the MDSS GDSC.
    Fix that up.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Fix up big CPU idle state entry latency [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:04 2023 +0100

    arm64: dts: qcom: sc8180x: Fix up big CPU idle state entry latency
    
    [ Upstream commit 266a3a92044b89c392b3e9cfcc328d4167c18294 ]
    
    The entry latency was oddly low.. Turns out somebody forgot about a
    second '1'! Fix it.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Hook up VDD_CX as GCC parent domain [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:03 2023 +0100

    arm64: dts: qcom: sc8180x: Hook up VDD_CX as GCC parent domain
    
    [ Upstream commit 3c58b96df110a80e78fa36ef928f1e6c375008e3 ]
    
    Most of GCC is powered by the CX rail. Describe that relationship to
    let the performance state requests trickle up the chain.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Require LOW_SVS vote for MMCX if DISPCC is on [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:08 2023 +0100

    arm64: dts: qcom: sc8180x: Require LOW_SVS vote for MMCX if DISPCC is on
    
    [ Upstream commit 6d9fb9e4c473cdfd2adca019b46d8e482105cae7 ]
    
    To ensure the PLLs are getting enough power, cast a vote with DISPCC so
    that MMCX is at least at LOW_SVS.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-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]>

arm64: dts: qcom: sc8180x: Shrink aoss_qmp register space size [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:10 2023 +0100

    arm64: dts: qcom: sc8180x: Shrink aoss_qmp register space size
    
    [ Upstream commit dcad0590d1ea4278a55c30dd2903611a96111601 ]
    
    The AOSS_QMP region is overallocated, bleeding into space that's supposed
    to be used by other peripherals. Fix it.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-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]>

arm64: dts: qcom: sdm845-db845c: correct PCIe wake-gpios [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Jan 8 14:12:15 2024 +0100

    arm64: dts: qcom: sdm845-db845c: correct PCIe wake-gpios
    
    [ Upstream commit 584a327c5cffc36369b2a8953d9448826240f1ac ]
    
    Bindings allow a "wake", not "enable", GPIO.  Schematics also use WAKE
    name for the pin:
    
      sdm845-db845c.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected)
    
    Fixes: 4a657c264b78 ("arm64: dts: qcom: db845c: Enable PCIe controllers")
    Signed-off-by: Krzysztof Kozlowski <[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]>

arm64: dts: qcom: sdm845-oneplus-common: improve DAI node naming [+ + +]
Author: David Heidelberg <[email protected]>
Date:   Fri Dec 29 21:02:33 2023 +0100

    arm64: dts: qcom: sdm845-oneplus-common: improve DAI node naming
    
    [ Upstream commit afe9867a0c0e10ba618c15d4ef6f8699872f6cc3 ]
    
    Make it easier to understand what the reg in those nodes is by using the
    constants provided by qcom,q6dsp-lpass-ports.h.
    
    Name nodes according to dt-binding expectations.
    
    Fix for
    ```
    arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dtb: service@4: dais: Unevaluated properties are not allowed ('qi2s@22', 'qi2s@23' were unexpected)
    ```
    
    Fixes: b7b734286856 ("arm64: dts: qcom: sdm845-oneplus-*: add audio devices")
    Signed-off-by: David Heidelberg <[email protected]>
    Reviewed-by: Luca Weiss <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sdm845: Use the Low Power Island CX/MX for SLPI [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Wed Dec 20 15:15:11 2023 +0100

    arm64: dts: qcom: sdm845: Use the Low Power Island CX/MX for SLPI
    
    [ Upstream commit 5dd227ccfb9568935bdaf82bc1893b36457dd4d3 ]
    
    The SLPI is powered by the Low Power Island power rails. Fix the incorrect
    assignment.
    
    Fixes: 74588aada59a ("arm64: dts: qcom: sdm845: add SLPI remoteproc")
    Signed-off-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]>

arm64: dts: qcom: sm6115: declare VLS CLAMP register for USB3 PHY [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jan 17 16:04:27 2024 +0200

    arm64: dts: qcom: sm6115: declare VLS CLAMP register for USB3 PHY
    
    [ Upstream commit 95d739ed962c9aaa17d77b739606dbdf31879f6e ]
    
    The USB3 PHY on the SM6115 platform doesn't have built-in
    PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately
    via the register in the TCSR space. Declare corresponding register.
    
    Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node")
    Signed-off-by: Dmitry Baryshkov <[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]>

arm64: dts: qcom: sm6115: drop pipe clock selection [+ + +]
Author: Vladimir Zapolskiy <[email protected]>
Date:   Tue Jan 30 21:32:58 2024 +0200

    arm64: dts: qcom: sm6115: drop pipe clock selection
    
    [ Upstream commit 7e3a1f6470f7243c81156d2ead60f87da1184225 ]
    
    Stop selecting UTMI clock as the USB3 PIPE clock. This setting is
    incompatible with the USB host working in USB3 (SuperSpeed) mode.
    While we are at it, also drop the default setting for the port speed.
    
    Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node")
    Signed-off-by: Vladimir Zapolskiy <[email protected]>
    [DB: fixed commit message, dropped dr_mode setting]
    Reviewed-by: Konrad Dybcio <[email protected]>
    Tested-by: Luca Weiss <[email protected]> # sdm632-fairphone-fp3
    Signed-off-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]>

arm64: dts: qcom: sm8150: correct PCIe wake-gpios [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Jan 8 14:12:16 2024 +0100

    arm64: dts: qcom: sm8150: correct PCIe wake-gpios
    
    [ Upstream commit 7c38989d0f7a35c83e7c4781271d42662903fa8d ]
    
    Bindings allow a "wake", not "enable", GPIO.  Schematics also use WAKE
    name for the pin:
    
      sa8155p-adp.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected)
    
    Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes")
    Signed-off-by: Krzysztof Kozlowski <[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]>

arm64: dts: qcom: sm8450: Add missing interconnects to serial [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Jan 16 13:25:44 2024 +0100

    arm64: dts: qcom: sm8450: Add missing interconnects to serial
    
    [ Upstream commit 6e115b75b43bd12d4061e53c8ff175e387783d8a ]
    
    The serial ports did not have their interconnect paths specified when
    they were first introduced. Fix that.
    
    Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI")
    Fixes: f5837418479a ("arm64: dts: qcom: sm8450: add uart20 node")
    Reported-by: Krzysztof Kozlowski <[email protected]>
    Suggested-by: Georgi Djakov <[email protected]>
    Signed-off-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Tested-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8550: Fix SPMI channels size [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Wed Feb 21 15:04:25 2024 +0200

    arm64: dts: qcom: sm8550: Fix SPMI channels size
    
    [ Upstream commit 77dd1e50ffcba33c3195ae4fc78f354368ddacb2 ]
    
    The actual size of the channels registers region is 4MB, according to the
    documentation. This issue was not caught until now because the driver was
    supposed to allow same regions being mapped multiple times for supporting
    multiple buses. Thie driver is using platform_get_resource_byname() and
    devm_ioremap() towards that purpose, which intentionally avoids
    devm_request_mem_region() altogether.
    
    Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi")
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Abel Vesa <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD
    Link: https://lore.kernel.org/r/20240221-dts-qcom-sm8550-fix-spmi-chnls-size-v2-1-72b5efd9dc4f@linaro.org
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8650: Fix SPMI channels size [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Wed Feb 21 15:04:26 2024 +0200

    arm64: dts: qcom: sm8650: Fix SPMI channels size
    
    [ Upstream commit a4f82b8045e3c7913266aa6ea1ee15752a062abd ]
    
    The actual size of the channels registers region is 4MB, according to the
    documentation. This issue was not caught until now because the driver was
    supposed to allow same regions being mapped multiple times for supporting
    multiple buses. Thie driver is using platform_get_resource_byname() and
    devm_ioremap() towards that purpose, which intentionally avoids
    devm_request_mem_region() altogether.
    
    Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Abel Vesa <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD
    Link: https://lore.kernel.org/r/20240221-dts-qcom-sm8550-fix-spmi-chnls-size-v2-2-72b5efd9dc4f@linaro.org
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8650: Fix UFS PHY clocks [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Wed Jan 31 12:37:40 2024 +0530

    arm64: dts: qcom: sm8650: Fix UFS PHY clocks
    
    [ Upstream commit 0f9b8054bb4abd7b4686cc66b85f71fec9160136 ]
    
    QMP PHY used in SM8650 requires 3 clocks:
    
    * ref - 19.2MHz reference clock from RPMh
    * ref_aux - Auxiliary reference clock from GCC
    * qref - QREF clock from TCSR
    
    Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
    Signed-off-by: Manivannan Sadhasivam <[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]>

arm64: dts: qcom: x1e80100-qcp: Fix supplies for LDOs 3E and 2J [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Mon Jan 29 14:45:43 2024 +0200

    arm64: dts: qcom: x1e80100-qcp: Fix supplies for LDOs 3E and 2J
    
    [ Upstream commit 7eac281cbedbd71d777eabca3a52d97983c61692 ]
    
    The LDOs 3E and 2J are actually supplied by SMPS 5J. Fix accordingly.
    
    Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
    Acked-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/20240129-x1e80100-dts-missing-nodes-v6-11-2c0e691cfa3b@linaro.org
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: x1e80100: drop qcom,drv-count [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Dec 18 15:50:50 2023 +0100

    arm64: dts: qcom: x1e80100: drop qcom,drv-count
    
    [ Upstream commit e81e86765f957f3c5d48df9e275c527bd8c14156 ]
    
    Property qcom,drv-count in the RSC node is not allowed and not used:
    
      x1e80100-crd.dtb: rsc@17500000: 'qcom,drv-count' does not match any of the regexes: '^regulators(-[0-9])?$', 'pinctrl-[0-9]+'
    
    Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizes [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Sun Feb 11 15:21:30 2024 +0100

    arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizes
    
    [ Upstream commit 0c51912331f8ba5ce5fb52f46e340945160672a3 ]
    
    All Ethernet AVB instances on R-Car V3U have registers related to UDP/IP
    support, but the declared register blocks for the first two instances
    are too small to cover them.
    
    Fix this by extending the register block sizes.
    
    Fixes: 5a633320f08b8c9b ("arm64: dts: renesas: r8a779a0: Add Ethernet-AVB support")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/ce6ce3c4b1495e02e7c1803fca810a7178a84500.1707660323.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a779g0: Add missing SCIF_CLK2 [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 18 17:32:37 2024 +0100

    arm64: dts: renesas: r8a779g0: Add missing SCIF_CLK2
    
    [ Upstream commit 08e799f6bce80dd63c174d8d0fc61d1a6149960b ]
    
    R-Car V4H actually has two SCIF_CLK pins.
    The second pin provides the SCIF_CLK signal for HSCIF2 and SCIF4.
    
    Fixes: a4c31c56d2d35641 ("arm64: dts: renesas: r8a779g0: Add SCIF nodes")
    Fixes: 39d9dfc6fbe1860e ("arm64: dts: renesas: r8a779g0: Add remaining HSCIF nodes")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/72f20c1bf32187bd30a963cafe27252907d661f9.1705589612.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a779g0: Correct avb[01] reg sizes [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Sun Feb 11 15:21:31 2024 +0100

    arm64: dts: renesas: r8a779g0: Correct avb[01] reg sizes
    
    [ Upstream commit 7edbb5880dc3317a5eaec2166de71ff394598e6b ]
    
    All Ethernet AVB instances on R-Car V4H have registers related to UDP/IP
    support, but the declared register blocks for the first two instances
    are too small to cover them.
    
    Fix this by extending the register block sizes.
    
    Fixes: 848c82db56923a8b ("arm64: dts: renesas: r8a779g0: Add RAVB nodes")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/83437778614a7c96f4d8f1be98dffeee29bb4a0b.1707660323.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r8a779g0: Restore sort order [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Jan 15 14:33:18 2024 +0100

    arm64: dts: renesas: r8a779g0: Restore sort order
    
    [ Upstream commit 8b93657c976a61726d7ffbe8d019b84b4abfb673 ]
    
    Numerical by unit address, alphabetical by node name.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/f00ef274a73c8fd60f940a1649423a8927b9ae8a.1705324708.git.geert+renesas@glider.be
    Stable-dep-of: 08e799f6bce8 ("arm64: dts: renesas: r8a779g0: Add missing SCIF_CLK2")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r9a08g045: Add missing interrupts to IRQC node [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Mon Feb 5 14:44:21 2024 +0000

    arm64: dts: renesas: r9a08g045: Add missing interrupts to IRQC node
    
    [ Upstream commit bf7e37716d995c54630c30540db5642f58ea037a ]
    
    The IRQC block on the RZ/G3S (R9A08G045) SoC supports ECCRAM error
    interrupts too.  Add those missing interrupts to the IRQC node.
    
    Fixes: 837918aa3fdd ("arm64: dts: renesas: r9a08g045: Add IA55 interrupt controller node")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Mon Feb 5 14:44:20 2024 +0000

    arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes
    
    [ Upstream commit 14fe225dd5fcd5928583b0bcc34398a581f51602 ]
    
    The IRQC IP block supports Bus error and ECCRAM interrupts on RZ/G2L and
    alike SoC's (listed below).  Update the IRQC nodes with the missing
    interrupts, and additionally, include the 'interrupt-names' properties
    in the IRQC nodes so that the driver can parse interrupts by name.
    
      - R9A07G043U              - RZ/G2UL
      - R9A07G044L/R9A07G044LC  - RZ/{G2L,G2LC}
      - R9A07G054               - RZ/V2L
    
    Fixes: 5edc51af5b30 ("arm64: dts: renesas: r9a07g044: Add IRQC node")
    Fixes: 48ab6eddd8bb ("arm64: dts: renesas: r9a07g043u: Add IRQC node")
    Fixes: 379478ab09e0 ("arm64: dts: renesas: r9a07g054: Add IRQC node")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: rzg3s-smarc-som: Guard Ethernet IRQ GPIO hogs [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Thu Feb 8 14:42:55 2024 +0200

    arm64: dts: renesas: rzg3s-smarc-som: Guard Ethernet IRQ GPIO hogs
    
    [ Upstream commit 150d81f7a260f36c118cbec253fdd493c671dc29 ]
    
    Ethernet IRQ GPIOs are marked as GPIO hogs.  Thus, these GPIOs are
    requested at probe time without considering if there are other
    peripherals that need them.  The Ethernet IRQ GPIOs are shared with
    SDHI2.  Selection between Ethernet and SDHI2 is done through a hardware
    switch.  To avoid scenarios where one wants to boot with SDHI2 support
    and some SDHI pins are not propertly configured because of the GPIO
    hogs, guard the Ethernet IRQ GPIO hogs with the proper build flag.
    
    Fixes: 932ff0c802c6 ("arm64: dts: renesas: rzg3s-smarc-som: Enable the Ethernet interfaces")
    Signed-off-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: add missing interrupt-names for rk356x vdpu [+ + +]
Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 18:35:25 2024 +0100

    arm64: dts: rockchip: add missing interrupt-names for rk356x vdpu
    
    [ Upstream commit d1c44d9afa6f89aa0e10a191f30868eb12cd719f ]
    
    The video-codec@fdea0400 was missing the interrupt-names property that is
    part of the binding. Add it.
    
    Fixes: 944be6fba401 ("arm64: dts: rockchip: Add VPU support for RK3568/RK3566")
    Cc: Piotr Oniszczuk <[email protected]>
    Acked-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s [+ + +]
Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 17:46:56 2024 +0100

    arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s
    
    [ Upstream commit a8037ceb89649659831e86a87a9329d1bb43c735 ]
    
    The rockchip,trcm-sync-tx-only property is at this time only documented
    for the tdm variant of Rockchip i2s controllers.
    
    While there was a series [0] adding code and binding for the property,
    it doesn't seem to have gone forward back in 2021.
    
    So for now fix the devicetree check by removing the property from rk3588
    i2s controllers until support for it gets merged.
    
    [0] https://patchwork.kernel.org/project/linux-rockchip/patch/[email protected]/
    
    Fixes: 8ae112a5554f ("arm64: dts: rockchip: Add rk3588s I2S nodes")
    Cc: Sugar Zhang <[email protected]>
    Cc: Cristian Ciocaltea <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Quentin Schulz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: fix reset-names for rk356x i2s2 controller [+ + +]
Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 18:35:26 2024 +0100

    arm64: dts: rockchip: fix reset-names for rk356x i2s2 controller
    
    [ Upstream commit 0fc19ab75acde78558bd0f6fe3e5f63cf8ee88b0 ]
    
    The dtbscheck reports a warning for a wrong reset-names property for
    the i2s2 controller on rk356x socs.
    
    The other controllers on the soc provide tx and rx directions and hence
    two resets and separate clocks for each direction, while i2s2 only
    provides one reset. This was so far named just "m" which isn't part of
    the binding.
    
    The clock-names the controller uses all end in "tx", so use the matching
    "tx-m" reset-name for the i2s controller.
    
    Fixes: 755f37010f3e ("arm64: dts: rockchip: RK356x: Add I2S2 device node")
    Acked-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: Add common1 register space for AM62x SoC [+ + +]
Author: Devarsh Thakkar <[email protected]>
Date:   Fri Feb 16 11:54:25 2024 +0530

    arm64: dts: ti: Add common1 register space for AM62x SoC
    
    [ Upstream commit 7d8ee2c3b8a2aabb9ce75795bad20773bfe1ba13 ]
    
    This adds common1 register space for AM62x SoC which is using TI's Keystone
    display hardware and supporting it as described in
    Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
    
    Fixes: 8ccc1073c7bb ("arm64: dts: ti: k3-am62-main: Add node for DSS")
    Signed-off-by: Devarsh Thakkar <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: Add common1 register space for AM65x SoC [+ + +]
Author: Devarsh Thakkar <[email protected]>
Date:   Fri Feb 16 11:54:24 2024 +0530

    arm64: dts: ti: Add common1 register space for AM65x SoC
    
    [ Upstream commit 1a5010eade10b409d353b770d97b548b0fbdf5d7 ]
    
    This adds common1 register space for AM65x SoC which is using TI's Keystone
    display hardware and supporting it as described in
    Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
    
    Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
    Signed-off-by: Devarsh Thakkar <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: am65x: Fix dtbs_install for Rocktech OLDI overlay [+ + +]
Author: Roger Quadros <[email protected]>
Date:   Thu Feb 8 15:51:43 2024 +0200

    arm64: dts: ti: am65x: Fix dtbs_install for Rocktech OLDI overlay
    
    [ Upstream commit 8ada14cafc5e185c668198617cd1ab4f1d8d325a ]
    
    Add the overlay dtbo file to a Makefile target so it can be
    picked by the dtbs_install command.
    
    Fixes: b8690ed3d1d1 ("arm64: dts: ti: am65x: Add Rocktech OLDI panel DT overlay")
    Signed-off-by: Roger Quadros <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62-main: disable usb lpm [+ + +]
Author: Andrejs Cainikovs <[email protected]>
Date:   Fri Feb 9 14:02:12 2024 +0100

    arm64: dts: ti: k3-am62-main: disable usb lpm
    
    [ Upstream commit 9c99b337a8755a09df7735d4324ae26a6eca6261 ]
    
    AM62 USB works with some devices, while failing to operate with others.
    
    [  560.189822] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller
    [  560.195631] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned bus number 2
    [  574.388509] xhci-hcd xhci-hcd.4.auto: can't setup: -110
    [  574.393814] xhci-hcd xhci-hcd.4.auto: USB bus 2 deregistered
    [  574.399544] xhci-hcd: probe of xhci-hcd.4.auto failed with error -110
    
    This seems to be related to LPM (Link Power Management), and disabling it
    turns USB into reliable working state.
    
    As per AM62 reference manual:
    
    > 4.8.2.1 USB2SS Unsupported Features
    >
    > The following features are not supported on this family of devices:
    > ...
    > - USB 2.0 ECN: Link Power Management (LPM)
    > ...
    
    Fixes: 2240f96cf3cd ("arm64: dts: ti: k3-am62-main: Add support for USB")
    Signed-off-by: Andrejs Cainikovs <[email protected]>
    Reviewed-by: Francesco Dolcini <[email protected]>
    Reviewed-by: Roger Quadros <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62p-mcu/wakeup: Disable MCU and wakeup R5FSS nodes [+ + +]
Author: Vaishnav Achath <[email protected]>
Date:   Sun Jan 21 19:10:17 2024 +0530

    arm64: dts: ti: k3-am62p-mcu/wakeup: Disable MCU and wakeup R5FSS nodes
    
    [ Upstream commit dfc90e5f1a0fe0f8124521bc1911e38aa6cd9118 ]
    
    K3 Remoteproc R5 driver requires reserved memory carveouts and
    mailbox configuration to instantiate the cores successfully.
    Since this is a board level dependency, keep the R5 subsytem
    disabled at SoC dtsi, otherwise it results in probe errors like
    below during AM62P SK boot:
    
    r5fss@79000000: reserved memory init failed, ret = -22
    r5fss@79000000: k3_r5_cluster_rproc_init failed, ret = -22
    r5fss@78000000: reserved memory init failed, ret = -22
    r5fss@78000000: k3_r5_cluster_rproc_init failed, ret = -22
    
    Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs")
    
    Signed-off-by: Vaishnav Achath <[email protected]>
    Reviewed-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Nishanth Menon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62p5-sk: Enable CPSW MDIO node [+ + +]
Author: Ravi Gunasekaran <[email protected]>
Date:   Thu Feb 1 18:13:53 2024 +0530

    arm64: dts: ti: k3-am62p5-sk: Enable CPSW MDIO node
    
    [ Upstream commit 8839a9af397e803e0447a6b3e69fad54ed22d26d ]
    
    Enable the CPSW MDIO node, and link the pinctrl information to enable
    ethernet on SK-AM62P.
    
    Ethernet was unintentally broken on this board, even though these nodes
    were already present, as enabling them was missed in the original
    patch.
    
    Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM")
    Signed-off-by: Ravi Gunasekaran <[email protected]>
    Signed-off-by: Jai Luthra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62p: Fix memory ranges for DMSS [+ + +]
Author: Jai Luthra <[email protected]>
Date:   Tue Feb 20 11:48:02 2024 +0530

    arm64: dts: ti: k3-am62p: Fix memory ranges for DMSS
    
    [ Upstream commit 90a67583171f213711de662fab9f8d24a2d291a9 ]
    
    The INTR module for DMASS1 (CSI specific DMASS) is outside the currently
    available ranges, as it starts at 0x4e400000. So fix the ranges property
    to enable programming the interrupts correctly.
    
    Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs")
    Reviewed-by: Vaishnav Achath <[email protected]>
    Signed-off-by: Jai Luthra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am64-main: Fix ITAP/OTAP values for MMC [+ + +]
Author: Judith Mendez <[email protected]>
Date:   Tue Feb 13 17:56:56 2024 -0600

    arm64: dts: ti: k3-am64-main: Fix ITAP/OTAP values for MMC
    
    [ Upstream commit 379c7752bbd0e81654544a896dd19c19ebb6faba ]
    
    Update MMC0/MMC1 OTAP/ITAP values according to the datasheet
    [0], refer to Table 7-68 for MMC0 and Table 7-77 for MMC1.
    
    [0] https://www.ti.com/lit/ds/symlink/am6442.pdf
    
    Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC")
    Signed-off-by: Judith Mendez <[email protected]>
    Tested-by: Wadim Egorov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am69-sk: fix PMIC interrupt number [+ + +]
Author: Romain Naour <[email protected]>
Date:   Fri Feb 9 18:11:45 2024 +0100

    arm64: dts: ti: k3-am69-sk: fix PMIC interrupt number
    
    [ Upstream commit c205595e3b708c36ef2d7609b9182c6729bb06ae ]
    
    The tps659413 node set WKUP_GPIO0_83 (AA37) pin as input to be used as
    PMIC interrupt but uses 39 (WKUP_GPIO0_39) as "interrupts" property.
    
    Replace 39 by 83 after checking in the board schematic [1].
    
    [1] https://www.ti.com/tool/SK-AM69
    
    Fixes: 865a1593bf99 ("arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC")
    Cc: Neha Malcom Francis <[email protected]>
    Signed-off-by: Romain Naour <[email protected]>
    Reviewed-by: Neha Malcom Francis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am69-sk: remove assigned-clock-parents for unused VP [+ + +]
Author: Jayesh Choudhary <[email protected]>
Date:   Thu Feb 1 19:53:08 2024 +0530

    arm64: dts: ti: k3-am69-sk: remove assigned-clock-parents for unused VP
    
    [ Upstream commit cfdb4f7ffdb855c1a3d274dc7757e780dcbf2d55 ]
    
    VP2 and VP3 are unused video ports and VP3 share the same parent
    clock as VP1 causing issue with pixel clock setting for HDMI (VP1).
    The current DM firmware does not support changing parent clock if it
    is shared by another component. It returns 0 for the determine_rate
    query before causing set_rate to set the clock at default maximum of
    1.8GHz which is a lot more than the maximum frequency videoports can
    support (600MHz) causing SYNC LOST issues.
    So remove the parent clocks for unused VPs to avoid conflict.
    
    Fixes: 6f8605fd7d11 ("arm64: dts: ti: k3-am69-sk: Add DP and HDMI support")
    Reported-by: Nishanth Menon <[email protected]>
    Signed-off-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Tested-by: Enric Balletbo i Serra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j7200-common-proc-board: Modify Pinmux for wkup_uart0 and mcu_uart0 [+ + +]
Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:43 2024 +0530

    arm64: dts: ti: k3-j7200-common-proc-board: Modify Pinmux for wkup_uart0 and mcu_uart0
    
    [ Upstream commit 566feddd2ba5e29d9ccab36d6508592ae563f275 ]
    
    WKUP_PADCONFIG registers for wkup_uart0 and mcu_uart0 lies
    under wkup_pmx2 for J7200. Thus, modify pinmux for both
    of them.
    
    Fixes: 3709ea7f960e ("arm64: dts: ti: k3-j7200-common-proc-board: Add uart pinmux")
    Signed-off-by: Bhavya Kapoor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j7200-common-proc-board: Remove clock-frequency from mcu_uart0 [+ + +]
Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:44 2024 +0530

    arm64: dts: ti: k3-j7200-common-proc-board: Remove clock-frequency from mcu_uart0
    
    [ Upstream commit 0fa8b0e2083d333e4854b9767fb893f924e70ae5 ]
    
    Clock-frequency property is already present in mcu_uart0 node of the
    k3-j7200-mcu-wakeup.dtsi file. Thus, remove redundant clock-frequency
    property from mcu_uart0 node.
    
    Fixes: 3709ea7f960e ("arm64: dts: ti: k3-j7200-common-proc-board: Add uart pinmux")
    Signed-off-by: Bhavya Kapoor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j721e-sk: fix PMIC interrupt number [+ + +]
Author: Romain Naour <[email protected]>
Date:   Fri Feb 9 18:11:46 2024 +0100

    arm64: dts: ti: k3-j721e-sk: fix PMIC interrupt number
    
    [ Upstream commit 7f25d6926d178734db17cfc12f0b1841e82914da ]
    
    The tps659413 and tps659411 nodes set WKUP_GPIO0_7 (G28) pin as input
    to be used as PMIC interrupt but uses 9 (WKUP_GPIO0_9) as
    "interrupts" property.
    
    Replace 9 by 7 for both tps659413 and tps659411 after checking in the
    board schematic [1].
    
    [1] https://www.ti.com/tool/SK-TDA4VM
    
    Fixes: b808cef0be46 ("arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs")
    Cc: Neha Malcom Francis <[email protected]>
    Signed-off-by: Romain Naour <[email protected]>
    Reviewed-by: Neha Malcom Francis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j721e: Fix mux-reg-masks in hbmc_mux [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Thu Feb 15 08:19:57 2024 -0600

    arm64: dts: ti: k3-j721e: Fix mux-reg-masks in hbmc_mux
    
    [ Upstream commit 3d585389d454e147187684e492a0eb8f56adf311 ]
    
    Change offset in mux-reg-masks property for hbmc_mux node
    since reg-mux property is used in compatible.
    
    While here, update the reg region to include 4 bytes as this
    is a 32bit register.
    
    Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
    Suggested-by: Peter Rosin <[email protected]>
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j721s2-common-proc-board: Remove Pinmux for CTS and RTS in wkup_uart0 [+ + +]
Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:45 2024 +0530

    arm64: dts: ti: k3-j721s2-common-proc-board: Remove Pinmux for CTS and RTS in wkup_uart0
    
    [ Upstream commit 28e5b74d524050008edf415f20a3e38907b8f176 ]
    
    Only Tx and Rx Signal lines for wkup_uart0 are brought out on
    the Common Proc Board through SoM, but CTS and RTS signal lines
    are not brought on the board. Thus, remove pinmux for CTS and RTS
    signal lines for wkup_uart0 in J721S2.
    
    Fixes: f5e9ee0b354a ("arm64: dts: ti: k3-j721s2-common-proc-board: Add uart pinmux")
    Signed-off-by: Bhavya Kapoor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j721s2: Fix power domain for VTM node [+ + +]
Author: Manorit Chawdhry <[email protected]>
Date:   Thu Feb 1 13:37:26 2024 +0530

    arm64: dts: ti: k3-j721s2: Fix power domain for VTM node
    
    [ Upstream commit 5ef196ed912e80a1e64936119ced8d7eb5635f0f ]
    
    Fix the power domain device ID for wkup_vtm0 node.
    
    Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html
    Fixes: d148e3fe52c8 ("arm64: dts: ti: j721s2: Add VTM node")
    Signed-off-by: Manorit Chawdhry <[email protected]>
    Reviewed-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/20240201-b4-upstream-j721s2-fix-vtm-devid-v2-1-85fd568b77e3@ti.com
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j784s4-evm: Remove Pinmux for CTS and RTS in wkup_uart0 [+ + +]
Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:46 2024 +0530

    arm64: dts: ti: k3-j784s4-evm: Remove Pinmux for CTS and RTS in wkup_uart0
    
    [ Upstream commit d29a6cf980572d8cf7b63935716fca663e2610f0 ]
    
    Only Tx and Rx Signal lines for wkup_uart0 are brought out on
    the J784S4 EVM from SoC, but CTS and RTS signal lines are not
    brought on the EVM. Thus, remove pinmux for CTS and RTS signal
    lines for wkup_uart0 in J784S4.
    
    Fixes: 6fa5d37a2f34 ("arm64: dts: ti: k3-j784s4-evm: Add mcu and wakeup uarts")
    Signed-off-by: Bhavya Kapoor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl [+ + +]
Author: Chintan Vankar <[email protected]>
Date:   Tue Feb 13 13:33:48 2024 +0530

    arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl
    
    [ Upstream commit 9a0c0a9baa2d1f906589d715f9baeab93e7fcdcb ]
    
    Change offset in mux-reg-masks property for serdes_ln_ctrl node
    since reg-mux property is used in compatible.
    
    Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
    Signed-off-by: Chintan Vankar <[email protected]>
    Acked-by: Andrew Davis <[email protected]>
    Signed-off-by: Siddharth Vadapalli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j784s4: Fix power domain for VTM node [+ + +]
Author: Manorit Chawdhry <[email protected]>
Date:   Thu Feb 1 13:37:27 2024 +0530

    arm64: dts: ti: k3-j784s4: Fix power domain for VTM node
    
    [ Upstream commit e4d252e6d29208aea56d4c04270523e306b1e3c2 ]
    
    Fix the power domain device ID for wkup_vtm0 node.
    
    Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/devices.html
    Fixes: 64821fbf6738 ("arm64: dts: ti: j784s4: Add VTM node")
    Signed-off-by: Manorit Chawdhry <[email protected]>
    Reviewed-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/20240201-b4-upstream-j721s2-fix-vtm-devid-v2-2-85fd568b77e3@ti.com
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with Clang [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Thu Feb 22 22:40:29 2024 -0800

    arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with Clang
    
    [ Upstream commit a743f26d03a96593c0f3d05dc26b388f45de67c9 ]
    
    Per commit b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with
    CC_OPTIMIZE_FOR_SIZE"), GCC is silently ignoring `-falign-functions=N`
    when passed `-Os`, causing functions to be improperly aligned. This
    doesn't seem to be a problem with Clang though, where enabling CALL_OPS
    with CC_OPTIMIZE_FOR_SIZE doesn't spit out any warnings at boot about
    misaligned patch-sites. Only forbid CALL_OPS if GCC is used and we're
    optimizing for size so that CALL_OPS can be used with clang optimizing
    for size.
    
    Cc: Jason Ling <[email protected]>
    Cc: Florian Fainelli <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Cc: Bill Wendling <[email protected]>
    Cc: Justin Stitt <[email protected]>
    Cc: [email protected]
    Fixes: b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with CC_OPTIMIZE_FOR_SIZE")
    Signed-off-by: Stephen Boyd <[email protected]>
    Reviewed-by: Nathan Chancellor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: arm: realview: Fix development chip ROM compatible value [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Aug 30 17:03:04 2023 +0200

    ARM: dts: arm: realview: Fix development chip ROM compatible value
    
    [ Upstream commit 3baa4c5143d65ebab2de0d99a395e5f4f1f46608 ]
    
    When the development chip ROM was added, the "direct-mapped" compatible
    value was already obsolete.  In addition, the device node lacked the
    accompanying "probe-type" property, causing the old physmap_of_core
    driver to fall back to trying all available probe types.
    Unfortunately this fallback was lost when the DT and pdata cases were
    merged.
    
    Fix this by using the modern "mtd-rom" compatible value instead.
    
    Fixes: 5c3f5edbe0a1dff3 ("ARM: realview: add flash devices to the PB1176 DTS")
    Fixes: 642b1e8dbed7bbbf ("mtd: maps: Merge physmap_of.c into physmap-core.c")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx6dl-yapp4: Fix typo in the QCA switch register address [+ + +]
Author: Michal Vokáč <[email protected]>
Date:   Wed Feb 14 10:03:27 2024 +0100

    ARM: dts: imx6dl-yapp4: Fix typo in the QCA switch register address
    
    [ Upstream commit 023bd910d3ab735459f84b22bb99fb9e00bd9d76 ]
    
    This change does not have any functional effect. The switch works just
    fine without this patch as it has full access to all the addresses
    on the bus. This is simply a clean-up to set the node name address
    and reg address to the same value.
    
    Fixes: 15b43e497ffd ("ARM: dts: imx6dl-yapp4: Use correct pseudo PHY address for the switch")
    Signed-off-by: Michal Vokáč <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx6dl-yapp4: Move the internal switch PHYs under the switch node [+ + +]
Author: Michal Vokáč <[email protected]>
Date:   Wed Feb 14 10:03:28 2024 +0100

    ARM: dts: imx6dl-yapp4: Move the internal switch PHYs under the switch node
    
    [ Upstream commit 79978bff2e4b8e05ebdf5fc3ee6b794002393484 ]
    
    We identified that the PHYs actually do not work since commit 7da7b84fee58
    ("ARM: dts: imx6dl-yapp4: Move phy reset into switch node") as
    a coincidence of several circumstances.
    
    The reset signal is kept asserted by a pull-down resistor on the board
    unless it is deasserted by GPIO from the SoC. This is to keep the switch
    dead until it is configured properly by the kernel and user space.
    
    Prior to the referenced commit the switch was reset by the FEC driver
    and the reset GPIO was actively deasserted. The mdio-bus was scanned
    and the attached switch and its PHYs were found and configured.
    
    With the referenced commit the switch is reset by the qca8k driver.
    Because of another bug in the qca8k driver, functionality of the reset
    pin depends on its pre-kernel configuration. See commit c44fc98f0a8f
    ("net: dsa: qca8k: fix illegal usage of GPIO")
    
    The problem did not appear until we removed support for the switch
    and configuration of its reset pin from the bootloader.
    
    To fix that, properly describe the internal mdio-bus configuration of
    the qca8334 switch. The PHYs are internal to the switch and sit on its
    internal mdio-bus.
    
    Fixes: 7da7b84fee58 ("ARM: dts: imx6dl-yapp4: Move phy reset into switch node")
    Signed-off-by: Michal Vokáč <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: msm8974: correct qfprom node size [+ + +]
Author: Craig Tatlor <[email protected]>
Date:   Sat Feb 10 17:45:40 2024 +0100

    ARM: dts: qcom: msm8974: correct qfprom node size
    
    [ Upstream commit 724c4bf0e4bf81dba77736afb93964c986c3c123 ]
    
    The qfprom actually is bigger than 0x1000, so adjust the reg.
    
    Note that the non-ECC-corrected qfprom can be found at 0xfc4b8000
    (-0x4000). The current reg points to the ECC-corrected qfprom block
    which should have equivalent values at all offsets compared to the
    non-corrected version.
    
    [[email protected]: extract to standalone patch and adjust for review
    comments]
    
    Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes")
    Signed-off-by: Craig Tatlor <[email protected]>
    Signed-off-by: Luca Weiss <[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]>

ARM: dts: renesas: r8a73a4: Fix external clocks and clock rate [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Jan 15 12:03:03 2024 +0100

    ARM: dts: renesas: r8a73a4: Fix external clocks and clock rate
    
    [ Upstream commit 090c4094574705b0afc7d37825cdc5d06f0e7e02 ]
    
    External clocks should be defined as zero-Hz clocks in the SoC .dtsi,
    and overridden in the board .dts when present.
    
    Correct the clock rate of extal1 from 25 to 26 MHz, to match the crystal
    oscillator present on the APE6-EVM board.
    
    Fixes: a76809a329d6ebae ("ARM: shmobile: r8a73a4: Common clock framework DT description")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Niklas Söderlund <[email protected]>
    Link: https://lore.kernel.org/r/1692bc8cd465d62168cbf110522ad62a7af3f606.1705315614.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: acp: Add missing error handling in sof-mach [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:21 2023 +0200

    ASoC: amd: acp: Add missing error handling in sof-mach
    
    [ Upstream commit d0ada20279db2649a7549a2b8a4a3379c59f238d ]
    
    Handle potential acp_sofdsp_dai_links_create() errors in ACP SOF machine
    driver's probe function.  Note there is no need for an undo.
    
    While at it, switch to dev_err_probe().
    
    Fixes: 9f84940f5004 ("ASoC: amd: acp: Add SOF audio support on Chrome board")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Reviewed-by: Emil Velikov <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: ssp-common: Add stub for sof_ssp_get_codec_name [+ + +]
Author: Charles Keepax <[email protected]>
Date:   Thu Feb 8 10:55:41 2024 -0600

    ASoC: Intel: ssp-common: Add stub for sof_ssp_get_codec_name
    
    [ Upstream commit c1469c3a8a306e5f1eab1ae9585640d08e183f87 ]
    
    As this function is now used in sof_board_helpers it requires a build
    stub for the case SSP_COMMON is not built in.
    
    Fixes: ba0c7c328762 ("ASoC: Intel: board_helpers: support amp link initialization")
    Reviewed-by: Bard Liao <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: aiu: fix function pointer type mismatch [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Tue Feb 13 22:58:03 2024 +0100

    ASoC: meson: aiu: fix function pointer type mismatch
    
    [ Upstream commit 98ac85a00f31d2e9d5452b825a9ed0153d934043 ]
    
    clang-16 warns about casting functions to incompatible types, as is done
    here to call clk_disable_unprepare:
    
    sound/soc/meson/aiu.c:243:12: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      243 |                                        (void(*)(void *))clk_disable_unprepare,
    
    The pattern of getting, enabling and setting a disable callback for a
    clock can be replaced with devm_clk_get_enabled(), which also fixes
    this warning.
    
    Fixes: 6ae9ca9ce986 ("ASoC: meson: aiu: add i2s and spdif support")
    Reported-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Jerome Brunet <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: axg-tdm-interface: add frame rate constraint [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Fri Feb 23 18:51:08 2024 +0100

    ASoC: meson: axg-tdm-interface: add frame rate constraint
    
    [ Upstream commit 59c6a3a43b221cc2a211181b1298e43b2c2df782 ]
    
    According to Amlogic datasheets for the SoCs supported by this driver, the
    maximum bit clock rate is 100MHz.
    
    The tdm interface allows the rates listed by the DAI driver, regardless of
    the number slots or their width. However, these will impact the bit clock
    rate.
    
    Hitting the 100MHz limit is very unlikely for most use cases but it is
    possible.
    
    For example with 32 slots / 32 bits wide, the maximum rate is no longer
    384kHz but ~96kHz.
    
    Add the constraint accordingly if the component is not already active.
    If it is active, the rate is already constrained by the first stream rate.
    
    Fixes: d60e4f1e4be5 ("ASoC: meson: add tdm interface driver")
    Signed-off-by: Jerome Brunet <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: axg-tdm-interface: fix mclk setup without mclk-fs [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Fri Feb 23 18:51:07 2024 +0100

    ASoC: meson: axg-tdm-interface: fix mclk setup without mclk-fs
    
    [ Upstream commit e3741a8d28a1137f8b19ae6f3d6e3be69a454a0a ]
    
    By default, when mclk-fs is not provided, the tdm-interface driver
    requests an MCLK that is 4x the bit clock, SCLK.
    
    However there is no justification for this:
    
    * If the codec needs MCLK for its operation, mclk-fs is expected to be set
      according to the codec requirements.
    * If the codec does not need MCLK the minimum is 2 * SCLK, because this is
      minimum the divider between SCLK and MCLK can do.
    
    Multiplying by 4 may cause problems because the PLL limit may be reached
    sooner than it should, so use 2x instead.
    
    Fixes: d60e4f1e4be5 ("ASoC: meson: add tdm interface driver")
    Signed-off-by: Jerome Brunet <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: t9015: fix function pointer type mismatch [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Tue Feb 13 22:58:04 2024 +0100

    ASoC: meson: t9015: fix function pointer type mismatch
    
    [ Upstream commit 5ad992c71b6a8e8a547954addc7af9fbde6ca10a ]
    
    clang-16 warns about casting functions to incompatible types, as is done
    here to call clk_disable_unprepare:
    
    sound/soc/meson/t9015.c:274:4: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      274 |                         (void(*)(void *))clk_disable_unprepare,
    
    The pattern of getting, enabling and setting a disable callback for a
    clock can be replaced with devm_clk_get_enabled(), which also fixes
    this warning.
    
    Fixes: 33901f5b9b16 ("ASoC: meson: add t9015 internal DAC driver")
    Reported-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Jerome Brunet <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates [+ + +]
Author: Luca Ceresoli <[email protected]>
Date:   Tue Mar 5 15:36:28 2024 +0100

    ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates
    
    [ Upstream commit 9e2ab4b18ebd46813fc3459207335af4d368e323 ]
    
    The sample rates set by the rockchip_i2s_tdm driver in master mode are
    inaccurate up to 5% in several cases, due to the driver logic to configure
    clocks and a nasty interaction with the Common Clock Framework.
    
    To understand what happens, here is the relevant section of the clock tree
    (slightly simplified), along with the names used in the driver:
    
           vpll0 _OR_ vpll1               "mclk_root"
              clk_i2s2_8ch_tx_src         "mclk_parent"
                 clk_i2s2_8ch_tx_mux
                    clk_i2s2_8ch_tx       "mclk" or "mclk_tx"
    
    This is what happens when playing back e.g. at 192 kHz using
    audio-graph-card (when recording the same applies, only s/tx/rx/):
    
     0. at probe, rockchip_i2s_tdm_set_sysclk() stores the passed frequency in
        i2s_tdm->mclk_tx_freq (*) which is 50176000, and that is never modified
        afterwards
    
     1. when playback is started, rockchip_i2s_tdm_hw_params() is called and
        does the following two calls
    
     2. rockchip_i2s_tdm_calibrate_mclk():
    
        2a. selects mclk_root0 (vpll0) as a parent for mclk_parent
            (mclk_tx_src), which is OK because the vpll0 rate is a good for
            192000 (and sumbultiple) rates
    
        2b. sets the mclk_root frequency based on ppm calibration computations
    
        2c. sets mclk_tx_src to 49152000 (= 256 * 192000), which is also OK as
            it is a multiple of the required bit clock
    
     3. rockchip_i2s_tdm_set_mclk()
    
        3a. calls clk_set_rate() to set the rate of mclk_tx (clk_i2s2_8ch_tx)
            to the value of i2s_tdm->mclk_tx_freq (*), i.e. 50176000 which is
            not a multiple of the sampling frequency -- this is not OK
    
            3a1. clk_set_rate() reacts by reparenting clk_i2s2_8ch_tx_src to
                 vpll1 -- this is not OK because the default vpll1 rate can be
                 divided to get 44.1 kHz and related rates, not 192 kHz
    
    The result is that the driver does a lot of ad-hoc decisions about clocks
    and ends up in using the wrong parent at an unoptimal rate.
    
    Step 0 is one part of the problem: unless the card driver calls set_sysclk
    at each stream start, whatever rate is set in mclk_tx_freq during boot will
    be taken and used until reboot. Moreover the driver does not care if its
    value is not a multiple of any audio frequency.
    
    Another part of the problem is that the whole reparenting and clock rate
    setting logic is conflicting with the CCF algorithms to achieve largely the
    same goal: selecting the best parent and setting the closest clock
    rate. And it turns out that only calling once clk_set_rate() on
    clk_i2s2_8ch_tx picks the correct vpll and sets the correct rate.
    
    The fix is based on removing the custom logic in the driver to select the
    parent and set the various clocks, and just let the Clock Framework do it
    all. As a side effect, the set_sysclk() op becomes useless because we now
    let the CCF compute the appropriate value for the sampling rate.  It also
    implies that the whole calibration logic is now dead code and so it is
    removed along with the "PCM Clock Compensation in PPM" kcontrol, which has
    always been broken anyway. The handling of the 4 optional clocks also
    becomes dead code and is removed.
    
    The actual rates have been tested playing 30 seconds of audio at various
    sampling rates before and after this change using sox:
    
        time play -r <sample_rate> -n synth 30 sine 950 gain -3
    
    The time reported in the table below is the 'real' value reported by the
    'time' command in the above command line.
    
         rate        before     after
       ---------     ------     ------
         8000 Hz     30.60s     30.63s
        11025 Hz     30.45s     30.51s
        16000 Hz     30.47s     30.50s
        22050 Hz     30.78s     30.41s
        32000 Hz     31.02s     30.43s
        44100 Hz     30.78s     30.41s
        48000 Hz     29.81s     30.45s
        88200 Hz     30.78s     30.41s
        96000 Hz     29.79s     30.42s
       176400 Hz     27.40s     30.41s
       192000 Hz     29.79s     30.42s
    
    While the tests are running the clock tree confirms that:
    
     * without the patch, vpll1 is always used and clk_i2s2_8ch_tx always
       produces 50176000 Hz, which cannot be divided for most audio rates
       except the slowest ones, generating inaccurate rates
     * with the patch:
       - for 192000 Hz vpll0 is used
       - for 176400 Hz vpll1 is used
       - clk_i2s2_8ch_tx always produces (256 * <rate>) Hz
    
    Tested on the RK3308 using the internal audio codec.
    
    Fixes: 081068fd6414 ("ASoC: rockchip: add support for i2s-tdm controller")
    Signed-off-by: Luca Ceresoli <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: sh: rz-ssi: Fix error message print [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Tue Jan 30 15:08:22 2024 +0000

    ASoC: sh: rz-ssi: Fix error message print
    
    [ Upstream commit 9a6d7c4fb2801b675a9c31a7ceb78c84b8c439bc ]
    
    The devm_request_irq() call is done for "dma_rt" interrupt but the error
    message printed "dma_tx" interrupt on failure, fix this by updating
    dma_tx -> dma_rt in dev_err_probe() message. While at it aligned the code.
    
    Signed-off-by: Lad Prabhakar <[email protected]>
    Fixes: 38c042b59af0248a ("ASoC: sh: rz-ssi: Update interrupt handling for half duplex channels")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Add some bounds checking to firmware data [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Feb 9 16:02:16 2024 +0300

    ASoC: SOF: Add some bounds checking to firmware data
    
    [ Upstream commit 98f681b0f84cfc3a1d83287b77697679e0398306 ]
    
    Smatch complains about "head->full_size - head->header_size" can
    underflow.  To some extent, we're always going to have to trust the
    firmware a bit.  However, it's easy enough to add a check for negatives,
    and let's add a upper bounds check as well.
    
    Fixes: d2458baa799f ("ASoC: SOF: ipc3-loader: Implement firmware parsing and loading")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: amd: Compute file paths on firmware load [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:26 2023 +0200

    ASoC: SOF: amd: Compute file paths on firmware load
    
    [ Upstream commit d9cacc1a2af2e1cd781b5cd2a3e57fbde64f5a2d ]
    
    Commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if
    firmware files are missing") changed the order of some operations and
    the firmware paths are not available anymore at snd_sof_probe() time.
    
    Precisely, fw_filename_prefix is set by sof_select_ipc_and_paths() via
    
      plat_data->fw_filename_prefix = out_profile.fw_path;
    
    but sof_init_environment() which calls this function was moved from
    snd_sof_device_probe() to sof_probe_continue(). Moreover,
    snd_sof_probe() was moved from sof_probe_continue() to
    sof_init_environment(), but before the call to
    sof_select_ipc_and_paths().
    
    The problem here is that amd_sof_acp_probe() uses fw_filename_prefix to
    compute fw_code_bin and fw_data_bin paths, and because the field is not
    yet initialized, the paths end up containing (null):
    
    snd_sof_amd_vangogh 0000:04:00.5: Direct firmware load for (null)/sof-vangogh-code.bin failed with error -2
    snd_sof_amd_vangogh 0000:04:00.5: sof signed firmware code bin is missing
    snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP firmware -2
    snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2
    
    Move usage of fw_filename_prefix right before request_firmware() calls
    in acp_sof_load_signed_firmware().
    
    Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Reviewed-by: Emil Velikov <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe() [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:23 2023 +0200

    ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()
    
    [ Upstream commit 222be59e5eed1554119294edc743ee548c2371d0 ]
    
    Driver uses kasprintf() to initialize fw_{code,data}_bin members of
    struct acp_dev_data, but kfree() is never called to deallocate the
    memory, which results in a memory leak.
    
    Fix the issue by switching to devm_kasprintf(). Additionally, ensure the
    allocation was successful by checking the pointer validity.
    
    Fixes: f7da88003c53 ("ASoC: SOF: amd: Enable signed firmware image loading for Vangogh platform")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Reviewed-by: Emil Velikov <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Feb 20 22:16:03 2024 +0200

    ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry
    
    [ Upstream commit 33c3d813330718c403a60d220f03fbece0f4fb5c ]
    
    The signed_fw_image member of struct sof_amd_acp_desc is used to enable
    signed firmware support in the driver via the acp_sof_quirk_table.
    
    In preparation to support additional use cases of the quirk table (i.e.
    adding new flags), move signed_fw_image to a new struct acp_quirk_entry
    and update all references to it accordingly.
    
    No functional changes intended.
    
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 094d11768f74 ("ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Feb 20 22:16:04 2024 +0200

    ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED
    
    [ Upstream commit 094d11768f740f11483dad4efcd9bbcffa4ce146 ]
    
    The recent introduction of the ACP/PSP communication for IRAM/DRAM fence
    register modification breaks the audio support on Valve's Steam Deck
    OLED device.
    
    It causes IPC timeout errors when trying to load DSP topology during
    probing:
    
    1707255557.688176 kernel: snd_sof_amd_vangogh 0000:04:00.5: ipc tx timed out for 0x30100000 (msg/reply size: 48/0)
    1707255557.689035 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump start ]------------
    1707255557.689421 kernel: snd_sof_amd_vangogh 0000:04:00.5: dsp_msg = 0x0 dsp_ack = 0x91d14f6f host_msg = 0x1 host_ack = 0xead0f1a4 irq_stat >
    1707255557.689730 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump end ]------------
    1707255557.690074 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump start ]------------
    1707255557.690376 kernel: snd_sof_amd_vangogh 0000:04:00.5: IPC timeout
    1707255557.690744 kernel: snd_sof_amd_vangogh 0000:04:00.5: fw_state: SOF_FW_BOOT_COMPLETE (7)
    1707255557.691037 kernel: snd_sof_amd_vangogh 0000:04:00.5: invalid header size 0xdb43fe7. FW oops is bogus
    1707255557.694824 kernel: snd_sof_amd_vangogh 0000:04:00.5: unexpected fault 0x6942d3b3 trace 0x6942d3b3
    1707255557.695392 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump end ]------------
    1707255557.695755 kernel: snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN
    1707255557.696069 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -110
    1707255557.696374 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22
    1707255557.697904 kernel: snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22
    1707255557.698405 kernel: sof_mach nau8821-max: ASoC: failed to instantiate card -22
    1707255557.701061 kernel: sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max)
    1707255557.701624 kernel: sof_mach: probe of nau8821-max failed with error -22
    
    Introduce a new member skip_iram_dram_size_mod to struct acp_quirk_entry and
    use it to skip IRAM/DRAM size modification for Vangogh Galileo device.
    
    Fixes: 55d7bbe43346 ("ASoC: SOF: amd: Add acp-psp mailbox interface for iram-dram fence register modification")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: core: Skip firmware test for custom loaders [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:25 2023 +0200

    ASoC: SOF: core: Skip firmware test for custom loaders
    
    [ Upstream commit 369b997a1371aeecd0a1fb0f9f4ef3747a1d07a4 ]
    
    The ACP driver for Vangogh platform uses a quirk for Valve Galileo
    device to setup a custom firmware loader, which neither requires nor
    uses the firmware file indicated via the default_fw_filename member of
    struct sof_dev_desc.
    
    Since commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version
    fallback if firmware files are missing"), the provided filename gets
    verified and triggers a fatal error on probe:
    
    [ 7.719337] snd_sof_amd_vangogh 0000:04:00.5: enabling device (0000 -> 0002)
    [ 7.721486] snd_sof_amd_vangogh 0000:04:00.5: SOF firmware and/or topology file not found.
    [ 7.721565] snd_sof_amd_vangogh 0000:04:00.5: Supported default profiles
    [ 7.721569] snd_sof_amd_vangogh 0000:04:00.5: - ipc type 0 (Requested):
    [ 7.721573] snd_sof_amd_vangogh 0000:04:00.5:  Firmware file: amd/sof/sof-vangogh.ri
    [ 7.721577] snd_sof_amd_vangogh 0000:04:00.5:  Topology file: amd/sof-tplg/sof-vangogh-nau8821-max.tplg
    [ 7.721582] snd_sof_amd_vangogh 0000:04:00.5: Check if you have 'sof-firmware' package installed.
    [ 7.721585] snd_sof_amd_vangogh 0000:04:00.5: Optionally it can be manually downloaded from:
    [ 7.721589] snd_sof_amd_vangogh 0000:04:00.5:    https://github.com/thesofproject/sof-bin/
    [ 7.721997] snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2
    
    According to AMD, a combined ".ri" file which includes the code and data
    segments cannot be used due to a limitation preventing the code image to
    be signed on build time.
    
    Fix the issue by skipping the firmware file test if a custom loader is
    being used instead of the generic one.
    
    Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing")
    Co-developed-by: Péter Ujfalusi <[email protected]>
    Signed-off-by: Péter Ujfalusi <[email protected]>
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tlv320adc3xxx: Don't strip remove function when driver is builtin [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Sun Mar 10 15:38:51 2024 +0100

    ASoC: tlv320adc3xxx: Don't strip remove function when driver is builtin
    
    [ Upstream commit f31e0d0c2cad23e0cc48731634f85bb2d8707790 ]
    
    Using __exit for the remove function results in the remove callback
    being discarded with SND_SOC_TLV320ADC3XXX=y. When such a device gets
    unbound (e.g. using sysfs or hotplug), the driver is just removed
    without the cleanup being performed. This results in resource leaks. Fix
    it by compiling in the remove callback unconditionally.
    
    This also fixes a W=1 modpost warning:
    
            WARNING: modpost: sound/soc/codecs/snd-soc-tlv320adc3xxx: section mismatch in reference: adc3xxx_i2c_driver+0x10 (section: .data) -> adc3xxx_i2c_remove (section: .exit.text)
    
    (which only happens with SND_SOC_TLV320ADC3XXX=m).
    
    Fixes: e9a3b57efd28 ("ASoC: codec: tlv320adc3xxx: New codec driver")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
backlight: da9052: Fully initialize backlight_properties during probe [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:24 2024 +0000

    backlight: da9052: Fully initialize backlight_properties during probe
    
    [ Upstream commit 0285e9efaee8276305db5c52a59baf84e9731556 ]
    
    props is stack allocated and the fields that are not explcitly set
    by the probe function need to be zeroed or we'll get undefined behaviour
    (especially so power/blank states)!
    
    Fixes: 6ede3d832aaa ("backlight: add driver for DA9052/53 PMIC v1")
    Signed-off-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: hx8357: Fix potential NULL pointer dereference [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Sun Jan 14 16:39:21 2024 +0200

    backlight: hx8357: Fix potential NULL pointer dereference
    
    [ Upstream commit b1ba8bcb2d1ffce11b308ce166c9cc28d989e3b9 ]
    
    The "im" pins are optional. Add missing check in the hx8357_probe().
    
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 7d84a63a39b7 ("backlight: hx8357: Convert to agnostic GPIO API")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: ktz8866: Correct the check for of_property_read_u32 [+ + +]
Author: Jianhua Lu <[email protected]>
Date:   Mon Jan 29 20:28:29 2024 +0800

    backlight: ktz8866: Correct the check for of_property_read_u32
    
    [ Upstream commit f1ac3c9825f99c93a9833beee6b78aa386e55b0b ]
    
    of_property_read_u32 returns 0 when success, so reverse the
    return value to get the true value.
    
    Fixes: f8449c8f7355 ("backlight: ktz8866: Add support for Kinetic KTZ8866 backlight")
    Signed-off-by: Jianhua Lu <[email protected]>
    Reviewed-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: lm3630a: Don't set bl->props.brightness in get_brightness [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Tue Feb 20 00:11:20 2024 +0100

    backlight: lm3630a: Don't set bl->props.brightness in get_brightness
    
    [ Upstream commit 4bf7ddd2d2f0f8826f25f74c7eba4e2c323a1446 ]
    
    There's no need to set bl->props.brightness, the get_brightness function
    is just supposed to return the current brightness and not touch the
    struct.
    
    With that done we can also remove the 'goto out' and just return the
    value.
    
    Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
    Signed-off-by: Luca Weiss <[email protected]>
    Reviewed-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: lm3630a: Initialize backlight_properties on init [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Tue Feb 20 00:11:19 2024 +0100

    backlight: lm3630a: Initialize backlight_properties on init
    
    [ Upstream commit ad9aeb0e3aa90ebdad5fabf9c21783740eb95907 ]
    
    The backlight_properties struct should be initialized to zero before
    using, otherwise there will be some random values in the struct.
    
    Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
    Signed-off-by: Luca Weiss <[email protected]>
    Reviewed-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: lm3639: Fully initialize backlight_properties during probe [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:25 2024 +0000

    backlight: lm3639: Fully initialize backlight_properties during probe
    
    [ Upstream commit abb5a5d951fbea3feb5c4ba179b89bb96a1d3462 ]
    
    props is stack allocated and the fields that are not explcitly set
    by the probe function need to be zeroed or we'll get undefined behaviour
    (especially so power/blank states)!
    
    Fixes: 0f59858d5119 ("backlight: add new lm3639 backlight driver")
    Signed-off-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

backlight: lp8788: Fully initialize backlight_properties during probe [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:26 2024 +0000

    backlight: lp8788: Fully initialize backlight_properties during probe
    
    [ Upstream commit 392346827fbe8a7fd573dfb145170d7949f639a6 ]
    
    props is stack allocated and the fields that are not explcitly set
    by the probe function need to be zeroed or we'll get undefined behaviour
    (especially so power/blank states)!
    
    Fixes: c5a51053cf3b ("backlight: add new lp8788 backlight driver")
    Signed-off-by: Daniel Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: fix deadlock between bd_link_disk_holder and partition scan [+ + +]
Author: Li Nan <[email protected]>
Date:   Wed Feb 21 17:01:22 2024 +0800

    block: fix deadlock between bd_link_disk_holder and partition scan
    
    [ Upstream commit 03f12122b20b6e6028e9ed69030a49f9cffcbb75 ]
    
    'open_mutex' of gendisk is used to protect open/close block devices. But
    in bd_link_disk_holder(), it is used to protect the creation of symlink
    between holding disk and slave bdev, which introduces some issues.
    
    When bd_link_disk_holder() is called, the driver is usually in the process
    of initialization/modification and may suspend submitting io. At this
    time, any io hold 'open_mutex', such as scanning partitions, can cause
    deadlocks. For example, in raid:
    
    T1                              T2
    bdev_open_by_dev
     lock open_mutex [1]
     ...
      efi_partition
      ...
       md_submit_bio
                                    md_ioctl mddev_syspend
                                      -> suspend all io
                                     md_add_new_disk
                                      bind_rdev_to_array
                                       bd_link_disk_holder
                                        try lock open_mutex [2]
        md_handle_request
         -> wait mddev_resume
    
    T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume
    mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.
    
    Fix it by introducing a local mutex 'blk_holder_mutex' to replace
    'open_mutex'.
    
    Fixes: 1b0a2d950ee2 ("md: use new apis to suspend array for ioctls involed array reconfiguration")
    Reported-by: [email protected]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218459
    Signed-off-by: Li Nan <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: af_bluetooth: Fix deadlock [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Mar 1 12:58:11 2024 -0500

    Bluetooth: af_bluetooth: Fix deadlock
    
    [ Upstream commit f7b94bdc1ec107c92262716b073b3e816d4784fb ]
    
    Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
    bellow, so instead of using sock_sock this uses sk_receive_queue.lock
    on bt_sock_ioctl to avoid the UAF:
    
    INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
          Not tainted 6.7.6-lemon #183
    Workqueue: hci0 hci_rx_work
    Call Trace:
     <TASK>
     __schedule+0x37d/0xa00
     schedule+0x32/0xe0
     __lock_sock+0x68/0xa0
     ? __pfx_autoremove_wake_function+0x10/0x10
     lock_sock_nested+0x43/0x50
     l2cap_sock_recv_cb+0x21/0xa0
     l2cap_recv_frame+0x55b/0x30a0
     ? psi_task_switch+0xeb/0x270
     ? finish_task_switch.isra.0+0x93/0x2a0
     hci_rx_work+0x33a/0x3f0
     process_one_work+0x13a/0x2f0
     worker_thread+0x2f0/0x410
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xe0/0x110
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2c/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>
    
    Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btrtl: fix out of bounds memory access [+ + +]
Author: Andrey Skvortsov <[email protected]>
Date:   Sat Feb 24 00:37:04 2024 +0300

    Bluetooth: btrtl: fix out of bounds memory access
    
    [ Upstream commit de4e88ec58c4202efd1f02eebb4939bbf6945358 ]
    
    The problem is detected by KASAN.
    btrtl driver uses private hci data to store 'struct btrealtek_data'.
    If btrtl driver is used with btusb, then memory for private hci data
    is allocated in btusb. But no private data is allocated after hci_dev,
    when btrtl is used with hci_h5.
    
    This commit adds memory allocation for hci_h5 case.
    
     ==================================================================
     BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl]
     Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76
    
     Hardware name: Pine64 PinePhone (1.2) (DT)
     Workqueue: hci0 hci_power_on [bluetooth]
     Call trace:
      dump_backtrace+0x9c/0x128
      show_stack+0x20/0x38
      dump_stack_lvl+0x48/0x60
      print_report+0xf8/0x5d8
      kasan_report+0x90/0xd0
      __asan_store8+0x9c/0xc0
             [btrtl]
      h5_btrtl_setup+0xd0/0x2f8 [hci_uart]
      h5_setup+0x50/0x80 [hci_uart]
      hci_uart_setup+0xd4/0x260 [hci_uart]
      hci_dev_open_sync+0x1cc/0xf68 [bluetooth]
      hci_dev_do_open+0x34/0x90 [bluetooth]
      hci_power_on+0xc4/0x3c8 [bluetooth]
      process_one_work+0x328/0x6f0
      worker_thread+0x410/0x778
      kthread+0x168/0x178
      ret_from_fork+0x10/0x20
    
     Allocated by task 53:
      kasan_save_stack+0x3c/0x68
      kasan_save_track+0x20/0x40
      kasan_save_alloc_info+0x68/0x78
      __kasan_kmalloc+0xd4/0xd8
      __kmalloc+0x1b4/0x3b0
      hci_alloc_dev_priv+0x28/0xa58 [bluetooth]
      hci_uart_register_device+0x118/0x4f8 [hci_uart]
      h5_serdev_probe+0xf4/0x178 [hci_uart]
      serdev_drv_probe+0x54/0xa0
      really_probe+0x254/0x588
      __driver_probe_device+0xc4/0x210
      driver_probe_device+0x64/0x160
      __driver_attach_async_helper+0x88/0x158
      async_run_entry_fn+0xd0/0x388
      process_one_work+0x328/0x6f0
      worker_thread+0x410/0x778
      kthread+0x168/0x178
      ret_from_fork+0x10/0x20
    
     Last potentially related work creation:
      kasan_save_stack+0x3c/0x68
      __kasan_record_aux_stack+0xb0/0x150
      kasan_record_aux_stack_noalloc+0x14/0x20
      __queue_work+0x33c/0x960
      queue_work_on+0x98/0xc0
      hci_recv_frame+0xc8/0x1e8 [bluetooth]
      h5_complete_rx_pkt+0x2c8/0x800 [hci_uart]
      h5_rx_payload+0x98/0xb8 [hci_uart]
      h5_recv+0x158/0x3d8 [hci_uart]
      hci_uart_receive_buf+0xa0/0xe8 [hci_uart]
      ttyport_receive_buf+0xac/0x178
      flush_to_ldisc+0x130/0x2c8
      process_one_work+0x328/0x6f0
      worker_thread+0x410/0x778
      kthread+0x168/0x178
      ret_from_fork+0x10/0x20
    
     Second to last potentially related work creation:
      kasan_save_stack+0x3c/0x68
      __kasan_record_aux_stack+0xb0/0x150
      kasan_record_aux_stack_noalloc+0x14/0x20
      __queue_work+0x788/0x960
      queue_work_on+0x98/0xc0
      __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth]
      __hci_cmd_sync+0x24/0x38 [bluetooth]
      btrtl_initialize+0x760/0x958 [btrtl]
      h5_btrtl_setup+0xd0/0x2f8 [hci_uart]
      h5_setup+0x50/0x80 [hci_uart]
      hci_uart_setup+0xd4/0x260 [hci_uart]
      hci_dev_open_sync+0x1cc/0xf68 [bluetooth]
      hci_dev_do_open+0x34/0x90 [bluetooth]
      hci_power_on+0xc4/0x3c8 [bluetooth]
      process_one_work+0x328/0x6f0
      worker_thread+0x410/0x778
      kthread+0x168/0x178
      ret_from_fork+0x10/0x20
     ==================================================================
    
    Fixes: 5b355944b190 ("Bluetooth: btrtl: Add btrealtek data struct")
    Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support")
    Signed-off-by: Andrey Skvortsov <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btusb: Fix memory leak [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 11:17:24 2024 -0500

    Bluetooth: btusb: Fix memory leak
    
    [ Upstream commit 79f4127a502c5905f04da1f20a7bbe07103fb77c ]
    
    This checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone
    the skb and also make sure btmtk_process_coredump frees the skb passed
    following the same logic.
    
    Fixes: 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek devcoredump support")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Fix eir name length [+ + +]
Author: Frédéric Danis <[email protected]>
Date:   Thu Mar 7 17:42:05 2024 +0100

    Bluetooth: Fix eir name length
    
    [ Upstream commit 2ab3e8d67fc1d4a7638b769cf83023ec209fc0a9 ]
    
    According to Section 1.2 of Core Specification Supplement Part A the
    complete or short name strings are defined as utf8s, which should not
    include the trailing NULL for variable length array as defined in Core
    Specification Vol1 Part E Section 2.9.3.
    
    Removing the trailing NULL allows PTS to retrieve the random address based
    on device name, e.g. for SM/PER/KDU/BV-02-C, SM/PER/KDU/BV-08-C or
    GAP/BROB/BCST/BV-03-C.
    
    Fixes: f61851f64b17 ("Bluetooth: Fix append max 11 bytes of name to scan rsp data")
    Signed-off-by: Frédéric Danis <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: fix use-after-free in accessing skb after sending it [+ + +]
Author: Pauli Virtanen <[email protected]>
Date:   Sat Mar 2 19:06:23 2024 +0200

    Bluetooth: fix use-after-free in accessing skb after sending it
    
    [ Upstream commit 947ec0d002dce8577b655793dcc6fc78d67b7cb6 ]
    
    hci_send_cmd_sync first sends skb and then tries to clone it.  However,
    the driver may have already freed the skb at that point.
    
    Fix by cloning the sent_cmd cloned just above, instead of the original.
    
    Log:
    ================================================================
    BUG: KASAN: slab-use-after-free in __copy_skb_header+0x1a/0x240
    ...
    Call Trace: ..
     __skb_clone+0x59/0x2c0
     hci_cmd_work+0x3b3/0x3d0 [bluetooth]
     process_one_work+0x459/0x900
    ...
    Allocated by task 129: ...
     __alloc_skb+0x1ae/0x220
     __hci_cmd_sync_sk+0x44c/0x7a0 [bluetooth]
     __hci_cmd_sync_status+0x24/0xb0 [bluetooth]
     set_cig_params_sync+0x778/0x7d0 [bluetooth]
    ...
    Freed by task 0: ...
     kmem_cache_free+0x157/0x3c0
     __usb_hcd_giveback_urb+0x11e/0x1e0
     usb_giveback_urb_bh+0x1ad/0x2a0
     tasklet_action_common.isra.0+0x259/0x4a0
     __do_softirq+0x15b/0x5a7
    ================================================================
    
    Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback")
    Signed-off-by: Pauli Virtanen <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_core: Cancel request on command timeout [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Tue Jan 9 13:45:40 2024 -0500

    Bluetooth: hci_core: Cancel request on command timeout
    
    [ Upstream commit 63298d6e752fc0ec7f5093860af8bc9f047b30c8 ]
    
    If command has timed out call __hci_cmd_sync_cancel to notify the
    hci_req since it will inevitably cause a timeout.
    
    This also rework the code around __hci_cmd_sync_cancel since it was
    wrongly assuming it needs to cancel timer as well, but sometimes the
    timers have not been started or in fact they already had timed out in
    which case they don't need to be cancel yet again.
    
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_core: Fix possible buffer overflow [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 10:49:26 2024 -0500

    Bluetooth: hci_core: Fix possible buffer overflow
    
    [ Upstream commit 81137162bfaa7278785b24c1fd2e9e74f082e8e4 ]
    
    struct hci_dev_info has a fixed size name[8] field so in the event that
    hdev->name is bigger than that strcpy would attempt to write past its
    size, so this fixes this problem by switching to use strscpy.
    
    Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_event: Fix not indicating new connection for BIG Sync [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Jan 31 11:24:19 2024 -0500

    Bluetooth: hci_event: Fix not indicating new connection for BIG Sync
    
    [ Upstream commit eeda1bf97bb500a901f7a9ee5615bad2160f2378 ]
    
    BIG Sync (aka. Broadcast sink) requires to inform that the device is
    connected when a data path is active otherwise userspace could attempt
    to free resources allocated to the device object while scanning.
    
    Fixes: 1d11d70d1f6b ("Bluetooth: ISO: Pass BIG encryption info through QoS")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_h5: Add ability to allocate memory for private data [+ + +]
Author: Andrey Skvortsov <[email protected]>
Date:   Sat Feb 24 00:37:03 2024 +0300

    Bluetooth: hci_h5: Add ability to allocate memory for private data
    
    [ Upstream commit 7a6d793e9ca8bc0c1d2f0aa0a02ec380d1124c74 ]
    
    In some cases uart-base drivers may need to use priv data. For
    example, to store information needed for devcoredump.
    
    Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support")
    Signed-off-by: Andrey Skvortsov <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional() [+ + +]
Author: Bartosz Golaszewski <[email protected]>
Date:   Thu Feb 8 17:40:17 2024 +0100

    Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()
    
    [ Upstream commit 56d074d26c5828773b00b2185dd7e1d08273b8e8 ]
    
    The optional variants for the gpiod_get() family of functions return NULL
    if the GPIO in question is not associated with this device. They return
    ERR_PTR() on any other error. NULL descriptors are graciously handled by
    GPIOLIB and can be safely passed to any of the GPIO consumer interfaces
    as they will return 0 and act as if the function succeeded. If one is
    using the optional variant, then there's no point in checking for NULL.
    
    Fixes: 6845667146a2 ("Bluetooth: hci_qca: Fix NULL vs IS_ERR_OR_NULL check in qca_serdev_probe")
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: Fix overwriting request callback [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Feb 16 16:20:11 2024 -0500

    Bluetooth: hci_sync: Fix overwriting request callback
    
    [ Upstream commit 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ]
    
    In a few cases the stack may generate commands as responses to events
    which would happen to overwrite the sent_cmd, so this attempts to store
    the request in req_skb so even if sent_cmd is replaced with a new
    command the pending request will remain in stored in req_skb.
    
    Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: mgmt: Remove leftover queuing of power_off work [+ + +]
Author: Jonas Dreßler <[email protected]>
Date:   Sun Jan 7 19:02:48 2024 +0100

    Bluetooth: mgmt: Remove leftover queuing of power_off work
    
    [ Upstream commit fee054b7579fe252f8b9e6c17b9c5bfdaa84dd7e ]
    
    Queuing of power_off work was introduced in these functions with commits
    8b064a3ad377 ("Bluetooth: Clean up HCI state when doing power off") and
    c9910d0fb4fc ("Bluetooth: Fix disconnecting connections in non-connected
    states") in an effort to clean up state and do things like disconnecting
    devices before actually powering off the device.
    
    After that, commit a3172b7eb4a2 ("Bluetooth: Add timer to force power off")
    introduced a timeout to ensure that the device actually got powered off,
    even if some of the cleanup work would never complete.
    
    This code later got refactored with commit cf75ad8b41d2 ("Bluetooth:
    hci_sync: Convert MGMT_SET_POWERED"), which made powering off the device
    synchronous and removed the need for initiating the power_off work from
    other places. The timeout mentioned above got removed too, because we now
    also made use of the command timeout during power on/off.
    
    These days the power_off work still exists, but it only seems to only be
    used for HCI_AUTO_OFF functionality, which is why we never noticed
    those two leftover places where we queue power_off work. So let's remove
    that code.
    
    Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED")
    Signed-off-by: Jonas Dreßler <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: msft: Fix memory leak [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 10:56:49 2024 -0500

    Bluetooth: msft: Fix memory leak
    
    [ Upstream commit a6e06258f4c31eba0fcd503e19828b5f8fe7b08b ]
    
    Fix leaking buffer allocated to send MSFT_OP_LE_MONITOR_ADVERTISEMENT.
    
    Fixes: 9e14606d8f38 ("Bluetooth: msft: Extended monitor tracking by address filter")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Remove BT_HS [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Thu Feb 1 11:18:58 2024 -0500

    Bluetooth: Remove BT_HS
    
    [ Upstream commit e7b02296fb400ee64822fbdd81a0718449066333 ]
    
    High Speed, Alternate MAC and PHY (AMP) extension, has been removed from
    Bluetooth Core specification on 5.3:
    
    https://www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancements/
    
    Fixes: 244bc377591c ("Bluetooth: Add BT_HS config option")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Remove HCI_POWER_OFF_TIMEOUT [+ + +]
Author: Jonas Dreßler <[email protected]>
Date:   Sun Jan 7 19:02:47 2024 +0100

    Bluetooth: Remove HCI_POWER_OFF_TIMEOUT
    
    [ Upstream commit 968667f2e0345a67a6eea5a502f4659085666564 ]
    
    With commit cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED"),
    the power off sequence got refactored so that this timeout was no longer
    necessary, let's remove the leftover define from the header too.
    
    Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED")
    Signed-off-by: Jonas Dreßler <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Remove superfluous call to hci_conn_check_pending() [+ + +]
Author: Jonas Dreßler <[email protected]>
Date:   Mon Jan 8 23:46:06 2024 +0100

    Bluetooth: Remove superfluous call to hci_conn_check_pending()
    
    [ Upstream commit 78e3639fc8031275010c3287ac548c0bc8de83b1 ]
    
    The "pending connections" feature was originally introduced with commit
    4c67bc74f016 ("[Bluetooth] Support concurrent connect requests") and
    6bd57416127e ("[Bluetooth] Handling pending connect attempts after
    inquiry") to handle controllers supporting only a single connection request
    at a time. Later things were extended to also cancel ongoing inquiries on
    connect() with commit 89e65975fea5 ("Bluetooth: Cancel Inquiry before
    Create Connection").
    
    With commit a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only
    opcodes"), hci_conn_check_pending() was introduced as a helper to
    consolidate a few places where we check for pending connections (indicated
    by the BT_CONNECT2 flag) and then try to connect.
    
    This refactoring commit also snuck in two more calls to
    hci_conn_check_pending():
    
    - One is in the failure callback of hci_cs_inquiry(), this one probably
    makes sense: If we send an "HCI Inquiry" command and then immediately
    after a "Create Connection" command, the "Create Connection" command might
    fail before the "HCI Inquiry" command, and then we want to retry the
    "Create Connection" on failure of the "HCI Inquiry".
    
    - The other added call to hci_conn_check_pending() is in the event handler
    for the "Remote Name" event, this seems unrelated and is possibly a
    copy-paste error, so remove that one.
    
    Fixes: a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only opcodes")
    Signed-off-by: Jonas Dreßler <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: don't emit warnings intended for global subprogs for static subprogs [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Fri Feb 2 11:05:29 2024 -0800

    bpf: don't emit warnings intended for global subprogs for static subprogs
    
    [ Upstream commit 1eb986746a67952df86eb2c50a36450ef103d01b ]
    
    When btf_prepare_func_args() was generalized to handle both static and
    global subprogs, a few warnings/errors that are meant only for global
    subprog cases started to be emitted for static subprogs, where they are
    sort of expected and irrelavant.
    
    Stop polutting verifier logs with irrelevant scary-looking messages.
    
    Fixes: e26080d0da87 ("bpf: prepare btf_prepare_func_args() for handling static subprogs")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix DEVMAP_HASH overflow check on 32-bit arches [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Thu Mar 7 13:03:35 2024 +0100

    bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
    
    [ Upstream commit 281d464a34f540de166cee74b723e97ac2515ec3 ]
    
    The devmap code allocates a number hash buckets equal to the next power
    of two of the max_entries value provided when creating the map. When
    rounding up to the next power of two, the 32-bit variable storing the
    number of buckets can overflow, and the code checks for overflow by
    checking if the truncated 32-bit value is equal to 0. However, on 32-bit
    arches the rounding up itself can overflow mid-way through, because it
    ends up doing a left-shift of 32 bits on an unsigned long value. If the
    size of an unsigned long is four bytes, this is undefined behaviour, so
    there is no guarantee that we'll end up with a nice and tidy 0-value at
    the end.
    
    Syzbot managed to turn this into a crash on arm32 by creating a
    DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
    Fix this by moving the overflow check to before the rounding up
    operation.
    
    Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-and-tested-by: [email protected]
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix hashtab overflow check on 32-bit arches [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Thu Mar 7 13:03:36 2024 +0100

    bpf: Fix hashtab overflow check on 32-bit arches
    
    [ Upstream commit 6787d916c2cf9850c97a0a3f73e08c43e7d973b1 ]
    
    The hashtab code relies on roundup_pow_of_two() to compute the number of
    hash buckets, and contains an overflow check by checking if the
    resulting value is 0. However, on 32-bit arches, the roundup code itself
    can overflow by doing a 32-bit left-shift of an unsigned long value,
    which is undefined behaviour, so it is not guaranteed to truncate
    neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
    contains the same check, copied from the hashtab code. So apply the same
    fix to hashtab, by moving the overflow check to before the roundup.
    
    Fixes: daaf427c6ab3 ("bpf: fix arraymap NULL deref and missing overflow and zero size checks")
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix stackmap overflow check on 32-bit arches [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Thu Mar 7 13:03:37 2024 +0100

    bpf: Fix stackmap overflow check on 32-bit arches
    
    [ Upstream commit 7a4b21250bf79eef26543d35bd390448646c536b ]
    
    The stackmap code relies on roundup_pow_of_two() to compute the number
    of hash buckets, and contains an overflow check by checking if the
    resulting value is 0. However, on 32-bit arches, the roundup code itself
    can overflow by doing a 32-bit left-shift of an unsigned long value,
    which is undefined behaviour, so it is not guaranteed to truncate
    neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
    contains the same check, copied from the hashtab code.
    
    The commit in the fixes tag actually attempted to fix this, but the fix
    did not account for the UB, so the fix only works on CPUs where an
    overflow does result in a neat truncation to zero, which is not
    guaranteed. Checking the value before rounding does not have this
    problem.
    
    Fixes: 6183f4d3a0a2 ("bpf: Check for integer overflow when using roundup_pow_of_two()")
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Reviewed-by: Bui Quang Minh <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: hardcode BPF_PROG_PACK_SIZE to 2MB * num_possible_nodes() [+ + +]
Author: Puranjay Mohan <[email protected]>
Date:   Mon Mar 11 12:27:22 2024 +0000

    bpf: hardcode BPF_PROG_PACK_SIZE to 2MB * num_possible_nodes()
    
    [ Upstream commit d6170e4aaf86424c24ce06e355b4573daa891b17 ]
    
    On some architectures like ARM64, PMD_SIZE can be really large in some
    configurations. Like with CONFIG_ARM64_64K_PAGES=y the PMD_SIZE is
    512MB.
    
    Use 2MB * num_possible_nodes() as the size for allocations done through
    the prog pack allocator. On most architectures, PMD_SIZE will be equal
    to 2MB in case of 4KB pages and will be greater than 2MB for bigger page
    sizes.
    
    Fixes: ea2babac63d4 ("bpf: Simplify bpf_prog_pack_[size|mask]")
    Reported-by: "kernelci.org bot" <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Suggested-by: Song Liu <[email protected]>
    Signed-off-by: Puranjay Mohan <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: make sure scalar args don't accept __arg_nonnull tag [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Thu Jan 4 16:09:03 2024 -0800

    bpf: make sure scalar args don't accept __arg_nonnull tag
    
    [ Upstream commit 18810ad3929ff6b5d8e67e3adc40d690bd780fd6 ]
    
    Move scalar arg processing in btf_prepare_func_args() after all pointer
    arg processing is done. This makes it easier to do validation. One
    example of unintended behavior right now is ability to specify
    __arg_nonnull for integer/enum arguments. This patch fixes this.
    
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Stable-dep-of: 1eb986746a67 ("bpf: don't emit warnings intended for global subprogs for static subprogs")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Mark bpf_spin_{lock,unlock}() helpers with notrace correctly [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Tue Feb 6 23:01:02 2024 -0800

    bpf: Mark bpf_spin_{lock,unlock}() helpers with notrace correctly
    
    [ Upstream commit 178c54666f9c4d2f49f2ea661d0c11b52f0ed190 ]
    
    Currently tracing is supposed not to allow for bpf_spin_{lock,unlock}()
    helper calls. This is to prevent deadlock for the following cases:
      - there is a prog (prog-A) calling bpf_spin_{lock,unlock}().
      - there is a tracing program (prog-B), e.g., fentry, attached
        to bpf_spin_lock() and/or bpf_spin_unlock().
      - prog-B calls bpf_spin_{lock,unlock}().
    For such a case, when prog-A calls bpf_spin_{lock,unlock}(),
    a deadlock will happen.
    
    The related source codes are below in kernel/bpf/helpers.c:
      notrace BPF_CALL_1(bpf_spin_lock, struct bpf_spin_lock *, lock)
      notrace BPF_CALL_1(bpf_spin_unlock, struct bpf_spin_lock *, lock)
    notrace is supposed to prevent fentry prog from attaching to
    bpf_spin_{lock,unlock}().
    
    But actually this is not the case and fentry prog can successfully
    attached to bpf_spin_lock(). Siddharth Chintamaneni reported
    the issue in [1]. The following is the macro definition for
    above BPF_CALL_1:
      #define BPF_CALL_x(x, name, ...)                                               \
            static __always_inline                                                 \
            u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__));   \
            typedef u64 (*btf_##name)(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__)); \
            u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__));         \
            u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__))          \
            {                                                                      \
                    return ((btf_##name)____##name)(__BPF_MAP(x,__BPF_CAST,__BPF_N,__VA_ARGS__));\
            }                                                                      \
            static __always_inline                                                 \
            u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__))
    
      #define BPF_CALL_1(name, ...)   BPF_CALL_x(1, name, __VA_ARGS__)
    
    The notrace attribute is actually applied to the static always_inline function
    ____bpf_spin_{lock,unlock}(). The actual callback function
    bpf_spin_{lock,unlock}() is not marked with notrace, hence
    allowing fentry prog to attach to two helpers, and this
    may cause the above mentioned deadlock. Siddharth Chintamaneni
    actually has a reproducer in [2].
    
    To fix the issue, a new macro NOTRACE_BPF_CALL_1 is introduced which
    will add notrace attribute to the original function instead of
    the hidden always_inline function and this fixed the problem.
    
      [1] https://lore.kernel.org/bpf/CAE5sdEigPnoGrzN8WU7Tx-h-iFuMZgW06qp0KHWtpvoXxf1OAQ@mail.gmail.com/
      [2] https://lore.kernel.org/bpf/CAE5sdEg6yUc_Jz50AnUXEEUh6O73yQ1Z6NV2srJnef0ZrQkZew@mail.gmail.com/
    
    Fixes: d83525ca62cf ("bpf: introduce bpf_spin_lock")
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: report RCU QS in cpumap kthread [+ + +]
Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:40 2024 -0700

    bpf: report RCU QS in cpumap kthread
    
    [ Upstream commit 00bf63122459e87193ee7f1bc6161c83a525569f ]
    
    When there are heavy load, cpumap kernel threads can be busy polling
    packets from redirect queues and block out RCU tasks from reaching
    quiescent states. It is insufficient to just call cond_resched() in such
    context. Periodically raise a consolidated RCU QS before cond_resched
    fixes the problem.
    
    Fixes: 6710e1126934 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP")
    Reviewed-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/r/c17b9f1517e19d813da3ede5ed33ee18496bb5d8.1710877680.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpftool: Fix wrong free call in do_show_link [+ + +]
Author: Jiri Olsa <[email protected]>
Date:   Fri Jan 19 12:05:00 2024 +0100

    bpftool: Fix wrong free call in do_show_link
    
    [ Upstream commit 2adb2e0fcdf3c6d8e28a5a9c33e458e1037ae5ad ]
    
    The error path frees wrong array, it should be ref_ctr_offsets.
    
    Acked-by: Yafang Shao <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Fixes: a7795698f8b6 ("bpftool: Add support to display uprobe_multi links")
    Signed-off-by: Jiri Olsa <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpftool: Silence build warning about calloc() [+ + +]
Author: Tiezhu Yang <[email protected]>
Date:   Tue Jan 16 14:19:20 2024 +0800

    bpftool: Silence build warning about calloc()
    
    [ Upstream commit f5f30386c78105cba520e443a6a9ee945ec1d066 ]
    
    There exists the following warning when building bpftool:
    
      CC      prog.o
    prog.c: In function ‘profile_open_perf_events’:
    prog.c:2301:24: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
     2301 |                 sizeof(int), obj->rodata->num_cpu * obj->rodata->num_metric);
          |                        ^~~
    prog.c:2301:24: note: earlier argument should specify number of elements, later size of each element
    
    Tested with the latest upstream GCC which contains a new warning option
    -Wcalloc-transposed-args. The first argument to calloc is documented to
    be number of elements in array, while the second argument is size of each
    element, just switch the first and second arguments of calloc() to silence
    the build warning, compile tested only.
    
    Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
    Signed-off-by: Tiezhu Yang <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix race when detecting delalloc ranges during fiemap [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed Feb 28 11:37:56 2024 +0000

    btrfs: fix race when detecting delalloc ranges during fiemap
    
    [ Upstream commit 978b63f7464abcfd364a6c95f734282c50f3decf ]
    
    For fiemap we recently stopped locking the target extent range for the
    whole duration of the fiemap call, in order to avoid a deadlock in a
    scenario where the fiemap buffer happens to be a memory mapped range of
    the same file. This use case is very unlikely to be useful in practice but
    it may be triggered by fuzz testing (syzbot, etc).
    
    This however introduced a race that makes us miss delalloc ranges for
    file regions that are currently holes, so the caller of fiemap will not
    be aware that there's data for some file regions. This can be quite
    serious for some use cases - for example in coreutils versions before 9.0,
    the cp program used fiemap to detect holes and data in the source file,
    copying only regions with data (extents or delalloc) from the source file
    to the destination file in order to preserve holes (see the documentation
    for its --sparse command line option). This means that if cp was used
    with a source file that had delalloc in a hole, the destination file could
    end up without that data, which is effectively a data loss issue, if it
    happened to hit the race described below.
    
    The race happens like this:
    
    1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that
       has delalloc in the file range [64M, 65M[, which is currently a hole;
    
    2) Fiemap locks the inode in shared mode, then starts iterating the
       inode's subvolume tree searching for file extent items, without having
       the whole fiemap target range locked in the inode's io tree - the
       change introduced recently by commit b0ad381fa769 ("btrfs: fix
       deadlock with fiemap and extent locking"). It only locks ranges in
       the io tree when it finds a hole or prealloc extent since that
       commit;
    
    3) Note that fiemap clones each leaf before using it, and this is to
       avoid deadlocks when locking a file range in the inode's io tree and
       the fiemap buffer is memory mapped to some file, because writing
       to the page with btrfs_page_mkwrite() will wait on any ordered extent
       for the page's range and the ordered extent needs to lock the range
       and may need to modify the same leaf, therefore leading to a deadlock
       on the leaf;
    
    4) While iterating the file extent items in the cloned leaf before
       finding the hole in the range [64M, 65M[, the delalloc in that range
       is flushed and its ordered extent completes - meaning the corresponding
       file extent item is in the inode's subvolume tree, but not present in
       the cloned leaf that fiemap is iterating over;
    
    5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in
       the cloned leaf (or a file extent item with disk_bytenr == 0 in case
       the NO_HOLES feature is not enabled), it will lock that file range in
       the inode's io tree and then search for delalloc by checking for the
       EXTENT_DELALLOC bit in the io tree for that range and ordered extents
       (with btrfs_find_delalloc_in_range()). But it finds nothing since the
       delalloc in that range was already flushed and the ordered extent
       completed and is gone - as a result fiemap will not report that there's
       delalloc or an extent for the range [64M, 65M[, so user space will be
       mislead into thinking that there's a hole in that range.
    
    This could actually be sporadically triggered with test case generic/094
    from fstests, which reports a missing extent/delalloc range like this:
    
    #  generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)
    #      --- tests/generic/094.out        2020-06-10 19:29:03.830519425 +0100
    #      +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000
    #      @@ -1,3 +1,9 @@
    #       QA output created by 094
    #       fiemap run with sync
    #       fiemap run without sync
    #      +ERROR: couldn't find extent at 7
    #      +map is 'HHDDHPPDPHPH'
    #      +logical: [       5..       6] phys:   301517..  301518 flags: 0x800 tot: 2
    #      +logical: [       8..       8] phys:   301520..  301520 flags: 0x800 tot: 1
    #      ...
    #      (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/generic/094.out /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad'  to see the entire diff)
    
    So in order to fix this, while still avoiding deadlocks in the case where
    the fiemap buffer is memory mapped to the same file, change fiemap to work
    like the following:
    
    1) Always lock the whole range in the inode's io tree before starting to
       iterate the inode's subvolume tree searching for file extent items,
       just like we did before commit b0ad381fa769 ("btrfs: fix deadlock with
       fiemap and extent locking");
    
    2) Now instead of writing to the fiemap buffer every time we have an extent
       to report, write instead to a temporary buffer (1 page), and when that
       buffer becomes full, stop iterating the file extent items, unlock the
       range in the io tree, release the search path, submit all the entries
       kept in that buffer to the fiemap buffer, and then resume the search
       for file extent items after locking again the remainder of the range in
       the io tree.
    
       The buffer having a size of a page, allows for 146 entries in a system
       with 4K pages. This is a large enough value to have a good performance
       by avoiding too many restarts of the search for file extent items.
       In other words this preserves the huge performance gains made in the
       last two years to fiemap, while avoiding the deadlocks in case the
       fiemap buffer is memory mapped to the same file (useless in practice,
       but possible and exercised by fuzz testing and syzbot).
    
    Fixes: b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking")
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: mhi: ep: check the correct variable in mhi_ep_register_controller() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Feb 21 09:20:19 2024 +0300

    bus: mhi: ep: check the correct variable in mhi_ep_register_controller()
    
    [ Upstream commit 27711860c54ccb5e80719df684f49f0bf3f8fb51 ]
    
    There is a copy and paste bug here so it checks "ev_ring_el_cache" instead
    of "ring_item_cache".
    
    Fixes: 62210a26cd4f ("bus: mhi: ep: Use slab allocator where applicable")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bus: tegra-aconnect: Update dependency to ARCH_TEGRA [+ + +]
Author: Peter Robinson <[email protected]>
Date:   Fri Feb 16 10:02:37 2024 +0000

    bus: tegra-aconnect: Update dependency to ARCH_TEGRA
    
    [ Upstream commit 4acd21a45c1446277e2abaece97d7fa7c2e692a9 ]
    
    Update the architecture dependency to be the generic Tegra
    because the driver works on the four latest Tegra generations
    not just Tegra210, if you build a kernel with a specific
    ARCH_TEGRA_xxx_SOC option that excludes Tegra210 you don't get
    this driver.
    
    Fixes: 46a88534afb59 ("bus: Add support for Tegra ACONNECT")
    Signed-off-by: Peter Robinson <[email protected]>
    Cc: Jon Hunter <[email protected]>
    Cc: Thierry Reding <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
can: m_can: Start/Cancel polling timer together with interrupts [+ + +]
Author: Markus Schneider-Pargmann <[email protected]>
Date:   Wed Feb 7 10:32:07 2024 +0100

    can: m_can: Start/Cancel polling timer together with interrupts
    
    [ Upstream commit a163c5761019b94258ca655b27b46e82657fd6f5 ]
    
    Interrupts are enabled/disabled in more places than just m_can_start()
    and m_can_stop(). Couple the polling timer with enabling/disabling of
    all interrupts to achieve equivalent behavior.
    
    Cc: Judith Mendez <[email protected]>
    Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrupt")
    Signed-off-by: Markus Schneider-Pargmann <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ceph: stop copying to iter at EOF on sync reads [+ + +]
Author: Xiubo Li <[email protected]>
Date:   Wed Feb 21 09:16:12 2024 +0800

    ceph: stop copying to iter at EOF on sync reads
    
    [ Upstream commit 1065da21e5df9d843d2c5165d5d576be000142a6 ]
    
    If EOF is encountered, ceph_sync_read() return value is adjusted down
    according to i_size, but the "to" iter is advanced by the actual number
    of bytes read.  Then, when retrying, the remainder of the range may be
    skipped incorrectly.
    
    Ensure that the "to" iter is advanced only until EOF.
    
    [ idryomov: changelog ]
    
    Fixes: c3d8e0b5de48 ("ceph: return the real size read when it hits EOF")
    Reported-by: Frank Hsiao <[email protected]>
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Ilya Dryomov <[email protected]>
    Tested-by: Frank Hsiao <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
char: xilinx_hwicap: Fix NULL vs IS_ERR() bug [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Feb 20 12:02:31 2024 +0300

    char: xilinx_hwicap: Fix NULL vs IS_ERR() bug
    
    [ Upstream commit 316459ba4051fd91237171fdca88920128a646f1 ]
    
    The devm_platform_ioremap_resource() function returns error pointers.
    It never returns NULL.  Update the check accordingly.
    
    Fixes: 672371832193 ("char: xilinx_hwicap: Modernize driver probe")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Michal Simek <[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]>

 
cifs: Fix writeback data corruption [+ + +]
Author: David Howells <[email protected]>
Date:   Thu Feb 22 11:20:26 2024 +0000

    cifs: Fix writeback data corruption
    
    [ Upstream commit f3dc1bdb6b0b0693562c7c54a6c28bafa608ba3c ]
    
    cifs writeback doesn't correctly handle the case where
    cifs_extend_writeback() hits a point where it is considering an additional
    folio, but this would overrun the wsize - at which point it drops out of
    the xarray scanning loop and calls xas_pause().  The problem is that
    xas_pause() advances the loop counter - thereby skipping that page.
    
    What needs to happen is for xas_reset() to be called any time we decide we
    don't want to process the page we're looking at, but rather send the
    request we are building and start a new one.
    
    Fix this by copying and adapting the netfslib writepages code as a
    temporary measure, with cifs writeback intending to be offloaded to
    netfslib in the near future.
    
    This also fixes the issue with the use of filemap_get_folios_tag() causing
    retry of a bunch of pages which the extender already dealt with.
    
    This can be tested by creating, say, a 64K file somewhere not on cifs
    (otherwise copy-offload may get underfoot), mounting a cifs share with a
    wsize of 64000, copying the file to it and then comparing the original file
    and the copy:
    
            dd if=/dev/urandom of=/tmp/64K bs=64k count=1
            mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000
            cp /tmp/64K /mnt/64K
            cmp /tmp/64K /mnt/64K
    
    Without the fix, the cmp fails at position 64000 (or shortly thereafter).
    
    Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
    Signed-off-by: David Howells <[email protected]>
    cc: Steve French <[email protected]>
    cc: Paulo Alcantara <[email protected]>
    cc: Ronnie Sahlberg <[email protected]>
    cc: Shyam Prasad N <[email protected]>
    cc: Tom Talpey <[email protected]>
    cc: Jeff Layton <[email protected]>
    cc: [email protected]
    cc: [email protected]
    cc: [email protected]
    cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: Fix clk_core_get NULL dereference [+ + +]
Author: Bryan O'Donoghue <[email protected]>
Date:   Sat Mar 2 00:52:14 2024 +0000

    clk: Fix clk_core_get NULL dereference
    
    [ Upstream commit e97fe4901e0f59a0bfd524578fe3768f8ca42428 ]
    
    It is possible for clk_core_get to dereference a NULL in the following
    sequence:
    
    clk_core_get()
        of_clk_get_hw_from_clkspec()
            __of_clk_get_hw_from_provider()
                __clk_get_hw()
    
    __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
    hw->core.
    
    Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
    clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
    caught the NULL.
    
    Reading the description of this function it talks about returning NULL but
    that cannot be so at the moment.
    
    Update the function to check for hw before dereferencing it and return NULL
    if hw is NULL.
    
    Fixes: dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups")
    Signed-off-by: Bryan O'Donoghue <[email protected]>
    Link: https://lore.kernel.org/r/20240302-linux-next-24-03-01-simple-clock-fixes-v1-1-25f348a5982b@linaro.org
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: hisilicon: hi3519: Release the correct number of gates in hi3519_clk_unregister() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Wed Jan 10 19:58:21 2024 +0100

    clk: hisilicon: hi3519: Release the correct number of gates in hi3519_clk_unregister()
    
    [ Upstream commit 74e39f526d95c0c119ada1874871ee328c59fbee ]
    
    The gates are stored in 'hi3519_gate_clks', not 'hi3519_mux_clks'.
    This is also in line with how hisi_clk_register_gate() is called in the
    probe.
    
    Fixes: 224b3b262c52 ("clk: hisilicon: hi3519: add driver remove path and fix some issues")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/c3f1877c9a0886fa35c949c8f0ef25547f284f18.1704912510.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: hisilicon: hi3559a: Fix an erroneous devm_kfree() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 21 16:16:24 2024 +0100

    clk: hisilicon: hi3559a: Fix an erroneous devm_kfree()
    
    [ Upstream commit 64c6a38136b74a2f18c42199830975edd9fbc379 ]
    
    'p_clk' is an array allocated just before the for loop for all clk that
    need to be registered.
    It is incremented at each loop iteration.
    
    If a clk_register() call fails, 'p_clk' may point to something different
    from what should be freed.
    
    The best we can do, is to avoid this wrong release of memory.
    
    Fixes: 6c81966107dc ("clk: hisilicon: Add clock driver for hi3559A SoC")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/773fc8425c3b8f5b0ca7c1d89f15b65831a85ca9.1705850155.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: imx8mp: Fix SAI_MCLK_SEL definition [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Fri Feb 23 18:15:51 2024 +0800

    clk: imx: imx8mp: Fix SAI_MCLK_SEL definition
    
    [ Upstream commit 13269dc6c70444528f0093585e3559cd2f38850a ]
    
    There is SAI1, SAI2, SAI3, SAI5, SAI6, SAI7 existing in this block
    control, the order is discontinuous. The definition of SAI_MCLK_SEL(n)
    is not match with the usage of CLK_SAIn(n).
    
    So define SAI##n##_MCLK_SEL separately to fix the issue.
    
    Fixes: 6cd95f7b151c ("clk: imx: imx8mp: Add audiomix block control")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 7 09:29:28 2024 +0100

    clk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe()
    
    [ Upstream commit a32e88f2b20259f5fe4f8eed598bbc85dc4879ed ]
    
    'clk_data' is allocated with mtk_devm_alloc_clk_data(). So calling
    mtk_free_clk_data() explicitly in the remove function would lead to a
    double-free.
    
    Remove the redundant call.
    
    Fixes: c50e2ea6507b ("clk: mediatek: mt7622-apmixedsys: Add .remove() callback for module build")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/2c553c2a5077757e4f7af0bb895acc43881cf62c.1704616152.git.christophe.jaillet@wanadoo.fr
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: mediatek: mt7981-topckgen: flag SGM_REG_SEL as critical [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Sun Feb 18 03:11:15 2024 +0000

    clk: mediatek: mt7981-topckgen: flag SGM_REG_SEL as critical
    
    [ Upstream commit aa690050c00a251ab69e3c5204d582833d0b958c ]
    
    Without the SGM_REG_SEL clock enabled the cpu freezes if trying to
    access registers used by MT7981 clock drivers itself.
    Mark SGM_REG_SEL as critical to make sure it is always enabled to
    prevent freezes on boot even if the Ethernet driver which prepares
    and enables the clock is not loaded or probed at a later point.
    
    Fixes: 813c3b53b55b ("clk: mediatek: add MT7981 clock support")
    Signed-off-by: Daniel Golle <[email protected]>
    Link: https://lore.kernel.org/r/fc157139e6b7f8dfb6430ac7191ba754027705e8.1708221995.git.daniel@makrotopia.org
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: mediatek: mt8135: Fix an error handling path in clk_mt8135_apmixed_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 7 09:12:17 2024 +0100

    clk: mediatek: mt8135: Fix an error handling path in clk_mt8135_apmixed_probe()
    
    [ Upstream commit 03c1c51eba6be49b42816af9db114553131af6c8 ]
    
    If an error occurs after mtk_alloc_clk_data(), mtk_free_clk_data() should
    be called, as already done in the remove function.
    
    Fixes: 54b7026f011e ("clk: mediatek: mt8135-apmixedsys: Convert to platform_driver and module")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/6cd6af61e5a91598068227f1f68cfcfde1507453.1704615011.git.christophe.jaillet@wanadoo.fr
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: mediatek: mt8183: Correct parent of CLK_INFRA_SSPM_32K_SELF [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Mon Feb 19 18:51:24 2024 +0800

    clk: mediatek: mt8183: Correct parent of CLK_INFRA_SSPM_32K_SELF
    
    [ Upstream commit a65083fa663a335008e34f65e184041174a9dc7e ]
    
    CLK_INFRA_SSPM_32K_SELF has the "f_f26m_ck" clock assigned as its parent.
    This is inconsistent as the clock is part of a group that are all gates
    without dividers, and this makes the kernel think it runs at 26 MHz.
    
    After clarification from MediaTek engineers, the correct parent is
    actually the system 32 KHz clock.
    
    Fixes: 1eb8d61ac5c9 ("clk: mediatek: mt8183: Add back SSPM related clocks")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: meson: Add missing clocks to axg_clk_regmaps [+ + +]
Author: Igor Prusov <[email protected]>
Date:   Fri Feb 2 17:25:48 2024 +0300

    clk: meson: Add missing clocks to axg_clk_regmaps
    
    [ Upstream commit ba535bce57e71463a86f8b33a0ea88c26e3a6418 ]
    
    Some clocks were missing from axg_clk_regmaps, which caused kernel panic
    during cat /sys/kernel/debug/clk/clk_summary
    
    [   57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc
    ...
    [   57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   57.436900] pc : regmap_read+0x1c/0x88
    [   57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0
    [   57.445611] sp : ffff800082f1b690
    [   57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70
    [   57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000
    [   57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000
    [   57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff
    [   57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000
    [   57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100
    [   57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24
    [   57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710
    [   57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000
    [   57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000
    [   57.519615] Call trace:
    [   57.522030]  regmap_read+0x1c/0x88
    [   57.525393]  clk_regmap_gate_is_enabled+0x3c/0xb0
    [   57.530050]  clk_core_is_enabled+0x44/0x120
    [   57.534190]  clk_summary_show_subtree+0x154/0x2f0
    [   57.538847]  clk_summary_show_subtree+0x220/0x2f0
    [   57.543505]  clk_summary_show_subtree+0x220/0x2f0
    [   57.548162]  clk_summary_show_subtree+0x220/0x2f0
    [   57.552820]  clk_summary_show_subtree+0x220/0x2f0
    [   57.557477]  clk_summary_show_subtree+0x220/0x2f0
    [   57.562135]  clk_summary_show_subtree+0x220/0x2f0
    [   57.566792]  clk_summary_show_subtree+0x220/0x2f0
    [   57.571450]  clk_summary_show+0x84/0xb8
    [   57.575245]  seq_read_iter+0x1bc/0x4b8
    [   57.578954]  seq_read+0x8c/0xd0
    [   57.582059]  full_proxy_read+0x68/0xc8
    [   57.585767]  vfs_read+0xb0/0x268
    [   57.588959]  ksys_read+0x70/0x108
    [   57.592236]  __arm64_sys_read+0x24/0x38
    [   57.596031]  invoke_syscall+0x50/0x128
    [   57.599740]  el0_svc_common.constprop.0+0x48/0xf8
    [   57.604397]  do_el0_svc+0x28/0x40
    [   57.607675]  el0_svc+0x34/0xb8
    [   57.610694]  el0t_64_sync_handler+0x13c/0x158
    [   57.615006]  el0t_64_sync+0x190/0x198
    [   57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)
    [   57.624668] ---[ end trace 0000000000000000 ]---
    
    [jbrunet: add missing Fixes tag]
    Signed-off-by: Igor Prusov <[email protected]>
    Link: https://lore.kernel.org/r/20240202172537.1.I64656c75d84284bc91e6126b50b33c502be7c42a@changeid
    Fixes: 14ebb3154b8f ("clk: meson: axg: add Video Clocks")
    Signed-off-by: Jerome Brunet <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sdm845: Adjust internal GDSC wait times [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Wed Jan 3 21:20:18 2024 +0100

    clk: qcom: dispcc-sdm845: Adjust internal GDSC wait times
    
    [ Upstream commit 117e7dc697c2739d754db8fe0c1e2d4f1f5d5f82 ]
    
    SDM845 downstream uses non-default values for GDSC internal waits.
    Program them accordingly to avoid surprises.
    
    Fixes: 81351776c9fb ("clk: qcom: Add display clock controller driver for SDM845")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Tested-by: Caleb Connolly <[email protected]> # OnePlus 6
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: gcc-ipq5018: fix 'enable_reg' offset of 'gcc_gmac0_sys_clk' [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:54 2024 +0100

    clk: qcom: gcc-ipq5018: fix 'enable_reg' offset of 'gcc_gmac0_sys_clk'
    
    [ Upstream commit f982adcc1b1c02a3114f68ac73c811cbfabe90fa ]
    
    The value of the 'enable_reg' field in the 'gcc_gmac0_sys_clk'
    clock definition seems wrong as it is greater than the
    'max_register' value defined in the regmap configuration.
    Additionally, all other gmac specific branch clock definitions
    within the driver uses the same value both for the 'enable_reg'
    and for the 'halt_reg' fields.
    
    Due to the lack of documentation the correct value is not known.
    Looking into the downstream driver does not help either, as that
    uses the same (presumably wrong) value [1].
    
    Nevertheless, change the 'enable_reg' field of 'gcc_gmac0_sys_clk'
    to use the value from the 'halt_reg' field so it follows the pattern
    used in other gmac clock definitions. The change is based on the
    assumption that the register layout of this clock is the same
    as the other gmac clocks.
    
    1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L1889
    
    Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
    Signed-off-by: Gabor Juhos <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Kathiravan Thirumoorthy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: gcc-ipq5018: fix 'halt_reg' offset of 'gcc_pcie1_pipe_clk' [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:55 2024 +0100

    clk: qcom: gcc-ipq5018: fix 'halt_reg' offset of 'gcc_pcie1_pipe_clk'
    
    [ Upstream commit 11b752ac5a07cbfd95592fac5237a02f45662926 ]
    
    The following table shows the values of the 'halt_reg' and the
    'enable_reg' fields from the pcie clocks defined in the current
    driver:
    
      clock                        halt_reg    enable_reg
    
      gcc_pcie0_ahb_clk            0x75010     0x75010
      gcc_pcie0_aux_clk            0x75014     0x75014
      gcc_pcie0_axi_m_clk          0x75008     0x75008
      gcc_pcie0_axi_s_bridge_clk   0x75048     0x75048
      gcc_pcie0_axi_s_clk          0x7500c     0x7500c
      gcc_pcie0_pipe_clk           0x75018     0x75018
    
      gcc_pcie1_ahb_clk            0x76010     0x76010
      gcc_pcie1_aux_clk            0x76014     0x76014
      gcc_pcie1_axi_m_clk          0x76008     0x76008
      gcc_pcie1_axi_s_bridge_clk   0x76048     0x76048
      gcc_pcie1_axi_s_clk          0x7600c     0x7600c
      gcc_pcie1_pipe_clk                 8*    0x76018
    
    Based on the table, it is quite likely that the pcie0 and the pci1
    clocks are using the same register layout, however it seems that
    the value of the 'halt_reg' field in the 'gcc_pcie1_pipe_clk' clock
    is wrong.
    
    In the downstream driver [1], the same '0x76018' value is used for
    both the 'halt_reg' and for the 'enable_reg' fields of the
    'gcc_pcie1_pipe_clk' clock.
    
    Update the current driver to use the same value used downstream as
    probably that is the correct value.
    
    1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L2316
    
    Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
    Signed-off-by: Gabor Juhos <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Kathiravan Thirumoorthy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: gcc-ipq5018: fix register offset for GCC_UBI0_AXI_ARES reset [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:56 2024 +0100

    clk: qcom: gcc-ipq5018: fix register offset for GCC_UBI0_AXI_ARES reset
    
    [ Upstream commit 7d474b43087aa356d714d39870c90d77fc6f1186 ]
    
    The current register offset used for the GCC_UBI0_AXI_ARES reset
    seems wrong. Or at least, the downstream driver uses [1] the same
    offset which is used for other the GCC_UBI0_*_ARES resets.
    
    Change the code to use the same offset used in the downstream
    driver and also specify the reset bit explicitly to use the
    same format as the followup entries.
    
    1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L3773
    
    Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
    Signed-off-by: Gabor Juhos <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Kathiravan Thirumoorthy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: reset: Commonize the de/assert functions [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Feb 6 19:43:35 2024 +0100

    clk: qcom: reset: Commonize the de/assert functions
    
    [ Upstream commit eda40d9c583e95e0b6ac69d2950eec10f802e0e8 ]
    
    They do the same thing, except the last argument of the last function
    call differs. Commonize them.
    
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Stable-dep-of: 2f8cf2c3f3e3 ("clk: qcom: reset: Ensure write completion on reset de/assertion")
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: reset: Ensure write completion on reset de/assertion [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Feb 6 19:43:36 2024 +0100

    clk: qcom: reset: Ensure write completion on reset de/assertion
    
    [ Upstream commit 2f8cf2c3f3e3f7ef61bd19abb4b0bb797ad50aaf ]
    
    Trying to toggle the resets in a rapid fashion can lead to the changes
    not actually arriving at the clock controller block when we expect them
    to. This was observed at least on SM8250.
    
    Read back the value after regmap_update_bits to ensure write completion.
    
    Fixes: b36ba30c8ac6 ("clk: qcom: Add reset controller support")
    Signed-off-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]>

clk: renesas: r8a779f0: Correct PFC/GPIO parent clock [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 25 16:45:13 2024 +0100

    clk: renesas: r8a779f0: Correct PFC/GPIO parent clock
    
    [ Upstream commit d1b32a83a02d9433dbd8c5f4d6fc44aa597755bd ]
    
    According to the R-Car S4 Series Hardware User’s Manual Rev.0.81, the
    parent clock of the Pin Function (PFC/GPIO) module clock is the CP
    clock.
    
    As this clock is not documented to exist on R-Car S4, use the CPEX clock
    instead.
    
    Fixes: 73421f2a48e6bd1d ("clk: renesas: r8a779f0: Add PFC clock")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/f88ec4aede0eaf0107c8bb7b28ba719ac6cd418f.1706197415.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: r8a779g0: Correct PFC/GPIO parent clocks [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 25 16:43:26 2024 +0100

    clk: renesas: r8a779g0: Correct PFC/GPIO parent clocks
    
    [ Upstream commit abb3fa662b8f8eaed1590b0e7a4e19eda467cdd3 ]
    
    According to the R-Car V4H Series Hardware User’s Manual Rev.1.00, the
    parent clock of the Pin Function (PFC/GPIO) module clocks is the CP
    clock.
    
    Fix this by adding the missing CP clock, and correcting the PFC parents.
    
    Fixes: f2afa78d5a0c0b0b ("dt-bindings: clock: Add r8a779g0 CPG Core Clock Definitions")
    Fixes: 36ff366033f0dde1 ("clk: renesas: r8a779g0: Add PFC/GPIO clocks")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/5401fccd204dc90b44f0013e7f53b9eff8df8214.1706197297.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: r8a779g0: Fix PCIe clock name [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Jan 30 10:47:49 2024 +0100

    clk: renesas: r8a779g0: Fix PCIe clock name
    
    [ Upstream commit 096311157d2a6bb8f06e28e1143e2a5de6a0183b ]
    
    Fix a typo in the name of the module clock for the second PCIe channel.
    
    Fixes: 5ab16198b431ca48 ("clk: renesas: r8a779g0: Add PCIe clocks")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Wolfram Sang <[email protected]>
    Link: https://lore.kernel.org/r/f582067564f357e2183d3db67b217084ecb51888.1706608032.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: r9a07g04[34]: Use SEL_SDHI1_STS status configuration for SD1 mux [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Wed Jan 31 12:29:29 2024 +0200

    clk: renesas: r9a07g04[34]: Use SEL_SDHI1_STS status configuration for SD1 mux
    
    [ Upstream commit 9b2a11c83859c06233049b134bd8ee974b284559 ]
    
    The status configuration for SD1 mux clock is SEL_SDHI1_STS. Fix it.
    
    Fixes: 16b86e5c03c5 ("clk: renesas: rzg2l: Refactor SD mux driver")
    Reported-by: Hien Huynh <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: samsung: exynos850: Propagate SPI IPCLK rate change [+ + +]
Author: Sam Protsenko <[email protected]>
Date:   Wed Jan 24 19:38:56 2024 -0600

    clk: samsung: exynos850: Propagate SPI IPCLK rate change
    
    [ Upstream commit 67c15187d4910ee353374676d4dddf09d8cb227e ]
    
    When SPI transfer is being prepared, the spi-s3c64xx driver will call
    clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
    is a gate (leaf) clock, so it must propagate the rate change up the
    clock tree, so that corresponding DIV clocks can actually change their
    divider values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
    all SPI instances in Exynos850 (spi_0, spi_1 and spi_2) to make it
    possible. This change involves next clocks:
    
    usi_spi_0:
    
        Clock                  Block       Div range
        --------------------------------------------
        gout_spi0_ipclk        CMU_PERI    -
        dout_peri_spi0         CMU_PERI    /1..32
        mout_peri_spi_user     CMU_PERI    -
        dout_peri_ip           CMU_TOP     /1..16
    
    usi_cmgp0:
    
        Clock                  Block       Div range
        --------------------------------------------
        gout_cmgp_usi0_ipclk   CMU_CMGP    -
        dout_cmgp_usi0         CMU_CMGP    /1..32
        mout_cmgp_usi0         CMU_CMGP    -
        gout_clkcmu_cmgp_bus   CMU_APM     -
        dout_apm_bus           CMU_APM     /1..8
    
    usi_cmgp1:
    
        Clock                  Block       Div range
        --------------------------------------------
        gout_cmgp_usi1_ipclk   CMU_CMGP    -
        dout_cmgp_usi1         CMU_CMGP    /1..32
        mout_cmgp_usi1         CMU_CMGP    -
        gout_clkcmu_cmgp_bus   CMU_APM     -
        dout_apm_bus           CMU_APM     /1..8
    
    With input clock of 400 MHz, this scheme provides next IPCLK rate range,
    for each SPI block:
    
        SPI0:   781 kHz ... 400 MHz
        SPI1/2: 1.6 MHz ... 400 MHz
    
    Accounting for internal /4 divider in SPI blocks, and because the max
    SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
    
        SPI0:   200 kHz ... 49.9 MHz
        SPI1/2: 400 kHz ... 49.9 MHz
    
    Which should cover all possible applications of SPI bus. Of course,
    setting SPI frequency to values as low as 500 kHz will also affect the
    common bus dividers (dout_apm_bus or dout_peri_ip), which in turn
    effectively lowers the rates for all leaf bus clocks derived from those
    dividers, like HSI2C and I3C clocks. But at least it gives the board
    designer a choice, whether to keep all clocks (SPI/HSI2C/I3C) at high
    frequencies, or make all those clocks have lower frequencies. Not
    propagating the rate change to those common dividers would limit this
    choice to "only high frequencies are allowed for SPI/HSI2C/I3C" option,
    making the common dividers useless. This decision follows the "Worse is
    better" approach, relying on the users/engineers to know the system
    internals when working with such low-level features, instead of trying
    to account for all possible use-cases.
    
    Fixes: 7dd05578198b ("clk: samsung: Introduce Exynos850 clock driver")
    Signed-off-by: Sam Protsenko <[email protected]>
    Reviewed-by: Tudor Ambarus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: zynq: Prevent null pointer dereference caused by kmalloc failure [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Fri Mar 1 16:44:37 2024 +0800

    clk: zynq: Prevent null pointer dereference caused by kmalloc failure
    
    [ Upstream commit 7938e9ce39d6779d2f85d822cc930f73420e54a6 ]
    
    The kmalloc() in zynq_clk_setup() will return null if the
    physical memory has run out. As a result, if we use snprintf()
    to write data to the null address, the null pointer dereference
    bug will happen.
    
    This patch uses a stack variable to replace the kmalloc().
    
    Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
    Suggested-by: Michal Simek <[email protected]>
    Suggested-by: Stephen Boyd <[email protected]>
    Signed-off-by: Duoming Zhou <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Michal Simek <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coccinelle: device_attr_show: Remove useless expression STR [+ + +]
Author: Li Zhijian <[email protected]>
Date:   Sun Feb 18 16:00:54 2024 +0800

    coccinelle: device_attr_show: Remove useless expression STR
    
    [ Upstream commit 173f6cd384ae27bb57af8cc5201b4f4a137d6e55 ]
    
    Commit ff82e84e80fc ("coccinelle: device_attr_show: simplify patch case")
    simplifies the patch case, as a result, STR is no longer needed.
    
    This also helps to fix below coccicheck warning:
    > warning: rp: metavariable STR not used in the - or context code
    
    CC: Julia Lawall <[email protected]>
    CC: Nicolas Palix <[email protected]>
    CC: [email protected]
    Fixes: ff82e84e80fc ("coccinelle: device_attr_show: simplify patch case")
    Signed-off-by: Li Zhijian <[email protected]>
    Signed-off-by: Julia Lawall <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: etm4x: Set skip_power_up in etm4_init_arch_data function [+ + +]
Author: Mao Jinlong <[email protected]>
Date:   Wed Jan 31 02:54:19 2024 -0800

    coresight: etm4x: Set skip_power_up in etm4_init_arch_data function
    
    [ Upstream commit 1bbe0a247e5d72f723daeecf41596bfa99e199f1 ]
    
    skip_power_up is used in etm4_init_arch_data when set lpoverride. So
    need to set the value of it before calling using it.
    
    Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
    Signed-off-by: Mao Jinlong <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Fix issue where a source device's helpers aren't disabled [+ + +]
Author: James Clark <[email protected]>
Date:   Mon Jan 29 15:40:32 2024 +0000

    coresight: Fix issue where a source device's helpers aren't disabled
    
    [ Upstream commit f68bbe4dcfa303164922bc331d2e8d38ed2d4f23 ]
    
    The linked commit reverts the change that accidentally used some sysfs
    enable/disable functions from Perf which broke the refcounting, but it
    also removes the fact that the sysfs disable function disabled the
    helpers.
    
    Add a new wrapper function that does both which is used by both Perf and
    sysfs, and label the sysfs disable function appropriately. The naming of
    all of the functions will be tidied up later to avoid this happening
    again.
    
    Fixes: 287e82cf69aa ("coresight: Fix crash when Perf and sysfs modes are used concurrently")
    Signed-off-by: James Clark <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value [+ + +]
Author: Anastasia Belova <[email protected]>
Date:   Wed Jan 17 10:12:20 2024 +0300

    cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
    
    [ Upstream commit f661017e6d326ee187db24194cabb013d81bc2a6 ]
    
    cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
    and return 0 in case of error.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
    Signed-off-by: Anastasia Belova <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw() [+ + +]
Author: Sibi Sankar <[email protected]>
Date:   Tue Mar 12 16:07:23 2024 +0530

    cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()
    
    [ Upstream commit f37a4d6b4a2c77414e8b9d25dd5ee31537ce9b00 ]
    
    In the existing code, per-policy flags don't have any impact i.e.
    if cpufreq_driver boost is enabled and boost is disabled for one or
    more of the policies, the cpufreq driver will behave as if boost is
    enabled.
    
    Fix this by incorporating per-policy boost flag in the policy->max
    computation used in cpufreq_frequency_table_cpuinfo and setting the
    default per-policy boost to mirror the cpufreq_driver boost flag.
    
    Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost")
    Reported-by: Dietmar Eggemann <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Signed-off-by: Sibi Sankar <[email protected]>
    Tested-by:Yipeng Zou <[email protected]> <mailto:[email protected]>
    Reviewed-by: Yipeng Zou <[email protected]> <mailto:[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: mediatek-hw: Don't error out if supply is not found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Wed Jan 24 17:31:43 2024 -0300

    cpufreq: mediatek-hw: Don't error out if supply is not found
    
    [ Upstream commit eaffb10b51bf74415c9252fd8fb4dd77122501ee ]
    
    devm_regulator_get_optional() returns -ENODEV if no supply can be found.
    By introducing its usage, commit 788715b5f21c ("cpufreq: mediatek-hw:
    Wait for CPU supplies before probing") caused the driver to fail probe
    if no supply was present in any of the CPU DT nodes.
    
    Use devm_regulator_get() instead since the CPUs do require supplies
    even if not described in the DT. It will gracefully return a dummy
    regulator if none is found in the DT node, allowing probe to succeed.
    
    Fixes: 788715b5f21c ("cpufreq: mediatek-hw: Wait for CPU supplies before probing")
    Reported-by: kernelci.org bot <[email protected]>
    Closes: https://linux.kernelci.org/test/case/id/65b0b169710edea22852a3fa/
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: mediatek-hw: Wait for CPU supplies before probing [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Wed Jan 10 11:23:02 2024 -0300

    cpufreq: mediatek-hw: Wait for CPU supplies before probing
    
    [ Upstream commit 788715b5f21c6455264fe00a1779e61bec407fe2 ]
    
    Before proceeding with the probe and enabling frequency scaling for the
    CPUs, make sure that all supplies feeding the CPUs have probed.
    
    This fixes an issue observed on MT8195-Tomato where if the
    mediatek-cpufreq-hw driver enabled the hardware (by writing to
    REG_FREQ_ENABLE) before the SPMI controller driver (spmi-mtk-pmif),
    behind which lies the big CPU supply, probed the platform would hang
    shortly after with "rcu: INFO: rcu_preempt detected stalls on
    CPUs/tasks" being printed in the log.
    
    Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: qcom-hw: add CONFIG_COMMON_CLK dependency [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Feb 15 09:33:14 2024 +0100

    cpufreq: qcom-hw: add CONFIG_COMMON_CLK dependency
    
    [ Upstream commit 3093fa33539b54db77171d2919352ad4f044a1c5 ]
    
    It is still possible to compile-test a kernel without CONFIG_COMMON_CLK
    for some ancient ARM boards or other architectures, but this causes a
    link failure in the qcom-cpufreq-hw driver:
    
    ERROR: modpost: "devm_clk_hw_register" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
    ERROR: modpost: "devm_of_clk_add_hw_provider" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
    ERROR: modpost: "of_clk_hw_onecell_get" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
    
    Add a Kconfig dependency here to make sure this always work. Apparently
    this bug has been in the kernel for a while without me running into it
    on randconfig builds as COMMON_CLK is almost always enabled.
    
    I have cross-checked by building an allmodconfig kernel with COMMON_CLK
    disabled, which showed no other driver having this problem.
    
    Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: arm/sha - fix function cast warnings [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 14:49:46 2024 +0100

    crypto: arm/sha - fix function cast warnings
    
    [ Upstream commit 53cc9baeb9bc2a187eb9c9790d30995148852b12 ]
    
    clang-16 warns about casting between incompatible function types:
    
    arch/arm/crypto/sha256_glue.c:37:5: error: cast from 'void (*)(u32 *, const void *, unsigned int)' (aka 'void (*)(unsigned int *, const void *, unsigned int)') to 'sha256_block_fn *' (aka 'void (*)(struct sha256_state *, const unsigned char *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       37 |                                 (sha256_block_fn *)sha256_block_data_order);
          |                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    arch/arm/crypto/sha512-glue.c:34:3: error: cast from 'void (*)(u64 *, const u8 *, int)' (aka 'void (*)(unsigned long long *, const unsigned char *, int)') to 'sha512_block_fn *' (aka 'void (*)(struct sha512_state *, const unsigned char *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       34 |                 (sha512_block_fn *)sha512_block_data_order);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix the prototypes for the assembler functions to match the typedef.
    The code already relies on the digest being the first part of the
    state structure, so there is no change in behavior.
    
    Fixes: c80ae7ca3726 ("crypto: arm/sha512 - accelerated SHA-512 using ARM generic ASM and NEON")
    Fixes: b59e2ae3690c ("crypto: arm/sha256 - move SHA-224/256 ASM/NEON implementation to base layer")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - Avoid discarding errors in psp_send_platform_access_msg() [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Feb 13 11:34:28 2024 -0600

    crypto: ccp - Avoid discarding errors in psp_send_platform_access_msg()
    
    [ Upstream commit 0e8fca2f12ceb77c3a6b6f210135031f264aa612 ]
    
    Errors can potentially occur in the "processing" of PSP commands or
    commands can be processed successfully but still return an error code in
    the header.
    
    This second case was being discarded because PSP communication worked but
    the command returned an error code in the payload header.
    
    Capture both cases and return them to the caller as -EIO for the caller
    to investigate. The caller can detect the latter by looking at
    `req->header->status`.
    
    Reported-and-tested-by: Tim Van Patten <[email protected]>
    Fixes: 7ccc4f4e2e50 ("crypto: ccp - Add support for an interface for platform features")
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: jitter - fix CRYPTO_JITTERENTROPY help text [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sat Feb 17 08:55:13 2024 -0800

    crypto: jitter - fix CRYPTO_JITTERENTROPY help text
    
    [ Upstream commit e63df1ec9a16dd9e13e9068243e64876de06f795 ]
    
    Correct various small problems in the help text:
    a. change 2 spaces to ", "
    b. finish an incomplete sentence
    c. change non-working URL to working URL
    
    Fixes: a9a98d49da52 ("crypto: Kconfig - simplify compression/RNG entries")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218458
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Bagas Sanjaya <[email protected]>
    Cc: Robert Elliott <[email protected]>
    Cc: Christoph Biedl <[email protected]>
    Cc: Herbert Xu <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Cc: [email protected]
    Acked-by: Bagas Sanjaya <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - avoid division by zero [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:57 2024 +0000

    crypto: qat - avoid division by zero
    
    [ Upstream commit f99fb7d660f7c818105803f1f1915396a14d18ad ]
    
    Check if delta_us is not zero and return -EINVAL if it is.
    delta_us is unlikely to be zero as there is a sleep between the reads of
    the two timestamps.
    
    This is to fix the following warning when compiling the QAT driver
    using clang scan-build:
        drivers/crypto/intel/qat/qat_common/adf_clock.c:87:9: warning: Division by zero [core.DivideZero]
           87 |         temp = DIV_ROUND_CLOSEST_ULL(temp, delta_us);
              |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fixes: e2980ba57e79 ("crypto: qat - add measure clock frequency")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - avoid memcpy() overflow warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jan 3 17:26:02 2024 +0100

    crypto: qat - avoid memcpy() overflow warning
    
    [ Upstream commit 23a22e831ed4e6aa0831312e8cc8b7c60a657f60 ]
    
    The use of array_size() leads gcc to assume the memcpy() can have a larger
    limit than actually possible, which triggers a string fortification warning:
    
    In file included from include/linux/string.h:296,
                     from include/linux/bitmap.h:12,
                     from include/linux/cpumask.h:12,
                     from include/linux/sched.h:16,
                     from include/linux/delay.h:23,
                     from include/linux/iopoll.h:12,
                     from drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c:3:
    In function 'fortify_memcpy_chk',
        inlined from 'adf_gen4_init_thd2arb_map' at drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c:401:3:
    include/linux/fortify-string.h:579:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
      579 |    __write_overflow_field(p_size_field, size);
          |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    include/linux/fortify-string.h:588:4: error: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning]
      588 |    __read_overflow2_field(q_size_field, size);
          |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Add an explicit range check to avoid this.
    
    Fixes: 5da6a2d5353e ("crypto: qat - generate dynamically arbiter mappings")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix ring to service map for dcc in 420xx [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Fri Feb 16 18:21:55 2024 +0100

    crypto: qat - fix ring to service map for dcc in 420xx
    
    [ Upstream commit a20a6060e0dd57fecaf55487985aef28bd08c6bf ]
    
    If a device is configured for data compression chaining (dcc), half of the
    engines are loaded with the symmetric crypto image and the rest are loaded
    with the compression image.
    However, in such configuration all rings can handle compression requests.
    
    Fix the ring to service mapping so that when a device is configured for
    dcc, the ring to service mapping reports that all rings in a bank can
    be used for compression.
    
    Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices")
    Signed-off-by: Damian Muszynski <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix ring to service map for dcc in 4xxx [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Fri Feb 16 18:21:54 2024 +0100

    crypto: qat - fix ring to service map for dcc in 4xxx
    
    [ Upstream commit df018f82002a8b4dc407bc9a6f416b9241d14415 ]
    
    If a device is configured for data compression chaining (dcc), half of the
    engines are loaded with the symmetric crypto image and the rest are loaded
    with the compression image.
    However, in such configuration all rings can handle compression requests.
    
    Fix the ring to service mapping so that when a device is configured for
    dcc, the ring to service mapping reports that all rings in a bank can
    be used for compression.
    
    Fixes: a238487f7965 ("crypto: qat - fix ring to service map for QAT GEN4")
    Signed-off-by: Damian Muszynski <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - remove double initialization of value [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:58 2024 +0000

    crypto: qat - remove double initialization of value
    
    [ Upstream commit a66cf93ab33853f17b8cc33a99263dd0a383a1a1 ]
    
    Remove double initialization of the reg variable.
    
    This is to fix the following warning when compiling the QAT driver
    using clang scan-build:
        drivers/crypto/intel/qat/qat_common/adf_gen4_ras.c:1010:6: warning: Value stored to 'reg' during its initialization is never read [deadcode.DeadStores]
         1010 |         u32 reg = ADF_CSR_RD(csr, ADF_GEN4_SSMCPPERR);
              |             ^~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        drivers/crypto/intel/qat/qat_common/adf_gen4_ras.c:1109:6: warning: Value stored to 'reg' during its initialization is never read [deadcode.DeadStores]
         1109 |         u32 reg = ADF_CSR_RD(csr, ADF_GEN4_SER_ERR_SSMSH);
              |             ^~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fixes: 99b1c9826e48 ("crypto: qat - count QAT GEN4 errors")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - remove unused macros in qat_comp_alg.c [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:55 2024 +0000

    crypto: qat - remove unused macros in qat_comp_alg.c
    
    [ Upstream commit dfff0e35fa5dd84ae75052ba129b0219d83e46dc ]
    
    As a result of the removal of qat_zlib_deflate, some defines where not
    removed. Remove them.
    
    This is to fix the following warning when compiling the QAT driver
    using the clang compiler with CC=clang W=2:
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:21:9: warning: macro is not used [-Wunused-macros]
           21 | #define QAT_RFC_1950_CM_OFFSET 4
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:16:9: warning: macro is not used [-Wunused-macros]
           16 | #define QAT_RFC_1950_HDR_SIZE 2
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:17:9: warning: macro is not used [-Wunused-macros]
           17 | #define QAT_RFC_1950_FOOTER_SIZE 4
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:22:9: warning: macro is not used [-Wunused-macros]
           22 | #define QAT_RFC_1950_DICT_MASK 0x20
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:18:9: warning: macro is not used [-Wunused-macros]
           18 | #define QAT_RFC_1950_CM_DEFLATE 8
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:20:9: warning: macro is not used [-Wunused-macros]
           20 | #define QAT_RFC_1950_CM_MASK 0x0f
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:23:9: warning: macro is not used [-Wunused-macros]
           23 | #define QAT_RFC_1950_COMP_HDR 0x785e
              |         ^
        drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:19:9: warning: macro is not used [-Wunused-macros]
           19 | #define QAT_RFC_1950_CM_DEFLATE_CINFO_32K 7
              |         ^
    
    Fixes: e9dd20e0e5f6 ("crypto: qat - Remove zlib-deflate")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - removed unused macro in adf_cnv_dbgfs.c [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:56 2024 +0000

    crypto: qat - removed unused macro in adf_cnv_dbgfs.c
    
    [ Upstream commit 9a5dcada14d5e027856a1bc38443e54111438da6 ]
    
    This macro was added but never used, remove it.
    
    This is to fix the following warning when compiling the QAT driver
    using the clang compiler with CC=clang W=2:
        drivers/crypto/intel/qat/qat_common/adf_cnv_dbgfs.c:19:9: warning: macro is not used [-Wunused-macros]
           19 | #define CNV_SLICE_ERR_MASK              GENMASK(7, 0)
              |         ^
    
    Fixes: d807f0240c71 ("crypto: qat - add cnv_errors debugfs file")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: xilinx - call finalize with bh disabled [+ + +]
Author: Quanyang Wang <[email protected]>
Date:   Sun Jan 28 12:29:06 2024 +0800

    crypto: xilinx - call finalize with bh disabled
    
    [ Upstream commit a853450bf4c752e664abab0b2fad395b7ad7701c ]
    
    When calling crypto_finalize_request, BH should be disabled to avoid
    triggering the following calltrace:
    
        ------------[ cut here ]------------
        WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
        Modules linked in: cryptodev(O)
        CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G           O       6.8.0-rc1-yocto-standard #323
        Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
        pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : crypto_finalize_request+0xa0/0x118
        lr : crypto_finalize_request+0x104/0x118
        sp : ffffffc085353ce0
        x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
        x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
        x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
        x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
        x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
        x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
        x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
        x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
        x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
        x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
        Call trace:
         crypto_finalize_request+0xa0/0x118
         crypto_finalize_aead_request+0x18/0x30
         zynqmp_handle_aes_req+0xcc/0x388
         crypto_pump_work+0x168/0x2d8
         kthread_worker_fn+0xfc/0x3a0
         kthread+0x118/0x138
         ret_from_fork+0x10/0x20
        irq event stamp: 40
        hardirqs last  enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
        hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
        softirqs last  enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
        softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
        ---[ end trace 0000000000000000 ]---
    
    Fixes: 4d96f7d48131 ("crypto: xilinx - Add Xilinx AES driver")
    Signed-off-by: Quanyang Wang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl: Fix the incorrect assignment of SSLBIS entry pointer initial location [+ + +]
Author: Dave Jiang <[email protected]>
Date:   Fri Mar 1 14:09:48 2024 -0700

    cxl: Fix the incorrect assignment of SSLBIS entry pointer initial location
    
    [ Upstream commit 99b52aac2d40203d0f6468325018f68e2c494c24 ]
    
    The 'entry' pointer in cdat_sslbis_handler() is set to header +
    sizeof(common header). However, the math missed the addition of the SSLBIS
    main header. It should be header + sizeof(common header) + sizeof(*sslbis).
    Use a defined struct for all the SSLBIS parts in order to avoid pointer
    math errors.
    
    The bug causes incorrect parsing of the SSLBIS table and introduces incorrect
    performance values to the access_coordinates during the CXL access_coordinate
    calculation path if there are CXL switches present in the topology.
    
    The issue was found during testing of new code being added to add additional
    checks for invalid CDAT values during CXL access_coordinate calculation. The
    testing was done on qemu with a CXL topology including a CXL switch.
    
    Fixes: 80aa780dda20 ("cxl: Add callback to parse the SSLBIS subtable from CDAT")
    Signed-off-by: Dave Jiang <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Reviewed-by: Fan Ni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
devlink: Fix devlink parallel commands processing [+ + +]
Author: Shay Drory <[email protected]>
Date:   Tue Mar 12 12:52:38 2024 +0200

    devlink: Fix devlink parallel commands processing
    
    [ Upstream commit d7d75124965aee23e5e4421d78376545cf070b0a ]
    
    Commit 870c7ad4a52b ("devlink: protect devlink->dev by the instance
    lock") added devlink instance locking inside a loop that iterates over
    all the registered devlink instances on the machine in the pre-doit
    phase. This can lead to serialization of devlink commands over
    different devlink instances.
    
    For example: While the first devlink instance is executing firmware
    flash, all commands to other devlink instances on the machine are
    forced to wait until the first devlink finishes.
    
    Therefore, in the pre-doit phase, take the devlink instance lock only
    for the devlink instance the command is targeting. Devlink layer is
    taking a reference on the devlink instance, ensuring the devlink->dev
    pointer is valid. This reference taking was introduced by commit
    a380687200e0 ("devlink: take device reference for devlink object").
    Without this commit, it would not be safe to access devlink->dev
    lockless.
    
    Fixes: 870c7ad4a52b ("devlink: protect devlink->dev by the instance lock")
    Signed-off-by: Shay Drory <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

devlink: Fix length of eswitch inline-mode [+ + +]
Author: William Tu <[email protected]>
Date:   Sun Mar 10 18:45:47 2024 +0200

    devlink: Fix length of eswitch inline-mode
    
    [ Upstream commit 8f4cd89bf10607de08231d6d91a73dd63336808e ]
    
    Set eswitch inline-mode to be u8, not u16. Otherwise, errors below
    
    $ devlink dev eswitch set pci/0000:08:00.0 mode switchdev \
      inline-mode network
        Error: Attribute failed policy validation.
        kernel answers: Numerical result out of rang
        netlink: 'devlink': attribute type 26 has an invalid length.
    
    Fixes: f2f9dd164db0 ("netlink: specs: devlink: add the remaining command to generate complete split_ops")
    Signed-off-by: William Tu <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

devlink: fix port new reply cmd type [+ + +]
Author: Jiri Pirko <[email protected]>
Date:   Mon Mar 18 10:19:08 2024 +0100

    devlink: fix port new reply cmd type
    
    [ Upstream commit 78a2f5e6c15d8dcbd6495bb9635c7cb89235dfc5 ]
    
    Due to a c&p error, port new reply fills-up cmd with wrong value,
    any other existing port command replies and notifications.
    
    Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW.
    
    Skimmed through devlink userspace implementations, none of them cares
    about this cmd value.
    
    Reported-by: Chenyuan Yang <[email protected]>
    Closes: https://lore.kernel.org/all/ZfZcDxGV3tSy4qsV@cy-server/
    Fixes: cd76dcd68d96 ("devlink: Support add and delete devlink port")
    Signed-off-by: Jiri Pirko <[email protected]>
    Reviewed-by: Parav Pandit <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm io: Support IO priority [+ + +]
Author: Hongyu Jin <[email protected]>
Date:   Wed Jan 24 13:35:53 2024 +0800

    dm io: Support IO priority
    
    [ Upstream commit 6e5f0f6383b4896c7e9b943d84b136149d0f45e9 ]
    
    Some IO will dispatch from kworker with different io_context settings
    than the submitting task, we may need to specify a priority to avoid
    losing priority.
    
    Add IO priority parameter to dm_io() and update all callers.
    
    Co-developed-by: Yibin Ding <[email protected]>
    Signed-off-by: Yibin Ding <[email protected]>
    Signed-off-by: Hongyu Jin <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Reviewed-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Stable-dep-of: b4d78cfeb304 ("dm-integrity: align the outgoing bio in integrity_recheck")
    Signed-off-by: Sasha Levin <[email protected]>

 
dm raid: fix false positive for requeue needed during reshape [+ + +]
Author: Ming Lei <[email protected]>
Date:   Mon Mar 11 13:42:55 2024 -0400

    dm raid: fix false positive for requeue needed during reshape
    
    [ Upstream commit b25b8f4b8ecef0f48c05f0c3572daeabefe16526 ]
    
    An empty flush doesn't have a payload, so it should never be looked at
    when considering to possibly requeue a bio for the case when a reshape
    is in progress.
    
    Fixes: 9dbd1aa3a81c ("dm raid: add reshaping support to the target")
    Reported-by: Patrick Plenefisch <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm-integrity: align the outgoing bio in integrity_recheck [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Thu Mar 21 17:48:45 2024 +0100

    dm-integrity: align the outgoing bio in integrity_recheck
    
    [ Upstream commit b4d78cfeb30476239cf08f4f40afc095c173d6e3 ]
    
    It is possible to set up dm-integrity with smaller sector size than
    the logical sector size of the underlying device. In this situation,
    dm-integrity guarantees that the outgoing bios have the same alignment as
    incoming bios (so, if you create a filesystem with 4k block size,
    dm-integrity would send 4k-aligned bios to the underlying device).
    
    This guarantee was broken when integrity_recheck was implemented.
    integrity_recheck sends bio that is aligned to ic->sectors_per_block. So
    if we set up integrity with 512-byte sector size on a device with logical
    block size 4k, we would be sending unaligned bio. This triggered a bug in
    one of our internal tests.
    
    This commit fixes it by determining the actual alignment of the
    incoming bio and then makes sure that the outgoing bio in
    integrity_recheck has the same alignment.
    
    Fixes: c88f5e553fe3 ("dm-integrity: recheck the integrity tag after a failure")
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dm-integrity: fix a memory leak when rechecking the data [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Mon Mar 18 18:35:06 2024 +0100

    dm-integrity: fix a memory leak when rechecking the data
    
    [ Upstream commit 55e565c42dce81a4e49c13262d5bc4eb4c2e588a ]
    
    Memory for the "checksums" pointer will leak if the data is rechecked
    after checksum failure (because the associated kfree won't happen due
    to 'goto skip_io').
    
    Fix this by freeing the checksums memory before recheck, and just use
    the "checksum_onstack" memory for storing checksum during recheck.
    
    Fixes: c88f5e553fe3 ("dm-integrity: recheck the integrity tag after a failure")
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm: call the resume method on internal suspend [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Mon Mar 11 15:06:39 2024 +0100

    dm: call the resume method on internal suspend
    
    [ Upstream commit 65e8fbde64520001abf1c8d0e573561b4746ef38 ]
    
    There is this reported crash when experimenting with the lvm2 testsuite.
    The list corruption is caused by the fact that the postsuspend and resume
    methods were not paired correctly; there were two consecutive calls to the
    origin_postsuspend function. The second call attempts to remove the
    "hash_list" entry from a list, while it was already removed by the first
    call.
    
    Fix __dm_internal_resume so that it calls the preresume and resume
    methods of the table's targets.
    
    If a preresume method of some target fails, we are in a tricky situation.
    We can't return an error because dm_internal_resume isn't supposed to
    return errors. We can't return success, because then the "resume" and
    "postsuspend" methods would not be paired correctly. So, we set the
    DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
    tools, but it won't cause a kernel crash.
    
    ------------[ cut here ]------------
    kernel BUG at lib/list_debug.c:56!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
    RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
    <snip>
    RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
    RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
    RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
    R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
    R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
    FS:  00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
    Call Trace:
     <TASK>
     ? die+0x2d/0x80
     ? do_trap+0xeb/0xf0
     ? __list_del_entry_valid_or_report+0x77/0xc0
     ? do_error_trap+0x60/0x80
     ? __list_del_entry_valid_or_report+0x77/0xc0
     ? exc_invalid_op+0x49/0x60
     ? __list_del_entry_valid_or_report+0x77/0xc0
     ? asm_exc_invalid_op+0x16/0x20
     ? table_deps+0x1b0/0x1b0 [dm_mod]
     ? __list_del_entry_valid_or_report+0x77/0xc0
     origin_postsuspend+0x1a/0x50 [dm_snapshot]
     dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
     dm_suspend+0xd8/0xf0 [dm_mod]
     dev_suspend+0x1f2/0x2f0 [dm_mod]
     ? table_deps+0x1b0/0x1b0 [dm_mod]
     ctl_ioctl+0x300/0x5f0 [dm_mod]
     dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
     __x64_compat_sys_ioctl+0x104/0x170
     do_syscall_64+0x184/0x1b0
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    RIP: 0033:0xf7e6aead
    <snip>
    ---[ end trace 0000000000000000 ]---
    
    Fixes: ffcc39364160 ("dm: enhance internal suspend and resume interface")
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: tegra210-adma: Update dependency to ARCH_TEGRA [+ + +]
Author: Peter Robinson <[email protected]>
Date:   Fri Jan 12 09:32:56 2024 +0000

    dmaengine: tegra210-adma: Update dependency to ARCH_TEGRA
    
    [ Upstream commit 33b7db45533af240fe44e809f9dc4d604cf82d07 ]
    
    Update the architecture dependency to be the generic Tegra
    because the driver works on the four latest Tegra generations
    not just T210, if you build a kernel with a specific
    ARCH_TEGRA_xxx_SOC option that excludes 210 you don't get
    this driver.
    
    Fixes: 433de642a76c9 ("dmaengine: tegra210-adma: add support for Tegra186/Tegra194")
    Signed-off-by: Peter Robinson <[email protected]>
    Cc: Jon Hunter <[email protected]>
    Cc: Thierry Reding <[email protected]>
    Cc: Sameer Pujar <[email protected]>
    Cc: Laxman Dewangan <[email protected]>
    Reviewed-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Fri Jan 19 07:39:06 2024 -0800

    do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
    
    [ Upstream commit 3948abaa4e2be938ccdfc289385a27342fb13d43 ]
    
    syzbot identified a kernel information leak vulnerability in
    do_sys_name_to_handle() and issued the following report [1].
    
    [1]
    "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
     instrument_copy_to_user include/linux/instrumented.h:114 [inline]
     _copy_to_user+0xbc/0x100 lib/usercopy.c:40
     copy_to_user include/linux/uaccess.h:191 [inline]
     do_sys_name_to_handle fs/fhandle.c:73 [inline]
     __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
     __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
     __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
     ...
    
    Uninit was created at:
     slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
     slab_alloc_node mm/slub.c:3478 [inline]
     __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
     __do_kmalloc_node mm/slab_common.c:1006 [inline]
     __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
     kmalloc include/linux/slab.h:604 [inline]
     do_sys_name_to_handle fs/fhandle.c:39 [inline]
     __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
     __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
     __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
     ...
    
    Bytes 18-19 of 20 are uninitialized
    Memory access of size 20 starts at ffff888128a46380
    Data copied to user address 0000000020000240"
    
    Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
    solve the problem.
    
    Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support")
    Suggested-by: Chuck Lever III <[email protected]>
    Reported-and-tested-by: <[email protected]>
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
 
dpll: fix dpll_xa_ref_*_del() for multiple registrations [+ + +]
Author: Jiri Pirko <[email protected]>
Date:   Wed Mar 6 16:12:40 2024 +0100

    dpll: fix dpll_xa_ref_*_del() for multiple registrations
    
    [ Upstream commit b446631f355ece73b13c311dd712c47381a23172 ]
    
    Currently, if there are multiple registrations of the same pin on the
    same dpll device, following warnings are observed:
    WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230
    WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0
    
    The problem is, that in both dpll_xa_ref_dpll_del() and
    dpll_xa_ref_pin_del() registration is only removed from list in case the
    reference count drops to zero. That is wrong, the registration has to
    be removed always.
    
    To fix this, remove the registration from the list and free
    it unconditionally, instead of doing it only when the ref reference
    counter reaches zero.
    
    Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions")
    Signed-off-by: Jiri Pirko <[email protected]>
    Reviewed-by: Rahul Rameshbabu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dpll: spec: use proper enum for pin capabilities attribute [+ + +]
Author: Jiri Pirko <[email protected]>
Date:   Wed Mar 6 13:07:39 2024 +0100

    dpll: spec: use proper enum for pin capabilities attribute
    
    [ Upstream commit 5c497a64820ef9f10962a9c37607df45d6395fa5 ]
    
    The enum is defined, however the pin capabilities attribute does
    refer to it. Add this missing enum field.
    
    This fixes ynl cli output:
    
    Example current output:
    $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml --do pin-get --json '{"id": 0}'
    {'capabilities': 4,
     ...
    Example new output:
    $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml --do pin-get --json '{"id": 0}'
    {'capabilities': {'state-can-change'},
     ...
    
    Fixes: 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML")
    Signed-off-by: Jiri Pirko <[email protected]>
    Reviewed-by: Jakub Kicinski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/ps3: select VIDEO to provide cmdline functions [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 7 08:13:22 2024 -0800

    drivers/ps3: select VIDEO to provide cmdline functions
    
    [ Upstream commit 7edd06233958d9086a9e3eb723a8768d3c5a9ce1 ]
    
    When VIDEO is not set, there is a build error. Fix that by selecting
    VIDEO for PS3_PS3AV.
    
    ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
    
    Fixes: dae7fbf43fd0 ("driver/ps3: Include <video/cmdline.h> for mode parsing")
    Fixes: a3b6792e990d ("video/cmdline: Introduce CONFIG_VIDEO for video= parameter")
    Cc: Michael Ellerman <[email protected]>
    Cc: Nicholas Piggin <[email protected]>
    Cc: Christophe Leroy <[email protected]>
    Cc: Aneesh Kumar K.V <[email protected]>
    Cc: Naveen N. Rao <[email protected]>
    Cc: [email protected]
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Geoff Levand <[email protected]>
    Acked-by: Geoff Levand <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Randy Dunlap <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Acked-by: Michael Ellerman <[email protected]>
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()' [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Feb 15 18:38:16 2024 +0530

    drm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()'
    
    [ Upstream commit f6aed043ee5d75b3d1bfc452b1a9584b63c8f76b ]
    
    In the first if statement, we're checking if 'replay' is NULL. But in
    the second if statement, we're not checking if 'replay' is NULL again
    before calling replay->funcs->replay_set_power_opt().
    
    if (replay == NULL && force_static)
        return false;
    
    ...
    
    if (link->replay_settings.replay_feature_enabled &&
        replay->funcs->replay_set_power_opt) {
            replay->funcs->replay_set_power_opt(replay, *power_opts, panel_inst);
            link->replay_settings.replay_power_opt_active = *power_opts;
    }
    
    If 'replay' is NULL, this will cause a null pointer dereference.
    
    Fixes the below found by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:895 edp_set_replay_allow_active() error: we previously assumed 'replay' could be null (see line 887)
    
    Fixes: c7ddc0a800bc ("drm/amd/display: Add Functions to enable Freesync Panel Replay")
    Cc: Bhawanpreet Lakha <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Tom Chung <[email protected]>
    Suggested-by: Tom Chung <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Tue Jan 23 20:18:07 2024 +0530

    drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
    
    [ Upstream commit 4b09715f1504f1b6e8dff0e9643630610bc05141 ]
    
    Tell snprintf() to store at most 10 bytes in the output buffer
    instead of 30.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10
    
    Fixes: c06e09b76639 ("drm/amd/display: Add DSC parameters logging to debugfs")
    Cc: Alex Hung <[email protected]>
    Cc: Qingqing Zhuo <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Feb 6 08:50:56 2024 -0800

    drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()
    
    [ Upstream commit 2a3cfb9a24a28da9cc13d2c525a76548865e182c ]
    
    Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
    before the call to dc_enable_dmub_notifications(), check
    beforehand to ensure there will not be a possible NULL-ptr-deref
    there.
    
    Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
    CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in
    'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().
    Clean up by combining them all under one 'if'.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Jan 25 21:16:04 2024 +0530

    drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
    
    [ Upstream commit 9ccfe80d022df7c595f1925afb31de2232900656 ]
    
    The 'stream' pointer is used in dcn10_set_output_transfer_func() before
    the check if 'stream' is NULL.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
    
    Fixes: ddef02de0d71 ("drm/amd/display: add null checks before logging")
    Cc: Wyatt Wood <[email protected]>
    Cc: Anthony Koo <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Anthony Koo <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm: Fix esm reg mask use to get pcie speed [+ + +]
Author: Asad Kamal <[email protected]>
Date:   Wed Feb 28 12:24:15 2024 +0800

    drm/amd/pm: Fix esm reg mask use to get pcie speed
    
    [ Upstream commit b485b899e5b8f83723833feca30a1a1e3df778df ]
    
    Fix mask used for esm ctrl register to get pcie link
    speed on smu_v11_0_3, smu_v13_0_2 & smu_v13_0_6
    
    Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
    Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)")
    Fixes: f1c378593153 ("drm/amd/powerplay: add Arcturus support for gpu metrics export")
    Signed-off-by: Asad Kamal <[email protected]>
    Reviewed-by: Lijo Lazar <[email protected]>
    Reviewed-by: Le Ma <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: add MMHUB 3.3.1 support [+ + +]
Author: Yifan Zhang <[email protected]>
Date:   Thu Jan 4 10:39:48 2024 +0800

    drm/amdgpu: add MMHUB 3.3.1 support
    
    [ Upstream commit 31e0a586f3385134bcad00d8194eb0728cb1a17d ]
    
    This patch to add MMHUB 3.3.1 support.
    
    v2: squash in fault info fix (Alex)
    
    Signed-off-by: Yifan Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 6540ff6482c1 ("drm/amdgpu: fix mmhub client id out-of-bounds access")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: drop setting buffer funcs in sdma442 [+ + +]
Author: Le Ma <[email protected]>
Date:   Fri Mar 15 16:55:39 2024 +0800

    drm/amdgpu: drop setting buffer funcs in sdma442
    
    [ Upstream commit ad550dbe8ae4ba833371a018265c1c3ae88559f0 ]
    
    To fix the entity rq NULL issue. This setting has been moved
    to upper level.
    
    Fixes: b70438004a14 ("drm/amdgpu: move buffer funcs setting up a level")
    Signed-off-by: Le Ma <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix missing break in ATOM_ARG_IMM Case of atom_get_src_int() [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Sat Feb 24 07:48:52 2024 +0530

    drm/amdgpu: Fix missing break in ATOM_ARG_IMM Case of atom_get_src_int()
    
    [ Upstream commit 7cf1ad2fe10634238b38442a851d89514cb14ea2 ]
    
    Missing break statement in the ATOM_ARG_IMM case of a switch statement,
    adds the missing break statement, ensuring that the program's control
    flow is as intended.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/atom.c:323 atom_get_src_int() warn: ignoring unreachable code.
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Cc: Jammy Zhou <[email protected]>
    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: Sasha Levin <[email protected]>

drm/amdgpu: fix mmhub client id out-of-bounds access [+ + +]
Author: Lang Yu <[email protected]>
Date:   Wed Mar 6 12:42:49 2024 +0800

    drm/amdgpu: fix mmhub client id out-of-bounds access
    
    [ Upstream commit 6540ff6482c1a5a6890ae44b23d0852ba1986d9e ]
    
    Properly handle cid 0x140.
    
    Fixes: aba2be41470a ("drm/amdgpu: add mmhub 3.3.0 support")
    Signed-off-by: Lang Yu <[email protected]>
    Reviewed-by: Yifan Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()' [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Feb 1 22:47:15 2024 +0530

    drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'
    
    [ Upstream commit cdb637d339572398821204a1142d8d615668f1e9 ]
    
    The issue arises when the array 'adev->vcn.vcn_config' is accessed
    before checking if the index 'adev->vcn.num_vcn_inst' is within the
    bounds of the array.
    
    The fix involves moving the bounds check before the array access. This
    ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array
    before it is used as an index.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use.
    
    Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances")
    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: Sasha Levin <[email protected]>

 
drm/bridge: adv7511: fix crash on irq during probe [+ + +]
Author: Mads Bligaard Nielsen <[email protected]>
Date:   Mon Feb 19 21:21:47 2024 +0100

    drm/bridge: adv7511: fix crash on irq during probe
    
    [ Upstream commit aeedaee5ef5468caf59e2bb1265c2116e0c9a924 ]
    
    Moved IRQ registration down to end of adv7511_probe().
    
    If an IRQ already is pending during adv7511_probe
    (before adv7511_cec_init) then cec_received_msg_ts
    could crash using uninitialized data:
    
        Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
        Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
        Call trace:
         cec_received_msg_ts+0x48/0x990 [cec]
         adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
         adv7511_irq_process+0xd8/0x120 [adv7511]
         adv7511_irq_handler+0x1c/0x30 [adv7511]
         irq_thread_fn+0x30/0xa0
         irq_thread+0x14c/0x238
         kthread+0x190/0x1a8
    
    Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
    Signed-off-by: Mads Bligaard Nielsen <[email protected]>
    Signed-off-by: Alvin Šipraga <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240219-adv7511-cec-irq-crash-fix-v2-1-245e53c4b96f@bang-olufsen.dk
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/lima: fix a memleak in lima_heap_alloc [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Wed Jan 17 15:13:28 2024 +0800

    drm/lima: fix a memleak in lima_heap_alloc
    
    [ Upstream commit 04ae3eb470e52a3c41babe85ff8cee195e4dcbea ]
    
    When lima_vm_map_bo fails, the resources need to be deallocated, or
    there will be memleaks.
    
    Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Qiang Yu <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mediatek: dsi: Fix DSI RGB666 formats and definitions [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Feb 15 09:53:09 2024 +0100

    drm/mediatek: dsi: Fix DSI RGB666 formats and definitions
    
    [ Upstream commit fae6f815505301b92d9113764f4d76d0bfe45607 ]
    
    The register bits definitions for RGB666 formats are wrong in multiple
    ways: first, in the DSI_PS_SEL bits region, the Packed 18-bits RGB666
    format is selected with bit 1, while the Loosely Packed one is bit 2,
    and second - the definition name "LOOSELY_PS_18BIT_RGB666" is wrong
    because the loosely packed format is 24 bits instead!
    
    Either way, functions mtk_dsi_ps_control_vact() and mtk_dsi_ps_control()
    do not even agree on the DSI_PS_SEL bit to set in DSI_PSCTRL: one sets
    loosely packed (24) on RGB666, the other sets packed (18), and the other
    way around for RGB666_PACKED.
    
    Fixing this entire stack of issues is done in one go:
     - Use the correct bit for the Loosely Packed RGB666 definition
     - Rename LOOSELY_PS_18BIT_RGB666 to LOOSELY_PS_24BIT_RGB666
     - Change ps_bpp_mode in mtk_dsi_ps_control_vact() to set:
        - Loosely Packed, 24-bits for MIPI_DSI_FMT_RGB666
        - Packed, 18-bits for MIPI_DSI_FMT_RGB666_PACKED
    
    Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
    Reviewed-by: Alexandre Mergnat <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip [+ + +]
Author: Hsin-Yi Wang <[email protected]>
Date:   Fri Feb 23 13:23:29 2024 -0800

    drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
    
    [ Upstream commit c958e86e9cc1b48cac004a6e245154dfba8e163b ]
    
    It's possible that mtk_crtc->event is NULL in
    mtk_drm_crtc_finish_page_flip().
    
    pending_needs_vblank value is set by mtk_crtc->event, but in
    mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
    lock in mtk_drm_finish_page_flip(), thus a race condition happens.
    
    Consider the following case:
    
    CPU1                              CPU2
    step 1:
    mtk_drm_crtc_atomic_begin()
    mtk_crtc->event is not null,
                                      step 1:
                                      mtk_drm_crtc_atomic_flush:
                                      mtk_drm_crtc_update_config(
                                          !!mtk_crtc->event)
    step 2:
    mtk_crtc_ddp_irq ->
    mtk_drm_finish_page_flip:
    lock
    mtk_crtc->event set to null,
    pending_needs_vblank set to false
    unlock
                                      pending_needs_vblank set to true,
    
                                      step 2:
                                      mtk_crtc_ddp_irq ->
                                      mtk_drm_finish_page_flip called again,
                                      pending_needs_vblank is still true
                                      //null pointer
    
    Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
    efficient to just check if mtk_crtc->event is null before use.
    
    Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
    Signed-off-by: Hsin-Yi Wang <[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: Sasha Levin <[email protected]>

 
drm/msm/a6xx: specify UBWC config for sc7180 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Tue Feb 20 19:12:10 2024 +0200

    drm/msm/a6xx: specify UBWC config for sc7180
    
    [ Upstream commit 0d7dfc79fb9b4b81f642f84796111f2bae8427e2 ]
    
    Historically the Adreno driver has not been updating memory
    configuration registers on a618 (SC7180 platform) implying that the
    default configuration is fine. After the rework performed in the commit
    8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function
    a6xx_calc_ubwc_config() still contained this shortcut and did not
    calculate UBWC configuration. However the function which now actually
    updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such
    check.
    
    Rather than adding the check to a6xx_set_ubwc_config(), fill in the
    UBWC config for a618 (based on readings from SC7180).
    
    Reported-by: Leonard Lausen <[email protected]>
    Link: https://gitlab.freedesktop.org/drm/msm/-/issues/49
    Fixes: 8814455a0e54 ("drm/msm: Refactor UBWC config setting")
    Cc: Connor Abbott <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Connor Abbott <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/579113/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/a7xx: Fix LLC typo [+ + +]
Author: Rob Clark <[email protected]>
Date:   Tue Jan 2 11:33:45 2024 -0800

    drm/msm/a7xx: Fix LLC typo
    
    [ Upstream commit 0776ad9274d96d132131af66a5941df45b9d46b4 ]
    
    We'd miss actually activating LLC.
    
    Signed-off-by: Rob Clark <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
    Patchwork: https://patchwork.freedesktop.org/patch/573043/
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dpu: add division of drm_display_mode's hskew parameter [+ + +]
Author: Paloma Arellano <[email protected]>
Date:   Thu Feb 22 11:39:47 2024 -0800

    drm/msm/dpu: add division of drm_display_mode's hskew parameter
    
    [ Upstream commit 551ee0f210991d25f336bc27262353bfe99d3eed ]
    
    Setting up the timing engine when the physical encoder has a split role
    neglects dividing the drm_display_mode's hskew parameter. Let's fix this
    since this must also be done in preparation for implementing YUV420 over
    DP.
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Paloma Arellano <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/579605/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: allow certain formats for CDM for DP [+ + +]
Author: Paloma Arellano <[email protected]>
Date:   Thu Feb 22 11:39:46 2024 -0800

    drm/msm/dpu: allow certain formats for CDM for DP
    
    [ Upstream commit 32b6ff95b91240e632f55be35c6ccd4bbe7434e4 ]
    
    CDM block supports formats other than H1V2 for DP. Since we are now
    adding support for CDM over DP, relax the checks to allow all other
    formats for DP other than H1V2.
    
    Changes in v2:
            - Add fixes tag
            - Move patch to top of series
    
    Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block")
    Signed-off-by: Paloma Arellano <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/579606/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: finalise global state object [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Dec 3 03:05:29 2023 +0300

    drm/msm/dpu: finalise global state object
    
    [ Upstream commit 49e27d3c9cd67fd5851f8b5518645b9bf3d2c6c0 ]
    
    Add calls to finalise global state object and corresponding lock.
    
    Fixes: de3916c70a24 ("drm/msm/dpu: Track resources in global state")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/570175/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: fix the programming of INTF_CFG2_DATA_HCTL_EN [+ + +]
Author: Abhinav Kumar <[email protected]>
Date:   Wed Jan 31 16:47:36 2024 -0800

    drm/msm/dpu: fix the programming of INTF_CFG2_DATA_HCTL_EN
    
    [ Upstream commit 2f4a67a3894e15c135125cb54edc5b43abc1b70e ]
    
    Currently INTF_CFG2_DATA_HCTL_EN is coupled with the enablement
    of widebus but this is incorrect because we should be enabling
    this bit independent of widebus except for cases where compression
    is enabled in one pixel per clock mode.
    
    Fix this by making the condition checks more explicit and enabling
    INTF_CFG2_DATA_HCTL_EN for all other cases when supported by DPU.
    
    Fixes: 3309a7563971 ("drm/msm/dpu: revise timing engine programming to support widebus feature")
    Suggested-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Abhinav Kumar <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/576722/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: Only enable DSC_MODE_MULTIPLEX if dsc_merge is enabled [+ + +]
Author: Marijn Suijten <[email protected]>
Date:   Sun Feb 4 18:45:27 2024 +0100

    drm/msm/dpu: Only enable DSC_MODE_MULTIPLEX if dsc_merge is enabled
    
    [ Upstream commit 06267d22f9ee6fd34150b6dcdb2fa6983e1a85bc ]
    
    When the topology calls for two interfaces on the current fixed topology
    of 2 DSC blocks, or uses 1 DSC block for a single interface (e.g. SC7280
    with only one DSC block), there should be no merging of DSC output.
    
    This is already represented by the return value of
    dpu_encoder_use_dsc_merge(), but not yet used to correctly configure
    this flag.
    
    Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
    Signed-off-by: Marijn Suijten <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/577067/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel-edp: use put_sync in unprepare [+ + +]
Author: Hsin-Yi Wang <[email protected]>
Date:   Wed Dec 20 14:13:11 2023 -0800

    drm/panel-edp: use put_sync in unprepare
    
    [ Upstream commit 49ddab089611ae5ddd0201ddbbf633da75bfcc25 ]
    
    Some edp panel requires T10 (Delay from end of valid video data transmitted
    by the Source device to power-off) less than 500ms. Using autosuspend with
    delay set as 1000 violates this requirement.
    
    Use put_sync_suspend in unprepare to meet the spec. For other cases (such
    as getting EDID), it still uses autosuspend.
    
    Suggested-by: Douglas Anderson <[email protected]>
    Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare")
    Signed-off-by: Hsin-Yi Wang <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: boe-tv101wum-nl6: make use of prepare_prev_first [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Feb 16 12:31:12 2024 -0800

    drm/panel: boe-tv101wum-nl6: make use of prepare_prev_first
    
    [ Upstream commit 42a7a16bedc991190310a02dd202e29cfac52525 ]
    
    The panel on sc7180-trogdor-wormdingler and
    sc7180-trogdor-quackingstick hasn't been coming up since commit
    9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
    at modeset"). Let's add "prepare_prev_first" as has been done for many
    other DSI panels.
    
    Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset")
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Jessica Zhang <[email protected]>
    Link: https://lore.kernel.org/r/20240216123111.1.I71c103720909790e1ec5a3f5bd96b18ab7b596fa@changeid
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240216123111.1.I71c103720909790e1ec5a3f5bd96b18ab7b596fa@changeid
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/ni: Fix wrong firmware size logging in ni_init_microcode() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Feb 6 08:48:14 2024 -0800

    drm/radeon/ni: Fix wrong firmware size logging in ni_init_microcode()
    
    [ Upstream commit c4891d979c7668b195a0a75787967ec95a24ecef ]
    
    Clean up a typo in pr_err() erroneously printing NI MC 'rdev->mc_fw->size'
    during SMC firmware load. Log 'rdev->smc_fw->size' instead.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 6596afd48af4 ("drm/radeon/kms: add dpm support for btc (v3)")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: inno_hdmi: Fix video timing [+ + +]
Author: Alex Bee <[email protected]>
Date:   Fri Dec 22 18:41:54 2023 +0100

    drm/rockchip: inno_hdmi: Fix video timing
    
    [ Upstream commit 47a145c03484d33e65d773169d5ca1b9fe2a492e ]
    
    The controller wants the difference between *total and *sync_start in the
    HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
    certain non-VIC modes. See downstream commit [0].
    
    [0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c
    
    Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
    Co-developed-by: Zheng Yang <[email protected]>
    Signed-off-by: Zheng Yang <[email protected]>
    Signed-off-by: Alex Bee <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/rockchip: lvds: do not overwrite error code [+ + +]
Author: Quentin Schulz <[email protected]>
Date:   Mon Nov 20 13:29:48 2023 +0100

    drm/rockchip: lvds: do not overwrite error code
    
    [ Upstream commit 79b09453c4e369ca81cfb670d0136d089e3b92f0 ]
    
    ret variable stores the return value of drm_of_find_panel_or_bridge
    which can return error codes different from EPROBE_DEFER. Therefore,
    let's just return that error code instead of forcing it to EPROBE_DEFER.
    
    Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
    Cc: Quentin Schulz <[email protected]>
    Signed-off-by: Quentin Schulz <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-1-9c59a5779cf9@theobroma-systems.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/rockchip: lvds: do not print scary message when probing defer [+ + +]
Author: Quentin Schulz <[email protected]>
Date:   Mon Nov 20 13:29:49 2023 +0100

    drm/rockchip: lvds: do not print scary message when probing defer
    
    [ Upstream commit 52d11c863ac92e36a0365249f7f6d27ac48c78bc ]
    
    This scary message can misled the user into thinking something bad has
    happened and needs to be fixed, however it could simply be part of a
    normal boot process where EPROBE_DEFER is taken into account. Therefore,
    let's use dev_err_probe so that this message doesn't get shown (by
    default) when the return code is EPROBE_DEFER.
    
    Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
    Cc: Quentin Schulz <[email protected]>
    Signed-off-by: Quentin Schulz <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-2-9c59a5779cf9@theobroma-systems.com
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tegra: dpaux: Fix PM disable depth imbalance in tegra_dpaux_probe [+ + +]
Author: Zhang Shurong <[email protected]>
Date:   Wed Oct 4 22:10:55 2023 +0800

    drm/tegra: dpaux: Fix PM disable depth imbalance in tegra_dpaux_probe
    
    [ Upstream commit 0800880f4eb789b7d299db40f2e86e056bd33a4e ]
    
    The pm_runtime_enable function increases the power disable depth,
    which means that we must perform a matching decrement on the error
    handling path to maintain balance within the given context.
    Additionally, we need to address the same issue for pm_runtime_get_sync.
    We fix this by invoking pm_runtime_disable and pm_runtime_put_sync
    when error returns.
    
    Fixes: 82b81b3ec1a7 ("drm/tegra: dpaux: Implement runtime PM")
    Signed-off-by: Zhang Shurong <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: dsi: Add missing check for of_find_device_by_node [+ + +]
Author: Chen Ni <[email protected]>
Date:   Tue Oct 24 08:07:38 2023 +0000

    drm/tegra: dsi: Add missing check for of_find_device_by_node
    
    [ Upstream commit afe6fcb9775882230cd29b529203eabd5d2a638d ]
    
    Add check for the return value of of_find_device_by_node() and return
    the error if it fails in order to avoid NULL pointer dereference.
    
    Fixes: e94236cde4d5 ("drm/tegra: dsi: Add ganged mode support")
    Signed-off-by: Chen Ni <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: dsi: Fix missing pm_runtime_disable() in the error handling path of tegra_dsi_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:09 2023 +0200

    drm/tegra: dsi: Fix missing pm_runtime_disable() in the error handling path of tegra_dsi_probe()
    
    [ Upstream commit 5286a9fc280c45b6b307ee1b07f7a997e042252c ]
    
    If an error occurs after calling pm_runtime_enable(), pm_runtime_disable()
    should be called as already done in the remove function.
    
    Fixes: ef8187d75265 ("drm/tegra: dsi: Implement runtime PM")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/ee4a15c9cd4b574a55cd67c30d2411239ba2cee9.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: dsi: Fix some error handling paths in tegra_dsi_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:08 2023 +0200

    drm/tegra: dsi: Fix some error handling paths in tegra_dsi_probe()
    
    [ Upstream commit 830c1ded356369cd1303e8bb87ce3fea6e744de8 ]
    
    If an error occurs after calling tegra_output_probe(),
    tegra_output_remove() should be called as already done in the remove
    function.
    
    Fixes: dec727399a4b ("drm/tegra: Add DSI support")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/16820073278d031f6c474a08d5f22a255158585e.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: hdmi: Fix some error handling paths in tegra_hdmi_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:10 2023 +0200

    drm/tegra: hdmi: Fix some error handling paths in tegra_hdmi_probe()
    
    [ Upstream commit 643ae131b8598fb2940c92c7d23fe62823a119c8 ]
    
    If an error occurs after calling tegra_output_probe(),
    tegra_output_remove() should be called as already done in the remove
    function.
    
    Fixes: 59d29c0ec93f ("drm/tegra: Allocate resources at probe time")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/9b7c564eb71977678b20abd73ee52001a51cf327.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: output: Fix missing i2c_put_adapter() in the error handling paths of tegra_output_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:13 2023 +0200

    drm/tegra: output: Fix missing i2c_put_adapter() in the error handling paths of tegra_output_probe()
    
    [ Upstream commit 2db4578ef6ffb2b52115ca0ebf897b60ec559556 ]
    
    If an error occurs after a successful of_get_i2c_adapter_by_node() call, it
    should be undone by a corresponding i2c_put_adapter().
    
    Add the missing i2c_put_adapter() call.
    
    Fixes: 9be7d864cf07 ("drm/tegra: Implement panel support")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/b38604178991e1f08b2cda219103be266be2d680.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: put drm_gem_object ref on error in tegra_fb_create [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Fri Dec 15 12:33:55 2023 +0300

    drm/tegra: put drm_gem_object ref on error in tegra_fb_create
    
    [ Upstream commit 32e5a120a5105bce01561978ee55aee8e40ac0dc ]
    
    Inside tegra_fb_create(), drm_gem_object_lookup() increments ref count of
    the found object. But if the following size check fails then the last
    found object's ref count should be put there as the unreferencing loop
    can't detect this situation.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: de2ba664c30f ("gpu: host1x: drm: Add memory manager and fb")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:12 2023 +0200

    drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe()
    
    [ Upstream commit 45c8034db47842b25a3ab6139d71e13b4e67b9b3 ]
    
    If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be
    undone.
    
    Add the missing clk_put and a new 'put_pll_d_out0' label in the error
    handling path, and use it.
    
    Fixes: 0c921b6d4ba0 ("drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/0182895ead4e4730426616b0d9995954c960b634.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

drm/tegra: rgb: Fix some error handling paths in tegra_dc_rgb_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:11 2023 +0200

    drm/tegra: rgb: Fix some error handling paths in tegra_dc_rgb_probe()
    
    [ Upstream commit bc456b5d93dbfdbd89f2a036f4f3d8026595f9e4 ]
    
    If an error occurs after calling tegra_output_probe(),
    tegra_output_remove() should be called as already done in the remove
    function.
    
    Fixes: 59d29c0ec93f ("drm/tegra: Allocate resources at probe time")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/0001f61eb89048bc36241629b564195689cf54b6.1693667005.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tests: helpers: Include missing drm_drv header [+ + +]
Author: Maxime Ripard <[email protected]>
Date:   Thu Feb 22 19:13:47 2024 +0100

    drm/tests: helpers: Include missing drm_drv header
    
    [ Upstream commit 73984daf07a1a89ace8f0db6dd2d640654ebbbee ]
    
    We have a few functions declared in our kunit helpers header, some of
    them dereferencing the struct drm_driver.
    
    However, we don't include the drm_drv.h header file defining that
    structure, leading to compilation errors if we don't include both
    headers.
    
    Fixes: d98780310719 ("drm/tests: helpers: Allow to pass a custom drm_driver")
    Reviewed-by: Maíra Canal <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tidss: Fix initial plane zpos values [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Tue Feb 13 10:16:36 2024 +0200

    drm/tidss: Fix initial plane zpos values
    
    [ Upstream commit 3ec948ccb2c4b99e8fbfdd950adbe92ea577b395 ]
    
    When the driver sets up the zpos property it sets the default zpos value
    to the HW id of the plane. That is fine as such, but as on many DSS
    versions the driver arranges the DRM planes in a different order than
    the HW planes (to keep the non-scalable planes first), this leads to odd
    initial zpos values. An example is J721e, where the initial zpos values
    for DRM planes are 1, 3, 0, 2.
    
    In theory the userspace should configure the zpos values properly when
    using multiple planes, and in that sense the initial zpos values
    shouldn't matter, but there's really no reason not to fix this and help
    the userspace apps which don't handle zpos perfectly. In particular,
    some versions of Weston seem to have issues dealing with the planes
    with the current default zpos values.
    
    So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
    
    Another option would be to configure the planes marked as primary planes
    to zpos 0. On a two display system this would give us plane zpos values
    of 0, 0, 1, 2. The end result and behavior would be very similar in this
    option, and I'm not aware that this would actually help us in any way.
    So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
    
    Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/tidss: Fix sync-lost issue with two displays [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Tue Feb 13 10:16:37 2024 +0200

    drm/tidss: Fix sync-lost issue with two displays
    
    [ Upstream commit c079e2e113f2ec2803ba859bbb442a6ab82c96bd ]
    
    A sync lost issue can be observed with two displays, when moving a plane
    from one disabled display to an another disabled display, and then
    enabling the display to which the plane was moved to. The exact
    requirements for this to trigger are not clear.
    
    It looks like the issue is that the layers are left enabled in the first
    display's OVR registers. Even if the corresponding VP is disabled, it
    still causes an issue, as if the disabled VP and its OVR would still be
    in use, leading to the same VID being used by two OVRs. However, this is
    just speculation based on testing the DSS behavior.
    
    Experimentation shows that as a workaround, we can disable all the
    layers in the OVR when disabling a VP. There should be no downside to
    this, as the OVR is anyway effectively disabled if its VP is disabled,
    and it seems to solve the sync lost issue.
    
    However, there may be a bigger issue in play here, related to J721e
    erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
    in Synclost During the Next Frame"). Experimentation also shows that the
    OVR's CHANNELIN field has similar issue. So we may need to revisit this
    when we find out more about the core issue.
    
    Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vkms: Avoid reading beyond LUT array [+ + +]
Author: Harry Wentland <[email protected]>
Date:   Wed Nov 8 11:36:24 2023 -0500

    drm/vkms: Avoid reading beyond LUT array
    
    [ Upstream commit 2fee84030d12d9fddfa874e4562d71761a129277 ]
    
    When the floor LUT index (drm_fixp2int(lut_index) is the last
    index of the array the ceil LUT index will point to an entry
    beyond the array. Make sure we guard against it and use the
    value of the floor LUT index.
    
    v3:
     - Drop bits from commit description that didn't contribute
       anything of value
    
    Fixes: db1f254f2cfa ("drm/vkms: Add support to 1D gamma LUT")
    Signed-off-by: Harry Wentland <[email protected]>
    Cc: Arthur Grillo <[email protected]>
    Reviewed-by: Arthur Grillo <[email protected]>
    Reviewed-by: Melissa Wen <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Mon Dec 4 17:14:16 2023 +0800

    drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node
    
    [ Upstream commit 89709105a6091948ffb6ec2427954cbfe45358ce ]
    
    When ida_alloc_max fails, resources allocated before should be freed,
    including *res allocated by kmalloc and ttm_resource_init.
    
    Fixes: d3bcb4b02fe9 ("drm/vmwgfx: switch the TTM backends to self alloc")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/vmwgfx: Fix vmw_du_get_cursor_mob fencing of newly-created MOBs [+ + +]
Author: Martin Krastev <[email protected]>
Date:   Fri Jan 26 15:08:03 2024 -0500

    drm/vmwgfx: Fix vmw_du_get_cursor_mob fencing of newly-created MOBs
    
    [ Upstream commit ed96cf7ad590989b009d6da5cd26387d995dac13 ]
    
    The fencing of MOB creation used in vmw_du_get_cursor_mob was incompatible
    with register-based device communication employed by this routine. As a
    result cursor MOB creation was racy, leading to potentially broken/missing
    mouse cursor on desktops using CursorMob device feature.
    
    Fixes: 53bc3f6fb6b3 ("drm/vmwgfx: Clean up cursor mobs")
    Signed-off-by: Martin Krastev <[email protected]>
    Reviewed-by: Maaz Mombasawala <[email protected]>
    Reviewed-by: Zack Rusin <[email protected]>
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/xe/tests: Fix printf format specifiers in xe_migrate test [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:21 2024 +0800

    drm/xe/tests: Fix printf format specifiers in xe_migrate test
    
    [ Upstream commit 689a930b93c5c20294df5da0407df361c5412eac ]
    
    KUNIT_FAIL() is used to fail the xe_migrate test when an error occurs.
    However, there's a mismatch in the format specifier: '%li' is used to
    log 'err', which is an 'int'.
    
    Use '%i' instead of '%li', and for the case where we're printing an
    error pointer, just use '%pe', instead of extracting the error code
    manually with PTR_ERR(). (This also results in a nicer output when the
    error code is known.)
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Acked-by: Thomas Hellström <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/xe: Fix ref counting leak on page fault [+ + +]
Author: Matthew Brost <[email protected]>
Date:   Thu Feb 29 20:10:36 2024 -0800

    drm/xe: Fix ref counting leak on page fault
    
    [ Upstream commit f7da398935f7ddabf1a098714593e032c875cd74 ]
    
    If a page fault occurs on VM not in fault a ref can be leaked. Fix this.
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Signed-off-by: Matthew Brost <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 27b5a3f237fe66dbf2288c2b50973aee8a427e41)
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/xe: Invalidate userptr VMA on page pin fault [+ + +]
Author: Matthew Brost <[email protected]>
Date:   Tue Mar 12 11:39:07 2024 -0700

    drm/xe: Invalidate userptr VMA on page pin fault
    
    [ Upstream commit 386021394394eccef248dc5eb9c9370240821a8c ]
    
    Rather than return an error to the user or ban the VM when userptr VMA
    page pin fails with -EFAULT, invalidate VMA mappings. This supports the
    UMD use case of freeing userptr while still having bindings.
    
    Now that non-faulting VMs can invalidate VMAs, drop the usm prefix for
    the tile_invalidated member.
    
    v2:
     - Fix build error (CI)
    v3:
     - Don't invalidate VMA if in fault mode, rather kill VM (Thomas)
     - Update commit message with tile_invalidated name chagne (Thomas)
     - Wait VM bookkeep slots with VM resv lock (Thomas)
    v4:
     - Move list_del_init(&userptr.repin_link) after error check (Thomas)
     - Assert not in fault mode (Matthew)
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Signed-off-by: Matthew Brost <[email protected]>
    Reviewed-by: Thomas Hellström <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 521db22a1d70dbc596a07544a738416025b1b63c)
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/xe: Replace 'grouped target' in Makefile with pattern rule [+ + +]
Author: Dafna Hirschfeld <[email protected]>
Date:   Sat Mar 2 17:39:28 2024 +0200

    drm/xe: Replace 'grouped target' in Makefile with pattern rule
    
    [ Upstream commit e62d2e00780b4a465c77d2229837495fcbc480d3 ]
    
    Since 'grouped target' is used only in 'make' 4.3, it should
    be avoided. Replace it with 'multi-target pattern rule' which
    has the same behavior.
    
    Fixes: 9616e74b796c ("drm/xe: Add support for OOB workarounds")
    Signed-off-by: Dafna Hirschfeld <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    [ reword commit message ]
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit 5224ed586ba7f9bba956655a1bfe5b75df7394d4)
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC [+ + +]
Author: José Roberto de Souza <[email protected]>
Date:   Wed Mar 13 10:13:18 2024 -0700

    drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC
    
    [ Upstream commit dd8a07f06dfd946e0eea1a3323d52e7c28a6ed80 ]
    
    Doing a XE_EXEC with num_batch_buffer == 0 makes signals passed as
    argument to be signaled when the last real XE_EXEC is completed.
    But to do that it was first pinning all VMAs in drm_gpuvm_exec_lock(),
    this patch remove this pinning as it is not required.
    
    This change also help Mesa implementing memory over-commiting recovery
    as it needs to unbind not needed VMAs when the whole VM can't fit
    in GPU memory but it can only do the unbiding when the last XE_EXEC
    is completed.
    So with this change Mesa can get the signal it want without getting
    out-of-memory errors.
    
    Fixes: eb9702ad2986 ("drm/xe: Allow num_batch_buffer / num_binds == 0 in IOCTLs")
    Cc: Thomas Hellstrom <[email protected]>
    Co-developed-by: Matthew Brost <[email protected]>
    Signed-off-by: José Roberto de Souza <[email protected]>
    Reviewed-by: Matthew Brost <[email protected]>
    Signed-off-by: Matthew Brost <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 58480c1c912ff8146d067301a0d04cca318b4a66)
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: ci: use clk_ignore_unused for apq8016 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Feb 14 10:37:08 2024 +0200

    drm: ci: use clk_ignore_unused for apq8016
    
    [ Upstream commit aa1267e673fe5307cf00d02add4017d2878598b6 ]
    
    If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
    built-in, the clk_disable_unused congests with the runtime PM handling
    of the DSI PHY for the clk_prepare_lock(). This causes apq8016 runner to
    fail without completing any jobs ([1]). Drop the BM_CMDLINE which
    duplicate the command line from the .baremetal-igt-arm64 clause and
    enforce the clk_ignore_unused kernelarg instead to make apq8016 runner
    work.
    
    [1] https://gitlab.freedesktop.org/drm/msm/-/jobs/54990475
    
    Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Acked-by: Helen Koike <[email protected]>
    Signed-off-by: Helen Koike <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: Don't treat 0 as -1 in drm_fixp2int_ceil [+ + +]
Author: Harry Wentland <[email protected]>
Date:   Wed Nov 8 11:36:20 2023 -0500

    drm: Don't treat 0 as -1 in drm_fixp2int_ceil
    
    [ Upstream commit cf8837d7204481026335461629b84ac7f4538fa5 ]
    
    Unit testing this in VKMS shows that passing 0 into
    this function returns -1, which is highly counter-
    intuitive. Fix it by checking whether the input is
    >= 0 instead of > 0.
    
    Fixes: 64566b5e767f ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil")
    Signed-off-by: Harry Wentland <[email protected]>
    Reviewed-by: Simon Ser <[email protected]>
    Reviewed-by: Melissa Wen <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: Fix drm_fixp2int_round() making it add 0.5 [+ + +]
Author: Arthur Grillo <[email protected]>
Date:   Sat Mar 16 13:25:20 2024 -0300

    drm: Fix drm_fixp2int_round() making it add 0.5
    
    [ Upstream commit 807f96abdf14c80f534c78f2d854c2590963345c ]
    
    As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
    To round a number, you need to add 0.5 to the number and floor that,
    drm_fixp2int_round() is adding 0.0000076. Make it add 0.5.
    
    [1]: https://lore.kernel.org/all/[email protected]/
    
    Fixes: 8b25320887d7 ("drm: Add fixed-point helper to get rounded integer values")
    Suggested-by: Pekka Paalanen <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Reviewed-by: Melissa Wen <[email protected]>
    Signed-off-by: Arthur Grillo <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: tests: Fix invalid printf format specifiers in KUnit tests [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 28 13:27:20 2024 +0800

    drm: tests: Fix invalid printf format specifiers in KUnit tests
    
    [ Upstream commit fc9a615200d48e076af58f4309f507e500ed900d ]
    
    The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
    which was then updated to be an 'unsigned long' to avoid 64-bit
    multiplication division helpers.
    
    However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the
    '%d' or '%llu' format specifiers, the former of which is always wrong,
    and the latter is no longer correct now that ps is no longer a u64. Fix
    these to all use '%lu'.
    
    Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the
    message. gcc and clang warns if a printf format string is empty, so
    give these some more detailed error messages, which should be more
    useful anyway.
    
    Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
    Fixes: fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
    Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
    Reviewed-by: Matthew Auld <[email protected]>
    Acked-by: Christian König <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if condition [+ + +]
Author: Neil Armstrong <[email protected]>
Date:   Fri Feb 16 12:03:49 2024 +0100

    dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if condition
    
    [ Upstream commit dc94d0cc718329a39ea2e986a123421a9203b471 ]
    
    The if condition for the SM8[45]50 GPU SMMU is too large,
    add the other compatible strings to the condition to only
    allow the clocks for the GPU SMMU nodes.
    
    Fixes: 4fff78dc2490 ("dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU")
    Suggested-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/578686/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: msm: qcom, mdss: Include ommited fam-b compatible [+ + +]
Author: Adam Skladowski <[email protected]>
Date:   Sun Jan 21 20:41:01 2024 +0100

    dt-bindings: msm: qcom, mdss: Include ommited fam-b compatible
    
    [ Upstream commit 3b63880de42bd3cb79c2a99949135a8f2441c088 ]
    
    During conversion 28nm-hpm-fam-b compat got lost, add it.
    
    Signed-off-by: Adam Skladowski <[email protected]>
    Fixes: f7d46c5efee2 ("dt-bindings: display/msm: split qcom, mdss bindings")
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/575290/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: fix lockdep false positives on initializing erofs_pseudo_mnt [+ + +]
Author: Baokun Li <[email protected]>
Date:   Thu Mar 7 18:10:18 2024 +0800

    erofs: fix lockdep false positives on initializing erofs_pseudo_mnt
    
    [ Upstream commit 0f28be64d132aaf95d06375c8002ad9ecea69d71 ]
    
    Lockdep reported the following issue when mounting erofs with a domain_id:
    
    ============================================
    WARNING: possible recursive locking detected
    6.8.0-rc7-xfstests #521 Not tainted
    --------------------------------------------
    mount/396 is trying to acquire lock:
    ffff907a8aaaa0e0 (&type->s_umount_key#50/1){+.+.}-{3:3},
                                                    at: alloc_super+0xe3/0x3d0
    
    but task is already holding lock:
    ffff907a8aaa90e0 (&type->s_umount_key#50/1){+.+.}-{3:3},
                                                    at: alloc_super+0xe3/0x3d0
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&type->s_umount_key#50/1);
      lock(&type->s_umount_key#50/1);
    
     *** DEADLOCK ***
    
     May be due to missing lock nesting notation
    
    2 locks held by mount/396:
     #0: ffff907a8aaa90e0 (&type->s_umount_key#50/1){+.+.}-{3:3},
                            at: alloc_super+0xe3/0x3d0
     #1: ffffffffc00e6f28 (erofs_domain_list_lock){+.+.}-{3:3},
                            at: erofs_fscache_register_fs+0x3d/0x270 [erofs]
    
    stack backtrace:
    CPU: 1 PID: 396 Comm: mount Not tainted 6.8.0-rc7-xfstests #521
    Call Trace:
     <TASK>
     dump_stack_lvl+0x64/0xb0
     validate_chain+0x5c4/0xa00
     __lock_acquire+0x6a9/0xd50
     lock_acquire+0xcd/0x2b0
     down_write_nested+0x45/0xd0
     alloc_super+0xe3/0x3d0
     sget_fc+0x62/0x2f0
     vfs_get_super+0x21/0x90
     vfs_get_tree+0x2c/0xf0
     fc_mount+0x12/0x40
     vfs_kern_mount.part.0+0x75/0x90
     kern_mount+0x24/0x40
     erofs_fscache_register_fs+0x1ef/0x270 [erofs]
     erofs_fc_fill_super+0x213/0x380 [erofs]
    
    This is because the file_system_type of both erofs and the pseudo-mount
    point of domain_id is erofs_fs_type, so two successive calls to
    alloc_super() are considered to be using the same lock and trigger the
    warning above.
    
    Therefore add a nodev file_system_type called erofs_anon_fs_type in
    fscache.c to silence this complaint. Because kern_mount() takes a
    pointer to struct file_system_type, not its (string) name. So we don't
    need to call register_filesystem(). In addition, call init_pseudo() in
    erofs_anon_init_fs_context() as suggested by Al Viro, so that we can
    remove erofs_fc_fill_pseudo_super(), erofs_fc_anon_get_tree(), and
    erofs_anon_context_ops.
    
    Suggested-by: Al Viro <[email protected]>
    Fixes: a9849560c55e ("erofs: introduce a pseudo mnt to manage shared cookies")
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-and-tested-by: Jingbo Xu <[email protected]>
    Reviewed-by: Yang Erkun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: check number of blocks in a current section [+ + +]
Author: Jaegeuk Kim <[email protected]>
Date:   Fri Feb 23 12:32:05 2024 -0800

    f2fs: check number of blocks in a current section
    
    [ Upstream commit 7af2df0f67a1469762e59be3726a803882d83f6f ]
    
    In cfd66bb715fd ("f2fs: fix deadloop in foreground GC"), we needed to check
    the number of blocks in a section instead of the segment.
    
    Fixes: cfd66bb715fd ("f2fs: fix deadloop in foreground GC")
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix reserve_cblocks counting error when out of space [+ + +]
Author: Xiuhong Wang <[email protected]>
Date:   Wed Mar 6 11:47:46 2024 +0800

    f2fs: compress: fix reserve_cblocks counting error when out of space
    
    [ Upstream commit 2f6d721e14b69d6e1251f69fa238b48e8374e25f ]
    
    When a file only needs one direct_node, performing the following
    operations will cause the file to be unrepairable:
    
    unisoc # ./f2fs_io compress test.apk
    unisoc #df -h | grep dm-48
    /dev/block/dm-48 112G 112G 1.2M 100% /data
    
    unisoc # ./f2fs_io release_cblocks test.apk
    924
    unisoc # df -h | grep dm-48
    /dev/block/dm-48 112G 112G 4.8M 100% /data
    
    unisoc # dd if=/dev/random of=file4 bs=1M count=3
    3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s
    unisoc # df -h | grep dm-48
    /dev/block/dm-48 112G 112G 1.8M 100% /data
    
    unisoc # ./f2fs_io reserve_cblocks test.apk
    F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
    
    adb reboot
    unisoc # df -h  | grep dm-48
    /dev/block/dm-48             112G 112G   11M 100% /data
    unisoc # ./f2fs_io reserve_cblocks test.apk
    0
    
    This is because the file has only one direct_node. After returning
    to -ENOSPC, reserved_blocks += ret will not be executed. As a result,
    the reserved_blocks at this time is still 0, which is not the real
    number of reserved blocks. Therefore, fsck cannot be set to repair
    the file.
    
    After this patch, the fsck flag will be set to fix this problem.
    
    unisoc # df -h | grep dm-48
    /dev/block/dm-48             112G 112G  1.8M 100% /data
    unisoc # ./f2fs_io reserve_cblocks test.apk
    F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
    
    adb reboot then fsck will be executed
    unisoc # df -h  | grep dm-48
    /dev/block/dm-48             112G 112G   11M 100% /data
    unisoc # ./f2fs_io reserve_cblocks test.apk
    924
    
    Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS")
    Signed-off-by: Xiuhong Wang <[email protected]>
    Signed-off-by: Zhiguo Niu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:30 2024 +0800

    f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode
    
    [ Upstream commit 54607494875edd636aff3c21ace3ad9a7da758a9 ]
    
    In reserve_compress_blocks(), we update blkaddrs of dnode in prior to
    inc_valid_block_count(), it may cause inconsistent status bewteen
    i_blocks and blkaddrs once inc_valid_block_count() fails.
    
    To fix this issue, it needs to reverse their invoking order.
    
    Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS")
    Reviewed-by: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to check compress flag w/ .i_sem lock [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Feb 19 10:28:44 2024 +0800

    f2fs: compress: fix to check compress flag w/ .i_sem lock
    
    [ Upstream commit ea59b12ac69774c08aa95cd5b6100700ea0cce97 ]
    
    It needs to check compress flag w/ .i_sem lock, otherwise, compressed
    inode may be disabled after the check condition, it's not needed to
    set compress option on non-compress inode.
    
    Fixes: e1e8debec656 ("f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to check unreleased compressed cluster [+ + +]
Author: Sheng Yong <[email protected]>
Date:   Sat Jan 13 03:41:29 2024 +0800

    f2fs: compress: fix to check unreleased compressed cluster
    
    [ Upstream commit eb8fbaa53374e0a2d4381190abfe708481517bbb ]
    
    Compressed cluster may not be released due to we can fail in
    release_compress_blocks(), fix to handle reserved compressed
    cluster correctly in reserve_compress_blocks().
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Signed-off-by: Sheng Yong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to check zstd compress level correctly in mount option [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Feb 13 00:08:18 2024 +0800

    f2fs: compress: fix to check zstd compress level correctly in mount option
    
    [ Upstream commit e39602da752cd1d0462e3fa04074146f6f2803f6 ]
    
    f2fs only support to config zstd compress level w/ a positive number due
    to layout design, but since commit e0c1b49f5b67 ("lib: zstd: Upgrade to
    latest upstream zstd version 1.4.10"), zstd supports negative compress
    level, so that zstd_min_clevel() may return a negative number, then w/
    below mount option, .compress_level can be configed w/ a negative number,
    which is not allowed to f2fs, let's add check condition to avoid it.
    
    mount -o compress_algorithm=zstd:4294967295 /dev/sdx /mnt/f2fs
    
    Fixes: 00e120b5e4b5 ("f2fs: assign default compression level")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to cover f2fs_disable_compressed_file() w/ i_sem [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Jan 22 10:23:13 2024 +0800

    f2fs: compress: fix to cover f2fs_disable_compressed_file() w/ i_sem
    
    [ Upstream commit 2f9420d3a94aeebd92db88f00f4f2f1a3bd3f6cf ]
    
    - f2fs_disable_compressed_file
      - check inode_has_data
                                            - f2fs_file_mmap
                                            - mkwrite
                                             - f2fs_get_block_locked
                                             : update metadata in compressed
                                               inode's disk layout
      - fi->i_flags &= ~F2FS_COMPR_FL
      - clear_inode_flag(inode, FI_COMPRESSED_FILE);
    
    we should use i_sem lock to prevent above race case.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to cover normal cluster write with cp_rwsem [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:28 2024 +0800

    f2fs: compress: fix to cover normal cluster write with cp_rwsem
    
    [ Upstream commit fd244524c2cf07b5f4c3fe8abd6a99225c76544b ]
    
    When we overwrite compressed cluster w/ normal cluster, we should
    not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data
    will be corrupted if partial blocks were persisted before CP & SPOR,
    due to cluster metadata wasn't updated atomically.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Reviewed-by: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to guarantee persisting compressed blocks by CP [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:27 2024 +0800

    f2fs: compress: fix to guarantee persisting compressed blocks by CP
    
    [ Upstream commit 8a430dd49e9cb021372b0ad91e60aeef9c6ced00 ]
    
    If data block in compressed cluster is not persisted with metadata
    during checkpoint, after SPOR, the data may be corrupted, let's
    guarantee to write compressed page by checkpoint.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Reviewed-by: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: relocate some judgments in f2fs_reserve_compress_blocks [+ + +]
Author: Xiuhong Wang <[email protected]>
Date:   Wed Mar 6 11:47:45 2024 +0800

    f2fs: compress: relocate some judgments in f2fs_reserve_compress_blocks
    
    [ Upstream commit b7d797d241c154d73ec5523f87f3b06d4f299da1 ]
    
    The following f2fs_io test will get a "0" result instead of -EINVAL,
    unisoc # ./f2fs_io compress file
    unisoc # ./f2fs_io reserve_cblocks file
     0
    it's not reasonable, so the judgement of
    atomic_read(&F2FS_I(inode)->i_compr_blocks) should be placed after
    the judgement of is_inode_flag_set(inode, FI_COMPRESS_RELEASED).
    
    Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS")
    Signed-off-by: Xiuhong Wang <[email protected]>
    Signed-off-by: Zhiguo Niu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix NULL pointer dereference in f2fs_submit_page_write() [+ + +]
Author: Wenjie Qi <[email protected]>
Date:   Tue Jan 16 22:11:38 2024 +0800

    f2fs: fix NULL pointer dereference in f2fs_submit_page_write()
    
    [ Upstream commit c2034ef6192a65a986a45c2aa2ed05824fdc0e9f ]
    
    BUG: kernel NULL pointer dereference, address: 0000000000000014
    RIP: 0010:f2fs_submit_page_write+0x6cf/0x780 [f2fs]
    Call Trace:
    <TASK>
    ? show_regs+0x6e/0x80
    ? __die+0x29/0x70
    ? page_fault_oops+0x154/0x4a0
    ? prb_read_valid+0x20/0x30
    ? __irq_work_queue_local+0x39/0xd0
    ? irq_work_queue+0x36/0x70
    ? do_user_addr_fault+0x314/0x6c0
    ? exc_page_fault+0x7d/0x190
    ? asm_exc_page_fault+0x2b/0x30
    ? f2fs_submit_page_write+0x6cf/0x780 [f2fs]
    ? f2fs_submit_page_write+0x736/0x780 [f2fs]
    do_write_page+0x50/0x170 [f2fs]
    f2fs_outplace_write_data+0x61/0xb0 [f2fs]
    f2fs_do_write_data_page+0x3f8/0x660 [f2fs]
    f2fs_write_single_data_page+0x5bb/0x7a0 [f2fs]
    f2fs_write_cache_pages+0x3da/0xbe0 [f2fs]
    ...
    It is possible that other threads have added this fio to io->bio
    and submitted the io->bio before entering f2fs_submit_page_write().
    At this point io->bio = NULL.
    If is_end_zone_blkaddr(sbi, fio->new_blkaddr) of this fio is true,
    then an NULL pointer dereference error occurs at bio_get(io->bio).
    The original code for determining zone end was after "out:",
    which would have missed some fio who is zone end. I've moved
     this code before "skip:" to make sure it's done for each fio.
    
    Fixes: e067dc3c6b9c ("f2fs: maintain six open zones for zoned devices")
    Signed-off-by: Wenjie Qi <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid potential panic during recovery [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jan 24 22:49:15 2024 +0800

    f2fs: fix to avoid potential panic during recovery
    
    [ Upstream commit 21ec68234826b1b54ab980a8df6e33c74cfbee58 ]
    
    During recovery, if FAULT_BLOCK is on, it is possible that
    f2fs_reserve_new_block() will return -ENOSPC during recovery,
    then it may trigger panic.
    
    Also, if fault injection rate is 1 and only FAULT_BLOCK fault
    type is on, it may encounter deadloop in loop of block reservation.
    
    Let's change as below to fix these issues:
    - remove bug_on() to avoid panic.
    - limit the loop count of block reservation to avoid potential
    deadloop.
    
    Fixes: 956fa1ddc132 ("f2fs: fix to check return value of f2fs_reserve_new_block()")
    Reported-by: Zhiguo Niu <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Mar 14 10:05:28 2024 +0800

    f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault
    
    [ Upstream commit eb70d5a6c932d9d23f4bb3e7b83782c21ac4b064 ]
    
    syzbot reports a f2fs bug as below:
    
    BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
    Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058
    
    CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x163/0x540 mm/kasan/report.c:488
     kasan_report+0x142/0x170 mm/kasan/report.c:601
     f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
     __do_fault+0x131/0x450 mm/memory.c:4376
     do_shared_fault mm/memory.c:4798 [inline]
     do_fault mm/memory.c:4872 [inline]
     do_pte_missing mm/memory.c:3745 [inline]
     handle_pte_fault mm/memory.c:5144 [inline]
     __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285
     handle_mm_fault+0x27e/0x770 mm/memory.c:5450
     do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]
     handle_page_fault arch/x86/mm/fault.c:1507 [inline]
     exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563
     asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
    
    The root cause is: in f2fs_filemap_fault(), vmf->vma may be not alive after
    filemap_fault(), so it may cause use-after-free issue when accessing
    vmf->vma->vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags
    in separated temporary variable for tracepoint use.
    
    Fixes: 87f3afd366f7 ("f2fs: add tracepoint for f2fs_vm_page_mkwrite()")
    Reported-and-tested-by: [email protected]
    Closes: https://lore.kernel.org/lkml/[email protected]
    Cc: Ed Tsai <[email protected]>
    Suggested-by: Hillf Danton <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to create selinux label during whiteout initialization [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Feb 7 15:05:48 2024 +0800

    f2fs: fix to create selinux label during whiteout initialization
    
    [ Upstream commit 40b2d55e045222dd6de2a54a299f682e0f954b03 ]
    
    #generic/700       - output mismatch (see /media/fstests/results//generic/700.out.bad)
    #    --- tests/generic/700.out  2023-03-28 10:40:42.735529223 +0000
    #    +++ /media/fstests/results//generic/700.out.bad    2024-02-06 04:37:56.000000000 +0000
    #    @@ -1,2 +1,4 @@
    #     QA output created by 700
    #    +/mnt/scratch_f2fs/f1: security.selinux: No such attribute
    #    +/mnt/scratch_f2fs/f2: security.selinux: No such attribute
    #     Silence is golden
    #    ...
    #    (Run 'diff -u /media/fstests/tests/generic/700.out /media/fstests/results//generic/700.out.bad'  to see the entire diff)
    
    HINT: You _MAY_ be missing kernel fix:
          70b589a37e1a xfs: add selinux labels to whiteout inodes
    
    Previously, it missed to create selinux labels during whiteout inode
    initialization, fix this issue.
    
    Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:31 2024 +0800

    f2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic
    
    [ Upstream commit b896e302f79678451a94769ddd9e52e954c64fbb ]
    
    verify_blkaddr() will trigger panic once we inject fault into
    f2fs_is_valid_blkaddr(), fix to remove this unnecessary f2fs_bug_on().
    
    Fixes: 18792e64c86d ("f2fs: support fault injection for f2fs_is_valid_blkaddr()")
    Reviewed-by: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to truncate meta inode pages forcely [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Mar 8 09:08:34 2024 +0800

    f2fs: fix to truncate meta inode pages forcely
    
    [ Upstream commit 9f0c4a46be1fe9b97dbe66d49204c1371e3ece65 ]
    
    Below race case can cause data corruption:
    
    Thread A                                GC thread
                                            - gc_data_segment
                                             - ra_data_block
                                              - locked meta_inode page
    - f2fs_inplace_write_data
     - invalidate_mapping_pages
     : fail to invalidate meta_inode page
       due to lock failure or dirty|writeback
       status
     - f2fs_submit_page_bio
     : write last dirty data to old blkaddr
                                             - move_data_block
                                              - load old data from meta_inode page
                                              - f2fs_submit_page_write
                                              : write old data to new blkaddr
    
    Because invalidate_mapping_pages() will skip invalidating page which
    has unclear status including locked, dirty, writeback and so on, so
    we need to use truncate_inode_pages_range() instead of
    invalidate_mapping_pages() to make sure meta_inode page will be dropped.
    
    Fixes: 6aa58d8ad20a ("f2fs: readahead encrypted block during GC")
    Fixes: e3b49ea36802 ("f2fs: invalidate META_MAPPING before IPU/DIO write")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to use correct segment type in f2fs_allocate_data_block() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sun Feb 25 14:36:28 2024 +0800

    f2fs: fix to use correct segment type in f2fs_allocate_data_block()
    
    [ Upstream commit 7324858237829733dec9c670170df2377c5ca6e2 ]
    
    @type in f2fs_allocate_data_block() indicates log header's type, it
    can be CURSEG_COLD_DATA_PINNED or CURSEG_ALL_DATA_ATGC, rather than
    type of data/node, however IS_DATASEG()/IS_NODESEG() only accept later
    one, fix it.
    
    Fixes: 093749e296e2 ("f2fs: support age threshold based garbage collection")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: ro: compress: fix to avoid caching unaligned extent [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Feb 26 15:35:38 2024 +0800

    f2fs: ro: compress: fix to avoid caching unaligned extent
    
    [ Upstream commit 4b99ecd304290c4ef55666a62c89dfb2dbf0b2cd ]
    
    Mapping info from dump.f2fs:
    i_addr[0x2d] cluster flag               [0xfffffffe : 4294967294]
    i_addr[0x2e]                            [0x   10428 : 66600]
    i_addr[0x2f]                            [0x   10429 : 66601]
    i_addr[0x30]                            [0x   1042a : 66602]
    
    f2fs_io fiemap 37 1 /mnt/f2fs/disk-58390c8c.raw
    
    Previsouly, it missed to align fofs and ofs_in_node to cluster_size,
    result in adding incorrect read extent cache, fix it.
    
    Before:
    f2fs_update_read_extent_tree_range: dev = (253,48), ino = 5, pgofs = 37, len = 4, blkaddr = 66600, c_len = 3
    
    After:
    f2fs_update_read_extent_tree_range: dev = (253,48), ino = 5, pgofs = 36, len = 4, blkaddr = 66600, c_len = 3
    
    Fixes: 94afd6d6e525 ("f2fs: extent cache: support unaligned extent")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: zone: fix to remove pow2 check condition for zoned block device [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Mar 8 11:50:57 2024 +0800

    f2fs: zone: fix to remove pow2 check condition for zoned block device
    
    [ Upstream commit 11bec96afbfbc4679863db55258de440d786821e ]
    
    Commit 2e2c6e9b72ce ("f2fs: remove power-of-two limitation of zoned
    device") missed to remove pow2 check condition in init_blkz_info(),
    fix it.
    
    Fixes: 2e2c6e9b72ce ("f2fs: remove power-of-two limitation of zoned device")
    Signed-off-by: Feng Song <[email protected]>
    Signed-off-by: Yongpeng Yang <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: zone: fix to wait completion of last bio in zone correctly [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Jan 29 19:27:40 2024 +0800

    f2fs: zone: fix to wait completion of last bio in zone correctly
    
    [ Upstream commit 536af8211586af09c5bea1c15ad28ddec5f66a97 ]
    
    It needs to check last zone_pending_bio and wait IO completion before
    traverse next fio in io->io_list, otherwise, bio in next zone may be
    submitted before all IO completion in current zone.
    
    Fixes: e067dc3c6b9c ("f2fs: maintain six open zones for zoned devices")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Daeho Jeong <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev/simplefb: change loglevel when the power domains cannot be parsed [+ + +]
Author: Brian Masney <[email protected]>
Date:   Tue Dec 12 14:57:54 2023 -0500

    fbdev/simplefb: change loglevel when the power domains cannot be parsed
    
    [ Upstream commit 4350aa21cca48a5d951ba108290bad703fbc0630 ]
    
    When the power domains cannot be parsed, the message is incorrectly
    logged as an info message. Let's change this to an error since an error
    is returned.
    
    Fixes: 92a511a568e4 ("fbdev/simplefb: Add support for generic power-domains")
    Signed-off-by: Brian Masney <[email protected]>
    Acked-by: Andrew Halaney <[email protected]>
    Acked-by: Javier Martinez Canillas <[email protected]>
    Acked-by: Thierry Reding <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_scmi: Fix double free in SMC transport cleanup path [+ + +]
Author: Andre Przywara <[email protected]>
Date:   Fri Jan 26 12:23:25 2024 +0000

    firmware: arm_scmi: Fix double free in SMC transport cleanup path
    
    [ Upstream commit f1d71576d2c9ec8fdb822173fa7f3de79475e9bd ]
    
    When the generic SCMI code tears down a channel, it calls the chan_free
    callback function, defined by each transport. Since multiple protocols
    might share the same transport_info member, chan_free() might want to
    clean up the same member multiple times within the given SCMI transport
    implementation. In this case, it is SMC transport. This will lead to a NULL
    pointer dereference at the second time:
    
        | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
        | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
        | arm-scmi firmware:scmi: unable to communicate with SCMI
        | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
        | Mem abort info:
        |   ESR = 0x0000000096000004
        |   EC = 0x25: DABT (current EL), IL = 32 bits
        |   SET = 0, FnV = 0
        |   EA = 0, S1PTW = 0
        |   FSC = 0x04: level 0 translation fault
        | Data abort info:
        |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
        |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
        |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
        | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
        | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
        | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
        | Modules linked in:
        | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
        | Hardware name: FVP Base RevC (DT)
        | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
        | pc : smc_chan_free+0x3c/0x6c
        | lr : smc_chan_free+0x3c/0x6c
        | Call trace:
        |  smc_chan_free+0x3c/0x6c
        |  idr_for_each+0x68/0xf8
        |  scmi_cleanup_channels.isra.0+0x2c/0x58
        |  scmi_probe+0x434/0x734
        |  platform_probe+0x68/0xd8
        |  really_probe+0x110/0x27c
        |  __driver_probe_device+0x78/0x12c
        |  driver_probe_device+0x3c/0x118
        |  __driver_attach+0x74/0x128
        |  bus_for_each_dev+0x78/0xe0
        |  driver_attach+0x24/0x30
        |  bus_add_driver+0xe4/0x1e8
        |  driver_register+0x60/0x128
        |  __platform_driver_register+0x28/0x34
        |  scmi_driver_init+0x84/0xc0
        |  do_one_initcall+0x78/0x33c
        |  kernel_init_freeable+0x2b8/0x51c
        |  kernel_init+0x24/0x130
        |  ret_from_fork+0x10/0x20
        | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
        | ---[ end trace 0000000000000000 ]---
    
    Simply check for the struct pointer being NULL before trying to access
    its members, to avoid this situation.
    
    This was found when a transport doesn't really work (for instance no SMC
    service), the probe routines then tries to clean up, and triggers a crash.
    
    Signed-off-by: Andre Przywara <[email protected]>
    Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport")
    Reviewed-by: Cristian Marussi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sudeep Holla <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/hfsplus: use better @opf description [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Fri Feb 9 21:06:06 2024 -0800

    fs/hfsplus: use better @opf description
    
    [ Upstream commit cf12445daec01aaa2d27bb34bd7c796a53442c42 ]
    
    Use a more descriptive explanation of the @opf function parameter,
    more in line with <linux/blk_types.h>.
    
    Fixes: 02105f18a26c ("fs/hfsplus: wrapper.c: fix kernel-doc warnings")
    Suggested-by: Bart Van Assche <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Cc: Alexander Viro <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/select: rework stack allocation hack for clang [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 16 21:23:34 2024 +0100

    fs/select: rework stack allocation hack for clang
    
    [ Upstream commit ddb9fd7a544088ed70eccbb9f85e9cc9952131c1 ]
    
    A while ago, we changed the way that select() and poll() preallocate
    a temporary buffer just under the size of the static warning limit of
    1024 bytes, as clang was frequently going slightly above that limit.
    
    The warnings have recently returned and I took another look. As it turns
    out, clang is not actually inherently worse at reserving stack space,
    it just happens to inline do_select() into core_sys_select(), while gcc
    never inlines it.
    
    Annotate do_select() to never be inlined and in turn remove the special
    case for the allocation size. This should give the same behavior for
    both clang and gcc all the time and once more avoids those warnings.
    
    Fixes: ad312f95d41c ("fs/select: avoid clang stack usage warning")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Kees Cook <[email protected]>
    Reviewed-by: Andi Kleen <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs: Fix rw_hint validation [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Fri Feb 2 12:39:20 2024 -0800

    fs: Fix rw_hint validation
    
    [ Upstream commit ec16b147a55bfa14e858234eb7b1a7c8e7cd5021 ]
    
    Reject values that are valid rw_hints after truncation but not before
    truncation by passing an untruncated value to rw_hint_valid().
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Kanchan Joshi <[email protected]>
    Cc: Jeff Layton <[email protected]>
    Cc: Chuck Lever <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Stephen Rothwell <[email protected]>
    Fixes: 5657cb0797c4 ("fs/fcntl: use copy_to/from_user() for u64 types")
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpio: nomadik: fix offset bug in nmk_pmx_set() [+ + +]
Author: Théo Lebrun <[email protected]>
Date:   Wed Feb 28 12:28:03 2024 +0100

    gpio: nomadik: fix offset bug in nmk_pmx_set()
    
    [ Upstream commit 53cf6b72e074864b94ade97dcb6f30b5ac1a82dc ]
    
    Previously, the statement looked like:
    
        slpm[x] &= ~BIT(g->grp.pins[i]);
    
    Where:
     - slpm is a unsigned int pointer;
     - g->grp.pins[i] is a pin number. It can grow to more than 32.
    
    The expected shift amount is a pin bank offset.
    
    This bug does not occur on every group or pin: the altsetting must be
    NMK_GPIO_ALT_C and the pin must be 32 or above. It might have occured.
    For example, in pinctrl-nomadik-db8500.c, pin group i2c3_c_2 has the
    right altsetting and pins 229 and 230.
    
    Fixes: dbfe8ca259e1 ("pinctrl/nomadik: implement pin multiplexing")
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Théo Lebrun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gpio: vf610: allow disabling the vf610 driver [+ + +]
Author: Martin Kaiser <[email protected]>
Date:   Wed Jan 24 21:58:57 2024 +0100

    gpio: vf610: allow disabling the vf610 driver
    
    [ Upstream commit f57595788244a838deec2d3be375291327cbc035 ]
    
    The vf610 gpio driver is enabled by default for all i.MX machines,
    without any option to disable it in a board-specific config file.
    
    Most i.MX chipsets have no hardware for this driver. Change the default
    to enable GPIO_VF610 for SOC_VF610 and disable it otherwise.
    
    Add a text description after the bool type, this makes the driver
    selectable by make config etc.
    
    Fixes: 30a35c07d9e9 ("gpio: vf610: drop the SOC_VF610 dependency for GPIO_VF610")
    Signed-off-by: Martin Kaiser <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index() [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Thu Feb 22 22:52:53 2024 -0800

    gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index()
    
    [ Upstream commit 0d776cfd5e5b559fdf2e38285c2aea4b7048acbd ]
    
    This devm API takes a consumer device as an argument to setup the devm
    action, but throws it away when calling further into gpiolib. This leads
    to odd debug messages like this:
    
     (NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
    
    Let's pass the consumer device down, by directly calling what
    fwnode_gpiod_get_index() calls but pass the device used for devm. This
    changes the message to look like this instead:
    
     gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
    
    Note that callers of fwnode_gpiod_get_index() will still see the NULL
    device pointer debug message, but there's not much we can do about that
    because the API doesn't take a struct device.
    
    Cc: Dmitry Torokhov <[email protected]>
    Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups")
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: amd_sfh: Avoid disabling the interrupt [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Wed Feb 14 20:11:42 2024 +0530

    HID: amd_sfh: Avoid disabling the interrupt
    
    [ Upstream commit c1db0073212ef39d5a46c2aea5e49bf884375ce4 ]
    
    HP ProBook x360 435 G7 using older version of firmware which doesn't
    support disabling the interrupt for all commands. Hence avoid disabling
    the interrupt for that particular model.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218104
    Fixes: b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command")
    Co-developed-by: Akshata MukundShetty <[email protected]>
    Signed-off-by: Akshata MukundShetty <[email protected]>
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: amd_sfh: Update HPD sensor structure elements [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Wed Feb 14 20:11:41 2024 +0530

    HID: amd_sfh: Update HPD sensor structure elements
    
    [ Upstream commit bbf0dec30696638b8bdc28cb2f5bf23f8d760b52 ]
    
    HPD sensor data is not populating properly because of wrong order of HPD
    sensor structure elements. So update the order of structure elements to
    match the HPD sensor data received from the firmware.
    
    Fixes: 24a31ea94922 ("HID: amd_sfh: Add initial support for HPD sensor")
    Co-developed-by: Akshata MukundShetty <[email protected]>
    Signed-off-by: Akshata MukundShetty <[email protected]>
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: lenovo: Add middleclick_workaround sysfs knob for cptkbd [+ + +]
Author: Mikhail Khvainitski <[email protected]>
Date:   Sat Dec 23 21:12:13 2023 +0200

    HID: lenovo: Add middleclick_workaround sysfs knob for cptkbd
    
    [ Upstream commit 2814646f76f8518326964f12ff20aaee70ba154d ]
    
    Previous attempt to autodetect well-behaving patched firmware
    introduced in commit 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw
    on cptkbd and stop applying workaround") has shown that there are
    false-positives on original firmware (on both 1st gen and 2nd gen
    keyboards) which causes the middle button click workaround to be
    mistakenly disabled.
    
    This commit adds explicit parameter to sysfs to control this
    workaround.
    
    Fixes: 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround")
    Fixes: 43527a0094c1 ("HID: lenovo: Restrict detection of patched firmware only to USB cptkbd")
    Signed-off-by: Mikhail Khvainitski <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hsr: Fix uninit-value access in hsr_get_node() [+ + +]
Author: Shigeru Yoshida <[email protected]>
Date:   Wed Mar 13 00:27:19 2024 +0900

    hsr: Fix uninit-value access in hsr_get_node()
    
    [ Upstream commit ddbec99f58571301679addbc022256970ca3eac6 ]
    
    KMSAN reported the following uninit-value access issue [1]:
    
    =====================================================
    BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
     hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
     fill_frame_info net/hsr/hsr_forward.c:577 [inline]
     hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
     hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
     __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
     netdev_start_xmit include/linux/netdevice.h:4954 [inline]
     xmit_one net/core/dev.c:3548 [inline]
     dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
     __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
     dev_queue_xmit include/linux/netdevice.h:3134 [inline]
     packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
     packet_snd net/packet/af_packet.c:3087 [inline]
     packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     __sys_sendto+0x735/0xa10 net/socket.c:2191
     __do_sys_sendto net/socket.c:2203 [inline]
     __se_sys_sendto net/socket.c:2199 [inline]
     __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
     slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
     slab_alloc_node mm/slub.c:3478 [inline]
     kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
     kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
     __alloc_skb+0x318/0x740 net/core/skbuff.c:651
     alloc_skb include/linux/skbuff.h:1286 [inline]
     alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
     sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
     packet_alloc_skb net/packet/af_packet.c:2936 [inline]
     packet_snd net/packet/af_packet.c:3030 [inline]
     packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     __sys_sendto+0x735/0xa10 net/socket.c:2191
     __do_sys_sendto net/socket.c:2203 [inline]
     __se_sys_sendto net/socket.c:2199 [inline]
     __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    =====================================================
    
    If the packet type ID field in the Ethernet header is either ETH_P_PRP or
    ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
    reads an invalid value as a sequence number. This causes the above issue.
    
    This patch fixes the issue by returning NULL if the Ethernet header is not
    followed by an HSR tag.
    
    Fixes: f266a683a480 ("net/hsr: Better frame dispatch")
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=2ef3a8ce8e91b5a50098 [1]
    Signed-off-by: Shigeru Yoshida <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hsr: Handle failures in module init [+ + +]
Author: Felix Maurer <[email protected]>
Date:   Fri Mar 15 13:04:52 2024 +0100

    hsr: Handle failures in module init
    
    [ Upstream commit 3cf28cd492308e5f63ed00b29ea03ca016264376 ]
    
    A failure during registration of the netdev notifier was not handled at
    all. A failure during netlink initialization did not unregister the netdev
    notifier.
    
    Handle failures of netdev notifier registration and netlink initialization.
    Both functions should only return negative values on failure and thereby
    lead to the hsr module not being loaded.
    
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Felix Maurer <[email protected]>
    Reviewed-by: Shigeru Yoshida <[email protected]>
    Reviewed-by: Breno Leitao <[email protected]>
    Link: https://lore.kernel.org/r/3ce097c15e3f7ace98fc7fd9bcbf299f092e63d1.1710504184.git.fmaurer@redhat.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwtracing: hisi_ptt: Move type check to the beginning of hisi_ptt_pmu_event_init() [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Mon Jan 8 12:19:06 2024 +0000

    hwtracing: hisi_ptt: Move type check to the beginning of hisi_ptt_pmu_event_init()
    
    [ Upstream commit 06226d120a28f146abd3637799958a4dc4dbb7a1 ]
    
    When perf_init_event() calls perf_try_init_event() to init pmu driver,
    searches for the next pmu driver only when the return value is -ENOENT.
    Therefore, hisi_ptt_pmu_event_init() needs to check the type at the
    beginning of the function.
    Otherwise, in the case of perf-task mode, perf_try_init_event() returns
    -EOPNOTSUPP and skips subsequent pmu drivers, causes perf_init_event() to
    fail.
    
    Fixes: ff0de066b463 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device")
    Signed-off-by: Yang Jihong <[email protected]>
    Reviewed-by: Yicong Yang <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
i3c: dw: Disable IBI IRQ depends on hot-join and SIR enabling [+ + +]
Author: Dylan Hung <[email protected]>
Date:   Fri Jan 19 13:45:47 2024 +0800

    i3c: dw: Disable IBI IRQ depends on hot-join and SIR enabling
    
    [ Upstream commit 10201396ef6455a68ac671fa0163205d327ebb70 ]
    
    Disable IBI IRQ signal and status only when hot-join and SIR enabling of
    all target devices attached to the bus are disabled.
    
    Fixes: e389b1d72a62 ("i3c: dw: Add support for in-band interrupts")
    
    Signed-off-by: Dylan Hung <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: fix stats being updated by way too large values [+ + +]
Author: Przemek Kitszel <[email protected]>
Date:   Tue Feb 27 15:31:06 2024 +0100

    ice: fix stats being updated by way too large values
    
    [ Upstream commit 257310e998700e60382fbd3f4fd275fdbd9b2aaf ]
    
    Simplify stats accumulation logic to fix the case where we don't take
    previous stat value into account, we should always respect it.
    
    Main netdev stats of our PF (Tx/Rx packets/bytes) were reported orders of
    magnitude too big during OpenStack reconfiguration events, possibly other
    reconfiguration cases too.
    
    The regression was reported to be between 6.1 and 6.2, so I was almost
    certain that on of the two "preserve stats over reset" commits were the
    culprit. While reading the code, it was found that in some cases we will
    increase the stats by arbitrarily large number (thanks to ignoring "-prev"
    part of condition, after zeroing it).
    
    Note that this fixes also the case where we were around limits of u64, but
    that was not the regression reported.
    
    Full disclosure: I remember suggesting this particular piece of code to
    Ben a few years ago, so blame on me.
    
    Fixes: 2fd5e433cd26 ("ice: Accumulate HW and Netdev statistics over reset")
    Reported-by: Nebojsa Stevanovic <[email protected]>
    Link: https://lore.kernel.org/intel-wired-lan/VI1PR02MB439744DEDAA7B59B9A2833FE912EA@VI1PR02MB4397.eurprd02.prod.outlook.com
    Reported-by: Christian Rohmann <[email protected]>
    Link: https://lore.kernel.org/intel-wired-lan/[email protected]
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igb: Fix missing time sync events [+ + +]
Author: Vinicius Costa Gomes <[email protected]>
Date:   Tue Feb 20 15:57:11 2024 -0800

    igb: Fix missing time sync events
    
    [ Upstream commit ee14cc9ea19ba9678177e2224a9c58cce5937c73 ]
    
    Fix "double" clearing of interrupts, which can cause external events
    or timestamps to be missed.
    
    The E1000_TSIRC Time Sync Interrupt Cause register can be cleared in two
    ways, by either reading it or by writing '1' into the specific cause
    bit. This is documented in section 8.16.1.
    
    The following flow was used:
        1. read E1000_TSIRC into 'tsicr';
        2. handle the interrupts present into 'tsirc' and mark them in 'ack';
        3. write 'ack' into E1000_TSICR;
    
    As both (1) and (3) will clear the interrupt cause, if the same
    interrupt happens again between (1) and (3) it will be ignored,
    causing events to be missed.
    
    Remove the extra clear in (3).
    
    Fixes: 00c65578b47b ("igb: enable internal PPS for the i210")
    Acked-by: Richard Cochran <[email protected]>
    Signed-off-by: Vinicius Costa Gomes <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igc: Fix missing time sync events [+ + +]
Author: Vinicius Costa Gomes <[email protected]>
Date:   Tue Feb 20 15:57:10 2024 -0800

    igc: Fix missing time sync events
    
    [ Upstream commit 244ae992e3e80e5c9c272c77324c831148457f95 ]
    
    Fix "double" clearing of interrupts, which can cause external events
    or timestamps to be missed.
    
    The IGC_TSIRC Time Sync Interrupt Cause register can be cleared in two
    ways, by either reading it or by writing '1' into the specific cause
    bit. This is documented in section 8.16.1.
    
    The following flow was used:
     1. read IGC_TSIRC into 'tsicr';
     2. handle the interrupts present in 'tsirc' and mark them in 'ack';
     3. write 'ack' into IGC_TSICR;
    
    As both (1) and (3) will clear the interrupt cause, if the same
    interrupt happens again between (1) and (3) it will be ignored,
    causing events to be missed.
    
    Remove the extra clear in (3).
    
    Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
    Reviewed-by: Kurt Kanzenbach <[email protected]>
    Tested-by: Kurt Kanzenbach <[email protected]> # Intel i225
    Signed-off-by: Vinicius Costa Gomes <[email protected]>
    Tested-by: Naama Meir <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: gts-helper: Fix division loop [+ + +]
Author: Matti Vaittinen <[email protected]>
Date:   Mon Feb 12 13:20:09 2024 +0200

    iio: gts-helper: Fix division loop
    
    [ Upstream commit bb76cc45dcdfcd962a5994b8fe19ab74fc6c3c3a ]
    
    The loop based 64bit division may run for a long time when dividend is a
    lot bigger than the divider. Replace the division loop by the
    div64_u64() which implementation may be significantly faster.
    
    Tested-by: Subhajit Ghosh <[email protected]>
    Signed-off-by: Matti Vaittinen <[email protected]>
    Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: pressure: mprls0025pa fix off-by-one enum [+ + +]
Author: Petre Rodan <[email protected]>
Date:   Fri Dec 29 11:24:32 2023 +0200

    iio: pressure: mprls0025pa fix off-by-one enum
    
    [ Upstream commit 9e65506ca9c7ff716c8441a33417820ad61d3a16 ]
    
    Fix off-by-one error in transfer-function property.
    The honeywell,transfer-function property takes values between 1-3 so
    make sure the proper enum gets used.
    
    Fixes: 713337d9143ed ("iio: pressure: Honeywell mprls0025pa pressure sensor")
    Co-developed-by: Andreas Klinger <[email protected]>
    Signed-off-by: Andreas Klinger <[email protected]>
    Signed-off-by: Petre Rodan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
inet_diag: annotate data-races around inet_diag_table[] [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Jan 22 11:25:56 2024 +0000

    inet_diag: annotate data-races around inet_diag_table[]
    
    [ Upstream commit e50e10ae5d81ddb41547114bfdc5edc04422f082 ]
    
    inet_diag_lock_handler() reads inet_diag_table[proto] locklessly.
    
    Use READ_ONCE()/WRITE_ONCE() annotations to avoid potential issues.
    
    Fixes: d523a328fb02 ("[INET]: Fix inet_diag dead-lock regression")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Guillaume Nault <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: iqs7222 - add support for IQS7222D v1.1 and v1.2 [+ + +]
Author: Jeff LaBundy <[email protected]>
Date:   Wed Mar 6 23:40:21 2024 -0600

    Input: iqs7222 - add support for IQS7222D v1.1 and v1.2
    
    [ Upstream commit 992cf65674778e22436807796b2df927de21bb75 ]
    
    The vendor has introduced two new revisions with slightly different
    memory maps; update the driver to support them.
    
    Fixes: dd24e202ac72 ("Input: iqs7222 - add support for Azoteq IQS7222D")
    Signed-off-by: Jeff LaBundy <[email protected]>
    Link: https://lore.kernel.org/r/ZelTRYX3fenMQuhF@nixie71
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/net: correct the type of variable [+ + +]
Author: Muhammad Usama Anjum <[email protected]>
Date:   Fri Mar 1 19:43:48 2024 +0500

    io_uring/net: correct the type of variable
    
    [ Upstream commit 86bcacc957fc2d0403aa0e652757eec59a5fd7ca ]
    
    The namelen is of type int. It shouldn't be made size_t which is
    unsigned. The signed number is needed for error checking before use.
    
    Fixes: c55978024d12 ("io_uring/net: move receive multishot out of the generic msghdr path")
    Signed-off-by: Muhammad Usama Anjum <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/net: fix overflow check in io_recvmsg_mshot_prep() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Mar 1 18:29:39 2024 +0300

    io_uring/net: fix overflow check in io_recvmsg_mshot_prep()
    
    [ Upstream commit 8ede3db5061bb1fe28e2c9683329aafa89d2b1b4 ]
    
    The "controllen" variable is type size_t (unsigned long).  Casting it
    to int could lead to an integer underflow.
    
    The check_add_overflow() function considers the type of the destination
    which is type int.  If we add two positive values and the result cannot
    fit in an integer then that's counted as an overflow.
    
    However, if we cast "controllen" to an int and it turns negative, then
    negative values *can* fit into an int type so there is no overflow.
    
    Good: 100 + (unsigned long)-4 = 96  <-- overflow
     Bad: 100 + (int)-4 = 96 <-- no overflow
    
    I deleted the cast of the sizeof() as well.  That's not a bug but the
    cast is unnecessary.
    
    Fixes: 9b0fc3c054ff ("io_uring: fix types in io_recvmsg_multishot_overflow")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/net: move receive multishot out of the generic msghdr path [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Tue Feb 27 11:09:20 2024 -0700

    io_uring/net: move receive multishot out of the generic msghdr path
    
    [ Upstream commit c55978024d123d43808ab393a0a4ce3ce8568150 ]
    
    Move the actual user_msghdr / compat_msghdr into the send and receive
    sides, respectively, so we can move the uaddr receive handling into its
    own handler, and ditto the multishot with buffer selection logic.
    
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 8ede3db5061b ("io_uring/net: fix overflow check in io_recvmsg_mshot_prep()")
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/net: unify how recvmsg and sendmsg copy in the msghdr [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Feb 19 14:16:47 2024 -0700

    io_uring/net: unify how recvmsg and sendmsg copy in the msghdr
    
    [ Upstream commit 52307ac4f2b507f60bae6df5be938d35e199c688 ]
    
    For recvmsg, we roll our own since we support buffer selections. This
    isn't the case for sendmsg right now, but in preparation for doing so,
    make the recvmsg copy helpers generic so we can call them from the
    sendmsg side as well.
    
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 8ede3db5061b ("io_uring/net: fix overflow check in io_recvmsg_mshot_prep()")
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: don't save/restore iowait state [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Mar 11 13:30:43 2024 -0600

    io_uring: don't save/restore iowait state
    
    [ Upstream commit 6f0974eccbf78baead1735722c4f1ee3eb9422cd ]
    
    This kind of state is per-syscall, and since we're doing the waiting off
    entering the io_uring_enter(2) syscall, there's no way that iowait can
    already be set for this case. Simplify it by setting it if we need to,
    and always clearing it to 0 when done.
    
    Fixes: 7b72d661f1f2 ("io_uring: gate iowait schedule on having pending requests")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring: fix poll_remove stalled req completion [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Fri Mar 15 15:29:51 2024 +0000

    io_uring: fix poll_remove stalled req completion
    
    [ Upstream commit 5e3afe580a9f5ca173a6bd55ffe10948796ef7e5 ]
    
    Taking the ctx lock is not enough to use the deferred request completion
    infrastructure, it'll get queued into the list but no one would expect
    it there, so it will sit there until next io_submit_flush_completions().
    It's hard to care about the cancellation path, so complete it via tw.
    
    Fixes: ef7dfac51d8ed ("io_uring/poll: serialize poll linked timer start with poll removal")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/c446740bc16858f8a2a8dcdce899812f21d15f23.1710514702.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring: Fix release of pinned pages when __io_uaddr_map fails [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Mar 13 17:39:12 2024 -0400

    io_uring: Fix release of pinned pages when __io_uaddr_map fails
    
    [ Upstream commit 67d1189d1095d471ed7fa426c7e384a7140a5dd7 ]
    
    Looking at the error path of __io_uaddr_map, if we fail after pinning
    the pages for any reasons, ret will be set to -EINVAL and the error
    handler won't properly release the pinned pages.
    
    I didn't manage to trigger it without forcing a failure, but it can
    happen in real life when memory is heavily fragmented.
    
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Fixes: 223ef4743164 ("io_uring: don't allow IORING_SETUP_NO_MMAP rings on highmem pages")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring: remove looping around handling traditional task_work [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Tue Jan 30 07:00:47 2024 -0700

    io_uring: remove looping around handling traditional task_work
    
    [ Upstream commit 592b4805432af075468876771c0f7d41273ccb3c ]
    
    A previous commit added looping around handling traditional task_work
    as an optimization, and while that may seem like a good idea, it's also
    possible to run into application starvation doing so. If the task_work
    generation is bursty, we can get very deep task_work queues, and we can
    end up looping in here for a very long time.
    
    One immediately observable problem with that is handling network traffic
    using provided buffers, where flooding incoming traffic and looping
    task_work handling will very quickly lead to buffer starvation as we
    keep running task_work rather than returning to the application so it
    can handle the associated CQEs and also provide buffers back.
    
    Fixes: 3a0c037b0e16 ("io_uring: batch task_work")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring: remove unconditional looping in local task_work handling [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Wed Jan 31 10:50:08 2024 -0700

    io_uring: remove unconditional looping in local task_work handling
    
    [ Upstream commit 9fe3eaea4a3530ca34a8d8ff00b1848c528789ca ]
    
    If we have a ton of notifications coming in, we can be looping in here
    for a long time. This can be problematic for various reasons, mostly
    because we can starve userspace. If the application is waiting on N
    events, then only re-run if we need more events.
    
    Fixes: c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iomap: clear the per-folio dirty bits on all writeback failures [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Thu Dec 7 08:26:57 2023 +0100

    iomap: clear the per-folio dirty bits on all writeback failures
    
    [ Upstream commit 7ea1d9b4a840c2dd01d1234663d4a8ef256cfe39 ]
    
    write_cache_pages always clear the page dirty bit before calling into the
    file systems, and leaves folios with a writeback failure without the
    dirty bit after return.  We also clear the per-block writeback bits for
    writeback failures unless no I/O has submitted, which will leave the
    folio in an inconsistent state where it doesn't have the folio dirty,
    but one or more per-block dirty bits.  This seems to be due the place
    where the iomap_clear_range_dirty call was inserted into the existing
    not very clearly structured code when adding per-block dirty bit support
    and not actually intentional.  Switch to always clearing the dirty on
    writeback failure.
    
    Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/amd: Mark interrupt as managed [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Mon Jan 22 17:34:00 2024 -0600

    iommu/amd: Mark interrupt as managed
    
    [ Upstream commit 0feda94c868d396fac3b3cb14089d2d989a07c72 ]
    
    On many systems that have an AMD IOMMU the following sequence of
    warnings is observed during bootup.
    
    ```
    pci 0000:00:00.2  can't derive routing for PCI INT A
    pci 0000:00:00.2: PCI INT A: not connected
    ```
    
    This series of events happens because of the IOMMU initialization
    sequence order and the lack of _PRT entries for the IOMMU.
    
    During initialization the IOMMU driver first enables the PCI device
    using pci_enable_device().  This will call acpi_pci_irq_enable()
    which will check if the interrupt is declared in a PCI routing table
    (_PRT) entry. According to the PCI spec [1] these routing entries
    are only required under PCI root bridges:
            The _PRT object is required under all PCI root bridges
    
    The IOMMU is directly connected to the root complex, so there is no
    parent bridge to look for a _PRT entry. The first warning is emitted
    since no entry could be found in the hierarchy. The second warning is
    then emitted because the interrupt hasn't yet been configured to any
    value.  The pin was configured in pci_read_irq() but the byte in
    PCI_INTERRUPT_LINE return 0xff which means "Unknown".
    
    After that sequence of events pci_enable_msi() is called and this
    will allocate an interrupt.
    
    That is both of these warnings are totally harmless because the IOMMU
    uses MSI for interrupts.  To avoid even trying to probe for a _PRT
    entry mark the IOMMU as IRQ managed. This avoids both warnings.
    
    Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html?highlight=_prt#prt-pci-routing-table [1]
    Signed-off-by: Mario Limonciello <[email protected]>
    Fixes: cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count")
    Reviewed-by: Vasant Hegde <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected [+ + +]
Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:15 2024 +0800

    iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected
    
    [ Upstream commit 4fc82cd907ac075648789cc3a00877778aa1838b ]
    
    For those endpoint devices connect to system via hotplug capable ports,
    users could request a hot reset to the device by flapping device's link
    through setting the slot's link control register, as pciehp_ist() DLLSC
    interrupt sequence response, pciehp will unload the device driver and
    then power it off. thus cause an IOMMU device-TLB invalidation (Intel
    VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence
    target device to be sent and deadly loop to retry that request after ITE
    fault triggered in interrupt context.
    
    That would cause following continuous hard lockup warning and system hang
    
    [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down
    [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present
    [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144
    [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
             OE    kernel version xxxx
    [ 4223.822623] Hardware name: vendorname xxxx 666-106,
    BIOS 01.01.02.03.01 05/15/2023
    [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490
    [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
     57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1
    0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
    [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
    [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
    [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
    [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
    [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
    [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
    [ 4223.822626] FS:  0000000000000000(0000) GS:ffffa237ae400000(0000)
    knlGS:0000000000000000
    [ 4223.822627] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0
    [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    [ 4223.822628] PKRU: 55555554
    [ 4223.822628] Call Trace:
    [ 4223.822628]  qi_flush_dev_iotlb+0xb1/0xd0
    [ 4223.822628]  __dmar_remove_one_dev_info+0x224/0x250
    [ 4223.822629]  dmar_remove_one_dev_info+0x3e/0x50
    [ 4223.822629]  intel_iommu_release_device+0x1f/0x30
    [ 4223.822629]  iommu_release_device+0x33/0x60
    [ 4223.822629]  iommu_bus_notifier+0x7f/0x90
    [ 4223.822630]  blocking_notifier_call_chain+0x60/0x90
    [ 4223.822630]  device_del+0x2e5/0x420
    [ 4223.822630]  pci_remove_bus_device+0x70/0x110
    [ 4223.822630]  pciehp_unconfigure_device+0x7c/0x130
    [ 4223.822631]  pciehp_disable_slot+0x6b/0x100
    [ 4223.822631]  pciehp_handle_presence_or_link_change+0xd8/0x320
    [ 4223.822631]  pciehp_ist+0x176/0x180
    [ 4223.822631]  ? irq_finalize_oneshot.part.50+0x110/0x110
    [ 4223.822632]  irq_thread_fn+0x19/0x50
    [ 4223.822632]  irq_thread+0x104/0x190
    [ 4223.822632]  ? irq_forced_thread_fn+0x90/0x90
    [ 4223.822632]  ? irq_thread_check_affinity+0xe0/0xe0
    [ 4223.822633]  kthread+0x114/0x130
    [ 4223.822633]  ? __kthread_cancel_work+0x40/0x40
    [ 4223.822633]  ret_from_fork+0x1f/0x30
    [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP
    [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
             OE     kernel version xxxx
    [ 4223.822634] Hardware name: vendorname xxxx 666-106,
    BIOS 01.01.02.03.01 05/15/2023
    [ 4223.822634] Call Trace:
    [ 4223.822634]  <NMI>
    [ 4223.822635]  dump_stack+0x6d/0x88
    [ 4223.822635]  panic+0x101/0x2d0
    [ 4223.822635]  ? ret_from_fork+0x11/0x30
    [ 4223.822635]  nmi_panic.cold.14+0xc/0xc
    [ 4223.822636]  watchdog_overflow_callback.cold.8+0x6d/0x81
    [ 4223.822636]  __perf_event_overflow+0x4f/0xf0
    [ 4223.822636]  handle_pmi_common+0x1ef/0x290
    [ 4223.822636]  ? __set_pte_vaddr+0x28/0x40
    [ 4223.822637]  ? flush_tlb_one_kernel+0xa/0x20
    [ 4223.822637]  ? __native_set_fixmap+0x24/0x30
    [ 4223.822637]  ? ghes_copy_tofrom_phys+0x70/0x100
    [ 4223.822637]  ? __ghes_peek_estatus.isra.16+0x49/0xa0
    [ 4223.822637]  intel_pmu_handle_irq+0xba/0x2b0
    [ 4223.822638]  perf_event_nmi_handler+0x24/0x40
    [ 4223.822638]  nmi_handle+0x4d/0xf0
    [ 4223.822638]  default_do_nmi+0x49/0x100
    [ 4223.822638]  exc_nmi+0x134/0x180
    [ 4223.822639]  end_repeat_nmi+0x16/0x67
    [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490
    [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
     57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 10
     74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
    [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
    [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
    [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
    [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
    [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
    [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
    [ 4223.822641]  ? qi_submit_sync+0x2c0/0x490
    [ 4223.822642]  ? qi_submit_sync+0x2c0/0x490
    [ 4223.822642]  </NMI>
    [ 4223.822642]  qi_flush_dev_iotlb+0xb1/0xd0
    [ 4223.822642]  __dmar_remove_one_dev_info+0x224/0x250
    [ 4223.822643]  dmar_remove_one_dev_info+0x3e/0x50
    [ 4223.822643]  intel_iommu_release_device+0x1f/0x30
    [ 4223.822643]  iommu_release_device+0x33/0x60
    [ 4223.822643]  iommu_bus_notifier+0x7f/0x90
    [ 4223.822644]  blocking_notifier_call_chain+0x60/0x90
    [ 4223.822644]  device_del+0x2e5/0x420
    [ 4223.822644]  pci_remove_bus_device+0x70/0x110
    [ 4223.822644]  pciehp_unconfigure_device+0x7c/0x130
    [ 4223.822644]  pciehp_disable_slot+0x6b/0x100
    [ 4223.822645]  pciehp_handle_presence_or_link_change+0xd8/0x320
    [ 4223.822645]  pciehp_ist+0x176/0x180
    [ 4223.822645]  ? irq_finalize_oneshot.part.50+0x110/0x110
    [ 4223.822645]  irq_thread_fn+0x19/0x50
    [ 4223.822646]  irq_thread+0x104/0x190
    [ 4223.822646]  ? irq_forced_thread_fn+0x90/0x90
    [ 4223.822646]  ? irq_thread_check_affinity+0xe0/0xe0
    [ 4223.822646]  kthread+0x114/0x130
    [ 4223.822647]  ? __kthread_cancel_work+0x40/0x40
    [ 4223.822647]  ret_from_fork+0x1f/0x30
    [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 (relocation
    range: 0xffffffff80000000-0xffffffffbfffffff)
    
    Such issue could be triggered by all kinds of regular surprise removal
    hotplug operation. like:
    
    1. pull EP(endpoint device) out directly.
    2. turn off EP's power.
    3. bring the link down.
    etc.
    
    this patch aims to work for regular safe removal and surprise removal
    unplug. these hot unplug handling process could be optimized for fix the
    ATS Invalidation hang issue by calling pci_dev_is_disconnected() in
    function devtlb_invalidation_with_pasid() to check target device state to
    avoid sending meaningless ATS Invalidation request to iommu when device is
    gone. (see IMPLEMENTATION NOTE in PCIe spec r6.1 section 10.3.1)
    
    For safe removal, device wouldn't be removed until the whole software
    handling process is done, it wouldn't trigger the hard lock up issue
    caused by too long ATS Invalidation timeout wait. In safe removal path,
    device state isn't set to pci_channel_io_perm_failure in
    pciehp_unconfigure_device() by checking 'presence' parameter, calling
    pci_dev_is_disconnected() in devtlb_invalidation_with_pasid() will return
    false there, wouldn't break the function.
    
    For surprise removal, device state is set to pci_channel_io_perm_failure in
    pciehp_unconfigure_device(), means device is already gone (disconnected)
    call pci_dev_is_disconnected() in devtlb_invalidation_with_pasid() will
    return true to break the function not to send ATS Invalidation request to
    the disconnected device blindly, thus avoid to trigger further ITE fault,
    and ITE fault will block all invalidation request to be handled.
    furthermore retry the timeout request could trigger hard lockup.
    
    safe removal (present) & surprise removal (not present)
    
    pciehp_ist()
       pciehp_handle_presence_or_link_change()
         pciehp_disable_slot()
           remove_board()
             pciehp_unconfigure_device(presence) {
               if (!presence)
                    pci_walk_bus(parent, pci_dev_set_disconnected, NULL);
               }
    
    this patch works for regular safe removal and surprise removal of ATS
    capable endpoint on PCIe switch downstream ports.
    
    Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface")
    Reviewed-by: Dan Carpenter <[email protected]>
    Tested-by: Haorong Ye <[email protected]>
    Signed-off-by: Ethan Zhao <[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]>

iommu/vt-d: Fix NULL domain on device release [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Mar 5 20:21:18 2024 +0800

    iommu/vt-d: Fix NULL domain on device release
    
    [ Upstream commit 81e921fd321614c2ad8ac333b041aae1da7a1c6d ]
    
    In the kdump kernel, the IOMMU operates in deferred_attach mode. In this
    mode, info->domain may not yet be assigned by the time the release_device
    function is called. It leads to the following crash in the crash kernel:
    
        BUG: kernel NULL pointer dereference, address: 000000000000003c
        ...
        RIP: 0010:do_raw_spin_lock+0xa/0xa0
        ...
        _raw_spin_lock_irqsave+0x1b/0x30
        intel_iommu_release_device+0x96/0x170
        iommu_deinit_device+0x39/0xf0
        __iommu_group_remove_device+0xa0/0xd0
        iommu_bus_notifier+0x55/0xb0
        notifier_call_chain+0x5a/0xd0
        blocking_notifier_call_chain+0x41/0x60
        bus_notify+0x34/0x50
        device_del+0x269/0x3d0
        pci_remove_bus_device+0x77/0x100
        p2sb_bar+0xae/0x1d0
        ...
        i801_probe+0x423/0x740
    
    Use the release_domain mechanism to fix it. The scalable mode context
    entry which is not part of release domain should be cleared in
    release_device().
    
    Fixes: 586081d3f6b1 ("iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO")
    Reported-by: Eric Badger <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Improve ITE fault handling if target device isn't present [+ + +]
Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:16 2024 +0800

    iommu/vt-d: Improve ITE fault handling if target device isn't present
    
    [ Upstream commit 80a9b50c0b9e297669a8a400eb35468cd87a9aed ]
    
    Because surprise removal could happen anytime, e.g. user could request safe
    removal to EP(endpoint device) via sysfs and brings its link down to do
    surprise removal cocurrently. such aggressive cases would cause ATS
    invalidation request issued to non-existence target device, then deadly
    loop to retry that request after ITE fault triggered in interrupt context.
    this patch aims to optimize the ITE handling by checking the target device
    presence state to avoid retrying the timeout request blindly, thus avoid
    hard lockup or system hang.
    
    Devices TLB should only be invalidated when devices are in the
    iommu->device_rbtree (probed, not released) and present.
    
    Fixes: 6ba6c3a4cacf ("VT-d: add device IOTLB invalidation support")
    Reviewed-by: Dan Carpenter <[email protected]>
    Signed-off-by: Ethan Zhao <[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]>

iommu/vt-d: Use device rbtree in iopf reporting path [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Feb 27 10:14:41 2024 +0800

    iommu/vt-d: Use device rbtree in iopf reporting path
    
    [ Upstream commit def054b01a867822254e1dda13d587f5c7a99e2a ]
    
    The existing I/O page fault handler currently locates the PCI device by
    calling pci_get_domain_bus_and_slot(). This function searches the list
    of all PCI devices until the desired device is found. To improve lookup
    efficiency, replace it with device_rbtree_find() to search the device
    within the probed device rbtree.
    
    The I/O page fault is initiated by the device, which does not have any
    synchronization mechanism with the software to ensure that the device
    stays in the probed device tree. Theoretically, a device could be released
    by the IOMMU subsystem after device_rbtree_find() and before
    iopf_get_dev_fault_param(), which would cause a use-after-free problem.
    
    Add a mutex to synchronize the I/O page fault reporting path and the IOMMU
    release device path. This lock doesn't introduce any performance overhead,
    as the conflict between I/O page fault reporting and device releasing is
    very rare.
    
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Use rbtree to track iommu probed devices [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Feb 27 10:14:40 2024 +0800

    iommu/vt-d: Use rbtree to track iommu probed devices
    
    [ Upstream commit 1a75cc710b956010137b4fe1d1fa3282bfd8f86c ]
    
    Use a red-black tree(rbtree) to track devices probed by the driver's
    probe_device callback. These devices need to be looked up quickly by
    a source ID when the hardware reports a fault, either recoverable or
    unrecoverable.
    
    Fault reporting paths are critical. Searching a list in this scenario
    is inefficient, with an algorithm complexity of O(n). An rbtree is a
    self-balancing binary search tree, offering an average search time
    complexity of O(log(n)). This significant performance improvement
    makes rbtrees a better choice.
    
    Furthermore, rbtrees are implemented on a per-iommu basis, eliminating
    the need for global searches and further enhancing efficiency in
    critical fault paths. The rbtree is protected by a spin lock with
    interrupts disabled to ensure thread-safe access even within interrupt
    contexts.
    
    Co-developed-by: Huang Jiaqing <[email protected]>
    Signed-off-by: Huang Jiaqing <[email protected]>
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if target device isn't present")
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu: Add static iommu_ops->release_domain [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Mar 5 20:21:17 2024 +0800

    iommu: Add static iommu_ops->release_domain
    
    [ Upstream commit 0061ffe289e19caabeea8103e69cb0f1896e34d8 ]
    
    The current device_release callback for individual iommu drivers does the
    following:
    
    1) Silent IOMMU DMA translation: It detaches any existing domain from the
       device and puts it into a blocking state (some drivers might use the
       identity state).
    2) Resource release: It releases resources allocated during the
       device_probe callback and restores the device to its pre-probe state.
    
    Step 1 is challenging for individual iommu drivers because each must check
    if a domain is already attached to the device. Additionally, if a deferred
    attach never occurred, the device_release should avoid modifying hardware
    configuration regardless of the reason for its call.
    
    To simplify this process, introduce a static release_domain within the
    iommu_ops structure. It can be either a blocking or identity domain
    depending on the iommu hardware. The iommu core will decide whether to
    attach this domain before the device_release callback, eliminating the
    need for repetitive code in various drivers.
    
    Consequently, the device_release callback can focus solely on the opposite
    operations of device_probe, including releasing all resources allocated
    during that callback.
    
    Co-developed-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")
    Signed-off-by: Sasha Levin <[email protected]>

iommu: Fix compilation without CONFIG_IOMMU_INTEL [+ + +]
Author: Bert Karwatzki <[email protected]>
Date:   Thu Mar 7 20:44:19 2024 +0100

    iommu: Fix compilation without CONFIG_IOMMU_INTEL
    
    [ Upstream commit 70bad345e622c23bb530016925c936ab04a646ac ]
    
    When the kernel is comiled with CONFIG_IRQ_REMAP=y but without
    CONFIG_IOMMU_INTEL compilation fails since commit def054b01a8678 with an
    undefined reference to device_rbtree_find(). This patch makes sure that
    intel specific code is only compiled with CONFIG_IOMMU_INTEL=y.
    
    Signed-off-by: Bert Karwatzki <[email protected]>
    Fixes: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if target  device isn't present")
    Reviewed-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]>

 
ipmr: fix incorrect parameter validation in the ip_mroute_getsockopt() function [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

    ipmr: fix incorrect parameter validation in the ip_mroute_getsockopt() function
    
    [ Upstream commit 5c3be3e0eb44b7f978bb6cbb20ad956adb93f736 ]
    
    The 'olr' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'olr' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv4: raw: Fix sending packets from raw sockets via IPsec tunnels [+ + +]
Author: Tobias Brunner <[email protected]>
Date:   Fri Mar 15 15:35:40 2024 +0100

    ipv4: raw: Fix sending packets from raw sockets via IPsec tunnels
    
    [ Upstream commit c9b3b81716c5b92132a6c1d4ac3c48a7b44082ab ]
    
    Since the referenced commit, the xfrm_inner_extract_output() function
    uses the protocol field to determine the address family.  So not setting
    it for IPv4 raw sockets meant that such packets couldn't be tunneled via
    IPsec anymore.
    
    IPv6 raw sockets are not affected as they already set the protocol since
    9c9c9ad5fae7 ("ipv6: set skb->protocol on tcp, raw and ip6_append_data
    genereated skbs").
    
    Fixes: f4796398f21b ("xfrm: Remove inner/outer modes from output path")
    Signed-off-by: Tobias Brunner <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Reviewed-by: Nicolas Dichtel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: fib6_rules: flush route cache when rule is changed [+ + +]
Author: Shiming Cheng <[email protected]>
Date:   Thu Mar 7 18:01:57 2024 +0800

    ipv6: fib6_rules: flush route cache when rule is changed
    
    [ Upstream commit c4386ab4f6c600f75fdfd21143f89bac3e625d0d ]
    
    When rule policy is changed, ipv6 socket cache is not refreshed.
    The sock's skb still uses a outdated route cache and was sent to
    a wrong interface.
    
    To avoid this error we should update fib node's version when
    rule is changed. Then skb's route will be reroute checked as
    route cache version is already different with fib node version.
    The route cache is refreshed to match the latest rule.
    
    Fixes: 101367c2f8c4 ("[IPV6]: Policy Routing Rules")
    Signed-off-by: Shiming Cheng <[email protected]>
    Signed-off-by: Lena Wang <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Feb 9 15:30:56 2024 +0000

    ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()
    
    [ Upstream commit 17ef8efc00b34918b966388b2af0993811895a8c ]
    
    As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops
    in igmp6_event_query() and igmp6_event_report()")) I think the
    synchronize_net() call in ipv6_mc_down() is not needed.
    
    Under load, synchronize_net() can last between 200 usec and 5 ms.
    
    KASAN seems to agree as well.
    
    Fixes: f185de28d9ae ("mld: add new workqueues for process mld events")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Taehee Yoo <[email protected]>
    Cc: Cong Wang <[email protected]>
    Cc: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kconfig: fix infinite loop when expanding a macro at the end of file [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Sat Feb 3 00:57:59 2024 +0900

    kconfig: fix infinite loop when expanding a macro at the end of file
    
    [ Upstream commit af8bbce92044dc58e4cc039ab94ee5d470a621f5 ]
    
    A macro placed at the end of a file with no newline causes an infinite
    loop.
    
    [Test Kconfig]
      $(info,hello)
      \ No newline at end of file
    
    I realized that flex-provided input() returns 0 instead of EOF when it
    reaches the end of a file.
    
    Fixes: 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='")
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kunit: Setup DMA masks on the kunit device [+ + +]
Author: Maxime Ripard <[email protected]>
Date:   Wed Feb 21 13:53:24 2024 +0100

    kunit: Setup DMA masks on the kunit device
    
    [ Upstream commit c5215d54dc10e801a6cefef62445a00a4c28a515 ]
    
    Commit d393acce7b3f ("drm/tests: Switch to kunit devices") switched the
    DRM device creation helpers from an ad-hoc implementation to the new
    kunit device creation helpers introduced in commit d03c720e03bd ("kunit:
    Add APIs for managing devices").
    
    However, while the DRM helpers were using a platform_device, the kunit
    helpers are using a dedicated bus and device type.
    
    That situation creates small differences in the initialisation, and one
    of them is that the kunit devices do not have the DMA masks setup. In
    turn, this means that we can't do any kind of DMA buffer allocation
    anymore, which creates a regression on some (downstream for now) tests.
    
    Let's set up a default DMA mask that should work on any platform to fix
    it.
    
    Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
    Signed-off-by: Maxime Ripard <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kunit: test: Log the correct filter string in executor_test [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:14 2024 +0800

    kunit: test: Log the correct filter string in executor_test
    
    [ Upstream commit 6f2f793fba78eb4a0d5a34a71bc781118ed923d3 ]
    
    KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(),
    but passed a random character from the filter, rather than the whole
    string.
    
    This was found by annotating KUNIT_ASSERT_EQ_MSG() to let gcc validate
    the format string.
    
    Fixes: 76066f93f1df ("kunit: add tests for filtering attributes")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Reviewed-by: Daniel Latypov <[email protected]>
    Reviewed-by: Rae Moar <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

    l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function
    
    [ Upstream commit 955e9876ba4ee26eeaab1b13517f5b2c88e73d55 ]
    
    The 'len' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'len' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
    Reviewed-by: Tom Parkin <[email protected]>
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
leds: aw2013: Unlock mutex before destroying it [+ + +]
Author: George Stark <[email protected]>
Date:   Thu Dec 14 20:36:05 2023 +0300

    leds: aw2013: Unlock mutex before destroying it
    
    [ Upstream commit 6969d0a2ba1adc9ba6a49b9805f24080896c255c ]
    
    In the probe() callback in case of error mutex is destroyed being locked
    which is not allowed so unlock the mutex before destroying.
    
    Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
    Signed-off-by: George Stark <[email protected]>
    Reviewed-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]>

leds: sgm3140: Add missing timer cleanup and flash gpio control [+ + +]
Author: Ondrej Jirman <[email protected]>
Date:   Sat Feb 17 20:11:30 2024 +0100

    leds: sgm3140: Add missing timer cleanup and flash gpio control
    
    [ Upstream commit 205c29887a333ee4b37596e6533373e38cb23947 ]
    
    Enabling strobe and then setting brightness to 0 causes the driver to enter
    invalid state after strobe end timer fires. We should cancel strobe mode
    resources when changing brightness (aka torch mode).
    
    Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver")
    Signed-off-by: Ondrej Jirman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/cmdline: Fix an invalid format specifier in an assertion msg [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:15 2024 +0800

    lib/cmdline: Fix an invalid format specifier in an assertion msg
    
    [ Upstream commit d2733a026fc7247ba42d7a8e1b737cf14bf1df21 ]
    
    The correct format specifier for p - n (both p and n are pointers) is
    %td, as the type should be ptrdiff_t.
    
    This was discovered by annotating KUnit assertion macros with gcc's
    printf specifier, but note that gcc incorrectly suggested a %d or %ld
    specifier (depending on the pointer size of the architecture being
    built).
    
    Fixes: 0ea09083116d ("lib/cmdline: Allow get_options() to take 0 to validate the input")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Daniel Latypov <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/stackdepot: fix first entry having a 0-handle [+ + +]
Author: Oscar Salvador <[email protected]>
Date:   Thu Feb 15 22:59:01 2024 +0100

    lib/stackdepot: fix first entry having a 0-handle
    
    [ Upstream commit 3ee34eabac2abb6b1b6fcdebffe18870719ad000 ]
    
    Patch series "page_owner: print stacks and their outstanding allocations",
    v10.
    
    page_owner is a great debug functionality tool that lets us know about all
    pages that have been allocated/freed and their specific stacktrace.  This
    comes very handy when debugging memory leaks, since with some scripting we
    can see the outstanding allocations, which might point to a memory leak.
    
    In my experience, that is one of the most useful cases, but it can get
    really tedious to screen through all pages and try to reconstruct the
    stack <-> allocated/freed relationship, becoming most of the time a
    daunting and slow process when we have tons of allocation/free operations.
    
    This patchset aims to ease that by adding a new functionality into
    page_owner.  This functionality creates a new directory called
    'page_owner_stacks' under 'sys/kernel//debug' with a read-only file called
    'show_stacks', which prints out all the stacks followed by their
    outstanding number of allocations (being that the times the stacktrace has
    allocated but not freed yet).  This gives us a clear and a quick overview
    of stacks <-> allocated/free.
    
    We take advantage of the new refcount_f field that stack_record struct
    gained, and increment/decrement the stack refcount on every
    __set_page_owner() (alloc operation) and __reset_page_owner (free
    operation) call.
    
    Unfortunately, we cannot use the new stackdepot api STACK_DEPOT_FLAG_GET
    because it does not fulfill page_owner needs, meaning we would have to
    special case things, at which point makes more sense for page_owner to do
    its own {dec,inc}rementing of the stacks.  E.g: Using
    STACK_DEPOT_FLAG_PUT, once the refcount reaches 0, such stack gets
    evicted, so page_owner would lose information.
    
    This patchset also creates a new file called 'set_threshold' within
    'page_owner_stacks' directory, and by writing a value to it, the stacks
    which refcount is below such value will be filtered out.
    
    A PoC can be found below:
    
     # cat /sys/kernel/debug/page_owner_stacks/show_stacks > page_owner_full_stacks.txt
     # head -40 page_owner_full_stacks.txt
      prep_new_page+0xa9/0x120
      get_page_from_freelist+0x801/0x2210
      __alloc_pages+0x18b/0x350
      alloc_pages_mpol+0x91/0x1f0
      folio_alloc+0x14/0x50
      filemap_alloc_folio+0xb2/0x100
      page_cache_ra_unbounded+0x96/0x180
      filemap_get_pages+0xfd/0x590
      filemap_read+0xcc/0x330
      blkdev_read_iter+0xb8/0x150
      vfs_read+0x285/0x320
      ksys_read+0xa5/0xe0
      do_syscall_64+0x80/0x160
      entry_SYSCALL_64_after_hwframe+0x6e/0x76
     stack_count: 521
    
      prep_new_page+0xa9/0x120
      get_page_from_freelist+0x801/0x2210
      __alloc_pages+0x18b/0x350
      alloc_pages_mpol+0x91/0x1f0
      folio_alloc+0x14/0x50
      filemap_alloc_folio+0xb2/0x100
      __filemap_get_folio+0x14a/0x490
      ext4_write_begin+0xbd/0x4b0 [ext4]
      generic_perform_write+0xc1/0x1e0
      ext4_buffered_write_iter+0x68/0xe0 [ext4]
      ext4_file_write_iter+0x70/0x740 [ext4]
      vfs_write+0x33d/0x420
      ksys_write+0xa5/0xe0
      do_syscall_64+0x80/0x160
      entry_SYSCALL_64_after_hwframe+0x6e/0x76
     stack_count: 4609
    ...
    ...
    
     # echo 5000 > /sys/kernel/debug/page_owner_stacks/set_threshold
     # cat /sys/kernel/debug/page_owner_stacks/show_stacks > page_owner_full_stacks_5000.txt
     # head -40 page_owner_full_stacks_5000.txt
      prep_new_page+0xa9/0x120
      get_page_from_freelist+0x801/0x2210
      __alloc_pages+0x18b/0x350
      alloc_pages_mpol+0x91/0x1f0
      folio_alloc+0x14/0x50
      filemap_alloc_folio+0xb2/0x100
      __filemap_get_folio+0x14a/0x490
      ext4_write_begin+0xbd/0x4b0 [ext4]
      generic_perform_write+0xc1/0x1e0
      ext4_buffered_write_iter+0x68/0xe0 [ext4]
      ext4_file_write_iter+0x70/0x740 [ext4]
      vfs_write+0x33d/0x420
      ksys_pwrite64+0x75/0x90
      do_syscall_64+0x80/0x160
      entry_SYSCALL_64_after_hwframe+0x6e/0x76
     stack_count: 6781
    
      prep_new_page+0xa9/0x120
      get_page_from_freelist+0x801/0x2210
      __alloc_pages+0x18b/0x350
      pcpu_populate_chunk+0xec/0x350
      pcpu_balance_workfn+0x2d1/0x4a0
      process_scheduled_works+0x84/0x380
      worker_thread+0x12a/0x2a0
      kthread+0xe3/0x110
      ret_from_fork+0x30/0x50
      ret_from_fork_asm+0x1b/0x30
     stack_count: 8641
    
    This patch (of 7):
    
    The very first entry of stack_record gets a handle of 0, but this is wrong
    because stackdepot treats a 0-handle as a non-valid one.  E.g: See the
    check in stack_depot_fetch()
    
    Fix this by adding and offset of 1.
    
    This bug has been lurking since the very beginning of stackdepot, but no
    one really cared as it seems.  Because of that I am not adding a Fixes
    tag.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Co-developed-by: Marco Elver <[email protected]>
    Signed-off-by: Marco Elver <[email protected]>
    Signed-off-by: Oscar Salvador <[email protected]>
    Acked-by: Vlastimil Babka <[email protected]>
    Acked-by: Andrey Konovalov <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Michal Hocko <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: dc24559472a6 ("lib/stackdepot: off by one in depot_fetch_stack()")
    Signed-off-by: Sasha Levin <[email protected]>

lib/stackdepot: off by one in depot_fetch_stack() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Feb 23 17:20:13 2024 +0300

    lib/stackdepot: off by one in depot_fetch_stack()
    
    [ Upstream commit dc24559472a682eb124e869cb110e7a2fd857322 ]
    
    The stack_pools[] array has DEPOT_MAX_POOLS.  The "pools_num" tracks the
    number of pools which are initialized.  See depot_init_pool() for more
    details.
    
    If pool_index == pools_num_cached, this will read one element beyond what
    we want.  If not all the pools are initialized, then the pool will be
    NULL, triggering a WARN(), and if they are all initialized it will read
    one element beyond the end of the array.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b29d31885814 ("lib/stackdepot: store free stack records in a freelist")
    Signed-off-by: Dan Carpenter <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Andrey Konovalov <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:16 2024 +0800

    lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg
    
    [ Upstream commit 0a549ed22c3c7cc6da5c5f5918efd019944489a5 ]
    
    The 'i' passed as an assertion message is a size_t, so should use '%zu',
    not '%d'.
    
    This was found by annotating the _MSG() variants of KUnit's assertions
    to let gcc validate the format strings.
    
    Fixes: bb95ebbe89a7 ("lib: Introduce CONFIG_MEMCPY_KUNIT_TEST")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
libbpf: Add missing LIBBPF_API annotation to libbpf_set_memlock_rlim API [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Thu Feb 1 09:20:24 2024 -0800

    libbpf: Add missing LIBBPF_API annotation to libbpf_set_memlock_rlim API
    
    [ Upstream commit 93ee1eb85e28d1e35bb059c1f5965d65d5fc83c2 ]
    
    LIBBPF_API annotation seems missing on libbpf_set_memlock_rlim API, so
    add it to make this API callable from libbpf's shared library version.
    
    Fixes: e542f2c4cd16 ("libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it for BPF")
    Fixes: ab9a5a05dc48 ("libbpf: fix up few libbpf.map problems")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Apply map_set_def_max_entries() for inner_maps on creation [+ + +]
Author: Andrey Grafin <[email protected]>
Date:   Wed Jan 17 16:06:18 2024 +0300

    libbpf: Apply map_set_def_max_entries() for inner_maps on creation
    
    [ Upstream commit f04deb90e516e8e48bf8693397529bc942a9e80b ]
    
    This patch allows to auto create BPF_MAP_TYPE_ARRAY_OF_MAPS and
    BPF_MAP_TYPE_HASH_OF_MAPS with values of BPF_MAP_TYPE_PERF_EVENT_ARRAY
    by bpf_object__load().
    
    Previous behaviour created a zero filled btf_map_def for inner maps and
    tried to use it for a map creation but the linux kernel forbids to create
    a BPF_MAP_TYPE_PERF_EVENT_ARRAY map with max_entries=0.
    
    Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support")
    Signed-off-by: Andrey Grafin <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Acked-by: Hou Tao <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: fix __arg_ctx type enforcement for perf_event programs [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Thu Jan 25 12:55:05 2024 -0800

    libbpf: fix __arg_ctx type enforcement for perf_event programs
    
    [ Upstream commit 9eea8fafe33eb70868f6ace2fc1e17c4ff5539c3 ]
    
    Adjust PERF_EVENT type enforcement around __arg_ctx to match exactly
    what kernel is doing.
    
    Fixes: 76ec90a996e3 ("libbpf: warn on unexpected __arg_ctx type when rewriting BTF")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Fix faccessat() usage on Android [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Fri Jan 26 14:09:44 2024 -0800

    libbpf: Fix faccessat() usage on Android
    
    [ Upstream commit ad57654053805bf9a62602aaec74cc78edb6f235 ]
    
    Android implementation of libc errors out with -EINVAL in faccessat() if
    passed AT_EACCESS ([0]), this leads to ridiculous issue with libbpf
    refusing to load /sys/kernel/btf/vmlinux on Androids ([1]). Fix by
    detecting Android and redefining AT_EACCESS to 0, it's equivalent on
    Android.
    
      [0] https://android.googlesource.com/platform/bionic/+/refs/heads/android13-release/libc/bionic/faccessat.cpp#50
      [1] https://github.com/libbpf/libbpf-bootstrap/issues/250#issuecomment-1911324250
    
    Fixes: 6a4ab8869d0b ("libbpf: Fix the case of running as non-root with capabilities")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: fix return value for PERF_EVENT __arg_ctx type fix up check [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Mon Feb 5 16:22:43 2024 -0800

    libbpf: fix return value for PERF_EVENT __arg_ctx type fix up check
    
    [ Upstream commit d7bc416aa5cc183691287e8f0b1d5b182a7ce9c3 ]
    
    If PERF_EVENT program has __arg_ctx argument with matching
    architecture-specific pt_regs/user_pt_regs/user_regs_struct pointer
    type, libbpf should still perform type rewrite for old kernels, but not
    emit the warning. Fix copy/paste from kernel code where 0 is meant to
    signify "no error" condition. For libbpf we need to return "true" to
    proceed with type rewrite (which for PERF_EVENT program will be
    a canonical `struct bpf_perf_event_data *` type).
    
    Fixes: 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for perf_event programs")
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Use OPTS_SET() macro in bpf_xdp_query() [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Tue Feb 6 13:59:22 2024 +0100

    libbpf: Use OPTS_SET() macro in bpf_xdp_query()
    
    [ Upstream commit 92a871ab9fa59a74d013bc04f321026a057618e7 ]
    
    When the feature_flags and xdp_zc_max_segs fields were added to the libbpf
    bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.
    This causes libbpf to write to those fields unconditionally, which means
    that programs compiled against an older version of libbpf (with a smaller
    size of the bpf_xdp_query_opts struct) will have its stack corrupted by
    libbpf writing out of bounds.
    
    The patch adding the feature_flags field has an early bail out if the
    feature_flags field is not part of the opts struct (via the OPTS_HAS)
    macro, but the patch adding xdp_zc_max_segs does not. For consistency, this
    fix just changes the assignments to both fields to use the OPTS_SET()
    macro.
    
    Fixes: 13ce2daa259a ("xsk: add new netlink attribute dedicated for ZC max frags")
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.8.2 [+ + +]
Author: Sasha Levin <[email protected]>
Date:   Sun Mar 24 14:36:44 2024 -0400

    Linux 6.8.2
    
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jiri Slaby <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
md/raid1: factor out helpers to add rdev to conf [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:05 2024 +0800

    md/raid1: factor out helpers to add rdev to conf
    
    [ Upstream commit 969d6589abcb369d53d84ec7c9c37f4b23ec1ad9 ]
    
    There are no functional changes, just make code cleaner and prepare to
    record disk non-rotational information while adding and removing rdev to
    conf
    
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balance()")
    Signed-off-by: Sasha Levin <[email protected]>

md/raid1: fix choose next idle in read_balance() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:07 2024 +0800

    md/raid1: fix choose next idle in read_balance()
    
    [ Upstream commit 257ac239ffcfd097a9a0732bf5095fb00164f334 ]
    
    Commit 12cee5a8a29e ("md/raid1: prevent merging too large request") add
    the case choose next idle in read_balance():
    
    read_balance:
     for_each_rdev
      if(next_seq_sect == this_sector || dist == 0)
      -> sequential reads
       best_disk = disk;
       if (...)
        choose_next_idle = 1
        continue;
    
     for_each_rdev
     -> iterate next rdev
      if (pending == 0)
       best_disk = disk;
       -> choose the next idle disk
       break;
    
      if (choose_next_idle)
       -> keep using this rdev if there are no other idle disk
       contine
    
    However, commit 2e52d449bcec ("md/raid1: add failfast handling for reads.")
    remove the code:
    
    -               /* If device is idle, use it */
    -               if (pending == 0) {
    -                       best_disk = disk;
    -                       break;
    -               }
    
    Hence choose next idle will never work now, fix this problem by
    following:
    
    1) don't set best_disk in this case, read_balance() will choose the best
       disk after iterating all the disks;
    2) add 'pending' so that other idle disk will be chosen;
    3) add a new local variable 'sequential_disk' to record the disk, and if
       there is no other idle disk, 'sequential_disk' will be chosen;
    
    Fixes: 2e52d449bcec ("md/raid1: add failfast handling for reads.")
    Co-developed-by: Paul Luse <[email protected]>
    Signed-off-by: Paul Luse <[email protected]>
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Xiao Ni <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

md/raid1: record nonrot rdevs while adding/removing rdevs to conf [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:06 2024 +0800

    md/raid1: record nonrot rdevs while adding/removing rdevs to conf
    
    [ Upstream commit 2c27d09d3a76b33629d2e681bf8b774f776ade7f ]
    
    For raid1, each read will iterate all the rdevs from conf and check if
    any rdev is non-rotational, then choose rdev with minimal IO inflight
    if so, or rdev with closest distance otherwise.
    
    Disk nonrot info can be changed through sysfs entry:
    
    /sys/block/[disk_name]/queue/rotational
    
    However, consider that this should only be used for testing, and user
    really shouldn't do this in real life. Record the number of non-rotational
    disks in conf, to avoid checking each rdev in IO fast path and simplify
    read_balance() a little bit.
    
    Co-developed-by: Paul Luse <[email protected]>
    Signed-off-by: Paul Luse <[email protected]>
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balance()")
    Signed-off-by: Sasha Levin <[email protected]>

 
md: Don't clear MD_CLOSING when the raid is about to stop [+ + +]
Author: Li Nan <[email protected]>
Date:   Mon Feb 26 11:14:40 2024 +0800

    md: Don't clear MD_CLOSING when the raid is about to stop
    
    [ Upstream commit 9674f54e41fffaf06f6a60202e1fa4cc13de3cf5 ]
    
    The raid should not be opened anymore when it is about to be stopped.
    However, other processes can open it again if the flag MD_CLOSING is
    cleared before exiting. From now on, this flag will not be cleared when
    the raid will be stopped.
    
    Fixes: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop")
    Signed-off-by: Li Nan <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

md: fix kmemleak of rdev->serial [+ + +]
Author: Li Nan <[email protected]>
Date:   Thu Feb 8 16:55:56 2024 +0800

    md: fix kmemleak of rdev->serial
    
    [ Upstream commit 6cf350658736681b9d6b0b6e58c5c76b235bb4c4 ]
    
    If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
    alloc not be freed, and kmemleak occurs.
    
    unreferenced object 0xffff88815a350000 (size 49152):
      comm "mdadm", pid 789, jiffies 4294716910
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc f773277a):
        [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
        [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
        [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
        [<00000000f206d60a>] kvmalloc_node+0x74/0x150
        [<0000000034bf3363>] rdev_init_serial+0x67/0x170
        [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
        [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
        [<0000000073c28560>] md_add_new_disk+0x400/0x9f0
        [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
        [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
        [<0000000085086a11>] vfs_ioctl+0x22/0x60
        [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
        [<00000000e54e675e>] do_syscall_64+0x71/0x150
        [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device")
    Signed-off-by: Li Nan <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
media: cadence: csi2rx: use match fwnode for media link [+ + +]
Author: Julien Massot <[email protected]>
Date:   Fri Jan 5 10:00:21 2024 +0100

    media: cadence: csi2rx: use match fwnode for media link
    
    [ Upstream commit 448699c522af9e3266f168c3f51f4c3713c7bee1 ]
    
    Since commit 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode matching"),
    async connections are matched using the async sub-device fwnode, not that
    of the endpoint. Fix this by using the fwnode of the connection match to
    find the pad.
    
    Fixes: 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode matching")
    Signed-off-by: Julien Massot <[email protected]>
    Reviewed-by: Jai Luthra <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cedrus: h265: Fix configuring bitstream size [+ + +]
Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:09:25 2023 +0100

    media: cedrus: h265: Fix configuring bitstream size
    
    [ Upstream commit 3a11887f7f11a6bb1f05e7f67b3ea20dadfec443 ]
    
    bit_size field holds size of slice, not slice + header. Because of HW
    quirks, driver can't program in just slice, but also preceding header.
    But that means that currently used bit_size is wrong (too small).
    Instead, just use size of whole buffer. There is no harm in doing this.
    
    Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
    Suggested-by: Paul Kocialkowski <[email protected]>
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dt-bindings: techwell,tw9900: Fix port schema ref [+ + +]
Author: Rob Herring <[email protected]>
Date:   Fri Feb 2 16:23:25 2024 -0600

    media: dt-bindings: techwell,tw9900: Fix port schema ref
    
    [ Upstream commit c9cd7308d64b13741ee03be81836a324fc4d657d ]
    
    The port@0 node doesn't define any extra properties in the port or endpoint
    nodes, so the $ref should be to "/properties/port" instead as it restricts
    extra properties.
    
    Fixes: 0f82ffa9a295 ("media: dt-bindings: media: i2c: Add bindings for TW9900")
    Signed-off-by: Rob Herring <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dvb-frontends: avoid stack overflow warnings with clang [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 16 17:31:44 2024 +0100

    media: dvb-frontends: avoid stack overflow warnings with clang
    
    [ Upstream commit 7a4cf27d1f0538f779bf31b8c99eda394e277119 ]
    
    A previous patch worked around a KASAN issue in stv0367, now a similar
    problem showed up with clang:
    
    drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
     1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
    
    Rework the stv0367_writereg() function to be simpler and mark both
    register access functions as noinline_for_stack so the temporary
    i2c_msg structures do not get duplicated on the stack when KASAN_STACK
    is enabled.
    
    Fixes: 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: edia: dvbdev: fix a use-after-free [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Sat Feb 3 14:40:43 2024 +0100

    media: edia: dvbdev: fix a use-after-free
    
    [ Upstream commit 8c64f4cdf4e6cc5682c52523713af8c39c94e6d5 ]
    
    In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
    in several error-handling paths. However, *pdvbdev is not set to NULL
    after dvbdev's deallocation, causing use-after-frees in many places,
    for example, in the following call chain:
    
    budget_register
      |-> dvb_dmxdev_init
            |-> dvb_register_device
      |-> dvb_dmxdev_release
            |-> dvb_unregister_device
                  |-> dvb_remove_device
                        |-> dvb_device_put
                              |-> kref_put
    
    When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
    dvb_register_device) could point to memory that had been freed in
    dvb_register_device. Thereafter, this pointer is transferred to
    kref_put and triggering a use-after-free.
    
    Link: https://lore.kernel.org/linux-media/[email protected]
    Fixes: b61901024776 ("V4L/DVB (5244): Dvbdev: fix illegal re-usage of fileoperations struct")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: em28xx: annotate unchecked call to media_device_register() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Fri Jan 12 05:42:26 2024 -0800

    media: em28xx: annotate unchecked call to media_device_register()
    
    [ Upstream commit fd61d77a3d28444b2635f0c8b5a2ecd6a4d94026 ]
    
    Static analyzers generate alerts for an unchecked call to
    `media_device_register()`. However, in this case, the device will work
    reliably without the media controller API.
    
    Add a comment above the call to prevent future unnecessary changes.
    
    Suggested-by: Mauro Carvalho Chehab <[email protected]>
    Fixes: 37ecc7b1278f ("[media] em28xx: add media controller support")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: go7007: add check of return value of go7007_read_addr() [+ + +]
Author: Daniil Dulov <[email protected]>
Date:   Sun Feb 11 07:07:05 2024 -0800

    media: go7007: add check of return value of go7007_read_addr()
    
    [ Upstream commit 0b70530ee740861f4776ff724fcc25023df1799a ]
    
    If go7007_read_addr() returns error channel is not assigned a value.
    In this case go to allocfail.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 866b8695d67e ("Staging: add the go7007 video driver")
    Signed-off-by: Daniil Dulov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: go7007: fix a memleak in go7007_load_encoder [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Wed Feb 21 12:37:13 2024 +0800

    media: go7007: fix a memleak in go7007_load_encoder
    
    [ Upstream commit b9b683844b01d171a72b9c0419a2d760d946ee12 ]
    
    In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
    a deallocation thereafter. After the following call chain:
    
    saa7134_go7007_init
      |-> go7007_boot_encoder
            |-> go7007_load_encoder
      |-> kfree(go)
    
    go is freed and thus bounce is leaked.
    
    Fixes: 95ef39403f89 ("[media] go7007: remember boot firmware")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: i2c: imx290: Fix IMX920 typo [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Wed Feb 21 08:15:50 2024 +0100

    media: i2c: imx290: Fix IMX920 typo
    
    [ Upstream commit 6fc62efa266b0918c7b226f45c2eccfcf99a6d8e ]
    
    Replace IMX920 by IMX290.
    
    Fixes: b4ab57b07c5b9 ("media: i2c: imx290: Add crop selection targets support")
    Signed-off-by: Alexander Stein <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak [+ + +]
Author: Lucas Stach <[email protected]>
Date:   Wed Jan 31 13:00:33 2024 +0100

    media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak
    
    [ Upstream commit 4797a3dd46f220e6d83daf54d70c5b33db6deb01 ]
    
    Free the memory allocated in v4l2_ctrl_handler_init on release.
    
    Fixes: a8ef0488cc59 ("media: imx: add csc/scaler mem2mem device")
    Signed-off-by: Lucas Stach <[email protected]>
    Reviewed-by: Philipp Zabel <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: ivsc: csi: Swap SINK and SOURCE pads [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Wed Feb 7 14:17:09 2024 +0200

    media: ivsc: csi: Swap SINK and SOURCE pads
    
    [ Upstream commit 48f5fd8967f8dd01679fc1618b0cba02095cddc5 ]
    
    This patch swaps SINK and SOURCE pads of the MEI CSI sub-device. While
    this does change the UAPI by swapping the pads, the driver has never been
    usable in upstream kernel as the Intel IPU6 driver it depends on any
    functionality has not yet been merged.
    
    Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule")
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: mediatek: vcodec: avoid -Wcast-function-type-strict warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Sat Feb 24 13:10:22 2024 +0100

    media: mediatek: vcodec: avoid -Wcast-function-type-strict warning
    
    [ Upstream commit bfb1b99802ef16045402deb855c197591dc78886 ]
    
    The ipi handler here tries hard to maintain const-ness of its argument,
    but by doing that causes a warning about function type casts:
    
    drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: error: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       38 |         ipi_handler_t handler_const = (ipi_handler_t)handler;
          |                                       ^~~~~~~~~~~~~~~~~~~~~~
    
    Remove the hack and just use a non-const argument.
    
    Fixes: bf1d556ad4e0 ("media: mtk-vcodec: abstract firmware interface")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Ricardo Ribalda <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: pvrusb2: fix pvr2_stream_callback casts [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:04:27 2024 +0100

    media: pvrusb2: fix pvr2_stream_callback casts
    
    [ Upstream commit 30baa4a96b23add91a87305baaeba82c4e109e1f ]
    
    clang-16 complains about a control flow integrity (KCFI) issue in pvrusb2,
    which casts three different prototypes into pvr2_stream_callback:
    
    drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:1070:30: error: cast from 'void (*)(struct pvr2_v4l2_fh *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1070 |         pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
          |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/media/usb/pvrusb2/pvrusb2-context.c:110:6: error: cast from 'void (*)(struct pvr2_context *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      110 |                                         (void (*)(void *))pvr2_context_notify,
          |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/media/usb/pvrusb2/pvrusb2-dvb.c:152:6: error: cast from 'void (*)(struct pvr2_dvb_adapter *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      152 |                                  (pvr2_stream_callback) pvr2_dvb_notify, adap);
          |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Change the functions to actually take a void* argument so the cast is no longer
    needed.
    
    Fixes: bb8ce9d9143c ("V4L/DVB (7682): pvrusb2-dvb: finish up stream & buffer handling")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: pvrusb2: fix uaf in pvr2_context_set_notify [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Fri Feb 16 15:30:47 2024 +0800

    media: pvrusb2: fix uaf in pvr2_context_set_notify
    
    [ Upstream commit 0a0b79ea55de8514e1750884e5fec77f9fdd01ee ]
    
    [Syzbot reported]
    BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
    Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
    
    CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    Workqueue: usb_hub_wq hub_event
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0xc4/0x620 mm/kasan/report.c:488
     kasan_report+0xda/0x110 mm/kasan/report.c:601
     pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
     pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
     pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
    
    Freed by task 906:
    kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
    kasan_save_track+0x14/0x30 mm/kasan/common.c:68
    kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
    poison_slab_object mm/kasan/common.c:241 [inline]
    __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
    kasan_slab_free include/linux/kasan.h:184 [inline]
    slab_free_hook mm/slub.c:2121 [inline]
    slab_free mm/slub.c:4299 [inline]
    kfree+0x105/0x340 mm/slub.c:4409
    pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
    pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
    
    [Analyze]
    Task A set disconnect_flag = !0, which resulted in Task B's condition being met
    and releasing mp, leading to this issue.
    
    [Fix]
    Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
    to avoid this issue.
    
    Reported-and-tested-by: [email protected]
    Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload")
    Signed-off-by: Edward Adam Davis <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: pvrusb2: remove redundant NULL check [+ + +]
Author: Daniil Dulov <[email protected]>
Date:   Sun Feb 11 07:07:25 2024 -0800

    media: pvrusb2: remove redundant NULL check
    
    [ Upstream commit 95ac1210fb2753f968ebce0730d4fbc553c2a3dc ]
    
    Pointer dip->stream cannot be NULL due to a shift, thus remove redundant
    NULL check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: c74e0062684b ("V4L/DVB (5059): Pvrusb2: Be smarter about mode restoration")
    Signed-off-by: Daniil Dulov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: sun8i-di: Fix chroma difference threshold [+ + +]
Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:22 2023 +0100

    media: sun8i-di: Fix chroma difference threshold
    
    [ Upstream commit 856525e8db272b0ce6d9c6e6c2eeb97892b485a6 ]
    
    While there is no good explanation what this value does, vendor driver
    uses value 31 for it. Align driver with it.
    
    Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: sun8i-di: Fix coefficient writes [+ + +]
Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:20 2023 +0100

    media: sun8i-di: Fix coefficient writes
    
    [ Upstream commit 794b581f8c6eb7b60fe468ccb96dd3cd38ff779f ]
    
    Currently coefficients are applied only once, since they don't change.
    However, this is done before enable bit is set and thus it doesn't get
    applied properly.
    
    Fix that by applying coefficients after enable bit is set. While this
    means that it will be done evey time, it doesn't bring much time
    penalty.
    
    Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: sun8i-di: Fix power on/off sequences [+ + +]
Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:21 2023 +0100

    media: sun8i-di: Fix power on/off sequences
    
    [ Upstream commit cff104e33bad38f4b2c8d58816a7accfaa2879f9 ]
    
    According to user manual, reset line should be deasserted before clocks
    are enabled. Also fix power down sequence to be reverse of that.
    
    Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: tc358743: register v4l2 async device only after successful setup [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Wed Jan 10 10:01:11 2024 +0100

    media: tc358743: register v4l2 async device only after successful setup
    
    [ Upstream commit 87399f1ff92203d65f1febf5919429f4bb613a02 ]
    
    Ensure the device has been setup correctly before registering the v4l2
    async device, thus allowing userspace to access.
    
    Signed-off-by: Alexander Stein <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Fixes: 4c5211a10039 ("[media] tc358743: register v4l2 asynchronous subdevice")
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

media: ttpci: fix two memleaks in budget_av_attach [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Wed Feb 21 13:17:04 2024 +0800

    media: ttpci: fix two memleaks in budget_av_attach
    
    [ Upstream commit d0b07f712bf61e1a3cf23c87c663791c42e50837 ]
    
    When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
    should free the resources it allocates, like the error-handling of
    ttpci_budget_init does. Besides, there are two fixme comment refers to
    such deallocations.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: usbtv: Remove useless locks in usbtv_video_free() [+ + +]
Author: Benjamin Gaignard <[email protected]>
Date:   Sat Mar 2 11:37:08 2024 +0100

    media: usbtv: Remove useless locks in usbtv_video_free()
    
    [ Upstream commit 65e6a2773d655172143cc0b927cdc89549842895 ]
    
    Remove locks calls in usbtv_video_free() because
    are useless and may led to a deadlock as reported here:
    https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
    Also remove usbtv_stop() call since it will be called when
    unregistering the device.
    
    Before 'c838530d230b' this issue would only be noticed if you
    disconnect while streaming and now it is noticeable even when
    disconnecting while not streaming.
    
    Fixes: c838530d230b ("media: media videobuf2: Be more flexible on the number of queue stored buffers")
    Fixes: f3d27f34fdd7 ("[media] usbtv: Add driver for Fushicai USBTV007 video frame grabber")
    
    Signed-off-by: Benjamin Gaignard <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Tested-by: Hans Verkuil <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    [hverkuil: fix minor spelling mistake in log message]
    Signed-off-by: Sasha Levin <[email protected]>

media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Thu Feb 1 20:48:44 2024 +0800

    media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
    
    [ Upstream commit 8f94b49a5b5d386c038e355bef6347298aabd211 ]
    
    The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity
    but isn't freed in its following error-handling paths. This patch
    adds such deallocation to prevent memleak of entity->name.
    
    Fixes: be2fff656322 ("media: add helpers for memory-to-memory media controller")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: v4l2-tpg: fix some memleaks in tpg_alloc [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Thu Feb 1 20:47:53 2024 +0800

    media: v4l2-tpg: fix some memleaks in tpg_alloc
    
    [ Upstream commit 8cf9c5051076e0eb958f4361d50d8b0c3ee6691c ]
    
    In tpg_alloc, resources should be deallocated in each and every
    error-handling paths, since they are allocated in for statements.
    Otherwise there would be memleaks because tpg_free is called only when
    tpg_alloc return 0.
    
    Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: v4l2: cci: print leading 0 on error [+ + +]
Author: Julien Massot <[email protected]>
Date:   Thu Jan 11 14:20:03 2024 +0100

    media: v4l2: cci: print leading 0 on error
    
    [ Upstream commit 58ab1f9e140006e9e5686640f1773260038fe889 ]
    
    In some error cases leading '0' for register address
    were missing.
    
    Fixes: 613cbb91e9ce ("media: Add MIPI CCI register access helper functions")
    Signed-off-by: Julien Massot <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: videobuf2: Add missing doc comment for waiting_in_dqbuf [+ + +]
Author: Andrzej Pietrasiewicz <[email protected]>
Date:   Mon Feb 12 20:12:03 2024 +0100

    media: videobuf2: Add missing doc comment for waiting_in_dqbuf
    
    [ Upstream commit 26a3a10342748862dcc8d22222563f6ca03d6ca3 ]
    
    While at it rearrange other comments to match the order of struct members.
    
    Fixes: d65842f7126a ("media: vb2: add waiting_in_dqbuf flag")
    
    Signed-off-by: Andrzej Pietrasiewicz <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mei: vsc: Call wake_up() in the threaded IRQ handler [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Mon Feb 19 21:58:05 2024 +0200

    mei: vsc: Call wake_up() in the threaded IRQ handler
    
    [ Upstream commit 058a38acba15fd8e7b262ec6e17c4204cb15f984 ]
    
    The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken.
    wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. This leads
    to sleeping in atomic context.
    
    Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr()
    where it can be safely called.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Signed-off-by: Sakari Ailus <[email protected]>
    Tested-and-Reviewed-by: Wentong Wu <[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]>

mei: vsc: Don't use sleeping condition in wait_event_timeout() [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Mon Feb 19 21:58:06 2024 +0200

    mei: vsc: Don't use sleeping condition in wait_event_timeout()
    
    [ Upstream commit b8b19acfafdeacbedd4e2795cb18c81c4d8bb6cc ]
    
    vsc_tp_wakeup_request() called wait_event_timeout() with
    gpiod_get_value_cansleep() which may sleep, and does so as the
    implementation is that of gpio-ljca.
    
    Move the GPIO state check outside the call.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Signed-off-by: Sakari Ailus <[email protected]>
    Tested-and-Reviewed-by: Wentong Wu <[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]>

 
memory: tegra: Correct DLA client names [+ + +]
Author: Jon Hunter <[email protected]>
Date:   Tue Feb 20 12:44:28 2024 +0000

    memory: tegra: Correct DLA client names
    
    [ Upstream commit 51d915cbeef4c7a154f5d810b1e10d8125f2b0cc ]
    
    Some of the names for the Tegra234 DLA clients are not unique and do not
    align with the name of the client ID definitions. Therefore, it is not
    possible to determine the exact DLA client from messages that print the
    client name. Fix this by correcting the DLA memory client names for
    Tegra234 to align with the name of the corresponding memory client ID.
    
    Note that although the client names are also used by the interconnect
    framework, interconnect support for the DLA clients has not been added
    and so this issue does not impact the interconnect support.
    
    Fixes: 5cd24ca0985f ("memory: tegra: Add DLA clients for Tegra234")
    Signed-off-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: altera-sysmgr: Call of_node_put() only when of_parse_phandle() takes a ref [+ + +]
Author: Peter Griffin <[email protected]>
Date:   Tue Feb 20 11:50:12 2024 +0000

    mfd: altera-sysmgr: Call of_node_put() only when of_parse_phandle() takes a ref
    
    [ Upstream commit e28c28a34ee9fa2ea671a20e5e7064e6220d55e7 ]
    
    of_parse_phandle() returns a device_node with refcount incremented, which
    the callee needs to call of_node_put() on when done. We should only call
    of_node_put() when the property argument is provided though as otherwise
    nothing has taken a reference on the node.
    
    Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager")
    Signed-off-by: Peter Griffin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: cs42l43: Fix wrong GPIO_FN_SEL and SPI_CLK_CONFIG1 defaults [+ + +]
Author: Maciej Strozek <[email protected]>
Date:   Fri Mar 1 10:15:47 2024 +0000

    mfd: cs42l43: Fix wrong GPIO_FN_SEL and SPI_CLK_CONFIG1 defaults
    
    [ Upstream commit 78334c343bef528b911da83a6b041d15a1a72efb ]
    
    Two regs have wrong values in existing fields, change them to match
    the datasheet.
    
    Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
    
    Signed-off-by: Maciej Strozek <[email protected]>
    Reviewed-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]>

mfd: cs42l43: Fix wrong register defaults [+ + +]
Author: Maciej Strozek <[email protected]>
Date:   Thu Feb 29 15:56:14 2024 +0000

    mfd: cs42l43: Fix wrong register defaults
    
    [ Upstream commit c9e1e505cde1a8ddd0968b4d54ec2ea1937dfe00 ]
    
    A few regs have unnecessary values in defaults, change them to match the
    datasheet
    
    Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
    
    Signed-off-by: Maciej Strozek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: syscon: Call of_node_put() only when of_parse_phandle() takes a ref [+ + +]
Author: Peter Griffin <[email protected]>
Date:   Tue Feb 20 11:50:10 2024 +0000

    mfd: syscon: Call of_node_put() only when of_parse_phandle() takes a ref
    
    [ Upstream commit d2b0680cf3b05490b579e71b0df6e07451977745 ]
    
    of_parse_phandle() returns a device_node with refcount incremented, which
    the callee needs to call of_node_put() on when done. We should only call
    of_node_put() when the property argument is provided though as otherwise
    nothing has taken a reference on the node.
    
    Fixes: 45330bb43421 ("mfd: syscon: Allow property as NULL in syscon_regmap_lookup_by_phandle")
    Signed-off-by: Peter Griffin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mips: cm: Convert __mips_cm_l2sync_phys_base() to weak function [+ + +]
Author: Serge Semin <[email protected]>
Date:   Mon Feb 26 13:54:21 2024 +0300

    mips: cm: Convert __mips_cm_l2sync_phys_base() to weak function
    
    [ Upstream commit 8bc8db2ab2832daabdd06feeabdd511dc9575bb6 ]
    
    The __mips_cm_l2sync_phys_base() and mips_cm_l2sync_phys_base() couple was
    introduced in commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access
    code") where the former method was a weak implementation of the later
    function. Such design pattern permitted to re-define the original method
    and to use the weak implementation in the new function. A similar approach
    was introduced in the framework of another arch-specific programmable
    interface: mips_cm_phys_base() and __mips_cm_phys_base(). The only
    difference is that the underscored method of the later couple was declared
    in the "asm/mips-cm.h" header file, but it wasn't done for the CM L2-sync
    methods in the subject. Due to the missing global function declaration
    the "missing prototype" warning was spotted in the framework of the commit
    9a2036724cd6 ("mips: mark local function static if possible") and fixed
    just be re-qualifying the weak method as static. Doing that broke what was
    originally implied by having the weak implementation globally defined.
    
    Let's fix the broken CM2 L2-sync arch-interface by dropping the static
    qualifier and, seeing the implemented pattern hasn't been used for over 10
    years but will be required soon (see the link for the discussion around
    it), converting it to a single weakly defined method:
    mips_cm_l2sync_phys_base().
    
    Fixes: 9a2036724cd6 ("mips: mark local function static if possible")
    Link: https://lore.kernel.org/linux-mips/[email protected]
    Signed-off-by: Serge Semin <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove function [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Feb 26 22:37:39 2024 +0100

    mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove function
    
    [ Upstream commit ae5004a40a262d329039b99b62bd3fe7645b66ad ]
    
    This looks strange to call release_mem_region() in a remove function
    without any request_mem_region() in the probe or "struct resource"
    somewhere.
    
    So remove the corresponding code.
    
    Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.1708983064.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
modules: wait do_free_init correctly [+ + +]
Author: Changbin Du <[email protected]>
Date:   Tue Feb 27 10:35:46 2024 +0800

    modules: wait do_free_init correctly
    
    [ Upstream commit 8f8cd6c0a43ed637e620bbe45a8d0e0c2f4d5130 ]
    
    The synchronization here is to ensure the ordering of freeing of a module
    init so that it happens before W+X checking.  It is worth noting it is not
    that the freeing was not happening, it is just that our sanity checkers
    raced against the permission checkers which assume init memory is already
    gone.
    
    Commit 1a7b7d922081 ("modules: Use vmalloc special flag") moved calling
    do_free_init() into a global workqueue instead of relying on it being
    called through call_rcu(..., do_free_init), which used to allowed us call
    do_free_init() asynchronously after the end of a subsequent grace period.
    The move to a global workqueue broke the gaurantees for code which needed
    to be sure the do_free_init() would complete with rcu_barrier().  To fix
    this callers which used to rely on rcu_barrier() must now instead use
    flush_work(&init_free_wq).
    
    Without this fix, we still could encounter false positive reports in W+X
    checking since the rcu_barrier() here can not ensure the ordering now.
    
    Even worse, the rcu_barrier() can introduce significant delay.  Eric
    Chanudet reported that the rcu_barrier introduces ~0.1s delay on a
    PREEMPT_RT kernel.
    
      [    0.291444] Freeing unused kernel memory: 5568K
      [    0.402442] Run /sbin/init as init process
    
    With this fix, the above delay can be eliminated.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag")
    Signed-off-by: Changbin Du <[email protected]>
    Tested-by: Eric Chanudet <[email protected]>
    Acked-by: Luis Chamberlain <[email protected]>
    Cc: Xiaoyi Su <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: maps: physmap-core: fix flash size larger than 32-bit [+ + +]
Author: Baruch Siach <[email protected]>
Date:   Thu Feb 8 12:34:18 2024 +0200

    mtd: maps: physmap-core: fix flash size larger than 32-bit
    
    [ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ]
    
    mtd-ram can potentially be larger than 4GB. get_bitmask_order() uses
    fls() that is not guaranteed to work with values larger than 32-bit.
    Specifically on aarch64 fls() returns 0 when all 32 LSB bits are clear.
    Use fls64() instead.
    
    Fixes: ba32ce95cbd987 ("mtd: maps: Merge gpio-addr-flash.c into physmap-core.c")
    Signed-off-by: Baruch Siach <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
    Signed-off-by: Sasha Levin <[email protected]>

mtd: maps: sun_uflash: Declare uflash_devinit static [+ + +]
Author: Sam Ravnborg <[email protected]>
Date:   Sat Feb 24 18:42:24 2024 +0100

    mtd: maps: sun_uflash: Declare uflash_devinit static
    
    [ Upstream commit 6892982316846d4c40d12b0641d59519d868a784 ]
    
    This fixes the following warning:
    sun_uflash.c:50:5: error: no previous prototype for 'uflash_devinit'
    
    Signed-off-by: Sam Ravnborg <[email protected]>
    Fixes: 0fcb70851fbf ("Makefile.extrawarn: turn on missing-prototypes globally")
    Reviewed-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]> # build-tested
    Cc: Andreas Larsson <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Acked-by: Miquel Raynal <[email protected]>
    Signed-off-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20240224-sam-fix-sparc32-all-builds-v2-3-1f186603c5c4@ravnborg.org
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: brcmnand: exec_op helper functions return type fixes [+ + +]
Author: David Regan <[email protected]>
Date:   Thu Feb 22 19:47:46 2024 -0800

    mtd: rawnand: brcmnand: exec_op helper functions return type fixes
    
    [ Upstream commit d4bba1501f72e8af09f2cde3d327147de1b69f5d ]
    
    Fix return types for exec_op reset and status helper functions.
    
    Reported-by: Dan Carpenter <[email protected]>
    Closes: http://lists.infradead.org/pipermail/linux-mtd/2023-December/102423.html
    Fixes: 3c8260ce7663 ("mtd: rawnand: brcmnand: exec_op implementation")
    Signed-off-by: David Regan <[email protected]>
    Signed-off-by: William Zhang <[email protected]>
    Reviewed-by: William Zhang <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: lpc32xx_mlc: fix irq handler prototype [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:00:09 2024 +0100

    mtd: rawnand: lpc32xx_mlc: fix irq handler prototype
    
    [ Upstream commit 347b828882e6334690e7003ce5e2fe5f233dc508 ]
    
    clang-16 warns about mismatched function prototypes:
    
    drivers/mtd/nand/raw/lpc32xx_mlc.c:783:29: error: cast from 'irqreturn_t (*)(int, struct lpc32xx_nand_host *)' (aka 'enum irqreturn (*)(int, struct lpc32xx_nand_host *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Change the interrupt handler to the normal way of just passing
    a void* pointer and converting it inside the function..
    
    Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: spinand: esmt: Extend IDs to 5 bytes [+ + +]
Author: Ezra Buehler <[email protected]>
Date:   Thu Jan 25 22:01:08 2024 +0200

    mtd: spinand: esmt: Extend IDs to 5 bytes
    
    [ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ]
    
    According to the datasheets, the ESMT chips in question will return a 5
    byte long identification code where the last 3 bytes are the JEDEC
    continuation codes (7Fh). Although, I would have expected 4 continuation
    codes as Powerchip Semiconductor (C8h, corresponding to the parameter
    page data) is located in bank 5 of the JEDEC database.
    
    By matching the full 5 bytes we can avoid clashes with GigaDevice NAND
    flashes.
    
    This fix allows the MT7688-based GARDENA smart Gateway to boot again.
    
    Fixes: aa08bf187f32 ("mtd: spinand: esmt: add support for F50D2G41KA")
    Signed-off-by: Ezra Buehler <[email protected]>
    Reviewed-by: Martin Kurbanov <[email protected]>
    Tested-by: Martin Kurbanov <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
nbd: null check for nla_nest_start [+ + +]
Author: Navid Emamdoost <[email protected]>
Date:   Sat Feb 17 20:25:38 2024 -0800

    nbd: null check for nla_nest_start
    
    [ Upstream commit 31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d ]
    
    nla_nest_start() may fail and return NULL. Insert a check and set errno
    based on other call sites within the same source code.
    
    Signed-off-by: Navid Emamdoost <[email protected]>
    Reviewed-by: Michal Kubecek <[email protected]>
    Fixes: 47d902b90a32 ("nbd: add a status netlink command")
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/bnx2x: Prevent access to a freed page in page_pool [+ + +]
Author: Thinh Tran <[email protected]>
Date:   Fri Mar 15 15:55:35 2024 -0500

    net/bnx2x: Prevent access to a freed page in page_pool
    
    [ Upstream commit d27e2da94a42655861ca4baea30c8cd65546f25d ]
    
    Fix race condition leading to system crash during EEH error handling
    
    During EEH error recovery, the bnx2x driver's transmit timeout logic
    could cause a race condition when handling reset tasks. The
    bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
    which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
    SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
    overlap with the EEH driver's attempt to reset the device using
    bnx2x_io_slot_reset(), which also tries to free SGEs. This race
    condition can result in system crashes due to accessing freed memory
    locations in bnx2x_free_rx_sge()
    
    799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
    800                             struct bnx2x_fastpath *fp, u16 index)
    801  {
    802     struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
    803     struct page *page = sw_buf->page;
    ....
    where sw_buf was set to NULL after the call to dma_unmap_page()
    by the preceding thread.
    
        EEH: Beginning: 'slot_reset'
        PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
        bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
        bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
        bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
        Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
        BUG: Kernel NULL pointer dereference on read at 0x00000000
        Faulting instruction address: 0xc0080000025065fc
        Oops: Kernel access of bad area, sig: 11 [#1]
        .....
        Call Trace:
        [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
        [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
        [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
        [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
        [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
        [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
        [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
    
    To solve this issue, we need to verify page pool allocations before
    freeing.
    
    Fixes: 4cace675d687 ("bnx2x: Alloc 4k fragment for each rx ring buffer element")
    Signed-off-by: Thinh Tran <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Mar 11 20:46:28 2024 +0000

    net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
    
    [ Upstream commit 343041b59b7810f9cdca371f445dd43b35c740b1 ]
    
    taprio_parse_tc_entry() is not correctly checking
    TCA_TAPRIO_TC_ENTRY_INDEX attribute:
    
            int tc; // Signed value
    
            tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
            if (tc >= TC_QOPT_MAX_QUEUE) {
                    NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");
                    return -ERANGE;
            }
    
    syzbot reported that it could fed arbitary negative values:
    
    UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18
    shift exponent -2147418108 is negative
    CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
      ubsan_epilogue lib/ubsan.c:217 [inline]
      __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386
      taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline]
      taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline]
      taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877
      taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134
      qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355
      tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776
      rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617
      netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
      netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
      netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
      netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x221/0x270 net/socket.c:745
      ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
      ___sys_sendmsg net/socket.c:2638 [inline]
      __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
     do_syscall_64+0xf9/0x240
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f1b2dea3759
    Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759
    RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004
    RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000
    R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340
    R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340
    
    Fixes: a54fc09e4cba ("net/sched: taprio: allow user input of per-tc max SDU")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Vladimir Oltean <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/x25: fix incorrect parameter validation in the x25_getsockopt() function [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

    net/x25: fix incorrect parameter validation in the x25_getsockopt() function
    
    [ Upstream commit d6eb8de2015f0c24822e47356f839167ebde2945 ]
    
    The 'len' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'len' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: blackhole_dev: fix build warning for ethh set but not used [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Fri Feb 2 07:13:29 2024 -0800

    net: blackhole_dev: fix build warning for ethh set but not used
    
    [ Upstream commit 843a8851e89e2e85db04caaf88d8554818319047 ]
    
    lib/test_blackhole_dev.c sets a variable that is never read, causing
    this following building warning:
    
            lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used [-Wunused-but-set-variable]
    
    Remove the variable struct ethhdr *ethh, which is unused.
    
    Fixes: 509e56b37cc3 ("blackhole_dev: add a selftest")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: microchip: make sure drive strength configuration is not lost by soft reset [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Mon Mar 4 14:56:12 2024 +0100

    net: dsa: microchip: make sure drive strength configuration is not lost by soft reset
    
    [ Upstream commit e3fb8e8ba72b053d05ca2602acdd6b869f9f296f ]
    
    This driver has two separate reset sequence in different places:
    - gpio/HW reset on start of ksz_switch_register()
    - SW reset on start of ksz_setup()
    
    The second one will overwrite drive strength configuration made in the
    ksz_switch_register().
    
    To fix it, move ksz_parse_drive_strength() from ksz_switch_register() to
    ksz_setup().
    
    Fixes: d67d7247f641 ("net: dsa: microchip: Add drive strength configuration")
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: fix handling of all link-local frames [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:33:42 2024 +0300

    net: dsa: mt7530: fix handling of all link-local frames
    
    [ Upstream commit 69ddba9d170bdaee1dc0eb4ced38d7e4bb7b92af ]
    
    Currently, the MT753X switches treat frames with :01-0D and :0F MAC DAs as
    regular multicast frames, therefore flooding them to user ports.
    
    On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE
    Std 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC
    DA must only be propagated to C-VLAN and MAC Bridge components. That means
    VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports,
    these frames are supposed to be processed by the CPU (software). So we make
    the switch only forward them to the CPU port. And if received from a CPU
    port, forward to a single port. The software is responsible of making the
    switch conform to the latter by setting a single port as destination port
    on the special tag.
    
    This switch intellectual property cannot conform to this part of the
    standard fully. Whilst the REV_UN frame tag covers the remaining :04-0D and
    :0F MAC DAs, it also includes :22-FF which the scope of propagation is not
    supposed to be restricted for these MAC DAs.
    
    Set frames with :01-03 MAC DAs to be trapped to the CPU port(s). Add a
    comment for the remaining MAC DAs.
    
    Note that the ingress port must have a PVID assigned to it for the switch
    to forward untagged frames. A PVID is set by default on VLAN-aware and
    VLAN-unaware ports. However, when the network interface that pertains to
    the ingress port is attached to a vlan_filtering enabled bridge, the user
    can remove the PVID assignment from it which would prevent the link-local
    frames from being trapped to the CPU port. I am yet to see a way to forward
    link-local frames while preventing other untagged frames from being
    forwarded too.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:33:41 2024 +0300

    net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
    
    [ Upstream commit e8bf353577f382c7066c661fed41b2adc0fc7c40 ]
    
    Whether VLAN-aware or not, on every VID VLAN table entry that has the CPU
    port as a member of it, frames are set to egress the CPU port with the VLAN
    tag stacked. This is so that VLAN tags can be appended after hardware
    special tag (called DSA tag in the context of Linux drivers).
    
    For user ports on a VLAN-unaware bridge, frame ingressing the user port
    egresses CPU port with only the special tag.
    
    For user ports on a VLAN-aware bridge, frame ingressing the user port
    egresses CPU port with the special tag and the VLAN tag.
    
    This causes issues with link-local frames, specifically BPDUs, because the
    software expects to receive them VLAN-untagged.
    
    There are two options to make link-local frames egress untagged. Setting
    CONSISTENT or UNTAGGED on the EG_TAG bits on the relevant register.
    CONSISTENT means frames egress exactly as they ingress. That means
    egressing with the VLAN tag they had at ingress or egressing untagged if
    they ingressed untagged. Although link-local frames are not supposed to be
    transmitted VLAN-tagged, if they are done so, when egressing through a CPU
    port, the special tag field will be broken.
    
    BPDU egresses CPU port with VLAN tag egressing stacked, received on
    software:
    
    00:01:25.104821 AF Unknown (382365846), length 106:
                                         | STAG  | | VLAN  |
            0x0000:  0000 6c27 614d 4143 0001 0000 8100 0001  ..l'aMAC........
            0x0010:  0026 4242 0300 0000 0000 0000 6c27 614d  .&BB........l'aM
            0x0020:  4143 0000 0000 0000 6c27 614d 4143 0000  AC......l'aMAC..
            0x0030:  0000 1400 0200 0f00 0000 0000 0000 0000  ................
    
    BPDU egresses CPU port with VLAN tag egressing untagged, received on
    software:
    
    00:23:56.628708 AF Unknown (25215488), length 64:
                                         | STAG  |
            0x0000:  0000 6c27 614d 4143 0001 0000 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    BPDU egresses CPU port with VLAN tag egressing tagged, received on
    software:
    
    00:01:34.311963 AF Unknown (25215488), length 64:
                                         | Mess  |
            0x0000:  0000 6c27 614d 4143 0001 0001 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    To prevent confusing the software, force the frame to egress UNTAGGED
    instead of CONSISTENT. This way, frames can't possibly be received TAGGED
    by software which would have the special tag field broken.
    
    VLAN Tag Egress Procedure
    
       For all frames, one of these options set the earliest in this order will
       apply to the frame:
    
       - EG_TAG in certain registers for certain frames.
         This will apply to frame with matching MAC DA or EtherType.
    
       - EG_TAG in the address table.
         This will apply to frame at its incoming port.
    
       - EG_TAG in the PVC register.
         This will apply to frame at its incoming port.
    
       - EG_CON and [EG_TAG per port] in the VLAN table.
         This will apply to frame at its outgoing port.
    
       - EG_TAG in the PCR register.
         This will apply to frame at its outgoing port.
    
       EG_TAG in certain registers for certain frames:
    
       PPPoE Discovery_ARP/RARP: PPP_EG_TAG and ARP_EG_TAG in the APC register.
       IGMP_MLD: IGMP_EG_TAG and MLD_EG_TAG in the IMC register.
       BPDU and PAE: BPDU_EG_TAG and PAE_EG_TAG in the BPC register.
       REV_01 and REV_02: R01_EG_TAG and R02_EG_TAG in the RGAC1 register.
       REV_03 and REV_0E: R03_EG_TAG and R0E_EG_TAG in the RGAC2 register.
       REV_10 and REV_20: R10_EG_TAG and R20_EG_TAG in the RGAC3 register.
       REV_21 and REV_UN: R21_EG_TAG and RUN_EG_TAG in the RGAC4 register.
    
    With this change, it can be observed that a bridge interface with stp_state
    and vlan_filtering enabled will properly block ports now.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: prevent possible incorrect XTAL frequency selection [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:28:35 2024 +0300

    net: dsa: mt7530: prevent possible incorrect XTAL frequency selection
    
    [ Upstream commit f490c492e946d8ffbe65ad4efc66de3c5ede30a4 ]
    
    On MT7530, the HT_XTAL_FSEL field of the HWTRAP register stores a 2-bit
    value that represents the frequency of the crystal oscillator connected to
    the switch IC. The field is populated by the state of the ESW_P4_LED_0 and
    ESW_P4_LED_0 pins, which is done right after reset is deasserted.
    
      ESW_P4_LED_0    ESW_P3_LED_0    Frequency
      -----------------------------------------
      0               0               Reserved
      0               1               20MHz
      1               0               40MHz
      1               1               25MHz
    
    On MT7531, the XTAL25 bit of the STRAP register stores this. The LAN0LED0
    pin is used to populate the bit. 25MHz when the pin is high, 40MHz when
    it's low.
    
    These pins are also used with LEDs, therefore, their state can be set to
    something other than the bootstrapping configuration. For example, a link
    may be established on port 3 before the DSA subdriver takes control of the
    switch which would set ESW_P3_LED_0 to high.
    
    Currently on mt7530_setup() and mt7531_setup(), 1000 - 1100 usec delay is
    described between reset assertion and deassertion. Some switch ICs in real
    life conditions cannot always have these pins set back to the bootstrapping
    configuration before reset deassertion in this amount of delay. This causes
    wrong crystal frequency to be selected which puts the switch in a
    nonfunctional state after reset deassertion.
    
    The tests below are conducted on an MT7530 with a 40MHz crystal oscillator
    by Justin Swartz.
    
    With a cable from an active peer connected to port 3 before reset, an
    incorrect crystal frequency (0b11 = 25MHz) is selected:
    
                          [1]                  [3]     [5]
                          :                    :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  _____________________________
    ESW_P3_LED_0                               |__________________________
    
                           :                  : :     :
                           :                  : [4]...:
                           :                  :
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 1000 - 1100 usec.
    [3] Reset is deasserted.
    [4] Period of 315 usec. HWTRAP register is populated with incorrect
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    Increase the delay between reset_control_assert() and
    reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and
    gpiod_set_value_cansleep(priv->reset, 1) to 5000 - 5100 usec. This amount
    ensures a higher possibility that the switch IC will have these pins back
    to the bootstrapping configuration before reset deassertion.
    
    With a cable from an active peer connected to port 3 before reset, the
    correct crystal frequency (0b10 = 40MHz) is selected:
    
                          [1]        [2-1]     [3]     [5]
                          :          :         :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  ___________________           _______
    ESW_P3_LED_0                     |_________|       |__________________
    
                           :          :       : :     :
                           :          [2-2]...: [4]...:
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 5000 - 5100 usec.
    [2-1] ESW_P3_LED_0 goes low.
    [2-2] Remaining period of 5000 - 5100 usec.
    [3] Reset is deasserted.
    [4] Period of 310 usec. HWTRAP register is populated with bootstrapped
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    ESW_P3_LED_0 low period before reset deassertion:
    
                  5000 usec
                - 5100 usec
        TEST     RESET HOLD
           #         (usec)
      ---------------------
           1           5410
           2           5440
           3           4375
           4           5490
           5           5475
           6           4335
           7           4370
           8           5435
           9           4205
          10           4335
          11           3750
          12           3170
          13           4395
          14           4375
          15           3515
          16           4335
          17           4220
          18           4175
          19           4175
          20           4350
    
         Min           3170
         Max           5490
    
      Median       4342.500
         Avg       4466.500
    
    Revert commit 2920dd92b980 ("net: dsa: mt7530: disable LEDs before reset").
    Changing the state of pins via reset assertion is simpler and more
    efficient than doing so by setting the LED controller off.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")
    Co-developed-by: Justin Swartz <[email protected]>
    Signed-off-by: Justin Swartz <[email protected]>
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Remove ena_select_queue [+ + +]
Author: Kamal Heib <[email protected]>
Date:   Thu Feb 15 17:31:04 2024 -0500

    net: ena: Remove ena_select_queue
    
    [ Upstream commit 78e886ba2b549945ecada055ee0765f0ded5707a ]
    
    Avoid the following warnings by removing the ena_select_queue() function
    and rely on the net core to do the queue selection, The issue happen
    when an skb received from an interface with more queues than ena is
    forwarded to the ena interface.
    
    [ 1176.159959] eth0 selects TX queue 11, but real number of TX queues is 8
    [ 1176.863976] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1180.767877] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1188.703742] eth0 selects TX queue 14, but real number of TX queues is 8
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Kamal Heib <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: mtk_eth_soc: fix PPE hanging issue [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:40 2024 +0000

    net: ethernet: mtk_eth_soc: fix PPE hanging issue
    
    [ Upstream commit ea80e3ed09ab2c2b75724faf5484721753e92c31 ]
    
    A patch to resolve an issue was found in MediaTek's GPL-licensed SDK:
    In the mtk_ppe_stop() function, the PPE scan mode is not disabled before
    disabling the PPE. This can potentially lead to a hang during the process
    of disabling the PPE.
    
    Without this patch, the PPE may experience a hang during the reboot test.
    
    Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b40da332dfe763932a82f9f62a4709457a15dd6c
    Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
    Suggested-by: Bc-bocun Chen <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix kernel crash when 1588 is received on HIP08 devices [+ + +]
Author: Yonglong Liu <[email protected]>
Date:   Thu Mar 7 09:01:11 2024 +0800

    net: hns3: fix kernel crash when 1588 is received on HIP08 devices
    
    [ Upstream commit 0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3 ]
    
    The HIP08 devices does not register the ptp devices, so the
    hdev->ptp is NULL, but the hardware can receive 1588 messages,
    and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
    access of hdev->ptp->flags will cause a kernel crash:
    
    [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    ...
    [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
    [ 5889.279101] sp : ffff800012c3bc50
    [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
    [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
    [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
    [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
    [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
    [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
    [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
    [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
    [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
    [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
    [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
    [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
    [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
    [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
    [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
    [ 5889.378857] Call trace:
    [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
    [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
    [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
    [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
    [ 5889.411084] napi_poll+0xcc/0x264
    [ 5889.415329] net_rx_action+0xd4/0x21c
    [ 5889.419911] __do_softirq+0x130/0x358
    [ 5889.424484] irq_exit+0x134/0x154
    [ 5889.428700] __handle_domain_irq+0x88/0xf0
    [ 5889.433684] gic_handle_irq+0x78/0x2c0
    [ 5889.438319] el1_irq+0xb8/0x140
    [ 5889.442354] arch_cpu_idle+0x18/0x40
    [ 5889.446816] default_idle_call+0x5c/0x1c0
    [ 5889.451714] cpuidle_idle_call+0x174/0x1b0
    [ 5889.456692] do_idle+0xc8/0x160
    [ 5889.460717] cpu_startup_entry+0x30/0xfc
    [ 5889.465523] secondary_start_kernel+0x158/0x1ec
    [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
    [ 5889.477950] SMP: stopping secondary CPUs
    [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
    [ 5890.522951] Starting crashdump kernel...
    
    Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
    Signed-off-by: Yonglong Liu <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix port duplex configure error in IMP reset [+ + +]
Author: Jie Wang <[email protected]>
Date:   Thu Mar 7 09:01:14 2024 +0800

    net: hns3: fix port duplex configure error in IMP reset
    
    [ Upstream commit 11d80f79dd9f871a52feba4bf24b5ac39f448eb7 ]
    
    Currently, the mac port is fixed to configured as full dplex mode in
    hclge_mac_init() when driver initialization or reset restore. Users may
    change the mode to half duplex with ethtool,  so it may cause the user
    configuration dropped after reset.
    
    To fix it, don't change the duplex mode when resetting.
    
    Fixes: 2d03eacc0b7e ("net: hns3: Only update mac configuation when necessary")
    Signed-off-by: Jie Wang <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix wrong judgment condition issue [+ + +]
Author: Jijie Shao <[email protected]>
Date:   Thu Mar 7 09:01:08 2024 +0800

    net: hns3: fix wrong judgment condition issue
    
    [ Upstream commit 07a1d6dc90baedcf5d713e2b003b9e387130ee30 ]
    
    In hns3_dcbnl_ieee_delapp, should check ieee_delapp not ieee_setapp.
    This path fix the wrong judgment.
    
    Fixes: 0ba22bcb222d ("net: hns3: add support config dscp map to tc")
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 7 10:07:16 2024 +0000

    net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()
    
    [ Upstream commit b0ec2abf98267f14d032102551581c833b0659d3 ]
    
    Apply the same fix than ones found in :
    
    8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
    1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")
    
    We have to save skb->network_header in a temporary variable
    in order to be able to recompute the network_header pointer
    after a pskb_inet_may_pull() call.
    
    pskb_inet_may_pull() makes sure the needed headers are in skb->head.
    
    syzbot reported:
    BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
     BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
     BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
     BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
      INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
      IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
      ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
      ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
      gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
      gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
      ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
      ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
      dst_input include/net/dst.h:461 [inline]
      ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
      __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
      __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
      netif_receive_skb_internal net/core/dev.c:5734 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5793
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
      tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
      __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
      alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
      alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
      skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
      tun_build_skb drivers/net/tun.c:1686 [inline]
      tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: kcm: fix incorrect parameter validation in the kcm_getsockopt) function [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

    net: kcm: fix incorrect parameter validation in the kcm_getsockopt) function
    
    [ Upstream commit 3ed5f415133f9b7518fbe55ba9ae9a3f5e700929 ]
    
    The 'len' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'len' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mctp: copy skb ext data when fragmenting [+ + +]
Author: Jeremy Kerr <[email protected]>
Date:   Mon Feb 19 17:51:54 2024 +0800

    net: mctp: copy skb ext data when fragmenting
    
    [ Upstream commit 1394c1dec1c619a46867ed32791a29695372bff8 ]
    
    If we're fragmenting on local output, the original packet may contain
    ext data for the MCTP flows. We'll want this in the resulting fragment
    skbs too.
    
    So, do a skb_ext_copy() in the fragmentation path, and implement the
    MCTP-specific parts of an ext copy operation.
    
    Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers")
    Reported-by: Jian Zhang <[email protected]>
    Signed-off-by: Jeremy Kerr <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mediatek: mtk_eth_soc: clear MAC_MCR_FORCE_LINK only when MAC is up [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:18 2024 +0000

    net: mediatek: mtk_eth_soc: clear MAC_MCR_FORCE_LINK only when MAC is up
    
    [ Upstream commit f1b85ef15a99f06ed48871ce933d591127d2dcc0 ]
    
    Clearing bit MAC_MCR_FORCE_LINK which forces the link down too early
    can result in MAC ending up in a broken/blocked state.
    
    Fix this by handling this bit in the .mac_link_up and .mac_link_down
    calls instead of in .mac_finish.
    
    Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support")
    Suggested-by: Mason-cw Chang <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: move dev->state into net_device_read_txrx group [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 14 20:08:45 2024 +0000

    net: move dev->state into net_device_read_txrx group
    
    [ Upstream commit f6e0a4984c2e7244689ea87b62b433bed9d07e94 ]
    
    dev->state can be read in rx and tx fast paths.
    
    netif_running() which needs dev->state is called from
    - enqueue_to_backlog() [RX path]
    - __dev_direct_xmit()  [TX path]
    
    Fixes: 43a71cd66b9c ("net-device: reorganize net_device fast path variables")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Coco Li <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: dp83822: Fix RGMII TX delay configuration [+ + +]
Author: Tim Pambor <[email protected]>
Date:   Tue Mar 5 12:06:08 2024 +0100

    net: phy: dp83822: Fix RGMII TX delay configuration
    
    [ Upstream commit c8a5c731fd1223090af57da33838c671a7fc6a78 ]
    
    The logic for enabling the TX clock shift is inverse of enabling the RX
    clock shift. The TX clock shift is disabled when DP83822_TX_CLK_SHIFT is
    set. Correct the current behavior and always write the delay configuration
    to ensure consistent delay settings regardless of bootloader configuration.
    
    Reference: https://www.ti.com/lit/ds/symlink/dp83822i.pdf p. 69
    
    Fixes: 8095295292b5 ("net: phy: DP83822: Add setting the fixed internal delay")
    Signed-off-by: Tim Pambor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: fix phy_get_internal_delay accessing an empty array [+ + +]
Author: Kévin L'hôpital <[email protected]>
Date:   Thu Mar 7 12:19:06 2024 +0100

    net: phy: fix phy_get_internal_delay accessing an empty array
    
    [ Upstream commit 4469c0c5b14a0919f5965c7ceac96b523eb57b79 ]
    
    The phy_get_internal_delay function could try to access to an empty
    array in the case that the driver is calling phy_get_internal_delay
    without defining delay_values and rx-internal-delay-ps or
    tx-internal-delay-ps is defined to 0 in the device-tree.
    This will lead to "unable to handle kernel NULL pointer dereference at
    virtual address 0". To avoid this kernel oops, the test should be delay
    >= 0. As there is already delay < 0 test just before, the test could
    only be size == 0.
    
    Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the internal delay")
    Co-developed-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Kévin L'hôpital <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: fix phy_read_poll_timeout argument type in genphy_loopback [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Fri Mar 15 20:50:52 2024 +0300

    net: phy: fix phy_read_poll_timeout argument type in genphy_loopback
    
    [ Upstream commit 32fa4366cc4da1c97b725a0066adf43c6b298f37 ]
    
    read_poll_timeout inside phy_read_poll_timeout can set val negative
    in some cases (for example, __mdiobus_read inside phy_read can return
    -EOPNOTSUPP).
    
    Supposedly, commit 4ec732951702 ("net: phylib: fix phy_read*_poll_timeout()")
    should fix problems with wrong-signed vals, but I do not see how
    as val is sent to phy_read as is and __val = phy_read (not val)
    is checked for sign.
    
    Change val type for signed to allow better error handling as done in other
    phy_read_poll_timeout callers. This will not fix any error handling
    by itself, but allows, for example, to modify cond with appropriate
    sign check or check resulting val separately.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 014068dcb5b1 ("net: phy: genphy_loopback: add link speed configuration")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: report RCU QS on threaded NAPI repolling [+ + +]
Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:37 2024 -0700

    net: report RCU QS on threaded NAPI repolling
    
    [ Upstream commit d6dbbb11247c71203785a2c9da474c36f4b19eae ]
    
    NAPI threads can keep polling packets under load. Currently it is only
    calling cond_resched() before repolling, but it is not sufficient to
    clear out the holdout of RCU tasks, which prevent BPF tracing programs
    from detaching for long period. This can be reproduced easily with
    following set up:
    
    ip netns add test1
    ip netns add test2
    
    ip -n test1 link add veth1 type veth peer name veth2 netns test2
    
    ip -n test1 link set veth1 up
    ip -n test1 link set lo up
    ip -n test2 link set veth2 up
    ip -n test2 link set lo up
    
    ip -n test1 addr add 192.168.1.2/31 dev veth1
    ip -n test1 addr add 1.1.1.1/32 dev lo
    ip -n test2 addr add 192.168.1.3/31 dev veth2
    ip -n test2 addr add 2.2.2.2/31 dev lo
    
    ip -n test1 route add default via 192.168.1.3
    ip -n test2 route add default via 192.168.1.2
    
    for i in `seq 10 210`; do
     for j in `seq 10 210`; do
        ip netns exec test2 iptables -I INPUT -s 3.3.$i.$j -p udp --dport 5201
     done
    done
    
    ip netns exec test2 ethtool -K veth2 gro on
    ip netns exec test2 bash -c 'echo 1 > /sys/class/net/veth2/threaded'
    ip netns exec test1 ethtool -K veth1 tso off
    
    Then run an iperf3 client/server and a bpftrace script can trigger it:
    
    ip netns exec test2 iperf3 -s -B 2.2.2.2 >/dev/null&
    ip netns exec test1 iperf3 -c 2.2.2.2 -B 1.1.1.1 -u -l 1500 -b 3g -t 100 >/dev/null&
    bpftrace -e 'kfunc:__napi_poll{@=count();} interval:s:1{exit();}'
    
    Report RCU quiescent states periodically will resolve the issue.
    
    Fixes: 29863d41bb6e ("net: implement threaded-able napi poll loop support")
    Reviewed-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/r/4c3b0d3f32d3b18949d75b18e5e1d9f13a24f025.1710877680.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Tue Oct 24 23:58:20 2023 +0200

    net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr()
    
    [ Upstream commit d6f4de70f73a106986ee315d7d512539f2f3303a ]
    
    The intent is to check if the strings' are truncated or not. So, >= should
    be used instead of >, because strlcat() and snprintf() return the length of
    the output, excluding the trailing NULL.
    
    Fixes: a02d69261134 ("SUNRPC: Provide functions for managing universal addresses")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: test: Fix printf format specifier in skb_segment kunit test [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:19 2024 +0800

    net: test: Fix printf format specifier in skb_segment kunit test
    
    [ Upstream commit ff3b96f2c9e5c24fca12239cd519a8a18569e687 ]
    
    KUNIT_FAIL() accepts a printf-style format string, but previously did
    not let gcc validate it with the __printf() attribute. The use of %lld
    for the result of PTR_ERR() is not correct.
    
    Instead, use %pe and pass the actual error pointer. printk() will format
    it correctly (and give a symbolic name rather than a number if
    available, which should make the output more readable, too).
    
    Fixes: b3098d32ed6e ("net: add skb_segment kunit test")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: fix clk_name exceed MAX_DEV_ID limits [+ + +]
Author: Duanqiang Wen <[email protected]>
Date:   Wed Mar 13 16:06:34 2024 +0800

    net: txgbe: fix clk_name exceed MAX_DEV_ID limits
    
    [ Upstream commit e30cef001da259e8df354b813015d0e5acc08740 ]
    
    txgbe register clk which name is i2c_designware.pci_dev_id(),
    clk_name will be stored in clk_lookup_alloc. If PCIe bus number
    is larger than 0x39, clk_name size will be larger than 20 bytes.
    It exceeds clk_lookup_alloc MAX_DEV_ID limits. So the driver
    shortened clk_name.
    
    Fixes: b63f20485e43 ("net: txgbe: Register fixed rate clock")
    Signed-off-by: Duanqiang Wen <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: veth: do not manipulate GRO when using XDP [+ + +]
Author: Ignat Korchagin <[email protected]>
Date:   Wed Mar 13 19:37:58 2024 +0100

    net: veth: do not manipulate GRO when using XDP
    
    [ Upstream commit d7db7775ea2e31502d46427f5efd385afc4ff1eb ]
    
    Commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP") tried to fix
    the fact that GRO was not possible without XDP, because veth did not use NAPI
    without XDP. However, it also introduced the behaviour that GRO is always
    enabled, when XDP is enabled.
    
    While it might be desired for most cases, it is confusing for the user at best
    as the GRO flag suddenly changes, when an XDP program is attached. It also
    introduces some complexities in state management as was partially addressed in
    commit fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down").
    
    But the biggest problem is that it is not possible to disable GRO at all, when
    an XDP program is attached, which might be needed for some use cases.
    
    Fix this by not touching the GRO flag on XDP enable/disable as the code already
    supports switching to NAPI if either GRO or XDP is requested.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP")
    Fixes: fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down")
    Signed-off-by: Ignat Korchagin <[email protected]>
    Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nf_tables: do not compare internal table flags on updates [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Mar 14 18:51:38 2024 +0100

    netfilter: nf_tables: do not compare internal table flags on updates
    
    [ Upstream commit 4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139 ]
    
    Restore skipping transaction if table update does not modify flags.
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: Fix a memory leak in nf_tables_updchain [+ + +]
Author: Quan Tian <[email protected]>
Date:   Thu Mar 7 01:24:02 2024 +0800

    netfilter: nf_tables: Fix a memory leak in nf_tables_updchain
    
    [ Upstream commit 7eaf837a4eb5f74561e2486972e7f5184b613f6e ]
    
    If nft_netdev_register_hooks() fails, the memory associated with
    nft_stats is not freed, causing a memory leak.
    
    This patch fixes it by moving nft_stats_alloc() down after
    nft_netdev_register_hooks() succeeds.
    
    Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain")
    Signed-off-by: Quan Tian <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_set_pipapo: release elements in clone only from destroy path [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Mar 10 10:02:41 2024 +0100

    netfilter: nft_set_pipapo: release elements in clone only from destroy path
    
    [ Upstream commit b0e256f3dd2ba6532f37c5c22e07cb07a36031ee ]
    
    Clone already always provides a current view of the lookup table, use it
    to destroy the set, otherwise it is possible to destroy elements twice.
    
    This fix requires:
    
     212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
    
    which came after:
    
     9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").
    
    Fixes: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfp: flower: handle acti_netdevs allocation failure [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Fri Mar 8 22:25:40 2024 +0800

    nfp: flower: handle acti_netdevs allocation failure
    
    [ Upstream commit 84e95149bd341705f0eca6a7fcb955c548805002 ]
    
    The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
    the physical memory has run out. As a result, if we dereference
    the acti_netdevs, the null pointer dereference bugs will happen.
    
    This patch adds a check to judge whether allocation failure occurs.
    If it happens, the delayed work will be rescheduled and try again.
    
    Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups")
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Louis Peens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Fix an off by one in root_nfs_cat() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Feb 18 22:16:53 2024 +0100

    NFS: Fix an off by one in root_nfs_cat()
    
    [ Upstream commit 698ad1a538da0b6bf969cfee630b4e3a026afb87 ]
    
    The intent is to check if 'dest' is truncated or not. So, >= should be
    used instead of >, because strlcat() returns the length of 'dest' and 'src'
    excluding the trailing NULL.
    
    Fixes: 56463e50d1fc ("NFS: Use super.c for NFSROOT mount option parsing")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt [+ + +]
Author: Dave Wysochanski <[email protected]>
Date:   Wed Jan 31 11:10:06 2024 -0500

    NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt
    
    [ Upstream commit fd5860ab6341506004219b080aea40213b299d2e ]
    
    The loop inside nfs_netfs_issue_read() currently does not disable
    interrupts while iterating through pages in the xarray to submit
    for NFS read.  This is not safe though since after taking xa_lock,
    another page in the mapping could be processed for writeback inside
    an interrupt, and deadlock can occur.  The fix is simple and clean
    if we use xa_for_each_range(), which handles the iteration with RCU
    while reducing code complexity.
    
    The problem is easily reproduced with the following test:
     mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs
     dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1
     echo 3 > /proc/sys/vm/drop_caches
     dd if=/mnt/nfs/file1.bin of=/dev/null
     umount /mnt/nfs
    
    On the console with a lockdep-enabled kernel a message similar to
    the following will be seen:
    
     ================================
     WARNING: inconsistent lock state
     6.7.0-lockdbg+ #10 Not tainted
     --------------------------------
     inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
     test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:
     ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at:
    nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
     {IN-SOFTIRQ-W} state was registered at:
       lock_acquire+0x144/0x380
       _raw_spin_lock_irqsave+0x4e/0xa0
       __folio_end_writeback+0x17e/0x5c0
       folio_end_writeback+0x93/0x1b0
       iomap_finish_ioend+0xeb/0x6a0
       blk_update_request+0x204/0x7f0
       blk_mq_end_request+0x30/0x1c0
       blk_complete_reqs+0x7e/0xa0
       __do_softirq+0x113/0x544
       __irq_exit_rcu+0xfe/0x120
       irq_exit_rcu+0xe/0x20
       sysvec_call_function_single+0x6f/0x90
       asm_sysvec_call_function_single+0x1a/0x20
       pv_native_safe_halt+0xf/0x20
       default_idle+0x9/0x20
       default_idle_call+0x67/0xa0
       do_idle+0x2b5/0x300
       cpu_startup_entry+0x34/0x40
       start_secondary+0x19d/0x1c0
       secondary_startup_64_no_verify+0x18f/0x19b
     irq event stamp: 176891
     hardirqs last  enabled at (176891): [<ffffffffa67a0be4>]
    _raw_spin_unlock_irqrestore+0x44/0x60
     hardirqs last disabled at (176890): [<ffffffffa67a0899>]
    _raw_spin_lock_irqsave+0x79/0xa0
     softirqs last  enabled at (176646): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
     softirqs last disabled at (176633): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&xa->xa_lock#4);
       <Interrupt>
         lock(&xa->xa_lock#4);
    
      *** DEADLOCK ***
    
     2 locks held by test5/1708:
      #0: ffff888127baa498 (&sb->s_type->i_mutex_key#22){++++}-{4:4}, at:
          nfs_start_io_read+0x28/0x90 [nfs]
      #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:
          page_cache_ra_unbounded+0xa4/0x280
    
     stack backtrace:
     CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
    04/01/2014
     Call Trace:
      dump_stack_lvl+0x5b/0x90
      mark_lock+0xb3f/0xd20
      __lock_acquire+0x77b/0x3360
      _raw_spin_lock+0x34/0x80
      nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
      netfs_begin_read+0x77f/0x980 [netfs]
      nfs_netfs_readahead+0x45/0x60 [nfs]
      nfs_readahead+0x323/0x5a0 [nfs]
      read_pages+0xf3/0x5c0
      page_cache_ra_unbounded+0x1c8/0x280
      filemap_get_pages+0x38c/0xae0
      filemap_read+0x206/0x5e0
      nfs_file_read+0xb7/0x140 [nfs]
      vfs_read+0x2a9/0x460
      ksys_read+0xb7/0x140
    
    Fixes: 000dbe0bec05 ("NFS: Convert buffered read paths to use netfs when fscache is enabled")
    Suggested-by: Jeff Layton <[email protected]>
    Signed-off-by: Dave Wysochanski <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: David Howells <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: fix panic when nfs4_ff_layout_prepare_ds() fails [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Mon Mar 11 11:11:53 2024 -0400

    nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
    
    [ Upstream commit 719fcafe07c12646691bd62d7f8d94d657fa0766 ]
    
    We've been seeing the following panic in production
    
    BUG: kernel NULL pointer dereference, address: 0000000000000065
    PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0
    RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
    Call Trace:
     <TASK>
     ? __die+0x78/0xc0
     ? page_fault_oops+0x286/0x380
     ? __rpc_execute+0x2c3/0x470 [sunrpc]
     ? rpc_new_task+0x42/0x1c0 [sunrpc]
     ? exc_page_fault+0x5d/0x110
     ? asm_exc_page_fault+0x22/0x30
     ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]
     pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]
     pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]
     ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]
     nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]
     ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]
     __nfs_pageio_add_request+0x154/0x6c0 [nfs]
     nfs_pageio_add_request+0x26b/0x380 [nfs]
     nfs_do_writepage+0x111/0x1e0 [nfs]
     nfs_writepages_callback+0xf/0x30 [nfs]
     write_cache_pages+0x17f/0x380
     ? nfs_pageio_init_write+0x50/0x50 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     nfs_writepages+0x125/0x210 [nfs]
     do_writepages+0x67/0x220
     ? generic_perform_write+0x14b/0x210
     filemap_fdatawrite_wbc+0x5b/0x80
     file_write_and_wait_range+0x6d/0xc0
     nfs_file_fsync+0x81/0x170 [nfs]
     ? nfs_file_mmap+0x60/0x60 [nfs]
     __x64_sys_fsync+0x53/0x90
     do_syscall_64+0x3d/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Inspecting the core with drgn I was able to pull this
    
      >>> prog.crashed_thread().stack_trace()[0]
      #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27
      >>> prog.crashed_thread().stack_trace()[0]['idx']
      (u32)1
      >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds
      (struct nfs4_ff_layout_ds *)0xffffffffffffffed
    
    This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()
    which could error out initializing the mirror_ds, and then we go to
    clean it all up and our check is only for if (!mirror->mirror_ds).  This
    is inconsistent with the rest of the users of mirror_ds, which have
    
      if (IS_ERR_OR_NULL(mirror_ds))
    
    to keep from tripping over this exact scenario.  Fix this up in
    ff_layout_cancel_io() to make sure we don't panic when we get an error.
    I also spot checked all the other instances of checking mirror_ds and we
    appear to be doing the correct checks everywhere, only unconditionally
    dereferencing mirror_ds when we know it would be valid.
    
    Signed-off-by: Josef Bacik <[email protected]>
    Fixes: b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked")
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1/pnfs: fix NFS with TLS in pnfs [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Tue Feb 20 18:25:34 2024 -0500

    NFSv4.1/pnfs: fix NFS with TLS in pnfs
    
    [ Upstream commit a35518cae4b325632840bc8c3aa9ad9bac430038 ]
    
    Currently, even though xprtsec=tls is specified and used for operations
    to MDS, any operations that go to DS travel over unencrypted connection.
    Or additionally, if more than 1 DS can serve the data, then trunked
    connections are also done unencrypted.
    
    IN GETDEVINCEINFO, we get an entry for the DS which carries a protocol
    type (which is TCP), then nfs4_set_ds_client() gets called with TCP
    instead of TCP with TLS.
    
    Currently, each trunked connection is created and uses clp->cl_hostname
    value which if TLS is used would get passed up in the handshake upcall,
    but instead we need to pass in the appropriate trunked address value.
    
    Fixes: c8407f2e560c ("NFS: Add an "xprtsec=" NFS mount option")
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.2: fix listxattr maximum XDR buffer size [+ + +]
Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:51:28 2024 -0700

    NFSv4.2: fix listxattr maximum XDR buffer size
    
    [ Upstream commit bcac8bff90a6ee1629f90669cdb9d28fb86049b0 ]
    
    Switch order of operations to avoid creating a short XDR buffer:
    e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20.
    
    Having a short XDR buffer leads to lxa_maxcount be a few bytes
    less than what is needed to retrieve the whole list when using
    a buflen as returned by a call with size = 0:
        buflen = listxattr(path, NULL, 0);
        buf = malloc(buflen);
        buflen = listxattr(path, buf, buflen);
    
    For a file with one attribute (name = '123456'), the first call
    with size = 0 will return buflen = 12 ('user.123456\x00').
    The second call with size = 12, sends LISTXATTRS with
    lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The
    XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count)
    + 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes
    shorter than the lxa_maxcount provided in the call.
    
    Fixes: 04a5da690e8f ("NFSv4.2: define limits and sizes for user xattr handling")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 [+ + +]
Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:56:12 2024 -0700

    NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
    
    [ Upstream commit 251a658bbfceafb4d58c76b77682c8bf7bcfad65 ]
    
    A call to listxattr() with a buffer size = 0 returns the actual
    size of the buffer needed for a subsequent call. When size > 0,
    nfs4_listxattr() does not return an error because either
    generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
    exactly all the bytes then size is 0 when calling
    nfs4_listxattr_nfs4_user() which then triggers the following
    kernel BUG:
    
      [   99.403778] kernel BUG at mm/usercopy.c:102!
      [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
      [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
      [   99.415827] Call trace:
      [   99.415985]  usercopy_abort+0x70/0xa0
      [   99.416227]  __check_heap_object+0x134/0x158
      [   99.416505]  check_heap_object+0x150/0x188
      [   99.416696]  __check_object_size.part.0+0x78/0x168
      [   99.416886]  __check_object_size+0x28/0x40
      [   99.417078]  listxattr+0x8c/0x120
      [   99.417252]  path_listxattr+0x78/0xe0
      [   99.417476]  __arm64_sys_listxattr+0x28/0x40
      [   99.417723]  invoke_syscall+0x78/0x100
      [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0
      [   99.418186]  do_el0_svc+0x24/0x38
      [   99.418376]  el0_svc+0x3c/0x110
      [   99.418554]  el0t_64_sync_handler+0x120/0x130
      [   99.418788]  el0t_64_sync+0x194/0x198
      [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
    
    Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
    thus calling lisxattr() with size = 16 will trigger the bug.
    
    Add check on nfs4_listxattr() to return ERANGE error when it is
    called with size > 0 and the return value is greater than size.
    
    Fixes: 012a211abd5d ("NFSv4.2: hook in the user extended attribute handlers")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nouveau/gsp: don't check devinit disable on GSP. [+ + +]
Author: Dave Airlie <[email protected]>
Date:   Thu Mar 14 11:45:21 2024 +1000

    nouveau/gsp: don't check devinit disable on GSP.
    
    [ Upstream commit 5d4e8ae6e57b025802aadf55a4775c55cceb75f1 ]
    
    GSP should be handling this and I can see no evidence in opengpu
    driver that this register should be touched.
    
    Fixed acceleration on 2080 Ti GPUs.
    
    Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
    
    Signed-off-by: Dave Airlie <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
nouveau: reset the bo resource bus info after an eviction [+ + +]
Author: Dave Airlie <[email protected]>
Date:   Mon Mar 11 17:20:37 2024 +1000

    nouveau: reset the bo resource bus info after an eviction
    
    [ Upstream commit f35c9af45ea7a4b1115b193d84858b14d13517fc ]
    
    Later attempts to refault the bo won't happen and the whole
    GPU does to lunch. I think Christian's refactoring of this
    code out to the driver broke this not very well tested path.
    
    Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver v5")
    Cc: Christian König <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
NTB: fix possible name leak in ntb_register_device() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Fri Dec 1 11:30:56 2023 +0800

    NTB: fix possible name leak in ntb_register_device()
    
    [ Upstream commit aebfdfe39b9327a3077d0df8db3beb3160c9bdd0 ]
    
    If device_register() fails in ntb_register_device(), the device name
    allocated by dev_set_name() should be freed. As per the comment in
    device_register(), callers should use put_device() to give up the
    reference in the error path. So fix this by calling put_device() in the
    error path so that the name can be freed in kobject_cleanup().
    
    As a result of this, put_device() in the error path of
    ntb_register_device() is removed and the actual error is returned.
    
    Fixes: a1bd3baeb2f1 ("NTB: Add NTB hardware abstraction layer")
    Signed-off-by: Yang Yingliang <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [mani: reworded commit message]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: fix reconnection fail due to reserved tag allocation [+ + +]
Author: Chunguang Xu <[email protected]>
Date:   Mon Mar 11 10:09:27 2024 +0800

    nvme: fix reconnection fail due to reserved tag allocation
    
    [ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]
    
    We found a issue on production environment while using NVMe over RDMA,
    admin_q reconnect failed forever while remote target and network is ok.
    After dig into it, we found it may caused by a ABBA deadlock due to tag
    allocation. In my case, the tag was hold by a keep alive request
    waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
    request maked as idle and will not process before reset success. As
    fabric_q shares tagset with admin_q, while reconnect remote target, we
    need a tag for connect command, but the only one reserved tag was held
    by keep alive command which waiting inside admin_q. As a result, we
    failed to reconnect admin_q forever. In order to fix this issue, I
    think we should keep two reserved tags for admin queue.
    
    Fixes: ed01fee283a0 ("nvme-fabrics: only reserve a single tag")
    Signed-off-by: Chunguang Xu <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvme: host: fix double-free of struct nvme_id_ns in ns_update_nuse() [+ + +]
Author: Shin'ichiro Kawasaki <[email protected]>
Date:   Wed Mar 6 15:03:03 2024 +0900

    nvme: host: fix double-free of struct nvme_id_ns in ns_update_nuse()
    
    [ Upstream commit 8d0d2447394b13fb22a069f0330f9c49b7fff9d3 ]
    
    When nvme_identify_ns() fails, it frees the pointer to the struct
    nvme_id_ns before it returns. However, ns_update_nuse() calls kfree()
    for the pointer even when nvme_identify_ns() fails. This results in
    KASAN double-free, which was observed with blktests nvme/045 with
    proposed patches [1] on the kernel v6.8-rc7. Fix the double-free by
    skipping kfree() when nvme_identify_ns() fails.
    
    Link: https://lore.kernel.org/linux-block/[email protected]/ [1]
    Fixes: a1a825ab6a60 ("nvme: add csi, ms and nuse to sysfs")
    Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Daniel Wagner <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Feb 26 23:35:27 2024 -0800

    objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks
    
    [ Upstream commit 10b4c4bce3f5541f54bcc2039720b11d2bc96d79 ]
    
    If SAVE and RESTORE unwind hints are in different basic blocks, and
    objtool sees the RESTORE before the SAVE, it errors out with:
    
      vmlinux.o: warning: objtool: vmw_port_hb_in+0x242: objtool isn't smart enough to handle this CFI save/restore combo
    
    In such a case, defer following the RESTORE block until the
    straight-line path gets followed later.
    
    Fixes: 8faea26e6111 ("objtool: Re-add UNWIND_HINT_{SAVE_RESTORE}")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/20240227073527.avcm5naavbv3cj5s@treble
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-af: Fix devlink params [+ + +]
Author: Sunil Goutham <[email protected]>
Date:   Thu Mar 7 16:26:23 2024 +0530

    octeontx2-af: Fix devlink params
    
    [ Upstream commit fc1b2901e0feed933aaee273d0b0ca961539f4d7 ]
    
    Devlink param for adjusting NPC MCAM high zone
    area is in wrong param list and is not getting
    activated on CN10KA silicon.
    That patch fixes this issue.
    
    Fixes: dd7842878633 ("octeontx2-af: Add new devlink param to configure maximum usable NIX block LFs")
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: Sai Krishna <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-af: Use matching wake_up API variant in CGX command interface [+ + +]
Author: Linu Cherian <[email protected]>
Date:   Tue Mar 12 12:36:22 2024 +0530

    octeontx2-af: Use matching wake_up API variant in CGX command interface
    
    [ Upstream commit e642921dfeed1e15e73f78f2c3b6746f72b6deb2 ]
    
    Use wake_up API instead of wake_up_interruptible, since
    wait_event_timeout API is used for waiting on command completion.
    
    Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management")
    Signed-off-by: Linu Cherian <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-af: Use separate handlers for interrupts [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:58 2024 +0530

    octeontx2-af: Use separate handlers for interrupts
    
    [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ]
    
    For PF to AF interrupt vector and VF to AF vector same
    interrupt handler is registered which is causing race condition.
    When two interrupts are raised to two CPUs at same time
    then two cores serve same event corrupting the data.
    
    Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: Send UP messages to VF only when VF is up. [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:57 2024 +0530

    octeontx2-pf: Send UP messages to VF only when VF is up.
    
    [ Upstream commit dfcf6355f53b1796cf7fd50a4f27b18ee6a3497a ]
    
    When PF sending link status messages to VF, it is possible
    that by the time link_event_task work function is executed
    VF might have brought down. Hence before sending VF link
    status message check whether VF is up to receive it.
    
    Fixes: ad513ed938c9 ("octeontx2-vf: Link event notification support")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: Use default max_active works instead of one [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:56 2024 +0530

    octeontx2-pf: Use default max_active works instead of one
    
    [ Upstream commit 7558ce0d974ced1dc07edc1197f750fe28c52e57 ]
    
    Only one execution context for the workqueue used for PF and
    VFs mailbox communication is incorrect since multiple works are
    queued simultaneously by all the VFs and PF link UP messages.
    Hence use default number of execution contexts by passing zero
    as max_active to alloc_workqueue function. With this fix in place,
    modify UP messages also to wait until completion.
    
    Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: Wait till detach_resources msg is complete [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:55 2024 +0530

    octeontx2-pf: Wait till detach_resources msg is complete
    
    [ Upstream commit cbf2f24939a5dafce6de4dd4422e543ce8f610cf ]
    
    During VF driver remove, a message is sent to detach VF
    resources to PF but VF is not waiting until message is
    complete. Also mailbox interrupts need to be turned off
    after the detach resource message is complete. This patch
    fixes that problem.
    
    Fixes: 05fcc9e08955 ("octeontx2-pf: Attach NIX and NPA block LFs")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2: Detect the mbox up or down message via register [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:54 2024 +0530

    octeontx2: Detect the mbox up or down message via register
    
    [ Upstream commit a88e0f936ba9a301c78f6eacfd38737d003c130b ]
    
    A single line of interrupt is used to receive up notifications
    and down reply messages from AF to PF (similarly from PF to its VF).
    PF acts as bridge and forwards VF messages to AF and sends respsones
    back from AF to VF. When an async event like link event is received
    by up message when PF is in middle of forwarding VF message then
    mailbox errors occur because PF state machine is corrupted.
    Since VF is a separate driver or VF driver can be in a VM it is
    not possible to serialize from the start of communication at VF.
    Hence to differentiate between type of messages at PF this patch makes
    sender to set mbox data register with distinct values for up and down
    messages. Sender also checks whether previous interrupt is received
    before triggering current interrupt by waiting for mailbox data register
    to become zero.
    
    Fixes: 5a6d7c9daef3 ("octeontx2-pf: Mailbox communication with AF")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
OPP: debugfs: Fix warning around icc_get_name() [+ + +]
Author: Viresh Kumar <[email protected]>
Date:   Mon Mar 4 16:48:28 2024 +0530

    OPP: debugfs: Fix warning around icc_get_name()
    
    [ Upstream commit 28330ceb953e39880ea77da4895bb902a1244860 ]
    
    If the kernel isn't built with interconnect support, icc_get_name()
    returns NULL and we get following warning:
    
    drivers/opp/debugfs.c: In function 'bw_name_read':
    drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-Werror=format-overflow=]
             i = scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path));
    
    Fix it.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 0430b1d5704b0 ("opp: Expose bandwidth information via debugfs")
    Signed-off-by: Viresh Kumar <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ovl: Always reject mounting over case-insensitive directories [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Feb 21 12:14:03 2024 -0500

    ovl: Always reject mounting over case-insensitive directories
    
    [ Upstream commit 2824083db76cb9d4b7910607b367e93b02912865 ]
    
    overlayfs relies on the filesystem setting DCACHE_OP_HASH or
    DCACHE_OP_COMPARE to reject mounting over case-insensitive directories.
    
    Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their
    d_ops"), we set ->d_op through a hook in ->d_lookup, which
    means the root dentry won't have them, causing the mount to accidentally
    succeed.
    
    In v6.7-rc7, the following sequence will succeed to mount, but any
    dentry other than the root dentry will be a "weird" dentry to ovl and
    fail with EREMOTE.
    
      mkfs.ext4 -O casefold lower.img
      mount -O loop lower.img lower
      mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl /mnt
    
    Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH
    and DCACHE_OP_COMPARE are properly set by ->lookup.
    
    Fix by explicitly rejecting superblocks that allow case-insensitive
    dentries. Yes, this will be solved when we move d_op configuration back
    to ->s_d_op. Yet, we better have an explicit fix to avoid messing up
    again.
    
    While there, re-sort the entries to have more descriptive error messages
    first.
    
    Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops")
    Acked-by: Amir Goldstein <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ovl: relax WARN_ON in ovl_verify_area() [+ + +]
Author: Amir Goldstein <[email protected]>
Date:   Sun Mar 17 13:59:43 2024 +0200

    ovl: relax WARN_ON in ovl_verify_area()
    
    [ Upstream commit 77a28aa476873048024ad56daf8f4f17d58ee48e ]
    
    syzbot hit an assertion in copy up data loop which looks like it is
    the result of a lower file whose size is being changed underneath
    overlayfs.
    
    This type of use case is documented to cause undefined behavior, so
    returning EIO error for the copy up makes sense, but it should not be
    causing a WARN_ON assertion.
    
    Reported-and-tested-by: [email protected]
    Fixes: ca7ab482401c ("ovl: add permission hooks outside of do_splice_direct()")
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
packet: annotate data-races around ignore_outgoing [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 14 14:18:16 2024 +0000

    packet: annotate data-races around ignore_outgoing
    
    [ Upstream commit 6ebfad33161afacb3e1e59ed1c2feefef70f9f97 ]
    
    ignore_outgoing is read locklessly from dev_queue_xmit_nit()
    and packet_getsockopt()
    
    Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
    
    syzbot reported:
    
    BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
    
    write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
     packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
     do_sock_setsockopt net/socket.c:2311 [inline]
     __sys_setsockopt+0x1d8/0x250 net/socket.c:2334
     __do_sys_setsockopt net/socket.c:2343 [inline]
     __se_sys_setsockopt net/socket.c:2340 [inline]
     __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
     dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
     xmit_one net/core/dev.c:3527 [inline]
     dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
     __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
     dev_queue_xmit include/linux/netdevice.h:3091 [inline]
     batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
     batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
     batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
     batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
     batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
     worker_thread+0x526/0x730 kernel/workqueue.c:3416
     kthread+0x1d1/0x210 kernel/kthread.c:388
     ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
    
    value changed: 0x00 -> 0x01
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
    
    Fixes: fa788d986a3a ("packet: add sockopt to ignore outgoing packets")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/CANn89i+Z7MfbkBLOv=p7KZ7=K1rKHO4P1OL5LYDCtBiyqsa9oQ@mail.gmail.com/T/#t
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Jason Xing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/DPC: Print all TLP Prefixes, not just the first [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Thu Jan 18 13:08:15 2024 +0200

    PCI/DPC: Print all TLP Prefixes, not just the first
    
    [ Upstream commit 6568d82512b0a64809acff3d7a747362fa4288c8 ]
    
    The TLP Prefix Log Register consists of multiple DWORDs (PCIe r6.1 sec
    7.9.14.13) but the loop in dpc_process_rp_pio_error() keeps reading from
    the first DWORD, so we print only the first PIO TLP Prefix (duplicated
    several times), and we never print the second, third, etc., Prefixes.
    
    Add the iteration count based offset calculation into the config read.
    
    Fixes: f20c4ea49ec4 ("PCI/DPC: Add eDPC support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    [bhelgaas: add user-visible details to commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/P2PDMA: Fix a sleeping issue in a RCU read section [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Jan 4 20:52:35 2024 +0100

    PCI/P2PDMA: Fix a sleeping issue in a RCU read section
    
    [ Upstream commit 1e5c66afd4a40bb7be17cb33cbb1a1085f727730 ]
    
    It is not allowed to sleep within a RCU read section, so use GFP_ATOMIC
    instead of GFP_KERNEL here.
    
    Link: https://lore.kernel.org/r/02d9ec4a10235def0e764ff1f5be881ba12e16e8.1704397858.git.christophe.jaillet@wanadoo.fr
    Fixes: ae21f835a5bd ("PCI/P2PDMA: Finish RCU conversion of pdev->p2pdma")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling [+ + +]
Author: Jonathan Bell <[email protected]>
Date:   Sat Feb 17 14:37:22 2024 +0100

    PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling
    
    [ Upstream commit 039741a8d7c9a01c1bc84a5ac5aa770a5e138a30 ]
    
    The MDIO_WT_DONE() macro tests bit 31, which is always 0 (== done) as
    readw_poll_timeout_atomic() does a 16-bit read. Replace with the readl
    variant.
    
    [kwilczynski: commit log]
    Fixes: ca5dcc76314d ("PCI: brcmstb: Replace status loops with read_poll_timeout_atomic()")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Jonathan Bell <[email protected]>
    Signed-off-by: Stefan Wahren <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Make pci_dev_is_disconnected() helper public for other drivers [+ + +]
Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:14 2024 +0800

    PCI: Make pci_dev_is_disconnected() helper public for other drivers
    
    [ Upstream commit 39714fd73c6b60a8d27bcc5b431afb0828bf4434 ]
    
    Make pci_dev_is_disconnected() public so that it can be called from
    Intel VT-d driver to quickly fix/workaround the surprise removal
    unplug hang issue for those ATS capable devices on PCIe switch downstream
    hotplug capable ports.
    
    Beside pci_device_is_present() function, this one has no config space
    space access, so is light enough to optimize the normal pure surprise
    removal and safe removal flow.
    
    Acked-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Tested-by: Haorong Ye <[email protected]>
    Signed-off-by: Ethan Zhao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected")
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Mark 3ware-9650SE Root Port Extended Tags as broken [+ + +]
Author: Jörg Wedekind <[email protected]>
Date:   Mon Feb 19 14:28:11 2024 +0100

    PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
    
    [ Upstream commit baf67aefbe7d7deafa59ca49612d163f8889934c ]
    
    Per PCIe r6.1, sec 2.2.6.2 and 7.5.3.4, a Requester may not use 8-bit Tags
    unless its Extended Tag Field Enable is set, but all Receivers/Completers
    must handle 8-bit Tags correctly regardless of their Extended Tag Field
    Enable.
    
    Some devices do not handle 8-bit Tags as Completers, so add a quirk for
    them.  If we find such a device, we disable Extended Tags for the entire
    hierarchy to make peer-to-peer DMA possible.
    
    The 3ware 9650SE seems to have issues with handling 8-bit tags. Mark it as
    broken.
    
    This fixes PCI Parity Errors like :
    
      3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425
    Signed-off-by: Jörg Wedekind <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: switchtec: Fix an error handling path in switchtec_pci_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Dec 24 15:30:01 2023 +0100

    PCI: switchtec: Fix an error handling path in switchtec_pci_probe()
    
    [ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ]
    
    The commit in Fixes changed the logic on how resources are released and
    introduced a new switchtec_exit_pci() that need to be called explicitly in
    order to undo a corresponding switchtec_init_pci().
    
    This was done in the remove function, but not in the probe.
    
    Fix the probe now.
    
    Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove")
    Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf bpf: Clean up the generated/copied vmlinux.h [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Fri Feb 2 11:32:20 2024 -0300

    perf bpf: Clean up the generated/copied vmlinux.h
    
    [ Upstream commit ffd856537b95dd65facb4e0c78ca1cb92c2048ff ]
    
    When building perf with BPF skels we either copy the minimalistic
    tools/perf/util/bpf_skel/vmlinux/vmlinux.h or use bpftool to generate a
    vmlinux from BTF, storing the result in $(SKEL_OUT)/vmlinux.h.
    
    We need to remove that when doing a 'make -C tools/perf clean', fix it.
    
    Fixes: b7a2d774c9c5a9a3 ("perf build: Add ability to build with a generated vmlinux.h")
    Reviewed-by: Ian Rogers <[email protected]>
    Cc: Andrii Nakryiko <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Tiezhu Yang <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Cc: [email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/Zbz89KK5wHfZ82jv@x1
    Signed-off-by: Sasha Levin <[email protected]>