Linux 6.9.2

 
admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Tue Apr 23 12:34:25 2024 +0200

    admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET
    
    commit 8af2d1ab78f2342f8c4c3740ca02d86f0ebfac5a upstream.
    
    sched_core_share_pid() copies the cookie to userspace with
    put_user(id, (u64 __user *)uaddr), expecting 64 bits of space.
    The "unsigned long" datatype that is documented in core-scheduling.rst
    however is only 32 bits large on 32 bit architectures.
    
    Document "unsigned long long" as the correct data type that is always
    64bits large.
    
    This matches what the selftest cs_prctl_test.c has been doing all along.
    
    Fixes: 0159bb020ca9 ("Documentation: Add usecases, design and interface for core scheduling")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/util-linux/df7a25a0-7923-4f8b-a527-5e6f0064074d@t-8ch.de/
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Reviewed-by: Chris Hyser <chris.hyser@oracle.com>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/20240423-core-scheduling-cookie-v1-1-5753a35f8dfc@weissschuh.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: Intel: sof_sdw: use generic rtd_init function for Realtek SDW DMICs [+ + +]
Author: Bard Liao <yung-chuan.liao@linux.intel.com>
Date:   Tue Mar 26 11:04:19 2024 -0500

    ASoC: Intel: sof_sdw: use generic rtd_init function for Realtek SDW DMICs
    
    commit bee2fe44679f1e6a5332d7f78587ccca4109919f upstream.
    
    The only thing that the rt_xxx_rtd_init() functions do is to set
    card->components. And we can set card->components with name_prefix
    as rt712_sdca_dmic_rtd_init() does.
    And sof_sdw_rtd_init() will always select the first dai with the
    given dai->name from codec_info_list[]. Unfortunately, we have
    different codecs with the same dai name. For example, dai name of
    rt715 and rt715-sdca are both "rt715-aif2". Using a generic rtd_init
    allow sof_sdw_rtd_init() run the rtd_init() callback from a similar
    codec dai.
    
    Fixes: 8266c73126b7 ("ASoC: Intel: sof_sdw: add common sdw dai link init")
    Reviewed-by: Chao Song <chao.song@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://msgid.link/r/20240326160429.13560-25-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
