Linux 6.7.11

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

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

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

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

ACPI: resource: Add Infinity laptops to irq1_edge_low_force_override [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

 
ALSA: hda/realtek - ALC285 reduce pop noise from Headphone port [+ + +]
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]>

ALSA: hda/realtek: Add quirks for Lenovo Thinkbook 16P laptops [+ + +]
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]>

ALSA: hda/realtek: cs35l41: Add internal speaker support for ASUS UM3402 with missing DSD [+ + +]
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]>

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

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

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

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

ALSA: hda/tas2781: add ptrs to calibration functions [+ + +]
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]>

ALSA: hda/tas2781: configure the amp after firmware load [+ + +]
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]>

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

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

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

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

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

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

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

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

ALSA: hda: cs35l41: Overwrite CS35L41 configuration for ASUS UM5302LA [+ + +]
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]>

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

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

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

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

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

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

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

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

 
arm64/sve: Lower the maximum allocation for the SVE ptrace regset [+ + +]
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]>

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

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

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

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

arm64: dts: Fix dtc interrupt_provider warnings [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

arm64: dts: qcom: Fix interrupt-map cell sizes [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

arm64: dts: qcom: sm8150: use 'gpios' suffix for PCI GPIOs [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

arm64: dts: rockchip: mark system power controller on rk3588-evb1 [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

arm64: dts: ti: k3-am64: Enable SDHCI nodes at the board level [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

arm64: tegra: Set the correct PHY mode for MGBE [+ + +]
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]>

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

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

 
arm: dts: Fix dtc interrupt_map warnings [+ + +]
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]>

arm: dts: Fix dtc interrupt_provider warnings [+ + +]
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]>

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

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

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

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

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

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

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

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

ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodes [+ + +]
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]>

ARM: dts: rockchip: Drop interrupts property from pwm-rockchip nodes [+ + +]
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]>

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

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

ASoC: amd: yc: Add HP Pavilion Aero Laptop 13-be2xxx(8BD6) into DMI quirk table [+ + +]
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]>

ASoC: amd: yc: Add Lenovo ThinkBook 21J0 into DMI quirk table [+ + +]
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]>

ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2 [+ + +]
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]>

ASoC: amd: yc: Fix non-functional mic on Lenovo 82UU [+ + +]
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]>

ASoC: cs42l43: Handle error from devm_pm_runtime_enable [+ + +]
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]>

ASoC: Intel: bytcr_rt5640: Add an extra entry for the Chuwi Vi8 tablet [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

ASoC: rt5645: Make LattePanda board DMI match more precise [+ + +]
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]>

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

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

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

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

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

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

ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend [+ + +]
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]>

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

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

ASoC: wm8962: Enable both SPKOUTR_ENA and SPKOUTL_ENA in mono mode [+ + +]
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]>

ASoC: wm8962: Enable oscillator if selecting WM8962_FLL_OSC [+ + +]
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]>

ASoC: wm8962: Fix up incorrect error message in wm8962_set_fll [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

 
bcachefs: check for failure to downgrade [+ + +]
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]>

bcachefs: Fix BTREE_ITER_FILTER_SNAPSHOTS on inodes btree [+ + +]
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]>

bcachefs: Fix build on parisc by avoiding __multi3() [+ + +]
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]>

bcachefs: fix simulateously upgrading & downgrading [+ + +]
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]>

bcachefs: install fd later to avoid race with close [+ + +]
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]>

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

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

block: sed-opal: handle empty atoms when parsing response [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bluetooth: mgmt: Fix limited discoverable off timeout [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security [+ + +]
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]>

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

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

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

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

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

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

bpf: Fix warning for bpf_cpumask in verifier [+ + +]
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]>

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

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

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

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

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

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

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

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

 
btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve [+ + +]
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]>

btrfs: fix data races when accessing the reserved amount of block reserves [+ + +]
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]>

btrfs: zoned: don't skip block group profile checks on conventional zones [+ + +]
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]>

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

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

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

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

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

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

 
ceph: add ceph_cap_unlink_work to fire check_caps() immediately [+ + +]
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]>

ceph: always queue a writeback when revoking the Fb caps [+ + +]
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]>

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

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

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

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

 
cifs: Don't use certain unnecessary folio_*() functions [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
comedi: comedi_8255: Correct error in subdevice initialization [+ + +]
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]>

comedi: comedi_test: Prevent timers rescheduling during deletion [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

crypto: qat - relocate and rename get_service_enabled() [+ + +]
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]>

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

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

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

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

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

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

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

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

 
cxl/region: Allow out of order assembly of autodiscovered regions [+ + +]
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]>

cxl/region: Handle endpoint decoders in cxl_region_find_decoder() [+ + +]
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]>

 
devlink: Acquire device lock during netns dismantle [+ + +]
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]>

devlink: Allow taking device lock in pre_doit operations [+ + +]
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]>

devlink: Enable the use of private flags in post_doit operations [+ + +]
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]>

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

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

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

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

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

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

devlink: Move private netlink flags to C file [+ + +]
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]>

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

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

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

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

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

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

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

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

 
dm-verity, dm-crypt: align "struct bvec_iter" correctly [+ + +]
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]>

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

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

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

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

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

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

 
dpll: fix dpll_xa_ref_*_del() for multiple registrations [+ + +]
Author: Jiri Pirko <[email protected]>
Date:   Wed Mar 6 16:12:40 2024 +0100

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

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

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

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

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

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

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

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

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

drm/amd/display: fix input states translation error for dcn35 & dcn351 [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

drm/amdgpu: Enable gpu reset for S3 abort cases on Raven series [+ + +]
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]>

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

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

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

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

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

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

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

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

 
drm/buddy: check range allocation matches alignment [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

drm/msm/dpu: use devres-managed allocation for HW blocks [+ + +]
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]>

drm/msm/dpu: use devres-managed allocation for MDP TOP [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
drm/ttm/tests: depend on UML || COMPILE_TEST [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
erofs: fix handling kern_mount() failure [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f2fs: delete obsolete FI_DROP_CACHE [+ + +]
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]>

f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

f2fs: introduce f2fs_invalidate_internal_cache() for cleanup [+ + +]
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]>

f2fs: introduce get_dnode_addr() to clean up codes [+ + +]
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]>

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

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

f2fs: update blkaddr in __set_data_blkaddr() for cleanup [+ + +]
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]>

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

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

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

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

 
firewire: core: use long bus reset on gap count error [+ + +]
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]>

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

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

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

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

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

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

 
gen_compile_commands: fix invalid escape sequence warning [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

HID: logitech-hidpp: Do not flood kernel log [+ + +]
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]>

HID: multitouch: Add required quirk for Synaptics 0xcddc device [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Input: gpio_keys_polled - suppress deferred probe error for gpio [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

 
io_uring/unix: drop usage of io_uring socket [+ + +]
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]>

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

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

io_uring: drop any code related to SCM_RIGHTS [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Linux: Linux 6.7.11 [+ + +]
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]>

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

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

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

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

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

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

md/raid1: remove rcu protection to access rdev from conf [+ + +]
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]>

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

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

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

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

