Список изменений в Linux 6.7.11

Author: Perry Yuan <[email protected]>
Date:   Thu Feb 8 11:46:28 2024 +0800

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

Author: Armin Wolf <[email protected]>
Date:   Tue Feb 13 01:41:58 2024 +0100

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

Author: David McFarland <[email protected]>
Date:   Wed Jan 3 12:55:18 2024 -0400

    ACPI: resource: Add Infinity laptops to irq1_edge_low_force_override
    
    [ Upstream commit e2605d4039a42a03000856b3229932455717b48b ]
    
    A user reported a keyboard problem similar to ones reported with other
    Zen laptops, on an Infinity E15-5A165-BM.
    
    Add board name matches for this model and one (untested) close relative
    to irq1_edge_low_force_override.
    
    Link: https://lemmy.ml/post/9864736
    Link: https://www.infinitygaming.com.au/bios/
    Link: https://lore.kernel.org/linux-acpi/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: 021a67d09615 ("ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Maxim Kudinov <[email protected]>
Date:   Fri Feb 23 19:24:08 2024 +0300

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

Author: Alexey I. Froloff <[email protected]>
Date:   Fri Feb 16 12:30:09 2024 +0000

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

Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Feb 26 17:35:27 2024 +0100

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

Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jan 23 09:08:52 2024 -0800

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

Author: David Howells <[email protected]>
Date:   Wed Mar 13 11:08:41 2024 +0000

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

Author: Kailang Yang <[email protected]>
Date:   Fri Feb 23 14:54:34 2024 +0800

    ALSA: hda/realtek - ALC285 reduce pop noise from Headphone port
    
    [ Upstream commit b34bf65838f7c6e785f62681605a538b73c2808c ]
    
    It had pop noise from Headphone port when system reboot state.
    If NID 58h Index 0x0 to fill default value, it will reduce pop noise.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Binding <[email protected]>
Date:   Fri Mar 1 16:01:53 2024 +0000

    ALSA: hda/realtek: Add quirks for Lenovo Thinkbook 16P laptops
    
    [ Upstream commit 6214e24cae9b10a7c1572f99552610a24614fffe ]
    
    These models use 2 CS35L41 amps with HDA using I2C.
    Both models have _DSD support inside cs35l41_hda_property.c.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218437
    
    Signed-off-by: Stefan Binding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jean-Loц╞c Charroud <[email protected]>
Date:   Wed Feb 14 00:38:31 2024 +0100

    ALSA: hda/realtek: cs35l41: Add internal speaker support for ASUS UM3402 with missing DSD
    
    [ Upstream commit 706c1fa1ab09f11a131fc4d699ce4c0224b1cb2d ]
    
    Add the values for the missing DSD properties to the cs35l41 config table.
    
    Signed-off-by: Jean-Loц╞c Charroud <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Athaariq Ardhiansyah <[email protected]>
Date:   Sun Mar 10 20:58:44 2024 +0700

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

Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:41 2024 +0100

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

Author: Gergo Koteles <[email protected]>
Date:   Sat Dec 30 01:09:42 2023 +0100

    ALSA: hda/tas2781: add ptrs to calibration functions
    
    [ Upstream commit 76f5f55c45b906710c9565a7e68c8d782c46b394 ]
    
    Make calibration functions configurable to support different calibration
    data storage modes.
    
    Signed-off-by: Gergo Koteles <[email protected]>
    Link: https://lore.kernel.org/r/5859c77ffef752b8a9784713b412d815d7e2688c.1703891777.git.soyer@irl.hu
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: 5f51de7e30c7 ("ALSA: hda/tas2781: do not call pm_runtime_force_* in system_resume/suspend")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gergo Koteles <[email protected]>
Date:   Sat Dec 30 01:13:41 2023 +0100

    ALSA: hda/tas2781: configure the amp after firmware load
    
    [ Upstream commit 68f7f3ff6c2a0998be9dc07622bd0d16fd1fda20 ]
    
    Make the amp available immediately after a module
    load to avoid having to wait for a PCM hook action.
    (eg. unloading & loading the module while listening
    music)
    
    Signed-off-by: Gergo Koteles <[email protected]>
    Link: https://lore.kernel.org/r/7f2f65d9212aa16edd4db8725489ae59dbe74c66.1703895108.git.soyer@irl.hu
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: 9fc91a6fe37c ("ALSA: hda/tas2781: restore power state after system_resume")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:43 2024 +0100

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

Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:42 2024 +0100

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

Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:44 2024 +0100

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

Author: Gergo Koteles <[email protected]>
Date:   Fri Mar 8 18:41:40 2024 +0100

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

Author: Stefan Binding <[email protected]>
Date:   Fri Mar 1 16:01:54 2024 +0000

    ALSA: hda: cs35l41: Overwrite CS35L41 configuration for ASUS UM5302LA
    
    [ Upstream commit b603d95692e47dc6f5f733e93c3841dc0c01e624 ]
    
    Whilst this laptop contains _DSD inside the BIOS, there is an error in
    this configuration. Override the _DSD in the BIOS with the correct
    configuration for this laptop.
    
    Signed-off-by: Stefan Binding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stefan Binding <[email protected]>
Date:   Fri Jan 26 16:40:02 2024 +0000

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

Author: Takashi Iwai <[email protected]>
Date:   Tue Feb 13 14:53:43 2024 +0100

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

Author: Johan Carlsson <[email protected]>
Date:   Wed Mar 13 09:15:09 2024 +0100

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

Author: Chun-Yi Lee <[email protected]>
Date:   Tue Mar 5 16:20:48 2024 +0800

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

Author: Mark Brown <[email protected]>
Date:   Tue Feb 13 18:24:38 2024 +0000

    arm64/sve: Lower the maximum allocation for the SVE ptrace regset
    
    [ Upstream commit 2813926261e436d33bc74486b51cce60b76edf78 ]
    
    Doug Anderson observed that ChromeOS crashes are being reported which
    include failing allocations of order 7 during core dumps due to ptrace
    allocating storage for regsets:
    
      chrome: page allocation failure: order:7,
              mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
              nodemask=(null),cpuset=urgent,mems_allowed=0
       ...
      regset_get_alloc+0x1c/0x28
      elf_core_dump+0x3d8/0xd8c
      do_coredump+0xeb8/0x1378
    
    with further investigation showing that this is:
    
       [   66.957385] DOUG: Allocating 279584 bytes
    
    which is the maximum size of the SVE regset. As Doug observes it is not
    entirely surprising that such a large allocation of contiguous memory might
    fail on a long running system.
    
    The SVE regset is currently sized to hold SVE registers with a VQ of
    SVE_VQ_MAX which is 512, substantially more than the architectural maximum
    of 16 which we might see even in a system emulating the limits of the
    architecture. Since we don't expose the size we tell the regset core
    externally let's define ARCH_SVE_VQ_MAX with the actual architectural
    maximum and use that for the regset, we'll still overallocate most of the
    time but much less so which will be helpful even if the core is fixed to
    not require contiguous allocations.
    
    Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written
    into ZCR_ELx.LEN (where this is set in the hardware). For consistency
    update the maximum SME vector length to be specified in the same style
    while we are at it.
    
    We could also teach the ptrace core about runtime discoverable regset sizes
    but that would be a more invasive change and this is being observed in
    practical systems.
    
    Reported-by: Doug Anderson <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Tested-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chen-Yu Tsai <[email protected]>
Date:   Sun Jan 28 00:32:45 2024 +0800

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Thu Jan 11 12:56:36 2024 +0100

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

Author: Rob Herring <[email protected]>
Date:   Tue Feb 13 13:34:27 2024 -0600

    arm64: dts: Fix dtc interrupt_provider warnings
    
    [ Upstream commit 91adecf911e5df78ea3e8f866e69db2c33416a5c ]
    
    The dtc interrupt_provider warning is off by default. Fix all the warnings
    so it can be enabled.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-By: AngeloGioacchino Del Regno <[email protected]> #
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Florian Fainelli <[email protected]> #Broadcom
    Acked-by: Chanho Min <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:03 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:02 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:48:58 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:48:59 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:01 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:00 2024 +0100

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

Author: Frieder Schrempf <[email protected]>
Date:   Mon Jan 8 09:49:04 2024 +0100

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

Author: Tim Harvey <[email protected]>
Date:   Wed Dec 20 15:30:46 2023 -0800

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

Author: Liu Ying <[email protected]>
Date:   Fri Feb 23 10:57:38 2024 +0800

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

Author: Marek Vasut <[email protected]>
Date:   Sat Feb 17 22:33:30 2024 +0100

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

Author: Frank Li <[email protected]>
Date:   Thu Dec 14 14:46:54 2023 -0500

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

Author: Frank Li <[email protected]>
Date:   Thu Dec 14 14:46:55 2023 -0500

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Tue Jan 23 13:22:58 2024 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Mon Jan 22 14:23:57 2024 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Mon Jan 1 19:20:40 2024 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Mon Jan 1 19:20:39 2024 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Thu Nov 16 14:24:11 2023 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Thu Nov 16 14:08:16 2023 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Thu Nov 16 14:09:51 2023 +0100

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

Author: Rafaе┌ Miе┌ecki <[email protected]>
Date:   Thu Nov 16 14:09:52 2023 +0100

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Tue Feb 13 10:02:37 2024 -0500

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Tue Feb 13 10:02:38 2024 -0500

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

Author: Eugen Hristev <[email protected]>
Date:   Thu Dec 28 13:32:44 2023 +0200

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Wed Feb 7 15:08:42 2024 -0500

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

Author: Eugen Hristev <[email protected]>
Date:   Thu Dec 28 13:32:42 2023 +0200

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Tue Jan 16 18:38:34 2024 -0300

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

Author: Hsin-Te Yuan <[email protected]>
Date:   Wed Jan 24 07:51:57 2024 +0000

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

Author: Rob Herring <[email protected]>
Date:   Tue Feb 13 13:34:29 2024 -0600

    arm64: dts: qcom: Fix interrupt-map cell sizes
    
    [ Upstream commit 704dccec0d490f2ad06f3f16ebed254d81906c3a ]
    
    The PCI node interrupt-map properties have the wrong size as #address-cells
    in the interrupt parent are not accounted for.
    
    The dtc interrupt_map check catches this, but the warning is off because
    its dependency, interrupt_provider, is off by default.
    
    Signed-off-by: Rob Herring <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jan 17 16:04:26 2024 +0200

    arm64: dts: qcom: qcm2290: declare VLS CLAMP register for USB3 PHY
    
    [ Upstream commit acb94d67f5a23dbb2e0021b6c30609ed05d7d6a5 ]
    
    The USB3 PHY on the QCM2290 platform doesn't have built-in
    PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately
    via the register in the TCSR space. Declare corresponding register.
    
    Fixes: 0c55f6229bc3 ("arm64: dts: qcom: qcm2290: Add USB3 PHY")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bjorn Andersson <[email protected]>
Date:   Thu Jan 25 13:05:11 2024 -0800

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

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:05 2023 +0100

    arm64: dts: qcom: sc8180x: Add missing CPU off state
    
    [ Upstream commit 07b600dfdfea65d58dd80ea25becd8cff69bfafc ]
    
    The CPUs can be powered off without pulling the plug from the rest of
    the system. Describe the idle state responsible for this.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:07 2023 +0100

    arm64: dts: qcom: sc8180x: Don't hold MDP core clock at FMAX
    
    [ Upstream commit 309b5774f45aafd002efdb2656673542419abd6f ]
    
    There's an OPP table to handle this, drop the permanent vote.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:06 2023 +0100

    arm64: dts: qcom: sc8180x: Fix eDP PHY power-domains
    
    [ Upstream commit 24e98cb3d5e2c86565680e00008a794b4eac0040 ]
    
    The (e)DP PHYs are powered by the MX line, not through the MDSS GDSC.
    Fix that up.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:04 2023 +0100

    arm64: dts: qcom: sc8180x: Fix up big CPU idle state entry latency
    
    [ Upstream commit 266a3a92044b89c392b3e9cfcc328d4167c18294 ]
    
    The entry latency was oddly low.. Turns out somebody forgot about a
    second '1'! Fix it.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:03 2023 +0100

    arm64: dts: qcom: sc8180x: Hook up VDD_CX as GCC parent domain
    
    [ Upstream commit 3c58b96df110a80e78fa36ef928f1e6c375008e3 ]
    
    Most of GCC is powered by the CX rail. Describe that relationship to
    let the performance state requests trickle up the chain.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:08 2023 +0100

    arm64: dts: qcom: sc8180x: Require LOW_SVS vote for MMCX if DISPCC is on
    
    [ Upstream commit 6d9fb9e4c473cdfd2adca019b46d8e482105cae7 ]
    
    To ensure the PLLs are getting enough power, cast a vote with DISPCC so
    that MMCX is at least at LOW_SVS.
    
    Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Sat Dec 30 01:05:10 2023 +0100

    arm64: dts: qcom: sc8180x: Shrink aoss_qmp register space size
    
    [ Upstream commit dcad0590d1ea4278a55c30dd2903611a96111601 ]
    
    The AOSS_QMP region is overallocated, bleeding into space that's supposed
    to be used by other peripherals. Fix it.
    
    Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Jan 8 14:12:15 2024 +0100

    arm64: dts: qcom: sdm845-db845c: correct PCIe wake-gpios
    
    [ Upstream commit 584a327c5cffc36369b2a8953d9448826240f1ac ]
    
    Bindings allow a "wake", not "enable", GPIO.  Schematics also use WAKE
    name for the pin:
    
      sdm845-db845c.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected)
    
    Fixes: 4a657c264b78 ("arm64: dts: qcom: db845c: Enable PCIe controllers")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Heidelberg <[email protected]>
Date:   Fri Dec 29 21:02:33 2023 +0100

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

Author: Konrad Dybcio <[email protected]>
Date:   Wed Dec 20 15:15:11 2023 +0100

    arm64: dts: qcom: sdm845: Use the Low Power Island CX/MX for SLPI
    
    [ Upstream commit 5dd227ccfb9568935bdaf82bc1893b36457dd4d3 ]
    
    The SLPI is powered by the Low Power Island power rails. Fix the incorrect
    assignment.
    
    Fixes: 74588aada59a ("arm64: dts: qcom: sdm845: add SLPI remoteproc")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jan 17 16:04:27 2024 +0200

    arm64: dts: qcom: sm6115: declare VLS CLAMP register for USB3 PHY
    
    [ Upstream commit 95d739ed962c9aaa17d77b739606dbdf31879f6e ]
    
    The USB3 PHY on the SM6115 platform doesn't have built-in
    PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately
    via the register in the TCSR space. Declare corresponding register.
    
    Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Jan 8 14:12:16 2024 +0100

    arm64: dts: qcom: sm8150: correct PCIe wake-gpios
    
    [ Upstream commit 7c38989d0f7a35c83e7c4781271d42662903fa8d ]
    
    Bindings allow a "wake", not "enable", GPIO.  Schematics also use WAKE
    name for the pin:
    
      sa8155p-adp.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected)
    
    Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Nov 11 17:42:26 2023 +0100

    arm64: dts: qcom: sm8150: use 'gpios' suffix for PCI GPIOs
    
    [ Upstream commit af6f6778d34cb40e60368e288767f674cc0c5f60 ]
    
    Linux handles both versions, but bindings expect GPIO properties to
    have 'gpios' suffix instead of 'gpio':
    
      sa8155p-adp.dtb: pci@1c00000: Unevaluated properties are not allowed ('perst-gpio' was unexpected)
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Stable-dep-of: 7c38989d0f7a ("arm64: dts: qcom: sm8150: correct PCIe wake-gpios")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konrad Dybcio <[email protected]>
Date:   Tue Jan 16 13:25:44 2024 +0100

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

Author: Abel Vesa <[email protected]>
Date:   Wed Feb 21 15:04:25 2024 +0200

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Sun Feb 11 15:21:30 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 18 17:32:37 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Sun Feb 11 15:21:31 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Jan 15 14:33:18 2024 +0100

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

Author: Lad Prabhakar <[email protected]>
Date:   Mon Feb 5 14:44:20 2024 +0000

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

Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 18:35:25 2024 +0100

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

Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 17:46:56 2024 +0100

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

Author: Heiko Stuebner <[email protected]>
Date:   Tue Feb 27 18:35:26 2024 +0100

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

Author: Sebastian Reichel <[email protected]>
Date:   Wed Jan 17 20:14:48 2024 +0100

    arm64: dts: rockchip: mark system power controller on rk3588-evb1
    
    [ Upstream commit fc4657971be31ae679e2bbeee2fb8e93a7a063eb ]
    
    Mark the primary PMIC as system-power-controller, so that the
    system properly shuts down on poweroff.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Devarsh Thakkar <[email protected]>
Date:   Fri Feb 16 11:54:25 2024 +0530

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

Author: Devarsh Thakkar <[email protected]>
Date:   Fri Feb 16 11:54:24 2024 +0530

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

Author: Roger Quadros <[email protected]>
Date:   Thu Feb 8 15:51:43 2024 +0200

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

Author: Andrejs Cainikovs <[email protected]>
Date:   Fri Feb 9 14:02:12 2024 +0100

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

Author: Vaishnav Achath <[email protected]>
Date:   Sun Jan 21 19:10:17 2024 +0530

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

Author: Ravi Gunasekaran <[email protected]>
Date:   Thu Feb 1 18:13:53 2024 +0530

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

Author: Jai Luthra <[email protected]>
Date:   Tue Feb 20 11:48:02 2024 +0530

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

Author: Judith Mendez <[email protected]>
Date:   Tue Feb 13 17:56:56 2024 -0600

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

Author: Andrew Davis <[email protected]>
Date:   Fri Nov 17 10:33:39 2023 -0600

    arm64: dts: ti: k3-am64: Enable SDHCI nodes at the board level
    
    [ Upstream commit 3b6345e3fcf4c93a79f396121cd0e6f98f04da13 ]
    
    SDHCI nodes defined in the top-level AM64 SoC dtsi files are incomplete
    and will not be functional unless they are extended.
    
    As the attached SD/eMMC is only known about at the board integration level,
    these nodes should only be enabled when provided with this information.
    
    Disable the SDHCI nodes in the dtsi files and only enable the ones that
    are actually pinned out on a given board.
    
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Stable-dep-of: 379c7752bbd0 ("arm64: dts: ti: k3-am64-main: Fix ITAP/OTAP values for MMC")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jayesh Choudhary <[email protected]>
Date:   Thu Feb 1 19:53:08 2024 +0530

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

Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:43 2024 +0530

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

Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:44 2024 +0530

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

Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:45 2024 +0530

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

Author: Manorit Chawdhry <[email protected]>
Date:   Thu Feb 1 13:37:26 2024 +0530

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

Author: Bhavya Kapoor <[email protected]>
Date:   Wed Feb 14 16:28:46 2024 +0530

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

Author: Manorit Chawdhry <[email protected]>
Date:   Thu Feb 1 13:37:27 2024 +0530

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

Author: Stephen Boyd <[email protected]>
Date:   Thu Feb 22 22:40:29 2024 -0800

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

Author: Thierry Reding <[email protected]>
Date:   Fri Feb 2 11:08:12 2024 +0100

    arm64: tegra: Set the correct PHY mode for MGBE
    
    [ Upstream commit 4c892121d43bc2b45896ca207b54f39a8fa6b852 ]
    
    The PHY is configured in 10GBASE-R, so make sure to reflect that in DT.
    
    Reviewed-by: Jon Hunter <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Aug 30 17:03:04 2023 +0200

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

Author: Rob Herring <[email protected]>
Date:   Tue Feb 13 13:34:28 2024 -0600

    arm: dts: Fix dtc interrupt_map warnings
    
    [ Upstream commit f02b0f0dc26fbb77fe47b6e47cc5c211f0432c37 ]
    
    The dtc interrupt_map warning is off because its dependency,
    interrupt_provider, is off by default. Fix all the warnings so it can be
    enabled.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rob Herring <[email protected]>
Date:   Tue Feb 13 13:34:26 2024 -0600

    arm: dts: Fix dtc interrupt_provider warnings
    
    [ Upstream commit 96fd598e9c34cfa68402a4da3020c9236cfacf35 ]
    
    The dtc interrupt_provider warning is off by default. Fix all the warnings
    so it can be enabled.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Alexandre Torgue <[email protected]>
    Acked-by: Florian Fainelli <[email protected]> #Broadcom
    Acked-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michal Vokц║д█ <[email protected]>
Date:   Wed Feb 14 10:03:27 2024 +0100

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

Author: Michal Vokц║д█ <[email protected]>
Date:   Wed Feb 14 10:03:28 2024 +0100

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

Author: Craig Tatlor <[email protected]>
Date:   Sat Feb 10 17:45:40 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Jan 15 12:03:03 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Feb 14 15:57:42 2024 +0100

    ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodes
    
    [ Upstream commit 8c987693dc2d292d777f1be63cb35233049ae25e ]
    
    make dtbs_check W=2:
    
        arch/arm/boot/dts/renesas/r8a7790-lager.dts:444.11-458.5: Warning (interrupt_provider): /i2c-mux4/pmic@58: Missing '#interrupt-cells' in interrupt provider
        ...
    
    Fix this by adding the missing #interrupt-cells properties.
    
    Reported-by: Rob Herring <[email protected]>
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Link: https://lore.kernel.org/r/a351e503ea97fb1af68395843f513925ff1bdf26.1707922460.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

Author: Uwe Kleine-Kц╤nig <[email protected]>
Date:   Mon Jan 29 12:32:02 2024 +0100

    ARM: dts: rockchip: Drop interrupts property from pwm-rockchip nodes
    
    [ Upstream commit f98643d8daf3443e3b414a82d0cb3d745f8c8bbc ]
    
    The binding doesn't define interrupts and adding such a definition was
    refused because it's unclear how they should ever be used and the
    relevant registers are outside the PWM range. So drop them fixing
    several dtbs_check warnings like:
    
            arch/arm/boot/dts/rockchip/rv1108-elgin-r1.dtb: pwm@10280030: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
    
    Signed-off-by: Uwe Kleine-Kц╤nig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:21 2023 +0200

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

Author: Al Raj Hassain <[email protected]>
Date:   Mon Mar 4 16:09:23 2024 +0530

    ASoC: amd: yc: Add HP Pavilion Aero Laptop 13-be2xxx(8BD6) into DMI quirk table
    
    [ Upstream commit b3a51137607cee7c814cd3a75d96f78b9ee1dc1f ]
    
    The HP Pavilion Aero Laptop 13-be2xxx(8BD6) requires a quirk entry for its internal microphone to function.
    
    Signed-off-by: Al Raj Hassain <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johnny Hsieh <[email protected]>
Date:   Mon Feb 26 21:44:50 2024 +0800

    ASoC: amd: yc: Add Lenovo ThinkBook 21J0 into DMI quirk table
    
    [ Upstream commit 50ee641643dd0f46702e9a99354398196e1734c2 ]
    
    This patch adds Lenovo 21J0 (ThinkBook 16 G5+ ARP) to the DMI quirks table
    to enable internal microphone array.
    
    Cc: [email protected]
    Signed-off-by: Johnny Hsieh <[email protected]>
    Link: https://msgid.link/r/TYSPR04MB8429D62DFDB6727866ECF1DEC55A2@TYSPR04MB8429.apcprd04.prod.outlook.com
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiawei Wang <[email protected]>
Date:   Wed Feb 28 15:39:14 2024 +0800

    ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2
    
    [ Upstream commit ed00a6945dc32462c2d3744a3518d2316da66fcc ]
    
    Like many other models, the Lenovo 21J2 (ThinkBook 16 G5+ APO)
    needs a quirk entry for the internal microphone to function.
    
    Signed-off-by: Jiawei Wang <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Attila Tе▒kц╘s <[email protected]>
Date:   Sat Feb 10 21:36:38 2024 +0200

    ASoC: amd: yc: Fix non-functional mic on Lenovo 82UU
    
    [ Upstream commit f7fe85b229bc30cb5dc95b4e9015a601c9e3a8cd ]
    
    Like many other models, the Lenovo 82UU (Yoga Slim 7 Pro 14ARH7)
    needs a quirk entry for the internal microphone to function.
    
    Signed-off-by: Attila Tе▒kц╘s <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Charles Keepax <[email protected]>
Date:   Tue Feb 6 11:38:49 2024 +0000

    ASoC: cs42l43: Handle error from devm_pm_runtime_enable
    
    [ Upstream commit d1722057477a3786b8c0d60c28fc281f6ecf1cc3 ]
    
    As devm_pm_runtime_enable can fail due to memory allocations, it is
    best to handle the error.
    
    Signed-off-by: Charles Keepax <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alban Boyц╘ <[email protected]>
Date:   Wed Feb 28 19:28:41 2024 +0000

    ASoC: Intel: bytcr_rt5640: Add an extra entry for the Chuwi Vi8 tablet
    
    [ Upstream commit f8b0127aca8c60826e7354e504a12d4a46b1c3bb ]
    
    The bios version can differ depending if it is a dual-boot variant of the tablet.
    Therefore another DMI match is required.
    
    Signed-off-by: Alban Boyц╘ <[email protected]>
    Reviewed-by: Cezary Rojewski <[email protected]>
    Acked-by: Pierre-Louis Bossart <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jerome Brunet <[email protected]>
Date:   Tue Feb 13 22:58:03 2024 +0100

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

Author: Jerome Brunet <[email protected]>
Date:   Fri Feb 23 18:51:08 2024 +0100

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

Author: Jerome Brunet <[email protected]>
Date:   Fri Feb 23 18:51:07 2024 +0100

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

Author: Jerome Brunet <[email protected]>
Date:   Tue Feb 13 22:58:04 2024 +0100

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

Author: Luca Ceresoli <[email protected]>
Date:   Tue Mar 5 15:36:28 2024 +0100

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

Author: Hans de Goede <[email protected]>
Date:   Sun Feb 11 22:27:35 2024 +0100

    ASoC: rt5645: Make LattePanda board DMI match more precise
    
    [ Upstream commit 551539a8606e28cb2a130f8ef3e9834235b456c4 ]
    
    The DMI strings used for the LattePanda board DMI quirks are very generic.
    
    Using the dmidecode database from https://linux-hardware.org/ shows
    that the chosen DMI strings also match the following 2 laptops
    which also have a rt5645 codec:
    
    Insignia NS-P11W7100 https://linux-hardware.org/?computer=E092FFF8BA04
    Insignia NS-P10W8100 https://linux-hardware.org/?computer=AFB6C0BF7934
    
    All 4 hw revisions of the LattePanda board have "S70CR" in their BIOS
    version DMI strings:
    
    DF-BI-7-S70CR100-*
    DF-BI-7-S70CR110-*
    DF-BI-7-S70CR200-*
    LP-BS-7-S70CR700-*
    
    See e.g. https://linux-hardware.org/?computer=D98250A817C0
    
    Add a partial (non exact) DMI match on this string to make the LattePanda
    board DMI match more precise to avoid false-positive matches.
    
    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]>

Author: Lad Prabhakar <[email protected]>
Date:   Tue Jan 30 15:08:22 2024 +0000

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

Author: Dan Carpenter <[email protected]>
Date:   Fri Feb 9 16:02:16 2024 +0300

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

Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Dec 19 05:07:23 2023 +0200

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

Author: Peter Ujfalusi <[email protected]>
Date:   Tue Feb 13 13:52:33 2024 +0200

    ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend
    
    [ Upstream commit c40aad7c81e5fba34b70123ed7ce3397fa62a4d2 ]
    
    When the system is suspended while audio is active, the
    sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during
    suspend the DSP is turned off, streams will be re-started after resume.
    
    If the firmware crashes during while audio is running (or when we reset
    the stream before suspend) then the sof_ipc4_set_multi_pipeline_state()
    will fail with IPC error and the state change is interrupted.
    This will cause misalignment between the kernel and firmware state on next
    DSP boot resulting errors returned by firmware for IPC messages, eventually
    failing the audio resume.
    On stream close the errors are ignored so the kernel state will be
    corrected on the next DSP boot, so the second boot after the DSP panic.
    
    If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then
    state parameter is SOF_IPC4_PIPE_RESET and only in this case.
    
    Treat a forced pipeline reset similarly to how we treat a pcm_free by
    ignoring error on state sending to allow the kernel's state to be
    consistent with the state the firmware will have after the next boot.
    
    Link: https://github.com/thesofproject/sof/issues/8721
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Uwe Kleine-Kц╤nig <[email protected]>
Date:   Sun Mar 10 15:38:51 2024 +0100

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

Author: Stuart Henderson <[email protected]>
Date:   Wed Mar 6 16:14:36 2024 +0000

    ASoC: wm8962: Enable both SPKOUTR_ENA and SPKOUTL_ENA in mono mode
    
    [ Upstream commit 6fa849e4d78b880e878138bf238e4fd2bac3c4fa ]
    
    Signed-off-by: Stuart Henderson <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stuart Henderson <[email protected]>
Date:   Wed Mar 6 16:14:35 2024 +0000

    ASoC: wm8962: Enable oscillator if selecting WM8962_FLL_OSC
    
    [ Upstream commit 03c7874106ca5032a312626b927b1c35f07b1f35 ]
    
    Signed-off-by: Stuart Henderson <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Stuart Henderson <[email protected]>
Date:   Wed Mar 6 16:14:39 2024 +0000

    ASoC: wm8962: Fix up incorrect error message in wm8962_set_fll
    
    [ Upstream commit 96e202f8c52ac49452f83317cf3b34cd1ad81e18 ]
    
    Use source instead of ret, which seems to be unrelated and will always
    be zero.
    
    Signed-off-by: Stuart Henderson <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:24 2024 +0000

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

Author: Jianhua Lu <[email protected]>
Date:   Mon Jan 29 20:28:29 2024 +0800

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

Author: Luca Weiss <[email protected]>
Date:   Tue Feb 20 00:11:20 2024 +0100

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

Author: Luca Weiss <[email protected]>
Date:   Tue Feb 20 00:11:19 2024 +0100

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

Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:25 2024 +0000

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

Author: Daniel Thompson <[email protected]>
Date:   Tue Feb 20 15:35:26 2024 +0000

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

Author: Kent Overstreet <[email protected]>
Date:   Fri Dec 22 21:58:43 2023 -0500

    bcachefs: check for failure to downgrade
    
    commit 447c1c01051251853e851bd77f26546488cbc7b7 upstream.
    
    With the upcoming member seq patch, it's now critical that we don't ever
    write to a superblock that hasn't been version downgraded - failure to
    update member seq fields will cause split brain detection to fire
    erroniously.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Kent Overstreet <[email protected]>
Date:   Sat Feb 24 19:14:36 2024 -0500

    bcachefs: Fix BTREE_ITER_FILTER_SNAPSHOTS on inodes btree
    
    commit 204f45140faa0772d2ca1b3de96d1c0fb3db8e77 upstream.
    
    If we're in FILTER_SNAPSHOTS mode and we start scanning a range of the
    keyspace where no keys are visible in the current snapshot, we have a
    problem - we'll scan for a very long time before scanning terminates.
    
    Awhile back, this was fixed for most cases with peek_upto() (and
    assertions that enforce that it's being used).
    
    But the fix missed the fact that the inodes btree is different - every
    key offset is in a different snapshot tree, not just the inode field.
    
    Fixes:
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Helge Deller <[email protected]>
Date:   Sun Jan 28 09:53:55 2024 +0100

    bcachefs: Fix build on parisc by avoiding __multi3()
    
    commit eba38cc7578bef94865341c73608bdf49193a51d upstream.
    
    The gcc compiler on paric does support the __int128 type, although the
    architecture does not have native 128-bit support.
    
    The effect is, that the bcachefs u128_square() function will pull in the
    libgcc __multi3() helper, which breaks the kernel build when bcachefs is
    built as module since this function isn't currently exported in
    arch/parisc/kernel/parisc_ksyms.c.
    The build failure can be seen in the latest debian kernel build at:
    https://buildd.debian.org/status/fetch.php?pkg=linux&arch=hppa&ver=6.7.1-1%7Eexp1&stamp=1706132569&raw=0
    
    We prefer to not export that symbol, so fall back to the optional 64-bit
    implementation provided by bcachefs and thus avoid usage of __multi3().
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Kent Overstreet <[email protected]>
Date:   Fri Jan 5 19:04:42 2024 -0500

    bcachefs: fix simulateously upgrading & downgrading
    
    commit e7999235e6c437b99fad03d8301a4341be0d2bb5 upstream.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mathias Krause <[email protected]>
Date:   Sun Feb 4 08:51:52 2024 +0100

    bcachefs: install fd later to avoid race with close
    
    commit dd839f31d7cd5e04f4111a219024268c6f6973f0 upstream.
    
    Calling fd_install() makes a file reachable for userland, including the
    possibility to close the file descriptor, which leads to calling its
    'release' hook. If that happens before the code had a chance to bump the
    reference of the newly created task struct, the release callback will
    call put_task_struct() too early, leading to the premature destruction
    of the kernel thread.
    
    Avoid that race by calling fd_install() later, after all the setup is
    done.
    
    Fixes: 1c6fdbd8f246 ("bcachefs: Initial commit")
    Signed-off-by: Mathias Krause <[email protected]>
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Li Nan <[email protected]>
Date:   Wed Feb 21 17:01:22 2024 +0800

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

Author: Greg Joyce <[email protected]>
Date:   Fri Feb 16 15:04:17 2024 -0600

    block: sed-opal: handle empty atoms when parsing response
    
    [ Upstream commit 5429c8de56f6b2bd8f537df3a1e04e67b9c04282 ]
    
    The SED Opal response parsing function response_parse() does not
    handle the case of an empty atom in the response. This causes
    the entry count to be too high and the response fails to be
    parsed. Recognizing, but ignoring, empty atoms allows response
    handling to succeed.
    
    Signed-off-by: Greg Joyce <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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

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

Author: Andrey Skvortsov <[email protected]>
Date:   Sat Feb 24 00:37:04 2024 +0300

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 11:17:24 2024 -0500

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

Author: Frц╘dц╘ric Danis <[email protected]>
Date:   Thu Mar 7 17:42:05 2024 +0100

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

Author: Pauli Virtanen <[email protected]>
Date:   Sat Mar 2 19:06:23 2024 +0200

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Tue Jan 9 13:45:40 2024 -0500

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 10:49:26 2024 -0500

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Jan 31 11:24:19 2024 -0500

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

Author: Andrey Skvortsov <[email protected]>
Date:   Sat Feb 24 00:37:03 2024 +0300

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

Author: Bartosz Golaszewski <[email protected]>
Date:   Thu Feb 8 17:40:17 2024 +0100

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Feb 16 16:20:11 2024 -0500

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

Author: Frц╘dц╘ric Danis <[email protected]>
Date:   Mon Jan 22 17:59:55 2024 +0100

    Bluetooth: mgmt: Fix limited discoverable off timeout
    
    [ Upstream commit 0bd1fb586235224048c726922db048d1bce6354a ]
    
    LIMITED_DISCOVERABLE flag is not reset from Class of Device and
    advertisement on limited discoverable timeout. This prevents to pass PTS
    test GAP/DISC/LIMM/BV-02-C
    
    Calling set_discoverable_sync as when the limited discovery is set
    correctly update the Class of Device and advertisement.
    
    Signed-off-by: Frц╘dц╘ric Danis <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonas Dreц÷ler <[email protected]>
Date:   Sun Jan 7 19:02:48 2024 +0100

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

Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Feb 28 10:56:49 2024 -0500

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

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

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

Author: Jonas Dreц÷ler <[email protected]>
Date:   Sun Jan 7 19:02:47 2024 +0100

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

Author: Jonas Dreц÷ler <[email protected]>
Date:   Mon Jan 8 23:46:06 2024 +0100

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

Author: Yuxuan Hu <[email protected]>
Date:   Wed Jan 3 17:10:43 2024 +0800

    Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
    
    [ Upstream commit 2535b848fa0f42ddff3e5255cf5e742c9b77bb26 ]
    
    During our fuzz testing of the connection and disconnection process at the
    RFCOMM layer, we discovered this bug. By comparing the packets from a
    normal connection and disconnection process with the testcase that
    triggered a KASAN report. We analyzed the cause of this bug as follows:
    
    1. In the packets captured during a normal connection, the host sends a
    `Read Encryption Key Size` type of `HCI_CMD` packet
    (Command Opcode: 0x1408) to the controller to inquire the length of
    encryption key.After receiving this packet, the controller immediately
    replies with a Command Completepacket (Event Code: 0x0e) to return the
    Encryption Key Size.
    
    2. In our fuzz test case, the timing of the controller's response to this
    packet was delayed to an unexpected point: after the RFCOMM and L2CAP
    layers had disconnected but before the HCI layer had disconnected.
    
    3. After receiving the Encryption Key Size Response at the time described
    in point 2, the host still called the rfcomm_check_security function.
    However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`
    had already been released, and when the function executed
    `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,
    specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.
    
    To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling
    rfcomm_recv_frame in rfcomm_process_rx.
    
    Signed-off-by: Yuxuan Hu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Toke Hц╦iland-Jц╦rgensen <[email protected]>
Date:   Thu Mar 7 13:03:35 2024 +0100

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

Author: Toke Hц╦iland-Jц╦rgensen <[email protected]>
Date:   Thu Mar 7 13:03:36 2024 +0100

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

Author: Toke Hц╦iland-Jц╦rgensen <[email protected]>
Date:   Thu Mar 7 13:03:37 2024 +0100

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

Author: Hari Bathini <[email protected]>
Date:   Thu Feb 8 15:31:15 2024 +0530

    bpf: Fix warning for bpf_cpumask in verifier
    
    [ Upstream commit 11f522256e9043b0fcd2f994278645d3e201d20c ]
    
    Compiling with CONFIG_BPF_SYSCALL & !CONFIG_BPF_JIT throws the below
    warning:
    
      "WARN: resolve_btfids: unresolved symbol bpf_cpumask"
    
    Fix it by adding the appropriate #ifdef.
    
    Signed-off-by: Hari Bathini <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Stanislav Fomichev <[email protected]>
    Acked-by: David Vernet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Puranjay Mohan <[email protected]>
Date:   Mon Mar 11 12:27:22 2024 +0000

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

Author: Yonghong Song <[email protected]>
Date:   Tue Feb 6 23:01:02 2024 -0800

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

Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:40 2024 -0700

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

Author: Tiezhu Yang <[email protected]>
Date:   Tue Jan 16 14:19:20 2024 +0800

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

Author: Filipe Manana <[email protected]>
Date:   Mon Feb 19 20:10:07 2024 +0000

    btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve
    
    [ Upstream commit c7bb26b847e5b97814f522686068c5628e2b3646 ]
    
    At btrfs_use_block_rsv() we read the size of a block reserve without
    locking its spinlock, which makes KCSAN complain because the size of a
    block reserve is always updated while holding its spinlock. The report
    from KCSAN is the following:
    
      [653.313148] BUG: KCSAN: data-race in btrfs_update_delayed_refs_rsv [btrfs] / btrfs_use_block_rsv [btrfs]
    
      [653.314755] read to 0x000000017f5871b8 of 8 bytes by task 7519 on cpu 0:
      [653.314779]  btrfs_use_block_rsv+0xe4/0x2f8 [btrfs]
      [653.315606]  btrfs_alloc_tree_block+0xdc/0x998 [btrfs]
      [653.316421]  btrfs_force_cow_block+0x220/0xe38 [btrfs]
      [653.317242]  btrfs_cow_block+0x1ac/0x568 [btrfs]
      [653.318060]  btrfs_search_slot+0xda2/0x19b8 [btrfs]
      [653.318879]  btrfs_del_csums+0x1dc/0x798 [btrfs]
      [653.319702]  __btrfs_free_extent.isra.0+0xc24/0x2028 [btrfs]
      [653.320538]  __btrfs_run_delayed_refs+0xd3c/0x2390 [btrfs]
      [653.321340]  btrfs_run_delayed_refs+0xae/0x290 [btrfs]
      [653.322140]  flush_space+0x5e4/0x718 [btrfs]
      [653.322958]  btrfs_preempt_reclaim_metadata_space+0x102/0x2f8 [btrfs]
      [653.323781]  process_one_work+0x3b6/0x838
      [653.323800]  worker_thread+0x75e/0xb10
      [653.323817]  kthread+0x21a/0x230
      [653.323836]  __ret_from_fork+0x6c/0xb8
      [653.323855]  ret_from_fork+0xa/0x30
    
      [653.323887] write to 0x000000017f5871b8 of 8 bytes by task 576 on cpu 3:
      [653.323906]  btrfs_update_delayed_refs_rsv+0x1a4/0x250 [btrfs]
      [653.324699]  btrfs_add_delayed_data_ref+0x468/0x6d8 [btrfs]
      [653.325494]  btrfs_free_extent+0x76/0x120 [btrfs]
      [653.326280]  __btrfs_mod_ref+0x6a8/0x6b8 [btrfs]
      [653.327064]  btrfs_dec_ref+0x50/0x70 [btrfs]
      [653.327849]  walk_up_proc+0x236/0xa50 [btrfs]
      [653.328633]  walk_up_tree+0x21c/0x448 [btrfs]
      [653.329418]  btrfs_drop_snapshot+0x802/0x1328 [btrfs]
      [653.330205]  btrfs_clean_one_deleted_snapshot+0x184/0x238 [btrfs]
      [653.330995]  cleaner_kthread+0x2b0/0x2f0 [btrfs]
      [653.331781]  kthread+0x21a/0x230
      [653.331800]  __ret_from_fork+0x6c/0xb8
      [653.331818]  ret_from_fork+0xa/0x30
    
    So add a helper to get the size of a block reserve while holding the lock.
    Reading the field while holding the lock instead of using the data_race()
    annotation is used in order to prevent load tearing.
    
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Filipe Manana <[email protected]>
Date:   Mon Feb 19 19:41:23 2024 +0000

    btrfs: fix data races when accessing the reserved amount of block reserves
    
    [ Upstream commit e06cc89475eddc1f3a7a4d471524256152c68166 ]
    
    At space_info.c we have several places where we access the ->reserved
    field of a block reserve without taking the block reserve's spinlock
    first, which makes KCSAN warn about a data race since that field is
    always updated while holding the spinlock.
    
    The reports from KCSAN are like the following:
    
      [117.193526] BUG: KCSAN: data-race in btrfs_block_rsv_release [btrfs] / need_preemptive_reclaim [btrfs]
    
      [117.195148] read to 0x000000017f587190 of 8 bytes by task 6303 on cpu 3:
      [117.195172]  need_preemptive_reclaim+0x222/0x2f0 [btrfs]
      [117.195992]  __reserve_bytes+0xbb0/0xdc8 [btrfs]
      [117.196807]  btrfs_reserve_metadata_bytes+0x4c/0x120 [btrfs]
      [117.197620]  btrfs_block_rsv_add+0x78/0xa8 [btrfs]
      [117.198434]  btrfs_delayed_update_inode+0x154/0x368 [btrfs]
      [117.199300]  btrfs_update_inode+0x108/0x1c8 [btrfs]
      [117.200122]  btrfs_dirty_inode+0xb4/0x140 [btrfs]
      [117.200937]  btrfs_update_time+0x8c/0xb0 [btrfs]
      [117.201754]  touch_atime+0x16c/0x1e0
      [117.201789]  filemap_read+0x674/0x728
      [117.201823]  btrfs_file_read_iter+0xf8/0x410 [btrfs]
      [117.202653]  vfs_read+0x2b6/0x498
      [117.203454]  ksys_read+0xa2/0x150
      [117.203473]  __s390x_sys_read+0x68/0x88
      [117.203495]  do_syscall+0x1c6/0x210
      [117.203517]  __do_syscall+0xc8/0xf0
      [117.203539]  system_call+0x70/0x98
    
      [117.203579] write to 0x000000017f587190 of 8 bytes by task 11 on cpu 0:
      [117.203604]  btrfs_block_rsv_release+0x2e8/0x578 [btrfs]
      [117.204432]  btrfs_delayed_inode_release_metadata+0x7c/0x1d0 [btrfs]
      [117.205259]  __btrfs_update_delayed_inode+0x37c/0x5e0 [btrfs]
      [117.206093]  btrfs_async_run_delayed_root+0x356/0x498 [btrfs]
      [117.206917]  btrfs_work_helper+0x160/0x7a0 [btrfs]
      [117.207738]  process_one_work+0x3b6/0x838
      [117.207768]  worker_thread+0x75e/0xb10
      [117.207797]  kthread+0x21a/0x230
      [117.207830]  __ret_from_fork+0x6c/0xb8
      [117.207861]  ret_from_fork+0xa/0x30
    
    So add a helper to get the reserved amount of a block reserve while
    holding the lock. The value may be not be up to date anymore when used by
    need_preemptive_reclaim() and btrfs_preempt_reclaim_metadata_space(), but
    that's ok since the worst it can do is cause more reclaim work do be done
    sooner rather than later. Reading the field while holding the lock instead
    of using the data_race() annotation is used in order to prevent load
    tearing.
    
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Thumshirn <[email protected]>
Date:   Mon Feb 12 11:59:52 2024 +0100

    btrfs: zoned: don't skip block group profile checks on conventional zones
    
    [ Upstream commit 5906333cc4af7b3fdb8cfff1cb3e8e579bd13174 ]
    
    On a zoned filesystem with conventional zones, we're skipping the block
    group profile checks for the conventional zones.
    
    This allows converting a zoned filesystem's data block groups to RAID when
    all of the zones backing the chunk are on conventional zones.  But this
    will lead to problems, once we're trying to allocate chunks backed by
    sequential zones.
    
    So also check for conventional zones when loading a block group's profile
    on them.
    
    Reported-by: HAN Yuwei <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/#t
    Reviewed-by: Boris Burkov <[email protected]>
    Reviewed-by: Naohiro Aota <[email protected]>
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dan Carpenter <[email protected]>
Date:   Wed Feb 21 09:20:19 2024 +0300

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

Author: Peter Robinson <[email protected]>
Date:   Fri Feb 16 10:02:37 2024 +0000

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

Author: Markus Schneider-Pargmann <[email protected]>
Date:   Wed Feb 7 10:32:07 2024 +0100

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

Author: Xiubo Li <[email protected]>
Date:   Thu Sep 14 10:29:16 2023 +0800

    ceph: add ceph_cap_unlink_work to fire check_caps() immediately
    
    [ Upstream commit dbc347ef7f0c53aa4a5383238a804d7ebbb0b5ca ]
    
    When unlinking a file the check caps could be delayed for more than
    5 seconds, but in MDS side it maybe waiting for the clients to
    release caps.
    
    This will use the cap_wq work queue and a dedicated list to help
    fire the check_caps() and dirty buffer flushing immediately.
    
    Link: https://tracker.ceph.com/issues/50223
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Milind Changire <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiubo Li <[email protected]>
Date:   Wed Sep 13 16:18:34 2023 +0800

    ceph: always queue a writeback when revoking the Fb caps
    
    [ Upstream commit 902d6d013f75b68f31d208c6f3ff9cdca82648a7 ]
    
    In case there is 'Fw' dirty caps and 'CHECK_CAPS_FLUSH' is set we
    will always ignore queue a writeback. Queue a writeback is very
    important because it will block kclient flushing the snapcaps to
    MDS and which will block MDS waiting for revoking the 'Fb' caps.
    
    Link: https://tracker.ceph.com/issues/50223
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Milind Changire <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xiubo Li <[email protected]>
Date:   Wed Feb 21 09:16:12 2024 +0800

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

Author: Dan Carpenter <[email protected]>
Date:   Tue Feb 20 12:02:31 2024 +0300

    char: xilinx_hwicap: Fix NULL vs IS_ERR() bug
    
    [ Upstream commit 316459ba4051fd91237171fdca88920128a646f1 ]
    
    The devm_platform_ioremap_resource() function returns error pointers.
    It never returns NULL.  Update the check accordingly.
    
    Fixes: 672371832193 ("char: xilinx_hwicap: Modernize driver probe")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Howells <[email protected]>
Date:   Tue Jan 9 17:54:35 2024 +0000

    cifs: Don't use certain unnecessary folio_*() functions
    
    [ Upstream commit c40497d82387188f14d9adc4caa58ee1cb1999e1 ]
    
    Filesystems should use folio->index and folio->mapping, instead of
    folio_index(folio), folio_mapping() and folio_file_mapping() since
    they know that it's in the pagecache.
    
    Change this automagically with:
    
    perl -p -i -e 's/folio_mapping[(]([^)]*)[)]/\1->mapping/g' fs/smb/client/*.c
    perl -p -i -e 's/folio_file_mapping[(]([^)]*)[)]/\1->mapping/g' fs/smb/client/*.c
    perl -p -i -e 's/folio_index[(]([^)]*)[)]/\1->index/g' fs/smb/client/*.c
    
    Reported-by: Matthew Wilcox <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    cc: Jeff Layton <[email protected]>
    cc: Steve French <[email protected]>
    cc: Paulo Alcantara <[email protected]>
    cc: Ronnie Sahlberg <[email protected]>
    cc: Shyam Prasad N <[email protected]>
    cc: Tom Talpey <[email protected]>
    cc: [email protected]
    cc: [email protected]
    Stable-dep-of: f3dc1bdb6b0b ("cifs: Fix writeback data corruption")
    Signed-off-by: Sasha Levin <[email protected]>

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

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

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

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

Author: Christophe JAILLET <[email protected]>
Date:   Wed Jan 10 19:58:21 2024 +0100

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

Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 21 16:16:24 2024 +0100

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

Author: Shengjiu Wang <[email protected]>
Date:   Fri Feb 23 18:15:51 2024 +0800

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

Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 7 09:29:28 2024 +0100

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

Author: Daniel Golle <[email protected]>
Date:   Sun Feb 18 03:11:15 2024 +0000

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

Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 7 09:12:17 2024 +0100

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

Author: Chen-Yu Tsai <[email protected]>
Date:   Mon Feb 19 18:51:24 2024 +0800

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

Author: Igor Prusov <[email protected]>
Date:   Fri Feb 2 17:25:48 2024 +0300

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

Author: Konrad Dybcio <[email protected]>
Date:   Wed Jan 3 21:20:18 2024 +0100

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

Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:54 2024 +0100

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

Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:55 2024 +0100

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

Author: Gabor Juhos <[email protected]>
Date:   Sun Feb 25 18:32:56 2024 +0100

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

Author: Konrad Dybcio <[email protected]>
Date:   Tue Feb 6 19:43:35 2024 +0100

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

Author: Konrad Dybcio <[email protected]>
Date:   Tue Feb 6 19:43:36 2024 +0100

    clk: qcom: reset: Ensure write completion on reset de/assertion
    
    [ Upstream commit 2f8cf2c3f3e3f7ef61bd19abb4b0bb797ad50aaf ]
    
    Trying to toggle the resets in a rapid fashion can lead to the changes
    not actually arriving at the clock controller block when we expect them
    to. This was observed at least on SM8250.
    
    Read back the value after regmap_update_bits to ensure write completion.
    
    Fixes: b36ba30c8ac6 ("clk: qcom: Add reset controller support")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 25 16:45:13 2024 +0100

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

Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 25 16:43:26 2024 +0100

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

Author: Claudiu Beznea <[email protected]>
Date:   Wed Jan 31 12:29:29 2024 +0200

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

Author: Sam Protsenko <[email protected]>
Date:   Wed Jan 24 19:38:56 2024 -0600

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

Author: Duoming Zhou <[email protected]>
Date:   Fri Mar 1 16:44:37 2024 +0800

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

Author: Frej Drejhammar <[email protected]>
Date:   Sun Feb 11 18:58:22 2024 +0100

    comedi: comedi_8255: Correct error in subdevice initialization
    
    commit cfa9ba1ae0bef0681833a22d326174fe633caab5 upstream.
    
    The refactoring done in commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework
    subdevice initialization functions") to the initialization of the io
    field of struct subdev_8255_private broke all cards using the
    drivers/comedi/drivers/comedi_8255.c module.
    
    Prior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field
    in the newly allocated struct subdev_8255_private to the non-NULL
    callback given to the function, otherwise it used a flag parameter to
    select between subdev_8255_mmio and subdev_8255_io. The refactoring
    removed that logic and the flag, as subdev_8255_mm_init() and
    subdev_8255_io_init() now explicitly pass subdev_8255_mmio and
    subdev_8255_io respectively to __subdev_8255_init(), only
    __subdev_8255_init() never sets spriv->io to the supplied
    callback. That spriv->io is NULL leads to a later BUG:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 0 P4D 0
    Oops: 0010 [#1] SMP PTI
    CPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1
    Hardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    RIP: 0010:0x0
    Code: Unable to access opcode bytes at 0xffffffffffffffd6.
    RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b
    RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00
    RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001
    R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000
    R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8
    FS:  00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0
    Call Trace:
     <TASK>
     ? __die_body+0x15/0x57
     ? page_fault_oops+0x2ef/0x33c
     ? insert_vmap_area.constprop.0+0xb6/0xd5
     ? alloc_vmap_area+0x529/0x5ee
     ? exc_page_fault+0x15a/0x489
     ? asm_exc_page_fault+0x22/0x30
     __subdev_8255_init+0x79/0x8d [comedi_8255]
     pci_8255_auto_attach+0x11a/0x139 [8255_pci]
     comedi_auto_config+0xac/0x117 [comedi]
     ? __pfx___driver_attach+0x10/0x10
     pci_device_probe+0x88/0xf9
     really_probe+0x101/0x248
     __driver_probe_device+0xbb/0xed
     driver_probe_device+0x1a/0x72
     __driver_attach+0xd4/0xed
     bus_for_each_dev+0x76/0xb8
     bus_add_driver+0xbe/0x1be
     driver_register+0x9a/0xd8
     comedi_pci_driver_register+0x28/0x48 [comedi_pci]
     ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci]
     do_one_initcall+0x72/0x183
     do_init_module+0x5b/0x1e8
     init_module_from_file+0x86/0xac
     __do_sys_finit_module+0x151/0x218
     do_syscall_64+0x72/0xdb
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    RIP: 0033:0x7f72f50a0cb9
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 71 0c 00 f7 d8 64 89 01 48
    RSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9
    RDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e
    RBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000
    R10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df
    R13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8
     </TASK>
    Modules linked in: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid
    CR2: 0000000000000000
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:0x0
    Code: Unable to access opcode bytes at 0xffffffffffffffd6.
    RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b
    RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00
    RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001
    R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000
    R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8
    FS:  00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0
    
    This patch simply corrects the above mistake by initializing spriv->io
    to the given io callback.
    
    Fixes: 5c57b1ccecc7 ("comedi: comedi_8255: Rework subdevice initialization functions")
    Signed-off-by: Frej Drejhammar <[email protected]>
    Cc: [email protected]
    Acked-by: Ian Abbott <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ian Abbott <[email protected]>
Date:   Wed Feb 14 10:07:25 2024 +0000

    comedi: comedi_test: Prevent timers rescheduling during deletion
    
    commit f53641a6e849034a44bf80f50245a75d7a376025 upstream.
    
    The comedi_test devices have a couple of timers (ai_timer and ao_timer)
    that can be started to simulate hardware interrupts.  Their expiry
    functions normally reschedule the timer.  The driver code calls either
    del_timer_sync() or del_timer() to delete the timers from the queue, but
    does not currently prevent the timers from rescheduling themselves so
    synchronized deletion may be ineffective.
    
    Add a couple of boolean members (one for each timer: ai_timer_enable and
    ao_timer_enable) to the device private data structure to indicate
    whether the timers are allowed to reschedule themselves.  Set the member
    to true when adding the timer to the queue, and to false when deleting
    the timer from the queue in the waveform_ai_cancel() and
    waveform_ao_cancel() functions.
    
    The del_timer_sync() function is also called from the waveform_detach()
    function, but the timer enable members will already be set to false when
    that function is called, so no change is needed there.
    
    Fixes: 403fe7f34e33 ("staging: comedi: comedi_test: fix timer race conditions")
    Cc: [email protected] # 4.4+
    Signed-off-by: Ian Abbott <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mao Jinlong <[email protected]>
Date:   Wed Jan 31 02:54:19 2024 -0800

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

Author: James Clark <[email protected]>
Date:   Mon Jan 29 15:40:32 2024 +0000

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

Author: Anastasia Belova <[email protected]>
Date:   Wed Jan 17 10:12:20 2024 +0300

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

Author: Sibi Sankar <[email protected]>
Date:   Tue Mar 12 16:07:23 2024 +0530

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Wed Jan 24 17:31:43 2024 -0300

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

Author: Nц╜colas F. R. A. Prado <[email protected]>
Date:   Wed Jan 10 11:23:02 2024 -0300

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

Author: Arnd Bergmann <[email protected]>
Date:   Thu Feb 15 09:33:14 2024 +0100

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

Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 14:49:46 2024 +0100

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

Author: Mario Limonciello <[email protected]>
Date:   Tue Feb 13 11:34:28 2024 -0600

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

Author: Randy Dunlap <[email protected]>
Date:   Sat Feb 17 08:55:13 2024 -0800

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

Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:57 2024 +0000

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

Author: Damian Muszynski <[email protected]>
Date:   Fri Feb 16 18:21:54 2024 +0100

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

Author: Jie Wang <[email protected]>
Date:   Fri Dec 15 05:01:44 2023 -0500

    crypto: qat - relocate and rename get_service_enabled()
    
    [ Upstream commit 4db87a5f9e3026d72e03bbdf1dac1dc5303e37f7 ]
    
    Move the function get_service_enabled() from adf_4xxx_hw_data.c to
    adf_cfg_services.c and rename it as adf_get_service_enabled().
    This function is not specific to the 4xxx and will be used by
    other QAT drivers.
    
    This does not introduce any functional change.
    
    Signed-off-by: Jie Wang <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: df018f82002a ("crypto: qat - fix ring to service map for dcc in 4xxx")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:58 2024 +0000

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

Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:55 2024 +0000

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

Author: Adam Guerin <[email protected]>
Date:   Fri Feb 16 15:19:56 2024 +0000

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

Author: Quanyang Wang <[email protected]>
Date:   Sun Jan 28 12:29:06 2024 +0800

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

Author: Alison Schofield <[email protected]>
Date:   Wed Jan 31 13:59:31 2024 -0800

    cxl/region: Allow out of order assembly of autodiscovered regions
    
    [ Upstream commit cb66b1d60c283bb340a2fc19deff7de8acea74b1 ]
    
    Autodiscovered regions can fail to assemble if they are not discovered
    in HPA decode order. The user will see failure messages like:
    
    [] cxl region0: endpoint5: HPA order violation region1
    [] cxl region0: endpoint5: failed to allocate region reference
    
    The check that is causing the failure helps the CXL driver enforce
    a CXL spec mandate that decoders be committed in HPA order. The
    check is needless for autodiscovered regions since their decoders
    are already programmed. Trying to enforce order in the assembly of
    these regions is useless because they are assembled once all their
    member endpoints arrive, and there is no guarantee on the order in
    which endpoints are discovered during probe.
    
    Keep the existing check, but for autodiscovered regions, allow the
    out of order assembly after a sanity check that the lesser numbered
    decoder has the lesser HPA starting address.
    
    Signed-off-by: Alison Schofield <[email protected]>
    Tested-by: Wonjae Lee <[email protected]>
    Link: https://lore.kernel.org/r/3dec69ee97524ab229a20c6739272c3000b18408.1706736863.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alison Schofield <[email protected]>
Date:   Wed Jan 31 13:59:30 2024 -0800

    cxl/region: Handle endpoint decoders in cxl_region_find_decoder()
    
    [ Upstream commit 453a7fde8031a5192ed2f9646ad048c1a5e930dc ]
    
    In preparation for adding a new caller of cxl_region_find_decoders()
    teach it to find a decoder from a cxl_endpoint_decoder structure.
    
    Combining switch and endpoint decoder lookup in one function prevents
    code duplication in call sites.
    
    Update the existing caller.
    
    Signed-off-by: Alison Schofield <[email protected]>
    Tested-by: Wonjae Lee <[email protected]>
    Link: https://lore.kernel.org/r/79ae6d72978ef9f3ceec9722e1cb793820553c8e.1706736863.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Wed Nov 15 13:17:11 2023 +0100

    devlink: Acquire device lock during netns dismantle
    
    [ Upstream commit e21c52d7814f5768f05224e773644629fe124af2 ]
    
    Device drivers register with devlink from their probe routines (under
    the device lock) by acquiring the devlink instance lock and calling
    devl_register().
    
    Drivers that support a devlink reload usually implement the
    reload_{down, up}() operations in a similar fashion to their remove and
    probe routines, respectively.
    
    However, while the remove and probe routines are invoked with the device
    lock held, the reload operations are only invoked with the devlink
    instance lock held. It is therefore impossible for drivers to acquire
    the device lock from their reload operations, as this would result in
    lock inversion.
    
    The motivating use case for invoking the reload operations with the
    device lock held is in mlxsw which needs to trigger a PCI reset as part
    of the reload. The driver cannot call pci_reset_function() as this
    function acquires the device lock. Instead, it needs to call
    __pci_reset_function_locked which expects the device lock to be held.
    
    To that end, adjust devlink to always acquire the device lock before the
    devlink instance lock when performing a reload.
    
    For now, only do that when reload is triggered as part of netns
    dismantle. Subsequent patches will handle the case where reload is
    explicitly triggered by user space.
    
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Wed Nov 15 13:17:13 2023 +0100

    devlink: Allow taking device lock in pre_doit operations
    
    [ Upstream commit d32c38256db30a2d55b849e2c77342bc70d58c6e ]
    
    Introduce a new private flag ('DEVLINK_NL_FLAG_NEED_DEV_LOCK') to allow
    netlink commands to specify that they need to acquire the device lock in
    their pre_doit operation and release it in their post_doit operation.
    
    The reload command will use this flag in the subsequent patch.
    
    No functional changes intended.
    
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Wed Nov 15 13:17:12 2023 +0100

    devlink: Enable the use of private flags in post_doit operations
    
    [ Upstream commit c8d0a7d6152bec970552786b77626f4b4c562f4d ]
    
    Currently, private flags (e.g., 'DEVLINK_NL_FLAG_NEED_PORT') are only
    used in pre_doit operations, but a subsequent patch will need to
    conditionally lock and unlock the device lock in pre and post doit
    operations, respectively.
    
    As a preparation, enable the use of private flags in post_doit
    operations in a similar fashion to how it is done for pre_doit
    operations.
    
    No functional changes intended.
    
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shay Drory <[email protected]>
Date:   Tue Mar 12 12:52:38 2024 +0200

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

Author: William Tu <[email protected]>
Date:   Sun Mar 10 18:45:47 2024 +0200

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

Author: Jiri Pirko <[email protected]>
Date:   Mon Mar 18 10:19:08 2024 +0100

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

Author: Ido Schimmel <[email protected]>
Date:   Wed Nov 15 13:17:10 2023 +0100

    devlink: Move private netlink flags to C file
    
    [ Upstream commit 526dd6d7877b80b1f56d87156b65b8227c69d59f ]
    
    The flags are not used outside of the C file so move them there.
    
    Suggested-by: Jiri Pirko <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d7d75124965a ("devlink: Fix devlink parallel commands processing")
    Signed-off-by: Sasha Levin <[email protected]>

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

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

Author: Ming Lei <[email protected]>
Date:   Mon Mar 11 13:42:55 2024 -0400

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

Author: Mikulas Patocka <[email protected]>
Date:   Thu Mar 21 17:48:45 2024 +0100

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

Author: Mikulas Patocka <[email protected]>
Date:   Mon Mar 18 18:35:06 2024 +0100

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

Author: Mikulas Patocka <[email protected]>
Date:   Tue Feb 20 19:11:51 2024 +0100

    dm-verity, dm-crypt: align "struct bvec_iter" correctly
    
    [ Upstream commit 787f1b2800464aa277236a66eb3c279535edd460 ]
    
    "struct bvec_iter" is defined with the __packed attribute, so it is
    aligned on a single byte. On X86 (and on other architectures that support
    unaligned addresses in hardware), "struct bvec_iter" is accessed using the
    8-byte and 4-byte memory instructions, however these instructions are less
    efficient if they operate on unaligned addresses.
    
    (on RISC machines that don't have unaligned access in hardware, GCC
    generates byte-by-byte accesses that are very inefficient - see [1])
    
    This commit reorders the entries in "struct dm_verity_io" and "struct
    convert_context", so that "struct bvec_iter" is aligned on 8 bytes.
    
    [1] https://lore.kernel.org/all/ZcLuWUNRZadJr0tQ@fedora/T/
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mikulas Patocka <[email protected]>
Date:   Mon Mar 11 15:06:39 2024 +0100

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

Author: Peter Robinson <[email protected]>
Date:   Fri Jan 12 09:32:56 2024 +0000

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

Author: Nikita Zhandarovich <[email protected]>
Date:   Fri Jan 19 07:39:06 2024 -0800

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

Author: Jiri Pirko <[email protected]>
Date:   Wed Mar 6 16:12:40 2024 +0100

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

Author: Jiri Pirko <[email protected]>
Date:   Wed Mar 6 13:07:39 2024 +0100

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

Author: Randy Dunlap <[email protected]>
Date:   Wed Feb 7 08:13:22 2024 -0800

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

Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Feb 15 18:38:16 2024 +0530

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

Author: Srinivasan Shanmugam <[email protected]>
Date:   Tue Jan 23 20:18:07 2024 +0530

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

Author: Swapnil Patel <[email protected]>
Date:   Tue Feb 6 11:40:20 2024 -0500

    drm/amd/display: fix input states translation error for dcn35 & dcn351
    
    [ Upstream commit 27a6c49394b1a203beeb94752c9a1d6318f24ddf ]
    
    [Why]
    Currently there is an error while translating input clock sates into
    output clock states. The highest fclk setting from output sates is
    being dropped because of this error.
    
    [How]
    For dcn35 and dcn351, make output_states equal to input states.
    
    Reviewed-by: Charlene Liu <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Swapnil Patel <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Feb 6 08:50:56 2024 -0800

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

Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Jan 25 21:16:04 2024 +0530

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

Author: Asad Kamal <[email protected]>
Date:   Wed Feb 28 12:24:15 2024 +0800

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

Author: Yifan Zhang <[email protected]>
Date:   Thu Jan 4 10:39:48 2024 +0800

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

Author: Le Ma <[email protected]>
Date:   Fri Mar 15 16:55:39 2024 +0800

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

Author: Prike Liang <[email protected]>
Date:   Thu Feb 22 20:56:59 2024 +0800

    drm/amdgpu: Enable gpu reset for S3 abort cases on Raven series
    
    [ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
    
    Currently, GPU resets can now be performed successfully on the Raven
    series. While GPU reset is required for the S3 suspend abort case.
    So now can enable gpu reset for S3 abort cases on the Raven series.
    
    Signed-off-by: Prike Liang <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Srinivasan Shanmugam <[email protected]>
Date:   Sat Feb 24 07:48:52 2024 +0530

    drm/amdgpu: Fix missing break in ATOM_ARG_IMM Case of atom_get_src_int()
    
    [ Upstream commit 7cf1ad2fe10634238b38442a851d89514cb14ea2 ]
    
    Missing break statement in the ATOM_ARG_IMM case of a switch statement,
    adds the missing break statement, ensuring that the program's control
    flow is as intended.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/atom.c:323 atom_get_src_int() warn: ignoring unreachable code.
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Cc: Jammy Zhou <[email protected]>
    Cc: Christian Kц╤nig <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Lang Yu <[email protected]>
Date:   Wed Mar 6 12:42:49 2024 +0800

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

Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Feb 1 22:47:15 2024 +0530

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

Author: Mads Bligaard Nielsen <[email protected]>
Date:   Mon Feb 19 21:21:47 2024 +0100

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

Author: Matthew Auld <[email protected]>
Date:   Mon Feb 19 12:18:53 2024 +0000

    drm/buddy: check range allocation matches alignment
    
    [ Upstream commit 2986314aa811c8a23aeb292edd30315495d54966 ]
    
    Likely not a big deal for real users, but for consistency we should
    respect the min_page_size here. Main issue is that bias allocations
    turns into normal range allocation if the range and size matches
    exactly, and in the next patch we want to add some unit tests for this
    part of the api.
    
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Arunpravin Paneer Selvam <[email protected]>
    Cc: Christian Kц╤nig <[email protected]>
    Reviewed-by: Arunpravin Paneer Selvam <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Christian Kц╤nig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhipeng Lu <[email protected]>
Date:   Wed Jan 17 15:13:28 2024 +0800

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

Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Feb 15 09:53:09 2024 +0100

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

Author: Hsin-Yi Wang <[email protected]>
Date:   Fri Feb 23 13:23:29 2024 -0800

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

Author: Rob Clark <[email protected]>
Date:   Tue Jan 2 11:33:45 2024 -0800

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

Author: Paloma Arellano <[email protected]>
Date:   Thu Feb 22 11:39:47 2024 -0800

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

Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Dec 3 03:05:29 2023 +0300

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

Author: Abhinav Kumar <[email protected]>
Date:   Wed Jan 31 16:47:36 2024 -0800

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

Author: Marijn Suijten <[email protected]>
Date:   Sun Feb 4 18:45:27 2024 +0100

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

Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Dec 2 00:18:38 2023 +0300

    drm/msm/dpu: use devres-managed allocation for HW blocks
    
    [ Upstream commit a106ed98af6848ef5810b12f5c9e2e0566f1d9c4 ]
    
    Use devm_kzalloc to create HW block structure. This allows us to remove
    corresponding kfree and drop all dpu_hw_*_destroy() functions as well as
    dpu_rm_destroy(), which becomes empty afterwards.
    
    Reviewed-by: Jessica Zhang <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/570041/
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 49e27d3c9cd6 ("drm/msm/dpu: finalise global state object")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Dec 2 00:18:37 2023 +0300

    drm/msm/dpu: use devres-managed allocation for MDP TOP
    
    [ Upstream commit 1e897dcc4c673b9d585c09ddcdbe7fab0934e64f ]
    
    Use devm_kzalloc to create MDP TOP structure. This allows us to remove
    corresponding kfree and drop dpu_hw_mdp_destroy() function.
    
    Reviewed-by: Jessica Zhang <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/570047/
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 49e27d3c9cd6 ("drm/msm/dpu: finalise global state object")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hsin-Yi Wang <[email protected]>
Date:   Wed Dec 20 14:13:11 2023 -0800

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

Author: Douglas Anderson <[email protected]>
Date:   Fri Feb 16 12:31:12 2024 -0800

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

Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Feb 6 08:48:14 2024 -0800

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

Author: Alex Bee <[email protected]>
Date:   Fri Dec 22 18:41:54 2023 +0100

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

Author: Quentin Schulz <[email protected]>
Date:   Mon Nov 20 13:29:48 2023 +0100

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

Author: Quentin Schulz <[email protected]>
Date:   Mon Nov 20 13:29:49 2023 +0100

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

Author: Zhang Shurong <[email protected]>
Date:   Wed Oct 4 22:10:55 2023 +0800

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

Author: Chen Ni <[email protected]>
Date:   Tue Oct 24 08:07:38 2023 +0000

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:09 2023 +0200

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:08 2023 +0200

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:10 2023 +0200

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:13 2023 +0200

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

Author: Fedor Pchelkin <[email protected]>
Date:   Fri Dec 15 12:33:55 2023 +0300

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:12 2023 +0200

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

Author: Christophe JAILLET <[email protected]>
Date:   Sat Sep 2 17:22:11 2023 +0200

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

Author: Maxime Ripard <[email protected]>
Date:   Thu Feb 22 19:13:47 2024 +0100

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

Author: Tomi Valkeinen <[email protected]>
Date:   Tue Feb 13 10:16:36 2024 +0200

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

Author: Tomi Valkeinen <[email protected]>
Date:   Tue Feb 13 10:16:37 2024 +0200

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

Author: Christian Kц╤nig <[email protected]>
Date:   Wed Feb 21 08:18:59 2024 +0100

    drm/ttm/tests: depend on UML || COMPILE_TEST
    
    [ Upstream commit 9d3f8a723c7950e56e0b95ab84b572caee29e065 ]
    
    At least the device test requires that no other driver using TTM is
    loaded. So make those unit tests depend on UML || COMPILE_TEST to
    prevent people from trying them on bare metal.
    
    Signed-off-by: Christian Kц╤nig <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Link: https://lore.kernel.org/all/20240219230116.77b8ad68@yea/
    Signed-off-by: Sasha Levin <[email protected]>

Author: Harry Wentland <[email protected]>
Date:   Wed Nov 8 11:36:24 2023 -0500

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

Author: Zhipeng Lu <[email protected]>
Date:   Mon Dec 4 17:14:16 2023 +0800

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

Author: Martin Krastev <[email protected]>
Date:   Fri Jan 26 15:08:03 2024 -0500

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

Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Feb 14 10:37:08 2024 +0200

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

Author: Harry Wentland <[email protected]>
Date:   Wed Nov 8 11:36:20 2023 -0500

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

Author: Arthur Grillo <[email protected]>
Date:   Sat Mar 16 13:25:20 2024 -0300

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

Author: Adam Skladowski <[email protected]>
Date:   Sun Jan 21 20:41:01 2024 +0100

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

Author: Al Viro <[email protected]>
Date:   Mon Feb 12 22:44:11 2024 -0500

    erofs: fix handling kern_mount() failure
    
    [ Upstream commit 2c88c16dc20e88dd54d2f6f4d01ae1dce6cc9654 ]
    
    if you have a variable that holds NULL or  a pointer to live struct mount,
    do not shove ERR_PTR() into it - not if you later treat "not NULL" as
    "holds a pointer to object".
    
    Signed-off-by: Al Viro <[email protected]>
    Stable-dep-of: 0f28be64d132 ("erofs: fix lockdep false positives on initializing erofs_pseudo_mnt")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Baokun Li <[email protected]>
Date:   Thu Mar 7 18:10:18 2024 +0800

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

Author: Jaegeuk Kim <[email protected]>
Date:   Fri Feb 23 12:32:05 2024 -0800

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

Author: Xiuhong Wang <[email protected]>
Date:   Wed Mar 6 11:47:46 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:30 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Mon Feb 19 10:28:44 2024 +0800

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

Author: Sheng Yong <[email protected]>
Date:   Sat Jan 13 03:41:29 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Tue Feb 13 00:08:18 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Mon Jan 22 10:23:13 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:28 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:27 2024 +0800

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

Author: Xiuhong Wang <[email protected]>
Date:   Wed Mar 6 11:47:45 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 17:20:36 2023 +0800

    f2fs: delete obsolete FI_DROP_CACHE
    
    [ Upstream commit bb6e1c8fa5b9b95bbb8e39b6105f8f6550e070fc ]
    
    FI_DROP_CACHE was introduced in commit 1e84371ffeef ("f2fs: change
    atomic and volatile write policies") for volatile write feature,
    after commit 7bc155fec5b3 ("f2fs: kill volatile write support"),
    we won't support volatile write, let's delete related codes.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 17:20:35 2023 +0800

    f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN
    
    [ Upstream commit a53936361330e4c55c0654605178281387d9c761 ]
    
    Commit 3c6c2bebef79 ("f2fs: avoid punch_hole overhead when releasing
    volatile data") introduced FI_FIRST_BLOCK_WRITTEN as below reason:
    
    This patch is to avoid some punch_hole overhead when releasing volatile
    data. If volatile data was not written yet, we just can make the first
    page as zero.
    
    After commit 7bc155fec5b3 ("f2fs: kill volatile write support"), we
    won't support volatile write, but it missed to remove obsolete
    FI_FIRST_BLOCK_WRITTEN, delete it in this patch.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wenjie Qi <[email protected]>
Date:   Tue Jan 16 22:11:38 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Wed Jan 24 22:49:15 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Wed Feb 7 15:05:48 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sat Jan 13 03:41:31 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Fri Mar 8 09:08:34 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sun Feb 25 14:36:28 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 17:20:39 2023 +0800

    f2fs: introduce f2fs_invalidate_internal_cache() for cleanup
    
    [ Upstream commit 4e4f1eb9949b10cb7d76370fd27d41f20ef2b32b ]
    
    Just cleanup, no logic changes.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 9f0c4a46be1f ("f2fs: fix to truncate meta inode pages forcely")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 17:20:37 2023 +0800

    f2fs: introduce get_dnode_addr() to clean up codes
    
    [ Upstream commit 2020cd48e41cb8470bb1ca0835033d13d3178425 ]
    
    Just cleanup, no logic changes.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chao Yu <[email protected]>
Date:   Mon Feb 26 15:35:38 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Sun Dec 10 17:20:38 2023 +0800

    f2fs: update blkaddr in __set_data_blkaddr() for cleanup
    
    [ Upstream commit 59d0d4c3eae0f3dd8886ed59f89f21fa09e324f5 ]
    
    This patch allows caller to pass blkaddr to f2fs_set_data_blkaddr()
    and let __set_data_blkaddr() inside f2fs_set_data_blkaddr() to update
    dn->data_blkaddr w/ last value of blkaddr.
    
    Just cleanup, no logic changes.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chao Yu <[email protected]>
Date:   Fri Mar 8 11:50:57 2024 +0800

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

Author: Chao Yu <[email protected]>
Date:   Mon Jan 29 19:27:40 2024 +0800

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

Author: Takashi Sakamoto <[email protected]>
Date:   Thu Feb 29 22:17:37 2024 +0900

    firewire: core: use long bus reset on gap count error
    
    [ Upstream commit d0b06dc48fb15902d7da09c5c0861e7f042a9381 ]
    
    When resetting the bus after a gap count error, use a long rather than
    short bus reset.
    
    IEEE 1394-1995 uses only long bus resets. IEEE 1394a adds the option of
    short bus resets. When video or audio transmission is in progress and a
    device is hot-plugged elsewhere on the bus, the resulting bus reset can
    cause video frame drops or audio dropouts. Short bus resets reduce or
    eliminate this problem. Accordingly, short bus resets are almost always
    preferred.
    
    However, on a mixed 1394/1394a bus, a short bus reset can trigger an
    immediate additional bus reset. This double bus reset can be interpreted
    differently by different nodes on the bus, resulting in an inconsistent gap
    count after the bus reset. An inconsistent gap count will cause another bus
    reset, leading to a neverending bus reset loop. This only happens for some
    bus topologies, not for all mixed 1394/1394a buses.
    
    By instead sending a long bus reset after a gap count inconsistency, we
    avoid the doubled bus reset, restoring the bus to normal operation.
    
    Signed-off-by: Adam Goldman <[email protected]>
    Link: https://sourceforge.net/p/linux1394/mailman/message/58741624/
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andre Przywara <[email protected]>
Date:   Fri Jan 26 12:23:25 2024 +0000

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

Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 16 21:23:34 2024 +0100

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

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

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

Author: Andrew Ballance <[email protected]>
Date:   Tue Feb 13 19:23:05 2024 -0600

    gen_compile_commands: fix invalid escape sequence warning
    
    [ Upstream commit dae4a0171e25884787da32823b3081b4c2acebb2 ]
    
    With python 3.12, '\#' results in this warning
        SyntaxWarning: invalid escape sequence '\#'
    
    Signed-off-by: Andrew Ballance <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thц╘o Lebrun <[email protected]>
Date:   Wed Feb 28 12:28:03 2024 +0100

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

Author: Martin Kaiser <[email protected]>
Date:   Wed Jan 24 21:58:57 2024 +0100

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

Author: Stephen Boyd <[email protected]>
Date:   Thu Feb 22 22:52:53 2024 -0800

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

Author: Basavaraj Natikar <[email protected]>
Date:   Wed Feb 14 20:11:42 2024 +0530

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

Author: Basavaraj Natikar <[email protected]>
Date:   Wed Feb 14 20:11:41 2024 +0530

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

Author: Mikhail Khvainitski <[email protected]>
Date:   Sat Dec 23 21:12:13 2023 +0200

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

Author: Oleksandr Natalenko <[email protected]>
Date:   Mon Jan 29 17:49:31 2024 +0100

    HID: logitech-hidpp: Do not flood kernel log
    
    [ Upstream commit 411a20db905b44e18cc9129b745f1d5deba4eae5 ]
    
    Since commit 680ee411a98e ("HID: logitech-hidpp: Fix connect event race")
    the following messages appear in the kernel log from time to time:
    
    logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected.
    logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected.
    logitech-hidpp-device 0003:046D:4051.0006: Disconnected
    logitech-hidpp-device 0003:046D:408A.0005: Disconnected
    
    As discussed, print the first per-device "device connected" message
    at info level, demoting subsequent messages to debug level. Also,
    demote the "Disconnected message" to debug level unconditionally.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Oleksandr Natalenko <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Manuel Fombuena <[email protected]>
Date:   Sun Feb 11 19:04:29 2024 +0000

    HID: multitouch: Add required quirk for Synaptics 0xcddc device
    
    [ Upstream commit 1741a8269e1c51fa08d4bfdf34667387a6eb10ec ]
    
    Add support for the pointing stick (Accupoint) and 2 mouse buttons.
    
    Present on some Toshiba/dynabook Portege X30 and X40 laptops.
    
    It should close https://bugzilla.kernel.org/show_bug.cgi?id=205817
    
    Signed-off-by: Manuel Fombuena <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shigeru Yoshida <[email protected]>
Date:   Wed Mar 13 00:27:19 2024 +0900

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

Author: Felix Maurer <[email protected]>
Date:   Fri Mar 15 13:04:52 2024 +0100

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

Author: Yang Jihong <[email protected]>
Date:   Mon Jan 8 12:19:06 2024 +0000

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

Author: Dylan Hung <[email protected]>
Date:   Fri Jan 19 13:45:47 2024 +0800

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

Author: Przemek Kitszel <[email protected]>
Date:   Tue Feb 27 15:31:06 2024 +0100

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

Author: Vinicius Costa Gomes <[email protected]>
Date:   Tue Feb 20 15:57:11 2024 -0800

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

Author: Vinicius Costa Gomes <[email protected]>
Date:   Tue Feb 20 15:57:10 2024 -0800

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

Author: Matti Vaittinen <[email protected]>
Date:   Mon Feb 12 13:20:09 2024 +0200

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

Author: Petre Rodan <[email protected]>
Date:   Fri Dec 29 11:24:32 2023 +0200

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

Author: Eric Dumazet <[email protected]>
Date:   Mon Jan 22 11:25:56 2024 +0000

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

Author: Uwe Kleine-Kц╤nig <[email protected]>
Date:   Tue Mar 5 11:10:42 2024 +0100

    Input: gpio_keys_polled - suppress deferred probe error for gpio
    
    [ Upstream commit 963465a33141d0d52338e77f80fe543d2c9dc053 ]
    
    On a PC Engines APU our admins are faced with:
    
            $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517"
            261
    
    Such a message always appears when e.g. a new USB device is plugged in.
    
    Suppress this message which considerably clutters the kernel log for
    EPROBE_DEFER (i.e. -517).
    
    Signed-off-by: Uwe Kleine-Kц╤nig <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jeff LaBundy <[email protected]>
Date:   Wed Mar 6 23:40:21 2024 -0600

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

Author: Muhammad Usama Anjum <[email protected]>
Date:   Fri Mar 1 19:43:48 2024 +0500

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

Author: Dan Carpenter <[email protected]>
Date:   Fri Mar 1 18:29:39 2024 +0300

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

Author: Jens Axboe <[email protected]>
Date:   Tue Feb 27 11:09:20 2024 -0700

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

Author: Jens Axboe <[email protected]>
Date:   Mon Feb 19 14:16:47 2024 -0700

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

Author: Jens Axboe <[email protected]>
Date:   Tue Dec 19 12:30:43 2023 -0700

    io_uring/unix: drop usage of io_uring socket
    
    Commit a4104821ad651d8a0b374f0b2474c345bbb42f82 upstream.
    
    Since we no longer allow sending io_uring fds over SCM_RIGHTS, move to
    using io_is_uring_fops() to detect whether this is a io_uring fd or not.
    With that done, kill off io_uring_get_socket() as nobody calls it
    anymore.
    
    This is in preparation to yanking out the rest of the core related to
    unix gc with io_uring.
    
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jens Axboe <[email protected]>
Date:   Mon Mar 11 13:30:43 2024 -0600

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

Author: Jens Axboe <[email protected]>
Date:   Tue Dec 19 12:36:34 2023 -0700

    io_uring: drop any code related to SCM_RIGHTS
    
    Commit 6e5e6d274956305f1fc0340522b38f5f5be74bdb upstream.
    
    This is dead code after we dropped support for passing io_uring fds
    over SCM_RIGHTS, get rid of it.
    
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Begunkov <[email protected]>
Date:   Fri Mar 15 15:29:51 2024 +0000

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

Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Mar 13 17:39:12 2024 -0400

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

Author: Jens Axboe <[email protected]>
Date:   Tue Jan 30 07:00:47 2024 -0700

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

Author: Jens Axboe <[email protected]>
Date:   Wed Jan 31 10:50:08 2024 -0700

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

Author: Christoph Hellwig <[email protected]>
Date:   Thu Dec 7 08:26:57 2023 +0100

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

Author: Mario Limonciello <[email protected]>
Date:   Mon Jan 22 17:34:00 2024 -0600

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

Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:15 2024 +0800

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

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

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

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

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

Author: Tobias Brunner <[email protected]>
Date:   Fri Mar 15 15:35:40 2024 +0100

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

Author: Shiming Cheng <[email protected]>
Date:   Thu Mar 7 18:01:57 2024 +0800

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

Author: Eric Dumazet <[email protected]>
Date:   Fri Feb 9 15:30:56 2024 +0000

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

Author: Masahiro Yamada <[email protected]>
Date:   Sat Feb 3 00:57:59 2024 +0900

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

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:14 2024 +0800

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

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

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

Author: George Stark <[email protected]>
Date:   Thu Dec 14 20:36:05 2023 +0300

    leds: aw2013: Unlock mutex before destroying it
    
    [ Upstream commit 6969d0a2ba1adc9ba6a49b9805f24080896c255c ]
    
    In the probe() callback in case of error mutex is destroyed being locked
    which is not allowed so unlock the mutex before destroying.
    
    Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
    Signed-off-by: George Stark <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ondrej Jirman <[email protected]>
Date:   Sat Feb 17 20:11:30 2024 +0100

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

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:15 2024 +0800

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

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:16 2024 +0800

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

Author: Andrii Nakryiko <[email protected]>
Date:   Thu Feb 1 09:20:24 2024 -0800

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

Author: Andrey Grafin <[email protected]>
Date:   Wed Jan 17 16:06:18 2024 +0300

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

Author: Andrii Nakryiko <[email protected]>
Date:   Fri Jan 26 14:09:44 2024 -0800

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

Author: Toke Hц╦iland-Jц╦rgensen <[email protected]>
Date:   Tue Feb 6 13:59:22 2024 +0100

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

Author: Sasha Levin <[email protected]>
Date:   Sun Mar 24 14:37:12 2024 -0400

    Linux 6.7.11
    
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:05 2024 +0800

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

Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:07 2024 +0800

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

Author: Yu Kuai <[email protected]>
Date:   Thu Feb 29 17:57:06 2024 +0800

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

Author: Yu Kuai <[email protected]>
Date:   Sat Nov 25 16:16:02 2023 +0800

    md/raid1: remove rcu protection to access rdev from conf
    
    [ Upstream commit 2d32777d60de81aa020a2431567020af26564c71 ]
    
    Because it's safe to accees rdev from conf:
     - If any spinlock is held, because synchronize_rcu() from
       md_kick_rdev_from_array() will prevent 'rdev' to be freed until
       spinlock is released;
     - If 'reconfig_lock' is held, because rdev can't be added or removed from
       array;
     - If there is normal IO inflight, because mddev_suspend() will prevent
       rdev to be added or removed from array;
     - If there is sync IO inflight, because 'MD_RECOVERY_RUNNING' is
       checked in remove_and_add_spares().
    
    And these will cover all the scenarios in raid1.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balance()")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Li Nan <[email protected]>
Date:   Mon Feb 26 11:14:40 2024 +0800

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

Author: Li Nan <[email protected]>
Date:   Thu Feb 8 16:55:56 2024 +0800

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

Author: Yu Kuai <[email protected]>
Date:   Sat Nov 25 16:16:00 2023 +0800

    md: remove flag RemoveSynchronized
    
    [ Upstream commit c891f1fd90e66e584bb1353e1859cef7c9eb36f8 ]
    
    rcu is not used correctly here, because synchronize_rcu() is called
    before replacing old value, for example:
    
    remove_and_add_spares   // other path
     synchronize_rcu
     // called before replacing old value
     set_bit(RemoveSynchronized)
                            rcu_read_lock()
                            rdev = conf->mirros[].rdev
     pers->hot_remove_disk
      conf->mirros[].rdev = NULL;
      if (!test_bit(RemoveSynchronized))
       synchronize_rcu
       /*
        * won't be called, and won't wait
        * for concurrent readers to be done.
        */
                            // access rdev after remove_and_add_spares()
                            rcu_read_unlock()
    
    Fortunately, there is a separate rcu protection to prevent such rdev
    to be freed:
    
    md_kick_rdev_from_array         //other path
                                    rcu_read_lock()
                                    rdev = conf->mirros[].rdev
    list_del_rcu(&rdev->same_set)
    
                                    rcu_read_unlock()
                                    /*
                                     * rdev can be removed from conf, but
                                     * rdev won't be freed.
                                     */
    synchronize_rcu()
    free rdev
    
    Hence remove this useless flag and prepare to remove rcu protection to
    access rdev from 'conf'.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balance()")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Julien Massot <[email protected]>
Date:   Fri Jan 5 10:00:21 2024 +0100

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

Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:09:25 2023 +0100

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

Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 16 17:31:44 2024 +0100

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

Author: Zhipeng Lu <[email protected]>
Date:   Sat Feb 3 14:40:43 2024 +0100

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

Author: Nikita Zhandarovich <[email protected]>
Date:   Fri Jan 12 05:42:26 2024 -0800

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

Author: Daniil Dulov <[email protected]>
Date:   Sun Feb 11 07:07:05 2024 -0800

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

Author: Zhipeng Lu <[email protected]>
Date:   Wed Feb 21 12:37:13 2024 +0800

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

Author: Alexander Stein <[email protected]>
Date:   Wed Feb 21 08:15:50 2024 +0100

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

Author: Lucas Stach <[email protected]>
Date:   Wed Jan 31 13:00:33 2024 +0100

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

Author: Sakari Ailus <[email protected]>
Date:   Wed Feb 7 14:17:09 2024 +0200

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

Author: Arnd Bergmann <[email protected]>
Date:   Sat Feb 24 13:10:22 2024 +0100

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

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

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

Author: Edward Adam Davis <[email protected]>
Date:   Fri Feb 16 15:30:47 2024 +0800

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

Author: Daniil Dulov <[email protected]>
Date:   Sun Feb 11 07:07:25 2024 -0800

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

Author: Tomi Valkeinen <[email protected]>
Date:   Mon Dec 18 08:54:01 2023 +0100

    media: rkisp1: Fix IRQ handling due to shared interrupts
    
    [ Upstream commit ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e ]
    
    The driver requests the interrupts as IRQF_SHARED, so the interrupt
    handlers can be called at any time. If such a call happens while the ISP
    is powered down, the SoC will hang as the driver tries to access the
    ISP registers.
    
    This can be reproduced even without the platform sharing the IRQ line:
    Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
    hang.
    
    Fix this by adding a new field, 'irqs_enabled', which is used to bail
    out from the interrupt handler when the ISP is not operational.
    
    Link: https://lore.kernel.org/r/[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]>

Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:22 2023 +0100

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

Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:20 2023 +0100

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

Author: Jernej Skrabec <[email protected]>
Date:   Sat Dec 16 14:34:21 2023 +0100

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

Author: Alexander Stein <[email protected]>
Date:   Wed Jan 10 10:01:11 2024 +0100

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

Author: Zhipeng Lu <[email protected]>
Date:   Wed Feb 21 13:17:04 2024 +0800

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

Author: Zhipeng Lu <[email protected]>
Date:   Thu Feb 1 20:48:44 2024 +0800

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

Author: Zhipeng Lu <[email protected]>
Date:   Thu Feb 1 20:47:53 2024 +0800

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

Author: Julien Massot <[email protected]>
Date:   Thu Jan 11 14:20:03 2024 +0100

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

Author: Alexander Usyskin <[email protected]>
Date:   Tue Feb 20 22:00:20 2024 +0200

    mei: gsc_proxy: match component when GSC is on different bus
    
    commit a0776c214d47ea4f7aaef138095beaa41cff03ef upstream.
    
    On Arrow Lake S systems, MEI is no longer strictly connected to bus 0,
    while graphics remain exclusively on bus 0. Adapt the component
    matching logic to accommodate this change:
    
    Original behavior: Required both MEI and graphics to be on the same
    bus 0.
    
    New behavior: Only enforces graphics to be on bus 0 (integrated),
    allowing MEI to reside on any bus.
    This ensures compatibility with Arrow Lake S and maintains functionality
    for the legacy systems.
    
    Fixes: 1dd924f6885b ("mei: gsc_proxy: add gsc proxy driver")
    Cc: [email protected] # v6.3+
    Signed-off-by: Alexander Usyskin <[email protected]>
    Signed-off-by: Tomas Winkler <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Jon Hunter <[email protected]>
Date:   Tue Feb 20 12:44:28 2024 +0000

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

Author: Peter Griffin <[email protected]>
Date:   Tue Feb 20 11:50:12 2024 +0000

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

Author: Maciej Strozek <[email protected]>
Date:   Fri Mar 1 10:15:47 2024 +0000

    mfd: cs42l43: Fix wrong GPIO_FN_SEL and SPI_CLK_CONFIG1 defaults
    
    [ Upstream commit 78334c343bef528b911da83a6b041d15a1a72efb ]
    
    Two regs have wrong values in existing fields, change them to match
    the datasheet.
    
    Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
    
    Signed-off-by: Maciej Strozek <[email protected]>
    Reviewed-by: Charles Keepax <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Maciej Strozek <[email protected]>
Date:   Thu Feb 29 15:56:14 2024 +0000

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

Author: Peter Griffin <[email protected]>
Date:   Tue Feb 20 11:50:10 2024 +0000

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

Author: Jiaxun Yang <[email protected]>
Date:   Fri Feb 2 12:30:27 2024 +0000

    MIPS: Clear Cause.BD in instruction_pointer_set
    
    [ Upstream commit 9d6e21ddf20293b3880ae55b9d14de91c5891c59 ]
    
    Clear Cause.BD after we use instruction_pointer_set to override
    EPC.
    
    This can prevent exception_epc check against instruction code at
    new return address.
    It won't be considered as "in delay slot" after epc being overridden
    anyway.
    
    Signed-off-by: Jiaxun Yang <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Mon Feb 26 22:37:39 2024 +0100

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

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

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

Author: Baruch Siach <[email protected]>
Date:   Thu Feb 8 12:34:18 2024 +0200

    mtd: maps: physmap-core: fix flash size larger than 32-bit
    
    [ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ]
    
    mtd-ram can potentially be larger than 4GB. get_bitmask_order() uses
    fls() that is not guaranteed to work with values larger than 32-bit.
    Specifically on aarch64 fls() returns 0 when all 32 LSB bits are clear.
    Use fls64() instead.
    
    Fixes: ba32ce95cbd987 ("mtd: maps: Merge gpio-addr-flash.c into physmap-core.c")
    Signed-off-by: Baruch Siach <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:00:09 2024 +0100

    mtd: rawnand: lpc32xx_mlc: fix irq handler prototype
    
    [ Upstream commit 347b828882e6334690e7003ce5e2fe5f233dc508 ]
    
    clang-16 warns about mismatched function prototypes:
    
    drivers/mtd/nand/raw/lpc32xx_mlc.c:783:29: error: cast from 'irqreturn_t (*)(int, struct lpc32xx_nand_host *)' (aka 'enum irqreturn (*)(int, struct lpc32xx_nand_host *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Change the interrupt handler to the normal way of just passing
    a void* pointer and converting it inside the function..
    
    Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ezra Buehler <[email protected]>
Date:   Thu Jan 25 22:01:08 2024 +0200

    mtd: spinand: esmt: Extend IDs to 5 bytes
    
    [ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ]
    
    According to the datasheets, the ESMT chips in question will return a 5
    byte long identification code where the last 3 bytes are the JEDEC
    continuation codes (7Fh). Although, I would have expected 4 continuation
    codes as Powerchip Semiconductor (C8h, corresponding to the parameter
    page data) is located in bank 5 of the JEDEC database.
    
    By matching the full 5 bytes we can avoid clashes with GigaDevice NAND
    flashes.
    
    This fix allows the MT7688-based GARDENA smart Gateway to boot again.
    
    Fixes: aa08bf187f32 ("mtd: spinand: esmt: add support for F50D2G41KA")
    Signed-off-by: Ezra Buehler <[email protected]>
    Reviewed-by: Martin Kurbanov <[email protected]>
    Tested-by: Martin Kurbanov <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Navid Emamdoost <[email protected]>
Date:   Sat Feb 17 20:25:38 2024 -0800

    nbd: null check for nla_nest_start
    
    [ Upstream commit 31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d ]
    
    nla_nest_start() may fail and return NULL. Insert a check and set errno
    based on other call sites within the same source code.
    
    Signed-off-by: Navid Emamdoost <[email protected]>
    Reviewed-by: Michal Kubecek <[email protected]>
    Fixes: 47d902b90a32 ("nbd: add a status netlink command")
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thinh Tran <[email protected]>
Date:   Fri Mar 15 15:55:35 2024 -0500

    net/bnx2x: Prevent access to a freed page in page_pool
    
    [ Upstream commit d27e2da94a42655861ca4baea30c8cd65546f25d ]
    
    Fix race condition leading to system crash during EEH error handling
    
    During EEH error recovery, the bnx2x driver's transmit timeout logic
    could cause a race condition when handling reset tasks. The
    bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
    which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
    SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
    overlap with the EEH driver's attempt to reset the device using
    bnx2x_io_slot_reset(), which also tries to free SGEs. This race
    condition can result in system crashes due to accessing freed memory
    locations in bnx2x_free_rx_sge()
    
    799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
    800                             struct bnx2x_fastpath *fp, u16 index)
    801  {
    802     struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
    803     struct page *page = sw_buf->page;
    ....
    where sw_buf was set to NULL after the call to dma_unmap_page()
    by the preceding thread.
    
        EEH: Beginning: 'slot_reset'
        PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
        bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
        bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
        bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
        Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
        BUG: Kernel NULL pointer dereference on read at 0x00000000
        Faulting instruction address: 0xc0080000025065fc
        Oops: Kernel access of bad area, sig: 11 [#1]
        .....
        Call Trace:
        [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
        [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
        [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
        [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
        [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
        [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
        [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
    
    To solve this issue, we need to verify page pool allocations before
    freeing.
    
    Fixes: 4cace675d687 ("bnx2x: Alloc 4k fragment for each rx ring buffer element")
    Signed-off-by: Thinh Tran <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexander Gordeev <[email protected]>
Date:   Wed Feb 14 17:32:40 2024 +0100

    net/iucv: fix the allocation size of iucv_path_table array
    
    [ Upstream commit b4ea9b6a18ebf7f9f3a7a60f82e925186978cfcf ]
    
    iucv_path_table is a dynamically allocated array of pointers to
    struct iucv_path items. Yet, its size is calculated as if it was
    an array of struct iucv_path items.
    
    Signed-off-by: Alexander Gordeev <[email protected]>
    Reviewed-by: Alexandra Winter <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Mon Mar 11 20:46:28 2024 +0000

    net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
    
    [ Upstream commit 343041b59b7810f9cdca371f445dd43b35c740b1 ]
    
    taprio_parse_tc_entry() is not correctly checking
    TCA_TAPRIO_TC_ENTRY_INDEX attribute:
    
            int tc; // Signed value
    
            tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
            if (tc >= TC_QOPT_MAX_QUEUE) {
                    NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");
                    return -ERANGE;
            }
    
    syzbot reported that it could fed arbitary negative values:
    
    UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18
    shift exponent -2147418108 is negative
    CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
      ubsan_epilogue lib/ubsan.c:217 [inline]
      __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386
      taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline]
      taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline]
      taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877
      taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134
      qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355
      tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776
      rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617
      netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
      netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
      netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
      netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x221/0x270 net/socket.c:745
      ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
      ___sys_sendmsg net/socket.c:2638 [inline]
      __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
     do_syscall_64+0xf9/0x240
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f1b2dea3759
    Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759
    RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004
    RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000
    R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340
    R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340
    
    Fixes: a54fc09e4cba ("net/sched: taprio: allow user input of per-tc max SDU")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Vladimir Oltean <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

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

Author: Breno Leitao <[email protected]>
Date:   Fri Feb 2 07:13:29 2024 -0800

    net: blackhole_dev: fix build warning for ethh set but not used
    
    [ Upstream commit 843a8851e89e2e85db04caaf88d8554818319047 ]
    
    lib/test_blackhole_dev.c sets a variable that is never read, causing
    this following building warning:
    
            lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used [-Wunused-but-set-variable]
    
    Remove the variable struct ethhdr *ethh, which is unused.
    
    Fixes: 509e56b37cc3 ("blackhole_dev: add a selftest")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleksij Rempel <[email protected]>
Date:   Mon Mar 4 14:56:12 2024 +0100

    net: dsa: microchip: make sure drive strength configuration is not lost by soft reset
    
    [ Upstream commit e3fb8e8ba72b053d05ca2602acdd6b869f9f296f ]
    
    This driver has two separate reset sequence in different places:
    - gpio/HW reset on start of ksz_switch_register()
    - SW reset on start of ksz_setup()
    
    The second one will overwrite drive strength configuration made in the
    ksz_switch_register().
    
    To fix it, move ksz_parse_drive_strength() from ksz_switch_register() to
    ksz_setup().
    
    Fixes: d67d7247f641 ("net: dsa: microchip: Add drive strength configuration")
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arд╠nц╖ ц°NAL <[email protected]>
Date:   Thu Mar 14 12:33:42 2024 +0300

    net: dsa: mt7530: fix handling of all link-local frames
    
    [ Upstream commit 69ddba9d170bdaee1dc0eb4ced38d7e4bb7b92af ]
    
    Currently, the MT753X switches treat frames with :01-0D and :0F MAC DAs as
    regular multicast frames, therefore flooding them to user ports.
    
    On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE
    Std 802.1QБ└╒-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC
    DA must only be propagated to C-VLAN and MAC Bridge components. That means
    VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports,
    these frames are supposed to be processed by the CPU (software). So we make
    the switch only forward them to the CPU port. And if received from a CPU
    port, forward to a single port. The software is responsible of making the
    switch conform to the latter by setting a single port as destination port
    on the special tag.
    
    This switch intellectual property cannot conform to this part of the
    standard fully. Whilst the REV_UN frame tag covers the remaining :04-0D and
    :0F MAC DAs, it also includes :22-FF which the scope of propagation is not
    supposed to be restricted for these MAC DAs.
    
    Set frames with :01-03 MAC DAs to be trapped to the CPU port(s). Add a
    comment for the remaining MAC DAs.
    
    Note that the ingress port must have a PVID assigned to it for the switch
    to forward untagged frames. A PVID is set by default on VLAN-aware and
    VLAN-unaware ports. However, when the network interface that pertains to
    the ingress port is attached to a vlan_filtering enabled bridge, the user
    can remove the PVID assignment from it which would prevent the link-local
    frames from being trapped to the CPU port. I am yet to see a way to forward
    link-local frames while preventing other untagged frames from being
    forwarded too.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arд╠nц╖ ц°NAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arд╠nц╖ ц°NAL <[email protected]>
Date:   Thu Mar 14 12:33:41 2024 +0300

    net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
    
    [ Upstream commit e8bf353577f382c7066c661fed41b2adc0fc7c40 ]
    
    Whether VLAN-aware or not, on every VID VLAN table entry that has the CPU
    port as a member of it, frames are set to egress the CPU port with the VLAN
    tag stacked. This is so that VLAN tags can be appended after hardware
    special tag (called DSA tag in the context of Linux drivers).
    
    For user ports on a VLAN-unaware bridge, frame ingressing the user port
    egresses CPU port with only the special tag.
    
    For user ports on a VLAN-aware bridge, frame ingressing the user port
    egresses CPU port with the special tag and the VLAN tag.
    
    This causes issues with link-local frames, specifically BPDUs, because the
    software expects to receive them VLAN-untagged.
    
    There are two options to make link-local frames egress untagged. Setting
    CONSISTENT or UNTAGGED on the EG_TAG bits on the relevant register.
    CONSISTENT means frames egress exactly as they ingress. That means
    egressing with the VLAN tag they had at ingress or egressing untagged if
    they ingressed untagged. Although link-local frames are not supposed to be
    transmitted VLAN-tagged, if they are done so, when egressing through a CPU
    port, the special tag field will be broken.
    
    BPDU egresses CPU port with VLAN tag egressing stacked, received on
    software:
    
    00:01:25.104821 AF Unknown (382365846), length 106:
                                         | STAG  | | VLAN  |
            0x0000:  0000 6c27 614d 4143 0001 0000 8100 0001  ..l'aMAC........
            0x0010:  0026 4242 0300 0000 0000 0000 6c27 614d  .&BB........l'aM
            0x0020:  4143 0000 0000 0000 6c27 614d 4143 0000  AC......l'aMAC..
            0x0030:  0000 1400 0200 0f00 0000 0000 0000 0000  ................
    
    BPDU egresses CPU port with VLAN tag egressing untagged, received on
    software:
    
    00:23:56.628708 AF Unknown (25215488), length 64:
                                         | STAG  |
            0x0000:  0000 6c27 614d 4143 0001 0000 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    BPDU egresses CPU port with VLAN tag egressing tagged, received on
    software:
    
    00:01:34.311963 AF Unknown (25215488), length 64:
                                         | Mess  |
            0x0000:  0000 6c27 614d 4143 0001 0001 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    To prevent confusing the software, force the frame to egress UNTAGGED
    instead of CONSISTENT. This way, frames can't possibly be received TAGGED
    by software which would have the special tag field broken.
    
    VLAN Tag Egress Procedure
    
       For all frames, one of these options set the earliest in this order will
       apply to the frame:
    
       - EG_TAG in certain registers for certain frames.
         This will apply to frame with matching MAC DA or EtherType.
    
       - EG_TAG in the address table.
         This will apply to frame at its incoming port.
    
       - EG_TAG in the PVC register.
         This will apply to frame at its incoming port.
    
       - EG_CON and [EG_TAG per port] in the VLAN table.
         This will apply to frame at its outgoing port.
    
       - EG_TAG in the PCR register.
         This will apply to frame at its outgoing port.
    
       EG_TAG in certain registers for certain frames:
    
       PPPoE Discovery_ARP/RARP: PPP_EG_TAG and ARP_EG_TAG in the APC register.
       IGMP_MLD: IGMP_EG_TAG and MLD_EG_TAG in the IMC register.
       BPDU and PAE: BPDU_EG_TAG and PAE_EG_TAG in the BPC register.
       REV_01 and REV_02: R01_EG_TAG and R02_EG_TAG in the RGAC1 register.
       REV_03 and REV_0E: R03_EG_TAG and R0E_EG_TAG in the RGAC2 register.
       REV_10 and REV_20: R10_EG_TAG and R20_EG_TAG in the RGAC3 register.
       REV_21 and REV_UN: R21_EG_TAG and RUN_EG_TAG in the RGAC4 register.
    
    With this change, it can be observed that a bridge interface with stp_state
    and vlan_filtering enabled will properly block ports now.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arд╠nц╖ ц°NAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arд╠nц╖ ц°NAL <[email protected]>
Date:   Thu Mar 14 12:28:35 2024 +0300

    net: dsa: mt7530: prevent possible incorrect XTAL frequency selection
    
    [ Upstream commit f490c492e946d8ffbe65ad4efc66de3c5ede30a4 ]
    
    On MT7530, the HT_XTAL_FSEL field of the HWTRAP register stores a 2-bit
    value that represents the frequency of the crystal oscillator connected to
    the switch IC. The field is populated by the state of the ESW_P4_LED_0 and
    ESW_P4_LED_0 pins, which is done right after reset is deasserted.
    
      ESW_P4_LED_0    ESW_P3_LED_0    Frequency
      -----------------------------------------
      0               0               Reserved
      0               1               20MHz
      1               0               40MHz
      1               1               25MHz
    
    On MT7531, the XTAL25 bit of the STRAP register stores this. The LAN0LED0
    pin is used to populate the bit. 25MHz when the pin is high, 40MHz when
    it's low.
    
    These pins are also used with LEDs, therefore, their state can be set to
    something other than the bootstrapping configuration. For example, a link
    may be established on port 3 before the DSA subdriver takes control of the
    switch which would set ESW_P3_LED_0 to high.
    
    Currently on mt7530_setup() and mt7531_setup(), 1000 - 1100 usec delay is
    described between reset assertion and deassertion. Some switch ICs in real
    life conditions cannot always have these pins set back to the bootstrapping
    configuration before reset deassertion in this amount of delay. This causes
    wrong crystal frequency to be selected which puts the switch in a
    nonfunctional state after reset deassertion.
    
    The tests below are conducted on an MT7530 with a 40MHz crystal oscillator
    by Justin Swartz.
    
    With a cable from an active peer connected to port 3 before reset, an
    incorrect crystal frequency (0b11 = 25MHz) is selected:
    
                          [1]                  [3]     [5]
                          :                    :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  _____________________________
    ESW_P3_LED_0                               |__________________________
    
                           :                  : :     :
                           :                  : [4]...:
                           :                  :
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 1000 - 1100 usec.
    [3] Reset is deasserted.
    [4] Period of 315 usec. HWTRAP register is populated with incorrect
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    Increase the delay between reset_control_assert() and
    reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and
    gpiod_set_value_cansleep(priv->reset, 1) to 5000 - 5100 usec. This amount
    ensures a higher possibility that the switch IC will have these pins back
    to the bootstrapping configuration before reset deassertion.
    
    With a cable from an active peer connected to port 3 before reset, the
    correct crystal frequency (0b10 = 40MHz) is selected:
    
                          [1]        [2-1]     [3]     [5]
                          :          :         :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  ___________________           _______
    ESW_P3_LED_0                     |_________|       |__________________
    
                           :          :       : :     :
                           :          [2-2]...: [4]...:
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 5000 - 5100 usec.
    [2-1] ESW_P3_LED_0 goes low.
    [2-2] Remaining period of 5000 - 5100 usec.
    [3] Reset is deasserted.
    [4] Period of 310 usec. HWTRAP register is populated with bootstrapped
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    ESW_P3_LED_0 low period before reset deassertion:
    
                  5000 usec
                - 5100 usec
        TEST     RESET HOLD
           #         (usec)
      ---------------------
           1           5410
           2           5440
           3           4375
           4           5490
           5           5475
           6           4335
           7           4370
           8           5435
           9           4205
          10           4335
          11           3750
          12           3170
          13           4395
          14           4375
          15           3515
          16           4335
          17           4220
          18           4175
          19           4175
          20           4350
    
         Min           3170
         Max           5490
    
      Median       4342.500
         Avg       4466.500
    
    Revert commit 2920dd92b980 ("net: dsa: mt7530: disable LEDs before reset").
    Changing the state of pins via reset assertion is simpler and more
    efficient than doing so by setting the LED controller off.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")
    Co-developed-by: Justin Swartz <[email protected]>
    Signed-off-by: Justin Swartz <[email protected]>
    Signed-off-by: Arд╠nц╖ ц°NAL <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kamal Heib <[email protected]>
Date:   Thu Feb 15 17:31:04 2024 -0500

    net: ena: Remove ena_select_queue
    
    [ Upstream commit 78e886ba2b549945ecada055ee0765f0ded5707a ]
    
    Avoid the following warnings by removing the ena_select_queue() function
    and rely on the net core to do the queue selection, The issue happen
    when an skb received from an interface with more queues than ena is
    forwarded to the ena interface.
    
    [ 1176.159959] eth0 selects TX queue 11, but real number of TX queues is 8
    [ 1176.863976] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1180.767877] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1188.703742] eth0 selects TX queue 14, but real number of TX queues is 8
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Kamal Heib <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:40 2024 +0000

    net: ethernet: mtk_eth_soc: fix PPE hanging issue
    
    [ Upstream commit ea80e3ed09ab2c2b75724faf5484721753e92c31 ]
    
    A patch to resolve an issue was found in MediaTek's GPL-licensed SDK:
    In the mtk_ppe_stop() function, the PPE scan mode is not disabled before
    disabling the PPE. This can potentially lead to a hang during the process
    of disabling the PPE.
    
    Without this patch, the PPE may experience a hang during the reboot test.
    
    Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b40da332dfe763932a82f9f62a4709457a15dd6c
    Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
    Suggested-by: Bc-bocun Chen <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yonglong Liu <[email protected]>
Date:   Thu Mar 7 09:01:11 2024 +0800

    net: hns3: fix kernel crash when 1588 is received on HIP08 devices
    
    [ Upstream commit 0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3 ]
    
    The HIP08 devices does not register the ptp devices, so the
    hdev->ptp is NULL, but the hardware can receive 1588 messages,
    and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
    access of hdev->ptp->flags will cause a kernel crash:
    
    [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    ...
    [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
    [ 5889.279101] sp : ffff800012c3bc50
    [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
    [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
    [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
    [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
    [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
    [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
    [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
    [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
    [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
    [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
    [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
    [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
    [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
    [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
    [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
    [ 5889.378857] Call trace:
    [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
    [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
    [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
    [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
    [ 5889.411084] napi_poll+0xcc/0x264
    [ 5889.415329] net_rx_action+0xd4/0x21c
    [ 5889.419911] __do_softirq+0x130/0x358
    [ 5889.424484] irq_exit+0x134/0x154
    [ 5889.428700] __handle_domain_irq+0x88/0xf0
    [ 5889.433684] gic_handle_irq+0x78/0x2c0
    [ 5889.438319] el1_irq+0xb8/0x140
    [ 5889.442354] arch_cpu_idle+0x18/0x40
    [ 5889.446816] default_idle_call+0x5c/0x1c0
    [ 5889.451714] cpuidle_idle_call+0x174/0x1b0
    [ 5889.456692] do_idle+0xc8/0x160
    [ 5889.460717] cpu_startup_entry+0x30/0xfc
    [ 5889.465523] secondary_start_kernel+0x158/0x1ec
    [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
    [ 5889.477950] SMP: stopping secondary CPUs
    [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
    [ 5890.522951] Starting crashdump kernel...
    
    Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
    Signed-off-by: Yonglong Liu <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jie Wang <[email protected]>
Date:   Thu Mar 7 09:01:14 2024 +0800

    net: hns3: fix port duplex configure error in IMP reset
    
    [ Upstream commit 11d80f79dd9f871a52feba4bf24b5ac39f448eb7 ]
    
    Currently, the mac port is fixed to configured as full dplex mode in
    hclge_mac_init() when driver initialization or reset restore. Users may
    change the mode to half duplex with ethtool,  so it may cause the user
    configuration dropped after reset.
    
    To fix it, don't change the duplex mode when resetting.
    
    Fixes: 2d03eacc0b7e ("net: hns3: Only update mac configuation when necessary")
    Signed-off-by: Jie Wang <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jijie Shao <[email protected]>
Date:   Thu Mar 7 09:01:08 2024 +0800

    net: hns3: fix wrong judgment condition issue
    
    [ Upstream commit 07a1d6dc90baedcf5d713e2b003b9e387130ee30 ]
    
    In hns3_dcbnl_ieee_delapp, should check ieee_delapp not ieee_setapp.
    This path fix the wrong judgment.
    
    Fixes: 0ba22bcb222d ("net: hns3: add support config dscp map to tc")
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 7 10:07:16 2024 +0000

    net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()
    
    [ Upstream commit b0ec2abf98267f14d032102551581c833b0659d3 ]
    
    Apply the same fix than ones found in :
    
    8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
    1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")
    
    We have to save skb->network_header in a temporary variable
    in order to be able to recompute the network_header pointer
    after a pskb_inet_may_pull() call.
    
    pskb_inet_may_pull() makes sure the needed headers are in skb->head.
    
    syzbot reported:
    BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
     BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
     BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
     BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
      INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
      IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
      ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
      ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
      gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
      gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
      ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
      ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
      dst_input include/net/dst.h:461 [inline]
      ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
      __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
      __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
      netif_receive_skb_internal net/core/dev.c:5734 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5793
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
      tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
      __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
      alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
      alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
      skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
      tun_build_skb drivers/net/tun.c:1686 [inline]
      tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

    net: kcm: fix incorrect parameter validation in the kcm_getsockopt) function
    
    [ Upstream commit 3ed5f415133f9b7518fbe55ba9ae9a3f5e700929 ]
    
    The 'len' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'len' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jeremy Kerr <[email protected]>
Date:   Mon Feb 19 17:51:54 2024 +0800

    net: mctp: copy skb ext data when fragmenting
    
    [ Upstream commit 1394c1dec1c619a46867ed32791a29695372bff8 ]
    
    If we're fragmenting on local output, the original packet may contain
    ext data for the MCTP flows. We'll want this in the resulting fragment
    skbs too.
    
    So, do a skb_ext_copy() in the fragmentation path, and implement the
    MCTP-specific parts of an ext copy operation.
    
    Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers")
    Reported-by: Jian Zhang <[email protected]>
    Signed-off-by: Jeremy Kerr <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:18 2024 +0000

    net: mediatek: mtk_eth_soc: clear MAC_MCR_FORCE_LINK only when MAC is up
    
    [ Upstream commit f1b85ef15a99f06ed48871ce933d591127d2dcc0 ]
    
    Clearing bit MAC_MCR_FORCE_LINK which forces the link down too early
    can result in MAC ending up in a broken/blocked state.
    
    Fix this by handling this bit in the .mac_link_up and .mac_link_down
    calls instead of in .mac_finish.
    
    Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support")
    Suggested-by: Mason-cw Chang <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tim Pambor <[email protected]>
Date:   Tue Mar 5 12:06:08 2024 +0100

    net: phy: dp83822: Fix RGMII TX delay configuration
    
    [ Upstream commit c8a5c731fd1223090af57da33838c671a7fc6a78 ]
    
    The logic for enabling the TX clock shift is inverse of enabling the RX
    clock shift. The TX clock shift is disabled when DP83822_TX_CLK_SHIFT is
    set. Correct the current behavior and always write the delay configuration
    to ensure consistent delay settings regardless of bootloader configuration.
    
    Reference: https://www.ti.com/lit/ds/symlink/dp83822i.pdf p. 69
    
    Fixes: 8095295292b5 ("net: phy: DP83822: Add setting the fixed internal delay")
    Signed-off-by: Tim Pambor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kц╘vin L'hц╢pital <[email protected]>
Date:   Thu Mar 7 12:19:06 2024 +0100

    net: phy: fix phy_get_internal_delay accessing an empty array
    
    [ Upstream commit 4469c0c5b14a0919f5965c7ceac96b523eb57b79 ]
    
    The phy_get_internal_delay function could try to access to an empty
    array in the case that the driver is calling phy_get_internal_delay
    without defining delay_values and rx-internal-delay-ps or
    tx-internal-delay-ps is defined to 0 in the device-tree.
    This will lead to "unable to handle kernel NULL pointer dereference at
    virtual address 0". To avoid this kernel oops, the test should be delay
    >= 0. As there is already delay < 0 test just before, the test could
    only be size == 0.
    
    Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the internal delay")
    Co-developed-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Kц╘vin L'hц╢pital <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikita Kiryushin <[email protected]>
Date:   Fri Mar 15 20:50:52 2024 +0300

    net: phy: fix phy_read_poll_timeout argument type in genphy_loopback
    
    [ Upstream commit 32fa4366cc4da1c97b725a0066adf43c6b298f37 ]
    
    read_poll_timeout inside phy_read_poll_timeout can set val negative
    in some cases (for example, __mdiobus_read inside phy_read can return
    -EOPNOTSUPP).
    
    Supposedly, commit 4ec732951702 ("net: phylib: fix phy_read*_poll_timeout()")
    should fix problems with wrong-signed vals, but I do not see how
    as val is sent to phy_read as is and __val = phy_read (not val)
    is checked for sign.
    
    Change val type for signed to allow better error handling as done in other
    phy_read_poll_timeout callers. This will not fix any error handling
    by itself, but allows, for example, to modify cond with appropriate
    sign check or check resulting val separately.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 014068dcb5b1 ("net: phy: genphy_loopback: add link speed configuration")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:37 2024 -0700

    net: report RCU QS on threaded NAPI repolling
    
    [ Upstream commit d6dbbb11247c71203785a2c9da474c36f4b19eae ]
    
    NAPI threads can keep polling packets under load. Currently it is only
    calling cond_resched() before repolling, but it is not sufficient to
    clear out the holdout of RCU tasks, which prevent BPF tracing programs
    from detaching for long period. This can be reproduced easily with
    following set up:
    
    ip netns add test1
    ip netns add test2
    
    ip -n test1 link add veth1 type veth peer name veth2 netns test2
    
    ip -n test1 link set veth1 up
    ip -n test1 link set lo up
    ip -n test2 link set veth2 up
    ip -n test2 link set lo up
    
    ip -n test1 addr add 192.168.1.2/31 dev veth1
    ip -n test1 addr add 1.1.1.1/32 dev lo
    ip -n test2 addr add 192.168.1.3/31 dev veth2
    ip -n test2 addr add 2.2.2.2/31 dev lo
    
    ip -n test1 route add default via 192.168.1.3
    ip -n test2 route add default via 192.168.1.2
    
    for i in `seq 10 210`; do
     for j in `seq 10 210`; do
        ip netns exec test2 iptables -I INPUT -s 3.3.$i.$j -p udp --dport 5201
     done
    done
    
    ip netns exec test2 ethtool -K veth2 gro on
    ip netns exec test2 bash -c 'echo 1 > /sys/class/net/veth2/threaded'
    ip netns exec test1 ethtool -K veth1 tso off
    
    Then run an iperf3 client/server and a bpftrace script can trigger it:
    
    ip netns exec test2 iperf3 -s -B 2.2.2.2 >/dev/null&
    ip netns exec test1 iperf3 -c 2.2.2.2 -B 1.1.1.1 -u -l 1500 -b 3g -t 100 >/dev/null&
    bpftrace -e 'kfunc:__napi_poll{@=count();} interval:s:1{exit();}'
    
    Report RCU quiescent states periodically will resolve the issue.
    
    Fixes: 29863d41bb6e ("net: implement threaded-able napi poll loop support")
    Reviewed-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/r/4c3b0d3f32d3b18949d75b18e5e1d9f13a24f025.1710877680.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andre Werner <[email protected]>
Date:   Mon Feb 19 06:33:32 2024 +0100

    net: smsc95xx: add support for SYS TEC USB-SPEmodule1
    
    [ Upstream commit 45532b21dc2a692444b6ad5f71c253cca53e8103 ]
    
    This patch adds support for the SYS TEC USB-SPEmodule1 10Base-T1L
    ethernet device to the existing smsc95xx driver by adding the new
    USB VID/PID pair.
    
    Signed-off-by: Andre Werner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Tue Oct 24 23:58:20 2023 +0200

    net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr()
    
    [ Upstream commit d6f4de70f73a106986ee315d7d512539f2f3303a ]
    
    The intent is to check if the strings' are truncated or not. So, >= should
    be used instead of >, because strlcat() and snprintf() return the length of
    the output, excluding the trailing NULL.
    
    Fixes: a02d69261134 ("SUNRPC: Provide functions for managing universal addresses")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:19 2024 +0800

    net: test: Fix printf format specifier in skb_segment kunit test
    
    [ Upstream commit ff3b96f2c9e5c24fca12239cd519a8a18569e687 ]
    
    KUNIT_FAIL() accepts a printf-style format string, but previously did
    not let gcc validate it with the __printf() attribute. The use of %lld
    for the result of PTR_ERR() is not correct.
    
    Instead, use %pe and pass the actual error pointer. printk() will format
    it correctly (and give a symbolic name rather than a number if
    available, which should make the output more readable, too).
    
    Fixes: b3098d32ed6e ("net: add skb_segment kunit test")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Duanqiang Wen <[email protected]>
Date:   Wed Mar 13 16:06:34 2024 +0800

    net: txgbe: fix clk_name exceed MAX_DEV_ID limits
    
    [ Upstream commit e30cef001da259e8df354b813015d0e5acc08740 ]
    
    txgbe register clk which name is i2c_designware.pci_dev_id(),
    clk_name will be stored in clk_lookup_alloc. If PCIe bus number
    is larger than 0x39, clk_name size will be larger than 20 bytes.
    It exceeds clk_lookup_alloc MAX_DEV_ID limits. So the driver
    shortened clk_name.
    
    Fixes: b63f20485e43 ("net: txgbe: Register fixed rate clock")
    Signed-off-by: Duanqiang Wen <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ignat Korchagin <[email protected]>
Date:   Wed Mar 13 19:37:58 2024 +0100

    net: veth: do not manipulate GRO when using XDP
    
    [ Upstream commit d7db7775ea2e31502d46427f5efd385afc4ff1eb ]
    
    Commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP") tried to fix
    the fact that GRO was not possible without XDP, because veth did not use NAPI
    without XDP. However, it also introduced the behaviour that GRO is always
    enabled, when XDP is enabled.
    
    While it might be desired for most cases, it is confusing for the user at best
    as the GRO flag suddenly changes, when an XDP program is attached. It also
    introduces some complexities in state management as was partially addressed in
    commit fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down").
    
    But the biggest problem is that it is not possible to disable GRO at all, when
    an XDP program is attached, which might be needed for some use cases.
    
    Fix this by not touching the GRO flag on XDP enable/disable as the code already
    supports switching to NAPI if either GRO or XDP is requested.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP")
    Fixes: fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down")
    Signed-off-by: Ignat Korchagin <[email protected]>
    Reviewed-by: Toke Hц╦iland-Jц╦rgensen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Mar 14 18:51:38 2024 +0100

    netfilter: nf_tables: do not compare internal table flags on updates
    
    [ Upstream commit 4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139 ]
    
    Restore skipping transaction if table update does not modify flags.
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Quan Tian <[email protected]>
Date:   Thu Mar 7 01:24:02 2024 +0800

    netfilter: nf_tables: Fix a memory leak in nf_tables_updchain
    
    [ Upstream commit 7eaf837a4eb5f74561e2486972e7f5184b613f6e ]
    
    If nft_netdev_register_hooks() fails, the memory associated with
    nft_stats is not freed, causing a memory leak.
    
    This patch fixes it by moving nft_stats_alloc() down after
    nft_netdev_register_hooks() succeeds.
    
    Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain")
    Signed-off-by: Quan Tian <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Mar 10 10:02:41 2024 +0100

    netfilter: nft_set_pipapo: release elements in clone only from destroy path
    
    [ Upstream commit b0e256f3dd2ba6532f37c5c22e07cb07a36031ee ]
    
    Clone already always provides a current view of the lookup table, use it
    to destroy the set, otherwise it is possible to destroy elements twice.
    
    This fix requires:
    
     212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
    
    which came after:
    
     9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").
    
    Fixes: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Duoming Zhou <[email protected]>
Date:   Fri Mar 8 22:25:40 2024 +0800

    nfp: flower: handle acti_netdevs allocation failure
    
    [ Upstream commit 84e95149bd341705f0eca6a7fcb955c548805002 ]
    
    The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
    the physical memory has run out. As a result, if we dereference
    the acti_netdevs, the null pointer dereference bugs will happen.
    
    This patch adds a check to judge whether allocation failure occurs.
    If it happens, the delayed work will be rescheduled and try again.
    
    Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups")
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Louis Peens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Sun Feb 18 22:16:53 2024 +0100

    NFS: Fix an off by one in root_nfs_cat()
    
    [ Upstream commit 698ad1a538da0b6bf969cfee630b4e3a026afb87 ]
    
    The intent is to check if 'dest' is truncated or not. So, >= should be
    used instead of >, because strlcat() returns the length of 'dest' and 'src'
    excluding the trailing NULL.
    
    Fixes: 56463e50d1fc ("NFS: Use super.c for NFSROOT mount option parsing")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dave Wysochanski <[email protected]>
Date:   Wed Jan 31 11:10:06 2024 -0500

    NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt
    
    [ Upstream commit fd5860ab6341506004219b080aea40213b299d2e ]
    
    The loop inside nfs_netfs_issue_read() currently does not disable
    interrupts while iterating through pages in the xarray to submit
    for NFS read.  This is not safe though since after taking xa_lock,
    another page in the mapping could be processed for writeback inside
    an interrupt, and deadlock can occur.  The fix is simple and clean
    if we use xa_for_each_range(), which handles the iteration with RCU
    while reducing code complexity.
    
    The problem is easily reproduced with the following test:
     mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs
     dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1
     echo 3 > /proc/sys/vm/drop_caches
     dd if=/mnt/nfs/file1.bin of=/dev/null
     umount /mnt/nfs
    
    On the console with a lockdep-enabled kernel a message similar to
    the following will be seen:
    
     ================================
     WARNING: inconsistent lock state
     6.7.0-lockdbg+ #10 Not tainted
     --------------------------------
     inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
     test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:
     ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at:
    nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
     {IN-SOFTIRQ-W} state was registered at:
       lock_acquire+0x144/0x380
       _raw_spin_lock_irqsave+0x4e/0xa0
       __folio_end_writeback+0x17e/0x5c0
       folio_end_writeback+0x93/0x1b0
       iomap_finish_ioend+0xeb/0x6a0
       blk_update_request+0x204/0x7f0
       blk_mq_end_request+0x30/0x1c0
       blk_complete_reqs+0x7e/0xa0
       __do_softirq+0x113/0x544
       __irq_exit_rcu+0xfe/0x120
       irq_exit_rcu+0xe/0x20
       sysvec_call_function_single+0x6f/0x90
       asm_sysvec_call_function_single+0x1a/0x20
       pv_native_safe_halt+0xf/0x20
       default_idle+0x9/0x20
       default_idle_call+0x67/0xa0
       do_idle+0x2b5/0x300
       cpu_startup_entry+0x34/0x40
       start_secondary+0x19d/0x1c0
       secondary_startup_64_no_verify+0x18f/0x19b
     irq event stamp: 176891
     hardirqs last  enabled at (176891): [<ffffffffa67a0be4>]
    _raw_spin_unlock_irqrestore+0x44/0x60
     hardirqs last disabled at (176890): [<ffffffffa67a0899>]
    _raw_spin_lock_irqsave+0x79/0xa0
     softirqs last  enabled at (176646): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
     softirqs last disabled at (176633): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&xa->xa_lock#4);
       <Interrupt>
         lock(&xa->xa_lock#4);
    
      *** DEADLOCK ***
    
     2 locks held by test5/1708:
      #0: ffff888127baa498 (&sb->s_type->i_mutex_key#22){++++}-{4:4}, at:
          nfs_start_io_read+0x28/0x90 [nfs]
      #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:
          page_cache_ra_unbounded+0xa4/0x280
    
     stack backtrace:
     CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
    04/01/2014
     Call Trace:
      dump_stack_lvl+0x5b/0x90
      mark_lock+0xb3f/0xd20
      __lock_acquire+0x77b/0x3360
      _raw_spin_lock+0x34/0x80
      nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
      netfs_begin_read+0x77f/0x980 [netfs]
      nfs_netfs_readahead+0x45/0x60 [nfs]
      nfs_readahead+0x323/0x5a0 [nfs]
      read_pages+0xf3/0x5c0
      page_cache_ra_unbounded+0x1c8/0x280
      filemap_get_pages+0x38c/0xae0
      filemap_read+0x206/0x5e0
      nfs_file_read+0xb7/0x140 [nfs]
      vfs_read+0x2a9/0x460
      ksys_read+0xb7/0x140
    
    Fixes: 000dbe0bec05 ("NFS: Convert buffered read paths to use netfs when fscache is enabled")
    Suggested-by: Jeff Layton <[email protected]>
    Signed-off-by: Dave Wysochanski <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: David Howells <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Josef Bacik <[email protected]>
Date:   Mon Mar 11 11:11:53 2024 -0400

    nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
    
    [ Upstream commit 719fcafe07c12646691bd62d7f8d94d657fa0766 ]
    
    We've been seeing the following panic in production
    
    BUG: kernel NULL pointer dereference, address: 0000000000000065
    PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0
    RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
    Call Trace:
     <TASK>
     ? __die+0x78/0xc0
     ? page_fault_oops+0x286/0x380
     ? __rpc_execute+0x2c3/0x470 [sunrpc]
     ? rpc_new_task+0x42/0x1c0 [sunrpc]
     ? exc_page_fault+0x5d/0x110
     ? asm_exc_page_fault+0x22/0x30
     ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]
     pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]
     pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]
     ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]
     nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]
     ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]
     __nfs_pageio_add_request+0x154/0x6c0 [nfs]
     nfs_pageio_add_request+0x26b/0x380 [nfs]
     nfs_do_writepage+0x111/0x1e0 [nfs]
     nfs_writepages_callback+0xf/0x30 [nfs]
     write_cache_pages+0x17f/0x380
     ? nfs_pageio_init_write+0x50/0x50 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     nfs_writepages+0x125/0x210 [nfs]
     do_writepages+0x67/0x220
     ? generic_perform_write+0x14b/0x210
     filemap_fdatawrite_wbc+0x5b/0x80
     file_write_and_wait_range+0x6d/0xc0
     nfs_file_fsync+0x81/0x170 [nfs]
     ? nfs_file_mmap+0x60/0x60 [nfs]
     __x64_sys_fsync+0x53/0x90
     do_syscall_64+0x3d/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Inspecting the core with drgn I was able to pull this
    
      >>> prog.crashed_thread().stack_trace()[0]
      #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27
      >>> prog.crashed_thread().stack_trace()[0]['idx']
      (u32)1
      >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds
      (struct nfs4_ff_layout_ds *)0xffffffffffffffed
    
    This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()
    which could error out initializing the mirror_ds, and then we go to
    clean it all up and our check is only for if (!mirror->mirror_ds).  This
    is inconsistent with the rest of the users of mirror_ds, which have
    
      if (IS_ERR_OR_NULL(mirror_ds))
    
    to keep from tripping over this exact scenario.  Fix this up in
    ff_layout_cancel_io() to make sure we don't panic when we get an error.
    I also spot checked all the other instances of checking mirror_ds and we
    appear to be doing the correct checks everywhere, only unconditionally
    dereferencing mirror_ds when we know it would be valid.
    
    Signed-off-by: Josef Bacik <[email protected]>
    Fixes: b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked")
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Olga Kornievskaia <[email protected]>
Date:   Tue Feb 20 18:25:34 2024 -0500

    NFSv4.1/pnfs: fix NFS with TLS in pnfs
    
    [ Upstream commit a35518cae4b325632840bc8c3aa9ad9bac430038 ]
    
    Currently, even though xprtsec=tls is specified and used for operations
    to MDS, any operations that go to DS travel over unencrypted connection.
    Or additionally, if more than 1 DS can serve the data, then trunked
    connections are also done unencrypted.
    
    IN GETDEVINCEINFO, we get an entry for the DS which carries a protocol
    type (which is TCP), then nfs4_set_ds_client() gets called with TCP
    instead of TCP with TLS.
    
    Currently, each trunked connection is created and uses clp->cl_hostname
    value which if TLS is used would get passed up in the handshake upcall,
    but instead we need to pass in the appropriate trunked address value.
    
    Fixes: c8407f2e560c ("NFS: Add an "xprtsec=" NFS mount option")
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:51:28 2024 -0700

    NFSv4.2: fix listxattr maximum XDR buffer size
    
    [ Upstream commit bcac8bff90a6ee1629f90669cdb9d28fb86049b0 ]
    
    Switch order of operations to avoid creating a short XDR buffer:
    e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20.
    
    Having a short XDR buffer leads to lxa_maxcount be a few bytes
    less than what is needed to retrieve the whole list when using
    a buflen as returned by a call with size = 0:
        buflen = listxattr(path, NULL, 0);
        buf = malloc(buflen);
        buflen = listxattr(path, buf, buflen);
    
    For a file with one attribute (name = '123456'), the first call
    with size = 0 will return buflen = 12 ('user.123456\x00').
    The second call with size = 12, sends LISTXATTRS with
    lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The
    XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count)
    + 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes
    shorter than the lxa_maxcount provided in the call.
    
    Fixes: 04a5da690e8f ("NFSv4.2: define limits and sizes for user xattr handling")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:56:12 2024 -0700

    NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
    
    [ Upstream commit 251a658bbfceafb4d58c76b77682c8bf7bcfad65 ]
    
    A call to listxattr() with a buffer size = 0 returns the actual
    size of the buffer needed for a subsequent call. When size > 0,
    nfs4_listxattr() does not return an error because either
    generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
    exactly all the bytes then size is 0 when calling
    nfs4_listxattr_nfs4_user() which then triggers the following
    kernel BUG:
    
      [   99.403778] kernel BUG at mm/usercopy.c:102!
      [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
      [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
      [   99.415827] Call trace:
      [   99.415985]  usercopy_abort+0x70/0xa0
      [   99.416227]  __check_heap_object+0x134/0x158
      [   99.416505]  check_heap_object+0x150/0x188
      [   99.416696]  __check_object_size.part.0+0x78/0x168
      [   99.416886]  __check_object_size+0x28/0x40
      [   99.417078]  listxattr+0x8c/0x120
      [   99.417252]  path_listxattr+0x78/0xe0
      [   99.417476]  __arm64_sys_listxattr+0x28/0x40
      [   99.417723]  invoke_syscall+0x78/0x100
      [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0
      [   99.418186]  do_el0_svc+0x24/0x38
      [   99.418376]  el0_svc+0x3c/0x110
      [   99.418554]  el0t_64_sync_handler+0x120/0x130
      [   99.418788]  el0t_64_sync+0x194/0x198
      [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
    
    Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
    thus calling lisxattr() with size = 16 will trigger the bug.
    
    Add check on nfs4_listxattr() to return ERANGE error when it is
    called with size > 0 and the return value is greater than size.
    
    Fixes: 012a211abd5d ("NFSv4.2: hook in the user extended attribute handlers")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dave Airlie <[email protected]>
Date:   Thu Mar 14 11:45:21 2024 +1000

    nouveau/gsp: don't check devinit disable on GSP.
    
    [ Upstream commit 5d4e8ae6e57b025802aadf55a4775c55cceb75f1 ]
    
    GSP should be handling this and I can see no evidence in opengpu
    driver that this register should be touched.
    
    Fixed acceleration on 2080 Ti GPUs.
    
    Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
    
    Signed-off-by: Dave Airlie <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dave Airlie <[email protected]>
Date:   Mon Mar 11 17:20:37 2024 +1000

    nouveau: reset the bo resource bus info after an eviction
    
    [ Upstream commit f35c9af45ea7a4b1115b193d84858b14d13517fc ]
    
    Later attempts to refault the bo won't happen and the whole
    GPU does to lunch. I think Christian's refactoring of this
    code out to the driver broke this not very well tested path.
    
    Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver v5")
    Cc: Christian Kц╤nig <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>
    Acked-by: Christian Kц╤nig <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Yingliang <[email protected]>
Date:   Fri Dec 1 11:30:56 2023 +0800

    NTB: fix possible name leak in ntb_register_device()
    
    [ Upstream commit aebfdfe39b9327a3077d0df8db3beb3160c9bdd0 ]
    
    If device_register() fails in ntb_register_device(), the device name
    allocated by dev_set_name() should be freed. As per the comment in
    device_register(), callers should use put_device() to give up the
    reference in the error path. So fix this by calling put_device() in the
    error path so that the name can be freed in kobject_cleanup().
    
    As a result of this, put_device() in the error path of
    ntb_register_device() is removed and the actual error is returned.
    
    Fixes: a1bd3baeb2f1 ("NTB: Add NTB hardware abstraction layer")
    Signed-off-by: Yang Yingliang <[email protected]>
    Reviewed-by: Ilpo Jц╓rvinen <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [mani: reworded commit message]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chunguang Xu <[email protected]>
Date:   Mon Mar 11 10:09:27 2024 +0800

    nvme: fix reconnection fail due to reserved tag allocation
    
    [ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]
    
    We found a issue on production environment while using NVMe over RDMA,
    admin_q reconnect failed forever while remote target and network is ok.
    After dig into it, we found it may caused by a ABBA deadlock due to tag
    allocation. In my case, the tag was hold by a keep alive request
    waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
    request maked as idle and will not process before reset success. As
    fabric_q shares tagset with admin_q, while reconnect remote target, we
    need a tag for connect command, but the only one reserved tag was held
    by keep alive command which waiting inside admin_q. As a result, we
    failed to reconnect admin_q forever. In order to fix this issue, I
    think we should keep two reserved tags for admin queue.
    
    Fixes: ed01fee283a0 ("nvme-fabrics: only reserve a single tag")
    Signed-off-by: Chunguang Xu <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Josh Poimboeuf <[email protected]>
Date:   Mon Feb 26 23:35:27 2024 -0800

    objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks
    
    [ Upstream commit 10b4c4bce3f5541f54bcc2039720b11d2bc96d79 ]
    
    If SAVE and RESTORE unwind hints are in different basic blocks, and
    objtool sees the RESTORE before the SAVE, it errors out with:
    
      vmlinux.o: warning: objtool: vmw_port_hb_in+0x242: objtool isn't smart enough to handle this CFI save/restore combo
    
    In such a case, defer following the RESTORE block until the
    straight-line path gets followed later.
    
    Fixes: 8faea26e6111 ("objtool: Re-add UNWIND_HINT_{SAVE_RESTORE}")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/20240227073527.avcm5naavbv3cj5s@treble
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Linu Cherian <[email protected]>
Date:   Tue Mar 12 12:36:22 2024 +0530

    octeontx2-af: Use matching wake_up API variant in CGX command interface
    
    [ Upstream commit e642921dfeed1e15e73f78f2c3b6746f72b6deb2 ]
    
    Use wake_up API instead of wake_up_interruptible, since
    wait_event_timeout API is used for waiting on command completion.
    
    Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management")
    Signed-off-by: Linu Cherian <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:58 2024 +0530

    octeontx2-af: Use separate handlers for interrupts
    
    [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ]
    
    For PF to AF interrupt vector and VF to AF vector same
    interrupt handler is registered which is causing race condition.
    When two interrupts are raised to two CPUs at same time
    then two cores serve same event corrupting the data.
    
    Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:57 2024 +0530

    octeontx2-pf: Send UP messages to VF only when VF is up.
    
    [ Upstream commit dfcf6355f53b1796cf7fd50a4f27b18ee6a3497a ]
    
    When PF sending link status messages to VF, it is possible
    that by the time link_event_task work function is executed
    VF might have brought down. Hence before sending VF link
    status message check whether VF is up to receive it.
    
    Fixes: ad513ed938c9 ("octeontx2-vf: Link event notification support")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:56 2024 +0530

    octeontx2-pf: Use default max_active works instead of one
    
    [ Upstream commit 7558ce0d974ced1dc07edc1197f750fe28c52e57 ]
    
    Only one execution context for the workqueue used for PF and
    VFs mailbox communication is incorrect since multiple works are
    queued simultaneously by all the VFs and PF link UP messages.
    Hence use default number of execution contexts by passing zero
    as max_active to alloc_workqueue function. With this fix in place,
    modify UP messages also to wait until completion.
    
    Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:55 2024 +0530

    octeontx2-pf: Wait till detach_resources msg is complete
    
    [ Upstream commit cbf2f24939a5dafce6de4dd4422e543ce8f610cf ]
    
    During VF driver remove, a message is sent to detach VF
    resources to PF but VF is not waiting until message is
    complete. Also mailbox interrupts need to be turned off
    after the detach resource message is complete. This patch
    fixes that problem.
    
    Fixes: 05fcc9e08955 ("octeontx2-pf: Attach NIX and NPA block LFs")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:54 2024 +0530

    octeontx2: Detect the mbox up or down message via register
    
    [ Upstream commit a88e0f936ba9a301c78f6eacfd38737d003c130b ]
    
    A single line of interrupt is used to receive up notifications
    and down reply messages from AF to PF (similarly from PF to its VF).
    PF acts as bridge and forwards VF messages to AF and sends respsones
    back from AF to VF. When an async event like link event is received
    by up message when PF is in middle of forwarding VF message then
    mailbox errors occur because PF state machine is corrupted.
    Since VF is a separate driver or VF driver can be in a VM it is
    not possible to serialize from the start of communication at VF.
    Hence to differentiate between type of messages at PF this patch makes
    sender to set mbox data register with distinct values for up and down
    messages. Sender also checks whether previous interrupt is received
    before triggering current interrupt by waiting for mailbox data register
    to become zero.
    
    Fixes: 5a6d7c9daef3 ("octeontx2-pf: Mailbox communication with AF")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viresh Kumar <[email protected]>
Date:   Mon Mar 4 16:48:28 2024 +0530

    OPP: debugfs: Fix warning around icc_get_name()
    
    [ Upstream commit 28330ceb953e39880ea77da4895bb902a1244860 ]
    
    If the kernel isn't built with interconnect support, icc_get_name()
    returns NULL and we get following warning:
    
    drivers/opp/debugfs.c: In function 'bw_name_read':
    drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-Werror=format-overflow=]
             i = scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path));
    
    Fix it.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 0430b1d5704b0 ("opp: Expose bandwidth information via debugfs")
    Signed-off-by: Viresh Kumar <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Feb 21 12:14:03 2024 -0500

    ovl: Always reject mounting over case-insensitive directories
    
    [ Upstream commit 2824083db76cb9d4b7910607b367e93b02912865 ]
    
    overlayfs relies on the filesystem setting DCACHE_OP_HASH or
    DCACHE_OP_COMPARE to reject mounting over case-insensitive directories.
    
    Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their
    d_ops"), we set ->d_op through a hook in ->d_lookup, which
    means the root dentry won't have them, causing the mount to accidentally
    succeed.
    
    In v6.7-rc7, the following sequence will succeed to mount, but any
    dentry other than the root dentry will be a "weird" dentry to ovl and
    fail with EREMOTE.
    
      mkfs.ext4 -O casefold lower.img
      mount -O loop lower.img lower
      mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl /mnt
    
    Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH
    and DCACHE_OP_COMPARE are properly set by ->lookup.
    
    Fix by explicitly rejecting superblocks that allow case-insensitive
    dentries. Yes, this will be solved when we move d_op configuration back
    to ->s_d_op. Yet, we better have an explicit fix to avoid messing up
    again.
    
    While there, re-sort the entries to have more descriptive error messages
    first.
    
    Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops")
    Acked-by: Amir Goldstein <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 14 14:18:16 2024 +0000

    packet: annotate data-races around ignore_outgoing
    
    [ Upstream commit 6ebfad33161afacb3e1e59ed1c2feefef70f9f97 ]
    
    ignore_outgoing is read locklessly from dev_queue_xmit_nit()
    and packet_getsockopt()
    
    Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
    
    syzbot reported:
    
    BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
    
    write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
     packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
     do_sock_setsockopt net/socket.c:2311 [inline]
     __sys_setsockopt+0x1d8/0x250 net/socket.c:2334
     __do_sys_setsockopt net/socket.c:2343 [inline]
     __se_sys_setsockopt net/socket.c:2340 [inline]
     __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
     dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
     xmit_one net/core/dev.c:3527 [inline]
     dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
     __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
     dev_queue_xmit include/linux/netdevice.h:3091 [inline]
     batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
     batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
     batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
     batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
     batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
     worker_thread+0x526/0x730 kernel/workqueue.c:3416
     kthread+0x1d1/0x210 kernel/kthread.c:388
     ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
    
    value changed: 0x00 -> 0x01
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
    
    Fixes: fa788d986a3a ("packet: add sockopt to ignore outgoing packets")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/CANn89i+Z7MfbkBLOv=p7KZ7=K1rKHO4P1OL5LYDCtBiyqsa9oQ@mail.gmail.com/T/#t
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Jason Xing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Max Kellermann <[email protected]>
Date:   Sun Feb 11 23:43:14 2024 +0100

    parisc/ftrace: add missing CONFIG_DYNAMIC_FTRACE check
    
    [ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
    
    Fixes a bug revealed by -Wmissing-prototypes when
    CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
    
     arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for 'ftrace_enable_ftrace_graph_caller' [-Werror=missing-prototypes]
        82 | int ftrace_enable_ftrace_graph_caller(void)
           |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     arch/parisc/kernel/ftrace.c:88:5: error: no previous prototype for 'ftrace_disable_ftrace_graph_caller' [-Werror=missing-prototypes]
        88 | int ftrace_disable_ftrace_graph_caller(void)
           |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Max Kellermann <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilpo Jц╓rvinen <[email protected]>
Date:   Thu Jan 18 13:08:15 2024 +0200

    PCI/DPC: Print all TLP Prefixes, not just the first
    
    [ Upstream commit 6568d82512b0a64809acff3d7a747362fa4288c8 ]
    
    The TLP Prefix Log Register consists of multiple DWORDs (PCIe r6.1 sec
    7.9.14.13) but the loop in dpc_process_rp_pio_error() keeps reading from
    the first DWORD, so we print only the first PIO TLP Prefix (duplicated
    several times), and we never print the second, third, etc., Prefixes.
    
    Add the iteration count based offset calculation into the config read.
    
    Fixes: f20c4ea49ec4 ("PCI/DPC: Add eDPC support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Jц╓rvinen <[email protected]>
    [bhelgaas: add user-visible details to commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Thu Jan 4 20:52:35 2024 +0100

    PCI/P2PDMA: Fix a sleeping issue in a RCU read section
    
    [ Upstream commit 1e5c66afd4a40bb7be17cb33cbb1a1085f727730 ]
    
    It is not allowed to sleep within a RCU read section, so use GFP_ATOMIC
    instead of GFP_KERNEL here.
    
    Link: https://lore.kernel.org/r/02d9ec4a10235def0e764ff1f5be881ba12e16e8.1704397858.git.christophe.jaillet@wanadoo.fr
    Fixes: ae21f835a5bd ("PCI/P2PDMA: Finish RCU conversion of pdev->p2pdma")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonathan Bell <[email protected]>
Date:   Sat Feb 17 14:37:22 2024 +0100

    PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling
    
    [ Upstream commit 039741a8d7c9a01c1bc84a5ac5aa770a5e138a30 ]
    
    The MDIO_WT_DONE() macro tests bit 31, which is always 0 (== done) as
    readw_poll_timeout_atomic() does a 16-bit read. Replace with the readl
    variant.
    
    [kwilczynski: commit log]
    Fixes: ca5dcc76314d ("PCI: brcmstb: Replace status loops with read_poll_timeout_atomic()")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Jonathan Bell <[email protected]>
    Signed-off-by: Stefan Wahren <[email protected]>
    Signed-off-by: Krzysztof Wilczyе└ski <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:14 2024 +0800

    PCI: Make pci_dev_is_disconnected() helper public for other drivers
    
    [ Upstream commit 39714fd73c6b60a8d27bcc5b431afb0828bf4434 ]
    
    Make pci_dev_is_disconnected() public so that it can be called from
    Intel VT-d driver to quickly fix/workaround the surprise removal
    unplug hang issue for those ATS capable devices on PCIe switch downstream
    hotplug capable ports.
    
    Beside pci_device_is_present() function, this one has no config space
    space access, so is light enough to optimize the normal pure surprise
    removal and safe removal flow.
    
    Acked-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Tested-by: Haorong Ye <[email protected]>
    Signed-off-by: Ethan Zhao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jц╤rg Wedekind <[email protected]>
Date:   Mon Feb 19 14:28:11 2024 +0100

    PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
    
    [ Upstream commit baf67aefbe7d7deafa59ca49612d163f8889934c ]
    
    Per PCIe r6.1, sec 2.2.6.2 and 7.5.3.4, a Requester may not use 8-bit Tags
    unless its Extended Tag Field Enable is set, but all Receivers/Completers
    must handle 8-bit Tags correctly regardless of their Extended Tag Field
    Enable.
    
    Some devices do not handle 8-bit Tags as Completers, so add a quirk for
    them.  If we find such a device, we disable Extended Tags for the entire
    hierarchy to make peer-to-peer DMA possible.
    
    The 3ware 9650SE seems to have issues with handling 8-bit tags. Mark it as
    broken.
    
    This fixes PCI Parity Errors like :
    
      3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425
    Signed-off-by: Jц╤rg Wedekind <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Sun Dec 24 15:30:01 2023 +0100

    PCI: switchtec: Fix an error handling path in switchtec_pci_probe()
    
    [ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ]
    
    The commit in Fixes changed the logic on how resources are released and
    introduced a new switchtec_exit_pci() that need to be called explicitly in
    order to undo a corresponding switchtec_init_pci().
    
    This was done in the remove function, but not in the probe.
    
    Fix the probe now.
    
    Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove")
    Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Fri Feb 2 11:32:20 2024 -0300

    perf bpf: Clean up the generated/copied vmlinux.h
    
    [ Upstream commit ffd856537b95dd65facb4e0c78ca1cb92c2048ff ]
    
    When building perf with BPF skels we either copy the minimalistic
    tools/perf/util/bpf_skel/vmlinux/vmlinux.h or use bpftool to generate a
    vmlinux from BTF, storing the result in $(SKEL_OUT)/vmlinux.h.
    
    We need to remove that when doing a 'make -C tools/perf clean', fix it.
    
    Fixes: b7a2d774c9c5a9a3 ("perf build: Add ability to build with a generated vmlinux.h")
    Reviewed-by: Ian Rogers <[email protected]>
    Cc: Andrii Nakryiko <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Tiezhu Yang <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Cc: [email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/Zbz89KK5wHfZ82jv@x1
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Jihong <[email protected]>
Date:   Sat Jan 27 02:57:56 2024 +0000

    perf evsel: Fix duplicate initialization of data->id in evsel__parse_sample()
    
    [ Upstream commit 4962aec0d684c8edb14574ccd0da53e4926ff834 ]
    
    data->id has been initialized at line 2362, remove duplicate initialization.
    
    Fixes: 3ad31d8a0df2 ("perf evsel: Centralize perf_sample initialization")
    Signed-off-by: Yang Jihong <[email protected]>
    Reviewed-by: Arnaldo Carvalho de Melo <[email protected]>
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ian Rogers <[email protected]>
Date:   Fri Feb 9 12:49:45 2024 -0800

    perf expr: Fix "has_event" function for metric style events
    
    [ Upstream commit 6dd76680b925228312756c13b9b983661b552a64 ]
    
    Events in metrics cannot use '/' as a separator, it would be
    recognized as a divide, so they use '@'. The '@' is recognized in the
    metricgroups code and changed to '/', do the same in the has_event
    function so that the parsing is only tried without the @s.
    
    Fixes: 4a4a9bf9075f ("perf expr: Add has_event function")
    Signed-off-by: Ian Rogers <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: K Prateek Nayak <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Kaige Ye <[email protected]>
    Cc: John Garry <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ian Rogers <[email protected]>
Date:   Fri Feb 9 12:49:47 2024 -0800

    perf metric: Don't remove scale from counts
    
    [ Upstream commit 6d6be5eb45b423a37d746d3ee0fd0c78f76ead9f ]
    
    Counts were switched from the scaled saved value form to the
    aggregated count to avoid double accounting. When this happened the
    removing of scaling for a count should have been removed, however, it
    wasn't and this wasn't observed as it normally doesn't matter because
    a counter's scale is 1. A problem was observed with RAPL events that
    are scaled.
    
    Fixes: 37cc8ad77cf8 ("perf metric: Directly use counts rather than saved_value")
    Signed-off-by: Ian Rogers <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: K Prateek Nayak <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Kaige Ye <[email protected]>
    Cc: John Garry <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Sat Aug 26 23:32:45 2023 +0200

    perf pmu: Fix a potential memory leak in perf_pmu__lookup()
    
    [ Upstream commit ef5de1613d7d92bdc975e6beb34bb0fa94f34078 ]
    
    The commit in Fixes has reordered some code, but missed an error handling
    path.
    
    'goto err' now, in order to avoid a memory leak in case of error.
    
    Fixes: f63a536f03a2 ("perf pmu: Merge JSON events with sysfs at load time")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Ian Rogers <[email protected]>
    Cc: [email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/9538b2b634894c33168dfe9d848d4df31fd4d801.1693085544.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ian Rogers <[email protected]>
Date:   Wed Jan 24 15:42:00 2024 -0800

    perf pmu: Treat the msr pmu as software
    
    [ Upstream commit 24852ef2e2d5c555c2da05baff112ea414b6e0f5 ]
    
    The msr PMU is a software one, meaning msr events may be grouped
    with events in a hardware context. As the msr PMU isn't marked as a
    software PMU by perf_pmu__is_software, groups with the msr PMU in
    are broken and the msr events placed in a different group. This
    may lead to multiplexing errors where a hardware event isn't
    counted while the msr event, such as tsc, is. Fix all of this by
    marking the msr PMU as software, which agrees with the driver.
    
    Before:
    ```
    $ perf stat -e '{slots,tsc}' -a true
    WARNING: events were regrouped to match PMUs
    
     Performance counter stats for 'system wide':
    
             1,750,335      slots
             4,243,557      tsc
    
           0.001456717 seconds time elapsed
    ```
    
    After:
    ```
    $ perf stat -e '{slots,tsc}' -a true
     Performance counter stats for 'system wide':
    
            12,526,380      slots
             3,415,163      tsc
    
           0.001488360 seconds time elapsed
    ```
    
    Fixes: 251aa040244a ("perf parse-events: Wildcard most "numeric" events")
    Signed-off-by: Ian Rogers <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Caleb Biggers <[email protected]>
    Cc: Edward Baker <[email protected]>
    Cc: Perry Taylor <[email protected]>
    Cc: Samantha Alt <[email protected]>
    Cc: Weilin Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mark Rutland <[email protected]>
Date:   Fri Jan 26 14:56:05 2024 +0000

    perf print-events: make is_event_supported() more robust
    
    [ Upstream commit 25412c0364f7110faa6053c73e3fd47ca956b8c3 ]
    
    Currently the perf tool doesn't detect support for extended event types
    on Apple M1/M2 systems, and will not auto-expand plain PERF_EVENT_TYPE
    hardware events into per-PMU events. This is due to the detection of
    extended event types not handling mandatory filters required by the
    M1/M2 PMU driver.
    
    PMU drivers and the core perf_events code can require that
    perf_event_attr::exclude_* filters are configured in a specific way and
    may reject certain configurations of filters, for example:
    
    (a) Many PMUs lack support for any event filtering, and require all
        perf_event_attr::exclude_* bits to be clear. This includes Alpha's
        CPU PMU, and ARM CPU PMUs prior to the introduction of PMUv2 in
        ARMv7,
    
    (b) When /proc/sys/kernel/perf_event_paranoid >= 2, the perf core
        requires that perf_event_attr::exclude_kernel is set.
    
    (c) The Apple M1/M2 PMU requires that perf_event_attr::exclude_guest is
        set as the hardware PMU does not count while a guest is running (but
        might be extended in future to do so).
    
    In is_event_supported(), we try to account for cases (a) and (b), first
    attempting to open an event without any filters, and if this fails,
    retrying with perf_event_attr::exclude_kernel set. We do not account for
    case (c), or any other filters that drivers could theoretically require
    to be set.
    
    Thus is_event_supported() will fail to detect support for any events
    targeting an Apple M1/M2 PMU, even where events would be supported with
    perf_event_attr:::exclude_guest set.
    
    Since commit:
    
      82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
    
    ... we use is_event_supported() to detect support for extended types,
    with the PMU ID encoded into the perf_event_attr::type. As above, on an
    Apple M1/M2 system this will always fail to detect that the event is
    supported, and consequently we fail to detect support for extended types
    even when these are supported, as they have been since commit:
    
      5c816728651ae425 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
    
    Due to this, the perf tool will not automatically expand plain
    PERF_TYPE_HARDWARE events into per-PMU events, even when all the
    necessary kernel support is present.
    
    This patch updates is_event_supported() to additionally try opening
    events with perf_event_attr::exclude_guest set, allowing support for
    events to be detected on Apple M1/M2 systems. I believe that this is
    sufficient for all contemporary CPU PMU drivers, though in future it may
    be necessary to check for other combinations of filter bits.
    
    I've deliberately changed the check to not expect a specific error code
    for missing filters, as today ;the kernel may return a number of
    different error codes for missing filters (e.g. -EACCESS, -EINVAL, or
    -EOPNOTSUPP) depending on why and where the filter configuration is
    rejected, and retrying for any error is more robust.
    
    Note that this does not remove the need for commit:
    
      a24d9d9dc096fc0d ("perf parse-events: Make legacy events lower priority than sysfs/JSON")
    
    ... which is still necessary so that named-pmu/event/ events work on
    kernels without extended type support, even if the event name happens to
    be the same as a PERF_EVENT_TYPE_HARDWARE event (e.g. as is the case for
    the M1/M2 PMU's 'cycles' and 'instructions' events).
    
    Fixes: 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
    Signed-off-by: Mark Rutland <[email protected]>
    Tested-by: Ian Rogers <[email protected]>
    Tested-by: James Clark <[email protected]>
    Tested-by: Marc Zyngier <[email protected]>
    Cc: Hector Martin <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: Mike Leach <[email protected]>
    Cc: Suzuki K Poulose <[email protected]>
    Cc: Thomas Richter <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: [email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Jihong <[email protected]>
Date:   Fri Jan 19 04:03:03 2024 +0000

    perf record: Check conflict between '--timestamp-filename' option and pipe mode before recording
    
    [ Upstream commit 02f9b50e04812782fd006ed21c6da1c5e3e373da ]
    
    In pipe mode, no need to switch perf data output, therefore,
    '--timestamp-filename' option should not take effect.
    Check the conflict before recording and output WARNING.
    In this case, the check pipe mode in perf_data__switch() can be removed.
    
    Before:
    
      # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
      # To display the perf.data header info, please use --header/--header-only options.
      #
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Dump -.2024011812110182 ]
      #
      # Total Lost Samples: 0
      #
      # Samples: 4K of event 'cycles:P'
      # Event count (approx.): 2176784359
      #
      # Overhead  Command  Shared Object         Symbol
      # ........  .......  ....................  ......................................
      #
          97.83%  perf     perf                  [.] noploop
    
      #
      # (Tip: Print event counts in CSV format with: perf stat -x,)
      #
    
    After:
    
      # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
      WARNING: --timestamp-filename option is not available in pipe mode.
      # To display the perf.data header info, please use --header/--header-only options.
      #
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.000 MB - ]
      #
      # Total Lost Samples: 0
      #
      # Samples: 4K of event 'cycles:P'
      # Event count (approx.): 2185575421
      #
      # Overhead  Command  Shared Object          Symbol
      # ........  .......  .....................  .............................................
      #
          97.75%  perf     perf                   [.] noploop
    
      #
      # (Tip: Profiling branch (mis)predictions with: perf record -b / perf report)
      #
    
    Fixes: ecfd7a9c044e ("perf record: Add '--timestamp-filename' option to append timestamp to output file name")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Jihong <[email protected]>
Date:   Fri Jan 19 04:03:02 2024 +0000

    perf record: Fix possible incorrect free in record__switch_output()
    
    [ Upstream commit aff10a165201f6f60cff225083ce301ad3f5d8f1 ]
    
    perf_data__switch() may not assign a legal value to 'new_filename'.
    In this case, 'new_filename' uses the on-stack value, which may cause a
    incorrect free and unexpected result.
    
    Fixes: 03724b2e9c45 ("perf record: Allow to limit number of reported perf.data files")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ian Rogers <[email protected]>
Date:   Wed Jan 31 16:15:02 2024 -0800

    perf srcline: Add missed addr2line closes
    
    [ Upstream commit c7ba9d18ae47924a6ea6a47ca139779f58eb83c0 ]
    
    The child_process for addr2line sets in and out to -1 so that pipes
    get created. It is the caller's responsibility to close the pipes,
    finish_command doesn't do it. Add the missed closes.
    
    Fixes: b3801e791231 ("perf srcline: Simplify addr2line subprocess")
    Signed-off-by: Ian Rogers <[email protected]>
    Cc: Ravi Bangoria <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Nick Desaulniers <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Tom Rix <[email protected]>
    Cc: [email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ian Rogers <[email protected]>
Date:   Fri Feb 9 12:49:46 2024 -0800

    perf stat: Avoid metric-only segv
    
    [ Upstream commit 2543947c77e0e224bda86b4e7220c2f6714da463 ]
    
    Cycles is recognized as part of a hard coded metric in stat-shadow.c,
    it may call print_metric_only with a NULL fmt string leading to a
    segfault. Handle the NULL fmt explicitly.
    
    Fixes: 088519f318be ("perf stat: Move the display functions to stat-display.c")
    Signed-off-by: Ian Rogers <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: K Prateek Nayak <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Kaige Ye <[email protected]>
    Cc: John Garry <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yang Jihong <[email protected]>
Date:   Tue Feb 6 08:32:28 2024 +0000

    perf thread_map: Free strlist on normal path in thread_map__new_by_tid_str()
    
    [ Upstream commit 1eb3d924e3c0b8c27388b0583a989d757866efb6 ]
    
    slist needs to be freed in both error path and normal path in
    thread_map__new_by_tid_str().
    
    Fixes: b52956c961be3a04 ("perf tools: Allow multiple threads or processes in record, stat, top")
    Reviewed-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Yang Jihong <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kan Liang <[email protected]>
Date:   Thu Dec 14 06:46:12 2023 -0800

    perf top: Uniform the event name for the hybrid machine
    
    [ Upstream commit a61f89bf76ef6f87ec48dd90dbc73a6cf9952edc ]
    
    It's hard to distinguish the default cycles events among hybrid PMUs.
    For example,
    
      $ perf top
      Available samples
      385 cycles:P
      903 cycles:P
    
    The other tool, e.g., perf record, uniforms the event name and adds the
    hybrid PMU name before opening the event. So the events can be easily
    distinguished. Apply the same methodology for the perf top as well.
    
    The evlist__uniquify_name() will be invoked by both record and top.
    Move it to util/evlist.c
    
    With the patch:
    
      $ perf top
      Available samples
      148 cpu_atom/cycles:P/
      1K cpu_core/cycles:P/
    
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Kan Liang <[email protected]>
    Tested-by: Arnaldo Carvalho de Melo <[email protected]>
    Cc: Hector Martin <[email protected]>
    Cc: Marc Zyngier <[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]>
    Stable-dep-of: 02f9b50e0481 ("perf record: Check conflict between '--timestamp-filename' option and pipe mode before recording")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilkka Koskinen <[email protected]>
Date:   Fri Feb 9 17:11:09 2024 +0000

    perf/arm-cmn: Workaround AmpereOneX errata AC04_MESH_1 (incorrect child count)
    
    [ Upstream commit 50572064ec7109b00eef8880e905f55861c8b3de ]
    
    AmpereOneX mesh implementation has a bug in HN-P nodes that makes them
    report incorrect child count. The failing crosspoints report 8 children
    while they only have two.
    
    When the driver tries to access the inexistent child nodes, it believes it
    has reached an invalid node type and probing fails. The workaround is to
    ignore those incorrect child nodes and continue normally.
    
    Signed-off-by: Ilkka Koskinen <[email protected]>
    [ rm: rewrote simpler generalised version ]
    Tested-by: Ilkka Koskinen <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/ce4b1442135fe03d0de41859b04b268c88c854a3.1707498577.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sandipan Das <[email protected]>
Date:   Mon Jan 29 16:36:26 2024 +0530

    perf/x86/amd/core: Avoid register reset when CPU is dead
    
    [ Upstream commit ad8c91282c95f801c37812d59d2d9eba6899b384 ]
    
    When bringing a CPU online, some of the PMC and LBR related registers
    are reset. The same is done when a CPU is taken offline although that
    is unnecessary. This currently happens in the "cpu_dead" callback which
    is also incorrect as the callback runs on a control CPU instead of the
    one that is being taken offline. This also affects hibernation and
    suspend to RAM on some platforms as reported in the link below.
    
    Fixes: 21d59e3e2c40 ("perf/x86/amd/core: Detect PerfMonV2 support")
    Reported-by: Mario Limonciello <[email protected]>
    Signed-off-by: Sandipan Das <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/550a026764342cf7e5812680e3e2b91fe662b5ac.1706526029.git.sandipan.das@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hojin Nam <[email protected]>
Date:   Fri Feb 16 10:45:22 2024 +0900

    perf: CXL: fix CPMU filter value mask length
    
    [ Upstream commit 802379b8f9e169293e9ba7089e5f1a6340e2e7a3 ]
    
    CPMU filter value is described as 4B length in CXL r3.0 8.2.7.2.2.
    However, it is used as 2B length in code and comments.
    
    Reviewed-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Hojin Nam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fei Wu <[email protected]>
Date:   Wed Feb 28 19:54:25 2024 +0800

    perf: RISCV: Fix panic on pmu overflow handler
    
    [ Upstream commit 34b567868777e9fd39ec5333969728a7f0cf179c ]
    
    (1 << idx) of int is not desired when setting bits in unsigned long
    overflowed_ctrs, use BIT() instead. This panic happens when running
    'perf record -e branches' on sophgo sg2042.
    
    [  273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
    [  273.320851] Oops [#1]
    [  273.323179] Modules linked in:
    [  273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9
    [  273.332521] Hardware name: Sophgo Mango (DT)
    [  273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62
    [  273.342291]  ra : pmu_sbi_ovf_handler+0x2e0/0x34e
    [  273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0
    [  273.354454]  gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978
    [  273.361815]  t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70
    [  273.369180]  s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000
    [  273.376540]  a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015
    [  273.383901]  a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a
    [  273.391327]  s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0
    [  273.398773]  s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210
    [  273.406139]  s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098
    [  273.413660]  s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca
    [  273.421022]  t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8
    [  273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d
    [  273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62
    [  273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee
    [  273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36
    [  273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e
    [  273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74
    [  273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92
    [  273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783
    [  273.477921] ---[ end trace 0000000000000000 ]---
    [  273.482630] Kernel panic - not syncing: Fatal exception in interrupt
    
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Reviewed-by: Atish Patra <[email protected]>
    Signed-off-by: Fei Wu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chen-Yu Tsai <[email protected]>
Date:   Wed Jan 31 15:19:07 2024 +0800

    pinctrl: mediatek: Drop bogus slew rate register range for MT8186
    
    [ Upstream commit 3a29c87548809405bcbc66acc69cbe6f15184d94 ]
    
    The MT8186 does not support configuring pin slew rate. This is evident
    from both the datasheet, and the fact that the driver points the slew
    rate register range at the GPIO direction register range.
    
    Drop the bogus setting.
    
    Fixes: 8b483bda1e46 ("pinctrl: add pinctrl driver on mt8186")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Chen-Yu Tsai <[email protected]>
Date:   Wed Jan 31 15:19:08 2024 +0800

    pinctrl: mediatek: Drop bogus slew rate register range for MT8192
    
    [ Upstream commit e15ab05a6b3ed42f2f43f8bd1a1abdbde64afecd ]
    
    The MT8192 does not support configuring pin slew rate. This is evident
    from both the datasheet, and the fact that the driver points the slew
    rate register range at the GPIO direction register range.
    
    Drop the bogus setting.
    
    Fixes: d32f38f2a8fc ("pinctrl: mediatek: Add pinctrl driver for mt8192")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Feb 21 12:13:59 2024 +0100

    pinctrl: renesas: Allow the compiler to optimize away sh_pfc_pm
    
    [ Upstream commit a6f06b909fee72c679c565adfa7f080f9595e336 ]
    
    The conversion to DEFINE_NOIRQ_DEV_PM_OPS() lost the ability of the
    compiler to optimize away the struct dev_pm_ops object when it is not
    needed.
    
    Fix this by replacing the use of pm_sleep_ptr() by a custom wrapper.
    
    Fixes: 727eb02eb753375e ("pinctrl: renesas: Switch to use DEFINE_NOIRQ_DEV_PM_OPS() helper")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/6238a78e32fa21f0c795406b6cba7bce7af92577.1708513940.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Thu Jan 18 17:32:36 2024 +0100

    pinctrl: renesas: r8a779g0: Add missing SCIF_CLK2 pin group/function
    
    [ Upstream commit 68540257cdf1d07ff8a649aa94c21c5804bbb9b0 ]
    
    R-Car V4H actually has two SCIF_CLK pins.
    The second pin provides the SCIF_CLK signal for HSCIF2 and SCIF4.
    
    Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/6352ec9b63fdd38c2c70d8d203e46f21fbfeccdc.1705589612.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Mon Mar 4 14:43:55 2024 +0100

    platform/x86: p2sb: On Goldmont only cache P2SB and SPI devfn BAR
    
    [ Upstream commit aec7d25b497ce4a8d044e9496de0aa433f7f8f06 ]
    
    On Goldmont p2sb_bar() only ever gets called for 2 devices, the actual P2SB
    devfn 13,0 and the SPI controller which is part of the P2SB, devfn 13,2.
    
    But the current p2sb code tries to cache BAR0 info for all of
    devfn 13,0 to 13,7 . This involves calling pci_scan_single_device()
    for device 13 functions 0-7 and the hw does not seem to like
    pci_scan_single_device() getting called for some of the other hidden
    devices. E.g. on an ASUS VivoBook D540NV-GQ065T this leads to continuous
    ACPI errors leading to high CPU usage.
    
    Fix this by only caching BAR0 info and thus only calling
    pci_scan_single_device() for the P2SB and the SPI controller.
    
    Fixes: 5913320eb0b3 ("platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe")
    Reported-by: Danil Rybakov <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218531
    Tested-by: Danil Rybakov <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Fri Feb 16 21:17:21 2024 +0100

    platform/x86: x86-android-tablets: Fix acer_b1_750_goodix_gpios name
    
    [ Upstream commit 8215ca518164d35f10c0b5545c8bb80f538638b8 ]
    
    The Acer B1 750 tablet used a Novatek NVT-ts touchscreen,
    not a Goodix touchscreen.
    
    Rename acer_b1_750_goodix_gpios to acer_b1_750_nvt_ts_gpios
    to correctly reflect this.
    
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bjorn Andersson <[email protected]>
Date:   Thu Jan 25 13:05:10 2024 -0800

    pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl
    
    [ Upstream commit 883957bee580b723fd87d49ac73e0c84fc03a446 ]
    
    On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is
    handled by an external regulator (max20411). Drop gfx.lvl from the list
    of power-domains exposed on this platform.
    
    Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Acked-by: Ulf Hansson <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Weiц÷schuh <[email protected]>
Date:   Sun Mar 3 16:31:13 2024 +0100

    power: supply: mm8013: fix "not charging" detection
    
    [ Upstream commit cd38a0acca734a1117663d6f0da579d3965b6c93 ]
    
    The charge_behaviours property is meant as a control-knob that can be
    changed by the user.
    
    Page 23 of [0] which documents the flag CHG_INH as follows:
    
      CHG_INH : Charge Inhibit      When the current is more than or equal to charge
                                    threshold current,
                                    charge inhibit temperature (upper/lower limit) О╪ 1
                                    charge permission temperature or the current is
                                    less than charge threshold current О╪ 0
    
    So this is pure read-only information which is better represented as
    POWER_SUPPLY_STATUS_NOT_CHARGING.
    
    [0] https://product.minebeamitsumi.com/en/product/category/ics/battery/fuel_gauge/parts/download/__icsFiles/afieldfile/2023/07/12/1_download_01_12.pdf
    
    Signed-off-by: Thomas Weiц÷schuh <[email protected]>
    Link: https://lore.kernel.org/r/20240303-power_supply-charge_behaviour_prop-v2-1-8ebb0a7c2409@weissschuh.net
    Fixes: e39257cde7e8 ("power: supply: mm8013: Add more properties")
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Lezcano <[email protected]>
Date:   Tue Feb 13 23:39:47 2024 +0100

    powercap: dtpm_cpu: Fix error check against freq_qos_add_request()
    
    [ Upstream commit b50155cb0d609437236c88201206267835c6f965 ]
    
    The caller of the function freq_qos_add_request() checks again a non
    zero value but freq_qos_add_request() can return '1' if the request
    already exists. Therefore, the setup function fails while the QoS
    request actually did not failed.
    
    Fix that by changing the check against a negative value like all the
    other callers of the function.
    
    Fixes: 0e8f68d7f0485 ("Add CPU energy model based support")
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Ellerman <[email protected]>
Date:   Sun Feb 11 14:16:23 2024 -0800

    powerpc/32: fix ADB_CUDA kconfig warning
    
    [ Upstream commit b72c066ba85a131091498a15a62d6068997278a4 ]
    
    Fix a (randconfig) kconfig warning by correcting the select
    statement:
    
    WARNING: unmet direct dependencies detected for ADB_CUDA
      Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && !PPC_PMAC64 [=n]
      Selected by [y]:
      - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] && PPC32 [=y]
    
    The PPC32 isn't needed because ADB depends on (PPC_PMAC && PPC32).
    
    Fixes: a3ef2fef198c ("powerpc/32: Add dependencies of POWER_RESET for pmac32")
    Signed-off-by: Randy Dunlap <[email protected]>
    Tested: Randy Dunlap <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Ellerman <[email protected]>
Date:   Tue Mar 5 23:34:08 2024 +1100

    powerpc/embedded6xx: Fix no previous prototype for avr_uart_send() etc.
    
    [ Upstream commit 20933531be0577cdd782216858c26150dbc7936f ]
    
    Move the prototypes into mpc10x.h which is included by all the relevant
    C files, fixes:
    
      arch/powerpc/platforms/embedded6xx/ls_uart.c:59:6: error: no previous prototype for 'avr_uart_configure'
      arch/powerpc/platforms/embedded6xx/ls_uart.c:82:6: error: no previous prototype for 'avr_uart_send'
    
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kajol Jain <[email protected]>
Date:   Thu Feb 29 17:58:47 2024 +0530

    powerpc/hv-gpci: Fix the H_GET_PERF_COUNTER_INFO hcall return value checks
    
    [ Upstream commit ad86d7ee43b22aa2ed60fb982ae94b285c1be671 ]
    
    Running event hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
    in one of the system throws below error:
    
     ---Logs---
     # perf list | grep hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles
      hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel PMU event]
    
     # perf stat -v -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2
    Using CPUID 00800200
    Control descriptor is not initialized
    Warning:
    hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event is not supported by the kernel.
    failed to read counter hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
    
     Performance counter stats for 'system wide':
    
       <not supported>      hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
    
           2.000700771 seconds time elapsed
    
    The above error is because of the hcall failure as required
    permission "Enable Performance Information Collection" is not set.
    Based on current code, single_gpci_request function did not check the
    error type incase hcall fails and by default returns EINVAL. But we can
    have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER with
    detail_rc as GEN_BUF_TOO_SMALL, for which we need to act accordingly.
    
    Fix this issue by adding new checks in the single_gpci_request and
    h_gpci_event_init functions.
    
    Result after fix patch changes:
    
     # perf stat -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2
    Error:
    No permission to enable hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event.
    
    Fixes: 220a0c609ad1 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface")
    Reported-by: Akanksha J N <[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]>

Author: Qiheng Lin <[email protected]>
Date:   Thu Dec 8 21:34:49 2022 +0800

    powerpc/pseries: Fix potential memleak in papr_get_attr()
    
    [ Upstream commit cda9c0d556283e2d4adaa9960b2dc19b16156bae ]
    
    `buf` is allocated in papr_get_attr(), and krealloc() of `buf`
    could fail. We need to free the original `buf` in the case of failure.
    
    Fixes: 3c14b73454cf ("powerpc/pseries: Interface to represent PAPR firmware attributes")
    Signed-off-by: Qiheng Lin <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe Leroy <[email protected]>
Date:   Tue Feb 13 14:58:37 2024 +0100

    powerpc: Force inlining of arch_vmap_p{u/m}d_supported()
    
    [ Upstream commit c5aebb53b32460bc52680dd4e2a2f6b84d5ea521 ]
    
    arch_vmap_pud_supported() and arch_vmap_pmd_supported() are
    expected to constant-fold to false when RADIX is not enabled.
    
    Force inlining in order to avoid following failure which
    leads to unexpected call of non-existing pud_set_huge() and
    pmd_set_huge() on powerpc 8xx.
    
    In function 'pud_huge_tests',
        inlined from 'debug_vm_pgtable' at mm/debug_vm_pgtable.c:1399:2:
    ./arch/powerpc/include/asm/vmalloc.h:9:33: warning: inlining failed in call to 'arch_vmap_pud_supported.isra': call is unlikely and code size would grow [-Winline]
        9 | #define arch_vmap_pud_supported arch_vmap_pud_supported
          |                                 ^~~~~~~~~~~~~~~~~~~~~~~
    ./arch/powerpc/include/asm/vmalloc.h:10:20: note: in expansion of macro 'arch_vmap_pud_supported'
       10 | static inline bool arch_vmap_pud_supported(pgprot_t prot)
          |                    ^~~~~~~~~~~~~~~~~~~~~~~
    ./arch/powerpc/include/asm/vmalloc.h:9:33: note: called from here
        9 | #define arch_vmap_pud_supported arch_vmap_pud_supported
    mm/debug_vm_pgtable.c:458:14: note: in expansion of macro 'arch_vmap_pud_supported'
      458 |         if (!arch_vmap_pud_supported(args->page_prot) ||
          |              ^~~~~~~~~~~~~~~~~~~~~~~
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 8309c9d71702 ("powerpc: inline huge vmap supported functions")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/bbd84ad52bf377e8d3b5865a906f2dc5d99964ba.1707832677.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:56 2024 +0106

    printk: Add this_cpu_in_panic()
    
    [ Upstream commit 36652d0f3bf34899e82d31a5fa9e2bdd02fd6381 ]
    
    There is already panic_in_progress() and other_cpu_in_panic(),
    but checking if the current CPU is the panic CPU must still be
    open coded.
    
    Add this_cpu_in_panic() to complete the set.
    
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Stable-dep-of: b1c4c67a5e90 ("printk: ringbuffer: Skip non-finalized records in panic")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Wed Feb 7 14:46:51 2024 +0106

    printk: Adjust mapping for 32bit seq macros
    
    [ Upstream commit 418ec1961c07d84293cc3cd54d67b90bbeba7feb ]
    
    Note: This change only applies to 32bit architectures. On 64bit
          architectures the macros are NOPs.
    
    __ulseq_to_u64seq() computes the upper 32 bits of the passed
    argument value (@ulseq). The upper bits are derived from a base
    value (@rb_next_seq) in a way that assumes @ulseq represents a
    64bit number that is less than or equal to @rb_next_seq.
    
    Until now this mapping has been correct for all call sites. However,
    in a follow-up commit, values of @ulseq will be passed in that are
    higher than the base value. This requires a change to how the 32bit
    value is mapped to a 64bit sequence number.
    
    Rather than mapping @ulseq such that the base value is the end of a
    32bit block, map @ulseq such that the base value is in the middle of
    a 32bit block. This allows supporting 31 bits before and after the
    base value, which is deemed acceptable for the console sequence
    number during runtime.
    
    Here is an example to illustrate the previous and new mappings.
    
    For a base value (@rb_next_seq) of 2 2000 0000...
    
    Before this change the range of possible return values was:
    
    1 2000 0001 to 2 2000 0000
    
    __ulseq_to_u64seq(1fff ffff) => 2 1fff ffff
    __ulseq_to_u64seq(2000 0000) => 2 2000 0000
    __ulseq_to_u64seq(2000 0001) => 1 2000 0001
    __ulseq_to_u64seq(9fff ffff) => 1 9fff ffff
    __ulseq_to_u64seq(a000 0000) => 1 a000 0000
    __ulseq_to_u64seq(a000 0001) => 1 a000 0001
    
    After this change the range of possible return values are:
    
    1 a000 0001 to 2 a000 0000
    
    __ulseq_to_u64seq(1fff ffff) => 2 1fff ffff
    __ulseq_to_u64seq(2000 0000) => 2 2000 0000
    __ulseq_to_u64seq(2000 0001) => 2 2000 0001
    __ulseq_to_u64seq(9fff ffff) => 2 9fff ffff
    __ulseq_to_u64seq(a000 0000) => 2 a000 0000
    __ulseq_to_u64seq(a000 0001) => 1 a000 0001
    
    [ john.ogness: Rewrite commit message. ]
    
    Reported-by: Francesco Dolcini <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Petr Mladek <[email protected]>
Date:   Wed Feb 7 14:47:00 2024 +0106

    printk: Disable passing console lock owner completely during panic()
    
    [ Upstream commit d04d5882cd678b898a9d7c5aee6afbe9e6e77fcd ]
    
    The commit d51507098ff91 ("printk: disable optimistic spin
    during panic") added checks to avoid becoming a console waiter
    if a panic is in progress.
    
    However, the transition to panic can occur while there is
    already a waiter. The current owner should not pass the lock to
    the waiter because it might get stopped or blocked anytime.
    
    Also the panic context might pass the console lock owner to an
    already stopped waiter by mistake. It might happen when
    console_flush_on_panic() ignores the current lock owner, for
    example:
    
    CPU0                                CPU1
    ----                                ----
    console_lock_spinning_enable()
                                        console_trylock_spinning()
                                          [CPU1 now console waiter]
    NMI: panic()
      panic_other_cpus_shutdown()
                                        [stopped as console waiter]
      console_flush_on_panic()
        console_lock_spinning_enable()
        [print 1 record]
        console_lock_spinning_disable_and_check()
          [handover to stopped CPU1]
    
    This results in panic() not flushing the panic messages.
    
    Fix these problems by disabling all spinning operations
    completely during panic().
    
    Another advantage is that it prevents possible deadlocks caused
    by "console_owner_lock". The panic() context does not need to
    take it any longer. The lockless checks are safe because the
    functions become NOPs when they see the panic in progress. All
    operations manipulating the state are still synchronized by the
    lock even when non-panic CPUs would notice the panic
    synchronously.
    
    The current owner might stay spinning. But non-panic() CPUs
    would get stopped anyway and the panic context will never start
    spinning.
    
    Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
    Signed-off-by: John Ogness <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:50 2024 +0106

    printk: nbcon: Relocate 32bit seq macros
    
    [ Upstream commit 5b73e706f00f3553e1a4efbb31951ce9fe18f2dc ]
    
    The macros __seq_to_nbcon_seq() and __nbcon_seq_to_seq() are
    used to provide support for atomic handling of sequence numbers
    on 32bit systems. Until now this was only used by nbcon.c,
    which is why they were located in nbcon.c and include nbcon in
    the name.
    
    In a follow-up commit this functionality is also needed by
    printk_ringbuffer. Rather than duplicating the functionality,
    relocate the macros to printk_ringbuffer.h.
    
    Also, since the macros will be no longer nbcon-specific, rename
    them to __u64seq_to_ulseq() and __ulseq_to_u64seq().
    
    This does not result in any functional change.
    
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Stable-dep-of: 5f72e52ba959 ("printk: ringbuffer: Do not skip non-finalized records with prb_next_seq()")
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:57 2024 +0106

    printk: ringbuffer: Cleanup reader terminology
    
    [ Upstream commit 584528d621459d1a5c31da7a591218ad3bb96d6c ]
    
    With the lockless ringbuffer, it is allowed that multiple
    CPUs/contexts write simultaneously into the buffer. This creates
    an ambiguity as some writers will finalize sooner.
    
    The documentation for the prb_read functions is not clear as it
    refers to "not yet written" and "no data available". Clarify the
    return values and language to be in terms of the reader: records
    available for reading.
    
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Stable-dep-of: b1c4c67a5e90 ("printk: ringbuffer: Skip non-finalized records in panic")
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:53 2024 +0106

    printk: ringbuffer: Do not skip non-finalized records with prb_next_seq()
    
    [ Upstream commit 5f72e52ba959e50680b8d83599da1368cd7a6ee2 ]
    
    Commit f244b4dc53e5 ("printk: ringbuffer: Improve
    prb_next_seq() performance") introduced an optimization for
    prb_next_seq() by using best-effort to track recently finalized
    records. However, the order of finalization does not
    necessarily match the order of the records. The optimization
    changed prb_next_seq() to return inconsistent results, possibly
    yielding sequence numbers that are not available to readers
    because they are preceded by non-finalized records or they are
    not yet visible to the reader CPU.
    
    Rather than simply best-effort tracking recently finalized
    records, force the committing writer to read records and
    increment the last "contiguous block" of finalized records. In
    order to do this, the sequence number instead of ID must be
    stored because ID's cannot be directly compared.
    
    A new memory barrier pair is introduced to guarantee that a
    reader can always read the records up until the sequence number
    returned by prb_next_seq() (unless the records have since
    been overwritten in the ringbuffer).
    
    This restores the original functionality of prb_next_seq()
    while also keeping the optimization.
    
    For 32bit systems, only the lower 32 bits of the sequence
    number are stored. When reading the value, it is expanded to
    the full 64bit sequence number using the 32bit seq macros,
    which fold in the value returned by prb_first_seq().
    
    Fixes: f244b4dc53e5 ("printk: ringbuffer: Improve prb_next_seq() performance")
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:59 2024 +0106

    printk: ringbuffer: Skip non-finalized records in panic
    
    [ Upstream commit b1c4c67a5e90db8fbdb5b5504fe16e17b564cca8 ]
    
    Normally a reader will stop once reaching a non-finalized
    record. However, when a panic happens, writers from other CPUs
    (or an interrupted context on the panic CPU) may have been
    writing a record and were unable to finalize it. The panic CPU
    will reserve/commit/finalize its panic records, but these will
    be located after the non-finalized records. This results in
    panic() not flushing the panic messages.
    
    Extend _prb_read_valid() to skip over non-finalized records if
    on the panic CPU.
    
    Fixes: 896fbe20b4e2 ("printk: use the lockless ringbuffer")
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:52 2024 +0106

    printk: Use prb_first_seq() as base for 32bit seq macros
    
    [ Upstream commit 90ad525c2d9a8a6591ab822234a94b82871ef8e0 ]
    
    Note: This change only applies to 32bit architectures. On 64bit
          architectures the macros are NOPs.
    
    Currently prb_next_seq() is used as the base for the 32bit seq
    macros __u64seq_to_ulseq() and __ulseq_to_u64seq(). However, in
    a follow-up commit, prb_next_seq() will need to make use of the
    32bit seq macros.
    
    Use prb_first_seq() as the base for the 32bit seq macros instead
    because it is guaranteed to return 64bit sequence numbers without
    relying on any 32bit seq macros.
    
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Ogness <[email protected]>
Date:   Wed Feb 7 14:46:58 2024 +0106

    printk: Wait for all reserved records with pr_flush()
    
    [ Upstream commit ac7d7844c64d15603daa3e905a311ddcfbb4bc91 ]
    
    Currently pr_flush() will only wait for records that were
    available to readers at the time of the call (using
    prb_next_seq()). But there may be more records (non-finalized)
    that have following finalized records. pr_flush() should wait
    for these to print as well. Particularly because any trailing
    finalized records may be the messages that the calling context
    wants to ensure are printed.
    
    Add a new ringbuffer function prb_next_reserve_seq() to return
    the sequence number following the most recently reserved record.
    This guarantees that pr_flush() will wait until all current
    printk() messages (completed or in progress) have been printed.
    
    Fixes: 3b604ca81202 ("printk: add pr_flush()")
    Signed-off-by: John Ogness <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kees Cook <[email protected]>
Date:   Tue Dec 5 10:26:15 2023 -0800

    pstore: inode: Convert mutex usage to guard(mutex)
    
    [ Upstream commit e2eeddefb046dbc771a6fa426f7f98fb25adfe68 ]
    
    Replace open-coded mutex handling with cleanup.h guard(mutex) and
    scoped_guard(mutex, ...).
    
    Cc: Guilherme G. Piccoli <[email protected]>
    Cc: Tony Luck <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Stable-dep-of: a43e0fc5e913 ("pstore: inode: Only d_invalidate() is needed")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kees Cook <[email protected]>
Date:   Thu Feb 22 09:48:46 2024 -0800

    pstore: inode: Only d_invalidate() is needed
    
    [ Upstream commit a43e0fc5e9134a46515de2f2f8d4100b74e50de3 ]
    
    Unloading a modular pstore backend with records in pstorefs would
    trigger the dput() double-drop warning:
    
      WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
    
    Using the combo of d_drop()/dput() (as mentioned in
    Documentation/filesystems/vfs.rst) isn't the right approach here, and
    leads to the reference counting problem seen above. Use d_invalidate()
    and update the code to not bother checking for error codes that can
    never happen.
    
    Suggested-by: Alexander Viro <[email protected]>
    Fixes: 609e28bb139e ("pstore: Remove filesystem records when backend is unregistered")
    Signed-off-by: Kees Cook <[email protected]>

Author: Uwe Kleine-Kц╤nig <[email protected]>
Date:   Fri Jan 26 13:04:33 2024 +0100

    pwm: atmel-hlcdc: Fix clock imbalance related to suspend support
    
    [ Upstream commit e25ac87d3f831fed002c34aadddaf4ebb4ea45ec ]
    
    The suspend callback disables the periph clock when the PWM is enabled
    and resume reenables this clock if the PWM was disabled before. Judging
    from the code comment it's suspend that is wrong here. Fix accordingly.
    
    Fixes: f9bb9da7c09d ("pwm: atmel-hlcdc: Implement the suspend/resume hooks")
    Reviewed-by: Claudiu Beznea <[email protected]>
    Link: https://lore.kernel.org/r/b51ea92b0a45eff3dc83b08adefd43d930df996c.1706269232.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-Kц╤nig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Uwe Kleine-Kц╤nig <[email protected]>
Date:   Sun Feb 4 22:20:43 2024 +0100

    pwm: sti: Fix capture for st,pwm-num-chan < st,capture-num-chan
    
    [ Upstream commit 5f623835584f1c8d1030666796f40c47a448ce0b ]
    
    The driver only used the number of pwm channels to set the pwm_chip's
    npwm member. The result is that if there are more capture channels than
    PWM channels specified in the device tree, only a part of the capture
    channel is usable. Fix that by passing the bigger channel count to the
    pwm framework. This makes it possible that the .apply() callback is
    called with .hwpwm >= pwm_num_devs, catch that case and return an error
    code.
    
    Fixes: c97267ae831d ("pwm: sti: Add PWM capture callback")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Uwe Kleine-Kц╤nig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wang Jianjian <[email protected]>
Date:   Fri Feb 2 16:18:52 2024 +0800

    quota: Fix potential NULL pointer dereference
    
    [ Upstream commit d0aa72604fbd80c8aabb46eda00535ed35570f1f ]
    
    Below race may cause NULL pointer dereference
    
    P1                                      P2
    dquot_free_inode                        quota_off
                                              drop_dquot_ref
                                               remove_dquot_ref
                                               dquots = i_dquot(inode)
      dquots = i_dquot(inode)
      srcu_read_lock
      dquots[cnt]) != NULL (1)
                                                 dquots[type] = NULL (2)
      spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
       ....
    
    If dquot_free_inode(or other routines) checks inode's quota pointers (1)
    before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
    dereference will be triggered.
    
    So let's fix it by using a temporary pointer to avoid this issue.
    
    Signed-off-by: Wang Jianjian <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Message-Id: <[email protected]>
    Stable-dep-of: 179b8c97ebf6 ("quota: Fix rcu annotations of inode dquot pointers")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jan Kara <[email protected]>
Date:   Tue Feb 6 15:32:09 2024 +0100

    quota: Fix rcu annotations of inode dquot pointers
    
    [ Upstream commit 179b8c97ebf63429589f5afeba59a181fe70603e ]
    
    Dquot pointers in i_dquot array in the inode are protected by
    dquot_srcu. Annotate the array pointers with __rcu, perform the locked
    dereferences with srcu_dereference_check() instead of plain reads, and
    set the array elements with rcu_assign_pointer().
    
    Fixes: b9ba6f94b238 ("quota: remove dqptr_sem")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jan Kara <[email protected]>
Date:   Tue Feb 6 15:08:19 2024 +0100

    quota: Properly annotate i_dquot arrays with __rcu
    
    [ Upstream commit ccb49011bb2ebfd66164dbf68c5bff48917bb5ef ]
    
    Dquots pointed to from i_dquot arrays in inodes are protected by
    dquot_srcu. Annotate them as such and change .get_dquots callback to
    return properly annotated pointer to make sparse happy.
    
    Fixes: b9ba6f94b238 ("quota: remove dqptr_sem")
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Frederic Weisbecker <[email protected]>
Date:   Fri Jan 12 16:46:15 2024 +0100

    rcu/exp: Fix RCU expedited parallel grace period kworker allocation failure recovery
    
    [ Upstream commit a636c5e6f8fc34be520277e69c7c6ee1d4fc1d17 ]
    
    Under CONFIG_RCU_EXP_KTHREAD=y, the nodes initialization for expedited
    grace periods is queued to a kworker. However if the allocation of that
    kworker failed, the nodes initialization is performed synchronously by
    the caller instead.
    
    Now the check for kworker initialization failure relies on the kworker
    pointer to be NULL while its value might actually encapsulate an
    allocation failure error.
    
    Make sure to handle this case.
    
    Reviewed-by: Kalesh Singh <[email protected]>
    Fixes: 9621fbee44df ("rcu: Move expedited grace period (GP) work to RT kthread_worker")
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Reviewed-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Boqun Feng <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Frederic Weisbecker <[email protected]>
Date:   Fri Jan 12 16:46:16 2024 +0100

    rcu/exp: Handle RCU expedited grace period kworker allocation failure
    
    [ Upstream commit e7539ffc9a770f36bacedcf0fbfb4bf2f244f4a5 ]
    
    Just like is done for the kworker performing nodes initialization,
    gracefully handle the possible allocation failure of the RCU expedited
    grace period main kworker.
    
    While at it perform a rename of the related checking functions to better
    reflect the expedited specifics.
    
    Reviewed-by: Kalesh Singh <[email protected]>
    Fixes: 9621fbee44df ("rcu: Move expedited grace period (GP) work to RT kthread_worker")
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Reviewed-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Boqun Feng <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:34 2024 -0700

    rcu: add a helper to report consolidated flavor QS
    
    [ Upstream commit 1a77557d48cff187a169c2aec01c0dd78a5e7e50 ]
    
    When under heavy load, network processing can run CPU-bound for many
    tens of seconds. Even in preemptible kernels (non-RT kernel), this can
    block RCU Tasks grace periods, which can cause trace-event removal to
    take more than a minute, which is unacceptably long.
    
    This commit therefore creates a new helper function that passes through
    both RCU and RCU-Tasks quiescent states every 100 milliseconds. This
    hard-coded value suffices for current workloads.
    
    Suggested-by: Paul E. McKenney <[email protected]>
    Reviewed-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Reviewed-by: Paul E. McKenney <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/r/90431d46ee112d2b0af04dbfe936faaca11810a5.1710877680.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: d6dbbb11247c ("net: report RCU QS on threaded NAPI repolling")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shifeng Li <[email protected]>
Date:   Fri Feb 2 19:53:13 2024 -0800

    RDMA/device: Fix a race between mad_client and cm_client init
    
    [ Upstream commit 7a8bccd8b29c321ac181369b42b04fecf05f98e2 ]
    
    The mad_client will be initialized in enable_device_and_get(), while the
    devices_rwsem will be downgraded to a read semaphore. There is a window
    that leads to the failed initialization for cm_client, since it can not
    get matched mad port from ib_mad_port_list, and the matched mad port will
    be added to the list after that.
    
        mad_client    |                       cm_client
    ------------------|--------------------------------------------------------
    ib_register_device|
    enable_device_and_get
    down_write(&devices_rwsem)
    xa_set_mark(&devices, DEVICE_REGISTERED)
    downgrade_write(&devices_rwsem)
                      |
                      |ib_cm_init
                      |ib_register_client(&cm_client)
                      |down_read(&devices_rwsem)
                      |xa_for_each_marked (&devices, DEVICE_REGISTERED)
                      |add_client_context
                      |cm_add_one
                      |ib_register_mad_agent
                      |ib_get_mad_port
                      |__ib_get_mad_port
                      |list_for_each_entry(entry, &ib_mad_port_list, port_list)
                      |return NULL
                      |up_read(&devices_rwsem)
                      |
    add_client_context|
    ib_mad_init_device|
    ib_mad_port_open  |
    list_add_tail(&port_priv->port_list, &ib_mad_port_list)
    up_read(&devices_rwsem)
                      |
    
    Fix it by using down_write(&devices_rwsem) in ib_register_client().
    
    Fixes: d0899892edd0 ("RDMA/device: Provide APIs from the core code to help unregistration")
    Link: https://lore.kernel.org/r/[email protected]
    Suggested-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Shifeng Li <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Luoyouming <[email protected]>
Date:   Mon Feb 19 14:18:05 2024 +0800

    RDMA/hns: Fix mis-modifying default congestion control algorithm
    
    [ Upstream commit d20a7cf9f714f0763efb56f0f2eeca1cb91315ed ]
    
    Commit 27c5fd271d8b ("RDMA/hns: The UD mode can only be configured
    with DCQCN") adds a check of congest control alorithm for UD. But
    that patch causes a problem: hr_dev->caps.congest_type is global,
    used by all QPs, so modifying this field to DCQCN for UD QPs causes
    other QPs unable to use any other algorithm except DCQCN.
    
    Revert the modification in commit 27c5fd271d8b ("RDMA/hns: The UD
    mode can only be configured with DCQCN"). Add a new field cong_type
    to struct hns_roce_qp and configure DCQCN for UD QPs.
    
    Fixes: 27c5fd271d8b ("RDMA/hns: The UD mode can only be configured with DCQCN")
    Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW")
    Signed-off-by: Luoyouming <[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]>

Author: Mustafa Ismail <[email protected]>
Date:   Wed Jan 31 17:39:53 2024 -0600

    RDMA/irdma: Remove duplicate assignment
    
    [ Upstream commit 926e8ea4b8dac84f6d14a4b60d0653f1f2ba9431 ]
    
    Remove the unneeded assignment of the qp_num which is already
    set in irdma_create_qp().
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Mustafa Ismail <[email protected]>
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Sindhu Devale <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Konstantin Taranov <[email protected]>
Date:   Mon Mar 4 05:52:40 2024 -0800

    RDMA/mana_ib: Fix bug in creation of dma regions
    
    [ Upstream commit e02497fb654689049ba8b46f098f17d5f19e0b3c ]
    
    Use ib_umem_dma_offset() helper to calculate correct dma offset.
    
    Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Leon Romanovsky <[email protected]>
Date:   Sun Jan 28 11:29:11 2024 +0200

    RDMA/mlx5: Fix fortify source warning while accessing Eth segment
    
    [ Upstream commit 4d5e86a56615cc387d21c629f9af8fb0e958d350 ]
    
     ------------[ cut here ]------------
     memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
     WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
     Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
      [last unloaded: mlx_compat(OE)]
     CPU: 0 PID: 293779 Comm: ssh Tainted: G           OE      6.2.0-32-generic #32~22.04.1-Ubuntu
     Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
     RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
     Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
     RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
     RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
     RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
     R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
     FS:  00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      <TASK>
      ? show_regs+0x72/0x90
      ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
      ? __warn+0x8d/0x160
      ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
      ? report_bug+0x1bb/0x1d0
      ? handle_bug+0x46/0x90
      ? exc_invalid_op+0x19/0x80
      ? asm_exc_invalid_op+0x1b/0x20
      ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
      mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
      ipoib_send+0x2ec/0x770 [ib_ipoib]
      ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
      dev_hard_start_xmit+0x8e/0x1e0
      ? validate_xmit_skb_list+0x4d/0x80
      sch_direct_xmit+0x116/0x3a0
      __dev_xmit_skb+0x1fd/0x580
      __dev_queue_xmit+0x284/0x6b0
      ? _raw_spin_unlock_irq+0xe/0x50
      ? __flush_work.isra.0+0x20d/0x370
      ? push_pseudo_header+0x17/0x40 [ib_ipoib]
      neigh_connected_output+0xcd/0x110
      ip_finish_output2+0x179/0x480
      ? __smp_call_single_queue+0x61/0xa0
      __ip_finish_output+0xc3/0x190
      ip_finish_output+0x2e/0xf0
      ip_output+0x78/0x110
      ? __pfx_ip_finish_output+0x10/0x10
      ip_local_out+0x64/0x70
      __ip_queue_xmit+0x18a/0x460
      ip_queue_xmit+0x15/0x30
      __tcp_transmit_skb+0x914/0x9c0
      tcp_write_xmit+0x334/0x8d0
      tcp_push_one+0x3c/0x60
      tcp_sendmsg_locked+0x2e1/0xac0
      tcp_sendmsg+0x2d/0x50
      inet_sendmsg+0x43/0x90
      sock_sendmsg+0x68/0x80
      sock_write_iter+0x93/0x100
      vfs_write+0x326/0x3c0
      ksys_write+0xbd/0xf0
      ? do_syscall_64+0x69/0x90
      __x64_sys_write+0x19/0x30
      do_syscall_64+0x59/0x90
      ? do_user_addr_fault+0x1d0/0x640
      ? exit_to_user_mode_prepare+0x3b/0xd0
      ? irqentry_exit_to_user_mode+0x9/0x20
      ? irqentry_exit+0x43/0x50
      ? exc_page_fault+0x92/0x1b0
      entry_SYSCALL_64_after_hwframe+0x72/0xdc
     RIP: 0033:0x7fc03ad14a37
     Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
     RSP: 002b:00007ffdf8697fe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
     RAX: ffffffffffffffda RBX: 0000000000008024 RCX: 00007fc03ad14a37
     RDX: 0000000000008024 RSI: 0000556f46bd8270 RDI: 0000000000000003
     RBP: 0000556f46bb1800 R08: 0000000000007fe3 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
     R13: 0000556f46bc66b0 R14: 000000000000000a R15: 0000556f46bb2f50
      </TASK>
     ---[ end trace 0000000000000000 ]---
    
    Link: https://lore.kernel.org/r/8228ad34bd1a25047586270f7b1fb4ddcd046282.1706433934.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yishai Hadas <[email protected]>
Date:   Sun Jan 28 11:29:13 2024 +0200

    RDMA/mlx5: Relax DEVX access upon modify commands
    
    [ Upstream commit be551ee1574280ef8afbf7c271212ac3e38933ef ]
    
    Relax DEVX access upon modify commands to be UVERBS_ACCESS_READ.
    
    The kernel doesn't need to protect what firmware protects, or what
    causes no damage to anyone but the user.
    
    As firmware needs to protect itself from parallel access to the same
    object, don't block parallel modify/query commands on the same object in
    the kernel side.
    
    This change will allow user space application to run parallel updates to
    different entries in the same bulk object.
    
    Tested-by: Tamar Mashiah <[email protected]>
    Signed-off-by: Yishai Hadas <[email protected]>
    Reviewed-by: Michael Guralnik <[email protected]>
    Link: https://lore.kernel.org/r/7407d5ed35dc427c1097699e12b49c01e1073406.1706433934.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexey Kodanev <[email protected]>
Date:   Wed Feb 21 11:32:04 2024 +0000

    RDMA/rtrs-clt: Check strnlen return len in sysfs mpath_policy_store()
    
    [ Upstream commit 7a7b7f575a25aa68ee934ee8107294487efcb3fe ]
    
    strnlen() may return 0 (e.g. for "\0\n" string), it's better to
    check the result of strnlen() before using 'len - 1' expression
    for the 'buf' array index.
    
    Detected using the static analysis tool - Svace.
    
    Fixes: dc3b66a0ce70 ("RDMA/rtrs-clt: Add a minimum latency multipath policy")
    Signed-off-by: Alexey Kodanev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Jack Wang <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: William Kucharski <[email protected]>
Date:   Fri Feb 2 02:15:49 2024 -0700

    RDMA/srpt: Do not register event handler until srpt device is fully setup
    
    [ Upstream commit c21a8870c98611e8f892511825c9607f1e2cd456 ]
    
    Upon rare occasions, KASAN reports a use-after-free Write
    in srpt_refresh_port().
    
    This seems to be because an event handler is registered before the
    srpt device is fully setup and a race condition upon error may leave a
    partially setup event handler in place.
    
    Instead, only register the event handler after srpt device initialization
    is complete.
    
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: William Kucharski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yewon Choi <[email protected]>
Date:   Fri Mar 15 18:28:38 2024 +0900

    rds: introduce acquire/release ordering in acquire/release_in_xmit()
    
    [ Upstream commit 1422f28826d2a0c11e5240b3e951c9e214d8656e ]
    
    acquire/release_in_xmit() work as bit lock in rds_send_xmit(), so they
    are expected to ensure acquire/release memory ordering semantics.
    However, test_and_set_bit/clear_bit() don't imply such semantics, on
    top of this, following smp_mb__after_atomic() does not guarantee release
    ordering (memory barrier actually should be placed before clear_bit()).
    
    Instead, we use clear_bit_unlock/test_and_set_bit_lock() here.
    
    Fixes: 0f4b1c7e89e6 ("rds: fix rds_send_xmit() serialization")
    Fixes: 1f9ecd7eacfd ("RDS: Pass rds_conn_path to rds_send_xmit()")
    Signed-off-by: Yewon Choi <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Link: https://lore.kernel.org/r/ZfQUxnNTO9AJmzwc@libra05
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Mar 8 12:01:22 2024 -0800

    rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
    
    [ Upstream commit 2a750d6a5b365265dbda33330a6188547ddb5c24 ]
    
    syzkaller reported a warning of netns tracker [0] followed by KASAN
    splat [1] and another ref tracker warning [1].
    
    syzkaller could not find a repro, but in the log, the only suspicious
    sequence was as follows:
    
      18:26:22 executing program 1:
      r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
      ...
      connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
    
    The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
    
    So, the scenario would be:
    
      1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
          rds_tcp_listen_init().
      2. syz-executor connect()s to it and creates a reqsk.
      3. syz-executor exit()s immediately.
      4. netns is dismantled.  [0]
      5. reqsk timer is fired, and UAF happens while freeing reqsk.  [1]
      6. listener is freed after RCU grace period.  [2]
    
    Basically, reqsk assumes that the listener guarantees netns safety
    until all reqsk timers are expired by holding the listener's refcount.
    However, this was not the case for kernel sockets.
    
    Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
    inet_twsk_purge()") fixed this issue only for per-netns ehash.
    
    Let's apply the same fix for the global ehash.
    
    [0]:
    ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
         sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
         inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
         __sock_create (net/socket.c:1572)
         rds_tcp_listen_init (net/rds/tcp_listen.c:279)
         rds_tcp_init_net (net/rds/tcp.c:577)
         ops_init (net/core/net_namespace.c:137)
         setup_net (net/core/net_namespace.c:340)
         copy_net_ns (net/core/net_namespace.c:497)
         create_new_namespaces (kernel/nsproxy.c:110)
         unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
         ksys_unshare (kernel/fork.c:3429)
         __x64_sys_unshare (kernel/fork.c:3496)
         do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
         entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    ...
    WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
    
    [1]:
    BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
    Read of size 8 at addr ffff88801b370400 by task swapper/0/0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <IRQ>
     dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
     print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
     kasan_report (mm/kasan/report.c:603)
     inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
     reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
     call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
     __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
     run_timer_softirq (kernel/time/timer.c:2053)
     __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
     irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
     </IRQ>
    
    Allocated by task 258 on cpu 0 at 83.612050s:
     kasan_save_stack (mm/kasan/common.c:48)
     kasan_save_track (mm/kasan/common.c:68)
     __kasan_slab_alloc (mm/kasan/common.c:343)
     kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
     copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
     create_new_namespaces (kernel/nsproxy.c:110)
     unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
     ksys_unshare (kernel/fork.c:3429)
     __x64_sys_unshare (kernel/fork.c:3496)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    
    Freed by task 27 on cpu 0 at 329.158864s:
     kasan_save_stack (mm/kasan/common.c:48)
     kasan_save_track (mm/kasan/common.c:68)
     kasan_save_free_info (mm/kasan/generic.c:643)
     __kasan_slab_free (mm/kasan/common.c:265)
     kmem_cache_free (mm/slub.c:4299 mm/slub.c:4363)
     cleanup_net (net/core/net_namespace.c:456 net/core/net_namespace.c:446 net/core/net_namespace.c:639)
     process_one_work (kernel/workqueue.c:2638)
     worker_thread (kernel/workqueue.c:2700 kernel/workqueue.c:2787)
     kthread (kernel/kthread.c:388)
     ret_from_fork (arch/x86/kernel/process.c:153)
     ret_from_fork_asm (arch/x86/entry/entry_64.S:250)
    
    The buggy address belongs to the object at ffff88801b370000
     which belongs to the cache net_namespace of size 4352
    The buggy address is located 1024 bytes inside of
     freed 4352-byte region [ffff88801b370000, ffff88801b371100)
    
    [2]:
    WARNING: CPU: 0 PID: 95 at lib/ref_tracker.c:228 ref_tracker_free (lib/ref_tracker.c:228 (discriminator 1))
    Modules linked in:
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:ref_tracker_free (lib/ref_tracker.c:228 (discriminator 1))
    ...
    Call Trace:
    <IRQ>
     __sk_destruct (./include/net/net_namespace.h:353 net/core/sock.c:2204)
     rcu_core (./arch/x86/include/asm/preempt.h:26 kernel/rcu/tree.c:2165 kernel/rcu/tree.c:2433)
     __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
     irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
    </IRQ>
    
    Reported-by: syzkaller <[email protected]>
    Suggested-by: Eric Dumazet <[email protected]>
    Fixes: 467fa15356ac ("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.")
    Signed-off-by: Kuniyuki Iwashima <[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]>

Author: Mark Brown <[email protected]>
Date:   Sun Feb 11 16:58:17 2024 +0000

    regmap: kunit: Ensure that changed bytes are actually different
    
    [ Upstream commit 2f0dbb24f78a333433a2b875c0b76bf55c119cd4 ]
    
    During the cache sync test we verify that values we expect to have been
    written only to the cache do not appear in the hardware. This works most
    of the time but since we randomly generate both the original and new values
    there is a low probability that these values may actually be the same.
    Wrap get_random_bytes() to ensure that the values are different, there
    are other tests which should have similar verification that we actually
    changed something.
    
    While we're at it refactor the test to use three changed values rather
    than attempting to use one of them twice, that just complicates checking
    that our new values are actually new.
    
    We use random generation to try to avoid data dependencies in the tests.
    
    Reported-by: Guenter Roeck <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Naresh Solanki <[email protected]>
Date:   Tue Feb 13 20:28:00 2024 +0530

    regulator: max5970: Fix regulator child node name
    
    [ Upstream commit e5d40e9afd84cec01cdbbbfe62d52f89959ab3ee ]
    
    Update regulator child node name to lower case i.e., sw0 & sw1 as
    descibed in max5970 dt binding.
    
    Signed-off-by: Naresh Solanki <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: John Keeping <[email protected]>
Date:   Mon Feb 26 16:05:53 2024 +0000

    regulator: userspace-consumer: add module device table
    
    [ Upstream commit 531a0c0cdbff9cecf41073220a826f8b1132f9ab ]
    
    The userspace consumer can be built as a module but it cannot be
    automatically probed as there is no device table to match it up with
    device tree nodes.
    
    Add the missing macro so that the module can load automatically.
    
    Fixes: 5c51d4afcf3fd ("regulator: userspace-consumer: Handle regulator-output DT nodes")
    Signed-off-by: John Keeping <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnaud Pouliquen <[email protected]>
Date:   Wed Jan 17 14:53:12 2024 +0100

    remoteproc: stm32: Fix incorrect type assignment returned by stm32_rproc_get_loaded_rsc_tablef
    
    [ Upstream commit c77b35ce66af25bdd6fde60b62e35b9b316ea5c2 ]
    
    The sparse tool complains about the remove of the _iomem attribute.
    
    stm32_rproc.c:660:17: warning: cast removes address space '__iomem' of expression
    
    Add '__force' to explicitly specify that the cast is intentional.
    This conversion is necessary to cast to addresses pointer,
    which are then managed by the remoteproc core as a pointer to a
    resource_table structure.
    
    Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops")
    Signed-off-by: Arnaud Pouliquen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnaud Pouliquen <[email protected]>
Date:   Wed Jan 17 14:53:11 2024 +0100

    remoteproc: stm32: Fix incorrect type in assignment for va
    
    [ Upstream commit 32381bbccba4c21145c571701f8f7fb1d9b3a92e ]
    
    The sparse tool complains about the attribute conversion between
    a _iomem void * and a void *:
    
    stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected void *va @@     got void [noderef] __iomem * @@
    stm32_rproc.c:122:12: sparse:     expected void *va
    stm32_rproc.c:122:12: sparse:     got void [noderef] __iomem *
    
    Add '__force' to explicitly specify that the cast is intentional.
    This conversion is necessary to cast to virtual addresses pointer,used,
    by the remoteproc core.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver")
    Signed-off-by: Arnaud Pouliquen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Conor Dooley <[email protected]>
Date:   Tue Feb 13 19:45:40 2024 +0000

    riscv: dts: sifive: add missing #interrupt-cells to pmic
    
    [ Upstream commit ce6b6d1513965f500a05f3facf223fa01fd74920 ]
    
    At W=2 dtc complains:
    hifive-unmatched-a00.dts:120.10-238.4: Warning (interrupt_provider): /soc/i2c@10030000/pmic@58: Missing '#interrupt-cells' in interrupt provider
    
    Add the missing property.
    
    Reviewed-by: Samuel Holland <[email protected]>
    Signed-off-by: Conor Dooley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexandre Ghiti <[email protected]>
Date:   Mon Mar 4 09:02:47 2024 +0100

    riscv: Fix compilation error with FAST_GUP and rv32
    
    [ Upstream commit 2bb7e0c49302feec1c2f777bbfe8726169986ed8 ]
    
    By surrounding the definition of pte_leaf_size() with a ifdef napot as
    it should have been.
    
    Fixes: e0fe5ab4192c ("riscv: Fix pte_leaf_size() for NAPOT")
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Reviewed-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]> # build-tested
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Charlie Jenkins <[email protected]>
Date:   Fri Mar 8 10:25:56 2024 -0800

    riscv: Only check online cpus for emulated accesses
    
    [ Upstream commit 313130c62cf1fc410ac8730b291fd4fde582d032 ]
    
    The unaligned access checker only sets valid values for online cpus.
    Check for these values on online cpus rather than on present cpus.
    
    Signed-off-by: Charlie Jenkins <[email protected]>
    Reviewed-by: Conor Dooley <[email protected]>
    Fixes: 71c54b3d169d ("riscv: report misaligned accesses emulation to hwprobe")
    Tested-by: Samuel Holland <[email protected]>
    Link: https://lore.kernel.org/r/20240308-disable_misaligned_probe_config-v9-2-a388770ba0ce@rivosinc.com
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Randy Dunlap <[email protected]>
Date:   Mon Feb 12 21:02:58 2024 -0800

    rtc: mt6397: select IRQ_DOMAIN instead of depending on it
    
    [ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
    
    IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
    it directly thru "make *config", so drivers should select it instead
    of depending on it if they need it.
    Relying on it being set for a dependency is risky.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on" for IRQ_DOMAIN to
    "select" for RTC_DRV_MT6397.
    
    Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
    Cc: Arnd Bergmann <[email protected]>
    Cc: Eddie Huang <[email protected]>
    Cc: Sean Wang <[email protected]>
    Cc: Matthias Brugger <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: Alessandro Zummo <[email protected]>
    Cc: Alexandre Belloni <[email protected]>
    Cc: [email protected]
    Cc: Marc Zyngier <[email protected]>
    Cc: Philipp Zabel <[email protected]>
    Cc: Peter Rosin <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:18 2024 +0800

    rtc: test: Fix invalid format specifier.
    
    [ Upstream commit 8a904a3caa88118744062e872ae90f37748a8fd8 ]
    
    'days' is a s64 (from div_s64), and so should use a %lld specifier.
    
    This was found by extending KUnit's assertion macros to use gcc's
    __printf attribute.
    
    Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add tests.")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Acked-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Carstens <[email protected]>
Date:   Sat Mar 2 20:22:09 2024 +0100

    s390/cache: prevent rebuild of shared_cpu_list
    
    [ Upstream commit cb0cd4ee11142339f2d47eef6db274290b7a482d ]
    
    With commit 36bbc5b4ffab ("cacheinfo: Allow early detection and population
    of cache attributes") the shared cpu list for each cache level higher than
    L1 is rebuilt even if the list already has been set up.
    
    This is caused by the removal of the cpumask_empty() check within
    cache_shared_cpu_map_setup().
    
    However architectures can enforce that the shared cpu list is not rebuilt
    by simply setting cpu_map_populated of the per cpu cache info structure to
    true, which is also the fix for this problem.
    
    Before:
    $ cat /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list
    0-7
    
    After:
    $ cat /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list
    1
    
    Fixes: 36bbc5b4ffab ("cacheinfo: Allow early detection and population of cache attributes")
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miroslav Franc <[email protected]>
Date:   Fri Feb 9 13:45:22 2024 +0100

    s390/dasd: fix double module refcount decrement
    
    [ Upstream commit c3116e62ddeff79cae342147753ce596f01fcf06 ]
    
    Once the discipline is associated with the device, deleting the device
    takes care of decrementing the module's refcount.  Doing it manually on
    this error path causes refcount to artificially decrease on each error
    while it should just stay the same.
    
    Fixes: c020d722b110 ("s390/dasd: fix panic during offline processing")
    Signed-off-by: Miroslav Franc <[email protected]>
    Signed-off-by: Jan Hц╤ppner <[email protected]>
    Signed-off-by: Stefan Haberland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jan Hц╤ppner <[email protected]>
Date:   Thu Feb 8 17:42:48 2024 +0100

    s390/dasd: Use dev_*() for device log messages
    
    [ Upstream commit 79ae56fc475869d636071f66d9e4ef2a3819eee6 ]
    
    All log messages in dasd.c use the printk variants of pr_*(). They all
    add the name of the affected device manually to the log message.
    This can be simplified by using the dev_*() variants of printk, which
    include the device information and make a separate call to dev_name()
    unnecessary.
    
    The KMSG_COMPONENT and the pr_fmt() definition can be dropped. Note that
    this removes the "dasd: " prefix from the one pr_info() call in
    dasd_init(). However, the log message already provides all relevant
    information.
    
    Signed-off-by: Jan Hц╤ppner <[email protected]>
    Reviewed-by: Stefan Haberland <[email protected]>
    Signed-off-by: Stefan Haberland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thomas Richter <[email protected]>
Date:   Thu Jan 18 13:03:39 2024 +0100

    s390/pai: fix attr_event_free upper limit for pai device drivers
    
    [ Upstream commit 225d09d6e5f3870560665a1829d2db79330b4c58 ]
    
    When the device drivers are initialized, a sysfs directory
    is created. This contains many attributes which are allocated with
    kzalloc(). Should it fail, the memory for the attributes already
    created is freed in attr_event_free(). Its second parameter is number
    of attribute elements to delete. This parameter is off by one.
    When i. e. the 10th attribute fails to get created, attributes
    numbered 0 to 9 should be deleted. Currently only attributes
    numbered 0 to 8 are deleted.
    
    Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters")
    Reported-by: Sumanth Korikkar <[email protected]>
    Signed-off-by: Thomas Richter <[email protected]>
    Acked-by: Sumanth Korikkar <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nathan Chancellor <[email protected]>
Date:   Tue Jan 30 20:14:28 2024 -0700

    s390/vdso: drop '-fPIC' from LDFLAGS
    
    [ Upstream commit 0628c03934187be33942580e10bb9afcc61adeed ]
    
    '-fPIC' as an option to the linker does not do what it seems like it
    should. With ld.bfd, it is treated as '-f PIC', which does not make
    sense based on the meaning of '-f':
    
      -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table
    
    When building with ld.lld (currently under review in a GitHub pull
    request), it just errors out because '-f' means nothing and neither does
    '-fPIC':
    
      ld.lld: error: unknown argument '-fPIC'
    
    '-fPIC' was blindly copied from CFLAGS when the vDSO stopped being
    linked with '$(CC)', it should not be needed. Remove it to clear up the
    build failure with ld.lld.
    
    Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")
    Link: https://github.com/llvm/llvm-project/pull/75643
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Fangrui Song <[email protected]>
    Link: https://lore.kernel.org/r/20240130-s390-vdso-drop-fpic-from-ldflags-v1-1-094ad104fc55@kernel.org
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mete Durlu <[email protected]>
Date:   Wed Mar 6 12:31:52 2024 +0100

    s390/vtime: fix average steal time calculation
    
    [ Upstream commit 367c50f78451d3bd7ad70bc5c89f9ba6dec46ca9 ]
    
    Current average steal timer calculation produces volatile and inflated
    values. The only user of this value is KVM so far and it uses that to
    decide whether or not to yield the vCPU which is seeing steal time.
    KVM compares average steal timer to a threshold and if the threshold
    is past then it does not allow CPU polling and yields it to host, else
    it keeps the CPU by polling.
    Since KVM's steal time threshold is very low by default (%10) it most
    likely is not effected much by the bloated average steal timer values
    because the operating region is pretty small. However there might be
    new users in the future who might rely on this number. Fix average
    steal timer calculation by changing the formula from:
    
            avg_steal_timer = avg_steal_timer / 2 + steal_timer;
    
    to the following:
    
            avg_steal_timer = (avg_steal_timer + steal_timer) / 2;
    
    This ensures that avg_steal_timer is actually a naive average of steal
    timer values. It now closely follows steal timer values but of course
    in a smoother manner.
    
    Fixes: 152e9b8676c6 ("s390/vtime: steal time exponential moving average")
    Signed-off-by: Mete Durlu <[email protected]>
    Acked-by: Heiko Carstens <[email protected]>
    Acked-by: Christian Borntraeger <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Keisuke Nishimura <[email protected]>
Date:   Wed Jan 10 14:17:07 2024 +0100

    sched/fair: Take the scheduling domain into account in select_idle_core()
    
    [ Upstream commit 23d04d8c6b8ec339057264659b7834027f3e6a63 ]
    
    When picking a CPU on task wakeup, select_idle_core() has to take
    into account the scheduling domain where the function looks for the CPU.
    
    This is because the "isolcpus" kernel command line option can remove CPUs
    from the domain to isolate them from other SMT siblings.
    
    This change replaces the set of CPUs allowed to run the task from
    p->cpus_ptr by the intersection of p->cpus_ptr and sched_domain_span(sd)
    which is stored in the 'cpus' argument provided by select_idle_cpu().
    
    Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()")
    Signed-off-by: Keisuke Nishimura <[email protected]>
    Signed-off-by: Julia Lawall <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Keisuke Nishimura <[email protected]>
Date:   Wed Jan 10 14:17:06 2024 +0100

    sched/fair: Take the scheduling domain into account in select_idle_smt()
    
    [ Upstream commit 8aeaffef8c6eceab0e1498486fdd4f3dc3b7066c ]
    
    When picking a CPU on task wakeup, select_idle_smt() has to take
    into account the scheduling domain of @target. This is because the
    "isolcpus" kernel command line option can remove CPUs from the domain to
    isolate them from other SMT siblings.
    
    This fix checks if the candidate CPU is in the target scheduling domain.
    
    Commit:
    
      df3cb4ea1fb6 ("sched/fair: Fix wrong cpu selecting from isolated domain")
    
    ... originally introduced this fix by adding the check of the scheduling
    domain in the loop.
    
    However, commit:
    
      3e6efe87cd5cc ("sched/fair: Remove redundant check in select_idle_smt()")
    
    ... accidentally removed the check. Bring it back.
    
    Fixes: 3e6efe87cd5c ("sched/fair: Remove redundant check in select_idle_smt()")
    Signed-off-by: Keisuke Nishimura <[email protected]>
    Signed-off-by: Julia Lawall <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Thu Feb 22 13:44:06 2024 +0100

    scsi: bfa: Fix function pointer type mismatch for hcb_qe->cbfn
    
    [ Upstream commit b69600231f751304db914c63b937f7098ed2895c ]
    
    Some callback functions used here take a boolean argument, others take a
    status argument. This breaks KCFI type checking, so clang now warns about
    the function pointer cast:
    
    drivers/scsi/bfa/bfad_bsg.c:2138:29: error: cast from 'void (*)(void *, enum bfa_status)' to 'bfa_cb_cbfn_t' (aka 'void (*)(void *, enum bfa_boolean)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Assuming the code is actually correct here and the callers always match the
    argument types of the callee, rework this to replace the explicit cast with
    a union of the two pointer types. This does not change the behavior of the
    code, so if something is actually broken here, a larger rework may be
    necessary.
    
    Fixes: 37ea0558b87a ("[SCSI] bfa: Added support to collect and reset fcport stats")
    Fixes: 3ec4f2c8bff2 ("[SCSI] bfa: Added support to configure QOS and collect stats.")
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:05:00 2024 +0100

    scsi: csiostor: Avoid function pointer casts
    
    [ Upstream commit 9f3dbcb5632d6876226031d552ef6163bb3ad215 ]
    
    csiostor uses function pointer casts to keep the csio_ln_ev state machine
    hidden, but this causes warnings about control flow integrity (KCFI)
    violations in clang-16 and higher:
    
    drivers/scsi/csiostor/csio_lnode.c:1098:33: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1098 |         return (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_ready));
          |                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/scsi/csiostor/csio_lnode.c:1369:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1369 |         if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_uninit)) {
          |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/scsi/csiostor/csio_lnode.c:1373:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1373 |         if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_ready)) {
          |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/scsi/csiostor/csio_lnode.c:1377:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1377 |         if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_offline)) {
          |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Move the enum into a shared header so the correct types can be used without
    the need for casts.
    
    Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yihang Li <[email protected]>
Date:   Mon Jan 22 14:25:44 2024 +0800

    scsi: hisi_sas: Fix a deadlock issue related to automatic dump
    
    [ Upstream commit 3c4f53b2c341ec6428b98cb51a89a09b025d0953 ]
    
    If we issue a disabling PHY command, the device attached with it will go
    offline, if a 2 bit ECC error occurs at the same time, a hung task may be
    found:
    
    [ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.
    [ 4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 4613.674809] task:kworker/u256:0  state:D stack:    0 pid:165233 ppid:     2 flags:0x00000208
    [ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]
    [ 4613.691518] Call trace:
    [ 4613.694678]  __switch_to+0xf8/0x17c
    [ 4613.698872]  __schedule+0x660/0xee0
    [ 4613.703063]  schedule+0xac/0x240
    [ 4613.706994]  schedule_timeout+0x500/0x610
    [ 4613.711705]  __down+0x128/0x36c
    [ 4613.715548]  down+0x240/0x2d0
    [ 4613.719221]  hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]
    [ 4613.726618]  sas_execute_internal_abort+0x144/0x310 [libsas]
    [ 4613.732976]  sas_execute_internal_abort_dev+0x44/0x60 [libsas]
    [ 4613.739504]  hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]
    [ 4613.747499]  hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]
    [ 4613.753682]  sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]
    [ 4613.759781]  sas_unregister_common_dev+0x4c/0x7a0 [libsas]
    [ 4613.765962]  sas_destruct_devices+0xb8/0x120 [libsas]
    [ 4613.771709]  sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]
    [ 4613.778930]  sas_revalidate_domain+0x60/0xa4 [libsas]
    [ 4613.784716]  process_one_work+0x248/0x950
    [ 4613.789424]  worker_thread+0x318/0x934
    [ 4613.793878]  kthread+0x190/0x200
    [ 4613.797810]  ret_from_fork+0x10/0x18
    [ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.
    [ 4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 4613.824538] task:kworker/u256:4  state:D stack:    0 pid:316722 ppid:     2 flags:0x00000208
    [ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]
    [ 4613.841491] Call trace:
    [ 4613.844647]  __switch_to+0xf8/0x17c
    [ 4613.848852]  __schedule+0x660/0xee0
    [ 4613.853052]  schedule+0xac/0x240
    [ 4613.856984]  schedule_timeout+0x500/0x610
    [ 4613.861695]  __down+0x128/0x36c
    [ 4613.865542]  down+0x240/0x2d0
    [ 4613.869216]  hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]
    [ 4613.876324]  hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]
    [ 4613.883019]  process_one_work+0x248/0x950
    [ 4613.887732]  worker_thread+0x318/0x934
    [ 4613.892204]  kthread+0x190/0x200
    [ 4613.896118]  ret_from_fork+0x10/0x18
    [ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.
    [ 4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 4613.922852] task:kworker/u256:1  state:D stack:    0 pid:348985 ppid:     2 flags:0x00000208
    [ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]
    [ 4613.939549] Call trace:
    [ 4613.942702]  __switch_to+0xf8/0x17c
    [ 4613.946892]  __schedule+0x660/0xee0
    [ 4613.951083]  schedule+0xac/0x240
    [ 4613.955015]  schedule_timeout+0x500/0x610
    [ 4613.959725]  wait_for_common+0x200/0x610
    [ 4613.964349]  wait_for_completion+0x3c/0x5c
    [ 4613.969146]  flush_workqueue+0x198/0x790
    [ 4613.973776]  sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]
    [ 4613.979960]  sas_port_event_worker+0x54/0xa0 [libsas]
    [ 4613.985708]  process_one_work+0x248/0x950
    [ 4613.990420]  worker_thread+0x318/0x934
    [ 4613.994868]  kthread+0x190/0x200
    [ 4613.998800]  ret_from_fork+0x10/0x18
    
    This is because when the device goes offline, we obtain the hisi_hba
    semaphore and send the ABORT_DEV command to the device. However, the
    internal abort timed out due to the 2 bit ECC error and triggers automatic
    dump. In addition, since the hisi_hba semaphore has been obtained, the dump
    cannot be executed and the controller cannot be reset.
    
    Therefore, the deadlocks occur on the following circular dependencies:
    hisi_sas_dev_gone() -> down() -> hisi_sas_internal_task_abort_dev() -> ...
    -> hisi_sas_internal_abort_timeout() -> down().
    
    The deadlock is triggered only when the timeout occurs during device goes
    offline. To fix this issue, use .rst_ha_timeout to distinguish the scenario
    where a device goes offline from other scenarios.
    
    Fixes: 2ff07b5c6fe9 ("scsi: hisi_sas: Directly call register snapshot instead of using workqueue")
    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]>

Author: Ranjan Kumar <[email protected]>
Date:   Wed Feb 21 12:47:24 2024 +0530

    scsi: mpt3sas: Prevent sending diag_reset when the controller is ready
    
    [ Upstream commit ee0017c3ed8a8abfa4d40e42f908fb38c31e7515 ]
    
    If the driver detects that the controller is not ready before sending the
    first IOC facts command, it will wait for a maximum of 10 seconds for it to
    become ready. However, even if the controller becomes ready within 10
    seconds, the driver will still issue a diagnostic reset.
    
    Modify the driver to avoid sending a diag reset if the controller becomes
    ready within the 10-second wait time.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andrey Grafin <[email protected]>
Date:   Wed Jan 17 16:06:19 2024 +0300

    selftest/bpf: Add map_in_maps with BPF_MAP_TYPE_PERF_EVENT_ARRAY values
    
    [ Upstream commit 40628f9fff73adecac77a9aa390f8016724cad99 ]
    
    Check that bpf_object__load() successfully creates map_in_maps
    with BPF_MAP_TYPE_PERF_EVENT_ARRAY values.
    These changes cover fix in the previous patch
    "libbpf: Apply map_set_def_max_entries() for inner_maps on creation".
    
    A command line output is:
    - w/o fix
    $ sudo ./test_maps
    libbpf: map 'mim_array_pe': failed to create inner map: -22
    libbpf: map 'mim_array_pe': failed to create: Invalid argument(-22)
    libbpf: failed to load object './test_map_in_map.bpf.o'
    Failed to load test prog
    
    - with fix
    $ sudo ./test_maps
    ...
    test_maps: OK, 0 SKIPPED
    
    Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support")
    Signed-off-by: Andrey Grafin <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Acked-by: Hou Tao <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Manu Bretelle <[email protected]>
Date:   Tue Jan 30 21:32:12 2024 -0800

    selftests/bpf: Disable IPv6 for lwt_redirect test
    
    [ Upstream commit 2ef61296d2844c6a4211e07ab70ef2fb412b2c30 ]
    
    After a recent change in the vmtest runner, this test started failing
    sporadically.
    
    Investigation showed that this test was subject to race condition which
    got exacerbated after the vm runner change. The symptoms being that the
    logic that waited for an ICMPv4 packet is naive and will break if 5 or
    more non-ICMPv4 packets make it to tap0.
    When ICMPv6 is enabled, the kernel will generate traffic such as ICMPv6
    router solicitation...
    On a system with good performance, the expected ICMPv4 packet would very
    likely make it to the network interface promptly, but on a system with
    poor performance, those "guarantees" do not hold true anymore.
    
    Given that the test is IPv4 only, this change disable IPv6 in the test
    netns by setting `net.ipv6.conf.all.disable_ipv6` to 1.
    This essentially leaves "ping" as the sole generator of traffic in the
    network namespace.
    If this test was to be made IPv6 compatible, the logic in
    `wait_for_packet` would need to be modified.
    
    In more details...
    
    At a high level, the test does:
    - create a new namespace
    - in `setup_redirect_target` set up lo, tap0, and link_err interfaces as
      well as add 2 routes that attaches ingress/egress sections of
      `test_lwt_redirect.bpf.o` to the xmit path.
    - in `send_and_capture_test_packets` send an ICMP packet and read off
      the tap interface (using `wait_for_packet`) to check that a ICMP packet
      with the right size is read.
    
    `wait_for_packet` will try to read `max_retry` (5) times from the tap0
    fd looking for an ICMPv4 packet matching some criteria.
    
    The problem is that when we set up the `tap0` interface, because IPv6 is
    enabled by default, traffic such as Router solicitation is sent through
    tap0, as in:
    
      # tcpdump -r /tmp/lwt_redirect.pc
      reading from file /tmp/lwt_redirect.pcap, link-type EN10MB (Ethernet)
      04:46:23.578352 IP6 :: > ff02::1:ffc0:4427: ICMP6, neighbor solicitation, who has fe80::fcba:dff:fec0:4427, length 32
      04:46:23.659522 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
      04:46:24.389169 IP 10.0.0.1 > 20.0.0.9: ICMP echo request, id 122, seq 1, length 108
      04:46:24.618599 IP6 fe80::fcba:dff:fec0:4427 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
      04:46:24.619985 IP6 fe80::fcba:dff:fec0:4427 > ff02::2: ICMP6, router solicitation, length 16
      04:46:24.767326 IP6 fe80::fcba:dff:fec0:4427 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
      04:46:28.936402 IP6 fe80::fcba:dff:fec0:4427 > ff02::2: ICMP6, router solicitation, length 16
    
    If `wait_for_packet` sees 5 non-ICMPv4 packets, it will return 0, which is what we see in:
    
      2024-01-31T03:51:25.0336992Z test_lwt_redirect_run:PASS:netns_create 0 nsec
      2024-01-31T03:51:25.0341309Z open_netns:PASS:malloc token 0 nsec
      2024-01-31T03:51:25.0344844Z open_netns:PASS:open /proc/self/ns/net 0 nsec
      2024-01-31T03:51:25.0350071Z open_netns:PASS:open netns fd 0 nsec
      2024-01-31T03:51:25.0353516Z open_netns:PASS:setns 0 nsec
      2024-01-31T03:51:25.0356560Z test_lwt_redirect_run:PASS:setns 0 nsec
      2024-01-31T03:51:25.0360140Z open_tuntap:PASS:open(/dev/net/tun) 0 nsec
      2024-01-31T03:51:25.0363822Z open_tuntap:PASS:ioctl(TUNSETIFF) 0 nsec
      2024-01-31T03:51:25.0367402Z open_tuntap:PASS:fcntl(O_NONBLOCK) 0 nsec
      2024-01-31T03:51:25.0371167Z setup_redirect_target:PASS:open_tuntap 0 nsec
      2024-01-31T03:51:25.0375180Z setup_redirect_target:PASS:if_nametoindex 0 nsec
      2024-01-31T03:51:25.0379929Z setup_redirect_target:PASS:ip link add link_err type dummy 0 nsec
      2024-01-31T03:51:25.0384874Z setup_redirect_target:PASS:ip link set lo up 0 nsec
      2024-01-31T03:51:25.0389678Z setup_redirect_target:PASS:ip addr add dev lo 10.0.0.1/32 0 nsec
      2024-01-31T03:51:25.0394814Z setup_redirect_target:PASS:ip link set link_err up 0 nsec
      2024-01-31T03:51:25.0399874Z setup_redirect_target:PASS:ip link set tap0 up 0 nsec
      2024-01-31T03:51:25.0407731Z setup_redirect_target:PASS:ip route add 10.0.0.0/24 dev link_err encap bpf xmit obj test_lwt_redirect.bpf.o sec redir_ingress 0 nsec
      2024-01-31T03:51:25.0419105Z setup_redirect_target:PASS:ip route add 20.0.0.0/24 dev link_err encap bpf xmit obj test_lwt_redirect.bpf.o sec redir_egress 0 nsec
      2024-01-31T03:51:25.0427209Z test_lwt_redirect_normal:PASS:setup_redirect_target 0 nsec
      2024-01-31T03:51:25.0431424Z ping_dev:PASS:if_nametoindex 0 nsec
      2024-01-31T03:51:25.0437222Z send_and_capture_test_packets:FAIL:wait_for_epacket unexpected wait_for_epacket: actual 0 != expected 1
      2024-01-31T03:51:25.0448298Z (/tmp/work/bpf/bpf/tools/testing/selftests/bpf/prog_tests/lwt_redirect.c:175: errno: Success) test_lwt_redirect_normal egress test fails
      2024-01-31T03:51:25.0457124Z close_netns:PASS:setns 0 nsec
    
    When running in a VM which potential resource contrains, the odds that calling
    `ping` is not scheduled very soon after bringing `tap0` up increases,
    and with this the chances to get our ICMP packet pushed to position 6+
    in the network trace.
    
    To confirm this indeed solves the issue, I ran the test 100 times in a
    row with:
    
      errors=0
      successes=0
      for i in `seq 1 100`
      do
        ./test_progs -t lwt_redirect/lwt_redirect_normal
        if [ $? -eq 0 ]; then
          successes=$((successes+1))
        else
          errors=$((errors+1))
        fi
      done
      echo "successes: $successes/errors: $errors"
    
    While this test would at least fail a couple of time every 10 runs, here
    it ran 100 times with no error.
    
    Fixes: 43a7c3ef8a15 ("selftests/bpf: Add lwt_xmit tests for BPF_REDIRECT")
    Signed-off-by: Manu Bretelle <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Artem Savkov <[email protected]>
Date:   Wed Jan 10 09:57:37 2024 +0100

    selftests/bpf: Fix potential premature unload in bpf_testmod
    
    [ Upstream commit d177c1be06ce28aa8c8710ac55be1b5ad3f314c6 ]
    
    It is possible for bpf_kfunc_call_test_release() to be called from
    bpf_map_free_deferred() when bpf_testmod is already unloaded and
    perf_test_stuct.cnt which it tries to decrease is no longer in memory.
    This patch tries to fix the issue by waiting for all references to be
    dropped in bpf_testmod_exit().
    
    The issue can be triggered by running 'test_progs -t map_kptr' in 6.5,
    but is obscured in 6.6 by d119357d07435 ("rcu-tasks: Treat only
    synchronous grace periods urgently").
    
    Fixes: 65eb006d85a2 ("bpf: Move kernel test kfuncs to bpf_testmod")
    Signed-off-by: Artem Savkov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Martin KaFai Lau <[email protected]>
Date:   Fri Jan 19 22:05:17 2024 -0800

    selftests/bpf: Fix the flaky tc_redirect_dtime test
    
    [ Upstream commit 177f1d083a19af58f4b1206d299ed73689249fd8 ]
    
    BPF CI has been reporting the tc_redirect_dtime test failing
    from time to time:
    
    test_inet_dtime:PASS:setns src 0 nsec
    (network_helpers.c:253: errno: No route to host) Failed to connect to server
    close_netns:PASS:setns 0 nsec
    test_inet_dtime:FAIL:connect_to_fd unexpected connect_to_fd: actual -1 < expected 0
    test_tcp_clear_dtime:PASS:tcp ip6 clear dtime ingress_fwdns_p100 0 nsec
    
    The connect_to_fd failure (EHOSTUNREACH) is from the
    test_tcp_clear_dtime() test and it is the very first IPv6 traffic
    after setting up all the links, addresses, and routes.
    
    The symptom is this first connect() is always slow. In my setup, it
    could take ~3s.
    
    After some tracing and tcpdump, the slowness is mostly spent in
    the neighbor solicitation in the "ns_fwd" namespace while
    the "ns_src" and "ns_dst" are fine.
    
    I forced the kernel to drop the neighbor solicitation messages.
    I can then reproduce EHOSTUNREACH. What actually happen could be:
    - the neighbor advertisement came back a little slow.
    - the "ns_fwd" namespace concluded a neighbor discovery failure
      and triggered the ndisc_error_report() => ip6_link_failure() =>
      icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, 0)
    - the client's connect() reports EHOSTUNREACH after receiving
      the ICMPV6_DEST_UNREACH message.
    
    The neigh table of both "ns_src" and "ns_dst" namespace has already
    been manually populated but not the "ns_fwd" namespace. This patch
    fixes it by manually populating the neigh table also in the "ns_fwd"
    namespace.
    
    Although the namespace configuration part had been existed before
    the tc_redirect_dtime test, still Fixes-tagging the patch when
    the tc_redirect_dtime test was added since it is the only test
    hitting it so far.
    
    Fixes: c803475fd8dd ("bpf: selftests: test skb->tstamp in redirect_neigh")
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shung-Hsi Yu <[email protected]>
Date:   Fri Feb 2 17:55:58 2024 +0800

    selftests/bpf: trace_helpers.c: do not use poisoned type
    
    [ Upstream commit a68b50f47bec8bd6a33b07b7e1562db2553981a7 ]
    
    After commit c698eaebdf47 ("selftests/bpf: trace_helpers.c: Optimize
    kallsyms cache") trace_helpers.c now includes libbpf_internal.h, and
    thus can no longer use the u32 type (among others) since they are poison
    in libbpf_internal.h. Replace u32 with __u32 to fix the following error
    when building trace_helpers.c on powerpc:
    
      error: attempt to use poisoned "u32"
    
    Fixes: c698eaebdf47 ("selftests/bpf: trace_helpers.c: Optimize kallsyms cache")
    Signed-off-by: Shung-Hsi Yu <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Martin KaFai Lau <[email protected]>
Date:   Fri Jan 19 22:05:18 2024 -0800

    selftests/bpf: Wait for the netstamp_needed_key static key to be turned on
    
    [ Upstream commit ce6f6cffaeaa0a3bcdafcae7fe03c68c3afae631 ]
    
    After the previous patch that speeded up the test (by avoiding neigh
    discovery in IPv6), the BPF CI occasionally hits this error:
    
    rcv tstamp unexpected pkt rcv tstamp: actual 0 == expected 0
    
    The test complains about the cmsg returned from the recvmsg() does not
    have the rcv timestamp. Setting skb->tstamp or not is
    controlled by a kernel static key "netstamp_needed_key". The static
    key is enabled whenever this is at least one sk with the SOCK_TIMESTAMP
    set.
    
    The test_redirect_dtime does use setsockopt() to turn on
    the SOCK_TIMESTAMP for the reading sk. In the kernel
    net_enable_timestamp() has a delay to enable the "netstamp_needed_key"
    when CONFIG_JUMP_LABEL is set. This potential delay is the likely reason
    for packet missing rcv timestamp occasionally.
    
    This patch is to create udp sockets with SOCK_TIMESTAMP set.
    It sends and receives some packets until the received packet
    has a rcv timestamp. It currently retries at most 5 times with 1s
    in between. This should be enough to wait for the "netstamp_needed_key".
    It then holds on to the socket and only closes it at the end of the test.
    This guarantees that the test has the "netstamp_needed_key" key turned
    on from the beginning.
    
    To simplify the udp sockets setup, they are sending/receiving packets
    in the same netns (ns_dst is used) and communicate over the "lo" dev.
    Hence, the patch enables the "lo" dev in the ns_dst.
    
    Fixes: c803475fd8dd ("bpf: selftests: test skb->tstamp in redirect_neigh")
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Petr Machata <[email protected]>
Date:   Fri Jan 26 17:36:16 2024 +0100

    selftests: forwarding: Add missing config entries
    
    [ Upstream commit 4acf4e62cd572b0c806035046b3698f5585ab821 ]
    
    The config file contains a partial kernel configuration to be used by
    `virtme-configkernel --custom'. The presumption is that the config file
    contains all Kconfig options needed by the selftests from the directory.
    
    In net/forwarding/config, many are missing, which manifests as spurious
    failures when running the selftests, with messages about unknown device
    types, qdisc kinds or classifier actions. Add the missing configurations.
    
    Tested the resulting configuration using virtme-ng as follows:
    
     # vng -b -f tools/testing/selftests/net/forwarding/config
     # vng --user root
     (within the VM:)
     # make -C tools/testing/selftests TARGETS=net/forwarding run_tests
    
    Signed-off-by: Petr Machata <[email protected]>
    Link: https://lore.kernel.org/r/025abded7ff9cea5874a7fe35dcd3fd41bf5e6ac.1706286755.git.petrm@nvidia.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: f0ddf15f0a74 ("selftests: forwarding: Add missing multicast routing config entries")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Thu Feb 8 18:55:38 2024 +0200

    selftests: forwarding: Add missing multicast routing config entries
    
    [ Upstream commit f0ddf15f0a74c27eb4b2271a90e69948acc3fa2c ]
    
    The two tests that make use of multicast routig (router.sh and
    router_multicast.sh) are currently failing in the netdev CI because the
    kernel is missing multicast routing support.
    
    Fix by adding the required config entries.
    
    Fixes: 6d4efada3b82 ("selftests: forwarding: Add multicast routing test")
    Signed-off-by: Ido Schimmel <[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]>

Author: Ido Schimmel <[email protected]>
Date:   Wed Mar 20 08:57:17 2024 +0200

    selftests: forwarding: Fix ping failure due to short timeout
    
    [ Upstream commit e4137851d4863a9bdc6aabc613bcb46c06d91e64 ]
    
    The tests send 100 pings in 0.1 second intervals and force a timeout of
    11 seconds, which is borderline (especially on debug kernels), resulting
    in random failures in netdev CI [1].
    
    Fix by increasing the timeout to 20 seconds. It should not prolong the
    test unless something is wrong, in which case the test will rightfully
    fail.
    
    [1]
     # selftests: net/forwarding: vxlan_bridge_1d_port_8472_ipv6.sh
     # INFO: Running tests with UDP port 8472
     # TEST: ping: local->local                                            [ OK ]
     # TEST: ping: local->remote 1                                         [FAIL]
     # Ping failed
     [...]
    
    Fixes: b07e9957f220 ("selftests: forwarding: Add VxLAN tests with a VLAN-unaware bridge for IPv6")
    Fixes: 728b35259e28 ("selftests: forwarding: Add VxLAN tests with a VLAN-aware bridge for IPv6")
    Reported-by: Paolo Abeni <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aaron Conole <[email protected]>
Date:   Wed Feb 7 08:24:16 2024 -0500

    selftests: openvswitch: Add validation for the recursion test
    
    [ Upstream commit bd128f62c365504e1268dc09fcccdfb1f091e93a ]
    
    Add a test case into the netlink checks that will show the number of
    nested action recursions won't exceed 16.  Going to 17 on a small
    clone call isn't enough to exhaust the stack on (most) systems, so
    it should be safe to run even on systems that don't have the fix
    applied.
    
    Signed-off-by: Aaron Conole <[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]>

Author: Jakub Kicinski <[email protected]>
Date:   Tue Feb 6 17:18:23 2024 -0800

    selftests: tls: use exact comparison in recv_partial
    
    [ Upstream commit 49d821064c44cb5ffdf272905236012ea9ce50e3 ]
    
    This exact case was fail for async crypto and we weren't
    catching it.
    
    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]>

Author: Andy Shevchenko <[email protected]>
Date:   Mon Feb 19 17:04:57 2024 +0200

    serial: 8250_exar: Don't remove GPIO device on suspend
    
    [ Upstream commit 73b5a5c00be39e23b194bad10e1ea8bb73eee176 ]
    
    It seems a copy&paste mistake that suspend callback removes the GPIO
    device. There is no counterpart of this action, means once suspended
    there is no more GPIO device available untile full unbind-bind cycle
    is performed. Remove suspicious GPIO device removal in suspend.
    
    Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hugo Villeneuve <[email protected]>
Date:   Thu Jan 18 10:22:01 2024 -0500

    serial: max310x: fix syntax error in IRQ error message
    
    [ Upstream commit 8ede8c6f474255b2213cccd7997b993272a8e2f9 ]
    
    Replace g with q.
    
    Helpful when grepping thru source code or logs for
    "request" keyword.
    
    Fixes: f65444187a66 ("serial: New serial driver MAX310X")
    Reviewed-by: Andy Shevchenko <[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]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Matthew Wilcox (Oracle) <[email protected]>
Date:   Wed Nov 8 20:46:04 2023 +0000

    smb: do not test the return value of folio_start_writeback()
    
    [ Upstream commit a9540e35624d1475f47dbf6353eed8b99936d36e ]
    
    In preparation for removing the return value entirely, stop testing it
    in smb.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
    Cc: David Howells <[email protected]>
    Cc: Steve French <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: f3dc1bdb6b0b ("cifs: Fix writeback data corruption")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 9 20:34:36 2024 +0100

    soc: fsl: dpio: fix kcalloc() argument order
    
    [ Upstream commit 72ebb41b88f9d7c10c5e159e0507074af0a22fe2 ]
    
    A previous bugfix added a call to kcalloc(), which starting in gcc-14
    causes a harmless warning about the argument order:
    
    drivers/soc/fsl/dpio/dpio-service.c: In function 'dpaa2_io_service_enqueue_multiple_desc_fq':
    drivers/soc/fsl/dpio/dpio-service.c:526:29: error: 'kcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
      526 |         ed = kcalloc(sizeof(struct qbman_eq_desc), 32, GFP_KERNEL);
          |                             ^~~~~~
    drivers/soc/fsl/dpio/dpio-service.c:526:29: note: earlier argument should specify number of elements, later size of each element
    
    Since the two are only multiplied, the order does not change the
    behavior, so just fix it now to shut up the compiler warning.
    
    Dmity independently came up with the same fix.
    
    Fixes: 5c4a5999b245 ("soc: fsl: dpio: avoid stack usage warning")
    Reported-by: Dmitry Antipov <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Jan 22 16:04:14 2024 +0100

    soc: microchip: Fix POLARFIRE_SOC_SYS_CTRL input prompt
    
    [ Upstream commit 6dd9a236042e305d7b69ee92db7347bf5943e7d3 ]
    
    The symbol's prompt should be a one-line description, instead of just
    duplicating the symbol name.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Conor Dooley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Unnathi Chalicheemala <[email protected]>
Date:   Mon Feb 12 10:35:15 2024 -0800

    soc: qcom: llcc: Check return value on Broadcast_OR reg read
    
    [ Upstream commit ceeaddc19a90039861564d8e1078b778a8f95101 ]
    
    Commit c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support")
    introduced a new 4.1 if statement in llcc_update_act_ctrl() without
    considering that ret might be overwritten. So, add return value check
    after Broadcast_OR register read in llcc_update_act_ctrl().
    
    Fixes: c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support")
    Signed-off-by: Unnathi Chalicheemala <[email protected]>
    Reviewed-by: Elliot Berman <[email protected]>
    Reviewed-by: Mukesh Ojha <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johan Hovold <[email protected]>
Date:   Fri Mar 8 10:03:57 2024 +0100

    soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
    
    commit b979f2d50a099f3402418d7ff5f26c3952fb08bb upstream.
    
    A recent DRM series purporting to simplify support for "transparent
    bridges" and handling of probe deferrals ironically exposed a
    use-after-free issue on pmic_glink_altmode probe deferral.
    
    This has manifested itself as the display subsystem occasionally failing
    to initialise and NULL-pointer dereferences during boot of machines like
    the Lenovo ThinkPad X13s.
    
    Specifically, the dp-hpd bridge is currently registered before all
    resources have been acquired which means that it can also be
    deregistered on probe deferrals.
    
    In the meantime there is a race window where the new aux bridge driver
    (or PHY driver previously) may have looked up the dp-hpd bridge and
    stored a (non-reference-counted) pointer to the bridge which is about to
    be deallocated.
    
    When the display controller is later initialised, this triggers a
    use-after-free when attaching the bridges:
    
            dp -> aux -> dp-hpd (freed)
    
    which may, for example, result in the freed bridge failing to attach:
    
            [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16
    
    or a NULL-pointer dereference:
    
            Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
            ...
            Call trace:
              drm_bridge_attach+0x70/0x1a8 [drm]
              drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
              drm_bridge_attach+0x80/0x1a8 [drm]
              dp_bridge_init+0xa8/0x15c [msm]
              msm_dp_modeset_init+0x28/0xc4 [msm]
    
    The DRM bridge implementation is clearly fragile and implicitly built on
    the assumption that bridges may never go away. In this case, the fix is
    to move the bridge registration in the pmic_glink_altmode driver to
    after all resources have been looked up.
    
    Incidentally, with the new dp-hpd bridge implementation, which registers
    child devices, this is also a requirement due to a long-standing issue
    in driver core that can otherwise lead to a probe deferral loop (see
    commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).
    
    [DB: slightly fixed commit message by adding the word 'commit']
    Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support")
    Fixes: 2bcca96abfbf ("soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE")
    Cc: <[email protected]>      # 6.3
    Cc: Bjorn Andersson <[email protected]>
    Cc: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    [ johan: backport to 6.7 which does not have DRM aux bridge ]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Jan 28 03:32:44 2024 +0200

    soc: qcom: socinfo: rename PM2250 to PM4125
    
    [ Upstream commit 5155e48128826d0c5999dc9f47aa746df54da448 ]
    
    It seems, the only actual mentions of PM2250 can be found are related to
    the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a
    PMIC name. Rename PM2250 to PM4125 to follow the documentation.
    
    Fixes: 082f9bc60f33 ("soc: qcom: spmi-pmic: add more PMIC SUBTYPE IDs")
    Fixes: 112d96fd2927 ("soc: qcom: socinfo: Add some PMICs")
    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]>

Author: Eric Dumazet <[email protected]>
Date:   Mon Jan 22 11:25:55 2024 +0000

    sock_diag: annotate data-races around sock_diag_handlers[family]
    
    [ Upstream commit efd402537673f9951992aea4ef0f5ff51d858f4b ]
    
    __sock_diag_cmd() and sock_diag_bind() read sock_diag_handlers[family]
    without a lock held.
    
    Use READ_ONCE()/WRITE_ONCE() annotations to avoid potential issues.
    
    Fixes: 8ef874bfc729 ("sock_diag: Move the sock_ code to net/core/")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Guillaume Nault <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sam Ravnborg <[email protected]>
Date:   Sat Feb 24 18:42:28 2024 +0100

    sparc32: Fix section mismatch in leon_pci_grpci
    
    [ Upstream commit 24338a6ae13cb743ced77da1b3a12c83f08a0c96 ]
    
    Passing a datastructre marked _initconst to platform_driver_register()
    is wrong. Drop the __initconst notation.
    
    This fixes the following warnings:
    
    WARNING: modpost: vmlinux: section mismatch in reference: grpci1_of_driver+0x30 (section: .data) -> grpci1_of_match (section: .init.rodata)
    WARNING: modpost: vmlinux: section mismatch in reference: grpci2_of_driver+0x30 (section: .data) -> grpci2_of_match (section: .init.rodata)
    
    Signed-off-by: Sam Ravnborg <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Cc: Andreas Larsson <[email protected]>
    Fixes: 4154bb821f0b ("sparc: leon: grpci1: constify of_device_id")
    Fixes: 03949b1cb9f1 ("sparc: leon: grpci2: constify of_device_id")
    Tested-by: Randy Dunlap <[email protected]> # build-tested
    Reviewed-by: Andreas Larsson <[email protected]>
    Tested-by: Andreas Larsson <[email protected]>
    Signed-off-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20240224-sam-fix-sparc32-all-builds-v2-7-1f186603c5c4@ravnborg.org
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thц╘o Lebrun <[email protected]>
Date:   Thu Feb 22 11:12:32 2024 +0100

    spi: cadence-qspi: add system-wide suspend and resume callbacks
    
    [ Upstream commit 078d62de433b4f4556bb676e5dd670f0d4103376 ]
    
    Each SPI controller is expected to call the spi_controller_suspend() and
    spi_controller_resume() callbacks at system-wide suspend and resume.
    
    It (1) handles the kthread worker for queued controllers and (2) marks
    the controller as suspended to have spi_sync() fail while the
    controller is unavailable.
    
    Those two operations do not require the controller to be active, we do
    not need to increment the runtime PM usage counter.
    
    Signed-off-by: Thц╘o Lebrun <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Thц╘o Lebrun <[email protected]>
Date:   Thu Feb 22 11:12:31 2024 +0100

    spi: cadence-qspi: put runtime in runtime PM hooks names
    
    [ Upstream commit 4efa1250b59ebf47ce64a7b6b7c3e2e0a2a9d35a ]
    
    Follow kernel naming convention with regards to power-management
    callback function names.
    
    The convention in the kernel is:
     - prefix_suspend means the system-wide suspend callback;
     - prefix_runtime_suspend means the runtime PM suspend callback.
    The same applies to resume callbacks.
    
    Signed-off-by: Thц╘o Lebrun <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mika Westerberg <[email protected]>
Date:   Mon Feb 12 10:20:27 2024 +0200

    spi: intel-pci: Add support for Lunar Lake-M SPI serial flash
    
    [ Upstream commit 8f44e3808200c1434c26ef459722f88f48b306df ]
    
    Add Intel Lunar Lake-M PCI ID to the driver list of supported devices.
    This is the same controller found in previous generations.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexander Sverdlin <[email protected]>
Date:   Tue Mar 12 12:20:48 2024 +0100

    spi: lpspi: Avoid potential use-after-free in probe()
    
    [ Upstream commit 2ae0ab0143fcc06190713ed81a6486ed0ad3c861 ]
    
    fsl_lpspi_probe() is allocating/disposing memory manually with
    spi_alloc_host()/spi_alloc_target(), but uses
    devm_spi_register_controller(). In case of error after the latter call the
    memory will be explicitly freed in the probe function by
    spi_controller_put() call, but used afterwards by "devm" management outside
    probe() (spi_unregister_controller() <- devm_spi_unregister() below).
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
    ...
    Call trace:
     kernfs_find_ns
     kernfs_find_and_get_ns
     sysfs_remove_group
     sysfs_remove_groups
     device_remove_attrs
     device_del
     spi_unregister_controller
     devm_spi_unregister
     release_nodes
     devres_release_all
     really_probe
     driver_probe_device
     __device_attach_driver
     bus_for_each_drv
     __device_attach
     device_initial_probe
     bus_probe_device
     deferred_probe_work_func
     process_one_work
     worker_thread
     kthread
     ret_from_fork
    
    Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver")
    Signed-off-by: Alexander Sverdlin <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Adam Butcher <[email protected]>
Date:   Mon Mar 18 17:50:52 2024 +0000

    spi: spi-imx: fix off-by-one in mx51 CPU mode burst length
    
    [ Upstream commit cf6d79a0f5769b5f4d9579ddaf88d2c30b03b873 ]
    
    c712c05e46c8 ("spi: imx: fix the burst length at DMA mode and CPU mode")
    corrects three cases of setting the ECSPI burst length but erroneously
    leaves the in-range CPU case one bit to big (in that field a value of
    0 means 1 bit).  The effect was that transmissions that should have been
    8-bit bytes appeared as 9-bit causing failed communication with SPI
    devices.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: c712c05e46c8 ("spi: imx: fix the burst length at DMA mode and CPU mode")
    Signed-off-by: Adam Butcher <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Fei Shao <[email protected]>
Date:   Thu Mar 21 15:08:57 2024 +0800

    spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
    
    [ Upstream commit a20ad45008a7c82f1184dc6dee280096009ece55 ]
    
    The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
    handler may end up writing to the invalid memory and cause crashes.
    
    Add a check to trans->tx_buf before using it.
    
    Fixes: 1ce24864bff4 ("spi: mediatek: Only do dma for 4-byte aligned buffers")
    Signed-off-by: Fei Shao <[email protected]>
    Reviewed-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]>

Author: Chen Ni <[email protected]>
Date:   Tue Mar 5 07:59:27 2024 +0000

    sr9800: Add check for usbnet_get_endpoints
    
    [ Upstream commit 07161b2416f740a2cb87faa5566873f401440a61 ]
    
    Add check for usbnet_get_endpoints() and return the error if it fails
    in order to transfer the error.
    
    Signed-off-by: Chen Ni <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Dan Carpenter <[email protected]>
Date:   Mon Mar 4 10:04:48 2024 +0300

    staging: greybus: fix get_channel_from_mode() failure path
    
    [ Upstream commit 34164202a5827f60a203ca9acaf2d9f7d432aac8 ]
    
    The get_channel_from_mode() function is supposed to return the channel
    which matches the mode.  But it has a bug where if it doesn't find a
    matching channel then it returns the last channel.  It should return
    NULL instead.
    
    Also remove an unnecessary NULL check on "channel".
    
    Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Rui Miguel Silva <[email protected]>
    Reviewed-by: Alex Elder <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhipeng Lu <[email protected]>
Date:   Sun Dec 24 16:20:33 2023 +0800

    SUNRPC: fix a memleak in gss_import_v2_context
    
    [ Upstream commit e67b652d8e8591d3b1e569dbcdfcee15993e91fa ]
    
    The ctx->mech_used.data allocated by kmemdup is not freed in neither
    gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
    which frees ctx on error.
    
    Thus, this patch reform the last call of gss_import_v2_context to the
    gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
    formation.
    
    Fixes: 47d848077629 ("gss_krb5: handle new context format from gssd")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhipeng Lu <[email protected]>
Date:   Tue Jan 2 13:38:13 2024 +0800

    SUNRPC: fix some memleaks in gssx_dec_option_array
    
    [ Upstream commit 3cfcfc102a5e57b021b786a755a38935e357797d ]
    
    The creds and oa->data need to be freed in the error-handling paths after
    their allocation. So this patch add these deallocations in the
    corresponding paths.
    
    Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:49 2024 +0000

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

Author: Eric Dumazet <[email protected]>
Date:   Fri Mar 8 12:01:21 2024 -0800

    tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge()
    
    [ Upstream commit 1c4e97dd2d3c9a3e84f7e26346aa39bc426d3249 ]
    
    inet_twsk_purge() uses rcu to find TIME_WAIT and NEW_SYN_RECV
    objects to purge.
    
    These objects use SLAB_TYPESAFE_BY_RCU semantic and need special
    care. We need to use refcount_inc_not_zero(&sk->sk_refcnt).
    
    Reuse the existing correct logic I wrote for TIME_WAIT,
    because both structures have common locations for
    sk_state, sk_family, and netns pointer.
    
    If after the refcount_inc_not_zero() the object fields longer match
    the keys, use sock_gen_put(sk) to release the refcount.
    
    Then we can call inet_twsk_deschedule_put() for TIME_WAIT,
    inet_csk_reqsk_queue_drop_and_put() for NEW_SYN_RECV sockets,
    with BH disabled.
    
    Then we need to restart the loop because we had drop rcu_read_lock().
    
    Fixes: 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inet_twsk_purge()")
    Link: https://lore.kernel.org/netdev/CANn89iLvFuuihCtt9PME2uS1WJATnf5fKjDToa1WzVnRzHnPfg@mail.gmail.com/T/#u
    Signed-off-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]>

Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Mar 8 12:16:23 2024 -0800

    tcp: Fix refcnt handling in __inet_hash_connect().
    
    [ Upstream commit 04d9d1fc428ac9f581d55118d67e0cb546701feb ]
    
    syzbot reported a warning in sk_nulls_del_node_init_rcu().
    
    The commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc
    failure after check_estalblished().") tried to fix an issue that an
    unconnected socket occupies an ehash entry when bhash2 allocation fails.
    
    In such a case, we need to revert changes done by check_established(),
    which does not hold refcnt when inserting socket into ehash.
    
    So, to revert the change, we need to __sk_nulls_add_node_rcu() instead
    of sk_nulls_add_node_rcu().
    
    Otherwise, sock_put() will cause refcnt underflow and leak the socket.
    
    [0]:
    WARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799
    Modules linked in:
    CPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799
    Code: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 <0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2
    RSP: 0018:ffffc900032d7848 EFLAGS: 00010246
    RAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000
    RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000
    RBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28
    R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140
    R13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130
    FS:  00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139
     dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956
     __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678
     inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749
     __sys_connect_file net/socket.c:2048 [inline]
     __sys_connect+0x2df/0x310 net/socket.c:2065
     __do_sys_connect net/socket.c:2075 [inline]
     __se_sys_connect net/socket.c:2072 [inline]
     __x64_sys_connect+0x7a/0x90 net/socket.c:2072
     do_syscall_64+0xf9/0x240
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f3b8167dda9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9
    RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
    RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    R13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8
     </TASK>
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=12c506c1aae251e70449
    Fixes: 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 28 09:38:10 2024 +0100

    thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path
    
    [ Upstream commit ca93bf607a44c1f009283dac4af7df0d9ae5e357 ]
    
    If devm_krealloc() fails, then 'efuse' is leaking.
    So free it to avoid a leak.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/481d345233862d58c3c305855a93d0dbc2bbae7e.1706431063.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peng Fan <[email protected]>
Date:   Mon Feb 26 08:36:57 2024 +0800

    thermal/drivers/qoriq: Fix getting tmu range
    
    [ Upstream commit 4d0642074c67ed9928e9d68734ace439aa06e403 ]
    
    TMU Version 1 has 4 TTRCRs, while TMU Version >=2 has 16 TTRCRs.
    So limit the len to 4 will report "invalid range data" for i.MX93.
    
    This patch drop the local array with allocated ttrcr array and
    able to support larger tmu ranges.
    
    Fixes: f12d60c81fce ("thermal/drivers/qoriq: Support version 2.1")
    Tested-by: Sascha Hauer <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:17 2024 +0800

    time: test: Fix incorrect format specifier
    
    [ Upstream commit 133e267ef4a26d19c93996a874714e9f3f8c70aa ]
    
    'days' is a s64 (from div_s64), and so should use a %lld specifier.
    
    This was found by extending KUnit's assertion macros to use gcc's
    __printf attribute.
    
    Fixes: 276010551664 ("time: Improve performance of time64_to_tm()")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Hilber <[email protected]>
Date:   Mon Dec 18 08:38:40 2023 +0100

    timekeeping: Fix cross-timestamp interpolation corner case decision
    
    [ Upstream commit 87a41130881995f82f7adbafbfeddaebfb35f0ef ]
    
    The cycle_between() helper checks if parameter test is in the open interval
    (before, after). Colloquially speaking, this also applies to the counter
    wrap-around special case before > after. get_device_system_crosststamp()
    currently uses cycle_between() at the first call site to decide whether to
    interpolate for older counter readings.
    
    get_device_system_crosststamp() has the following problem with
    cycle_between() testing against an open interval: Assume that, by chance,
    cycles == tk->tkr_mono.cycle_last (in the following, "cycle_last" for
    brevity). Then, cycle_between() at the first call site, with effective
    argument values cycle_between(cycle_last, cycles, now), returns false,
    enabling interpolation. During interpolation,
    get_device_system_crosststamp() will then call cycle_between() at the
    second call site (if a history_begin was supplied). The effective argument
    values are cycle_between(history_begin->cycles, cycles, cycles), since
    system_counterval.cycles == interval_start == cycles, per the assumption.
    Due to the test against the open interval, cycle_between() returns false
    again. This causes get_device_system_crosststamp() to return -EINVAL.
    
    This failure should be avoided, since get_device_system_crosststamp() works
    both when cycles follows cycle_last (no interpolation), and when cycles
    precedes cycle_last (interpolation). For the case cycles == cycle_last,
    interpolation is actually unneeded.
    
    Fix this by changing cycle_between() into timestamp_in_interval(), which
    now checks against the closed interval, rather than the open interval.
    
    This changes the get_device_system_crosststamp() behavior for three corner
    cases:
    
    1. Bypass interpolation in the case cycles == tk->tkr_mono.cycle_last,
       fixing the problem described above.
    
    2. At the first timestamp_in_interval() call site, cycles == now no longer
       causes failure.
    
    3. At the second timestamp_in_interval() call site, history_begin->cycles
       == system_counterval.cycles no longer causes failure.
       adjust_historical_crosststamp() also works for this corner case,
       where partial_history_cycles == total_history_cycles.
    
    These behavioral changes should not cause any problems.
    
    Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface supporting slower devices")
    Signed-off-by: Peter Hilber <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Hilber <[email protected]>
Date:   Mon Dec 18 08:38:41 2023 +0100

    timekeeping: Fix cross-timestamp interpolation for non-x86
    
    [ Upstream commit 14274d0bd31b4debf28284604589f596ad2e99f2 ]
    
    So far, get_device_system_crosststamp() unconditionally passes
    system_counterval.cycles to timekeeping_cycles_to_ns(). But when
    interpolating system time (do_interp == true), system_counterval.cycles is
    before tkr_mono.cycle_last, contrary to the timekeeping_cycles_to_ns()
    expectations.
    
    On x86, CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE will mitigate on
    interpolating, setting delta to 0. With delta == 0, xtstamp->sys_monoraw
    and xtstamp->sys_realtime are then set to the last update time, as
    implicitly expected by adjust_historical_crosststamp(). On other
    architectures, the resulting nonsense xtstamp->sys_monoraw and
    xtstamp->sys_realtime corrupt the xtstamp (ts) adjustment in
    adjust_historical_crosststamp().
    
    Fix this by deriving xtstamp->sys_monoraw and xtstamp->sys_realtime from
    the last update time when interpolating, by using the local variable
    "cycles". The local variable already has the right value when
    interpolating, unlike system_counterval.cycles.
    
    Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface supporting slower devices")
    Signed-off-by: Peter Hilber <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: John Stultz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Hilber <[email protected]>
Date:   Mon Dec 18 08:38:39 2023 +0100

    timekeeping: Fix cross-timestamp interpolation on counter wrap
    
    [ Upstream commit 84dccadd3e2a3f1a373826ad71e5ced5e76b0c00 ]
    
    cycle_between() decides whether get_device_system_crosststamp() will
    interpolate for older counter readings.
    
    cycle_between() yields wrong results for a counter wrap-around where after
    < before < test, and for the case after < test < before.
    
    Fix the comparison logic.
    
    Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface supporting slower devices")
    Signed-off-by: Peter Hilber <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: John Stultz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viktor Malik <[email protected]>
Date:   Tue Feb 6 13:46:10 2024 +0100

    tools/resolve_btfids: Fix cross-compilation to non-host endianness
    
    [ Upstream commit 903fad4394666bc23975c93fb58f137ce64b5192 ]
    
    The .BTF_ids section is pre-filled with zeroed BTF ID entries during the
    build and afterwards patched by resolve_btfids with correct values.
    Since resolve_btfids always writes in host-native endianness, it relies
    on libelf to do the translation when the target ELF is cross-compiled to
    a different endianness (this was introduced in commit 61e8aeda9398
    ("bpf: Fix libelf endian handling in resolv_btfids")).
    
    Unfortunately, the translation will corrupt the flags fields of SET8
    entries because these were written during vmlinux compilation and are in
    the correct endianness already. This will lead to numerous selftests
    failures such as:
    
        $ sudo ./test_verifier 502 502
        #502/p sleepable fentry accept FAIL
        Failed to load prog 'Invalid argument'!
        bpf_fentry_test1 is not sleepable
        verification time 34 usec
        stack depth 0
        processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
        Summary: 0 PASSED, 0 SKIPPED, 1 FAILED
    
    Since it's not possible to instruct libelf to translate just certain
    values, let's manually bswap the flags (both global and entry flags) in
    resolve_btfids when needed, so that libelf then translates everything
    correctly.
    
    Fixes: ef2c6f370a63 ("tools/resolve_btfids: Add support for 8-byte BTF sets")
    Signed-off-by: Viktor Malik <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/7b6bff690919555574ce0f13d2a5996cacf7bf69.1707223196.git.vmalik@redhat.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Viktor Malik <[email protected]>
Date:   Tue Feb 6 13:46:09 2024 +0100

    tools/resolve_btfids: Refactor set sorting with types from btf_ids.h
    
    [ Upstream commit 9707ac4fe2f5bac6406d2403f8b8a64d7b3d8e43 ]
    
    Instead of using magic offsets to access BTF ID set data, leverage types
    from btf_ids.h (btf_id_set and btf_id_set8) which define the actual
    layout of the data. Thanks to this change, set sorting should also
    continue working if the layout changes.
    
    This requires to sync the definition of 'struct btf_id_set8' from
    include/linux/btf_ids.h to tools/include/linux/btf_ids.h. We don't sync
    the rest of the file at the moment, b/c that would require to also sync
    multiple dependent headers and we don't need any other defs from
    btf_ids.h.
    
    Signed-off-by: Viktor Malik <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Daniel Xu <[email protected]>
    Link: https://lore.kernel.org/bpf/ff7f062ddf6a00815fda3087957c4ce667f50532.1707223196.git.vmalik@redhat.com
    Stable-dep-of: 903fad439466 ("tools/resolve_btfids: Fix cross-compilation to non-host endianness")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tudor Ambarus <[email protected]>
Date:   Fri Jan 19 10:45:08 2024 +0000

    tty: serial: samsung: fix tx_empty() to return TIOCSER_TEMT
    
    [ Upstream commit 314c2b399288f0058a8c5b6683292cbde5f1531b ]
    
    The core expects for tx_empty() either TIOCSER_TEMT when the tx is
    empty or 0 otherwise. s3c24xx_serial_txempty_nofifo() might return
    0x4, and at least uart_get_lsr_info() tries to clear exactly
    TIOCSER_TEMT (BIT(1)). Fix tx_empty() to return TIOCSER_TEMT.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Tudor Ambarus <[email protected]>
    Reviewed-by: Sam Protsenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Mon Jan 22 12:03:17 2024 +0100

    tty: vt: fix 20 vs 0x20 typo in EScsiignore
    
    [ Upstream commit 0e6a92f67c8a94707f7bb27ac29e2bdf3e7c167d ]
    
    The if (c >= 20 && c <= 0x3f) test added in commit 7a99565f8732 is
    wrong.  20 is DC4 in ascii and it makes no sense to consider that as the
    bottom limit. Instead, it should be 0x20 as in the other test in
    the commit above. This is supposed to NOT change anything as we handle
    interesting 20-0x20 asciis far before this if.
    
    So for sakeness, change to 0x20 (which is SPACE).
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Fixes: 7a99565f8732 ("vt: ignore csi sequences with intermediate characters.")
    Cc: Martin Hostettler <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Tested-by: Helge Deller <[email protected]> # parisc STI console
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gavrilov Ilia <[email protected]>
Date:   Thu Mar 7 14:23:50 2024 +0000

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

Author: Colin Ian King <[email protected]>
Date:   Thu Mar 7 18:17:34 2024 +0000

    usb: gadget: net2272: Use irqflags in the call to net2272_probe_fin
    
    [ Upstream commit 600556809f04eb3bbccd05218215dcd7b285a9a9 ]
    
    Currently the variable irqflags is being set but is not being used,
    it appears it should be used in the call to net2272_probe_fin
    rather than IRQF_TRIGGER_LOW being used. Kudos to Uwe Kleine-Kц╤nig
    for suggesting the fix.
    
    Cleans up clang scan build warning:
    drivers/usb/gadget/udc/net2272.c:2610:15: warning: variable 'irqflags'
    set but not used [-Wunused-but-set-variable]
    
    Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller")
    Signed-off-by: Colin Ian King <[email protected]>
    Acked-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sean Anderson <[email protected]>
Date:   Tue Jan 23 17:51:09 2024 -0500

    usb: phy: generic: Get the vbus supply
    
    [ Upstream commit 75fd6485cccef269ac9eb3b71cf56753341195ef ]
    
    While support for working with a vbus was added, the regulator was never
    actually gotten (despite what was documented). Fix this by actually
    getting the supply from the device tree.
    
    Fixes: 7acc9973e3c4 ("usb: phy: generic: add vbus support")
    Signed-off-by: Sean Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jonah Palmer <[email protected]>
Date:   Fri Feb 16 09:25:02 2024 -0500

    vdpa/mlx5: Allow CVQ size changes
    
    [ Upstream commit 749a4016839270163efc36ecddddd01de491a16b ]
    
    The MLX driver was not updating its control virtqueue size at set_vq_num
    and instead always initialized to MLX5_CVQ_MAX_ENT (16) at
    setup_cvq_vring.
    
    Qemu would try to set the size to 64 by default, however, because the
    CVQ size always was initialized to 16, an error would be thrown when
    sending >16 control messages (as used-ring entry 17 is initialized to 0).
    For example, starting a guest with x-svq=on and then executing the
    following command would produce the error below:
    
     # for i in {1..20}; do ifconfig eth0 hw ether XX:xx:XX:xx:XX:XX; done
    
     qemu-system-x86_64: Insufficient written data (0)
     [  435.331223] virtio_net virtio0: Failed to set mac address by vq command.
     SIOCSIFHWADDR: Invalid argument
    
    Acked-by: Dragos Tatulea <[email protected]>
    Acked-by: Eugenio Pц╘rez <[email protected]>
    Signed-off-by: Jonah Palmer <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Tested-by: Lei Yang <[email protected]>
    Fixes: 5262912ef3cf ("vdpa/mlx5: Add support for control VQ and MAC setting")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Steve Sistare <[email protected]>
Date:   Fri Feb 9 14:30:07 2024 -0800

    vdpa_sim: reset must not run
    
    [ Upstream commit 9588e7fc511f9c55b9835f14916e90ab940061b7 ]
    
    vdpasim_do_reset sets running to true, which is wrong, as it allows
    vdpasim_kick_vq to post work requests before the device has been
    configured.  To fix, do not set running until VIRTIO_CONFIG_S_DRIVER_OK
    is set.
    
    Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op")
    Signed-off-by: Steve Sistare <[email protected]>
    Reviewed-by: Eugenio Pц╘rez <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Xuan Zhuo <[email protected]>
Date:   Fri Feb 23 15:18:33 2024 +0800

    virtio: packed: fix unmap leak for indirect desc table
    
    [ Upstream commit d5c0ed17fea60cca9bc3bf1278b49ba79242bbcd ]
    
    When use_dma_api and premapped are true, then the do_unmap is false.
    
    Because the do_unmap is false, vring_unmap_extra_packed is not called by
    detach_buf_packed.
    
      if (unlikely(vq->do_unmap)) {
                    curr = id;
                    for (i = 0; i < state->num; i++) {
                            vring_unmap_extra_packed(vq,
                                                     &vq->packed.desc_extra[curr]);
                            curr = vq->packed.desc_extra[curr].next;
                    }
      }
    
    So the indirect desc table is not unmapped. This causes the unmap leak.
    
    So here, we check vq->use_dma_api instead. Synchronously, dma info is
    updated based on use_dma_api judgment
    
    This bug does not occur, because no driver use the premapped with
    indirect.
    
    Fixes: b319940f83c2 ("virtio_ring: skip unmap for premapped")
    Signed-off-by: Xuan Zhuo <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: William Tu <[email protected]>
Date:   Sat Mar 9 20:31:47 2024 +0200

    vmxnet3: Fix missing reserved tailroom
    
    [ Upstream commit e127ce7699c1e05279ee5ee61f00893e7bfa9671 ]
    
    Use rbi->len instead of rcd->len for non-dataring packet.
    
    Found issue:
      XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom
      WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O       6.5.1 #1
      RIP: 0010:xdp_warn+0xf/0x20
      ...
      ? xdp_warn+0xf/0x20
      xdp_do_redirect+0x15f/0x1c0
      vmxnet3_run_xdp+0x17a/0x400 [vmxnet3]
      vmxnet3_process_xdp+0xe4/0x760 [vmxnet3]
      ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3]
      vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3]
      vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3]
      __napi_poll+0x20/0x180
      net_rx_action+0x177/0x390
    
    Reported-by: Martin Zaharinov <[email protected]>
    Tested-by: Martin Zaharinov <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: 54f00cce1178 ("vmxnet3: Add XDP support.")
    Signed-off-by: William Tu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ji Sheng Teoh <[email protected]>
Date:   Fri Jan 19 16:27:21 2024 +0800

    watchdog: starfive: Check pm_runtime_enabled() before decrementing usage counter
    
    [ Upstream commit 8bc22a2f1bf0f402029087fcb53130233a544fed ]
    
    In the probe function, pm_runtime_put_sync() will fail on platform with
    runtime PM disabled.
    Check if runtime PM is enabled before calling pm_runtime_put_sync() to
    fix it.
    
    Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver")
    Signed-off-by: Xingyu Wu <[email protected]>
    Signed-off-by: Ley Foon Tan <[email protected]>
    Signed-off-by: Ji Sheng Teoh <[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]>

Author: Ben Wolsieffer <[email protected]>
Date:   Wed Feb 28 13:27:23 2024 -0500

    watchdog: stm32_iwdg: initialize default timeout
    
    [ Upstream commit dbd7c0088b7f44aa0b9276ed3449df075a7b5b54 ]
    
    The driver never sets a default timeout value, therefore it is
    initialized to zero. When CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is
    enabled, the watchdog is started during probe. The kernel is supposed to
    automatically ping the watchdog from this point until userspace takes
    over, but this does not happen if the configured timeout is zero. A zero
    timeout causes watchdog_need_worker() to return false, so the heartbeat
    worker does not run and the system therefore resets soon after the
    driver is probed.
    
    This patch fixes this by setting an arbitrary non-zero default timeout.
    The default could be read from the hardware instead, but I didn't see
    any reason to add this complexity.
    
    This has been tested on an STM32F746.
    
    Fixes: 85fdc63fe256 ("drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe")
    Signed-off-by: Ben Wolsieffer <[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]>

Author: Xingyuan Mo <[email protected]>
Date:   Sun Dec 17 13:29:01 2023 +0200

    wifi: ath10k: fix NULL pointer dereference in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev()
    
    [ Upstream commit ad25ee36f00172f7d53242dc77c69fff7ced0755 ]
    
    We should check whether the WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT tlv is
    present before accessing it, otherwise a null pointer deference error will
    occur.
    
    Fixes: dc405152bb64 ("ath10k: handle mgmt tx completion event")
    Signed-off-by: Xingyuan Mo <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Wen Gong <[email protected]>
Date:   Wed Jan 31 10:18:32 2024 +0800

    wifi: ath11k: change to move WMI_VDEV_PARAM_SET_HEMU_MODE before WMI_PEER_ASSOC_CMDID
    
    [ Upstream commit 413e20e82ee78f142cb5194fd317db514f012602 ]
    
    Currently when connecting to an AP with 11AX-HE phy mode, host sends
    WMI_VDEV_PARAM_SET_HEMU_MODE parameter to firmware after
    WMI_PEER_ASSOC_CMDID command. This results in TXBF not working, because
    firmware calculates TXBF values while handling WMI_PEER_ASSOC_CMDID,
    however at that time WMI_VDEV_PARAM_SET_HEMU_MODE has not been sent yet.
    See below log:
    
    AP sends "VHT/HE/EHT NDP Announcement" to station, and station sends
    "Action no Ack" of category code HE to AP, the "Nc Index" and
    "Codebook Information" are wrong:
    
    Issued action:
    IEEE 802.11 Action No Ack, Flags: ........
    IEEE 802.11 wireless LAN
        Fixed parameters
            Category code: HE (30)
            HE Action: HE Compressed Beamforming And CQI (0)
                Total length: 152
                HE MIMO Control: 0x0004008018
                    .... .... .... .... .... .... .... .... .... .000 = Nc Index: 1 Column (0)
                    .... .... .... .... .... .... .... ..0. .... .... = Codebook Information: 0
    
    Change to send WMI_VDEV_PARAM_SET_HEMU_MODE before WMI_PEER_ASSOC_CMDID,
    then firmware will calculate the TXBF values with valid parameters
    instead of empty values. TXBF works well and throughput performance is
    improved from 80 Mbps to 130 Mbps with this patch.
    
    Good action after this patch:
    IEEE 802.11 Action No Ack, Flags: ........
    IEEE 802.11 wireless LAN
        Fixed parameters
            Category code: HE (30)
            HE Action: HE Compressed Beamforming And CQI (0)
                Total length: 409
                HE MIMO Control: 0x0004008219
                    .... .... .... .... .... .... .... .... .... .001 = Nc Index: 2 Columns (1)
                    .... .... .... .... .... .... .... ..1. .... .... = Codebook Information: 1
    
    This change applies to all chipsets.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
    
    Fixes: 38dfe775d0ab ("wifi: ath11k: push MU-MIMO params from hostapd to hardware")
    Signed-off-by: Wen Gong <[email protected]>
    Signed-off-by: Baochen Qiang <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Baochen Qiang <[email protected]>
Date:   Fri Feb 2 10:35:47 2024 +0800

    wifi: ath11k: initialize rx_mcs_80 and rx_mcs_160 before use
    
    [ Upstream commit b802e7b7e771dee3377d071418281f8b64d2d832 ]
    
    Currently in ath11k_peer_assoc_h_he() rx_mcs_80 and rx_mcs_160
    are used to calculate max_nss, see
            if (support_160)
                    max_nss = min(rx_mcs_80, rx_mcs_160);
            else
                    max_nss = rx_mcs_80;
    
    Kernel test robot complains on uninitialized symbols:
    drivers/net/wireless/ath/ath11k/mac.c:2321 ath11k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_80'.
    drivers/net/wireless/ath/ath11k/mac.c:2321 ath11k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_160'.
    drivers/net/wireless/ath/ath11k/mac.c:2323 ath11k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_80'.
    
    This is because there are some code paths that never set them, so
    the assignment of max_nss can come from uninitialized variables.
    This could result in some unknown issues since a wrong peer_nss
    might be passed to firmware.
    
    Change to initialize them to an invalid value at the beginning. This
    makes sense because even max_nss gets an invalid value, due to either
    or both of them being invalid, we can get an valid peer_nss with
    following guard:
            arg->peer_nss = min(sta->deflink.rx_nss, max_nss)
    
    Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
    
    Fixes: 3db26ecf7114 ("ath11k: calculate the correct NSS of peer for HE capabilities")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Baochen Qiang <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Raj Kumar Bhagat <[email protected]>
Date:   Mon Jan 29 12:27:15 2024 +0530

    wifi: ath12k: fix fetching MCBC flag for QCN9274
    
    [ Upstream commit 902700d55d4a4522bb3eb4ef94f752a19c42230a ]
    
    In QCN9274, RX packet's multicast and broadcast(MCBC) flag is fetched
    from RX descriptor's msdu_end info5 member but it is not correct
    for QCN9274. Due to this with encryption, ARP request packet is wrongly
    marked as MCBC packet and it is sent to mac80211 without setting
    RX_FLAG_PN_VALIDATED & RX_FLAG_DECRYPTED flag. This results in packet
    getting dropped in mac80211. Hence ping initiated from station to AP
    fails.
    
    Fix this by fetching correct MCBC flag in case of QCN9274.
    For QC9274 MCBC flag should be fetched from RX descriptor's mpdu_start
    info6 member.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Fixes: 8f04852e90cb ("wifi: ath12k: Use msdu_end to check MCBC")
    Signed-off-by: Raj Kumar Bhagat <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kang Yang <[email protected]>
Date:   Mon Feb 5 19:03:27 2024 +0200

    wifi: ath12k: fix incorrect logic of calculating vdev_stats_id
    
    [ Upstream commit 019b58dcb6ed267e17b7efd03ec8575c1b67d942 ]
    
    During calculate vdev_stats_id, will compare vdev_stats_id with
    ATH12K_INVAL_VDEV_STATS_ID by '<='. If vdev_stats_id is relatively
    small, then assign ATH12K_INVAL_VDEV_STATS_ID to vdev_stats_id.
    
    This logic is incorrect. Firstly, should use '>=' instead of '<=' to
    check if this u8 variable exceeds the max valid range.
    
    Secondly, should use the maximum value as comparison value.
    
    Correct comparison symbols and use the maximum value
    ATH12K_MAX_VDEV_STATS_ID for comparison.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Kang Yang <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sriram R <[email protected]>
Date:   Wed Jan 17 11:56:28 2024 +0530

    wifi: ath12k: Fix issues in channel list update
    
    [ Upstream commit 67a48d937fac917947540c9f89630d472cd61fcb ]
    
    Currently, the logic used to select the 6 GHz band is incorrect,
    which may cause 6 GHz supported channels to not be updated properly.
    This is because the 6 GHz Max frequency supported by the driver is
    being compared to the Max frequency supported on the board. If in
    some cases, the 6 GHz Max frequency supported on the board is less
    than the defined 6 GHz Max frequency, all 6 GHz channels are disabled.
    To address this, compare the max frequency supported by the board to
    the defined 6 GHz Minimum frequency by the driver.
    
    Similarly, when a dual mac card supports both 6 GHz and 5 GHz radios,
    if the 5 GHz radio gets enumerated first before 6 GHz, the checks in
    ath12k_mac_setup_channels_rates() can cause the 5 GHz channels which
    were enabled earlier to get disabled when the 6 GHz channel list is
    updated. This is because the Min 6 GHz frequency defined in the driver
    is 5945 MHz, which should be 5925 MHz since channel 2 is not considered
    currently, but the firmware can pass 5925 MHz as the minimum.
    Hence, update the Min frequency supported by the driver to 5925 MHz.
    
    In addition, ensure that the channel list update to firmware updates
    only the channels that the current radio (ar) supports rather than
    considering the wiphy support. This would be required when multiple pdevs
    are supported in a wiphy and they support different ranges of frequencies
    or bands as in single wiphy support.
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Signed-off-by: Sriram R <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jeff Johnson <[email protected]>
Date:   Tue Nov 28 07:19:25 2023 -0800

    wifi: ath12k: Update Qualcomm Innovation Center, Inc. copyrights
    
    [ Upstream commit 05205b9576615fca5da91cdae5a3f89f2ad32703 ]
    
    Update the copyright for all ath12k files modified on behalf of
    Qualcomm Innovation Center, Inc. in 2023.
    
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 902700d55d4a ("wifi: ath12k: fix fetching MCBC flag for QCN9274")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Toke Hц╦iland-Jц╦rgensen <[email protected]>
Date:   Fri Jan 26 15:02:17 2024 +0100

    wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
    
    [ Upstream commit 24355fcb0d4cbcb6ddda262596558e8cfba70f11 ]
    
    The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
    structures have been fully initialised by the time it runs. However, because of
    the order in which things are initialised, this is not guaranteed to be the
    case, because the device is exposed to the USB subsystem before the ath9k driver
    initialisation is completed.
    
    We already committed a partial fix for this in commit:
    8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
    
    However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
    tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
    seems syzbot managed to trigger the race for one of the other commands as well,
    so let's just move the existing synchronisation bit to cover the whole
    tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
    ath9k_tx_init()).
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
    Reported-by: Ubisectech Sirius <[email protected]>
    Signed-off-by: Toke Hц╦iland-Jц╦rgensen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rahul Rameshbabu <[email protected]>
Date:   Sun Dec 31 05:03:58 2023 +0000

    wifi: b43: Disable QoS for bcm4331
    
    [ Upstream commit 09795bded2e725443fe4a4803cae2079cdaf7b26 ]
    
    bcm4331 seems to not function correctly with QoS support. This may be due
    to issues with currently available firmware or potentially a device
    specific issue.
    
    When queues that are not of the default "best effort" priority are
    selected, traffic appears to not transmit out of the hardware while no
    errors are returned. This behavior is present among all the other priority
    queues: video, voice, and background. While this can be worked around by
    setting a kernel parameter, the default behavior is problematic for most
    users and may be difficult to debug. This patch offers a working out-of-box
    experience for bcm4331 users.
    
    Log of the issue (using ssh low-priority traffic as an example):
        ssh -T -vvvv [email protected]
        OpenSSH_9.6p1, OpenSSL 3.0.12 24 Oct 2023
        debug1: Reading configuration data /etc/ssh/ssh_config
        debug2: checking match for 'host * exec "/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7sh1i8js8w-gnupg-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye >/dev/null 2>&1'"' host github.com originally github.com
        debug3: /etc/ssh/ssh_config line 5: matched 'host "github.com"'
        debug1: Executing command: '/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7sh1i8js8w-gnupg-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye >/dev/null 2>&1''
        debug3: command returned status 0
        debug3: /etc/ssh/ssh_config line 5: matched 'exec "/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0r"'
        debug2: match found
        debug1: /etc/ssh/ssh_config line 9: Applying options for *
        debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/binary-eater/.ssh/known_hosts'
        debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/binary-eater/.ssh/known_hosts2'
        debug2: resolving "github.com" port 22
        debug3: resolve_host: lookup github.com:22
        debug3: channel_clear_timeouts: clearing
        debug3: ssh_connect_direct: entering
        debug1: Connecting to github.com [192.30.255.113] port 22.
        debug3: set_sock_tos: set socket 3 IP_TOS 0x48
    
    Fixes: e6f5b934fba8 ("b43: Add QOS support")
    Signed-off-by: Rahul Rameshbabu <[email protected]>
    Reviewed-by: Julian Calaby <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rahul Rameshbabu <[email protected]>
Date:   Sun Dec 31 05:03:51 2023 +0000

    wifi: b43: Stop correct queue in DMA worker when QoS is disabled
    
    [ Upstream commit 581c8967d66c4961076dbbee356834e9c6777184 ]
    
    When QoS is disabled, the queue priority value will not map to the correct
    ieee80211 queue since there is only one queue. Stop queue 0 when QoS is
    disabled to prevent trying to stop a non-existent queue and failing to stop
    the actual queue instantiated.
    
    Fixes: bad691946966 ("b43: avoid packet losses in the dma worker code.")
    Signed-off-by: Rahul Rameshbabu <[email protected]>
    Reviewed-by: Julian Calaby <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rahul Rameshbabu <[email protected]>
Date:   Sun Dec 31 05:03:33 2023 +0000

    wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
    
    [ Upstream commit 9636951e4468f02c72cc75a82dc65d003077edbc ]
    
    When QoS is disabled, the queue priority value will not map to the correct
    ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
    is disabled to prevent trying to stop/wake a non-existent queue and failing
    to stop/wake the actual queue instantiated.
    
    Log of issue before change (with kernel parameter qos=0):
        [  +5.112651] ------------[ cut here ]------------
        [  +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
        [  +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
        [  +0.000044]  videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
        [  +0.000055]  usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
        [  +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G        W  O       6.6.7 #1-NixOS
        [  +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
        [  +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
        [  +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
        [  +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
        [  +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
        [  +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
        [  +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
        [  +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
        [  +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
        [  +0.000001] FS:  0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
        [  +0.000001] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [  +0.000001] CR2: 00007fafda7ae008 CR3: 000000046d220005 CR4: 00000000000606e0
        [  +0.000002] Call Trace:
        [  +0.000003]  <TASK>
        [  +0.000001]  ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]
        [  +0.000044]  ? __warn+0x81/0x130
        [  +0.000005]  ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]
        [  +0.000045]  ? report_bug+0x171/0x1a0
        [  +0.000004]  ? handle_bug+0x41/0x70
        [  +0.000004]  ? exc_invalid_op+0x17/0x70
        [  +0.000003]  ? asm_exc_invalid_op+0x1a/0x20
        [  +0.000005]  ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]
        [  +0.000043]  ieee80211_wake_queue+0x4a/0x80 [mac80211]
        [  +0.000044]  b43_dma_handle_txstatus+0x29c/0x3a0 [b43]
        [  +0.000016]  ? __pfx_irq_thread_fn+0x10/0x10
        [  +0.000002]  b43_handle_txstatus+0x61/0x80 [b43]
        [  +0.000012]  b43_interrupt_thread_handler+0x3f9/0x6b0 [b43]
        [  +0.000011]  irq_thread_fn+0x23/0x60
        [  +0.000002]  irq_thread+0xfe/0x1c0
        [  +0.000002]  ? __pfx_irq_thread_dtor+0x10/0x10
        [  +0.000001]  ? __pfx_irq_thread+0x10/0x10
        [  +0.000001]  kthread+0xe8/0x120
        [  +0.000003]  ? __pfx_kthread+0x10/0x10
        [  +0.000003]  ret_from_fork+0x34/0x50
        [  +0.000002]  ? __pfx_kthread+0x10/0x10
        [  +0.000002]  ret_from_fork_asm+0x1b/0x30
        [  +0.000004]  </TASK>
        [  +0.000001] ---[ end trace 0000000000000000 ]---
    
        [  +0.000065] ------------[ cut here ]------------
        [  +0.000001] WARNING: CPU: 0 PID: 56077 at net/mac80211/util.c:514 __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
        [  +0.000077] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
        [  +0.000073]  videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
        [  +0.000084]  usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43]
        [  +0.000012] CPU: 0 PID: 56077 Comm: kworker/u16:17 Tainted: G        W  O       6.6.7 #1-NixOS
        [  +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
        [  +0.000001] Workqueue: phy7 b43_tx_work [b43]
        [  +0.000019] RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
        [  +0.000076] Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 ab f4 00 00 65 ff 0d 9c b7 34 3f 0f 85 55 ff ff ff 0f 1f 44 00 00 e9 4b ff ff ff <0f> 0b 5b 5d 41 5c 41 5d c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90
        [  +0.000002] RSP: 0000:ffffc90004157d50 EFLAGS: 00010097
        [  +0.000002] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
        [  +0.000002] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8882d65d0900
        [  +0.000002] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
        [  +0.000001] R10: 00000000000000ff R11: ffff88814d0155a0 R12: ffff8882d65d0900
        [  +0.000002] R13: 0000000000000000 R14: ffff8881002d2800 R15: 00000000000000d0
        [  +0.000002] FS:  0000000000000000(0000) GS:ffff88846f800000(0000) knlGS:0000000000000000
        [  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [  +0.000002] CR2: 00007f2e8c10c880 CR3: 0000000385b66005 CR4: 00000000000606f0
        [  +0.000002] Call Trace:
        [  +0.000001]  <TASK>
        [  +0.000001]  ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
        [  +0.000075]  ? __warn+0x81/0x130
        [  +0.000004]  ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
        [  +0.000075]  ? report_bug+0x171/0x1a0
        [  +0.000005]  ? handle_bug+0x41/0x70
        [  +0.000003]  ? exc_invalid_op+0x17/0x70
        [  +0.000004]  ? asm_exc_invalid_op+0x1a/0x20
        [  +0.000004]  ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
        [  +0.000076]  ieee80211_stop_queue+0x36/0x50 [mac80211]
        [  +0.000077]  b43_dma_tx+0x550/0x780 [b43]
        [  +0.000023]  b43_tx_work+0x90/0x130 [b43]
        [  +0.000018]  process_one_work+0x174/0x340
        [  +0.000003]  worker_thread+0x27b/0x3a0
        [  +0.000004]  ? __pfx_worker_thread+0x10/0x10
        [  +0.000002]  kthread+0xe8/0x120
        [  +0.000003]  ? __pfx_kthread+0x10/0x10
        [  +0.000004]  ret_from_fork+0x34/0x50
        [  +0.000002]  ? __pfx_kthread+0x10/0x10
        [  +0.000003]  ret_from_fork_asm+0x1b/0x30
        [  +0.000006]  </TASK>
        [  +0.000001] ---[ end trace 0000000000000000 ]---
    
    Fixes: e6f5b934fba8 ("b43: Add QOS support")
    Signed-off-by: Rahul Rameshbabu <[email protected]>
    Reviewed-by: Julian Calaby <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Rahul Rameshbabu <[email protected]>
Date:   Sun Dec 31 05:03:45 2023 +0000

    wifi: b43: Stop/wake correct queue in PIO Tx path when QoS is disabled
    
    [ Upstream commit 77135a38f6c2f950d2306ac3d37cbb407e6243f2 ]
    
    When QoS is disabled, the queue priority value will not map to the correct
    ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
    is disabled to prevent trying to stop/wake a non-existent queue and failing
    to stop/wake the actual queue instantiated.
    
    Fixes: 5100d5ac81b9 ("b43: Add PIO support for PCMCIA devices")
    Signed-off-by: Rahul Rameshbabu <[email protected]>
    Reviewed-by: Julian Calaby <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Duoming Zhou <[email protected]>
Date:   Thu Feb 29 18:31:53 2024 +0800

    wifi: brcm80211: handle pmk_op allocation failure
    
    [ Upstream commit b4152222e04cb8afeeca239c90e3fcaf4c553b42 ]
    
    The kzalloc() in brcmf_pmksa_v3_op() will return null if the
    physical memory has run out. As a result, if we dereference
    the null value, the null pointer dereference bug will happen.
    
    Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails
    for pmk_op.
    
    Fixes: a96202acaea4 ("wifi: brcmfmac: cfg80211: Add support for PMKID_V3 operations")
    Acked-by: Arend van Spriel <[email protected]>
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:05:37 2024 +0100

    wifi: brcmsmac: avoid function pointer casts
    
    [ Upstream commit e1ea6db35fc3ba5ff063f097385e9f7a88c25356 ]
    
    An old cleanup went a little too far and causes a warning with clang-16
    and higher as it breaks control flow integrity (KCFI) rules:
    
    drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c:64:34: error: cast from 'void (*)(struct brcms_phy *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       64 |                         brcms_init_timer(physhim->wl, (void (*)(void *))fn,
          |                                                       ^~~~~~~~~~~~~~~~~~~~
    
    Change this one instance back to passing a void pointer so it can be
    used with the timer callback interface.
    
    Fixes: d89a4c80601d ("staging: brcm80211: removed void * from softmac phy")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Arend van Spriel <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Sun Jan 28 08:53:55 2024 +0200

    wifi: iwlwifi: acpi: fix WPFC reading
    
    [ Upstream commit 296f3e926716ded8dc29e349d2b042b362f96515 ]
    
    The code reading the WPFC table needs to take into account
    the domain type (first element in the package), shouldn't
    leak the memory if it fails, and has a bad comment. Fix all
    these issues.
    
    Fixes: c4c954547755 ("wifi: iwlwifi: implement WPFC ACPI table loading")
    Reported-by: Miri Korenblit <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Gregory Greenman Gregory <[email protected]>
    Link: https://msgid.link/20240128084842.2afeb476b62d.I200568dc42a277e21c12be99d5aaa39b009d45da@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Mon Jan 29 21:21:54 2024 +0200

    wifi: iwlwifi: always have 'uats_enabled'
    
    [ Upstream commit f639602a58e7564dd091c7c0793f61042bad9bb6 ]
    
    We check this in code that'd be complicated to put under
    ifdef (CONFIG_ACPI), so just always have 'uats_enabled'.
    
    Fixes: 4a9bb5b4d949 ("wifi: iwlwifi: fw: Add support for UATS table in UHB")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Mukesh Sisodiya <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240129211905.bdc5fb20f00a.I902d801d79873c5c9cd51cef8e8226e2acefe88d@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miri Korenblit <[email protected]>
Date:   Tue Jan 23 20:08:16 2024 +0200

    wifi: iwlwifi: change link id in time event to s8
    
    [ Upstream commit 6c8ce23854b66db94d88e0957e531cb074806c16 ]
    
    Link ID in time event data is -1 when the time event is cleared.
    Change the type of the link ID in the time event data structure
    and in the affected function from unsigned to signed.
    
    Fixes: 135065837310 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION cmd")
    Signed-off-by: Miri Korenblit <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Link: https://msgid.link/20240123200528.50d4941f946c.Iea990b118c69bc3e1eb61c1d134c9d470b3a17ac@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Sun Jan 28 08:53:53 2024 +0200

    wifi: iwlwifi: dbg-tlv: ensure NUL termination
    
    [ Upstream commit ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea ]
    
    The iwl_fw_ini_debug_info_tlv is used as a string, so we must
    ensure the string is terminated correctly before using it.
    
    Fixes: a9248de42464 ("iwlwifi: dbg_ini: add TLV allocation new API support")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240128084842.be15e858ee89.Ibff93429cf999eafc7b26f3eef4c055dc84984a0@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miri Korenblit <[email protected]>
Date:   Mon Jan 29 21:21:49 2024 +0200

    wifi: iwlwifi: fix EWRD table validity check
    
    [ Upstream commit c8d8f3911135921ace8e939ea0956b55f74bf8a0 ]
    
    EWRD ACPI table contains up to 3 additional sar profiles.
    According to the BIOS spec, the table contains a n_profile
    variable indicating how many additional profiles exist in the
    table.
    Currently we check that n_profiles is not <= 0.
    But according to the BIOS spec, 0 is a valid value,
    and it can't be < 0 anyway because we receive that from ACPI as
    an unsigned integer.
    
    Fixes: 39c1a9728f93 ("iwlwifi: refactor the SAR tables from mvm to acpi")
    Signed-off-by: Miri Korenblit <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Link: https://msgid.link/20240129211905.448ea2f40814.Iffd2aadf8e8693e6cb599bee0406a800a0c1e081@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Mon Jan 29 21:21:51 2024 +0200

    wifi: iwlwifi: mvm: d3: fix IPN byte order
    
    [ Upstream commit 0c769cb6b9f364423c255f117774c9ecd5bf23ea ]
    
    The IPN is reported by the firmware in 6 bytes little endian,
    but mac80211 expects big endian so it can do memcmp() on it.
    We used to store this as a u64 which was filled in the right
    way, but never used. When implementing that it's used, we
    changed it to just be 6 bytes, but lost the conversion. Add
    it back.
    
    Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240129211905.138ed8a698e3.I1b66c386e45b5392696424ec636474bff86fd5ef@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Tue Feb 6 18:02:09 2024 +0200

    wifi: iwlwifi: mvm: don't set replay counters to 0xff
    
    [ Upstream commit d5bd4041cd70faf26fc9a54bd6f172537bbe77f3 ]
    
    The firmware (later) actually uses the values even for keys
    that are invalid as far as the host is concerned, later in
    rekeying, and then only sets the low 48 bits since the PNs
    are only 48 bits over the air. It does, however, compare the
    full 64 bits later, obviously causing problems.
    
    Remove the memset and use kzalloc instead to avoid any old
    heap data leaking to the firmware. We already init all the
    other fields in the struct anyway. This leaves the data set
    to zero for any unused fields, so the firmware can look at
    them safely even if they're not used right now.
    
    Fixes: 79e561f0f05a ("iwlwifi: mvm: d3: implement RSC command version 5")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240206175739.462101146fef.I10f3855b99417af4247cff04af78dcbc6cb75c9c@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Emmanuel Grumbach <[email protected]>
Date:   Tue Feb 6 18:02:06 2024 +0200

    wifi: iwlwifi: mvm: don't set the MFP flag for the GTK
    
    [ Upstream commit e35f316bce9e5733c9826120c1838f4c447b2c4c ]
    
    The firmware doesn't need the MFP flag for the GTK, it can even make the
    firmware crash. in case the AP is configured with: group cipher TKIP and
    MFPC. We would send the GTK with cipher = TKIP and MFP which is of course
    not possible.
    
    Fixes: 5c75a208c244 ("wifi: iwlwifi: mvm: support new key API")
    Signed-off-by: Emmanuel Grumbach <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240206175739.2f2c602ab3c6.If13b2e2fa532381d985c07df130bee1478046c89@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Benjamin Berg <[email protected]>
Date:   Sun Feb 18 19:51:47 2024 +0200

    wifi: iwlwifi: mvm: ensure offloading TID queue exists
    
    [ Upstream commit 78f65fbf421a61894c14a1b91fe2fb4437b3fe5f ]
    
    The resume code path assumes that the TX queue for the offloading TID
    has been configured. At resume time it then tries to sync the write
    pointer as it may have been updated by the firmware.
    
    In the unusual event that no packets have been send on TID 0, the queue
    will not have been allocated and this causes a crash. Fix this by
    ensuring the queue exist at suspend time.
    
    Signed-off-by: Benjamin Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240218194912.6632e6dc7b35.Ie6e6a7488c9c7d4529f13d48f752b5439d8ac3c4@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Mon Feb 5 21:21:14 2024 +0200

    wifi: iwlwifi: mvm: fix erroneous queue index mask
    
    [ Upstream commit 2e0e766bd8a7f14f10c3e70b8203c4c1e6d9ec76 ]
    
    When retrieving the queue index ("SCD SSN") from the TX response,
    it's currently masked with 0xFFF. However, now that we have queues
    longer than 4k, that became wrong, so make the mask depend on the
    hardware family.
    
    This fixes an issue where if we get a single frame reclaim while
    in the top half of an 8k long queue, we'd reclaim-wrap the queue
    twice (once on this and then again on the next non-single reclaim)
    which at least triggers the WARN_ON_ONCE() in iwl_txq_reclaim(),
    but could have other negative side effects (such as unmapping a
    frame that wasn't transmitted yet, and then taking an IOMMU fault)
    as well.
    
    Fixes: 7b3e42ea2ead ("iwlwifi: support multiple tfd queue max sizes for different devices")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240205211151.4148a6ef54e0.I733a70f679c25f9f99097a8dcb3a1f8165da6997@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilan Peer <[email protected]>
Date:   Thu Feb 8 18:58:38 2024 +0200

    wifi: iwlwifi: mvm: Fix the listener MAC filter flags
    
    [ Upstream commit 4cdb86487e3eaddb4b3a7df30ae709e810aac84b ]
    
    One of the flags was from the wrong API.
    
    Fixes: 9be162a7b670 ("wifi: iwlwifi: mvm: add support for the new MAC CTXT command")
    Signed-off-by: Ilan Peer <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240208185302.a338c30ec4e9.Ic2813cdeba4443c692d462fc4859392f069d7e33@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Emmanuel Grumbach <[email protected]>
Date:   Mon Jan 29 21:21:59 2024 +0200

    wifi: iwlwifi: mvm: fix the TLC command after ADD_STA
    
    [ Upstream commit 0fcdf55fced7121c43fa576433986f1c04115b73 ]
    
    ADD_STA resets the link quality data inside the firmware. This is not
    supposed to happen and has been fixed for newer devices. For older
    devices (AX201 and down), this makes us send frames with rates that are
    not in the TLC table.
    
    Fixes: 5a86dcb4a908 ("wifi: iwlwifi: mvm: update station's MFP flag after association")
    Signed-off-by: Emmanuel Grumbach <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240129211905.1deca7eaff14.I597abd7aab36fdab4aa8311a48c98a3d5bd433ba@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Emmanuel Grumbach <[email protected]>
Date:   Sun Feb 18 19:51:50 2024 +0200

    wifi: iwlwifi: mvm: fix the TXF mapping for BZ devices
    
    [ Upstream commit d3433d1bb7bde449035f54b7000361ce151bad07 ]
    
    Those devices' fifos are numbered differently.
    Because of that, we were looking at the size of the VO fifo size to
    determine the size of the A-MSDU which led to a lower throughput.
    
    Note that for those devices the only user of the AC -> fifo mapping is
    the size limitation of A-MSDU.
    
    Signed-off-by: Emmanuel Grumbach <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240218194912.da336ca2fa0a.I73e44d5fc474ebb6f275b9008950e59c012f33b2@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Sun Jan 28 08:53:58 2024 +0200

    wifi: iwlwifi: mvm: initialize rates in FW earlier
    
    [ Upstream commit d3b2c6c65bfd3b9616084e91bd0d402964ea7cef ]
    
    When connecting to an AP, we currently initialize the rate
    control only after associating. Since we now use firmware
    to assign rates to auth/assoc frames rather than using the
    data in the station and the firmware doesn't know, they're
    transmitted using low mandatory rates. However, if the AP
    advertised only higher supported rates we want to use them
    to be nicer (it still must receive mandatory rates though),
    so send the information to the firmware earlier to have it
    know about it and be able to use it.
    
    Fixes: 499d02790495 ("wifi: iwlwifi: Use FW rate for non-data frames")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240128084842.ed7ab1c859c2.I4b4d4fc3905c8d8470fc0fee4648f25c950c9bb7@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Johannes Berg <[email protected]>
Date:   Sun Jan 28 08:53:48 2024 +0200

    wifi: iwlwifi: mvm: report beacon protection failures
    
    [ Upstream commit 91380f768d7f6e3d003755defa792e9a00a1444a ]
    
    Andrei reports that we just silently drop beacons after we
    report the key counters, but never report to userspace, so
    wpa_supplicant cannot send the WNM action frame. Fix that.
    
    Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available")
    Reported-by: Andrei Otcheretianski <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240128084842.7d855442cdce.Iba90b26f893dc8c49bfb8be65373cd0a138af12c@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Daniel Gabay <[email protected]>
Date:   Mon Feb 5 00:06:03 2024 +0200

    wifi: iwlwifi: mvm: use correct address 3 in A-MSDU
    
    [ Upstream commit 2e57b77583ca34fdb6e14f253172636c52f81cf2 ]
    
    As described in IEEE sta 802.11-2020, table 9-30 (Address
    field contents), A-MSDU address 3 should contain the BSSID
    address.
    
    In TX_CMD we copy the MAC header from skb, and skb address 3
    holds the destination address, but it may not be identical to
    the BSSID.
    
    Using the wrong destination address appears to work with (most)
    receivers without MLO, but in MLO some devices are checking for
    it carefully, perhaps as a consequence of link to MLD address
    translation.
    
    Replace address 3 in the TX_CMD MAC header with the correct
    address while retaining the skb address 3 unchanged.
    This ensures that skb address 3 will be utilized later for
    constructing the A-MSDU subframes.
    
    Note that we fill in the MLD address, but the firmware will do the
    necessary translation to link address after encryption.
    
    Signed-off-by: Daniel Gabay <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240204235836.4583a1bf9188.I3f8e7892bdf8f86b4daa28453771a8c9817b2416@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miri Korenblit <[email protected]>
Date:   Mon Feb 5 21:21:05 2024 +0200

    wifi: iwlwifi: properly check if link is active
    
    [ Upstream commit 556c7cd721b5262579ba1710c3b4e7ffdb5573ac ]
    
    Before sending SESSION PROTECTION cmd the driver verifies that the
    link for which the cmd is going to be sent is active.
    The existing code is checking it only for MLD vifs,
    but also the deflink (in non-MLD vifs) needs to be active in order
    the have a session protection for it.
    Fix this by checking if the link is active also for non-MLD vifs
    
    Fixes: 135065837310 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION cmd")
    Signed-off-by: Miri Korenblit <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Link: https://msgid.link/20240205211151.c61820f14ca6.Ibbe0f848f3e71f64313d21642650b6e4bfbe4b39@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miri Korenblit <[email protected]>
Date:   Wed Jan 31 10:24:34 2024 +0200

    wifi: iwlwifi: read BIOS PNVM only for non-Intel SKU
    
    [ Upstream commit c868a189ecfe8cc0b3173c2eaa7f0b659326c151 ]
    
    The driver is supposed to read the PNVM from BIOS only for non-Intel
    SKUs. For Intel SKUs the OEM ID will be 0.
    Read BIOS PNVM only when a non-Intel SKU is indicated.
    
    Fixes: b99e32cbfdf6 ("wifi: iwlwifi: Take loading and setting of pnvm image out of parsing part")
    Signed-off-by: Miri Korenblit <[email protected]>
    Reviewed-by: Gregory Greenman <[email protected]>
    Link: https://msgid.link/20240131091413.3625cf1223d3.Ieffda5f506713b1c979388dd7a0e1c1a0145cfca@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Miri Korenblit <[email protected]>
Date:   Mon Feb 5 00:06:13 2024 +0200

    wifi: iwlwifi: support EHT for WH
    
    [ Upstream commit f51d6431824f0afb9f73d68971d154c47c26b86a ]
    
    sku_cap_11be_enable should be set to true also for WH.
    
    Fixes: e1374ed25324 ("wifi: iwlwifi: Add support for new CNVi (SC)")
    Signed-off-by: Miri Korenblit <[email protected]>
    Reviewed-by: Emmanuel Grumbach <[email protected]>
    Link: https://msgid.link/20240204235836.a6d4097cbaca.I8b00fa7b6226b4116cd91f70fb0b15e79b4dee5a@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhipeng Lu <[email protected]>
Date:   Fri Jan 26 15:53:34 2024 +0800

    wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
    
    [ Upstream commit 5f0e4aede01cb01fa633171f0533affd25328c3a ]
    
    In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
    cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
    be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
    
    Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Felix Fietkau <[email protected]>
Date:   Wed Feb 21 15:05:35 2024 +0100

    wifi: mac80211: only call drv_sta_rc_update for uploaded stations
    
    [ Upstream commit 413dafc8170fcb925fb17af8842f06af305f8e0b ]
    
    When a station has not been uploaded yet, receiving SMPS or channel width
    notification action frames can lead to rate_control_rate_update calling
    drv_sta_rc_update with uninitialized driver private data.
    Fix this by adding a missing check for sta->uploaded.
    
    Signed-off-by: Felix Fietkau <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Benjamin Berg <[email protected]>
Date:   Thu Jan 11 18:17:46 2024 +0200

    wifi: mac80211: use deflink and fix typo in link ID check
    
    [ Upstream commit e10322810ce0d0d4a5a319458c4e1e052c6fe9be ]
    
    This does not change anything effectively, but it is closer to what the
    code is trying to achieve here. i.e. select the link data if it is an
    MLD and fall back to using the deflink otherwise.
    
    Fixes: 0f99f0878350 ("wifi: mac80211: Print local link address during authentication")
    Signed-off-by: Benjamin Berg <[email protected]>
    Reviewed-by: Ilan Peer <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://msgid.link/20240111181514.4c4b1c40eb3c.I2771621dee328c618536596b7e56232df42a79c8@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Allen Ye <[email protected]>
Date:   Thu Nov 2 18:03:01 2023 +0800

    wifi: mt76: connac: add beacon protection support for mt7996
    
    [ Upstream commit eb80e02b2c03141460749d3800126e2cdb674c9e ]
    
    Implement beacon protection feature for mt7996 chipsets, and also do
    some cleanup on the set key routine.
    
    Co-developed-by: Rudra Shahi <[email protected]>
    Signed-off-by: Rudra Shahi <[email protected]>
    Signed-off-by: Allen Ye <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Stable-dep-of: 47916693ec7c ("wifi: mt76: mt7925: fix WoW failed in encrypted mode")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Wed Feb 7 11:31:23 2024 +0800

    wifi: mt76: fix the issue of missing txpwr settings from ch153 to ch177
    
    [ Upstream commit e9a46175a79fbc591c48d433020444b8fa2750ee ]
    
    Because the number of channels to be configured is calculated using the %,
    and it results in 0 when there's an exact division, this leads to some
    channels not having their tx power configured.
    
    Fixes: 7801da338856 ("wifi: mt76: mt7921: enable set txpower for UNII-4")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Tue Jan 16 10:48:54 2024 +0800

    wifi: mt76: mt7921: fix incorrect type conversion for CLC command
    
    [ Upstream commit b6351ef9994ccb93b2447d396a0c517964dff2bc ]
    
    clc->len is defined as 32 bits in length, so it must also be
    operated on with 32 bits, not 16 bits.
    
    Fixes: fa6ad88e023d ("wifi: mt76: mt7921: fix country count limitation for CLC")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Deren Wu <[email protected]>
Date:   Sat Jan 13 17:00:22 2024 +0800

    wifi: mt76: mt7921e: fix use-after-free in free_irq()
    
    [ Upstream commit c957280ef6ab6bdf559a91ae693a6b34310697e3 ]
    
    From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test
    to make sure the shared irq handler should be able to handle the unexpected
    event after deregistration. For this case, let's apply MT76_REMOVED flag to
    indicate the device was removed and do not run into the resource access
    anymore.
    
    BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e]
    Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115
    CPU: 28 PID: 11115 Comm: rmmod Tainted: G        W    L    5.17.0 #10
    Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I
    EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6f/0xa0
     print_address_description.constprop.0+0x1f/0x190
     ? mt7921_irq_handler+0xd8/0x100 [mt7921e]
     ? mt7921_irq_handler+0xd8/0x100 [mt7921e]
     kasan_report.cold+0x7f/0x11b
     ? mt7921_irq_handler+0xd8/0x100 [mt7921e]
     mt7921_irq_handler+0xd8/0x100 [mt7921e]
     free_irq+0x627/0xaa0
     devm_free_irq+0x94/0xd0
     ? devm_request_any_context_irq+0x160/0x160
     ? kobject_put+0x18d/0x4a0
     mt7921_pci_remove+0x153/0x190 [mt7921e]
     pci_device_remove+0xa2/0x1d0
     __device_release_driver+0x346/0x6e0
     driver_detach+0x1ef/0x2c0
     bus_remove_driver+0xe7/0x2d0
     ? __check_object_size+0x57/0x310
     pci_unregister_driver+0x26/0x250
     __do_sys_delete_module+0x307/0x510
     ? free_module+0x6a0/0x6a0
     ? fpregs_assert_state_consistent+0x4b/0xb0
     ? rcu_read_lock_sched_held+0x10/0x70
     ? syscall_enter_from_user_mode+0x20/0x70
     ? trace_hardirqs_on+0x1c/0x130
     do_syscall_64+0x5c/0x80
     ? trace_hardirqs_on_prepare+0x72/0x160
     ? do_syscall_64+0x68/0x80
     ? trace_hardirqs_on_prepare+0x72/0x160
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Reported-by: Mikhail Gavrilov <[email protected]>
    Closes: https://lore.kernel.org/linux-wireless/CABXGCsOdvVwdLmSsC8TZ1jF0UOg_F_W3wqLECWX620PUkvNk=A@mail.gmail.com/
    Fixes: 9270270d6219 ("wifi: mt76: mt7921: fix PCI DMA hang after reboot")
    Tested-by: Mikhail Gavrilov <[email protected]>
    Signed-off-by: Deren Wu <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Quan Zhou <[email protected]>
Date:   Fri Dec 29 11:09:35 2023 +0800

    wifi: mt76: mt7925: add flow to avoid chip bt function fail
    
    [ Upstream commit 9300ae0cd9e8f2407b20e0e67ee3ea03dc8b06af ]
    
    A sub-process of Wifi L0.5 reset will make chip common partition
    enter low power, and have chance lead to Bluetooth host-to-chip
    command timeout, modify the software flow according to the chip's
    design to solve the problem.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Quan Zhou <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Fri Dec 29 11:09:36 2023 +0800

    wifi: mt76: mt7925: add support to set ifs time by mcu command
    
    [ Upstream commit 8536ef0aeae1177c4a59b043d4b1c41ddaa9df2a ]
    
    There's a race between driver and fw on some tx/rx control registers
    when setting ifs, which will cause accidental hw queue pause problems.
    Avoid this by setting ifs time with bss_info mcu command.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Co-developed-by: Deren Wu <[email protected]>
    Signed-off-by: Deren Wu <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Fri Dec 29 11:09:28 2023 +0800

    wifi: mt76: mt7925: fix connect to 80211b mode fail in 2Ghz band
    
    [ Upstream commit 479146078a21ff2015cdd4e0467cba0559911915 ]
    
    Driver should setting correct phy mode to firmware when in legacy mode.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hao Zhang <[email protected]>
Date:   Fri Dec 29 11:09:30 2023 +0800

    wifi: mt76: mt7925: fix mcu query command fail
    
    [ Upstream commit 2f475cb63eb304bdbb58c9b07b0547ca6c343012 ]
    
    Apply query command type properly to make the chip send the response back.
    Otherwise, we may see the command timeout in driver side.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Hao Zhang <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: rong.yan <[email protected]>
Date:   Fri Dec 29 11:09:29 2023 +0800

    wifi: mt76: mt7925: fix SAP no beacon issue in 5Ghz and 6Ghz band
    
    [ Upstream commit 243cecc857735344473ea33a713cd5c2ec1fe347 ]
    
    Driver should configure basic rate and phy mode for SAP mode.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: rong.yan <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Fri Dec 29 11:09:34 2023 +0800

    wifi: mt76: mt7925: fix the wrong header translation config
    
    [ Upstream commit d8cf7e1344727b80b4ec3dc17ca520238d55a88d ]
    
    The header translation config should set to broadcast and unicast
    cases correctly, not only unicast case. And also remove the cmds
    of wtbl (wlan table) series, because these MCU commands have
    already been replaced by other commands in mt7925.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Fri Dec 29 11:09:31 2023 +0800

    wifi: mt76: mt7925: fix wmm queue mapping
    
    [ Upstream commit 9d89edb576e385267f40193bd3776157101a504a ]
    
    Firmware uses access class index (ACI) for wmm parameters update,
    so convert mac80211 queue to ACI in mt7925_conf_tx().
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Fri Dec 29 11:09:33 2023 +0800

    wifi: mt76: mt7925: fix WoW failed in encrypted mode
    
    [ Upstream commit 47916693ec7cd1b283ffa7554fc48ff4eec2daa1 ]
    
    When in suspend mode, WoW (Wake-on-WLAN) fails to wake the system remotely
    due to incorrect encryption mode settings. For the new mt7925 chipset, the
    old STA_REC_KEY_V2 command will send incorrect parameters to the firmware.
    Therefore, STA_REC_KEY_V3 has been introduced as a replacement for it.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Deren Wu <[email protected]>
Date:   Fri Dec 29 11:09:37 2023 +0800

    wifi: mt76: mt7925: update PCIe DMA settings
    
    [ Upstream commit 0844947ccf64ea45edf6619ae2ba6dd9098b3308 ]
    
    Fix the wrong WFDMA settings to improve TX performance.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Deren Wu <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Deren Wu <[email protected]>
Date:   Sat Jan 13 17:00:23 2024 +0800

    wifi: mt76: mt7925e: fix use-after-free in free_irq()
    
    [ Upstream commit a5a5f4413d91f395cb2d89829d376d7393ad48b9 ]
    
    From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test
    to make sure the shared irq handler should be able to handle the unexpected
    event after deregistration. For this case, let's apply MT76_REMOVED flag to
    indicate the device was removed and do not run into the resource access
    anymore.
    
    Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
    Signed-off-by: Deren Wu <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ming Yen Hsieh <[email protected]>
Date:   Tue Jan 16 10:48:55 2024 +0800

    wifi: mt76: mt792x: fix a potential loading failure of the 6Ghz channel config from ACPI
    
    [ Upstream commit 07ce1d46372489d90f9cccebb3277d1af801c4b9 ]
    
    In some case, the MTCL table will exist, but MTDS table will not.
    So the SAR will init fail. This patch make MTCL and MTDS can exist
    with no dependence.
    
    Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support")
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Signed-off-by: Leon Yen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Gen Xu <[email protected]>
Date:   Sat Jan 27 09:04:30 2024 -0800

    wifi: mt76: mt792x: fix ethtool warning
    
    [ Upstream commit 7b4f9cd6a5fc221895b1d9be83ee3c13c00d09ab ]
    
    Add a missing EHT related field to fix the following ethtool warning:
    [98179.287352] mt7921e 0003:01:00.0: ei: 74  SSTATS_LEN: 73
    
    Fixes: c74df1c067f2 ("wifi: mt76: mt792x: introduce mt792x-lib module")
    Signed-off-by: Gen Xu <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Chiu <[email protected]>
Date:   Fri Jan 26 17:09:12 2024 +0800

    wifi: mt76: mt7996: check txs format before getting skb by pid
    
    [ Upstream commit 9c9c25f1dcdd98fffda564d2073f26219c84a2c3 ]
    
    The PPDU TXS does not include the error bit so it cannot use to report
    status to mac80211. This patch fixes issue that STA wrongly detects if AP
    is still alive.
    
    Fixes: 2569ea5326e2 ("wifi: mt76: mt7996: enable PPDU-TxS to host")
    Signed-off-by: Peter Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: StanleyYP Wang <[email protected]>
Date:   Fri Jan 26 17:09:19 2024 +0800

    wifi: mt76: mt7996: fix efuse reading issue
    
    [ Upstream commit d3ad99be7cc2d174126d908addd6bea2b157aa75 ]
    
    The efuse data starts from the 48th bytes instead of 64th bytes in the
    returned event skb.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    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]>

Author: Howard Hsu <[email protected]>
Date:   Fri Jan 26 17:09:17 2024 +0800

    wifi: mt76: mt7996: fix HE beamformer phy cap for station vif
    
    [ Upstream commit e1a491e856a8a36c46b39ecd07f3bba5a119d83a ]
    
    Set correct beamformer capabilities for station vif in HE PHY
    capability IE.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Howard Hsu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Benjamin Lin <[email protected]>
Date:   Fri Jan 26 17:09:23 2024 +0800

    wifi: mt76: mt7996: fix HIF_TXD_V2_1 value
    
    [ Upstream commit de8882775156682ba358afc82cb575c92cf3d092 ]
    
    Sync the value of HIF_TXD_V2_1 with firmware to let it correctly fill
    TXD values for HW path.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Benjamin Lin <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Benjamin Lin <[email protected]>
Date:   Fri Jan 26 17:09:15 2024 +0800

    wifi: mt76: mt7996: fix incorrect interpretation of EHT MCS caps
    
    [ Upstream commit d52c97592f06552a4289008602b5d5b724084ba7 ]
    
    The EHT MCS map subfield of 20 MHz-Only is not present in the EHT
    capability of AP, so STA does not need to parse the subfield.
    Moreover, AP should parse the subfield only if STA is 20 MHz-Only, which
    can be confirmed by checking supported channel width in HE capability.
    
    Fixes: 92aa2da9fa49 ("wifi: mt76: mt7996: enable EHT support in firmware")
    Co-developed-by: Shayne Chen <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Benjamin Lin <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Peter Chiu <[email protected]>
Date:   Fri Jan 26 17:09:13 2024 +0800

    wifi: mt76: mt7996: fix TWT issues
    
    [ Upstream commit 5c832c228f6a7ba7e900c5296ce0fb3844bafec5 ]
    
    This patch fixes the following TWT issues:
    - Change table_mask to u16 to support up to 16 TWT stations
    - Reject TWT flows for duplicated establishment
    - Fix possible unaligned pointer
    - Remove unsupported TWT_CONTROL_WAKE_DUR_UNIT flag
    - The minimum TWT duration supported by mt7996 chipsets is 64. Reply
      with TWT_SETUP_CMD_DICTATE if the min_twt_dur is smaller than 64
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jinjie Ruan <[email protected]>
Date:   Sun Sep 3 11:02:15 2023 +0800

    wifi: mwifiex: debugfs: Drop unnecessary error check for debugfs_create_dir()
    
    [ Upstream commit 50180c7f8e3de7c2d87f619131776598fcb1478d ]
    
    debugfs_create_dir() returns ERR_PTR and never return NULL.
    
    As Russell suggested, this patch removes the error checking for
    debugfs_create_dir(). This is because the DebugFS kernel API is developed
    in a way that the caller can safely ignore the errors that occur during
    the creation of DebugFS nodes. The debugfs APIs have a IS_ERR() judge in
    start_creating() which can handle it gracefully. So these checks are
    unnecessary.
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Suggested-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Martin Kaistra <[email protected]>
Date:   Thu Jan 11 17:36:27 2024 +0100

    wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
    
    [ Upstream commit 1213acb478a7181cd73eeaf00db430f1e45b1361 ]
    
    The workqueue might still be running, when the driver is stopped. To
    avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().
    
    Fixes: e542e66b7c2e ("rtl8xxxu: add bluetooth co-existence support for single antenna")
    Signed-off-by: Martin Kaistra <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bitterblue Smith <[email protected]>
Date:   Fri Mar 1 00:35:09 2024 +0200

    wifi: rtw88: 8821c: Fix beacon loss and disconnect
    
    [ Upstream commit e1dfa21427baeb813f9a2f9ceab6b7d32c3ca425 ]
    
    Tenda U9 V2.0, which contains RTL8811CU, is practically unusable because
    of frequent disconnections:
    
    Feb 23 14:46:45 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS
    Feb 23 14:46:46 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED
            bssid=90:55:de:__:__:__ reason=4 locally_generated=1
    
    Feb 23 14:46:52 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED
            - Connection to 90:55:de:__:__:__ completed [id=0 id_str=]
    Feb 23 14:46:54 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS
    Feb 23 14:46:55 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED
            bssid=90:55:de:__:__:__ reason=4 locally_generated=1
    
    Feb 23 14:47:01 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED
            - Connection to 90:55:de:__:__:__ completed [id=0 id_str=]
    Feb 23 14:47:04 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS
    Feb 23 14:47:05 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED
            bssid=90:55:de:__:__:__ reason=4 locally_generated=1
    
    This is caused by a mistake in the chip initialisation. This version of
    the chip requires loading an extra AGC table right after the main one,
    but the extra table is being loaded at the wrong time, in
    rtw_chip_board_info_setup().
    
    Move the extra AGC table loading to the right place, in
    rtw_phy_load_tables().
    
    The rtw_chip_board_info_setup() can only do "software" things, and
    rtw_phy_load_tables() can really do IO.
    
    Fixes: 5d6651fe8583 ("rtw88: 8821c: support RFE type2 wifi NIC")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bitterblue Smith <[email protected]>
Date:   Fri Mar 1 00:35:58 2024 +0200

    wifi: rtw88: 8821c: Fix false alarm count
    
    [ Upstream commit c238adbc578eeb70cbc8fdd1bef3666b0f585b13 ]
    
    total_fa_cnt is supposed to include cck_fa_cnt and ofdm_fa_cnt, not just
    ofdm_fa_cnt.
    
    Fixes: 960361238b86 ("rtw88: 8821c: add false alarm statistics")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bitterblue Smith <[email protected]>
Date:   Fri Mar 1 00:32:45 2024 +0200

    wifi: rtw88: 8821cu: Fix firmware upload fail
    
    [ Upstream commit 41a7acb7dde8395f52a707bbba7712a898dfafb0 ]
    
    RTL8822CU, RTL8822BU, and RTL8821CU need an extra register write after
    reading and writing certain addresses.
    
    Without this, the firmware upload fails approximately more than 50% of
    the time.
    
    Tested with RTL8811CU (Tenda U9 V2.0) which is the same as RTL8821CU
    but without Bluetooth.
    
    Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jц╘rц╢me Pouiller <[email protected]>
Date:   Fri Feb 2 17:42:13 2024 +0100

    wifi: wfx: fix memory leak when starting AP
    
    [ Upstream commit b8cfb7c819dd39965136a66fe3a7fde688d976fc ]
    
    Kmemleak reported this error:
    
        unreferenced object 0xd73d1180 (size 184):
          comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
          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 1e 00 01 00 00 00 00 00  ................
          backtrace:
            [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
            [<127bdd74>] __alloc_skb+0x144/0x170
            [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
            [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
            [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
            [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
            [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
            [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
            [<47bd8b68>] genl_rcv_msg+0x198/0x378
            [<453ef796>] netlink_rcv_skb+0xd0/0x130
            [<6b7c977a>] genl_rcv+0x34/0x44
            [<66b2d04d>] netlink_unicast+0x1b4/0x258
            [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
            [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
            [<d2b5212d>] ___sys_sendmsg+0x80/0xb4
            [<69954f45>] __sys_sendmsg+0x64/0xa8
        unreferenced object 0xce087000 (size 1024):
          comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
          hex dump (first 32 bytes):
            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
            10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
          backtrace:
            [<9a993714>] __kmalloc_track_caller+0x230/0x600
            [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
            [<a2c61343>] __alloc_skb+0xa0/0x170
            [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
            [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
            [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
            [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
            [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
            [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
            [<47bd8b68>] genl_rcv_msg+0x198/0x378
            [<453ef796>] netlink_rcv_skb+0xd0/0x130
            [<6b7c977a>] genl_rcv+0x34/0x44
            [<66b2d04d>] netlink_unicast+0x1b4/0x258
            [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
            [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
            [<d2b5212d>] ___sys_sendmsg+0x80/0xb4
    
    However, since the kernel is build optimized, it seems the stack is not
    accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
    is obvious in this function: memory allocated by ieee80211_beacon_get()
    is never released. Fixing this leak makes kmemleak happy.
    
    Reported-by: Ulrich Mohr <[email protected]>
    Co-developed-by: Ulrich Mohr <[email protected]>
    Signed-off-by: Ulrich Mohr <[email protected]>
    Fixes: 268bceec1684 ("staging: wfx: fix BA when device is AP and MFP is enabled")
    Signed-off-by: Jц╘rц╢me Pouiller <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ajay Singh <[email protected]>
Date:   Mon Jan 15 15:56:32 2024 +0100

    wifi: wilc1000: do not realloc workqueue everytime an interface is added
    
    [ Upstream commit 328efda22af81130c2ad981c110518cb29ff2f1d ]
    
    Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to
    "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to
    set the interface name in the workqueue name. However, while the driver
    needs only one workqueue, the wilc_netdev_ifc_init is called each time we
    add an interface over a phy, which in turns overwrite the workqueue with a
    new one. This can be observed with the following commands:
    
    for i in $(seq 0 10)
    do
      iw phy phy0 interface add wlan1 type managed
      iw dev wlan1 del
    done
    ps -eo pid,comm|grep wlan
    
     39 kworker/R-wlan0
     98 kworker/R-wlan1
    102 kworker/R-wlan1
    105 kworker/R-wlan1
    108 kworker/R-wlan1
    111 kworker/R-wlan1
    114 kworker/R-wlan1
    117 kworker/R-wlan1
    120 kworker/R-wlan1
    123 kworker/R-wlan1
    126 kworker/R-wlan1
    129 kworker/R-wlan1
    
    Fix this leakage by putting back hif_workqueue allocation in
    wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to
    set it lowercase, however it is not  attached to a specific netdev, so
    enforcing netdev name in the name is not so relevant. Still, enrich the
    name with the wiphy name to make it clear which phy is using the workqueue.
    
    Fixes: 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"")
    Signed-off-by: Ajay Singh <[email protected]>
    Co-developed-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexis Lothorц╘ <[email protected]>
Date:   Fri Jan 5 08:57:32 2024 +0100

    wifi: wilc1000: fix declarations ordering
    
    [ Upstream commit 535733e90e5d8912ebeccebb05b354a2d06ff459 ]
    
    Reorder parameters declaration in wilc_parse_join_bss_param to enforce
    reverse christmas tree
    
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Stable-dep-of: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ajay Singh <[email protected]>
Date:   Mon Jan 15 15:56:34 2024 +0100

    wifi: wilc1000: fix multi-vif management when deleting a vif
    
    [ Upstream commit 12cfc9c8d3faf887a202c89bc312202445fca7e8 ]
    
    Adding then removing a second vif currently makes the first vif not working
    anymore. This is visible for example when we have a first interface
    connected to some access point:
    - create a wpa_supplicant.conf with some AP credentials
    - wpa_supplicant -Dnl80211 -c /etc/wpa_supplicant.conf -i wlan0
    - dhclient wlan0
    - iw phy phy0 interface add wlan1 type managed
    - iw dev wlan1 del
    wlan0 does not manage properly traffic anymore (eg: ping not working)
    
    This is due to vif mode being incorrectly reconfigured with some default
    values in del_virtual_intf, affecting by default first vif.
    
    Prevent first vif from being affected on second vif removal by removing vif
    mode change command in del_virtual_intf
    
    Fixes: 9bc061e88054 ("staging: wilc1000: added support to dynamically add/remove interfaces")
    Signed-off-by: Ajay Singh <[email protected]>
    Co-developed-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexis Lothorц╘ <[email protected]>
Date:   Fri Jan 5 08:57:33 2024 +0100

    wifi: wilc1000: fix RCU usage in connect path
    
    [ Upstream commit 205c50306acf58a335eb19fa84e40140f4fe814f ]
    
    With lockdep enabled, calls to the connect function from cfg802.11 layer
    lead to the following warning:
    
    =============================
    WARNING: suspicious RCU usage
    6.7.0-rc1-wt+ #333 Not tainted
    -----------------------------
    drivers/net/wireless/microchip/wilc1000/hif.c:386
    suspicious rcu_dereference_check() usage!
    [...]
    stack backtrace:
    CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
    Hardware name: Atmel SAMA5
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x34/0x48
     dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
     wilc_parse_join_bss_param from connect+0x2c4/0x648
     connect from cfg80211_connect+0x30c/0xb74
     cfg80211_connect from nl80211_connect+0x860/0xa94
     nl80211_connect from genl_rcv_msg+0x3fc/0x59c
     genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
     netlink_rcv_skb from genl_rcv+0x2c/0x3c
     genl_rcv from netlink_unicast+0x3b0/0x550
     netlink_unicast from netlink_sendmsg+0x368/0x688
     netlink_sendmsg from ____sys_sendmsg+0x190/0x430
     ____sys_sendmsg from ___sys_sendmsg+0x110/0x158
     ___sys_sendmsg from sys_sendmsg+0xe8/0x150
     sys_sendmsg from ret_fast_syscall+0x0/0x1c
    
    This warning is emitted because in the connect path, when trying to parse
    target BSS parameters, we dereference a RCU pointer whithout being in RCU
    critical section.
    Fix RCU dereference usage by moving it to a RCU read critical section. To
    avoid wrapping the whole wilc_parse_join_bss_param under the critical
    section, just use the critical section to copy ies data
    
    Fixes: c460495ee072 ("staging: wilc1000: fix incorrent type in initializer")
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexis Lothorц╘ <[email protected]>
Date:   Mon Feb 12 13:57:37 2024 +0100

    wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
    
    [ Upstream commit cb5942b77c05d54310a0420cac12935e9b6aa21c ]
    
    wilc_netdev_cleanup currently triggers a KASAN warning, which can be
    observed on interface registration error path, or simply by
    removing the module/unbinding device from driver:
    
    echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
    Read of size 4 at addr c54d1ce8 by task sh/86
    
    CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
    Hardware name: Atmel SAMA5
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x34/0x58
     dump_stack_lvl from print_report+0x154/0x500
     print_report from kasan_report+0xac/0xd8
     kasan_report from wilc_netdev_cleanup+0x508/0x5cc
     wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
     wilc_bus_remove from spi_remove+0x8c/0xac
     spi_remove from device_release_driver_internal+0x434/0x5f8
     device_release_driver_internal from unbind_store+0xbc/0x108
     unbind_store from kernfs_fop_write_iter+0x398/0x584
     kernfs_fop_write_iter from vfs_write+0x728/0xf88
     vfs_write from ksys_write+0x110/0x1e4
     ksys_write from ret_fast_syscall+0x0/0x1c
    
    [...]
    
    Allocated by task 1:
     kasan_save_track+0x30/0x5c
     __kasan_kmalloc+0x8c/0x94
     __kmalloc_node+0x1cc/0x3e4
     kvmalloc_node+0x48/0x180
     alloc_netdev_mqs+0x68/0x11dc
     alloc_etherdev_mqs+0x28/0x34
     wilc_netdev_ifc_init+0x34/0x8ec
     wilc_cfg80211_init+0x690/0x910
     wilc_bus_probe+0xe0/0x4a0
     spi_probe+0x158/0x1b0
     really_probe+0x270/0xdf4
     __driver_probe_device+0x1dc/0x580
     driver_probe_device+0x60/0x140
     __driver_attach+0x228/0x5d4
     bus_for_each_dev+0x13c/0x1a8
     bus_add_driver+0x2a0/0x608
     driver_register+0x24c/0x578
     do_one_initcall+0x180/0x310
     kernel_init_freeable+0x424/0x484
     kernel_init+0x20/0x148
     ret_from_fork+0x14/0x28
    
    Freed by task 86:
     kasan_save_track+0x30/0x5c
     kasan_save_free_info+0x38/0x58
     __kasan_slab_free+0xe4/0x140
     kfree+0xb0/0x238
     device_release+0xc0/0x2a8
     kobject_put+0x1d4/0x46c
     netdev_run_todo+0x8fc/0x11d0
     wilc_netdev_cleanup+0x1e4/0x5cc
     wilc_bus_remove+0xc8/0xec
     spi_remove+0x8c/0xac
     device_release_driver_internal+0x434/0x5f8
     unbind_store+0xbc/0x108
     kernfs_fop_write_iter+0x398/0x584
     vfs_write+0x728/0xf88
     ksys_write+0x110/0x1e4
     ret_fast_syscall+0x0/0x1c
     [...]
    
    David Mosberger-Tan initial investigation [1] showed that this
    use-after-free is due to netdevice unregistration during vif list
    traversal. When unregistering a net device, since the needs_free_netdev has
    been set to true during registration, the netdevice object is also freed,
    and as a consequence, the corresponding vif object too, since it is
    attached to it as private netdevice data. The next occurrence of the loop
    then tries to access freed vif pointer to the list to move forward in the
    list.
    
    Fix this use-after-free thanks to two mechanisms:
    - navigate in the list with list_for_each_entry_safe, which allows to
      safely modify the list as we go through each element. For each element,
      remove it from the list with list_del_rcu
    - make sure to wait for RCU grace period end after each vif removal to make
      sure it is safe to free the corresponding vif too (through
      unregister_netdev)
    
    Since we are in a RCU "modifier" path (not a "reader" path), and because
    such path is expected not to be concurrent to any other modifier (we are
    using the vif_mutex lock), we do not need to use RCU list API, that's why
    we can benefit from list_for_each_entry_safe.
    
    [1] https://lore.kernel.org/linux-wireless/[email protected]/
    
    Fixes: 8399918f3056 ("staging: wilc1000: use RCU list to maintain vif interfaces list")
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Alexis Lothorц╘ <[email protected]>
Date:   Sat Feb 17 14:22:41 2024 +0100

    wifi: wilc1000: revert reset line logic flip
    
    [ Upstream commit f3ec643947634bed41b97bd56b248f7c78498eab ]
    
    This reverts commit fcf690b0b47494df51d214db5c5a714a400b0257.
    
    When using a wilc1000 chip over a spi bus, users can optionally define a
    reset gpio and a chip enable gpio. The reset line of wilc1000 is active
    low, so to hold the chip in reset, a low (physical) value must be applied.
    
    The corresponding device tree binding documentation was introduced by
    commit f31ee3c0a555 ("wilc1000: Document enable-gpios and reset-gpios
    properties") and correctly indicates that the reset line is an active-low
    signal. The corresponding driver part, brought by commit ec031ac4792c
    ("wilc1000: Add reset/enable GPIO support to SPI driver") was applying the
    correct logic. But commit fcf690b0b474 ("wifi: wilc1000: use correct
    sequence of RESET for chip Power-UP/Down") eventually flipped this logic
    and started misusing the gpiod APIs, applying an inverted logic when
    powering up/down the chip (for example, setting the reset line to a logic
    "1" during power up, which in fact asserts the reset line when device tree
    describes the reset line as GPIO_ACTIVE_LOW). As a consequence, any
    platform currently using the driver in SPI mode must use a faulty reset
    line description in device tree, or else chip will be maintained in reset
    and will not even allow to bring up the chip.
    
    Fix reset line usage by inverting back the gpiod APIs usage, setting the
    reset line to the logic value "0" when powering the chip, and the logic
    value "1" when powering off the chip.
    
    Fixes: fcf690b0b474 ("wifi: wilc1000: use correct sequence of RESET for chip Power-UP/Down")
    Signed-off-by: Alexis Lothorц╘ <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Acked-by: Ajay Singh <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nikita Zhandarovich <[email protected]>
Date:   Thu Mar 14 16:49:06 2024 -0600

    wireguard: receive: annotate data-race around receiving_counter.counter
    
    [ Upstream commit bba045dc4d996d03dce6fe45726e78a1a1f6d4c3 ]
    
    Syzkaller with KCSAN identified a data-race issue when accessing
    keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()
    annotations to mark the data race as intentional.
    
        BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll
    
        write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0:
         counter_validate drivers/net/wireguard/receive.c:321 [inline]
         wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461
         __napi_poll+0x60/0x3b0 net/core/dev.c:6536
         napi_poll net/core/dev.c:6605 [inline]
         net_rx_action+0x32b/0x750 net/core/dev.c:6738
         __do_softirq+0xc4/0x279 kernel/softirq.c:553
         do_softirq+0x5e/0x90 kernel/softirq.c:454
         __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
         __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
         _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
         spin_unlock_bh include/linux/spinlock.h:396 [inline]
         ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]
         wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499
         process_one_work kernel/workqueue.c:2633 [inline]
         ...
    
        read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1:
         decrypt_packet drivers/net/wireguard/receive.c:252 [inline]
         wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501
         process_one_work kernel/workqueue.c:2633 [inline]
         process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706
         worker_thread+0x525/0x730 kernel/workqueue.c:2787
         ...
    
    Fixes: a9e90d9931f3 ("wireguard: noise: separate receive counter from send counter")
    Reported-by: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Audra Mitchell <[email protected]>
Date:   Mon Jan 15 12:08:22 2024 -0500

    workqueue.c: Increase workqueue name length
    
    [ Upstream commit 31c89007285d365aa36f71d8fb0701581c770a27 ]
    
    Currently we limit the size of the workqueue name to 24 characters due to
    commit ecf6881ff349 ("workqueue: make workqueue->name[] fixed len")
    Increase the size to 32 characters and print a warning in the event
    the requested name is larger than the limit of 32 characters.
    
    Signed-off-by: Audra Mitchell <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Tue Jan 30 18:55:55 2024 -1000

    workqueue: Don't call cpumask_test_cpu() with -1 CPU in wq_update_node_max_active()
    
    [ Upstream commit 15930da42f8981dc42c19038042947b475b19f47 ]
    
    For wq_update_node_max_active(), @off_cpu of -1 indicates that no CPU is
    going down. The function was incorrectly calling cpumask_test_cpu() with -1
    CPU leading to oopses like the following on some archs:
    
      Unable to handle kernel paging request at virtual address ffff0002100296e0
      ..
      pc : wq_update_node_max_active+0x50/0x1fc
      lr : wq_update_node_max_active+0x1f0/0x1fc
      ...
      Call trace:
        wq_update_node_max_active+0x50/0x1fc
        apply_wqattrs_commit+0xf0/0x114
        apply_workqueue_attrs_locked+0x58/0xa0
        alloc_workqueue+0x5ac/0x774
        workqueue_init_early+0x460/0x540
        start_kernel+0x258/0x684
        __primary_switched+0xb8/0xc0
      Code: 9100a273 35000d01 53067f00 d0016dc1 (f8607a60)
      ---[ end trace 0000000000000000 ]---
      Kernel panic - not syncing: Attempted to kill the idle task!
      ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
    
    Fix it.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: Marek Szyprowski <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Factor out pwq_is_empty()
    
    [ Upstream commit afa87ce85379e2d93863fce595afdb5771a84004 ]
    
    "!pwq->nr_active && list_empty(&pwq->inactive_works)" test is repeated
    multiple times. Let's factor it out into pwq_is_empty().
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:25 2024 -1000

    workqueue: Implement system-wide nr_active enforcement for unbound workqueues
    
    [ Upstream commit 5797b1c18919cd9c289ded7954383e499f729ce0 ]
    
    A pool_workqueue (pwq) represents the connection between a workqueue and a
    worker_pool. One of the roles that a pwq plays is enforcement of the
    max_active concurrency limit. Before 636b927eba5b ("workqueue: Make unbound
    workqueues to use per-cpu pool_workqueues"), there was one pwq per each CPU
    for per-cpu workqueues and per each NUMA node for unbound workqueues, which
    was a natural result of per-cpu workqueues being served by per-cpu pools and
    unbound by per-NUMA pools.
    
    In terms of max_active enforcement, this was, while not perfect, workable.
    For per-cpu workqueues, it was fine. For unbound, it wasn't great in that
    NUMA machines would get max_active that's multiplied by the number of nodes
    but didn't cause huge problems because NUMA machines are relatively rare and
    the node count is usually pretty low.
    
    However, cache layouts are more complex now and sharing a worker pool across
    a whole node didn't really work well for unbound workqueues. Thus, a series
    of commits culminating on 8639ecebc9b1 ("workqueue: Make unbound workqueues
    to use per-cpu pool_workqueues") implemented more flexible affinity
    mechanism for unbound workqueues which enables using e.g. last-level-cache
    aligned pools. In the process, 636b927eba5b ("workqueue: Make unbound
    workqueues to use per-cpu pool_workqueues") made unbound workqueues use
    per-cpu pwqs like per-cpu workqueues.
    
    While the change was necessary to enable more flexible affinity scopes, this
    came with the side effect of blowing up the effective max_active for unbound
    workqueues. Before, the effective max_active for unbound workqueues was
    multiplied by the number of nodes. After, by the number of CPUs.
    
    636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu
    pool_workqueues") claims that this should generally be okay. It is okay for
    users which self-regulates concurrency level which are the vast majority;
    however, there are enough use cases which actually depend on max_active to
    prevent the level of concurrency from going bonkers including several IO
    handling workqueues that can issue a work item for each in-flight IO. With
    targeted benchmarks, the misbehavior can easily be exposed as reported in
    http://lkml.kernel.org/r/dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3.
    
    Unfortunately, there is no way to express what these use cases need using
    per-cpu max_active. A CPU may issue most of in-flight IOs, so we don't want
    to set max_active too low but as soon as we increase max_active a bit, we
    can end up with unreasonable number of in-flight work items when many CPUs
    issue IOs at the same time. ie. The acceptable lowest max_active is higher
    than the acceptable highest max_active.
    
    Ideally, max_active for an unbound workqueue should be system-wide so that
    the users can regulate the total level of concurrency regardless of node and
    cache layout. The reasons workqueue hasn't implemented that yet are:
    
    - One max_active enforcement decouples from pool boundaires, chaining
      execution after a work item finishes requires inter-pool operations which
      would require lock dancing, which is nasty.
    
    - Sharing a single nr_active count across the whole system can be pretty
      expensive on NUMA machines.
    
    - Per-pwq enforcement had been more or less okay while we were using
      per-node pools.
    
    It looks like we no longer can avoid decoupling max_active enforcement from
    pool boundaries. This patch implements system-wide nr_active mechanism with
    the following design characteristics:
    
    - To avoid sharing a single counter across multiple nodes, the configured
      max_active is split across nodes according to the proportion of each
      workqueue's online effective CPUs per node. e.g. A node with twice more
      online effective CPUs will get twice higher portion of max_active.
    
    - Workqueue used to be able to process a chain of interdependent work items
      which is as long as max_active. We can't do this anymore as max_active is
      distributed across the nodes. Instead, a new parameter min_active is
      introduced which determines the minimum level of concurrency within a node
      regardless of how max_active distribution comes out to be.
    
      It is set to the smaller of max_active and WQ_DFL_MIN_ACTIVE which is 8.
      This can lead to higher effective max_weight than configured and also
      deadlocks if a workqueue was depending on being able to handle chains of
      interdependent work items that are longer than 8.
    
      I believe these should be fine given that the number of CPUs in each NUMA
      node is usually higher than 8 and work item chain longer than 8 is pretty
      unlikely. However, if these assumptions turn out to be wrong, we'll need
      to add an interface to adjust min_active.
    
    - Each unbound wq has an array of struct wq_node_nr_active which tracks
      per-node nr_active. When its pwq wants to run a work item, it has to
      obtain the matching node's nr_active. If over the node's max_active, the
      pwq is queued on wq_node_nr_active->pending_pwqs. As work items finish,
      the completion path round-robins the pending pwqs activating the first
      inactive work item of each, which involves some pool lock dancing and
      kicking other pools. It's not the simplest code but doesn't look too bad.
    
    v4: - wq_adjust_max_active() updated to invoke wq_update_node_max_active().
    
        - wq_adjust_max_active() is now protected by wq->mutex instead of
          wq_pool_mutex.
    
    v3: - wq_node_max_active() used to calculate per-node max_active on the fly
          based on system-wide CPU online states. Lai pointed out that this can
          lead to skewed distributions for workqueues with restricted cpumasks.
          Update the max_active distribution to use per-workqueue effective
          online CPU counts instead of system-wide and cache the calculation
          results in node_nr_active->max.
    
    v2: - wq->min/max_active now uses WRITE/READ_ONCE() as suggested by Lai.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: Naohiro Aota <[email protected]>
    Link: http://lkml.kernel.org/r/dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3
    Fixes: 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues")
    Reviewed-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Introduce struct wq_node_nr_active
    
    [ Upstream commit 91ccc6e7233bb10a9c176aa4cc70d6f432a441a5 ]
    
    Currently, for both percpu and unbound workqueues, max_active applies
    per-cpu, which is a recent change for unbound workqueues. The change for
    unbound workqueues was a significant departure from the previous behavior of
    per-node application. It made some use cases create undesirable number of
    concurrent work items and left no good way of fixing them. To address the
    problem, workqueue is implementing a NUMA node segmented global nr_active
    mechanism, which will be explained further in the next patch.
    
    As a preparation, this patch introduces struct wq_node_nr_active. It's a
    data structured allocated for each workqueue and NUMA node pair and
    currently only tracks the workqueue's number of active work items on the
    node. This is split out from the next patch to make it easier to understand
    and review.
    
    Note that there is an extra wq_node_nr_active allocated for the invalid node
    nr_node_ids which is used to track nr_active for pools which don't have NUMA
    node associated such as the default fallback system-wide pool.
    
    This doesn't cause any behavior changes visible to userland yet. The next
    patch will expand to implement the control mechanism on top.
    
    v4: - Fixed out-of-bound access when freeing per-cpu workqueues.
    
    v3: - Use flexible array for wq->node_nr_active as suggested by Lai.
    
    v2: - wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai.
    
        - Lai pointed out that pwq_tryinc_nr_active() incorrectly dropped
          pwq->max_active check. Restored. As the next patch replaces the
          max_active enforcement mechanism, this doesn't change the end result.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Make wq_adjust_max_active() round-robin pwqs while activating
    
    [ Upstream commit c5404d4e6df6faba1007544b5f4e62c7c14416dd ]
    
    wq_adjust_max_active() needs to activate work items after max_active is
    increased. Previously, it did that by visiting each pwq once activating all
    that could be activated. While this makes sense with per-pwq nr_active,
    nr_active will be shared across multiple pwqs for unbound wqs. Then, we'd
    want to round-robin through pwqs to be fairer.
    
    In preparation, this patch makes wq_adjust_max_active() round-robin pwqs
    while activating. While the activation ordering changes, this shouldn't
    cause user-noticeable behavior changes.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Move nr_active handling into helpers
    
    [ Upstream commit 1c270b79ce0b8290f146255ea9057243f6dd3c17 ]
    
    __queue_work(), pwq_dec_nr_in_flight() and wq_adjust_max_active() were
    open-coding nr_active handling, which is fine given that the operations are
    trivial. However, the planned unbound nr_active update will make them more
    complicated, so let's move them into helpers.
    
    - pwq_tryinc_nr_active() is added. It increments nr_active if under
      max_active limit and return a boolean indicating whether inc was
      successful. Note that the function is structured to accommodate future
      changes. __queue_work() is updated to use the new helper.
    
    - pwq_activate_first_inactive() is updated to use pwq_tryinc_nr_active() and
      thus no longer assumes that nr_active is under max_active and returns a
      boolean to indicate whether a work item has been activated.
    
    - wq_adjust_max_active() no longer tests directly whether a work item can be
      activated. Instead, it's updated to use the return value of
      pwq_activate_first_inactive() to tell whether a work item has been
      activated.
    
    - nr_active decrement and activating the first inactive work item is
      factored into pwq_dec_nr_active().
    
    v3: - WARN_ON_ONCE(!WORK_STRUCT_INACTIVE) added to __pwq_activate_work() as
          now we're calling the function unconditionally from
          pwq_activate_first_inactive().
    
    v2: - wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Move pwq->max_active to wq->max_active
    
    [ Upstream commit a045a272d887575da17ad86d6573e82871b50c27 ]
    
    max_active is a workqueue-wide setting and the configured value is stored in
    wq->saved_max_active; however, the effective value was stored in
    pwq->max_active. While this is harmless, it makes max_active update process
    more complicated and gets in the way of the planned max_active semantic
    updates for unbound workqueues.
    
    This patches moves pwq->max_active to wq->max_active. This simplifies the
    code and makes freezing and noop max_active updates cheaper too. No
    user-visible behavior change is intended.
    
    As wq->max_active is updated while holding wq mutex but read without any
    locking, it now uses WRITE/READ_ONCE(). A new locking locking rule WO is
    added for it.
    
    v2: wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: RCU protect wq->dfl_pwq and implement accessors for it
    
    [ Upstream commit 9f66cff212bb3c1cd25996aaa0dfd0c9e9d8baab ]
    
    wq->cpu_pwq is RCU protected but wq->dfl_pwq isn't. This is okay because
    currently wq->dfl_pwq is used only accessed to install it into wq->cpu_pwq
    which doesn't require RCU access. However, we want to be able to access
    wq->dfl_pwq under RCU in the future to access its __pod_cpumask and the code
    can be made easier to read by making the two pwq fields behave in the same
    way.
    
    - Make wq->dfl_pwq RCU protected.
    
    - Add unbound_pwq_slot() and unbound_pwq() which can access both ->dfl_pwq
      and ->cpu_pwq. The former returns the double pointer that can be used
      access and update the pwqs. The latter performs locking check and
      dereferences the double pointer.
    
    - pwq accesses and updates are converted to use unbound_pwq[_slot]().
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tejun Heo <[email protected]>
Date:   Mon Jan 29 08:11:24 2024 -1000

    workqueue: Replace pwq_activate_inactive_work() with [__]pwq_activate_work()
    
    [ Upstream commit 4c6380305d21e36581b451f7337a36c93b64e050 ]
    
    To prepare for unbound nr_active handling improvements, move work activation
    part of pwq_activate_inactive_work() into __pwq_activate_work() and add
    pwq_activate_work() which tests WORK_STRUCT_INACTIVE and updates nr_active.
    
    pwq_activate_first_inactive() and try_to_grab_pending() are updated to use
    pwq_activate_work(). The latter conversion is functionally identical. For
    the former, this conversion adds an unnecessary WORK_STRUCT_INACTIVE
    testing. This is temporary and will be removed by the next patch.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Lai Jiangshan <[email protected]>
    Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kees Cook <[email protected]>
Date:   Tue Feb 27 09:51:12 2024 -0800

    x86, relocs: Ignore relocations in .notes section
    
    [ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ]
    
    When building with CONFIG_XEN_PV=y, .text symbols are emitted into
    the .notes section so that Xen can find the "startup_xen" entry point.
    This information is used prior to booting the kernel, so relocations
    are not useful. In fact, performing relocations against the .notes
    section means that the KASLR base is exposed since /sys/kernel/notes
    is world-readable.
    
    To avoid leaking the KASLR base without breaking unprivileged tools that
    are expecting to read /sys/kernel/notes, skip performing relocations in
    the .notes section. The values readable in .notes are then identical to
    those found in System.map.
    
    Reported-by: Guixiong Wei <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: 5ead97c84fa7 ("xen: Core Xen implementation")
    Fixes: da1a679cde9b ("Add /sys/kernel/notes")
    Reviewed-by: Juergen Gross <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ard Biesheuvel <[email protected]>
Date:   Fri Mar 15 16:26:16 2024 +0100

    x86/efistub: Clear decompressor BSS in native EFI entrypoint
    
    [ Upstream commit b3810c5a2cc4a6665f7a65bed5393c75ce3f3aa2 ]
    
    The EFI stub on x86 no longer invokes the decompressor as a subsequent
    boot stage, but calls into the decompression code directly while running
    in the context of the EFI boot services.
    
    This means that when using the native EFI entrypoint (as opposed to the
    EFI handover protocol, which clears BSS explicitly), the firmware PE
    image loader is being relied upon to ensure that BSS is zeroed before
    the EFI stub is entered from the firmware.
    
    As Radek's report proves, this is a bad idea. Not all loaders do this
    correctly, which means some global variables that should be statically
    initialized to 0x0 may have junk in them.
    
    So clear BSS explicitly when entering via efi_pe_entry(). Note that
    zeroing BSS from C code is not generally safe, but in this case, the
    following assignment and dereference of a global pointer variable
    ensures that the memset() cannot be deferred or reordered.
    
    Cc: <[email protected]> # v6.1+
    Reported-by: Radek Podgorny <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ard Biesheuvel <[email protected]>
Date:   Fri Mar 22 17:01:45 2024 +0100

    x86/efistub: Don't clear BSS twice in mixed mode
    
    [ Upstream commit df7ecce842b846a04d087ba85fdb79a90e26a1b0 ]
    
    Clearing BSS should only be done once, at the very beginning.
    efi_pe_entry() is the entrypoint from the firmware, which may not clear
    BSS and so it is done explicitly. However, efi_pe_entry() is also used
    as an entrypoint by the mixed mode startup code, in which case BSS will
    already have been cleared, and doing it again at this point will corrupt
    global variables holding the firmware's GDT/IDT and segment selectors.
    
    So make the memset() conditional on whether the EFI stub is running in
    native mode.
    
    Fixes: b3810c5a2cc4a666 ("x86/efistub: Clear decompressor BSS in native EFI entrypoint")
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Saurabh Sengar <[email protected]>
Date:   Mon Jan 15 09:57:40 2024 -0800

    x86/hyperv: Allow 15-bit APIC IDs for VTL platforms
    
    [ Upstream commit 0d63e4c0ebc2b5c329babde44fd61d3f08db814d ]
    
    The current method for signaling the compatibility of a Hyper-V host
    with MSIs featuring 15-bit APIC IDs relies on a synthetic cpuid leaf.
    However, for higher VTLs, this leaf is not reported, due to the absence
    of an IO-APIC.
    
    As an alternative, assume that when running at a high VTL, the host
    supports 15-bit APIC IDs. This assumption is safe, as Hyper-V does not
    employ any architectural MSIs at higher VTLs
    
    This unblocks startup of VTL2 environments with more than 256 CPUs.
    
    Signed-off-by: Saurabh Sengar <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Saurabh Sengar <[email protected]>
Date:   Sun Mar 3 00:01:36 2024 -0800

    x86/hyperv: Use per cpu initial stack for vtl context
    
    [ Upstream commit 2b4b90e053a29057fb05ba81acce26bddce8d404 ]
    
    Currently, the secondary CPUs in Hyper-V VTL context lack support for
    parallel startup. Therefore, relying on the single initial_stack fetched
    from the current task structure suffices for all vCPUs.
    
    However, common initial_stack risks stack corruption when parallel startup
    is enabled. In order to facilitate parallel startup, use the initial_stack
    from the per CPU idle thread instead of the current task.
    
    Fixes: 3be1bc2fe9d2 ("x86/hyperv: VTL support for Hyper-V")
    Signed-off-by: Saurabh Sengar <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hou Tao <[email protected]>
Date:   Fri Feb 2 18:39:34 2024 +0800

    x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()
    
    [ Upstream commit 32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58 ]
    
    When trying to use copy_from_kernel_nofault() to read vsyscall page
    through a bpf program, the following oops was reported:
    
      BUG: unable to handle page fault for address: ffffffffff600000
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
      Oops: 0000 [#1] PREEMPT SMP PTI
      CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
      RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
      ......
      Call Trace:
       <TASK>
       ? copy_from_kernel_nofault+0x6f/0x110
       bpf_probe_read_kernel+0x1d/0x50
       bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d
       trace_call_bpf+0xc5/0x1c0
       perf_call_bpf_enter.isra.0+0x69/0xb0
       perf_syscall_enter+0x13e/0x200
       syscall_trace_enter+0x188/0x1c0
       do_syscall_64+0xb5/0xe0
       entry_SYSCALL_64_after_hwframe+0x6e/0x76
       </TASK>
      ......
      ---[ end trace 0000000000000000 ]---
    
    The oops is triggered when:
    
    1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall
    page and invokes copy_from_kernel_nofault() which in turn calls
    __get_user_asm().
    
    2) Because the vsyscall page address is not readable from kernel space,
    a page fault exception is triggered accordingly.
    
    3) handle_page_fault() considers the vsyscall page address as a user
    space address instead of a kernel space address. This results in the
    fix-up setup by bpf not being applied and a page_fault_oops() is invoked
    due to SMAP.
    
    Considering handle_page_fault() has already considered the vsyscall page
    address as a userspace address, fix the problem by disallowing vsyscall
    page read for copy_from_kernel_nofault().
    
    Originally-by: Thomas Gleixner <[email protected]>
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/CAG48ez06TZft=ATH1qh2c5mpS5BT8UakwNkzi6nvK5_djC-4Nw@mail.gmail.com
    Reported-by: xingwei lee <[email protected]>
    Closes: https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com
    Signed-off-by: Hou Tao <[email protected]>
    Reviewed-by: Sohil Mehta <[email protected]>
    Acked-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Michael Roth <[email protected]>
Date:   Wed Nov 22 10:37:00 2023 -0600

    x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type
    
    [ Upstream commit 8e5647a723c49d73b9f108a8bb38e8c29d3948ea ]
    
    On 64-bit platforms, the pfn_to_kaddr() macro requires that the input
    value is 64 bits in order to ensure that valid address bits don't get
    lost when shifting that input by PAGE_SHIFT to calculate the physical
    address to provide a virtual address for.
    
    One such example is in pvalidate_pages() (used by SEV-SNP guests), where
    the GFN in the struct used for page-state change requests is a 40-bit
    bit-field, so attempts to pass this GFN field directly into
    pfn_to_kaddr() ends up causing guest crashes when dealing with addresses
    above the 1TB range due to the above.
    
    Fix this issue with SEV-SNP guests, as well as any similar cases that
    might cause issues in current/future code, by using an inline function,
    instead of a macro, so that the input is implicitly cast to the
    expected 64-bit input type prior to performing the shift operation.
    
    While it might be argued that the issue is on the caller side, other
    archs/macros have taken similar approaches to deal with instances like
    this, such as ARM explicitly casting the input to phys_addr_t:
    
      e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()")
    
    A C inline function is even better though.
    
    [ mingo: Refined the changelog some more & added __always_inline. ]
    
    Fixes: 6c3211796326 ("x86/sev: Add SNP-specific unaccepted memory support")
    Suggested-by: Dave Hansen <[email protected]>
    Suggested-by: H. Peter Anvin <[email protected]>
    Signed-off-by: Michael Roth <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Andy Lutomirski <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Hou Tao <[email protected]>
Date:   Fri Feb 2 18:39:33 2024 +0800

    x86/mm: Move is_vsyscall_vaddr() into asm/vsyscall.h
    
    [ Upstream commit ee0e39a63b78849f8abbef268b13e4838569f646 ]
    
    Move is_vsyscall_vaddr() into asm/vsyscall.h to make it available for
    copy_from_kernel_nofault_allowed() in arch/x86/mm/maccess.c.
    
    Reviewed-by: Sohil Mehta <[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]>

Author: Tony Luck <[email protected]>
Date:   Mon Jan 22 10:08:07 2024 -0800

    x86/resctrl: Implement new mba_MBps throttling heuristic
    
    [ Upstream commit c2427e70c1630d98966375fffc2b713ab9768a94 ]
    
    The mba_MBps feedback loop increases throttling when a group is using
    more bandwidth than the target set by the user in the schemata file, and
    decreases throttling when below target.
    
    To avoid possibly stepping throttling up and down on every poll a flag
    "delta_comp" is set whenever throttling is changed to indicate that the
    actual change in bandwidth should be recorded on the next poll in
    "delta_bw". Throttling is only reduced if the current bandwidth plus
    delta_bw is below the user target.
    
    This algorithm works well if the workload has steady bandwidth needs.
    But it can go badly wrong if the workload moves to a different phase
    just as the throttling level changed. E.g. if the workload becomes
    essentially idle right as throttling level is increased, the value
    calculated for delta_bw will be more or less the old bandwidth level.
    If the workload then resumes, Linux may never reduce throttling because
    current bandwidth plus delta_bw is above the target set by the user.
    
    Implement a simpler heuristic by assuming that in the worst case the
    currently measured bandwidth is being controlled by the current level of
    throttling. Compute how much it may increase if throttling is relaxed to
    the next higher level. If that is still below the user target, then it
    is ok to reduce the amount of throttling.
    
    Fixes: ba0f26d8529c ("x86/intel_rdt/mba_sc: Prepare for feedback loop")
    Reported-by: Xiaochen Shen <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Tested-by: Xiaochen Shen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Babu Moger <[email protected]>
Date:   Mon Jan 15 16:52:28 2024 -0600

    x86/resctrl: Read supported bandwidth sources from CPUID
    
    [ Upstream commit 54e35eb8611cce5550d3d7689679b1a91c864f28 ]
    
    If the BMEC (Bandwidth Monitoring Event Configuration) feature is
    supported, the bandwidth events can be configured. The maximum supported
    bandwidth bitmask can be read from CPUID:
    
      CPUID_Fn80000020_ECX_x03 [Platform QoS Monitoring Bandwidth Event Configuration]
      Bits    Description
      31:7    Reserved
       6:0    Identifies the bandwidth sources that can be tracked.
    
    While at it, move the mask checking to mon_config_write() before
    iterating over all the domains. Also, print the valid bitmask when the
    user tries to configure invalid event configuration value.
    
    The CPUID details are documented in the Processor Programming Reference
    (PPR) Vol 1.1 for AMD Family 19h Model 11h B1 - 55901 Rev 0.25 in the
    Link tag.
    
    Fixes: dc2a3e857981 ("x86/resctrl: Add interface to read mbm_total_bytes_config")
    Signed-off-by: Babu Moger <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
    Link: https://lore.kernel.org/r/669896fa512c7451319fa5ca2fdb6f7e015b5635.1705359148.git.babu.moger@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Babu Moger <[email protected]>
Date:   Mon Jan 15 16:52:27 2024 -0600

    x86/resctrl: Remove hard-coded memory bandwidth limit
    
    [ Upstream commit 0976783bb123f30981bc1e7a14d9626a6f63aeac ]
    
    The QOS Memory Bandwidth Enforcement Limit is reported by
    CPUID_Fn80000020_EAX_x01 and CPUID_Fn80000020_EAX_x02:
    
      Bits   Description
      31:0   BW_LEN: Size of the QOS Memory Bandwidth Enforcement Limit.
    
    Newer processors can support higher bandwidth limit than the current
    hard-coded value. Remove latter and detect using CPUID instead. Also,
    update the register variables eax and edx to match the AMD CPUID
    definition.
    
    The CPUID details are documented in the Processor Programming Reference
    (PPR) Vol 1.1 for AMD Family 19h Model 11h B1 - 55901 Rev 0.25 in the
    Link tag below.
    
    Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
    Signed-off-by: Babu Moger <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
    Link: https://lore.kernel.org/r/c26a8ca79d399ed076cf8bf2e9fbc58048808289.1705359148.git.babu.moger@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ard Biesheuvel <[email protected]>
Date:   Fri Jan 26 17:39:19 2024 +0100

    x86/sme: Fix memory encryption setting if enabled by default and not overridden
    
    [ Upstream commit e814b59e6c2b11f5a3d007b2e61f7d550c354c3a ]
    
    Commit
    
      cbebd68f59f0 ("x86/mm: Fix use of uninitialized buffer in sme_enable()")
    
    'fixed' an issue in sme_enable() detected by static analysis, and broke
    the common case in the process.
    
    cmdline_find_option() will return < 0 on an error, or when the command
    line argument does not appear at all. In this particular case, the
    latter is not an error condition, and so the early exit is wrong.
    
    Instead, without mem_encrypt= on the command line, the compile time
    default should be honoured, which could be to enable memory encryption,
    and this is currently broken.
    
    Fix it by setting sme_me_mask to a preliminary value based on the
    compile time default, and only omitting the command line argument test
    when cmdline_find_option() returns an error.
    
      [ bp: Drop active_by_default while at it. ]
    
    Fixes: cbebd68f59f0 ("x86/mm: Fix use of uninitialized buffer in sme_enable()")
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Tom Lendacky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kunwu Chan <[email protected]>
Date:   Fri Jan 19 17:49:48 2024 +0800

    x86/xen: Add some null pointer checking to smp.c
    
    [ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Suggested-by: Markus Elfring <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Juergen Gross <[email protected]>
Date:   Wed Mar 13 08:14:09 2024 +0100

    xen/events: increment refcnt only if event channel is refcounted
    
    [ Upstream commit d277f9d82802223f242cd9b60c988cfdda1d6be0 ]
    
    In bind_evtchn_to_irq_chip() don't increment the refcnt of the event
    channel blindly. In case the event channel is NOT refcounted, issue a
    warning instead.
    
    Add an additional safety net by doing the refcnt increment only if the
    caller has specified IRQF_SHARED in the irqflags parameter.
    
    Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Oleksandr Tyshchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Juergen Gross <[email protected]>
Date:   Wed Mar 13 08:14:08 2024 +0100

    xen/evtchn: avoid WARN() when unbinding an event channel
    
    [ Upstream commit 51c23bd691c0f1fb95b29731c356c6fd69925d17 ]
    
    When unbinding a user event channel, the related handler might be
    called a last time in case the kernel was built with
    CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.
    
    Avoid that by adding an "unbinding" flag to struct user_event which
    will short circuit the handler.
    
    Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
    Reported-by: Demi Marie Obenour <[email protected]>
    Tested-by: Demi Marie Obenour <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Oleksandr Tyshchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Leon Romanovsky <[email protected]>
Date:   Tue Mar 12 13:55:22 2024 +0200

    xfrm: Allow UDP encapsulation only in offload modes
    
    [ Upstream commit 773bb766ca4a05bf363203030b72b10088869224 ]
    
    The missing check of x->encap caused to the situation where GSO packets
    were created with UDP encapsulation.
    
    As a solution return the encap check for non-offloaded SA.
    
    Fixes: 983a73da1f99 ("xfrm: Pass UDP encapsulation in TX packet offload")
    Closes: https://lore.kernel.org/all/[email protected]
    Reported-by: Paolo Abeni <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mike Yu <[email protected]>
Date:   Mon Mar 4 12:24:08 2024 +0000

    xfrm: fix xfrm child route lookup for packet offload
    
    [ Upstream commit d4872d70fc6feabfc8e897edad993a81096ade9f ]
    
    In current code, xfrm_bundle_create() always uses the matched
    SA's family type to look up a xfrm child route for the skb.
    The route returned by xfrm_dst_lookup() will eventually be
    used in xfrm_output_resume() (skb_dst(skb)->ops->local_out()).
    
    If packet offload is used, the above behavior can lead to
    calling ip_local_out() for an IPv6 packet or calling
    ip6_local_out() for an IPv4 packet, which is likely to fail.
    
    This change fixes the behavior by checking if the matched SA
    has packet offload enabled. If not, keep the same behavior;
    if yes, use the matched SP's family type for the lookup.
    
    Test: verified IPv6-in-IPv4 packets on Android device with
          IPsec packet offload enabled
    Signed-off-by: Mike Yu <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mike Yu <[email protected]>
Date:   Mon Mar 4 12:24:09 2024 +0000

    xfrm: set skb control buffer based on packet offload as well
    
    [ Upstream commit 8688ab2170a5be0bc922195f7091c38b506bab2e ]
    
    In packet offload, packets are not encrypted in XFRM stack, so
    the next network layer which the packets will be forwarded to
    should depend on where the packet came from (either xfrm4_output
    or xfrm6_output) rather than the matched SA's family type.
    
    Test: verified IPv6-in-IPv4 packets on Android device with
          IPsec packet offload enabled
    Signed-off-by: Mike Yu <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>