óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 6.7.2

 
accel/habanalabs: fix information leak in sec_attest_info() [+ + +]
Author: Xingyuan Mo <[email protected]>
Date:   Fri Dec 8 21:00:59 2023 +0800

    accel/habanalabs: fix information leak in sec_attest_info()
    
    [ Upstream commit a9f07790a4b2250f0140e9a61c7f842fd9b618c7 ]
    
    This function may copy the pad0 field of struct hl_info_sec_attest to user
    mode which has not been initialized, resulting in leakage of kernel heap
    data to user mode. To prevent this, use kzalloc() to allocate and zero out
    the buffer, which can also eliminate other uninitialized holes, if any.
    
    Fixes: 0c88760f8f5e ("habanalabs/gaudi2: add secured attestation info uapi")
    Signed-off-by: Xingyuan Mo <[email protected]>
    Reviewed-by: Oded Gabbay <[email protected]>
    Signed-off-by: Oded Gabbay <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error [+ + +]
Author: Tony Luck <[email protected]>
Date:   Tue Dec 12 13:22:39 2023 -0800

    ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error
    
    [ Upstream commit 38c872a9e96f72f2947affc0526cc05659367d3d ]
    
    When both CONFIG_RAS_CEC and CONFIG_ACPI_EXTLOG are enabled, Linux does
    not clear the status word of the BIOS supplied error record for corrected
    errors. This may prevent logging of subsequent uncorrected errors.
    
    Fix by clearing the status.
    
    Fixes: 23ba710a0864 ("x86/mce: Fix all mce notifiers to update the mce->kflags bitmask")
    Reported-by: Erwin Tsaur <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: LPIT: Avoid u32 multiplication overflow [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Thu Nov 9 21:08:59 2023 +0300

    ACPI: LPIT: Avoid u32 multiplication overflow
    
    [ Upstream commit 56d2eeda87995245300836ee4dbd13b002311782 ]
    
    In lpit_update_residency() there is a possibility of overflow
    in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
    
    Change multiplication to mul_u32_u32().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: LPSS: Fix the fractional clock divider flags [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Mon Dec 11 13:14:29 2023 +0200

    ACPI: LPSS: Fix the fractional clock divider flags
    
    [ Upstream commit 3ebccf1d1ca74bbb78e6f8c38d1d172e468d91f8 ]
    
    The conversion to CLK_FRAC_DIVIDER_POWER_OF_TWO_PS uses wrong flags
    in the parameters and hence miscalculates the values in the clock
    divider. Fix this by applying the flag to the proper parameter.
    
    Fixes: 82f53f9ee577 ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag")
    Reported-by: Alex Vinarskis <[email protected]>
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
acpi: property: Let args be NULL in __acpi_node_get_property_reference [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Thu Nov 9 12:10:08 2023 +0200

    acpi: property: Let args be NULL in __acpi_node_get_property_reference
    
    [ Upstream commit bef52aa0f3de1b7d8c258c13b16e577361dabf3a ]
    
    fwnode_get_property_reference_args() may not be called with args argument
    NULL on ACPI, OF already supports this. Add the missing NULL checks and
    document this.
    
    The purpose is to be able to count the references.
    
    Fixes: 977d5ad39f3e ("ACPI: Convert ACPI reference args to generic fwnode reference args")
    Signed-off-by: Sakari Ailus <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

 
ACPI: video: check for error while searching for backlight device parent [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Thu Nov 9 16:49:25 2023 +0300

    ACPI: video: check for error while searching for backlight device parent
    
    [ Upstream commit ccd45faf4973746c4f30ea41eec864e5cf191099 ]
    
    If acpi_get_parent() called in acpi_video_dev_register_backlight()
    fails, for example, because acpi_ut_acquire_mutex() fails inside
    acpi_get_parent), this can lead to incorrect (uninitialized)
    acpi_parent handle being passed to acpi_get_pci_dev() for detecting
    the parent pci device.
    
    Check acpi_get_parent() result and set parent device only in case of success.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9661e92c10a9 ("acpi: tie ACPI backlight devices to PCI devices if possible")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: aloop: Introduce a function to get if access is interleaved mode [+ + +]
Author: Chancel Liu <[email protected]>
Date:   Thu Jan 11 11:52:19 2024 +0900

    ALSA: aloop: Introduce a function to get if access is interleaved mode
    
    [ Upstream commit cdac6e1f716419ce307ad3e44a718557a5469c17 ]
    
    There's a use case that playback stream of a loopback cable works on
    RW_INTERLEAVED mode while capture stream works on MMAP_INTERLEAVED mode:
    
    aplay -Dhw:Loopback,0,0 S32_48K_2ch.wav;
    arecord -Dplughw:Loopback,1,0 -fS32_LE -r16000 -c2 cap.wav;
    
    The plug plugin handles only slave PCM support MMAP mode. Not only plug
    plugin but also other plugins like direct plugins(dmix/dsnoop/dshare)
    work on MMAP access mode. In this case capture stream is the slave
    PCM works on MMAP_INTERLEAVED mode. However loopback_check_format()
    rejects this access setting and return:
    
    arecord: pcm_read:2240: read error: Input/output error
    
    To fix it a function called is_access_interleaved() is introduced to
    get if access is interleaved mode. If both access of capture stream and
    playback stream is interleaved mode loopback_check_format() will allow
    this kind of access setting.
    
    Fixes: 462494565c27 ("ALSA: aloop: Add support for the non-interleaved access mode")
    Signed-off-by: Chancel Liu <[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: hda/realtek: Enable headset mic on Lenovo M70 Gen5 [+ + +]
Author: Bin Li <[email protected]>
Date:   Wed Jan 17 23:41:23 2024 +0800

    ALSA: hda/realtek: Enable headset mic on Lenovo M70 Gen5
    
    commit fb3c007fde80d9d3b4207943e74c150c9116cead upstream.
    
    Lenovo M70 Gen5 is equipped with ALC623, and it needs
    ALC283_FIXUP_HEADSET_MIC quirk to make its headset mic work.
    
    Signed-off-by: Bin Li <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Enable mute/micmute LEDs and limit mic boost on HP ZBook [+ + +]
Author: Yo-Jung Lin <[email protected]>
Date:   Tue Jan 16 10:07:19 2024 +0800

    ALSA: hda/realtek: Enable mute/micmute LEDs and limit mic boost on HP ZBook
    
    commit b018cee7369896c7a15bfdbe88f168f3dbd8ba27 upstream.
    
    On some HP ZBooks, the audio LEDs can be enabled by
    ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF. So use it accordingly.
    
    Signed-off-by: Yo-Jung Lin <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/relatek: Enable Mute LED on HP Laptop 15s-fq2xxx [+ + +]
Author: ÇaÄŸhan Demir <[email protected]>
Date:   Mon Jan 15 20:23:03 2024 +0300

    ALSA: hda/relatek: Enable Mute LED on HP Laptop 15s-fq2xxx
    
    commit bc7863d18677df66b2c7a0e172c91296ff380f11 upstream.
    
    This HP Laptop uses ALC236 codec with COEF 0x07 idx 1 controlling
    the mute LED. This patch enables the already existing quirk for
    this device.
    
    Signed-off-by: ÇaÄŸhan Demir <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Properly setup HDMI stream [+ + +]
Author: Amadeusz SÅ‚awiÅ„ski <[email protected]>
Date:   Fri Jan 12 12:33:49 2024 +0100

    ALSA: hda: Properly setup HDMI stream
    
    [ Upstream commit 454abb80e26ab85323a30e52aa7b0ee9aae1d38a ]
    
    Since commit 4005d1ba0a7e ("ASoC: soc-dai: don't call PCM audio ops if
    the stream is not supported") HDMI playback is broken with avs driver.
    This happens because for HDMI stream (unlike generic HDA one)
    channels_min for stream is not set when creating PCMs. Fix this by
    setting the value based on first available converter.
    
    Fixes: 4005d1ba0a7e ("ASoC: soc-dai: don't call PCM audio ops if the stream is not supported")
    Signed-off-by: Amadeusz SÅ‚awiÅ„ski <[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: oxygen: Fix right channel of capture volume mixer [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Fri Jan 12 12:10:23 2024 +0100

    ALSA: oxygen: Fix right channel of capture volume mixer
    
    commit a03cfad512ac24a35184d7d87ec0d5489e1cb763 upstream.
    
    There was a typo in oxygen mixer code that didn't update the right
    channel value properly for the capture volume.  Let's fix it.
    
    This trivial fix was originally reported on Bugzilla.
    
    Fixes: a3601560496d ("[ALSA] oxygen: add front panel controls")
    Cc: <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=156561
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Wed Dec 20 04:07:52 2023 +1030

    ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
    
    [ Upstream commit 04f8f053252b86c7583895c962d66747ecdc61b7 ]
    
    Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
    SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
    scarlett2_mixer_values[].
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Add missing error check to scarlett2_config_save() [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Wed Dec 20 04:07:00 2023 +1030

    ALSA: scarlett2: Add missing error check to scarlett2_config_save()
    
    [ Upstream commit 5f6ff6931a1c0065a55448108940371e1ac8075f ]
    
    scarlett2_config_save() was ignoring the return value from
    scarlett2_usb(). As this function is not called from user-space we
    can't return the error, so call usb_audio_err() instead.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config() [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Wed Dec 20 04:07:21 2023 +1030

    ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()
    
    [ Upstream commit ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3 ]
    
    scarlett2_usb_set_config() calls scarlett2_usb_get() but was not
    checking the result. Return the error if it fails rather than
    continuing with an invalid value.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 9e15fae6c51a ("ALSA: usb-audio: scarlett2: Allow bit-level access to config")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Add missing error checks to *_ctl_get() [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Wed Dec 20 04:07:37 2023 +1030

    ALSA: scarlett2: Add missing error checks to *_ctl_get()
    
    [ Upstream commit 50603a67daef161c78c814580d57f7f0be57167e ]
    
    The *_ctl_get() functions which call scarlett2_update_*() were not
    checking the return value. Fix to check the return value and pass to
    the caller.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: scarlett2: Add missing mutex lock around get meter levels [+ + +]
Author: Geoffrey D. Bennett <[email protected]>
Date:   Wed Dec 20 04:08:09 2023 +1030

    ALSA: scarlett2: Add missing mutex lock around get meter levels
    
    [ Upstream commit 993f7b42fa066b055e3a19b7f76ad8157c0927a0 ]
    
    As scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex
    should be locked while accessing it.
    
    Signed-off-by: Geoffrey D. Bennett <[email protected]>
    Fixes: 3473185f31df ("ALSA: scarlett2: Remap Level Meter values")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
amt: do not use overwrapped cb area [+ + +]
Author: Taehee Yoo <[email protected]>
Date:   Sun Jan 7 14:42:41 2024 +0000

    amt: do not use overwrapped cb area
    
    [ Upstream commit bec161add35b478a7746bf58bcdea6faa19129ef ]
    
    amt driver uses skb->cb for storing tunnel information.
    This job is worked before TC layer and then amt driver load tunnel info
    from skb->cb after TC layer.
    So, its cb area should not be overwrapped with CB area used by TC.
    In order to not use cb area used by TC, it skips the biggest cb
    structure used by TC, which was qdisc_skb_cb.
    But it's not anymore.
    Currently, biggest structure of TC's CB is tc_skb_cb.
    So, it should skip size of tc_skb_cb instead of qdisc_skb_cb.
    
    Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block")
    Signed-off-by: Taehee Yoo <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Jamal Hadi Salim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
apparmor: avoid crash when parsed profile name is empty [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Thu Dec 28 19:07:43 2023 +0300

    apparmor: avoid crash when parsed profile name is empty
    
    [ Upstream commit 55a8210c9e7d21ff2644809699765796d4bfb200 ]
    
    When processing a packed profile in unpack_profile() described like
    
     "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
    
    a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
    passed to aa_splitn_fqname().
    
    aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
    Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
    aa_alloc_profile() crashes as the new profile name is NULL now.
    
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
    RIP: 0010:strlen+0x1e/0xa0
    Call Trace:
     <TASK>
     ? strlen+0x1e/0xa0
     aa_policy_init+0x1bb/0x230
     aa_alloc_profile+0xb1/0x480
     unpack_profile+0x3bc/0x4960
     aa_unpack+0x309/0x15e0
     aa_replace_profiles+0x213/0x33c0
     policy_update+0x261/0x370
     profile_replace+0x20e/0x2a0
     vfs_write+0x2af/0xe00
     ksys_write+0x126/0x250
     do_syscall_64+0x46/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
     </TASK>
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:strlen+0x1e/0xa0
    
    It seems such behaviour of aa_splitn_fqname() is expected and checked in
    other places where it is called (e.g. aa_remove_profiles). Well, there
    is an explicit comment "a ns name without a following profile is allowed"
    inside.
    
    AFAICS, nothing can prevent unpacked "name" to be in form like
    ":samba-dcerpcd" - it is passed from userspace.
    
    Deny the whole profile set replacement in such case and inform user with
    EPROTO and an explaining message.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 04dc715e24d0 ("apparmor: audit policy ns specified in policy load")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: Fix memory leak in unpack_profile() [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Fri Jan 5 10:01:26 2024 +0800

    apparmor: Fix memory leak in unpack_profile()
    
    [ Upstream commit 8ead196be219adade3bd0d4115cc9b8506643121 ]
    
    The aa_put_pdb(rules->file) should be called when rules->file is
    reassigned, otherwise there may be a memory leak.
    
    This was found via kmemleak:
    
    unreferenced object 0xffff986c17056600 (size 192):
      comm "apparmor_parser", pid 875, jiffies 4294893488
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 89 14 04 6c 98 ff ff  ............l...
        00 00 8c 11 6c 98 ff ff bc 0c 00 00 00 00 00 00  ....l...........
      backtrace (crc e28c80c4):
        [<ffffffffba25087f>] kmemleak_alloc+0x4f/0x90
        [<ffffffffb95ecd42>] kmalloc_trace+0x2d2/0x340
        [<ffffffffb98a7b3d>] aa_alloc_pdb+0x4d/0x90
        [<ffffffffb98ab3b8>] unpack_pdb+0x48/0x660
        [<ffffffffb98ac073>] unpack_profile+0x693/0x1090
        [<ffffffffb98acf5a>] aa_unpack+0x10a/0x6e0
        [<ffffffffb98a93e3>] aa_replace_profiles+0xa3/0x1210
        [<ffffffffb989a183>] policy_update+0x163/0x2a0
        [<ffffffffb989a381>] profile_replace+0xb1/0x130
        [<ffffffffb966cb64>] vfs_write+0xd4/0x3d0
        [<ffffffffb966d05b>] ksys_write+0x6b/0xf0
        [<ffffffffb966d10e>] __x64_sys_write+0x1e/0x30
        [<ffffffffba242316>] do_syscall_64+0x76/0x120
        [<ffffffffba4000e5>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    So add aa_put_pdb(rules->file) to fix it when rules->file is reassigned.
    
    Fixes: 98b824ff8984 ("apparmor: refcount the pdb")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: fix possible memory leak in unpack_trans_table [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Mon Dec 4 21:19:44 2023 +0300

    apparmor: fix possible memory leak in unpack_trans_table
    
    [ Upstream commit 1342ad786073e96fa813ad943c19f586157ae297 ]
    
    If we fail to unpack the transition table then the table elements which
    have been already allocated are not freed on error path.
    
    unreferenced object 0xffff88802539e000 (size 128):
      comm "apparmor_parser", pid 903, jiffies 4294914938 (age 35.085s)
      hex dump (first 32 bytes):
        20 73 6f 6d 65 20 6e 61 73 74 79 20 73 74 72 69   some nasty stri
        6e 67 20 73 6f 6d 65 20 6e 61 73 74 79 20 73 74  ng some nasty st
      backtrace:
        [<ffffffff81ddb312>] __kmem_cache_alloc_node+0x1e2/0x2d0
        [<ffffffff81c47194>] __kmalloc_node_track_caller+0x54/0x170
        [<ffffffff81c225b9>] kmemdup+0x29/0x60
        [<ffffffff83e1ee65>] aa_unpack_strdup+0xe5/0x1b0
        [<ffffffff83e20808>] unpack_pdb+0xeb8/0x2700
        [<ffffffff83e23567>] unpack_profile+0x1507/0x4a30
        [<ffffffff83e27bfa>] aa_unpack+0x36a/0x1560
        [<ffffffff83e194c3>] aa_replace_profiles+0x213/0x33c0
        [<ffffffff83de9461>] policy_update+0x261/0x370
        [<ffffffff83de978e>] profile_replace+0x20e/0x2a0
        [<ffffffff81eac8bf>] vfs_write+0x2af/0xe00
        [<ffffffff81eaddd6>] ksys_write+0x126/0x250
        [<ffffffff88f34fb6>] do_syscall_64+0x46/0xf0
        [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Call aa_free_str_table() on error path as was done before the blamed
    commit. It implements all necessary checks, frees str_table if it is
    available and nullifies the pointers.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: a0792e2ceddc ("apparmor: make transition table unpack generic so it can be reused")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: Fix ref count leak in task_kill [+ + +]
Author: John Johansen <[email protected]>
Date:   Fri Dec 29 06:54:41 2023 -0800

    apparmor: Fix ref count leak in task_kill
    
    [ Upstream commit 2cb54a19ac7153b9a26a72098c495187f64c2276 ]
    
    apparmor_task_kill was not putting the task_cred reference tc, or the
    cred_label reference tc when dealing with a passed in cred, fix this
    by using a single fn exit.
    
    Fixes: 90c436a64a6e ("apparmor: pass cred through to audit info.")
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

apparmor: free the allocated pdb objects [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Mon Nov 27 20:59:04 2023 +0300

    apparmor: free the allocated pdb objects
    
    [ Upstream commit 1af5aa82c976753e93eb52b72784e586a7d2844b ]
    
    policy_db objects are allocated with kzalloc() inside aa_alloc_pdb() and
    are not cleared in the corresponding aa_free_pdb() function causing leak:
    
    unreferenced object 0xffff88801f0a1400 (size 192):
      comm "apparmor_parser", pid 1247, jiffies 4295122827 (age 2306.399s)
      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:
        [<ffffffff81ddc612>] __kmem_cache_alloc_node+0x1e2/0x2d0
        [<ffffffff81c47c55>] kmalloc_trace+0x25/0xc0
        [<ffffffff83eb9a12>] aa_alloc_pdb+0x82/0x140
        [<ffffffff83ec4077>] unpack_pdb+0xc7/0x2700
        [<ffffffff83ec6b10>] unpack_profile+0x450/0x4960
        [<ffffffff83ecc129>] aa_unpack+0x309/0x15e0
        [<ffffffff83ebdb23>] aa_replace_profiles+0x213/0x33c0
        [<ffffffff83e8d341>] policy_update+0x261/0x370
        [<ffffffff83e8d66e>] profile_replace+0x20e/0x2a0
        [<ffffffff81eadfaf>] vfs_write+0x2af/0xe00
        [<ffffffff81eaf4c6>] ksys_write+0x126/0x250
        [<ffffffff890fa0b6>] do_syscall_64+0x46/0xf0
        [<ffffffff892000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Free the pdbs inside aa_free_pdb(). While at it, rename the variable
    representing an aa_policydb object to make the function more unified with
    aa_pdb_free_kref() and aa_alloc_pdb().
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 98b824ff8984 ("apparmor: refcount the pdb")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: John Johansen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64/ptrace: Don't flush ZA/ZT storage when writing ZA via ptrace [+ + +]
Author: Mark Brown <[email protected]>
Date:   Mon Jan 15 18:42:38 2024 +0000

    arm64/ptrace: Don't flush ZA/ZT storage when writing ZA via ptrace
    
    [ Upstream commit b7c510d049049409e8945b932f4b0b357fa17415 ]
    
    When writing ZA we currently unconditionally flush the buffer used to store
    it as part of ensuring that it is allocated. Since this buffer is shared
    with ZT0 this means that a write to ZA when PSTATE.ZA is already set will
    corrupt the value of ZT0 on a SME2 system. Fix this by only flushing the
    backing storage if PSTATE.ZA was not previously set.
    
    This will mean that short or failed writes may leave stale data in the
    buffer, this seems as correct as our current behaviour and unlikely to be
    something that userspace will rely on.
    
    Fixes: f90b529bcbe5 ("arm64/sme: Implement ZT0 ptrace support")
    Signed-off-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: armada-3720-turris-mox: set irq type for RTC [+ + +]
Author: Sjoerd Simons <[email protected]>
Date:   Tue Nov 28 22:35:06 2023 +0100

    arm64: dts: armada-3720-turris-mox: set irq type for RTC
    
    commit fca8a117c1c9a0f8b8feed117db34cf58134dc2c upstream.
    
    The rtc on the mox shares its interrupt line with the moxtet bus. Set
    the interrupt type to be consistent between both devices. This ensures
    correct setup of the interrupt line regardless of probing order.
    
    Signed-off-by: Sjoerd Simons <[email protected]>
    Cc: <[email protected]> # v6.2+
    Fixes: 21aad8ba615e ("arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC")
    Reviewed-by: Marek Behún <[email protected]>
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: hisilicon: hikey970-pmic: fix regulator cells properties [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Thu Nov 30 18:56:34 2023 +0100

    arm64: dts: hisilicon: hikey970-pmic: fix regulator cells properties
    
    [ Upstream commit 44ab3ee76a5a977864ba0bb6c352dcf6206804e0 ]
    
    The Hi6421 PMIC regulator child nodes do not have unit addresses so drop
    the incorrect '#address-cells' and '#size-cells' properties.
    
    Fixes: 6219b20e1ecd ("arm64: dts: hisilicon: Add support for Hikey 970 PMIC")
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Wei Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm: Reduce GPU to nominal speed [+ + +]
Author: Adam Ford <[email protected]>
Date:   Tue Nov 28 14:02:16 2023 -0600

    arm64: dts: imx8mm: Reduce GPU to nominal speed
    
    [ Upstream commit 1f794d3eed5345413c2b0cf1bcccc92d77681220 ]
    
    When the GPU nodes were added, the GPU_PLL_OUT was configured
    for 1000MHz, but this requires the SoC to run in overdrive mode
    which requires an elevated voltage operating point.
    
    Since this may run some boards out of spec, the default clock
    should be set to 800MHz for nominal operating mode. Boards
    that run at the higher voltage can update their clocks
    accordingly.
    
    Fixes: 4523be8e46be ("arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core")
    Signed-off-by: Adam Ford <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8183: correct MDP3 DMA-related nodes [+ + +]
Author: Moudy Ho <[email protected]>
Date:   Mon Oct 30 17:48:38 2023 +0800

    arm64: dts: mediatek: mt8183: correct MDP3 DMA-related nodes
    
    [ Upstream commit 188ffcd7fea79af3cac441268fc99f60e87f03b3 ]
    
    In order to generalize the node names, the DMA-related nodes
    corresponding to MT8183 MDP3 need to be corrected.
    
    Fixes: 60a2fb8d202a ("arm64: dts: mt8183: add MediaTek MDP3 nodes")
    Signed-off-by: Moudy Ho <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186: fix address warning for ADSP mailboxes [+ + +]
Author: Eugen Hristev <[email protected]>
Date:   Mon Dec 4 15:55:33 2023 +0200

    arm64: dts: mediatek: mt8186: fix address warning for ADSP mailboxes
    
    [ Upstream commit 840e341bed3c4331061031dc9db0aff04abafb4b ]
    
    Fix warnings reported by dtbs_check :
    
    arch/arm64/boot/dts/mediatek/mt8186.dtsi:1163.35-1168.5: Warning (simple_bus_reg):
     /soc/mailbox@10686000: simple-bus unit address format error, expected "10686100"
    arch/arm64/boot/dts/mediatek/mt8186.dtsi:1170.35-1175.5: Warning (simple_bus_reg):
     /soc/mailbox@10687000: simple-bus unit address format error, expected "10687100"
    
    by having the right bus address as node name.
    
    Fixes: 379cf0e639ae ("arm64: dts: mediatek: mt8186: Add ADSP mailbox nodes")
    Signed-off-by: Eugen Hristev <[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: mt8186: Fix alias prefix for ovl_2l0 [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Thu Nov 30 15:40:31 2023 +0800

    arm64: dts: mediatek: mt8186: Fix alias prefix for ovl_2l0
    
    [ Upstream commit 6ed159e499bc2ebedf94c9086244220824e71672 ]
    
    The alias prefix for ovl_2l (2 layer overlay) is "ovl-2l", not "ovl_2l".
    
    Fix this.
    
    Fixes: 7e07d3322de2 ("arm64: dts: mediatek: mt8186: Add display nodes")
    Signed-off-by: Chen-Yu Tsai <[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: mt8195: revise VDOSYS RDMA node name [+ + +]
Author: Moudy Ho <[email protected]>
Date:   Mon Oct 30 17:48:39 2023 +0800

    arm64: dts: mediatek: mt8195: revise VDOSYS RDMA node name
    
    [ Upstream commit 52f4a10f2a860402c130c5c21d055e721d63a7e9 ]
    
    DMA-related nodes have their own standardized naming. Therefore,
    the MT8195 VDOSYS RDMA has been unified and corrected.
    Additionally, these modifications will facilitate the further
    integration of bindings.
    
    Fixes: 92d2c23dc269 ("arm64: dts: mt8195: add display node for vdosys1")
    Signed-off-by: Moudy Ho <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: acer-aspire1: Correct audio codec definition [+ + +]
Author: Nikita Travkin <[email protected]>
Date:   Tue Dec 5 16:48:11 2023 +0500

    arm64: dts: qcom: acer-aspire1: Correct audio codec definition
    
    [ Upstream commit feec9f0add432a867f23e29afcd2f7088889b8e2 ]
    
    When initially added, a mistake was made in the definition of the codec.
    
    Despite the fact that the DMIC line is connected on the side of the
    codec chip, and relevant passive components, including 0-ohm resistors
    connecting the dmics, are present, the dmic line is still cut in
    another place on the board, which was overlooked.
    
    Correct this by replacing the dmic configuration with a comment
    describing this hardware detail.
    
    While at it, also add missing regulators definitions. This is not a
    functional change as all the relevant regulators were already added via
    the other rail supplies.
    
    Fixes: 4a9f8f8f2ada ("arm64: dts: qcom: Add Acer Aspire 1")
    Signed-off-by: Nikita Travkin <[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: ipq6018: fix clock rates for GCC_USB0_MOCK_UTMI_CLK [+ + +]
Author: Chukun Pan <[email protected]>
Date:   Mon Dec 18 23:08:05 2023 +0800

    arm64: dts: qcom: ipq6018: fix clock rates for GCC_USB0_MOCK_UTMI_CLK
    
    [ Upstream commit 5c0dbe8b058436ad5daecb19c60869f832607ea3 ]
    
    The downstream QSDK kernel [1] and GCC_USB1_MOCK_UTMI_CLK are both 24MHz.
    Adjust GCC_USB0_MOCK_UTMI_CLK to 24MHz to avoid the following error:
    
    clk: couldn't set gcc_usb0_mock_utmi_clk clk rate to 20000000 (-22), current rate: 24000000
    
    1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/commit/486c8485f59
    
    Fixes: 5726079cd486 ("arm64: dts: ipq6018: Use reference clock to set dwc3 period")
    Signed-off-by: Chukun Pan <[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: qrb2210-rb1: use USB host mode [+ + +]
Author: Caleb Connolly <[email protected]>
Date:   Wed Oct 25 12:58:00 2023 +0100

    arm64: dts: qcom: qrb2210-rb1: use USB host mode
    
    [ Upstream commit e0cee8dc6757f9f18718eec553be9fffa503e103 ]
    
    The default for the QCM2290 platform that this board is based on is OTG
    mode, however the role detection logic is not hooked up for this board
    and the dwc3 driver is configured to not allow role switching from
    userspace.
    
    Force this board to host mode as this is the preferred usecase until we
    get role switching hooked up.
    
    Fixes: e18771961336 ("arm64: dts: qcom: Add initial QTI RB1 device tree")
    Signed-off-by: Caleb Connolly <[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: qrb4210-rb2: don't force usb peripheral mode [+ + +]
Author: Caleb Connolly <[email protected]>
Date:   Tue Oct 10 11:46:58 2023 +0100

    arm64: dts: qcom: qrb4210-rb2: don't force usb peripheral mode
    
    [ Upstream commit 27c2ca90e2f34cd3c4849af996e1a96a69e700d3 ]
    
    The rb2 only has a single USB controller, it can be switched between a
    type-c port and an internal USB hub via a DIP switch. Until dynamic
    role switching is available it's preferable to put the USB controller
    in host mode so that the type-A ports and ethernet are available.
    
    Signed-off-by: Caleb Connolly <[email protected]>
    Reviewed-by: Vladimir Zapolskiy <[email protected]>
    Fixes: eaa53a85748d ("arm64: dts: qcom: qrb4210-rb2: Enable USB node")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: qrb5165-rb5: correct LED panic indicator [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Nov 11 10:46:23 2023 +0100

    arm64: dts: qcom: qrb5165-rb5: correct LED panic indicator
    
    [ Upstream commit dc6b5562acbac0285ab3b2dad23930b6434bdfc6 ]
    
    There is no "panic-indicator" default trigger but a property with that
    name:
    
      qrb5165-rb5.dtb: leds: led-user4: Unevaluated properties are not allowed ('linux,default-trigger' was unexpected)
    
    Fixes: b5cbd84e499a ("arm64: dts: qcom: qrb5165-rb5: Add onboard LED support")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-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: qrb5165-rb5: use u16 for DP altmode svid [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Dec 4 04:03:02 2023 +0200

    arm64: dts: qcom: qrb5165-rb5: use u16 for DP altmode svid
    
    [ Upstream commit 70e6163d17dd501ef27680eeb80d78b2cf823c5e ]
    
    Follow the bindings and use 16-bit value for AltMode SVID instead of
    using the full u32.
    
    Fixes: b3dea914127e ("arm64: dts: qcom: qrb5165-rb5: enable DP altmode")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[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]>

arm64: dts: qcom: sa8775p: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Nov 20 17:43:22 2023 +0100

    arm64: dts: qcom: sa8775p: fix USB wakeup interrupt types
    
    [ Upstream commit 0984bc0165f7c5203dfffe8cdb5186995f628a80 ]
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Note that only triggering on rising edges can be used to detect resume
    events but not disconnect events.
    
    Fixes: de1001525c1a ("arm64: dts: qcom: sa8775p: add USB nodes")
    Cc: Shazad Hussain <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Andrew Halaney <[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: sa8775p: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:33 2023 -0800

    arm64: dts: qcom: sa8775p: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 48d5cf4772ec6268853158d9ffc54612e988ebe6 ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 09b701b89a76 ("arm64: dts: qcom: sa8775p: add the watchdog node")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Bartosz Golaszewski <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.6.I909b7c4453d7b7fb0db4b6e49aa21666279d827d@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7180: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:28 2023 -0800

    arm64: dts: qcom: sc7180: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 7ac90b4cf107a3999b30844d7899e0331686b33b ]
    
    On sc7180 when the watchdog timer fires your logs get filled with:
      watchdog0: pretimeout event
      watchdog0: pretimeout event
      watchdog0: pretimeout event
      ...
      watchdog0: pretimeout event
    
    If you're using console-ramoops to debug crashes the above gets quite
    annoying since it blows away any other log messages that might have
    been there.
    
    The issue is that the "bark" interrupt (AKA the "pretimeout"
    interrupt) remains high until the watchdog is pet. Since we've got
    things configured as "level" triggered we'll keep getting interrupted
    over and over.
    
    Let's switch to edge triggered. Now we'll get one interrupt when the
    "bark" interrupt goes off and won't get another one until the "bark"
    interrupt is cleared and asserts again.
    
    This matches how many older Qualcomm SoCs have things configured.
    
    Fixes: 28cc13e4060c ("arm64: dts: qcom: sc7180: Add watchdog bark interrupt")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.1.Ic7577567baff921347d423b722de8b857602efb1@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7280: Fix up GPU SIDs [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Nov 20 13:12:53 2023 +0100

    arm64: dts: qcom: sc7280: Fix up GPU SIDs
    
    [ Upstream commit 94085049fdad7a36fe14dd55e72e712fe55d6bca ]
    
    GPU_SMMU SID 1 is meant for Adreno LPAC (Low Priority Async Compute).
    On platforms that support it (in firmware), it is necessary to
    describe that link, or Adreno register access will hang the board.
    
    The current settings are functionally identical, *but* due to what is
    likely hardcoded security policies, the secure firmware rejects them,
    resulting in the board hanging. To avoid that, alter the settings such
    that SID 0 and 1 are described separately.
    
    Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu 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]>

arm64: dts: qcom: sc7280: fix usb_2 wakeup interrupt types [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Nov 20 17:43:25 2023 +0100

    arm64: dts: qcom: sc7280: fix usb_2 wakeup interrupt types
    
    [ Upstream commit 24f8aba9a7c77c7e9d814a5754798e8346c7dd28 ]
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Note that only triggering on rising edges can be used to detect resume
    events but not disconnect events.
    
    Fixes: bb9efa59c665 ("arm64: dts: qcom: sc7280: Add USB related nodes")
    Signed-off-by: Johan Hovold <[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: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:29 2023 -0800

    arm64: dts: qcom: sc7280: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 6897fac411db7b43243f67d4fd4d3f95abf7f656 ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 0e51f883daa9 ("arm64: dts: qcom: sc7280: Add APSS watchdog node")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.2.I11f77956d2492c88aca0ef5462123f225caf4fb4@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7280: Mark Adreno SMMU as DMA coherent [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Nov 20 13:12:54 2023 +0100

    arm64: dts: qcom: sc7280: Mark Adreno SMMU as DMA coherent
    
    [ Upstream commit 31edad478534186a2718be9206ce7b19f2735f6e ]
    
    The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
    mark the GPU one as well.
    
    Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
    Reviewed-by: Akhil P Oommen <[email protected]>
    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: sc7280: Mark SDHCI hosts as cache-coherent [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 15:38:33 2023 +0100

    arm64: dts: qcom: sc7280: Mark SDHCI hosts as cache-coherent
    
    [ Upstream commit 827f5fc8d912203c1f971e47d61130b13c6820ba ]
    
    The SDHCI hosts on SC7280 are cache-coherent, just like on most fairly
    recent Qualcomm SoCs. Mark them as such.
    
    Fixes: 298c81a7d44f ("arm64: dts: qcom: sc7280: Add nodes for eMMC and SD card")
    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-primus: Fix HALL_INT polarity [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Thu Nov 30 16:11:10 2023 -0800

    arm64: dts: qcom: sc8180x-primus: Fix HALL_INT polarity
    
    [ Upstream commit 1aaa08e8de365cce59203541cafadb5053b1ec1a ]
    
    The hall sensor interrupt on the Primus is active low, which means that
    with the current configuration the device attempts to suspend when the
    LID is open.
    
    Fix the polarity of the HALL_INT GPIO to avoid this.
    
    Fixes: 2ce38cc1e8fe ("arm64: dts: qcom: sc8180x: Introduce Primus")
    Signed-off-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/20231130-sc8180x-primus-lid-polarity-v1-1-da917b59604b@quicinc.com
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc8180x: Fix up PCIe nodes [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Dec 19 14:05:06 2023 +0100

    arm64: dts: qcom: sc8180x: Fix up PCIe nodes
    
    [ Upstream commit 78403b37f6770441f80a78d13772394731afe055 ]
    
    Duplicated clock output names cause probe errors and wrong clocks cause
    hardware not to work. Fix such issues.
    
    Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances")
    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: Mark PCIe hosts cache-coherent [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Dec 19 19:40:21 2023 +0100

    arm64: dts: qcom: sc8180x: Mark PCIe hosts cache-coherent
    
    [ Upstream commit 45e8c72712345263208f7c94f334fa718634f557 ]
    
    The PCIe controllers on 8180 are cache-coherent. Mark them as such.
    
    Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances")
    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: sc8280xp-x13s: add missing camera LED pin config [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 3 11:36:47 2023 +0200

    arm64: dts: qcom: sc8280xp-x13s: add missing camera LED pin config
    
    [ Upstream commit a3457cc5bc30ad053c90ae9f14e9b7723d204a98 ]
    
    Add the missing pin configuration for the recently added camera
    indicator LED.
    
    Fixes: 1c63dd1c5fda ("arm64: dts: qcom: sc8280xp-x13s: Add camera activity LED")
    Cc: Konrad Dybcio <[email protected]>
    Signed-off-by: Johan Hovold <[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: sc8280xp-x13s: Use the correct DP PHY compatible [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Fri Sep 29 18:02:57 2023 +0200

    arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY compatible
    
    [ Upstream commit 0cd080dd6d08817c9980d2069197b066636b0f23 ]
    
    The DP PHY needs different settings when an eDP display is used.
    Make sure these apply on the X13s.
    
    FWIW
    I could not notice any user-facing change stemming from this commit.
    
    Fixes: f48c70b111b4 ("arm64: dts: qcom: sc8280xp-x13s: enable eDP display")
    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: sc8280xp: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:34 2023 -0800

    arm64: dts: qcom: sc8280xp: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 6c4a9c7ea486da490400c84ba2768c90d228c283 ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.7.I1c8ab71570f6906fd020decb80675f05fbe1fe74@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sdm845-db845c: correct LED panic indicator [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Nov 11 10:56:16 2023 +0100

    arm64: dts: qcom: sdm845-db845c: correct LED panic indicator
    
    [ Upstream commit 0c90c75e663246203a2b7f6dd9e08a110f4c3c43 ]
    
    There is no "panic-indicator" default trigger but a property with that
    name:
    
      sdm845-db845c.dtb: leds: led-0: Unevaluated properties are not allowed ('linux,default-trigger' was unexpected)
    
    Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c")
    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: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:30 2023 -0800

    arm64: dts: qcom: sdm845: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 263b348499454f38d36b9442c3cf9279c571bb54 ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 36c436b03c58 ("arm64: dts: qcom: sdm845: Add watchdog bark interrupt")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.3.I16675ebe5517c68453a1bd7f4334ff885f806c03@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm6125: add interrupts to DWC3 USB controller [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Nov 11 17:42:28 2023 +0100

    arm64: dts: qcom: sm6125: add interrupts to DWC3 USB controller
    
    [ Upstream commit 67e4656f4487b95a39e45884c99235f62ebfaa47 ]
    
    Add interrupts to SM6125 DWC3 USB controller, based on downstream/vendor
    code of Trinket DTSI from Xiaomi Laurel device, to fix dtbs_check
    warnings:
    
      sm6125-xiaomi-laurel-sprout.dtb: usb@4ef8800: 'interrupt-names' is a required property
      sm6125-xiaomi-laurel-sprout.dtb: usb@4ef8800: 'oneOf' conditional failed, one must be fixed:
        'interrupts' is a required property
        'interrupts-extended' is a required property
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
    Reviewed-by: Marijn Suijten <[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: sm6350: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:35 2023 -0800

    arm64: dts: qcom: sm6350: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 5b84bb2b8d86595544fc8272364b0f1a34b68a4f ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 5f82b9cda61e ("arm64: dts: qcom: Add SM6350 device tree")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.8.Ic1d4402e99c70354d501ccd98105e908a902f671@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm6375: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Nov 20 17:43:29 2023 +0100

    arm64: dts: qcom: sm6375: fix USB wakeup interrupt types
    
    [ Upstream commit 41952be6661b20f56c2c5b06c431880dd975b747 ]
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Fixes: 59d34ca97f91 ("arm64: dts: qcom: Add initial device tree for SM6375")
    Cc: [email protected]      # 6.2
    Cc: Konrad Dybcio <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Stable-dep-of: d3246a0cf43f ("arm64: dts: qcom: sm6375: Hook up MPM")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm6375: Hook up MPM [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Fri Dec 15 01:01:08 2023 +0100

    arm64: dts: qcom: sm6375: Hook up MPM
    
    [ Upstream commit d3246a0cf43fd24a1986163284edd2389143809d ]
    
    Add a node for MPM and wire it up on consumers that use it. This also
    fixes a very bad and sad assumption I made when initially porting this
    SoC that the downstream MPM-TLMM mappings were 1-1. That apparently
    changed some time ago, so with this patch the MPM consumers will actually
    be hooked up to the correct interrupt lines.
    
    Fixes: 59d34ca97f91 ("arm64: dts: qcom: Add initial device tree for SM6375")
    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: sm8150-hdk: fix SS USB regulators [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Fri Dec 15 19:40:35 2023 +0200

    arm64: dts: qcom: sm8150-hdk: fix SS USB regulators
    
    [ Upstream commit a509adf05b2aac31b22781f5aa09e4768a5b6c39 ]
    
    The SM8150-HDK uses two different regulators to power up SuperSpeed USB
    PHYs. The L5A regulator is used for the second USB host, while the first
    (OTG) USB host uses different regulator, L18A. Fix the regulator for the
    usb_1 QMPPHY and (to remove possible confusion) drop the
    usb_ss_dp_core_1/_2 labels.
    
    Fixes: 0ab1b2d10afe ("arm64: dts: qcom: add sm8150 hdk dts")
    Reviewed-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: sm8150: make dispcc cast minimal vote on MMCX [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Fri Dec 15 19:40:33 2023 +0200

    arm64: dts: qcom: sm8150: make dispcc cast minimal vote on MMCX
    
    [ Upstream commit 617de4ce7b1c4b41c1316e493d4717cd2f208def ]
    
    Add required-opps property to the display clock controller. This makes
    it cast minimal vote on the MMCX lane and prevents further 'clock stuck'
    errors when enabling the display.
    
    Fixes: 2ef3bb17c45c ("arm64: dts: qcom: sm8150: Add DISPCC node")
    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: sm8150: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:31 2023 -0800

    arm64: dts: qcom: sm8150: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 9204e9a4099212c850e1703c374ef4538080825b ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: b094c8f8dd2a ("arm64: dts: qcom: sm8150: Add watchdog bark interrupt")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.4.I23d0aa6c8f1fec5c26ad9b3c610df6f4c5392850@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8250: Make watchdog bark interrupt edge triggered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Nov 6 14:43:32 2023 -0800

    arm64: dts: qcom: sm8250: Make watchdog bark interrupt edge triggered
    
    [ Upstream commit 735d80e2e8e5d073ae8b1fff8b1589ea284aa5af ]
    
    As described in the patch ("arm64: dts: qcom: sc7180: Make watchdog
    bark interrupt edge triggered"), the Qualcomm watchdog timer's bark
    interrupt should be configured as edge triggered. Make the change.
    
    Fixes: 46a4359f9156 ("arm64: dts: qcom: sm8250: Add watchdog bark interrupt")
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20231106144335.v2.5.I2910e7c10493d896841e9785c1817df9b9a58701@changeid
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8350: Fix DMA0 address [+ + +]
Author: Nia Espera <[email protected]>
Date:   Sat Nov 11 23:07:40 2023 +0100

    arm64: dts: qcom: sm8350: Fix DMA0 address
    
    [ Upstream commit 01a9e9eb6cdbce175ddea3cbe1163daed6d54344 ]
    
    DMA0 node downstream is specified at 0x900000, so fix the typo. Without
    this, enabling any i2c node using DMA0 causes a hang.
    
    Fixes: bc08fbf49bc8 ("arm64: dts: qcom: sm8350: Define GPI DMA engines")
    Fixes: 41d6bca799b3 ("arm64: dts: qcom: sm8350: correct DMA controller unit address")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Nia Espera <[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: correct TX Soundwire clock [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Nov 29 15:05:36 2023 +0100

    arm64: dts: qcom: sm8450: correct TX Soundwire clock
    
    [ Upstream commit 20e886590a310665244a354e3b693b881544edec ]
    
    The TX Soundwire controller should take clock from TX macro codec, not
    VA macro codec clock, otherwise the clock stays disabled.  This looks
    like a copy-paste issue, because the SC8280xp code uses here correctly
    clock from TX macro.  The VA macro clock is already consumed by TX macro
    codec, thus it won't be disabled by this change.
    
    Fixes: 14341e76dbc7 ("arm64: dts: qcom: sm8450: add Soundwire and LPASS")
    Reported-by: Neil Armstrong <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Acked-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: sm8550: correct TX Soundwire clock [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Nov 29 15:05:37 2023 +0100

    arm64: dts: qcom: sm8550: correct TX Soundwire clock
    
    [ Upstream commit ead0f132fc494b46fcd94788456f9b264fd631bb ]
    
    The TX Soundwire controller should take clock from TX macro codec, not
    VA macro codec clock, otherwise the clock stays disabled.  This looks
    like a copy-paste issue, because the SC8280xp code uses here correctly
    clock from TX macro.  The VA macro clock is already consumed by TX macro
    codec, thus it won't be disabled by this change.
    
    Fixes: 61b006389bb7 ("arm64: dts: qcom: sm8550: add Soundwire controllers")
    Reported-by: Neil Armstrong <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Neil Armstrong <[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 USB wakeup interrupt types [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Nov 20 17:43:31 2023 +0100

    arm64: dts: qcom: sm8550: fix USB wakeup interrupt types
    
    [ Upstream commit 29d91ecf530a4ef0b7f94cb8cde07ed69731e45d ]
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Note that only triggering on rising edges can be used to detect resume
    events but not disconnect events.
    
    Fixes: 7f7e5c1b037f ("arm64: dts: qcom: sm8550: Add USB PHYs and controller nodes")
    Cc: Abel Vesa <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Abel Vesa <[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: Separate out X3 idle state [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:12 2023 +0100

    arm64: dts: qcom: sm8550: Separate out X3 idle state
    
    [ Upstream commit 28b735232d5e16a34f98dbac1e7b5401c1c16d89 ]
    
    The X3 core has different entry/exit/residency time requirements than
    the big cluster. Denote them to stop confusing the scheduler.
    
    Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi")
    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: sm8550: Update idle state time requirements [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:13 2023 +0100

    arm64: dts: qcom: sm8550: Update idle state time requirements
    
    [ Upstream commit ad6556fb45d4ab91ad786a2025cbe2b0f2e6cf77 ]
    
    The idle state entry/exit/residency times differ from what shipped on
    production devices, mostly being overly optimistic in entry times and
    overly pessimistic in minimal residency times. Align them with
    downstream sources.
    
    Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi")
    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: renesas: white-hawk-cpu: Fix missing serial console pin control [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Dec 13 10:32:25 2023 +0100

    arm64: dts: renesas: white-hawk-cpu: Fix missing serial console pin control
    
    [ Upstream commit fc67495680f60e88bb8ca43421c1dd628928d581 ]
    
    The pin control description for the serial console was added, but not
    enabled, due to missing pinctrl properties in the serial port device
    node.
    
    Fixes: 7a8d590de8132853 ("arm64: dts: renesas: white-hawk-cpu: Add serial port pin control")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/8a51516581cd71ecbfa174af9c7cebad1fc83c5b.1702459865.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Fix led pinctrl of lubancat 1 [+ + +]
Author: Andy Yan <[email protected]>
Date:   Mon Dec 25 08:50:55 2023 +0800

    arm64: dts: rockchip: Fix led pinctrl of lubancat 1
    
    [ Upstream commit 8586a5d217ef7bfeee24943c600a8a7890d6f477 ]
    
    According to the schematics, the gpio control sys_led is GPIO0_C5.
    
    Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
    Reported-by: Zhang Ning <[email protected]>
    Closes: https://lore.kernel.org/linux-rockchip/OS0P286MB06412D049D8BF7B063D41350CD95A@OS0P286MB0641.JPNP286.PROD.OUTLOOK.COM/T/#u
    Signed-off-by: Andy Yan <[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: ti: iot2050: Re-add aliases [+ + +]
Author: Jan Kiszka <[email protected]>
Date:   Sat Nov 4 09:52:15 2023 +0100

    arm64: dts: ti: iot2050: Re-add aliases
    
    [ Upstream commit ad8edf4ff37ab157f6547da173aedc9f4e5c4015 ]
    
    Lost while dropping them from the common dtsi.
    
    Fixes: ffc449e016e2 ("arm64: dts: ti: k3-am65: Drop aliases")
    Signed-off-by: Jan Kiszka <[email protected]>
    Link: https://lore.kernel.org/r/1edbc1b56ed4ff2256d7afb7db3cab4b3a423692.1699087938.git.jan.kiszka@siemens.com
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am62a-main: Fix GPIO pin count in DT nodes [+ + +]
Author: Nitin Yadav <[email protected]>
Date:   Fri Oct 27 12:29:30 2023 +0530

    arm64: dts: ti: k3-am62a-main: Fix GPIO pin count in DT nodes
    
    [ Upstream commit 7dc4af358cc382c5d20bd5b726e53ef0f526eb6d ]
    
    Fix number of gpio pins in main_gpio0 & main_gpio1 DT nodes according
    to AM62A7 datasheet[0].
    
    [0] https://www.ti.com/lit/gpn/am62a3 Section: 6.3.10 GPIO (Page No. 52-55)
    Fixes: 5fc6b1b62639 ("arm64: dts: ti: Introduce AM62A7 family of SoCs")
    Signed-off-by: Nitin Yadav <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Mon Nov 6 11:57:48 2023 +0200

    arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type
    
    [ Upstream commit b57160859263c083c49482b0d083a586b1517f78 ]
    
    DSS irq trigger type is set to IRQ_TYPE_EDGE_RISING in the DT file, but
    the TRM says it is level triggered.
    
    For some reason triggering on rising edge results in double the amount
    of expected interrupts, e.g. for normal page flipping test the number of
    interrupts per second is 2 * fps. It is as if the IRQ triggers on both
    edges. There are no other side effects to this issue than slightly
    increased CPU & power consumption due to the extra interrupt.
    
    Switching to IRQ_TYPE_LEVEL_HIGH is correct and fixes the issue, so
    let's do that.
    
    Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: xilinx: Apply overlays to base dtbs [+ + +]
Author: Rob Herring <[email protected]>
Date:   Mon Sep 11 16:47:47 2023 -0500

    arm64: dts: xilinx: Apply overlays to base dtbs
    
    [ Upstream commit 23b697ec85f3e7beed271b9f344c54821de2251e ]
    
    DT overlays in tree need to be applied to a base DTB to validate they
    apply, to run schema checks on them, and to catch any errors at compile
    time. Defining the "-dtbs" variable is not enough as the combined DT must
    be added to dtbs-y.
    
    zynqmp-sck-kr-g-revA.dtso and zynqmp-sck-kr-g-revB.dtso don't exist, so drop
    them.
    
    Signed-off-by: Rob Herring <[email protected]>
    Fixes: 45fe0dc4ea2e ("arm64: xilinx: Use zynqmp prefix for SOM dt overlays")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michal Simek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: 9330/1: davinci: also select PINCTRL [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Tue Nov 7 01:36:03 2023 +0100

    ARM: 9330/1: davinci: also select PINCTRL
    
    [ Upstream commit f54e8634d1366926c807e2af6125b33cff555fa7 ]
    
    kconfig warns when PINCTRL_SINGLE is selected but PINCTRL is not
    set, so also set PINCTRL for ARCH_DAVINCI. This prevents a
    kconfig/build warning:
    
       WARNING: unmet direct dependencies detected for PINCTRL_SINGLE
         Depends on [n]: PINCTRL [=n] && OF [=y] && HAS_IOMEM [=y]
         Selected by [y]:
         - ARCH_DAVINCI [=y] && ARCH_MULTI_V5 [=y]
    
    Closes: lore.kernel.org/r/[email protected]
    
    Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: Bartosz Golaszewski <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: davinci: always select CONFIG_CPU_ARM926T [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Jan 8 12:00:36 2024 +0100

    ARM: davinci: always select CONFIG_CPU_ARM926T
    
    [ Upstream commit 40974ee421b4d1fc74ac733d86899ce1b83d8f65 ]
    
    The select was lost by accident during the multiplatform conversion.
    Any davinci-only
    
    arm-linux-gnueabi-ld: arch/arm/mach-davinci/sleep.o: in function `CACHE_FLUSH':
    (.text+0x168): undefined reference to `arm926_flush_kern_cache_all'
    
    Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5")
    Acked-by: Bartosz Golaszewski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: apq8064: correct XOADC register address [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Thu Sep 28 14:02:35 2023 +0300

    ARM: dts: qcom: apq8064: correct XOADC register address
    
    [ Upstream commit 554557542e709e190eff8a598f0cde02647d533a ]
    
    The XOADC is present at the address 0x197 rather than just 197. It
    doesn't change a lot (since the driver hardcodes all register
    addresses), but the DT should present correct address anyway.
    
    Fixes: c4b70883ee33 ("ARM: dts: add XOADC and IIO HWMON to APQ8064")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[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]>

ARM: dts: qcom: msm8226: provide dsi phy clocks to mmcc [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Wed Jul 12 09:52:07 2023 +0200

    ARM: dts: qcom: msm8226: provide dsi phy clocks to mmcc
    
    [ Upstream commit 836d083524888069cd358776a4e6c4ceec04962e ]
    
    Some mmcc clocks have dsi0pll & dsi0pllbyte as clock parents so we
    should provide them in the dt, which I missed in the commit adding the
    mdss nodes.
    
    Fixes: d5fb01ad5eb4 ("ARM: dts: qcom: msm8226: Add mdss nodes")
    Signed-off-by: Luca Weiss <[email protected]>
    Reviewed-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]>

ARM: dts: qcom: sdx55: Fix the base address of PCIe PHY [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Mon Dec 11 22:54:11 2023 +0530

    ARM: dts: qcom: sdx55: Fix the base address of PCIe PHY
    
    commit cc6fc55c7ae04ab19b3972f78d3a8b1be32bf533 upstream.
    
    While convering the binding to new format, serdes address specified in the
    old binding was used as the base address. This causes a boot hang as the
    driver tries to access memory region outside of the specified address. Fix
    it!
    
    Cc: Dmitry Baryshkov <[email protected]>
    Cc: [email protected] # 6.6
    Fixes: bb56cff4ac03 ("ARM: dts: qcom-sdx55: switch PCIe QMP PHY to new style of bindings")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ARM: dts: qcom: sdx65: correct PCIe EP phy-names [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Sep 24 20:31:01 2023 +0200

    ARM: dts: qcom: sdx65: correct PCIe EP phy-names
    
    [ Upstream commit 94da379dba88c4cdd562bad21c9ba5656e5ed5df ]
    
    Qualcomm PCIe endpoint bindings expect phy-names to be "pciephy":
    
      arch/arm/boot/dts/qcom/qcom-sdx65-mtp.dtb: pcie-ep@1c00000: phy-names:0: 'pciephy' was expected
    
    Fixes: 9c0bb38414a4 ("ARM: dts: qcom: sdx65: Add support for PCIe EP")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: qcom: sdx65: correct SPMI node name [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Sep 24 20:31:03 2023 +0200

    ARM: dts: qcom: sdx65: correct SPMI node name
    
    [ Upstream commit a900ad783f507cb396e402827052e70c0c565ae9 ]
    
    Node names should not have vendor prefixes:
    
      qcom-sdx65-mtp.dtb: qcom,spmi@c440000: $nodename:0: 'qcom,spmi@c440000' does not match '^spmi@.*
    
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: stm32: don't mix SCMI and non-SCMI board compatibles [+ + +]
Author: Ahmad Fatoum <[email protected]>
Date:   Wed Nov 22 19:52:34 2023 +0100

    ARM: dts: stm32: don't mix SCMI and non-SCMI board compatibles
    
    [ Upstream commit bfc3c6743de0ecb169026c36cbdbc0d12d22a528 ]
    
    The binding erroneously decreed that the SCMI variants of the ST
    evaluation kits are compatible with the non-SCMI variants.
    
    This is not correct, as a kernel or bootloader compatible with the non-SCMI
    variant is not necessarily able to function, when direct access
    to resources is replaced by having to talk SCMI to the secure monitor.
    
    The binding has been adjusted to reflect thus, so synchronize the device
    trees now.
    
    Fixes: 5b7e58313a77 ("ARM: dts: stm32: Add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)")
    Signed-off-by: Ahmad Fatoum <[email protected]>
    Signed-off-by: Alexandre Torgue <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
asm-generic: Fix 32 bit __generic_cmpxchg_local [+ + +]
Author: David McKay <[email protected]>
Date:   Thu Jan 4 09:40:10 2024 +0000

    asm-generic: Fix 32 bit __generic_cmpxchg_local
    
    [ Upstream commit d93cca2f3109f88c94a32d3322ec8b2854a9c339 ]
    
    Commit 656e9007ef58 ("asm-generic: avoid __generic_cmpxchg_local
    warnings") introduced a typo that means the code is incorrect for 32 bit
    values. It will work fine for postive numbers, but will fail for
    negative numbers on a system where longs are 64 bit.
    
    Fixes: 656e9007ef58 ("asm-generic: avoid __generic_cmpxchg_local warnings")
    Signed-off-by: David McKay <[email protected]>
    Signed-off-by: Stuart Menefy <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: vangogh: Drop conflicting ACPI-based probing [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Sat Dec 9 22:32:19 2023 +0200

    ASoC: amd: vangogh: Drop conflicting ACPI-based probing
    
    [ Upstream commit ddd1ee12a8fb6e4d6f86eddeba64c135eee56623 ]
    
    The Vangogh machine driver variant based on the MAX98388 amplifier, as
    found on Valve's Steam Deck OLED, relies on probing via an ACPI match
    table.  This worked fine until commit 197b1f7f0df1 ("ASoC: amd: Add new
    dmi entries to config entry") enabled SOF support for the target machine
    (i.e. Galileo product), causing the sound card to enter the deferred
    probe state indefinitely:
    
    $ cat /sys/kernel/debug/devices_deferred
    AMDI8821:00     acp5x_mach: Register card (acp5x-max98388) failed
    
    The issue is related to commit e89f45edb747 ("ASoC: amd: vangogh: Add
    check for acp config flags in vangogh platform"), which tries to
    mitigate potential conflicts between SOF and generic ACP Vangogh
    drivers, due to sharing the PCI device IDs.
    
    However, the solution is effective only if the machine driver is
    directly probed by pci-acp5x through platform_device_register_full().
    
    Hence, remove the conflicting ACPI based probing and rely exclusively on
    DMI quirks for sound card setup.
    
    Fixes: dba22efd0d17 ("ASoC: amd: vangogh: Add support for NAU8821/MAX98388 variant")
    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: cs35l33: Fix GPIO name and drop legacy include [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Fri Dec 1 14:20:31 2023 +0100

    ASoC: cs35l33: Fix GPIO name and drop legacy include
    
    [ Upstream commit 50678d339d670a92658e5538ebee30447c88ccb3 ]
    
    This driver includes the legacy GPIO APIs <linux/gpio.h> and
    <linux/of_gpio.h> but does not use any symbols from any of
    them.
    
    Drop the includes.
    
    Further the driver is requesting "reset-gpios" rather than
    just "reset" from the GPIO framework. This is wrong because
    the gpiolib core will add "-gpios" before processing the
    request from e.g. device tree. Drop the suffix.
    
    The last problem means that the optional RESET GPIO has
    never been properly retrieved and used even if it existed,
    but nobody noticed.
    
    Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.")
    Acked-by: Charles Keepax <[email protected]>
    Signed-off-by: Linus Walleij <[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: cs35l34: Fix GPIO name and drop legacy include [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Fri Dec 1 14:20:32 2023 +0100

    ASoC: cs35l34: Fix GPIO name and drop legacy include
    
    [ Upstream commit a6122b0b4211d132934ef99e7b737910e6d54d2f ]
    
    This driver includes the legacy GPIO APIs <linux/gpio.h> and
    <linux/of_gpio.h> but does not use any symbols from any of
    them.
    
    Drop the includes.
    
    Further the driver is requesting "reset-gpios" rather than
    just "reset" from the GPIO framework. This is wrong because
    the gpiolib core will add "-gpios" before processing the
    request from e.g. device tree. Drop the suffix.
    
    The last problem means that the optional RESET GPIO has
    never been properly retrieved and used even if it existed,
    but nobody noticed.
    
    Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.")
    Acked-by: Charles Keepax <[email protected]>
    Signed-off-by: Linus Walleij <[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: fsl_rpmsg: update Kconfig dependencies [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Nov 29 12:31:17 2023 +0100

    ASoC: fsl_rpmsg: update Kconfig dependencies
    
    [ Upstream commit 9cce9c4806a89439ea34aad2e382150d68c7ea95 ]
    
    SND_SOC_IMX_RPMSG gained a new dependency and gets selected by SND_SOC_FSL_RPMSG,
    which as a result needs to have the same dependency, or produce a build failure
    based on that:
    
    WARNING: unmet direct dependencies detected for SND_SOC_IMX_RPMSG
      Depends on [n]: SOUND [=y] && SND [=y] && SND_SOC [=y] && SND_IMX_SOC [=y] && RPMSG [=y] && OF [=y] && I2C [=n]
      Selected by [y]:
      - SND_SOC_FSL_RPMSG [=y] && SOUND [=y] && SND [=y] && SND_SOC [=y] && COMMON_CLK [=y] && RPMSG [=y] && (SND_IMX_SOC [=y] || SND_IMX_SOC [=y]=n) && SND_IMX_SOC [=y]!=n
    x86_64-linux-ld: sound/soc/fsl/imx-rpmsg.o: in function `imx_rpmsg_late_probe':
    imx-rpmsg.c:(.text+0x11e): undefined reference to `i2c_find_device_by_fwnode'
    
    Fixes: f83d38def6b1 ("ASoC: imx-rpmsg: SND_SOC_IMX_RPMSG should depend on OF and I2C")
    Signed-off-by: Arnd Bergmann <[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: Intel: glk_rt5682_max98357a: fix board id mismatch [+ + +]
Author: Brent Lu <[email protected]>
Date:   Mon Dec 4 15:41:58 2023 -0600

    ASoC: Intel: glk_rt5682_max98357a: fix board id mismatch
    
    [ Upstream commit 486ede0df82dd74472c6f5651e38ff48f7f766c1 ]
    
    The drv_name in enumeration table for ALC5682I-VS codec does not match
    the board id string in machine driver. Modify the entry of "10EC5682"
    to enumerate "RTL5682" as well and remove invalid entry.
    
    Fixes: 88b4d77d6035 ("ASoC: Intel: glk_rt5682_max98357a: support ALC5682I-VS codec")
    Reported-by: Curtis Malainey <[email protected]>
    Reviewed-by: Curtis Malainey <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Signed-off-by: Brent Lu <[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: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL [+ + +]
Author: Bard Liao <[email protected]>
Date:   Mon Dec 4 15:41:59 2023 -0600

    ASoC: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL
    
    [ Upstream commit e38e252dbceeef7d2f848017132efd68e9ae1416 ]
    
    sof_sdw_rt_sdca_jack_exit() are used by different codecs, and some of
    them use the same dai name.
    For example, rt712 and rt713 both use "rt712-sdca-aif1" and
    sof_sdw_rt_sdca_jack_exit().
    As a result, sof_sdw_rt_sdca_jack_exit() will be called twice by
    mc_dailink_exit_loop(). Set ctx->headset_codec_dev = NULL; after
    put_device(ctx->headset_codec_dev); to avoid ctx->headset_codec_dev
    being put twice.
    
    Fixes: 5360c6704638 ("ASoC: Intel: sof_sdw: add rt712 support")
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Signed-off-by: Bard Liao <[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: mediatek: sof-common: Add NULL check for normal_link string [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jan 11 11:52:26 2024 +0100

    ASoC: mediatek: sof-common: Add NULL check for normal_link string
    
    [ Upstream commit e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed ]
    
    It's not granted that all entries of struct sof_conn_stream declare
    a `normal_link` (a non-SOF, direct link) string, and this is the case
    for SoCs that support only SOF paths (hence do not support both direct
    and SOF usecases).
    
    For example, in the case of MT8188 there is no normal_link string in
    any of the sof_conn_stream entries and there will be more drivers
    doing that in the future.
    
    To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.
    
    Fixes: 0caf1120c583 ("ASoC: mediatek: mt8195: extract SOF common code")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt5645: Drop double EF20 entry from dmi_platform_data[] [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sun Nov 26 22:40:18 2023 +0100

    ASoC: rt5645: Drop double EF20 entry from dmi_platform_data[]
    
    [ Upstream commit 51add1687f39292af626ac3c2046f49241713273 ]
    
    dmi_platform_data[] first contains a DMI entry matching:
    
       DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
    
    and then contains an identical entry except for the match being:
    
       DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
    
    Since these are partial (non exact) DMI matches the first match
    will also match any board with "EF20EA" in their DMI product-name,
    drop the second, redundant, entry.
    
    Fixes: a4dae468cfdd ("ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series")
    Cc: Chris Chiu <[email protected]>
    Signed-off-by: Hans de Goede <[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: Intel: pci-mtl: fix ARL-S definitions [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Mon Dec 4 15:27:09 2023 -0600

    ASoC: SOF: Intel: pci-mtl: fix ARL-S definitions
    
    [ Upstream commit a00be6dc9bb80796244196033aa5eb258b6af47a ]
    
    The initial copy/paste from MTL was incorrect, the hardware is
    different and requires different descriptors along with a dedicated
    firmware binary.
    
    Fixes: 3851831f529e ("ASoC: SOF: Intel: pci-mtl: use ARL specific firmware definitions")
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Acked-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc4-loader: remove the CPC check warnings [+ + +]
Author: Kai Vehmanen <[email protected]>
Date:   Mon Jan 15 11:22:09 2024 +0200

    ASoC: SOF: ipc4-loader: remove the CPC check warnings
    
    [ Upstream commit ab09fb9c629ed3aaea6a82467f08595dbc549726 ]
    
    Warnings related to missing data in firmware manifest have
    proven to be too verbose. This relates to description of
    DSP module cost expressed in cycles per chunk (CPC). If
    a matching value is not found in the manifest, kernel will
    pass a zero value and DSP firmware will use a conservative
    value in its place.
    
    Downgrade the warnings to dev_dbg().
    
    Fixes: d8a2c9879349 ("ASoC: SOF: ipc4-loader/topology: Query the CPC value from manifest")
    Signed-off-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Signed-off-by: Peter Ujfalusi <[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: topology: Use partial match for disconnecting DAI link and DAI widget [+ + +]
Author: Bard Liao <[email protected]>
Date:   Mon Dec 4 15:47:10 2023 -0600

    ASoC: SOF: topology: Use partial match for disconnecting DAI link and DAI widget
    
    [ Upstream commit 2f03970198d6438d95b96f69041254bd39aafed0 ]
    
    We use partial match for connecting DAI link and DAI widget. We need to
    use partial match for disconnecting, too.
    
    Fixes: fe88788779fc ("ASoC: SOF: topology: Use partial match for connecting DAI link and DAI widget")
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Signed-off-by: Bard Liao <[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: tas2781: add support for FW version 0x0503 [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Thu Dec 14 01:25:39 2023 +0100

    ASoC: tas2781: add support for FW version 0x0503
    
    [ Upstream commit ee00330a5b78e2acf4b3aac32913da43e2c12a26 ]
    
    Layout of FW version 0x0503 is compatible with 0x0502.
    Already supported by TI's tas2781-linux-driver tree.
    https://git.ti.com/cgit/tas2781-linux-drivers/tas2781-linux-driver/
    
    Fixes: 915f5eadebd2 ("ASoC: tas2781: firmware lib")
    Signed-off-by: Gergo Koteles <[email protected]>
    Link: https://msgid.link/r/98d4ee4e01e834af72a1a0bea6736facf43582e0.1702513517.git.soyer@irl.hu
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
base/node.c: initialize the accessor list before registering [+ + +]
Author: Gregory Price <[email protected]>
Date:   Mon Oct 30 00:42:39 2023 -0400

    base/node.c: initialize the accessor list before registering
    
    [ Upstream commit 48b5928e18dc27e05cab3dc4c78cd8a15baaf1e5 ]
    
    The current code registers the node as available in the node array
    before initializing the accessor list.  This makes it so that
    anything which might access the accessor list as a result of
    allocations will cause an undefined memory access.
    
    In one example, an extension to access hmat data during interleave
    caused this undefined access as a result of a bulk allocation
    that occurs during node initialization but before the accessor
    list is initialized.
    
    Initialize the accessor list before making the node generally
    available to the global system.
    
    Fixes: 08d9dbe72b1f ("node: Link memory nodes to their compute nodes")
    Signed-off-by: Gregory Price <[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]>

 
binder: fix async space check for 0-sized buffers [+ + +]
Author: Carlos Llamas <[email protected]>
Date:   Fri Dec 1 17:21:33 2023 +0000

    binder: fix async space check for 0-sized buffers
    
    commit 3091c21d3e9322428691ce0b7a0cfa9c0b239eeb upstream.
    
    Move the padding of 0-sized buffers to an earlier stage to account for
    this round up during the alloc->free_async_space check.
    
    Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
    Reviewed-by: Alice Ryhl <[email protected]>
    Signed-off-by: Carlos Llamas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

binder: fix race between mmput() and do_exit() [+ + +]
Author: Carlos Llamas <[email protected]>
Date:   Fri Dec 1 17:21:32 2023 +0000

    binder: fix race between mmput() and do_exit()
    
    commit 9a9ab0d963621d9d12199df9817e66982582d5a5 upstream.
    
    Task A calls binder_update_page_range() to allocate and insert pages on
    a remote address space from Task B. For this, Task A pins the remote mm
    via mmget_not_zero() first. This can race with Task B do_exit() and the
    final mmput() refcount decrement will come from Task A.
    
      Task A            | Task B
      ------------------+------------------
      mmget_not_zero()  |
                        |  do_exit()
                        |    exit_mm()
                        |      mmput()
      mmput()           |
        exit_mmap()     |
          remove_vma()  |
            fput()      |
    
    In this case, the work of ____fput() from Task B is queued up in Task A
    as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
    work gets executed. However, Task A instead sleep, waiting for a reply
    from Task B that never comes (it's dead).
    
    This means the binder_deferred_release() is blocked until an unrelated
    binder event forces Task A to go back to userspace. All the associated
    death notifications will also be delayed until then.
    
    In order to fix this use mmput_async() that will schedule the work in
    the corresponding mm->async_put_work WQ instead of Task A.
    
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Reviewed-by: Alice Ryhl <[email protected]>
    Signed-off-by: Carlos Llamas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

binder: fix unused alloc->free_async_space [+ + +]
Author: Carlos Llamas <[email protected]>
Date:   Fri Dec 1 17:21:34 2023 +0000

    binder: fix unused alloc->free_async_space
    
    commit c6d05e0762ab276102246d24affd1e116a46aa0c upstream.
    
    Each transaction is associated with a 'struct binder_buffer' that stores
    the metadata about its buffer area. Since commit 74310e06be4d ("android:
    binder: Move buffer out of area shared with user space") this struct is
    no longer embedded within the buffer itself but is instead allocated on
    the heap to prevent userspace access to this driver-exclusive info.
    
    Unfortunately, the space of this struct is still being accounted for in
    the total buffer size calculation, specifically for async transactions.
    This results in an additional 104 bytes added to every async buffer
    request, and this area is never used.
    
    This wasted space can be substantial. If we consider the maximum mmap
    buffer space of SZ_4M, the driver will reserve half of it for async
    transactions, or 0x200000. This area should, in theory, accommodate up
    to 262,144 buffers of the minimum 8-byte size. However, after adding
    the extra 'sizeof(struct binder_buffer)', the total number of buffers
    drops to only 18,724, which is a sad 7.14% of the actual capacity.
    
    This patch fixes the buffer size calculation to enable the utilization
    of the entire async buffer space. This is expected to reduce the number
    of -ENOSPC errors that are seen on the field.
    
    Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
    Signed-off-by: Carlos Llamas <[email protected]>
    Reviewed-by: Alice Ryhl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
blk-cgroup: fix rcu lockdep warning in blkg_lookup() [+ + +]
Author: Ming Lei <[email protected]>
Date:   Tue Dec 19 09:28:33 2023 +0800

    blk-cgroup: fix rcu lockdep warning in blkg_lookup()
    
    [ Upstream commit 393cd8ffd832f23eec3a105553eff622e8198918 ]
    
    blkg_lookup() is called with either queue_lock or rcu read lock, so
    use rcu_dereference_check(lockdep_is_held(&q->queue_lock)) for
    retrieving 'blkg', which way models the check exactly for covering
    queue lock or rcu read lock.
    
    Fix lockdep warning of "block/blk-cgroup.h:254 suspicious rcu_dereference_check() usage!"
    from blkg_lookup().
    
    Tested-by: Changhui Zhong <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Fixes: 83462a6c971c ("blkcg: Drop unnecessary RCU read [un]locks from blkg_conf_prep/finish()")
    Acked-by: Tejun Heo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: add check of 'minors' and 'first_minor' in device_add_disk() [+ + +]
Author: Li Nan <[email protected]>
Date:   Tue Dec 19 15:59:42 2023 +0800

    block: add check of 'minors' and 'first_minor' in device_add_disk()
    
    [ Upstream commit 4c434392c4777881d01beada6701eff8c76b43fe ]
    
    'first_minor' represents the starting minor number of disks, and
    'minors' represents the number of partitions in the device. Neither
    of them can be greater than MINORMASK + 1.
    
    Commit e338924bd05d ("block: check minor range in device_add_disk()")
    only added the check of 'first_minor + minors'. However, their sum might
    be less than MINORMASK but their values are wrong. Complete the checks now.
    
    Fixes: e338924bd05d ("block: check minor range in device_add_disk()")
    Signed-off-by: Li Nan <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: add check that partition length needs to be aligned with block size [+ + +]
Author: Min Li <[email protected]>
Date:   Thu Jun 29 14:25:17 2023 +0000

    block: add check that partition length needs to be aligned with block size
    
    commit 6f64f866aa1ae6975c95d805ed51d7e9433a0016 upstream.
    
    Before calling add partition or resize partition, there is no check
    on whether the length is aligned with the logical block size.
    If the logical block size of the disk is larger than 512 bytes,
    then the partition size maybe not the multiple of the logical block size,
    and when the last sector is read, bio_truncate() will adjust the bio size,
    resulting in an IO error if the size of the read command is smaller than
    the logical block size.If integrity data is supported, this will also
    result in a null pointer dereference when calling bio_integrity_free.
    
    Cc:  <[email protected]>
    Signed-off-by: Min Li <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

block: ensure we hold a queue reference when using queue limits [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Fri Jan 12 09:12:20 2024 -0700

    block: ensure we hold a queue reference when using queue limits
    
    [ Upstream commit 7b4f36cd22a65b750b4cb6ac14804fb7d6e6c67d ]
    
    q_usage_counter is the only thing preventing us from the limits changing
    under us in __bio_split_to_limits, but blk_mq_submit_bio doesn't hold
    it while calling into it.
    
    Move the splitting inside the region where we know we've got a queue
    reference. Ideally this could still remain a shared section of code, but
    let's keep the fix simple and defer any refactoring here to later.
    
    Reported-by: Christoph Hellwig <[email protected]>
    Fixes: 900e08075202 ("block: move queue enter logic into blk_mq_submit_bio()")
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: Fix iterating over an empty bio with bio_for_each_folio_all [+ + +]
Author: Matthew Wilcox (Oracle) <[email protected]>
Date:   Tue Jan 16 21:29:59 2024 +0000

    block: Fix iterating over an empty bio with bio_for_each_folio_all
    
    commit 7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7 upstream.
    
    If the bio contains no data, bio_first_folio() calls page_folio() on a
    NULL pointer and oopses.  Move the test that we've reached the end of
    the bio from bio_next_folio() to bio_first_folio().
    
    Reported-by: [email protected]
    Reported-by: [email protected]
    Fixes: 640d1930bef4 ("block: Add bio_for_each_folio_all()")
    Cc: [email protected]
    Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [axboe: add unlikely() to error case]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

block: Remove special-casing of compound pages [+ + +]
Author: Matthew Wilcox (Oracle) <[email protected]>
Date:   Mon Aug 14 15:41:00 2023 +0100

    block: Remove special-casing of compound pages
    
    commit 1b151e2435fc3a9b10c8946c6aebe9f3e1938c55 upstream.
    
    The special casing was originally added in pre-git history; reproducing
    the commit log here:
    
    > commit a318a92567d77
    > Author: Andrew Morton <[email protected]>
    > Date:   Sun Sep 21 01:42:22 2003 -0700
    >
    >     [PATCH] Speed up direct-io hugetlbpage handling
    >
    >     This patch short-circuits all the direct-io page dirtying logic for
    >     higher-order pages.  Without this, we pointlessly bounce BIOs up to
    >     keventd all the time.
    
    In the last twenty years, compound pages have become used for more than
    just hugetlb.  Rewrite these functions to operate on folios instead
    of pages and remove the special case for hugetlbfs; I don't think
    it's needed any more (and if it is, we can put it back in as a call
    to folio_test_hugetlb()).
    
    This was found by inspection; as far as I can tell, this bug can lead
    to pages used as the destination of a direct I/O read not being marked
    as dirty.  If those pages are then reclaimed by the MM without being
    dirtied for some other reason, they won't be written out.  Then when
    they're faulted back in, they will not contain the data they should.
    It'll take a pretty unusual setup to produce this problem with several
    races all going the wrong way.
    
    This problem predates the folio work; it could for example have been
    triggered by mmaping a THP in tmpfs and using that as the target of an
    O_DIRECT read.
    
    Fixes: 800d8c63b2e98 ("shmem: add huge pages support")
    Cc:  <[email protected]>
    Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

block: Set memalloc_noio to false on device_add_disk() error path [+ + +]
Author: Li Nan <[email protected]>
Date:   Mon Dec 11 15:53:56 2023 +0800

    block: Set memalloc_noio to false on device_add_disk() error path
    
    [ Upstream commit 5fa3d1a00c2d4ba14f1300371ad39d5456e890d7 ]
    
    On the error path of device_add_disk(), device's memalloc_noio flag was
    set but not cleared. As the comment of pm_runtime_set_memalloc_noio(),
    "The function should be called between device_add() and device_del()".
    Clear this flag before device_del() now.
    
    Fixes: 25e823c8c37d ("block/genhd.c: apply pm_runtime_set_memalloc_noio on block devices")
    Signed-off-by: Li Nan <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
blocklayoutdriver: Fix reference leak of pnfs_device_node [+ + +]
Author: Benjamin Coddington <[email protected]>
Date:   Tue Dec 5 10:05:01 2023 -0500

    blocklayoutdriver: Fix reference leak of pnfs_device_node
    
    [ Upstream commit 1530827b90025cdf80c9b0d07a166d045a0a7b81 ]
    
    The error path for blocklayout's device lookup is missing a reference drop
    for the case where a lookup finds the device, but the device is marked with
    NFS_DEVICEID_UNAVAILABLE.
    
    Fixes: b3dce6a2f060 ("pnfs/blocklayout: handle transient devices")
    Signed-off-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: btmtkuart: fix recv_buf() return value [+ + +]
Author: Francesco Dolcini <[email protected]>
Date:   Mon Dec 11 17:40:19 2023 +0100

    Bluetooth: btmtkuart: fix recv_buf() return value
    
    [ Upstream commit 64057f051f20c2a2184b9db7f8037d928d68a4f4 ]
    
    Serdev recv_buf() callback is supposed to return the amount of bytes
    consumed, therefore an int in between 0 and count.
    
    Do not return negative number in case of issue, just print an error and
    return count. This fixes a WARN in ttyport_receive_buf().
    
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
    Signed-off-by: Francesco Dolcini <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btnxpuart: fix recv_buf() return value [+ + +]
Author: Francesco Dolcini <[email protected]>
Date:   Mon Dec 11 17:40:18 2023 +0100

    Bluetooth: btnxpuart: fix recv_buf() return value
    
    [ Upstream commit 94d05394254401e503867c16aff561d3e687dfdc ]
    
    Serdev recv_buf() callback is supposed to return the amount of bytes
    consumed, therefore an int in between 0 and count.
    
    Do not return a negative number in case of issue, just print an error
    and return count. Before this change, in case of error, the returned
    negative number was internally converted to 0 in ttyport_receive_buf,
    now when the receive buffer is corrupted we return the size of the whole
    received data (`count`). This should allow for better recovery in case
    receiver/transmitter get out of sync if some data is lost.
    
    This fixes a WARN in ttyport_receive_buf().
    
      Bluetooth: hci0: Frame reassembly failed (-84)
      ------------[ cut here ]------------
      serial serial0: receive_buf returns -84 (count = 6)
      WARNING: CPU: 0 PID: 37 at drivers/tty/serdev/serdev-ttyport.c:37 ttyport_receive_buf+0xd8/0xf8
      Modules linked in: mwifiex_sdio(+) ...
      CPU: 0 PID: 37 Comm: kworker/u4:2 Not tainted 6.7.0-rc2-00147-gf1a09972a45a #1
      Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)
      Workqueue: events_unbound flush_to_ldisc
      pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : ttyport_receive_buf+0xd8/0xf8
      lr : ttyport_receive_buf+0xd8/0xf8
    ...
      Call trace:
       ttyport_receive_buf+0xd8/0xf8
       flush_to_ldisc+0xbc/0x1a4
       process_scheduled_works+0x16c/0x28c
    
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets")
    Signed-off-by: Francesco Dolcini <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Fix atomicity violation in {min,max}_key_size_set [+ + +]
Author: Gui-Dong Han <[email protected]>
Date:   Fri Dec 22 23:12:41 2023 +0800

    Bluetooth: Fix atomicity violation in {min,max}_key_size_set
    
    commit da9065caa594d19b26e1a030fd0cc27bd365d685 upstream.
    
    In min_key_size_set():
        if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE)
            return -EINVAL;
        hci_dev_lock(hdev);
        hdev->le_min_key_size = val;
        hci_dev_unlock(hdev);
    
    In max_key_size_set():
        if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size)
            return -EINVAL;
        hci_dev_lock(hdev);
        hdev->le_max_key_size = val;
        hci_dev_unlock(hdev);
    
    The atomicity violation occurs due to concurrent execution of set_min and
    set_max funcs.Consider a scenario where setmin writes a new, valid 'min'
    value, and concurrently, setmax writes a value that is greater than the
    old 'min' but smaller than the new 'min'. In this case, setmax might check
    against the old 'min' value (before acquiring the lock) but write its
    value after the 'min' has been updated by setmin. This leads to a
    situation where the 'max' value ends up being smaller than the 'min'
    value, which is an inconsistency.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team, BassCheck[1]. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations. The above
    possible bug is reported when our tool analyzes the source code of
    Linux 5.17.
    
    To resolve this issue, it is suggested to encompass the validity checks
    within the locked sections in both set_min and set_max funcs. The
    modification ensures that the validation of 'val' against the
    current min/max values is atomic, thus maintaining the integrity of the
    settings. With this patch applied, our tool no longer reports the bug,
    with the kernel configuration allyesconfig for x86_64. Due to the lack of
    associated hardware, we cannot test the patch in runtime testing, and just
    verify it according to the code logic.
    
    [1] https://sites.google.com/view/basscheck/
    
    Fixes: 18f81241b74f ("Bluetooth: Move {min,max}_key_size debugfs ...")
    Cc: [email protected]
    Signed-off-by: Gui-Dong Han <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: Fix bogus check for re-auth no supported with non-ssp [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Thu Nov 30 14:58:03 2023 +0100

    Bluetooth: Fix bogus check for re-auth no supported with non-ssp
    
    [ Upstream commit d03376c185926098cb4d668d6458801eb785c0a5 ]
    
    This reverts 19f8def031bfa50c579149b200bfeeb919727b27
    "Bluetooth: Fix auth_complete_evt for legacy units" which seems to be
    working around a bug on a broken controller rather then any limitation
    imposed by the Bluetooth spec, in fact if there ws not possible to
    re-auth the command shall fail not succeed.
    
    Fixes: 19f8def031bf ("Bluetooth: Fix auth_complete_evt for legacy units")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, lpm: Fix check prefixlen before walking trie [+ + +]
Author: Florian Lehner <[email protected]>
Date:   Sun Nov 5 09:58:01 2023 +0100

    bpf, lpm: Fix check prefixlen before walking trie
    
    [ Upstream commit 9b75dbeb36fcd9fc7ed51d370310d0518a387769 ]
    
    When looking up an element in LPM trie, the condition 'matchlen ==
    trie->max_prefixlen' will never return true, if key->prefixlen is larger
    than trie->max_prefixlen. Consequently all elements in the LPM trie will
    be visited and no element is returned in the end.
    
    To resolve this, check key->prefixlen first before walking the LPM trie.
    
    Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation")
    Signed-off-by: Florian Lehner <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Add crosstask check to __bpf_get_stack [+ + +]
Author: Jordan Rome <[email protected]>
Date:   Wed Nov 8 03:23:34 2023 -0800

    bpf: Add crosstask check to __bpf_get_stack
    
    [ Upstream commit b8e3a87a627b575896e448021e5c2f8a3bc19931 ]
    
    Currently get_perf_callchain only supports user stack walking for
    the current task. Passing the correct *crosstask* param will return
    0 frames if the task passed to __bpf_get_stack isn't the current
    one instead of a single incorrect frame/address. This change
    passes the correct *crosstask* param but also does a preemptive
    check in __bpf_get_stack if the task is current and returns
    -EOPNOTSUPP if it is not.
    
    This issue was found using bpf_get_task_stack inside a BPF
    iterator ("iter/task"), which iterates over all tasks.
    bpf_get_task_stack works fine for fetching kernel stacks
    but because get_perf_callchain relies on the caller to know
    if the requested *task* is the current one (via *crosstask*)
    it was failing in a confusing way.
    
    It might be possible to get user stacks for all tasks utilizing
    something like access_process_vm but that requires the bpf
    program calling bpf_get_task_stack to be sleepable and would
    therefore be a breaking change.
    
    Fixes: fa28dcb82a38 ("bpf: Introduce helper bpf_get_task_stack()")
    Signed-off-by: Jordan Rome <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Add KF_RCU flag to bpf_refcount_acquire_impl [+ + +]
Author: Dave Marchevsky <[email protected]>
Date:   Tue Nov 7 00:56:34 2023 -0800

    bpf: Add KF_RCU flag to bpf_refcount_acquire_impl
    
    [ Upstream commit 1500a5d9f49cb66906d3ea1c9158df25cc41dd40 ]
    
    Refcounted local kptrs are kptrs to user-defined types with a
    bpf_refcount field. Recent commits ([0], [1]) modified the lifetime of
    refcounted local kptrs such that the underlying memory is not reused
    until RCU grace period has elapsed.
    
    Separately, verification of bpf_refcount_acquire calls currently
    succeeds for MAYBE_NULL non-owning reference input, which is a problem
    as bpf_refcount_acquire_impl has no handling for this case.
    
    This patch takes advantage of aforementioned lifetime changes to tag
    bpf_refcount_acquire_impl kfunc KF_RCU, thereby preventing MAYBE_NULL
    input to the kfunc. The KF_RCU flag applies to all kfunc params; it's
    fine for it to apply to the void *meta__ign param as that's populated by
    the verifier and is tagged __ign regardless.
    
      [0]: commit 7e26cd12ad1c ("bpf: Use bpf_mem_free_rcu when
           bpf_obj_dropping refcounted nodes") is the actual change to
           allocation behaivor
      [1]: commit 0816b8c6bf7f ("bpf: Consider non-owning refs to refcounted
           nodes RCU protected") modified verifier understanding of
           refcounted local kptrs to match [0]'s changes
    
    Signed-off-by: Dave Marchevsky <[email protected]>
    Fixes: 7c50b1cb76ac ("bpf: Add bpf_refcount_acquire kfunc")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Add map and need_defer parameters to .map_fd_put_ptr() [+ + +]
Author: Hou Tao <[email protected]>
Date:   Mon Dec 4 22:04:20 2023 +0800

    bpf: Add map and need_defer parameters to .map_fd_put_ptr()
    
    [ Upstream commit 20c20bd11a0702ce4dc9300c3da58acf551d9725 ]
    
    map is the pointer of outer map, and need_defer needs some explanation.
    need_defer tells the implementation to defer the reference release of
    the passed element and ensure that the element is still alive before
    the bpf program, which may manipulate it, exits.
    
    The following three cases will invoke map_fd_put_ptr() and different
    need_defer values will be passed to these callers:
    
    1) release the reference of the old element in the map during map update
       or map deletion. The release must be deferred, otherwise the bpf
       program may incur use-after-free problem, so need_defer needs to be
       true.
    2) release the reference of the to-be-added element in the error path of
       map update. The to-be-added element is not visible to any bpf
       program, so it is OK to pass false for need_defer parameter.
    3) release the references of all elements in the map during map release.
       Any bpf program which has access to the map must have been exited and
       released, so need_defer=false will be OK.
    
    These two parameters will be used by the following patches to fix the
    potential use-after-free problem for map-in-map.
    
    Signed-off-by: Hou Tao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Stable-dep-of: 876673364161 ("bpf: Defer the free of inner map when necessary")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Avoid iter->offset making backward progress in bpf_iter_udp [+ + +]
Author: Martin KaFai Lau <[email protected]>
Date:   Fri Jan 12 11:05:29 2024 -0800

    bpf: Avoid iter->offset making backward progress in bpf_iter_udp
    
    [ Upstream commit 2242fd537fab52d5f4d2fbb1845f047c01fad0cf ]
    
    There is a bug in the bpf_iter_udp_batch() function that stops
    the userspace from making forward progress.
    
    The case that triggers the bug is the userspace passed in
    a very small read buffer. When the bpf prog does bpf_seq_printf,
    the userspace read buffer is not enough to capture the whole bucket.
    
    When the read buffer is not large enough, the kernel will remember
    the offset of the bucket in iter->offset such that the next userspace
    read() can continue from where it left off.
    
    The kernel will skip the number (== "iter->offset") of sockets in
    the next read(). However, the code directly decrements the
    "--iter->offset". This is incorrect because the next read() may
    not consume the whole bucket either and then the next-next read()
    will start from offset 0. The net effect is the userspace will
    keep reading from the beginning of a bucket and the process will
    never finish. "iter->offset" must always go forward until the
    whole bucket is consumed.
    
    This patch fixes it by using a local variable "resume_offset"
    and "resume_bucket". "iter->offset" is always reset to 0 before
    it may be used. "iter->offset" will be advanced to the
    "resume_offset" when it continues from the "resume_bucket" (i.e.
    "state->bucket == resume_bucket"). This brings it closer to
    the bpf_iter_tcp's offset handling which does not suffer
    the same bug.
    
    Cc: Aditi Ghag <[email protected]>
    Fixes: c96dac8d369f ("bpf: udp: Implement batching for sockets iterator")
    Acked-by: Yonghong Song <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Aditi Ghag <[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: Defer the free of inner map when necessary [+ + +]
Author: Hou Tao <[email protected]>
Date:   Mon Dec 4 22:04:22 2023 +0800

    bpf: Defer the free of inner map when necessary
    
    [ Upstream commit 876673364161da50eed6b472d746ef88242b2368 ]
    
    When updating or deleting an inner map in map array or map htab, the map
    may still be accessed by non-sleepable program or sleepable program.
    However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
    directly through bpf_map_put(), if the ref-counter is the last one
    (which is true for most cases), the inner map will be freed by
    ops->map_free() in a kworker. But for now, most .map_free() callbacks
    don't use synchronize_rcu() or its variants to wait for the elapse of a
    RCU grace period, so after the invocation of ops->map_free completes,
    the bpf program which is accessing the inner map may incur
    use-after-free problem.
    
    Fix the free of inner map by invoking bpf_map_free_deferred() after both
    one RCU grace period and one tasks trace RCU grace period if the inner
    map has been removed from the outer map before. The deferment is
    accomplished by using call_rcu() or call_rcu_tasks_trace() when
    releasing the last ref-counter of bpf map. The newly-added rcu_head
    field in bpf_map shares the same storage space with work field to
    reduce the size of bpf_map.
    
    Fixes: bba1dc0b55ac ("bpf: Remove redundant synchronize_rcu.")
    Fixes: 638e4b825d52 ("bpf: Allows per-cpu maps and map-in-map in sleepable programs")
    Signed-off-by: Hou Tao <[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: enforce precision of R0 on callback return [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Sat Dec 2 09:56:57 2023 -0800

    bpf: enforce precision of R0 on callback return
    
    [ Upstream commit 0acd03a5bd188b0c501d285d938439618bd855c4 ]
    
    Given verifier checks actual value, r0 has to be precise, so we need to
    propagate precision properly. r0 also has to be marked as read,
    otherwise subsequent state comparisons will ignore such register as
    unimportant and precision won't really help here.
    
    Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
    Acked-by: Eduard Zingerman <[email protected]>
    Acked-by: Shung-Hsi Yu <[email protected]>
    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 a race condition between btf_put() and map_free() [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Thu Dec 14 12:38:15 2023 -0800

    bpf: Fix a race condition between btf_put() and map_free()
    
    [ Upstream commit 59e5791f59dd83e8aa72a4e74217eabb6e8cfd90 ]
    
    When running `./test_progs -j` in my local vm with latest kernel,
    I once hit a kasan error like below:
    
      [ 1887.184724] BUG: KASAN: slab-use-after-free in bpf_rb_root_free+0x1f8/0x2b0
      [ 1887.185599] Read of size 4 at addr ffff888106806910 by task kworker/u12:2/2830
      [ 1887.186498]
      [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Tainted: G           OEL     6.7.0-rc3-00699-g90679706d486-dirty #494
      [ 1887.188034] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      [ 1887.189618] Workqueue: events_unbound bpf_map_free_deferred
      [ 1887.190341] Call Trace:
      [ 1887.190666]  <TASK>
      [ 1887.190949]  dump_stack_lvl+0xac/0xe0
      [ 1887.191423]  ? nf_tcp_handle_invalid+0x1b0/0x1b0
      [ 1887.192019]  ? panic+0x3c0/0x3c0
      [ 1887.192449]  print_report+0x14f/0x720
      [ 1887.192930]  ? preempt_count_sub+0x1c/0xd0
      [ 1887.193459]  ? __virt_addr_valid+0xac/0x120
      [ 1887.194004]  ? bpf_rb_root_free+0x1f8/0x2b0
      [ 1887.194572]  kasan_report+0xc3/0x100
      [ 1887.195085]  ? bpf_rb_root_free+0x1f8/0x2b0
      [ 1887.195668]  bpf_rb_root_free+0x1f8/0x2b0
      [ 1887.196183]  ? __bpf_obj_drop_impl+0xb0/0xb0
      [ 1887.196736]  ? preempt_count_sub+0x1c/0xd0
      [ 1887.197270]  ? preempt_count_sub+0x1c/0xd0
      [ 1887.197802]  ? _raw_spin_unlock+0x1f/0x40
      [ 1887.198319]  bpf_obj_free_fields+0x1d4/0x260
      [ 1887.198883]  array_map_free+0x1a3/0x260
      [ 1887.199380]  bpf_map_free_deferred+0x7b/0xe0
      [ 1887.199943]  process_scheduled_works+0x3a2/0x6c0
      [ 1887.200549]  worker_thread+0x633/0x890
      [ 1887.201047]  ? __kthread_parkme+0xd7/0xf0
      [ 1887.201574]  ? kthread+0x102/0x1d0
      [ 1887.202020]  kthread+0x1ab/0x1d0
      [ 1887.202447]  ? pr_cont_work+0x270/0x270
      [ 1887.202954]  ? kthread_blkcg+0x50/0x50
      [ 1887.203444]  ret_from_fork+0x34/0x50
      [ 1887.203914]  ? kthread_blkcg+0x50/0x50
      [ 1887.204397]  ret_from_fork_asm+0x11/0x20
      [ 1887.204913]  </TASK>
      [ 1887.204913]  </TASK>
      [ 1887.205209]
      [ 1887.205416] Allocated by task 2197:
      [ 1887.205881]  kasan_set_track+0x3f/0x60
      [ 1887.206366]  __kasan_kmalloc+0x6e/0x80
      [ 1887.206856]  __kmalloc+0xac/0x1a0
      [ 1887.207293]  btf_parse_fields+0xa15/0x1480
      [ 1887.207836]  btf_parse_struct_metas+0x566/0x670
      [ 1887.208387]  btf_new_fd+0x294/0x4d0
      [ 1887.208851]  __sys_bpf+0x4ba/0x600
      [ 1887.209292]  __x64_sys_bpf+0x41/0x50
      [ 1887.209762]  do_syscall_64+0x4c/0xf0
      [ 1887.210222]  entry_SYSCALL_64_after_hwframe+0x63/0x6b
      [ 1887.210868]
      [ 1887.211074] Freed by task 36:
      [ 1887.211460]  kasan_set_track+0x3f/0x60
      [ 1887.211951]  kasan_save_free_info+0x28/0x40
      [ 1887.212485]  ____kasan_slab_free+0x101/0x180
      [ 1887.213027]  __kmem_cache_free+0xe4/0x210
      [ 1887.213514]  btf_free+0x5b/0x130
      [ 1887.213918]  rcu_core+0x638/0xcc0
      [ 1887.214347]  __do_softirq+0x114/0x37e
    
    The error happens at bpf_rb_root_free+0x1f8/0x2b0:
    
      00000000000034c0 <bpf_rb_root_free>:
      ; {
        34c0: f3 0f 1e fa                   endbr64
        34c4: e8 00 00 00 00                callq   0x34c9 <bpf_rb_root_free+0x9>
        34c9: 55                            pushq   %rbp
        34ca: 48 89 e5                      movq    %rsp, %rbp
      ...
      ;       if (rec && rec->refcount_off >= 0 &&
        36aa: 4d 85 ed                      testq   %r13, %r13
        36ad: 74 a9                         je      0x3658 <bpf_rb_root_free+0x198>
        36af: 49 8d 7d 10                   leaq    0x10(%r13), %rdi
        36b3: e8 00 00 00 00                callq   0x36b8 <bpf_rb_root_free+0x1f8>
                                            <==== kasan function
        36b8: 45 8b 7d 10                   movl    0x10(%r13), %r15d
                                            <==== use-after-free load
        36bc: 45 85 ff                      testl   %r15d, %r15d
        36bf: 78 8c                         js      0x364d <bpf_rb_root_free+0x18d>
    
    So the problem is at rec->refcount_off in the above.
    
    I did some source code analysis and find the reason.
                                      CPU A                        CPU B
      bpf_map_put:
        ...
        btf_put with rcu callback
        ...
        bpf_map_free_deferred
          with system_unbound_wq
        ...                          ...                           ...
        ...                          btf_free_rcu:                 ...
        ...                          ...                           bpf_map_free_deferred:
        ...                          ...
        ...         --------->       btf_struct_metas_free()
        ...         | race condition ...
        ...         --------->                                     map->ops->map_free()
        ...
        ...                          btf->struct_meta_tab = NULL
    
    In the above, map_free() corresponds to array_map_free() and eventually
    calling bpf_rb_root_free() which calls:
      ...
      __bpf_obj_drop_impl(obj, field->graph_root.value_rec, false);
      ...
    
    Here, 'value_rec' is assigned in btf_check_and_fixup_fields() with following code:
    
      meta = btf_find_struct_meta(btf, btf_id);
      if (!meta)
        return -EFAULT;
      rec->fields[i].graph_root.value_rec = meta->record;
    
    So basically, 'value_rec' is a pointer to the record in struct_metas_tab.
    And it is possible that that particular record has been freed by
    btf_struct_metas_free() and hence we have a kasan error here.
    
    Actually it is very hard to reproduce the failure with current bpf/bpf-next
    code, I only got the above error once. To increase reproducibility, I added
    a delay in bpf_map_free_deferred() to delay map->ops->map_free(), which
    significantly increased reproducibility.
    
    #  diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
    #  index 5e43ddd1b83f..aae5b5213e93 100644
    #  --- a/kernel/bpf/syscall.c
    #  +++ b/kernel/bpf/syscall.c
    #  @@ -695,6 +695,7 @@ static void bpf_map_free_deferred(struct work_struct *work)
    #        struct bpf_map *map = container_of(work, struct bpf_map, work);
    #        struct btf_record *rec = map->record;
    #
    #  +     mdelay(100);
    #        security_bpf_map_free(map);
    #        bpf_map_release_memcg(map);
    #        /* implementation dependent freeing */
    
    Hao also provided test cases ([1]) for easily reproducing the above issue.
    
    There are two ways to fix the issue, the v1 of the patch ([2]) moving
    btf_put() after map_free callback, and the v5 of the patch ([3]) using
    a kptr style fix which tries to get a btf reference during
    map_check_btf(). Each approach has its pro and cons. The first approach
    delays freeing btf while the second approach needs to acquire reference
    depending on context which makes logic not very elegant and may
    complicate things with future new data structures. Alexei
    suggested in [4] going back to v1 which is what this patch
    tries to do.
    
    Rerun './test_progs -j' with the above mdelay() hack for a couple
    of times and didn't observe the error for the above rb_root test cases.
    Running Hou's test ([1]) is also successful.
    
      [1] https://lore.kernel.org/bpf/[email protected]/
      [2] v1: https://lore.kernel.org/bpf/[email protected]/
      [3] v5: https://lore.kernel.org/bpf/[email protected]/
      [4] v4: https://lore.kernel.org/bpf/CAADnVQJ3FiXUhZJwX_81sjZvSYYKCFB3BT6P8D59RS2Gu+0Z7g@mail.gmail.com/
    
    Cc: Hou Tao <[email protected]>
    Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new")
    Signed-off-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix accesses to uninit stack slots [+ + +]
Author: Andrei Matei <[email protected]>
Date:   Thu Dec 7 22:25:18 2023 -0500

    bpf: Fix accesses to uninit stack slots
    
    [ Upstream commit 6b4a64bafd107e521c01eec3453ce94a3fb38529 ]
    
    Privileged programs are supposed to be able to read uninitialized stack
    memory (ever since 6715df8d5) but, before this patch, these accesses
    were permitted inconsistently. In particular, accesses were permitted
    above state->allocated_stack, but not below it. In other words, if the
    stack was already "large enough", the access was permitted, but
    otherwise the access was rejected instead of being allowed to "grow the
    stack". This undesired rejection was happening in two places:
    - in check_stack_slot_within_bounds()
    - in check_stack_range_initialized()
    This patch arranges for these accesses to be permitted. A bunch of tests
    that were relying on the old rejection had to change; all of them were
    changed to add also run unprivileged, in which case the old behavior
    persists. One tests couldn't be updated - global_func16 - because it
    can't run unprivileged for other reasons.
    
    This patch also fixes the tracking of the stack size for variable-offset
    reads. This second fix is bundled in the same commit as the first one
    because they're inter-related. Before this patch, writes to the stack
    using registers containing a variable offset (as opposed to registers
    with fixed, known values) were not properly contributing to the
    function's needed stack size. As a result, it was possible for a program
    to verify, but then to attempt to read out-of-bounds data at runtime
    because a too small stack had been allocated for it.
    
    Each function tracks the size of the stack it needs in
    bpf_subprog_info.stack_depth, which is maintained by
    update_stack_depth(). For regular memory accesses, check_mem_access()
    was calling update_state_depth() but it was passing in only the fixed
    part of the offset register, ignoring the variable offset. This was
    incorrect; the minimum possible value of that register should be used
    instead.
    
    This tracking is now fixed by centralizing the tracking of stack size in
    grow_stack_state(), and by lifting the calls to grow_stack_state() to
    check_stack_access_within_bounds() as suggested by Andrii. The code is
    now simpler and more convincingly tracks the correct maximum stack size.
    check_stack_range_initialized() can now rely on enough stack having been
    allocated for the access; this helps with the fix for the first issue.
    
    A few tests were changed to also check the stack depth computation. The
    one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
    
    Fixes: 01f810ace9ed3 ("bpf: Allow variable-offset stack access")
    Reported-by: Hao Sun <[email protected]>
    Signed-off-by: Andrei Matei <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    
    Closes: https://lore.kernel.org/bpf/CABWLsev9g8UP_c3a=1qbuZUi20tGoUXoU07FPf-5FLvhOKOY+Q@mail.gmail.com/
    Signed-off-by: Sasha Levin <[email protected]>

bpf: fix check for attempt to corrupt spilled pointer [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Tue Dec 5 10:42:41 2023 -0800

    bpf: fix check for attempt to corrupt spilled pointer
    
    [ Upstream commit ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae ]
    
    When register is spilled onto a stack as a 1/2/4-byte register, we set
    slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,
    depending on actual spill size). So to check if some stack slot has
    spilled register we need to consult slot_type[7], not slot_type[0].
    
    To avoid the need to remember and double-check this in the future, just
    use is_spilled_reg() helper.
    
    Fixes: 27113c59b6d0 ("bpf: Check the other end of slot_type for STACK_SPILL")
    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 re-attachment branch in bpf_tracing_prog_attach [+ + +]
Author: Jiri Olsa <[email protected]>
Date:   Wed Jan 3 20:05:46 2024 +0100

    bpf: Fix re-attachment branch in bpf_tracing_prog_attach
    
    commit 715d82ba636cb3629a6e18a33bb9dbe53f9936ee upstream.
    
    The following case can cause a crash due to missing attach_btf:
    
    1) load rawtp program
    2) load fentry program with rawtp as target_fd
    3) create tracing link for fentry program with target_fd = 0
    4) repeat 3
    
    In the end we have:
    
    - prog->aux->dst_trampoline == NULL
    - tgt_prog == NULL (because we did not provide target_fd to link_create)
    - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
    - the program was loaded for tgt_prog but we have no way to find out which one
    
        BUG: kernel NULL pointer dereference, address: 0000000000000058
        Call Trace:
         <TASK>
         ? __die+0x20/0x70
         ? page_fault_oops+0x15b/0x430
         ? fixup_exception+0x22/0x330
         ? exc_page_fault+0x6f/0x170
         ? asm_exc_page_fault+0x22/0x30
         ? bpf_tracing_prog_attach+0x279/0x560
         ? btf_obj_id+0x5/0x10
         bpf_tracing_prog_attach+0x439/0x560
         __sys_bpf+0x1cf4/0x2de0
         __x64_sys_bpf+0x1c/0x30
         do_syscall_64+0x41/0xf0
         entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Return -EINVAL in this situation.
    
    Fixes: f3a95075549e0 ("bpf: Allow trampoline re-attach for tracing and lsm programs")
    Cc: [email protected]
    Signed-off-by: Jiri Olsa <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Signed-off-by: Dmitrii Dolgov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bpf: Fix verification of indirect var-off stack access [+ + +]
Author: Andrei Matei <[email protected]>
Date:   Wed Dec 6 23:11:48 2023 -0500

    bpf: Fix verification of indirect var-off stack access
    
    [ Upstream commit a833a17aeac73b33f79433d7cee68d5cafd71e4f ]
    
    This patch fixes a bug around the verification of possibly-zero-sized
    stack accesses. When the access was done through a var-offset stack
    pointer, check_stack_access_within_bounds was incorrectly computing the
    maximum-offset of a zero-sized read to be the same as the register's min
    offset. Instead, we have to take in account the register's maximum
    possible value. The patch also simplifies how the max offset is checked;
    the check is now simpler than for min offset.
    
    The bug was allowing accesses to erroneously pass the
    check_stack_access_within_bounds() checks, only to later crash in
    check_stack_range_initialized() when all the possibly-affected stack
    slots are iterated (this time with a correct max offset).
    check_stack_range_initialized() is relying on
    check_stack_access_within_bounds() for its accesses to the
    stack-tracking vector to be within bounds; in the case of zero-sized
    accesses, we were essentially only verifying that the lowest possible
    slot was within bounds. We would crash when the max-offset of the stack
    pointer was >= 0 (which shouldn't pass verification, and hopefully is
    not something anyone's code attempts to do in practice).
    
    Thanks Hao for reporting!
    
    Fixes: 01f810ace9ed3 ("bpf: Allow variable-offset stack access")
    Reported-by: Hao Sun <[email protected]>
    Signed-off-by: Andrei Matei <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    
    Closes: https://lore.kernel.org/bpf/CACkBjsZGEUaRCHsmaX=h-efVogsRfK1FPxmkgb0Os_frnHiNdw@mail.gmail.com/
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Guard stack limits against 32bit overflow [+ + +]
Author: Andrei Matei <[email protected]>
Date:   Wed Dec 6 23:11:50 2023 -0500

    bpf: Guard stack limits against 32bit overflow
    
    [ Upstream commit 1d38a9ee81570c4bd61f557832dead4d6f816760 ]
    
    This patch promotes the arithmetic around checking stack bounds to be
    done in the 64-bit domain, instead of the current 32bit. The arithmetic
    implies adding together a 64-bit register with a int offset. The
    register was checked to be below 1<<29 when it was variable, but not
    when it was fixed. The offset either comes from an instruction (in which
    case it is 16 bit), from another register (in which case the caller
    checked it to be below 1<<29 [1]), or from the size of an argument to a
    kfunc (in which case it can be a u32 [2]). Between the register being
    inconsistently checked to be below 1<<29, and the offset being up to an
    u32, it appears that we were open to overflowing the `int`s which were
    currently used for arithmetic.
    
    [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498
    [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904
    
    Reported-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Andrei Matei <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 6b4a64bafd10 ("bpf: Fix accesses to uninit stack slots")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: iter_udp: Retry with a larger batch size without going back to the previous bucket [+ + +]
Author: Martin KaFai Lau <[email protected]>
Date:   Fri Jan 12 11:05:28 2024 -0800

    bpf: iter_udp: Retry with a larger batch size without going back to the previous bucket
    
    [ Upstream commit 19ca0823f6eaad01d18f664a00550abe912c034c ]
    
    The current logic is to use a default size 16 to batch the whole bucket.
    If it is too small, it will retry with a larger batch size.
    
    The current code accidentally does a state->bucket-- before retrying.
    This goes back to retry with the previous bucket which has already
    been done. This patch fixed it.
    
    It is hard to create a selftest. I added a WARN_ON(state->bucket < 0),
    forced a particular port to be hashed to the first bucket,
    created >16 sockets, and observed the for-loop went back
    to the "-1" bucket.
    
    Cc: Aditi Ghag <[email protected]>
    Fixes: c96dac8d369f ("bpf: udp: Implement batching for sockets iterator")
    Acked-by: Yonghong Song <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Aditi Ghag <[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: Limit the number of kprobes when attaching program to multiple kprobes [+ + +]
Author: Hou Tao <[email protected]>
Date:   Fri Dec 15 18:07:05 2023 +0800

    bpf: Limit the number of kprobes when attaching program to multiple kprobes
    
    [ Upstream commit d6d1e6c17cab2dcb7b8530c599f00e7de906d380 ]
    
    An abnormally big cnt may also be assigned to kprobe_multi.cnt when
    attaching multiple kprobes. It will trigger the following warning in
    kvmalloc_node():
    
            if (unlikely(size > INT_MAX)) {
                WARN_ON_ONCE(!(flags & __GFP_NOWARN));
                return NULL;
            }
    
    Fix the warning by limiting the maximal number of kprobes in
    bpf_kprobe_multi_link_attach(). If the number of kprobes is greater than
    MAX_KPROBE_MULTI_CNT, the attachment will fail and return -E2BIG.
    
    Fixes: 0dcac2725406 ("bpf: Add multi kprobe link")
    Signed-off-by: Hou Tao <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Limit the number of uprobes when attaching program to multiple uprobes [+ + +]
Author: Hou Tao <[email protected]>
Date:   Fri Dec 15 18:07:04 2023 +0800

    bpf: Limit the number of uprobes when attaching program to multiple uprobes
    
    [ Upstream commit 8b2efe51ba85ca83460941672afac6fca4199df6 ]
    
    An abnormally big cnt may be passed to link_create.uprobe_multi.cnt,
    and it will trigger the following warning in kvmalloc_node():
    
            if (unlikely(size > INT_MAX)) {
                    WARN_ON_ONCE(!(flags & __GFP_NOWARN));
                    return NULL;
            }
    
    Fix the warning by limiting the maximal number of uprobes in
    bpf_uprobe_multi_link_attach(). If the number of uprobes is greater than
    MAX_UPROBE_MULTI_CNT, the attachment will return -E2BIG.
    
    Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link")
    Reported-by: Xingwei Lee <[email protected]>
    Signed-off-by: Hou Tao <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Closes: https://lore.kernel.org/bpf/CABOYnLwwJY=yFAGie59LFsUsBAgHfroVqbzZ5edAXbFE3YiNVA@mail.gmail.com
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS [+ + +]
Author: Hao Sun <[email protected]>
Date:   Mon Jan 15 09:20:27 2024 +0100

    bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
    
    [ Upstream commit 22c7fa171a02d310e3a3f6ed46a698ca8a0060ed ]
    
    For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
    for validation. However, variable offset ptr alu is not prohibited
    for this ptr kind. So the variable offset is not checked.
    
    The following prog is accepted:
    
      func#0 @0
      0: R1=ctx() R10=fp0
      0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
      1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()
      2: (b7) r8 = 1024                     ; R8_w=1024
      3: (37) r8 /= 1                       ; R8_w=scalar()
      4: (57) r8 &= 1024                    ; R8_w=scalar(smin=smin32=0,
      smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
      5: (0f) r7 += r8
      mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
      mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
      mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
      mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
      6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
      =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
      var_off=(0x0; 0x400))
      6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()
      7: (95) exit
    
    This prog loads flow_keys to r7, and adds the variable offset r8
    to r7, and finally causes out-of-bounds access:
    
      BUG: unable to handle page fault for address: ffffc90014c80038
      [...]
      Call Trace:
       <TASK>
       bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
       __bpf_prog_run include/linux/filter.h:651 [inline]
       bpf_prog_run include/linux/filter.h:658 [inline]
       bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
       bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
       bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
       bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
       __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
       __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
       __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
       __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fix this by rejecting ptr alu with variable offset on flow_keys.
    Applying the patch rejects the program with "R7 pointer arithmetic
    on flow_keys prohibited".
    
    Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
    Signed-off-by: Hao Sun <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: sockmap, fix proto update hook to avoid dup calls [+ + +]
Author: John Fastabend <[email protected]>
Date:   Thu Dec 21 15:23:23 2023 -0800

    bpf: sockmap, fix proto update hook to avoid dup calls
    
    [ Upstream commit 16b2f264983dc264c1560cc0170e760dec1bf54f ]
    
    When sockets are added to a sockmap or sockhash we allocate and init a
    psock. Then update the proto ops with sock_map_init_proto the flow is
    
      sock_hash_update_common
        sock_map_link
          psock = sock_map_psock_get_checked() <-returns existing psock
          sock_map_init_proto(sk, psock)       <- updates sk_proto
    
    If the socket is already in a map this results in the sock_map_init_proto
    being called multiple times on the same socket. We do this because when
    a socket is added to multiple maps this might result in a new set of BPF
    programs being attached to the socket requiring an updated ops struct.
    
    This creates a rule where it must be safe to call psock_update_sk_prot
    multiple times. When we added a fix for UAF through unix sockets in patch
    4dd9a38a753fc we broke this rule by adding a sock_hold in that path
    to ensure the sock is not released. The result is if a af_unix stream sock
    is placed in multiple maps it results in a memory leak because we call
    sock_hold multiple times with only a single sock_put on it.
    
    Fixes: 8866730aed51 ("bpf, sockmap: af_unix stream sockets need to hold ref for pair sock")
    Reported-by: Xingwei Lee <[email protected]>
    Signed-off-by: John Fastabend <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Jakub Sitnicki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Use c->unit_size to select target cache during free [+ + +]
Author: Hou Tao <[email protected]>
Date:   Sat Dec 16 21:10:51 2023 +0800

    bpf: Use c->unit_size to select target cache during free
    
    [ Upstream commit 7ac5c53e00735d183a0f5e2cfce5eeb6c16319f2 ]
    
    At present, bpf memory allocator uses check_obj_size() to ensure that
    ksize() of allocated pointer is equal with the unit_size of used
    bpf_mem_cache. Its purpose is to prevent bpf_mem_free() from selecting
    a bpf_mem_cache which has different unit_size compared with the
    bpf_mem_cache used for allocation. But as reported by lkp, the return
    value of ksize() or kmalloc_size_roundup() may change due to slab merge
    and it will lead to the warning report in check_obj_size().
    
    The reported warning happened as follows:
    (1) in bpf_mem_cache_adjust_size(), kmalloc_size_roundup(96) returns the
    object_size of kmalloc-96 instead of kmalloc-cg-96. The object_size of
    kmalloc-96 is 96, so size_index for 96 is not adjusted accordingly.
    (2) the object_size of kmalloc-cg-96 is adjust from 96 to 128 due to
    slab merge in __kmem_cache_alias(). For SLAB, SLAB_HWCACHE_ALIGN is
    enabled by default for kmalloc slab, so align is 64 and size is 128 for
    kmalloc-cg-96. SLUB has a similar merge logic, but its object_size will
    not be changed, because its align is 8 under x86-64.
    (3) when unit_alloc() does kmalloc_node(96, __GFP_ACCOUNT, node),
    ksize() returns 128 instead of 96 for the returned pointer.
    (4) the warning in check_obj_size() is triggered.
    
    Considering the slab merge can happen in anytime (e.g, a slab created in
    a new module), the following case is also possible: during the
    initialization of bpf_global_ma, there is no slab merge and ksize() for
    a 96-bytes object returns 96. But after that a new slab created by a
    kernel module is merged to kmalloc-cg-96 and the object_size of
    kmalloc-cg-96 is adjust from 96 to 128 (which is possible for x86-64 +
    CONFIG_SLAB, because its alignment requirement is 64 for 96-bytes slab).
    So soon or later, when bpf_global_ma frees a 96-byte-sized pointer
    which is allocated from bpf_mem_cache with unit_size=96, bpf_mem_free()
    will free the pointer through a bpf_mem_cache in which unit_size is 128,
    because the return value of ksize() changes. The warning for the
    mismatch will be triggered again.
    
    A feasible fix is introducing similar APIs compared with ksize() and
    kmalloc_size_roundup() to return the actually-allocated size instead of
    size which may change due to slab merge, but it will introduce
    unnecessary dependency on the implementation details of mm subsystem.
    
    As for now the pointer of bpf_mem_cache is saved in the 8-bytes area
    (or 4-bytes under 32-bit host) above the returned pointer, using
    unit_size in the saved bpf_mem_cache to select the target cache instead
    of inferring the size from the pointer itself. Beside no extra
    dependency on mm subsystem, the performance for bpf_mem_free_rcu() is
    also improved as shown below.
    
    Before applying the patch, the performances of bpf_mem_alloc() and
    bpf_mem_free_rcu() on 8-CPUs VM with one producer are as follows:
    
    kmalloc : alloc 11.69 ± 0.28M/s free 29.58 ± 0.93M/s
    percpu  : alloc 14.11 ± 0.52M/s free 14.29 ± 0.99M/s
    
    After apply the patch, the performance for bpf_mem_free_rcu() increases
    9% and 146% for kmalloc memory and per-cpu memory respectively:
    
    kmalloc: alloc 11.01 ± 0.03M/s free   32.42 ± 0.48M/s
    percpu:  alloc 12.84 ± 0.12M/s free   35.24 ± 0.23M/s
    
    After the fixes, there is no need to adjust size_index to fix the
    mismatch between allocation and free, so remove it as well. Also return
    NULL instead of ZERO_SIZE_PTR for zero-sized alloc in bpf_mem_alloc(),
    because there is no bpf_mem_cache pointer saved above ZERO_SIZE_PTR.
    
    Fixes: 9077fc228f09 ("bpf: Use kmalloc_size_roundup() to adjust size_index")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Hou Tao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: mhi: ep: Do not allocate event ring element on stack [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Fri Sep 1 13:05:02 2023 +0530

    bus: mhi: ep: Do not allocate event ring element on stack
    
    [ Upstream commit 987fdb5a43a66764808371b54e6047834170d565 ]
    
    It is possible that the host controller driver would use DMA framework to
    write the event ring element. So avoid allocating event ring element on the
    stack as DMA cannot work on vmalloc memory.
    
    Cc: [email protected]
    Fixes: 961aeb689224 ("bus: mhi: ep: Add support for sending events to the host")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Stable-dep-of: 327ec5f70609 ("PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()")
    Signed-off-by: Sasha Levin <[email protected]>

bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Thu Aug 17 23:24:52 2023 +0530

    bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs
    
    [ Upstream commit b08ded2ef2e98768d5ee5f71da8fe768b1f7774b ]
    
    In the preparation of DMA async support, let's pass the parameters to
    read_from_host() and write_to_host() APIs using mhi_ep_buf_info structure.
    
    No functional change.
    
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Stable-dep-of: 327ec5f70609 ("PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()")
    Signed-off-by: Sasha Levin <[email protected]>

bus: mhi: ep: Use slab allocator where applicable [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Wed Oct 18 17:58:12 2023 +0530

    bus: mhi: ep: Use slab allocator where applicable
    
    [ Upstream commit 62210a26cd4f8ad52683a71c0226dfe85de1144d ]
    
    Use slab allocator for allocating the memory for objects used frequently
    and are of fixed size. This reduces the overheard associated with
    kmalloc().
    
    Suggested-by: Alex Elder <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Stable-dep-of: 327ec5f70609 ("PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()")
    Signed-off-by: Sasha Levin <[email protected]>

 
calipso: fix memory leak in netlbl_calipso_add_pass() [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Thu Nov 23 09:25:54 2023 +0000

    calipso: fix memory leak in netlbl_calipso_add_pass()
    
    [ Upstream commit ec4e9d630a64df500641892f4e259e8149594a99 ]
    
    If IPv6 support is disabled at boot (ipv6.disable=1),
    the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
    and the netlbl_calipso_ops_get() function always returns NULL.
    In this case, the netlbl_calipso_add_pass() function allocates memory
    for the doi_def variable but doesn't free it with the calipso_doi_free().
    
    BUG: memory leak
    unreferenced object 0xffff888011d68180 (size 64):
      comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
      hex dump (first 32 bytes):
        00 00 00 00 02 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:
        [<...>] kmalloc include/linux/slab.h:552 [inline]
        [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
        [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
        [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
        [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
        [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
        [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
        [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
        [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
        [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
        [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
        [<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
        [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
        [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
        [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
        [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
        [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
        [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with Syzkaller
    
    Fixes: cb72d38211ea ("netlabel: Initial support for the CALIPSO netlink protocol.")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    [PM: merged via the LSM tree at Jakub Kicinski request]
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cdx: call of_node_put() on error path [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Jan 2 16:10:21 2024 +0300

    cdx: call of_node_put() on error path
    
    [ Upstream commit 87736ae12e1427bb2e6fd11f37b2ff76ed69aa0f ]
    
    Add a missing call to of_node_put(np) on error.
    
    There was a second error path where "np" was NULL, but that situation is
    impossible.  The for_each_compatible_node() loop iterator is always
    non-NULL.  Just deleted that error path.
    
    Fixes: 54b406e10f03 ("cdx: Remove cdx controller list from cdx bus system")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Abhijit Gangurde <[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]>

cdx: Explicitly include correct DT includes, again [+ + +]
Author: Rob Herring <[email protected]>
Date:   Thu Dec 7 10:31:27 2023 -0600

    cdx: Explicitly include correct DT includes, again
    
    [ Upstream commit aaee477e3e2c7305a95ffc528bf831a13da3dacb ]
    
    The DT of_device.h and of_platform.h date back to the separate
    of_platform_bus_type before it was merged into the regular platform bus.
    As part of that merge prepping Arm DT support 13 years ago, they
    "temporarily" include each other. They also include platform_device.h
    and of.h. As a result, there's a pretty much random mix of those include
    files used throughout the tree. In order to detangle these headers and
    replace the implicit includes with struct declarations, users need to
    explicitly include the correct includes.
    
    CDX was fixed once, but commit ("cdx: Remove cdx controller list from cdx
    bus system") added another occurrence.
    
    Fixes: 54b406e10f03 ("cdx: Remove cdx controller list from cdx bus system")
    Signed-off-by: Rob Herring <[email protected]>
    Acked-by: Nikhil Agarwal <[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]>

cdx: Unlock on error path in rescan_store() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Jan 2 16:11:16 2024 +0300

    cdx: Unlock on error path in rescan_store()
    
    [ Upstream commit 1960932eef9183e2dab662fe75126f7fa46e0e6d ]
    
    We added locking to this function but these two error paths were
    accidentally overlooked.
    
    Fixes: f0af81683466 ("cdx: Introduce lock to protect controller ops")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Abhijit Gangurde <[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]>

 
ceph: select FS_ENCRYPTION_ALGS if FS_ENCRYPTION [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 22 19:08:38 2023 -0800

    ceph: select FS_ENCRYPTION_ALGS if FS_ENCRYPTION
    
    commit 9c896d6bc3dfef86659a6a1fb25ccdea5dbef6a3 upstream.
    
    The kconfig options for filesystems that support FS_ENCRYPTION are
    supposed to select FS_ENCRYPTION_ALGS.  This is needed to ensure that
    required crypto algorithms get enabled as loadable modules or builtin as
    is appropriate for the set of enabled filesystems.  Do this for CEPH_FS
    so that there aren't any missing algorithms if someone happens to have
    CEPH_FS as their only enabled filesystem that supports encryption.
    
    Cc: [email protected]
    Fixes: f061feda6c54 ("ceph: add fscrypt ioctls and ceph.fscrypt.auth vxattr")
    Signed-off-by: Eric Biggers <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
class: fix use-after-free in class_register() [+ + +]
Author: Jing Xia <[email protected]>
Date:   Wed Dec 20 10:46:03 2023 +0800

    class: fix use-after-free in class_register()
    
    commit 93ec4a3b76404bce01bd5c9032bef5df6feb1d62 upstream.
    
    The lock_class_key is still registered and can be found in
    lock_keys_hash hlist after subsys_private is freed in error
    handler path.A task who iterate over the lock_keys_hash
    later may cause use-after-free.So fix that up and unregister
    the lock_class_key before kfree(cp).
    
    On our platform, a driver fails to kset_register because of
    creating duplicate filename '/class/xxx'.With Kasan enabled,
    it prints a invalid-access bug report.
    
    KASAN bug report:
    
    BUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bc
    Write of size 8 at addr 15ffff808b8c0368 by task modprobe/252
    Pointer tag: [15], memory tag: [fe]
    
    CPU: 7 PID: 252 Comm: modprobe Tainted: G        W
     6.6.0-mainline-maybe-dirty #1
    
    Call trace:
    dump_backtrace+0x1b0/0x1e4
    show_stack+0x2c/0x40
    dump_stack_lvl+0xac/0xe0
    print_report+0x18c/0x4d8
    kasan_report+0xe8/0x148
    __hwasan_store8_noabort+0x88/0x98
    lockdep_register_key+0x19c/0x1bc
    class_register+0x94/0x1ec
    init_module+0xbc/0xf48 [rfkill]
    do_one_initcall+0x17c/0x72c
    do_init_module+0x19c/0x3f8
    ...
    Memory state around the buggy address:
    ffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a
    ffffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe
    >ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
                                         ^
    ffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03
    
    As CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-access
    not use-after-free here.In this case, modprobe is manipulating
    the corrupted lock_keys_hash hlish where lock_class_key is already
    freed before.
    
    It's worth noting that this only can happen if lockdep is enabled,
    which is not true for normal system.
    
    Fixes: dcfbb67e48a2 ("driver core: class: use lock_class_key already present in struct subsys_private")
    Cc: stable <[email protected]>
    Signed-off-by: Jing Xia <[email protected]>
    Signed-off-by: Xuewen Yan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw [+ + +]
Author: Théo Lebrun <[email protected]>
Date:   Mon Dec 18 18:14:16 2023 +0100

    clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw
    
    [ Upstream commit ee0cf5e07f44a10fce8f1bfa9db226c0b5ecf880 ]
    
    Add missing comma and remove extraneous NULL argument. The macro is
    currently used by no one which explains why the typo slipped by.
    
    Fixes: 2d34f09e79c9 ("clk: fixed-rate: Add support for specifying parents via DT/pointers")
    Signed-off-by: Théo Lebrun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8550: Update disp PLL settings [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:09 2023 +0100

    clk: qcom: dispcc-sm8550: Update disp PLL settings
    
    [ Upstream commit febd251d8775c4fb6e4acd6b5d7b0ed707f4611f ]
    
    The settings in the driver seem to have been taken from an older
    release. Update them to match the latest values.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    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: qcom: dispcc-sm8550: Use the correct PLL configuration function [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:10 2023 +0100

    clk: qcom: dispcc-sm8550: Use the correct PLL configuration function
    
    [ Upstream commit c559bcb92564cbaedd43c749cf9b6fbb3d53ad5e ]
    
    To ensure that all fields (particularly CAL_L and CAL_L_RINGOSC) are
    filled properly, use the correct prepare function for OLE PLLs.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    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: qcom: gcc-sm8550: Add the missing RETAIN_FF_ENABLE GDSC flag [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:04 2023 +0100

    clk: qcom: gcc-sm8550: Add the missing RETAIN_FF_ENABLE GDSC flag
    
    [ Upstream commit 1fe8273c8d4088dd68faaab8640ec95f381cbf1e ]
    
    All of the 8550's GCC GDSCs can and should use the retain registers so
    as not to lose their state when entering lower power modes.
    
    Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550")
    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: qcom: gcc-sm8550: Mark RCGs shared where applicable [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:07 2023 +0100

    clk: qcom: gcc-sm8550: Mark RCGs shared where applicable
    
    [ Upstream commit 929c75d575667af389c8a9e03cebc93d43bb7f31 ]
    
    The vast majority of shared RCGs were not marked as such. Fix it.
    
    Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550")
    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: qcom: gcc-sm8550: Mark the PCIe GDSCs votable [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:05 2023 +0100

    clk: qcom: gcc-sm8550: Mark the PCIe GDSCs votable
    
    [ Upstream commit e7fe73fc6b68ee97b1e8f124a66a5ee50d8d5e5b ]
    
    The PCIe GDSCs on most Qualcomm platforms expect the OS to always
    consider collapse requests as successful. This also concerns SM8550.
    
    Add the VOTABLE flag to the GDSCs in question to comply with these
    expectations.
    
    Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550")
    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: qcom: gcc-sm8550: use collapse-voting for PCIe GDSCs [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:06 2023 +0100

    clk: qcom: gcc-sm8550: use collapse-voting for PCIe GDSCs
    
    [ Upstream commit 7e77a39265293ea4f05e20fff180755503c49918 ]
    
    The PCIe GDSCs can be shared with other masters and should use the APCS
    collapse-vote register when updating the power state.
    
    This is specifically also needed to be able to disable power domains
    that have been enabled by boot firmware using the vote register.
    
    Following other recent Qualcomm platforms, describe this register and
    the corresponding mask for the PCIe (and _phy) GDSCs.
    
    Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550")
    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: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config [+ + +]
Author: Satya Priya Kakitapalli <[email protected]>
Date:   Wed Nov 22 09:58:14 2023 +0530

    clk: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config
    
    [ Upstream commit 6ebd9a4f8b8d2b35cf965a04849c4ba763722f13 ]
    
    Update the test_ctl_hi_val and test_ctl_hi1_val of gpu_cc_pll1
    as per latest HW recommendation.
    
    Fixes: 0cef71f2ccc8 ("clk: qcom: Add graphics clock controller driver for SM8150")
    Signed-off-by: Satya Priya Kakitapalli <[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]>

clk: qcom: gpucc-sm8550: Update GPU PLL settings [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Dec 18 17:02:08 2023 +0100

    clk: qcom: gpucc-sm8550: Update GPU PLL settings
    
    [ Upstream commit 1d595972da12b5a78748eeb3ba1ff58bb0283b91 ]
    
    The settings in the driver seem to have been taken from an older
    release. Update them to match the latest values.
    
    Fixes: bfae40744b33 ("clk: qcom: gpucc-sm8550: Add support for graphics clock controller")
    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: qcom: videocc-sm8150: Add missing PLL config property [+ + +]
Author: Satya Priya Kakitapalli <[email protected]>
Date:   Fri Dec 1 15:20:26 2023 +0530

    clk: qcom: videocc-sm8150: Add missing PLL config property
    
    [ Upstream commit 71f130c9193f613d497f7245365ed05ffdb0a401 ]
    
    When the driver was ported upstream, PLL test_ctl_hi1 register value
    was omitted. Add it to ensure the PLLs are fully configured.
    
    Fixes: 5658e8cf1a8a ("clk: qcom: add video clock controller driver for SM8150")
    Signed-off-by: Satya Priya Kakitapalli <[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]>

clk: renesas: rzg2l-cpg: Reuse code in rzg2l_cpg_reset() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Mon Nov 20 09:00:11 2023 +0200

    clk: renesas: rzg2l-cpg: Reuse code in rzg2l_cpg_reset()
    
    [ Upstream commit 5f9e29b9159a41fcf6733c3b59fa46a90ce3ae20 ]
    
    Code in rzg2l_cpg_reset() is equivalent with the combined code of
    rzg2l_cpg_assert() and rzg2l_cpg_deassert(). There is no need to have
    different versions thus re-use rzg2l_cpg_assert() and rzg2l_cpg_deassert().
    
    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]>
    Stable-dep-of: da235d2fac21 ("clk: renesas: rzg2l: Check reset monitor registers")
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: rzg2l: Check reset monitor registers [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Thu Dec 7 09:06:50 2023 +0200

    clk: renesas: rzg2l: Check reset monitor registers
    
    [ Upstream commit da235d2fac212d0add570e755feb1167a830bc99 ]
    
    The hardware manual of both RZ/G2L and RZ/G3S specifies that the reset
    monitor registers need to be interrogated when the reset signals are
    toggled (chapters "Procedures for Supplying and Stopping Reset Signals"
    and "Procedure for Activating Modules").  Without this, there is a
    chance that different modules (e.g. Ethernet) are not ready after their
    reset signal is toggled, leading to failures (on probe or resume from
    deep sleep states).
    
    The same indications are available for RZ/V2M for TYPE-B reset controls.
    
    Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC")
    Fixes: 8090bea32484 ("clk: renesas: rzg2l: Add support for RZ/V2M reset monitor reg")
    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: rs9: Fix DIF OEn bit placement on 9FGV0241 [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Sun Nov 5 21:06:15 2023 +0100

    clk: rs9: Fix DIF OEn bit placement on 9FGV0241
    
    [ Upstream commit 29d861b5d29b6c80a887e93ad982cbbf4af2a06b ]
    
    On 9FGV0241, the DIF OE0 is BIT(1) and DIF OE1 is BIT(2), on the other
    chips like 9FGV0441 and 9FGV0841 DIF OE0 is BIT(0) and so on. Increment
    the index in BIT() macro instead of the result of BIT() macro to shift
    the bit correctly on 9FGV0241.
    
    Fixes: 603df193ec51 ("clk: rs9: Support device specific dif bit calculation")
    Signed-off-by: Marek Vasut <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Alexander Stein <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: si5341: fix an error code problem in si5341_output_clk_set_rate [+ + +]
Author: Su Hui <[email protected]>
Date:   Wed Nov 1 11:16:36 2023 +0800

    clk: si5341: fix an error code problem in si5341_output_clk_set_rate
    
    [ Upstream commit 5607068ae5ab02c3ac9cabc6859d36e98004c341 ]
    
    regmap_bulk_write() return zero or negative error code, return the value
    of regmap_bulk_write() rather than '0'.
    
    Fixes: 3044a860fd09 ("clk: Add Si5341/Si5340 driver")
    Acked-by: Mike Looijmans <[email protected]>
    Signed-off-by: Su Hui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: sp7021: fix return value check in sp7021_clk_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Tue Nov 28 21:30:16 2023 +0800

    clk: sp7021: fix return value check in sp7021_clk_probe()
    
    [ Upstream commit 1004c346a2b7393fce37dd1f320555e0a0d71e3f ]
    
    devm_platform_ioremap_resource() never returns NULL pointer,
    it will return ERR_PTR() when it fails, so replace the check
    with IS_ERR().
    
    Fixes: d54c1fd4a51e ("clk: Add Sunplus SP7021 clock driver")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clocksource/drivers/ep93xx: Fix error handling during probe [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Dec 12 22:46:07 2023 +0100

    clocksource/drivers/ep93xx: Fix error handling during probe
    
    commit c0c4579d79d0df841e825c68df450909a0032faf upstream.
    
    When the interrupt property fails to be parsed, ep93xx_timer_of_init()
    return code ends up uninitialized:
    
    drivers/clocksource/timer-ep93xx.c:160:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
            if (irq < 0) {
                ^~~~~~~
    drivers/clocksource/timer-ep93xx.c:188:9: note: uninitialized use occurs here
            return ret;
                   ^~~
    drivers/clocksource/timer-ep93xx.c:160:2: note: remove the 'if' if its condition is always false
            if (irq < 0) {
            ^~~~~~~~~~~~~~
    
    Simplify this portion to use the normal construct of just checking
    whether a valid interrupt was returned. Note that irq_of_parse_and_map()
    never returns a negative value and no other callers check for that either.
    
    Fixes: c28ca80ba3b5 ("clocksource: ep93xx: Add driver for Cirrus Logic EP93xx")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clocksource/drivers/timer-ti-dm: Fix make W=n kerneldoc warnings [+ + +]
Author: Tony Lindgren <[email protected]>
Date:   Tue Nov 14 09:29:30 2023 +0200

    clocksource/drivers/timer-ti-dm: Fix make W=n kerneldoc warnings
    
    commit b99a212a7697c542b460adaa15d4a98abf8223f0 upstream.
    
    Kernel test robot reports of kerneldoc related warnings that happen with
    make W=n for "parameter or member not described".
    
    These were caused by changes to function parameter names with
    earlier commits where the kerneldoc parts were not updated.
    
    Fixes: 49cd16bb573e ("clocksource/drivers/timer-ti-dm: Simplify register writes with dmtimer_write()")
    Fixes: a6e543f61531 ("clocksource/drivers/timer-ti-dm: Move struct omap_dm_timer fields to driver")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Tony Lindgren <[email protected]>
    Reviewed-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider() [+ + +]
Author: Alexandra Diupina <[email protected]>
Date:   Tue Dec 5 18:12:20 2023 +0300

    cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
    
    [ Upstream commit c4a5118a3ae1eadc687d84eef9431f9e13eb015c ]
    
    devm_of_clk_add_hw_provider() may return an errno, so
    add a return value check
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")
    Signed-off-by: Alexandra Diupina <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpuidle: haltpoll: Do not enable interrupts when entering idle [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Fri Dec 29 18:08:18 2023 +0100

    cpuidle: haltpoll: Do not enable interrupts when entering idle
    
    [ Upstream commit c8f5caec3df84a02b937d6d9cda1f7ffa8dc443f ]
    
    The cpuidle drivers' ->enter() methods are supposed to be IRQ invariant:
    
      5e26aa933911 ("cpuidle/poll: Ensure IRQs stay disabled after cpuidle_state::enter() calls")
      bb7b11258561 ("cpuidle: Move IRQ state validation")
    
    Do that in the haltpoll driver too.
    
    Fixes: 5e26aa933911 ("cpuidle/poll: Ensure IRQs stay disabled after cpuidle_state::enter() calls")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218245
    Reported-by: <[email protected]>
    Tested-by: <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    [ rjw: Changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: af_alg - Disallow multiple in-flight AIO requests [+ + +]
Author: Herbert Xu <[email protected]>
Date:   Tue Nov 28 16:25:49 2023 +0800

    crypto: af_alg - Disallow multiple in-flight AIO requests
    
    [ Upstream commit 67b164a871af1d736f131fd6fe78a610909f06f3 ]
    
    Having multiple in-flight AIO requests results in unpredictable
    output because they all share the same IV.  Fix this by only allowing
    one request at a time.
    
    Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to algif_aead")
    Fixes: a596999b7ddf ("crypto: algif - change algif_skcipher to be asynchronous")
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - fix memleak in ccp_init_dm_workarea [+ + +]
Author: Dinghao Liu <[email protected]>
Date:   Mon Nov 27 11:47:10 2023 +0800

    crypto: ccp - fix memleak in ccp_init_dm_workarea
    
    [ Upstream commit a1c95dd5bc1d6a5d7a75a376c2107421b7d6240d ]
    
    When dma_map_single() fails, wa->address is supposed to be freed
    by the callers of ccp_init_dm_workarea() through ccp_dm_free().
    However, many of the call spots don't expect to have to call
    ccp_dm_free() on failure of ccp_init_dm_workarea(), which may
    lead to a memleak. Let's free wa->address in ccp_init_dm_workarea()
    when dma_map_single() fails.
    
    Fixes: 63b945091a07 ("crypto: ccp - CCP device driver and interface support")
    Signed-off-by: Dinghao Liu <[email protected]>
    Acked-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/hpre - save capability registers in probe process [+ + +]
Author: Zhiqi Song <[email protected]>
Date:   Sat Dec 2 17:17:20 2023 +0800

    crypto: hisilicon/hpre - save capability registers in probe process
    
    [ Upstream commit cf8b5156bbc8c9376f699e8d35e9464b739e33ff ]
    
    Pre-store the valid value of hpre alg support related capability
    register in hpre_qm_init(), which will be called by hpre_probe().
    It can reduce the number of capability register queries and avoid
    obtaining incorrect values in abnormal scenarios, such as reset
    failed and the memory space disabled.
    
    Fixes: f214d59a0603 ("crypto: hisilicon/hpre - support hpre capability")
    Signed-off-by: Zhiqi Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - add a function to set qm algs [+ + +]
Author: Wenkai Lin <[email protected]>
Date:   Sat Dec 2 17:17:18 2023 +0800

    crypto: hisilicon/qm - add a function to set qm algs
    
    [ Upstream commit f76f0d7f20672611974d3cc705996751fc403734 ]
    
    Extract a public function to set qm algs and remove
    the similar code for setting qm algs in each module.
    
    Signed-off-by: Wenkai Lin <[email protected]>
    Signed-off-by: Hao Fang <[email protected]>
    Signed-off-by: Zhiqi Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: cf8b5156bbc8 ("crypto: hisilicon/hpre - save capability registers in probe process")
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - save capability registers in qm init process [+ + +]
Author: Zhiqi Song <[email protected]>
Date:   Sat Dec 2 17:17:19 2023 +0800

    crypto: hisilicon/qm - save capability registers in qm init process
    
    [ Upstream commit cabe13d0bd2efb8dd50ed2310f57b33e1a69a0d4 ]
    
    In previous capability register implementation, qm irq related values
    were read from capability registers dynamically when needed. But in
    abnormal scenario, e.g. the core is timeout and the device needs to
    soft reset and reset failed after disabling the MSE, the device can
    not be removed normally, causing the following call trace:
    
            | Call trace:
            |  pci_irq_vector+0xfc/0x140
            |  hisi_qm_uninit+0x278/0x3b0 [hisi_qm]
            |  hpre_remove+0x16c/0x1c0 [hisi_hpre]
            |  pci_device_remove+0x6c/0x264
            |  device_release_driver_internal+0x1ec/0x3e0
            |  device_release_driver+0x3c/0x60
            |  pci_stop_bus_device+0xfc/0x22c
            |  pci_stop_and_remove_bus_device+0x38/0x70
            |  pci_iov_remove_virtfn+0x108/0x1c0
            |  sriov_disable+0x7c/0x1e4
            |  pci_disable_sriov+0x4c/0x6c
            |  hisi_qm_sriov_disable+0x90/0x160 [hisi_qm]
            |  hpre_remove+0x1a8/0x1c0 [hisi_hpre]
            |  pci_device_remove+0x6c/0x264
            |  device_release_driver_internal+0x1ec/0x3e0
            |  driver_detach+0x168/0x2d0
            |  bus_remove_driver+0xc0/0x230
            |  driver_unregister+0x58/0xdc
            |  pci_unregister_driver+0x40/0x220
            |  hpre_exit+0x34/0x64 [hisi_hpre]
            |  __arm64_sys_delete_module+0x374/0x620
            [...]
    
            | Call trace:
            |  free_msi_irqs+0x25c/0x300
            |  pci_disable_msi+0x19c/0x264
            |  pci_free_irq_vectors+0x4c/0x70
            |  hisi_qm_pci_uninit+0x44/0x90 [hisi_qm]
            |  hisi_qm_uninit+0x28c/0x3b0 [hisi_qm]
            |  hpre_remove+0x16c/0x1c0 [hisi_hpre]
            |  pci_device_remove+0x6c/0x264
            [...]
    
    The reason for this call trace is that when the MSE is disabled, the value
    of capability registers in the BAR space become invalid. This will make the
    subsequent unregister process get the wrong irq vector through capability
    registers and get the wrong irq number by pci_irq_vector().
    
    So add a capability table structure to pre-store the valid value of the irq
    information capability register in qm init process, avoid obtaining invalid
    capability register value after the MSE is disabled.
    
    Fixes: 3536cc55cada ("crypto: hisilicon/qm - support get device irq information from hardware registers")
    Signed-off-by: Zhiqi Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/sec2 - save capability registers in probe process [+ + +]
Author: Zhiqi Song <[email protected]>
Date:   Sat Dec 2 17:17:21 2023 +0800

    crypto: hisilicon/sec2 - save capability registers in probe process
    
    [ Upstream commit f1115b0096c3163592e04e74f5a7548c25bda957 ]
    
    Pre-store the valid value of the sec alg support related capability
    register in sec_qm_init(), which will be called by probe process.
    It can reduce the number of capability register queries and avoid
    obtaining incorrect values in abnormal scenarios, such as reset
    failed and the memory space disabled.
    
    Fixes: 921715b6b782 ("crypto: hisilicon/sec - get algorithm bitmap from registers")
    Signed-off-by: Zhiqi Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/zip - add zip comp high perf mode configuration [+ + +]
Author: Chenghai Huang <[email protected]>
Date:   Fri Nov 24 13:49:24 2023 +0800

    crypto: hisilicon/zip - add zip comp high perf mode configuration
    
    [ Upstream commit a9864bae1806499ebf3757a9e71dddde5b9c48c6 ]
    
    To meet specific application scenarios, the function of switching between
    the high performance mode and the high compression mode is added.
    
    Use the perf_mode=0/1 configuration to set the compression high perf mode,
    0(default, high compression mode), 1(high performance mode). These two
    modes only apply to the compression direction and are compatible with
    software algorithm in both directions.
    
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: cf8b5156bbc8 ("crypto: hisilicon/hpre - save capability registers in probe process")
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/zip - save capability registers in probe process [+ + +]
Author: Zhiqi Song <[email protected]>
Date:   Sat Dec 2 17:17:22 2023 +0800

    crypto: hisilicon/zip - save capability registers in probe process
    
    [ Upstream commit 2ff0ad847951d61c2d8b309e1ccefb26c57dcc7b ]
    
    Pre-store the valid value of the zip alg support related capability
    register in hisi_zip_qm_init(), which will be called by hisi_zip_probe().
    It can reduce the number of capability register queries and avoid
    obtaining incorrect values in abnormal scenarios, such as reset failed
    and the memory space disabled.
    
    Fixes: db700974b69d ("crypto: hisilicon/zip - support zip capability")
    Signed-off-by: Zhiqi Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: jh7110 - Correct deferred probe return [+ + +]
Author: Chanho Park <[email protected]>
Date:   Thu Nov 9 15:32:59 2023 +0900

    crypto: jh7110 - Correct deferred probe return
    
    [ Upstream commit d57343022b71b9f41e731282dbe0baf0cff6ada8 ]
    
    This fixes list_add corruption error when the driver is returned
    with -EPROBE_DEFER. It is also required to roll back the previous
    probe sequences in case of deferred_probe. So, this removes
    'err_probe_defer" goto label and just use err_dma_init instead.
    
    Fixes: 42ef0e944b01 ("crypto: starfive - Add crypto engine support")
    Signed-off-by: Chanho Park <[email protected]>
    Reviewed-by: Jia Jie Ho <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - add NULL pointer check [+ + +]
Author: Giovanni Cabiddu <[email protected]>
Date:   Tue Nov 28 19:17:25 2023 +0000

    crypto: qat - add NULL pointer check
    
    [ Upstream commit a643212c9f28d09225c3792c316bc4aaf6be4a68 ]
    
    There is a possibility that the function adf_devmgr_pci_to_accel_dev()
    might return a NULL pointer.
    Add a NULL pointer check in the function rp2srv_show().
    
    Fixes: dbc8876dd873 ("crypto: qat - add rp2svc sysfs attribute")
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Ahsan Atta <[email protected]>
    Reviewed-by: David Guckian <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - add sysfs_added flag for ras [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Tue Nov 21 17:59:45 2023 +0100

    crypto: qat - add sysfs_added flag for ras
    
    [ Upstream commit 65089000ba8c2ae713ccac6603319143f3e1c08b ]
    
    The qat_ras sysfs attribute group is registered within the
    adf_dev_start() function, alongside other driver components.
    If any of the functions preceding the group registration fails,
    the adf_dev_start() function returns, and the caller, to undo the
    operation, invokes adf_dev_stop() followed by adf_dev_shutdown().
    However, the current flow lacks information about whether the
    registration of the qat_ras attribute group was successful or not.
    
    In cases where this condition is encountered, an error similar to
    the following might be reported:
    
        4xxx 0000:6b:00.0: Starting device qat_dev0
        4xxx 0000:6b:00.0: qat_dev0 started 9 acceleration engines
        4xxx 0000:6b:00.0: Failed to send init message
        4xxx 0000:6b:00.0: Failed to start device qat_dev0
        sysfs group 'qat_ras' not found for kobject '0000:6b:00.0'
        ...
        sysfs_remove_groups+0x29/0x50
        adf_sysfs_stop_ras+0x4b/0x80 [intel_qat]
        adf_dev_stop+0x43/0x1d0 [intel_qat]
        adf_dev_down+0x4b/0x150 [intel_qat]
        ...
        4xxx 0000:6b:00.0: qat_dev0 stopped 9 acceleration engines
        4xxx 0000:6b:00.0: Resetting device qat_dev0
    
    To prevent attempting to remove attributes from a group that has not
    been added yet, a flag named 'sysfs_added' is introduced. This flag
    is set to true upon the successful registration of the attribute group.
    
    Fixes: 532d7f6bc458 ("crypto: qat - add error counters")
    Signed-off-by: Damian Muszynski <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Ahsan Atta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - add sysfs_added flag for rate limiting [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Tue Nov 21 18:02:23 2023 +0100

    crypto: qat - add sysfs_added flag for rate limiting
    
    [ Upstream commit d71fdd0f3c278c7f132c3a522645ebf9157edd6d ]
    
    The qat_rl sysfs attribute group is registered within the adf_dev_start()
    function, alongside other driver components.
    If any of the functions preceding the group registration fails,
    the adf_dev_start() function returns, and the caller, to undo the
    operation, invokes adf_dev_stop() followed by adf_dev_shutdown().
    However, the current flow lacks information about whether the
    registration of the qat_rl attribute group was successful or not.
    
    In cases where this condition is encountered, an error similar to
    the following might be reported:
    
        4xxx 0000:6b:00.0: Starting device qat_dev0
        4xxx 0000:6b:00.0: qat_dev0 started 9 acceleration engines
        4xxx 0000:6b:00.0: Failed to send init message
        4xxx 0000:6b:00.0: Failed to start device qat_dev0
        sysfs group 'qat_rl' not found for kobject '0000:6b:00.0'
        ...
        sysfs_remove_groups+0x2d/0x50
        adf_sysfs_rl_rm+0x44/0x70 [intel_qat]
        adf_rl_stop+0x2d/0xb0 [intel_qat]
        adf_dev_stop+0x33/0x1d0 [intel_qat]
        adf_dev_down+0xf1/0x150 [intel_qat]
        ...
        4xxx 0000:6b:00.0: qat_dev0 stopped 9 acceleration engines
        4xxx 0000:6b:00.0: Resetting device qat_dev0
    
    To prevent attempting to remove attributes from a group that has not
    been added yet, a flag named 'sysfs_added' is introduced. This flag
    is set to true upon the successful registration of the attribute group.
    
    Fixes: d9fb8408376e ("crypto: qat - add rate limiting feature to qat_4xxx")
    Signed-off-by: Damian Muszynski <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Ahsan Atta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - fix error path in add_update_sla() [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Tue Nov 28 18:37:32 2023 +0100

    crypto: qat - fix error path in add_update_sla()
    
    [ Upstream commit 6627f03c21cb7001ae4dbbfb7a8514516d02331c ]
    
    The input argument `sla_in` is a pointer to a structure that contains
    the parameters of the SLA which is being added or updated.
    If this pointer is NULL, the function should return an error as
    the data required for the algorithm is not available.
    By mistake, the logic jumps to the error path which dereferences
    the pointer.
    
    This results in a warnings reported by the static analyzer Smatch when
    executed without a database:
    
        drivers/crypto/intel/qat/qat_common/adf_rl.c:871 add_update_sla()
        error: we previously assumed 'sla_in' could be null (see line 812)
    
    This issue was not found in internal testing as the pointer cannot be
    NULL. The function add_update_sla() is only called (indirectly) by
    the rate limiting sysfs interface implementation in adf_sysfs_rl.c
    which ensures that the data structure is allocated and valid. This is
    also proven by the fact that Smatch executed with a database does not
    report such error.
    
    Fix it by returning with error if the pointer `sla_in` is NULL.
    
    Fixes: d9fb8408376e ("crypto: qat - add rate limiting feature to qat_4xxx")
    Reported-by: Dan Carpenter <[email protected]>
    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 mutex ordering in adf_rl [+ + +]
Author: Damian Muszynski <[email protected]>
Date:   Tue Nov 28 18:39:30 2023 +0100

    crypto: qat - fix mutex ordering in adf_rl
    
    [ Upstream commit 487caa8d5ef9a9a27b092c5790d529a7a0c24f8b ]
    
    If the function validate_user_input() returns an error, the error path
    attempts to unlock an unacquired mutex.
    Acquire the mutex before calling validate_user_input(). This is not
    strictly necessary but simplifies the code.
    
    Fixes: d9fb8408376e ("crypto: qat - add rate limiting feature to qat_4xxx")
    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 - prevent underflow in rp2srv_store() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Oct 31 11:58:32 2023 +0300

    crypto: qat - prevent underflow in rp2srv_store()
    
    [ Upstream commit e53c741303a59ee1682e11f61b7772863e02526d ]
    
    The "ring" variable has an upper bounds check but nothing checks for
    negatives.  This code uses kstrtouint() already and it was obviously
    intended to be declared as unsigned int.  Make it so.
    
    Fixes: dbc8876dd873 ("crypto: qat - add rp2svc sysfs attribute")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: rsa - add a check for allocation failure [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Oct 30 12:02:59 2023 +0300

    crypto: rsa - add a check for allocation failure
    
    [ Upstream commit d872ca165cb67112f2841ef9c37d51ef7e63d1e4 ]
    
    Static checkers insist that the mpi_alloc() allocation can fail so add
    a check to prevent a NULL dereference.  Small allocations like this
    can't actually fail in current kernels, but adding a check is very
    simple and makes the static checkers happy.
    
    Fixes: 6637e11e4ad2 ("crypto: rsa - allow only odd e and restrict value in FIPS mode")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sa2ul - Return crypto_aead_setkey to transfer the error [+ + +]
Author: Chen Ni <[email protected]>
Date:   Mon Nov 27 02:03:01 2023 +0000

    crypto: sa2ul - Return crypto_aead_setkey to transfer the error
    
    [ Upstream commit ce852f1308ac738e61c5b2502517deea593a1554 ]
    
    Return crypto_aead_setkey() in order to transfer the error if
    it fails.
    
    Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support")
    Signed-off-by: Chen Ni <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: safexcel - Add error handling for dma_map_sg() calls [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Fri Dec 1 04:49:29 2023 -0800

    crypto: safexcel - Add error handling for dma_map_sg() calls
    
    [ Upstream commit 87e02063d07708cac5bfe9fd3a6a242898758ac8 ]
    
    Macro dma_map_sg() may return 0 on error. This patch enables
    checks in case of the macro failure and ensures unmapping of
    previously mapped buffers with dma_unmap_sg().
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 49186a7d9e46 ("crypto: inside_secure - Avoid dma map if size is zero")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - avoid skcipher fallback code duplication [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:25 2023 +0200

    crypto: sahara - avoid skcipher fallback code duplication
    
    [ Upstream commit 01d70a4bbff20ea05cadb4c208841985a7cc6596 ]
    
    Factor out duplicated skcipher fallback handling code to a helper function
    sahara_aes_fallback(). Also, keep a single check if fallback is required in
    sahara_aes_crypt().
    
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: d1d6351e37aa ("crypto: sahara - handle zero-length aes requests")
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - do not resize req->src when doing hash operations [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:36 2023 +0200

    crypto: sahara - do not resize req->src when doing hash operations
    
    [ Upstream commit a3c6f4f4d249cecaf2f34471aadbfb4f4ef57298 ]
    
    When testing sahara sha256 speed performance with tcrypt (mode=404) on
    imx53-qsrb board, multiple "Invalid numbers of src SG." errors are
    reported. This was traced to sahara_walk_and_recalc() resizing req->src
    and causing the subsequent dma_map_sg() call to fail.
    
    Now that the previous commit fixed sahara_sha_hw_links_create() to take
    into account the actual request size, rather than relying on sg->length
    values, the resize operation is no longer necessary.
    
    Therefore, remove sahara_walk_and_recalc() and simplify associated logic.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix ahash reqsize [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:32 2023 +0200

    crypto: sahara - fix ahash reqsize
    
    [ Upstream commit efcb50f41740ac55e6ccc4986c1a7740e21c62b4 ]
    
    Set the reqsize for sha algorithms to sizeof(struct sahara_sha_reqctx), the
    extra space is not needed.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix ahash selftest failure [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:21 2023 +0200

    crypto: sahara - fix ahash selftest failure
    
    [ Upstream commit afffcf3db98b9495114b79d5381f8cc3f69476fb ]
    
    update() calls should not modify the result buffer, so add an additional
    check for "rctx->last" to make sure that only the final hash value is
    copied into the buffer.
    
    Fixes the following selftest failure:
    alg: ahash: sahara-sha256 update() used result buffer on test vector 3,
    cfg="init+update+final aligned buffer"
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix cbc selftest failure [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:20 2023 +0200

    crypto: sahara - fix cbc selftest failure
    
    [ Upstream commit 9f10bc28c0fb676ae58aa3bfa358db8f5de124bb ]
    
    The kernel crypto API requires that all CBC implementations update the IV
    buffer to contain the last ciphertext block.
    
    This fixes the following cbc selftest error:
    alg: skcipher: sahara-cbc-aes encryption test failed (wrong output IV) on
    test vector 0, cfg="in-place (one sglist)"
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix error handling in sahara_hw_descriptor_create() [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:23 2023 +0200

    crypto: sahara - fix error handling in sahara_hw_descriptor_create()
    
    [ Upstream commit ee6e6f0a7f5b39d50a5ef5fcc006f4f693db18a7 ]
    
    Do not call dma_unmap_sg() for scatterlists that were not mapped
    successfully.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix processing hash requests with req->nbytes < sg->length [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:35 2023 +0200

    crypto: sahara - fix processing hash requests with req->nbytes < sg->length
    
    [ Upstream commit 7bafa74d1ba35dcc173e1ce915e983d65905f77e ]
    
    It's not always the case that the entire sg entry needs to be processed.
    Currently, when nbytes is less than sg->length, "Descriptor length" errors
    are encountered.
    
    To fix this, take the actual request size into account when populating the
    hw links.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix processing requests with cryptlen < sg->length [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:22 2023 +0200

    crypto: sahara - fix processing requests with cryptlen < sg->length
    
    [ Upstream commit 5b8668ce3452827d27f8c34ff6ba080a8f983ed0 ]
    
    It's not always the case that the entire sg entry needs to be processed.
    Currently, when cryptlen is less than sg->legth, "Descriptor length" errors
    are encountered.
    
    The error was noticed when testing xts(sahara-ecb-aes) with arbitrary sized
    input data. To fix this, take the actual request size into account when
    populating the hw links.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - fix wait_for_completion_timeout() error handling [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:33 2023 +0200

    crypto: sahara - fix wait_for_completion_timeout() error handling
    
    [ Upstream commit 2dba8e1d1a7957dcbe7888846268538847b471d1 ]
    
    The sg lists are not unmapped in case of timeout errors. Fix this.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - handle zero-length aes requests [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:31 2023 +0200

    crypto: sahara - handle zero-length aes requests
    
    [ Upstream commit d1d6351e37aac14b32a291731d0855996c459d11 ]
    
    In case of a zero-length input, exit gracefully from sahara_aes_crypt().
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - improve error handling in sahara_sha_process() [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Sun Dec 24 10:21:34 2023 +0200

    crypto: sahara - improve error handling in sahara_sha_process()
    
    [ Upstream commit 5deff027fca49a1eb3b20359333cf2ae562a2343 ]
    
    sahara_sha_hw_data_descriptor_create() returns negative error codes on
    failure, so make sure the errors are correctly handled / propagated.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: sahara - remove FLAGS_NEW_KEY logic [+ + +]
Author: Ovidiu Panait <[email protected]>
Date:   Fri Dec 1 19:06:19 2023 +0200

    crypto: sahara - remove FLAGS_NEW_KEY logic
    
    [ Upstream commit 8fd183435728b139248a77978ea3732039341779 ]
    
    Remove the FLAGS_NEW_KEY logic as it has the following issues:
    - the wrong key may end up being used when there are multiple data streams:
           t1            t2
        setkey()
        encrypt()
                       setkey()
                       encrypt()
    
        encrypt() <--- key from t2 is used
    - switching between encryption and decryption with the same key is not
      possible, as the hdr flags are only updated when a new setkey() is
      performed
    
    With this change, the key is always sent along with the cryptdata when
    performing encryption/decryption operations.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: scomp - fix req->dst buffer overflow [+ + +]
Author: Chengming Zhou <[email protected]>
Date:   Wed Dec 27 09:35:23 2023 +0000

    crypto: scomp - fix req->dst buffer overflow
    
    [ Upstream commit 744e1885922a9943458954cfea917b31064b4131 ]
    
    The req->dst buffer size should be checked before copying from the
    scomp_scratch->dst to avoid req->dst buffer overflow problem.
    
    Fixes: 1ab53a77b772 ("crypto: acomp - add driver-side scomp interface")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Chengming Zhou <[email protected]>
    Reviewed-by: Barry Song <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: virtio - Handle dataq logic with tasklet [+ + +]
Author: Gonglei (Arei) <[email protected]>
Date:   Mon Nov 20 11:49:45 2023 +0000

    crypto: virtio - Handle dataq logic with tasklet
    
    [ Upstream commit fed93fb62e05c38152b0fc1dc9609639e63eed76 ]
    
    Doing ipsec produces a spinlock recursion warning.
    This is due to crypto_finalize_request() being called in the upper half.
    Move virtual data queue processing of virtio-crypto driver to tasklet.
    
    Fixes: dbaf0624ffa57 ("crypto: add virtio-crypto driver")
    Reported-by: Halil Pasic <[email protected]>
    Signed-off-by: wangyangxin <[email protected]>
    Signed-off-by: Gonglei <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: virtio - Wait for tasklet to complete on device remove [+ + +]
Author: wangyangxin <[email protected]>
Date:   Mon Dec 11 19:42:15 2023 +0800

    crypto: virtio - Wait for tasklet to complete on device remove
    
    [ Upstream commit 67cc511e8d436456cc98033e6d4ba83ebfc8e672 ]
    
    The scheduled tasklet needs to be executed on device remove.
    
    Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: wangyangxin <[email protected]>
    Signed-off-by: Gonglei <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
csky: fix arch_jump_label_transform_static override [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Nov 6 22:02:59 2023 +0100

    csky: fix arch_jump_label_transform_static override
    
    [ Upstream commit ca8e45c8048a2c9503c74751d25414601f730580 ]
    
    The arch_jump_label_transform_static() function in csky was originally meant to
    override the generic __weak function, but that got changed to an #ifndef check.
    
    This showed up as a missing-prototype warning:
    arch/csky/kernel/jump_label.c:43:6: error: no previous prototype for 'arch_jump_label_transform_static' [-Werror=missing-prototypes]
    
    Change the method to use the new method of having a #define and a prototype
    for the global function.
    
    Fixes: 7e6b9db27de9 ("jump_label: make initial NOP patching the special case")
    Fixes: 4e8bb4ba5a55 ("csky: Add jump-label implementation")
    Reviewed-by: Guo Ren <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/port: Fix decoder initialization when nr_targets > interleave_ways [+ + +]
Author: Huang Ying <[email protected]>
Date:   Fri Dec 8 11:06:36 2023 +0800

    cxl/port: Fix decoder initialization when nr_targets > interleave_ways
    
    commit d6488fee66472b468ed88d265b14aa3f04dc3bdf upstream.
    
    The decoder_populate_targets() helper walks all of the targets in a port
    and makes sure they can be looked up in @target_map. Where @target_map
    is a lookup table from target position to target id (corresponding to a
    cxl_dport instance). However @target_map is only responsible for
    conveying the active dport instances as indicated by interleave_ways.
    
    When nr_targets > interleave_ways it results in
    decoder_populate_targets() walking off the end of the valid entries in
    @target_map. Given target_map is initialized to 0 it results in the
    dport lookup failing if position 0 is not mapped to a dport with an id
    of 0:
    
      cxl_port port3: Failed to populate active decoder targets
      cxl_port port3: Failed to add decoder
      cxl_port port3: Failed to add decoder3.0
      cxl_bus_probe: cxl_port port3: probe: -6
    
    This bug also highlights that when the decoder's ->targets[] array is
    written in cxl_port_setup_targets() it is missing a hold of the
    targets_lock to synchronize against sysfs readers of the target list. A
    fix for that is saved for a later patch.
    
    Fixes: a5c258021689 ("cxl/bus: Populate the target list at decoder create")
    Cc:  <[email protected]>
    Signed-off-by: Huang, Ying <[email protected]>
    [djbw: rewrite the changelog, find the Fixes: tag]
    Co-developed-by: Dan Williams <[email protected]>
    Reviewed-by: Alison Schofield <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cxl/port: Fix missing target list lock [+ + +]
Author: Dan Williams <[email protected]>
Date:   Thu Dec 21 21:05:01 2023 -0800

    cxl/port: Fix missing target list lock
    
    [ Upstream commit 5459e186a5c9f412334321cff58d70dcb0e48a04 ]
    
    cxl_port_setup_targets() modifies the ->targets[] array of a switch
    decoder. target_list_show() expects to be able to emit a coherent
    snapshot of that array by "holding" ->target_lock for read. The
    target_lock is held for write during initialization of the ->targets[]
    array, but it is not held for write during cxl_port_setup_targets().
    
    The ->target_lock() predates the introduction of @cxl_region_rwsem. That
    semaphore protects changes to host-physical-address (HPA) decode which
    is precisely what writes to a switch decoder's target list affects.
    
    Replace ->target_lock with @cxl_region_rwsem.
    
    Now the side-effect of snapshotting a unstable view of a decoder's
    target list is likely benign so the Fixes: tag is presumptive.
    
    Fixes: 27b3f8d13830 ("cxl/region: Program target lists")
    Reviewed-by: Alison Schofield <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/region: fix x9 interleave typo [+ + +]
Author: Jim Harris <[email protected]>
Date:   Fri Nov 3 20:18:34 2023 +0000

    cxl/region: fix x9 interleave typo
    
    [ Upstream commit c7ad3dc3649730af483ee1e78be5d0362da25bfe ]
    
    CXL supports x3, x6 and x12 - not x9.
    
    Fixes: 80d10a6cee050 ("cxl/region: Add interleave geometry attributes")
    Signed-off-by: Jim Harris <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Fan Ni <[email protected]>
    Link: https://lore.kernel.org/r/169904271254.204936.8580772404462743630.stgit@ubuntu
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dlm: fix format seq ops type 4 [+ + +]
Author: Alexander Aring <[email protected]>
Date:   Wed Dec 20 14:38:58 2023 -0500

    dlm: fix format seq ops type 4
    
    [ Upstream commit 367e753d5c54a414d82610eb709fe71fda6cf1c3 ]
    
    This patch fixes to set the type 4 format ops in case of table_open4().
    It got accidentially changed by commit 541adb0d4d10 ("fs: dlm: debugfs
    for queued callbacks") and since them toss debug dumps the same format
    as format 5 that are the queued ast callbacks for lkbs.
    
    Fixes: 541adb0d4d10 ("fs: dlm: debugfs for queued callbacks")
    Signed-off-by: Alexander Aring <[email protected]>
    Signed-off-by: David Teigland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dma-mapping: clear dev->dma_mem to NULL after freeing it [+ + +]
Author: Joakim Zhang <[email protected]>
Date:   Thu Dec 14 16:25:26 2023 +0800

    dma-mapping: clear dev->dma_mem to NULL after freeing it
    
    [ Upstream commit b07bc2347672cc8c7293c64499f1488278c5ca3d ]
    
    Reproduced with below sequence:
    dma_declare_coherent_memory()->dma_release_coherent_memory()
    ->dma_declare_coherent_memory()->"return -EBUSY" error
    
    It will return -EBUSY from the dma_assign_coherent_memory()
    in dma_declare_coherent_memory(), the reason is that dev->dma_mem
    pointer has not been set to NULL after it's freed.
    
    Fixes: cf65a0f6f6ff ("dma-mapping: move all DMA mapping code to kernel/dma")
    Signed-off-by: Joakim Zhang <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/amd/pm: fix a use-after-free in kv_parse_power_table [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Fri Dec 15 00:24:58 2023 +0800

    drivers/amd/pm: fix a use-after-free in kv_parse_power_table
    
    [ Upstream commit 28dd788382c43b330480f57cd34cde0840896743 ]
    
    When ps allocated by kzalloc equals to NULL, kv_parse_power_table
    frees adev->pm.dpm.ps that allocated before. However, after the control
    flow goes through the following call chains:
    
    kv_parse_power_table
      |-> kv_dpm_init
            |-> kv_dpm_sw_init
                  |-> kv_dpm_fini
    
    The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
    first free in kv_parse_power_table and causes a use-after-free bug.
    
    Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/perf: hisi: Fix some event id for HiSilicon UC pmu [+ + +]
Author: Junhao He <[email protected]>
Date:   Mon Dec 4 19:04:25 2023 +0800

    drivers/perf: hisi: Fix some event id for HiSilicon UC pmu
    
    [ Upstream commit 38bbef7240b8c5f2dc4493eec356e2efbf2da5f4 ]
    
    Some event id of HiSilicon uncore UC PMU driver is incorrect, fix them.
    
    Fixes: 312eca95e28d ("drivers/perf: hisi: Add support for HiSilicon UC PMU driver")
    Signed-off-by: Junhao He <[email protected]>
    Reviewed-by: Yicong Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment [+ + +]
Author: Binbin Zhou <[email protected]>
Date:   Fri Nov 24 17:57:45 2023 +0800

    drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment
    
    [ Upstream commit 15ef92e9c41124ee9d88b01208364f3fe1f45f84 ]
    
    PTR_ERR() returns -ENODEV when thermal-zones are undefined, and we need
    -ENODEV as the right value for comparison.
    
    Otherwise, tz->type is NULL when thermal-zones is undefined, resulting
    in the following error:
    
    [   12.290030] CPU 1 Unable to handle kernel paging request at virtual address fffffffffffffff1, era == 900000000355f410, ra == 90000000031579b8
    [   12.302877] Oops[#1]:
    [   12.305190] CPU: 1 PID: 181 Comm: systemd-udevd Not tainted 6.6.0-rc7+ #5385
    [   12.312304] pc 900000000355f410 ra 90000000031579b8 tp 90000001069e8000 sp 90000001069eba10
    [   12.320739] a0 0000000000000000 a1 fffffffffffffff1 a2 0000000000000014 a3 0000000000000001
    [   12.329173] a4 90000001069eb990 a5 0000000000000001 a6 0000000000001001 a7 900000010003431c
    [   12.337606] t0 fffffffffffffff1 t1 54567fd5da9b4fd4 t2 900000010614ec40 t3 00000000000dc901
    [   12.346041] t4 0000000000000000 t5 0000000000000004 t6 900000010614ee20 t7 900000000d00b790
    [   12.354472] t8 00000000000dc901 u0 54567fd5da9b4fd4 s9 900000000402ae10 s0 900000010614ec40
    [   12.362916] s1 90000000039fced0 s2 ffffffffffffffed s3 ffffffffffffffed s4 9000000003acc000
    [   12.362931] s5 0000000000000004 s6 fffffffffffff000 s7 0000000000000490 s8 90000001028b2ec8
    [   12.362938]    ra: 90000000031579b8 thermal_add_hwmon_sysfs+0x258/0x300
    [   12.386411]   ERA: 900000000355f410 strscpy+0xf0/0x160
    [   12.391626]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
    [   12.397898]  PRMD: 00000004 (PPLV0 +PIE -PWE)
    [   12.403678]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
    [   12.409859]  ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
    [   12.415882] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
    [   12.415907]  BADV: fffffffffffffff1
    [   12.415911]  PRID: 0014a000 (Loongson-64bit, Loongson-2K1000)
    [   12.415917] Modules linked in: loongson2_thermal(+) vfat fat uio_pdrv_genirq uio fuse zram zsmalloc
    [   12.415950] Process systemd-udevd (pid: 181, threadinfo=00000000358b9718, task=00000000ace72fe3)
    [   12.415961] Stack : 0000000000000dc0 54567fd5da9b4fd4 900000000402ae10 9000000002df9358
    [   12.415982]         ffffffffffffffed 0000000000000004 9000000107a10aa8 90000001002a3410
    [   12.415999]         ffffffffffffffed ffffffffffffffed 9000000107a11268 9000000003157ab0
    [   12.416016]         9000000107a10aa8 ffffff80020fc0c8 90000001002a3410 ffffffffffffffed
    [   12.416032]         0000000000000024 ffffff80020cc1e8 900000000402b2a0 9000000003acc000
    [   12.416048]         90000001002a3410 0000000000000000 ffffff80020f4030 90000001002a3410
    [   12.416065]         0000000000000000 9000000002df6808 90000001002a3410 0000000000000000
    [   12.416081]         ffffff80020f4030 0000000000000000 90000001002a3410 9000000002df2ba8
    [   12.416097]         00000000000000b4 90000001002a34f4 90000001002a3410 0000000000000002
    [   12.416114]         ffffff80020f4030 fffffffffffffff0 90000001002a3410 9000000002df2f30
    [   12.416131]         ...
    [   12.416138] Call Trace:
    [   12.416142] [<900000000355f410>] strscpy+0xf0/0x160
    [   12.416167] [<90000000031579b8>] thermal_add_hwmon_sysfs+0x258/0x300
    [   12.416183] [<9000000003157ab0>] devm_thermal_add_hwmon_sysfs+0x50/0xe0
    [   12.416200] [<ffffff80020cc1e8>] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal]
    [   12.416232] [<9000000002df6808>] platform_probe+0x68/0x140
    [   12.416249] [<9000000002df2ba8>] really_probe+0xc8/0x3c0
    [   12.416269] [<9000000002df2f30>] __driver_probe_device+0x90/0x180
    [   12.416286] [<9000000002df3058>] driver_probe_device+0x38/0x160
    [   12.416302] [<9000000002df33a8>] __driver_attach+0xa8/0x200
    [   12.416314] [<9000000002deffec>] bus_for_each_dev+0x8c/0x120
    [   12.416330] [<9000000002df198c>] bus_add_driver+0x10c/0x2a0
    [   12.416346] [<9000000002df46b4>] driver_register+0x74/0x160
    [   12.416358] [<90000000022201a4>] do_one_initcall+0x84/0x220
    [   12.416372] [<90000000022f3ab8>] do_init_module+0x58/0x2c0
    [   12.416386] [<90000000022f6538>] init_module_from_file+0x98/0x100
    [   12.416399] [<90000000022f67f0>] sys_finit_module+0x230/0x3c0
    [   12.416412] [<900000000358f7c8>] do_syscall+0x88/0xc0
    [   12.416431] [<900000000222137c>] handle_syscall+0xbc/0x158
    
    Fixes: e7e3a7c35791 ("thermal/drivers/loongson-2: Add thermal management support")
    Cc: Yinbo Zhu <[email protected]>
    Signed-off-by: Binbin Zhou <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/343c14de98216636a47b43e8bfd47b70d0a8e068.1700817227.git.zhoubinbin@loongson.cn
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers: clk: zynqmp: calculate closest mux rate [+ + +]
Author: Jay Buddhabhatti <[email protected]>
Date:   Wed Nov 29 03:29:15 2023 -0800

    drivers: clk: zynqmp: calculate closest mux rate
    
    [ Upstream commit b782921ddd7f84f524723090377903f399fdbbcb ]
    
    Currently zynqmp clock driver is not calculating closest mux rate and
    because of that Linux is not setting proper frequency for CPU and
    not able to set given frequency for dynamic frequency scaling.
    
    E.g., In current logic initial acpu clock parent and frequency as below
    apll1                  0    0    0  2199999978    0     0  50000      Y
        acpu0_mux          0    0    0  2199999978    0     0  50000      Y
            acpu0_idiv1    0    0    0  2199999978    0     0  50000      Y
                acpu0      0    0    0  2199999978    0     0  50000      Y
    
    After changing acpu frequency to 549999994 Hz using CPU freq scaling its
    selecting incorrect parent which is not closest frequency.
    rpll_to_xpd            0    0    0  1599999984    0     0  50000      Y
        acpu0_mux          0    0    0  1599999984    0     0  50000      Y
            acpu0_div1     0    0    0   533333328    0     0  50000      Y
                acpu0      0    0    0   533333328    0     0  50000      Y
    
    Parent should remain same since 549999994 = 2199999978 / 4.
    
    So use __clk_mux_determine_rate_closest() generic function to calculate
    closest rate for mux clock. After this change its selecting correct
    parent and correct clock rate.
    apll1                  0    0    0  2199999978    0     0  50000      Y
        acpu0_mux          0    0    0  2199999978    0     0  50000      Y
            acpu0_div1     0    0    0   549999995    0     0  50000      Y
                acpu0      0    0    0   549999995    0     0  50000      Y
    
    Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
    Signed-off-by: Jay Buddhabhatti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers: clk: zynqmp: update divider round rate logic [+ + +]
Author: Jay Buddhabhatti <[email protected]>
Date:   Wed Nov 29 03:29:16 2023 -0800

    drivers: clk: zynqmp: update divider round rate logic
    
    [ Upstream commit 1fe15be1fb613534ecbac5f8c3f8744f757d237d ]
    
    Currently zynqmp divider round rate is considering single parent and
    calculating rate and parent rate accordingly. But if divider clock flag
    is set to SET_RATE_PARENT then its not trying to traverse through all
    parent rate and not selecting best parent rate from that. So use common
    divider_round_rate() which is traversing through all clock parents and
    its rate and calculating proper parent rate.
    
    Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
    Signed-off-by: Jay Buddhabhatti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings() [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Nov 22 23:13:36 2023 +0100

    drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings()
    
    [ Upstream commit c966dc0e9d96dc44423c404a2628236f1200c24e ]
    
    gcc prints a warning about a possible array overflow for a couple of
    callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
    Enable -Wstringop-overflow globally"):
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c: In function 'dp_perform_fixed_vs_pe_training_sequence_legacy':
    drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1 [-Werror=stringop-overflow=]
      426 |                         dp_decide_lane_settings(lt_settings, dpcd_lane_adjust,
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      427 |                                         lt_settings->hw_lane_settings, lt_settings->dpcd_lane_settings);
          |                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: note: referencing argument 4 of type 'union dpcd_training_lane[4]'
    
    I'm not entirely sure what caused this, but changing the prototype to expect
    a pointer instead of an array avoids the warnings.
    
    Fixes: 7727e7b60f82 ("drm/amd/display: Improve robustness of FIXED_VS link training at DP1 rates")
    Acked-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]> # build-tested
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Check writeback connectors in create_validate_stream_for_sink [+ + +]
Author: Alex Hung <[email protected]>
Date:   Fri Dec 1 06:25:28 2023 -0700

    drm/amd/display: Check writeback connectors in create_validate_stream_for_sink
    
    [ Upstream commit dbf5d3d02987faa0eec3710dd687cd912362d7b5 ]
    
    [WHY & HOW]
    This is to check connector type to avoid
    unhandled null pointer for writeback connectors.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Fixes: 60e034f28600 ("drm/amd/display: Revert "drm/amd/display: Use drm_connector in create_validate_stream_for_sink"")
    Signed-off-by: Alex Hung <[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 pointer dereference at hibernate [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Nov 28 18:35:09 2023 -0600

    drm/amd/display: Fix NULL pointer dereference at hibernate
    
    [ Upstream commit b719a9c15d52d4f56bdea8241a5d90fd9197ce99 ]
    
    During hibernate sequence the source context might not have a clk_mgr.
    So don't use it to look for DML2 support.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2980
    Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Return drm_connector from find_first_crtc_matching_connector [+ + +]
Author: Harry Wentland <[email protected]>
Date:   Fri Dec 1 06:25:26 2023 -0700

    drm/amd/display: Return drm_connector from find_first_crtc_matching_connector
    
    [ Upstream commit 748b091d641638e68330b1b24195eaba9aadf997 ]
    
    [WHY]
    We will be dealing with two types of connector: amdgpu_dm_connector
    and drm_writeback_connector.
    
    [HOW]
    We want to find both and then cast to the appriopriate type afterwards.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: dbf5d3d02987 ("drm/amd/display: Check writeback connectors in create_validate_stream_for_sink")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Use drm_connector in create_stream_for_sink [+ + +]
Author: Harry Wentland <[email protected]>
Date:   Fri Dec 1 06:25:27 2023 -0700

    drm/amd/display: Use drm_connector in create_stream_for_sink
    
    [ Upstream commit 3e094a2875260543ca74838decc0c995d3765096 ]
    
    [WHAT]
    We need to use this function for both amdgpu_dm_connectors
    and drm_writeback_connectors. Modify it to operate on
    a drm_connector as a common base.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: dbf5d3d02987 ("drm/amd/display: Check writeback connectors in create_validate_stream_for_sink")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_init [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Sun Dec 24 16:22:47 2023 +0800

    drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_init
    
    [ Upstream commit 2f3be3ca779b11c332441b10e00443a2510f4d7b ]
    
    The hwmgr->backend, (i.e. data) allocated by kzalloc is not freed in
    the error-handling paths of smu7_get_evv_voltages and
    smu7_update_edc_leakage_table. However, it did be freed in the
    error-handling of phm_initializa_dynamic_state_adjustment_rule_settings,
    by smu7_hwmgr_backend_fini. So the lack of free in smu7_get_evv_voltages
    and smu7_update_edc_leakage_table is considered a memleak in this patch.
    
    Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.")
    Fixes: 8f0804c6b7d0 ("drm/amd/pm: add edc leakage controller setting")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm: fix a double-free in amdgpu_parse_extended_power_table [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Fri Dec 15 00:59:38 2023 +0800

    drm/amd/pm: fix a double-free in amdgpu_parse_extended_power_table
    
    [ Upstream commit a6582701178a47c4d0cb2188c965c59c0c0647c8 ]
    
    The amdgpu_free_extended_power_table is called in every error-handling
    paths of amdgpu_parse_extended_power_table. However, after the following
    call chain of returning:
    
    amdgpu_parse_extended_power_table
      |-> kv_dpm_init / si_dpm_init
          (the only two caller of amdgpu_parse_extended_power_table)
            |-> kv_dpm_sw_init / si_dpm_sw_init
                (the only caller of kv_dpm_init / si_dpm_init, accordingly)
                  |-> kv_dpm_fini / si_dpm_fini
                      (goto dpm_failed in xx_dpm_sw_init)
                        |-> amdgpu_free_extended_power_table
    
    As above, the amdgpu_free_extended_power_table is called twice in this
    returning chain and thus a double-free is triggered. Similarily, the
    last kfree in amdgpu_parse_extended_power_table also cause a double free
    with amdgpu_free_extended_power_table in kv_dpm_fini.
    
    Fixes: 84176663e70d ("drm/amd/pm: create a new holder for those APIs used only by legacy ASICs(si/kv)")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: fix a double-free in si_dpm_init [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Thu Dec 14 23:24:11 2023 +0800

    drm/amd/pm: fix a double-free in si_dpm_init
    
    [ Upstream commit ac16667237a82e2597e329eb9bc520d1cf9dff30 ]
    
    When the allocation of
    adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
    amdgpu_free_extended_power_table is called to free some fields of adev.
    However, when the control flow returns to si_dpm_sw_init, it goes to
    label dpm_failed and calls si_dpm_fini, which calls
    amdgpu_free_extended_power_table again and free those fields again. Thus
    a double-free is triggered.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd: Enable PCIe PME from D3 [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Nov 24 09:56:32 2023 -0600

    drm/amd: Enable PCIe PME from D3
    
    commit bd1f6a31e7762ebc99b97f3eda5e5ea3708fa792 upstream.
    
    When dGPU is put into BOCO it may be in D3cold but still able send
    PME on display hotplug event. For this to work it must be enabled
    as wake source from D3.
    
    When runpm is enabled use pci_wake_from_d3() to mark wakeup as
    enabled by default.
    
    Cc: [email protected] # 6.1+
    Signed-off-by: Mario Limonciello <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu/debugfs: fix error code when smc register accessors are NULL [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Nov 27 17:26:29 2023 -0500

    drm/amdgpu/debugfs: fix error code when smc register accessors are NULL
    
    [ Upstream commit afe58346d5d3887b3e49ff623d2f2e471f232a8d ]
    
    Should be -EOPNOTSUPP.
    
    Fixes: 5104fdf50d32 ("drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL")
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: fall back to INPUT power for AVG power via INFO IOCTL [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Oct 2 14:43:06 2023 -0400

    drm/amdgpu: fall back to INPUT power for AVG power via INFO IOCTL
    
    [ Upstream commit d02069850fc102b07ae923535d5e212f2c8a34e9 ]
    
    For backwards compatibility with userspace.
    
    Fixes: 47f1724db4fe ("drm/amd: Introduce `AMDGPU_PP_SENSOR_GPU_INPUT_POWER`")
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2897
    Reviewed-by: Yang Wang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: revert "Adjust removal control flow for smu v13_0_2" [+ + +]
Author: Christian König <[email protected]>
Date:   Wed Jan 10 15:19:29 2024 +0100

    drm/amdgpu: revert "Adjust removal control flow for smu v13_0_2"
    
    commit fb1c93c2e9604a884467a773790016199f78ca08 upstream.
    
    Calling amdgpu_device_ip_resume_phase1() during shutdown leaves the
    HW in an active state and is an unbalanced use of the IP callbacks.
    
    Using the IP callbacks like this can lead to memory leaks, double
    free and imbalanced reference counters.
    
    Leaving the HW in an active state can lead to DMA accesses to memory now
    freed by the driver.
    
    Both is a complete no-go for driver unload so completely revert the
    workaround for now.
    
    This reverts commit f5c7e7797060255dbc8160734ccc5ad6183c5e04.
    
    Signed-off-by: Christian König <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Dec 21 07:16:23 2023 +0530

    drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c
    
    [ Upstream commit 499839eca34ad62d43025ec0b46b80e77065f6d8 ]
    
    Before using list_first_entry, make sure to check that list is not
    empty, if list is empty return -ENODATA.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL?
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL?
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
    
    Fixes: 0f28cca87e9a ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links")
    Cc: Felix Kuehling <[email protected]>
    Cc: Christian König <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Suggested-by: Felix Kuehling <[email protected]>
    Suggested-by: Lijo Lazar <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdkfd: Fix type of 'dbg_flags' in 'struct kfd_process' [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Dec 21 08:10:42 2023 +0530

    drm/amdkfd: Fix type of 'dbg_flags' in 'struct kfd_process'
    
    [ Upstream commit 217e85f97031791fb48a2d374c7bdcf439365b21 ]
    
    dbg_flags looks to be defined with incorrect data type; to process
    multiple debug flag options, and hence defined dbg_flags as u32.
    
    Fixes the below:
    
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_packet_manager_v9.c:117 pm_map_process_aldebaran() warn: maybe use && instead of &
    
    Fixes: 0de4ec9a0353 ("drm/amdgpu: prepare map process for multi-process debug devices")
    Suggested-by: Lijo Lazar <[email protected]>
    Cc: Felix Kuehling <[email protected]>
    Cc: Christian König <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdkfd: fixes for HMM mem allocation [+ + +]
Author: Dafna Hirschfeld <[email protected]>
Date:   Sun Jan 7 15:07:00 2024 +0200

    drm/amdkfd: fixes for HMM mem allocation
    
    [ Upstream commit 02eed83abc1395a1207591aafad9bcfc5cb1abcb ]
    
    Fix err return value and reset pgmap->type after checking it.
    
    Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Dafna Hirschfeld <[email protected]>
    Signed-off-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/bridge: cdns-mhdp8546: Fix use of uninitialized variable [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Fri Nov 3 15:14:05 2023 +0200

    drm/bridge: cdns-mhdp8546: Fix use of uninitialized variable
    
    [ Upstream commit 155d6fb61270dd297f128731cd155080deee8f3a ]
    
    'ret' could be uninitialized at the end of the function, although it's
    not clear if that can happen in practice.
    
    Fixes: 6a3608eae6d3 ("drm: bridge: cdns-mhdp8546: Enable HDCP")
    Acked-by: Maxime Ripard <[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/bridge: Fix typo in post_disable() description [+ + +]
Author: Dario Binacchi <[email protected]>
Date:   Fri Nov 24 10:42:30 2023 +0100

    drm/bridge: Fix typo in post_disable() description
    
    [ Upstream commit 288b039db225676e0c520c981a1b5a2562d893a3 ]
    
    s/singals/signals/
    
    Fixes: 199e4e967af4 ("drm: Extract drm_bridge.h")
    Signed-off-by: Dario Binacchi <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: imx93-mipi-dsi: Fix a couple of building warnings [+ + +]
Author: Liu Ying <[email protected]>
Date:   Thu Nov 23 13:18:07 2023 +0800

    drm/bridge: imx93-mipi-dsi: Fix a couple of building warnings
    
    [ Upstream commit 325b71e820b67569048c621227266783442b75ed ]
    
    Fix a couple of building warnings on used uninitialized 'best_m' and
    'best_n' local variables by initializing 'best_m' to zero and 'best_n'
    to UINT_MAX.  This makes compiler happy only.  No functional change.
    
    Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Liu Ying <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: tc358767: Fix return value on error case [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Fri Nov 3 15:14:06 2023 +0200

    drm/bridge: tc358767: Fix return value on error case
    
    [ Upstream commit 32bd29b619638256c5b75fb021d6d9f12fc4a984 ]
    
    If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains
    0, instead of an error value.
    
    Return -EINVAL instead.
    
    Fixes: f25ee5017e4f ("drm/bridge: tc358767: add IRQ and HPD support")
    Acked-by: Maxime Ripard <[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/bridge: tpd12s015: Drop buggy __exit annotation for remove function [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Thu Nov 2 17:56:42 2023 +0100

    drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
    
    [ Upstream commit ce3e112e7ae854249d8755906acc5f27e1542114 ]
    
    With tpd12s015_remove() marked with __exit this function is discarded
    when the driver is compiled as a built-in. The result is that when the
    driver unbinds there is no cleanup done which results in resource
    leakage or worse.
    
    Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
    Signed-off-by: Uwe Kleine-König <[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/dp_mst: Fix fractional DSC bpp handling [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Tue Oct 24 04:08:57 2023 +0300

    drm/dp_mst: Fix fractional DSC bpp handling
    
    [ Upstream commit 7707dd6022593f3edd8e182e7935870cf326f874 ]
    
    The current code does '(bpp << 4) / 16' in the MST PBN
    calculation, but that is just the same as 'bpp' so the
    DSC codepath achieves absolutely nothing. Fix it up so that
    the fractional part of the bpp value is actually used instead
    of truncated away. 64*1006 has enough zero lsbs that we can
    just shift that down in the dividend and thus still manage
    to stick to a 32bit divisor.
    
    And while touching this, let's just make the whole thing more
    straightforward by making the passed in bpp value .4 binary
    fixed point always, instead of having to pass in different
    things based on whether DSC is enabled or not.
    
    v2:
    - Fix DSC kunit test cases.
    
    Cc: Manasi Navare <[email protected]>
    Cc: Lyude Paul <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: David Francis <[email protected]>
    Cc: Mikita Lipski <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Fixes: dc48529fb14e ("drm/dp_mst: Add PBN calculation for DSC modes")
    Signed-off-by: Ville Syrjälä <[email protected]>
    [Imre: Fix kunit test cases]
    Acked-by: Maxime Ripard <[email protected]>
    Reviewed-by: Lyude Paul <[email protected]>
    Acked-by: Harry Wentland <[email protected]>
    Signed-off-by: Imre Deak <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/drv: propagate errors from drm_modeset_register_all() [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Dec 3 01:55:52 2023 +0300

    drm/drv: propagate errors from drm_modeset_register_all()
    
    [ Upstream commit 5f8dec200923a76dc57187965fd59c1136f5d085 ]
    
    In case the drm_modeset_register_all() function fails, its error code
    will be ignored. Instead make the drm_dev_register() bail out in case of
    such an error.
    
    Fixes: 79190ea2658a ("drm: Add callbacks for late registering")
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[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/i915/display: Move releasing gem object away from fb tracking [+ + +]
Author: Jouni Högander <[email protected]>
Date:   Thu Oct 12 10:21:57 2023 +0300

    drm/i915/display: Move releasing gem object away from fb tracking
    
    [ Upstream commit 501069dad5214fafe1b8ba38fa26a5d07df784c3 ]
    
    As a preparation for Xe we want to remove all i915_gem_object details away
    from frontbuffer tacking code. Due to this move releasing gem object
    reference to i915_gem_object_set_frontbuffer.
    
    Signed-off-by: Jouni Högander <[email protected]>
    Reviewed-by: Juha-Pekka Heikkila <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Stable-dep-of: 560ea72c76eb ("drm/i915/dp_mst: Fix race between connector registration and setup")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/dp: Fix the max DSC bpc supported by source [+ + +]
Author: Ankit Nautiyal <[email protected]>
Date:   Wed Dec 13 14:46:29 2023 +0530

    drm/i915/dp: Fix the max DSC bpc supported by source
    
    [ Upstream commit 584ebbefd12296c6bad009c8a0c9e610eb8283c8 ]
    
    Use correct helper for getting max DSC bpc supported by the source.
    
    Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp")
    Cc: Ankit Nautiyal <[email protected]>
    Cc: Stanislav Lisovskiy <[email protected]>
    Cc: Jani Nikula <[email protected]>
    
    Signed-off-by: Ankit Nautiyal <[email protected]>
    Reviewed-by: Swati Sharma <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit cd7b0b2dd3d9fecc6057c07b40e8087db2f9f71a)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/imx/lcdc: Fix double-free of driver data [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Thu Jul 6 11:27:31 2023 +0200

    drm/imx/lcdc: Fix double-free of driver data
    
    [ Upstream commit ff3670877e7c73d06c2a835d9abb62efcae0145c ]
    
    The struct imx_lcdc driver data is allocated using devm_drm_dev_alloc()
    so it must not be explicitly kfree()d.
    
    Also drm_kms_helper_poll_fini() should not be called as there is no
    matching drm_kms_helper_poll_init(). So drop the release function
    completely.
    
    Fixes: c87e859cdeb5 ("drm/imx/lcdc: Implement DRM driver for imx25")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Reviewed-by: Philipp Zabel <[email protected]>
    Signed-off-by: Philipp Zabel <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue Nov 21 09:29:27 2023 -0500

    drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency
    
    [ Upstream commit c8048dd0b07df68724805254b9e994d99e9a7af4 ]
    
    The mtk_dp driver registers a phy device which is handled by the
    phy_mtk_dp driver and assumes that the phy probe will complete
    synchronously, proceeding to make use of functionality exposed by that
    driver right away. This assumption however is false when the phy driver
    is built as a module, causing the mtk_dp driver to fail probe in this
    case.
    
    Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
    ensure the phy module has been loaded before the dp, so that the phy
    probe happens synchrounously and the mtk_dp driver can probe
    successfully even with the phy driver built as a module.
    
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Guillaume Ranquet <[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 underrun in VDO1 when switches off the layer [+ + +]
Author: Hsiao Chien Sung <[email protected]>
Date:   Thu Dec 14 13:58:46 2023 +0800

    drm/mediatek: Fix underrun in VDO1 when switches off the layer
    
    [ Upstream commit 73b5ab27ab2ee616f2709dc212c2b0007894a12e ]
    
    Do not reset Merge while using CMDQ because reset API doesn't
    wait for frame done event as CMDQ does and could lead to
    underrun when the layer is switching off.
    
    Fixes: aaf94f7c3ae6 ("drm/mediatek: Add display merge async reset control")
    
    Reviewed-by: CK Hu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Hsiao Chien Sung <[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: Remove the redundant driver data for DPI [+ + +]
Author: Hsiao Chien Sung <[email protected]>
Date:   Thu Dec 14 13:58:45 2023 +0800

    drm/mediatek: Remove the redundant driver data for DPI
    
    [ Upstream commit 8ac6935e5689a491f0bec78fec732722b3dad094 ]
    
    DPI input is in 1T2P mode on both MT8195 and MT8188.
    Remove the redundant driver data to align the settings, or
    the screen will glitch.
    
    Fixes: 2847cd7e6403 ("drm/mediatek: Add mt8188 dpi compatibles and platform data")
    
    Reviewed-by: CK Hu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Hsiao Chien Sung <[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: Return error if MDP RDMA failed to enable the clock [+ + +]
Author: Hsiao Chien Sung <[email protected]>
Date:   Thu Dec 14 13:58:44 2023 +0800

    drm/mediatek: Return error if MDP RDMA failed to enable the clock
    
    [ Upstream commit 21b287146adf39304193e4c49198021e06a28ded ]
    
    Return the result of clk_prepare_enable() instead of
    always returns 0.
    
    Fixes: f8946e2b6bb2 ("drm/mediatek: Add display MDP RDMA support for MT8195")
    
    Reviewed-by: CK Hu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Hsiao Chien Sung <[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: add QMP dependency [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 16 22:04:03 2023 +0200

    drm/msm/a6xx: add QMP dependency
    
    [ Upstream commit 96ab215b2d5edc39310c00f50b33d8ab72ac3fe3 ]
    
    When QMP is in a loadable module, the A6xx GPU driver fails to link
    as built-in:
    
    x86_64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gmu.o: in function `a6xx_gmu_resume':
    a6xx_gmu.c:(.text+0xd62): undefined reference to `qmp_send'
    
    Add the usual dependency that still allows compiling without QMP but
    otherwise avoids the broken combination of options.
    
    Fixes: 88a0997f2f949 ("drm/msm/a6xx: Send ACD state to QMP at GMU resume")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/562945/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/adreno: Fix A680 chip id [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Thu Nov 30 16:26:41 2023 -0800

    drm/msm/adreno: Fix A680 chip id
    
    [ Upstream commit 3e6688fd96966b6c275e95c39aa367bc0a490ccd ]
    
    The only A680 referenced from DeviceTree is patch level 1, which since
    commit '90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying
    GPU")' isn't a known chip id.
    
    Correct the chip id to allow the A680 to be recognized again.
    
    Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")
    Signed-off-by: Bjorn Andersson <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/569839/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dpu: Add missing safe_lut_tbl in sc8180x catalog [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Thu Nov 30 16:35:01 2023 -0800

    drm/msm/dpu: Add missing safe_lut_tbl in sc8180x catalog
    
    [ Upstream commit 7cc2621f16b644bb7af37987cb471311641a9e56 ]
    
    Similar to SC8280XP, the misconfigured SAFE logic causes rather
    significant delays in __arm_smmu_tlb_sync(), resulting in poor
    performance for things such as USB.
    
    Introduce appropriate SAFE values for SC8180X to correct this.
    
    Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog")
    Signed-off-by: Bjorn Andersson <[email protected]>
    Reported-by: Anton Bambura <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/569840/
    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: correct clk bit for WB2 block [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Dec 3 03:24:37 2023 +0300

    drm/msm/dpu: correct clk bit for WB2 block
    
    [ Upstream commit e843ca2f30e630675e2d2a75c96f4844f2854430 ]
    
    On sc7280 there are two clk bits for WB2: vbif_cli and clk_ctrl. While
    programming the VBIF params of WB, the driver should be toggling the
    former bit, while the sc7180_mdp, sc7280_mdp and sm8250_mdp structs
    list the latter one.
    
    Correct that to ensure proper programming sequence for WB2 on these
    platforms.
    
    Fixes: 255f056181ac ("drm/msm/dpu: sc7180: add missing WB2 clock control")
    Fixes: 3ce166380567 ("drm/msm/dpu: add writeback support for sc7280")
    Fixes: 53324b99bd7b ("drm/msm/dpu: add writeback blocks to the sm8250 DPU catalog")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Tested-by: Paloma Arellano <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/570185/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: Drop enable and frame_count parameters from dpu_hw_setup_misr() [+ + +]
Author: Jessica Zhang <[email protected]>
Date:   Wed Dec 13 13:30:18 2023 -0800

    drm/msm/dpu: Drop enable and frame_count parameters from dpu_hw_setup_misr()
    
    [ Upstream commit 3313c23f3eab698bc6b904520ee608fc0f7b03d0 ]
    
    Drop the enable and frame_count parameters from dpu_hw_setup_misr() as they
    are always set to the same values.
    
    In addition, replace MISR_FRAME_COUNT_MASK with MISR_FRAME_COUNT as
    frame_count is always set to the same value.
    
    Fixes: 7b37523fb1d1 ("drm/msm/dpu: Move MISR methods to dpu_hw_util")
    Signed-off-by: Jessica Zhang <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/572009/
    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: enable SmartDMA on SM8450 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Oct 9 19:56:27 2023 +0300

    drm/msm/dpu: enable SmartDMA on SM8450
    
    [ Upstream commit a9bd555de5e9042fdf8ab8d6080b86f45c68ddf6 ]
    
    Enable the SmartDMA / multirect support on the SM8450 platform to
    support higher resoltion modes.
    
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/561590/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Stable-dep-of: 46b1f1b839ca ("drm/msm/dpu: populate SSPP scaler block version")
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: populate SSPP scaler block version [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Dec 2 01:40:25 2023 +0200

    drm/msm/dpu: populate SSPP scaler block version
    
    [ Upstream commit 46b1f1b839cad600de3ad7ed999bd0155c528746 ]
    
    The function _dpu_hw_sspp_setup_scaler3() passes and
    dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
    the scaler (QSEED3) block should be programmed. However up to now we
    were not setting this field. Set it now, splitting the vig_sblk data
    which has different version fields.
    
    Reported-by: Marijn Suijten <[email protected]>
    Fixes: 9b6f4fedaac2 ("drm/msm/dpu: Add SM6125 support")
    Fixes: 27f0df03f3ff ("drm/msm/dpu: Add SM6375 support")
    Fixes: 3186acba5cdc ("drm/msm/dpu: Add SM6350 support")
    Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
    Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
    Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
    Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
    Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
    Fixes: dabfdd89eaa9 ("drm/msm/disp/dpu1: add inline rotation support for sc7280")
    Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog")
    Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
    Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog")
    Fixes: 386fced3f76f ("drm/msm/dpu: add SM8150 to hw catalog")
    Fixes: b75ab05a3479 ("msm:disp:dpu1: add scaler support on SC7180 display")
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/570098/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dpu: Set input_sel bit for INTF [+ + +]
Author: Jessica Zhang <[email protected]>
Date:   Wed Dec 13 13:30:17 2023 -0800

    drm/msm/dpu: Set input_sel bit for INTF
    
    [ Upstream commit 980fffd0c69e5df0f67ee089d405899d532aeeab ]
    
    Set the input_sel bit for encoders as it was missed in the initial
    implementation.
    
    Reported-by: Rob Clark <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/39
    Fixes: 91143873a05d ("drm/msm/dpu: Add MISR register support for interface")
    Signed-off-by: Jessica Zhang <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/572007/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Jun 20 13:43:20 2023 +0200

    drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
    
    [ Upstream commit 3d07a411b4faaf2b498760ccf12888f8de529de0 ]
    
    This helper has been introduced to avoid programmer errors (missing
    _put calls leading to dangling refcnt) when using pm_runtime_get, use it.
    
    While at it, start checking the return value.
    
    Signed-off-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Fixes: 5c8290284402 ("drm/msm/dsi: Split PHY drivers to separate files")
    Patchwork: https://patchwork.freedesktop.org/patch/543350/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/mdp4: flush vblank event on disable [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Tue Nov 28 00:54:01 2023 +0300

    drm/msm/mdp4: flush vblank event on disable
    
    [ Upstream commit c6721b3c6423d8a348ae885a0f4c85e14f9bf85c ]
    
    Flush queued events when disabling the crtc. This avoids timeouts when
    we come back and wait for dependencies (like the previous frame's
    flip_done).
    
    Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/569127/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer [+ + +]
Author: Abhinav Singh <[email protected]>
Date:   Tue Nov 14 00:43:03 2023 +0530

    drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer
    
    [ Upstream commit 5f35a624c1e30b5bae5023b3c256e94e0ad4f806 ]
    
    Fix a sparse warning with this message
    "warning:dereference of noderef expression". In this context it means we
    are dereferencing a __rcu tagged pointer directly.
    
    We should not be directly dereferencing a rcu pointer. To get a normal
    (non __rcu tagged pointer) from a __rcu tagged pointer we are using the
    function unrcu_pointer(...). The non __rcu tagged pointer then can be
    dereferenced just like a normal pointer.
    
    I tested with qemu with this command
    qemu-system-x86_64 \
            -m 2G \
            -smp 2 \
            -kernel bzImage \
            -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
            -drive file=bullseye.img,format=raw \
            -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
            -net nic,model=e1000 \
            -enable-kvm \
            -nographic \
            -pidfile vm.pid \
            2>&1 | tee vm.log
    with lockdep enabled.
    
    Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
    Signed-off-by: Abhinav Singh <[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]>

 
drm/panel-elida-kd35t133: hold panel in reset for unprepare [+ + +]
Author: Chris Morgan <[email protected]>
Date:   Fri Nov 17 13:44:02 2023 -0600

    drm/panel-elida-kd35t133: hold panel in reset for unprepare
    
    [ Upstream commit 03c5b2a5f6c39fe4e090346536cf1c14ee18b61e ]
    
    For devices like the Anbernic RG351M and RG351P the panel is wired to
    an always on regulator. When the device suspends and wakes up, there
    are some slight artifacts on the screen that go away over time. If
    instead we hold the panel in reset status after it is unprepared,
    this does not happen.
    
    Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133 panels")
    Signed-off-by: Chris Morgan <[email protected]>
    Reviewed-by: Jessica Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: nv3051d: Hold panel in reset for unprepare [+ + +]
Author: Chris Morgan <[email protected]>
Date:   Fri Nov 17 14:25:32 2023 -0600

    drm/panel: nv3051d: Hold panel in reset for unprepare
    
    [ Upstream commit 697ebc319b942403a6fee894607fd2cd47cca069 ]
    
    Improve the panel's ability to restore from suspend by holding the
    panel in suspend after unprepare.
    
    Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
    Signed-off-by: Chris Morgan <[email protected]>
    Reviewed-by: Jessica Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: st7701: Fix AVCL calculation [+ + +]
Author: Chris Morgan <[email protected]>
Date:   Fri Dec 8 09:48:45 2023 -0600

    drm/panel: st7701: Fix AVCL calculation
    
    [ Upstream commit 799825aa87200ade1ba21db853d1c2ff720dcfe0 ]
    
    The AVCL register, according to the datasheet, comes in increments
    of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented
    by 0x3). The current calculation is done by adding the defined
    AVCL value in mV to -4400 and then dividing by 200 to get the register
    value. Unfortunately if I subtract -4400 from -4400 I get -8800, which
    divided by 200 gives me -44. If I instead subtract -4400 from -4400
    I get 0, which divided by 200 gives me 0. Based on the datasheet this
    is the expected register value.
    
    Fixes: 83b7a8e7e88e ("drm/panel/panel-sitronix-st7701: Parametrize voltage and timing")
    
    Signed-off-by: Chris Morgan <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Mon Dec 4 12:42:13 2023 +0100

    drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq
    
    [ Upstream commit a4f5892914ca7709ea6d191f0edace93a5935966 ]
    
    Some SoCs may be equipped with a GPU containing two core groups
    and this is exactly the case of Samsung's Exynos 5422 featuring
    an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
    is partial, as this driver currently supports using only one
    core group and that's reflected on all parts of it, including
    the power on (and power off, previously to this patch) function.
    
    The issue with this is that even though executing the soft reset
    operation should power off all cores unconditionally, on at least
    one platform we're seeing a crash that seems to be happening due
    to an interrupt firing which may be because we are calling power
    transition only on the first core group, leaving the second one
    unchanged, or because ISR execution was pending before entering
    the panfrost_gpu_power_off() function and executed after powering
    off the GPU cores, or all of the above.
    
    Finally, solve this by:
     - Avoid to enable the power transition interrupt on reset; and
     - Ignoring the core_mask and ask the GPU to poweroff both core groups
    
    Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()")
    Reviewed-by: Boris Brezillon <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Signed-off-by: Boris Brezillon <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off() [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Nov 2 15:15:07 2023 +0100

    drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()
    
    [ Upstream commit 22aa1a209018dc2eca78745f7666db63637cd5dc ]
    
    The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
    powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
    this means that in order to request poweroff of cores, we are supposed
    to write a bitmask of cores that should be powered off!
    This means that the panfrost_gpu_power_off() function has always been
    doing nothing.
    
    Fix powering off the GPU by writing a bitmask of the cores to poweroff
    to the relevant PWROFF_LO registers and then check that the transition
    (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
    registers.
    
    While at it, in order to avoid code duplication, move the core mask
    logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
    function, used in both poweron and poweroff.
    
    Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Steven Price <[email protected]>
    Signed-off-by: Steven Price <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/dpm: fix a memleak in sumo_parse_power_table [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Mon Dec 4 16:57:56 2023 +0800

    drm/radeon/dpm: fix a memleak in sumo_parse_power_table
    
    [ Upstream commit 0737df9ed0997f5b8addd6e2b9699a8c6edba2e4 ]
    
    The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
    following error-handling path. However, in the error-handling of
    rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
    resulting in a memleak in this function.
    
    Fixes: 80ea2c129c76 ("drm/radeon/kms: add dpm support for sumo asics (v2)")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/r100: Fix integer overflow issues in r100_cs_track_check() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Nov 29 07:22:12 2023 -0800

    drm/radeon/r100: Fix integer overflow issues in r100_cs_track_check()
    
    [ Upstream commit b5c5baa458faa5430c445acd9a17481274d77ccf ]
    
    It may be possible, albeit unlikely, to encounter integer overflow
    during the multiplication of several unsigned int variables, the
    result being assigned to a variable 'size' of wider type.
    
    Prevent this potential behaviour by converting one of the multiples
    to unsigned long.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 0242f74d29df ("drm/radeon: clean up CS functions in r100.c")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/r600_cs: Fix possible int overflows in r600_cs_check_reg() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Nov 29 07:22:30 2023 -0800

    drm/radeon/r600_cs: Fix possible int overflows in r600_cs_check_reg()
    
    [ Upstream commit 39c960bbf9d9ea862398759e75736cfb68c3446f ]
    
    While improbable, there may be a chance of hitting integer
    overflow when the result of radeon_get_ib_value() gets shifted
    left.
    
    Avoid it by casting one of the operands to larger data type (u64).
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 1729dd33d20b ("drm/radeon/kms: r600 CS parser fixes")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/trinity_dpm: fix a memleak in trinity_parse_power_table [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Mon Dec 4 18:21:54 2023 +0800

    drm/radeon/trinity_dpm: fix a memleak in trinity_parse_power_table
    
    [ Upstream commit 28c28d7f77c06ac2c0b8f9c82bc04eba22912b3b ]
    
    The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
    following error-handling path. However, in the error-handling of
    rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
    resulting in a memleak in this function.
    
    Fixes: d70229f70447 ("drm/radeon/kms: add dpm support for trinity asics")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon: check return value of radeon_ring_lock() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Aug 8 11:04:16 2023 -0700

    drm/radeon: check return value of radeon_ring_lock()
    
    [ Upstream commit 71225e1c930942cb1e042fc08c5cc0c4ef30e95e ]
    
    In the unlikely event of radeon_ring_lock() failing, its errno return
    value should be processed. This patch checks said return value and
    prints a debug message in case of an error.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 48c0c902e2e6 ("drm/radeon/kms: add support for CP setup on SI")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Thu Nov 30 15:50:16 2023 +0800

    drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()
    
    [ Upstream commit 7a2464fac80d42f6f8819fed97a553e9c2f43310 ]
    
    check the alloc_workqueue return value in radeon_crtc_init()
    to avoid null-ptr-deref.
    
    Fixes: fa7f517cb26e ("drm/radeon: rework page flip handling v4")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/sched: Fix bounds limiting when given a malformed entity [+ + +]
Author: Luben Tuikov <[email protected]>
Date:   Wed Nov 22 23:58:53 2023 -0500

    drm/sched: Fix bounds limiting when given a malformed entity
    
    [ Upstream commit 2bbe6ab2be53858507f11f99f856846d04765ae3 ]
    
    If we're given a malformed entity in drm_sched_entity_init()--shouldn't
    happen, but we verify--with out-of-bounds priority value, we set it to an
    allowed value. Fix the expression which sets this limit.
    
    Signed-off-by: Luben Tuikov <[email protected]>
    Fixes: 56e449603f0ac5 ("drm/sched: Convert the GPU scheduler to variable number of run-queues")
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Christian König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tidss: Check for K2G in in dispc_softreset() [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Thu Nov 9 09:37:59 2023 +0200

    drm/tidss: Check for K2G in in dispc_softreset()
    
    [ Upstream commit 151825150cf9c2e9fb90763d35b9dff3783628ac ]
    
    K2G doesn't have softreset feature. Instead of having every caller of
    dispc_softreset() check for K2G, move the check into dispc_softreset(),
    and make dispc_softreset() return 0 in case of K2G.
    
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Stable-dep-of: bc288a927815 ("drm/tidss: Fix dss reset")
    Signed-off-by: Sasha Levin <[email protected]>

drm/tidss: Fix dss reset [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Thu Nov 9 09:38:01 2023 +0200

    drm/tidss: Fix dss reset
    
    [ Upstream commit bc288a927815efcf9d7f4a54d4d89c5df478c635 ]
    
    The probe function calls dispc_softreset() before runtime PM is enabled
    and without enabling any of the DSS clocks. This happens to work by
    luck, and we need to make sure the DSS HW is active and the fclk is
    enabled.
    
    To fix the above, add a new function, dispc_init_hw(), which does:
    
    - pm_runtime_set_active()
    - clk_prepare_enable(fclk)
    - dispc_softreset().
    
    This ensures that the reset can be successfully accomplished.
    
    Note that we use pm_runtime_set_active(), not the normal
    pm_runtime_get(). The reason for this is that at this point we haven't
    enabled the runtime PM yet and also we don't want the normal resume
    callback to be called: the dispc resume callback does some initial HW
    setup, and it expects that the HW was off (no video ports are
    streaming). If the bootloader has enabled the DSS and has set up a
    boot time splash-screen, the DSS would be enabled and streaming which
    might lead to issues with the normal resume callback.
    
    Fixes: c9b2d923befd ("drm/tidss: Soft Reset DISPC on startup")
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/tidss: Move reset to the end of dispc_init() [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Thu Nov 9 09:37:57 2023 +0200

    drm/tidss: Move reset to the end of dispc_init()
    
    [ Upstream commit 36d1e0852680aa038e2428d450673390111b165c ]
    
    We do a DSS reset in the middle of the dispc_init(). While that happens
    to work now, we should really make sure that e..g the fclk, which is
    acquired only later in the function, is enabled when doing a reset. This
    will be handled in a later patch, but for now, let's move the
    dispc_softreset() call to the end of dispc_init(), which is a sensible
    place for it anyway.
    
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Stable-dep-of: bc288a927815 ("drm/tidss: Fix dss reset")
    Signed-off-by: Sasha Levin <[email protected]>

drm/tidss: Return error value from from softreset [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Thu Nov 9 09:37:58 2023 +0200

    drm/tidss: Return error value from from softreset
    
    [ Upstream commit aceafbb5035c4bfc75a321863ed1e393d644d2d2 ]
    
    Return an error value from dispc_softreset() so that the caller can
    handle the errors.
    
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Stable-dep-of: bc288a927815 ("drm/tidss: Fix dss reset")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tilcdc: Fix irq free on unload [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Tue Sep 19 10:12:50 2023 +0300

    drm/tilcdc: Fix irq free on unload
    
    [ Upstream commit 38360bf96d816e175bc602c4ee76953cd303b71d ]
    
    The driver only frees the reserved irq if priv->irq_enabled is set to
    true. However, the driver mistakenly sets priv->irq_enabled to false,
    instead of true, in tilcdc_irq_install(), and thus the driver never
    frees the irq, causing issues on loading the driver a second time.
    
    Fixes: b6366814fa77 ("drm/tilcdc: Convert to Linux IRQ interfaces")
    Cc: Thomas Zimmermann <[email protected]>
    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]>

 
dt-bindings: arm: qcom: Fix html link [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Tue Nov 28 19:04:41 2023 -0800

    dt-bindings: arm: qcom: Fix html link
    
    [ Upstream commit 3c3fcac8d3b1b0f242845c3b3c3263bd38b3b92f ]
    
    This link got broken by commit e790a4ce5290 ("arm: docs: Move Arm
    documentation to Documentation/arch/") when the doc moved from arm/ to
    arch/arm/. Fix the link so that it can continue to be followed.
    
    Fixes: e790a4ce5290 ("arm: docs: Move Arm documentation to Documentation/arch/")
    Cc: Alexandre TORGUE <[email protected]>
    Cc: Yanteng Si <[email protected]>
    Cc: Jonathan Corbet <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: gpio: xilinx: Fix node address in gpio [+ + +]
Author: Michal Simek <[email protected]>
Date:   Fri Jan 12 12:32:58 2024 +0100

    dt-bindings: gpio: xilinx: Fix node address in gpio
    
    [ Upstream commit 314c020c4ed3de72b15603eb6892250bc4b51702 ]
    
    Node address doesn't match reg property which is not correct.
    
    Fixes: ba96b2e7974b ("dt-bindings: gpio: gpio-xilinx: Convert Xilinx axi gpio binding to YAML")
    Signed-off-by: Michal Simek <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names [+ + +]
Author: Moudy Ho <[email protected]>
Date:   Tue Oct 31 16:33:42 2023 +0800

    dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
    
    [ Upstream commit f5f185bf7c42f6ca885202fefc40fc871d08a722 ]
    
    The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
    In addition, fix improper space indent in example.
    
    Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek MDP3 components")
    Signed-off-by: Moudy Ho <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: fix path to header [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Dec 18 14:05:53 2023 +0100

    dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: fix path to header
    
    commit 21a1d02579ae75fd45555b84d20ba55632a14a19 upstream.
    
    Fix the path to bindings header in description.
    
    Fixes: e1c4c5436b4a ("dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp binding")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dt-bindings: timer: thead,c900-aclint-mtimer: separate mtime and mtimecmp regs [+ + +]
Author: Inochi Amaoto <[email protected]>
Date:   Mon Dec 4 17:51:08 2023 +0800

    dt-bindings: timer: thead,c900-aclint-mtimer: separate mtime and mtimecmp regs
    
    commit b91cf01cf3e63a627b3b65f4284dcf9a4deb80f9 upstream.
    
    The timer registers of aclint don't follow the clint layout and can
    be mapped on any different offset. As sg2042 uses separated timer
    and mswi for its clint, it should follow the aclint spec and have
    separated registers.
    
    The previous patch introduced a new type of T-HEAD aclint timer which
    has clint timer layout. Although it has the clint timer layout, it
    should follow the aclint spec and uses the separated mtime and mtimecmp
    regs. So a ABI change is needed to make the timer fit the aclint spec.
    
    To make T-HEAD aclint timer more closer to the aclint spec, use
    regs-names to represent the mtimecmp register, which can avoid hack
    for unsupport mtime register of T-HEAD aclint timer.
    
    Also, as T-HEAD aclint only supports mtimecmp, it is unnecessary to
    implement the whole aclint spec. To make this binding T-HEAD specific,
    only add reg-name for existed register. For details, see the discussion
    in the last link.
    
    Signed-off-by: Inochi Amaoto <[email protected]>
    Fixes: 4734449f7311 ("dt-bindings: timer: Add Sophgo sg2042 CLINT timer")
    Link: https://lists.infradead.org/pipermail/opensbi/2023-October/005693.html
    Link: https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
    Link: https://lore.kernel.org/all/IA1PR20MB4953F9D77FFC76A9D236922DBBB6A@IA1PR20MB4953.namprd20.prod.outlook.com/
    Acked-by: Guo Ren <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/IA1PR20MB49531ED1BCC00D6B265C2D10BB86A@IA1PR20MB4953.namprd20.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
EDAC/thunderx: Fix possible out-of-bounds string access [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Nov 22 23:19:53 2023 +0100

    EDAC/thunderx: Fix possible out-of-bounds string access
    
    [ Upstream commit 475c58e1a471e9b873e3e39958c64a2d278275c8 ]
    
    Enabling -Wstringop-overflow globally exposes a warning for a common bug
    in the usage of strncat():
    
      drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
      drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
       1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);
            |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ...
       1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
       ...
       1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
    
       ...
    
    Apparently the author of this driver expected strncat() to behave the
    way that strlcat() does, which uses the size of the destination buffer
    as its third argument rather than the length of the source buffer. The
    result is that there is no check on the size of the allocated buffer.
    
    Change it to strlcat().
    
      [ bp: Trim compiler output, fixup commit message. ]
    
    Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
efivarfs: force RO when remounting if SetVariable is not supported [+ + +]
Author: Ilias Apalodimas <[email protected]>
Date:   Tue Nov 7 14:40:56 2023 +0900

    efivarfs: force RO when remounting if SetVariable is not supported
    
    [ Upstream commit 0e8d2444168dd519fea501599d150e62718ed2fe ]
    
    If SetVariable at runtime is not supported by the firmware we never assign
    a callback for that function. At the same time mount the efivarfs as
    RO so no one can call that.  However, we never check the permission flags
    when someone remounts the filesystem as RW. As a result this leads to a
    crash looking like this:
    
    $ mount -o remount,rw /sys/firmware/efi/efivars
    $ efi-updatevar -f PK.auth PK
    
    [  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    [  303.280482] Mem abort info:
    [  303.280854]   ESR = 0x0000000086000004
    [  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
    [  303.282016]   SET = 0, FnV = 0
    [  303.282414]   EA = 0, S1PTW = 0
    [  303.282821]   FSC = 0x04: level 0 translation fault
    [  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
    [  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
    [  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
    [  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
    [  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
    [  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
    [  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  303.292123] pc : 0x0
    [  303.292443] lr : efivar_set_variable_locked+0x74/0xec
    [  303.293156] sp : ffff800008673c10
    [  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
    [  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
    [  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
    [  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
    [  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
    [  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
    [  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
    [  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
    [  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
    [  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
    [  303.303341] Call trace:
    [  303.303679]  0x0
    [  303.303938]  efivar_entry_set_get_size+0x98/0x16c
    [  303.304585]  efivarfs_file_write+0xd0/0x1a4
    [  303.305148]  vfs_write+0xc4/0x2e4
    [  303.305601]  ksys_write+0x70/0x104
    [  303.306073]  __arm64_sys_write+0x1c/0x28
    [  303.306622]  invoke_syscall+0x48/0x114
    [  303.307156]  el0_svc_common.constprop.0+0x44/0xec
    [  303.307803]  do_el0_svc+0x38/0x98
    [  303.308268]  el0_svc+0x2c/0x84
    [  303.308702]  el0t_64_sync_handler+0xf4/0x120
    [  303.309293]  el0t_64_sync+0x190/0x194
    [  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
    [  303.310612] ---[ end trace 0000000000000000 ]---
    
    Fix this by adding a .reconfigure() function to the fs operations which
    we can use to check the requested flags and deny anything that's not RO
    if the firmware doesn't implement SetVariable at runtime.
    
    Fixes: f88814cc2578 ("efi/efivars: Expose RT service availability via efivars abstraction")
    Signed-off-by: Ilias Apalodimas <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

efivarfs: Free s_fs_info on unmount [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Fri Dec 8 17:39:28 2023 +0100

    efivarfs: Free s_fs_info on unmount
    
    [ Upstream commit 547713d502f7b4b8efccd409cff84d731a23853b ]
    
    Now that we allocate a s_fs_info struct on fs context creation, we
    should ensure that we free it again when the superblock goes away.
    
    Fixes: 5329aa5101f7 ("efivarfs: Add uid/gid mount options")
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: fix inconsistent per-file compression format [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Sat Jan 13 23:06:02 2024 +0800

    erofs: fix inconsistent per-file compression format
    
    [ Upstream commit 118a8cf504d7dfa519562d000f423ee3ca75d2c4 ]
    
    EROFS can select compression algorithms on a per-file basis, and each
    per-file compression algorithm needs to be marked in the on-disk
    superblock for initialization.
    
    However, syzkaller can generate inconsistent crafted images that use
    an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA
    algorithmtype even it's not set in `sbi->available_compr_algs`.  This
    can lead to an unexpected "BUG: kernel NULL pointer dereference" if
    the corresponding decompressor isn't built-in.
    
    Fix this by checking against `sbi->available_compr_algs` for each
    m_algorithmformat request.  Incorrect !erofs_sb_has_compr_cfgs preset
    bitmap is now fixed together since it was harmless previously.
    
    Reported-by: <[email protected]>
    Fixes: 8f89926290c4 ("erofs: get compression algorithms directly on mapping")
    Fixes: 622ceaddb764 ("erofs: lzma compression support")
    Reviewed-by: Yue Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

erofs: fix memory leak on short-lived bounced pages [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Nov 29 02:04:31 2023 +0800

    erofs: fix memory leak on short-lived bounced pages
    
    [ Upstream commit 93d6fda7f926451a0fa1121b9558d75ca47e861e ]
    
    Both MicroLZMA and DEFLATE algorithms can use short-lived pages on
    demand for the overlapped inplace I/O decompression.
    
    However, those short-lived pages are actually added to
    `be->compressed_pages`.  Thus, it should be checked instead of
    `pcl->compressed_bvecs`.
    
    The LZ4 algorithm doesn't work like this, so it won't be impacted.
    
    Fixes: 67139e36d970 ("erofs: introduce `z_erofs_parse_in_bvecs'")
    Reviewed-by: Yue Hu <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ethtool: netlink: Add missing ethnl_ops_begin/complete [+ + +]
Author: Ludvig Pärsson <[email protected]>
Date:   Wed Jan 17 13:03:14 2024 +0100

    ethtool: netlink: Add missing ethnl_ops_begin/complete
    
    [ Upstream commit f1172f3ee3a98754d95b968968920a7d03fdebcc ]
    
    Accessing an ethernet device that is powered off or clock gated might
    cause the CPU to hang. Add ethnl_ops_begin/complete in
    ethnl_set_features() to protect against this.
    
    Fixes: 0980bfcd6954 ("ethtool: set netdev features with FEATURES_SET request")
    Signed-off-by: Ludvig Pärsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: fix to avoid dirent corruption [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Nov 28 17:25:16 2023 +0800

    f2fs: fix to avoid dirent corruption
    
    [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ]
    
    As Al reported in link[1]:
    
    f2fs_rename()
    ...
            if (old_dir != new_dir && !whiteout)
                    f2fs_set_link(old_inode, old_dir_entry,
                                            old_dir_page, new_dir);
            else
                    f2fs_put_page(old_dir_page, 0);
    
    You want correct inumber in the ".." link.  And cross-directory
    rename does move the source to new parent, even if you'd been asked
    to leave a whiteout in the old place.
    
    [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/
    
    With below testcase, it may cause dirent corruption, due to it missed
    to call f2fs_set_link() to update ".." link to new directory.
    - mkdir -p dir/foo
    - renameat2 -w dir/foo bar
    
    [ASSERT] (__chk_dots_dentries:1421)  --> Bad inode number[0x4] for '..', parent parent ino is [0x3]
    [FSCK] other corrupted bugs                           [Fail]
    
    Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT")
    Cc: Jan Kara <[email protected]>
    Reported-by: Al Viro <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check compress file in f2fs_move_file_range() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 19:35:44 2023 +0800

    f2fs: fix to check compress file in f2fs_move_file_range()
    
    [ Upstream commit fb9b65340c818875ea86464faf3c744bdce0055c ]
    
    f2fs_move_file_range() doesn't support migrating compressed cluster
    data, let's add the missing check condition and return -EOPNOTSUPP
    for the case until we support it.
    
    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: fix to check return value of f2fs_recover_xattr_data [+ + +]
Author: Zhiguo Niu <[email protected]>
Date:   Tue Dec 12 10:15:27 2023 +0800

    f2fs: fix to check return value of f2fs_recover_xattr_data
    
    [ Upstream commit 86d7d57a3f096c8349b32a0cd5f6f314e4416a6d ]
    
    Should check return value of f2fs_recover_xattr_data in
    __f2fs_setxattr rather than doing invalid retry if error happen.
    
    Also just do set_page_dirty in f2fs_recover_xattr_data when
    page is changed really.
    
    Fixes: 50a472bbc79f ("f2fs: do not return EFSCORRUPTED, but try to run online repair")
    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 to update iostat correctly in f2fs_filemap_fault() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 19:35:47 2023 +0800

    f2fs: fix to update iostat correctly in f2fs_filemap_fault()
    
    [ Upstream commit bb34cc6ca87ff78f9fb5913d7619dc1389554da6 ]
    
    In f2fs_filemap_fault(), it fixes to update iostat info only if
    VM_FAULT_LOCKED is tagged in return value of filemap_fault().
    
    Fixes: 8b83ac81f428 ("f2fs: support read iostat")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to wait on block writeback for post_read case [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 19:35:43 2023 +0800

    f2fs: fix to wait on block writeback for post_read case
    
    [ Upstream commit 55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00 ]
    
    If inode is compressed, but not encrypted, it missed to call
    f2fs_wait_on_block_writeback() to wait for GCed page writeback
    in IPU write path.
    
    Thread A                                GC-Thread
                                            - f2fs_gc
                                             - do_garbage_collect
                                              - gc_data_segment
                                               - move_data_block
                                                - f2fs_submit_page_write
                                                 migrate normal cluster's block via
                                                 meta_inode's page cache
    - f2fs_write_single_data_page
     - f2fs_do_write_data_page
      - f2fs_inplace_write_data
       - f2fs_submit_page_bio
    
    IRQ
    - f2fs_read_end_io
                                            IRQ
                                            old data overrides new data due to
                                            out-of-order GC and common IO.
                                            - f2fs_read_end_io
    
    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: Restrict max filesize for 16K f2fs [+ + +]
Author: Daniel Rosenberg <[email protected]>
Date:   Mon Dec 4 18:38:01 2023 -0800

    f2fs: Restrict max filesize for 16K f2fs
    
    [ Upstream commit a6a010f5def544af3efcfe21683905a712b60536 ]
    
    Blocks are tracked by u32, so the max permitted filesize is
    (U32_MAX + 1) * BLOCK_SIZE. Additionally, in order to support crypto
    data unit sizes of 4K with a 16K block with IV_INO_LBLK_{32,64}, we must
    further restrict max filesize to (U32_MAX + 1) * 4096. This does not
    affect 4K blocksize f2fs as the natural limit for files are well below
    that.
    
    Fixes: d7e9a9037de2 ("f2fs: Support Block Size == Page Size")
    Signed-off-by: Daniel Rosenberg <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev/acornfb: Fix name of fb_ops initializer macro [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Nov 27 14:15:30 2023 +0100

    fbdev/acornfb: Fix name of fb_ops initializer macro
    
    commit b48807788e7a2bd93044fe84cfe8ff64b85ec15e upstream.
    
    Fix build by using the correct name for the initializer macro
    for struct fb_ops.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: 9037afde8b9d ("fbdev/acornfb: Use fbdev I/O helpers")
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: <[email protected]> # v6.6+
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fbdev/sm712fb: Use correct initializer macros for struct fb_ops [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Nov 27 14:15:31 2023 +0100

    fbdev/sm712fb: Use correct initializer macros for struct fb_ops
    
    [ Upstream commit 12d55c013a09a2d490f004a324c20800e4ff35ec ]
    
    Only initialize mmap and draw helpers with macros; leave read/write
    callbacks to driver implementations. Fixes the following warnings:
    
      CC [M]  drivers/video/fbdev/sm712fb.o
      sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init]
      1355 |         .fb_fillrect  = cfb_fillrect,
           |                         ^~~~~~~~~~~~
      sm712fb.c:1355:25: note: (near initialization for 'smtcfb_ops.fb_fillrect')
      sm712fb.c:1356:25: warning: initialized field overwritten [-Woverride-init]
      1356 |         .fb_imageblit = cfb_imageblit,
           |                         ^~~~~~~~~~~~~
      sm712fb.c:1356:25: note: (near initialization for 'smtcfb_ops.fb_imageblit')
      sm712fb.c:1357:25: warning: initialized field overwritten [-Woverride-init]
      1357 |         .fb_copyarea  = cfb_copyarea,
           |                         ^~~~~~~~~~~~
      sm712fb.c:1357:25: note: (near initialization for 'smtcfb_ops.fb_copyarea')
      sm712fb.c:1358:25: warning: initialized field overwritten [-Woverride-init]
      1358 |         .fb_read      = smtcfb_read,
           |                         ^~~~~~~~~~~
      sm712fb.c:1358:25: note: (near initialization for 'smtcfb_ops.fb_read')
      sm712fb.c:1359:25: warning: initialized field overwritten [-Woverride-init]
      1359 |         .fb_write     = smtcfb_write,
           |                         ^~~~~~~~~~~~
      sm712fb.c:1359:25: note: (near initialization for 'smtcfb_ops.fb_write')
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: 586132cf1d38 ("fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory helpers")
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: Sudip Mukherjee <[email protected]>
    Cc: Teddy Wang <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: [email protected]
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: flush deferred IO before closing [+ + +]
Author: Nam Cao <[email protected]>
Date:   Mon Dec 18 10:57:31 2023 +0100

    fbdev: flush deferred IO before closing
    
    commit 33cd6ea9c0673517cdb06ad5c915c6f22e9615fc upstream.
    
    When framebuffer gets closed, the queued deferred IO gets cancelled. This
    can cause some last display data to vanish. This is problematic for users
    who send a still image to the framebuffer, then close the file: the image
    may never appear.
    
    To ensure none of display data get lost, flush the queued deferred IO
    first before closing.
    
    Another possible solution is to delete the cancel_delayed_work_sync()
    instead. The difference is that the display may appear some time after
    closing. However, the clearing of page mapping after this needs to be
    removed too, because the page mapping is used by the deferred work. It is
    not completely obvious whether it is okay to not clear the page mapping.
    For a patch intended for stable trees, go with the simple and obvious
    solution.
    
    Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support")
    Cc: [email protected]
    Signed-off-by: Nam Cao <[email protected]>
    Reviewed-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fbdev: flush deferred work in fb_deferred_io_fsync() [+ + +]
Author: Nam Cao <[email protected]>
Date:   Mon Dec 18 10:57:30 2023 +0100

    fbdev: flush deferred work in fb_deferred_io_fsync()
    
    commit 15e4c1f462279b4e128f27de48133e0debe9e0df upstream.
    
    The driver's fsync() is supposed to flush any pending operation to
    hardware. It is implemented in this driver by cancelling the queued
    deferred IO first, then schedule it for "immediate execution" by calling
    schedule_delayed_work() again with delay=0. However, setting delay=0
    only means the work is scheduled immediately, it does not mean the work
    is executed immediately. There is no guarantee that the work is finished
    after schedule_delayed_work() returns. After this driver's fsync()
    returns, there can still be pending work. Furthermore, if close() is
    called by users immediately after fsync(), the pending work gets
    cancelled and fsync() may do nothing.
    
    To ensure that the deferred IO completes, use flush_delayed_work()
    instead. Write operations to this driver either write to the device
    directly, or invoke schedule_delayed_work(); so by flushing the
    workqueue, it can be guaranteed that all previous writes make it to the
    device.
    
    Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.")
    Cc: [email protected]
    Signed-off-by: Nam Cao <[email protected]>
    Reviewed-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fbdev: imxfb: fix left margin setting [+ + +]
Author: Dario Binacchi <[email protected]>
Date:   Sat Nov 11 11:41:50 2023 +0100

    fbdev: imxfb: fix left margin setting
    
    [ Upstream commit 5758844105f7dd9a0a04990cd92499a1a593dd36 ]
    
    The previous setting did not take into account the CSTN mode.
    For the H_WAIT_2 bitfield (bits 0-7) of the LCDC Horizontal Configuration
    Register (LCDCR), the IMX25RM manual states that:
    
    In TFT mode, it specifies the number of SCLK periods between the end of
    HSYNC and the beginning of OE signal, and the total delay time equals
    (H_WAIT_2 + 3) of SCLK periods.
    In CSTN mode, it specifies the number of SCLK periods between the end of
    HSYNC and the first display data in each line, and the total delay time
    equals (H_WAIT_2 + 2) of SCLK periods.
    
    The patch handles both cases.
    
    Fixes: 4e47382fbca9 ("fbdev: imxfb: warn about invalid left/right margin")
    Fixes: 7e8549bcee00 ("imxfb: Fix margin settings")
    Signed-off-by: Dario Binacchi <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: qcom: qseecom: fix memory leaks in error paths [+ + +]
Author: Bartosz Golaszewski <[email protected]>
Date:   Mon Nov 27 15:15:48 2023 +0100

    firmware: qcom: qseecom: fix memory leaks in error paths
    
    [ Upstream commit 6c57d7b593c4a4e60db65d5ce0fe1d9f79ccbe9b ]
    
    Fix instances of returning error codes directly instead of jumping to
    the relevant labels where memory allocated for the SCM calls would be
    freed.
    
    Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Reviewed-by: Maximilian Luz <[email protected]>
    Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Oct 30 11:12:26 2023 +0100

    firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create()
    
    [ Upstream commit 964946b88887089f447a9b6a28c39ee97dc76360 ]
    
    The ending NULL is not taken into account by strncat(), so switch to
    snprintf() to correctly build 'debug_name'.
    
    Using snprintf() also makes the code more readable.
    
    Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/7158db0a4d7b19855ddd542ec61b666973aad8dc.1698660720.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/pipe: Fix lockdep false-positive in watchqueue pipe_write() [+ + +]
Author: Jann Horn <[email protected]>
Date:   Fri Nov 24 16:08:22 2023 +0100

    fs/pipe: Fix lockdep false-positive in watchqueue pipe_write()
    
    [ Upstream commit 055ca83559912f2cfd91c9441427bac4caf3c74e ]
    
    When you try to splice between a normal pipe and a notification pipe,
    get_pipe_info(..., true) fails, so splice() falls back to treating the
    notification pipe like a normal pipe - so we end up in
    iter_file_splice_write(), which first locks the input pipe, then calls
    vfs_iter_write(), which locks the output pipe.
    
    Lockdep complains about that, because we're taking a pipe lock while
    already holding another pipe lock.
    
    I think this probably (?) can't actually lead to deadlocks, since you'd
    need another way to nest locking a normal pipe into locking a
    watch_queue pipe, but the lockdep annotations don't make that clear.
    
    Bail out earlier in pipe_write() for notification pipes, before taking
    the pipe lock.
    
    Reported-and-tested-by: <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=011e4ea1da6692cf881c
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Signed-off-by: Jann Horn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs: indicate request originates from old mount API [+ + +]
Author: Christian Brauner <[email protected]>
Date:   Wed Nov 22 12:17:37 2023 -0500

    fs: indicate request originates from old mount API
    
    [ Upstream commit f67d922edb4e95a4a56d07d5d40a76dd4f23a85b ]
    
    We already communicate to filesystems when a remount request comes from
    the old mount API as some filesystems choose to implement different
    behavior in the new mount API than the old mount API to e.g., take the
    chance to fix significant API bugs. Allow the same for regular mount
    requests.
    
    Fixes: b330966f79fb ("fuse: reject options on reconfigure via fsconfig(2)")
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Reviewed-by: Anand Jain <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Josef Bacik <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gfs2: fix kernel BUG in gfs2_quota_cleanup [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Sat Dec 2 17:25:49 2023 +0800

    gfs2: fix kernel BUG in gfs2_quota_cleanup
    
    [ Upstream commit 71733b4922007500ae259af9e96017080f5d36d9 ]
    
    [Syz report]
    kernel BUG at fs/gfs2/quota.c:1508!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 5060 Comm: syz-executor505 Not tainted 6.7.0-rc3-syzkaller-00134-g994d5c58e50e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:gfs2_quota_cleanup+0x6b5/0x6c0 fs/gfs2/quota.c:1508
    Code: fe e9 cf fd ff ff 44 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c 2d fe ff ff 4c 89 ef e8 b6 19 23 fe e9 20 fe ff ff e8 ec 11 c7 fd 90 <0f> 0b e8 84 9c 4f 07 0f 1f 40 00 66 0f 1f 00 55 41 57 41 56 41 54
    RSP: 0018:ffffc9000409f9e0 EFLAGS: 00010293
    RAX: ffffffff83c76854 RBX: 0000000000000002 RCX: ffff888026001dc0
    RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
    RBP: ffffc9000409fb00 R08: ffffffff83c762b0 R09: 1ffff1100fd38015
    R10: dffffc0000000000 R11: ffffed100fd38016 R12: dffffc0000000000
    R13: ffff88807e9c0828 R14: ffff888014693580 R15: ffff88807e9c0000
    FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f16d1bd70f8 CR3: 0000000027199000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     gfs2_put_super+0x2e1/0x940 fs/gfs2/super.c:611
     generic_shutdown_super+0x13a/0x2c0 fs/super.c:696
     kill_block_super+0x44/0x90 fs/super.c:1667
     deactivate_locked_super+0xc1/0x130 fs/super.c:484
     cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256
     task_work_run+0x24a/0x300 kernel/task_work.c:180
     exit_task_work include/linux/task_work.h:38 [inline]
     do_exit+0xa34/0x2750 kernel/exit.c:871
     do_group_exit+0x206/0x2c0 kernel/exit.c:1021
     __do_sys_exit_group kernel/exit.c:1032 [inline]
     __se_sys_exit_group kernel/exit.c:1030 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    ...
    
    [pid  5060] fsconfig(4, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0) = 0
    [pid  5060] exit_group(1)               = ?
    ...
    
    [Analysis]
    When the task exits, it will execute cleanup_mnt() to recycle the mounted gfs2
    file system, but it performs a system call fsconfig(4, FSCONFIG_CMD_RECONFIGURE,
    NULL, NULL, 0) before executing the task exit operation.
    
    This will execute the following kernel path to complete the setting of
    SDF_JOURNAL_LIVE for sd_flags:
    
    SYSCALL_DEFINE5(fsconfig, ..)->
            vfs_fsconfig_locked()->
                    vfs_cmd_reconfigure()->
                            gfs2_reconfigure()->
                                    gfs2_make_fs_rw()->
                                            set_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags);
    
    [Fix]
    Add SDF_NORECOVERY check in gfs2_quota_cleanup() to avoid checking
    SDF_JOURNAL_LIVE on the path where gfs2 is being unmounted.
    
    Reported-and-tested-by: [email protected]
    Fixes: f66af88e3321 ("gfs2: Stop using gfs2_make_fs_ro for withdraw")
    Signed-off-by: Edward Adam Davis <[email protected]>
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump [+ + +]
Author: Osama Muhammad <[email protected]>
Date:   Mon Nov 6 21:21:29 2023 +0500

    gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
    
    [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ]
    
    Syzkaller has reported a NULL pointer dereference when accessing
    rgd->rd_rgl in gfs2_rgrp_dump().  This can happen when creating
    rgd->rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
    gfs2_rgrp_dump() to prevent that.
    
    Reported-and-tested-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d
    Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found")
    Signed-off-by: Osama Muhammad <[email protected]>
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpio: mlxbf3: add an error code check in mlxbf3_gpio_probe [+ + +]
Author: Su Hui <[email protected]>
Date:   Fri Jan 12 12:24:04 2024 +0800

    gpio: mlxbf3: add an error code check in mlxbf3_gpio_probe
    
    [ Upstream commit d460e9c2075164e9b1fa9c4c95f8c05517bd8752 ]
    
    Clang static checker warning: Value stored to 'ret' is never read.
    bgpio_init() returns error code if failed, it's better to add this
    check.
    
    Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support")
    Signed-off-by: Su Hui <[email protected]>
    [Bartosz: add the Fixes: tag]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpiolib: Fix scope-based gpio_device refcounting [+ + +]
Author: Lukas Wunner <[email protected]>
Date:   Mon Jan 15 16:05:26 2024 +0100

    gpiolib: Fix scope-based gpio_device refcounting
    
    [ Upstream commit 832b371097eb928d077c827b8f117bf5b99d35c0 ]
    
    Commit 9e4555d1e54a ("gpiolib: add support for scope-based management to
    gpio_device") sought to add scope-based gpio_device refcounting, but
    erroneously forgot a negation of IS_ERR_OR_NULL().
    
    As a result, gpio_device_put() is not called if the gpio_device pointer
    is valid (meaning the ref is leaked), but only called if the pointer is
    NULL or an ERR_PTR().
    
    While at it drop a superfluous trailing semicolon.
    
    Fixes: 9e4555d1e54a ("gpiolib: add support for scope-based management to gpio_device")
    Signed-off-by: Lukas Wunner <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpu/drm/radeon: fix two memleaks in radeon_vm_init [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Fri Dec 15 00:58:42 2023 +0800

    gpu/drm/radeon: fix two memleaks in radeon_vm_init
    
    [ Upstream commit c2709b2d6a537ca0fa0f1da36fdaf07e48ef447d ]
    
    When radeon_bo_create and radeon_vm_clear_bo fail, the vm->page_tables
    allocated before need to be freed. However, neither radeon_vm_init
    itself nor its caller have done such deallocation.
    
    Fixes: 6d2f2944e95e ("drm/radeon: use normal BOs for the page tables v4")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
greybus: gb-beagleplay: Remove use of pad bytes [+ + +]
Author: Ayush Singh <[email protected]>
Date:   Sun Dec 17 17:41:32 2023 +0530

    greybus: gb-beagleplay: Remove use of pad bytes
    
    [ Upstream commit 08b3485540d9e94ed8335f82e5fc491fc02f8423 ]
    
    Make gb-beagleplay greybus spec compliant by moving cport information to
    transport layer instead of using `header->pad` bytes.
    
    Greybus HDLC frame now has the following payload:
    1. le16 cport
    2. gb_operation_msg_hdr msg_header
    3. u8 *msg_payload
    
    Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver")
    Signed-off-by: Ayush Singh <[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]>

 
HID: sensor-hub: Enable hid core report processing for all devices [+ + +]
Author: Yauhen Kharuzhy <[email protected]>
Date:   Wed Dec 20 01:15:03 2023 +0200

    HID: sensor-hub: Enable hid core report processing for all devices
    
    commit 8e2f79f41a5d1b1a4a53ec524eb7609ca89f3c65 upstream.
    
    After the commit 666cf30a589a ("HID: sensor-hub: Allow multi-function
    sensor devices") hub devices are claimed by hidraw driver in hid_connect().
    This causes stoppping of processing HID reports by hid core due to
    optimization.
    
    In such case, the hid-sensor-custom driver cannot match a known custom
    sensor in hid_sensor_custom_get_known() because it try to check custom
    properties which weren't filled from the report because hid core didn't
    parsed it.
    
    As result, custom sensors like hinge angle sensor and LISS sensors
    don't work.
    
    Mark the sensor hub devices claimed by some driver to avoid hidraw-related
    optimizations.
    
    Fixes: 666cf30a589a ("HID: sensor-hub: Allow multi-function sensor devices")
    Cc: [email protected]
    Signed-off-by: Yauhen Kharuzhy <[email protected]>
    Tested-by: Daniel Thompson <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: Correct behavior when processing some confidence == false touches [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Tue Dec 19 13:33:43 2023 -0800

    HID: wacom: Correct behavior when processing some confidence == false touches
    
    commit 502296030ec6b0329e00f9fb15018e170cc63037 upstream.
    
    There appear to be a few different ways that Wacom devices can deal with
    confidence:
    
      1. If the device looses confidence in a touch, it will first clear
         the tipswitch flag in one report, and then clear the confidence
         flag in a second report. This behavior is used by e.g. DTH-2452.
    
      2. If the device looses confidence in a touch, it will clear both
         the tipswitch and confidence flags within the same report. This
         behavior is used by some AES devices.
    
      3. If the device looses confidence in a touch, it will clear *only*
         the confidence bit. The tipswitch bit will remain set so long as
         the touch is tracked. This behavior may be used in future devices.
    
    The driver does not currently handle situation 3 properly. Touches that
    loose confidence will remain "in prox" and essentially frozen in place
    until the tipswitch bit is finally cleared. Not only does this result
    in userspace seeing a stuck touch, but it also prevents pen arbitration
    from working properly (the pen won't send events until all touches are
    up, but we don't currently process events from non-confident touches).
    
    This commit centralizes the checking of the confidence bit in the
    wacom_wac_finger_slot() function and has 'prox' depend on it. In the
    case where situation 3 is encountered, the treat the touch as though
    it was removed, allowing both userspace and the pen arbitration to
    act normally.
    
    Signed-off-by: Tatsunosuke Tobita <[email protected]>
    Signed-off-by: Ping Cheng <[email protected]>
    Signed-off-by: Jason Gerecke <[email protected]>
    Fixes: 7fb0413baa7f ("HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts")
    Cc: [email protected]
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume [+ + +]
Author: Shameer Kolothum <[email protected]>
Date:   Mon Nov 20 09:14:06 2023 +0000

    hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume
    
    [ Upstream commit be12ad45e15b5ee0e2526a50266ba1d295d26a88 ]
    
    When the optional PRE_COPY support was added to speed up the device
    compatibility check, it failed to update the saving/resuming data
    pointers based on the fd offset. This results in migration data
    corruption and when the device gets started on the destination the
    following error is reported in some cases,
    
    [  478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received:
    [  478.913691] arm-smmu-v3 arm-smmu-v3.2.auto:  0x0000310200000010
    [  478.919603] arm-smmu-v3 arm-smmu-v3.2.auto:  0x000002088000007f
    [  478.925515] arm-smmu-v3 arm-smmu-v3.2.auto:  0x0000000000000000
    [  478.931425] arm-smmu-v3 arm-smmu-v3.2.auto:  0x0000000000000000
    [  478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found
    [  478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found
    [  478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2
    
    Fixes: d9a871e4a143 ("hisi_acc_vfio_pci: Introduce support for PRE_COPY state transitions")
    Signed-off-by: Shameer Kolothum <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwrng: stm32 - add missing clk_disable_unprepare() in stm32_rng_init() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Fri Dec 1 16:20:48 2023 +0800

    hwrng: stm32 - add missing clk_disable_unprepare() in stm32_rng_init()
    
    [ Upstream commit 429fec81d12266e6402868672de8c68bf4d8db13 ]
    
    Add clk_disable_unprepare() in the error path in stm32_rng_init().
    
    Fixes: 6b85a7e141cb ("hwrng: stm32 - implement STM32MP13x support")
    Signed-off-by: Yang Yingliang <[email protected]>
    Reviewed-by: Gatien Chevallier <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: s3c24xx: fix read transfers in polling mode [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Wed Nov 8 17:43:52 2023 +0100

    i2c: s3c24xx: fix read transfers in polling mode
    
    [ Upstream commit 0d9cf23ed55d7ba3ab26d617a3ae507863674c8f ]
    
    To properly handle read transfers in polling mode, no waiting for the ACK
    state is needed as it will never come. Just wait a bit to ensure start
    state is on the bus and continue processing next bytes.
    
    Fixes: 117053f77a5a ("i2c: s3c2410: Add polling mode support")
    Signed-off-by: Marek Szyprowski <[email protected]>
    Reviewed-by: Chanho Park <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: s3c24xx: fix transferring more than one message in polling mode [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Wed Nov 8 17:43:53 2023 +0100

    i2c: s3c24xx: fix transferring more than one message in polling mode
    
    [ Upstream commit 990489e1042c6c5d6bccf56deca68f8dbeed8180 ]
    
    To properly handle ACK on the bus when transferring more than one
    message in polling mode, move the polling handling loop from
    s3c24xx_i2c_message_start() to s3c24xx_i2c_doxfer(). This way
    i2c_s3c_irq_nextbyte() is always executed till the end, properly
    acknowledging the IRQ bits and no recursive calls to
    i2c_s3c_irq_nextbyte() are made.
    
    While touching this, also fix finishing transfers in polling mode by
    using common code path and always waiting for the bus to become idle
    and disabled.
    
    Fixes: 117053f77a5a ("i2c: s3c2410: Add polling mode support")
    Signed-off-by: Marek Szyprowski <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
IB/iser: Prevent invalidating wrong MR [+ + +]
Author: Sergey Gorenko <[email protected]>
Date:   Tue Dec 19 09:23:11 2023 +0200

    IB/iser: Prevent invalidating wrong MR
    
    [ Upstream commit 2f1888281e67205bd80d3e8f54dbd519a9653f26 ]
    
    The iser_reg_resources structure has two pointers to MR but only one
    mr_valid field. The implementation assumes that we use only *sig_mr when
    pi_enable is true. Otherwise, we use only *mr. However, it is only
    sometimes correct. Read commands without protection information occur even
    when pi_enble is true. For example, the following SCSI commands have a
    Data-In buffer but never have protection information: READ CAPACITY (16),
    INQUIRY, MODE SENSE(6), MAINTENANCE IN. So, we use
    *sig_mr for some SCSI commands and *mr for the other SCSI commands.
    
    In most cases, it works fine because the remote invalidation is applied.
    However, there are two cases when the remote invalidation is not
    applicable.
     1. Small write commands when all data is sent as an immediate.
     2. The target does not support the remote invalidation feature.
    
    The lazy invalidation is used if the remote invalidation is impossible.
    Since, at the lazy invalidation, we always invalidate the MR we want to
    use, the wrong MR may be invalidated.
    
    To fix the issue, we need a field per MR that indicates the MR needs
    invalidation. Since the ib_mr structure already has such a field, let's
    use ib_mr.need_inval instead of iser_reg_resources.mr_valid.
    
    Fixes: b76a439982f8 ("IB/iser: Use IB_WR_REG_MR_INTEGRITY for PI handover")
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Max Gurtovoy <[email protected]>
    Signed-off-by: Sergey Gorenko <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: Fix some null pointer dereference issues in ice_ptp.c [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Tue Dec 12 10:40:15 2023 +0800

    ice: Fix some null pointer dereference issues in ice_ptp.c
    
    [ Upstream commit 3027e7b15b02d2d37e3f82d6b8404f6d37e3b8cf ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: d938a8cca88a ("ice: Auxbus devices & driver for E822 TS")
    Cc: Kunwu Chan <[email protected]>
    Suggested-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Kunwu Chan <[email protected]>
    Reviewed-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]>

 
iio: adc: ad7091r: Pass iio_dev to event handler [+ + +]
Author: Marcelo Schmitt <[email protected]>
Date:   Sat Dec 16 14:46:11 2023 -0300

    iio: adc: ad7091r: Pass iio_dev to event handler
    
    commit a25a7df518fc71b1ba981d691e9322e645d2689c upstream.
    
    Previous version of ad7091r event handler received the ADC state pointer
    and retrieved the iio device from driver data field with dev_get_drvdata().
    However, no driver data have ever been set, which led to null pointer
    dereference when running the event handler.
    
    Pass the iio device to the event handler and retrieve the ADC state struct
    from it so we avoid the null pointer dereference and save the driver from
    filling the driver data field.
    
    Fixes: ca69300173b6 ("iio: adc: Add support for AD7091R5 ADC")
    Signed-off-by: Marcelo Schmitt <[email protected]>
    Link: https://lore.kernel.org/r/5024b764107463de9578d5b3b0a3d5678e307b1a.1702746240.git.marcelo.schmitt1@gmail.com
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: adc: ad9467: add mutex to struct ad9467_state [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Thu Dec 7 13:39:26 2023 +0100

    iio: adc: ad9467: add mutex to struct ad9467_state
    
    [ Upstream commit 737720197be445bb9eec2986101e4a386e019337 ]
    
    When calling ad9467_set_scale(), multiple calls to ad9467_spi_write()
    are done which means we need to properly protect the whole operation so
    we are sure we will be in a sane state if two concurrent calls occur.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Signed-off-by: Nuno Sa <[email protected]>
    Reviewed-by: David Lechner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad9467: don't ignore error codes [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Thu Dec 7 13:39:25 2023 +0100

    iio: adc: ad9467: don't ignore error codes
    
    [ Upstream commit e072e149cfb827e0ab4cafb0547e9658e35393cd ]
    
    Make sure functions that return errors are not ignored.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Reviewed-by: David Lechner <[email protected]>
    Signed-off-by: Nuno Sa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad9467: fix reset gpio handling [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Thu Dec 7 13:39:24 2023 +0100

    iio: adc: ad9467: fix reset gpio handling
    
    [ Upstream commit 76f028539cf360f750efd8cde560edda298e4c6b ]
    
    The reset gpio was being handled with inverted polarity. This means that
    as far as gpiolib is concerned we were actually leaving the pin asserted
    (in theory, this would mean reset). However, inverting the polarity in
    devicetree made things work. Fix it by doing it the proper way and how
    gpiolib expects it to be done.
    
    While at it, moved the handling to it's own function and dropped
    'reset_gpio' from the 'struct ad9467_state' as we only need it during
    probe. On top of that, refactored things so that we now request the gpio
    asserted (i.e in reset) and then de-assert it. Also note that we now use
    gpiod_set_value_cansleep() instead of gpiod_direction_output() as we
    already request the pin as output.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Reviewed-by: David Lechner <[email protected]>
    Signed-off-by: Nuno Sa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad9467: fix scale setting [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Thu Dec 7 13:39:27 2023 +0100

    iio: adc: ad9467: fix scale setting
    
    [ Upstream commit b73f08bb7fe5a0901646ca5ceaa1e7a2d5ee6293 ]
    
    When reading in_voltage_scale we can get something like:
    
    root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale
    0.038146
    
    However, when reading the available options:
    
    root@analog:/sys/bus/iio/devices/iio:device2# cat
    in_voltage_scale_available
    2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010
    
    which does not make sense. Moreover, when trying to set a new scale we
    get an error because there's no call to __ad9467_get_scale() to give us
    values as given when reading in_voltage_scale. Fix it by computing the
    available scales during probe and properly pass the list when
    .read_available() is called.
    
    While at it, change to use .read_available() from iio_info. Also note
    that to properly fix this, adi-axi-adc.c has to be changed accordingly.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Signed-off-by: Nuno Sa <[email protected]>
    Reviewed-by: David Lechner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: atkbd - use ab83 as id when skipping the getid command [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Jan 16 21:43:25 2024 +0100

    Input: atkbd - use ab83 as id when skipping the getid command
    
    commit 58f65f9db7e0de366a5a115c2e2c0703858bba69 upstream.
    
    Barnabás reported that the change to skip the getid command
    when the controller is in translated mode on laptops caused
    the Version field of his "AT Translated Set 2 keyboard"
    input device to change from ab83 to abba, breaking a custom
    hwdb entry for this keyboard.
    
    Use the standard ab83 id for keyboards when getid is skipped
    (rather then that getid fails) to avoid reporting a different
    Version to userspace then before skipping the getid.
    
    Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
    Reported-by: Barnabás PÅ‘cze <[email protected]>
    Closes: https://lore.kernel.org/linux-input/W1ydwoG2fYv85Z3C3yfDOJcVpilEvGge6UGa9kZh8zI2-qkHXp7WLnl2hSkFz63j-c7WupUWI5TLL6n7Lt8DjRuU-yJBwLYWrreb1hbnd6A=@protonmail.com/
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/rw: ensure io->bytes_done is always initialized [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Dec 21 08:49:18 2023 -0700

    io_uring/rw: ensure io->bytes_done is always initialized
    
    commit 0a535eddbe0dc1de4386046ab849f08aeb2f8faf upstream.
    
    If IOSQE_ASYNC is set and we fail importing an iovec for a readv or
    writev request, then we leave ->bytes_done uninitialized and hence the
    eventual failure CQE posted can potentially have a random res value
    rather than the expected -EINVAL.
    
    Setup ->bytes_done before potentially failing, so we have a consistent
    value if we fail the request early.
    
    Cc: [email protected]
    Reported-by: xingwei lee <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring: adjust defer tw counting [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Wed Jan 17 00:57:26 2024 +0000

    io_uring: adjust defer tw counting
    
    [ Upstream commit dc12d1799ce710fd90abbe0ced71e7e1ae0894fc ]
    
    The UINT_MAX work item counting bias in io_req_local_work_add() in case
    of !IOU_F_TWQ_LAZY_WAKE works in a sense that we will not miss a wake up,
    however it's still eerie. In particular, if we add a lazy work item
    after a non-lazy one, we'll increment it and get nr_tw==0, and
    subsequent adds may try to unnecessarily wake up the task, which is
    though not so likely to happen in real workloads.
    
    Half the bias, it's still large enough to be larger than any valid
    ->cq_wait_nr, which is limited by IORING_MAX_CQ_ENTRIES, but further
    have a good enough of space before it overflows.
    
    Fixes: 8751d15426a31 ("io_uring: reduce scheduling due to tw")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/108b971e958deaf7048342930c341ba90f75d806.1705438669.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring: don't check iopoll if request completes [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Fri Dec 1 00:38:52 2023 +0000

    io_uring: don't check iopoll if request completes
    
    commit 9b43ef3d52532a0175ed6654618f7db61d390d2e upstream.
    
    IOPOLL request should never return IOU_OK, so the following iopoll
    queueing check in io_issue_sqe() after getting IOU_OK doesn't make any
    sense as would never turn true. Let's optimise on that and return a bit
    earlier. It's also much more resilient to potential bugs from
    mischieving iopoll implementations.
    
    Cc:  <[email protected]>
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/2f8690e2fa5213a2ff292fac29a7143c036cdd60.1701390926.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring: ensure local task_work is run on wait timeout [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Jan 4 12:21:08 2024 -0700

    io_uring: ensure local task_work is run on wait timeout
    
    commit 6ff1407e24e6fdfa4a16ba9ba551e3d253a26391 upstream.
    
    A previous commit added an earlier break condition here, which is fine if
    we're using non-local task_work as it'll be run on return to userspace.
    However, if DEFER_TASKRUN is used, then we could be leaving local
    task_work that is ready to process in the ctx list until next time that
    we enter the kernel to wait for events.
    
    Move the break condition to _after_ we have run task_work.
    
    Cc: [email protected]
    Fixes: 846072f16eed ("io_uring: mimimise io_cqring_wait_schedule")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu/arm-smmu-qcom: Add missing GMU entry to match table [+ + +]
Author: Rob Clark <[email protected]>
Date:   Sun Dec 10 10:06:53 2023 -0800

    iommu/arm-smmu-qcom: Add missing GMU entry to match table
    
    commit afc95681c3068956fed1241a1ff1612c066c75ac upstream.
    
    In some cases the firmware expects cbndx 1 to be assigned to the GMU,
    so we also want the default domain for the GMU to be an identy domain.
    This way it does not get a context bank assigned.  Without this, both
    of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
    allocating and configuring a context bank.  So GMU ends up attached to
    both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
    and surprises the firmware if the GPU later triggers a translation
    fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
    getting wedged and the GPU stuck without memory access.
    
    Cc: [email protected]
    Signed-off-by: Rob Clark <[email protected]>
    Tested-by: Johan Hovold <[email protected]>
    Reviewed-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu/dma: Trace bounce buffer usage when mapping buffers [+ + +]
Author: Isaac J. Manjarres <[email protected]>
Date:   Fri Dec 8 15:41:40 2023 -0800

    iommu/dma: Trace bounce buffer usage when mapping buffers
    
    commit a63c357b9fd56ad5fe64616f5b22835252c6a76a upstream.
    
    When commit 82612d66d51d ("iommu: Allow the dma-iommu api to
    use bounce buffers") was introduced, it did not add the logic
    for tracing the bounce buffer usage from iommu_dma_map_page().
    
    All of the users of swiotlb_tbl_map_single() trace their bounce
    buffer usage, except iommu_dma_map_page(). This makes it difficult
    to track SWIOTLB usage from that function. Thus, trace bounce buffer
    usage from iommu_dma_map_page().
    
    Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers")
    Cc: [email protected] # v5.15+
    Cc: Tom Murphy <[email protected]>
    Cc: Lu Baolu <[email protected]>
    Cc: Saravana Kannan <[email protected]>
    Signed-off-by: Isaac J. Manjarres <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu: Don't reserve 0-length IOVA region [+ + +]
Author: Ashish Mhetre <[email protected]>
Date:   Tue Dec 5 12:26:56 2023 +0530

    iommu: Don't reserve 0-length IOVA region
    
    [ Upstream commit bb57f6705960bebeb832142ce9abf43220c3eab1 ]
    
    When the bootloader/firmware doesn't setup the framebuffers, their
    address and size are 0 in "iommu-addresses" property. If IOVA region is
    reserved with 0 length, then it ends up corrupting the IOVA rbtree with
    an entry which has pfn_hi < pfn_lo.
    If we intend to use display driver in kernel without framebuffer then
    it's causing the display IOMMU mappings to fail as entire valid IOVA
    space is reserved when address and length are passed as 0.
    An ideal solution would be firmware removing the "iommu-addresses"
    property and corresponding "memory-region" if display is not present.
    But the kernel should be able to handle this by checking for size of
    IOVA region and skipping the IOVA reservation if size is 0. Also, add
    a warning if firmware is requesting 0-length IOVA region reservation.
    
    Fixes: a5bf3cfce8cb ("iommu: Implement of_iommu_get_resv_regions()")
    Signed-off-by: Ashish Mhetre <[email protected]>
    Acked-by: Robin Murphy <[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: Map reserved memory as cacheable if device is coherent [+ + +]
Author: Laurentiu Tudor <[email protected]>
Date:   Tue Sep 26 18:26:00 2023 +0300

    iommu: Map reserved memory as cacheable if device is coherent
    
    [ Upstream commit f1aad9df93f39267e890836a28d22511f23474e1 ]
    
    Check if the device is marked as DMA coherent in the DT and if so,
    map its reserved memory as cacheable in the IOMMU.
    This fixes the recently added IOMMU reserved memory support which
    uses IOMMU_RESV_DIRECT without properly building the PROT for the
    mapping.
    
    Fixes: a5bf3cfce8cb ("iommu: Implement of_iommu_get_resv_regions()")
    Signed-off-by: Laurentiu Tudor <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Acked-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jan 5 17:03:13 2024 +0000

    ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
    
    [ Upstream commit d375b98e0248980681e5e56b712026174d617198 ]
    
    syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
    
    Reading frag_off can only be done if we pulled enough bytes
    to skb->head. Currently we might access garbage.
    
    [1]
    BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
    ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
    ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
    ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
    __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]
    neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
    neigh_output include/net/neighbour.h:542 [inline]
    ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
    ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
    NF_HOOK_COND include/linux/netfilter.h:303 [inline]
    ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
    dst_output include/net/dst.h:451 [inline]
    ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
    ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
    ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
    rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
    rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
    inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
    ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
    __sys_sendmsg net/socket.c:2667 [inline]
    __do_sys_sendmsg net/socket.c:2676 [inline]
    __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 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+0x5c9/0x970 mm/slub.c:3517
    __do_kmalloc_node mm/slab_common.c:1006 [inline]
    __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
    kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
    pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
    __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
    pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
    pskb_may_pull include/linux/skbuff.h:2681 [inline]
    ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
    ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
    ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
    __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]
    neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
    neigh_output include/net/neighbour.h:542 [inline]
    ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
    ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
    NF_HOOK_COND include/linux/netfilter.h:303 [inline]
    ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
    dst_output include/net/dst.h:451 [inline]
    ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
    ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
    ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
    rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
    rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
    inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
    ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
    __sys_sendmsg net/socket.c:2667 [inline]
    __do_sys_sendmsg net/socket.c:2676 [inline]
    __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    CPU: 0 PID: 7345 Comm: syz-executor.3 Not tainted 6.7.0-rc8-syzkaller-00024-gac865f00af29 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipmr: support IP_PKTINFO on cache report IGMP msg [+ + +]
Author: Leone Fernando <[email protected]>
Date:   Wed Dec 13 17:19:35 2023 +0100

    ipmr: support IP_PKTINFO on cache report IGMP msg
    
    [ Upstream commit bb7403655b3c3eb245d0ee330047cd3e20b3c4af ]
    
    In order to support IP_PKTINFO on those packets, we need to call
    ipv4_pktinfo_prepare.
    
    When sending mrouted/pimd daemons a cache report IGMP msg, it is
    unnecessary to set dst on the newly created skb.
    It used to be necessary on older versions until
    commit d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference") which
    changed the way IP_PKTINFO struct is been retrieved.
    
    Changes from v1:
    1. Undo changes in ipv4_pktinfo_prepare function. use it directly
       and copy the control block.
    
    Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference")
    Signed-off-by: Leone Fernando <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jan 17 09:21:02 2024 -0800

    ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
    
    [ Upstream commit 2e7ef287f07c74985f1bf2858bedc62bd9ebf155 ]
    
    idev->mc_ifc_count can be written over without proper locking.
    
    Originally found by syzbot [1], fix this issue by encapsulating calls
    to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with
    mutex_lock() and mutex_unlock() accordingly as these functions
    should only be called with mc_lock per their declarations.
    
    [1]
    BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work
    
    write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:
     mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]
     ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725
     addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949
     addrconf_notify+0x310/0x980
     notifier_call_chain kernel/notifier.c:93 [inline]
     raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461
     __dev_notify_flags+0x205/0x3d0
     dev_change_flags+0xab/0xd0 net/core/dev.c:8685
     do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916
     rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]
     __rtnl_newlink net/core/rtnetlink.c:3717 [inline]
     rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754
     rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558
     netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545
     rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576
     netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
     netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368
     netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910
     ...
    
    write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:
     mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700
     worker_thread+0x525/0x730 kernel/workqueue.c:2781
     ...
    
    Fixes: 2d9a93b4902b ("mld: convert from timer to delayed work")
    Reported-by: [email protected]
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Acked-by: Taehee Yoo <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipvs: avoid stat macros calls from preemptible context [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Mon Jan 15 17:39:22 2024 +0300

    ipvs: avoid stat macros calls from preemptible context
    
    [ Upstream commit d6938c1c76c64f42363d0d1f051e1b4641c2ad40 ]
    
    Inside decrement_ttl() upon discovering that the packet ttl has exceeded,
    __IP_INC_STATS and __IP6_INC_STATS macros can be called from preemptible
    context having the following backtrace:
    
    check_preemption_disabled: 48 callbacks suppressed
    BUG: using __this_cpu_add() in preemptible [00000000] code: curl/1177
    caller is decrement_ttl+0x217/0x830
    CPU: 5 PID: 1177 Comm: curl Not tainted 6.7.0+ #34
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0xbd/0xe0
     check_preemption_disabled+0xd1/0xe0
     decrement_ttl+0x217/0x830
     __ip_vs_get_out_rt+0x4e0/0x1ef0
     ip_vs_nat_xmit+0x205/0xcd0
     ip_vs_in_hook+0x9b1/0x26a0
     nf_hook_slow+0xc2/0x210
     nf_hook+0x1fb/0x770
     __ip_local_out+0x33b/0x640
     ip_local_out+0x2a/0x490
     __ip_queue_xmit+0x990/0x1d10
     __tcp_transmit_skb+0x288b/0x3d10
     tcp_connect+0x3466/0x5180
     tcp_v4_connect+0x1535/0x1bb0
     __inet_stream_connect+0x40d/0x1040
     inet_stream_connect+0x57/0xa0
     __sys_connect_file+0x162/0x1a0
     __sys_connect+0x137/0x160
     __x64_sys_connect+0x72/0xb0
     do_syscall_64+0x6f/0x140
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    RIP: 0033:0x7fe6dbbc34e0
    
    Use the corresponding preemption-aware variants: IP_INC_STATS and
    IP6_INC_STATS.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 8d8e20e2d7bb ("ipvs: Decrement ttl")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Acked-by: Julian Anastasov <[email protected]>
    Acked-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kdb: Fix a potential buffer overflow in kdb_local() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Nov 25 13:05:04 2023 +0100

    kdb: Fix a potential buffer overflow in kdb_local()
    
    [ Upstream commit 4f41d30cd6dc865c3cbc1a852372321eba6d4e4c ]
    
    When appending "[defcmd]" to 'kdb_prompt_str', the size of the string
    already in the buffer should be taken into account.
    
    An option could be to switch from strncat() to strlcat() which does the
    correct test to avoid such an overflow.
    
    However, this actually looks as dead code, because 'defcmd_in_progress'
    can't be true here.
    See a more detailed explanation at [1].
    
    [1]: https://lore.kernel.org/all/CAD=FV=WSh7wKN7Yp-3wWiDgX4E3isQ8uh0LCzTmd1v9Cg9j+nQ@mail.gmail.com/
    
    Fixes: 5d5314d6795f ("kdb: core for kgdb back end (1 of 2)")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kernfs: convert kernfs_idr_lock to an irq safe raw spinlock [+ + +]
Author: Andrea Righi <[email protected]>
Date:   Fri Dec 29 08:49:16 2023 +0100

    kernfs: convert kernfs_idr_lock to an irq safe raw spinlock
    
    commit c312828c37a72fe2d033a961c47c227b0767e9f8 upstream.
    
    bpf_cgroup_from_id() is basically a wrapper to cgroup_get_from_id(),
    that is relying on kernfs to determine the right cgroup associated to
    the target id.
    
    As a kfunc, it has the potential to be attached to any function through
    BPF, particularly in contexts where certain locks are held.
    
    However, kernfs is not using an irq safe spinlock for kernfs_idr_lock,
    that means any kernfs function that is acquiring this lock can be
    interrupted and potentially hit bpf_cgroup_from_id() in the process,
    triggering a deadlock.
    
    For example, it is really easy to trigger a lockdep splat between
    kernfs_idr_lock and rq->_lock, attaching a small BPF program to
    __set_cpus_allowed_ptr_locked() that just calls bpf_cgroup_from_id():
    
     =====================================================
     WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
     6.7.0-rc7-virtme #5 Not tainted
     -----------------------------------------------------
     repro/131 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
     ffffffffb2dc4578 (kernfs_idr_lock){+.+.}-{2:2}, at: kernfs_find_and_get_node_by_id+0x1d/0x80
    
     and this task is already holding:
     ffff911cbecaf218 (&rq->__lock){-.-.}-{2:2}, at: task_rq_lock+0x50/0xc0
     which would create a new lock dependency:
      (&rq->__lock){-.-.}-{2:2} -> (kernfs_idr_lock){+.+.}-{2:2}
    
     but this new dependency connects a HARDIRQ-irq-safe lock:
      (&rq->__lock){-.-.}-{2:2}
    
     ... which became HARDIRQ-irq-safe at:
       lock_acquire+0xbf/0x2b0
       _raw_spin_lock_nested+0x2e/0x40
       scheduler_tick+0x5d/0x170
       update_process_times+0x9c/0xb0
       tick_periodic+0x27/0xe0
       tick_handle_periodic+0x24/0x70
       __sysvec_apic_timer_interrupt+0x64/0x1a0
       sysvec_apic_timer_interrupt+0x6f/0x80
       asm_sysvec_apic_timer_interrupt+0x1a/0x20
       memcpy+0xc/0x20
       arch_dup_task_struct+0x15/0x30
       copy_process+0x1ce/0x1eb0
       kernel_clone+0xac/0x390
       kernel_thread+0x6f/0xa0
       kthreadd+0x199/0x230
       ret_from_fork+0x31/0x50
       ret_from_fork_asm+0x1b/0x30
    
     to a HARDIRQ-irq-unsafe lock:
      (kernfs_idr_lock){+.+.}-{2:2}
    
     ... which became HARDIRQ-irq-unsafe at:
     ...
       lock_acquire+0xbf/0x2b0
       _raw_spin_lock+0x30/0x40
       __kernfs_new_node.isra.0+0x83/0x280
       kernfs_create_root+0xf6/0x1d0
       sysfs_init+0x1b/0x70
       mnt_init+0xd9/0x2a0
       vfs_caches_init+0xcf/0xe0
       start_kernel+0x58a/0x6a0
       x86_64_start_reservations+0x18/0x30
       x86_64_start_kernel+0xc5/0xe0
       secondary_startup_64_no_verify+0x178/0x17b
    
     other info that might help us debug this:
    
      Possible interrupt unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(kernfs_idr_lock);
                                    local_irq_disable();
                                    lock(&rq->__lock);
                                    lock(kernfs_idr_lock);
       <Interrupt>
         lock(&rq->__lock);
    
      *** DEADLOCK ***
    
    Prevent this deadlock condition converting kernfs_idr_lock to a raw irq
    safe spinlock.
    
    The performance impact of this change should be negligible and it also
    helps to prevent similar deadlock conditions with any other subsystems
    that may depend on kernfs.
    
    Fixes: 332ea1f697be ("bpf: Add bpf_cgroup_from_id() kfunc")
    Cc: stable <[email protected]>
    Signed-off-by: Andrea Righi <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
keys, dns: Fix size check of V1 server-list header [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Jan 10 21:11:40 2024 +0000

    keys, dns: Fix size check of V1 server-list header
    
    [ Upstream commit acc657692aed438e9931438f8c923b2b107aebf9 ]
    
    Fix the size check added to dns_resolver_preparse() for the V1 server-list
    header so that it doesn't give EINVAL if the size supplied is the same as
    the size of the header struct (which should be valid).
    
    This can be tested with:
    
            echo -n -e '\0\0\01\xff\0\0' | keyctl padd dns_resolver desc @p
    
    which will give "add_key: Invalid argument" without this fix.
    
    Fixes: 1997b3cb4217 ("keys, dns: Fix missing size check of V1 server-list header")
    Reported-by: Pengfei Xu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: David Howells <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KEYS: encrypted: Add check for strsep [+ + +]
Author: Chen Ni <[email protected]>
Date:   Wed Nov 8 07:36:27 2023 +0000

    KEYS: encrypted: Add check for strsep
    
    [ Upstream commit b4af096b5df5dd131ab796c79cedc7069d8f4882 ]
    
    Add check for strsep() in order to transfer the error.
    
    Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data")
    Signed-off-by: Chen Ni <[email protected]>
    Signed-off-by: Mimi Zohar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kselftest/alsa - conf: Stringify the printed errno in sysfs_get() [+ + +]
Author: Mirsad Todorovac <[email protected]>
Date:   Sun Jan 7 18:37:08 2024 +0100

    kselftest/alsa - conf: Stringify the printed errno in sysfs_get()
    
    [ Upstream commit fd38dd6abda589a8771e7872e4dea28c99c6a6ef ]
    
    GCC 13.2.0 reported the warning of the print format specifier:
    
    conf.c: In function ‘sysfs_get’:
    conf.c:181:72: warning: format ‘%s’ expects argument of type ‘char *’, \
                            but argument 3 has type ‘int’ [-Wformat=]
      181 |                 ksft_exit_fail_msg("sysfs: unable to read value '%s': %s\n",
          |                                                                       ~^
          |                                                                        |
          |                                                                        char *
          |                                                                       %d
    
    The fix passes strerror(errno) as it was intended, like in the sibling error
    exit message.
    
    Fixes: aba51cd0949ae ("selftests: alsa - add PCM test")
    Cc: Mark Brown <[email protected]>
    Cc: Jaroslav Kysela <[email protected]>
    Cc: Takashi Iwai <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Mirsad Todorovac <[email protected]>
    Acked-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kselftest/alsa - mixer-test: fix the number of parameters to ksft_exit_fail_msg() [+ + +]
Author: Mirsad Todorovac <[email protected]>
Date:   Sun Jan 7 18:37:02 2024 +0100

    kselftest/alsa - mixer-test: fix the number of parameters to ksft_exit_fail_msg()
    
    [ Upstream commit 8c51c13dc63d46e754c44215eabc0890a8bd9bfb ]
    
    Minor fix in the number of arguments to error reporting function in the
    test program as reported by GCC 13.2.0 warning.
    
    mixer-test.c: In function ‘find_controls’:
    mixer-test.c:169:44: warning: too many arguments for format [-Wformat-extra-args]
      169 |                         ksft_exit_fail_msg("snd_ctl_poll_descriptors() failed for %d\n",
          |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The number of arguments in call to ksft_exit_fail_msg() doesn't correspond
    to the format specifiers, so this is adjusted resembling the sibling calls
    to the error function.
    
    Fixes: b1446bda56456 ("kselftest: alsa: Check for event generation when we write to controls")
    Cc: Mark Brown <[email protected]>
    Cc: Jaroslav Kysela <[email protected]>
    Cc: Takashi Iwai <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Mirsad Todorovac <[email protected]>
    Acked-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kselftest/alsa - mixer-test: Fix the print format specifier warning [+ + +]
Author: Mirsad Todorovac <[email protected]>
Date:   Sun Jan 7 18:37:04 2024 +0100

    kselftest/alsa - mixer-test: Fix the print format specifier warning
    
    [ Upstream commit 3f47c1ebe5ca9c5883e596c7888dec4bec0176d8 ]
    
    The GCC 13.2.0 compiler issued the following warning:
    
    mixer-test.c: In function ‘ctl_value_index_valid’:
    mixer-test.c:322:79: warning: format ‘%lld’ expects argument of type ‘long long int’, \
                                  but argument 5 has type ‘long int’ [-Wformat=]
      322 |                         ksft_print_msg("%s.%d value %lld more than maximum %lld\n",
          |                                                                            ~~~^
          |                                                                               |
          |                                                                               long long int
          |                                                                            %ld
      323 |                                        ctl->name, index, int64_val,
      324 |                                        snd_ctl_elem_info_get_max(ctl->info));
          |                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |                                        |
          |                                        long int
    
    Fixing the format specifier as advised by the compiler suggestion removes the
    warning.
    
    Fixes: 3f48b137d88e7 ("kselftest: alsa: Factor out check that values meet constraints")
    Cc: Mark Brown <[email protected]>
    Cc: Jaroslav Kysela <[email protected]>
    Cc: Takashi Iwai <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Mirsad Todorovac <[email protected]>
    Acked-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: fix UAF issue in ksmbd_tcp_new_connection() [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sat Jan 13 15:30:07 2024 +0900

    ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
    
    commit 38d20c62903d669693a1869aa68c4dd5674e2544 upstream.
    
    The race is between the handling of a new TCP connection and
    its disconnection. It leads to UAF on `struct tcp_transport` in
    ksmbd_tcp_new_connection() function.
    
    Cc: [email protected]
    Reported-by: [email protected] # ZDI-CAN-22991
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: only v2 leases handle the directory [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Mon Jan 15 10:24:54 2024 +0900

    ksmbd: only v2 leases handle the directory
    
    commit 77bebd186442a7d703b796784db7495129cc3e70 upstream.
    
    When smb2 leases is disable, ksmbd can send oplock break notification
    and cause wait oplock break ack timeout. It may appear like hang when
    accessing a directory. This patch make only v2 leases handle the
    directory.
    
    Cc: [email protected]
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: validate mech token in session setup [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sat Jan 13 15:11:41 2024 +0900

    ksmbd: validate mech token in session setup
    
    commit 92e470163d96df8db6c4fa0f484e4a229edb903d upstream.
    
    If client send invalid mech token in session setup request, ksmbd
    validate and make the error if it is invalid.
    
    Cc: [email protected]
    Reported-by: [email protected] # ZDI-CAN-22890
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: validate the zero field of packet header [+ + +]
Author: Li Nan <[email protected]>
Date:   Fri Dec 8 14:56:47 2023 +0800

    ksmbd: validate the zero field of packet header
    
    [ Upstream commit 516b3eb8c8065f7465f87608d37a7ed08298c7a5 ]
    
    The SMB2 Protocol requires that "The first byte of the Direct TCP
    transport packet header MUST be zero (0x00)"[1]. Commit 1c1bcf2d3ea0
    ("ksmbd: validate smb request protocol id") removed the validation of
    this 1-byte zero. Add the validation back now.
    
    [1]: [MS-SMB2] - v20230227, page 30.
    https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-SMB2/%5bMS-SMB2%5d-230227.pdf
    
    Fixes: 1c1bcf2d3ea0 ("ksmbd: validate smb request protocol id")
    Signed-off-by: Li Nan <[email protected]>
    Acked-by: Tom Talpey <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kunit: debugfs: Fix unchecked dereference in debugfs_print_results() [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Mon Oct 30 10:47:58 2023 +0000

    kunit: debugfs: Fix unchecked dereference in debugfs_print_results()
    
    [ Upstream commit 34dfd5bb2e5507e69d9b6d6c90f546600c7a4977 ]
    
    Move the call to kunit_suite_has_succeeded() after the check that
    the kunit_suite pointer is valid.
    
    This was found by smatch:
    
     lib/kunit/debugfs.c:66 debugfs_print_results() warn: variable
     dereferenced before check 'suite' (see line 63)
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Fixes: 38289a26e1b8 ("kunit: fix debugfs code to use enum kunit_status, not bool")
    Reviewed-by: Rae Moar <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kunit: debugfs: Handle errors from alloc_string_stream() [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Mon Oct 30 10:47:32 2023 +0000

    kunit: debugfs: Handle errors from alloc_string_stream()
    
    [ Upstream commit 1557e89d3af51a4f1bd6870b3117bed651de5dbf ]
    
    In kunit_debugfs_create_suite() give up and skip creating the debugfs
    file if any of the alloc_string_stream() calls return an error or NULL.
    Only put a value in the log pointer of kunit_suite and kunit_test if it
    is a valid pointer to a log.
    
    This prevents the potential invalid dereference reported by smatch:
    
     lib/kunit/debugfs.c:115 kunit_debugfs_create_suite() error: 'suite->log'
            dereferencing possible ERR_PTR()
     lib/kunit/debugfs.c:119 kunit_debugfs_create_suite() error: 'test_case->log'
            dereferencing possible ERR_PTR()
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Fixes: 05e2006ce493 ("kunit: Use string_stream for test log")
    Reviewed-by: Rae Moar <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache [+ + +]
Author: Oliver Upton <[email protected]>
Date:   Thu Jan 4 18:32:32 2024 +0000

    KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
    
    commit ad362fe07fecf0aba839ff2cc59a3617bd42c33f upstream.
    
    There is a potential UAF scenario in the case of an LPI translation
    cache hit racing with an operation that invalidates the cache, such
    as a DISCARD ITS command. The root of the problem is that
    vgic_its_check_cache() does not elevate the refcount on the vgic_irq
    before dropping the lock that serializes refcount changes.
    
    Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
    and add the corresponding decrement after queueing the interrupt.
    
    Cc: [email protected]
    Signed-off-by: Oliver Upton <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: arm64: vgic-v4: Restore pending state on host userspace write [+ + +]
Author: Marc Zyngier <[email protected]>
Date:   Sun Dec 17 11:15:09 2023 +0000

    KVM: arm64: vgic-v4: Restore pending state on host userspace write
    
    commit 7b95382f965133ef61ce44aaabc518c16eb46909 upstream.
    
    When the VMM writes to ISPENDR0 to set the state pending state of
    an SGI, we fail to convey this to the HW if this SGI is already
    backed by a GICv4.1 vSGI.
    
    This is a bit of a corner case, as this would only occur if the
    vgic state is changed on an already running VM, but this can
    apparently happen across a guest reset driven by the VMM.
    
    Fix this by always writing out the pending_latch value to the
    HW, and reseting it to false.
    
    Reported-by: Kunkun Jiang <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Reviewed-by: Zenghui Yu <[email protected]>
    Cc: [email protected] # 5.10+
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: PPC: Book3S HV: Handle pending exceptions on guest entry with MSR_EE [+ + +]
Author: Nicholas Piggin <[email protected]>
Date:   Fri Dec 1 18:56:11 2023 +0530

    KVM: PPC: Book3S HV: Handle pending exceptions on guest entry with MSR_EE
    
    [ Upstream commit ecd10702baae5c16a91d139bde7eff84ce55daee ]
    
    Commit 026728dc5d41 ("KVM: PPC: Book3S HV P9: Inject pending xive
    interrupts at guest entry") changed guest entry so that if external
    interrupts are enabled, BOOK3S_IRQPRIO_EXTERNAL is not tested for. Test
    for this regardless of MSR_EE.
    
    For an L1 host, do not inject an interrupt, but always
    use LPCR_MER. If the L0 desires it can inject an interrupt.
    
    Fixes: 026728dc5d41 ("KVM: PPC: Book3S HV P9: Inject pending xive interrupts at guest entry")
    Signed-off-by: Nicholas Piggin <[email protected]>
    [jpn: use kvmpcc_get_msr(), write commit message]
    Signed-off-by: Jordan Niethe <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

KVM: x86/pmu: Move PMU reset logic to common x86 code [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Nov 3 16:05:36 2023 -0700

    KVM: x86/pmu: Move PMU reset logic to common x86 code
    
    commit cbb359d81a2695bb5e63ec9de06fcbef28518891 upstream.
    
    Move the common (or at least "ignored") aspects of resetting the vPMU to
    common x86 code, along with the stop/release helpers that are no used only
    by the common pmu.c.
    
    There is no need to manually handle fixed counters as all_valid_pmc_idx
    tracks both fixed and general purpose counters, and resetting the vPMU is
    far from a hot path, i.e. the extra bit of overhead to the PMC from the
    index is a non-issue.
    
    Zero fixed_ctr_ctrl in common code even though it's Intel specific.
    Ensuring it's zero doesn't harm AMD/SVM in any way, and stopping the fixed
    counters via all_valid_pmc_idx, but not clearing the associated control
    bits, would be odd/confusing.
    
    Make the .reset() hook optional as SVM no longer needs vendor specific
    handling.
    
    Cc: [email protected]
    Reviewed-by: Dapeng Mi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86/pmu: Reset the PMU, i.e. stop counters, before refreshing [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Nov 3 16:05:37 2023 -0700

    KVM: x86/pmu: Reset the PMU, i.e. stop counters, before refreshing
    
    commit 1647b52757d59131fe30cf73fa36fac834d4367f upstream.
    
    Stop all counters and release all perf events before refreshing the vPMU,
    i.e. before reconfiguring the vPMU to respond to changes in the vCPU
    model.
    
    Clear need_cleanup in kvm_pmu_reset() as well so that KVM doesn't
    prematurely stop counters, e.g. if KVM enters the guest and enables
    counters before the vCPU is scheduled out.
    
    Cc: [email protected]
    Reviewed-by: Dapeng Mi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
leds: aw200xx: Fix write to DIM parameter [+ + +]
Author: Martin Kurbanov <[email protected]>
Date:   Sat Nov 25 23:05:09 2023 +0300

    leds: aw200xx: Fix write to DIM parameter
    
    [ Upstream commit adfd4621b78d0c02da91335da2b9ad847cb7b39e ]
    
    If write only DIM value to the page 4, LED brightness will not be
    updated, as both DIM and FADE need to be written to the page 4.
    Therefore, write DIM to the page 1.
    
    Fixes: 36a87f371b7a ("leds: Add AW20xx driver")
    Signed-off-by: Martin Kurbanov <[email protected]>
    Signed-off-by: Dmitry Rokosov <[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: aw2013: Select missing dependency REGMAP_I2C [+ + +]
Author: Dang Huynh <[email protected]>
Date:   Fri Nov 3 18:42:03 2023 +0700

    leds: aw2013: Select missing dependency REGMAP_I2C
    
    [ Upstream commit 75469bb0537ad2ab0fc1fb6e534a79cfc03f3b3f ]
    
    The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
    be selected.
    
    Otherwise build process may fail with:
      ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe':
        leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c'
    
    Signed-off-by: Dang Huynh <[email protected]>
    Acked-by: Nikita Travkin <[email protected]>
    Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
libapi: Add missing linux/types.h header to get the __u64 type on io.h [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Thu Nov 30 14:11:45 2023 -0300

    libapi: Add missing linux/types.h header to get the __u64 type on io.h
    
    [ Upstream commit af76b2dec0984a079d8497bfa37d29a9b55932e1 ]
    
    There are functions using __u64, so we need to have the linux/types.h
    header otherwise we'll break when its not included before api/io.h.
    
    Fixes: e95770af4c4a280f ("tools api: Add a lightweight buffered reading api")
    Reviewed-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.7.2 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jan 25 15:45:31 2024 -0800

    Linux 6.7.2
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Luna Jernberg <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Luna Jernberg <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
LoongArch: BPF: Prevent out-of-bounds memory access [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Wed Jan 17 12:43:13 2024 +0800

    LoongArch: BPF: Prevent out-of-bounds memory access
    
    [ Upstream commit 36a87385e31c9343af9a4756598e704741250a67 ]
    
    The test_tag test triggers an unhandled page fault:
    
      # ./test_tag
      [  130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70
      [  130.640501] Oops[#3]:
      [  130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G      D    O       6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a
      [  130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
      [  130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40
      [  130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000
      [  130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000
      [  130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70
      [  130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0
      [  130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0
      [  130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000
      [  130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000
      [  130.641900]    ra: 9000000003139e70 build_body+0x1fcc/0x4988
      [  130.642007]   ERA: 9000000003137f7c build_body+0xd8/0x4988
      [  130.642112]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
      [  130.642261]  PRMD: 00000004 (PPLV0 +PIE -PWE)
      [  130.642353]  EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
      [  130.642458]  ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
      [  130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
      [  130.642658]  BADV: ffff80001b898004
      [  130.642719]  PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
      [  130.642815] Modules linked in: [last unloaded: bpf_testmod(O)]
      [  130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd)
      [  130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8
      [  130.643213]         0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0
      [  130.643378]         0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000
      [  130.643538]         0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000
      [  130.643685]         00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000
      [  130.643831]         ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000
      [  130.643983]         0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558
      [  130.644131]         0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000
      [  130.644276]         9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc
      [  130.644423]         ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0
      [  130.644572]         ...
      [  130.644629] Call Trace:
      [  130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988
      [  130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec
      [  130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0
      [  130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44
      [  130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588
      [  130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c
      [  130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94
      [  130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158
      [  130.645507]
      [  130.645539] Code: 380839f6  380831f9  28412bae <24000ca6> 004081ad  0014cb50  004083e8  02bff34c  58008e91
      [  130.645729]
      [  130.646418] ---[ end trace 0000000000000000 ]---
    
    On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at
    loading a BPF prog with 2039 instructions:
    
      prog = (struct bpf_prog *)ffff80001b894000
      insn = (struct bpf_insn *)(prog->insnsi)ffff80001b894048
      insn + 2039 = (struct bpf_insn *)ffff80001b898000 <- end of the page
    
    In the build_insn() function, we are trying to access next instruction
    unconditionally, i.e. `(insn + 1)->imm`. The address lies in the next
    page and can be not owned by the current process, thus an page fault is
    inevitable and then segfault.
    
    So, let's access next instruction only under `dst = imm64` context.
    
    With this fix, we have:
    
      # ./test_tag
      test_tag: OK (40945 tests)
    
    Fixes: bbfddb904df6f82 ("LoongArch: BPF: Avoid declare variables in switch-case")
    Tested-by: Tiezhu Yang <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

LoongArch: Fix and simplify fcsr initialization on execve() [+ + +]
Author: Xi Ruoyao <[email protected]>
Date:   Wed Jan 17 12:43:08 2024 +0800

    LoongArch: Fix and simplify fcsr initialization on execve()
    
    commit c2396651309eba291c15e32db8fbe44c738b5921 upstream.
    
    There has been a lingering bug in LoongArch Linux systems causing some
    GCC tests to intermittently fail (see Closes link).  I've made a minimal
    reproducer:
    
        zsh% cat measure.s
        .align 4
        .globl _start
        _start:
            movfcsr2gr  $a0, $fcsr0
            bstrpick.w  $a0, $a0, 16, 16
            beqz        $a0, .ok
            break       0
        .ok:
            li.w        $a7, 93
            syscall     0
        zsh% cc mesaure.s -o measure -nostdlib
        zsh% echo $((1.0/3))
        0.33333333333333331
        zsh% while ./measure; do ; done
    
    This while loop should not stop as POSIX is clear that execve must set
    fenv to the default, where FCSR should be zero.  But in fact it will
    just stop after running for a while (normally less than 30 seconds).
    Note that "$((1.0/3))" is needed to reproduce this issue because it
    raises FE_INVALID and makes fcsr0 non-zero.
    
    The problem is we are currently relying on SET_PERSONALITY2() to reset
    current->thread.fpu.fcsr.  But SET_PERSONALITY2() is executed before
    start_thread which calls lose_fpu(0).  We can see if kernel preempt is
    enabled, we may switch to another thread after SET_PERSONALITY2() but
    before lose_fpu(0).  Then bad thing happens: during the thread switch
    the value of the fcsr0 register is stored into current->thread.fpu.fcsr,
    making it dirty again.
    
    The issue can be fixed by setting current->thread.fpu.fcsr after
    lose_fpu(0) because lose_fpu() clears TIF_USEDFPU, then the thread
    switch won't touch current->thread.fpu.fcsr.
    
    The only other architecture setting FCSR in SET_PERSONALITY2() is MIPS.
    I've ran a similar test on MIPS with mainline kernel and it turns out
    MIPS is buggy, too.  Anyway MIPS do this for supporting different FP
    flavors (NaN encodings, etc.) which do not exist on LoongArch.  So for
    LoongArch, we can simply remove the current->thread.fpu.fcsr setting
    from SET_PERSONALITY2() and do it in start_thread(), after lose_fpu(0).
    
    The while loop failing with the mainline kernel has survived one hour
    after this change on LoongArch.
    
    Fixes: 803b0fc5c3f2baa ("LoongArch: Add process management")
    Closes: https://github.com/loongson-community/discussions/issues/7
    Link: https://lore.kernel.org/linux-mips/[email protected]/
    Cc: [email protected]
    Signed-off-by: Xi Ruoyao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
loop: fix the the direct I/O support check when used on top of block devices [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Wed Jan 17 18:59:01 2024 +0100

    loop: fix the the direct I/O support check when used on top of block devices
    
    [ Upstream commit baa7d536077dcdfe2b70c476a8873d1745d3de0f ]
    
    __loop_update_dio only checks the alignment requirement for block backed
    file systems, but misses them for the case where the loop device is
    created directly on top of another block device.  Due to this creating
    a loop device with default option plus the direct I/O flag on a > 512 byte
    sector size file system will lead to incorrect I/O being submitted to the
    lower block device and a lot of error from the lock layer.  This can
    be seen with xfstests generic/563.
    
    Fix the code in __loop_update_dio by factoring the alignment check into
    a helper, and calling that also for the struct block_device of a block
    device inode.
    
    Also remove the TODO comment talking about dynamically switching between
    buffered and direct I/O, which is a would be a recipe for horrible
    performance and occasional data loss.
    
    Fixes: 2e5ab5f379f9 ("block: loop: prepare for supporing direct IO")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
md/raid1: Use blk_opf_t for read and write operations [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Sun Jan 7 16:12:23 2024 -0800

    md/raid1: Use blk_opf_t for read and write operations
    
    commit 7dab24554dedd4e6f408af8eb2d25c89997a6a1f upstream.
    
    Use the type blk_opf_t for read and write operations instead of int. This
    patch does not affect the generated code but fixes the following sparse
    warning:
    
    drivers/md/raid1.c:1993:60: sparse: sparse: incorrect type in argument 5 (different base types)
         expected restricted blk_opf_t [usertype] opf
         got int rw
    
    Cc: Song Liu <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Fixes: 3c5e514db58f ("md/raid1: Use the new blk_opf_t type")
    Cc: [email protected] # v6.0+
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
md: Fix md_seq_ops() regressions [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Tue Jan 9 21:39:57 2024 +0800

    md: Fix md_seq_ops() regressions
    
    commit f9cfe7e7f96a9414a17d596e288693c4f2325d49 upstream.
    
    Commit cf1b6d4441ff ("md: simplify md_seq_ops") introduce following
    regressions:
    
    1) If list all_mddevs is emptly, personalities and unused devices won't
       be showed to user anymore.
    2) If seq_file buffer overflowed from md_seq_show(), then md_seq_start()
       will be called again, hence personalities will be showed to user
       again.
    3) If seq_file buffer overflowed from md_seq_stop(), seq_read_iter()
       doesn't handle this, hence unused devices won't be showed to user.
    
    Fix above problems by printing personalities and unused devices in
    md_seq_show().
    
    Fixes: cf1b6d4441ff ("md: simplify md_seq_ops")
    Cc: [email protected] # v6.7+
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

md: synchronize flush io with array reconfiguration [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Nov 29 10:02:34 2023 +0800

    md: synchronize flush io with array reconfiguration
    
    [ Upstream commit fa2bbff7b0b4e211fec5e5686ef96350690597b5 ]
    
    Currently rcu is used to protect iterating rdev from submit_flushes():
    
    submit_flushes                  remove_and_add_spares
                                    synchronize_rcu
                                    pers->hot_remove_disk()
     rcu_read_lock()
     rdev_for_each_rcu
      if (rdev->raid_disk >= 0)
                                    rdev->radi_disk = -1;
       atomic_inc(&rdev->nr_pending)
       rcu_read_unlock()
       bi = bio_alloc_bioset()
       bi->bi_end_io = md_end_flush
       bi->private = rdev
       submit_bio
       // issue io for removed rdev
    
    Fix this problem by grabbing 'acive_io' before iterating rdev, make sure
    that remove_and_add_spares() won't concurrent with submit_flushes().
    
    Fixes: a2826aa92e2e ("md: support barrier requests on all personalities.")
    Signed-off-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]>

 
media: amphion: Fix VPU core alias name [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Tue Nov 7 08:15:21 2023 +0100

    media: amphion: Fix VPU core alias name
    
    [ Upstream commit f033c87fda47e272bb4f75dc7b03677261d91158 ]
    
    Starting with commit f6038de293f2 ("arm64: dts: imx8qm: Fix VPU core
    alias name") the alias for VPU cores uses dashes instead of underscores.
    Adjust the alias stem accordingly. Fixes the errors:
    amphion-vpu-core 2d040000.vpu-core: can't get vpu core id
    amphion-vpu-core 2d050000.vpu-core: can't get vpu core id
    
    Fixes: f6038de293f2 ("arm64: dts: imx8qm: Fix VPU core alias name")
    Signed-off-by: Alexander Stein <[email protected]>
    Reviewed-by: Ming Qian <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: bttv: add back vbi hack [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Nov 30 13:58:11 2023 +0100

    media: bttv: add back vbi hack
    
    [ Upstream commit 3f1faa154a4316b1b585a25394697504b3c24e98 ]
    
    The old (now removed) videobuf framework had an optional vbi hack where
    the sequence number of the frame counter was copied in the last 4 bytes
    of the buffer. This hack was active only for the read() interface
    (so not for streaming I/O), and it was enabled by bttv. This allowed
    applications that used read() for the VBI data to match it with the
    corresponding video frame.
    
    When bttv was converted to vb2 this hack was forgotten, but some old
    applications rely on this.
    
    So add this back, but this time in the bttv driver rather than in the
    vb2 framework.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: b7ec3212a73a ("media: bttv: convert to vb2")
    Tested-by: Dr. David Alan Gilbert <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: bttv: start_streaming should return a proper error code [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Nov 30 13:58:10 2023 +0100

    media: bttv: start_streaming should return a proper error code
    
    [ Upstream commit 0d75bb6ae127f5e3fd0e2239714908fd2038193d ]
    
    The start_streaming callback returned 0 or 1 instead of a
    proper error code. Fix that.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: b7ec3212a73a ("media: bttv: convert to vb2")
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cx231xx: fix a memleak in cx231xx_init_isoc [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Fri Dec 1 21:22:55 2023 +0800

    media: cx231xx: fix a memleak in cx231xx_init_isoc
    
    [ Upstream commit 5d3c8990e2bbf929cb211563dadd70708f42e4e6 ]
    
    The dma_q->p_left_data alloced by kzalloc should be freed in all the
    following error handling paths. However, it hasn't been freed in the
    allocation error paths of dev->video_mode.isoc_ctl.urb and
    dev->video_mode.isoc_ctl.transfer_buffer.
    
    On the other hand, the dma_q->p_left_data did be freed in the
    error-handling paths after that of dev->video_mode.isoc_ctl.urb and
    dev->video_mode.isoc_ctl.transfer_buffer, by calling
    cx231xx_uninit_isoc(dev). So the same free operation should be done in
    error-handling paths of those two allocation.
    
    Fixes: 64fbf4445526 ("[media] cx231xx: Added support for Carraera, Shelby, RDx_253S and VIDEO_GRABBER")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dt-bindings: media: rkisp1: Fix the port description for the parallel interface [+ + +]
Author: Mehdi Djait <[email protected]>
Date:   Wed Nov 15 17:44:07 2023 +0100

    media: dt-bindings: media: rkisp1: Fix the port description for the parallel interface
    
    [ Upstream commit 25bf28b25a2afa1864b7143259443160d9163ea0 ]
    
    The bus-type belongs to the endpoint's properties and should therefore
    be moved.
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: 6a0eaa25bf36 ("media: dt-bindings: media: rkisp1: Add port for parallel interface")
    Signed-off-by: Mehdi Djait <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dvb-frontends: m88ds3103: Fix a memory leak in an error handling path of m88ds3103_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Oct 30 08:20:26 2023 +0100

    media: dvb-frontends: m88ds3103: Fix a memory leak in an error handling path of m88ds3103_probe()
    
    [ Upstream commit 5b2f885e2f6f482d05c23f04c8240f7b4fc5bdb5 ]
    
    If an error occurs after a successful i2c_mux_add_adapter(), then
    i2c_mux_del_adapters() should be called to free some resources, as
    already done in the remove function.
    
    Fixes: e6089feca460 ("media: m88ds3103: Add support for ds3103b demod")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dvbdev: drop refcount on error path in dvb_device_open() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Oct 31 12:53:33 2023 +0300

    media: dvbdev: drop refcount on error path in dvb_device_open()
    
    [ Upstream commit a2dd235df435a05d389240be748909ada91201d2 ]
    
    If call to file->f_op->open() fails, then call dvb_device_put(dvbdev).
    
    Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: i2c: mt9m114: use fsleep() in place of udelay() [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Dec 13 12:23:07 2023 +0100

    media: i2c: mt9m114: use fsleep() in place of udelay()
    
    [ Upstream commit 02d4e62ae2452c83e4a3e279b8e4cb4dcbad4b31 ]
    
    With clang-16, building without COMMON_CLK triggers a range check on
    udelay() because of a constant division-by-zero calculation:
    
    ld.lld: error: undefined symbol: __bad_udelay
    >>> referenced by mt9m114.c
    >>>               drivers/media/i2c/mt9m114.o:(mt9m114_power_on) in archive vmlinux.a
    
    In this configuration, the driver already fails to probe, before
    this function gets called, so it's enough to suppress the assertion.
    
    Do this by using fsleep(), which turns long delays into sleep() calls
    in place of the link failure.
    
    This is probably a good idea regardless to avoid overly long dynamic
    udelay() calls on a slow clock.
    
    Cc: Sakari Ailus <[email protected]>
    Fixes: 24d756e914fc ("media: i2c: Add driver for onsemi MT9M114 camera sensor")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Tomi Valkeinen <[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-mipi-csis: Drop extra clock enable at probe() [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Nov 22 16:21:35 2023 +0100

    media: imx-mipi-csis: Drop extra clock enable at probe()
    
    [ Upstream commit fb387fcb5cdd0384ba04a5d15a3605e2dccdab2a ]
    
    The driver always enables the clocks at probe() and disables them only
    at remove(). It is not clear why the driver does this, as it supports
    runtime PM, and enables and disables the clocks in the runtime resume
    and suspend callbacks. Also, in the case runtime PM is not available,
    the driver calls the resume and suspend callbacks manually from probe()
    and remove().
    
    Drop the unnecessary clock enable, thus enabling the clocks only when
    actually needed.
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: 7807063b862b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7")
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: imx-mipi-csis: Fix clock handling in remove() [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Nov 22 16:21:34 2023 +0100

    media: imx-mipi-csis: Fix clock handling in remove()
    
    [ Upstream commit 5705b0e0eb550ff834125a46a4ef99b62093d83d ]
    
    The driver always calls mipi_csis_runtime_suspend() and
    mipi_csis_clk_disable() in remove(). This causes multiple WARNs from the
    kernel, as the clocks get disabled too many times.
    
    Fix the remove() to call mipi_csis_runtime_suspend() and
    mipi_csis_clk_disable() in a way that reverses what is done in probe().
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: 7807063b862b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7")
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: mtk-jpeg: Remove cancel worker in mtk_jpeg_remove to avoid the crash of multi-core JPEG devices [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Mon Nov 6 15:48:09 2023 +0100

    media: mtk-jpeg: Remove cancel worker in mtk_jpeg_remove to avoid the crash of multi-core JPEG devices
    
    [ Upstream commit d8212c5c87c143ca01b78f6bf61244af07e0058e ]
    
    This patch reverts commit c677d7ae8314
    ("media: mtk-jpeg: Fix use after free bug due to uncanceled work").
    The job_timeout_work is initialized only for
    the single-core JPEG device so it will cause the crash for multi-core
    JPEG devices.
    
    Fix it by removing the cancel_delayed_work_sync function.
    
    Fixes: c677d7ae8314 ("media: mtk-jpeg: Fix use after free bug due to uncanceled work")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Dmitry Osipenko <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: pvrusb2: fix use after free on context disconnection [+ + +]
Author: Ricardo B. Marliere <[email protected]>
Date:   Fri Oct 13 01:09:12 2023 +0200

    media: pvrusb2: fix use after free on context disconnection
    
    [ Upstream commit ded85b0c0edd8f45fec88783d7555a5b982449c1 ]
    
    Upon module load, a kthread is created targeting the
    pvr2_context_thread_func function, which may call pvr2_context_destroy
    and thus call kfree() on the context object. However, that might happen
    before the usb hub_event handler is able to notify the driver. This
    patch adds a sanity check before the invalid read reported by syzbot,
    within the context disconnection call stack.
    
    Reported-and-tested-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    
    Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload")
    Signed-off-by: Ricardo B. Marliere <[email protected]>
    Acked-by: Mike Isely <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rkisp1: Fix media device memory leak [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Nov 22 16:50:07 2023 +0100

    media: rkisp1: Fix media device memory leak
    
    [ Upstream commit 452f604a4683654f4d9472b3126d8da61d748443 ]
    
    Add missing calls to media_device_cleanup() to fix memory leak.
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: d65dd85281fb ("media: staging: rkisp1: add Rockchip ISP1 base driver")
    Reviewed-by: Tommaso Merciai <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rkisp1: Fix memory leaks in rkisp1_isp_unregister() [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Nov 22 16:50:08 2023 +0100

    media: rkisp1: Fix memory leaks in rkisp1_isp_unregister()
    
    [ Upstream commit 688f3af3c354adc19b78d352c8c7b2006f993f2d ]
    
    Add missing call to v4l2_subdev_cleanup() to fix memory leak.
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: 2cce0a369dbd ("media: rkisp1: isp: Use V4L2 subdev active state")
    Reviewed-by: Tommaso Merciai <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rkvdec: Hook the (TRY_)DECODER_CMD stateless ioctls [+ + +]
Author: Paul Kocialkowski <[email protected]>
Date:   Thu Nov 9 21:16:40 2023 +0100

    media: rkvdec: Hook the (TRY_)DECODER_CMD stateless ioctls
    
    [ Upstream commit 1fb7b5ab62113b29ce331464048d8c39e58fd08a ]
    
    The (TRY_)DECODER_CMD ioctls are used to support flushing when holding
    capture buffers is supported. This is the case of this driver but the
    ioctls were never hooked to the ioctl ops.
    
    Add them to correctly support flushing.
    
    Fixes: ed7bb87d3d03 ("media: rkvdec: Enable capture buffer holding for H264")
    Signed-off-by: Paul Kocialkowski <[email protected]>
    Reviewed-by: Daniel Almeida <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c) [+ + +]
Author: Aurelien Jarno <[email protected]>
Date:   Sat Jan 13 19:33:31 2024 +0100

    media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
    
    commit 31e97d7c9ae3de072d7b424b2cf706a03ec10720 upstream.
    
    This patch replaces max(a, min(b, c)) by clamp(b, a, c) in the solo6x10
    driver.  This improves the readability and more importantly, for the
    solo6x10-p2m.c file, this reduces on my system (x86-64, gcc 13):
    
     - the preprocessed size from 121 MiB to 4.5 MiB;
    
     - the build CPU time from 46.8 s to 1.6 s;
    
     - the build memory from 2786 MiB to 98MiB.
    
    In fine, this allows this relatively simple C file to be built on a
    32-bit system.
    
    Reported-by: Jiri Slaby <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Cc:  <[email protected]> # v6.7+
    Suggested-by: David Laight <[email protected]>
    Signed-off-by: Aurelien Jarno <[email protected]>
    Reviewed-by: David Laight <[email protected]>
    Reviewed-by: Hans Verkuil <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: v4l: async: Fix duplicated list deletion [+ + +]
Author: Sebastian Reichel <[email protected]>
Date:   Mon Nov 13 23:57:23 2023 +0100

    media: v4l: async: Fix duplicated list deletion
    
    [ Upstream commit 3de6ee94aae701fa949cd3b5df6b6a440ddfb8f2 ]
    
    The list deletion call dropped here is already called from the
    helper function in the line before. Having a second list_del()
    call results in either a warning (with CONFIG_DEBUG_LIST=y):
    
    list_del corruption, c46c8198->next is LIST_POISON1 (00000100)
    
    If CONFIG_DEBUG_LIST is disabled the operation results in a
    kernel error due to NULL pointer dereference.
    
    Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities")
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: verisilicon: Hook the (TRY_)DECODER_CMD stateless ioctls [+ + +]
Author: Paul Kocialkowski <[email protected]>
Date:   Thu Nov 9 21:16:39 2023 +0100

    media: verisilicon: Hook the (TRY_)DECODER_CMD stateless ioctls
    
    [ Upstream commit 6c0d9e12b1d12bbd95484e4b99f63feeb423765f ]
    
    The (TRY_)DECODER_CMD ioctls are used to support flushing when holding
    capture buffers is supported. This is the case of this driver but the
    ioctls were never hooked to the ioctl ops.
    
    Add them to correctly support flushing.
    
    Fixes: 340ce50f75a6 ("media: hantro: Enable HOLD_CAPTURE_BUF for H.264")
    Signed-off-by: Paul Kocialkowski <[email protected]>
    Reviewed-by: Daniel Almeida <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: videobuf2: request more buffers for vb2_read [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Nov 30 13:58:12 2023 +0100

    media: videobuf2: request more buffers for vb2_read
    
    [ Upstream commit 350ab13e1382f2afcc2285041a1e75b80d771c2c ]
    
    The vb2 read support requests 1 buffer, leaving it to the driver
    to increase this number to something that works.
    
    Unfortunately, drivers do not deal with this reliably, and in fact
    this caused problems for the bttv driver and reading from /dev/vbiX,
    causing every other VBI frame to be all 0.
    
    Instead, request as the number of buffers whatever is the maximum of
    2 and q->min_buffers_needed+1.
    
    In order to start streaming you need at least q->min_buffers_needed
    queued buffers, so add 1 buffer for processing. And if that field
    is 0, then choose 2 (again, one buffer is being filled while the
    other one is being processed).
    
    This certainly makes more sense than requesting just 1 buffer, and
    the VBI bttv support is now working again.
    
    It turns out that the old videobuf1 behavior of bttv was to allocate
    8 (video) and 4 (vbi) buffers when used with read(). After the vb2
    conversion that changed to 2 for both. With this patch it is 3, which
    is really all you need.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: b7ec3212a73a ("media: bttv: convert to vb2")
    Tested-by: Dr. David Alan Gilbert <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: visl: Hook the (TRY_)DECODER_CMD stateless ioctls [+ + +]
Author: Paul Kocialkowski <[email protected]>
Date:   Thu Nov 9 21:16:38 2023 +0100

    media: visl: Hook the (TRY_)DECODER_CMD stateless ioctls
    
    [ Upstream commit 3907f6ef8e0d55a88cdb0f7238363d24e26790ca ]
    
    The (TRY_)DECODER_CMD ioctls are used to support flushing when holding
    capture buffers is supported. This is the case of this driver but the
    ioctls were never hooked to the ioctl ops.
    
    Add them to correctly support flushing.
    
    Fixes: 0c078e310b6d ("media: visl: add virtual stateless decoder driver")
    Signed-off-by: Paul Kocialkowski <[email protected]>
    Reviewed-by: Daniel Almeida <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: cs42l43: Correct SoundWire port list [+ + +]
Author: Charles Keepax <[email protected]>
Date:   Thu Nov 30 11:57:11 2023 +0000

    mfd: cs42l43: Correct SoundWire port list
    
    [ Upstream commit 47b1b03dc56ebc302620ce43e967aa8f33516f6f ]
    
    Two ports are missing from the port list, and the wrong port is set
    to 4 channels. Also the attempt to list them by function is rather
    misguided, there is nothing in the hardware that fixes a particular
    port to one function. Factor out the port properties to an actual
    struct, fixing the missing ports and correcting the port set to 4
    channels.
    
    Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
    Signed-off-by: Charles Keepax <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: intel-lpss: Fix the fractional clock divider flags [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Mon Dec 11 13:14:41 2023 +0200

    mfd: intel-lpss: Fix the fractional clock divider flags
    
    [ Upstream commit 03d790f04fb2507173913cad9c213272ac983a60 ]
    
    The conversion to CLK_FRAC_DIVIDER_POWER_OF_TWO_PS uses wrong flags
    in the parameters and hence miscalculates the values in the clock
    divider. Fix this by applying the flag to the proper parameter.
    
    Fixes: 82f53f9ee577 ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Reported-by: Alex Vinarskis <[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: rk8xx: fixup devices registration with PLATFORM_DEVID_AUTO [+ + +]
Author: Neil Armstrong <[email protected]>
Date:   Thu Nov 16 15:05:13 2023 +0100

    mfd: rk8xx: fixup devices registration with PLATFORM_DEVID_AUTO
    
    [ Upstream commit 4aedcd4aa61d536ca17e67ecd5bc5d42529164f4 ]
    
    Since commit 210f418f8ace ("mfd: rk8xx: Add rk806 support"), devices are
    registered with "0" as id, causing devices to not have an automatic device id
    and prevents having multiple RK8xx PMICs on the same system.
    
    Properly pass PLATFORM_DEVID_AUTO to devm_mfd_add_devices() and since
    it will ignore the cells .id with this special value, also cleanup
    by removing all now ignored cells .id values.
    
    Now we have the same behaviour as before rk806 introduction and rk806
    retains the intended behavior.
    
    This fixes a regression while booting the Odroid Go Ultra on v6.6.1:
    sysfs: cannot create duplicate filename '/bus/platform/devices/rk808-clkout'
    CPU: 3 PID: 97 Comm: kworker/u12:2 Not tainted 6.6.1 #1
    Hardware name: Hardkernel ODROID-GO-Ultra (DT)
    Workqueue: events_unbound deferred_probe_work_func
    Call trace:
    dump_backtrace+0x9c/0x11c
    show_stack+0x18/0x24
    dump_stack_lvl+0x78/0xc4
    dump_stack+0x18/0x24
    sysfs_warn_dup+0x64/0x80
    sysfs_do_create_link_sd+0xf0/0xf8
    sysfs_create_link+0x20/0x40
    bus_add_device+0x114/0x160
    device_add+0x3f0/0x7cc
    platform_device_add+0x180/0x270
    mfd_add_device+0x390/0x4a8
    devm_mfd_add_devices+0xb0/0x150
    rk8xx_probe+0x26c/0x410
    rk8xx_i2c_probe+0x64/0x98
    i2c_device_probe+0x104/0x2e8
    really_probe+0x184/0x3c8
    __driver_probe_device+0x7c/0x16c
    driver_probe_device+0x3c/0x10c
    __device_attach_driver+0xbc/0x158
    bus_for_each_drv+0x80/0xdc
    __device_attach+0x9c/0x1ac
    device_initial_probe+0x14/0x20
    bus_probe_device+0xac/0xb0
    deferred_probe_work_func+0xa0/0xf4
    process_one_work+0x1bc/0x378
    worker_thread+0x1dc/0x3d4
    kthread+0x104/0x118
    ret_from_fork+0x10/0x20
    rk8xx-i2c 0-001c: error -EEXIST: failed to add MFD devices
    rk8xx-i2c: probe of 0-001c failed with error -17
    
    Fixes: 210f418f8ace ("mfd: rk8xx: Add rk806 support")
    Reported-by: Adam Green <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Reviewed-by: Sebastian Reichel <[email protected]>
    Link: https://lore.kernel.org/r/20231116-topic-amlogic-upstream-fix-rk8xx-devid-auto-v2-1-3f1bad68ab9d@linaro.org
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: syscon: Fix null pointer dereference in of_syscon_register() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Mon Dec 4 17:24:43 2023 +0800

    mfd: syscon: Fix null pointer dereference in of_syscon_register()
    
    [ Upstream commit 41673c66b3d0c09915698fec5c13b24336f18dd1 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config")
    Signed-off-by: Kunwu Chan <[email protected]>
    Reviewed-by: Arnd Bergmann <[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: tps6594: Add null pointer check to tps6594_device_init() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Fri Dec 8 11:33:20 2023 +0800

    mfd: tps6594: Add null pointer check to tps6594_device_init()
    
    [ Upstream commit 825906f2ebe83977d747d8bce61675dddd72485d ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 325bec7157b3 ("mfd: tps6594: Add driver for TI TPS6594 PMIC")
    Suggested-by: Lee Jones <[email protected]>
    Signed-off-by: Kunwu Chan <[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: Alchemy: Fix an out-of-bound access in db1200_dev_setup() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Wed Jan 10 19:07:36 2024 +0100

    MIPS: Alchemy: Fix an out-of-bound access in db1200_dev_setup()
    
    [ Upstream commit 89c4b588d11e9acf01d604de4b0c715884f59213 ]
    
    When calling spi_register_board_info(), we should pass the number of
    elements in 'db1200_spi_devs', not 'db1200_i2c_devs'.
    
    Fixes: 63323ec54a7e ("MIPS: Alchemy: Extended DB1200 board support.")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

MIPS: Alchemy: Fix an out-of-bound access in db1550_dev_setup() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Wed Jan 10 19:09:46 2024 +0100

    MIPS: Alchemy: Fix an out-of-bound access in db1550_dev_setup()
    
    [ Upstream commit 3c1e5abcda64bed0c7bffa65af2316995f269a61 ]
    
    When calling spi_register_board_info(),
    
    Fixes: f869d42e580f ("MIPS: Alchemy: Improved DB1550 support, with audio and serial busses.")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mips: dmi: Fix early remap on MIPS32 [+ + +]
Author: Serge Semin <[email protected]>
Date:   Sat Dec 2 14:14:18 2023 +0300

    mips: dmi: Fix early remap on MIPS32
    
    [ Upstream commit 0d0a3748a2cb38f9da1f08d357688ebd982eb788 ]
    
    dmi_early_remap() has been defined as ioremap_cache() which on MIPS32 gets
    to be converted to the VM-based mapping. DMI early remapping is performed
    at the setup_arch() stage with no VM available. So calling the
    dmi_early_remap() for MIPS32 causes the system to crash at the early boot
    time. Fix that by converting dmi_early_remap() to the uncached remapping
    which is always available on both 32 and 64-bits MIPS systems.
    
    Note this change shall not cause any regressions on the current DMI
    support implementation because on the early boot-up stage neither MIPS32
    nor MIPS64 has the cacheable ioremapping support anyway.
    
    Fixes: be8fa1cb444c ("MIPS: Add support for Desktop Management Interface (DMI)")
    Signed-off-by: Serge Semin <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mips: Fix incorrect max_low_pfn adjustment [+ + +]
Author: Serge Semin <[email protected]>
Date:   Sat Dec 2 14:14:19 2023 +0300

    mips: Fix incorrect max_low_pfn adjustment
    
    [ Upstream commit 0f5cc249ff73552d3bd864e62f85841dafaa107d ]
    
    max_low_pfn variable is incorrectly adjusted if the kernel is built with
    high memory support and the later is detected in a running system, so the
    memory which actually can be directly mapped is getting into the highmem
    zone. See the ZONE_NORMAL range on my MIPS32r5 system:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x0000000007ffffff]
    >   HighMem  [mem 0x0000000008000000-0x000000020fffffff]
    
    while the zones are supposed to look as follows:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x000000001fffffff]
    >   HighMem  [mem 0x0000000020000000-0x000000020fffffff]
    
    Even though the physical memory within the range [0x08000000;0x20000000]
    belongs to MMIO on our system, we don't really want it to be considered as
    high memory since on MIPS32 that range still can be directly mapped.
    
    Note there might be other problems caused by the max_low_pfn variable
    misconfiguration. For instance high_memory variable is initialize with
    virtual address corresponding to the max_low_pfn PFN, and by design it
    must define the upper bound on direct map memory, then end of the normal
    zone. That in its turn potentially may cause problems in accessing the
    memory by means of the /dev/mem and /dev/kmem devices.
    
    Let's fix the discovered misconfiguration then. It turns out the commit
    a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") didn't introduce the
    max_low_pfn adjustment quite correct. If the kernel is built with high
    memory support and the system is equipped with high memory, the
    max_low_pfn variable will need to be initialized with PFN of the most
    upper directly reachable memory address so the zone normal would be
    correctly setup. On MIPS that PFN corresponds to PFN_DOWN(HIGHMEM_START).
    If the system is built with no high memory support and one is detected in
    the running system, we'll just need to adjust the max_pfn variable to
    discard the found high memory from the system and leave the max_low_pfn as
    is, since the later will be less than PFN_DOWN(HIGHMEM_START) anyway by
    design of the for_each_memblock() loop performed a bit early in the
    bootmem_init() method.
    
    Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
    Signed-off-by: Serge Semin <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mlxbf_gige: Enable the GigE port in mlxbf_gige_open [+ + +]
Author: Asmaa Mnebhi <[email protected]>
Date:   Fri Jan 5 11:00:14 2024 -0500

    mlxbf_gige: Enable the GigE port in mlxbf_gige_open
    
    [ Upstream commit a460f4a684511e007bbf1700758a41f05d9981e6 ]
    
    At the moment, the GigE port is enabled in the mlxbf_gige_probe
    function. If the mlxbf_gige_open is not executed, this could cause
    pause frames to increase in the case where there is high backgroud
    traffic. This results in clogging the port.
    So move enabling the OOB port to mlxbf_gige_open.
    
    Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver")
    Reviewed-by: David Thompson <[email protected]>
    Signed-off-by: Asmaa Mnebhi <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlxbf_gige: Fix intermittent no ip issue [+ + +]
Author: Asmaa Mnebhi <[email protected]>
Date:   Fri Jan 5 10:59:46 2024 -0500

    mlxbf_gige: Fix intermittent no ip issue
    
    [ Upstream commit ef210ef85d5cb543ce34a57803ed856d0c8c08c2 ]
    
    Although the link is up, there is no ip assigned on setups with high background
    traffic. Nothing is transmitted nor received. The RX error count keeps on
    increasing. After several minutes, the RX error count stagnates and the
    GigE interface finally gets an ip.
    
    The issue is that mlxbf_gige_rx_init() is called before phy_start().
    As soon as the RX DMA is enabled in mlxbf_gige_rx_init(), the RX CI reaches the max
    of 128, and becomes equal to RX PI. RX CI doesn't decrease since the code hasn't
    ran phy_start yet.
    Bring the PHY up before starting the RX.
    
    Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver")
    Reviewed-by: David Thompson <[email protected]>
    Signed-off-by: Asmaa Mnebhi <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure [+ + +]
Author: Amit Cohen <[email protected]>
Date:   Wed Jan 17 16:04:16 2024 +0100

    mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure
    
    [ Upstream commit 6d6eeabcfaba2fcadf5443b575789ea606f9de83 ]
    
    Lately, a bug was found when many TC filters are added - at some point,
    several bugs are printed to dmesg [1] and the switch is crashed with
    segmentation fault.
    
    The issue starts when gen_pool_free() fails because of unexpected
    behavior - a try to free memory which is already freed, this leads to BUG()
    call which crashes the switch and makes many other bugs.
    
    Trying to track down the unexpected behavior led to a bug in eRP code. The
    function mlxsw_sp_acl_erp_table_alloc() gets a pointer to the allocated
    index, sets the value and returns an error code. When gen_pool_alloc()
    fails it returns address 0, we track it and return -ENOBUFS outside, BUT
    the call for gen_pool_alloc() already override the index in erp_table
    structure. This is a problem when such allocation is done as part of
    table expansion. This is not a new table, which will not be used in case
    of allocation failure. We try to expand eRP table and override the
    current index (non-zero) with zero. Then, it leads to an unexpected
    behavior when address 0 is freed twice. Note that address 0 is valid in
    erp_table->base_index and indeed other tables use it.
    
    gen_pool_alloc() fails in case that there is no space left in the
    pre-allocated pool, in our case, the pool is limited to
    ACL_MAX_ERPT_BANK_SIZE, which is read from hardware. When more than max
    erp entries are required, we exceed the limit and return an error, this
    error leads to "Failed to migrate vregion" print.
    
    Fix this by changing erp_table->base_index only in case of a successful
    allocation.
    
    Add a test case for such a scenario. Without this fix it causes
    segmentation fault:
    
    $ TESTS="max_erp_entries_test" ./tc_flower.sh
    ./tc_flower.sh: line 988:  1560 Segmentation fault      tc filter del dev $h2 ingress chain $i protocol ip pref $i handle $j flower &>/dev/null
    
    [1]:
    kernel BUG at lib/genalloc.c:508!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 6 PID: 3531 Comm: tc Not tainted 6.7.0-rc5-custom-ga6893f479f5e #1
    Hardware name: Mellanox Technologies Ltd. MSN4700/VMOD0010, BIOS 5.11 07/12/2021
    RIP: 0010:gen_pool_free_owner+0xc9/0xe0
    ...
    Call Trace:
     <TASK>
     __mlxsw_sp_acl_erp_table_other_dec+0x70/0xa0 [mlxsw_spectrum]
     mlxsw_sp_acl_erp_mask_destroy+0xf5/0x110 [mlxsw_spectrum]
     objagg_obj_root_destroy+0x18/0x80 [objagg]
     objagg_obj_destroy+0x12c/0x130 [objagg]
     mlxsw_sp_acl_erp_mask_put+0x37/0x50 [mlxsw_spectrum]
     mlxsw_sp_acl_ctcam_region_entry_remove+0x74/0xa0 [mlxsw_spectrum]
     mlxsw_sp_acl_ctcam_entry_del+0x1e/0x40 [mlxsw_spectrum]
     mlxsw_sp_acl_tcam_ventry_del+0x78/0xd0 [mlxsw_spectrum]
     mlxsw_sp_flower_destroy+0x4d/0x70 [mlxsw_spectrum]
     mlxsw_sp_flow_block_cb+0x73/0xb0 [mlxsw_spectrum]
     tc_setup_cb_destroy+0xc1/0x180
     fl_hw_destroy_filter+0x94/0xc0 [cls_flower]
     __fl_delete+0x1ac/0x1c0 [cls_flower]
     fl_destroy+0xc2/0x150 [cls_flower]
     tcf_proto_destroy+0x1a/0xa0
    ...
    mlxsw_spectrum3 0000:07:00.0: Failed to migrate vregion
    mlxsw_spectrum3 0000:07:00.0: Failed to migrate vregion
    
    Fixes: f465261aa105 ("mlxsw: spectrum_acl: Implement common eRP core")
    Signed-off-by: Amit Cohen <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/4cfca254dfc0e5d283974801a24371c7b6db5989.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Wed Jan 17 16:04:17 2024 +0100

    mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
    
    [ Upstream commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 ]
    
    When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
    failing to attach the region to an ACL group, we hit a NULL pointer
    dereference upon 'region->group->tcam' [1].
    
    Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().
    
    [1]
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    [...]
    RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
    [...]
    Call Trace:
     mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
     mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
     mlxsw_sp_acl_rule_add+0x47/0x240
     mlxsw_sp_flower_replace+0x1a9/0x1d0
     tc_setup_cb_add+0xdc/0x1c0
     fl_hw_replace_filter+0x146/0x1f0
     fl_change+0xc17/0x1360
     tc_new_tfilter+0x472/0xb90
     rtnetlink_rcv_msg+0x313/0x3b0
     netlink_rcv_skb+0x58/0x100
     netlink_unicast+0x244/0x390
     netlink_sendmsg+0x1e4/0x440
     ____sys_sendmsg+0x164/0x260
     ___sys_sendmsg+0x9a/0xe0
     __sys_sendmsg+0x7a/0xc0
     do_syscall_64+0x40/0xe0
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation")
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Amit Cohen <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlxsw: spectrum_acl_tcam: Fix stack corruption [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Wed Jan 17 16:04:18 2024 +0100

    mlxsw: spectrum_acl_tcam: Fix stack corruption
    
    [ Upstream commit 483ae90d8f976f8339cf81066312e1329f2d3706 ]
    
    When tc filters are first added to a net device, the corresponding local
    port gets bound to an ACL group in the device. The group contains a list
    of ACLs. In turn, each ACL points to a different TCAM region where the
    filters are stored. During forwarding, the ACLs are sequentially
    evaluated until a match is found.
    
    One reason to place filters in different regions is when they are added
    with decreasing priorities and in an alternating order so that two
    consecutive filters can never fit in the same region because of their
    key usage.
    
    In Spectrum-2 and newer ASICs the firmware started to report that the
    maximum number of ACLs in a group is more than 16, but the layout of the
    register that configures ACL groups (PAGT) was not updated to account
    for that. It is therefore possible to hit stack corruption [1] in the
    rare case where more than 16 ACLs in a group are required.
    
    Fix by limiting the maximum ACL group size to the minimum between what
    the firmware reports and the maximum ACLs that fit in the PAGT register.
    
    Add a test case to make sure the machine does not crash when this
    condition is hit.
    
    [1]
    Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
    [...]
     dump_stack_lvl+0x36/0x50
     panic+0x305/0x330
     __stack_chk_fail+0x15/0x20
     mlxsw_sp_acl_tcam_group_update+0x116/0x120
     mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
     mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
     mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
     mlxsw_sp_acl_rule_add+0x47/0x240
     mlxsw_sp_flower_replace+0x1a9/0x1d0
     tc_setup_cb_add+0xdc/0x1c0
     fl_hw_replace_filter+0x146/0x1f0
     fl_change+0xc17/0x1360
     tc_new_tfilter+0x472/0xb90
     rtnetlink_rcv_msg+0x313/0x3b0
     netlink_rcv_skb+0x58/0x100
     netlink_unicast+0x244/0x390
     netlink_sendmsg+0x1e4/0x440
     ____sys_sendmsg+0x164/0x260
     ___sys_sendmsg+0x9a/0xe0
     __sys_sendmsg+0x7a/0xc0
     do_syscall_64+0x40/0xe0
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
    Reported-by: Orel Hagag <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Amit Cohen <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/2d91c89afba59c22587b444994ae419dbea8d876.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlxsw: spectrum_router: Register netdevice notifier before nexthop [+ + +]
Author: Petr Machata <[email protected]>
Date:   Wed Jan 17 16:04:19 2024 +0100

    mlxsw: spectrum_router: Register netdevice notifier before nexthop
    
    [ Upstream commit 62bef63646c194e0f82b40304a0f2d060b28687b ]
    
    If there are IPIP nexthops at the time when the driver is loaded (or the
    devlink instance reloaded), the driver looks up the corresponding IPIP
    entry. But IPIP entries are only created as a result of netdevice
    notifications. Since the netdevice notifier is registered after the nexthop
    notifier, mlxsw_sp_nexthop_type_init() never finds the IPIP entry,
    registers the nexthop MLXSW_SP_NEXTHOP_TYPE_ETH, and fails to assign a CRIF
    to the nexthop. Later on when the CRIF is necessary, the WARN_ON in
    mlxsw_sp_nexthop_rif() triggers, causing the splat [1].
    
    In order to fix the issue, reorder the netdevice notifier to be registered
    before the nexthop one.
    
    [1] (edited for clarity):
    
        WARNING: CPU: 1 PID: 1364 at drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3245 mlxsw_sp_nexthop_rif (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3246 (discriminator 1)) mlxsw_spectrum
        Hardware name: Mellanox Technologies Ltd. MSN4410/VMOD0010, BIOS 5.11 01/06/2019
        Call Trace:
        ? mlxsw_sp_nexthop_rif (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3246 (discriminator 1)) mlxsw_spectrum
        __mlxsw_sp_nexthop_eth_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3637) mlxsw_spectrum
        mlxsw_sp_nexthop_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3679 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3727) mlxsw_spectrum
        mlxsw_sp_nexthop_group_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3757) mlxsw_spectrum
        mlxsw_sp_nexthop_group_refresh (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4112) mlxsw_spectrum
        mlxsw_sp_nexthop_obj_event (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5118 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5191 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5315 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5500) mlxsw_spectrum
        nexthops_dump (net/ipv4/nexthop.c:217 net/ipv4/nexthop.c:440 net/ipv4/nexthop.c:3609)
        register_nexthop_notifier (net/ipv4/nexthop.c:3624)
        mlxsw_sp_router_init (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:11486) mlxsw_spectrum
        mlxsw_sp_init (drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3267) mlxsw_spectrum
        __mlxsw_core_bus_device_register (drivers/net/ethernet/mellanox/mlxsw/core.c:2202) mlxsw_core
        mlxsw_devlink_core_bus_device_reload_up (drivers/net/ethernet/mellanox/mlxsw/core.c:2265 drivers/net/ethernet/mellanox/mlxsw/core.c:1603) mlxsw_core
        devlink_reload (net/devlink/dev.c:314 net/devlink/dev.c:475)
        [...]
    
    Fixes: 9464a3d68ea9 ("mlxsw: spectrum_router: Track next hops at CRIFs")
    Reported-by: Maksym Yaremchuk <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/74edb8d45d004e8d8f5318eede6ccc3d786d8ba9.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: sdhci_am654: Fix TI SoC dependencies [+ + +]
Author: Peter Robinson <[email protected]>
Date:   Wed Dec 20 13:59:46 2023 +0000

    mmc: sdhci_am654: Fix TI SoC dependencies
    
    [ Upstream commit cb052da7f031b0d2309a4895ca236afb3b4bbf50 ]
    
    The sdhci_am654 is specific to recent TI SoCs, update the
    dependencies for those SoCs and compile testing. While we're
    at it update the text to reflect the wider range of
    supported TI SoCS the driver now supports.
    
    Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
    Signed-off-by: Peter Robinson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_omap: Fix TI SoC dependencies [+ + +]
Author: Peter Robinson <[email protected]>
Date:   Wed Dec 20 13:59:47 2023 +0000

    mmc: sdhci_omap: Fix TI SoC dependencies
    
    [ Upstream commit 09f164d393a6671e5ff8342ba6b3cb7fe3f20208 ]
    
    The sdhci_omap is specific to  older TI SoCs, update the
    dependencies for those SoCs and compile testing. While we're
    at it update the text to reflect the wider range of
    supported TI SoCS the driver now supports.
    
    Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
    Signed-off-by: Peter Robinson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mptcp: mptcp_parse_option() fix for MPTCPOPT_MP_JOIN [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 19:49:13 2024 +0000

    mptcp: mptcp_parse_option() fix for MPTCPOPT_MP_JOIN
    
    [ Upstream commit 89e23277f9c16df6f9f9c1a1a07f8f132339c15c ]
    
    mptcp_parse_option() currently sets OPTIONS_MPTCP_MPJ, for the three
    possible cases handled for MPTCPOPT_MP_JOIN option.
    
    OPTIONS_MPTCP_MPJ is the combination of three flags:
    - OPTION_MPTCP_MPJ_SYN
    - OPTION_MPTCP_MPJ_SYNACK
    - OPTION_MPTCP_MPJ_ACK
    
    This is a problem, because backup, join_id, token, nonce and/or hmac fields
    could be left uninitialized in some cases.
    
    Distinguish the three cases, as following patches will need this step.
    
    Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Florian Westphal <[email protected]>
    Cc: Peter Krystad <[email protected]>
    Cc: Matthieu Baerts <[email protected]>
    Cc: Mat Martineau <[email protected]>
    Cc: Geliang Tang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: refine opt_mp_capable determination [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 19:49:17 2024 +0000

    mptcp: refine opt_mp_capable determination
    
    [ Upstream commit 724b00c12957973656d312dce2a110c75ae2c680 ]
    
    OPTIONS_MPTCP_MPC is a combination of three flags.
    
    It would be better to be strict about testing what
    flag is expected, at least for code readability.
    
    mptcp_parse_option() already makes the distinction.
    
    - subflow_check_req() should use OPTION_MPTCP_MPC_SYN.
    
    - mptcp_subflow_init_cookie_req() should use OPTION_MPTCP_MPC_ACK.
    
    - subflow_finish_connect() should use OPTION_MPTCP_MPC_SYNACK
    
    - subflow_syn_recv_sock should use OPTION_MPTCP_MPC_ACK
    
    Suggested-by: Paolo Abeni <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Fixes: 74c7dfbee3e1 ("mptcp: consolidate in_opt sub-options fields in a bitmask")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: relax check on MPC passive fallback [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Tue Jan 16 18:18:47 2024 +0100

    mptcp: relax check on MPC passive fallback
    
    [ Upstream commit c0f5aec28edf98906d28f08daace6522adf9ee7a ]
    
    While testing the blamed commit below, I was able to miss (!)
    packetdrill failures in the fastopen test-cases.
    
    On passive fastopen the child socket is created by incoming TCP MPC syn,
    allow for both MPC_SYN and MPC_ACK header.
    
    Fixes: 724b00c12957 ("mptcp: refine opt_mp_capable determination")
    Reviewed-by: Matthieu Baerts <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: strict validation before using mp_opt->hmac [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 19:49:14 2024 +0000

    mptcp: strict validation before using mp_opt->hmac
    
    [ Upstream commit c1665273bdc7c201766c65e561c06711f2e050dc ]
    
    mp_opt->hmac contains uninitialized data unless OPTION_MPTCP_MPJ_ACK
    was set in mptcp_parse_option().
    
    We must refine the condition before we call subflow_hmac_valid().
    
    Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Florian Westphal <[email protected]>
    Cc: Peter Krystad <[email protected]>
    Cc: Matthieu Baerts <[email protected]>
    Cc: Mat Martineau <[email protected]>
    Cc: Geliang Tang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: use OPTION_MPTCP_MPJ_SYN in subflow_check_req() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 19:49:16 2024 +0000

    mptcp: use OPTION_MPTCP_MPJ_SYN in subflow_check_req()
    
    [ Upstream commit 66ff70df1a919a066942844bb095d6fcb748d78d ]
    
    syzbot reported that subflow_check_req() was using uninitialized data in
    subflow_check_req() [1]
    
    This is because mp_opt.token is only set when OPTION_MPTCP_MPJ_SYN is also set.
    
    While we are are it, fix mptcp_subflow_init_cookie_req()
    to test for OPTION_MPTCP_MPJ_ACK.
    
    [1]
    
    BUG: KMSAN: uninit-value in subflow_token_join_request net/mptcp/subflow.c:91 [inline]
     BUG: KMSAN: uninit-value in subflow_check_req+0x1028/0x15d0 net/mptcp/subflow.c:209
      subflow_token_join_request net/mptcp/subflow.c:91 [inline]
      subflow_check_req+0x1028/0x15d0 net/mptcp/subflow.c:209
      subflow_v6_route_req+0x269/0x410 net/mptcp/subflow.c:367
      tcp_conn_request+0x153a/0x4240 net/ipv4/tcp_input.c:7164
     subflow_v6_conn_request+0x3ee/0x510
      tcp_rcv_state_process+0x2e1/0x4ac0 net/ipv4/tcp_input.c:6659
      tcp_v6_do_rcv+0x11bf/0x1fe0 net/ipv6/tcp_ipv6.c:1669
      tcp_v6_rcv+0x480b/0x4fb0 net/ipv6/tcp_ipv6.c:1900
      ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
      ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
      dst_input include/net/dst.h:461 [inline]
      ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
      __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
      netif_receive_skb_internal net/core/dev.c:5732 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5791
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
      tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
      call_write_iter include/linux/fs.h:2020 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x8ef/0x1490 fs/read_write.c:584
      ksys_write+0x20f/0x4c0 fs/read_write.c:637
      __do_sys_write fs/read_write.c:649 [inline]
      __se_sys_write fs/read_write.c:646 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:646
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Local variable mp_opt created at:
      subflow_check_req+0x6d/0x15d0 net/mptcp/subflow.c:145
      subflow_v6_route_req+0x269/0x410 net/mptcp/subflow.c:367
    
    CPU: 1 PID: 5924 Comm: syz-executor.3 Not tainted 6.7.0-rc8-syzkaller-00055-g5eff55d725a4 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Florian Westphal <[email protected]>
    Cc: Peter Krystad <[email protected]>
    Cc: Matthieu Baerts <[email protected]>
    Cc: Mat Martineau <[email protected]>
    Cc: Geliang Tang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 19:49:15 2024 +0000

    mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
    
    [ Upstream commit be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb ]
    
    subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
    that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
    in mptcp_parse_option()
    
    Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Florian Westphal <[email protected]>
    Cc: Peter Krystad <[email protected]>
    Cc: Matthieu Baerts <[email protected]>
    Cc: Mat Martineau <[email protected]>
    Cc: Geliang Tang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier [+ + +]
Author: ZhaoLong Wang <[email protected]>
Date:   Wed Dec 20 10:46:19 2023 +0800

    mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
    
    [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ]
    
    If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
    triggers NULL pointer dereference when trying to access
    ‘gluebi->desc’ in gluebi_read().
    
    ubi_gluebi_init
      ubi_register_volume_notifier
        ubi_enumerate_volumes
          ubi_notify_all
            gluebi_notify    nb->notifier_call()
              gluebi_create
                mtd_device_register
                  mtd_device_parse_register
                    add_mtd_device
                      blktrans_notify_add   not->add()
                        ftl_add_mtd         tr->add_mtd()
                          scan_header
                            mtd_read
                              mtd_read_oob
                                mtd_read_oob_std
                                  gluebi_read   mtd->read()
                                    gluebi->desc - NULL
    
    Detailed reproduction information available at the Link [1],
    
    In the normal case, obtain gluebi->desc in the gluebi_get_device(),
    and access gluebi->desc in the gluebi_read(). However,
    gluebi_get_device() is not executed in advance in the
    ftl_add_mtd() process, which leads to NULL pointer dereference.
    
    The solution for the gluebi module is to run jffs2 on the UBI
    volume without considering working with ftl or mtdblock [2].
    Therefore, this problem can be avoided by preventing gluebi from
    creating the mtdblock device after creating mtd partition of the
    type MTD_UBIVOLUME.
    
    Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1]
    Link: https://lore.kernel.org/lkml/[email protected]/ [2]
    Signed-off-by: ZhaoLong Wang <[email protected]>
    Reviewed-by: Zhihao Cheng <[email protected]>
    Acked-by: Richard Weinberger <[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: Increment IFC_TIMEOUT_MSECS for nand controller response [+ + +]
Author: Ronald Monthero <[email protected]>
Date:   Sat Nov 18 18:31:51 2023 +1000

    mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response
    
    [ Upstream commit 923fb6238cb3ac529aa2bf13b3b1e53762186a8b ]
    
    Under heavy load it is likely that the controller is done
    with its own task but the thread unlocking the wait is not
    scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the
    controller to respond within allowable timeslice of 1 sec.
    
    fsl,ifc-nand 7e800000.nand: Controller is not responding
    
    [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a)
    [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c)
    [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c)
    [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
    
    Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
    Reviewed-by: Miquel Raynal <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Ronald Monthero <[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]>

 
net/ncsi: Fix netlink major/minor version numbers [+ + +]
Author: Peter Delevoryas <[email protected]>
Date:   Tue Nov 14 10:07:34 2023 -0600

    net/ncsi: Fix netlink major/minor version numbers
    
    [ Upstream commit 3084b58bfd0b9e4b5e034f31f31b42977db35f12 ]
    
    The netlink interface for major and minor version numbers doesn't actually
    return the major and minor version numbers.
    
    It reports a u32 that contains the (major, minor, update, alpha1)
    components as the major version number, and then alpha2 as the minor
    version number.
    
    For whatever reason, the u32 byte order was reversed (ntohl): maybe it was
    assumed that the encoded value was a single big-endian u32, and alpha2 was
    the minor version.
    
    The correct way to get the supported NC-SI version from the network
    controller is to parse the Get Version ID response as described in 8.4.44
    of the NC-SI spec[1].
    
        Get Version ID Response Packet Format
    
                  Bits
                +--------+--------+--------+--------+
         Bytes  | 31..24 | 23..16 | 15..8  | 7..0   |
        +-------+--------+--------+--------+--------+
        | 0..15 | NC-SI Header                      |
        +-------+--------+--------+--------+--------+
        | 16..19| Response code   | Reason code     |
        +-------+--------+--------+--------+--------+
        |20..23 | Major  | Minor  | Update | Alpha1 |
        +-------+--------+--------+--------+--------+
        |24..27 |         reserved         | Alpha2 |
        +-------+--------+--------+--------+--------+
        |            .... other stuff ....          |
    
    The major, minor, and update fields are all binary-coded decimal (BCD)
    encoded [2]. The spec provides examples below the Get Version ID response
    format in section 8.4.44.1, but for practical purposes, this is an example
    from a live network card:
    
        root@bmc:~# ncsi-util 0x15
        NC-SI Command Response:
        cmd: GET_VERSION_ID(0x15)
        Response: COMMAND_COMPLETED(0x0000)  Reason: NO_ERROR(0x0000)
        Payload length = 40
    
        20: 0xf1 0xf1 0xf0 0x00 <<<<<<<<< (major, minor, update, alpha1)
        24: 0x00 0x00 0x00 0x00 <<<<<<<<< (_, _, _, alpha2)
    
        28: 0x6d 0x6c 0x78 0x30
        32: 0x2e 0x31 0x00 0x00
        36: 0x00 0x00 0x00 0x00
        40: 0x16 0x1d 0x07 0xd2
        44: 0x10 0x1d 0x15 0xb3
        48: 0x00 0x17 0x15 0xb3
        52: 0x00 0x00 0x81 0x19
    
    This should be parsed as "1.1.0".
    
    "f" in the upper-nibble means to ignore it, contributing zero.
    
    If both nibbles are "f", I think the whole field is supposed to be ignored.
    Major and minor are "required", meaning they're not supposed to be "ff",
    but the update field is "optional" so I think it can be ff. I think the
    simplest thing to do is just set the major and minor to zero instead of
    juggling some conditional logic or something.
    
    bcd2bin() from "include/linux/bcd.h" seems to assume both nibbles are 0-9,
    so I've provided a custom BCD decoding function.
    
    Alpha1 and alpha2 are ISO/IEC 8859-1 encoded, which just means ASCII
    characters as far as I can tell, although the full encoding table for
    non-alphabetic characters is slightly different (I think).
    
    I imagine the alpha fields are just supposed to be alphabetic characters,
    but I haven't seen any network cards actually report a non-zero value for
    either.
    
    If people wrote software against this netlink behavior, and were parsing
    the major and minor versions themselves from the u32, then this would
    definitely break their code.
    
    [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.0.0.pdf
    [2] https://en.wikipedia.org/wiki/Binary-coded_decimal
    [2] https://en.wikipedia.org/wiki/ISO/IEC_8859-1
    
    Signed-off-by: Peter Delevoryas <[email protected]>
    Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: act_ct: fix skb leak and crash on ooo frags [+ + +]
Author: Tao Liu <[email protected]>
Date:   Thu Dec 28 16:14:57 2023 +0800

    net/sched: act_ct: fix skb leak and crash on ooo frags
    
    [ Upstream commit 3f14b377d01d8357eba032b4cabc8c1149b458b6 ]
    
    act_ct adds skb->users before defragmentation. If frags arrive in order,
    the last frag's reference is reset in:
    
      inet_frag_reasm_prepare
        skb_morph
    
    which is not straightforward.
    
    However when frags arrive out of order, nobody unref the last frag, and
    all frags are leaked. The situation is even worse, as initiating packet
    capture can lead to a crash[0] when skb has been cloned and shared at the
    same time.
    
    Fix the issue by removing skb_get() before defragmentation. act_ct
    returns TC_ACT_CONSUMED when defrag failed or in progress.
    
    [0]:
    [  843.804823] ------------[ cut here ]------------
    [  843.809659] kernel BUG at net/core/skbuff.c:2091!
    [  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
    [  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
    [  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
    [  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
    [  843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
    [  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
    [  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
    [  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
    [  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
    [  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
    [  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
    [  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
    [  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
    [  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  843.894229] PKRU: 55555554
    [  843.898539] Call Trace:
    [  843.902772]  <IRQ>
    [  843.906922]  ? __die_body+0x1e/0x60
    [  843.911032]  ? die+0x3c/0x60
    [  843.915037]  ? do_trap+0xe2/0x110
    [  843.918911]  ? pskb_expand_head+0x2ac/0x300
    [  843.922687]  ? do_error_trap+0x65/0x80
    [  843.926342]  ? pskb_expand_head+0x2ac/0x300
    [  843.929905]  ? exc_invalid_op+0x50/0x60
    [  843.933398]  ? pskb_expand_head+0x2ac/0x300
    [  843.936835]  ? asm_exc_invalid_op+0x1a/0x20
    [  843.940226]  ? pskb_expand_head+0x2ac/0x300
    [  843.943580]  inet_frag_reasm_prepare+0xd1/0x240
    [  843.946904]  ip_defrag+0x5d4/0x870
    [  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
    [  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]
    [  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
    [  843.959657]  tcf_action_exec+0xa1/0x160
    [  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]
    [  843.966010]  ? skb_clone+0x53/0xc0
    [  843.969173]  tcf_classify+0x24d/0x420
    [  843.972333]  tc_run+0x8f/0xf0
    [  843.975465]  __netif_receive_skb_core+0x67a/0x1080
    [  843.978634]  ? dev_gro_receive+0x249/0x730
    [  843.981759]  __netif_receive_skb_list_core+0x12d/0x260
    [  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0
    [  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
    [  843.991170]  napi_complete_done+0x72/0x1a0
    [  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
    [  843.997501]  __napi_poll+0x25/0x1b0
    [  844.000627]  net_rx_action+0x256/0x330
    [  844.003705]  __do_softirq+0xb3/0x29b
    [  844.006718]  irq_exit_rcu+0x9e/0xc0
    [  844.009672]  common_interrupt+0x86/0xa0
    [  844.012537]  </IRQ>
    [  844.015285]  <TASK>
    [  844.017937]  asm_common_interrupt+0x26/0x40
    [  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
    [  844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb f4 <fa> c3 0f 1f 00 89 fa ec 48 8b 05 ee 88 ed 00 a9 00 00 00 80 75 11
    [  844.028900] RSP: 0018:ffffc90000533e70 EFLAGS: 00000246
    [  844.031725] RAX: 0000000000004000 RBX: 0000000000000001 RCX: 0000000000000000
    [  844.034553] RDX: ffff889ffffc0000 RSI: ffffffff828b7f20 RDI: ffff88a090f45c64
    [  844.037368] RBP: ffff88a0901a2800 R08: ffff88a090f45c00 R09: 00000000000317c0
    [  844.040155] R10: 00ec812281150475 R11: ffff889fffff0e04 R12: ffffffff828b7fa0
    [  844.042962] R13: ffffffff828b7f20 R14: 0000000000000001 R15: 0000000000000000
    [  844.045819]  acpi_idle_enter+0x7b/0xc0
    [  844.048621]  cpuidle_enter_state+0x7f/0x430
    [  844.051451]  cpuidle_enter+0x2d/0x40
    [  844.054279]  do_idle+0x1d4/0x240
    [  844.057096]  cpu_startup_entry+0x2a/0x30
    [  844.059934]  start_secondary+0x104/0x130
    [  844.062787]  secondary_startup_64_no_verify+0x16b/0x16b
    [  844.065674]  </TASK>
    
    Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
    Signed-off-by: Tao Liu <[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: add more sanity check in virtio_net_hdr_to_skb() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jan 12 12:28:16 2024 +0000

    net: add more sanity check in virtio_net_hdr_to_skb()
    
    [ Upstream commit 9181d6f8a2bb32d158de66a84164fac05e3ddd18 ]
    
    syzbot/KMSAN reports access to uninitialized data from gso_features_check() [1]
    
    The repro use af_packet, injecting a gso packet and hdrlen == 0.
    
    We could fix the issue making gso_features_check() more careful
    while dealing with NETIF_F_TSO_MANGLEID in fast path.
    
    Or we can make sure virtio_net_hdr_to_skb() pulls minimal network and
    transport headers as intended.
    
    Note that for GSO packets coming from untrusted sources, SKB_GSO_DODGY
    bit forces a proper header validation (and pull) before the packet can
    hit any device ndo_start_xmit(), thus we do not need a precise disection
    at virtio_net_hdr_to_skb() stage.
    
    [1]
    BUG: KMSAN: uninit-value in skb_gso_segment include/net/gso.h:83 [inline]
    BUG: KMSAN: uninit-value in validate_xmit_skb+0x10f2/0x1930 net/core/dev.c:3629
     skb_gso_segment include/net/gso.h:83 [inline]
     validate_xmit_skb+0x10f2/0x1930 net/core/dev.c:3629
     __dev_queue_xmit+0x1eac/0x5130 net/core/dev.c:4341
     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_sendmsg+0x9c2/0xd60 net/socket.c:2584
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
     __sys_sendmsg net/socket.c:2667 [inline]
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x44/0x110 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:2780
     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_sendmsg+0x9c2/0xd60 net/socket.c:2584
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
     __sys_sendmsg net/socket.c:2667 [inline]
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    CPU: 0 PID: 5025 Comm: syz-executor279 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Reported-by: [email protected]
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: 9274124f023b ("net: stricter validation of untrusted gso packets")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Wed Jan 10 02:33:54 2024 +0200

    net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events
    
    [ Upstream commit 844f104790bd69c2e4dbb9ee3eba46fde1fcea7b ]
    
    After the blamed commit, we started doing this dereference for every
    NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system.
    
    static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev)
    {
            struct dsa_user_priv *p = netdev_priv(dev);
    
            return p->dp;
    }
    
    Which is obviously bogus, because not all net_devices have a netdev_priv()
    of type struct dsa_user_priv. But struct dsa_user_priv is fairly small,
    and p->dp means dereferencing 8 bytes starting with offset 16. Most
    drivers allocate that much private memory anyway, making our access not
    fault, and we discard the bogus data quickly afterwards, so this wasn't
    caught.
    
    But the dummy interface is somewhat special in that it calls
    alloc_netdev() with a priv size of 0. So every netdev_priv() dereference
    is invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER event
    with a VLAN as its new upper:
    
    $ ip link add dummy1 type dummy
    $ ip link add link dummy1 name dummy1.100 type vlan id 100
    [   43.309174] ==================================================================
    [   43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8
    [   43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374
    [   43.330058]
    [   43.342436] Call trace:
    [   43.366542]  dsa_user_prechangeupper+0x30/0xe8
    [   43.371024]  dsa_user_netdevice_event+0xb38/0xee8
    [   43.375768]  notifier_call_chain+0xa4/0x210
    [   43.379985]  raw_notifier_call_chain+0x24/0x38
    [   43.384464]  __netdev_upper_dev_link+0x3ec/0x5d8
    [   43.389120]  netdev_upper_dev_link+0x70/0xa8
    [   43.393424]  register_vlan_dev+0x1bc/0x310
    [   43.397554]  vlan_newlink+0x210/0x248
    [   43.401247]  rtnl_newlink+0x9fc/0xe30
    [   43.404942]  rtnetlink_rcv_msg+0x378/0x580
    
    Avoid the kernel oops by dereferencing after the type check, as customary.
    
    Fixes: 4c3f80d22b2e ("net: dsa: walk through all changeupper notifier functions")
    Reported-and-tested-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Reviewed-by: Eric Dumazet <[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: vsc73xx: Add null pointer check to vsc73xx_gpio_probe [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Thu Jan 11 15:20:18 2024 +0800

    net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probe
    
    [ Upstream commit 776dac5a662774f07a876b650ba578d0a62d20db ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver")
    Signed-off-by: Kunwu Chan <[email protected]>
    Suggested-by: Jakub Kicinski <[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]>

net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames [+ + +]
Author: Sanjuán García, Jorge <[email protected]>
Date:   Fri Jan 5 08:55:43 2024 +0000

    net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames
    
    [ Upstream commit 64e47d8afb5ca533b27efc006405e5bcae2c4a7b ]
    
    The value of AM65_CPSW_MAX_PACKET_SIZE represents the maximum length
    of a received frame. This value is written to the register
    AM65_CPSW_PORT_REG_RX_MAXLEN.
    
    The maximum MTU configured on the network device should then leave
    some room for the ethernet headers and frame check. Otherwise, if
    the network interface is configured to its maximum mtu possible,
    the frames will be larger than AM65_CPSW_MAX_PACKET_SIZE and will
    get dropped as oversized.
    
    The switch supports ethernet frame sizes between 64 and 2024 bytes
    (including VLAN) as stated in the technical reference manual, so
    define AM65_CPSW_MAX_PACKET_SIZE with that maximum size.
    
    Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
    Signed-off-by: Jorge Sanjuan Garcia <[email protected]>
    Reviewed-by: Horatiu Vultur <[email protected]>
    Reviewed-by: Siddharth Vadapalli <[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: micrel: Fix PTP frame parsing for lan8841 [+ + +]
Author: Horatiu Vultur <[email protected]>
Date:   Wed Jan 10 12:37:30 2024 +0100

    net: micrel: Fix PTP frame parsing for lan8841
    
    [ Upstream commit acd66c2126eb9b5da2d89ae07dbcd73b909c2111 ]
    
    The HW has the capability to check each frame if it is a PTP frame,
    which domain it is, which ptp frame type it is, different ip address in
    the frame. And if one of these checks fail then the frame is not
    timestamp. Most of these checks were disabled except checking the field
    minorVersionPTP inside the PTP header. Meaning that once a partner sends
    a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
    frame was not timestamp because the HW expected by default a value of 0
    in minorVersionPTP.
    Fix this issue by removing this check so the userspace can decide on this.
    
    Fixes: cafc3662ee3f ("net: micrel: Add PHC support for lan8841")
    Signed-off-by: Horatiu Vultur <[email protected]>
    Reviewed-by: Divya Koppera <[email protected]>
    Reviewed-by: Rahul Rameshbabu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: netdev_queue: netdev_txq_completed_mb(): fix wake condition [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Jan 12 17:13:14 2024 +0100

    net: netdev_queue: netdev_txq_completed_mb(): fix wake condition
    
    [ Upstream commit 894d7508316e7ad722df597d68b4b1797a9eee11 ]
    
    netif_txq_try_stop() uses "get_desc >= start_thrs" as the check for
    the call to netif_tx_start_queue().
    
    Use ">=" i netdev_txq_completed_mb(), too.
    
    Fixes: c91c46de6bbc ("net: provide macros for commonly copied lockless queue stop/wake code")
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Acked-by: Jakub Kicinski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: netdevsim: don't try to destroy PHC on VFs [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Tue Jan 16 11:14:00 2024 -0800

    net: netdevsim: don't try to destroy PHC on VFs
    
    [ Upstream commit ea937f77208323d35ffe2f8d8fc81b00118bfcda ]
    
    PHC gets initialized in nsim_init_netdevsim(), which
    is only called if (nsim_dev_port_is_pf()).
    
    Create a counterpart of nsim_init_netdevsim() and
    move the mock_phc_destroy() there.
    
    This fixes a crash trying to destroy netdevsim with
    VFs instantiated, as caught by running the devlink.sh test:
    
        BUG: kernel NULL pointer dereference, address: 00000000000000b8
        RIP: 0010:mock_phc_destroy+0xd/0x30
        Call Trace:
         <TASK>
         nsim_destroy+0x4a/0x70 [netdevsim]
         __nsim_dev_port_del+0x47/0x70 [netdevsim]
         nsim_dev_reload_destroy+0x105/0x120 [netdevsim]
         nsim_drv_remove+0x2f/0xb0 [netdevsim]
         device_release_driver_internal+0x1a1/0x210
         bus_remove_device+0xd5/0x120
         device_del+0x159/0x490
         device_unregister+0x12/0x30
         del_device_store+0x11a/0x1a0 [netdevsim]
         kernfs_fop_write_iter+0x130/0x1d0
         vfs_write+0x30b/0x4b0
         ksys_write+0x69/0xf0
         do_syscall_64+0xcc/0x1e0
         entry_SYSCALL_64_after_hwframe+0x6f/0x77
    
    Fixes: b63e78fca889 ("net: netdevsim: use mock PHC driver")
    Signed-off-by: Jakub Kicinski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: micrel: populate .soft_reset for KSZ9131 [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Fri Jan 5 10:52:42 2024 +0200

    net: phy: micrel: populate .soft_reset for KSZ9131
    
    [ Upstream commit e398822c4751017fe401f57409488f5948d12fb5 ]
    
    The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
    is used with the ravb Ethernet driver. It has been discovered that when
    bringing the Ethernet interface down/up continuously, e.g., with the
    following sh script:
    
    $ while :; do ifconfig eth0 down; ifconfig eth0 up; done
    
    the link speed and duplex are wrong after interrupting the bring down/up
    operation even though the Ethernet interface is up. To recover from this
    state the following configuration sequence is necessary (executed
    manually):
    
    $ ifconfig eth0 down
    $ ifconfig eth0 up
    
    The behavior has been identified also on the Microchip SAMA7G5-EK board
    which runs the macb driver and uses the same PHY.
    
    The order of PHY-related operations in ravb_open() is as follows:
    ravb_open() ->
      ravb_phy_start() ->
        ravb_phy_init() ->
          of_phy_connect() ->
            phy_connect_direct() ->
              phy_attach_direct() ->
                phy_init_hw() ->
                  phydev->drv->soft_reset()
                  phydev->drv->config_init()
                  phydev->drv->config_intr()
                phy_resume()
                  kszphy_resume()
    
    The order of PHY-related operations in ravb_close is as follows:
    ravb_close() ->
      phy_stop() ->
        phy_suspend() ->
          kszphy_suspend() ->
            genphy_suspend()
              // set BMCR_PDOWN bit in MII_BMCR
    
    In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
    to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
    Thus, when opening the interface after it has been  previously closed (via
    ravb_close()), the phydev->drv->config_init() and
    phydev->drv->config_intr() reach the KSZ9131 PHY driver via the
    ksz9131_config_init() and kszphy_config_intr() functions.
    
    KSZ9131 specifies that the MII management interface remains operational
    during SPD (Software Power-Down), but (according to manual):
    - Only access to the standard registers (0 through 31) is supported.
    - Access to MMD address spaces other than MMD address space 1 is possible
      if the spd_clock_gate_override bit is set.
    - Access to MMD address space 1 is not possible.
    
    The spd_clock_gate_override bit is not used in the KSZ9131 driver.
    
    ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
    accessesing MMD registers other than those in address space 1.
    
    The datasheet for the KSZ9131 does not specify what happens if registers
    from an unsupported address space are accessed while the PHY is in SPD.
    
    To fix the issue the .soft_reset method has been instantiated for KSZ9131,
    too. This resets the PHY to the default state before doing any
    configurations to it, thus switching it out of SPD.
    
    Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
    Signed-off-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Maxime Chevallier <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qualcomm: rmnet: fix global oob in rmnet_policy [+ + +]
Author: Lin Ma <[email protected]>
Date:   Wed Jan 10 14:14:00 2024 +0800

    net: qualcomm: rmnet: fix global oob in rmnet_policy
    
    [ Upstream commit b33fb5b801c6db408b774a68e7c8722796b59ecc ]
    
    The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
    global out-of-bounds read when parsing the netlink attributes. See bug
    trace below:
    
    ==================================================================
    BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
    BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
    Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
    
    CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:284 [inline]
     print_report+0x172/0x475 mm/kasan/report.c:395
     kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
     validate_nla lib/nlattr.c:386 [inline]
     __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
     __nla_parse+0x3e/0x50 lib/nlattr.c:697
     nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
     __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
     rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
     rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
     netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0x154/0x190 net/socket.c:734
     ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
     ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
     __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fdcf2072359
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
    RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
    RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
     </TASK>
    
    The buggy address belongs to the variable:
     rmnet_policy+0x30/0xe0
    
    The buggy address belongs to the physical page:
    page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
    flags: 0x200000000001000(reserved|node=0|zone=2)
    raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
    raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
     ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
    >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
                                                     ^
     ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
     ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
    
    According to the comment of `nla_parse_nested_deprecated`, the maxtype
    should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.
    
    Fixes: 14452ca3b5ce ("net: qualcomm: rmnet: Export mux_id and flags to netlink")
    Signed-off-by: Lin Ma <[email protected]>
    Reviewed-by: Subash Abhinov Kasiviswanathan <[email protected]>
    Reviewed-by: Simon Horman <[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: ravb: Fix dma_addr_t truncation in error case [+ + +]
Author: Nikita Yushchenko <[email protected]>
Date:   Sat Jan 13 10:22:21 2024 +0600

    net: ravb: Fix dma_addr_t truncation in error case
    
    [ Upstream commit e327b2372bc0f18c30433ac40be07741b59231c5 ]
    
    In ravb_start_xmit(), ravb driver uses u32 variable to store result of
    dma_map_single() call. Since ravb hardware has 32-bit address fields in
    descriptors, this works properly when mapping is successful - it is
    platform's job to provide mapping addresses that fit into hardware
    limitations.
    
    However, in failure case dma_map_single() returns DMA_MAPPING_ERROR
    constant that is 64-bit when dma_addr_t is 64-bit. Storing this constant
    in u32 leads to truncation, and further call to dma_mapping_error()
    fails to notice the error.
    
    Fix that by storing result of dma_map_single() in a dma_addr_t
    variable.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Nikita Yushchenko <[email protected]>
    Reviewed-by: Niklas Söderlund <[email protected]>
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls [+ + +]
Author: Qiang Ma <[email protected]>
Date:   Fri Jan 12 10:12:49 2024 +0800

    net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls
    
    [ Upstream commit a23aa04042187cbde16f470b49d4ad60d32e9206 ]
    
    We found the following dmesg calltrace when testing the GMAC NIC notebook:
    
    [9.448656] ------------[ cut here ]------------
    [9.448658] Unbalanced IRQ 43 wake disable
    [9.448673] WARNING: CPU: 3 PID: 1083 at kernel/irq/manage.c:688 irq_set_irq_wake+0xe0/0x128
    [9.448717] CPU: 3 PID: 1083 Comm: ethtool Tainted: G           O      4.19 #1
    [9.448773]         ...
    [9.448774] Call Trace:
    [9.448781] [<9000000000209b5c>] show_stack+0x34/0x140
    [9.448788] [<9000000000d52700>] dump_stack+0x98/0xd0
    [9.448794] [<9000000000228610>] __warn+0xa8/0x120
    [9.448797] [<9000000000d2fb60>] report_bug+0x98/0x130
    [9.448800] [<900000000020a418>] do_bp+0x248/0x2f0
    [9.448805] [<90000000002035f4>] handle_bp_int+0x4c/0x78
    [9.448808] [<900000000029ea40>] irq_set_irq_wake+0xe0/0x128
    [9.448813] [<9000000000a96a7c>] stmmac_set_wol+0x134/0x150
    [9.448819] [<9000000000be6ed0>] dev_ethtool+0x1368/0x2440
    [9.448824] [<9000000000c08350>] dev_ioctl+0x1f8/0x3e0
    [9.448827] [<9000000000bb2a34>] sock_ioctl+0x2a4/0x450
    [9.448832] [<900000000046f044>] do_vfs_ioctl+0xa4/0x738
    [9.448834] [<900000000046f778>] ksys_ioctl+0xa0/0xe8
    [9.448837] [<900000000046f7d8>] sys_ioctl+0x18/0x28
    [9.448840] [<9000000000211ab4>] syscall_common+0x20/0x34
    [9.448842] ---[ end trace 40c18d9aec863c3e ]---
    
    Multiple disable_irq_wake() calls will keep decreasing the IRQ
    wake_depth, When wake_depth is 0, calling disable_irq_wake() again,
    will report the above calltrace.
    
    Due to the need to appear in pairs, we cannot call disable_irq_wake()
    without calling enable_irq_wake(). Fix this by making sure there are
    no unbalanced disable_irq_wake() calls.
    
    Fixes: 3172d3afa998 ("stmmac: support wake up irq from external sources (v3)")
    Signed-off-by: Qiang Ma <[email protected]>
    Reviewed-by: Simon Horman <[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: stmmac: Fix ethool link settings ops for integrated PCS [+ + +]
Author: Sneh Shah <[email protected]>
Date:   Tue Jan 9 20:17:29 2024 +0530

    net: stmmac: Fix ethool link settings ops for integrated PCS
    
    [ Upstream commit 08300adac3b8dab9e2fd3be0155c7d3093c755f4 ]
    
    Currently get/set_link_ksettings ethtool ops are dependent on PCS.
    When PCS is integrated, it will not have separate link config.
    Bypass configuring and checking PCS for integrated PCS.
    
    Fixes: aa571b6275fb ("net: stmmac: add new switch to struct plat_stmmacenet_data")
    Tested-by: Andrew Halaney <[email protected]> # sa8775p-ride
    Signed-off-by: Sneh Shah <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: fix ethtool per-queue statistics [+ + +]
Author: Petr Tesarik <[email protected]>
Date:   Fri Jan 5 21:16:42 2024 +0100

    net: stmmac: fix ethtool per-queue statistics
    
    commit 61921bdaa132b580b6db6858e6d7dcdb870df5fe upstream.
    
    Fix per-queue statistics for devices with more than one queue.
    
    The output data pointer is currently reset in each loop iteration,
    effectively summing all queue statistics in the first four u64 values.
    
    The summary values are not even labeled correctly. For example, if eth0 has
    2 queues, ethtool -S eth0 shows:
    
         q0_tx_pkt_n: 374 (actually tx_pkt_n over all queues)
         q0_tx_irq_n: 23  (actually tx_normal_irq_n over all queues)
         q1_tx_pkt_n: 462 (actually rx_pkt_n over all queues)
         q1_tx_irq_n: 446 (actually rx_normal_irq_n over all queues)
         q0_rx_pkt_n: 0
         q0_rx_irq_n: 0
         q1_rx_pkt_n: 0
         q1_rx_irq_n: 0
    
    Fixes: 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics where necessary")
    Cc: [email protected]
    Signed-off-by: Petr Tesarik <[email protected]>
    Reviewed-by: Jisheng Zhang <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: stmmac: Prevent DSA tags from breaking COE [+ + +]
Author: Romain Gantois <[email protected]>
Date:   Tue Jan 16 13:19:17 2024 +0100

    net: stmmac: Prevent DSA tags from breaking COE
    
    commit c2945c435c999c63e47f337bc7c13c98c21d0bcc upstream.
    
    Some DSA tagging protocols change the EtherType field in the MAC header
    e.g.  DSA_TAG_PROTO_(DSA/EDSA/BRCM/MTK/RTL4C_A/SJA1105). On TX these tagged
    frames are ignored by the checksum offload engine and IP header checker of
    some stmmac cores.
    
    On RX, the stmmac driver wrongly assumes that checksums have been computed
    for these tagged packets, and sets CHECKSUM_UNNECESSARY.
    
    Add an additional check in the stmmac TX and RX hotpaths so that COE is
    deactivated for packets with ethertypes that will not trigger the COE and
    IP header checks.
    
    Fixes: 6b2c6e4a938f ("net: stmmac: propagate feature flags to vlan")
    Cc:  <[email protected]>
    Reported-by: Richard Tresidder <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Reported-by: Romain Gantois <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Reviewed-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Romain Gantois <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: tls, fix WARNIING in __sk_msg_free [+ + +]
Author: John Fastabend <[email protected]>
Date:   Fri Jan 12 16:32:57 2024 -0800

    net: tls, fix WARNIING in __sk_msg_free
    
    [ Upstream commit dc9dfc8dc629e42f2234e3327b75324ffc752bc9 ]
    
    A splice with MSG_SPLICE_PAGES will cause tls code to use the
    tls_sw_sendmsg_splice path in the TLS sendmsg code to move the user
    provided pages from the msg into the msg_pl. This will loop over the
    msg until msg_pl is full, checked by sk_msg_full(msg_pl). The user
    can also set the MORE flag to hint stack to delay sending until receiving
    more pages and ideally a full buffer.
    
    If the user adds more pages to the msg than can fit in the msg_pl
    scatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send
    the buffer anyways.
    
    What actually happens though is we abort the msg to msg_pl scatterlist
    setup and then because we forget to set 'full record' indicating we
    can no longer consume data without a send we fallthrough to the 'continue'
    path which will check if msg_data_left(msg) has more bytes to send and
    then attempts to fit them in the already full msg_pl. Then next
    iteration of sender doing send will encounter a full msg_pl and throw
    the warning in the syzbot report.
    
    To fix simply check if we have a full_record in splice code path and
    if not send the msg regardless of MORE flag.
    
    Reported-and-tested-by: [email protected]
    Reported-by: Edward Adam Davis <[email protected]>
    Fixes: fe1e81d4f73b ("tls/sw: Support MSG_SPLICE_PAGES")
    Reviewed-by: Jakub Kicinski <[email protected]>
    Signed-off-by: John Fastabend <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: bridge: replace physindev with physinif in nf_bridge_info [+ + +]
Author: Pavel Tikhomirov <[email protected]>
Date:   Thu Jan 11 23:06:40 2024 +0800

    netfilter: bridge: replace physindev with physinif in nf_bridge_info
    
    [ Upstream commit 9874808878d9eed407e3977fd11fee49de1e1d86 ]
    
    An skb can be added to a neigh->arp_queue while waiting for an arp
    reply. Where original skb's skb->dev can be different to neigh's
    neigh->dev. For instance in case of bridging dnated skb from one veth to
    another, the skb would be added to a neigh->arp_queue of the bridge.
    
    As skb->dev can be reset back to nf_bridge->physindev and used, and as
    there is no explicit mechanism that prevents this physindev from been
    freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
    different device's neigh queue) we can crash on e.g. this stack:
    
    arp_process
      neigh_update
        skb = __skb_dequeue(&neigh->arp_queue)
          neigh_resolve_output(..., skb)
            ...
              br_nf_dev_xmit
                br_nf_pre_routing_finish_bridge_slow
                  skb->dev = nf_bridge->physindev
                  br_handle_frame_finish
    
    Let's use plain ifindex instead of net_device link. To peek into the
    original net_device we will use dev_get_by_index_rcu(). Thus either we
    get device and are safe to use it or we don't get it and drop skb.
    
    Fixes: c4e70a87d975 ("netfilter: bridge: rename br_netfilter.c to br_netfilter_hooks.c")
    Suggested-by: Florian Westphal <[email protected]>
    Signed-off-by: Pavel Tikhomirov <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_queue: remove excess nf_bridge variable [+ + +]
Author: Pavel Tikhomirov <[email protected]>
Date:   Thu Jan 11 23:06:38 2024 +0800

    netfilter: nf_queue: remove excess nf_bridge variable
    
    [ Upstream commit aeaa44075f8e49e2e0ad4507d925e690b7950145 ]
    
    We don't really need nf_bridge variable here. And nf_bridge_info_exists
    is better replacement for nf_bridge_info_get in case we are only
    checking for existence.
    
    Signed-off-by: Pavel Tikhomirov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Stable-dep-of: 9874808878d9 ("netfilter: bridge: replace physindev with physinif in nf_bridge_info")
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: check if catch-all set element is active in next generation [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Fri Jan 12 23:28:45 2024 +0100

    netfilter: nf_tables: check if catch-all set element is active in next generation
    
    commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7 upstream.
    
    When deactivating the catch-all set element, check the state in the next
    generation that represents this transaction.
    
    This bug uncovered after the recent removal of the element busy mark
    a2dd0233cbc4 ("netfilter: nf_tables: remove busy mark and gc batch API").
    
    Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support")
    Cc: [email protected]
    Reported-by: lonial con <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

netfilter: nf_tables: do not allow mismatch field size and set key length [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Jan 14 23:53:39 2024 +0100

    netfilter: nf_tables: do not allow mismatch field size and set key length
    
    [ Upstream commit 3ce67e3793f48c1b9635beb9bb71116ca1e51b58 ]
    
    The set description provides the size of each field in the set whose sum
    should not mismatch the set key length, bail out otherwise.
    
    I did not manage to crash nft_set_pipapo with mismatch fields and set key
    length so far, but this is UB which must be disallowed.
    
    Fixes: f3a2181e16f1 ("netfilter: nf_tables: Support for sets with multiple ranged fields")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: mark newset as dead on transaction abort [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Mon Nov 27 11:00:37 2023 +0100

    netfilter: nf_tables: mark newset as dead on transaction abort
    
    [ Upstream commit 08e4c8c5919fd405a4d709b4ba43d836894a26eb ]
    
    If a transaction is aborted, we should mark the to-be-released NEWSET dead,
    just like commit path does for DEL and DESTROYSET commands.
    
    In both cases all remaining elements will be released via
    set->ops->destroy().
    
    The existing abort code does NOT post the actual release to the work queue.
    Also the entire __nf_tables_abort() function is wrapped in gc_seq
    begin/end pair.
    
    Therefore, async gc worker will never try to release the pending set
    elements, as gc sequence is always stale.
    
    It might be possible to speed up transaction aborts via work queue too,
    this would result in a race and a possible use-after-free.
    
    So fix this before it becomes an issue.
    
    Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject invalid set policy [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Wed Jan 3 23:34:58 2024 +0100

    netfilter: nf_tables: reject invalid set policy
    
    [ Upstream commit 0617c3de9b4026b87be12b0cb5c35f42c7c66fcb ]
    
    Report -EINVAL in case userspace provides a unsupported set backend
    policy.
    
    Fixes: c50b960ccc59 ("netfilter: nf_tables: implement proper set selection")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Mon Jan 15 12:50:29 2024 +0100

    netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description
    
    [ Upstream commit 113661e07460a6604aacc8ae1b23695a89e7d4b3 ]
    
    It is still possible to set on the NFT_SET_CONCAT flag by specifying a
    set size and no field description, report EINVAL in such case.
    
    Fixes: 1b6345d4160e ("netfilter: nf_tables: check NFT_SET_CONCAT flag if field_count is specified")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: skip dead set elements in netlink dump [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Mon Jan 15 00:14:38 2024 +0100

    netfilter: nf_tables: skip dead set elements in netlink dump
    
    [ Upstream commit 6b1ca88e4bb63673dc9f9c7f23c899f22c3cb17a ]
    
    Delete from packet path relies on the garbage collector to purge
    elements with NFT_SET_ELEM_DEAD_BIT on.
    
    Skip these dead elements from nf_tables_dump_setelem() path, I very
    rarely see tests/shell/testcases/maps/typeof_maps_add_delete reports
    [DUMP FAILED] showing a mismatch in the expected output with an element
    that should not be there.
    
    If the netlink dump happens before GC worker run, it might show dead
    elements in the ruleset listing.
    
    nft_rhash_get() already skips dead elements in nft_rhash_cmp(),
    therefore, it already does not show the element when getting a single
    element via netlink control plane.
    
    Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: validate chain type update if available [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Dec 14 22:43:22 2023 +0100

    netfilter: nf_tables: validate chain type update if available
    
    [ Upstream commit aaba7ddc8507f4ad5bbd07988573967632bc2385 ]
    
    Parse netlink attribute containing the chain type in this update, to
    bail out if this is different from the existing type.
    
    Otherwise, it is possible to define a chain with the same name, hook and
    priority but different type, which is silently ignored.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nfnetlink_log: use proper helper for fetching physinif [+ + +]
Author: Pavel Tikhomirov <[email protected]>
Date:   Thu Jan 11 23:06:37 2024 +0800

    netfilter: nfnetlink_log: use proper helper for fetching physinif
    
    [ Upstream commit c3f9fd54cd87233f53bdf0e191a86b3a5e960e02 ]
    
    We don't use physindev in __build_packet_message except for getting
    physinif from it. So let's switch to nf_bridge_get_physinif to get what
    we want directly.
    
    Signed-off-by: Pavel Tikhomirov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Stable-dep-of: 9874808878d9 ("netfilter: bridge: replace physindev with physinif in nf_bridge_info")
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_limit: do not ignore unsupported flags [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Wed Jan 10 00:42:37 2024 +0100

    netfilter: nft_limit: do not ignore unsupported flags
    
    [ Upstream commit 91a139cee1202a4599a380810d93c69b5bac6197 ]
    
    Bail out if userspace provides unsupported flags, otherwise future
    extensions to the limit expression will be silently ignored by the
    kernel.
    
    Fixes: c7862a5f0de5 ("netfilter: nft_limit: allow to invert matching criteria")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: propagate net to nf_bridge_get_physindev [+ + +]
Author: Pavel Tikhomirov <[email protected]>
Date:   Thu Jan 11 23:06:39 2024 +0800

    netfilter: propagate net to nf_bridge_get_physindev
    
    [ Upstream commit a54e72197037d2c9bfcd70dddaac8c8ccb5b41ba ]
    
    This is a preparation patch for replacing physindev with physinif on
    nf_bridge_info structure. We will use dev_get_by_index_rcu to resolve
    device, when needed, and it requires net to be available.
    
    Signed-off-by: Pavel Tikhomirov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Stable-dep-of: 9874808878d9 ("netfilter: bridge: replace physindev with physinif in nf_bridge_info")
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Use parent's objective cred in nfs_access_login_time() [+ + +]
Author: Scott Mayhew <[email protected]>
Date:   Tue Dec 5 09:10:54 2023 -0500

    NFS: Use parent's objective cred in nfs_access_login_time()
    
    [ Upstream commit a10a9233073d984b239e22358ba21825e27e2e88 ]
    
    The subjective cred (task->cred) can potentially be overridden and
    subsquently freed in non-RCU context, which could lead to a panic if we
    try to use it in cred_fscmp().  Use __task_cred(), which returns the
    objective cred (task->real_cred) instead.
    
    Fixes: 0eb43812c027 ("NFS: Clear the file access cache upon login")
    Fixes: 5e9a7b9c2ea1 ("NFS: Fix up a sparse warning")
    
    Signed-off-by: Scott Mayhew <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Wed Nov 15 13:55:29 2023 -0500

    NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT
    
    [ Upstream commit 037e56a22ff37f9a9c2330b66cff55d3d1ff9b90 ]
    
    Once the client has processed the CB_LAYOUTRECALL, but has not yet
    successfully returned the layout, the server is supposed to switch to
    returning NFS4ERR_RETURNCONFLICT. This patch ensures that we handle
    that return value correctly.
    
    Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
null_blk: don't cap max_hw_sectors to BLK_DEF_MAX_SECTORS [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Wed Dec 27 09:23:02 2023 +0000

    null_blk: don't cap max_hw_sectors to BLK_DEF_MAX_SECTORS
    
    [ Upstream commit 9a9525de865410047fa962867b4fcd33943b206f ]
    
    null_blk has some rather odd capping of the max_hw_sectors value to
    BLK_DEF_MAX_SECTORS, which doesn't make sense - max_hw_sector is the
    hardware limit, and BLK_DEF_MAX_SECTORS despite the confusing name is the
    default cap for the max_sectors field used for normal file system I/O.
    
    Remove all the capping, and simply leave it to the block layer or
    user to take up or not all of that for file system I/O.
    
    Fixes: ea17fd354ca8 ("null_blk: Allow controlling max_hw_sectors limit")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: trace: avoid memcpy overflow warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jan 3 16:56:56 2024 +0100

    nvme: trace: avoid memcpy overflow warning
    
    [ Upstream commit a7de1dea76cd6a3707707af4ea2f8bc3cdeaeb11 ]
    
    A previous patch introduced a struct_group() in nvme_common_command to help
    stringop fortification figure out the length of the fields, but one function
    is not currently using them:
    
    In file included from drivers/nvme/target/core.c:7:
    In file included from include/linux/string.h:254:
    include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
                            __read_overflow2_field(q_size_field, size);
                            ^
    
    Change this one to use the correct field name to avoid the warning.
    
    Fixes: 5c629dc9609dc ("nvme: use struct group for generic command dwords")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet-tcp: fix a crash in nvmet_req_complete() [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Fri Dec 22 16:17:49 2023 +0100

    nvmet-tcp: fix a crash in nvmet_req_complete()
    
    [ Upstream commit 0849a5441358cef02586fb2d60f707c0db195628 ]
    
    in nvmet_tcp_handle_h2c_data_pdu(), if the host sends a data_offset
    different from rbytes_done, the driver ends up calling nvmet_req_complete()
    passing a status error.
    The problem is that at this point cmd->req is not yet initialized,
    the kernel will crash after dereferencing a NULL pointer.
    
    Fix the bug by replacing the call to nvmet_req_complete() with
    nvmet_tcp_fatal_error().
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Reviewed-by: Keith Busch <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Fri Dec 22 16:17:48 2023 +0100

    nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
    
    [ Upstream commit efa56305908ba20de2104f1b8508c6a7401833be ]
    
    If the host sends an H2CData command with an invalid DATAL,
    the kernel may crash in nvmet_tcp_build_pdu_iovec().
    
    Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000000
    lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]
    Call trace:
      process_one_work+0x174/0x3c8
      worker_thread+0x2d0/0x3e8
      kthread+0x104/0x110
    
    Fix the bug by raising a fatal error if DATAL isn't coherent
    with the packet size.
    Also, the PDU length should never exceed the MAXH2CDATA parameter which
    has been communicated to the host in nvmet_tcp_handle_icreq().
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet-tcp: fix a missing endianess conversion in nvmet_tcp_try_peek_pdu [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Tue Dec 26 08:13:29 2023 +0000

    nvmet-tcp: fix a missing endianess conversion in nvmet_tcp_try_peek_pdu
    
    [ Upstream commit 3a96bff229d6e3016805fd6c3dba0655ccba01eb ]
    
    No, a __le32 cast doesn't magically byteswap on big-endian systems..
    
    Fixes: 70525e5d82f6 ("nvmet-tcp: peek icreq before starting TLS")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet-tcp: Fix the H2C expected PDU len calculation [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Fri Jan 5 09:14:44 2024 +0100

    nvmet-tcp: Fix the H2C expected PDU len calculation
    
    [ Upstream commit 9a1abc24850eb759e36a2f8869161c3b7254c904 ]
    
    The nvmet_tcp_handle_h2c_data_pdu() function should take into
    consideration the possibility that the header digest and/or the data
    digests are enabled when calculating the expected PDU length, before
    comparing it to the value stored in cmd->pdu_len.
    
    Fixes: efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet: re-fix tracing strncpy() warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jan 3 16:56:55 2024 +0100

    nvmet: re-fix tracing strncpy() warning
    
    [ Upstream commit 4ee7ffeb4ce50c80bc4504db6f39b25a2df6bcf4 ]
    
    An earlier patch had tried to address a warning about a string copy with
    missing zero termination:
    
    drivers/nvme/target/trace.h:52:3: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
    
    The new version causes a different warning with some compiler versions, notably
    gcc-9 and gcc-10, and also misses the zero padding that was apparently done
    intentionally in the original code:
    
    drivers/nvme/target/trace.h:56:2: error: 'strncpy' specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
    
    Change it to use strscpy_pad() with the original length, which will give
    a properly padded and zero-terminated string as well as avoiding the warning.
    
    Fixes: d86481e924a7 ("nvmet: use min of device_path and disk len")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-af: CN10KB: Fix FIFO length calculation for RPM2 [+ + +]
Author: Nithin Dabilpuram <[email protected]>
Date:   Mon Jan 8 13:00:36 2024 +0530

    octeontx2-af: CN10KB: Fix FIFO length calculation for RPM2
    
    [ Upstream commit a0cb76a770083a22167659e64ba69af6425b1d9b ]
    
    RPM0 and RPM1 on the CN10KB SoC have 8 LMACs each, whereas RPM2
    has only 4 LMACs. Similarly, the RPM0 and RPM1 have 256KB FIFO,
    whereas RPM2 has 128KB FIFO. This patch fixes an issue with
    improper TX credit programming for the RPM2 link.
    
    Fixes: b9d0fedc6234 ("octeontx2-af: cn10kb: Add RPM_USX MAC support")
    Signed-off-by: Nithin Dabilpuram <[email protected]>
    Signed-off-by: Naveen Mamindlapalli <[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]>

 
of: Fix double free in of_parse_phandle_with_args_map [+ + +]
Author: Christian A. Ehrhardt <[email protected]>
Date:   Fri Dec 29 11:54:11 2023 +0100

    of: Fix double free in of_parse_phandle_with_args_map
    
    [ Upstream commit 4dde83569832f9377362e50f7748463340c5db6b ]
    
    In of_parse_phandle_with_args_map() the inner loop that
    iterates through the map entries calls of_node_put(new)
    to free the reference acquired by the previous iteration
    of the inner loop. This assumes that the value of "new" is
    NULL on the first iteration of the inner loop.
    
    Make sure that this is true in all iterations of the outer
    loop by setting "new" to NULL after its value is assigned to "cur".
    
    Extend the unittest to detect the double free and add an additional
    test case that actually triggers this path.
    
    Fixes: bd6f2fd5a1 ("of: Support parsing phandle argument lists through a nexus node")
    Cc: Stephen Boyd <[email protected]>
    Signed-off-by: "Christian A. Ehrhardt" <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Herring <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

of: unittest: Fix of_count_phandle_with_args() expected value message [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 11 09:50:25 2024 +0100

    of: unittest: Fix of_count_phandle_with_args() expected value message
    
    [ Upstream commit 716089b417cf98d01f0dc1b39f9c47e1d7b4c965 ]
    
    The expected result value for the call to of_count_phandle_with_args()
    was updated from 7 to 8, but the accompanying error message was
    forgotten.
    
    Fixes: 4dde83569832f937 ("of: Fix double free in of_parse_phandle_with_args_map")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Herring <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/P2PDMA: Remove reference to pci_p2pdma_map_sg() [+ + +]
Author: Tadeusz Struk <[email protected]>
Date:   Mon Nov 13 19:03:25 2023 +0100

    PCI/P2PDMA: Remove reference to pci_p2pdma_map_sg()
    
    commit 9a000a72af75886e5de13f4edef7f0d788622e7d upstream.
    
    Update Documentation/driver-api/pci/p2pdma.rst doc and remove references to
    obsolete p2pdma mapping functions.
    
    Fixes: 0d06132fc84b ("PCI/P2PDMA: Remove pci_p2pdma_[un]map_sg()")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tadeusz Struk <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: Avoid potential out-of-bounds read in pci_dev_for_each_resource() [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Mon Oct 30 13:42:18 2023 +0200

    PCI: Avoid potential out-of-bounds read in pci_dev_for_each_resource()
    
    [ Upstream commit 3171e46d677a668eed3086da78671f1e4f5b8405 ]
    
    Coverity complains that pointer in the pci_dev_for_each_resource() may be
    wrong, i.e., might be used for the out-of-bounds read.
    
    There is no actual issue right now because we have another check afterwards
    and the out-of-bounds read is not being performed. In any case it's better
    code with this fixed, hence the proposed change.
    
    As Jonas pointed out "It probably makes the code slightly less performant
    as res will now be checked for being not NULL (which will always be true),
    but I doubt it will be significant (or in any hot paths)."
    
    Fixes: 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()")
    Reported-by: Bjorn Helgaas <[email protected]>
    Closes: https://lore.kernel.org/r/20230509182122.GA1259567@bhelgaas
    Suggested-by: Jonas Gorski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Tue Nov 28 14:22:30 2023 +0100

    PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support
    
    commit 2217fffcd63f86776c985d42e76daa43a56abdf1 upstream.
    
    Commit 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get
    correct MSI-X table address") modified dw_pcie_ep_raise_msix_irq() to
    support iATUs which require a specific alignment.
    
    However, this support cannot have been properly tested.
    
    The whole point is for the iATU to map an address that is aligned,
    using dw_pcie_ep_map_addr(), and then let the writel() write to
    ep->msi_mem + aligned_offset.
    
    Thus, modify the address that is mapped such that it is aligned.
    With this change, dw_pcie_ep_raise_msix_irq() matches the logic in
    dw_pcie_ep_raise_msi_irq().
    
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Fixes: 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address")
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Cc: [email protected] # 5.7
    Cc: Kishon Vijay Abraham I <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single() [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Thu Dec 14 12:03:28 2023 +0530

    PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()
    
    [ Upstream commit 327ec5f70609cf00c6f961073c01857555c6a8eb ]
    
    In the error path of pci_epf_mhi_edma_write() function, the DMA data
    direction passed (DMA_FROM_DEVICE) doesn't match the actual direction used
    for the data transfer. Fix it by passing the correct one (DMA_TO_DEVICE).
    
    Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
    Reviewed-by: Krzysztof WilczyÅ„ski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: keystone: Fix race condition when initializing PHYs [+ + +]
Author: Siddharth Vadapalli <[email protected]>
Date:   Wed Sep 27 09:48:45 2023 +0530

    PCI: keystone: Fix race condition when initializing PHYs
    
    [ Upstream commit c12ca110c613a81cb0f0099019c839d078cd0f38 ]
    
    The PCI driver invokes the PHY APIs using the ks_pcie_enable_phy()
    function. The PHY in this case is the Serdes. It is possible that the
    PCI instance is configured for two lane operation across two different
    Serdes instances, using one lane of each Serdes.
    
    In such a configuration, if the reference clock for one Serdes is
    provided by the other Serdes, it results in a race condition. After the
    Serdes providing the reference clock is initialized by the PCI driver by
    invoking its PHY APIs, it is not guaranteed that this Serdes remains
    powered on long enough for the PHY APIs based initialization of the
    dependent Serdes. In such cases, the PLL of the dependent Serdes fails
    to lock due to the absence of the reference clock from the former Serdes
    which has been powered off by the PM Core.
    
    Fix this by obtaining reference to the PHYs before invoking the PHY
    initialization APIs and releasing reference after the initialization is
    complete.
    
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Fixes: 49229238ab47 ("PCI: keystone: Cleanup PHY handling")
    Signed-off-by: Siddharth Vadapalli <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Acked-by: Ravi Gunasekaran <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: mediatek-gen3: Fix translation window size calculation [+ + +]
Author: Jianjun Wang <[email protected]>
Date:   Mon Oct 23 16:14:23 2023 +0800

    PCI: mediatek-gen3: Fix translation window size calculation
    
    [ Upstream commit 9ccc1318cf4bd90601f221268e42c3374703d681 ]
    
    When using the fls() helper, the translation table should be a power of
    two; otherwise, the resulting value will not be correct.
    
    For example, given fls(0x3e00000) - 1 = 25, the PCIe translation window
    size will be set to 0x2000000 instead of the expected size 0x3e00000.
    
    Fix the translation window by splitting the MMIO space into multiple tables
    if its size is not a power of two.
    
    [kwilczynski: commit log]
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
    Signed-off-by: Jianjun Wang <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: mediatek: Clear interrupt status before dispatching handler [+ + +]
Author: qizhong cheng <[email protected]>
Date:   Mon Dec 11 17:49:23 2023 +0800

    PCI: mediatek: Clear interrupt status before dispatching handler
    
    commit 4e11c29873a8a296a20f99b3e03095e65ebf897d upstream.
    
    We found a failure when using the iperf tool during WiFi performance
    testing, where some MSIs were received while clearing the interrupt
    status, and these MSIs cannot be serviced.
    
    The interrupt status can be cleared even if the MSI status remains pending.
    As such, given the edge-triggered interrupt type, its status should be
    cleared before being dispatched to the handler of the underling device.
    
    [kwilczynski: commit log, code comment wording]
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622")
    Signed-off-by: qizhong cheng <[email protected]>
    Signed-off-by: Jianjun Wang <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    [bhelgaas: rewrap comment]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Cc:  <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: xilinx-xdma: Fix error code in xilinx_pl_dma_pcie_init_irq_domain() [+ + +]
Author: Harshit Mogalapalli <[email protected]>
Date:   Mon Oct 30 00:27:57 2023 -0700

    PCI: xilinx-xdma: Fix error code in xilinx_pl_dma_pcie_init_irq_domain()
    
    [ Upstream commit 2324be17b5e05ac682e7c81fcbfc7b36a9b1becb ]
    
    Currently, if the function irq_domain_add_linear() fails to allocate
    a new IRQ domain and returns NULL, we would then still return a success
    from the xilinx_pl_dma_pcie_init_irq_domain() function regardless, as
    the PTR_ERR(NULL) would return a value of zero.  This is not a desirable
    outcome.
    
    Thus, fix the incorrect error code and return the -ENOMEM error code if
    the irq_domain_add_linear() fails to allocate a new IRQ domain.
    
    [kwilczynski: commit log]
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
    Signed-off-by: Harshit Mogalapalli <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-xdma: Fix uninitialized symbols in xilinx_pl_dma_pcie_setup_irq() [+ + +]
Author: Krzysztof WilczyÅ„ski <[email protected]>
Date:   Sat Jan 6 12:43:28 2024 +0000

    PCI: xilinx-xdma: Fix uninitialized symbols in xilinx_pl_dma_pcie_setup_irq()
    
    [ Upstream commit 7aa5f8fcd6d95b713a39fe52c296a6892eda7f02 ]
    
    The error paths that follow calls to the devm_request_irq() functions
    within the xilinx_pl_dma_pcie_setup_irq() reference an uninitialized
    symbol each that also so happens to be incorrect.
    
    Thus, fix this omission and reference the correct variable when invoking
    a given dev_err() function following an error.
    
    This problem was found using smatch via the 0-DAY CI Kernel Test service:
    
      drivers/pci/controller/pcie-xilinx-dma-pl.c:638 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.
      drivers/pci/controller/pcie-xilinx-dma-pl.c:645 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.
    
    Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
    Link: https://lore.kernel.org/oe-kbuild/[email protected]/
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf db-export: Fix missing reference count get in call_path_from_sample() [+ + +]
Author: Ben Gainey <[email protected]>
Date:   Thu Dec 7 14:09:11 2023 +0000

    perf db-export: Fix missing reference count get in call_path_from_sample()
    
    [ Upstream commit 1e24ce402c97dc3c0ab050593f1d5f6fde524564 ]
    
    The addr_location map and maps fields in the inner loop were missing
    calls to map__get()/maps__get(). The subsequent addr_location__exit()
    call in each loop puts the map/maps fields causing use-after-free
    aborts.
    
    This issue reproduces on at least arm64 and x86_64 with something
    simple like `perf record -g ls` followed by `perf script -s script.py`
    with the following script:
    
        perf_db_export_mode = True
        perf_db_export_calls = False
        perf_db_export_callchains = True
    
        def sample_table(*args):
            print(f'sample_table({args})')
    
        def call_path_table(*args):
            print(f'call_path_table({args}')
    
    Committer testing:
    
    This test, just introduced by Ian Rogers, now passes, not segfaulting
    anymore:
    
      # perf test "perf script tests"
       95: perf script tests                                               : Ok
      #
    
    Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions")
    Signed-off-by: Ben Gainey <[email protected]>
    Tested-by: Arnaldo Carvalho de Melo <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf env: Avoid recursively taking env->bpf_progs.lock [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Wed Dec 6 17:46:55 2023 -0800

    perf env: Avoid recursively taking env->bpf_progs.lock
    
    [ Upstream commit 9c51f8788b5d4e9f46afbcf563255cfd355690b3 ]
    
    Add variants of perf_env__insert_bpf_prog_info(), perf_env__insert_btf()
    and perf_env__find_btf prefixed with __ to indicate the
    env->bpf_progs.lock is assumed held.
    
    Call these variants when the lock is held to avoid recursively taking it
    and potentially having a thread deadlock with itself.
    
    Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()")
    Signed-off-by: Ian Rogers <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Huacai Chen <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: K Prateek Nayak <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Ming Wang <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Ravi Bangoria <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf genelf: Set ELF program header addresses properly [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Mon Dec 11 23:05:44 2023 -0800

    perf genelf: Set ELF program header addresses properly
    
    [ Upstream commit 1af478903fc48c1409a8dd6b698383b62387adf1 ]
    
    The text section starts after the ELF headers so PHDR.p_vaddr and
    others should have the correct addresses.
    
    Fixes: babd04386b1df8c3 ("perf jit: Include program header in ELF files")
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Lieven Hey <[email protected]>
    Cc: Milian Wolff <[email protected]>
    Cc: Pablo Galindo <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf header: Fix one memory leakage in perf_event__fprintf_event_update() [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Thu Dec 7 16:16:34 2023 +0800

    perf header: Fix one memory leakage in perf_event__fprintf_event_update()
    
    [ Upstream commit 813900d19b923fc1b241c1ce292472f68066092b ]
    
    When dump the raw trace by `perf report -D` ASan reports a memory
    leakage in perf_event__fprintf_event_update().
    
    It shows that we allocated a temporary cpumap for dumping the CPUs but
    doesn't release it and it's not used elsewhere. Fix this by free the
    cpumap after the dumping.
    
    Fixes: c853f9394b7bc189 ("perf tools: Add perf_event__fprintf_event_update function")
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Yicong Yang <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Cc: Junhao He <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf header: Fix segfault on build_mem_topology() error path [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Thu Nov 23 09:58:41 2023 +0200

    perf header: Fix segfault on build_mem_topology() error path
    
    [ Upstream commit 70df07838fc1c0acfab3325ae79014e241a88bdf ]
    
    Do not increase the node count unless a node has been successfully read,
    because it can lead to a segfault if an error occurs.
    
    For example, if perf exceeds the open file limit in memory_node__read(),
    which, on a test system, could be made to happen by setting the file limit
    to exactly 32:
    
     Before:
    
      $ ulimit -n 32
      $ perf mem record --all-user -- sleep 1
      [ perf record: Woken up 1 times to write data ]
      failed: can't open memory sysfs data
      perf: Segmentation fault
      Obtained 14 stack frames.
      perf(sighandler_dump_stack+0x48) [0x55f4b1f59558]
      /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f4ba1c42520]
      /lib/x86_64-linux-gnu/libc.so.6(free+0x1e) [0x7f4ba1ca53fe]
      perf(+0x178ff4) [0x55f4b1f48ff4]
      perf(+0x179a70) [0x55f4b1f49a70]
      perf(+0x17ef5d) [0x55f4b1f4ef5d]
      perf(+0x85c0b) [0x55f4b1e55c0b]
      perf(cmd_record+0xe1d) [0x55f4b1e5920d]
      perf(cmd_mem+0xc96) [0x55f4b1e80e56]
      perf(+0x130460) [0x55f4b1f00460]
      perf(main+0x689) [0x55f4b1e427d9]
      /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f4ba1c29d90]
      /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f4ba1c29e40]
      perf(_start+0x25) [0x55f4b1e42a25]
      Segmentation fault (core dumped)
      $
    
    After:
    
      $ ulimit -n 32
      $ perf mem record --all-user -- sleep 1
      [ perf record: Woken up 1 times to write data ]
      failed: can't open memory sysfs data
      [ perf record: Captured and wrote 0.005 MB perf.data (11 samples) ]
      $
    
    Fixes: f8e502b9d1b3b197 ("perf header: Ensure bitmaps are freed")
    Signed-off-by: Adrian Hunter <[email protected]>
    Acked-by: Ian Rogers <[email protected]>
    Cc: German Gomez <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf hisi-ptt: Fix one memory leakage in hisi_ptt_process_auxtrace_event() [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Thu Dec 7 16:16:35 2023 +0800

    perf hisi-ptt: Fix one memory leakage in hisi_ptt_process_auxtrace_event()
    
    [ Upstream commit 1bc479d665bc25a9a4e8168d5b400a47491511f9 ]
    
    ASan complains a memory leakage in hisi_ptt_process_auxtrace_event()
    that the data buffer is not freed. Since currently we only support the
    raw dump trace mode, the data buffer is used only within this function.
    So fix this by freeing the data buffer before going out.
    
    Fixes: 5e91e57e68090c0e ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet")
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Yicong Yang <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Cc: Junhao He <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Qi Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf mem: Fix error on hybrid related to availability of mem event in a PMU [+ + +]
Author: Kan Liang <[email protected]>
Date:   Tue Nov 28 12:39:40 2023 -0800

    perf mem: Fix error on hybrid related to availability of mem event in a PMU
    
    [ Upstream commit a4320085a6c694326dd8db46f563d52d1a826f07 ]
    
    The below error can be triggered on a hybrid machine.
    
     $ perf mem record -t load sleep 1
     event syntax error: 'breakpoint/mem-loads,ldlat=30/P'
                                    \___ Bad event or PMU
    
     Unable to find PMU or event on a PMU of 'breakpoint'
    
    In the perf_mem_events__record_args(), the current perf never checks the
    availability of a mem event on a given PMU. All the PMUs will be added
    to the perf mem event list. Perf errors out for the unsupported PMU.
    
    Extend perf_mem_event__supported() and take a PMU into account. Check
    the mem event for each PMU before adding it to the perf mem event list.
    
    Optimize the perf_mem_events__init() a little bit. The function is to
    check whether the mem events are supported in the system. It doesn't
    need to scan all PMUs. Just return with the first supported PMU is good
    enough.
    
    Fixes: 5752c20f3787c9bc ("perf mem: Scan all PMUs instead of just core ones")
    Reported-by: Ammy Yi <[email protected]>
    Signed-off-by: Kan Liang <[email protected]>
    Tested-by: Ammy Yi <[email protected]>
    Acked-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Ravi Bangoria <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf stat: Exit perf stat if parse groups fails [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Wed Dec 6 10:35:33 2023 -0800

    perf stat: Exit perf stat if parse groups fails
    
    [ Upstream commit 0713ab3bd169da82c35eefd012b07b715e4ebcf7 ]
    
    Metrics were added by a callback but commit a4b8cfcabb1d90ec ("perf
    stat: Delay metric parsing") postponed this to allow optimizations based
    on the CPU configuration.
    
    In doing so it stopped errors in metric parsing from causing 'perf stat'
    termination.
    
    This change adds the termination for bad metric names back in.
    
    Fixes: a4b8cfcabb1d90ec ("perf stat: Delay metric parsing")
    Reported-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Ian Rogers <[email protected]>
    Tested-by: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf stat: Fix hard coded LL miss units [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Mon Dec 11 10:12:41 2023 -0800

    perf stat: Fix hard coded LL miss units
    
    [ Upstream commit f2567e12a090f0eb22553a4468d4c4fe04aad906 ]
    
    Copy-paste error where LL cache misses are reported as l1i.
    
    Fixes: 0a57b910807ad163 ("perf stat: Use counts rather than saved_value")
    Suggested-by: Guillaume Endignoux <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Signed-off-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf test record user-regs: Fix mask for vg register [+ + +]
Author: Veronika Molnarova <[email protected]>
Date:   Fri Dec 1 20:46:17 2023 +0100

    perf test record user-regs: Fix mask for vg register
    
    [ Upstream commit 28b01743ca752cea5ab182297d8b912b22f2a2d1 ]
    
    The 'vg' register for arm64 shows up in --user_regs as available when
    masking the variable AT_HWCAP with 1 << 22 returns '1' as done in
    perf_regs.c.
    
    However, in subtests for support of SVE, the check for the 'vg' register
    is done by masking the variable AT_HWCAP with the value 0x200000 which
    is equals to 1 << 21 instead of 1 << 22.
    
    This results in inconsistencies on certain systems where the test
    expects that the 'vg' register is not operational when it is, and
    vice-versa.
    
    During the testing on a machine that the test expected not to have the
    'vg' register available, 'perf record' with the option --user-regs
    showed records for the 'vg' register together with all of the others,
    which means that the mask for the subtest of perf_event_attr is off by
    one.
    
    Change the value of the mask from 0x200000 to 0x400000 to correct it.
    
    Fixes: 9440ebdc333dd12e ("perf test arm64: Add attr tests for new VG register")
    Reviewed-by: Leo Yan <[email protected]>
    Signed-off-by: Veronika Molnarova <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Michael Petlan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf test: Remove atomics from test_loop to avoid test failures [+ + +]
Author: Nick Forrington <[email protected]>
Date:   Thu Nov 2 16:22:24 2023 +0000

    perf test: Remove atomics from test_loop to avoid test failures
    
    [ Upstream commit 72b4ca7e993e94f09bcf6d19fc385a2e8060c71f ]
    
    The current use of atomics can lead to test failures, as tests (such as
    tests/shell/record.sh) search for samples with "test_loop" as the
    top-most stack frame, but find frames related to the atomic operation
    (e.g. __aarch64_ldadd4_relax).
    
    This change simply removes the "count" variable, as it is not necessary.
    
    Fixes: 1962ab6f6e0b39e4 ("perf test workload thloop: Make count increments atomic")
    Reviewed-by: James Clark <[email protected]>
    Signed-off-by: Nick Forrington <[email protected]>
    Acked-by: Leo Yan <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf unwind-libdw: Handle JIT-generated DSOs properly [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Mon Dec 11 23:05:45 2023 -0800

    perf unwind-libdw: Handle JIT-generated DSOs properly
    
    [ Upstream commit c966d23a351a33f8a977fd7efbb6f467132f7383 ]
    
    Usually DSOs are mapped from the beginning of the file, so the base
    address of the DSO can be calculated by map->start - map->pgoff.
    
    However, JIT DSOs which are generated by `perf inject -j`, are mapped
    only the code segment.  This makes unwind-libdw code confusing and
    rejects processing unwinds in the JIT DSOs.  It should use the map
    start address as base for them to fix the confusion.
    
    Fixes: 1fe627da30331024 ("perf unwind: Take pgoff into account when reporting elf to libdwfl")
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Milian Wolff <[email protected]>
    Cc: Pablo Galindo <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf unwind-libunwind: Fix base address for .eh_frame [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Mon Dec 11 23:05:46 2023 -0800

    perf unwind-libunwind: Fix base address for .eh_frame
    
    [ Upstream commit 4fb54994b2360ab5029ee3a959161f6fe6bbb349 ]
    
    The base address of a DSO mapping should start at the start of the file.
    Usually DSOs are mapped from the pgoff 0 so it doesn't matter when it
    uses the start of the map address.
    
    But generated DSOs for JIT codes doesn't start from the 0 so it should
    subtract the offset to calculate the .eh_frame table offsets correctly.
    
    Fixes: dc2cf4ca866f5715 ("perf unwind: Fix segbase for ld.lld linked objects")
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Fangrui Song <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Milian Wolff <[email protected]>
    Cc: Pablo Galindo <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf vendor events arm64 AmpereOne: Rename BPU_FLUSH_MEM_FAULT to GPC_FLUSH_MEM_FAULT [+ + +]
Author: Ilkka Koskinen <[email protected]>
Date:   Thu Nov 30 18:15:49 2023 -0800

    perf vendor events arm64 AmpereOne: Rename BPU_FLUSH_MEM_FAULT to GPC_FLUSH_MEM_FAULT
    
    [ Upstream commit 10a149e4b4a9187940adbfff0f216ccb5a15aa41 ]
    
    The documentation wrongly called the event as BPU_FLUSH_MEM_FAULT and now
    has been fixed. Correct the name in the perf tool as well.
    
    Fixes: a9650b7f6fc09d16 ("perf vendor events arm64: Add AmpereOne core PMU events")
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Ilkka Koskinen <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ilkka Koskinen <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: [email protected]
    Cc: Mark Rutland <[email protected]>
    Cc: Mike Leach <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf vendor events powerpc: Update datasource event name to fix duplicate events [+ + +]
Author: Athira Rajeev <[email protected]>
Date:   Thu Nov 23 21:31:10 2023 +0530

    perf vendor events powerpc: Update datasource event name to fix duplicate events
    
    [ Upstream commit 9eef41014fe01287dae79fe208b9b433b13040bb ]
    
    Running "perf list" on powerpc fails with segfault as below:
    
       $ ./perf list
       Segmentation fault (core dumped)
       $
    
    This happens because of duplicate events in the JSON list.  The powerpc
    JSON event list contains some event with same event name, but different
    event code. They are:
    
    - PM_INST_FROM_L3MISS (Present in datasource and frontend)
    - PM_MRK_DATA_FROM_L2MISS (Present in datasource and marked)
    - PM_MRK_INST_FROM_L3MISS (Present in datasource and marked)
    - PM_MRK_DATA_FROM_L3MISS (Present in datasource and marked)
    
    pmu_events_table__num_events() uses the value from table_pmu->num_entries
    which includes duplicate events as well. This causes issue during "perf
    list" and results in a segmentation fault.
    
    Since both event codes are valid, append _DSRC to the Data Source events
    (datasource.json), so that they would have a unique name.
    
    Also add PM_DATA_FROM_L2MISS_DSRC and PM_DATA_FROM_L3MISS_DSRC events.
    
    With the fix, 'perf list' works as expected.
    
    Fixes: fc143580753348c6 ("perf vendor events power10: Update JSON/events")
    Signed-off-by: Athira Jajeev <[email protected]>
    Tested-by: Disha Goel <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Disha Goel <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kajol Jain <[email protected]>
    Cc: [email protected]
    Cc: Madhavan Srinivasan <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf vendor events: Remove UTF-8 characters from cmn.json [+ + +]
Author: Jing Zhang <[email protected]>
Date:   Thu Dec 21 14:03:13 2023 +0800

    perf vendor events: Remove UTF-8 characters from cmn.json
    
    [ Upstream commit 457caadce7ab71a54ee2d4f032ee4a55b4a28776 ]
    
    cmn.json contains UTF-8 characters in brief description which
    could break the perf build on some distros.
    
    Fix this issue by removing the UTF-8 characters from cmn.json.
    
    without this fix:
    
      $find tools/perf/pmu-events/ -name "*.json" | xargs file -i | grep -v us-ascii
      tools/perf/pmu-events/arch/arm64/arm/cmn/sys/cmn.json:                   application/json; charset=utf-8
    
    with it:
    
      $ file -i tools/perf/pmu-events/arch/arm64/arm/cmn/sys/cmn.json
      tools/perf/pmu-events/arch/arm64/arm/cmn/sys/cmn.json: text/plain; charset=us-ascii
    
    Fixes: 0b4de7bdf46c5215 ("perf jevents: Add support for Arm CMN PMU aliasing")
    Reported-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Jing Zhang <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jing Zhang <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kajol Jain <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Sukadev Bhattiprolu <[email protected]>
    Cc: Thomas Richter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/arm-cmn: Fix HN-F class_occup_id events [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Thu Nov 23 11:58:13 2023 +0000

    perf/arm-cmn: Fix HN-F class_occup_id events
    
    [ Upstream commit 590f23b092401f29e410fd4ca67128fcc45192fc ]
    
    A subtle copy-paste error managed to slip through the reorganisation
    of these patches in development, and not only give some HN-F events
    the wrong type, but use that wrong type before the subsequent patch
    defined it. Too late to fix history, but we can at least fix the bug.
    
    Fixes: b1b7dc38e482 ("perf/arm-cmn: Refactor HN-F event selector macros")
    Reported-by: Jing Zhang <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/5a22439de84ff188ef76674798052448eb03a3e1.1700740693.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology() [+ + +]
Author: Alexander Antonov <[email protected]>
Date:   Mon Nov 27 10:52:45 2023 -0800

    perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology()
    
    [ Upstream commit 1692cf434ba13ee212495b5af795b6a07e986ce4 ]
    
    Get logical socket id instead of physical id in discover_upi_topology()
    to avoid out-of-bound access on 'upi = &type->topology[nid][idx];' line
    that leads to NULL pointer dereference in upi_fill_topology()
    
    Fixes: f680b6e6062e ("perf/x86/intel/uncore: Enable UPI topology discovery for Icelake Server")
    Reported-by: Kyle Meyer <[email protected]>
    Signed-off-by: Alexander Antonov <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Tested-by: Kyle Meyer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86/intel/vsec: Fix xa_alloc memory leak [+ + +]
Author: David E. Box <[email protected]>
Date:   Wed Nov 29 14:21:13 2023 -0800

    platform/x86/intel/vsec: Fix xa_alloc memory leak
    
    [ Upstream commit 8cbcc1dbf8a62c730fadd60de761e0658547a589 ]
    
    Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery
    support to Intel PMT") added an xarray to track the list of vsec devices to
    be recovered after a PCI error. But it did not provide cleanup for the list
    leading to a memory leak that was caught by kmemleak.  Do xa_alloc() before
    devm_add_action_or_reset() so that the list may be cleaned up with
    xa_erase() in the release function.
    
    Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT")
    Signed-off-by: David E. Box <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [[email protected]: Add missing xa_erase() on error-exit
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pNFS: Fix the pnfs block driver's calculation of layoutget size [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Fri Nov 17 06:25:13 2023 -0500

    pNFS: Fix the pnfs block driver's calculation of layoutget size
    
    [ Upstream commit 8a6291bf3b0eae1bf26621e6419a91682f2d6227 ]
    
    Instead of relying on the value of the 'bytes_left' field, we should
    calculate the layout size based on the offset of the request that is
    being written out.
    
    Reported-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Fixes: 954998b60caa ("NFS: Fix error handling for O_DIRECT write scheduling")
    Reviewed-by: Benjamin Coddington <[email protected]>
    Tested-by: Benjamin Coddington <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: bq256xx: fix some problem in bq256xx_hw_init [+ + +]
Author: Su Hui <[email protected]>
Date:   Thu Nov 16 12:18:23 2023 +0800

    power: supply: bq256xx: fix some problem in bq256xx_hw_init
    
    [ Upstream commit b55d073e6501dc6077edaa945a6dad8ac5c8bbab ]
    
    smatch complains that there is a buffer overflow and clang complains
    'ret' is never read.
    
    Smatch error:
    drivers/power/supply/bq256xx_charger.c:1578 bq256xx_hw_init() error:
    buffer overflow 'bq256xx_watchdog_time' 4 <= 4
    
    Clang static checker:
    Value stored to 'ret' is never read.
    
    Add check for buffer overflow and error code from regmap_update_bits().
    
    Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver")
    Signed-off-by: Su Hui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: cw2015: correct time_to_empty units in sysfs [+ + +]
Author: Jan Palus <[email protected]>
Date:   Sat Nov 11 23:17:04 2023 +0100

    power: supply: cw2015: correct time_to_empty units in sysfs
    
    [ Upstream commit f37669119423ca852ca855b24732f25c0737aa57 ]
    
    RRT_ALRT register holds remaining battery time in minutes therefore it
    needs to be scaled accordingly when exposing TIME_TO_EMPTY via sysfs
    expressed in seconds
    
    Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver")
    Signed-off-by: Jan Palus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: Fix null pointer dereference in smb2_probe [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Fri Nov 24 15:50:21 2023 +0800

    power: supply: Fix null pointer dereference in smb2_probe
    
    [ Upstream commit 88f04bc3e737155e13caddf0ba8ed19db87f0212 ]
    
    devm_kasprintf and devm_kzalloc return a pointer to dynamically
    allocated memory which can be NULL upon failure.
    
    Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver")
    Signed-off-by: Kunwu Chan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/44x: select I2C for CURRITUCK [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Thu Nov 30 21:51:59 2023 -0800

    powerpc/44x: select I2C for CURRITUCK
    
    [ Upstream commit 4a74197b65e69c46fe6e53f7df2f4d6ce9ffe012 ]
    
    Fix build errors when CURRITUCK=y and I2C is not builtin (=m or is
    not set). Fixes these build errors:
    
    powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `avr_halt_system':
    ppc476.c:(.text+0x58): undefined reference to `i2c_smbus_write_byte_data'
    powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `ppc47x_device_probe':
    ppc476.c:(.init.text+0x18): undefined reference to `i2c_register_driver'
    
    Fixes: 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: lore.kernel.org/r/[email protected]
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/64s: Increase default stack size to 32KB [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Fri Dec 15 23:44:49 2023 +1100

    powerpc/64s: Increase default stack size to 32KB
    
    commit 18f14afe281648e31ed35c9ad2fcb724c4838ad9 upstream.
    
    There are reports of kernels crashing due to stack overflow while
    running OpenShift (Kubernetes). The primary contributor to the stack
    usage seems to be openvswitch, which is used by OVN-Kubernetes (based on
    OVN (Open Virtual Network)), but NFS also contributes in some stack
    traces.
    
    There may be some opportunities to reduce stack usage in the openvswitch
    code, but doing so potentially require tradeoffs vs performance, and
    also requires testing across architectures.
    
    Looking at stack usage across the kernel (using -fstack-usage), shows
    that ppc64le stack frames are on average 50-100% larger than the
    equivalent function built for x86-64. Which is not surprising given the
    minimum stack frame size is 32 bytes on ppc64le vs 16 bytes on x86-64.
    
    So increase the default stack size to 32KB for the modern 64-bit Book3S
    platforms, ie. pseries (virtualised) and powernv (bare metal). That
    leaves the older systems like G5s, and the AmigaOne (pasemi) with a 16KB
    stack which should be sufficient on those machines.
    
    Signed-off-by: Michael Ellerman <[email protected]>
    Signed-off-by: Aneesh Kumar K.V (IBM) <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/hv-gpci: Add return value check in affinity_domain_via_partition_show function [+ + +]
Author: Kajol Jain <[email protected]>
Date:   Thu Nov 16 17:50:32 2023 +0530

    powerpc/hv-gpci: Add return value check in affinity_domain_via_partition_show function
    
    [ Upstream commit 070b71f428facd9130319707db854ed8bd24637a ]
    
    To access hv-gpci kernel interface files data, the
    "Enable Performance Information Collection" option has to be set
    in hmc. Incase that option is not set and user try to read
    the interface files, it should give error message as
    operation not permitted.
    
    Result of accessing added interface files with disabled
    performance collection option:
    
    [command]# cat processor_bus_topology
    cat: processor_bus_topology: Operation not permitted
    
    [command]# cat processor_config
    cat: processor_config: Operation not permitted
    
    [command]# cat affinity_domain_via_domain
    cat: affinity_domain_via_domain: Operation not permitted
    
    [command]# cat affinity_domain_via_virtual_processor
    cat: affinity_domain_via_virtual_processor: Operation not permitted
    
    [command]# cat affinity_domain_via_partition
    
    Based on above result there is no error message when reading
    affinity_domain_via_partition file because of missing
    check for failed hcall. Fix this issue by adding
    a check in the start of affinity_domain_via_partition_show
    function, to return error incase hcall fails, with error type
    other then H_PARAMETER.
    
    Fixes: a15e0d6a6929 ("powerpc/hv_gpci: Add sysfs file inside hv_gpci device to show affinity domain via partition information")
    Reported-by: Disha Goel <[email protected]>
    Signed-off-by: Kajol Jain <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/imc-pmu: Add a null pointer check in update_events_in_group() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Sun Nov 26 17:37:19 2023 +0800

    powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
    
    [ Upstream commit 0a233867a39078ebb0f575e2948593bbff5826b3 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support")
    Signed-off-by: Kunwu Chan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/powernv: Add a null pointer check in opal_event_init() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Mon Nov 27 11:07:55 2023 +0800

    powerpc/powernv: Add a null pointer check in opal_event_init()
    
    [ Upstream commit 8649829a1dd25199bbf557b2621cedb4bf9b3050 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 2717a33d6074 ("powerpc/opal-irqchip: Use interrupt names if present")
    Signed-off-by: Kunwu Chan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

powerpc/powernv: Add a null pointer check in opal_powercap_init() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Sun Nov 26 17:57:39 2023 +0800

    powerpc/powernv: Add a null pointer check in opal_powercap_init()
    
    [ Upstream commit e123015c0ba859cf48aa7f89c5016cc6e98e018d ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: b9ef7b4b867f ("powerpc: Convert to using %pOFn instead of device_node.name")
    Signed-off-by: Kunwu Chan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

powerpc/powernv: Add a null pointer check to scom_debug_init_one() [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Fri Dec 8 16:59:37 2023 +0800

    powerpc/powernv: Add a null pointer check to scom_debug_init_one()
    
    [ Upstream commit 9a260f2dd827bbc82cc60eb4f4d8c22707d80742 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    Add a null pointer check, and release 'ent' to avoid memory leaks.
    
    Fixes: bfd2f0d49aef ("powerpc/powernv: Get rid of old scom_controller abstraction")
    Signed-off-by: Kunwu Chan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/pseries/memhp: Fix access beyond end of drmem array [+ + +]
Author: Nathan Lynch <[email protected]>
Date:   Tue Nov 14 11:01:53 2023 -0600

    powerpc/pseries/memhp: Fix access beyond end of drmem array
    
    [ Upstream commit bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5 ]
    
    dlpar_memory_remove_by_index() may access beyond the bounds of the
    drmem lmb array when the LMB lookup fails to match an entry with the
    given DRC index. When the search fails, the cursor is left pointing to
    &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
    last valid entry in the array. The debug message at the end of the
    function then dereferences this pointer:
    
            pr_debug("Failed to hot-remove memory at %llx\n",
                     lmb->base_addr);
    
    This was found by inspection and confirmed with KASAN:
    
      pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
      Read of size 8 at addr c000000364e97fd0 by task bash/949
    
      dump_stack_lvl+0xa4/0xfc (unreliable)
      print_report+0x214/0x63c
      kasan_report+0x140/0x2e0
      __asan_load8+0xa8/0xe0
      dlpar_memory+0x298/0x1658
      handle_dlpar_errorlog+0x130/0x1d0
      dlpar_store+0x18c/0x3e0
      kobj_attr_store+0x68/0xa0
      sysfs_kf_write+0xc4/0x110
      kernfs_fop_write_iter+0x26c/0x390
      vfs_write+0x2d4/0x4e0
      ksys_write+0xac/0x1a0
      system_call_exception+0x268/0x530
      system_call_vectored_common+0x15c/0x2ec
    
      Allocated by task 1:
       kasan_save_stack+0x48/0x80
       kasan_set_track+0x34/0x50
       kasan_save_alloc_info+0x34/0x50
       __kasan_kmalloc+0xd0/0x120
       __kmalloc+0x8c/0x320
       kmalloc_array.constprop.0+0x48/0x5c
       drmem_init+0x2a0/0x41c
       do_one_initcall+0xe0/0x5c0
       kernel_init_freeable+0x4ec/0x5a0
       kernel_init+0x30/0x1e0
       ret_from_kernel_user_thread+0x14/0x1c
    
      The buggy address belongs to the object at c000000364e80000
       which belongs to the cache kmalloc-128k of size 131072
      The buggy address is located 0 bytes to the right of
       allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
    
      ==================================================================
      pseries-hotplug-mem: Failed to hot-remove memory at 0
    
    Log failed lookups with a separate message and dereference the
    cursor only when it points to a valid entry.
    
    Signed-off-by: Nathan Lynch <[email protected]>
    Fixes: 51925fb3c5c9 ("powerpc/pseries: Implement memory hotplug remove in the kernel")
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/rtas: Avoid warning on invalid token argument to sys_rtas() [+ + +]
Author: Nathan Lynch <[email protected]>
Date:   Tue Dec 12 11:01:48 2023 -0600

    powerpc/rtas: Avoid warning on invalid token argument to sys_rtas()
    
    [ Upstream commit 01e346ffefda3a7088afebf02b940614179688e7 ]
    
    rtas_token_to_function() WARNs when passed an invalid token; it's
    meant to catch bugs in kernel-based users of RTAS functions. However,
    user space controls the token value passed to rtas_token_to_function()
    by block_rtas_call(), so user space with sufficient privilege to use
    sys_rtas() can trigger the warnings at will:
    
      unexpected failed lookup for token 2048
      WARNING: CPU: 20 PID: 2247 at arch/powerpc/kernel/rtas.c:556
        rtas_token_to_function+0xfc/0x110
      ...
      NIP rtas_token_to_function+0xfc/0x110
      LR  rtas_token_to_function+0xf8/0x110
      Call Trace:
        rtas_token_to_function+0xf8/0x110 (unreliable)
        sys_rtas+0x188/0x880
        system_call_exception+0x268/0x530
        system_call_common+0x160/0x2c4
    
    It's desirable to continue warning on bogus tokens in
    rtas_token_to_function(). Currently it is used to look up RTAS
    function descriptors when tracing, where we know there has to have
    been a successful descriptor lookup by different means already, and it
    would be a serious inconsistency for the reverse lookup to fail.
    
    So instead of weakening rtas_token_to_function()'s contract by
    removing the warnings, introduce rtas_token_to_function_untrusted(),
    which has no opinion on failed lookups. Convert block_rtas_call() and
    rtas_token_to_function() to use it.
    
    Fixes: 8252b88294d2 ("powerpc/rtas: improve function information lookups")
    Signed-off-by: Nathan Lynch <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-1-e9eafd0c8c6c@linux.ibm.com
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc: add crtsavres.o to always-y instead of extra-y [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Tue Nov 21 08:23:32 2023 +0900

    powerpc: add crtsavres.o to always-y instead of extra-y
    
    [ Upstream commit 1b1e38002648819c04773647d5242990e2824264 ]
    
    crtsavres.o is linked to modules. However, as explained in commit
    d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
    and always-y"), 'make modules' does not build extra-y.
    
    For example, the following command fails:
    
      $ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig modules
        [snip]
        LD [M]  arch/powerpc/platforms/cell/spufs/spufs.ko
      ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory
      make[3]: *** [scripts/Makefile.modfinal:56: arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
      make[2]: *** [Makefile:1844: modules] Error 2
      make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350: __build_one_by_one] Error 2
      make: *** [Makefile:234: __sub-make] Error 2
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Fixes: baa25b571a16 ("powerpc/64: Do not link crtsavres.o in vmlinux")
    Reviewed-by: Nicholas Piggin <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc() [+ + +]
Author: Sergey Shtylyov <[email protected]>
Date:   Sun Nov 5 23:29:36 2023 +0300

    pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
    
    [ Upstream commit 86222a8fc16ec517de8da2604d904c9df3a08e5d ]
    
    In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
    64-bit value since persistent_ram_zone::buffer_size has type size_t which
    is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
    this value gets assigned to has (always 32-bit) *int* type.  Even if that
    value fits into *int* type, an overflow is still possible when calculating
    the size_t typed ecc_total variable further below since there's no cast to
    any 64-bit type before multiplication.  Declaring the ecc_blocks variable
    as *size_t* should fix this mess...
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE static
    analysis tool.
    
    Fixes: 9cc05ad97c57 ("staging: android: persistent_ram: refactor ecc support")
    Signed-off-by: Sergey Shtylyov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: Fix out-of-bounds access in of_pwm_single_xlate() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue Jan 9 22:34:31 2024 +0100

    pwm: Fix out-of-bounds access in of_pwm_single_xlate()
    
    commit a297d07b9a1e4fb8cda25a4a2363a507d294b7c9 upstream.
    
    With args->args_count == 2 args->args[2] is not defined. Actually the
    flags are contained in args->args[1].
    
    Fixes: 3ab7b6ac5d82 ("pwm: Introduce single-PWM of_xlate function")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/243908750d306e018a3d4bf2eb745d53ab50f663.1704835845.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pwm: jz4740: Don't use dev_err_probe() in .request() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Sat Jan 6 15:13:03 2024 +0100

    pwm: jz4740: Don't use dev_err_probe() in .request()
    
    commit 9320fc509b87b4d795fb37112931e2f4f8b5c55f upstream.
    
    dev_err_probe() is only supposed to be used in probe functions. While it
    probably doesn't hurt, both the EPROBE_DEFER handling and calling
    device_set_deferred_probe_reason() are conceptually wrong in the request
    callback. So replace the call by dev_err() and a separate return
    statement.
    
    This effectively reverts commit c0bfe9606e03 ("pwm: jz4740: Simplify
    with dev_err_probe()").
    
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: c0bfe9606e03 ("pwm: jz4740: Simplify with dev_err_probe()")
    Cc: [email protected]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pwm: stm32: Fix enable count for clk in .probe() [+ + +]
Author: Philipp Zabel <[email protected]>
Date:   Thu Oct 19 22:07:04 2023 +0200

    pwm: stm32: Fix enable count for clk in .probe()
    
    [ Upstream commit 19f1016ea9600ed89bc24247c36ff5934ad94fbb ]
    
    Make the driver take over hardware state without disabling in .probe()
    and enable the clock for each enabled channel.
    
    Signed-off-by: Philipp Zabel <[email protected]>
    [ukleinek: split off from a patch that also implemented .get_state()]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
    Reviewed-by: Fabrice Gasnier <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: stm32: Use hweight32 in stm32_pwm_detect_channels [+ + +]
Author: Philipp Zabel <[email protected]>
Date:   Thu Oct 19 22:07:02 2023 +0200

    pwm: stm32: Use hweight32 in stm32_pwm_detect_channels
    
    [ Upstream commit 41fa8f57c0d269243fe3bde2bce71e82c884b9ad ]
    
    Use hweight32() to count the CCxE bits in stm32_pwm_detect_channels().
    Since the return value is assigned to chip.npwm, change it to unsigned
    int as well.
    
    Signed-off-by: Philipp Zabel <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Reviewed-by: Fabrice Gasnier <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Stable-dep-of: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()")
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu: Restrict access to RCU CPU stall notifiers [+ + +]
Author: Paul E. McKenney <[email protected]>
Date:   Wed Nov 1 18:28:38 2023 -0700

    rcu: Restrict access to RCU CPU stall notifiers
    
    [ Upstream commit 4e58aaeebb3c27993c734c99eae6881b196b1ddb ]
    
    Although the RCU CPU stall notifiers can be useful for dumping state when
    tracking down delicate forward-progress bugs where NUMA effects cause
    cache lines to be delivered to a given CPU regularly, but always in a
    state that prevents that CPU from making forward progress.  These bugs can
    be detected by the RCU CPU stall-warning mechanism, but in some cases,
    the stall-warnings printk()s disrupt the forward-progress bug before
    any useful state can be obtained.
    
    Unfortunately, the notifier mechanism added by commit 5b404fdabacf ("rcu:
    Add RCU CPU stall notifier") can make matters worse if used at all
    carelessly. For example, if the stall warning was caused by a lock not
    being released, then any attempt to acquire that lock in the notifier
    will hang. This will prevent not only the notifier from producing any
    useful output, but it will also prevent the stall-warning message from
    ever appearing.
    
    This commit therefore hides this new RCU CPU stall notifier
    mechanism under a new RCU_CPU_STALL_NOTIFIER Kconfig option that
    depends on both DEBUG_KERNEL and RCU_EXPERT.  In addition, the
    rcupdate.rcu_cpu_stall_notifiers=1 kernel boot parameter must also
    be specified.  The RCU_CPU_STALL_NOTIFIER Kconfig option's help text
    contains a warning and explains the dangers of careless use, recommending
    lockless notifier code.  In addition, a WARN() is triggered each time
    that an attempt is made to register a stall-warning notifier in kernels
    built with CONFIG_RCU_CPU_STALL_NOTIFIER=y.
    
    This combination of measures will keep use of this mechanism confined to
    debug kernels and away from routine deployments.
    
    [ paulmck: Apply Dan Carpenter feedback. ]
    
    Fixes: 5b404fdabacf ("rcu: Add RCU CPU stall notifier")
    Reported-by: Linus Torvalds <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Reviewed-by: Joel Fernandes (Google) <[email protected]>
    Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/hns: Fix inappropriate err code for unsupported operations [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Tue Nov 14 20:34:47 2023 +0800

    RDMA/hns: Fix inappropriate err code for unsupported operations
    
    [ Upstream commit f45b83ad39f8033e717b1eee57e81811113d5a84 ]
    
    EOPNOTSUPP is more situable than EINVAL for allocating XRCD while XRC
    is not supported and unsupported resizing SRQ.
    
    Fixes: 32548870d438 ("RDMA/hns: Add support for XRC on HIP09")
    Fixes: 221109e64316 ("RDMA/hns: Add interception for resizing SRQs")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix memory leak in free_mr_init() [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Thu Dec 7 19:42:31 2023 +0800

    RDMA/hns: Fix memory leak in free_mr_init()
    
    [ Upstream commit 288f535951aa81ed674f5e5477ab11b9d9351b8c ]
    
    When a reserved QP fails to be created, the memory of the remaining
    created reserved QPs is leaked.
    
    Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/usnic: Silence uninitialized symbol smatch warnings [+ + +]
Author: Leon Romanovsky <[email protected]>
Date:   Mon Nov 13 11:28:02 2023 +0200

    RDMA/usnic: Silence uninitialized symbol smatch warnings
    
    [ Upstream commit b9a85e5eec126d6ae6c362f94b447c223e8fe6e4 ]
    
    The patch 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16, 2005
    (linux-next), leads to the following Smatch static checker warning:
    
            drivers/infiniband/hw/mthca/mthca_cmd.c:644 mthca_SYS_EN()
            error: uninitialized symbol 'out'.
    
    drivers/infiniband/hw/mthca/mthca_cmd.c
        636 int mthca_SYS_EN(struct mthca_dev *dev)
        637 {
        638         u64 out;
        639         int ret;
        640
        641         ret = mthca_cmd_imm(dev, 0, &out, 0, 0, CMD_SYS_EN, CMD_TIME_CLASS_D);
    
    We pass out here and it gets used without being initialized.
    
            err = mthca_cmd_post(dev, in_param,
                                 out_param ? *out_param : 0,
                                             ^^^^^^^^^^
                                 in_modifier, op_modifier,
                                 op, context->token, 1);
    
    It's the same in mthca_cmd_wait() and mthca_cmd_poll().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Link: https://lore.kernel.org/r/c559cb7113158c02d75401ac162652072ef1b5f0.1699867650.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole" [+ + +]
Author: Kaibo Ma <[email protected]>
Date:   Wed Jan 3 12:29:56 2024 +0800

    Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"
    
    commit 0f35b0a7b8fa402adbffa2565047cdcc4c480153 upstream.
    
    That commit causes NULL pointer dereferences in dmesgs when
    running applications using ROCm, including clinfo, blender,
    and PyTorch, since v6.6.1. Revert it to fix blender again.
    
    This reverts commit 96c211f1f9ef82183493f4ceed4e347b52849149.
    
    Closes: https://github.com/ROCm/ROCm/issues/2596
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2991
    Reviewed-by: Jay Cornwall <[email protected]>
    Signed-off-by: Kaibo Ma <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/bridge: Add 200ms delay to wait FW HPD status stable" [+ + +]
Author: Xin Ji <[email protected]>
Date:   Mon Nov 20 17:10:36 2023 +0800

    Revert "drm/bridge: Add 200ms delay to wait FW HPD status stable"
    
    [ Upstream commit af3145aa142c92409d3b123ff87ff0b5fd0bf849 ]
    
    This reverts commit 330140d7319fcc4ec68bd924ea212e476bf12275
    
    200ms delay will cause panel display image later than backlight
    turn on, revert this patch.
    
    Fixes: 330140d7319fcc ("drm/bridge: Add 200ms delay to wait FW HPD status stable")
    Signed-off-by: Xin Ji <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "drm/omapdrm: Annotate dma-fence critical section in commit path" [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Sep 20 15:57:17 2023 +0300

    Revert "drm/omapdrm: Annotate dma-fence critical section in commit path"
    
    [ Upstream commit 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 ]
    
    This reverts commit 250aa22920cd5d956a5d3e9c6a43d671c2bae217.
    
    The DMA-fence annotations cause a lockdep warning (see below). As per
    https://patchwork.freedesktop.org/patch/462170/ it sounds like the
    annotations don't work correctly.
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.5.0-rc2+ #2 Not tainted
    ------------------------------------------------------
    kmstest/219 is trying to acquire lock:
    c4705838 (&hdmi->lock){+.+.}-{3:3}, at: hdmi5_bridge_mode_set+0x1c/0x50
    
    but task is already holding lock:
    c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (dma_fence_map){++++}-{0:0}:
           __dma_fence_might_wait+0x48/0xb4
           dma_resv_lockdep+0x1b8/0x2bc
           do_one_initcall+0x68/0x3b0
           kernel_init_freeable+0x260/0x34c
           kernel_init+0x14/0x140
           ret_from_fork+0x14/0x28
    
    -> #1 (fs_reclaim){+.+.}-{0:0}:
           fs_reclaim_acquire+0x70/0xa8
           __kmem_cache_alloc_node+0x3c/0x368
           kmalloc_trace+0x28/0x58
           _drm_do_get_edid+0x7c/0x35c
           hdmi5_bridge_get_edid+0xc8/0x1ac
           drm_bridge_connector_get_modes+0x64/0xc0
           drm_helper_probe_single_connector_modes+0x170/0x528
           drm_client_modeset_probe+0x208/0x1334
           __drm_fb_helper_initial_config_and_unlock+0x30/0x548
           omap_fbdev_client_hotplug+0x3c/0x6c
           drm_client_register+0x58/0x94
           pdev_probe+0x544/0x6b0
           platform_probe+0x58/0xbc
           really_probe+0xd8/0x3fc
           __driver_probe_device+0x94/0x1f4
           driver_probe_device+0x2c/0xc4
           __device_attach_driver+0xa4/0x11c
           bus_for_each_drv+0x84/0xdc
           __device_attach+0xac/0x20c
           bus_probe_device+0x8c/0x90
           device_add+0x588/0x7e0
           platform_device_add+0x110/0x24c
           platform_device_register_full+0x108/0x15c
           dss_bind+0x90/0xc0
           try_to_bring_up_aggregate_device+0x1e0/0x2c8
           __component_add+0xa4/0x174
           hdmi5_probe+0x1c8/0x270
           platform_probe+0x58/0xbc
           really_probe+0xd8/0x3fc
           __driver_probe_device+0x94/0x1f4
           driver_probe_device+0x2c/0xc4
           __device_attach_driver+0xa4/0x11c
           bus_for_each_drv+0x84/0xdc
           __device_attach+0xac/0x20c
           bus_probe_device+0x8c/0x90
           deferred_probe_work_func+0x8c/0xd8
           process_one_work+0x2ac/0x6e4
           worker_thread+0x30/0x4ec
           kthread+0x100/0x124
           ret_from_fork+0x14/0x28
    
    -> #0 (&hdmi->lock){+.+.}-{3:3}:
           __lock_acquire+0x145c/0x29cc
           lock_acquire.part.0+0xb4/0x258
           __mutex_lock+0x90/0x950
           mutex_lock_nested+0x1c/0x24
           hdmi5_bridge_mode_set+0x1c/0x50
           drm_bridge_chain_mode_set+0x48/0x5c
           crtc_set_mode+0x188/0x1d0
           omap_atomic_commit_tail+0x2c/0xbc
           commit_tail+0x9c/0x188
           drm_atomic_helper_commit+0x158/0x18c
           drm_atomic_commit+0xa4/0xe8
           drm_mode_atomic_ioctl+0x9a4/0xc38
           drm_ioctl+0x210/0x4a8
           sys_ioctl+0x138/0xf00
           ret_fast_syscall+0x0/0x1c
    
    other info that might help us debug this:
    
    Chain exists of:
      &hdmi->lock --> fs_reclaim --> dma_fence_map
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      rlock(dma_fence_map);
                                   lock(fs_reclaim);
                                   lock(dma_fence_map);
      lock(&hdmi->lock);
    
     *** DEADLOCK ***
    
    3 locks held by kmstest/219:
     #0: f1011de4 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_atomic_ioctl+0xf0/0xc38
     #1: c47059c8 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xf8/0x230
     #2: c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc
    
    stack backtrace:
    CPU: 1 PID: 219 Comm: kmstest Not tainted 6.5.0-rc2+ #2
    Hardware name: Generic DRA74X (Flattened Device Tree)
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x58/0x70
     dump_stack_lvl from check_noncircular+0x164/0x198
     check_noncircular from __lock_acquire+0x145c/0x29cc
     __lock_acquire from lock_acquire.part.0+0xb4/0x258
     lock_acquire.part.0 from __mutex_lock+0x90/0x950
     __mutex_lock from mutex_lock_nested+0x1c/0x24
     mutex_lock_nested from hdmi5_bridge_mode_set+0x1c/0x50
     hdmi5_bridge_mode_set from drm_bridge_chain_mode_set+0x48/0x5c
     drm_bridge_chain_mode_set from crtc_set_mode+0x188/0x1d0
     crtc_set_mode from omap_atomic_commit_tail+0x2c/0xbc
     omap_atomic_commit_tail from commit_tail+0x9c/0x188
     commit_tail from drm_atomic_helper_commit+0x158/0x18c
     drm_atomic_helper_commit from drm_atomic_commit+0xa4/0xe8
     drm_atomic_commit from drm_mode_atomic_ioctl+0x9a4/0xc38
     drm_mode_atomic_ioctl from drm_ioctl+0x210/0x4a8
     drm_ioctl from sys_ioctl+0x138/0xf00
     sys_ioctl from ret_fast_syscall+0x0/0x1c
    Exception stack(0xf1011fa8 to 0xf1011ff0)
    1fa0:                   00466d58 be9ab510 00000003 c03864bc be9ab510 be9ab4e0
    1fc0: 00466d58 be9ab510 c03864bc 00000036 00466ef0 00466fc0 00467020 00466f20
    1fe0: b6bc7ef4 be9ab4d0 b6bbbb00 b6cb2cc0
    
    Fixes: 250aa22920cd ("drm/omapdrm: Annotate dma-fence critical section in commit path")
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230920-dma-fence-annotation-revert-v1-2-7ebf6f7f5bf6@ideasonboard.com
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "drm/tidss: Annotate dma-fence critical section in commit path" [+ + +]
Author: Tomi Valkeinen <[email protected]>
Date:   Wed Sep 20 15:57:16 2023 +0300

    Revert "drm/tidss: Annotate dma-fence critical section in commit path"
    
    [ Upstream commit ca34d816558c3e4c3f8fe037b5a6b16c944693de ]
    
    This reverts commit 4d56a4f08391857ba93465de489707b66adad114.
    
    The DMA-fence annotations cause a lockdep warning (see below). As per
    https://patchwork.freedesktop.org/patch/462170/ it sounds like the
    annotations don't work correctly.
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.6.0-rc2+ #1 Not tainted
    ------------------------------------------------------
    kmstest/733 is trying to acquire lock:
    ffff8000819377f0 (fs_reclaim){+.+.}-{0:0}, at: __kmem_cache_alloc_node+0x58/0x2d4
    
    but task is already holding lock:
    ffff800081a06aa0 (dma_fence_map){++++}-{0:0}, at: tidss_atomic_commit_tail+0x20/0xc0 [tidss]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (dma_fence_map){++++}-{0:0}:
           __dma_fence_might_wait+0x5c/0xd0
           dma_resv_lockdep+0x1a4/0x32c
           do_one_initcall+0x84/0x2fc
           kernel_init_freeable+0x28c/0x4c4
           kernel_init+0x24/0x1dc
           ret_from_fork+0x10/0x20
    
    -> #1 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
           fs_reclaim_acquire+0x70/0xe4
           __kmem_cache_alloc_node+0x58/0x2d4
           kmalloc_trace+0x38/0x78
           __kthread_create_worker+0x3c/0x150
           kthread_create_worker+0x64/0x8c
           workqueue_init+0x1e8/0x2f0
           kernel_init_freeable+0x11c/0x4c4
           kernel_init+0x24/0x1dc
           ret_from_fork+0x10/0x20
    
    -> #0 (fs_reclaim){+.+.}-{0:0}:
           __lock_acquire+0x1370/0x20d8
           lock_acquire+0x1e8/0x308
           fs_reclaim_acquire+0xd0/0xe4
           __kmem_cache_alloc_node+0x58/0x2d4
           __kmalloc_node_track_caller+0x58/0xf0
           kmemdup+0x34/0x60
           regmap_bulk_write+0x64/0x2c0
           tc358768_bridge_pre_enable+0x8c/0x12d0 [tc358768]
           drm_atomic_bridge_call_pre_enable+0x68/0x80 [drm]
           drm_atomic_bridge_chain_pre_enable+0x50/0x158 [drm]
           drm_atomic_helper_commit_modeset_enables+0x164/0x264 [drm_kms_helper]
           tidss_atomic_commit_tail+0x58/0xc0 [tidss]
           commit_tail+0xa0/0x188 [drm_kms_helper]
           drm_atomic_helper_commit+0x1a8/0x1c0 [drm_kms_helper]
           drm_atomic_commit+0xa8/0xe0 [drm]
           drm_mode_atomic_ioctl+0x9ec/0xc80 [drm]
           drm_ioctl_kernel+0xc4/0x170 [drm]
           drm_ioctl+0x234/0x4b0 [drm]
           drm_compat_ioctl+0x110/0x12c [drm]
           __arm64_compat_sys_ioctl+0x128/0x150
           invoke_syscall+0x48/0x110
           el0_svc_common.constprop.0+0x40/0xe0
           do_el0_svc_compat+0x1c/0x38
           el0_svc_compat+0x48/0xb4
           el0t_32_sync_handler+0xb0/0x138
           el0t_32_sync+0x194/0x198
    
    other info that might help us debug this:
    
    Chain exists of:
      fs_reclaim --> mmu_notifier_invalidate_range_start --> dma_fence_map
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      rlock(dma_fence_map);
                                   lock(mmu_notifier_invalidate_range_start);
                                   lock(dma_fence_map);
      lock(fs_reclaim);
    
     *** DEADLOCK ***
    
    3 locks held by kmstest/733:
     #0: ffff800082e5bba0 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_atomic_ioctl+0x118/0xc80 [drm]
     #1: ffff000004224c88 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xdc/0x1a0 [drm]
     #2: ffff800081a06aa0 (dma_fence_map){++++}-{0:0}, at: tidss_atomic_commit_tail+0x20/0xc0 [tidss]
    
    stack backtrace:
    CPU: 0 PID: 733 Comm: kmstest Not tainted 6.6.0-rc2+ #1
    Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
    Call trace:
     dump_backtrace+0x98/0x118
     show_stack+0x18/0x24
     dump_stack_lvl+0x60/0xac
     dump_stack+0x18/0x24
     print_circular_bug+0x288/0x368
     check_noncircular+0x168/0x17c
     __lock_acquire+0x1370/0x20d8
     lock_acquire+0x1e8/0x308
     fs_reclaim_acquire+0xd0/0xe4
     __kmem_cache_alloc_node+0x58/0x2d4
     __kmalloc_node_track_caller+0x58/0xf0
     kmemdup+0x34/0x60
     regmap_bulk_write+0x64/0x2c0
     tc358768_bridge_pre_enable+0x8c/0x12d0 [tc358768]
     drm_atomic_bridge_call_pre_enable+0x68/0x80 [drm]
     drm_atomic_bridge_chain_pre_enable+0x50/0x158 [drm]
     drm_atomic_helper_commit_modeset_enables+0x164/0x264 [drm_kms_helper]
     tidss_atomic_commit_tail+0x58/0xc0 [tidss]
     commit_tail+0xa0/0x188 [drm_kms_helper]
     drm_atomic_helper_commit+0x1a8/0x1c0 [drm_kms_helper]
     drm_atomic_commit+0xa8/0xe0 [drm]
     drm_mode_atomic_ioctl+0x9ec/0xc80 [drm]
     drm_ioctl_kernel+0xc4/0x170 [drm]
     drm_ioctl+0x234/0x4b0 [drm]
     drm_compat_ioctl+0x110/0x12c [drm]
     __arm64_compat_sys_ioctl+0x128/0x150
     invoke_syscall+0x48/0x110
     el0_svc_common.constprop.0+0x40/0xe0
     do_el0_svc_compat+0x1c/0x38
     el0_svc_compat+0x48/0xb4
     el0t_32_sync_handler+0xb0/0x138
     el0t_32_sync+0x194/0x198
    
    Fixes: 4d56a4f08391 ("drm/tidss: Annotate dma-fence critical section in commit path")
    Reviewed-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230920-dma-fence-annotation-revert-v1-1-7ebf6f7f5bf6@ideasonboard.com
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "kernfs: convert kernfs_idr_lock to an irq safe raw spinlock" [+ + +]
Author: Tejun Heo <[email protected]>
Date:   Tue Jan 9 11:48:02 2024 -1000

    Revert "kernfs: convert kernfs_idr_lock to an irq safe raw spinlock"
    
    commit e3977e0609a07d86406029fceea0fd40d7849368 upstream.
    
    This reverts commit dad3fb67ca1cbef87ce700e83a55835e5921ce8a.
    
    The commit converted kernfs_idr_lock to an IRQ-safe raw_spinlock because it
    could be acquired while holding an rq lock through bpf_cgroup_from_id().
    However, kernfs_idr_lock is held while doing GPF_NOWAIT allocations which
    involves acquiring an non-IRQ-safe and non-raw lock leading to the following
    lockdep warning:
    
      =============================
      [ BUG: Invalid wait context ]
      6.7.0-rc5-kzm9g-00251-g655022a45b1c #578 Not tainted
      -----------------------------
      swapper/0/0 is trying to lock:
      dfbcd488 (&c->lock){....}-{3:3}, at: local_lock_acquire+0x0/0xa4
      other info that might help us debug this:
      context-{5:5}
      2 locks held by swapper/0/0:
       #0: dfbc9c60 (lock){+.+.}-{3:3}, at: local_lock_acquire+0x0/0xa4
       #1: c0c012a8 (kernfs_idr_lock){....}-{2:2}, at: __kernfs_new_node.constprop.0+0x68/0x258
      stack backtrace:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc5-kzm9g-00251-g655022a45b1c #578
      Hardware name: Generic SH73A0 (Flattened Device Tree)
       unwind_backtrace from show_stack+0x10/0x14
       show_stack from dump_stack_lvl+0x68/0x90
       dump_stack_lvl from __lock_acquire+0x3cc/0x168c
       __lock_acquire from lock_acquire+0x274/0x30c
       lock_acquire from local_lock_acquire+0x28/0xa4
       local_lock_acquire from ___slab_alloc+0x234/0x8a8
       ___slab_alloc from __slab_alloc.constprop.0+0x30/0x44
       __slab_alloc.constprop.0 from kmem_cache_alloc+0x7c/0x148
       kmem_cache_alloc from radix_tree_node_alloc.constprop.0+0x44/0xdc
       radix_tree_node_alloc.constprop.0 from idr_get_free+0x110/0x2b8
       idr_get_free from idr_alloc_u32+0x9c/0x108
       idr_alloc_u32 from idr_alloc_cyclic+0x50/0xb8
       idr_alloc_cyclic from __kernfs_new_node.constprop.0+0x88/0x258
       __kernfs_new_node.constprop.0 from kernfs_create_root+0xbc/0x154
       kernfs_create_root from sysfs_init+0x18/0x5c
       sysfs_init from mnt_init+0xc4/0x220
       mnt_init from vfs_caches_init+0x6c/0x88
       vfs_caches_init from start_kernel+0x474/0x528
       start_kernel from 0x0
    
    Let's rever the commit. It's undesirable to spread out raw spinlock usage
    anyway and the problem can be solved by protecting the lookup path with RCU
    instead.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Cc: Andrea Righi <[email protected]>
    Reported-by: Geert Uytterhoeven <[email protected]>
    Link: http://lkml.kernel.org/r/CAMuHMdV=AKt+mwY7svEq5gFPx41LoSQZ_USME5_MEdWQze13ww@mail.gmail.com
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Andrea Righi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "KEYS: encrypted: Add check for strsep" [+ + +]
Author: Mimi Zohar <[email protected]>
Date:   Wed Jan 24 14:21:44 2024 -0500

    Revert "KEYS: encrypted: Add check for strsep"
    
    commit 1ed4b563100230ea68821a2b25a3d9f25388a3e6 upstream.
    
    This reverts commit b4af096b5df5dd131ab796c79cedc7069d8f4882.
    
    New encrypted keys are created either from kernel-generated random
    numbers or user-provided decrypted data.  Revert the change requiring
    user-provided decrypted data.
    
    Reported-by: Vishal Verma <[email protected]>
    Signed-off-by: Mimi Zohar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "net: rtnetlink: Enslave device before bringing it up" [+ + +]
Author: Nicolas Dichtel <[email protected]>
Date:   Mon Jan 8 10:41:02 2024 +0100

    Revert "net: rtnetlink: Enslave device before bringing it up"
    
    commit ec4ffd100ffb396eca13ebe7d18938ea80f399c3 upstream.
    
    This reverts commit a4abfa627c3865c37e036bccb681619a50d3d93c.
    
    The patch broke:
    > ip link set dummy0 up
    > ip link set dummy0 master bond0 down
    
    This last command is useful to be able to enslave an interface with only
    one netlink message.
    
    After discussion, there is no good reason to support:
    > ip link set dummy0 down
    > ip link set dummy0 master bond0 up
    because the bond interface already set the slave up when it is up.
    
    Cc: [email protected]
    Fixes: a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up")
    Signed-off-by: Nicolas Dichtel <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "nSVM: Check for reserved encodings of TLB_CONTROL in nested VMCB" [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Wed Oct 18 12:41:03 2023 -0700

    Revert "nSVM: Check for reserved encodings of TLB_CONTROL in nested VMCB"
    
    commit a484755ab2526ebdbe042397cdd6e427eb4b1a68 upstream.
    
    Revert KVM's made-up consistency check on SVM's TLB control.  The APM says
    that unsupported encodings are reserved, but the APM doesn't state that
    VMRUN checks for a supported encoding.  Unless something is called out
    in "Canonicalization and Consistency Checks" or listed as MBZ (Must Be
    Zero), AMD behavior is typically to let software shoot itself in the foot.
    
    This reverts commit 174a921b6975ef959dd82ee9e8844067a62e3ec1.
    
    Fixes: 174a921b6975 ("nSVM: Check for reserved encodings of TLB_CONTROL in nested VMCB")
    Reported-by: Stefan Sterz <[email protected]>
    Closes: https://lkml.kernel.org/r/b9915c9c-4cf6-051a-2d91-44cc6380f455%40proxmox.com
    Cc: [email protected]
    Reviewed-by: Maxim Levitsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"" [+ + +]
Author: Song Liu <[email protected]>
Date:   Thu Jan 25 00:21:31 2024 -0800

    Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d""
    
    This reverts commit bed9e27baf52a09b7ba2a3714f1e24e17ced386d.
    
    The original set [1][2] was expected to undo a suboptimal fix in [2], and
    replace it with a better fix [1]. However, as reported by Dan Moulding [2]
    causes an issue with raid5 with journal device.
    
    Revert [2] for now to close the issue. We will follow up on another issue
    reported by Juxiao Bi, as [2] is expected to fix it. We believe this is a
    good trade-off, because the latter issue happens less freqently.
    
    In the meanwhile, we will NOT revert [1], as it contains the right logic.
    
    [1] commit d6e035aad6c0 ("md: bypass block throttle for superblock update")
    [2] commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
    
    Reported-by: Dan Moulding <[email protected]>
    Closes: https://lore.kernel.org/linux-raid/[email protected]/
    Fixes: bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
    Cc: [email protected] # v5.19+
    Cc: Junxiao Bi <[email protected]>
    Cc: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only" [+ + +]
Author: Thinh Nguyen <[email protected]>
Date:   Fri Dec 22 22:11:33 2023 +0000

    Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only"
    
    commit afe28cd686aeb77e8d9140d50fb1cf06a7ecb731 upstream.
    
    This reverts commit e835c0a4e23c38531dcee5ef77e8d1cf462658c7.
    
    Don't omit soft-reset. During initialization, the driver may need to
    perform a soft reset to ensure the phy is ready when the controller
    updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset.
    Many platforms often have access to DCTL register for soft-reset despite
    being host-only. If there are actual reported issues from the platforms
    that don't expose DCTL registers, then we will need to revisit (perhaps
    to teach dwc3 to perform xhci's soft-reset USBCMD.HCRST).
    
    Cc:  <[email protected]>
    Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
    Signed-off-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/7668ab11a48f260820825274976eb41fec7f54d1.1703282469.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "usb: dwc3: Soft reset phy on probe for host" [+ + +]
Author: Thinh Nguyen <[email protected]>
Date:   Fri Dec 22 22:11:27 2023 +0000

    Revert "usb: dwc3: Soft reset phy on probe for host"
    
    commit 7059fbebcb00554c3f31e5b5d93ef6d2d96dc7b4 upstream.
    
    This reverts commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b.
    
    The phy soft reset GUSB2PHYCFG.PHYSOFTRST only applies to UTMI phy, not
    ULPI. This fix is incomplete.
    
    Cc:  <[email protected]>
    Fixes: 8bea147dfdf8 ("usb: dwc3: Soft reset phy on probe for host")
    Reported-by: Köry Maincent <[email protected]>
    Closes: https://lore.kernel.org/linux-usb/20231205151959.5236c231@kmaincent-XPS-13-7390
    Signed-off-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/29a26593a60eba727de872a3e580a674807b3339.1703282469.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "usb: gadget: f_uvc: change endpoint allocation in uvc_function_bind()" [+ + +]
Author: Frank Li <[email protected]>
Date:   Sun Dec 24 10:38:16 2023 -0500

    Revert "usb: gadget: f_uvc: change endpoint allocation in uvc_function_bind()"
    
    commit 895ee5aefb7e24203de5dffae7ce9a02d78fa3d1 upstream.
    
    This reverts commit 3c5b006f3ee800b4bd9ed37b3a8f271b8560126e.
    
    gadget_is_{super|dual}speed() API check UDC controller capitblity. It
    should pass down highest speed endpoint descriptor to UDC controller. So
    UDC controller driver can reserve enough resource at check_config(),
    especially mult and maxburst. So UDC driver (such as cdns3) can know need
    at least (mult + 1) * (maxburst + 1) * wMaxPacketSize internal memory for
    this uvc functions.
    
    Cc:  <[email protected]>
    Signed-off-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs" [+ + +]
Author: Heikki Krogerus <[email protected]>
Date:   Tue Jan 2 11:11:41 2024 +0200

    Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs"
    
    commit 9c6b789e954fae73c548f39332bcc56bdf0d4373 upstream.
    
    This reverts commit b17b7fe6dd5c6ff74b38b0758ca799cdbb79e26e.
    
    That commit messed up the reference counting, so it needs to
    be rethought.
    
    Fixes: b17b7fe6dd5c ("usb: typec: class: fix typec_altmode_put_partner to put plugs")
    Cc:  <[email protected]>
    Cc: RD Babiera <[email protected]>
    Reported-by: Chris Bainbridge <[email protected]>
    Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/
    Signed-off-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: Check if the code to patch lies in the exit section [+ + +]
Author: Alexandre Ghiti <[email protected]>
Date:   Thu Dec 14 10:19:26 2023 +0100

    riscv: Check if the code to patch lies in the exit section
    
    [ Upstream commit 420370f3ae3d3b883813fd3051a38805160b2b9f ]
    
    Otherwise we fall through to vmalloc_to_page() which panics since the
    address does not lie in the vmalloc region.
    
    Fixes: 043cb41a85de ("riscv: introduce interfaces to patch kernel code")
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Reviewed-by: Charlie Jenkins <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Fix module_alloc() that did not reset the linear mapping permissions [+ + +]
Author: Alexandre Ghiti <[email protected]>
Date:   Wed Dec 13 14:40:26 2023 +0100

    riscv: Fix module_alloc() that did not reset the linear mapping permissions
    
    [ Upstream commit 749b94b08005929bbc636df21a23322733166e35 ]
    
    After unloading a module, we must reset the linear mapping permissions,
    see the example below:
    
    Before unloading a module:
    
    0xffffaf809d65d000-0xffffaf809d6dc000    0x000000011d65d000       508K PTE .   ..     ..   D A G . . W R V
    0xffffaf809d6dc000-0xffffaf809d6dd000    0x000000011d6dc000         4K PTE .   ..     ..   D A G . . . R V
    0xffffaf809d6dd000-0xffffaf809d6e1000    0x000000011d6dd000        16K PTE .   ..     ..   D A G . . W R V
    0xffffaf809d6e1000-0xffffaf809d6e7000    0x000000011d6e1000        24K PTE .   ..     ..   D A G . X . R V
    
    After unloading a module:
    
    0xffffaf809d65d000-0xffffaf809d6e1000    0x000000011d65d000       528K PTE .   ..     ..   D A G . . W R V
    0xffffaf809d6e1000-0xffffaf809d6e7000    0x000000011d6e1000        24K PTE .   ..     ..   D A G . X W R V
    
    The last mapping is not reset and we end up with WX mappings in the linear
    mapping.
    
    So add VM_FLUSH_RESET_PERMS to our module_alloc() definition.
    
    Fixes: 0cff8bff7af8 ("riscv: avoid the PIC offset of static percpu data in module beyond 2G limits")
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Fix set_direct_map_default_noflush() to reset _PAGE_EXEC [+ + +]
Author: Alexandre Ghiti <[email protected]>
Date:   Wed Dec 13 14:40:27 2023 +0100

    riscv: Fix set_direct_map_default_noflush() to reset _PAGE_EXEC
    
    [ Upstream commit b8b2711336f03ece539de61479d6ffc44fb603d3 ]
    
    When resetting the linear mapping permissions, we must make sure that we
    clear the X bit so that do not end up with WX mappings (since we set
    PAGE_KERNEL).
    
    Fixes: 395a21ff859c ("riscv: add ARCH_HAS_SET_DIRECT_MAP support")
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Fix wrong usage of lm_alias() when splitting a huge linear mapping [+ + +]
Author: Alexandre Ghiti <[email protected]>
Date:   Tue Dec 12 20:54:00 2023 +0100

    riscv: Fix wrong usage of lm_alias() when splitting a huge linear mapping
    
    [ Upstream commit c29fc621e1a49949a14c7fa031dd4760087bfb29 ]
    
    lm_alias() can only be used on kernel mappings since it explicitly uses
    __pa_symbol(), so simply fix this by checking where the address belongs
    to before.
    
    Fixes: 311cd2f6e253 ("riscv: Fix set_memory_XX() and set_direct_map_XX() by splitting huge linear mappings")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/linux-riscv/[email protected]/
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Reviewed-by: Charlie Jenkins <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Fixed wrong register in XIP_FIXUP_FLASH_OFFSET macro [+ + +]
Author: Frederik Haxel <[email protected]>
Date:   Tue Dec 12 14:01:13 2023 +0100

    riscv: Fixed wrong register in XIP_FIXUP_FLASH_OFFSET macro
    
    [ Upstream commit 5daa3726410288075ba73c336bb2e80d6b06aa4d ]
    
    During the refactoring, a bug was introduced in the rarly used
    XIP_FIXUP_FLASH_OFFSET macro.
    
    Fixes: bee7fbc38579 ("RISC-V CPU Idle Support")
    Fixes: e7681beba992 ("RISC-V: Split out the XIP fixups into their own file")
    
    Signed-off-by: Frederik Haxel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rootfs: Fix support for rootfstype= when root= is given [+ + +]
Author: Stefan Berger <[email protected]>
Date:   Sun Nov 19 20:12:48 2023 -0500

    rootfs: Fix support for rootfstype= when root= is given
    
    commit 21528c69a0d8483f7c6345b1a0bc8d8975e9a172 upstream.
    
    Documentation/filesystems/ramfs-rootfs-initramfs.rst states:
    
      If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
      default.  To force ramfs, add "rootfstype=ramfs" to the kernel command
      line.
    
    This currently does not work when root= is provided since then
    saved_root_name contains a string and rootfstype= is ignored. Therefore,
    ramfs is currently always chosen when root= is provided.
    
    The current behavior for rootfs's filesystem is:
    
       root=       | rootfstype= | chosen rootfs filesystem
       ------------+-------------+--------------------------
       unspecified | unspecified | tmpfs
       unspecified | tmpfs       | tmpfs
       unspecified | ramfs       | ramfs
        provided   | ignored     | ramfs
    
    rootfstype= should be respected regardless whether root= is given,
    as shown below:
    
       root=       | rootfstype= | chosen rootfs filesystem
       ------------+-------------+--------------------------
       unspecified | unspecified | tmpfs  (as before)
       unspecified | tmpfs       | tmpfs  (as before)
       unspecified | ramfs       | ramfs  (as before)
        provided   | unspecified | ramfs  (compatibility with before)
        provided   | tmpfs       | tmpfs  (new)
        provided   | ramfs       | ramfs  (new)
    
    This table represents the new behavior.
    
    Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified")
    Cc: <[email protected]>
    Signed-off-by: Rob Landley <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reviewed-and-Tested-by: Mimi Zohar <[email protected]>
    Signed-off-by: Stefan Berger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rust: Ignore preserve-most functions [+ + +]
Author: Matthew Maurer <[email protected]>
Date:   Tue Oct 31 20:19:44 2023 +0000

    rust: Ignore preserve-most functions
    
    commit bad098d76835c1379e1cf6afc935f8a7e050f83c upstream.
    
    Neither bindgen nor Rust know about the preserve-most calling
    convention, and Clang describes it as unstable. Since we aren't using
    functions with this calling convention from Rust, blocklist them.
    
    These functions are only added to the build when list hardening is
    enabled, which is likely why others didn't notice this yet.
    
    Signed-off-by: Matthew Maurer <[email protected]>
    Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
    Reviewed-by: Alice Ryhl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ Used Markdown for consistency with the other comments in the file. ]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rxrpc: Fix skbuff cleanup of call's recvmsg_queue and rx_oos_queue [+ + +]
Author: David Howells <[email protected]>
Date:   Fri Jan 5 17:05:41 2024 +0000

    rxrpc: Fix skbuff cleanup of call's recvmsg_queue and rx_oos_queue
    
    [ Upstream commit 4fc68c4c1a114ba597b4f3b082f04622dfa0e0f6 ]
    
    Fix rxrpc_cleanup_ring() to use rxrpc_purge_queue() rather than
    skb_queue_purge() so that the count of outstanding skbuffs is correctly
    updated when a failed call is cleaned up.
    
    Without this rmmod may hang waiting for rxrpc_n_rx_skbs to become zero.
    
    Fixes: 5d7edbc9231e ("rxrpc: Get rid of the Rx ring")
    Reported-by: Marc Dionne <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    cc: "David S. Miller" <[email protected]>
    cc: Eric Dumazet <[email protected]>
    cc: Jakub Kicinski <[email protected]>
    cc: Paolo Abeni <[email protected]>
    cc: [email protected]
    cc: [email protected]
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rxrpc: Fix use of Don't Fragment flag [+ + +]
Author: David Howells <[email protected]>
Date:   Tue Jan 9 15:10:48 2024 +0000

    rxrpc: Fix use of Don't Fragment flag
    
    [ Upstream commit 8722014311e613244f33952354956a82fa4b0472 ]
    
    rxrpc normally has the Don't Fragment flag set on the UDP packets it
    transmits, except when it has decided that DATA packets aren't getting
    through - in which case it turns it off just for the DATA transmissions.
    This can be a problem, however, for RESPONSE packets that convey
    authentication and crypto data from the client to the server as ticket may
    be larger than can fit in the MTU.
    
    In such a case, rxrpc gets itself into an infinite loop as the sendmsg
    returns an error (EMSGSIZE), which causes rxkad_send_response() to return
    -EAGAIN - and the CHALLENGE packet is put back on the Rx queue to retry,
    leading to the I/O thread endlessly attempting to perform the transmission.
    
    Fix this by disabling DF on RESPONSE packets for now.  The use of DF and
    best data MTU determination needs reconsidering at some point in the
    future.
    
    Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
    Reported-by: Marc Dionne <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    cc: [email protected]
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/bpf: Fix gotol with large offsets [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Tue Jan 2 20:30:35 2024 +0100

    s390/bpf: Fix gotol with large offsets
    
    [ Upstream commit ecba66cb36e3428e9f0c2362b45e213ad43ba8d0 ]
    
    The gotol implementation uses a wrong data type for the offset: it
    should be s32, not s16.
    
    Fixes: c690191e23d8 ("s390/bpf: Implement unconditional jump with 32-bit offset")
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/pci: fix max size calculation in zpci_memcpy_toio() [+ + +]
Author: Niklas Schnelle <[email protected]>
Date:   Tue Nov 28 16:22:49 2023 +0100

    s390/pci: fix max size calculation in zpci_memcpy_toio()
    
    [ Upstream commit 80df7d6af7f6d229b34cf237b2cc9024c07111cd ]
    
    The zpci_get_max_write_size() helper is used to determine the maximum
    size a PCI store or load can use at a given __iomem address.
    
    For the PCI block store the following restrictions apply:
    
    1. The dst + len must not cross a 4K boundary in the (pseudo-)MMIO space
    2. len must not exceed ZPCI_MAX_WRITE_SIZE
    3. len must be a multiple of 8 bytes
    4. The src address must be double word (8 byte) aligned
    5. The dst address must be double word (8 byte) aligned
    
    Otherwise only a normal PCI store which takes its src value from
    a register can be used. For these PCI store restriction 1 still applies.
    Similarly 1 also applies to PCI loads.
    
    It turns out zpci_max_write_size() instead implements stricter
    conditions which prevents PCI block stores from being used where they
    can and should be used. In particular instead of conditions 4 and 5 it
    wrongly enforces both dst and src to be size aligned. This indirectly
    covers condition 1 but also prevents many legal PCI block stores.
    
    On top of the functional shortcomings the zpci_get_max_write_size() is
    misnamed as it is used for both read and write size calculations. Rename
    it to zpci_get_max_io_size() and implement the listed conditions
    explicitly.
    
    Reviewed-by: Matthew Rosato <[email protected]>
    Fixes: cd24834130ac ("s390/pci: base support")
    Signed-off-by: Niklas Schnelle <[email protected]>
    [[email protected] replaced spaces with tabs]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/fair: Update min_vruntime for reweight_entity() correctly [+ + +]
Author: Yiwei Lin <[email protected]>
Date:   Fri Nov 17 16:01:06 2023 +0800

    sched/fair: Update min_vruntime for reweight_entity() correctly
    
    [ Upstream commit 5068d84054b766efe7c6202fc71b2350d1c326f1 ]
    
    Since reweight_entity() may have chance to change the weight of
    cfs_rq->curr entity, we should also update_min_vruntime() if
    this is the case
    
    Fixes: eab03c23c2a1 ("sched/eevdf: Fix vruntime adjustment on reweight")
    Signed-off-by: Yiwei Lin <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Abel Wu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: bfa: Use the proper data type for BLIST flags [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Wed Nov 15 11:33:38 2023 -0800

    scsi: bfa: Use the proper data type for BLIST flags
    
    [ Upstream commit 0349be31e4ffc79723e46e2e373569567b06347b ]
    
    Fix the following sparse warning:
    
    drivers/scsi/bfa/bfad_bsg.c:2553:50: sparse: sparse: incorrect type in initializer (different base types)
    
    Fixes: 2e5a6c3baccd ("scsi: bfa: Convert bfad_reset_sdev_bflags() from a macro into a function")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: fnic: Return error if vmalloc() failed [+ + +]
Author: Artem Chernyshev <[email protected]>
Date:   Tue Nov 28 14:10:08 2023 +0300

    scsi: fnic: Return error if vmalloc() failed
    
    [ Upstream commit f5f27a332a14f43463aa0075efa3a0c662c0f4a8 ]
    
    In fnic_init_module() exists redundant check for return value from
    fnic_debugfs_init(), because at moment it only can return zero. It make
    sense to process theoretical vmalloc() failure.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9730ddfb123d ("scsi: fnic: remove redundant assignment of variable rc")
    Signed-off-by: Artem Chernyshev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Karan Tilak Kumar <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hisi_sas: Check before using pointer variables [+ + +]
Author: Yihang Li <[email protected]>
Date:   Thu Dec 14 11:45:14 2023 +0800

    scsi: hisi_sas: Check before using pointer variables
    
    [ Upstream commit 8dd10296be8562a45c6c6794dd492a2b7dccede8 ]
    
    In commit 4b329abc9180 ("scsi: hisi_sas: Move slot variable definition in
    hisi_sas_abort_task()"), we move the variables slot to the function head.
    However, the variable slot may be NULL, we should check it in each branch.
    
    Fixes: 4b329abc9180 ("scsi: hisi_sas: Move slot variable definition in hisi_sas_abort_task()")
    Signed-off-by: Yihang Li <[email protected]>
    Signed-off-by: Xiang Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hisi_sas: Correct the number of global debugfs registers [+ + +]
Author: Yihang Li <[email protected]>
Date:   Thu Dec 14 11:45:16 2023 +0800

    scsi: hisi_sas: Correct the number of global debugfs registers
    
    [ Upstream commit 73e33f969ef05328766b23a99b2c07bfff765009 ]
    
    In function debugfs_debugfs_snapshot_global_reg_v3_hw() it uses
    debugfs_axi_reg.count (which is the number of axi debugfs registers) to
    acquire the number of global debugfs registers.
    
    Use debugfs_global_reg.count to acquire the number of global debugfs
    registers instead.
    
    Fixes: 623a4b6d5c2a ("scsi: hisi_sas: Move debugfs code to v3 hw driver")
    Signed-off-by: Yihang Li <[email protected]>
    Signed-off-by: Xiang Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hisi_sas: Replace with standard error code return value [+ + +]
Author: Yihang Li <[email protected]>
Date:   Thu Dec 14 11:45:13 2023 +0800

    scsi: hisi_sas: Replace with standard error code return value
    
    [ Upstream commit d34ee535705eb43885bc0f561c63046f697355ad ]
    
    In function hisi_sas_controller_prereset(), -ENOSYS (Function not
    implemented) should be returned if the driver does not support .soft_reset.
    Returns -EPERM (Operation not permitted) if HISI_SAS_RESETTING_BIT is
    already be set.
    
    In function _suspend_v3_hw(), returns -EPERM (Operation not permitted) if
    HISI_SAS_RESETTING_BIT is already be set.
    
    Fixes: 4522204ab218 ("scsi: hisi_sas: tidy host controller reset function a bit")
    Signed-off-by: Yihang Li <[email protected]>
    Signed-off-by: Xiang Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hisi_sas: Rollback some operations if FLR failed [+ + +]
Author: Yihang Li <[email protected]>
Date:   Thu Dec 14 11:45:15 2023 +0800

    scsi: hisi_sas: Rollback some operations if FLR failed
    
    [ Upstream commit 7ea3e7763c50b20a8bd25cf524ea0c6463de69be ]
    
    We obtain the semaphore and set HISI_SAS_RESETTING_BIT in
    hisi_sas_reset_prepare_v3_hw(), block the scsi host and set
    HISI_SAS_REJECT_CMD_BIT in hisi_sas_controller_reset_prepare(), released
    them in hisi_sas_controller_reset_done(). However, if the HW reset failure
    in FLR results in early return, the semaphore and flag bits will not be
    release.
    
    Rollback some operations including clearing flags / releasing semaphore
    when FLR is failed.
    
    Fixes: e5ea48014adc ("scsi: hisi_sas: Implement handlers of PCIe FLR for v3 hw")
    Signed-off-by: Yihang Li <[email protected]>
    Signed-off-by: Xiang Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: lpfc: Fix list_entry null check warning in lpfc_cmpl_els_plogi() [+ + +]
Author: Justin Tee <[email protected]>
Date:   Tue Oct 31 12:12:18 2023 -0700

    scsi: lpfc: Fix list_entry null check warning in lpfc_cmpl_els_plogi()
    
    [ Upstream commit 1dec1311b9b6cc9c5fd26a77b936f542f03c51d1 ]
    
    Smatch called out a warning for null checking a ptr that is assigned by
    list_entry(). list_entry() does not return null and, if the list is empty,
    can return an invalid ptr. Thus, the !psrp check does not execute properly.
    
     drivers/scsi/lpfc/lpfc_els.c:2133 lpfc_cmpl_els_plogi()
     warn: list_entry() does not return NULL 'prsp'
    
    Replace list_entry() with list_get_first(), which does a list_empty() check
    before returning the first entry.
    
    Fixes: a3c3c0a806f1 ("scsi: lpfc: Validate ELS LS_ACC completion payload")
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/linux-scsi/[email protected]/
    Signed-off-by: Justin Tee <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Himanshu Madhani <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpi3mr: Block PEL Enable Command on Controller Reset and Unrecoverable State [+ + +]
Author: Chandrakanth patil <[email protected]>
Date:   Sun Nov 26 11:01:33 2023 +0530

    scsi: mpi3mr: Block PEL Enable Command on Controller Reset and Unrecoverable State
    
    commit f8fb3f39148e8010479e4b2003ba4728818ec661 upstream.
    
    If a controller reset is underway or the controller is in an unrecoverable
    state, the PEL enable management command will be returned as EAGAIN or
    EFAULT.
    
    Cc: <[email protected]> # v6.1+
    Co-developed-by: Sathya Prakash <[email protected]>
    Signed-off-by: Sathya Prakash <[email protected]>
    Signed-off-by: Chandrakanth patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: mpi3mr: Clean up block devices post controller reset [+ + +]
Author: Chandrakanth patil <[email protected]>
Date:   Sun Nov 26 11:01:32 2023 +0530

    scsi: mpi3mr: Clean up block devices post controller reset
    
    commit c01d515687e358b22aa8414d6dac60d7defa6eb9 upstream.
    
    After a controller reset, if the firmware changes the state of devices to
    "hide", then remove those devices from the OS.
    
    Cc: <[email protected]> # v6.6+
    Co-developed-by: Sathya Prakash <[email protected]>
    Signed-off-by: Sathya Prakash <[email protected]>
    Signed-off-by: Chandrakanth patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: mpi3mr: Refresh sdev queue depth after controller reset [+ + +]
Author: Chandrakanth patil <[email protected]>
Date:   Sun Nov 26 11:01:31 2023 +0530

    scsi: mpi3mr: Refresh sdev queue depth after controller reset
    
    commit e5aab848dfdf7996d20ece4d28d2733c732c5e5a upstream.
    
    After a controller reset, the firmware may modify the device queue depth.
    Therefore, update the device queue depth accordingly.
    
    Cc: <[email protected]> # v5.15+
    Co-developed-by: Sathya Prakash <[email protected]>
    Signed-off-by: Sathya Prakash <[email protected]>
    Signed-off-by: Chandrakanth patil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: target: core: add missing file_{start,end}_write() [+ + +]
Author: Amir Goldstein <[email protected]>
Date:   Thu Nov 23 11:20:00 2023 +0200

    scsi: target: core: add missing file_{start,end}_write()
    
    commit 0db1d53937fafa8bb96e077375691e16902f4899 upstream.
    
    The callers of vfs_iter_write() are required to hold file_start_write().
    file_start_write() is a no-op for the S_ISBLK() case, but it is really
    needed when the backing file is a regular file.
    
    We are going to move file_{start,end}_write() into vfs_iter_write(), but
    we need to fix this first, so that the fix could be backported to stable
    kernels.
    
    Suggested-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Cc:  <[email protected]>
    Signed-off-by: Amir Goldstein <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Martin K. Petersen <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Jens Axboe <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: core: Simplify power management during async scan [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Mon Dec 18 14:52:14 2023 -0800

    scsi: ufs: core: Simplify power management during async scan
    
    commit daf7795406bf307997366f694888bd317ae5b5fa upstream.
    
    ufshcd_init() calls pm_runtime_get_sync() before it calls
    async_schedule(). ufshcd_async_scan() calls pm_runtime_put_sync() directly
    or indirectly from ufshcd_add_lus(). Simplify ufshcd_async_scan() by always
    calling pm_runtime_put_sync() from ufshcd_async_scan().
    
    Cc: <[email protected]>
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Can Guo <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: qcom: Fix the return value of ufs_qcom_ice_program_key() [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Fri Dec 8 12:28:47 2023 +0530

    scsi: ufs: qcom: Fix the return value of ufs_qcom_ice_program_key()
    
    [ Upstream commit 3bf7ab4ac30c03beecf57c052e87d5a38fb8aed6 ]
    
    Currently, the function returns -EINVAL if algorithm other than AES-256-XTS
    is requested. But the correct error code is -EOPNOTSUPP. Fix it!
    
    Cc: Abel Vesa <[email protected]>
    Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API")
    Reviewed-by: Abel Vesa <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Andrew Halaney <[email protected]> # sa8775p-ride
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Fix the return value when platform_get_resource_byname() fails [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Fri Dec 8 12:28:48 2023 +0530

    scsi: ufs: qcom: Fix the return value when platform_get_resource_byname() fails
    
    [ Upstream commit 3a747c5cf9b6c36649783b28d2ef8f9c92b16a0f ]
    
    The return value should be -ENODEV indicating that the resource is not
    provided in DT, not -ENOMEM. Fix it!
    
    Fixes: c263b4ef737e ("scsi: ufs: core: mcq: Configure resource regions")
    Reviewed-by: Andrew Halaney <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Andrew Halaney <[email protected]> # sa8775p-ride
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sctp: fix busy polling [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Dec 19 17:00:17 2023 +0000

    sctp: fix busy polling
    
    [ Upstream commit a562c0a2d651e040681b0bfce9b4d229ac3b0b8c ]
    
    Busy polling while holding the socket lock makes litle sense,
    because incoming packets wont reach our receive queue.
    
    Fixes: 8465a5fcd1ce ("sctp: add support for busy polling to sctp protocol")
    Reported-by: Jacob Moroni <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Marcelo Ricardo Leitner <[email protected]>
    Cc: Xin Long <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sctp: support MSG_ERRQUEUE flag in recvmsg() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Dec 12 14:55:50 2023 +0000

    sctp: support MSG_ERRQUEUE flag in recvmsg()
    
    [ Upstream commit 4746b36b1abe11ca32987b2d21e1e770deab17cc ]
    
    For some reason sctp_poll() generates EPOLLERR if sk->sk_error_queue
    is not empty but recvmsg() can not drain the error queue yet.
    
    This is needed to better support timestamping.
    
    I had to export inet_recv_error(), since sctp
    can be compiled as a module.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Marcelo Ricardo Leitner <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Acked-by: Xin Long <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: a562c0a2d651 ("sctp: fix busy polling")
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Add assert for user stacks in test_task_stack [+ + +]
Author: Jordan Rome <[email protected]>
Date:   Sat Nov 11 18:30:10 2023 -0800

    selftests/bpf: Add assert for user stacks in test_task_stack
    
    commit 727a92d62fd6a382b4c5972008e45667e707b0e4 upstream.
    
    This is a follow up to:
    commit b8e3a87a627b ("bpf: Add crosstask check to __bpf_get_stack").
    
    This test ensures that the task iterator only gets a single
    user stack (for the current task).
    
    Signed-off-by: Jordan Rome <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Stanislav Fomichev <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests/bpf: Fix erroneous bitmask operation [+ + +]
Author: Jeroen van Ingen Schenau <[email protected]>
Date:   Thu Nov 30 13:03:53 2023 +0100

    selftests/bpf: Fix erroneous bitmask operation
    
    [ Upstream commit b6a3451e0847d5d70fb5fa2b2a80ab9f80bf2c7b ]
    
    xdp_synproxy_kern.c is a BPF program that generates SYN cookies on
    allowed TCP ports and sends SYNACKs to clients, accelerating synproxy
    iptables module.
    
    Fix the bitmask operation when checking the status of an existing
    conntrack entry within tcp_lookup() function. Do not AND with the bit
    position number, but with the bitmask value to check whether the entry
    found has the IPS_CONFIRMED flag set.
    
    Fixes: fb5cd0ce70d4 ("selftests/bpf: Add selftests for raw syncookie helpers")
    Signed-off-by: Jeroen van Ingen Schenau <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Tested-by: Minh Le Hoang <[email protected]>
    Link: https://lore.kernel.org/xdp-newbies/CAAi1gX7owA+Tcxq-titC-h-KPM7Ri-6ZhTNMhrnPq5gmYYwKow@mail.gmail.com/T/#u
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Relax time_tai test for equal timestamps in tai_forward [+ + +]
Author: YiFei Zhu <[email protected]>
Date:   Tue Dec 12 18:29:11 2023 +0000

    selftests/bpf: Relax time_tai test for equal timestamps in tai_forward
    
    [ Upstream commit e1ba7f64b192f083b4423644be03bb9e3dc8ae84 ]
    
    We're observing test flakiness on an arm64 platform which might not
    have timestamps as precise as x86. The test log looks like:
    
      test_time_tai:PASS:tai_open 0 nsec
      test_time_tai:PASS:test_run 0 nsec
      test_time_tai:PASS:tai_ts1 0 nsec
      test_time_tai:PASS:tai_ts2 0 nsec
      test_time_tai:FAIL:tai_forward unexpected tai_forward: actual 1702348135471494160 <= expected 1702348135471494160
      test_time_tai:PASS:tai_gettime 0 nsec
      test_time_tai:PASS:tai_future_ts1 0 nsec
      test_time_tai:PASS:tai_future_ts2 0 nsec
      test_time_tai:PASS:tai_range_ts1 0 nsec
      test_time_tai:PASS:tai_range_ts2 0 nsec
      #199     time_tai:FAIL
    
    This patch changes ASSERT_GT to ASSERT_GE in the tai_forward assertion
    so that equal timestamps are permitted.
    
    Fixes: 64e15820b987 ("selftests/bpf: Add BPF-helper test for CLOCK_TAI access")
    Signed-off-by: YiFei Zhu <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/net: fix grep checking for fib_nexthop_multiprefix [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Wed Dec 13 14:08:49 2023 +0800

    selftests/net: fix grep checking for fib_nexthop_multiprefix
    
    [ Upstream commit a33e9da3470499e9ff476138f271fb52d6bfe767 ]
    
    When running fib_nexthop_multiprefix test I saw all IPv6 test failed.
    e.g.
    
     ]# ./fib_nexthop_multiprefix.sh
     TEST: IPv4: host 0 to host 1, mtu 1300                              [ OK ]
     TEST: IPv6: host 0 to host 1, mtu 1300                              [FAIL]
    
     With -v it shows
    
     COMMAND: ip netns exec h0 /usr/sbin/ping6 -s 1350 -c5 -w5 2001:db8:101::1
     PING 2001:db8:101::1(2001:db8:101::1) 1350 data bytes
     From 2001:db8:100::64 icmp_seq=1 Packet too big: mtu=1300
    
     --- 2001:db8:101::1 ping statistics ---
     1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
    
     Route get
     2001:db8:101::1 via 2001:db8:100::64 dev eth0 src 2001:db8:100::1 metric 1024 expires 599sec mtu 1300 pref medium
     Searching for:
         2001:db8:101::1 from :: via 2001:db8:100::64 dev eth0 src 2001:db8:100::1 .* mtu 1300
    
    The reason is when CONFIG_IPV6_SUBTREES is not enabled, rt6_fill_node() will
    not put RTA_SRC info. After fix:
    
    ]# ./fib_nexthop_multiprefix.sh
    TEST: IPv4: host 0 to host 1, mtu 1300                              [ OK ]
    TEST: IPv6: host 0 to host 1, mtu 1300                              [ OK ]
    
    Fixes: 735ab2f65dce ("selftests: Add test with multiple prefixes using single nexthop")
    Signed-off-by: Hangbin Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/net: specify the interface when do arping [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Sat Dec 2 10:00:59 2023 +0800

    selftests/net: specify the interface when do arping
    
    [ Upstream commit 7f770d28f2e5abfd442ad689ba1129dd66593529 ]
    
    When do arping, the interface need to be specified. Or we will
    get error: Interface "lo" is not ARPable. And the test failed.
    ]# ./arp_ndisc_untracked_subnets.sh
        TEST: test_arp:  accept_arp=0                                       [ OK ]
        TEST: test_arp:  accept_arp=1                                       [FAIL]
        TEST: test_arp:  accept_arp=2  same_subnet=0                        [ OK ]
        TEST: test_arp:  accept_arp=2  same_subnet=1                        [FAIL]
    
    After fix:
    ]# ./arp_ndisc_untracked_subnets.sh
        TEST: test_arp:  accept_arp=0                                       [ OK ]
        TEST: test_arp:  accept_arp=1                                       [ OK ]
        TEST: test_arp:  accept_arp=2  same_subnet=0                        [ OK ]
        TEST: test_arp:  accept_arp=2  same_subnet=1                        [ OK ]
    
    Fixes: 0ea7b0a454ca ("selftests: net: arp_ndisc_untracked_subnets: test for arp_accept and accept_untracked_na")
    Signed-off-by: Hangbin Liu <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/powerpc: Fix error handling in FPU/VMX preemption tests [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Wed Nov 29 00:27:44 2023 +1100

    selftests/powerpc: Fix error handling in FPU/VMX preemption tests
    
    [ Upstream commit 9dbd5927408c4a0707de73ae9dd9306b184e8fee ]
    
    The FPU & VMX preemption tests do not check for errors returned by the
    low-level asm routines, preempt_fpu() / preempt_vsx() respectively.
    That means any register corruption detected by the asm routines does not
    result in a test failure.
    
    Fix it by returning the return value of the asm routines from the
    pthread child routines.
    
    Fixes: e5ab8be68e44 ("selftests/powerpc: Test preservation of FPU and VMX regs across preemption")
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/sgx: Fix uninitialized pointer dereference in error path [+ + +]
Author: Jo Van Bulck <[email protected]>
Date:   Thu Oct 5 17:38:42 2023 +0200

    selftests/sgx: Fix uninitialized pointer dereference in error path
    
    [ Upstream commit 79eba8c924f7decfa71ddf187d38cb9f5f2cd7b3 ]
    
    Ensure ctx is zero-initialized, such that the encl_measure function will
    not call EVP_MD_CTX_destroy with an uninitialized ctx pointer in case of an
    early error during key generation.
    
    Fixes: 2adcba79e69d ("selftests/x86: Add a selftest for SGX")
    Signed-off-by: Jo Van Bulck <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Acked-by: Kai Huang <[email protected]>
    Link: https://lore.kernel.org/all/20231005153854.25566-2-jo.vanbulck%40cs.kuleuven.be
    Signed-off-by: Sasha Levin <[email protected]>

selftests/sgx: Fix uninitialized pointer dereferences in encl_get_entry [+ + +]
Author: Jo Van Bulck <[email protected]>
Date:   Thu Oct 5 17:38:43 2023 +0200

    selftests/sgx: Fix uninitialized pointer dereferences in encl_get_entry
    
    [ Upstream commit b84fc2e0139ba4b23b8039bd7cfd242894fe8f8b ]
    
    Ensure sym_tab and sym_names are zero-initialized and add an early-out
    condition in the unlikely (erroneous) case that the enclave ELF file would
    not contain a symbol table.
    
    This addresses -Werror=maybe-uninitialized compiler warnings for gcc -O2.
    
    Fixes: 33c5aac3bf32 ("selftests/sgx: Test complete changing of page type flow")
    Signed-off-by: Jo Van Bulck <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Link: https://lore.kernel.org/all/20231005153854.25566-3-jo.vanbulck%40cs.kuleuven.be
    Signed-off-by: Sasha Levin <[email protected]>

selftests/sgx: Include memory clobber for inline asm in test enclave [+ + +]
Author: Jo Van Bulck <[email protected]>
Date:   Thu Oct 5 17:38:44 2023 +0200

    selftests/sgx: Include memory clobber for inline asm in test enclave
    
    [ Upstream commit 853a57a43ebdb8c024160c1a0990bae85f4bcc2f ]
    
    Add the "memory" clobber to the EMODPE and EACCEPT asm blocks to tell the
    compiler the assembly code accesses to the secinfo struct. This ensures
    the compiler treats the asm block as a memory barrier and the write to
    secinfo will be visible to ENCLU.
    
    Fixes: 20404a808593 ("selftests/sgx: Add test for EPCM permission changes")
    Signed-off-by: Jo Van Bulck <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Kai Huang <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Link: https://lore.kernel.org/all/20231005153854.25566-4-jo.vanbulck%40cs.kuleuven.be
    Signed-off-by: Sasha Levin <[email protected]>

selftests/sgx: Skip non X86_64 platform [+ + +]
Author: Zhao Mengmeng <[email protected]>
Date:   Tue Dec 5 21:56:05 2023 -0500

    selftests/sgx: Skip non X86_64 platform
    
    [ Upstream commit 981cf568a8644161c2f15c02278ebc2834b51ba6 ]
    
    When building whole selftests on arm64, rsync gives an erorr about sgx:
    
    rsync: [sender] link_stat "/root/linux-next/tools/testing/selftests/sgx/test_encl.elf" failed: No such file or directory (2)
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1327) [sender=3.2.5]
    
    The root casue is sgx only used on X86_64, and shall be skipped on other
    platforms.
    
    Fix this by moving TEST_CUSTOM_PROGS and TEST_FILES inside the if check,
    then the build result will be "Skipping non-existent dir: sgx".
    
    Fixes: 2adcba79e69d ("selftests/x86: Add a selftest for SGX")
    Signed-off-by: Zhao Mengmeng <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Link: https://lore.kernel.org/all/20231206025605.3965302-1-zhaomzhao%40126.com
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/xsk: Fix for SEND_RECEIVE_UNALIGNED test [+ + +]
Author: Tushar Vyavahare <[email protected]>
Date:   Thu Dec 14 13:00:07 2023 +0000

    selftests/xsk: Fix for SEND_RECEIVE_UNALIGNED test
    
    [ Upstream commit 2e1d6a04116c373fbd25beddba4267178535bc60 ]
    
    Fix test broken by shared umem test and framework enhancement commit.
    
    Correct the current implementation of pkt_stream_replace_half() by
    ensuring that nb_valid_entries are not set to half, as this is not true
    for all the tests. Ensure that the expected value for valid_entries for
    the SEND_RECEIVE_UNALIGNED test equals the total number of packets sent,
    which is 4096.
    
    Create a new function called pkt_stream_pkt_set() that allows for packet
    modification to meet specific requirements while ensuring the accurate
    maintenance of the valid packet count to prevent inconsistencies in packet
    tracking.
    
    Fixes: 6d198a89c004 ("selftests/xsk: Add a test for shared umem feature")
    Reported-by: Maciej Fijalkowski <[email protected]>
    Signed-off-by: Tushar Vyavahare <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Maciej Fijalkowski <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: bonding: Change script interpreter [+ + +]
Author: Benjamin Poirier <[email protected]>
Date:   Wed Jan 10 09:14:35 2024 -0500

    selftests: bonding: Change script interpreter
    
    [ Upstream commit c2518da8e6b0e248cfff1d4b6682e14020bd4d3f ]
    
    The tests changed by this patch, as well as the scripts they source, use
    features which are not part of POSIX sh (ex. 'source' and 'local'). As a
    result, these tests fail when /bin/sh is dash such as on Debian. Change the
    interpreter to bash so that these tests can run successfully.
    
    Fixes: d43eff0b85ae ("selftests: bonding: up/down delay w/ slave link flapping")
    Tested-by: Hangbin Liu <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Reviewed-by: Petr Machata <[email protected]>
    Signed-off-by: Benjamin Poirier <[email protected]>
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes [+ + +]
Author: Amit Cohen <[email protected]>
Date:   Wed Jan 17 16:04:21 2024 +0100

    selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes
    
    [ Upstream commit b34f4de6d30cbaa8fed905a5080b6eace8c84dc7 ]
    
    'qos_pfc' test checks PFC behavior. The idea is to limit the traffic
    using a shaper somewhere in the flow of the packets. In this area, the
    buffer is smaller than the buffer at the beginning of the flow, so it fills
    up until there is no more space left. The test configures there PFC
    which is supposed to notice that the headroom is filling up and send PFC
    Xoff to indicate the transmitter to stop sending traffic for the priorities
    sharing this PG.
    
    The Xon/Xoff threshold is auto-configured and always equal to
    2*(MTU rounded up to cell size). Even after sending the PFC Xoff packet,
    traffic will keep arriving until the transmitter receives and processes
    the PFC packet. This amount of traffic is known as the PFC delay allowance.
    
    Currently the buffer for the delay traffic is configured as 100KB. The
    MTU in the test is 10KB, therefore the threshold for Xoff is about 20KB.
    This allows 80KB extra to be stored in this buffer.
    
    8-lane ports use two buffers among which the configured buffer is split,
    the Xoff threshold then applies to each buffer in parallel.
    
    The test does not take into account the behavior of 8-lane ports, when the
    ports are configured to 400Gbps with 8 lanes or 800Gbps with 8 lanes,
    packets are dropped and the test fails.
    
    Check if the relevant ports use 8 lanes, in such case double the size of
    the buffer, as the headroom is split half-half.
    
    Cc: Shuah Khan <[email protected]>
    Fixes: bfa804784e32 ("selftests: mlxsw: Add a PFC test")
    Signed-off-by: Amit Cohen <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Link: https://lore.kernel.org/r/23ff11b7dff031eb04a41c0f5254a2b636cd8ebb.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selinux: Fix error priority for bind with AF_UNSPEC on PF_INET6 socket [+ + +]
Author: Mickaël Salaün <[email protected]>
Date:   Wed Jan 3 17:34:15 2024 +0100

    selinux: Fix error priority for bind with AF_UNSPEC on PF_INET6 socket
    
    [ Upstream commit bbf5a1d0e5d0fb3bdf90205aa872636122692a50 ]
    
    The IPv6 network stack first checks the sockaddr length (-EINVAL error)
    before checking the family (-EAFNOSUPPORT error).
    
    This was discovered thanks to commit a549d055a22e ("selftests/landlock:
    Add network tests").
    
    Cc: Eric Paris <[email protected]>
    Cc: Konstantin Meskhidze <[email protected]>
    Cc: Paul Moore <[email protected]>
    Cc: Stephen Smalley <[email protected]>
    Reported-by: Muhammad Usama Anjum <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 0f8db8cc73df ("selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()")
    Signed-off-by: Mickaël Salaün <[email protected]>
    Tested-by: Muhammad Usama Anjum <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Nov 10 16:29:29 2023 +0100

    serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
    
    [ Upstream commit ad90d0358bd3b4554f243a425168fc7cebe7d04e ]
    
    Returning an error code from .remove() makes the driver core emit the
    little helpful error message:
    
            remove callback returned a non-zero value. This will be ignored.
    
    and then remove the device anyhow. So all resources that were not freed
    are leaked in this case. Skipping serial8250_unregister_port() has the
    potential to keep enough of the UART around to trigger a use-after-free.
    
    So replace the error return (and with it the little helpful error
    message) by a more useful error message and continue to cleanup.
    
    Fixes: e3f0c638f428 ("serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Reviewed-by: Tony Lindgren <[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]>

serial: 8250_bcm2835aux: Restore clock error handling [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Wed Dec 20 12:43:34 2023 +0100

    serial: 8250_bcm2835aux: Restore clock error handling
    
    commit 83e571f054cd742eb9a46d46ef05193904adf53f upstream.
    
    The commit fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support")
    dropped the error handling for clock acquiring. But even an optional
    clock needs this.
    
    Fixes: fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support")
    Cc: stable <[email protected]>
    Signed-off-by: Stefan Wahren <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: 8250_exar: Set missing rs485_supported flag [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:18 2024 +0100

    serial: 8250_exar: Set missing rs485_supported flag
    
    commit 0c2a5f471ce58bca8f8ab5fcb911aff91eaaa5eb upstream.
    
    The UART supports an auto-RTS mode in which the RTS pin is automatically
    activated during transmission. So mark this mode as being supported even
    if RTS is not controlled by the driver but the UART.
    
    Also the serial core expects now at least one of both modes rts-on-send or
    rts-after-send to be supported. This is since during sanitization
    unsupported flags are deleted from a RS485 configuration set by userspace.
    However if the configuration ends up with both flags unset, the core prints
    a warning since it considers such a configuration invalid (see
    uart_sanitize_serial_rs485()).
    
    Cc:  <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: apbuart: fix console prompt on qemu [+ + +]
Author: Sam Ravnborg <[email protected]>
Date:   Tue Dec 26 13:16:07 2023 +0100

    serial: apbuart: fix console prompt on qemu
    
    [ Upstream commit c6dcd8050fb7c2efec6946ae9c49bc186b0a7475 ]
    
    When using a leon kernel with qemu there where no console prompt.
    The root cause is the handling of the fifo size in the tx part of the
    apbuart driver.
    
    The qemu uart driver only have a very rudimentary status handling and do
    not report the number of chars queued in the tx fifo in the status register.
    So the driver ends up with a fifo size of 1.
    
    In the tx path the fifo size is divided by 2 - resulting in a fifo
    size of zero.
    
    The original implementation would always try to send one char, but
    after the introduction of uart_port_tx_limited() the fifo size is
    respected even for the first char.
    
    There seems to be no good reason to divide the fifo size with two - so
    remove this. It looks like something copied from the original amba driver.
    
    With qemu we now have a minimum fifo size of one char, so we show
    the prompt.
    
    Signed-off-by: Sam Ravnborg <[email protected]>
    Fixes: d11cc8c3c4b6 ("tty: serial: use uart_port_tx_limited()")
    Cc: Andreas Larsson <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Cc:  <[email protected]>
    Cc:  <[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]>

serial: core, imx: do not set RS485 enabled if it is not supported [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:16 2024 +0100

    serial: core, imx: do not set RS485 enabled if it is not supported
    
    commit 74eab89b26ac433ad857292f4707b43c1a8f0209 upstream.
    
    If the imx driver cannot support RS485 it nullifies the ports
    rs485_supported structure. But it still calls uart_get_rs485_mode() which
    may set the RS485_ENABLED flag nevertheless.
    
    This may lead to an attempt to configure RS485 even if it is not supported
    when the flag is evaluated in uart_configure_port() at port startup.
    
    Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED
    flag is not supported by the caller.
    
    With this fix a check for RTS availability is now obsolete in the imx
    driver, since it can not evaluate to true any more. So remove this check.
    
    Furthermore the explicit nullifcation of rs485_supported is not needed,
    since the memory has already been set to zeros at allocation. So remove
    this, too.
    
    Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported")
    Cc: Shawn Guo <[email protected]>
    Cc: Sascha Hauer <[email protected]>
    Cc:  <[email protected]>
    Suggested-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: core: fix sanitizing check for RTS settings [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:14 2024 +0100

    serial: core: fix sanitizing check for RTS settings
    
    commit 4afeced55baa391490b61ed9164867e2927353ed upstream.
    
    Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
    settings in a RS485 configuration that has been passed by userspace.
    If RTS-on-send and RTS-after-send are both set or unset the configuration
    is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
    
    This however makes only sense if both RTS modes are actually supported by
    the driver.
    
    With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
    take the driver support into account but only checks if one of both RTS
    modes are supported. This may lead to the errorneous result of RTS-on-send
    being set even if only RTS-after-send is supported.
    
    Fix this by changing the implemented logic: First clear all unsupported
    flags in the RS485 configuration, then adjust an invalid RTS setting by
    taking into account which RTS mode is supported.
    
    Cc:  <[email protected]>
    Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: core: make sure RS485 cannot be enabled when it is not supported [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:15 2024 +0100

    serial: core: make sure RS485 cannot be enabled when it is not supported
    
    commit c73986913fa47e71e0b1ad7f039f6444915e8810 upstream.
    
    Some uart drivers specify a rs485_config() function and then decide later
    to disable RS485 support for some reason (e.g. imx and ar933).
    
    In these cases userspace may be able to activate RS485 via TIOCSRS485
    nevertheless, since in uart_set_rs485_config() an existing rs485_config()
    function indicates that RS485 is supported.
    
    Make sure that this is not longer possible by checking the uarts
    rs485_supported.flags instead and bailing out if SER_RS485_ENABLED is not
    set.
    
    Furthermore instead of returning an empty structure return -ENOTTY if the
    RS485 configuration is requested via TIOCGRS485 but RS485 is not supported.
    This has a small impact on userspace visibility but it is consistent with
    the -ENOTTY error for TIOCGRS485.
    
    Fixes: e849145e1fdd ("serial: ar933x: Fill in rs485_supported")
    Fixes: 55e18c6b6d42 ("serial: imx: Remove serial_rs485 sanitization")
    Cc: Shawn Guo <[email protected]>
    Cc: Sascha Hauer <[email protected]>
    Cc:  <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: core: set missing supported flag for RX during TX GPIO [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:13 2024 +0100

    serial: core: set missing supported flag for RX during TX GPIO
    
    commit 1a33e33ca0e80d485458410f149265cdc0178cfa upstream.
    
    If the RS485 feature RX-during-TX is supported by means of a GPIO set the
    according supported flag. Otherwise setting this feature from userspace may
    not be possible, since in uart_sanitize_serial_rs485() the passed RS485
    configuration is matched against the supported features and unsupported
    settings are thereby removed and thus take no effect.
    
    Cc:  <[email protected]>
    Fixes: 163f080eb717 ("serial: core: Add option to output RS485 RX_DURING_TX state via GPIO")
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: Do not hold the port lock when setting rx-during-tx GPIO [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:12 2024 +0100

    serial: Do not hold the port lock when setting rx-during-tx GPIO
    
    commit 07c30ea5861fb26a77dade8cdc787252f6122fb1 upstream.
    
    Both the imx and stm32 driver set the rx-during-tx GPIO in rs485_config().
    Since this function is called with the port lock held, this can be a
    problem in case that setting the GPIO line can sleep (e.g. if a GPIO
    expander is used which is connected via SPI or I2C).
    
    Avoid this issue by moving the GPIO setting outside of the port lock into
    the serial core and thus making it a generic feature.
    
    Also with commit c54d48543689 ("serial: stm32: Add support for rs485
    RX_DURING_TX output GPIO") the SER_RS485_RX_DURING_TX flag is only set if a
    rx-during-tx GPIO is _not_ available, which is wrong. Fix this, too.
    
    Furthermore reset old GPIO settings in case that changing the RS485
    configuration failed.
    
    Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO")
    Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO")
    Cc: Shawn Guo <[email protected]>
    Cc: Sascha Hauer <[email protected]>
    Cc:  <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: imx: Correct clock error message in function probe() [+ + +]
Author: Christoph Niedermaier <[email protected]>
Date:   Sun Dec 24 10:32:09 2023 +0100

    serial: imx: Correct clock error message in function probe()
    
    [ Upstream commit 3e189470cad27d41a3a9dc02649f965b7ed1c90f ]
    
    Correct the clock error message by changing the clock name.
    
    Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails")
    Signed-off-by: Christoph Niedermaier <[email protected]>
    Reviewed-by: Uwe Kleine-König <[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]>

serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock [+ + +]
Author: Christoph Niedermaier <[email protected]>
Date:   Tue Dec 26 12:36:47 2023 +0100

    serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock
    
    commit 7c45eaa813476bd195ac1227a64b52f9cf2e2030 upstream.
    
    There are register accesses in the function imx_uart_rs485_config(). The
    clock must be enabled for these accesses. This was ensured by calling it
    via the function uart_rs485_config() in the probe() function within the
    range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
    Deassert Transmit Enable on probe in driver-specific way") it was removed
    from the probe() function and is now only called through the function
    uart_add_one_port() which is located at the end of the probe() function.
    But the clock is already switched off in this area. To ensure that the
    clock is enabled during register access, move the disabling of the clock
    to the very end of the probe() function. To avoid leaking enabled clocks
    on error also add an error path for exiting with disabling the clock.
    
    Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
    Cc: stable <[email protected]>
    Signed-off-by: Christoph Niedermaier <[email protected]>
    Reviewed-by: Lukas Wunner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: imx: fix tx statemachine deadlock [+ + +]
Author: Paul Geurts <[email protected]>
Date:   Fri Nov 24 14:11:10 2023 +0100

    serial: imx: fix tx statemachine deadlock
    
    [ Upstream commit 78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0 ]
    
    When using the serial port as RS485 port, the tx statemachine is used to
    control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
    TTY port is closed in the middle of a transmission (for instance during
    userland application crash), imx_uart_shutdown disables the interface
    and disables the Transmission Complete interrupt. afer that,
    imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
    by the TC interrupt. This interrupt is disabled and therefore the tx
    statemachine never transitions out of SEND. The statemachine is in
    deadlock now, and the TX_EN remains low, making the interface useless.
    
    imx_uart_stop_tx now checks for incomplete transmission AND whether TC
    interrupts are enabled before bailing to be retriggered. This makes sure
    the state machine handling is reached, and is properly set to
    WAIT_AFTER_SEND.
    
    Fixes: cb1a60923609 ("serial: imx: implement rts delaying for rs485")
    Signed-off-by: Paul Geurts <[email protected]>
    Tested-by: Rasmus Villemoes <[email protected]>
    Tested-by: Eberhard Stoll <[email protected]>
    Link: https://lore.kernel.org/r/AM0PR09MB26758F651BC1B742EB45775995B8A@AM0PR09MB2675.eurprd09.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: omap: do not override settings for RS485 support [+ + +]
Author: Lino Sanfilippo <[email protected]>
Date:   Wed Jan 3 07:18:17 2024 +0100

    serial: omap: do not override settings for RS485 support
    
    commit 51f93776b84dee23e44a7be880736669a01cec2b upstream.
    
    The drivers RS485 support is deactivated if there is no RTS GPIO available.
    This is done by nullifying the ports rs485_supported struct. After that
    however the settings in serial_omap_rs485_supported are assigned to the
    same structure unconditionally, which results in an unintended reactivation
    of RS485 support.
    
    Fix this by moving the assignment to the beginning of
    serial_omap_probe_rs485() and thus before uart_get_rs485_mode() gets
    called.
    
    Also replace the assignment of rs485_config() to have the complete RS485
    setup in one function.
    
    Fixes: e2752ae3cfc9 ("serial: omap: Disallow RS-485 if rts-gpio is not specified")
    Cc:  <[email protected]>
    Signed-off-by: Lino Sanfilippo <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: sc16is7xx: add check for unsupported SPI modes during probe [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Thu Dec 21 18:18:09 2023 -0500

    serial: sc16is7xx: add check for unsupported SPI modes during probe
    
    commit 6d710b769c1f5f0d55c9ad9bb49b7dce009ec103 upstream.
    
    The original comment is confusing because it implies that variants other
    than the SC16IS762 supports other SPI modes beside SPI_MODE_0.
    
    Extract from datasheet:
        The SC16IS762 differs from the SC16IS752 in that it supports SPI clock
        speeds up to 15 Mbit/s instead of the 4 Mbit/s supported by the
        SC16IS752... In all other aspects, the SC16IS762 is functionally and
        electrically the same as the SC16IS752.
    
    The same is also true of the SC16IS760 variant versus the SC16IS740 and
    SC16IS750 variants.
    
    For all variants, only SPI mode 0 is supported.
    
    Change comment and abort probing if the specified SPI mode is not
    SPI_MODE_0.
    
    Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added")
    Cc:  <[email protected]>
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: sc16is7xx: set safe default SPI clock frequency [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Thu Dec 21 18:18:10 2023 -0500

    serial: sc16is7xx: set safe default SPI clock frequency
    
    commit 3ef79cd1412236d884ab0c46b4d1921380807b48 upstream.
    
    15 MHz is supported only by 76x variants.
    
    If the SPI clock frequency is not specified, use a safe default clock value
    of 4 MHz that is supported by all variants.
    
    Also use HZ_PER_MHZ macro to improve readability.
    
    Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added")
    Cc:  <[email protected]>
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
soc: qcom: llcc: Fix dis_cap_alloc and retain_on_pc configuration [+ + +]
Author: Atul Dhudase <[email protected]>
Date:   Wed Dec 6 21:02:51 2023 +0530

    soc: qcom: llcc: Fix dis_cap_alloc and retain_on_pc configuration
    
    [ Upstream commit eed6e57e9f3e2beac37563eb6a0129549daa330e ]
    
    Commit c14e64b46944 ("soc: qcom: llcc: Support chipsets that can
     write to llcc") add the support for chipset where capacity based
    allocation and retention through power collapse can be programmed
    based on content of SCT table mentioned in the llcc driver where
    the target like sdm845 where the entire programming related to it
    is controlled in firmware. However, the commit introduces a bug
    where capacity/retention register get overwritten each time it
    gets programmed for each slice and that results in misconfiguration
    of the register based on SCT table and that is not expected
    behaviour instead it should be read modify write to retain the
    configuration of other slices.
    
    This issue is totally caught from code review and programming test
    and not through any power/perf numbers so, it is not known what
    impact this could make if we don't have this change however,
    this feature are for these targets and they should have been
    programmed accordingly as per their configuration mentioned in
    SCT table like others bits information.
    
    This change brings one difference where it keeps capacity/retention
    bits of the slices that are not mentioned in SCT table in unknown
    state where as earlier it was initialized to zero.
    
    Fixes: c14e64b46944 ("soc: qcom: llcc: Support chipsets that can write to llcc")
    Signed-off-by: Atul Dhudase <[email protected]>
    Signed-off-by: Mukesh Ojha <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: llcc: Fix LLCC_TRP_ATTR2_CFGn offset [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Thu Oct 12 19:05:09 2023 +0300

    soc: qcom: llcc: Fix LLCC_TRP_ATTR2_CFGn offset
    
    [ Upstream commit 110cb8d861cc1a040cdab495b22ac436c49d1454 ]
    
    According to documentation, it has increments of 4, not 8.
    
    Fixes: c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support")
    Reported-by: Unnathi Chalicheemala <[email protected]>
    Reviewed-by: Satya Durga Srinivasu Prabhala <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
software node: Let args be NULL in software_node_get_reference_args [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Thu Nov 9 12:10:09 2023 +0200

    software node: Let args be NULL in software_node_get_reference_args
    
    [ Upstream commit 1eaea4b3604eb9ca7d9a1e73d88fc121bb4061f5 ]
    
    fwnode_get_property_reference_args() may not be called with args argument
    NULL and while OF already supports this. Add the missing NULL check.
    
    The purpose is to be able to count the references.
    
    Fixes: b06184acf751 ("software node: Add software_node_get_reference_args()")
    Signed-off-by: Sakari Ailus <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

 
spi: cadence-quadspi: add missing clk_disable_unprepare() in cqspi_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Wed Nov 29 16:11:47 2023 +0800

    spi: cadence-quadspi: add missing clk_disable_unprepare() in cqspi_probe()
    
    [ Upstream commit 5cb475174cce1bfedf1025b6e235e2c43d81144f ]
    
    cqspi_jh7110_clk_init() is called after clk_prepare_enable(cqspi->clk),
    if it fails, it should goto label 'probe_reset_failed' to disable
    cqspi->clk.
    
    In the error path after calling cqspi_jh7110_clk_init(),
    cqspi_jh7110_disable_clk() need be called.
    
    Fixes: 33f1ef6d4eb6 ("spi: cadence-quadspi: Add clock configuration for StarFive JH7110 QSPI")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: coldfire-qspi: Remove an erroneous clk_disable_unprepare() from the remove function [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Fri Jan 5 15:21:00 2024 +0100

    spi: coldfire-qspi: Remove an erroneous clk_disable_unprepare() from the remove function
    
    [ Upstream commit 17dc11a02d8dacc7e78968daa2a8c16281eb7d1e ]
    
    The commit in Fixes has changed a devm_clk_get()/clk_prepare_enable() into
    a devm_clk_get_enabled().
    It has updated the error handling path of the probe accordingly, but the
    remove has been left unchanged.
    
    Remove now the redundant clk_disable_unprepare() call from the remove
    function.
    
    Fixes: a90a987ebe00 ("spi: use devm_clk_get_enabled() in mcfqspi_probe()")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://msgid.link/r/6670aed303e1f7680e0911387606a8ae069e2cef.1704464447.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: sh-msiof: Enforce fixed DTDL for R-Car H3 [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Tue Dec 12 09:12:38 2023 +0100

    spi: sh-msiof: Enforce fixed DTDL for R-Car H3
    
    [ Upstream commit e5c7bcb499840551cfbe85c6df177ebc50432bf0 ]
    
    Documentation says only DTDL of 200 is allowed for this SoC.
    
    Fixes: 4286db8456f4 ("spi: sh-msiof: Add R-Car Gen 2 and 3 fallback bindings")
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Yoshihiro Shimoda <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: spi-zynqmp-gqspi: fix driver kconfig dependencies [+ + +]
Author: Amit Kumar Mahapatra <[email protected]>
Date:   Mon Nov 6 20:23:55 2023 +0530

    spi: spi-zynqmp-gqspi: fix driver kconfig dependencies
    
    [ Upstream commit 424a8166764e462258fdccaaefbdeb07517c8b21 ]
    
    ZynqMP GQSPI driver no longer uses spi-master framework. It had been
    converted to use spi-mem framework. So remove driver dependency from
    spi-master and replace it with spi-mem.
    
    Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
    Signed-off-by: Amit Kumar Mahapatra <[email protected]>
    Signed-off-by: Radhey Shyam Pandey <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spmi: mtk-pmif: Serialize PMIF status check and command submission [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Wed Dec 6 15:17:24 2023 -0800

    spmi: mtk-pmif: Serialize PMIF status check and command submission
    
    [ Upstream commit f200fff8d019f2754f91f5d715652e3e3fdf3604 ]
    
    Before writing the read or write command to the SPMI arbiter through the
    PMIF interface, the current status of the channel is checked to ensure
    it is idle. However, since the status only changes from idle when the
    command is written, it is possible for two concurrent calls to determine
    that the channel is idle and simultaneously send their commands. At this
    point the PMIF interface hangs, with the status register no longer being
    updated, and thus causing all subsequent operations to time out.
    
    This was observed on the mt8195-cherry-tomato-r2 machine, particularly
    after commit 46600ab142f8 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for
    drivers between 5.10 and 5.15") was applied, since then the two MT6315
    devices present on the SPMI bus would probe assynchronously and
    sometimes (during probe or at a later point) read the bus
    simultaneously, breaking the PMIF interface and consequently slowing
    down the whole system.
    
    To fix the issue at its root cause, introduce locking around the channel
    status check and the command write, so that both become an atomic
    operation, preventing race conditions between two (or more) SPMI bus
    read/write operations. A spinlock is used since this is a fast bus, as
    indicated by the usage of the atomic variant of readl_poll, and
    '.fast_io = true' being used in the mt6315 driver, so spinlocks are
    already used for the regmap access.
    
    Fixes: b45b3ccef8c0 ("spmi: mediatek: Add support for MT6873/8192")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Alexandre Mergnat <[email protected]>
    Signed-off-by: Stephen Boyd <[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]>

 
srcu: Use try-lock lockdep annotation for NMI-safe access. [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Thu Nov 30 14:27:29 2023 +0100

    srcu: Use try-lock lockdep annotation for NMI-safe access.
    
    [ Upstream commit 3c6b0c1c28184038d90dffe8eb542bedcb8ccf98 ]
    
    It is claimed that srcu_read_lock_nmisafe() NMI-safe. However it
    triggers a lockdep if used from NMI because lockdep expects a deadlock
    since nothing disables NMIs while the lock is acquired.
    
    This is because commit f0f44752f5f61 ("rcu: Annotate SRCU's update-side
    lockdep dependencies") annotates synchronize_srcu() as a write lock
    usage. This helps to detect a deadlocks such as
            srcu_read_lock();
            synchronize_srcu();
            srcu_read_unlock();
    
    The side effect is that the lock srcu_struct now has a USED usage in normal
    contexts, so it conflicts with a USED_READ usage in NMI. But this shouldn't
    cause a real deadlock because the write lock usage from synchronize_srcu()
    is a fake one and only used for read/write deadlock detection.
    
    Use a try-lock annotation for srcu_read_lock_nmisafe() to avoid lockdep
    complains if used from NMI.
    
    Fixes: f0f44752f5f6 ("rcu: Annotate SRCU's update-side lockdep dependencies")
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Boqun Feng <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Neeraj Upadhyay (AMD) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: vc04_services: Do not pass NULL to vchiq_log_error() [+ + +]
Author: Umang Jain <[email protected]>
Date:   Wed Nov 29 01:49:22 2023 +0530

    staging: vc04_services: Do not pass NULL to vchiq_log_error()
    
    [ Upstream commit 149261d378d0ca441b16de6c1a250a350df66598 ]
    
    vchiq_add_connected_callback() logs using vchiq_log_error() macro,
    but passes NULL instead of a struct device pointer. Fix it.
    
    vchiq_add_connected_callback() is not used anywhere in the vc04_services
    as of now. It will be used when we add new drivers(VC shared memory and
    bcm2835-isp), hence it kept as it is for now.
    
    Fixes: 1d8915cf8899 ("staging: vc04: Convert vchiq_log_error() to use dynamic debug")
    Signed-off-by: Umang Jain <[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]>

staging: vc04_services: vchiq_core: Log through struct vchiq_instance [+ + +]
Author: Umang Jain <[email protected]>
Date:   Wed Nov 29 01:48:45 2023 +0530

    staging: vc04_services: vchiq_core: Log through struct vchiq_instance
    
    [ Upstream commit f9c42898830383aff4fdc723828fa93a6abec02d ]
    
    The handle_to_service() helper can return NULL, so `service` pointer
    can indeed be set to NULL. So, do not log through service pointer
    (which can cause NULL-deference), instead, use the vchiq_instance
    function argument to get access to the struct device.
    
    Fixes: f67af5940d6d ("staging: vc04: Convert(and rename) vchiq_log_info() to use dynamic debug")
    Reviewed-by: Ricardo B. Marliere <[email protected]>
    Signed-off-by: Umang Jain <[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]>

 
SUNRPC: fix _xprt_switch_find_current_entry logic [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Fri Dec 1 14:42:03 2023 -0500

    SUNRPC: fix _xprt_switch_find_current_entry logic
    
    [ Upstream commit 98b4e5137504a5bd9346562b1310cdc13486603b ]
    
    Fix the logic for picking current transport entry.
    
    Fixes: 95d0d30c66b8 ("SUNRPC create an iterator to list only OFFLINE xprts")
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

SUNRPC: Fixup v4.1 backchannel request timeouts [+ + +]
Author: Benjamin Coddington <[email protected]>
Date:   Thu Jan 4 09:58:45 2024 -0500

    SUNRPC: Fixup v4.1 backchannel request timeouts
    
    [ Upstream commit e6f533b615971afcaa1141573a1a1714d9d4f31a ]
    
    After commit 59464b262ff5 ("SUNRPC: SOFTCONN tasks should time out when on
    the sending list"), any 4.1 backchannel tasks placed on the sending queue
    would immediately return with -ETIMEDOUT since their req timers are zero.
    
    Initialize the backchannel's rpc_rqst timeout parameters from the xprt's
    default timeout settings.
    
    Fixes: 59464b262ff5 ("SUNRPC: SOFTCONN tasks should time out when on the sending list")
    Signed-off-by: Benjamin Coddington <[email protected]>
    Tested-by: Chuck Lever <[email protected]>
    Tested-by: Jeff Layton <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
test_bpf: Rename second ALU64_SMOD_X to ALU64_SMOD_K [+ + +]
Author: Tiezhu Yang <[email protected]>
Date:   Thu Dec 7 12:08:51 2023 +0800

    test_bpf: Rename second ALU64_SMOD_X to ALU64_SMOD_K
    
    [ Upstream commit 5181dc08f79583c6dead80208137a97e68ff07b0 ]
    
    Currently, there are two test cases with same name
    "ALU64_SMOD_X: -7 % 2 = -1", the first one is right,
    the second one should be ALU64_SMOD_K because its
    code is BPF_ALU64 | BPF_MOD | BPF_K.
    
    Before:
    test_bpf: #170 ALU64_SMOD_X: -7 % 2 = -1 jited:1 4 PASS
    test_bpf: #171 ALU64_SMOD_X: -7 % 2 = -1 jited:1 4 PASS
    
    After:
    test_bpf: #170 ALU64_SMOD_X: -7 % 2 = -1 jited:1 4 PASS
    test_bpf: #171 ALU64_SMOD_K: -7 % 2 = -1 jited:1 4 PASS
    
    Fixes: daabb2b098e0 ("bpf/tests: add tests for cpuv4 instructions")
    Signed-off-by: Tiezhu Yang <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal: core: Fix NULL pointer dereference in zone registration error path [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Dec 14 11:52:25 2023 +0100

    thermal: core: Fix NULL pointer dereference in zone registration error path
    
    [ Upstream commit 04e6ccfc93c5a1aa1d75a537cf27e418895e20ea ]
    
    If device_register() in thermal_zone_device_register_with_trips()
    returns an error, the tz variable is set to NULL and subsequently
    dereferenced in kfree(tz->tzp).
    
    Commit adc8749b150c ("thermal/drivers/core: Use put_device() if
    device_register() fails") added the tz = NULL assignment in question to
    avoid a possible double-free after dropping the reference to the zone
    device.  However, after commit 4649620d9404 ("thermal: core: Make
    thermal_zone_device_unregister() return after freeing the zone"), that
    assignment has become redundant, because dropping the reference to the
    zone device does not cause the zone object to be freed any more.
    
    Drop it to address the NULL pointer dereference.
    
    Fixes: 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure")
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Lukasz Luba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Mon Jan 15 17:35:55 2024 +0100

    tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug
    
    commit 71fee48fb772ac4f6cfa63dbebc5629de8b4cc09 upstream.
    
    When offlining and onlining CPUs the overall reported idle and iowait
    times as reported by /proc/stat jump backward and forward:
    
    cpu  132 0 176 225249 47 6 6 21 0 0
    cpu0 80 0 115 112575 33 3 4 18 0 0
    cpu1 52 0 60 112673 13 3 1 2 0 0
    
    cpu  133 0 177 226681 47 6 6 21 0 0
    cpu0 80 0 116 113387 33 3 4 18 0 0
    
    cpu  133 0 178 114431 33 6 6 21 0 0 <---- jump backward
    cpu0 80 0 116 114247 33 3 4 18 0 0
    cpu1 52 0 61 183 0 3 1 2 0 0        <---- idle + iowait start with 0
    
    cpu  133 0 178 228956 47 6 6 21 0 0 <---- jump forward
    cpu0 81 0 117 114929 33 3 4 18 0 0
    
    Reason for this is that get_idle_time() in fs/proc/stat.c has different
    sources for both values depending on if a CPU is online or offline:
    
    - if a CPU is online the values may be taken from its per cpu
      tick_cpu_sched structure
    
    - if a CPU is offline the values are taken from its per cpu cpustat
      structure
    
    The problem is that the per cpu tick_cpu_sched structure is set to zero on
    CPU offline. See tick_cancel_sched_timer() in kernel/time/tick-sched.c.
    
    Therefore when a CPU is brought offline and online afterwards both its idle
    and iowait sleeptime will be zero, causing a jump backward in total system
    idle and iowait sleeptime. In a similar way if a CPU is then brought
    offline again the total idle and iowait sleeptimes will jump forward.
    
    It looks like this behavior was introduced with commit 4b0c0f294f60
    ("tick: Cleanup NOHZ per cpu data on cpu down").
    
    This was only noticed now on s390, since we switched to generic idle time
    reporting with commit be76ea614460 ("s390/idle: remove arch_cpu_idle_time()
    and corresponding code").
    
    Fix this by preserving the values of idle_sleeptime and iowait_sleeptime
    members of the per-cpu tick_sched structure on CPU hotplug.
    
    Fixes: 4b0c0f294f60 ("tick: Cleanup NOHZ per cpu data on cpu down")
    Reported-by: Gerald Schaefer <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Frederic Weisbecker <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
udp: annotate data-races around up->pending [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jan 12 10:44:27 2024 +0000

    udp: annotate data-races around up->pending
    
    [ Upstream commit 482521d8e0c6520429478aa6866cd44128b33d5d ]
    
    up->pending can be read without holding the socket lock,
    as pointed out by syzbot [1]
    
    Add READ_ONCE() in lockless contexts, and WRITE_ONCE()
    on write side.
    
    [1]
    BUG: KCSAN: data-race in udpv6_sendmsg / udpv6_sendmsg
    
    write to 0xffff88814e5eadf0 of 4 bytes by task 15547 on cpu 1:
     udpv6_sendmsg+0x1405/0x1530 net/ipv6/udp.c:1596
     inet6_sendmsg+0x63/0x80 net/ipv6/af_inet6.c:657
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     __sys_sendto+0x257/0x310 net/socket.c:2192
     __do_sys_sendto net/socket.c:2204 [inline]
     __se_sys_sendto net/socket.c:2200 [inline]
     __x64_sys_sendto+0x78/0x90 net/socket.c:2200
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    read to 0xffff88814e5eadf0 of 4 bytes by task 15551 on cpu 0:
     udpv6_sendmsg+0x22c/0x1530 net/ipv6/udp.c:1373
     inet6_sendmsg+0x63/0x80 net/ipv6/af_inet6.c:657
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     ____sys_sendmsg+0x37c/0x4d0 net/socket.c:2586
     ___sys_sendmsg net/socket.c:2640 [inline]
     __sys_sendmmsg+0x269/0x500 net/socket.c:2726
     __do_sys_sendmmsg net/socket.c:2755 [inline]
     __se_sys_sendmmsg net/socket.c:2752 [inline]
     __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2752
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    value changed: 0x00000000 -> 0x0000000a
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 15551 Comm: syz-executor.1 Tainted: G        W          6.7.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: [email protected]
    Link: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
um: virt-pci: fix platform map offset [+ + +]
Author: Vincent Whitchurch <[email protected]>
Date:   Fri Sep 1 15:35:43 2023 +0200

    um: virt-pci: fix platform map offset
    
    [ Upstream commit 32253f00ac8a8073bf6db4bfe9d6511cc93c4aef ]
    
    The offset is currently always zero so the backend can't distinguish
    between accesses to different ioremapped areas.
    
    Fixes: 522c532c4fe7 ("virt-pci: add platform bus support")
    Signed-off-by: Vincent Whitchurch <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: cdc-acm: return correct error code on unsupported break [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Dec 7 14:26:30 2023 +0100

    usb: cdc-acm: return correct error code on unsupported break
    
    [ Upstream commit 66aad7d8d3ec5a3a8ec2023841bcec2ded5f65c9 ]
    
    In ACM support for sending breaks to devices is optional.
    If a device says that it doenot support sending breaks,
    the host must respect that.
    Given the number of optional features providing tty operations
    for each combination is not practical and errors need to be
    returned dynamically if unsupported features are requested.
    
    In case a device does not support break, we want the tty layer
    to treat that like it treats drivers that statically cannot
    support sending a break. It ignores the inability and does nothing.
    This patch uses EOPNOTSUPP to indicate that.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Fixes: 9e98966c7bb94 ("tty: rework break handling")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: cdns3: fix iso transfer error when mult is not zero [+ + +]
Author: Frank Li <[email protected]>
Date:   Sun Dec 24 10:38:14 2023 -0500

    usb: cdns3: fix iso transfer error when mult is not zero
    
    commit 92f02efa1d86d7dcaef7f38a5fe3396c4e88a93c upstream.
    
    ISO basic transfer is
            ITP(SOF) Package_0 Package_1 ... Package_n
    
    CDNS3 DMA start dma transfer from memmory to internal FIFO when get SOF,
    controller will transfer data to usb bus from internal FIFO when get IN
    token.
    
    According USB spec defination:
            Maximum number of packets = (bMaxBurst + 1) * (Mult + 1)
    
    Internal memory should be the same as (bMaxBurst + 1) * (Mult + 1). DMA
    don't fetch data advance when ISO transfer, so only reserve
    (bMaxBurst + 1) * (Mult + 1) internal memory for ISO transfer.
    
    Need save Mult and bMaxBurst information and set it into EP_CFG register,
    otherwise only 1 package is sent by controller, other package will be
    lost.
    
    Cc:  <[email protected]>
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: cdns3: Fix uvc fail when DMA cross 4k boundery since sg enabled [+ + +]
Author: Frank Li <[email protected]>
Date:   Sun Dec 24 10:38:15 2023 -0500

    usb: cdns3: Fix uvc fail when DMA cross 4k boundery since sg enabled
    
    commit 40c304109e866a7dc123661a5c8ca72f6b5e14e0 upstream.
    
    Supposed DMA cross 4k bounder problem should be fixed at DEV_VER_V2, but
    still met problem when do ISO transfer if sg enabled.
    
    Data pattern likes below when sg enabled, package size is 1k and mult is 2
            [UVC Header(8B) ] [data(3k - 8)] ...
    
    The received data at offset 0xd000 will get 0xc000 data, len 0x70. Error
    happen position as below pattern:
            0xd000: wrong
            0xe000: wrong
            0xf000: correct
            0x10000: wrong
            0x11000: wrong
            0x12000: correct
            ...
    
    To avoid DMA cross 4k bounder at ISO transfer, reduce burst len according
    to start DMA address's alignment.
    
    Cc:  <[email protected]>
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: cdns3: fix uvc failure work since sg support enabled [+ + +]
Author: Frank Li <[email protected]>
Date:   Sun Dec 24 10:38:13 2023 -0500

    usb: cdns3: fix uvc failure work since sg support enabled
    
    commit 1b8be5ecff26201bafb0a554c74e91571299fb94 upstream.
    
    When IP version >= DEV_VER_V2, gadget:sg_supported is true. So uvc gadget
    function driver will use sg to equeue data, first is 8bytes header, the
    second is 1016bytes data.
    
        cdns3_prepare_trb: ep2in: trb 0000000000ac755f, dma buf: 0xbf455000, size: 8, burst: 128 ctrl: 0x00000415 (C=1, T=0, ISP, CHAIN, Normal)
        cdns3_prepare_trb: ep2in: trb 00000000a574e693, dma buf: 0xc0200fe0, size: 1016, burst: 128 ctrl: 0x00000405 (C=1, T=0, ISP, Normal)
    
    But cdns3_ep_run_transfer() can't correctly handle this case, which only
    support one TRB for ISO transfer.
    
    The controller requires duplicate the TD for each SOF if priv_ep->interval
    is not 1. DMA will read data from DDR to internal FIFO when get SOF. Send
    data to bus when receive IN token. DMA always refill FIFO when get SOF
    regardless host send IN token or not. If host send IN token later, some
    frames data will be lost.
    
    Fixed it by below major steps:
    
    1. Calculate numembers of TRB base on sg_nums and priv_ep->interval.
    2. Remove CHAIN flags for each end TRB of TD when duplicate TD.
    3. The controller requires LINK TRB must be first TRB of TD. When check
    there are not enough TRBs lefts, just fill LINK TRB for left TRBs.
    
    .... CHAIN_TRB DATA_TRB, CHAIN_TRB DATA_TRB,  LINK_TRB ... LINK_TRB
                                                               ^End of TRB List
    
    Cc:  <[email protected]>
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: chipidea: wait controller resume finished for wakeup irq [+ + +]
Author: Xu Yang <[email protected]>
Date:   Thu Dec 28 19:07:52 2023 +0800

    usb: chipidea: wait controller resume finished for wakeup irq
    
    commit 128d849074d05545becf86e713715ce7676fc074 upstream.
    
    After the chipidea driver introduce extcon for id and vbus, it's able
    to wakeup from another irq source, in case the system with extcon ID
    cable, wakeup from usb ID cable and device removal, the usb device
    disconnect irq may come firstly before the extcon notifier while system
    resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
    and one for extcon ID cable change(real wakeup event), current driver
    treat them as 2 successive wakeup irq so can't handle it correctly, then
    finally the usb irq can't be enabled. This patch adds a check to bypass
    further usb events before controller resume finished to fix it.
    
    Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
    cc:  <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Signed-off-by: Li Jun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc3: gadget: Handle EP0 request dequeuing properly [+ + +]
Author: Wesley Cheng <[email protected]>
Date:   Wed Dec 6 12:18:14 2023 -0800

    usb: dwc3: gadget: Handle EP0 request dequeuing properly
    
    commit 730e12fbec53ab59dd807d981a204258a4cfb29a upstream.
    
    Current EP0 dequeue path will share the same as other EPs.  However, there
    are some special considerations that need to be made for EP0 transfers:
    
      - EP0 transfers never transition into the started_list
      - EP0 only has one active request at a time
    
    In case there is a vendor specific control message for a function over USB
    FFS, then there is no guarantee on the timeline which the DATA/STATUS stage
    is responded to.  While this occurs, any attempt to end transfers on
    non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and
    defer issuing of the end transfer command.  If the USB FFS application
    decides to timeout the control transfer, or if USB FFS AIO path exits, the
    USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request.
    
    In case of the AIO exit path, the AIO FS blocks until all pending USB
    requests utilizing the AIO path is completed.  However, since the dequeue
    of ep0 req does not happen properly, all non-control EPs with the
    DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will
    be stuck waiting for the USB FFS data endpoints to receive a completion
    callback.
    
    Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0
    is brought back to the SETUP state, and ensures that any deferred end
    transfer commands are handled.  This also will end any active transfers
    on EP0, compared to the previous implementation which directly called
    giveback only.
    
    Fixes: fcd2def66392 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue")
    Cc: stable <[email protected]>
    Signed-off-by: Wesley Cheng <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc3: gadget: Queue PM runtime idle on disconnect event [+ + +]
Author: Wesley Cheng <[email protected]>
Date:   Wed Jan 3 13:49:46 2024 -0800

    usb: dwc3: gadget: Queue PM runtime idle on disconnect event
    
    commit 3c7af52c7616c3aa6dacd2336ec748d4a65df8f4 upstream.
    
    There is a scenario where DWC3 runtime suspend is blocked due to the
    dwc->connected flag still being true while PM usage_count is zero after
    DWC3 giveback is completed and the USB gadget session is being terminated.
    This leads to a case where nothing schedules a PM runtime idle for the
    device.
    
    The exact condition is seen with the following sequence:
      1.  USB bus reset is issued by the host
      2.  Shortly after, or concurrently, a USB PD DR SWAP request is received
          (sink->source)
      3.  USB bus reset event handler runs and issues
          dwc3_stop_active_transfers(), and pending transfer are stopped
      4.  DWC3 usage_count decremented to 0, and runtime idle occurs while
          dwc->connected == true, returns -EBUSY
      5.  DWC3 disconnect event seen, dwc->connected set to false due to DR
          swap handling
      6.  No runtime idle after this point
    
    Address this by issuing an asynchronous PM runtime idle call after the
    disconnect event is completed, as it modifies the dwc->connected flag,
    which is what blocks the initial runtime idle.
    
    Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM")
    Cc:  <[email protected]>
    Signed-off-by: Wesley Cheng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart [+ + +]
Author: Uttkarsh Aggarwal <[email protected]>
Date:   Fri Dec 22 15:17:04 2023 +0530

    usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart
    
    commit e9d40b215e38480fd94c66b06d79045717a59e9c upstream.
    
    Current implementation blocks the running operations when Plug-out and
    Plug-In is performed continuously, process gets stuck in
    dwc3_thread_interrupt().
    
    Code Flow:
    
            CPU1
    
            ->Gadget_start
            ->dwc3_interrupt
            ->dwc3_thread_interrupt
            ->dwc3_process_event_buf
            ->dwc3_process_event_entry
            ->dwc3_endpoint_interrupt
            ->dwc3_ep0_interrupt
            ->dwc3_ep0_inspect_setup
            ->dwc3_ep0_stall_and_restart
    
    By this time if pending_list is not empty, it will get the next request
    on the given list and calls dwc3_gadget_giveback which will unmap request
    and call its complete() callback to notify upper layers that it has
    completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET,
    whereas it should be -ESHUTDOWN based on condition if not dwc->connected
    is true.
    
    Cc:  <[email protected]>
    Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart")
    Signed-off-by: Uttkarsh Aggarwal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: u_ether: Re-attach netif device to mirror detachment [+ + +]
Author: Richard Acayan <[email protected]>
Date:   Mon Dec 18 11:45:33 2023 -0500

    usb: gadget: u_ether: Re-attach netif device to mirror detachment
    
    commit 76c945730cdffb572c7767073cc6515fd3f646b4 upstream.
    
    In 6.7-rc1, there was a netif_device_detach call added to the
    gether_disconnect function. This clears the __LINK_STATE_PRESENT bit of
    the netif device and suppresses pings (ICMP messages) and TCP connection
    requests from the connected host. If userspace temporarily disconnects
    the gadget, such as by temporarily removing configuration in the gadget
    configfs interface, network activity should continue to be processed
    when the gadget is re-connected. Mirror the netif_device_detach call
    with a netif_device_attach call in gether_connect to fix re-connecting
    gadgets.
    
    Link: https://gitlab.com/postmarketOS/pmaports/-/tree/6002e51b7090aeeb42947e0ca7ec22278d7227d0/main/postmarketos-base-ui/rootfs-usr-lib-NetworkManager-dispatcher.d-50-tethering.sh
    Cc: stable <[email protected]>
    Fixes: f49449fbc21e ("usb: gadget: u_ether: Replace netif_stop_queue with netif_device_detach")
    Signed-off-by: Richard Acayan <[email protected]>
    Tested-by: Luca Weiss <[email protected]>
    Tested-by: Duje Mihanović <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: webcam: Make g_webcam loadable again [+ + +]
Author: Andrzej Pietrasiewicz <[email protected]>
Date:   Fri Dec 15 14:16:14 2023 +0100

    usb: gadget: webcam: Make g_webcam loadable again
    
    [ Upstream commit f1fd91a0924b6bff91ca1287461fb8e3b3b61d92 ]
    
    commit 588b9e85609b ("usb: gadget: uvc: add v4l2 enumeration api calls")
    has rendered the precomposed (aka legacy) webcam gadget unloadable.
    
    uvc_alloc() since then has depended on certain config groups being
    available in configfs tree related to the UVC function. However, legacy
    gadgets do not create anything in configfs, so uvc_alloc() must fail
    with -ENOENT no matter what.
    
    This patch mimics the required configfs hierarchy to satisfy the code which
    inspects formats and frames found in uvcg_streaming_header.
    
    This has been tested with guvcview on the host side, using vivid as a
    source of video stream on the device side and using the userspace program
    found at https://gitlab.freedesktop.org/camera/uvc-gadget.git.
    
    Signed-off-by: Andrzej Pietrasiewicz <[email protected]>
    Fixes: 588b9e85609b ("usb: gadget: uvc: add v4l2 enumeration api calls")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: mon: Fix atomicity violation in mon_bin_vma_fault [+ + +]
Author: Gui-Dong Han <[email protected]>
Date:   Fri Jan 5 13:24:12 2024 +0800

    usb: mon: Fix atomicity violation in mon_bin_vma_fault
    
    commit 2dd23cc4d0e6aa55cf9fb3b05f2f4165b01de81c upstream.
    
    In mon_bin_vma_fault():
        offset = vmf->pgoff << PAGE_SHIFT;
        if (offset >= rp->b_size)
            return VM_FAULT_SIGBUS;
        chunk_idx = offset / CHUNK_SIZE;
        pageptr = rp->b_vec[chunk_idx].pg;
    The code is executed without holding any lock.
    
    In mon_bin_vma_close():
        spin_lock_irqsave(&rp->b_lock, flags);
        rp->mmap_active--;
        spin_unlock_irqrestore(&rp->b_lock, flags);
    
    In mon_bin_ioctl():
        spin_lock_irqsave(&rp->b_lock, flags);
        if (rp->mmap_active) {
            ...
        } else {
            ...
            kfree(rp->b_vec);
            rp->b_vec  = vec;
            rp->b_size = size;
            ...
        }
        spin_unlock_irqrestore(&rp->b_lock, flags);
    
    Concurrent execution of mon_bin_vma_fault() with mon_bin_vma_close() and
    mon_bin_ioctl() could lead to atomicity violations. mon_bin_vma_fault()
    accesses rp->b_size and rp->b_vec without locking, risking array
    out-of-bounds access or use-after-free bugs due to possible modifications
    in mon_bin_ioctl().
    
    This possible bug is found by an experimental static analysis tool
    developed by our team, BassCheck[1]. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations. The above
    possible bug is reported when our tool analyzes the source code of
    Linux 6.2.
    
    To address this issue, it is proposed to add a spin lock pair in
    mon_bin_vma_fault() to ensure atomicity. With this patch applied, our tool
    never reports the possible bug, with the kernel configuration allyesconfig
    for x86_64. Due to the lack of associated hardware, we cannot test the
    patch in runtime testing, and just verify it according to the code logic.
    
    [1] https://sites.google.com/view/basscheck/
    
    Fixes: 19e6317d24c2 ("usb: mon: Fix a deadlock in usbmon between ...")
    Cc:  <[email protected]>
    Signed-off-by: Gui-Dong Han <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host() [+ + +]
Author: Xu Yang <[email protected]>
Date:   Thu Dec 28 19:07:53 2023 +0800

    usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
    
    commit ff2b89de471da942a4d853443688113a44fd35ed upstream.
    
    When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
    false. This behaviour is wrong. Since phy.last_event will always be set
    for either host or device mode. Therefore, CONFIG_USB_OTG condition
    can be removed.
    
    Fixes: 5eda42aebb76 ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()")
    cc:  <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: class: fix typec_altmode_put_partner to put plugs [+ + +]
Author: RD Babiera <[email protected]>
Date:   Wed Jan 3 18:17:55 2024 +0000

    usb: typec: class: fix typec_altmode_put_partner to put plugs
    
    commit 5962ded777d689cd8bf04454273e32228d7fb71f upstream.
    
    When typec_altmode_put_partner is called by a plug altmode upon release,
    the port altmode the plug belongs to will not remove its reference to the
    plug. The check to see if the altmode being released is a plug evaluates
    against the released altmode's partner instead of the calling altmode, so
    change adev in typec_altmode_put_partner to properly refer to the altmode
    being released.
    
    Because typec_altmode_set_partner calls get_device() on the port altmode,
    add partner_adev that points to the port altmode in typec_put_partner to
    call put_device() on. typec_altmode_set_partner is not called for port
    altmodes, so add a check in typec_altmode_release to prevent
    typec_altmode_put_partner() calls on port altmode release.
    
    Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
    Cc:  <[email protected]>
    Co-developed-by: Christian A. Ehrhardt <[email protected]>
    Signed-off-by: Christian A. Ehrhardt <[email protected]>
    Signed-off-by: RD Babiera <[email protected]>
    Tested-by: Christian A. Ehrhardt <[email protected]>
    Acked-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer [+ + +]
Author: Chunfeng Yun <[email protected]>
Date:   Thu Jan 4 14:16:39 2024 +0800

    usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
    
    [ Upstream commit 017dbfc05c31284150819890b4cc86a699cbdb71 ]
    
    For Gen1 isoc-in transfer, host still send out unexpected ACK after device
    finish the burst with a short packet, this will cause an exception on the
    connected device, such as, a usb 4k camera.
    It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use
    3k here, the side-effect is that may cause performance drop about 10%,
    including bulk transfer.
    
    Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Chunfeng Yun <[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]>

 
vdpa: Fix an error handling path in eni_vdpa_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Oct 20 21:21:09 2022 +0200

    vdpa: Fix an error handling path in eni_vdpa_probe()
    
    [ Upstream commit c1b9f2c66eed3261db76cccd8a22a9affae8dcbf ]
    
    After a successful vp_legacy_probe() call, vp_legacy_remove() should be
    called in the error handling path, as already done in the remove function.
    
    Add the missing call.
    
    Fixes: e85087beedca ("eni_vdpa: add vDPA driver for Alibaba ENI")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Message-Id: <a7b0ef1eabd081f1c7c894e9b11de01678e85dee.1666293559.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vfio/pds: Fix calculations in pds_vfio_dirty_sync [+ + +]
Author: Brett Creeley <[email protected]>
Date:   Thu Nov 16 16:12:02 2023 -0800

    vfio/pds: Fix calculations in pds_vfio_dirty_sync
    
    [ Upstream commit 4004497cec3093d7b0087bc70709b45969fa07b6 ]
    
    The incorrect check is being done for comparing the
    iova/length being requested to sync. This can cause
    the dirty sync operation to fail. Fix this by making
    sure the iova offset added to the requested sync
    length doesn't exceed the region_size.
    
    Also, the region_start is assumed to always be at 0.
    This can cause dirty tracking to fail because the
    device/driver bitmap offset always starts at 0,
    however, the region_start/iova may not. Fix this by
    determining the iova offset from region_start to
    determine the bitmap offset.
    
    Fixes: f232836a9152 ("vfio/pds: Add support for dirty page tracking")
    Signed-off-by: Brett Creeley <[email protected]>
    Signed-off-by: Shannon Nelson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
virtio/vsock: fix logic which reduces credit update messages [+ + +]
Author: Arseniy Krasnov <[email protected]>
Date:   Thu Dec 14 15:52:28 2023 +0300

    virtio/vsock: fix logic which reduces credit update messages
    
    [ Upstream commit 93b80887668226180ea5f5349cc728ca6dc700ab ]
    
    Add one more condition for sending credit update during dequeue from
    stream socket: when number of bytes in the rx queue is smaller than
    SO_RCVLOWAT value of the socket. This is actual for non-default value
    of SO_RCVLOWAT (e.g. not 1) - idea is to "kick" peer to continue data
    transmission, because we need at least SO_RCVLOWAT bytes in our rx
    queue to wake up user for reading data (in corner case it is also
    possible to stuck both tx and rx sides, this is why 'Fixes' is used).
    
    Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages")
    Signed-off-by: Arseniy Krasnov <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

virtio/vsock: send credit update during setting SO_RCVLOWAT [+ + +]
Author: Arseniy Krasnov <[email protected]>
Date:   Thu Dec 14 15:52:29 2023 +0300

    virtio/vsock: send credit update during setting SO_RCVLOWAT
    
    [ Upstream commit 0fe1798968115488c0c02f4633032a015b1faf97 ]
    
    Send credit update message when SO_RCVLOWAT is updated and it is bigger
    than number of bytes in rx queue. It is needed, because 'poll()' will
    wait until number of bytes in rx queue will be not smaller than
    O_RCVLOWAT, so kick sender to send more data. Otherwise mutual hungup
    for tx/rx is possible: sender waits for free space and receiver is
    waiting data in 'poll()'.
    
    Rename 'set_rcvlowat' callback to 'notify_set_rcvlowat' and set
    'sk->sk_rcvlowat' only in one place (i.e. 'vsock_set_rcvlowat'), so the
    transport doesn't need to do it.
    
    Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages")
    Signed-off-by: Arseniy Krasnov <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO [+ + +]
Author: Jerry Hoemann <[email protected]>
Date:   Wed Dec 13 14:53:38 2023 -0700

    watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO
    
    [ Upstream commit dced0b3e51dd2af3730efe14dd86b5e3173f0a65 ]
    
    Avoid unnecessary crashes by claiming only NMIs that are due to
    ERROR signalling or generated by the hpwdt hardware device.
    
    The code does this, but only for iLO5.
    
    The intent was to preserve legacy, Gen9 and earlier, semantics of
    using hpwdt for error containtment as hardware/firmware would signal
    fatal IO errors as an NMI with the expectation of hpwdt crashing
    the system.  Howerver, these IO errors should be received by hpwdt
    as an NMI_IO_CHECK.  So the test is overly permissive and should
    not be limited to only ilo5.
    
    We need to enable this protection for future iLOs not matching the
    current PCI IDs.
    
    Fixes: 62290a5c194b ("watchdog: hpwdt: Claim NMIs generated by iLO5")
    Signed-off-by: Jerry Hoemann <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Sun Nov 12 18:32:51 2023 +0100

    watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling
    
    [ Upstream commit f33f5b1fd1be5f5106d16f831309648cb0f1c31d ]
    
    Users report about the unexpected behavior for setting timeouts above
    15 sec on Raspberry Pi. According to watchdog-api.rst the ioctl
    WDIOC_SETTIMEOUT shouldn't fail because of hardware limitations.
    But looking at the code shows that max_timeout based on the
    register value PM_WDOG_TIME_SET, which is the maximum.
    
    Since 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat
    in watchdog core") the watchdog core is able to handle this problem.
    
    This fix has been tested with watchdog-test from selftests.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217374
    Fixes: 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat in watchdog core")
    Signed-off-by: Stefan Wahren <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused [+ + +]
Author: Vignesh Raghavendra <[email protected]>
Date:   Wed Dec 13 19:31:10 2023 +0530

    watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused
    
    [ Upstream commit c1a6edf3b541e44e78f10bc6024df779715723f1 ]
    
    Call runtime_pm_put*() if watchdog is not already started during probe and re
    enable it in watchdog start as required.
    
    On K3 SoCs, watchdogs and their corresponding CPUs are under same
    power-domain, so if the reference count of unused watchdogs aren't
    dropped, it will lead to CPU hotplug failures as Device Management
    firmware won't allow to turn off the power-domain due to dangling
    reference count.
    
    Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
    Signed-off-by: Vignesh Raghavendra <[email protected]>
    Tested-by: Manorit Chawdhry <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

watchdog: set cdev owner before adding [+ + +]
Author: Curtis Klein <[email protected]>
Date:   Tue Dec 5 11:05:22 2023 -0800

    watchdog: set cdev owner before adding
    
    [ Upstream commit 38d75297745f04206db9c29bdd75557f0344c7cc ]
    
    When the new watchdog character device is registered, it becomes
    available for opening. This creates a race where userspace may open the
    device before the character device's owner is set. This results in an
    imbalance in module_get calls as the cdev_get in cdev_open will not
    increment the reference count on the watchdog driver module.
    
    This causes problems when the watchdog character device is released as
    the module loader's reference will also be released. This makes it
    impossible to open the watchdog device later on as it now appears that
    the module is being unloaded. The open will fail with -ENXIO from
    chrdev_open.
    
    The legacy watchdog device will fail with -EBUSY from the try_module_get
    in watchdog_open because it's module owner is the watchdog core module
    so it can still be opened but it will fail to get a refcount on the
    underlying watchdog device driver.
    
    Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev")
    Signed-off-by: Curtis Klein <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ath11k: Defer on rproc_get failure [+ + +]
Author: Luca Weiss <[email protected]>
Date:   Fri Oct 27 08:57:18 2023 +0200

    wifi: ath11k: Defer on rproc_get failure
    
    [ Upstream commit 2a3ec40b98b46c339adb57313d3b933ee5e7a8e8 ]
    
    If we already have gotten the rproc_handle (meaning the "qcom,rproc"
    property is defined in the devicetree), it's a valid state that the
    remoteproc module hasn't probed yet so we should defer probing instead
    of just failing to probe.
    
    This resolves a race condition when the ath11k driver probes and fails
    before the wpss remoteproc driver has probed, like the following:
    
      [    6.232360] ath11k 17a10040.wifi: failed to get rproc
      [    6.232366] ath11k 17a10040.wifi: failed to get rproc: -22
      [    6.232478] ath11k: probe of 17a10040.wifi failed with error -22
           ...
      [    6.252415] remoteproc remoteproc2: 8a00000.remoteproc is available
      [    6.252776] remoteproc remoteproc2: powering up 8a00000.remoteproc
      [    6.252781] remoteproc remoteproc2: Booting fw image qcom/qcm6490/fairphone5/wpss.mdt, size 7188
    
    So, defer the probe if we hit that so we can retry later once the wpss
    remoteproc is available.
    
    Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01264-QCAMSLSWPLZ-1.37886.3
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Luca Weiss <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix the error handler of rfkill config [+ + +]
Author: Karthikeyan Periyasamy <[email protected]>
Date:   Wed Nov 22 20:31:02 2023 +0200

    wifi: ath12k: fix the error handler of rfkill config
    
    [ Upstream commit 898d8b3e1414cd900492ee6a0b582f8095ba4a1a ]
    
    When the core rfkill config throws error, it should free the
    allocated resources. Currently it is not freeing the core pdev
    create resources. Avoid this issue by calling the core pdev
    destroy in the error handler of core rfkill config.
    
    Found this issue in the code review and it is compile tested only.
    
    Fixes: 004ccbc0dd49 ("wifi: ath12k: add support for hardware rfkill for WCN7850")
    Signed-off-by: Karthikeyan Periyasamy <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: correct comment about MLD ID [+ + +]
Author: Benjamin Berg <[email protected]>
Date:   Tue Jan 2 21:35:30 2024 +0200

    wifi: cfg80211: correct comment about MLD ID
    
    [ Upstream commit 2a0698f86d4dfc43cc0c1703efb7ba6b1506a4e2 ]
    
    The comment was referencing the wrong section of the documentation and
    was also subtly wrong as it assumed the rules that apply when sending
    probe requests directly to a nontransmitted AP. However, in that case
    the response comes from the transmitting AP and the AP MLD ID will be
    included.
    
    Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
    Signed-off-by: Benjamin Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240102213313.0917ab4b5d7f.I76aff0e261a5de44ffb467e591a46597a30d7c0a@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: parse all ML elements in an ML probe response [+ + +]
Author: Benjamin Berg <[email protected]>
Date:   Tue Jan 2 21:35:31 2024 +0200

    wifi: cfg80211: parse all ML elements in an ML probe response
    
    [ Upstream commit d18125b640309e925441ce49559be33867ae6b29 ]
    
    A probe response from a transmitting AP in an Multi-BSSID setup will
    contain more than one Multi-Link element. Most likely, only one of these
    elements contains per-STA profiles.
    
    Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
    Signed-off-by: Benjamin Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240102213313.6635eb152735.I94289002d4a2f7b6b44dfa428344854e37b0b29c@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: assign phy_ctxt before eSR activation [+ + +]
Author: Miri Korenblit <[email protected]>
Date:   Tue Dec 19 21:58:56 2023 +0200

    wifi: iwlwifi: assign phy_ctxt before eSR activation
    
    [ Upstream commit 9b6614e5ead5d19a71893bcca3f1a6569ca0c456 ]
    
    eSR is activated when a chanctx is assigned to more than one link.
    During eSR activation we should disable RLC for both phys, and configure
    the FW with a special phy command for both phys.
    Currently we assign the phy_ctxt to the link only after eSR activation,
    so RLC is not disabled for the new phy_ctxt, and a cmd is not sent to FW.
    Fix this by first assigning the new phy_ctxt to the link and then
    doing the eSR activation.
    
    Fixes: 12bacfc2c065 ("wifi: iwlwifi: handle eSR transitions")
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231219215605.3d94507f5d9a.I537fcd73aedf94c7348c03157e486f24301fef14@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: don't support triggered EHT CQI feedback [+ + +]
Author: Miri Korenblit <[email protected]>
Date:   Thu Dec 7 04:50:08 2023 +0200

    wifi: iwlwifi: don't support triggered EHT CQI feedback
    
    [ Upstream commit 637bbd5b3cbd0fc6945ebd2e311315b6cca1f9c5 ]
    
    EHT CQI is one of the EHT PHY capabilities. We don't support EHT CQI.
    The non-triggered CQI feedback bit was unset in a previous patch,
    but the triggered CQI feedback bit wasn't. Unset it.
    
    Fixes: 0e21ec6edbb5 ("wifi: iwlwifi: nvm: Update EHT capabilities for GL device")
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231207044813.092528daf59e.I5715769490835819beddb00c91bbc9e806e170cb@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: fix out of bound copy_from_user [+ + +]
Author: Anjaneyulu <[email protected]>
Date:   Tue Dec 19 21:58:55 2023 +0200

    wifi: iwlwifi: fix out of bound copy_from_user
    
    [ Upstream commit cb2dfacb197bed0241fbb4f84bd0995a47f4465e ]
    
    The driver copies the userspace buffer into an internal NUL
    byte terminated buffer. While doing so, it was reading beyond
    the end of the userspace buffer, overwriting its own NUL
    termination in the process.
    
    Fix this by only copying the correct number of bytes.
    
    Fixes: 3f244876ef73 ("wifi: iwlwifi: make debugfs entries link specific")
    Signed-off-by: Anjaneyulu <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Reviewed-by: Benjamin Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231219215605.e4913deb2ad4.Idcf6a7e909ff4b7801cd49c2f691f84a2f68eff9@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: Do not warn if valid link pair was not found [+ + +]
Author: Ilan Peer <[email protected]>
Date:   Tue Dec 19 21:58:54 2023 +0200

    wifi: iwlwifi: mvm: Do not warn if valid link pair was not found
    
    [ Upstream commit c5bfdb46636a2ea7f0678243c6d3e9f8d26b027a ]
    
    It is possible that though multiple links are enabled we cannot enabled
    EMLSR enable more than a single link, e.g., all valid links are on the
    same band etc. Thus, do not warn in case no valid link pair is found.
    
    Fixes: b9be67fb4207 ("wifi: iwlwifi: mvm: Add basic link selection logic")
    Signed-off-by: Ilan Peer <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231219215605.142e57a05230.I7cfe78c94c3d15c4c744bccadd8f187e43594932@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: send TX path flush in rfkill [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Dec 19 21:58:52 2023 +0200

    wifi: iwlwifi: mvm: send TX path flush in rfkill
    
    [ Upstream commit 2afc3dad39ea84a072d04ff40a417234326adc47 ]
    
    If we want to drop packets, that's surely a good thing to
    do when we want to enter rfkill. Send this command despite
    rfkill so we can successfully clean up everything, we need
    to handle it separately since it has CMD_WANT_SKB, so it's
    not going to automatically return success when in rfkill.
    
    Fixes: d4e3a341b87b ("iwlwifi: mvm: add support for new flush queue response")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231219215605.c528a6fa6cec.Ibe5e9560359ccc0fba60c35e01de285c376748a2@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: set siso/mimo chains to 1 in FW SMPS request [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Dec 19 21:58:49 2023 +0200

    wifi: iwlwifi: mvm: set siso/mimo chains to 1 in FW SMPS request
    
    [ Upstream commit b1a2e5c310e063560760806d2cc5d2233c596067 ]
    
    The firmware changed their mind, don't set the chains to zero,
    instead set them to 1 as we normally would for connections to
    APs that don't use MIMO.
    
    Fixes: 2a7ce54ccc23 ("iwlwifi: mvm: honour firmware SMPS requests")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Luciano Coelho <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231219215605.7f031f1a127f.Idc816e0f604b07d22a9d5352bc23c445512fad14@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: libertas: stop selecting wext [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Nov 8 16:34:03 2023 +0100

    wifi: libertas: stop selecting wext
    
    [ Upstream commit 8170b04c2c92eee52ea50b96db4c54662197e512 ]
    
    Libertas no longer references the iw_handler infrastructure or wext_spy,
    so neither of the 'select' statements are used any more.
    
    Fixes: e86dc1ca4676 ("Libertas: cfg80211 support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix advertised TTLM scheduling [+ + +]
Author: Ayala Beker <[email protected]>
Date:   Wed Dec 20 13:41:44 2023 +0200

    wifi: mac80211: fix advertised TTLM scheduling
    
    [ Upstream commit b1a23f8ae0d76ad32fe36682730c050251275b0b ]
    
    Handle a case of time overflow, where the switch time might
    be smaller than the partial TSF in the beacon.
    Additionally, apply advertised TTLM earlier in order to be
    ready on time on the newly activated links.
    
    Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping")
    Signed-off-by: Ayala Beker <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20231220133549.15079c34e5c8.I0dd50bcceff5953080cdd7aee5118b72c78c6507@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: fix broken precal loading from MTD for mt7915 [+ + +]
Author: Christian Marangi <[email protected]>
Date:   Wed Oct 18 15:09:37 2023 +0200

    wifi: mt76: fix broken precal loading from MTD for mt7915
    
    commit e874a79250b39447765ac13272b67ac36ccf2a75 upstream.
    
    Commit 495184ac91bb ("mt76: mt7915: add support for applying
    pre-calibration data") was fundamentally broken and never worked.
    
    The idea (before NVMEM support) was to expand the MTD function and pass
    an additional offset. For normal EEPROM load the offset would always be
    0. For the purpose of precal loading, an offset was passed that was
    internally the size of EEPROM, since precal data is right after the
    EEPROM.
    
    Problem is that the offset value passed is never handled and is actually
    overwrite by
    
            offset = be32_to_cpup(list);
            ret = mtd_read(mtd, offset, len, &retlen, eep);
    
    resulting in the passed offset value always ingnored. (and even passing
    garbage data as precal as the start of the EEPROM is getting read)
    
    Fix this by adding to the current offset value, the offset from DT to
    correctly read the piece of data at the requested location.
    
    Cc: [email protected]
    Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data")
    Signed-off-by: Christian Marangi <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: fix typo in mt76_get_of_eeprom_from_nvmem function [+ + +]
Author: Christian Marangi <[email protected]>
Date:   Wed Oct 18 15:09:38 2023 +0200

    wifi: mt76: fix typo in mt76_get_of_eeprom_from_nvmem function
    
    [ Upstream commit c33e5f4cbb9f961e66473a9ace077c4d1f29a5bb ]
    
    Fix typo in mt76_get_of_eeprom_from_nvmem where eeprom was misspelled as
    epprom.
    
    Fixes: 5bef3a406c6e ("wifi: mt76: add support for providing eeprom in nvmem cells")
    Signed-off-by: Christian Marangi <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7915: also MT7981 is 3T3R but nss2 on 5 GHz band [+ + +]
Author: StanleyYP Wang <[email protected]>
Date:   Mon Nov 6 22:39:31 2023 +0000

    wifi: mt76: mt7915: also MT7981 is 3T3R but nss2 on 5 GHz band
    
    [ Upstream commit ff434cc129d6907e6dbc89dd0ebc59fd3646d4c2 ]
    
    Just like MT7916 also MT7981 can handle 3T3R DBDC frontend and should
    hence be included in the corresponding conditional expression in the
    driver. Add it.
    
    Fixes: 6bad146d162e ("wifi: mt76: mt7915: add support for MT7981")
    Signed-off-by: StanleyYP Wang <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7915: fallback to non-wed mode if platform_get_resource fails in mt7915_mmio_wed_init() [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Fri Oct 20 12:45:19 2023 +0200

    wifi: mt76: mt7915: fallback to non-wed mode if platform_get_resource fails in mt7915_mmio_wed_init()
    
    [ Upstream commit 5f9d5d4fc561e7bd3a18742f1fdb96cab98f1870 ]
    
    mt76 assumes mt7915_mmio_wed_init can fail just after wed driver has
    been attached running mtk_wed_device_attach().
    Fall back to non-wed mode if platform_get_resource fails in
    mt7915_mmio_wed_init routines.
    
    Fixes: eebb70976be5 ("wifi: mt76: mt7915: enable wed for mt7986-wmac chipset")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7915: fix EEPROM offset of TSSI flag on MT7981 [+ + +]
Author: StanleyYP Wang <[email protected]>
Date:   Mon Nov 6 22:38:53 2023 +0000

    wifi: mt76: mt7915: fix EEPROM offset of TSSI flag on MT7981
    
    [ Upstream commit 3531c72aedb95261f4d78c47efa4b5ba7cdcddd9 ]
    
    The offset of the TSSI flag on the EEPROM of MT7981 devices was wrong.
    Set the correct offset instead.
    
    Fixes: 6bad146d162e ("wifi: mt76: mt7915: add support for MT7981")
    Signed-off-by: StanleyYP Wang <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7921: fix CLC command timeout when suspend/resume [+ + +]
Author: Ming Yen Hsieh <[email protected]>
Date:   Wed Nov 22 11:06:45 2023 +0800

    wifi: mt76: mt7921: fix CLC command timeout when suspend/resume
    
    [ Upstream commit d0a2bc5fe712217d2c73822ae75fd4e69a15cb2c ]
    
    When enter suspend/resume while in a connected state, the upper layer
    will trigger disconnection before entering suspend, and at the same time,
    it will trigger regd_notifier() and update CLC, causing the CLC event to
    not be received due to suspend, resulting in a command timeout.
    
    Therefore, the update of CLC is postponed until resume, to ensure data
    consistency and avoid the occurrence of command timeout.
    
    Fixes: 4fc8df50fd41 ("wifi: mt76: mt7921: get regulatory information from the clc event")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7921: fix country count limitation for CLC [+ + +]
Author: Ming Yen Hsieh <[email protected]>
Date:   Wed Nov 22 11:06:44 2023 +0800

    wifi: mt76: mt7921: fix country count limitation for CLC
    
    [ Upstream commit fa6ad88e023ddfa6c5dcdb466d159e89f451e305 ]
    
    Due to the increase in the number of power tables for 6Ghz on CLC,
    the variable nr_country is no longer sufficient to represent the
    total quantity. Therefore, we have switched to calculating the
    length of clc buf to obtain the correct power table. Additionally,
    the version number has been incremented to 1.
    
    Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7921: fix wrong 6Ghz power type [+ + +]
Author: Ming Yen Hsieh <[email protected]>
Date:   Wed Nov 22 11:06:46 2023 +0800

    wifi: mt76: mt7921: fix wrong 6Ghz power type
    
    [ Upstream commit 10f2903147ed04784522ab841c20bb469bdd8681 ]
    
    To avoid using incorrect 6g power settings after disconnection,
    it should to update back to the default state when disconnected.
    
    Fixes: 51ba0e3a15eb ("wifi: mt76: mt7921: add 6GHz power type support for clc")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7921s: fix workqueue problem causes STA association fail [+ + +]
Author: Wang Zhao <[email protected]>
Date:   Fri Nov 17 20:54:49 2023 +0800

    wifi: mt76: mt7921s: fix workqueue problem causes STA association fail
    
    [ Upstream commit 92184eae1d5ad804884e2c6e289d885b9e3194d1 ]
    
    The ieee80211_queue_work function queues work into the mac80211
    local->workqueue, which is widely used for mac80211 internal
    work processes. In the mt76 driver, both the mt76-sido-status and
    mt76-sdio-net threads enqueue workers to the workqueue with this
    function. However, in some cases, when two workers are enqueued
    to the workqueue almost simultaneously, the second worker may not
    be scheduled immediately and may get stuck for a while.
    This can cause timing issues. To avoid these timing
    conflicts caused by worker scheduling, replace the worker
    with an independent thread.
    
    Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
    Signed-off-by: Wang Zhao <[email protected]>
    Signed-off-by: Deren Wu <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix alignment of sta info event [+ + +]
Author: StanleyYP Wang <[email protected]>
Date:   Thu Nov 2 18:02:59 2023 +0800

    wifi: mt76: mt7996: fix alignment of sta info event
    
    [ Upstream commit d58a9778f7ca0634622d2fc2e9f76163467bdf5b ]
    
    Fix the alignment of struct mt7996_mcu_all_sta_info_event.
    
    Fixes: adde3eed4a75 ("wifi: mt76: mt7996: Add mcu commands for getting sta tx statistic")
    Signed-off-by: StanleyYP Wang <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix mt7996_mcu_all_sta_info_event struct packing [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Nov 10 15:29:30 2023 +0100

    wifi: mt76: mt7996: fix mt7996_mcu_all_sta_info_event struct packing
    
    [ Upstream commit 2ee1c40daeb9a33e25c460bf87feca58e91af879 ]
    
    The internal struct and union inside mt7996_mcu_all_sta_info_event is
    marked as being aligned, which conflicts with it being unaligned
    within that structure:
    
    drivers/net/wireless/mediatek/mt76/mt7996/mcu.h:165:2: error: field  within 'struct mt7996_mcu_all_sta_info_event' is less aligned than 'union mt7996_mcu_all_sta_info_event::(anonymous at ../drivers/net/wireless/mediatek/mt76/mt7996/mcu.h:165:2)' and is usually due to 'struct mt7996_mcu_all_sta_info_event' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
    
    Mark all three as being packed as well to ensure byte packing for
    the entire thing.
    
    Fixes: adde3eed4a75 ("wifi: mt76: mt7996: Add mcu commands for getting sta tx statistic")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix rate usage of inband discovery frames [+ + +]
Author: MeiChia Chiu <[email protected]>
Date:   Mon Oct 23 23:38:54 2023 +0800

    wifi: mt76: mt7996: fix rate usage of inband discovery frames
    
    [ Upstream commit 1e3f387736c744e73b5398a147b90412f82f54da ]
    
    For UBPR and FILS frames, the BSS_CHANGED_BEACON flag will also be set,
    which causes those frames to use the beacon rate in TX descriptors.
    Adjust the statement to fix this issue.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: MeiChia Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix the size of struct bss_rate_tlv [+ + +]
Author: Sujuan Chen <[email protected]>
Date:   Mon Oct 23 23:38:49 2023 +0800

    wifi: mt76: mt7996: fix the size of struct bss_rate_tlv
    
    [ Upstream commit 4aa9992674e70074fce450f65ebc95c2ba2b79ae ]
    
    Align the format of struct bss_rate_tlv to the firmware.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Sujuan Chen <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix uninitialized variable in parsing txfree [+ + +]
Author: Yi-Chia Hsieh <[email protected]>
Date:   Thu Oct 12 15:00:26 2023 -0700

    wifi: mt76: mt7996: fix uninitialized variable in parsing txfree
    
    [ Upstream commit 706e83b33103fc5dc945765ddbf6a3e879d21275 ]
    
    Fix the uninitialized variable warning in mt7996_mac_tx_free.
    
    Fixes: 2461599f835e ("wifi: mt76: mt7996: get tx_retries and tx_failed from txfree")
    Signed-off-by: Yi-Chia Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mwifiex: add extra delay for firmware ready [+ + +]
Author: David Lin <[email protected]>
Date:   Sat Dec 9 07:40:29 2023 +0800

    wifi: mwifiex: add extra delay for firmware ready
    
    commit 1c5d463c0770c6fa2037511a24fb17966fd07d97 upstream.
    
    For SDIO IW416, due to a bug, FW may return ready before complete full
    initialization. Command timeout may occur at driver load after reboot.
    Workaround by adding 100ms delay at checking FW status.
    
    Signed-off-by: David Lin <[email protected]>
    Cc: [email protected]
    Reviewed-by: Francesco Dolcini <[email protected]>
    Acked-by: Brian Norris <[email protected]>
    Tested-by: Marcel Ziswiler <[email protected]> # Verdin AM62 (IW416)
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mwifiex: configure BSSID consistently when starting AP [+ + +]
Author: David Lin <[email protected]>
Date:   Fri Dec 15 08:51:18 2023 +0800

    wifi: mwifiex: configure BSSID consistently when starting AP
    
    commit f0dd488e11e71ac095df7638d892209c629d9af2 upstream.
    
    AP BSSID configuration is missing at AP start.  Without this fix, FW returns
    STA interface MAC address after first init.  When hostapd restarts, it gets MAC
    address from netdev before driver sets STA MAC to netdev again. Now MAC address
    between hostapd and net interface are different causes STA cannot connect to
    AP.  After that MAC address of uap0 mlan0 become the same. And issue disappears
    after following hostapd restart (another issue is AP/STA MAC address become the
    same).
    
    This patch fixes the issue cleanly.
    
    Signed-off-by: David Lin <[email protected]>
    Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers")
    Cc: [email protected]
    Reviewed-by: Francesco Dolcini <[email protected]>
    Tested-by: Rafael Beims <[email protected]> # Verdin iMX8MP/SD8997 SD
    Acked-by: Brian Norris <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mwifiex: fix uninitialized firmware_stat [+ + +]
Author: David Lin <[email protected]>
Date:   Thu Dec 21 09:55:11 2023 +0800

    wifi: mwifiex: fix uninitialized firmware_stat
    
    commit 3df95e265924ac898c1a38a0c01846dd0bd3b354 upstream.
    
    Variable firmware_stat is possible to be used without initialization.
    
    Signed-off-by: David Lin <[email protected]>
    Fixes: 1c5d463c0770 ("wifi: mwifiex: add extra delay for firmware ready")
    Cc: [email protected]
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Acked-by: Brian Norris <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: plfxlc: check for allocation failure in plfxlc_usb_wreq_async() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Oct 30 12:03:23 2023 +0300

    wifi: plfxlc: check for allocation failure in plfxlc_usb_wreq_async()
    
    [ Upstream commit 40018a8fa9aa63ca5b26e803502138158fb0ff96 ]
    
    Check for if the usb_alloc_urb() failed.
    
    Fixes: 68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: add calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:29 2023 +0800

    wifi: rtlwifi: add calculate_bit_shift()
    
    [ Upstream commit 52221dfddbbfb5b4e029bb2efe9bb7da33ec1e46 ]
    
    There are many same functions like _rtl88e_phy_calculate_bit_shift(),
    _rtl92c_phy_calculate_bit_shift() and so on. And these functions can
    cause undefined bitwise shift behavior. Add calculate_bit_shift() to
    replace them and fix undefined behavior in subsequent patches.
    
    Signed-off-by: Su Hui <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Stable-dep-of: 969bc926f04b ("wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift()")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Fri Nov 24 10:47:17 2023 +0200

    wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors
    
    commit 5894d0089cbc146063dcc0239a78ede0a8142efb upstream.
    
    The rtlwifi driver comes with custom code to write into PCIe Link
    Control register. RMW access for the Link Control register requires
    locking that is already provided by the standard PCIe capability
    accessors.
    
    Convert the custom RMW code writing into LNKCTL register to standard
    RMW capability accessors. The accesses are changed to cover the full
    LNKCTL register instead of touching just a single byte of the register.
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Cc: [email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Fri Nov 24 10:47:16 2023 +0200

    wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code
    
    commit b3943b3c2971444364e03224cfc828c5789deada upstream.
    
    Ever since introduction in the commit 0c8173385e54 ("rtl8192ce: Add new
    driver") the rtlwifi code has, according to comments, attempted to
    disable/enable ASPM of the upstream bridge by writing into its LNKCTL
    register. However, the code has never been correct because it performs
    the writes to the device instead of the upstream bridge.
    
    Worse yet, the offset where the PCIe capabilities reside is derived
    from the offset of the upstream bridge. As a result, the write will use
    an offset on the device that does not relate to the LNKCTL register
    making the ASPM disable/enable code outright dangerous.
    
    Because of those problems, there is no indication that the driver needs
    disable/enable ASPM on the upstream bridge. As the Capabilities offset
    is not correctly calculated for the write to target device's LNKCTL
    register, the code is not disabling/enabling device's ASPM either.
    Therefore, just remove the upstream bridge related ASPM disable/enable
    code entirely.
    
    The upstream bridge related ASPM code was the only user of the struct
    mp_adapter members num4bytes, pcibridge_pciehdr_offset, and
    pcibridge_linkctrlreg so those are removed as well.
    
    Note: This change does not remove the code related to changing the
    device's ASPM on purpose (which is independent of this flawed code
    related to upstream bridge's ASPM).
    
    Suggested-by: Bjorn Helgaas <[email protected]>
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Fixes: 886e14b65a8f ("rtlwifi: Eliminate raw reads and writes from PCIe portion")
    Cc: [email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:31 2023 +0800

    wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift()
    
    [ Upstream commit 969bc926f04b438676768aeffffffb050e480b62 ]
    
    Using calculate_bit_shift() to replace _rtl88e_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: f0eb856e0b6c ("rtlwifi: rtl8188ee: Add new driver")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192c: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:32 2023 +0800

    wifi: rtlwifi: rtl8192c: using calculate_bit_shift()
    
    [ Upstream commit 1dedc3a6699d827d345019e921b8d8f37f694333 ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 4295cd254af3 ("rtlwifi: Move common parts of rtl8192ce/phy.c")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192ce: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:34 2023 +0800

    wifi: rtlwifi: rtl8192ce: using calculate_bit_shift()
    
    [ Upstream commit 3d03e8231031bcc65a48cd88ef9c71b6524ce70b ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192cu: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:33 2023 +0800

    wifi: rtlwifi: rtl8192cu: using calculate_bit_shift()
    
    [ Upstream commit f4088c8fcbabadad9dd17d17ae9ba24e9e3221ec ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix an undefined bitwise shift behavior problem.
    
    Fixes: f0a39ae738d6 ("rtlwifi: rtl8192cu: Add routine phy")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192de: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:35 2023 +0800

    wifi: rtlwifi: rtl8192de: using calculate_bit_shift()
    
    [ Upstream commit b8b2baad2e652042cf8b6339939ac2f4e6f53de4 ]
    
    Using calculate_bit_shift() to replace _rtl92d_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192ee: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:36 2023 +0800

    wifi: rtlwifi: rtl8192ee: using calculate_bit_shift()
    
    [ Upstream commit 63526897fc0d086069bcab67c3a112caaec751cb ]
    
    Using calculate_bit_shift() to replace _rtl92ee_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: b1a3bfc97cd9 ("rtlwifi: rtl8192ee: Move driver from staging to the regular tree")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8192se: using calculate_bit_shift() [+ + +]
Author: Su Hui <[email protected]>
Date:   Tue Dec 19 14:57:37 2023 +0800

    wifi: rtlwifi: rtl8192se: using calculate_bit_shift()
    
    [ Upstream commit ac32b9317063b101a8ff3d3e885f76f87a280419 ]
    
    Using calculate_bit_shift() to replace _rtl92s_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: d15853163bea ("rtlwifi: rtl8192se: Merge phy routines")
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtlwifi: rtl8821ae: phy: fix an undefined bitwise shift behavior [+ + +]
Author: Su Hui <[email protected]>
Date:   Mon Nov 27 09:35:13 2023 +0800

    wifi: rtlwifi: rtl8821ae: phy: fix an undefined bitwise shift behavior
    
    [ Upstream commit bc8263083af60e7e57c6120edbc1f75d6c909a35 ]
    
    Clang static checker warns:
    
    drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:184:49:
            The result of the left shift is undefined due to shifting by '32',
            which is greater or equal to the width of type 'u32'.
            [core.UndefinedBinaryOperatorResult]
    
    If the value of the right operand is negative or is greater than or
    equal to the width of the promoted left operand, the behavior is
    undefined.[1][2]
    
    For example, when using different gcc's compilation optimization options
    (-O0 or -O2), the result of '(u32)data << 32' is different. One is 0, the
    other is old value of data. Let _rtl8821ae_phy_calculate_bit_shift()'s
    return value less than 32 to fix this problem. Warn if bitmask is zero.
    
    [1] https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type
    [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
    
    Fixes: 21e4b0726dc6 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree")
    Signed-off-by: Su Hui <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: fix RX filter in FIF_ALLMULTI flag [+ + +]
Author: Chih-Kang Chang <[email protected]>
Date:   Fri Nov 3 10:08:51 2023 +0800

    wifi: rtw88: fix RX filter in FIF_ALLMULTI flag
    
    [ Upstream commit 53ee0b3b99edc6a47096bffef15695f5a895386f ]
    
    The broadcast packets will be filtered in the FIF_ALLMULTI flag in
    the original code, which causes beacon packets to be filtered out
    and disconnection. Therefore, we fix it.
    
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Chih-Kang Chang <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: sdio: Honor the host max_req_size in the RX path [+ + +]
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Nov 20 12:57:26 2023 +0100

    wifi: rtw88: sdio: Honor the host max_req_size in the RX path
    
    [ Upstream commit 00384f565a91c08c4bedae167f749b093d10e3fe ]
    
    Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes
    with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth
    combo card. The error he observed is identical to what has been fixed
    in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST
    bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem.
    
    Lukas found that disabling or limiting RX aggregation works around the
    problem for some time (but does not fully fix it). In the following
    discussion a few key topics have been discussed which have an impact on
    this problem:
    - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller
      which prevents DMA transfers. Instead all transfers need to go through
      the controller SRAM which limits transfers to 1536 bytes
    - rtw88 chips don't split incoming (RX) packets, so if a big packet is
      received this is forwarded to the host in it's original form
    - rtw88 chips can do RX aggregation, meaning more multiple incoming
      packets can be pulled by the host from the card with one MMC/SDIO
      transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH
      register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will
      be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation
      and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)
    
    Use multiple consecutive reads in rtw_sdio_read_port() and limit the
    number of bytes which are copied by the host from the card in one
    MMC/SDIO transfer. This allows receiving a buffer that's larger than
    the hosts max_req_size (number of bytes which can be transferred in
    one MMC/SDIO transfer). As a result of this the skb_over_panic error
    is gone as the rtw88 driver is now able to receive more than 1536 bytes
    from the card (either because the incoming packet is larger than that
    or because multiple packets have been aggregated).
    
    In case of an receive errors (-EILSEQ has been observed by Lukas) we
    need to drain the remaining data from the card's buffer, otherwise the
    card will return corrupt data for the next rtw_sdio_read_port() call.
    
    Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
    Reported-by: Lukas F. Hartmann <[email protected]>
    Closes: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/
    Suggested-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Tested-by: Lukas F. Hartmann <[email protected]>
    Reported-by: Lukas F. Hartmann <[email protected]>
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Tested-by: Lukas F. Hartmann <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/kvm: Do not try to disable kvmclock if it was not enabled [+ + +]
Author: Kirill A. Shutemov <[email protected]>
Date:   Tue Dec 5 03:45:01 2023 +0300

    x86/kvm: Do not try to disable kvmclock if it was not enabled
    
    commit 1c6d984f523f67ecfad1083bb04c55d91977bb15 upstream.
    
    kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
    present in the VM. It leads to write to a MSR that doesn't exist on some
    configurations, namely in TDX guest:
    
            unchecked MSR access error: WRMSR to 0x12 (tried to write 0x0000000000000000)
            at rIP: 0xffffffff8110687c (kvmclock_disable+0x1c/0x30)
    
    kvmclock enabling is gated by CLOCKSOURCE and CLOCKSOURCE2 KVM paravirt
    features.
    
    Do not disable kvmclock if it was not enabled.
    
    Signed-off-by: Kirill A. Shutemov <[email protected]>
    Fixes: c02027b5742b ("x86/kvm: Disable kvmclock on all CPUs on shutdown")
    Reviewed-by: Sean Christopherson <[email protected]>
    Reviewed-by: Vitaly Kuznetsov <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Wanpeng Li <[email protected]>
    Cc: [email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/lib: Fix overflow when counting digits [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Thu Nov 2 17:49:01 2023 +0000

    x86/lib: Fix overflow when counting digits
    
    [ Upstream commit a24d61c609813963aacc9f6ec8343f4fcaac7243 ]
    
    tl;dr: The num_digits() function has a theoretical overflow issue.
    But it doesn't affect any actual in-tree users.  Fix it by using
    a larger type for one of the local variables.
    
    Long version:
    
    There is an overflow in variable m in function num_digits when val
    is >= 1410065408 which leads to the digit calculation loop to
    iterate more times than required. This results in either more
    digits being counted or in some cases (for example where val is
    1932683193) the value of m eventually overflows to zero and the
    while loop spins forever).
    
    Currently the function num_digits is currently only being used for
    small values of val in the SMP boot stage for digit counting on the
    number of cpus and NUMA nodes, so the overflow is never encountered.
    However it is useful to fix the overflow issue in case the function
    is used for other purposes in the future. (The issue was discovered
    while investigating the digit counting performance in various
    kernel helper functions rather than any real-world use-case).
    
    The simplest fix is to make m a long long, the overhead in
    multiplication speed for a long long is very minor for small values
    of val less than 10000 on modern processors. The alternative
    fix is to replace the multiplication with a constant division
    by 10 loop (this compiles down to an multiplication and shift)
    without needing to make m a long long, but this is slightly slower
    than the fix in this commit when measured on a range of x86
    processors).
    
    [ dhansen: subject and changelog tweaks ]
    
    Fixes: 646e29a1789a ("x86: Improve the printout of the SMP bootup CPU table")
    Signed-off-by: Colin Ian King <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Link: https://lore.kernel.org/all/20231102174901.2590325-1-colin.i.king%40gmail.com
    Signed-off-by: Sasha Levin <[email protected]>
 
x86/mce/inject: Clear test status value [+ + +]
Author: Yazen Ghannam <[email protected]>
Date:   Sat Nov 18 13:32:29 2023 -0600

    x86/mce/inject: Clear test status value
    
    [ Upstream commit 6175b407756b22e7fdc771181b7d832ebdedef5c ]
    
    AMD systems generally allow MCA "simulation" where MCA registers can be
    written with valid data and the full MCA handling flow can be tested by
    software.
    
    However, the platform on Scalable MCA systems, can prevent software from
    writing data to the MCA registers. There is no architectural way to
    determine this configuration. Therefore, the MCE injection module will
    check for this behavior by writing and reading back a test status value.
    This is done during module init, and the check can run on any CPU with
    any valid MCA bank.
    
    If MCA_STATUS writes are ignored by the platform, then there are no side
    effects on the hardware state.
    
    If the writes are not ignored, then the test status value will remain in
    the hardware MCA_STATUS register. It is likely that the value will not
    be overwritten by hardware or software, since the tested CPU and bank
    are arbitrary. Therefore, the user may see a spurious, synthetic MCA
    error reported whenever MCA is polled for this CPU.
    
    Clear the test value immediately after writing it. It is very unlikely
    that a valid MCA error is logged by hardware during the test. Errors
    that cause an #MC won't be affected.
    
    Fixes: 891e465a1bd8 ("x86/mce: Check whether writes to MCA_STATUS are getting ignored")
    Signed-off-by: Yazen Ghannam <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/microcode/intel: Set new revision only after a successful update [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Fri Dec 1 14:35:06 2023 +0100

    x86/microcode/intel: Set new revision only after a successful update
    
    [ Upstream commit 9c21ea53e6bd1104c637b80a0688040f184cc761 ]
    
    This was meant to be done only when early microcode got updated
    successfully. Move it into the if-branch.
    
    Also, make sure the current revision is read unconditionally and only
    once.
    
    Fixes: 080990aa3344 ("x86/microcode: Rework early revisions reporting")
    Reported-by: Ashok Raj <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Tested-by: Ashok Raj <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/pci: Reserve ECAM if BIOS didn't include it in PNP0C02 _CRS [+ + +]
Author: Bjorn Helgaas <[email protected]>
Date:   Tue Nov 21 12:36:35 2023 -0600

    x86/pci: Reserve ECAM if BIOS didn't include it in PNP0C02 _CRS
    
    commit 070909e56a7d65fd0b4aad6e808966b7c634befe upstream.
    
    Tomasz, Sebastian, and some Proxmox users reported problems initializing
    ixgbe NICs.
    
    I think the problem is that ECAM space described in the ACPI MCFG table is
    not reserved via a PNP0C02 _CRS method as required by the PCI Firmware spec
    (r3.3, sec 4.1.2), but it *is* included in the PNP0A03 host bridge _CRS as
    part of the MMIO aperture.
    
    If we allocate space for a PCI BAR, we're likely to allocate it from that
    ECAM space, which obviously cannot work.
    
    This could happen for any device, but in the ixgbe case it happens because
    it's an SR-IOV device and the BIOS didn't allocate space for the VF BARs,
    so Linux reallocated the bridge window leading to ixgbe and put it on top
    of the ECAM space.  From Tomasz' system:
    
      PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
      PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources
      pci_bus 0000:00: root bus resource [mem 0x80000000-0xfbffffff window]
    
      pci 0000:00:01.1: PCI bridge to [bus 02-03]
      pci 0000:00:01.1:   bridge window [mem 0xfb900000-0xfbbfffff]
      pci 0000:02:00.0: [8086:10fb] type 00 class 0x020000  # ixgbe
      pci 0000:02:00.0: reg 0x10: [mem 0xfba80000-0xfbafffff 64bit]
      pci 0000:02:00.0: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit] (contains BAR0 for 64 VFs)
      pci 0000:02:00.0: BAR 7: no space for [mem size 0x00100000 64bit]   # VF BAR 0
    
      pci_bus 0000:00: No. 2 try to assign unassigned res
      pci 0000:00:01.1: resource 14 [mem 0xfb900000-0xfbbfffff] released
      pci 0000:00:01.1: BAR 14: assigned [mem 0x80000000-0x806fffff]
      pci 0000:02:00.0: BAR 0: assigned [mem 0x80000000-0x8007ffff 64bit]
      pci 0000:02:00.0: BAR 7: assigned [mem 0x80204000-0x80303fff 64bit] # VF BAR 0
    
    Fixes: 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map")
    Fixes: fd3a8cff4d4a ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM space")
    Reported-by: Tomasz Pala <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218050
    Reported-by: Sebastian Manciulea <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218107
    Link: https://forum.proxmox.com/threads/proxmox-8-kernel-6-2-16-4-pve-ixgbe-driver-fails-to-load-due-to-pci-device-probing-failure.131203/
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Tomasz Pala <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]      # v6.2+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86: Fix CPUIDLE_FLAG_IRQ_ENABLE leaking timer reprogram [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Wed Nov 15 10:13:23 2023 -0500

    x86: Fix CPUIDLE_FLAG_IRQ_ENABLE leaking timer reprogram
    
    [ Upstream commit edc8fc01f608108b0b7580cb2c29dfb5135e5f0e ]
    
    intel_idle_irq() re-enables IRQs very early. As a result, an interrupt
    may fire before mwait() is eventually called. If such an interrupt queues
    a timer, it may go unnoticed until mwait returns and the idle loop
    handles the tick re-evaluation. And monitoring TIF_NEED_RESCHED doesn't
    help because a local timer enqueue doesn't set that flag.
    
    The issue is mitigated by the fact that this idle handler is only invoked
    for shallow C-states when, presumably, the next tick is supposed to be
    close enough. There may still be rare cases though when the next tick
    is far away and the selected C-state is shallow, resulting in a timer
    getting ignored for a while.
    
    Fix this with using sti_mwait() whose IRQ-reenablement only triggers
    upon calling mwait(), dealing with the race while keeping the interrupt
    latency within acceptable bounds.
    
    Fixes: c227233ad64c (intel_idle: enable interrupts before C1 on Xeons)
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Rafael J. Wysocki <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
xen-netback: don't produce zero-size SKB frags [+ + +]
Author: Jan Beulich <[email protected]>
Date:   Mon Jan 8 09:55:56 2024 +0100

    xen-netback: don't produce zero-size SKB frags
    
    commit c7ec4f2d684e17d69bbdd7c4324db0ef5daac26a upstream.
    
    While frontends may submit zero-size requests (wasting a precious slot),
    core networking code as of at least 3ece782693c4b ("sock: skb_copy_ubufs
    support for compound pages") can't deal with SKBs when they have all
    zero-size fragments. Respond to empty requests right when populating
    fragments; all further processing is fragment based and hence won't
    encounter these empty requests anymore.
    
    In a way this should have been that way from the beginning: When no data
    is to be transferred for a particular request, there's not even a point
    in validating the respective grant ref. That's no different from e.g.
    passing NULL into memcpy() when at the same time the size is 0.
    
    This is XSA-448 / CVE-2023-46838.
    
    Cc: [email protected]
    Signed-off-by: Jan Beulich <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Reviewed-by: Paul Durrant <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>