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

 
ALSA: hda/realtek: Add supported ALC257 for ChromeOS [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Wed Nov 29 15:38:40 2023 +0800

    ALSA: hda/realtek: Add supported ALC257 for ChromeOS
    
    commit cae2bdb579ecc9d4219c58a7d3fde1958118dc1d upstream.
    
    ChromeOS want to support ALC257.
    Add codec ID to some relation function.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Headset Mic VREF to 100% [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Wed Oct 25 15:24:06 2023 +0800

    ALSA: hda/realtek: Headset Mic VREF to 100%
    
    commit baaacbff64d9f34b64f294431966d035aeadb81c upstream.
    
    This platform need to set Mic VREF to 100%.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Disable power-save on KONTRON SinglePC [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Thu Nov 30 16:13:21 2023 +0100

    ALSA: hda: Disable power-save on KONTRON SinglePC
    
    commit a337c355719c42a6c5b67e985ad753590ed844fb upstream.
    
    It's been reported that the runtime PM on KONTRON SinglePC (PCI SSID
    1734:1232) caused a stall of playback after a bunch of invocations.
    (FWIW, this looks like an timing issue, and the stall happens rather
    on the controller side.)
    
    As a workaround, disable the default power-save on this platform.
    
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
auxdisplay: hd44780: move cursor home after clear display command [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Sat Jul 22 14:09:25 2023 -0400

    auxdisplay: hd44780: move cursor home after clear display command
    
    commit 35b464e32c8bccef435e415db955787ead4ab44c upstream.
    
    The DISPLAY_CLEAR command on the NewHaven NHD-0220DZW-AG5 display
    does NOT change the DDRAM address to 00h (home position) like the
    standard Hitachi HD44780 controller. As a consequence, the starting
    position of the initial string LCD_INIT_TEXT is not guaranteed to be
    at 0,0 depending on where the cursor was before the DISPLAY_CLEAR
    command.
    
    Extract of DISPLAY_CLEAR command from datasheets of:
    
        Hitachi HD44780:
            ... It then sets DDRAM address 0 into the address counter...
    
        NewHaven NHD-0220DZW-AG5 datasheet:
            ... This instruction does not change the DDRAM Address
    
    Move the cursor home after sending DISPLAY_CLEAR command to support
    non-standard LCDs.
    
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Tested-by: David Reaver <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bcache: revert replacing IS_ERR_OR_NULL with IS_ERR [+ + +]
Author: Markus Weippert <[email protected]>
Date:   Fri Nov 24 16:14:37 2023 +0100

    bcache: revert replacing IS_ERR_OR_NULL with IS_ERR
    
    commit bb6cc253861bd5a7cf8439e2118659696df9619f upstream.
    
    Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in
    node allocations") replaced IS_ERR_OR_NULL by IS_ERR. This leads to a
    NULL pointer dereference.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000080
    Call Trace:
     ? __die_body.cold+0x1a/0x1f
     ? page_fault_oops+0xd2/0x2b0
     ? exc_page_fault+0x70/0x170
     ? asm_exc_page_fault+0x22/0x30
     ? btree_node_free+0xf/0x160 [bcache]
     ? up_write+0x32/0x60
     btree_gc_coalesce+0x2aa/0x890 [bcache]
     ? bch_extent_bad+0x70/0x170 [bcache]
     btree_gc_recurse+0x130/0x390 [bcache]
     ? btree_gc_mark_node+0x72/0x230 [bcache]
     bch_btree_gc+0x5da/0x600 [bcache]
     ? cpuusage_read+0x10/0x10
     ? bch_btree_gc+0x600/0x600 [bcache]
     bch_gc_thread+0x135/0x180 [bcache]
    
    The relevant code starts with:
    
        new_nodes[0] = NULL;
    
        for (i = 0; i < nodes; i++) {
            if (__bch_keylist_realloc(&keylist, bkey_u64s(&r[i].b->key)))
                goto out_nocoalesce;
        // ...
    out_nocoalesce:
        // ...
        for (i = 0; i < nodes; i++)
            if (!IS_ERR(new_nodes[i])) {  // IS_ERR_OR_NULL before
    028ddcac477b
                btree_node_free(new_nodes[i]);  // new_nodes[0] is NULL
                rw_unlock(true, new_nodes[i]);
            }
    
    This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
    
    Fixes: 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations")
    Link: https://lore.kernel.org/all/[email protected]/
    Cc: [email protected]
    Cc: Zheng Wang <[email protected]>
    Cc: Coly Li <[email protected]>
    Signed-off-by: Markus Weippert <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
btrfs: add dmesg output for first mount and last unmount of a filesystem [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Thu Nov 2 07:54:50 2023 +1030

    btrfs: add dmesg output for first mount and last unmount of a filesystem
    
    commit 2db313205f8b96eea467691917138d646bb50aef upstream.
    
    There is a feature request to add dmesg output when unmounting a btrfs.
    There are several alternative methods to do the same thing, but with
    their own problems:
    
    - Use eBPF to watch btrfs_put_super()/open_ctree()
      Not end user friendly, they have to dip their head into the source
      code.
    
    - Watch for directory /sys/fs/<uuid>/
      This is way more simple, but still requires some simple device -> uuid
      lookups.  And a script needs to use inotify to watch /sys/fs/.
    
    Compared to all these, directly outputting the information into dmesg
    would be the most simple one, with both device and UUID included.
    
    And since we're here, also add the output when mounting a filesystem for
    the first time for parity. A more fine grained monitoring of subvolume
    mounts should be done by another layer, like audit.
    
    Now mounting a btrfs with all default mkfs options would look like this:
    
      [81.906566] BTRFS info (device dm-8): first mount of filesystem 633b5c16-afe3-4b79-b195-138fe145e4f2
      [81.907494] BTRFS info (device dm-8): using crc32c (crc32c-intel) checksum algorithm
      [81.908258] BTRFS info (device dm-8): using free space tree
      [81.912644] BTRFS info (device dm-8): auto enabling async discard
      [81.913277] BTRFS info (device dm-8): checking UUID tree
      [91.668256] BTRFS info (device dm-8): last unmount of filesystem 633b5c16-afe3-4b79-b195-138fe145e4f2
    
    CC: [email protected] # 5.4+
    Link: https://github.com/kdave/btrfs-progs/issues/689
    Reviewed-by: Anand Jain <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    [ update changelog ]
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix 64bit compat send ioctl arguments not initializing version member [+ + +]
Author: David Sterba <[email protected]>
Date:   Tue Nov 14 17:44:11 2023 +0100

    btrfs: fix 64bit compat send ioctl arguments not initializing version member
    
    commit 5de0434bc064606d6b7467ec3e5ad22963a18c04 upstream.
    
    When the send protocol versioning was added in 5.16 e77fbf990316
    ("btrfs: send: prepare for v2 protocol"), the 32/64bit compat code was
    not updated (added by 2351f431f727 ("btrfs: fix send ioctl on 32bit with
    64bit kernel")), missing the version struct member. The compat code is
    probably rarely used, nobody reported any bugs.
    
    Found by tool https://github.com/jirislaby/clang-struct .
    
    Fixes: e77fbf990316 ("btrfs: send: prepare for v2 protocol")
    CC: [email protected] # 6.1+
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix off-by-one when checking chunk map includes logical address [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Nov 21 13:38:32 2023 +0000

    btrfs: fix off-by-one when checking chunk map includes logical address
    
    commit 5fba5a571858ce2d787fdaf55814e42725bfa895 upstream.
    
    At btrfs_get_chunk_map() we get the extent map for the chunk that contains
    the given logical address stored in the 'logical' argument. Then we do
    sanity checks to verify the extent map contains the logical address. One
    of these checks verifies if the extent map covers a range with an end
    offset behind the target logical address - however this check has an
    off-by-one error since it will consider an extent map whose start offset
    plus its length matches the target logical address as inclusive, while
    the fact is that the last byte it covers is behind the target logical
    address (by 1).
    
    So fix this condition by using '<=' rather than '<' when comparing the
    extent map's "start + length" against the target logical address.
    
    CC: [email protected] # 4.14+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: make error messages more clear when getting a chunk map [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Nov 21 13:38:33 2023 +0000

    btrfs: make error messages more clear when getting a chunk map
    
    commit 7d410d5efe04e42a6cd959bfe6d59d559fdf8b25 upstream.
    
    When getting a chunk map, at btrfs_get_chunk_map(), we do some sanity
    checks to verify we found a chunk map and that map found covers the
    logical address the caller passed in. However the messages aren't very
    clear in the sense that don't mention the issue is with a chunk map and
    one of them prints the 'length' argument as if it were the end offset of
    the requested range (while the in the string format we use %llu-%llu
    which suggests a range, and the second %llu-%llu is actually a range for
    the chunk map). So improve these two details in the error messages.
    
    CC: [email protected] # 5.4+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: ref-verify: fix memory leaks in btrfs_ref_tree_mod() [+ + +]
Author: Bragatheswaran Manickavel <[email protected]>
Date:   Sat Nov 18 14:40:12 2023 +0530

    btrfs: ref-verify: fix memory leaks in btrfs_ref_tree_mod()
    
    commit f91192cd68591c6b037da345bc9fcd5e50540358 upstream.
    
    In btrfs_ref_tree_mod(), when !parent 're' was allocated through
    kmalloc(). In the following code, if an error occurs, the execution will
    be redirected to 'out' or 'out_unlock' and the function will be exited.
    However, on some of the paths, 're' are not deallocated and may lead to
    memory leaks.
    
    For example: lookup_block_entry() for 'be' returns NULL, the out label
    will be invoked. During that flow ref and 'ra' are freed but not 're',
    which can potentially lead to a memory leak.
    
    CC: [email protected] # 5.10+
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=d66de4cbf532749df35f
    Signed-off-by: Bragatheswaran Manickavel <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: send: ensure send_fd is writable [+ + +]
Author: Jann Horn <[email protected]>
Date:   Fri Nov 24 17:48:31 2023 +0100

    btrfs: send: ensure send_fd is writable
    
    commit 0ac1d13a55eb37d398b63e6ff6db4a09a2c9128c upstream.
    
    kernel_write() requires the caller to ensure that the file is writable.
    Let's do that directly after looking up the ->send_fd.
    
    We don't need a separate bailout path because the "out" path already
    does fput() if ->send_filp is non-NULL.
    
    This has no security impact for two reasons:
    
     - the ioctl requires CAP_SYS_ADMIN
     - __kernel_write() bails out on read-only files - but only since 5.8,
       see commit a01ac27be472 ("fs: check FMODE_WRITE in __kernel_write")
    
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=12e098239d20385264d3
    Fixes: 31db9f7c23fb ("Btrfs: introduce BTRFS_IOC_SEND for btrfs send/receive")
    CC: [email protected] # 4.14+
    Signed-off-by: Jann Horn <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cifs: Fix FALLOC_FL_INSERT_RANGE by setting i_size after EOF moved [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Nov 29 16:56:18 2023 +0000

    cifs: Fix FALLOC_FL_INSERT_RANGE by setting i_size after EOF moved
    
    commit 88010155f02b2c3b03c71609ba6ceeb457ece095 upstream.
    
    Fix the cifs filesystem implementations of FALLOC_FL_INSERT_RANGE, in
    smb3_insert_range(), to set i_size after extending the file on the server
    and before we do the copy to open the gap (as we don't clean up the EOF
    marker if the copy fails).
    
    Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support")
    Cc: [email protected]
    Signed-off-by: David Howells <[email protected]>
    Acked-by: Paulo Alcantara <[email protected]>
    cc: Shyam Prasad N <[email protected]>
    cc: Rohith Surabattula <[email protected]>
    cc: Jeff Layton <[email protected]>
    cc: [email protected]
    cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: Fix FALLOC_FL_ZERO_RANGE by setting i_size if EOF moved [+ + +]
Author: David Howells <[email protected]>
Date:   Wed Nov 29 16:56:17 2023 +0000

    cifs: Fix FALLOC_FL_ZERO_RANGE by setting i_size if EOF moved
    
    commit 83d5518b124dfd605f10a68128482c839a239f9d upstream.
    
    Fix the cifs filesystem implementations of FALLOC_FL_ZERO_RANGE, in
    smb3_zero_range(), to set i_size after extending the file on the server.
    
    Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required")
    Cc: [email protected]
    Signed-off-by: David Howells <[email protected]>
    Acked-by: Paulo Alcantara <[email protected]>
    cc: Shyam Prasad N <[email protected]>
    cc: Rohith Surabattula <[email protected]>
    cc: Jeff Layton <[email protected]>
    cc: [email protected]
    cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
cpufreq/amd-pstate: Fix the return value of amd_pstate_fast_switch() [+ + +]
Author: Gautham R. Shenoy <[email protected]>
Date:   Mon Nov 27 16:41:21 2023 +0530

    cpufreq/amd-pstate: Fix the return value of amd_pstate_fast_switch()
    
    commit bb87be267b8ee9b40917fb5bf51be5ddb33c37c2 upstream.
    
    cpufreq_driver->fast_switch() callback expects a frequency as a return
    value. amd_pstate_fast_switch() was returning the return value of
    amd_pstate_update_freq(), which only indicates a success or failure.
    
    Fix this by making amd_pstate_fast_switch() return the target_freq
    when the call to amd_pstate_update_freq() is successful, and return
    the current frequency from policy->cur when the call to
    amd_pstate_update_freq() is unsuccessful.
    
    Fixes: 4badf2eb1e98 ("cpufreq: amd-pstate: Add ->fast_switch() callback")
    Acked-by: Huang Rui <[email protected]>
    Reviewed-by: Wyes Karny <[email protected]>
    Reviewed-by: Perry Yuan <[email protected]>
    Cc: 6.4+ <[email protected]> # v6.4+
    Signed-off-by: Gautham R. Shenoy <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cpufreq: imx6q: Don't disable 792 Mhz OPP unnecessarily [+ + +]
Author: Christoph Niedermaier <[email protected]>
Date:   Wed Nov 22 14:41:13 2023 +0100

    cpufreq: imx6q: Don't disable 792 Mhz OPP unnecessarily
    
    [ Upstream commit 2e4e0984c7d696cc74cf2fd7e7f62997f0e9ebe6 ]
    
    For a 900MHz i.MX6ULL CPU the 792MHz OPP is disabled. There is no
    convincing reason to disable this OPP. If a CPU can run at 900MHz,
    it should also be able to cope with 792MHz. Looking at the voltage
    level of 792MHz in [1] (page 24, table 10. "Operating Ranges") the
    current defined OPP is above the minimum. So the voltage level
    shouldn't be a problem. However in [2] (page 24, table 10.
    "Operating Ranges"), it is not mentioned that 792MHz OPP isn't
    allowed. Change it to only disable 792MHz OPP for i.MX6ULL types
    below 792 MHz.
    
    [1] https://www.nxp.com/docs/en/data-sheet/IMX6ULLIEC.pdf
    [2] https://www.nxp.com/docs/en/data-sheet/IMX6ULLCEC.pdf
    
    Fixes: 0aa9abd4c212 ("cpufreq: imx6q: check speed grades for i.MX6ULL")
    Signed-off-by: Christoph Niedermaier <[email protected]>
    Reviewed-by: Marek Vasut <[email protected]>
    Reviewed-by: Fabio Estevam <[email protected]>
    [ Viresh: Edited subject ]
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: imx6q: don't warn for disabling a non-existing frequency [+ + +]
Author: Christoph Niedermaier <[email protected]>
Date:   Fri May 12 17:07:11 2023 +0200

    cpufreq: imx6q: don't warn for disabling a non-existing frequency
    
    [ Upstream commit 11a3b0ac33d95aa84be426e801f800997262a225 ]
    
    It is confusing if a warning is given for disabling a non-existent
    frequency of the operating performance points (OPP). In this case
    the function dev_pm_opp_disable() returns -ENODEV. Check the return
    value and avoid the output of a warning in this case. Avoid code
    duplication by using a separate function.
    
    Signed-off-by: Christoph Niedermaier <[email protected]>
    [ Viresh : Updated commit subject ]
    Signed-off-by: Viresh Kumar <[email protected]>
    Stable-dep-of: 2e4e0984c7d6 ("cpufreq: imx6q: Don't disable 792 Mhz OPP unnecessarily")
    Signed-off-by: Sasha Levin <[email protected]>

 
dm verity: don't perform FEC for failed readahead IO [+ + +]
Author: Wu Bo <[email protected]>
Date:   Tue Nov 21 20:51:50 2023 -0700

    dm verity: don't perform FEC for failed readahead IO
    
    commit 0193e3966ceeeef69e235975918b287ab093082b upstream.
    
    We found an issue under Android OTA scenario that many BIOs have to do
    FEC where the data under dm-verity is 100% complete and no corruption.
    
    Android OTA has many dm-block layers, from upper to lower:
    dm-verity
    dm-snapshot
    dm-origin & dm-cow
    dm-linear
    ufs
    
    DM tables have to change 2 times during Android OTA merging process.
    When doing table change, the dm-snapshot will be suspended for a while.
    During this interval, many readahead IOs are submitted to dm_verity
    from filesystem. Then the kverity works are busy doing FEC process
    which cost too much time to finish dm-verity IO. This causes needless
    delay which feels like system is hung.
    
    After adding debugging it was found that each readahead IO needed
    around 10s to finish when this situation occurred. This is due to IO
    amplification:
    
    dm-snapshot suspend
    erofs_readahead     // 300+ io is submitted
            dm_submit_bio (dm_verity)
                    dm_submit_bio (dm_snapshot)
                    bio return EIO
                    bio got nothing, it's empty
            verity_end_io
            verity_verify_io
            forloop range(0, io->n_blocks)    // each io->nblocks ~= 20
                    verity_fec_decode
                    fec_decode_rsb
                    fec_read_bufs
                    forloop range(0, v->fec->rsn) // v->fec->rsn = 253
                            new_read
                            submit_bio (dm_snapshot)
                    end loop
            end loop
    dm-snapshot resume
    
    Readahead BIOs get nothing while dm-snapshot is suspended, so all of
    them will cause verity's FEC.
    Each readahead BIO needs to verify ~20 (io->nblocks) blocks.
    Each block needs to do FEC, and every block needs to do 253
    (v->fec->rsn) reads.
    So during the suspend interval(~200ms), 300 readahead BIOs trigger
    ~1518000 (300*20*253) IOs to dm-snapshot.
    
    As readahead IO is not required by userspace, and to fix this issue,
    it is best to pass readahead errors to upper layer to handle it.
    
    Cc: [email protected]
    Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
    Signed-off-by: Wu Bo <[email protected]>
    Reviewed-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dm verity: initialize fec io before freeing it [+ + +]
Author: Wu Bo <[email protected]>
Date:   Tue Nov 21 20:51:49 2023 -0700

    dm verity: initialize fec io before freeing it
    
    commit 7be05bdfb4efc1396f7692562c7161e2b9f595f1 upstream.
    
    If BIO error, verity_end_io() can call verity_finish_io() before
    verity_fec_init_io(). Therefore, fec_io->rs is not initialized and
    may crash when doing memory freeing in verity_fec_finish_io().
    
    Crash call stack:
     die+0x90/0x2b8
     __do_kernel_fault+0x260/0x298
     do_bad_area+0x2c/0xdc
     do_translation_fault+0x3c/0x54
     do_mem_abort+0x54/0x118
     el1_abort+0x38/0x5c
     el1h_64_sync_handler+0x50/0x90
     el1h_64_sync+0x64/0x6c
     free_rs+0x18/0xac
     fec_rs_free+0x10/0x24
     mempool_free+0x58/0x148
     verity_fec_finish_io+0x4c/0xb0
     verity_end_io+0xb8/0x150
    
    Cc: [email protected]      # v6.0+
    Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
    Signed-off-by: Wu Bo <[email protected]>
    Reviewed-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm-verity: align struct dm_verity_fec_io properly [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Tue Nov 28 14:50:23 2023 +0100

    dm-verity: align struct dm_verity_fec_io properly
    
    commit 38bc1ab135db87577695816b190e7d6d8ec75879 upstream.
    
    dm_verity_fec_io is placed after the end of two hash digests. If the hash
    digest has unaligned length, struct dm_verity_fec_io could be unaligned.
    
    This commit fixes the placement of struct dm_verity_fec_io, so that it's
    aligned.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Cc: [email protected]
    Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dma-buf: fix check in dma_resv_add_fence [+ + +]
Author: Christian König <[email protected]>
Date:   Tue Nov 14 13:37:09 2023 +0100

    dma-buf: fix check in dma_resv_add_fence
    
    commit 95ba893c9f4feb836ddce627efd0bb6af6667031 upstream.
    
    It's valid to add the same fence multiple times to a dma-resv object and
    we shouldn't need one extra slot for each.
    
    Signed-off-by: Christian König <[email protected]>
    Reviewed-by: Thomas Hellström <[email protected]>
    Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later")
    Cc: [email protected] # v5.19+
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dpaa2-eth: increase the needed headroom to account for alignment [+ + +]
Author: Ioana Ciornei <[email protected]>
Date:   Fri Nov 24 12:28:04 2023 +0200

    dpaa2-eth: increase the needed headroom to account for alignment
    
    [ Upstream commit f422abe3f23d483cf01f386819f26fb3fe0dbb2b ]
    
    Increase the needed headroom to account for a 64 byte alignment
    restriction which, with this patch, we make mandatory on the Tx path.
    The case in which the amount of headroom needed is not available is
    already handled by the driver which instead sends a S/G frame with the
    first buffer only holding the SW and HW annotation areas.
    
    Without this patch, we can empirically see data corruption happening
    between Tx and Tx confirmation which sometimes leads to the SW
    annotation area being overwritten.
    
    Since this is an old IP where the hardware team cannot help to
    understand the underlying behavior, we make the Tx alignment mandatory
    for all frames to avoid the crash on Tx conf. Also, remove the comment
    that suggested that this is just an optimization.
    
    This patch also sets the needed_headroom net device field to the usual
    value that the driver would need on the Tx path:
            - 64 bytes for the software annotation area
            - 64 bytes to account for a 64 byte aligned buffer address
    
    Fixes: 6e2387e8f19e ("staging: fsl-dpaa2/eth: Add Freescale DPAA2 Ethernet driver")
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Ioana Ciornei <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: clean code-style issues in dcn30_set_mpc_shaper_3dlut [+ + +]
Author: Melissa Wen <[email protected]>
Date:   Tue Feb 14 11:14:02 2023 -0100

    drm/amd/display: clean code-style issues in dcn30_set_mpc_shaper_3dlut
    
    [ Upstream commit 94369589e4ec13c762fe10a1fdc4463bdfee5d5f ]
    
    This function has many conditions and all code style issues (identation,
    missing braces, etc.) make reading it really annoying.
    
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Melissa Wen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 6f395cebdd89 ("drm/amd/display: Fix MPCC 1DLUT programming")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Expand kernel doc for DC [+ + +]
Author: Rodrigo Siqueira <[email protected]>
Date:   Thu Oct 20 11:46:57 2022 -0400

    drm/amd/display: Expand kernel doc for DC
    
    [ Upstream commit 1682bd1a6b5fb094e914d9b73b711821fd84dcbd ]
    
    This commit adds extra documentation for elements related to FAMs.
    
    Tested-by: Mark Broadworth <[email protected]>
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 67e38874b85b ("drm/amd/display: Increase num voltage states to 40")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: fix ABM disablement [+ + +]
Author: Hamza Mahfooz <[email protected]>
Date:   Wed Nov 22 14:50:34 2023 -0500

    drm/amd/display: fix ABM disablement
    
    commit b9f46f0b98784e40288ee393f863f553fde062fa upstream.
    
    On recent versions of DMUB firmware, if we want to completely disable
    ABM we have to pass ABM_LEVEL_IMMEDIATE_DISABLE as the requested ABM
    level to DMUB. Otherwise, LCD eDP displays are unable to reach their
    maximum brightness levels. So, to fix this whenever the user requests an
    ABM level of 0 pass ABM_LEVEL_IMMEDIATE_DISABLE to DMUB instead. Also,
    to keep the user's experience consistent map ABM_LEVEL_IMMEDIATE_DISABLE
    to 0 when a user tries to read the requested ABM level.
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Fix MPCC 1DLUT programming [+ + +]
Author: Ilya Bakoulin <[email protected]>
Date:   Tue Nov 7 15:07:56 2023 -0500

    drm/amd/display: Fix MPCC 1DLUT programming
    
    [ Upstream commit 6f395cebdd8927fbffdc3a55a14fcacf93634359 ]
    
    [Why]
    Wrong function is used to translate LUT values to HW format, leading to
    visible artifacting in some cases.
    
    [How]
    Use the correct cm3_helper function.
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Krunoslav Kovac <[email protected]>
    Acked-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Ilya Bakoulin <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix the delta clamping for shaper LUT [+ + +]
Author: Harry Wentland <[email protected]>
Date:   Thu Apr 6 18:06:27 2023 -0400

    drm/amd/display: Fix the delta clamping for shaper LUT
    
    [ Upstream commit 27fc10d1095f7a7de7c917638d7134033a190dd8 ]
    
    The shaper LUT requires a 10-bit value of the delta between segments. We
    were using dc_fixpt_clamp_u0d10() to do that but it doesn't do what we
    want it to do. It will preserve 10-bit precision after the decimal
    point, but that's not quite what we want. We want 14-bit precision and
    discard the 4 most-significant bytes.
    
    To do that we'll do dc_fixpt_clamp_u0d14() & 0x3ff instead.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Reviewed-by: Krunoslav Kovac <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 6f395cebdd89 ("drm/amd/display: Fix MPCC 1DLUT programming")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Guard against invalid RPTR/WPTR being set [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Wed Sep 13 16:18:44 2023 -0400

    drm/amd/display: Guard against invalid RPTR/WPTR being set
    
    [ Upstream commit 1ffa8602e39b89469dc703ebab7a7e44c33da0f7 ]
    
    [WHY]
    HW can return invalid values on register read, guard against these being
    set and causing us to access memory out of range and page fault.
    
    [HOW]
    Guard at sync_inbox1 and guard at pushing commands.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Hansen Dsouza <[email protected]>
    Acked-by: Alex Hung <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Include udelay when waiting for INBOX0 ACK [+ + +]
Author: Alvin Lee <[email protected]>
Date:   Mon Nov 6 11:20:15 2023 -0500

    drm/amd/display: Include udelay when waiting for INBOX0 ACK
    
    commit 3c9ea68cb61bd7e5bd312c06a12adada74ff5805 upstream.
    
    When waiting for the ACK for INBOX0 message,
    we have to ensure to include the udelay
    for proper wait time
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Samson Tam <[email protected]>
    Acked-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Alvin Lee <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Remove min_dst_y_next_start check for Z8 [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Wed Nov 8 10:55:53 2023 -0500

    drm/amd/display: Remove min_dst_y_next_start check for Z8
    
    commit 08448812acb2ab701cd5ff7e1a1dc97f7f10260c upstream.
    
    [Why]
    Flickering occurs on DRR supported panels when engaged in DRR due to
    min_dst_y_next becoming larger than the frame size itself.
    
    [How]
    In general, we should be able to enter Z8 when this is engaged but it
    might be a net power loss even if the calculation wasn't bugged.
    
    Don't support enabling Z8 during the DRR region.
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Syed Hassan <[email protected]>
    Acked-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Restore rptr/wptr for DMCUB as workaround [+ + +]
Author: JinZe.Xu <[email protected]>
Date:   Mon Apr 10 23:23:37 2023 +0800

    drm/amd/display: Restore rptr/wptr for DMCUB as workaround
    
    [ Upstream commit 8f3589bb6fcea397775398cba4fbcc46829a60ed ]
    
    [Why]
    States may be desync after resume.
    
    [How]
    Sync sw state with hw state.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: JinZe.Xu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 1ffa8602e39b ("drm/amd/display: Guard against invalid RPTR/WPTR being set")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Update min Z8 residency time to 2100 for DCN314 [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Wed Nov 8 10:59:00 2023 -0500

    drm/amd/display: Update min Z8 residency time to 2100 for DCN314
    
    commit 4636a211980052ca0df90265c8a3ed2d46099091 upstream.
    
    [Why]
    Some panels with residency period of 2054 exhibit flickering with
    Z8 at the end of the frame.
    
    [How]
    As a workaround, increase the limit to block these panels.
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Syed Hassan <[email protected]>
    Acked-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Use DRAM speed from validation for dummy p-state [+ + +]
Author: Alvin Lee <[email protected]>
Date:   Tue Nov 7 17:01:49 2023 -0500

    drm/amd/display: Use DRAM speed from validation for dummy p-state
    
    commit 9be601135ba8ac69880c01606c82140f2dde105e upstream.
    
    [Description]
    When choosing which dummy p-state latency to use, we
    need to use the DRAM speed from validation. The DRAMSpeed
    DML variable can change because we use different input
    params to DML when populating watermarks set B.
    
    Cc: [email protected] # 6.1+
    Reviewed-by: Samson Tam <[email protected]>
    Acked-by: Hamza Mahfooz <[email protected]>
    Signed-off-by: Alvin Lee <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/pm: fix a memleak in aldebaran_tables_init [+ + +]
Author: Dinghao Liu <[email protected]>
Date:   Thu Nov 23 15:33:22 2023 +0800

    drm/amd/pm: fix a memleak in aldebaran_tables_init
    
    [ Upstream commit 7a88f23e768491bae653b444a96091d2aaeb0818 ]
    
    When kzalloc() for smu_table->ecc_table fails, we should free
    the previously allocated resources to prevent memleak.
    
    Fixes: edd794208555 ("drm/amd/pm: add message smu to get ecc_table v2")
    Signed-off-by: Dinghao Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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

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

 
drm/amdgpu: Force order between a read and write to the same address [+ + +]
Author: Alex Sierra <[email protected]>
Date:   Mon Nov 20 11:31:32 2023 -0600

    drm/amdgpu: Force order between a read and write to the same address
    
    commit 4b27a33c3b173bef1d19ba89e0b9b812b4fddd25 upstream.
    
    Setting register to force ordering to prevent read/write or write/read
    hazards for un-cached modes.
    
    Signed-off-by: Alex Sierra <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fbdev: stifb: Make the STI next font pointer a 32-bit signed offset [+ + +]
Author: Helge Deller <[email protected]>
Date:   Fri Oct 27 13:36:48 2023 +0200

    fbdev: stifb: Make the STI next font pointer a 32-bit signed offset
    
    [ Upstream commit 8a32aa17c1cd48df1ddaa78e45abcb8c7a2220d6 ]
    
    The pointer to the next STI font is actually a signed 32-bit
    offset. With this change the 64-bit kernel will correctly subract
    the (signed 32-bit) offset instead of adding a (unsigned 32-bit)
    offset. It has no effect on 32-bit kernels.
    
    This fixes the stifb driver with a 64-bit kernel on qemu.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
firewire: core: fix possible memory leak in create_units() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Wed Nov 29 17:34:08 2023 +0800

    firewire: core: fix possible memory leak in create_units()
    
    commit 891e0eab32a57fca4d36c5162628eb0bcb1f0edf upstream.
    
    If device_register() fails, the refcount of device is not 0, the name
    allocated in dev_set_name() is leaked. To fix this by calling put_device(),
    so that it will be freed in callback function kobject_cleanup().
    
    unreferenced object 0xffff9d99035c7a90 (size 8):
      comm "systemd-udevd", pid 168, jiffies 4294672386 (age 152.089s)
      hex dump (first 8 bytes):
        66 77 30 2e 30 00 ff ff                          fw0.0...
      backtrace:
        [<00000000e1d62bac>] __kmem_cache_alloc_node+0x1e9/0x360
        [<00000000bbeaff31>] __kmalloc_node_track_caller+0x44/0x1a0
        [<00000000491f2fb4>] kvasprintf+0x67/0xd0
        [<000000005b960ddc>] kobject_set_name_vargs+0x1e/0x90
        [<00000000427ac591>] dev_set_name+0x4e/0x70
        [<000000003b4e447d>] create_units+0xc5/0x110
    
    fw_unit_release() will be called in the error path, move fw_device_get()
    before calling device_register() to keep balanced with fw_device_put() in
    fw_unit_release().
    
    Cc: [email protected]
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Fixes: a1f64819fe9f ("firewire: struct device - replace bus_id with dev_name(), dev_set_name()")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: xpad - add HyperX Clutch Gladiate Support [+ + +]
Author: Max Nguyen <[email protected]>
Date:   Sun Sep 17 22:21:53 2023 -0700

    Input: xpad - add HyperX Clutch Gladiate Support
    
    commit e28a0974d749e5105d77233c0a84d35c37da047e upstream.
    
    Add HyperX controller support to xpad_device and xpad_table.
    
    Suggested-by: Chris Toledanes <[email protected]>
    Reviewed-by: Carl Ng <[email protected]>
    Signed-off-by: Max Nguyen <[email protected]>
    Reviewed-by: Rahul Rameshbabu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iomap: update ki_pos a little later in iomap_dio_complete [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Thu Jun 1 16:58:54 2023 +0200

    iomap: update ki_pos a little later in iomap_dio_complete
    
    commit 936e114a245b6e38e0dbf706a67e7611fc993da1 upstream.
    
    Move the ki_pos update down a bit to prepare for a better common helper
    that invalidates pages based of an iocb.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Darrick J. Wong <[email protected]>
    Cc: Al Viro <[email protected]>
    Cc: Andreas Gruenbacher <[email protected]>
    Cc: Anna Schumaker <[email protected]>
    Cc: Chao Yu <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: Ilya Dryomov <[email protected]>
    Cc: Jaegeuk Kim <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Johannes Thumshirn <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Miklos Szeredi <[email protected]>
    Cc: Miklos Szeredi <[email protected]>
    Cc: Theodore Ts'o <[email protected]>
    Cc: Trond Myklebust <[email protected]>
    Cc: Xiubo Li <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Cc: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/20231205122122.dfhhoaswsfscuhc3@quack3
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu/vt-d: Add device_block_translation() helper [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Nov 22 08:29:44 2022 +0800

    iommu/vt-d: Add device_block_translation() helper
    
    [ Upstream commit c7be17c2903d4acbf9aa372bfb6e2a418387fce0 ]
    
    If domain attaching to device fails, the IOMMU driver should bring the
    device to blocking DMA state. The upper layer is expected to recover it
    by attaching a new domain. Use device_block_translation() in the error
    path of dev_attach to make the behavior specific.
    
    The difference between device_block_translation() and the previous
    dmar_remove_one_dev_info() is that, in the scalable mode, it is the
    RID2PASID entry instead of context entry being cleared. As a result,
    enabling PCI capabilities is moved up.
    
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: da37dddcf4ca ("iommu/vt-d: Disable PCI ATS in legacy passthrough mode")
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Add MTL to quirk list to skip TE disabling [+ + +]
Author: Abdul Halim, Mohd Syazwan <[email protected]>
Date:   Wed Nov 22 11:26:06 2023 +0800

    iommu/vt-d: Add MTL to quirk list to skip TE disabling
    
    commit 85b80fdffa867d75dfb9084a839e7949e29064e8 upstream.
    
    The VT-d spec requires (10.4.4 Global Command Register, TE field) that:
    
    Hardware implementations supporting DMA draining must drain any in-flight
    DMA read/write requests queued within the Root-Complex before switching
    address translation on or off and reflecting the status of the command
    through the TES field in the Global Status register.
    
    Unfortunately, some integrated graphic devices fail to do so after some
    kind of power state transition. As the result, the system might stuck in
    iommu_disable_translation(), waiting for the completion of TE transition.
    
    Add MTL to the quirk list for those devices and skips TE disabling if the
    qurik hits.
    
    Fixes: b1012ca8dc4f ("iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu")
    Cc: [email protected]
    Signed-off-by: Abdul Halim, Mohd Syazwan <[email protected]>
    Signed-off-by: Lu Baolu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iommu/vt-d: Allocate pasid table in device probe path [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Tue Nov 22 08:29:43 2022 +0800

    iommu/vt-d: Allocate pasid table in device probe path
    
    [ Upstream commit ec62b4424174f41bdcedd08d12d7bed80088453d ]
    
    Whether or not a domain is attached to the device, the pasid table should
    always be valid as long as it has been probed. This moves the pasid table
    allocation from the domain attaching device path to device probe path and
    frees it in the device release path.
    
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Stable-dep-of: da37dddcf4ca ("iommu/vt-d: Disable PCI ATS in legacy passthrough mode")
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Disable PCI ATS in legacy passthrough mode [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Wed Nov 22 11:26:04 2023 +0800

    iommu/vt-d: Disable PCI ATS in legacy passthrough mode
    
    [ Upstream commit da37dddcf4caf015c400a930301d2ee27a7a15fb ]
    
    When IOMMU hardware operates in legacy mode, the TT field of the context
    entry determines the translation type, with three supported types (Section
    9.3 Context Entry):
    
    - DMA translation without device TLB support
    - DMA translation with device TLB support
    - Passthrough mode with translated and translation requests blocked
    
    Device TLB support is absent when hardware is configured in passthrough
    mode.
    
    Disable the PCI ATS feature when IOMMU is configured for passthrough
    translation type in legacy (non-scalable) mode.
    
    Fixes: 0faa19a1515f ("iommu/vt-d: Decouple PASID & PRI enabling from SVA")
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Make context clearing consistent with context mapping [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Wed Nov 22 11:26:05 2023 +0800

    iommu/vt-d: Make context clearing consistent with context mapping
    
    [ Upstream commit 9a16ab9d640274b20813d2d17475e18d3e99d834 ]
    
    In the iommu probe_device path, domain_context_mapping() allows setting
    up the context entry for a non-PCI device. However, in the iommu
    release_device path, domain_context_clear() only clears context entries
    for PCI devices.
    
    Make domain_context_clear() behave consistently with
    domain_context_mapping() by clearing context entries for both PCI and
    non-PCI devices.
    
    Fixes: 579305f75d34 ("iommu/vt-d: Update to use PCI DMA aliases")
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Omit devTLB invalidation requests when TES=0 [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Wed Nov 22 11:26:03 2023 +0800

    iommu/vt-d: Omit devTLB invalidation requests when TES=0
    
    [ Upstream commit 0f5432a9b839847dcfe9fa369d72e3d646102ddf ]
    
    The latest VT-d spec indicates that when remapping hardware is disabled
    (TES=0 in Global Status Register), upstream ATS Invalidation Completion
    requests are treated as UR (Unsupported Request).
    
    Consequently, the spec recommends in section 4.3 Handling of Device-TLB
    Invalidations that software refrain from submitting any Device-TLB
    invalidation requests when address remapping hardware is disabled.
    
    Verify address remapping hardware is enabled prior to submitting Device-
    TLB invalidation requests.
    
    Fixes: 792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by default")
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv4: igmp: fix refcnt uaf issue when receiving igmp query packet [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Thu Nov 23 15:13:14 2023 +0800

    ipv4: igmp: fix refcnt uaf issue when receiving igmp query packet
    
    [ Upstream commit e2b706c691905fe78468c361aaabc719d0a496f1 ]
    
    When I perform the following test operations:
    1.ip link add br0 type bridge
    2.brctl addif br0 eth0
    3.ip addr add 239.0.0.1/32 dev eth0
    4.ip addr add 239.0.0.1/32 dev br0
    5.ip addr add 224.0.0.1/32 dev br0
    6.while ((1))
        do
            ifconfig br0 up
            ifconfig br0 down
        done
    7.send IGMPv2 query packets to port eth0 continuously. For example,
    ./mausezahn ethX -c 0 "01 00 5e 00 00 01 00 72 19 88 aa 02 08 00 45 00 00
    1c 00 01 00 00 01 02 0e 7f c0 a8 0a b7 e0 00 00 01 11 64 ee 9b 00 00 00 00"
    
    The preceding tests may trigger the refcnt uaf issue of the mc list. The
    stack is as follows:
            refcount_t: addition on 0; use-after-free.
            WARNING: CPU: 21 PID: 144 at lib/refcount.c:25 refcount_warn_saturate (lib/refcount.c:25)
            CPU: 21 PID: 144 Comm: ksoftirqd/21 Kdump: loaded Not tainted 6.7.0-rc1-next-20231117-dirty #80
            Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
            RIP: 0010:refcount_warn_saturate (lib/refcount.c:25)
            RSP: 0018:ffffb68f00657910 EFLAGS: 00010286
            RAX: 0000000000000000 RBX: ffff8a00c3bf96c0 RCX: ffff8a07b6160908
            RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff8a07b6160900
            RBP: ffff8a00cba36862 R08: 0000000000000000 R09: 00000000ffff7fff
            R10: ffffb68f006577c0 R11: ffffffffb0fdcdc8 R12: ffff8a00c3bf9680
            R13: ffff8a00c3bf96f0 R14: 0000000000000000 R15: ffff8a00d8766e00
            FS:  0000000000000000(0000) GS:ffff8a07b6140000(0000) knlGS:0000000000000000
            CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
            CR2: 000055f10b520b28 CR3: 000000039741a000 CR4: 00000000000006f0
            Call Trace:
            <TASK>
            igmp_heard_query (net/ipv4/igmp.c:1068)
            igmp_rcv (net/ipv4/igmp.c:1132)
            ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
            ip_local_deliver_finish (net/ipv4/ip_input.c:234)
            __netif_receive_skb_one_core (net/core/dev.c:5529)
            netif_receive_skb_internal (net/core/dev.c:5729)
            netif_receive_skb (net/core/dev.c:5788)
            br_handle_frame_finish (net/bridge/br_input.c:216)
            nf_hook_bridge_pre (net/bridge/br_input.c:294)
            __netif_receive_skb_core (net/core/dev.c:5423)
            __netif_receive_skb_list_core (net/core/dev.c:5606)
            __netif_receive_skb_list (net/core/dev.c:5674)
            netif_receive_skb_list_internal (net/core/dev.c:5764)
            napi_gro_receive (net/core/gro.c:609)
            e1000_clean_rx_irq (drivers/net/ethernet/intel/e1000/e1000_main.c:4467)
            e1000_clean (drivers/net/ethernet/intel/e1000/e1000_main.c:3805)
            __napi_poll (net/core/dev.c:6533)
            net_rx_action (net/core/dev.c:6735)
            __do_softirq (kernel/softirq.c:554)
            run_ksoftirqd (kernel/softirq.c:913)
            smpboot_thread_fn (kernel/smpboot.c:164)
            kthread (kernel/kthread.c:388)
            ret_from_fork (arch/x86/kernel/process.c:153)
            ret_from_fork_asm (arch/x86/entry/entry_64.S:250)
            </TASK>
    
    The root causes are as follows:
    Thread A                                        Thread B
    ...                                             netif_receive_skb
    br_dev_stop                                     ...
        br_multicast_leave_snoopers                 ...
            __ip_mc_dec_group                       ...
                __igmp_group_dropped                igmp_rcv
                    igmp_stop_timer                     igmp_heard_query         //ref = 1
                    ip_ma_put                               igmp_mod_timer
                        refcount_dec_and_test                   igmp_start_timer //ref = 0
                            ...                                     refcount_inc //ref increases from 0
    When the device receives an IGMPv2 Query message, it starts the timer
    immediately, regardless of whether the device is running. If the device is
    down and has left the multicast group, it will cause the mc list refcount
    uaf issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Hangbin Liu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers [+ + +]
Author: Nicholas Piggin <[email protected]>
Date:   Wed Nov 22 12:58:11 2023 +1000

    KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers
    
    commit dc158d23b33df9033bcc8e7117e8591dd2f9d125 upstream.
    
    Before running a guest, the host process (e.g., QEMU) FP/VEC registers
    are saved if they were being used, similarly to when the kernel uses FP
    registers. The guest values are then loaded into regs, and the host
    process registers will be restored lazily when it uses FP/VEC.
    
    KVM HV has a bug here: the host process registers do get saved, but the
    user MSR bits remain enabled, which indicates the registers are valid
    for the process. After they are clobbered by running the guest, this
    valid indication causes the host process to take on the FP/VEC register
    values of the guest.
    
    Fixes: 34e119c96b2b ("KVM: PPC: Book3S HV P9: Reduce mtmsrd instructions required to save host SPRs")
    Cc: [email protected] # v5.17+
    Signed-off-by: Nicholas Piggin <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Fix lapic timer interrupt lost after loading a snapshot. [+ + +]
Author: Haitao Shan <[email protected]>
Date:   Tue Sep 12 16:55:45 2023 -0700

    KVM: x86: Fix lapic timer interrupt lost after loading a snapshot.
    
    [ Upstream commit 9cfec6d097c607e36199cf0cfbb8cf5acbd8e9b2 ]
    
    When running android emulator (which is based on QEMU 2.12) on
    certain Intel hosts with kernel version 6.3-rc1 or above, guest
    will freeze after loading a snapshot. This is almost 100%
    reproducible. By default, the android emulator will use snapshot
    to speed up the next launching of the same android guest. So
    this breaks the android emulator badly.
    
    I tested QEMU 8.0.4 from Debian 12 with an Ubuntu 22.04 guest by
    running command "loadvm" after "savevm". The same issue is
    observed. At the same time, none of our AMD platforms is impacted.
    More experiments show that loading the KVM module with
    "enable_apicv=false" can workaround it.
    
    The issue started to show up after commit 8e6ed96cdd50 ("KVM: x86:
    fire timer when it is migrated and expired, and in oneshot mode").
    However, as is pointed out by Sean Christopherson, it is introduced
    by commit 967235d32032 ("KVM: vmx: clear pending interrupts on
    KVM_SET_LAPIC"). commit 8e6ed96cdd50 ("KVM: x86: fire timer when
    it is migrated and expired, and in oneshot mode") just makes it
    easier to hit the issue.
    
    Having both commits, the oneshot lapic timer gets fired immediately
    inside the KVM_SET_LAPIC call when loading the snapshot. On Intel
    platforms with APIC virtualization and posted interrupt processing,
    this eventually leads to setting the corresponding PIR bit. However,
    the whole PIR bits get cleared later in the same KVM_SET_LAPIC call
    by apicv_post_state_restore. This leads to timer interrupt lost.
    
    The fix is to move vmx_apicv_post_state_restore to the beginning of
    the KVM_SET_LAPIC call and rename to vmx_apicv_pre_state_restore.
    What vmx_apicv_post_state_restore does is actually clearing any
    former apicv state and this behavior is more suitable to carry out
    in the beginning.
    
    Fixes: 967235d32032 ("KVM: vmx: clear pending interrupts on KVM_SET_LAPIC")
    Cc: [email protected]
    Suggested-by: Sean Christopherson <[email protected]>
    Signed-off-by: Haitao Shan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.1.66 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Dec 8 08:51:20 2023 +0100

    Linux 6.1.66
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Conor Dooley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: block: Be sure to wait while busy in CQE error recovery [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:17 2023 +0200

    mmc: block: Be sure to wait while busy in CQE error recovery
    
    commit c616696a902987352426fdaeec1b0b3240949e6b upstream.
    
    STOP command does not guarantee to wait while busy, but subsequent command
    MMC_CMDQ_TASK_MGMT to discard the queue will fail if the card is busy, so
    be sure to wait by employing mmc_poll_for_busy().
    
    Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Reviewed-by: Christian Loehle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: block: Do not lose cache flush during CQE error recovery [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:15 2023 +0200

    mmc: block: Do not lose cache flush during CQE error recovery
    
    commit 174925d340aac55296318e43fd96c0e1d196e105 upstream.
    
    During CQE error recovery, error-free data commands get requeued if there
    is any data left to transfer, but non-data commands are completed even
    though they have not been processed.  Requeue them instead.
    
    Note the only non-data command is cache flush, which would have resulted in
    a cache flush being lost if it was queued at the time of CQE recovery.
    
    Fixes: 1e8e55b67030 ("mmc: block: Add CQE support")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: block: Retry commands in CQE error recovery [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:18 2023 +0200

    mmc: block: Retry commands in CQE error recovery
    
    commit 8155d1fa3a747baad5caff5f8303321d68ddd48c upstream.
    
    It is important that MMC_CMDQ_TASK_MGMT command to discard the queue is
    successful because otherwise a subsequent reset might fail to flush the
    cache first.  Retry it and the previous STOP command.
    
    Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: core: add helpers mmc_regulator_enable/disable_vqmmc [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Sat Mar 11 23:39:55 2023 +0100

    mmc: core: add helpers mmc_regulator_enable/disable_vqmmc
    
    [ Upstream commit 8d91f3f8ae57e6292142ca89f322e90fa0d6ac02 ]
    
    There's a number of drivers (e.g. dw_mmc, meson-gx, mmci, sunxi) using
    the same mechanism and a private flag vqmmc_enabled to deal with
    enabling/disabling the vqmmc regulator.
    
    Move this to the core and create new helpers mmc_regulator_enable_vqmmc
    and mmc_regulator_disable_vqmmc.
    
    Signed-off-by: Heiner Kallweit <[email protected]>
    Acked-by: Martin Blumenstingl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Stable-dep-of: 477865af60b2 ("mmc: sdhci-sprd: Fix vqmmc not shutting down after the card was pulled")
    Signed-off-by: Sasha Levin <[email protected]>

mmc: cqhci: Fix task clearing in CQE error recovery [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:20 2023 +0200

    mmc: cqhci: Fix task clearing in CQE error recovery
    
    commit 1de1b77982e1a1df9707cb11f9b1789e6b8919d4 upstream.
    
    If a task completion notification (TCN) is received when there is no
    outstanding task, the cqhci driver issues a "spurious TCN" warning. This
    was observed to happen right after CQE error recovery.
    
    When an error interrupt is received the driver runs recovery logic.
    It halts the controller, clears all pending tasks, and then re-enables
    it. On some platforms, like Intel Jasper Lake, a stale task completion
    event was observed, regardless of the CQHCI_CLEAR_ALL_TASKS bit being set.
    
    This results in either:
    a) Spurious TC completion event for an empty slot.
    b) Corrupted data being passed up the stack, as a result of premature
       completion for a newly added task.
    
    Rather than add a quirk for affected controllers, ensure tasks are cleared
    by toggling CQHCI_ENABLE, which would happen anyway if
    cqhci_clear_all_tasks() timed out. This is simpler and should be safe and
    effective for all controllers.
    
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Cc: [email protected]
    Reported-by: Kornel DulÄ™ba <[email protected]>
    Tested-by: Kornel DulÄ™ba <[email protected]>
    Co-developed-by: Kornel DulÄ™ba <[email protected]>
    Signed-off-by: Kornel DulÄ™ba <[email protected]>
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: cqhci: Increase recovery halt timeout [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:16 2023 +0200

    mmc: cqhci: Increase recovery halt timeout
    
    commit b578d5d18e929aa7c007a98cce32657145dde219 upstream.
    
    Failing to halt complicates the recovery. Additionally, unless the card or
    controller are stuck, which is expected to be very rare, then the halt
    should succeed, so it is better to wait. Set a large timeout.
    
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: cqhci: Warn of halt or task clear failure [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Fri Nov 3 10:47:19 2023 +0200

    mmc: cqhci: Warn of halt or task clear failure
    
    commit 35597bdb04ec27ef3b1cea007dc69f8ff5df75a5 upstream.
    
    A correctly operating controller should successfully halt and clear tasks.
    Failure may result in errors elsewhere, so promote messages from debug to
    warnings.
    
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Reviewed-by: Avri Altman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-pci-gli: Disable LPM during initialization [+ + +]
Author: Kornel DulÄ™ba <[email protected]>
Date:   Tue Nov 14 11:54:49 2023 +0000

    mmc: sdhci-pci-gli: Disable LPM during initialization
    
    commit d9ed644f58670865cf067351deb71010bd87a52f upstream.
    
    To address IO performance commit f9e5b33934ce
    ("mmc: host: Improve I/O read/write performance for GL9763E")
    limited LPM negotiation to runtime suspend state.
    The problem is that it only flips the switch in the runtime PM
    resume/suspend logic.
    
    Disable LPM negotiation in gl9763e_add_host.
    This helps in two ways:
    1. It was found that the LPM switch stays in the same position after
       warm reboot. Having it set in init helps with consistency.
    2. Disabling LPM during the first runtime resume leaves us susceptible
       to the performance issue in the time window between boot and the
       first runtime suspend.
    
    Fixes: f9e5b33934ce ("mmc: host: Improve I/O read/write performance for GL9763E")
    Cc: [email protected]
    Signed-off-by: Kornel DulÄ™ba <[email protected]>
    Reviewed-by: Sven van Ashbrook <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-sprd: Fix vqmmc not shutting down after the card was pulled [+ + +]
Author: Wenchao Chen <[email protected]>
Date:   Wed Nov 15 16:34:06 2023 +0800

    mmc: sdhci-sprd: Fix vqmmc not shutting down after the card was pulled
    
    [ Upstream commit 477865af60b2117ceaa1d558e03559108c15c78c ]
    
    With cat regulator_summary, we found that vqmmc was not shutting
    down after the card was pulled.
    
    cat /sys/kernel/debug/regulator/regulator_summary
    1.before fix
    1)Insert SD card
     vddsdio                1    1  0 unknown  3500mV 0mA  1200mV  3750mV
        71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV
    
    2)Pull out the SD card
     vddsdio                1    1  0 unknown  3500mV 0mA  1200mV  3750mV
        71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV
    
    2.after fix
    1)Insert SD cardt
     vddsdio                1    1  0 unknown  3500mV 0mA  1200mV  3750mV
        71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV
    
    2)Pull out the SD card
     vddsdio                0    1  0 unknown  3500mV 0mA  1200mV  3750mV
        71100000.mmc-vqmmc  0                         0mA  3500mV  3600mV
    
    Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
    Signed-off-by: Wenchao Chen <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: ravb: Check return value of reset_control_deassert() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:34 2023 +0200

    net: ravb: Check return value of reset_control_deassert()
    
    [ Upstream commit d8eb6ea4b302e7ff78535c205510e359ac10a0bd ]
    
    reset_control_deassert() could return an error. Some devices cannot work
    if reset signal de-assert operation fails. To avoid this check the return
    code of reset_control_deassert() in ravb_probe() and take proper action.
    
    Along with it, the free_netdev() call from the error path was moved after
    reset_control_assert() on its own label (out_free_netdev) to free
    netdev in case reset_control_deassert() fails.
    
    Fixes: 0d13a1a464a0 ("ravb: Add reset support")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Reviewed-by: Philipp Zabel <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ravb: Keep reverse order of operations in ravb_remove() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:39 2023 +0200

    net: ravb: Keep reverse order of operations in ravb_remove()
    
    [ Upstream commit edf9bc396e05081ca281ffb0cd41e44db478ff26 ]
    
    On RZ/G3S SMARC Carrier II board having RGMII connections b/w Ethernet
    MACs and PHYs it has been discovered that doing unbind/bind for ravb
    driver in a loop leads to wrong speed and duplex for Ethernet links and
    broken connectivity (the connectivity cannot be restored even with
    bringing interface down/up). Before doing unbind/bind the Ethernet
    interfaces were configured though systemd. The sh instructions used to
    do unbind/bind were:
    
    $ cd /sys/bus/platform/drivers/ravb/
    $ while :; do echo 11c30000.ethernet > unbind ; \
      echo 11c30000.ethernet > bind; done
    
    It has been discovered that there is a race b/w IOCTLs initialized by
    systemd at the response of success binding and the
    "ravb_write(ndev, CCC_OPC_RESET, CCC)" call in ravb_remove() as
    follows:
    
    1/ as a result of bind success the user space open/configures the
       interfaces tough an IOCTL; the following stack trace has been
       identified on RZ/G3S:
    
    Call trace:
    dump_backtrace+0x9c/0x100
    show_stack+0x20/0x38
    dump_stack_lvl+0x48/0x60
    dump_stack+0x18/0x28
    ravb_open+0x70/0xa58
    __dev_open+0xf4/0x1e8
    __dev_change_flags+0x198/0x218
    dev_change_flags+0x2c/0x80
    devinet_ioctl+0x640/0x708
    inet_ioctl+0x1e4/0x200
    sock_do_ioctl+0x50/0x108
    sock_ioctl+0x240/0x358
    __arm64_sys_ioctl+0xb0/0x100
    invoke_syscall+0x50/0x128
    el0_svc_common.constprop.0+0xc8/0xf0
    do_el0_svc+0x24/0x38
    el0_svc+0x34/0xb8
    el0t_64_sync_handler+0xc0/0xc8
    el0t_64_sync+0x190/0x198
    
    2/ this call may execute concurrently with ravb_remove() as the
       unbind/bind operation was executed in a loop
    3/ if the operation mode is changed to RESET (through
       ravb_write(ndev, CCC_OPC_RESET, CCC) call in ravb_remove())
       while the above ravb_open() is in progress it may lead to MAC
       (or PHY, or MAC-PHY connection, the right point hasn't been identified
       at the moment) to be broken, thus the Ethernet connectivity fails to
       restore.
    
    The simple fix for this is to move ravb_write(ndev, CCC_OPC_RESET, CCC))
    after unregister_netdev() to avoid resetting the controller while the
    netdev interface is still registered.
    
    To avoid future issues in ravb_remove(), the patch follows the proper order
    of operations in ravb_remove(): reverse order compared with ravb_probe().
    This avoids described races as the IOCTLs as well as unregister_netdev()
    (called now at the beginning of ravb_remove()) calls rtnl_lock() before
    continuing and IOCTLs check (though devinet_ioctl()) if device is still
    registered just after taking the lock:
    
    int devinet_ioctl(struct net *net, unsigned int cmd, struct ifreq *ifr)
    {
            // ...
    
            rtnl_lock();
    
            ret = -ENODEV;
            dev = __dev_get_by_name(net, ifr->ifr_name);
            if (!dev)
                    goto done;
    
            // ...
    done:
            rtnl_unlock();
    out:
            return ret;
    }
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ravb: Make write access to CXR35 first before accessing other EMAC registers [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:36 2023 +0200

    net: ravb: Make write access to CXR35 first before accessing other EMAC registers
    
    [ Upstream commit d78c0ced60d5e2f8b5a4a0468a5c400b24aeadf2 ]
    
    Hardware manual of RZ/G3S (and RZ/G2L) specifies the following on the
    description of CXR35 register (chapter "PHY interface select register
    (CXR35)"): "After release reset, make write-access to this register before
    making write-access to other registers (except MDIOMOD). Even if not need
    to change the value of this register, make write-access to this register
    at least one time. Because RGMII/MII MODE is recognized by accessing this
    register".
    
    The setup procedure for EMAC module (chapter "Setup procedure" of RZ/G3S,
    RZ/G2L manuals) specifies the E-MAC.CXR35 register is the first EMAC
    register that is to be configured.
    
    Note [A] from chapter "PHY interface select register (CXR35)" specifies
    the following:
    [A] The case which CXR35 SEL_XMII is used for the selection of RGMII/MII
    in APB Clock 100 MHz.
    (1) To use RGMII interface, Set ‘H’03E8_0000’ to this register.
    (2) To use MII interface, Set ‘H’03E8_0002’ to this register.
    
    Take into account these indication.
    
    Fixes: 1089877ada8d ("ravb: Add RZ/G2L MII interface support")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ravb: Start TX queues after HW initialization succeeded [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:37 2023 +0200

    net: ravb: Start TX queues after HW initialization succeeded
    
    [ Upstream commit 6f32c086602050fc11157adeafaa1c1eb393f0af ]
    
    ravb_phy_start() may fail. If that happens, the TX queues will remain
    started. Thus, move the netif_tx_start_all_queues() after PHY is
    successfully initialized.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ravb: Stop DMA in case of failures on ravb_open() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:38 2023 +0200

    net: ravb: Stop DMA in case of failures on ravb_open()
    
    [ Upstream commit eac16a733427ba0de2449ffc7bd3da32ddb65cb7 ]
    
    In case ravb_phy_start() returns with error the settings applied in
    ravb_dmac_init() are not reverted (e.g. config mode). For this call
    ravb_stop_dma() on failure path of ravb_open().
    
    Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ravb: Use pm_runtime_resume_and_get() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Tue Nov 28 10:04:35 2023 +0200

    net: ravb: Use pm_runtime_resume_and_get()
    
    [ Upstream commit 88b74831faaee455c2af380382d979fc38e79270 ]
    
    pm_runtime_get_sync() may return an error. In case it returns with an error
    dev->power.usage_count needs to be decremented. pm_runtime_resume_and_get()
    takes care of this. Thus use it.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: xgmac: Disable FPE MMC interrupts [+ + +]
Author: Furong Xu <[email protected]>
Date:   Sat Nov 25 14:01:26 2023 +0800

    net: stmmac: xgmac: Disable FPE MMC interrupts
    
    [ Upstream commit e54d628a2721bfbb002c19f6e8ca6746cec7640f ]
    
    Commit aeb18dd07692 ("net: stmmac: xgmac: Disable MMC interrupts
    by default") tries to disable MMC interrupts to avoid a storm of
    unhandled interrupts, but leaves the FPE(Frame Preemption) MMC
    interrupts enabled, FPE MMC interrupts can cause the same problem.
    Now we mask FPE TX and RX interrupts to disable all MMC interrupts.
    
    Fixes: aeb18dd07692 ("net: stmmac: xgmac: Disable MMC interrupts by default")
    Reviewed-by: Larysa Zaremba <[email protected]>
    Signed-off-by: Furong Xu <[email protected]>
    Reviewed-by: Serge Semin <[email protected]>
    Reviewed-by: Wojciech Drewek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: check for valid nvme_identify_ns() before using it [+ + +]
Author: Ewan D. Milne <[email protected]>
Date:   Mon Nov 27 15:56:57 2023 -0500

    nvme: check for valid nvme_identify_ns() before using it
    
    commit d8b90d600aff181936457f032d116dbd8534db06 upstream.
    
    When scanning namespaces, it is possible to get valid data from the first
    call to nvme_identify_ns() in nvme_alloc_ns(), but not from the second
    call in nvme_update_ns_info_block().  In particular, if the NSID becomes
    inactive between the two commands, a storage device may return a buffer
    filled with zero as per 4.1.5.1.  In this case, we can get a kernel crash
    due to a divide-by-zero in blk_stack_limits() because ns->lba_shift will
    be set to zero.
    
    PID: 326      TASK: ffff95fec3cd8000  CPU: 29   COMMAND: "kworker/u98:10"
     #0 [ffffad8f8702f9e0] machine_kexec at ffffffff91c76ec7
     #1 [ffffad8f8702fa38] __crash_kexec at ffffffff91dea4fa
     #2 [ffffad8f8702faf8] crash_kexec at ffffffff91deb788
     #3 [ffffad8f8702fb00] oops_end at ffffffff91c2e4bb
     #4 [ffffad8f8702fb20] do_trap at ffffffff91c2a4ce
     #5 [ffffad8f8702fb70] do_error_trap at ffffffff91c2a595
     #6 [ffffad8f8702fbb0] exc_divide_error at ffffffff928506e6
     #7 [ffffad8f8702fbd0] asm_exc_divide_error at ffffffff92a00926
        [exception RIP: blk_stack_limits+434]
        RIP: ffffffff92191872  RSP: ffffad8f8702fc80  RFLAGS: 00010246
        RAX: 0000000000000000  RBX: ffff95efa0c91800  RCX: 0000000000000001
        RDX: 0000000000000000  RSI: 0000000000000001  RDI: 0000000000000001
        RBP: 00000000ffffffff   R8: ffff95fec7df35a8   R9: 0000000000000000
        R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000
        R13: 0000000000000000  R14: 0000000000000000  R15: ffff95fed33c09a8
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #8 [ffffad8f8702fce0] nvme_update_ns_info_block at ffffffffc06d3533 [nvme_core]
     #9 [ffffad8f8702fd18] nvme_scan_ns at ffffffffc06d6fa7 [nvme_core]
    
    This happened when the check for valid data was moved out of nvme_identify_ns()
    into one of the callers.  Fix this by checking in both callers.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218186
    Fixes: 0dd6fff2aad4 ("nvme: bring back auto-removal of deleted namespaces during sequential scan")
    Cc: [email protected]
    Signed-off-by: Ewan D. Milne <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
octeontx2-af: Fix possible buffer overflow [+ + +]
Author: Elena Salomatkina <[email protected]>
Date:   Sat Nov 25 00:08:02 2023 +0300

    octeontx2-af: Fix possible buffer overflow
    
    [ Upstream commit ad31c629ca3c87f6d557488c1f9faaebfbcd203c ]
    
    A loop in rvu_mbox_handler_nix_bandprof_free() contains
    a break if (idx == MAX_BANDPROF_PER_PFFUNC),
    but if idx may reach MAX_BANDPROF_PER_PFFUNC
    buffer '(*req->prof_idx)[layer]' overflow happens before that check.
    
    The patch moves the break to the
    beginning of the loop.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: e8e095b3b370 ("octeontx2-af: cn10k: Bandwidth profiles config support").
    Signed-off-by: Elena Salomatkina <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Subbaraya Sundeep <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-af: Initialize 'cntr_val' to fix uninitialized symbol error [+ + +]
Author: Suman Ghosh <[email protected]>
Date:   Thu Jul 27 22:01:01 2023 +0530

    octeontx2-af: Initialize 'cntr_val' to fix uninitialized symbol error
    
    commit 222a6c42e9ef131fd20463bf95d7ce7b39bee2f8 upstream.
    
    drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c:860
    otx2_tc_update_mcam_table_del_req()
    error: uninitialized symbol 'cntr_val'.
    
    Fixes: ec87f05402f5 ("octeontx2-af: Install TC filter rules in hardware based on priority")
    Signed-off-by: Suman Ghosh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

octeontx2-af: Install TC filter rules in hardware based on priority [+ + +]
Author: Suman Ghosh <[email protected]>
Date:   Fri Jul 21 10:09:25 2023 +0530

    octeontx2-af: Install TC filter rules in hardware based on priority
    
    [ Upstream commit ec87f05402f592d27507e1aa6b2fd21c486f2cc0 ]
    
    As of today, hardware does not support installing tc filter
    rules based on priority. This patch adds support to install
    the hardware rules based on priority. The final hardware rules
    will not be dependent on rule installation order, it will be strictly
    priority based, same as software.
    
    Signed-off-by: Suman Ghosh <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: fd7f98b2e12a ("octeontx2-pf: Restore TC ingress police rules when interface is up")
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: Fix adding mbox work queue entry when num_vfs > 64 [+ + +]
Author: Geetha sowjanya <[email protected]>
Date:   Sat Nov 25 22:04:02 2023 +0530

    octeontx2-pf: Fix adding mbox work queue entry when num_vfs > 64
    
    [ Upstream commit 51597219e0cd5157401d4d0ccb5daa4d9961676f ]
    
    When more than 64 VFs are enabled for a PF then mbox communication
    between VF and PF is not working as mbox work queueing for few VFs
    are skipped due to wrong calculation of VF numbers.
    
    Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: Restore TC ingress police rules when interface is up [+ + +]
Author: Subbaraya Sundeep <[email protected]>
Date:   Sat Nov 25 22:06:57 2023 +0530

    octeontx2-pf: Restore TC ingress police rules when interface is up
    
    [ Upstream commit fd7f98b2e12a3d96a92bde6640657ec7116f4372 ]
    
    TC ingress policer rules depends on interface receive queue
    contexts since the bandwidth profiles are attached to RQ
    contexts. When an interface is brought down all the queue
    contexts are freed. This in turn frees bandwidth profiles in
    hardware causing ingress police rules non-functional after
    the interface is brought up. Fix this by applying all the ingress
    police rules config to hardware in otx2_open. Also allow
    adding ingress rules only when interface is running
    since no contexts exist for the interface when it is down.
    
    Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: Drop the HP-UX ENOSYM and EREMOTERELEASE error codes [+ + +]
Author: Helge Deller <[email protected]>
Date:   Thu Nov 23 20:28:27 2023 +0100

    parisc: Drop the HP-UX ENOSYM and EREMOTERELEASE error codes
    
    commit e5f3e299a2b1e9c3ece24a38adfc089aef307e8a upstream.
    
    Those return codes are only defined for the parisc architecture and
    are leftovers from when we wanted to be HP-UX compatible.
    
    They are not returned by any Linux kernel syscall but do trigger
    problems with the glibc strerrorname_np() and strerror() functions as
    reported in glibc issue #31080.
    
    There is no need to keep them, so simply remove them.
    
    Signed-off-by: Helge Deller <[email protected]>
    Reported-by: Bruno Haible <[email protected]>
    Closes: https://sourceware.org/bugzilla/show_bug.cgi?id=31080
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Ensure 32-bit alignment on parisc unwind section [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sat Nov 25 09:16:02 2023 +0100

    parisc: Ensure 32-bit alignment on parisc unwind section
    
    commit c9fcb2b65c2849e8ff3be23fd8828312fb68dc19 upstream.
    
    Make sure the .PARISC.unwind section will be 32-bit aligned.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Mark altinstructions read-only and 32-bit aligned [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Nov 20 23:10:20 2023 +0100

    parisc: Mark altinstructions read-only and 32-bit aligned
    
    commit 33f806da2df68606f77d7b892cd1298ba3d463e8 upstream.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Mark ex_table entries 32-bit aligned in assembly.h [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Nov 20 15:37:50 2023 +0100

    parisc: Mark ex_table entries 32-bit aligned in assembly.h
    
    commit e11d4cccd094a7cd4696c8c42e672c76c092dad5 upstream.
    
    Add an align statement to tell the linker that all ex_table entries and as
    such the whole ex_table section should be 32-bit aligned in vmlinux and modules.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Mark ex_table entries 32-bit aligned in uaccess.h [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Nov 20 15:39:03 2023 +0100

    parisc: Mark ex_table entries 32-bit aligned in uaccess.h
    
    commit a80aeb86542a50aa8521729ea4cc731ee7174f03 upstream.
    
    Add an align statement to tell the linker that all ex_table entries and as
    such the whole ex_table section should be 32-bit aligned in vmlinux and modules.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Mark jump_table naturally aligned [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Nov 20 23:14:39 2023 +0100

    parisc: Mark jump_table naturally aligned
    
    commit 07eecff8ae78df7f28800484d31337e1f9bfca3a upstream.
    
    The jump_table stores two 32-bit words and one 32- (on 32-bit kernel)
    or one 64-bit word (on 64-bit kernel).
    Ensure that the last word is always 64-bit aligned on a 64-bit kernel
    by aligning the whole structure on sizeof(long).
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Mark lock_aligned variables 16-byte aligned on SMP [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sat Nov 25 09:11:56 2023 +0100

    parisc: Mark lock_aligned variables 16-byte aligned on SMP
    
    commit b28fc0d8739c03e7b6c44914a9d00d4c6dddc0ea upstream.
    
    On parisc we need 16-byte alignment for variables which are used for
    locking. Mark the __lock_aligned attribute acordingly so that the
    .data..lock_aligned section will get that alignment in the generated
    object files.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Use natural CPU alignment for bug_table [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Nov 20 23:30:49 2023 +0100

    parisc: Use natural CPU alignment for bug_table
    
    commit fe76a1349f235969381832c83d703bc911021eb6 upstream.
    
    Make sure that the __bug_table section gets 32- or 64-bit aligned,
    depending if a 32- or 64-bit kernel is being built.
    Mark it non-writeable and use .blockz instead of the .org assembler
    directive to pad the struct.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]   # v6.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: Lengthen reset delay for VideoPropulsion Torrent QN16e card [+ + +]
Author: Lukas Wunner <[email protected]>
Date:   Thu Sep 21 16:23:34 2023 +0200

    PCI: Lengthen reset delay for VideoPropulsion Torrent QN16e card
    
    [ Upstream commit c9260693aa0c1e029ed23693cfd4d7814eee6624 ]
    
    Commit ac91e6980563 ("PCI: Unify delay handling for reset and resume")
    shortened an unconditional 1 sec delay after a Secondary Bus Reset to 100
    msec for PCIe (per PCIe r6.1 sec 6.6.1).  The 1 sec delay is only required
    for Conventional PCI.
    
    But it turns out that there are PCIe devices which require a longer delay
    than prescribed before first config space access after reset recovery or
    resume from D3cold:
    
    Chad reports that a "VideoPropulsion Torrent QN16e" MPEG QAM Modulator
    "raises a PCI system error (PERR), as reported by the IPMI event log, and
    the hardware itself would suffer a catastrophic event, cycling the server"
    unless the longer delay is observed.
    
    The card is specified to conform to PCIe r1.0 and indeed only supports Gen1
    speed (2.5 GT/s) according to lspci.  PCIe r1.0 sec 7.6 prescribes the same
    100 msec delay as PCIe r6.1 sec 6.6.1:
    
      To allow components to perform internal initialization, system software
      must wait for at least 100 ms from the end of a reset (cold/warm/hot)
      before it is permitted to issue Configuration Requests
    
    The behavior of the Torrent QN16e card thus appears to be a quirk.  Treat
    it as such and lengthen the reset delay for this specific device.
    
    Fixes: ac91e6980563 ("PCI: Unify delay handling for reset and resume")
    Link: https://lore.kernel.org/r/47727e792c7f0282dc144e3ec8ce8eb6e713394e.1695304512.git.lukas@wunner.de
    Reported-by: Chad Schroeder <[email protected]>
    Closes: https://lore.kernel.org/linux-pci/DM6PR16MB2844903E34CAB910082DF019B1FAA@DM6PR16MB2844.namprd16.prod.outlook.com/
    Tested-by: Chad Schroeder <[email protected]>
    Signed-off-by: Lukas Wunner <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected] # v5.4+
    Signed-off-by: Sasha Levin <[email protected]>

PCI: qcom-ep: Add dedicated callback for writing to DBI2 registers [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Wed Oct 25 18:30:29 2023 +0530

    PCI: qcom-ep: Add dedicated callback for writing to DBI2 registers
    
    [ Upstream commit a07d2497ed657eb2efeb967af47e22f573dcd1d6 ]
    
    The DWC core driver exposes the write_dbi2() callback for writing to the
    DBI2 registers in a vendor-specific way.
    
    On the Qcom EP platforms, the DBI_CS2 bit in the ELBI region needs to be
    asserted before writing to any DBI2 registers and deasserted once done.
    
    So, let's implement the callback for the Qcom PCIe EP driver so that the
    DBI2 writes are correctly handled in the hardware.
    
    Without this callback, the DBI2 register writes like BAR size won't go
    through and as a result, the default BAR size is set for all BARs.
    
    [kwilczynski: commit log, renamed function to match the DWC convention]
    Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver")
    Suggested-by: Serge Semin <[email protected]>
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Krzysztof WilczyÅ„ski <[email protected]>
    Reviewed-by: Serge Semin <[email protected]>
    Cc: [email protected] # 5.16+
    Signed-off-by: Sasha Levin <[email protected]>

 
pinctrl: avoid reload of p state in list iteration [+ + +]
Author: Maria Yu <[email protected]>
Date:   Wed Nov 15 18:28:24 2023 +0800

    pinctrl: avoid reload of p state in list iteration
    
    commit 4198a9b571065978632276264e01d71d68000ac5 upstream.
    
    When in the list_for_each_entry iteration, reload of p->state->settings
    with a local setting from old_state will turn the list iteration into an
    infinite loop.
    
    The typical symptom when the issue happens, will be a printk message like:
    
      "not freeing pin xx (xxx) as part of deactivating group xxx - it is
    already used for some other setting".
    
    This is a compiler-dependent problem, one instance occurred using Clang
    version 10.0 on the arm64 architecture with linux version 4.19.
    
    Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
    Signed-off-by: Maria Yu <[email protected]>
    Cc:  <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powercap: DTPM: Fix unneeded conversions to micro-Watts [+ + +]
Author: Lukasz Luba <[email protected]>
Date:   Mon Nov 27 09:28:19 2023 +0000

    powercap: DTPM: Fix unneeded conversions to micro-Watts
    
    commit b817f1488fca548fe50e2654d84a1956a16a1a8a upstream.
    
    The power values coming from the Energy Model are already in uW.
    
    The PowerCap and DTPM frameworks operate on uW, so all places should
    just use the values from the EM.
    
    Fix the code by removing all of the conversion to uW still present in it.
    
    Fixes: ae6ccaa65038 (PM: EM: convert power field to micro-Watts precision and align drivers)
    Cc: 5.19+ <[email protected]> # v5.19+
    Signed-off-by: Lukasz Luba <[email protected]>
    [ rjw: Changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc: Don't clobber f0/vs0 during fp|altivec register save [+ + +]
Author: Timothy Pearson <[email protected]>
Date:   Sun Nov 19 09:18:02 2023 -0600

    powerpc: Don't clobber f0/vs0 during fp|altivec register save
    
    commit 5e1d824f9a283cbf90f25241b66d1f69adb3835b upstream.
    
    During floating point and vector save to thread data f0/vs0 are
    clobbered by the FPSCR/VSCR store routine. This has been obvserved to
    lead to userspace register corruption and application data corruption
    with io-uring.
    
    Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
    all the FP, altivec, VMX register save paths.
    
    Tested under QEMU in kvm mode, running on a Talos II workstation with
    dual POWER9 DD2.2 CPUs.
    
    Additional detail (mpe):
    
    Typically save_fpu() is called from __giveup_fpu() which saves the FP
    regs and also *turns off FP* in the tasks MSR, meaning the kernel will
    reload the FP regs from the thread struct before letting the task use FP
    again. So in that case save_fpu() is free to clobber f0 because the FP
    regs no longer hold live values for the task.
    
    There is another case though, which is the path via:
      sys_clone()
        ...
        copy_process()
          dup_task_struct()
            arch_dup_task_struct()
              flush_all_to_thread()
                save_all()
    
    That path saves the FP regs but leaves them live. That's meant as an
    optimisation for a process that's using FP/VSX and then calls fork(),
    leaving the regs live means the parent process doesn't have to take a
    fault after the fork to get its FP regs back. The optimisation was added
    in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
    giving it up").
    
    That path does clobber f0, but f0 is volatile across function calls,
    and typically programs reach copy_process() from userspace via a syscall
    wrapper function. So in normal usage f0 being clobbered across a
    syscall doesn't cause visible data corruption.
    
    But there is now a new path, because io-uring can call copy_process()
    via create_io_thread() from the signal handling path. That's OK if the
    signal is handled as part of syscall return, but it's not OK if the
    signal is handled due to some other interrupt.
    
    That path is:
    
    interrupt_return_srr_user()
      interrupt_exit_user_prepare()
        interrupt_exit_user_prepare_main()
          do_notify_resume()
            get_signal()
              task_work_run()
                create_worker_cb()
                  create_io_worker()
                    copy_process()
                      dup_task_struct()
                        arch_dup_task_struct()
                          flush_all_to_thread()
                            save_all()
                              if (tsk->thread.regs->msr & MSR_FP)
                                save_fpu()
                                # f0 is clobbered and potentially live in userspace
    
    Note the above discussion applies equally to save_altivec().
    
    Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
    Cc: [email protected] # v4.6+
    Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
    Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
    Tested-by: Timothy Pearson <[email protected]>
    Tested-by: Jens Axboe <[email protected]>
    Signed-off-by: Timothy Pearson <[email protected]>
    [mpe: Reword change log to describe exact path of corruption & other minor tweaks]
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
r8169: disable ASPM in case of tx timeout [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Tue Jan 10 23:03:18 2023 +0100

    r8169: disable ASPM in case of tx timeout
    
    [ Upstream commit 80c0576ef179311f624bc450fede30a89afe9792 ]
    
    There are still single reports of systems where ASPM incompatibilities
    cause tx timeouts. It's not clear whom to blame, so let's disable
    ASPM in case of a tx timeout.
    
    v2:
    - add one-time warning for informing the user
    
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Alexander Duyck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 59d395ed606d ("r8169: fix deadlock on RTL8125 in jumbo mtu mode")
    Signed-off-by: Sasha Levin <[email protected]>

r8169: fix deadlock on RTL8125 in jumbo mtu mode [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Sun Nov 26 19:36:46 2023 +0100

    r8169: fix deadlock on RTL8125 in jumbo mtu mode
    
    [ Upstream commit 59d395ed606d8df14615712b0cdcdadb2d962175 ]
    
    The original change results in a deadlock if jumbo mtu mode is used.
    Reason is that the phydev lock is held when rtl_reset_work() is called
    here, and rtl_jumbo_config() calls phy_start_aneg() which also tries
    to acquire the phydev lock. Fix this by calling rtl_reset_work()
    asynchronously.
    
    Fixes: 621735f59064 ("r8169: fix rare issue with broken rx after link-down on RTL8125")
    Reported-by: Ian Chen <[email protected]>
    Tested-by: Ian Chen <[email protected]>
    Cc: [email protected]
    Signed-off-by: Heiner Kallweit <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8169: prevent potential deadlock in rtl8169_close [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Sun Nov 26 23:01:02 2023 +0100

    r8169: prevent potential deadlock in rtl8169_close
    
    [ Upstream commit 91d3d149978ba7b238198dd80e4b823756aa7cfa ]
    
    ndo_stop() is RTNL-protected by net core, and the worker function takes
    RTNL as well. Therefore we will deadlock when trying to execute a
    pending work synchronously. To fix this execute any pending work
    asynchronously. This will do no harm because netif_running() is false
    in ndo_stop(), and therefore the work function is effectively a no-op.
    However we have to ensure that no task is running or pending after
    rtl_remove_one(), therefore add a call to cancel_work_sync().
    
    Fixes: abe5fc42f9ce ("r8169: use RTNL to protect critical sections")
    Signed-off-by: Heiner Kallweit <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ravb: Fix races between ravb_tx_timeout_work() and net related ops [+ + +]
Author: Yoshihiro Shimoda <[email protected]>
Date:   Mon Nov 27 21:24:20 2023 +0900

    ravb: Fix races between ravb_tx_timeout_work() and net related ops
    
    [ Upstream commit 9870257a0a338cd8d6c1cddab74e703f490f6779 ]
    
    Fix races between ravb_tx_timeout_work() and functions of net_device_ops
    and ethtool_ops by using rtnl_trylock() and rtnl_unlock(). Note that
    since ravb_close() is under the rtnl lock and calls cancel_work_sync(),
    ravb_tx_timeout_work() should calls rtnl_trylock(). Otherwise, a deadlock
    may happen in ravb_tx_timeout_work() like below:
    
    CPU0                    CPU1
                            ravb_tx_timeout()
                            schedule_work()
    ...
    __dev_close_many()
    // Under rtnl lock
    ravb_close()
    cancel_work_sync()
    // Waiting
                            ravb_tx_timeout_work()
                            rtnl_lock()
                            // This is possible to cause a deadlock
    
    If rtnl_trylock() fails, rescheduling the work with sleep for 1 msec.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yoshihiro Shimoda <[email protected]>
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: Change SCSI device boolean fields to single bit flags [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Tue Nov 21 07:56:30 2023 +0900

    scsi: Change SCSI device boolean fields to single bit flags
    
    commit 6371be7aeb986905bb60ec73d002fc02343393b4 upstream.
    
    Commit 3cc2ffe5c16d ("scsi: sd: Differentiate system and runtime start/stop
    management") changed the single bit manage_start_stop flag into 2 boolean
    fields of the SCSI device structure. Commit 24eca2dce0f8 ("scsi: sd:
    Introduce manage_shutdown device flag") introduced the manage_shutdown
    boolean field for the same structure. Together, these 2 commits increase
    the size of struct scsi_device by 8 bytes by using booleans instead of
    defining the manage_xxx fields as single bit flags, similarly to other
    flags of this structure.
    
    Avoid this unnecessary structure size increase and be consistent with the
    definition of other flags by reverting the definitions of the manage_xxx
    fields as single bit flags.
    
    Fixes: 3cc2ffe5c16d ("scsi: sd: Differentiate system and runtime start/stop management")
    Fixes: 24eca2dce0f8 ("scsi: sd: Introduce manage_shutdown device flag")
    Cc: <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Niklas Cassel <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: sd: Fix system start for ATA devices [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Tue Nov 21 07:56:31 2023 +0900

    scsi: sd: Fix system start for ATA devices
    
    commit b09d7f8fd50f6e93cbadd8d27fde178f745b42a1 upstream.
    
    It is not always possible to keep a device in the runtime suspended state
    when a system level suspend/resume cycle is executed. E.g. for ATA devices
    connected to AHCI adapters, system resume resets the ATA ports, which
    causes connected devices to spin up. In such case, a runtime suspended disk
    will incorrectly be seen with a suspended runtime state because the device
    is not resumed by sd_resume_system(). The power state seen by the user is
    different than the actual device physical power state.
    
    Fix this issue by introducing the struct scsi_device flag
    force_runtime_start_on_system_start. When set, this flag causes
    sd_resume_system() to request a runtime resume operation for runtime
    suspended devices. This results in the user seeing the device runtime_state
    as active after a system resume, thus correctly reflecting the device
    physical power state.
    
    Fixes: 9131bff6a9f1 ("scsi: core: pm: Only runtime resume if necessary")
    Cc: <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/net: fix a char signedness issue [+ + +]
Author: Willem de Bruijn <[email protected]>
Date:   Fri Nov 24 12:15:20 2023 -0500

    selftests/net: fix a char signedness issue
    
    [ Upstream commit 7b29828c5af6841bdeb9fafa32fdfeff7ab9c407 ]
    
    Signedness of char is signed on x86_64, but unsigned on arm64.
    
    Fix the warning building cmsg_sender.c on signed platforms or
    forced with -fsigned-char:
    
        msg_sender.c:455:12:
        error: implicit conversion from 'int' to 'char'
        changes value from 128 to -128
        [-Werror,-Wconstant-conversion]
            buf[0] = ICMPV6_ECHO_REQUEST;
    
    constant ICMPV6_ECHO_REQUEST is 128.
    
    Link: https://lwn.net/Articles/911914
    Fixes: de17e305a810 ("selftests: net: cmsg_sender: support icmp and raw sockets")
    Signed-off-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/net: ipsec: fix constant out of range [+ + +]
Author: Willem de Bruijn <[email protected]>
Date:   Fri Nov 24 12:15:19 2023 -0500

    selftests/net: ipsec: fix constant out of range
    
    [ Upstream commit 088559815477c6f623a5db5993491ddd7facbec7 ]
    
    Fix a small compiler warning.
    
    nr_process must be a signed long: it is assigned a signed long by
    strtol() and is compared against LONG_MIN and LONG_MAX.
    
    ipsec.c:2280:65:
        error: result of comparison of constant -9223372036854775808
        with expression of type 'unsigned int' is always false
        [-Werror,-Wtautological-constant-out-of-range-compare]
    
      if ((errno == ERANGE && (nr_process == LONG_MAX || nr_process == LONG_MIN))
    
    Fixes: bc2652b7ae1e ("selftest/net/xfrm: Add test for ipsec tunnel")
    Signed-off-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Dmitry Safonov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/net: mptcp: fix uninitialized variable warnings [+ + +]
Author: Willem de Bruijn <[email protected]>
Date:   Fri Nov 24 12:15:22 2023 -0500

    selftests/net: mptcp: fix uninitialized variable warnings
    
    [ Upstream commit 00a4f8fd9c750f20d8fd4535c71c9caa7ef5ff2f ]
    
    Same init_rng() in both tests. The function reads /dev/urandom to
    initialize srand(). In case of failure, it falls back onto the
    entropy in the uninitialized variable. Not sure if this is on purpose.
    But failure reading urandom should be rare, so just fail hard. While
    at it, convert to getrandom(). Which man 4 random suggests is simpler
    and more robust.
    
        mptcp_inq.c:525:6:
        mptcp_connect.c:1131:6:
    
        error: variable 'foo' is used uninitialized
        whenever 'if' condition is false
        [-Werror,-Wsometimes-uninitialized]
    
    Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
    Fixes: b51880568f20 ("selftests: mptcp: add inq test case")
    Cc: Florian Westphal <[email protected]>
    Signed-off-by: Willem de Bruijn <[email protected]>
    
    ----
    
    When input is randomized because this is expected to meaningfully
    explore edge cases, should we also add
    1. logging the random seed to stdout and
    2. adding a command line argument to replay from a specific seed
    I can do this in net-next, if authors find it useful in this case.
    Reviewed-by: Matthieu Baerts <[email protected]>
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/net: unix: fix unused variable compiler warning [+ + +]
Author: Willem de Bruijn <[email protected]>
Date:   Fri Nov 24 12:15:21 2023 -0500

    selftests/net: unix: fix unused variable compiler warning
    
    [ Upstream commit 59fef379d453781f0dabfa1f1a1e86e78aee919a ]
    
    Remove an unused variable.
    
        diag_uid.c:151:24:
        error: unused variable 'udr'
        [-Werror,-Wunused-variable]
    
    Fixes: ac011361bd4f ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.")
    Signed-off-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: sc16is7xx: add missing support for rs485 devicetree properties [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Mon Aug 7 17:45:56 2023 -0400

    serial: sc16is7xx: add missing support for rs485 devicetree properties
    
    commit b4a778303ea0fcabcaff974721477a5743e1f8ec upstream.
    
    Retrieve rs485 devicetree properties on registration of sc16is7xx ports in
    case they are attached to an rs485 transceiver.
    
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Lech Perczak <[email protected]>
    Tested-by: Lech Perczak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Hugo Villeneuve <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: sc16is7xx: Put IOControl register into regmap_volatile [+ + +]
Author: Hui Wang <[email protected]>
Date:   Mon Jul 24 11:47:27 2023 +0800

    serial: sc16is7xx: Put IOControl register into regmap_volatile
    
    commit 77a82cebf0eb023203b4cb2235cab75afc77cccf upstream.
    
    According to the IOControl register bits description in the page 31 of
    the product datasheet, we know the bit 3 of IOControl register is
    softreset, this bit will self-clearing once the reset finish.
    
    In the probe, the softreset bit is set, and when we read this register
    from debugfs/regmap interface, we found the softreset bit is still
    setting, this confused us for a while. Finally we found this register
    is cached, to read the real value from register, we could put it
    into the regmap_volatile().
    
    Signed-off-by: Hui Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Hugo Villeneuve <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
smb: client: report correct st_size for SMB and NFS symlinks [+ + +]
Author: Paulo Alcantara <[email protected]>
Date:   Tue Nov 28 16:37:19 2023 -0300

    smb: client: report correct st_size for SMB and NFS symlinks
    
    commit 9d63509547a940225d06d7eba1dc412befae255d upstream.
    
    We can't rely on FILE_STANDARD_INFORMATION::EndOfFile for reparse
    points as they will be always zero.  Set it to symlink target's length
    as specified by POSIX.
    
    This will make stat() family of syscalls return the correct st_size
    for such files.
    
    Cc: [email protected]
    Signed-off-by: Paulo Alcantara (SUSE) <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: Fix null dereference on suspend [+ + +]
Author: Mark Hasemeyer <[email protected]>
Date:   Tue Nov 7 14:47:43 2023 -0700

    spi: Fix null dereference on suspend
    
    [ Upstream commit bef4a48f4ef798c4feddf045d49e53c8a97d5e37 ]
    
    A race condition exists where a synchronous (noqueue) transfer can be
    active during a system suspend. This can cause a null pointer
    dereference exception to occur when the system resumes.
    
    Example order of events leading to the exception:
    1. spi_sync() calls __spi_transfer_message_noqueue() which sets
       ctlr->cur_msg
    2. Spi transfer begins via spi_transfer_one_message()
    3. System is suspended interrupting the transfer context
    4. System is resumed
    6. spi_controller_resume() calls spi_start_queue() which resets cur_msg
       to NULL
    7. Spi transfer context resumes and spi_finalize_current_message() is
       called which dereferences cur_msg (which is now NULL)
    
    Wait for synchronous transfers to complete before suspending by
    acquiring the bus mutex and setting/checking a suspend flag.
    
    Signed-off-by: Mark Hasemeyer <[email protected]>
    Link: https://lore.kernel.org/r/20231107144743.v1.1.I7987f05f61901f567f7661763646cb7d7919b528@changeid
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
uapi: propagate __struct_group() attributes to the container union [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Mon Nov 20 14:05:08 2023 +0300

    uapi: propagate __struct_group() attributes to the container union
    
    [ Upstream commit 4e86f32a13af1970d21be94f659cae56bbe487ee ]
    
    Recently the kernel test robot has reported an ARM-specific BUILD_BUG_ON()
    in an old and unmaintained wil6210 wireless driver. The problem comes from
    the structure packing rules of old ARM ABI ('-mabi=apcs-gnu'). For example,
    the following structure is packed to 18 bytes instead of 16:
    
    struct poorly_packed {
            unsigned int a;
            unsigned int b;
            unsigned short c;
            union {
                    struct {
                            unsigned short d;
                            unsigned int e;
                    } __attribute__((packed));
                    struct {
                            unsigned short d;
                            unsigned int e;
                    } __attribute__((packed)) inner;
            };
    } __attribute__((packed));
    
    To fit it into 16 bytes, it's required to add packed attribute to the
    container union as well:
    
    struct poorly_packed {
            unsigned int a;
            unsigned int b;
            unsigned short c;
            union {
                    struct {
                            unsigned short d;
                            unsigned int e;
                    } __attribute__((packed));
                    struct {
                            unsigned short d;
                            unsigned int e;
                    } __attribute__((packed)) inner;
            } __attribute__((packed));
    } __attribute__((packed));
    
    Thanks to Andrew Pinski of GCC team for sorting the things out at
    https://gcc.gnu.org/pipermail/gcc/2023-November/242888.html.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]
    Signed-off-by: Dmitry Antipov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 50d7bd38c3aa ("stddef: Introduce struct_group() helper macro")
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: config: fix iteration issue in 'usb_get_bos_descriptor()' [+ + +]
Author: Niklas Neronin <[email protected]>
Date:   Wed Nov 15 14:13:25 2023 +0200

    usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
    
    [ Upstream commit 974bba5c118f4c2baf00de0356e3e4f7928b4cbc ]
    
    The BOS descriptor defines a root descriptor and is the base descriptor for
    accessing a family of related descriptors.
    
    Function 'usb_get_bos_descriptor()' encounters an iteration issue when
    skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
    the same descriptor being read repeatedly.
    
    To address this issue, a 'goto' statement is introduced to ensure that the
    pointer and the amount read is updated correctly. This ensures that the
    function iterates to the next descriptor instead of reading the same
    descriptor repeatedly.
    
    Cc: [email protected]
    Fixes: 3dd550a2d365 ("USB: usbcore: Fix slab-out-of-bounds bug during device reset")
    Signed-off-by: Niklas Neronin <[email protected]>
    Acked-by: Mathias Nyman <[email protected]>
    Reviewed-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: core: Change configuration warnings to notices [+ + +]
Author: Alan Stern <[email protected]>
Date:   Wed Nov 2 14:13:19 2022 -0400

    USB: core: Change configuration warnings to notices
    
    [ Upstream commit 7a09c1269702db8eccb6f718da2b00173e1e0034 ]
    
    It has been pointed out that the kernel log messages warning about
    problems in USB configuration and related descriptors are vexing for
    users.  The warning log level has a fairly high priority, but the user
    can do nothing to fix the underlying errors in the device's firmware.
    
    To reduce the amount of useless information produced by tools that
    filter high-priority log messages, we can change these warnings to
    notices, i.e., change dev_warn() to dev_notice().  The same holds for
    a few messages that currently use dev_err(): Unless they indicate a
    failure that might make a device unusable (such as inability to
    transfer a config descriptor), change them to dev_notice() also.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216630
    Suggested-by: Artem S. Tashkinov <[email protected]>
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 974bba5c118f ("usb: config: fix iteration issue in 'usb_get_bos_descriptor()'")
    Signed-off-by: Sasha Levin <[email protected]>

USB: xhci-plat: fix legacy PHY double init [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Fri Nov 3 17:43:23 2023 +0100

    USB: xhci-plat: fix legacy PHY double init
    
    [ Upstream commit 16b7e0cccb243033de4406ffb4d892365041a1e7 ]
    
    Commits 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") and
    9134c1fd0503 ("usb: xhci: plat: Add USB 3.0 phy support") added support
    for looking up legacy PHYs from the sysdev devicetree node and
    initialising them.
    
    This broke drivers such as dwc3 which manages PHYs themself as the PHYs
    would now be initialised twice, something which specifically can lead to
    resources being left enabled during suspend (e.g. with the
    usb_phy_generic PHY driver).
    
    As the dwc3 driver uses driver-name matching for the xhci platform
    device, fix this by only looking up and initialising PHYs for devices
    that have been matched using OF.
    
    Note that checking that the platform device has a devicetree node would
    currently be sufficient, but that could lead to subtle breakages in case
    anyone ever tries to reuse an ancestor's node.
    
    Fixes: 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support")
    Fixes: 9134c1fd0503 ("usb: xhci: plat: Add USB 3.0 phy support")
    Cc: [email protected]      # 4.1
    Cc: Maxime Ripard <[email protected]>
    Cc: Stanley Chang <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Tested-by: Stefan Eichenberger <[email protected]>
    Tested-by: Stanley Chang <[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]>

 
wifi: cfg80211: fix CQM for non-range use [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Nov 6 23:17:16 2023 +0100

    wifi: cfg80211: fix CQM for non-range use
    
    commit 7e7efdda6adb385fbdfd6f819d76bc68c923c394 upstream.
    
    My prior race fix here broke CQM when ranges aren't used, as
    the reporting worker now requires the cqm_config to be set in
    the wdev, but isn't set when there's no range configured.
    
    Rather than continuing to special-case the range version, set
    the cqm_config always and configure accordingly, also tracking
    if range was used or not to be able to clear the configuration
    appropriately with the same API, which was actually not right
    if both were implemented by a driver for some reason, as is
    the case with mac80211 (though there the implementations are
    equivalent so it doesn't matter.)
    
    Also, the original multiple-RSSI commit lost checking for the
    callback, so might have potentially crashed if a driver had
    neither implementation, and userspace tried to use it despite
    not being advertised as supported.
    
    Cc: [email protected]
    Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM")
    Fixes: 37c20b2effe9 ("wifi: cfg80211: fix cqm_config access race")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/apic/msi: Fix misconfigured non-maskable MSI quirk [+ + +]
Author: Koichiro Den <[email protected]>
Date:   Thu Oct 26 12:20:36 2023 +0900

    x86/apic/msi: Fix misconfigured non-maskable MSI quirk
    
    commit b56ebe7c896dc78b5865ec2c4b1dae3c93537517 upstream.
    
    commit ef8dd01538ea ("genirq/msi: Make interrupt allocation less
    convoluted"), reworked the code so that the x86 specific quirk for affinity
    setting of non-maskable PCI/MSI interrupts is not longer activated if
    necessary.
    
    This could be solved by restoring the original logic in the core MSI code,
    but after a deeper analysis it turned out that the quirk flag is not
    required at all.
    
    The quirk is only required when the PCI/MSI device cannot mask the MSI
    interrupts, which in turn also prevents reservation mode from being enabled
    for the affected interrupt.
    
    This allows ot remove the NOMASK quirk bit completely as msi_set_affinity()
    can instead check whether reservation mode is enabled for the interrupt,
    which gives exactly the same answer.
    
    Even in the momentary non-existing case that the reservation mode would be
    not set for a maskable MSI interrupt this would not cause any harm as it
    just would cause msi_set_affinity() to go needlessly through the
    functionaly equivalent slow path, which works perfectly fine with maskable
    interrupts as well.
    
    Rework msi_set_affinity() to query the reservation mode and remove all
    NOMASK quirk logic from the core code.
    
    [ tglx: Massaged changelog ]
    
    Fixes: ef8dd01538ea ("genirq/msi: Make interrupt allocation less convoluted")
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Koichiro Den <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/xen: fix percpu vcpu_info allocation [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Fri Nov 24 08:48:52 2023 +0100

    x86/xen: fix percpu vcpu_info allocation
    
    [ Upstream commit db2832309a82b9acc4b8cc33a1831d36507ec13e ]
    
    Today the percpu struct vcpu_info is allocated via DEFINE_PER_CPU(),
    meaning that it could cross a page boundary. In this case registering
    it with the hypervisor will fail, resulting in a panic().
    
    This can easily be fixed by using DEFINE_PER_CPU_ALIGNED() instead,
    as struct vcpu_info is guaranteed to have a size of 64 bytes, matching
    the cache line size of x86 64-bit processors (Xen doesn't support
    32-bit processors).
    
    Fixes: 5ead97c84fa7 ("xen: Core Xen implementation")
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Boris Ostrovsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xen: Allow platform PCI interrupt to be shared [+ + +]
Author: David Woodhouse <[email protected]>
Date:   Wed Jan 18 12:22:38 2023 +0000

    xen: Allow platform PCI interrupt to be shared
    
    [ Upstream commit 3e8cd711c3da6c3d724076048038cd666bdbb2b5 ]
    
    When we don't use the per-CPU vector callback, we ask Xen to deliver event
    channel interrupts as INTx on the PCI platform device. As such, it can be
    shared with INTx on other PCI devices.
    
    Set IRQF_SHARED, and make it return IRQ_HANDLED or IRQ_NONE according to
    whether the evtchn_upcall_pending flag was actually set. Now I can share
    the interrupt:
    
     11:         82          0   IO-APIC  11-fasteoi   xen-platform-pci, ens4
    
    Drop the IRQF_TRIGGER_RISING. It has no effect when the IRQ is shared,
    and besides, the only effect it was having even beforehand was to trigger
    a debug message in both I/OAPIC and legacy PIC cases:
    
    [    0.915441] genirq: No set_type function for IRQ 11 (IO-APIC)
    [    0.951939] genirq: No set_type function for IRQ 11 (XT-PIC)
    
    Signed-off-by: David Woodhouse <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Stable-dep-of: db2832309a82 ("x86/xen: fix percpu vcpu_info allocation")
    Signed-off-by: Sasha Levin <[email protected]>

xen: simplify evtchn_do_upcall() call maze [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Thu Aug 24 17:34:21 2023 +0200

    xen: simplify evtchn_do_upcall() call maze
    
    [ Upstream commit 37510dd566bdbff31a769cde2fa6654bccdb8b24 ]
    
    There are several functions involved for performing the functionality
    of evtchn_do_upcall():
    
    - __xen_evtchn_do_upcall() doing the real work
    - xen_hvm_evtchn_do_upcall() just being a wrapper for
      __xen_evtchn_do_upcall(), exposed for external callers
    - xen_evtchn_do_upcall() calling __xen_evtchn_do_upcall(), too, but
      without any user
    
    Simplify this maze by:
    
    - removing the unused xen_evtchn_do_upcall()
    - removing xen_hvm_evtchn_do_upcall() as the only left caller of
      __xen_evtchn_do_upcall(), while renaming __xen_evtchn_do_upcall() to
      xen_evtchn_do_upcall()
    
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Boris Ostrovsky <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Stable-dep-of: db2832309a82 ("x86/xen: fix percpu vcpu_info allocation")
    Signed-off-by: Sasha Levin <[email protected]>