binder: fix max_thread type inconsistency [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Sun Apr 21 17:37:49 2024 +0000

    binder: fix max_thread type inconsistency
    
    commit 42316941335644a98335f209daafa4c122f28983 upstream.
    
    The type defined for the BINDER_SET_MAX_THREADS ioctl was changed from
    size_t to __u32 in order to avoid incompatibility issues between 32 and
    64-bit kernels. However, the internal types used to copy from user and
    store the value were never updated. Use u32 to fix the inconsistency.
    
    Fixes: a9350fc859ae ("staging: android: binder: fix BINDER_SET_MAX_THREADS declaration")
    Reported-by: Arve Hjønnevåg <arve@android.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://lore.kernel.org/r/20240421173750.3117808-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: add a disk_has_partscan helper [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu May 2 15:00:32 2024 +0200

    block: add a disk_has_partscan helper
    
    commit 140ce28dd3bee8e53acc27f123ae474d69ef66f0 upstream.
    
    Add a helper to check if partition scanning is enabled instead of
    open coding the check in a few places.  This now always checks for
    the hidden flag even if all but one of the callers are never reachable
    for hidden gendisks.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240502130033.1958492-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

block: add a partscan sysfs attribute for disks [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu May 2 15:00:33 2024 +0200

    block: add a partscan sysfs attribute for disks
    
    commit a4217c6740dc64a3eb6815868a9260825e8c68c6 upstream.
    
    Userspace had been unknowingly relying on a non-stable interface of
    kernel internals to determine if partition scanning is enabled for a
    given disk. Provide a stable interface for this purpose instead.
    
    Cc: stable@vger.kernel.org # 6.3+
    Depends-on: 140ce28dd3be ("block: add a disk_has_partscan helper")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/linux-block/ZhQJf8mzq_wipkBH@gardel-login/
    Link: https://lore.kernel.org/r/20240502130033.1958492-3-hch@lst.de
    [axboe: add links and commit message from Keith]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: btusb: Fix the patch for MT7920 the affected to MT7921 [+ + +]
Author: Peter Tsao <peter.tsao@mediatek.com>
Date:   Mon Apr 15 22:19:22 2024 +0800

    Bluetooth: btusb: Fix the patch for MT7920 the affected to MT7921
    
    commit 958cd6beab693f395ffe07814ef77d2b45e8b0fc upstream.
    
    Because both MT7920 and MT7921 use the same chip ID.
    We use the 8th bit of fw_flavor to distingush MT7920.
    The original patch made a mistake to check whole fw_flavor,
    that makes the condition both true (dev_id == 0x7961 && fw_flavor),
    and makes MT7921 flow wrong.
    
    In this patch, we correct the flow to get the 8th bit value for MT7920.
    And the patch is verified pass with both MT7920 and MT7921.
    
    Signed-off-by: Peter Tsao <peter.tsao@mediatek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() [+ + +]
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Sat May 4 15:23:29 2024 -0400

    Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
    
    commit a5b862c6a221459d54e494e88965b48dcfa6cc44 upstream.
    
    l2cap_le_flowctl_init() can cause both div-by-zero and an integer
    overflow since hdev->le_mtu may not fall in the valid range.
    
    Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
    process earlier if MTU is invalid.
    Also, add a missing validation in read_buffer_size() and make it return
    an error value if the validation fails.
    Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
    kzalloc failure and invalid MTU value.
    
    divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
    CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Workqueue: hci0 hci_rx_work
    RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
    Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
    89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
    b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
    RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
    RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
    RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
    RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
    R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
    R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
    FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
     l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
     l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
     l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
     l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
     hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
     hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
     worker_thread+0x926/0xe70 kernel/workqueue.c:3416
     kthread+0x2e3/0x380 kernel/kthread.c:388
     ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
     </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 6ed58ec520ad ("Bluetooth: Use LE buffers for LE traffic")
    Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: amd-pstate: fix the highest frequency issue which limits performance [+ + +]
Author: Perry Yuan <perry.yuan@amd.com>
Date:   Wed May 8 13:47:03 2024 +0800

    cpufreq: amd-pstate: fix the highest frequency issue which limits performance
    
    commit bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 upstream.
    
    To address the performance drop issue, an optimization has been
    implemented. The incorrect highest performance value previously set by the
    low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID
    ranging from 0x70 to 0x7F series has been identified as the cause.
    
    To resolve this, a check has been implemented to accurately determine the
    CPU family and model ID. The correct highest performance value is now set
    and the performance drop caused by the incorrect highest performance value
    are eliminated.
    
    Before the fix, the highest frequency was set to 4200MHz, now it is set
    to 4971MHz which is correct.
    
    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
      0    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
      1    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
      2    0      0    1 1:1:1:0          yes 4971.0000 400.0000 4865.8140
      3    0      0    1 1:1:1:0          yes 4971.0000 400.0000  400.0000
    
    Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759
    Signed-off-by: Perry Yuan <perry.yuan@amd.com>
    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Tested-by: Gaha Bana <gahabana@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri May 3 11:03:14 2024 -0700

    Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file
    
    commit da2a061888883e067e8e649d086df35c92c760a7 upstream.
    
    The example usage of DAMOS filter sysfs files, specifically the part of
    'matching' file writing for memcg type filter, is wrong.  The intention is
    to exclude pages of a memcg that already getting enough care from a given
    scheme, but the example is setting the filter to apply the scheme to only
    the pages of the memcg.  Fix it.
    
    Link: https://lkml.kernel.org/r/20240503180318.72798-7-sj@kernel.org
    Fixes: 9b7f9322a530 ("Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs")
    Closes: https://lore.kernel.org/r/20240317191358.97578-1-sj@kernel.org
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.3.x]
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri May 3 11:03:15 2024 -0700

    Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command
    
    commit 14e70e4660d6ecaf503c461f072949ef8758e4a1 upstream.
    
    To update effective size quota of DAMOS schemes on DAMON sysfs file
    interface, user should write 'update_schemes_effective_quotas' to the
    kdamond 'state' file.  But the document is mistakenly saying the input
    string as 'update_schemes_effective_bytes'.  Fix it (s/bytes/quotas/).
    
    Link: https://lkml.kernel.org/r/20240503180318.72798-8-sj@kernel.org
    Fixes: a6068d6dfa2f ("Docs/admin-guide/mm/damon/usage: document effective_bytes file")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.9.x]
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
docs: kernel_include.py: Cope with docutils 0.21 [+ + +]
Author: Akira Yokosawa <akiyks@gmail.com>
Date:   Wed May 1 12:16:11 2024 +0900

    docs: kernel_include.py: Cope with docutils 0.21
    
    commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream.
    
    Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in
    a build error:
    
        Sphinx parallel build error:
        AttributeError: module 'docutils.nodes' has no attribute 'reprunicode'
    
    docutils 0.21 has removed nodes.reprunicode, quote from release note [1]:
    
      * Removed objects:
    
        docutils.nodes.reprunicode, docutils.nodes.ensure_str()
            Python 2 compatibility hacks
    
    Sphinx 7.3.0 supports docutils 0.21 [2]:
    
    kernel_include.py, whose origin is misc.py of docutils, uses reprunicode.
    
    Upstream docutils removed the offending line from the corresponding file
    (docutils/docutils/parsers/rst/directives/misc.py) in January 2022.
    Quoting the changelog [3]:
    
        Deprecate `nodes.reprunicode` and `nodes.ensure_str()`.
    
        Drop uses of the deprecated constructs (not required with Python 3).
    
    Do the same for kernel_include.py.
    
    Tested against:
      - Sphinx 2.4.5 (docutils 0.17.1)
      - Sphinx 3.4.3 (docutils 0.17.1)
      - Sphinx 5.3.0 (docutils 0.18.1)
      - Sphinx 6.2.1 (docutils 0.19)
      - Sphinx 7.2.6 (docutils 0.20.1)
      - Sphinx 7.3.7 (docutils 0.21.2)
    
    Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1]
    Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2]
    Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3]
    Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Fix division by zero in setup_dsc_config [+ + +]