md: remove flag RemoveSynchronized [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

media: rkisp1: Fix IRQ handling due to shared interrupts [+ + +]
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]>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
mei: gsc_proxy: match component when GSC is on different bus [+ + +]
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]>

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

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

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

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

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

    mfd: cs42l43: Fix wrong GPIO_FN_SEL and SPI_CLK_CONFIG1 defaults
    
    [ Upstream commit 78334c343bef528b911da83a6b041d15a1a72efb ]
    
    Two regs have wrong values in existing fields, change them to match
    the datasheet.
    
    Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
    
    Signed-off-by: Maciej Strozek <[email protected]>
    Reviewed-by: Charles Keepax <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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

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

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

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

 
MIPS: Clear Cause.BD in instruction_pointer_set [+ + +]
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]>

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

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

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

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

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

    mtd: maps: physmap-core: fix flash size larger than 32-bit
    
    [ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ]
    
    mtd-ram can potentially be larger than 4GB. get_bitmask_order() uses
    fls() that is not guaranteed to work with values larger than 32-bit.
    Specifically on aarch64 fls() returns 0 when all 32 LSB bits are clear.
    Use fls64() instead.
    
    Fixes: ba32ce95cbd987 ("mtd: maps: Merge gpio-addr-flash.c into physmap-core.c")
    Signed-off-by: Baruch Siach <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: lpc32xx_mlc: fix irq handler prototype [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Feb 13 11:00:09 2024 +0100

    mtd: rawnand: lpc32xx_mlc: fix irq handler prototype
    
    [ Upstream commit 347b828882e6334690e7003ce5e2fe5f233dc508 ]
    
    clang-16 warns about mismatched function prototypes:
    
    drivers/mtd/nand/raw/lpc32xx_mlc.c:783:29: error: cast from 'irqreturn_t (*)(int, struct lpc32xx_nand_host *)' (aka 'enum irqreturn (*)(int, struct lpc32xx_nand_host *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Change the interrupt handler to the normal way of just passing
    a void* pointer and converting it inside the function..
    
    Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: spinand: esmt: Extend IDs to 5 bytes [+ + +]
Author: Ezra Buehler <[email protected]>
Date:   Thu Jan 25 22:01:08 2024 +0200

    mtd: spinand: esmt: Extend IDs to 5 bytes
    
    [ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ]
    
    According to the datasheets, the ESMT chips in question will return a 5
    byte long identification code where the last 3 bytes are the JEDEC
    continuation codes (7Fh). Although, I would have expected 4 continuation
    codes as Powerchip Semiconductor (C8h, corresponding to the parameter
    page data) is located in bank 5 of the JEDEC database.
    
    By matching the full 5 bytes we can avoid clashes with GigaDevice NAND
    flashes.
    
    This fix allows the MT7688-based GARDENA smart Gateway to boot again.
    
    Fixes: aa08bf187f32 ("mtd: spinand: esmt: add support for F50D2G41KA")
    Signed-off-by: Ezra Buehler <[email protected]>
    Reviewed-by: Martin Kurbanov <[email protected]>
    Tested-by: Martin Kurbanov <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
nbd: null check for nla_nest_start [+ + +]
Author: Navid Emamdoost <[email protected]>
Date:   Sat Feb 17 20:25:38 2024 -0800

    nbd: null check for nla_nest_start
    
    [ Upstream commit 31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d ]
    
    nla_nest_start() may fail and return NULL. Insert a check and set errno
    based on other call sites within the same source code.
    
    Signed-off-by: Navid Emamdoost <[email protected]>
    Reviewed-by: Michal Kubecek <[email protected]>
    Fixes: 47d902b90a32 ("nbd: add a status netlink command")
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/bnx2x: Prevent access to a freed page in page_pool [+ + +]
Author: Thinh Tran <[email protected]>
Date:   Fri Mar 15 15:55:35 2024 -0500

    net/bnx2x: Prevent access to a freed page in page_pool
    
    [ Upstream commit d27e2da94a42655861ca4baea30c8cd65546f25d ]
    
    Fix race condition leading to system crash during EEH error handling
    
    During EEH error recovery, the bnx2x driver's transmit timeout logic
    could cause a race condition when handling reset tasks. The
    bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
    which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
    SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
    overlap with the EEH driver's attempt to reset the device using
    bnx2x_io_slot_reset(), which also tries to free SGEs. This race
    condition can result in system crashes due to accessing freed memory
    locations in bnx2x_free_rx_sge()
    
    799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
    800                             struct bnx2x_fastpath *fp, u16 index)
    801  {
    802     struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
    803     struct page *page = sw_buf->page;
    ....
    where sw_buf was set to NULL after the call to dma_unmap_page()
    by the preceding thread.
    
        EEH: Beginning: 'slot_reset'
        PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
        bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
        bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
        bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
        Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
        BUG: Kernel NULL pointer dereference on read at 0x00000000
        Faulting instruction address: 0xc0080000025065fc
        Oops: Kernel access of bad area, sig: 11 [#1]
        .....
        Call Trace:
        [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
        [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
        [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
        [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
        [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
        [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
        [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
    
    To solve this issue, we need to verify page pool allocations before
    freeing.
    
    Fixes: 4cace675d687 ("bnx2x: Alloc 4k fragment for each rx ring buffer element")
    Signed-off-by: Thinh Tran <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/iucv: fix the allocation size of iucv_path_table array [+ + +]
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]>

 
net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Mar 11 20:46:28 2024 +0000

    net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
    
    [ Upstream commit 343041b59b7810f9cdca371f445dd43b35c740b1 ]
    
    taprio_parse_tc_entry() is not correctly checking
    TCA_TAPRIO_TC_ENTRY_INDEX attribute:
    
            int tc; // Signed value
    
            tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
            if (tc >= TC_QOPT_MAX_QUEUE) {
                    NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");
                    return -ERANGE;
            }
    
    syzbot reported that it could fed arbitary negative values:
    
    UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18
    shift exponent -2147418108 is negative
    CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
      ubsan_epilogue lib/ubsan.c:217 [inline]
      __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386
      taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline]
      taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline]
      taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877
      taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134
      qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355
      tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776
      rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617
      netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
      netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
      netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
      netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x221/0x270 net/socket.c:745
      ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
      ___sys_sendmsg net/socket.c:2638 [inline]
      __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
     do_syscall_64+0xf9/0x240
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f1b2dea3759
    Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759
    RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004
    RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000
    R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340
    R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340
    
    Fixes: a54fc09e4cba ("net/sched: taprio: allow user input of per-tc max SDU")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Vladimir Oltean <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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

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

 
net: blackhole_dev: fix build warning for ethh set but not used [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Fri Feb 2 07:13:29 2024 -0800

    net: blackhole_dev: fix build warning for ethh set but not used
    
    [ Upstream commit 843a8851e89e2e85db04caaf88d8554818319047 ]
    
    lib/test_blackhole_dev.c sets a variable that is never read, causing
    this following building warning:
    
            lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used [-Wunused-but-set-variable]
    
    Remove the variable struct ethhdr *ethh, which is unused.
    
    Fixes: 509e56b37cc3 ("blackhole_dev: add a selftest")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: microchip: make sure drive strength configuration is not lost by soft reset [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Mon Mar 4 14:56:12 2024 +0100

    net: dsa: microchip: make sure drive strength configuration is not lost by soft reset
    
    [ Upstream commit e3fb8e8ba72b053d05ca2602acdd6b869f9f296f ]
    
    This driver has two separate reset sequence in different places:
    - gpio/HW reset on start of ksz_switch_register()
    - SW reset on start of ksz_setup()
    
    The second one will overwrite drive strength configuration made in the
    ksz_switch_register().
    
    To fix it, move ksz_parse_drive_strength() from ksz_switch_register() to
    ksz_setup().
    
    Fixes: d67d7247f641 ("net: dsa: microchip: Add drive strength configuration")
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: fix handling of all link-local frames [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:33:42 2024 +0300

    net: dsa: mt7530: fix handling of all link-local frames
    
    [ Upstream commit 69ddba9d170bdaee1dc0eb4ced38d7e4bb7b92af ]
    
    Currently, the MT753X switches treat frames with :01-0D and :0F MAC DAs as
    regular multicast frames, therefore flooding them to user ports.
    
    On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE
    Std 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC
    DA must only be propagated to C-VLAN and MAC Bridge components. That means
    VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports,
    these frames are supposed to be processed by the CPU (software). So we make
    the switch only forward them to the CPU port. And if received from a CPU
    port, forward to a single port. The software is responsible of making the
    switch conform to the latter by setting a single port as destination port
    on the special tag.
    
    This switch intellectual property cannot conform to this part of the
    standard fully. Whilst the REV_UN frame tag covers the remaining :04-0D and
    :0F MAC DAs, it also includes :22-FF which the scope of propagation is not
    supposed to be restricted for these MAC DAs.
    
    Set frames with :01-03 MAC DAs to be trapped to the CPU port(s). Add a
    comment for the remaining MAC DAs.
    
    Note that the ingress port must have a PVID assigned to it for the switch
    to forward untagged frames. A PVID is set by default on VLAN-aware and
    VLAN-unaware ports. However, when the network interface that pertains to
    the ingress port is attached to a vlan_filtering enabled bridge, the user
    can remove the PVID assignment from it which would prevent the link-local
    frames from being trapped to the CPU port. I am yet to see a way to forward
    link-local frames while preventing other untagged frames from being
    forwarded too.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:33:41 2024 +0300

    net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
    
    [ Upstream commit e8bf353577f382c7066c661fed41b2adc0fc7c40 ]
    
    Whether VLAN-aware or not, on every VID VLAN table entry that has the CPU
    port as a member of it, frames are set to egress the CPU port with the VLAN
    tag stacked. This is so that VLAN tags can be appended after hardware
    special tag (called DSA tag in the context of Linux drivers).
    
    For user ports on a VLAN-unaware bridge, frame ingressing the user port
    egresses CPU port with only the special tag.
    
    For user ports on a VLAN-aware bridge, frame ingressing the user port
    egresses CPU port with the special tag and the VLAN tag.
    
    This causes issues with link-local frames, specifically BPDUs, because the
    software expects to receive them VLAN-untagged.
    
    There are two options to make link-local frames egress untagged. Setting
    CONSISTENT or UNTAGGED on the EG_TAG bits on the relevant register.
    CONSISTENT means frames egress exactly as they ingress. That means
    egressing with the VLAN tag they had at ingress or egressing untagged if
    they ingressed untagged. Although link-local frames are not supposed to be
    transmitted VLAN-tagged, if they are done so, when egressing through a CPU
    port, the special tag field will be broken.
    
    BPDU egresses CPU port with VLAN tag egressing stacked, received on
    software:
    
    00:01:25.104821 AF Unknown (382365846), length 106:
                                         | STAG  | | VLAN  |
            0x0000:  0000 6c27 614d 4143 0001 0000 8100 0001  ..l'aMAC........
            0x0010:  0026 4242 0300 0000 0000 0000 6c27 614d  .&BB........l'aM
            0x0020:  4143 0000 0000 0000 6c27 614d 4143 0000  AC......l'aMAC..
            0x0030:  0000 1400 0200 0f00 0000 0000 0000 0000  ................
    
    BPDU egresses CPU port with VLAN tag egressing untagged, received on
    software:
    
    00:23:56.628708 AF Unknown (25215488), length 64:
                                         | STAG  |
            0x0000:  0000 6c27 614d 4143 0001 0000 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    BPDU egresses CPU port with VLAN tag egressing tagged, received on
    software:
    
    00:01:34.311963 AF Unknown (25215488), length 64:
                                         | Mess  |
            0x0000:  0000 6c27 614d 4143 0001 0001 0026 4242  ..l'aMAC.....&BB
            0x0010:  0300 0000 0000 0000 6c27 614d 4143 0000  ........l'aMAC..
            0x0020:  0000 0000 6c27 614d 4143 0000 0000 1400  ....l'aMAC......
            0x0030:  0200 0f00 0000 0000 0000 0000            ............
    
    To prevent confusing the software, force the frame to egress UNTAGGED
    instead of CONSISTENT. This way, frames can't possibly be received TAGGED
    by software which would have the special tag field broken.
    
    VLAN Tag Egress Procedure
    
       For all frames, one of these options set the earliest in this order will
       apply to the frame:
    
       - EG_TAG in certain registers for certain frames.
         This will apply to frame with matching MAC DA or EtherType.
    
       - EG_TAG in the address table.
         This will apply to frame at its incoming port.
    
       - EG_TAG in the PVC register.
         This will apply to frame at its incoming port.
    
       - EG_CON and [EG_TAG per port] in the VLAN table.
         This will apply to frame at its outgoing port.
    
       - EG_TAG in the PCR register.
         This will apply to frame at its outgoing port.
    
       EG_TAG in certain registers for certain frames:
    
       PPPoE Discovery_ARP/RARP: PPP_EG_TAG and ARP_EG_TAG in the APC register.
       IGMP_MLD: IGMP_EG_TAG and MLD_EG_TAG in the IMC register.
       BPDU and PAE: BPDU_EG_TAG and PAE_EG_TAG in the BPC register.
       REV_01 and REV_02: R01_EG_TAG and R02_EG_TAG in the RGAC1 register.
       REV_03 and REV_0E: R03_EG_TAG and R0E_EG_TAG in the RGAC2 register.
       REV_10 and REV_20: R10_EG_TAG and R20_EG_TAG in the RGAC3 register.
       REV_21 and REV_UN: R21_EG_TAG and RUN_EG_TAG in the RGAC4 register.
    
    With this change, it can be observed that a bridge interface with stp_state
    and vlan_filtering enabled will properly block ports now.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: prevent possible incorrect XTAL frequency selection [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Thu Mar 14 12:28:35 2024 +0300

    net: dsa: mt7530: prevent possible incorrect XTAL frequency selection
    
    [ Upstream commit f490c492e946d8ffbe65ad4efc66de3c5ede30a4 ]
    
    On MT7530, the HT_XTAL_FSEL field of the HWTRAP register stores a 2-bit
    value that represents the frequency of the crystal oscillator connected to
    the switch IC. The field is populated by the state of the ESW_P4_LED_0 and
    ESW_P4_LED_0 pins, which is done right after reset is deasserted.
    
      ESW_P4_LED_0    ESW_P3_LED_0    Frequency
      -----------------------------------------
      0               0               Reserved
      0               1               20MHz
      1               0               40MHz
      1               1               25MHz
    
    On MT7531, the XTAL25 bit of the STRAP register stores this. The LAN0LED0
    pin is used to populate the bit. 25MHz when the pin is high, 40MHz when
    it's low.
    
    These pins are also used with LEDs, therefore, their state can be set to
    something other than the bootstrapping configuration. For example, a link
    may be established on port 3 before the DSA subdriver takes control of the
    switch which would set ESW_P3_LED_0 to high.
    
    Currently on mt7530_setup() and mt7531_setup(), 1000 - 1100 usec delay is
    described between reset assertion and deassertion. Some switch ICs in real
    life conditions cannot always have these pins set back to the bootstrapping
    configuration before reset deassertion in this amount of delay. This causes
    wrong crystal frequency to be selected which puts the switch in a
    nonfunctional state after reset deassertion.
    
    The tests below are conducted on an MT7530 with a 40MHz crystal oscillator
    by Justin Swartz.
    
    With a cable from an active peer connected to port 3 before reset, an
    incorrect crystal frequency (0b11 = 25MHz) is selected:
    
                          [1]                  [3]     [5]
                          :                    :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  _____________________________
    ESW_P3_LED_0                               |__________________________
    
                           :                  : :     :
                           :                  : [4]...:
                           :                  :
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 1000 - 1100 usec.
    [3] Reset is deasserted.
    [4] Period of 315 usec. HWTRAP register is populated with incorrect
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    Increase the delay between reset_control_assert() and
    reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and
    gpiod_set_value_cansleep(priv->reset, 1) to 5000 - 5100 usec. This amount
    ensures a higher possibility that the switch IC will have these pins back
    to the bootstrapping configuration before reset deassertion.
    
    With a cable from an active peer connected to port 3 before reset, the
    correct crystal frequency (0b10 = 40MHz) is selected:
    
                          [1]        [2-1]     [3]     [5]
                          :          :         :       :
                  _____________________________         __________________
    ESW_P4_LED_0                               |_______|
                  ___________________           _______
    ESW_P3_LED_0                     |_________|       |__________________
    
                           :          :       : :     :
                           :          [2-2]...: [4]...:
                           [2]................:
    
    [1] Reset is asserted.
    [2] Period of 5000 - 5100 usec.
    [2-1] ESW_P3_LED_0 goes low.
    [2-2] Remaining period of 5000 - 5100 usec.
    [3] Reset is deasserted.
    [4] Period of 310 usec. HWTRAP register is populated with bootstrapped
        XTAL frequency.
    [5] Signals reflect the bootstrapped configuration.
    
    ESW_P3_LED_0 low period before reset deassertion:
    
                  5000 usec
                - 5100 usec
        TEST     RESET HOLD
           #         (usec)
      ---------------------
           1           5410
           2           5440
           3           4375
           4           5490
           5           5475
           6           4335
           7           4370
           8           5435
           9           4205
          10           4335
          11           3750
          12           3170
          13           4395
          14           4375
          15           3515
          16           4335
          17           4220
          18           4175
          19           4175
          20           4350
    
         Min           3170
         Max           5490
    
      Median       4342.500
         Avg       4466.500
    
    Revert commit 2920dd92b980 ("net: dsa: mt7530: disable LEDs before reset").
    Changing the state of pins via reset assertion is simpler and more
    efficient than doing so by setting the LED controller off.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")
    Co-developed-by: Justin Swartz <[email protected]>
    Signed-off-by: Justin Swartz <[email protected]>
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Remove ena_select_queue [+ + +]
Author: Kamal Heib <[email protected]>
Date:   Thu Feb 15 17:31:04 2024 -0500

    net: ena: Remove ena_select_queue
    
    [ Upstream commit 78e886ba2b549945ecada055ee0765f0ded5707a ]
    
    Avoid the following warnings by removing the ena_select_queue() function
    and rely on the net core to do the queue selection, The issue happen
    when an skb received from an interface with more queues than ena is
    forwarded to the ena interface.
    
    [ 1176.159959] eth0 selects TX queue 11, but real number of TX queues is 8
    [ 1176.863976] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1180.767877] eth0 selects TX queue 14, but real number of TX queues is 8
    [ 1188.703742] eth0 selects TX queue 14, but real number of TX queues is 8
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Kamal Heib <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: mtk_eth_soc: fix PPE hanging issue [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:40 2024 +0000

    net: ethernet: mtk_eth_soc: fix PPE hanging issue
    
    [ Upstream commit ea80e3ed09ab2c2b75724faf5484721753e92c31 ]
    
    A patch to resolve an issue was found in MediaTek's GPL-licensed SDK:
    In the mtk_ppe_stop() function, the PPE scan mode is not disabled before
    disabling the PPE. This can potentially lead to a hang during the process
    of disabling the PPE.
    
    Without this patch, the PPE may experience a hang during the reboot test.
    
    Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b40da332dfe763932a82f9f62a4709457a15dd6c
    Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
    Suggested-by: Bc-bocun Chen <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix kernel crash when 1588 is received on HIP08 devices [+ + +]
Author: Yonglong Liu <[email protected]>
Date:   Thu Mar 7 09:01:11 2024 +0800

    net: hns3: fix kernel crash when 1588 is received on HIP08 devices
    
    [ Upstream commit 0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3 ]
    
    The HIP08 devices does not register the ptp devices, so the
    hdev->ptp is NULL, but the hardware can receive 1588 messages,
    and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
    access of hdev->ptp->flags will cause a kernel crash:
    
    [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
    ...
    [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
    [ 5889.279101] sp : ffff800012c3bc50
    [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
    [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
    [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
    [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
    [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
    [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
    [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
    [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
    [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
    [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
    [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
    [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
    [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
    [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
    [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
    [ 5889.378857] Call trace:
    [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
    [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
    [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
    [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
    [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
    [ 5889.411084] napi_poll+0xcc/0x264
    [ 5889.415329] net_rx_action+0xd4/0x21c
    [ 5889.419911] __do_softirq+0x130/0x358
    [ 5889.424484] irq_exit+0x134/0x154
    [ 5889.428700] __handle_domain_irq+0x88/0xf0
    [ 5889.433684] gic_handle_irq+0x78/0x2c0
    [ 5889.438319] el1_irq+0xb8/0x140
    [ 5889.442354] arch_cpu_idle+0x18/0x40
    [ 5889.446816] default_idle_call+0x5c/0x1c0
    [ 5889.451714] cpuidle_idle_call+0x174/0x1b0
    [ 5889.456692] do_idle+0xc8/0x160
    [ 5889.460717] cpu_startup_entry+0x30/0xfc
    [ 5889.465523] secondary_start_kernel+0x158/0x1ec
    [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
    [ 5889.477950] SMP: stopping secondary CPUs
    [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
    [ 5890.522951] Starting crashdump kernel...
    
    Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
    Signed-off-by: Yonglong Liu <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix port duplex configure error in IMP reset [+ + +]
Author: Jie Wang <[email protected]>
Date:   Thu Mar 7 09:01:14 2024 +0800

    net: hns3: fix port duplex configure error in IMP reset
    
    [ Upstream commit 11d80f79dd9f871a52feba4bf24b5ac39f448eb7 ]
    
    Currently, the mac port is fixed to configured as full dplex mode in
    hclge_mac_init() when driver initialization or reset restore. Users may
    change the mode to half duplex with ethtool,  so it may cause the user
    configuration dropped after reset.
    
    To fix it, don't change the duplex mode when resetting.
    
    Fixes: 2d03eacc0b7e ("net: hns3: Only update mac configuation when necessary")
    Signed-off-by: Jie Wang <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix wrong judgment condition issue [+ + +]
Author: Jijie Shao <[email protected]>
Date:   Thu Mar 7 09:01:08 2024 +0800

    net: hns3: fix wrong judgment condition issue
    
    [ Upstream commit 07a1d6dc90baedcf5d713e2b003b9e387130ee30 ]
    
    In hns3_dcbnl_ieee_delapp, should check ieee_delapp not ieee_setapp.
    This path fix the wrong judgment.
    
    Fixes: 0ba22bcb222d ("net: hns3: add support config dscp map to tc")
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 7 10:07:16 2024 +0000

    net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()
    
    [ Upstream commit b0ec2abf98267f14d032102551581c833b0659d3 ]
    
    Apply the same fix than ones found in :
    
    8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
    1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")
    
    We have to save skb->network_header in a temporary variable
    in order to be able to recompute the network_header pointer
    after a pskb_inet_may_pull() call.
    
    pskb_inet_may_pull() makes sure the needed headers are in skb->head.
    
    syzbot reported:
    BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
     BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
     BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
     BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
      INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
      IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
      ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
      __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
      ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
      gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
      gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
      ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
      ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
      dst_input include/net/dst.h:461 [inline]
      ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
      __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
      __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
      netif_receive_skb_internal net/core/dev.c:5734 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5793
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
      tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
      __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
      alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
      alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
      skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
      tun_build_skb drivers/net/tun.c:1686 [inline]
      tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
      call_write_iter include/linux/fs.h:2087 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb6b/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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

    net: kcm: fix incorrect parameter validation in the kcm_getsockopt) function
    
    [ Upstream commit 3ed5f415133f9b7518fbe55ba9ae9a3f5e700929 ]
    
    The 'len' variable can't be negative when assigned the result of
    'min_t' because all 'min_t' parameters are cast to unsigned int,
    and then the minimum one is chosen.
    
    To fix the logic, check 'len' as read from 'optlen',
    where the types of relevant variables are (signed) int.
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mctp: copy skb ext data when fragmenting [+ + +]
Author: Jeremy Kerr <[email protected]>
Date:   Mon Feb 19 17:51:54 2024 +0800

    net: mctp: copy skb ext data when fragmenting
    
    [ Upstream commit 1394c1dec1c619a46867ed32791a29695372bff8 ]
    
    If we're fragmenting on local output, the original packet may contain
    ext data for the MCTP flows. We'll want this in the resulting fragment
    skbs too.
    
    So, do a skb_ext_copy() in the fragmentation path, and implement the
    MCTP-specific parts of an ext copy operation.
    
    Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers")
    Reported-by: Jian Zhang <[email protected]>
    Signed-off-by: Jeremy Kerr <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mediatek: mtk_eth_soc: clear MAC_MCR_FORCE_LINK only when MAC is up [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Wed Mar 13 22:50:18 2024 +0000

    net: mediatek: mtk_eth_soc: clear MAC_MCR_FORCE_LINK only when MAC is up
    
    [ Upstream commit f1b85ef15a99f06ed48871ce933d591127d2dcc0 ]
    
    Clearing bit MAC_MCR_FORCE_LINK which forces the link down too early
    can result in MAC ending up in a broken/blocked state.
    
    Fix this by handling this bit in the .mac_link_up and .mac_link_down
    calls instead of in .mac_finish.
    
    Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support")
    Suggested-by: Mason-cw Chang <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: dp83822: Fix RGMII TX delay configuration [+ + +]
Author: Tim Pambor <[email protected]>
Date:   Tue Mar 5 12:06:08 2024 +0100

    net: phy: dp83822: Fix RGMII TX delay configuration
    
    [ Upstream commit c8a5c731fd1223090af57da33838c671a7fc6a78 ]
    
    The logic for enabling the TX clock shift is inverse of enabling the RX
    clock shift. The TX clock shift is disabled when DP83822_TX_CLK_SHIFT is
    set. Correct the current behavior and always write the delay configuration
    to ensure consistent delay settings regardless of bootloader configuration.
    
    Reference: https://www.ti.com/lit/ds/symlink/dp83822i.pdf p. 69
    
    Fixes: 8095295292b5 ("net: phy: DP83822: Add setting the fixed internal delay")
    Signed-off-by: Tim Pambor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: fix phy_get_internal_delay accessing an empty array [+ + +]
Author: Kévin L'hôpital <[email protected]>
Date:   Thu Mar 7 12:19:06 2024 +0100

    net: phy: fix phy_get_internal_delay accessing an empty array
    
    [ Upstream commit 4469c0c5b14a0919f5965c7ceac96b523eb57b79 ]
    
    The phy_get_internal_delay function could try to access to an empty
    array in the case that the driver is calling phy_get_internal_delay
    without defining delay_values and rx-internal-delay-ps or
    tx-internal-delay-ps is defined to 0 in the device-tree.
    This will lead to "unable to handle kernel NULL pointer dereference at
    virtual address 0". To avoid this kernel oops, the test should be delay
    >= 0. As there is already delay < 0 test just before, the test could
    only be size == 0.
    
    Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the internal delay")
    Co-developed-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Enguerrand de Ribaucourt <[email protected]>
    Signed-off-by: Kévin L'hôpital <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: fix phy_read_poll_timeout argument type in genphy_loopback [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Fri Mar 15 20:50:52 2024 +0300

    net: phy: fix phy_read_poll_timeout argument type in genphy_loopback
    
    [ Upstream commit 32fa4366cc4da1c97b725a0066adf43c6b298f37 ]
    
    read_poll_timeout inside phy_read_poll_timeout can set val negative
    in some cases (for example, __mdiobus_read inside phy_read can return
    -EOPNOTSUPP).
    
    Supposedly, commit 4ec732951702 ("net: phylib: fix phy_read*_poll_timeout()")
    should fix problems with wrong-signed vals, but I do not see how
    as val is sent to phy_read as is and __val = phy_read (not val)
    is checked for sign.
    
    Change val type for signed to allow better error handling as done in other
    phy_read_poll_timeout callers. This will not fix any error handling
    by itself, but allows, for example, to modify cond with appropriate
    sign check or check resulting val separately.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 014068dcb5b1 ("net: phy: genphy_loopback: add link speed configuration")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Reviewed-by: Russell King (Oracle) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: report RCU QS on threaded NAPI repolling [+ + +]
Author: Yan Zhai <[email protected]>
Date:   Tue Mar 19 13:44:37 2024 -0700

    net: report RCU QS on threaded NAPI repolling
    
    [ Upstream commit d6dbbb11247c71203785a2c9da474c36f4b19eae ]
    
    NAPI threads can keep polling packets under load. Currently it is only
    calling cond_resched() before repolling, but it is not sufficient to
    clear out the holdout of RCU tasks, which prevent BPF tracing programs
    from detaching for long period. This can be reproduced easily with
    following set up:
    
    ip netns add test1
    ip netns add test2
    
    ip -n test1 link add veth1 type veth peer name veth2 netns test2
    
    ip -n test1 link set veth1 up
    ip -n test1 link set lo up
    ip -n test2 link set veth2 up
    ip -n test2 link set lo up
    
    ip -n test1 addr add 192.168.1.2/31 dev veth1
    ip -n test1 addr add 1.1.1.1/32 dev lo
    ip -n test2 addr add 192.168.1.3/31 dev veth2
    ip -n test2 addr add 2.2.2.2/31 dev lo
    
    ip -n test1 route add default via 192.168.1.3
    ip -n test2 route add default via 192.168.1.2
    
    for i in `seq 10 210`; do
     for j in `seq 10 210`; do
        ip netns exec test2 iptables -I INPUT -s 3.3.$i.$j -p udp --dport 5201
     done
    done
    
    ip netns exec test2 ethtool -K veth2 gro on
    ip netns exec test2 bash -c 'echo 1 > /sys/class/net/veth2/threaded'
    ip netns exec test1 ethtool -K veth1 tso off
    
    Then run an iperf3 client/server and a bpftrace script can trigger it:
    
    ip netns exec test2 iperf3 -s -B 2.2.2.2 >/dev/null&
    ip netns exec test1 iperf3 -c 2.2.2.2 -B 1.1.1.1 -u -l 1500 -b 3g -t 100 >/dev/null&
    bpftrace -e 'kfunc:__napi_poll{@=count();} interval:s:1{exit();}'
    
    Report RCU quiescent states periodically will resolve the issue.
    
    Fixes: 29863d41bb6e ("net: implement threaded-able napi poll loop support")
    Reviewed-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Link: https://lore.kernel.org/r/4c3b0d3f32d3b18949d75b18e5e1d9f13a24f025.1710877680.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: smsc95xx: add support for SYS TEC USB-SPEmodule1 [+ + +]
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]>

net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Tue Oct 24 23:58:20 2023 +0200

    net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr()
    
    [ Upstream commit d6f4de70f73a106986ee315d7d512539f2f3303a ]
    
    The intent is to check if the strings' are truncated or not. So, >= should
    be used instead of >, because strlcat() and snprintf() return the length of
    the output, excluding the trailing NULL.
    
    Fixes: a02d69261134 ("SUNRPC: Provide functions for managing universal addresses")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: test: Fix printf format specifier in skb_segment kunit test [+ + +]
Author: David Gow <[email protected]>
Date:   Wed Feb 21 17:27:19 2024 +0800

    net: test: Fix printf format specifier in skb_segment kunit test
    
    [ Upstream commit ff3b96f2c9e5c24fca12239cd519a8a18569e687 ]
    
    KUNIT_FAIL() accepts a printf-style format string, but previously did
    not let gcc validate it with the __printf() attribute. The use of %lld
    for the result of PTR_ERR() is not correct.
    
    Instead, use %pe and pass the actual error pointer. printk() will format
    it correctly (and give a symbolic name rather than a number if
    available, which should make the output more readable, too).
    
    Fixes: b3098d32ed6e ("net: add skb_segment kunit test")
    Signed-off-by: David Gow <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: fix clk_name exceed MAX_DEV_ID limits [+ + +]
Author: Duanqiang Wen <[email protected]>
Date:   Wed Mar 13 16:06:34 2024 +0800

    net: txgbe: fix clk_name exceed MAX_DEV_ID limits
    
    [ Upstream commit e30cef001da259e8df354b813015d0e5acc08740 ]
    
    txgbe register clk which name is i2c_designware.pci_dev_id(),
    clk_name will be stored in clk_lookup_alloc. If PCIe bus number
    is larger than 0x39, clk_name size will be larger than 20 bytes.
    It exceeds clk_lookup_alloc MAX_DEV_ID limits. So the driver
    shortened clk_name.
    
    Fixes: b63f20485e43 ("net: txgbe: Register fixed rate clock")
    Signed-off-by: Duanqiang Wen <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: veth: do not manipulate GRO when using XDP [+ + +]
Author: Ignat Korchagin <[email protected]>
Date:   Wed Mar 13 19:37:58 2024 +0100

    net: veth: do not manipulate GRO when using XDP
    
    [ Upstream commit d7db7775ea2e31502d46427f5efd385afc4ff1eb ]
    
    Commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP") tried to fix
    the fact that GRO was not possible without XDP, because veth did not use NAPI
    without XDP. However, it also introduced the behaviour that GRO is always
    enabled, when XDP is enabled.
    
    While it might be desired for most cases, it is confusing for the user at best
    as the GRO flag suddenly changes, when an XDP program is attached. It also
    introduces some complexities in state management as was partially addressed in
    commit fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down").
    
    But the biggest problem is that it is not possible to disable GRO at all, when
    an XDP program is attached, which might be needed for some use cases.
    
    Fix this by not touching the GRO flag on XDP enable/disable as the code already
    supports switching to NAPI if either GRO or XDP is requested.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP")
    Fixes: fe9f801355f0 ("net: veth: clear GRO when clearing XDP even when down")
    Signed-off-by: Ignat Korchagin <[email protected]>
    Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nf_tables: do not compare internal table flags on updates [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Mar 14 18:51:38 2024 +0100

    netfilter: nf_tables: do not compare internal table flags on updates
    
    [ Upstream commit 4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139 ]
    
    Restore skipping transaction if table update does not modify flags.
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: Fix a memory leak in nf_tables_updchain [+ + +]
Author: Quan Tian <[email protected]>
Date:   Thu Mar 7 01:24:02 2024 +0800

    netfilter: nf_tables: Fix a memory leak in nf_tables_updchain
    
    [ Upstream commit 7eaf837a4eb5f74561e2486972e7f5184b613f6e ]
    
    If nft_netdev_register_hooks() fails, the memory associated with
    nft_stats is not freed, causing a memory leak.
    
    This patch fixes it by moving nft_stats_alloc() down after
    nft_netdev_register_hooks() succeeds.
    
    Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain")
    Signed-off-by: Quan Tian <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_set_pipapo: release elements in clone only from destroy path [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Mar 10 10:02:41 2024 +0100

    netfilter: nft_set_pipapo: release elements in clone only from destroy path
    
    [ Upstream commit b0e256f3dd2ba6532f37c5c22e07cb07a36031ee ]
    
    Clone already always provides a current view of the lookup table, use it
    to destroy the set, otherwise it is possible to destroy elements twice.
    
    This fix requires:
    
     212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
    
    which came after:
    
     9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").
    
    Fixes: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfp: flower: handle acti_netdevs allocation failure [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Fri Mar 8 22:25:40 2024 +0800

    nfp: flower: handle acti_netdevs allocation failure
    
    [ Upstream commit 84e95149bd341705f0eca6a7fcb955c548805002 ]
    
    The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
    the physical memory has run out. As a result, if we dereference
    the acti_netdevs, the null pointer dereference bugs will happen.
    
    This patch adds a check to judge whether allocation failure occurs.
    If it happens, the delayed work will be rescheduled and try again.
    
    Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups")
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Louis Peens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Fix an off by one in root_nfs_cat() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Feb 18 22:16:53 2024 +0100

    NFS: Fix an off by one in root_nfs_cat()
    
    [ Upstream commit 698ad1a538da0b6bf969cfee630b4e3a026afb87 ]
    
    The intent is to check if 'dest' is truncated or not. So, >= should be
    used instead of >, because strlcat() returns the length of 'dest' and 'src'
    excluding the trailing NULL.
    
    Fixes: 56463e50d1fc ("NFS: Use super.c for NFSROOT mount option parsing")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt [+ + +]
Author: Dave Wysochanski <[email protected]>
Date:   Wed Jan 31 11:10:06 2024 -0500

    NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt
    
    [ Upstream commit fd5860ab6341506004219b080aea40213b299d2e ]
    
    The loop inside nfs_netfs_issue_read() currently does not disable
    interrupts while iterating through pages in the xarray to submit
    for NFS read.  This is not safe though since after taking xa_lock,
    another page in the mapping could be processed for writeback inside
    an interrupt, and deadlock can occur.  The fix is simple and clean
    if we use xa_for_each_range(), which handles the iteration with RCU
    while reducing code complexity.
    
    The problem is easily reproduced with the following test:
     mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs
     dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1
     echo 3 > /proc/sys/vm/drop_caches
     dd if=/mnt/nfs/file1.bin of=/dev/null
     umount /mnt/nfs
    
    On the console with a lockdep-enabled kernel a message similar to
    the following will be seen:
    
     ================================
     WARNING: inconsistent lock state
     6.7.0-lockdbg+ #10 Not tainted
     --------------------------------
     inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
     test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:
     ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at:
    nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
     {IN-SOFTIRQ-W} state was registered at:
       lock_acquire+0x144/0x380
       _raw_spin_lock_irqsave+0x4e/0xa0
       __folio_end_writeback+0x17e/0x5c0
       folio_end_writeback+0x93/0x1b0
       iomap_finish_ioend+0xeb/0x6a0
       blk_update_request+0x204/0x7f0
       blk_mq_end_request+0x30/0x1c0
       blk_complete_reqs+0x7e/0xa0
       __do_softirq+0x113/0x544
       __irq_exit_rcu+0xfe/0x120
       irq_exit_rcu+0xe/0x20
       sysvec_call_function_single+0x6f/0x90
       asm_sysvec_call_function_single+0x1a/0x20
       pv_native_safe_halt+0xf/0x20
       default_idle+0x9/0x20
       default_idle_call+0x67/0xa0
       do_idle+0x2b5/0x300
       cpu_startup_entry+0x34/0x40
       start_secondary+0x19d/0x1c0
       secondary_startup_64_no_verify+0x18f/0x19b
     irq event stamp: 176891
     hardirqs last  enabled at (176891): [<ffffffffa67a0be4>]
    _raw_spin_unlock_irqrestore+0x44/0x60
     hardirqs last disabled at (176890): [<ffffffffa67a0899>]
    _raw_spin_lock_irqsave+0x79/0xa0
     softirqs last  enabled at (176646): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
     softirqs last disabled at (176633): [<ffffffffa515d91e>]
    __irq_exit_rcu+0xfe/0x120
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&xa->xa_lock#4);
       <Interrupt>
         lock(&xa->xa_lock#4);
    
      *** DEADLOCK ***
    
     2 locks held by test5/1708:
      #0: ffff888127baa498 (&sb->s_type->i_mutex_key#22){++++}-{4:4}, at:
          nfs_start_io_read+0x28/0x90 [nfs]
      #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:
          page_cache_ra_unbounded+0xa4/0x280
    
     stack backtrace:
     CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
    04/01/2014
     Call Trace:
      dump_stack_lvl+0x5b/0x90
      mark_lock+0xb3f/0xd20
      __lock_acquire+0x77b/0x3360
      _raw_spin_lock+0x34/0x80
      nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
      netfs_begin_read+0x77f/0x980 [netfs]
      nfs_netfs_readahead+0x45/0x60 [nfs]
      nfs_readahead+0x323/0x5a0 [nfs]
      read_pages+0xf3/0x5c0
      page_cache_ra_unbounded+0x1c8/0x280
      filemap_get_pages+0x38c/0xae0
      filemap_read+0x206/0x5e0
      nfs_file_read+0xb7/0x140 [nfs]
      vfs_read+0x2a9/0x460
      ksys_read+0xb7/0x140
    
    Fixes: 000dbe0bec05 ("NFS: Convert buffered read paths to use netfs when fscache is enabled")
    Suggested-by: Jeff Layton <[email protected]>
    Signed-off-by: Dave Wysochanski <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: David Howells <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: fix panic when nfs4_ff_layout_prepare_ds() fails [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Mon Mar 11 11:11:53 2024 -0400

    nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
    
    [ Upstream commit 719fcafe07c12646691bd62d7f8d94d657fa0766 ]
    
    We've been seeing the following panic in production
    
    BUG: kernel NULL pointer dereference, address: 0000000000000065
    PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0
    RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
    Call Trace:
     <TASK>
     ? __die+0x78/0xc0
     ? page_fault_oops+0x286/0x380
     ? __rpc_execute+0x2c3/0x470 [sunrpc]
     ? rpc_new_task+0x42/0x1c0 [sunrpc]
     ? exc_page_fault+0x5d/0x110
     ? asm_exc_page_fault+0x22/0x30
     ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
     ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]
     pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]
     pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]
     ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]
     nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]
     ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]
     __nfs_pageio_add_request+0x154/0x6c0 [nfs]
     nfs_pageio_add_request+0x26b/0x380 [nfs]
     nfs_do_writepage+0x111/0x1e0 [nfs]
     nfs_writepages_callback+0xf/0x30 [nfs]
     write_cache_pages+0x17f/0x380
     ? nfs_pageio_init_write+0x50/0x50 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     ? nfs_writepages+0x6d/0x210 [nfs]
     nfs_writepages+0x125/0x210 [nfs]
     do_writepages+0x67/0x220
     ? generic_perform_write+0x14b/0x210
     filemap_fdatawrite_wbc+0x5b/0x80
     file_write_and_wait_range+0x6d/0xc0
     nfs_file_fsync+0x81/0x170 [nfs]
     ? nfs_file_mmap+0x60/0x60 [nfs]
     __x64_sys_fsync+0x53/0x90
     do_syscall_64+0x3d/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Inspecting the core with drgn I was able to pull this
    
      >>> prog.crashed_thread().stack_trace()[0]
      #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27
      >>> prog.crashed_thread().stack_trace()[0]['idx']
      (u32)1
      >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds
      (struct nfs4_ff_layout_ds *)0xffffffffffffffed
    
    This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()
    which could error out initializing the mirror_ds, and then we go to
    clean it all up and our check is only for if (!mirror->mirror_ds).  This
    is inconsistent with the rest of the users of mirror_ds, which have
    
      if (IS_ERR_OR_NULL(mirror_ds))
    
    to keep from tripping over this exact scenario.  Fix this up in
    ff_layout_cancel_io() to make sure we don't panic when we get an error.
    I also spot checked all the other instances of checking mirror_ds and we
    appear to be doing the correct checks everywhere, only unconditionally
    dereferencing mirror_ds when we know it would be valid.
    
    Signed-off-by: Josef Bacik <[email protected]>
    Fixes: b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked")
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1/pnfs: fix NFS with TLS in pnfs [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Tue Feb 20 18:25:34 2024 -0500

    NFSv4.1/pnfs: fix NFS with TLS in pnfs
    
    [ Upstream commit a35518cae4b325632840bc8c3aa9ad9bac430038 ]
    
    Currently, even though xprtsec=tls is specified and used for operations
    to MDS, any operations that go to DS travel over unencrypted connection.
    Or additionally, if more than 1 DS can serve the data, then trunked
    connections are also done unencrypted.
    
    IN GETDEVINCEINFO, we get an entry for the DS which carries a protocol
    type (which is TCP), then nfs4_set_ds_client() gets called with TCP
    instead of TCP with TLS.
    
    Currently, each trunked connection is created and uses clp->cl_hostname
    value which if TLS is used would get passed up in the handshake upcall,
    but instead we need to pass in the appropriate trunked address value.
    
    Fixes: c8407f2e560c ("NFS: Add an "xprtsec=" NFS mount option")
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.2: fix listxattr maximum XDR buffer size [+ + +]
Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:51:28 2024 -0700

    NFSv4.2: fix listxattr maximum XDR buffer size
    
    [ Upstream commit bcac8bff90a6ee1629f90669cdb9d28fb86049b0 ]
    
    Switch order of operations to avoid creating a short XDR buffer:
    e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20.
    
    Having a short XDR buffer leads to lxa_maxcount be a few bytes
    less than what is needed to retrieve the whole list when using
    a buflen as returned by a call with size = 0:
        buflen = listxattr(path, NULL, 0);
        buf = malloc(buflen);
        buflen = listxattr(path, buf, buflen);
    
    For a file with one attribute (name = '123456'), the first call
    with size = 0 will return buflen = 12 ('user.123456\x00').
    The second call with size = 12, sends LISTXATTRS with
    lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The
    XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count)
    + 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes
    shorter than the lxa_maxcount provided in the call.
    
    Fixes: 04a5da690e8f ("NFSv4.2: define limits and sizes for user xattr handling")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 [+ + +]
Author: Jorge Mora <[email protected]>
Date:   Thu Jan 25 07:56:12 2024 -0700

    NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
    
    [ Upstream commit 251a658bbfceafb4d58c76b77682c8bf7bcfad65 ]
    
    A call to listxattr() with a buffer size = 0 returns the actual
    size of the buffer needed for a subsequent call. When size > 0,
    nfs4_listxattr() does not return an error because either
    generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
    exactly all the bytes then size is 0 when calling
    nfs4_listxattr_nfs4_user() which then triggers the following
    kernel BUG:
    
      [   99.403778] kernel BUG at mm/usercopy.c:102!
      [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
      [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
      [   99.415827] Call trace:
      [   99.415985]  usercopy_abort+0x70/0xa0
      [   99.416227]  __check_heap_object+0x134/0x158
      [   99.416505]  check_heap_object+0x150/0x188
      [   99.416696]  __check_object_size.part.0+0x78/0x168
      [   99.416886]  __check_object_size+0x28/0x40
      [   99.417078]  listxattr+0x8c/0x120
      [   99.417252]  path_listxattr+0x78/0xe0
      [   99.417476]  __arm64_sys_listxattr+0x28/0x40
      [   99.417723]  invoke_syscall+0x78/0x100
      [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0
      [   99.418186]  do_el0_svc+0x24/0x38
      [   99.418376]  el0_svc+0x3c/0x110
      [   99.418554]  el0t_64_sync_handler+0x120/0x130
      [   99.418788]  el0t_64_sync+0x194/0x198
      [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
    
    Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
    thus calling lisxattr() with size = 16 will trigger the bug.
    
    Add check on nfs4_listxattr() to return ERANGE error when it is
    called with size > 0 and the return value is greater than size.
    
    Fixes: 012a211abd5d ("NFSv4.2: hook in the user extended attribute handlers")
    Signed-off-by: Jorge Mora <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nouveau/gsp: don't check devinit disable on GSP. [+ + +]
Author: Dave Airlie <[email protected]>
Date:   Thu Mar 14 11:45:21 2024 +1000

    nouveau/gsp: don't check devinit disable on GSP.
    
    [ Upstream commit 5d4e8ae6e57b025802aadf55a4775c55cceb75f1 ]
    
    GSP should be handling this and I can see no evidence in opengpu
    driver that this register should be touched.
    
    Fixed acceleration on 2080 Ti GPUs.
    
    Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
    
    Signed-off-by: Dave Airlie <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
nouveau: reset the bo resource bus info after an eviction [+ + +]
Author: Dave Airlie <[email protected]>
Date:   Mon Mar 11 17:20:37 2024 +1000

    nouveau: reset the bo resource bus info after an eviction
    
    [ Upstream commit f35c9af45ea7a4b1115b193d84858b14d13517fc ]
    
    Later attempts to refault the bo won't happen and the whole
    GPU does to lunch. I think Christian's refactoring of this
    code out to the driver broke this not very well tested path.
    
    Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver v5")
    Cc: Christian König <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
NTB: fix possible name leak in ntb_register_device() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Fri Dec 1 11:30:56 2023 +0800

    NTB: fix possible name leak in ntb_register_device()
    
    [ Upstream commit aebfdfe39b9327a3077d0df8db3beb3160c9bdd0 ]
    
    If device_register() fails in ntb_register_device(), the device name
    allocated by dev_set_name() should be freed. As per the comment in
    device_register(), callers should use put_device() to give up the
    reference in the error path. So fix this by calling put_device() in the
    error path so that the name can be freed in kobject_cleanup().
    
    As a result of this, put_device() in the error path of
    ntb_register_device() is removed and the actual error is returned.
    
    Fixes: a1bd3baeb2f1 ("NTB: Add NTB hardware abstraction layer")
    Signed-off-by: Yang Yingliang <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [mani: reworded commit message]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: fix reconnection fail due to reserved tag allocation [+ + +]
Author: Chunguang Xu <[email protected]>
Date:   Mon Mar 11 10:09:27 2024 +0800

    nvme: fix reconnection fail due to reserved tag allocation
    
    [ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]
    
    We found a issue on production environment while using NVMe over RDMA,
    admin_q reconnect failed forever while remote target and network is ok.
    After dig into it, we found it may caused by a ABBA deadlock due to tag
    allocation. In my case, the tag was hold by a keep alive request
    waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
    request maked as idle and will not process before reset success. As
    fabric_q shares tagset with admin_q, while reconnect remote target, we
    need a tag for connect command, but the only one reserved tag was held
    by keep alive command which waiting inside admin_q. As a result, we
    failed to reconnect admin_q forever. In order to fix this issue, I
    think we should keep two reserved tags for admin queue.
    
    Fixes: ed01fee283a0 ("nvme-fabrics: only reserve a single tag")
    Signed-off-by: Chunguang Xu <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Feb 26 23:35:27 2024 -0800

    objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks
    
    [ Upstream commit 10b4c4bce3f5541f54bcc2039720b11d2bc96d79 ]
    
    If SAVE and RESTORE unwind hints are in different basic blocks, and
    objtool sees the RESTORE before the SAVE, it errors out with:
    
      vmlinux.o: warning: objtool: vmw_port_hb_in+0x242: objtool isn't smart enough to handle this CFI save/restore combo
    
    In such a case, defer following the RESTORE block until the
    straight-line path gets followed later.
    
    Fixes: 8faea26e6111 ("objtool: Re-add UNWIND_HINT_{SAVE_RESTORE}")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/20240227073527.avcm5naavbv3cj5s@treble
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-af: Use matching wake_up API variant in CGX command interface [+ + +]
Author: Linu Cherian <[email protected]>
Date:   Tue Mar 12 12:36:22 2024 +0530

    octeontx2-af: Use matching wake_up API variant in CGX command interface
    
    [ Upstream commit e642921dfeed1e15e73f78f2c3b6746f72b6deb2 ]
    
    Use wake_up API instead of wake_up_interruptible, since
    wait_event_timeout API is used for waiting on command completion.
    
    Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management")
    Signed-off-by: Linu Cherian <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-af: Use separate handlers for interrupts [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:58 2024 +0530

    octeontx2-af: Use separate handlers for interrupts
    
    [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ]
    
    For PF to AF interrupt vector and VF to AF vector same
    interrupt handler is registered which is causing race condition.
    When two interrupts are raised to two CPUs at same time
    then two cores serve same event corrupting the data.
    
    Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: Send UP messages to VF only when VF is up. [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:57 2024 +0530

    octeontx2-pf: Send UP messages to VF only when VF is up.
    
    [ Upstream commit dfcf6355f53b1796cf7fd50a4f27b18ee6a3497a ]
    
    When PF sending link status messages to VF, it is possible
    that by the time link_event_task work function is executed
    VF might have brought down. Hence before sending VF link
    status message check whether VF is up to receive it.
    
    Fixes: ad513ed938c9 ("octeontx2-vf: Link event notification support")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: Use default max_active works instead of one [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:56 2024 +0530

    octeontx2-pf: Use default max_active works instead of one
    
    [ Upstream commit 7558ce0d974ced1dc07edc1197f750fe28c52e57 ]
    
    Only one execution context for the workqueue used for PF and
    VFs mailbox communication is incorrect since multiple works are
    queued simultaneously by all the VFs and PF link UP messages.
    Hence use default number of execution contexts by passing zero
    as max_active to alloc_workqueue function. With this fix in place,
    modify UP messages also to wait until completion.
    
    Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: Wait till detach_resources msg is complete [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:55 2024 +0530

    octeontx2-pf: Wait till detach_resources msg is complete
    
    [ Upstream commit cbf2f24939a5dafce6de4dd4422e543ce8f610cf ]
    
    During VF driver remove, a message is sent to detach VF
    resources to PF but VF is not waiting until message is
    complete. Also mailbox interrupts need to be turned off
    after the detach resource message is complete. This patch
    fixes that problem.
    
    Fixes: 05fcc9e08955 ("octeontx2-pf: Attach NIX and NPA block LFs")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2: Detect the mbox up or down message via register [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Mon Mar 18 14:59:54 2024 +0530

    octeontx2: Detect the mbox up or down message via register
    
    [ Upstream commit a88e0f936ba9a301c78f6eacfd38737d003c130b ]
    
    A single line of interrupt is used to receive up notifications
    and down reply messages from AF to PF (similarly from PF to its VF).
    PF acts as bridge and forwards VF messages to AF and sends respsones
    back from AF to VF. When an async event like link event is received
    by up message when PF is in middle of forwarding VF message then
    mailbox errors occur because PF state machine is corrupted.
    Since VF is a separate driver or VF driver can be in a VM it is
    not possible to serialize from the start of communication at VF.
    Hence to differentiate between type of messages at PF this patch makes
    sender to set mbox data register with distinct values for up and down
    messages. Sender also checks whether previous interrupt is received
    before triggering current interrupt by waiting for mailbox data register
    to become zero.
    
    Fixes: 5a6d7c9daef3 ("octeontx2-pf: Mailbox communication with AF")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
OPP: debugfs: Fix warning around icc_get_name() [+ + +]
Author: Viresh Kumar <[email protected]>
Date:   Mon Mar 4 16:48:28 2024 +0530

    OPP: debugfs: Fix warning around icc_get_name()
    
    [ Upstream commit 28330ceb953e39880ea77da4895bb902a1244860 ]
    
    If the kernel isn't built with interconnect support, icc_get_name()
    returns NULL and we get following warning:
    
    drivers/opp/debugfs.c: In function 'bw_name_read':
    drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-Werror=format-overflow=]
             i = scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path));
    
    Fix it.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 0430b1d5704b0 ("opp: Expose bandwidth information via debugfs")
    Signed-off-by: Viresh Kumar <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ovl: Always reject mounting over case-insensitive directories [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Feb 21 12:14:03 2024 -0500

    ovl: Always reject mounting over case-insensitive directories
    
    [ Upstream commit 2824083db76cb9d4b7910607b367e93b02912865 ]
    
    overlayfs relies on the filesystem setting DCACHE_OP_HASH or
    DCACHE_OP_COMPARE to reject mounting over case-insensitive directories.
    
    Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their
    d_ops"), we set ->d_op through a hook in ->d_lookup, which
    means the root dentry won't have them, causing the mount to accidentally
    succeed.
    
    In v6.7-rc7, the following sequence will succeed to mount, but any
    dentry other than the root dentry will be a "weird" dentry to ovl and
    fail with EREMOTE.
    
      mkfs.ext4 -O casefold lower.img
      mount -O loop lower.img lower
      mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl /mnt
    
    Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH
    and DCACHE_OP_COMPARE are properly set by ->lookup.
    
    Fix by explicitly rejecting superblocks that allow case-insensitive
    dentries. Yes, this will be solved when we move d_op configuration back
    to ->s_d_op. Yet, we better have an explicit fix to avoid messing up
    again.
    
    While there, re-sort the entries to have more descriptive error messages
    first.
    
    Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops")
    Acked-by: Amir Goldstein <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
packet: annotate data-races around ignore_outgoing [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Mar 14 14:18:16 2024 +0000

    packet: annotate data-races around ignore_outgoing
    
    [ Upstream commit 6ebfad33161afacb3e1e59ed1c2feefef70f9f97 ]
    
    ignore_outgoing is read locklessly from dev_queue_xmit_nit()
    and packet_getsockopt()
    
    Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
    
    syzbot reported:
    
    BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
    
    write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
     packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
     do_sock_setsockopt net/socket.c:2311 [inline]
     __sys_setsockopt+0x1d8/0x250 net/socket.c:2334
     __do_sys_setsockopt net/socket.c:2343 [inline]
     __se_sys_setsockopt net/socket.c:2340 [inline]
     __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
     dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
     xmit_one net/core/dev.c:3527 [inline]
     dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
     __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
     dev_queue_xmit include/linux/netdevice.h:3091 [inline]
     batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
     batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
     batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
     batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
     batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
     worker_thread+0x526/0x730 kernel/workqueue.c:3416
     kthread+0x1d1/0x210 kernel/kthread.c:388
     ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
    
    value changed: 0x00 -> 0x01
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
    
    Fixes: fa788d986a3a ("packet: add sockopt to ignore outgoing packets")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/CANn89i+Z7MfbkBLOv=p7KZ7=K1rKHO4P1OL5LYDCtBiyqsa9oQ@mail.gmail.com/T/#t
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Jason Xing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc/ftrace: add missing CONFIG_DYNAMIC_FTRACE check [+ + +]
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]>

 
PCI/DPC: Print all TLP Prefixes, not just the first [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Thu Jan 18 13:08:15 2024 +0200

    PCI/DPC: Print all TLP Prefixes, not just the first
    
    [ Upstream commit 6568d82512b0a64809acff3d7a747362fa4288c8 ]
    
    The TLP Prefix Log Register consists of multiple DWORDs (PCIe r6.1 sec
    7.9.14.13) but the loop in dpc_process_rp_pio_error() keeps reading from
    the first DWORD, so we print only the first PIO TLP Prefix (duplicated
    several times), and we never print the second, third, etc., Prefixes.
    
    Add the iteration count based offset calculation into the config read.
    
    Fixes: f20c4ea49ec4 ("PCI/DPC: Add eDPC support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    [bhelgaas: add user-visible details to commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/P2PDMA: Fix a sleeping issue in a RCU read section [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Jan 4 20:52:35 2024 +0100

    PCI/P2PDMA: Fix a sleeping issue in a RCU read section
    
    [ Upstream commit 1e5c66afd4a40bb7be17cb33cbb1a1085f727730 ]
    
    It is not allowed to sleep within a RCU read section, so use GFP_ATOMIC
    instead of GFP_KERNEL here.
    
    Link: https://lore.kernel.org/r/02d9ec4a10235def0e764ff1f5be881ba12e16e8.1704397858.git.christophe.jaillet@wanadoo.fr
    Fixes: ae21f835a5bd ("PCI/P2PDMA: Finish RCU conversion of pdev->p2pdma")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling [+ + +]
Author: Jonathan Bell <[email protected]>
Date:   Sat Feb 17 14:37:22 2024 +0100

    PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling
    
    [ Upstream commit 039741a8d7c9a01c1bc84a5ac5aa770a5e138a30 ]
    
    The MDIO_WT_DONE() macro tests bit 31, which is always 0 (== done) as
    readw_poll_timeout_atomic() does a 16-bit read. Replace with the readl
    variant.
    
    [kwilczynski: commit log]
    Fixes: ca5dcc76314d ("PCI: brcmstb: Replace status loops with read_poll_timeout_atomic()")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Jonathan Bell <[email protected]>
    Signed-off-by: Stefan Wahren <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Make pci_dev_is_disconnected() helper public for other drivers [+ + +]
Author: Ethan Zhao <[email protected]>
Date:   Tue Mar 5 20:21:14 2024 +0800

    PCI: Make pci_dev_is_disconnected() helper public for other drivers
    
    [ Upstream commit 39714fd73c6b60a8d27bcc5b431afb0828bf4434 ]
    
    Make pci_dev_is_disconnected() public so that it can be called from
    Intel VT-d driver to quickly fix/workaround the surprise removal
    unplug hang issue for those ATS capable devices on PCIe switch downstream
    hotplug capable ports.
    
    Beside pci_device_is_present() function, this one has no config space
    space access, so is light enough to optimize the normal pure surprise
    removal and safe removal flow.
    
    Acked-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Tested-by: Haorong Ye <[email protected]>
    Signed-off-by: Ethan Zhao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected")
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Mark 3ware-9650SE Root Port Extended Tags as broken [+ + +]
Author: Jörg Wedekind <[email protected]>
Date:   Mon Feb 19 14:28:11 2024 +0100

    PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
    
    [ Upstream commit baf67aefbe7d7deafa59ca49612d163f8889934c ]
    
    Per PCIe r6.1, sec 2.2.6.2 and 7.5.3.4, a Requester may not use 8-bit Tags
    unless its Extended Tag Field Enable is set, but all Receivers/Completers
    must handle 8-bit Tags correctly regardless of their Extended Tag Field
    Enable.
    
    Some devices do not handle 8-bit Tags as Completers, so add a quirk for
    them.  If we find such a device, we disable Extended Tags for the entire
    hierarchy to make peer-to-peer DMA possible.
    
    The 3ware 9650SE seems to have issues with handling 8-bit tags. Mark it as
    broken.
    
    This fixes PCI Parity Errors like :
    
      3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing.
      3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425
    Signed-off-by: Jörg Wedekind <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: switchtec: Fix an error handling path in switchtec_pci_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Dec 24 15:30:01 2023 +0100

    PCI: switchtec: Fix an error handling path in switchtec_pci_probe()
    
    [ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ]
    
    The commit in Fixes changed the logic on how resources are released and
    introduced a new switchtec_exit_pci() that need to be called explicitly in
    order to undo a corresponding switchtec_init_pci().
    
    This was done in the remove function, but not in the probe.
    
    Fix the probe now.
    
    Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove")
    Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf bpf: Clean up the generated/copied vmlinux.h [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Fri Feb 2 11:32:20 2024 -0300

    perf bpf: Clean up the generated/copied vmlinux.h
    
    [ Upstream commit ffd856537b95dd65facb4e0c78ca1cb92c2048ff ]
    
    When building perf with BPF skels we either copy the minimalistic
    tools/perf/util/bpf_skel/vmlinux/vmlinux.h or use bpftool to generate a
    vmlinux from BTF, storing the result in $(SKEL_OUT)/vmlinux.h.
    
    We need to remove that when doing a 'make -C tools/perf clean', fix it.
    
    Fixes: b7a2d774c9c5a9a3 ("perf build: Add ability to build with a generated vmlinux.h")
    Reviewed-by: Ian Rogers <[email protected]>
    Cc: Andrii Nakryiko <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Tiezhu Yang <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Cc: [email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/Zbz89KK5wHfZ82jv@x1
    Signed-off-by: Sasha Levin <[email protected]>

 
perf evsel: Fix duplicate initialization of data->id in evsel__parse_sample() [+ + +]
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]>

 
perf expr: Fix "has_event" function for metric style events [+ + +]
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]>

 
perf metric: Don't remove scale from counts [+ + +]
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]>

 
perf pmu: Fix a potential memory leak in perf_pmu__lookup() [+ + +]
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]>

perf pmu: Treat the msr pmu as software [+ + +]
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]>

 
perf print-events: make is_event_supported() more robust [+ + +]
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_HAR