Author: Jose Fernandez <josef@netflix.com>
Date:   Mon Apr 22 08:35:44 2024 -0600

    drm/amd/display: Fix division by zero in setup_dsc_config
    
    commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream.
    
    When slice_height is 0, the division by slice_height in the calculation
    of the number of slices will cause a division by zero driver crash. This
    leaves the kernel in a state that requires a reboot. This patch adds a
    check to avoid the division by zero.
    
    The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
    a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
    connected via Thunderbolt. The amdgpu driver crashed with this exception
    when I rebooted the system with the monitor connected.
    
    kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
    kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
    
    After applying this patch, the driver no longer crashes when the monitor
    is connected and the system is rebooted. I believe this is the same
    issue reported for 3113.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Jose Fernandez <josef@netflix.com>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <mario.limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KEYS: trusted: Do not use WARN when encode fails [+ + +]
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Mon May 13 21:19:04 2024 +0300

    KEYS: trusted: Do not use WARN when encode fails
    
    commit 050bf3c793a07f96bd1e2fd62e1447f731ed733b upstream.
    
    When asn1_encode_sequence() fails, WARN is not the correct solution.
    
    1. asn1_encode_sequence() is not an internal function (located
       in lib/asn1_encode.c).
    2. Location is known, which makes the stack trace useless.
    3. Results a crash if panic_on_warn is set.
    
    It is also noteworthy that the use of WARN is undocumented, and it
    should be avoided unless there is a carefully considered rationale to
    use it.
    
    Replace WARN with pr_err, and print the return value instead, which is
    only useful piece of information.
    
    Cc: stable@vger.kernel.org # v5.13+
    Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KEYS: trusted: Fix memory leak in tpm2_key_encode() [+ + +]
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Mon May 20 02:31:53 2024 +0300

    KEYS: trusted: Fix memory leak in tpm2_key_encode()
    
    commit ffcaa2172cc1a85ddb8b783de96d38ca8855e248 upstream.
    
    'scratch' is never freed. Fix this by calling kfree() in the success, and
    in the error case.
    
    Cc: stable@vger.kernel.org # +v5.13
    Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.9.2 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 25 16:30:56 2024 +0200

    Linux 6.9.2
    
    Link: https://lore.kernel.org/r/20240523130330.386580714@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Pascal Ernster <git@hardfalcon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ks8851: Fix another TX stall caused by wrong ISR flag handling [+ + +]
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Mon May 13 16:39:22 2024 +0200

    net: ks8851: Fix another TX stall caused by wrong ISR flag handling
    
    commit 317a215d493230da361028ea8a4675de334bfa1a upstream.
    
    Under some circumstances it may happen that the ks8851 Ethernet driver
    stops sending data.
    
    Currently the interrupt handler resets the interrupt status flags in the
    hardware after handling TX. With this approach we may lose interrupts in
    the time window between handling the TX interrupt and resetting the TX
    interrupt status bit.
    
    When all of the three following conditions are true then transmitting
    data stops:
    
      - TX queue is stopped to wait for room in the hardware TX buffer
      - no queued SKBs in the driver (txq) that wait for being written to hw
      - hardware TX buffer is empty and the last TX interrupt was lost
    
    This is because reenabling the TX queue happens when handling the TX
    interrupt status but if the TX status bit has already been cleared then
    this interrupt will never come.
    
    With this commit the interrupt status flags will be cleared before they
    are handled. That way we stop losing interrupts.
    
    The wrong handling of the ISR flags was there from the beginning but
    with commit 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX
    buffer overrun") the issue becomes apparent.
    
    Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Simon Horman <horms@kernel.org>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: ax88179_178a: fix link status when link is set to down/up [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Fri May 10 11:08:28 2024 +0200

    net: usb: ax88179_178a: fix link status when link is set to down/up
    
    commit ecf848eb934b03959918f5269f64c0e52bc23998 upstream.
    
    The idea was to keep only one reset at initialization stage in order to
    reduce the total delay, or the reset from usbnet_probe or the reset from
    usbnet_open.
    
    I have seen that restarting from usbnet_probe is necessary to avoid doing
    too complex things. But when the link is set to down/up (for example to
    configure a different mac address) the link is not correctly recovered
    unless a reset is commanded from usbnet_open.
    
    So, detect the initialization stage (first call) to not reset from
    usbnet_open after the reset from usbnet_probe and after this stage, always
    reset from usbnet_open too (when the link needs to be rechecked).
    
    Apply to all the possible devices, the behavior now is going to be the same.
    
    cc: stable@vger.kernel.org # 6.6+
    Fixes: 56f78615bcb1 ("net: usb: ax88179_178a: avoid writing the mac address before first reading")
    Reported-by: Isaac Ganoung <inventor500@vivaldi.net>
    Reported-by: Yongqin Liu <yongqin.liu@linaro.org>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240510090846.328201-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Mar 21 09:46:13 2024 +0100

    remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
    
    commit 331f91d86f71d0bb89a44217cc0b2a22810bbd42 upstream.
    
    The IPI buffer location is read from the firmware that we load to the
    System Companion Processor, and it's not granted that both the SRAM
    (L2TCM) size that is defined in the devicetree node is large enough
    for that, and while this is especially true for multi-core SCP, it's
    still useful to check on single-core variants as well.
    
    Failing to perform this check may make this driver perform R/W
    operations out of the L2TCM boundary, resulting (at best) in a
    kernel panic.
    
    To fix that, check that the IPI buffer fits, otherwise return a
    failure and refuse to boot the relevant SCP core (or the SCP at
    all, if this is single core).
    
    Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "media: v4l2-ctrls: show all owned controls in log_status" [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri May 10 09:11:46 2024 +0200

    Revert "media: v4l2-ctrls: show all owned controls in log_status"
    
    commit eba63df7eb1f95df6bfb67722a35372b6994928d upstream.
    
    This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739.
    
    This patch introduced a potential deadlock scenario:
    
    [Wed May  8 10:02:06 2024]  Possible unsafe locking scenario:
    
    [Wed May  8 10:02:06 2024]        CPU0                    CPU1
    [Wed May  8 10:02:06 2024]        ----                    ----
    [Wed May  8 10:02:06 2024]   lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);
    [Wed May  8 10:02:06 2024]                                lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);
    [Wed May  8 10:02:06 2024]                                lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);
    [Wed May  8 10:02:06 2024]   lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);
    
    For now just revert.
    
    Fixes: 9801b5b28c69 ("media: v4l2-ctrls: show all owned controls in log_status")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: kgdboc: Fix NMI-safety problems from keyboard reset code [+ + +]
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date:   Wed Apr 24 15:21:41 2024 +0100

    serial: kgdboc: Fix NMI-safety problems from keyboard reset code
    
    commit b2aba15ad6f908d1a620fd97f6af5620c3639742 upstream.
    
    Currently, when kdb is compiled with keyboard support, then we will use
    schedule_work() to provoke reset of the keyboard status.  Unfortunately
    schedule_work() gets called from the kgdboc post-debug-exception
    handler.  That risks deadlock since schedule_work() is not NMI-safe and,
    even on platforms where the NMI is not directly used for debugging, the
    debug trap can have NMI-like behaviour depending on where breakpoints
    are placed.
    
    Fix this by using the irq work system, which is NMI-safe, to defer the
    call to schedule_work() to a point when it is safe to call.
    
    Reported-by: Liuye <liu.yeC@h3c.com>
    Closes: https://lore.kernel.org/all/20240228025602.3087748-1-liu.yeC@h3c.com/
    Cc: stable@vger.kernel.org
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240424-kgdboc_fix_schedule_work-v2-1-50f5a490aec5@linaro.org
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: Wait unconditionally after issuing EndXfer command [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Thu May 2 10:11:03 2024 +0530

    usb: dwc3: Wait unconditionally after issuing EndXfer command
    
    commit 1d26ba0944d398f88aaf997bda3544646cf21945 upstream.
    
    Currently all controller IP/revisions except DWC3_usb3 >= 310a
    wait 1ms unconditionally for ENDXFER completion when IOC is not
    set. This is because DWC_usb3 controller revisions >= 3.10a
    supports GUCTL2[14: Rst_actbitlater] bit which allows polling
    CMDACT bit to know whether ENDXFER command is completed.
    
    Consider a case where an IN request was queued, and parallelly
    soft_disconnect was called (due to ffs_epfile_release). This
    eventually calls stop_active_transfer with IOC cleared, hence
    send_gadget_ep_cmd() skips waiting for CMDACT cleared during
    EndXfer. For DWC3 controllers with revisions >= 310a, we don't
    forcefully wait for 1ms either, and we proceed by unmapping the
    requests. If ENDXFER didn't complete by this time, it leads to
    SMMU faults since the controller would still be accessing those
    requests.
    
    Fix this by ensuring ENDXFER completion by adding 1ms delay in
    __dwc3_stop_active_transfer() unconditionally.
    
    Cc: stable@vger.kernel.org
    Fixes: b353eb6dc285 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer")
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240502044103.1066350-1-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tipd: fix event checking for tps25750 [+ + +]
Author: Javier Carrasco <javier.carrasco@wolfvision.net>
Date:   Mon Apr 29 15:35:57 2024 +0200

    usb: typec: tipd: fix event checking for tps25750
    
    commit d64adb0f41e62f91fcfdf0e0d9d5bfa714db0d23 upstream.
    
    In its current form, the interrupt service routine of the tps25750
    checks the event flags in the lowest 64 bits of the interrupt event
    register (event[0]), but also in the upper part (event[1]).
    
    Given that all flags are defined as BIT() or BIT_ULL(), they are
    restricted to the first 64 bits of the INT_EVENT1 register. Including
    the upper part of the register can lead to false positives e.g. if the
    event 64 bits above the one being checked is set, but the one being
    checked is not.
    
    Restrict the flag checking to the first 64 bits of the INT_EVENT1
    register.
    
    Fixes: 7e7a3c815d22 ("USB: typec: tps6598x: Add TPS25750 support")
    Cc: stable@vger.kernel.org
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
    Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-1-4e8e58dce489@wolfvision.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tipd: fix event checking for tps6598x [+ + +]
Author: Javier Carrasco <javier.carrasco@wolfvision.net>
Date:   Mon Apr 29 15:35:58 2024 +0200

    usb: typec: tipd: fix event checking for tps6598x
    
    commit 409c1cfb5a803f3cf2d17aeaf75c25c4be951b07 upstream.
    
    The current interrupt service routine of the tps6598x only reads the
    first 64 bits of the INT_EVENT1 and INT_EVENT2 registers, which means
    that any event above that range will be ignored, leaving interrupts
    unattended. Moreover, those events will not be cleared, and the device
    will keep the interrupt enabled.
    
    This issue has been observed while attempting to load patches, and the
    'ReadyForPatch' field (bit 81) of INT_EVENT1 was set.
    
    Given that older versions of the tps6598x (1, 2 and 6) provide 8-byte
    registers, a mechanism based on the upper byte of the version register
    (0x0F) has been included. The manufacturer has confirmed [1] that this
    byte is always 0 for older versions, and either 0xF7 (DH parts) or 0xF9
    (DK parts) is returned in newer versions (7 and 8).
    
    Read the complete INT_EVENT registers to handle all interrupts generated
    by the device and account for the hardware version to select the
    register size.
    
    Link: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1346521/tps65987d-register-command-to-distinguish-between-tps6591-2-6-and-tps65987-8 [1]
    Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
    Cc: stable@vger.kernel.org
    Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
    Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-2-4e8e58dce489@wolfvision.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: displayport: Fix potential deadlock [+ + +]
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue May 7 16:43:16 2024 +0300

    usb: typec: ucsi: displayport: Fix potential deadlock
    
    commit b791a67f68121d69108640d4a3e591d210ffe850 upstream.
    
    The function ucsi_displayport_work() does not access the
    connector, so it also must not acquire the connector lock.
    
    This fixes a potential deadlock scenario:
    
    ucsi_displayport_work() -> lock(&con->lock)
    typec_altmode_vdm()
    dp_altmode_vdm()
    dp_altmode_work()
    typec_altmode_enter()
    ucsi_displayport_enter() -> lock(&con->lock)
    
    Reported-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240507134316.161999-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: iwlwifi: Use request_module_nowait [+ + +]
Author: Ben Greear <greearb@candelatech.com>
Date:   Tue Apr 30 16:42:12 2024 -0700

    wifi: iwlwifi: Use request_module_nowait
    
    commit 3d913719df14c28c4d3819e7e6d150760222bda4 upstream.
    
    This appears to work around a deadlock regression that came in
    with the LED merge in 6.9.
    
    The deadlock happens on my system with 24 iwlwifi radios, so maybe
    it something like all worker threads are busy and some work that needs
    to complete cannot complete.
    
    Link: https://lore.kernel.org/linux-kernel/20240411070718.GD6194@google.com/
    Fixes: f5c31bcf604d ("Merge tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds")
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Link: https://msgid.link/20240430234212.2132958-1-greearb@candelatech.com
    [also remove unnecessary "load_module" var and now-wrong comment]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/percpu: Use __force to cast from __percpu address space [+ + +]
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Tue Apr 2 19:50:38 2024 +0200

    x86/percpu: Use __force to cast from __percpu address space
    
    commit a55c1fdad5f61b4bfe42319694b23671a758cb28 upstream.
    
    Fix Sparse warning when casting from __percpu address space by using
    __force in the cast. x86 named address spaces are not considered to
    be subspaces of the generic (flat) address space, so explicit casts
    are required to convert pointers between these address spaces and the
    generic address space (the application should cast to uintptr_t and
    apply the segment base offset). The cast to uintptr_t removes
    __percpu address space tag and Sparse reports:
    
      warning: cast removes address space '__percpu' of expression
    
    Use __force to inform Sparse that the cast is intentional.
    
    Fixes: 9a462b9eafa6 ("x86/percpu: Use compiler segment prefix qualifier")
    Reported-by: Charlemagne Lasse <charlemagnelasse@gmail.com>
    Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240402175058.52649-1-ubizjak@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Closes: https://lore.kernel.org/lkml/CAFGhKbzev7W4aHwhFPWwMZQEHenVgZUj7=aunFieVqZg3mt14A@mail.gmail.com/