commit 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 8 11:24:08 2022 +0200

    Linux 5.19.8
    
    Link: https://lore.kernel.org/r/20220906132829.417117002@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Zan Aziz <zanaziz313@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>=20
    Tested-by: Jiri Slaby <jirislaby@kernel.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 132331c1f605eb5911795a6b9115114575594d0a
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Aug 29 16:16:40 2022 +0300

    tty: n_gsm: avoid call of sleeping functions from atomic context
    
    commit 902e02ea9385373ce4b142576eef41c642703955 upstream.
    
    Syzkaller reports the following problem:
    
    BUG: sleeping function called from invalid context at kernel/printk/printk.c:2347
    in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1105, name: syz-executor423
    3 locks held by syz-executor423/1105:
     #0: ffff8881468b9098 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x22/0x90 drivers/tty/tty_ldisc.c:266
     #1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: tty_write_lock drivers/tty/tty_io.c:952 [inline]
     #1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: do_tty_write drivers/tty/tty_io.c:975 [inline]
     #1: ffff8881468b9130 (&tty->atomic_write_lock){+.+.}-{3:3}, at: file_tty_write.constprop.0+0x2a8/0x8e0 drivers/tty/tty_io.c:1118
     #2: ffff88801b06c398 (&gsm->tx_lock){....}-{2:2}, at: gsmld_write+0x5e/0x150 drivers/tty/n_gsm.c:2717
    irq event stamp: 3482
    hardirqs last  enabled at (3481): [<ffffffff81d13343>] __get_reqs_available+0x143/0x2f0 fs/aio.c:946
    hardirqs last disabled at (3482): [<ffffffff87d39722>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
    hardirqs last disabled at (3482): [<ffffffff87d39722>] _raw_spin_lock_irqsave+0x52/0x60 kernel/locking/spinlock.c:159
    softirqs last  enabled at (3408): [<ffffffff87e01002>] asm_call_irq_on_stack+0x12/0x20
    softirqs last disabled at (3401): [<ffffffff87e01002>] asm_call_irq_on_stack+0x12/0x20
    Preemption disabled at:
    [<0000000000000000>] 0x0
    CPU: 2 PID: 1105 Comm: syz-executor423 Not tainted 5.10.137-syzkaller #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x107/0x167 lib/dump_stack.c:118
     ___might_sleep.cold+0x1e8/0x22e kernel/sched/core.c:7304
     console_lock+0x19/0x80 kernel/printk/printk.c:2347
     do_con_write+0x113/0x1de0 drivers/tty/vt/vt.c:2909
     con_write+0x22/0xc0 drivers/tty/vt/vt.c:3296
     gsmld_write+0xd0/0x150 drivers/tty/n_gsm.c:2720
     do_tty_write drivers/tty/tty_io.c:1028 [inline]
     file_tty_write.constprop.0+0x502/0x8e0 drivers/tty/tty_io.c:1118
     call_write_iter include/linux/fs.h:1903 [inline]
     aio_write+0x355/0x7b0 fs/aio.c:1580
     __io_submit_one fs/aio.c:1952 [inline]
     io_submit_one+0xf45/0x1a90 fs/aio.c:1999
     __do_sys_io_submit fs/aio.c:2058 [inline]
     __se_sys_io_submit fs/aio.c:2028 [inline]
     __x64_sys_io_submit+0x18c/0x2f0 fs/aio.c:2028
     do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    The problem happens in the following control flow:
    
    gsmld_write(...)
    spin_lock_irqsave(&gsm->tx_lock, flags) // taken a spinlock on TX data
     con_write(...)
      do_con_write(...)
       console_lock()
        might_sleep() // -> bug
    
    As far as console_lock() might sleep it should not be called with
    spinlock held.
    
    The patch replaces tx_lock spinlock with mutex in order to avoid the
    problem.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 32dd59f96924 ("tty: n_gsm: fix race condition in gsmld_write()")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Link: https://lore.kernel.org/r/20220829131640.69254-3-pchelkin@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2af54fe4f713d5f29e1520d7780112ff9b6121be
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Aug 29 16:16:39 2022 +0300

    tty: n_gsm: replace kicktimer with delayed_work
    
    commit c9ab053e56ce13a949977398c8edc12e6c02fc95 upstream.
    
    A kick_timer timer_list is replaced with kick_timeout delayed_work to be
    able to synchronize with mutexes as a prerequisite for the introduction
    of tx_mutex.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: c568f7086c6e ("tty: n_gsm: fix missing timer to handle stalled links")
    Cc: stable <stable@kernel.org>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Suggested-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Link: https://lore.kernel.org/r/20220829131640.69254-2-pchelkin@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55f799f2c34a4f0731ce58466b1a84aef24b06bc
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sat Aug 27 22:47:19 2022 +0900

    tty: n_gsm: initialize more members at gsm_alloc_mux()
    
    commit 4bb1a53be85fcb1e24c14860e326a00cdd362c28 upstream.
    
    syzbot is reporting use of uninitialized spinlock at gsmld_write() [1], for
    commit 32dd59f96924f45e ("tty: n_gsm: fix race condition in gsmld_write()")
    allows accessing gsm->tx_lock before gsm_activate_mux() initializes it.
    
    Since object initialization should be done right after allocation in order
    to avoid accessing uninitialized memory, move initialization of
    timer/work/waitqueue/spinlock from gsmld_open()/gsm_activate_mux() to
    gsm_alloc_mux().
    
    Link: https://syzkaller.appspot.com/bug?extid=cf155def4e717db68a12 [1]
    Fixes: 32dd59f96924f45e ("tty: n_gsm: fix race condition in gsmld_write()")
    Reported-by: syzbot <syzbot+cf155def4e717db68a12@syzkaller.appspotmail.com>
    Tested-by: syzbot <syzbot+cf155def4e717db68a12@syzkaller.appspotmail.com>
    Cc: stable <stable@kernel.org>
    Acked-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Link: https://lore.kernel.org/r/2110618e-57f0-c1ce-b2ad-b6cacef3f60e@I-love.SAKURA.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5aa37f9510345a812c0998bcbbc4d88d1dcc4d8b
Author: Mazin Al Haddad <mazinalhaddad05@gmail.com>
Date:   Sun Aug 14 04:52:12 2022 +0300

    tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()
    
    commit f16c6d2e58a4c2b972efcf9eb12390ee0ba3befb upstream.
    
    A null pointer dereference can happen when attempting to access the
    "gsm->receive()" function in gsmld_receive_buf(). Currently, the code
    assumes that gsm->recieve is only called after MUX activation.
    Since the gsmld_receive_buf() function can be accessed without the need to
    initialize the MUX, the gsm->receive() function will not be set and a
    NULL pointer dereference will occur.
    
    Fix this by avoiding the call to "gsm->receive()" in case the function is
    not initialized by adding a sanity check.
    
    Call Trace:
     <TASK>
     gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861
     tiocsti drivers/tty/tty_io.c:2293 [inline]
     tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:870 [inline]
     __se_sys_ioctl fs/ioctl.c:856 [inline]
     __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Link: https://syzkaller.appspot.com/bug?id=bdf035c61447f8c6e0e6920315d577cb5cc35ac5
    Fixes: 01aecd917114 ("tty: n_gsm: fix tty registration before control channel open")
    Cc: stable <stable@kernel.org>
    Reported-and-tested-by: syzbot+e3563f0c94e188366dbb@syzkaller.appspotmail.com
    Signed-off-by: Mazin Al Haddad <mazinalhaddad05@gmail.com>
    Link: https://lore.kernel.org/r/20220814015211.84180-1-mazinalhaddad05@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c5bdf735443df04ad2e416742e45002b064f81
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jun 17 22:59:48 2022 +0300

    drm/i915: Skip wm/ddb readout for disabled pipes
    
    commit 0211c2a0ea600e25db3044daaeff4fe41c3ed6d9 upstream.
    
    The stuff programmed into the wm/ddb registers of planes
    on disabled pipes doesn't matter. So during readout just
    leave our software state tracking for those zeroed.
    
    This should avoid us trying too hard to clean up after
    whatever mess the VBIOS/GOP left in there. The actual
    hardware state will get cleaned up if/when we enable
    the pipe anyway.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5711
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220617195948.24007-1-ville.syrjala@linux.intel.com
    Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
    (cherry picked from commit b183db8f4783ca2efc9b47734f15aad9477a108a)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 747a192e46746f0a80ad24ebabed19dabc2a33fb
Author: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Date:   Thu Jun 16 15:41:37 2022 +0300

    drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk
    
    commit 919bef7a106ade2bda73681bbc2f3678198f44fc upstream.
    
    The quirk added in upstream commit 90c3e2198777 ("drm/i915/glk: Add
    Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
    Q2.
    
    Note: Would be nicer to figure out the extra delay required for the
    retimer without quirks, however don't know how to check for that.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1326
    Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220616124137.3184371-1-jani.nikula@intel.com
    (cherry picked from commit 08e9505fa8f9aa00072a47b6f234d89b6b27a89c)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dd7a8e7a044757a96f92abb473e35e4209258ca
Author: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Date:   Thu Aug 11 14:08:12 2022 -0700

    drm/i915/guc: clear stalled request after a reset
    
    commit 4595a25443447b9542b2a5ee7961eb290e94b496 upstream.
    
    If the GuC CTs are full and we need to stall the request submission
    while waiting for space, we save the stalled request and where the stall
    occurred; when the CTs have space again we pick up the request submission
    from where we left off.
    
    If a full GT reset occurs, the state of all contexts is cleared and all
    non-guilty requests are unsubmitted, therefore we need to restart the
    stalled request submission from scratch. To make sure that we do so,
    clear the saved request after a reset.
    
    Fixes note: the patch that introduced the bug is in 5.15, but no
    officially supported platform had GuC submission enabled by default
    in that kernel, so the backport to that particular version (and only
    that one) can potentially be skipped.
    
    Fixes: 925dc1cf58ed ("drm/i915/guc: Implement GuC submission tasklet")
    Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
    Cc: Matthew Brost <matthew.brost@intel.com>
    Cc: John Harrison <john.c.harrison@intel.com>
    Cc: <stable@vger.kernel.org> # v5.15+
    Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220811210812.3239621-1-daniele.ceraolospurio@intel.com
    (cherry picked from commit f922fbb0f2ad1fd3e3186f39c46673419e6d9281)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cde8745d15e6a807bc89f031f9286ee4d562eee
Author: Jouni Högander <jouni.hogander@intel.com>
Date:   Mon Aug 22 17:08:36 2022 +0300

    drm/i915/backlight: Disable pps power hook for aux based backlight
    
    commit 51fbbe8a3f8b9dd128fa98f6ea36058dfa3f36de upstream.
    
    Pps power hook seems to be problematic for backlight controlled via
    aux channel. Disable it for such cases.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3657
    Cc: stable@vger.kernel.org
    Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220822140836.534432-1-jouni.hogander@intel.com
    (cherry picked from commit 869e3bb7acb59d88c1226892136661810e8223a4)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a26889698d86dd0e76acbafa490c6582f88cba1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 23 09:27:17 2022 +0200

    ALSA: seq: Fix data-race at module auto-loading
    
    commit 3e7e04b747adea36f349715d9f0998eeebf15d72 upstream.
    
    It's been reported that there is a possible data-race accessing to the
    global card_requested[] array at ALSA sequencer core, which is used
    for determining whether to call request_module() for the card or not.
    This data race itself is almost harmless, as it might end up with one
    extra request_module() call for the already loaded module at most.
    But it's still better to fix.
    
    This patch addresses the possible data race of card_requested[] and
    client_requested[] arrays by replacing them with bitmask.
    It's an atomic operation and can work without locks.
    
    Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
    Link: https://lore.kernel.org/r/20220823072717.1706-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54b8252562e99e767ff6ab1db2bedc56e1b3eb54
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 23 09:27:16 2022 +0200

    ALSA: seq: oss: Fix data-race for max_midi_devs access
    
    commit 22dec134dbfa825b963f8a1807ad19b943e46a56 upstream.
    
    ALSA OSS sequencer refers to a global variable max_midi_devs at
    creating a new port, storing it to its own field.  Meanwhile this
    variable may be changed by other sequencer events at
    snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data
    race.
    
    OTOH, this data race itself is almost harmless, as the access to the
    MIDI device is done via get_mdev() and it's protected with a refcount,
    hence its presence is guaranteed.
    
    Though, it's sill better to address the data-race from the code sanity
    POV, and this patch adds the proper spinlock for the protection.
    
    Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg@mail.gmail.com
    Link: https://lore.kernel.org/r/20220823072717.1706-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0dfc4412e61da17ba3845e3c619cc1d5f316780
Author: Kacper Michajłow <kasper93@gmail.com>
Date:   Sat Aug 27 22:33:28 2022 +0200

    ALSA: hda/realtek: Add speaker AMP init for Samsung laptops with ALC298
    
    commit a2d57ebec1e15f0ac256eb8397e82b07adfaaacc upstream.
    
    Magic initialization sequence was extracted from Windows driver and
    cleaned up manually.
    
    Fixes internal speakers output.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=207423
    Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518
    Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220827203328.30363-1-kasper93@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2473382f79f44501d4472e61dc3c343e2880efe1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Aug 21 17:59:11 2022 +0200

    ALSA: memalloc: Revive x86-specific WC page allocations again
    
    commit a8d302a0b77057568350fe0123e639d02dba0745 upstream.
    
    We dropped the x86-specific hack for WC-page allocations with a hope
    that the standard dma_alloc_wc() works nowadays.  Alas, it doesn't,
    and we need to take back some workaround again, but in a different
    form, as the previous one was broken for some platforms.
    
    This patch re-introduces the x86-specific WC-page allocations, but it
    uses rather the manual page allocations instead of
    dma_alloc_coherent().  The use of dma_alloc_coherent() was also a
    potential problem in the recent addition of the fallback allocation
    for noncontig pages, and this patch eliminates both at once.
    
    Fixes: 9882d63bea14 ("ALSA: memalloc: Drop x86-specific hack for WC allocations")
    Cc: <stable@vger.kernel.org>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216363
    Link: https://lore.kernel.org/r/20220821155911.10715-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05d101e27cfdff58c2e2b0ebbe0fcd5de565e608
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Fri Aug 26 16:29:54 2022 +0200

    net: mac802154: Fix a condition in the receive path
    
    commit f0da47118c7e93cdbbc6fb403dd729a5f2c90ee3 upstream.
    
    Upon reception, a packet must be categorized, either it's destination is
    the host, or it is another host. A packet with no destination addressing
    fields may be valid in two situations:
    - the packet has no source field: only ACKs are built like that, we
      consider the host as the destination.
    - the packet has a valid source field: it is directed to the PAN
      coordinator, as for know we don't have this information we consider we
      are not the PAN coordinator.
    
    There was likely a copy/paste error made during a previous cleanup
    because the if clause is now containing exactly the same condition as in
    the switch case, which can never be true. In the past the destination
    address was used in the switch and the source address was used in the
    if, which matches what the spec says.
    
    Cc: stable@vger.kernel.org
    Fixes: ae531b9475f6 ("ieee802154: use ieee802154_addr instead of *_sa variants")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20220826142954.254853-1-miquel.raynal@bootlin.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89b1ca91677fc2d1597edf9591999fd4f6a88a7a
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Thu Aug 25 13:36:45 2022 +0200

    net: Use u64_stats_fetch_begin_irq() for stats fetch.
    
    commit 278d3ba61563ceed3cb248383ced19e14ec7bc1f upstream.
    
    On 32bit-UP u64_stats_fetch_begin() disables only preemption. If the
    reader is in preemptible context and the writer side
    (u64_stats_update_begin*()) runs in an interrupt context (IRQ or
    softirq) then the writer can update the stats during the read operation.
    This update remains undetected.
    
    Use u64_stats_fetch_begin_irq() to ensure the stats fetch on 32bit-UP
    are not interrupted by a writer. 32bit-SMP remains unaffected by this
    change.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Catherine Sullivan <csully@google.com>
    Cc: David Awogbemila <awogbemila@google.com>
    Cc: Dimitris Michailidis <dmichail@fungible.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Jeroen de Borst <jeroendb@google.com>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Simon Horman <simon.horman@corigine.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-wireless@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: oss-drivers@corigine.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df93a4b439ee74fbd28b15e33ee0391bd88e762d
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Mon Aug 29 12:01:21 2022 +0200

    ip: fix triggering of 'icmp redirect'
    
    commit eb55dc09b5dd040232d5de32812cc83001a23da6 upstream.
    
    __mkroute_input() uses fib_validate_source() to trigger an icmp redirect.
    My understanding is that fib_validate_source() is used to know if the src
    address and the gateway address are on the same link. For that,
    fib_validate_source() returns 1 (same link) or 0 (not the same network).
    __mkroute_input() is the only user of these positive values, all other
    callers only look if the returned value is negative.
    
    Since the below patch, fib_validate_source() didn't return anymore 1 when
    both addresses are on the same network, because the route lookup returns
    RT_SCOPE_LINK instead of RT_SCOPE_HOST. But this is, in fact, right.
    Let's adapat the test to return 1 again when both addresses are on the same
    link.
    
    CC: stable@vger.kernel.org
    Fixes: 747c14307214 ("ip: fix dflt addr selection for connected nexthop")
    Reported-by: kernel test robot <yujie.liu@intel.com>
    Reported-by: Heng Qi <hengqi@linux.alibaba.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20220829100121.3821-1-nicolas.dichtel@6wind.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0445feb80a4d0854898118fa01073701f8d356b
Author: Siddh Raman Pant <code@siddh.me>
Date:   Sat Aug 20 01:33:40 2022 +0530

    wifi: mac80211: Fix UAF in ieee80211_scan_rx()
    
    commit 60deb9f10eec5c6a20252ed36238b55d8b614a2c upstream.
    
    ieee80211_scan_rx() tries to access scan_req->flags after a
    null check, but a UAF is observed when the scan is completed
    and __ieee80211_scan_completed() executes, which then calls
    cfg80211_scan_done() leading to the freeing of scan_req.
    
    Since scan_req is rcu_dereference()'d, prevent the racing in
    __ieee80211_scan_completed() by ensuring that from mac80211's
    POV it is no longer accessed from an RCU read critical section
    before we call cfg80211_scan_done().
    
    Cc: stable@vger.kernel.org
    Link: https://syzkaller.appspot.com/bug?extid=f9acff9bf08a845f225d
    Reported-by: syzbot+f9acff9bf08a845f225d@syzkaller.appspotmail.com
    Suggested-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Siddh Raman Pant <code@siddh.me>
    Link: https://lore.kernel.org/r/20220819200340.34826-1-code@siddh.me
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 864e280cb3a9a0f5212b16ef5057c4e692f7039d
Author: Siddh Raman Pant <code@siddh.me>
Date:   Sun Aug 14 20:45:12 2022 +0530

    wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected
    
    commit 15bc8966b6d3a5b9bfe4c9facfa02f2b69b1e5f0 upstream.
    
    When we are not connected to a channel, sending channel "switch"
    announcement doesn't make any sense.
    
    The BSS list is empty in that case. This causes the for loop in
    cfg80211_get_bss() to be bypassed, so the function returns NULL
    (check line 1424 of net/wireless/scan.c), causing the WARN_ON()
    in ieee80211_ibss_csa_beacon() to get triggered (check line 500
    of net/mac80211/ibss.c), which was consequently reported on the
    syzkaller dashboard.
    
    Thus, check if we have an existing connection before generating
    the CSA beacon in ieee80211_ibss_finish_csa().
    
    Cc: stable@vger.kernel.org
    Fixes: cd7760e62c2a ("mac80211: add support for CSA in IBSS mode")
    Link: https://syzkaller.appspot.com/bug?id=05603ef4ae8926761b678d2939a3b2ad28ab9ca6
    Reported-by: syzbot+b6c9fe29aefe68e4ad34@syzkaller.appspotmail.com
    Signed-off-by: Siddh Raman Pant <code@siddh.me>
    Tested-by: syzbot+b6c9fe29aefe68e4ad34@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20220814151512.9985-1-code@siddh.me
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4c5cc34976883e2b16b2bfdec70c8d33238a20f
Author: Isaac J. Manjarres <isaacmanjarres@google.com>
Date:   Wed Aug 17 11:40:26 2022 -0700

    driver core: Don't probe devices after bus_type.match() probe deferral
    
    commit 25e9fbf0fd38868a429feabc38abebfc6dbf6542 upstream.
    
    Both __device_attach_driver() and __driver_attach() check the return
    code of the bus_type.match() function to see if the device needs to be
    added to the deferred probe list. After adding the device to the list,
    the logic attempts to bind the device to the driver anyway, as if the
    device had matched with the driver, which is not correct.
    
    If __device_attach_driver() detects that the device in question is not
    ready to match with a driver on the bus, then it doesn't make sense for
    the device to attempt to bind with the current driver or continue
    attempting to match with any of the other drivers on the bus. So, update
    the logic in __device_attach_driver() to reflect this.
    
    If __driver_attach() detects that a driver tried to match with a device
    that is not ready to match yet, then the driver should not attempt to bind
    with the device. However, the driver can still attempt to match and bind
    with other devices on the bus, as drivers can be bound to multiple
    devices. So, update the logic in __driver_attach() to reflect this.
    
    Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
    Cc: stable@vger.kernel.org
    Cc: Saravana Kannan <saravanak@google.com>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
    Link: https://lore.kernel.org/r/20220817184026.3468620-1-isaacmanjarres@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 731f903c56eaaea6faf4dbae88e1b4a61ed20a2a
Author: Levi Yun <ppbuk5246@gmail.com>
Date:   Wed Aug 31 19:39:13 2022 +0900

    arm64/kexec: Fix missing extra range for crashkres_low.
    
    commit 4831be702b95047c89b3fa5728d07091e9e9f7c9 upstream.
    
    Like crashk_res, Calling crash_exclude_mem_range function with
    crashk_low_res area would need extra crash_mem range too.
    
    Add one more extra cmem slot in case of crashk_low_res is used.
    
    Signed-off-by: Levi Yun <ppbuk5246@gmail.com>
    Fixes: 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
    Cc: <stable@vger.kernel.org> # 5.19.x
    Acked-by: Baoquan He <bhe@redhat.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Link: https://lore.kernel.org/r/20220831103913.12661-1-ppbuk5246@gmail.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c798fe98adceb642050819cb57cbc8f5c27870
Author: Christian König <ckoenig.leichtzumerken@gmail.com>
Date:   Wed Aug 10 19:26:17 2022 +0200

    dma-buf/dma-resv: check if the new fence is really later
    
    commit a3f7c10a269d5b77dd5822ade822643ced3057f0 upstream.
    
    Previously when we added a fence to a dma_resv object we always
    assumed the the newer than all the existing fences.
    
    With Jason's work to add an UAPI to explicit export/import that's not
    necessary the case any more. So without this check we would allow
    userspace to force the kernel into an use after free error.
    
    Since the change is very small and defensive it's probably a good
    idea to backport this to stable kernels as well just in case others
    are using the dma_resv object in the same way.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220810172617.140047-1-christian.koenig@amd.com
    Cc: stable@vger.kernel.org # v5.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a065e4673cbdd9f222a05f85e17d78ea50c8d9c
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 26 15:31:17 2022 -0400

    USB: gadget: Fix obscure lockdep violation for udc_mutex
    
    commit 1016fc0c096c92dd0e6e0541daac7a7868169903 upstream.
    
    A recent commit expanding the scope of the udc_lock mutex in the
    gadget core managed to cause an obscure and slightly bizarre lockdep
    violation.  In abbreviated form:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    5.19.0-rc7+ #12510 Not tainted
    ------------------------------------------------------
    udevadm/312 is trying to acquire lock:
    ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0
    
    but task is already holding lock:
    ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #3 (kn->active#4){++++}-{0:0}:
            lock_acquire+0x68/0x84
            __kernfs_remove+0x268/0x380
            kernfs_remove_by_name_ns+0x58/0xac
            sysfs_remove_file_ns+0x18/0x24
            device_del+0x15c/0x440
    
    -> #2 (device_links_lock){+.+.}-{3:3}:
            lock_acquire+0x68/0x84
            __mutex_lock+0x9c/0x430
            mutex_lock_nested+0x38/0x64
            device_link_remove+0x3c/0xa0
            _regulator_put.part.0+0x168/0x190
            regulator_put+0x3c/0x54
            devm_regulator_release+0x14/0x20
    
    -> #1 (regulator_list_mutex){+.+.}-{3:3}:
            lock_acquire+0x68/0x84
            __mutex_lock+0x9c/0x430
            mutex_lock_nested+0x38/0x64
            regulator_lock_dependent+0x54/0x284
            regulator_enable+0x34/0x80
            phy_power_on+0x24/0x130
            __dwc2_lowlevel_hw_enable+0x100/0x130
            dwc2_lowlevel_hw_enable+0x18/0x40
            dwc2_hsotg_udc_start+0x6c/0x2f0
            gadget_bind_driver+0x124/0x1f4
    
    -> #0 (udc_lock){+.+.}-{3:3}:
            __lock_acquire+0x1298/0x20cc
            lock_acquire.part.0+0xe0/0x230
            lock_acquire+0x68/0x84
            __mutex_lock+0x9c/0x430
            mutex_lock_nested+0x38/0x64
            usb_udc_uevent+0x54/0xe0
    
    Evidently this was caused by the scope of udc_mutex being too large.
    The mutex is only meant to protect udc->driver along with a few other
    things.  As far as I can tell, there's no reason for the mutex to be
    held while the gadget core calls a gadget driver's ->bind or ->unbind
    routine, or while a UDC is being started or stopped.  (This accounts
    for link #1 in the chain above, where the mutex is held while the
    dwc2_hsotg_udc is started as part of driver probing.)
    
    Gadget drivers' ->disconnect callbacks are problematic.  Even though
    usb_gadget_disconnect() will now acquire the udc_mutex, there's a
    window in usb_gadget_bind_driver() between the times when the mutex is
    released and the ->bind callback is invoked.  If a disconnect occurred
    during that window, we could call the driver's ->disconnect routine
    before its ->bind routine.  To prevent this from happening, it will be
    necessary to prevent a UDC from connecting while it has no gadget
    driver.  This should be done already but it doesn't seem to be;
    currently usb_gadget_connect() has no check for this.  Such a check
    will have to be added later.
    
    Some degree of mutual exclusion is required in soft_connect_store(),
    which can dereference udc->driver at arbitrary times since it is a
    sysfs callback.  The solution here is to acquire the gadget's device
    lock rather than the udc_mutex.  Since the driver core guarantees that
    the device lock is always held during driver binding and unbinding,
    this will make the accesses in soft_connect_store() mutually exclusive
    with any changes to udc->driver.
    
    Lastly, it turns out there is one place which should hold the
    udc_mutex but currently does not: The function_show() routine needs
    protection while it dereferences udc->driver.  The missing lock and
    unlock calls are added.
    
    Link: https://lore.kernel.org/all/b2ba4245-9917-e399-94c8-03a383e7070e@samsung.com/
    Fixes: 2191c00855b0 ("USB: gadget: Fix use-after-free Read in usb_udc_uevent()")
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: stable@vger.kernel.org
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/YwkfhdxA/I2nOcK7@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdaac12bb135d70e915982dd7a81da0832760ee4
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Sat Aug 27 08:45:10 2022 +0530

    usb: gadget: mass_storage: Fix cdrom data transfers on MAC-OS
    
    commit 9d4dc16ec71bd6368548e9743223e449b4377fc7 upstream.
    
    During cdrom emulation, the response to read_toc command must contain
    the cdrom address as the number of sectors (2048 byte sized blocks)
    represented either as an absolute value (when MSF bit is '0') or in
    terms of PMin/PSec/PFrame (when MSF bit is set to '1'). Incase of
    cdrom, the fsg_lun_open call sets the sector size to 2048 bytes.
    
    When MAC OS sends a read_toc request with MSF set to '1', the
    store_cdrom_address assumes that the address being provided is the
    LUN size represented in 512 byte sized blocks instead of 2048. It
    tries to modify the address further to convert it to 2048 byte sized
    blocks and store it in MSF format. This results in data transfer
    failures as the cdrom address being provided in the read_toc response
    is incorrect.
    
    Fixes: 3f565a363cee ("usb: gadget: storage: adapt logic block size to bound block devices")
    Cc: stable@vger.kernel.org
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Link: https://lore.kernel.org/r/1661570110-19127-1-git-send-email-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e78ca7f51ac5a026088670c3c52194d5b89996c1
Author: Jing Leng <jleng@ambarella.com>
Date:   Wed Jul 20 18:48:15 2022 -0700

    usb: gadget: f_uac2: fix superspeed transfer
    
    commit f511aef2ebe5377d4c263842f2e0c0b8e274e8e5 upstream.
    
    On page 362 of the USB3.2 specification (
    https://usb.org/sites/default/files/usb_32_20210125.zip),
    The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned
    by Enhanced SuperSpeed devices that are operating at Gen X speed.
    Each endpoint described in an interface is followed by a 'SuperSpeed
    Endpoint Companion Descriptor'.
    
    If users use SuperSpeed UDC, host can't recognize the device if endpoint
    doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed.
    
    Currently in the uac2 driver code:
    1. ss_epout_desc_comp follows ss_epout_desc;
    2. ss_epin_fback_desc_comp follows ss_epin_fback_desc;
    3. ss_epin_desc_comp follows ss_epin_desc;
    4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint
    Companion Descriptor' followed, so we should add it.
    
    Fixes: eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Jing Leng <jleng@ambarella.com>
    Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
    Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cf44c63bc1b07b9ec02548e50c094f6b1dfee29
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Fri Aug 19 16:05:56 2022 +0800

    usb: xhci-mtk: fix bandwidth release issue
    
    commit 6020f480004a80cdad4ae5ee180a231c4f65595b upstream.
    
    This happens when @udev->reset_resume is set to true, when usb resume,
    the flow as below:
      - hub_resume
        - usb_disable_interface
          - usb_disable_endpoint
            - usb_hcd_disable_endpoint
              - xhci_endpoint_disable  // it set @ep->hcpriv to NULL
    
    Then when reset usb device, it will drop allocated endpoints,
    the flow as below:
      - usb_reset_and_verify_device
        - usb_hcd_alloc_bandwidth
          - xhci_mtk_drop_ep
    
    but @ep->hcpriv is already set to NULL, the bandwidth will be not
    released anymore.
    
    Due to the added endponts are stored in hash table, we can drop the check
    of @ep->hcpriv.
    
    Fixes: 4ce186665e7c ("usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/20220819080556.32215-2-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 283a781b97547aea1c6f838557900ef498e9bcdc
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Fri Aug 19 16:05:55 2022 +0800

    usb: xhci-mtk: relax TT periodic bandwidth allocation
    
    commit 8b13ea05117ffad4727b0971ed09122d5c91c4dc upstream.
    
    Currently uses the worst case byte budgets on FS/LS bus bandwidth,
    for example, for an isochronos IN endpoint with 192 bytes budget, it
    will consume the whole 5 uframes(188 * 5) while the actual FS bus
    budget should be just 192 bytes. It cause that many usb audio headsets
    with 3 interfaces (audio input, audio output, and HID) cannot be
    configured.
    To improve it, changes to use "approximate" best case budget for FS/LS
    bandwidth management. For the same endpoint from the above example,
    the approximate best case budget is now reduced to (188 * 2) bytes.
    
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20220819080556.32215-1-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5eb850b3e8836197a38475840725260b9783e94
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 26 15:31:32 2022 -0400

    USB: core: Prevent nested device-reset calls
    
    commit 9c6d778800b921bde3bff3cff5003d1650f942d1 upstream.
    
    Automatic kernel fuzzing revealed a recursive locking violation in
    usb-storage:
    
    ============================================
    WARNING: possible recursive locking detected
    5.18.0 #3 Not tainted
    --------------------------------------------
    kworker/1:3/1205 is trying to acquire lock:
    ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
    usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
    
    but task is already holding lock:
    ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
    usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
    
    ...
    
    stack backtrace:
    CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.13.0-1ubuntu1.1 04/01/2014
    Workqueue: usb_hub_wq hub_event
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
    print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
    check_deadlock kernel/locking/lockdep.c:3031 [inline]
    validate_chain kernel/locking/lockdep.c:3816 [inline]
    __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
    lock_acquire kernel/locking/lockdep.c:5665 [inline]
    lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
    __mutex_lock_common kernel/locking/mutex.c:603 [inline]
    __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
    usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
    usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
    r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
    usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
    device_remove drivers/base/dd.c:545 [inline]
    device_remove+0x11f/0x170 drivers/base/dd.c:537
    __device_release_driver drivers/base/dd.c:1222 [inline]
    device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
    usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
    usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
    usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114
    
    This turned out not to be an error in usb-storage but rather a nested
    device reset attempt.  That is, as the rtl8712 driver was being
    unbound from a composite device in preparation for an unrelated USB
    reset (that driver does not have pre_reset or post_reset callbacks),
    its ->remove routine called usb_reset_device() -- thus nesting one
    reset call within another.
    
    Performing a reset as part of disconnect processing is a questionable
    practice at best.  However, the bug report points out that the USB
    core does not have any protection against nested resets.  Adding a
    reset_in_progress flag and testing it will prevent such errors in the
    future.
    
    Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3047e37461147b8b43ff07f136f98b2941888642
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Fri Aug 26 16:55:44 2022 -0700

    s390: fix nospec table alignments
    
    commit c9305b6c1f52060377c72aebe3a701389e9f3172 upstream.
    
    Add proper alignment for .nospec_call_table and .nospec_return_table in
    vmlinux.
    
    [hca@linux.ibm.com]: The problem with the missing alignment of the nospec
    tables exist since a long time, however only since commit e6ed91fd0768
    ("s390/alternatives: remove padding generation code") and with
    CONFIG_RELOCATABLE=n the kernel may also crash at boot time.
    
    The above named commit reduced the size of struct alt_instr by one byte,
    so its new size is 11 bytes. Therefore depending on the number of cpu
    alternatives the size of the __alt_instructions array maybe odd, which
    again also causes that the addresses of the nospec tables will be odd.
    
    If the address of __nospec_call_start is odd and the kernel is compiled
    With CONFIG_RELOCATABLE=n the compiler may generate code that loads the
    address of __nospec_call_start with a 'larl' instruction.
    
    This will generate incorrect code since the 'larl' instruction only works
    with even addresses. In result the members of the nospec tables will be
    accessed with an off-by-one offset, which subsequently may lead to
    addressing exceptions within __nospec_revert().
    
    Fixes: f19fbd5ed642 ("s390: introduce execute-trampolines for branches")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/8719bf1ce4a72ebdeb575200290094e9ce047bcc.1661557333.git.jpoimboe@kernel.org
    Cc: <stable@vger.kernel.org> # 4.16
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ade001d99aeac57e3e6f9501f87b5d28a98da2c1
Author: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Date:   Fri Aug 19 18:53:43 2022 +0200

    s390/hugetlb: fix prepare_hugepage_range() check for 2 GB hugepages
    
    commit 7c8d42fdf1a84b1a0dd60d6528309c8ec127e87c upstream.
    
    The alignment check in prepare_hugepage_range() is wrong for 2 GB
    hugepages, it only checks for 1 MB hugepage alignment.
    
    This can result in kernel crash in __unmap_hugepage_range() at the
    BUG_ON(start & ~huge_page_mask(h)) alignment check, for mappings
    created with MAP_FIXED at unaligned address.
    
    Fix this by correctly handling multiple hugepage sizes, similar to the
    generic version of prepare_hugepage_range().
    
    Fixes: d08de8e2d867 ("s390/mm: add support for 2GB hugepages")
    Cc: <stable@vger.kernel.org> # 4.8+
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56b409037d62bfe3f66adcf317de796c98f3924d
Author: Witold Lipieta <witold.lipieta@thaumatec.com>
Date:   Tue Aug 9 13:29:11 2022 +0200

    usb-storage: Add ignore-residue quirk for NXP PN7462AU
    
    commit 2aa48857ad52236a9564c71183d6cc8893becd41 upstream.
    
    This is USB mass storage primary boot loader for code download on
    NXP PN7462AU.
    
    Without the quirk it is impossible to write whole memory at once as
    device restarts during the write due to bogus residue values reported.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Witold Lipieta <witold.lipieta@thaumatec.com>
    Link: https://lore.kernel.org/r/20220809112911.462776-1-witold.lipieta@thaumatec.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ae507d6a554778a78c9d5746f2cefe6bcd8c814
Author: Thierry GUIBERT <thierry.guibert@croix-rouge.fr>
Date:   Fri Aug 19 10:17:02 2022 +0200

    USB: cdc-acm: Add Icom PMR F3400 support (0c26:0020)
    
    commit a10bc71729b236fe36de0d8e4d35c959fd8dec3a upstream.
    
    Supports for ICOM F3400 and ICOM F4400 PMR radios in CDC-ACM driver
    enabling the AT serial port.
    The Vendor Id is 0x0C26
    The Product ID is 0x0020
    
    Output of lsusb :
    Bus 001 Device 009: ID 0c26:0020 Prolific Technology Inc. ICOM Radio
    Couldn't open device, some information will be missing
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            2 Communications
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x0c26 Prolific Technology Inc.
      idProduct          0x0020
      bcdDevice            0.00
      iManufacturer           1 ICOM Inc.
      iProduct                2 ICOM Radio
      iSerial                 3 *obfuscated*
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength       0x0030
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0xc0
          Self Powered
        MaxPower                0mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval              12
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0
          bInterfaceProtocol      0
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
    
    Signed-off-by: Thierry GUIBERT <thierry.guibert@croix-rouge.fr>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20220819081702.84118-1-thierry.guibert@croix-rouge.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 459edcb1e1339d99a350a30c9dd0d7fc3d321522
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Thu Aug 25 08:22:07 2022 +0200

    usb: cdns3: fix incorrect handling TRB_SMM flag for ISOC transfer
    
    commit d5dcc33677d7415c5f23b3c052f9e80cbab9ea4e upstream.
    
    The TRB_SMM flag indicates that DMA has completed the TD service with
    this TRB. Usually it’s a last TRB in TD. In case of ISOC transfer for
    bInterval > 1 each ISOC transfer contains more than one TD associated
    with usb request (one TD per ITP). In such case the TRB_SMM flag will
    be set in every TD and driver will recognize the end of transfer after
    processing the first TD with TRB_SMM. In result driver stops updating
    request->actual and returns incorrect actual length.
    To fix this issue driver additionally must check TRB_CHAIN which is not
    used for isochronous transfers.
    
    Fixes: 249f0a25e8be ("usb: cdns3: gadget: handle sg list use case at completion correctly")
    cc: <stable@vger.kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20220825062207.5824-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 142e8c06e5f9c110dc82173a282fbb7dc3b3b88a
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Thu Aug 25 08:21:37 2022 +0200

    usb: cdns3: fix issue with rearming ISO OUT endpoint
    
    commit b46a6b09fa056042a302b181a1941f0056944603 upstream.
    
    ISO OUT endpoint is enabled during queuing first usb request
    in transfer ring and disabled when TRBERR is reported by controller.
    After TRBERR and before next transfer added to TR driver must again
    reenable endpoint but does not.
    To solve this issue during processing TRBERR event driver must
    set the flag EP_UPDATE_EP_TRBADDR in priv_ep->flags field.
    
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    cc: <stable@vger.kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20220825062137.5766-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62ef6b5f280b0c39086bcc4d468e6152e402ea92
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Tue Aug 23 19:58:42 2022 +0200

    usb: dwc2: fix wrong order of phy_power_on and phy_init
    
    commit f9b995b49a07bd0d43b0e490f59be84415c745ae upstream.
    
    Since 1599069a62c6 ("phy: core: Warn when phy_power_on is called before
    phy_init") the driver complains. In my case (Amlogic SoC) the warning
    is: phy phy-fe03e000.phy.2: phy_power_on was called before phy_init
    So change the order of the two calls. The same change has to be done
    to the order of phy_exit() and phy_power_off().
    
    Fixes: 09a75e857790 ("usb: dwc2: refactor common low-level hw code to platform.c")
    Cc: stable@vger.kernel.org
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/dfcc6b40-2274-4e86-e73c-5c5e6aa3e046@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbf5cb0137dc9c97c6ae01ea4306824e93ea4069
Author: Badhri Jagan Sridharan <badhri@google.com>
Date:   Wed Aug 17 14:54:10 2022 -0700

    usb: typec: tcpm: Return ENOTSUPP for power supply prop writes
    
    commit f2d38edc5e3375e56b4a30d5b66cefd385a2b38c upstream.
    
    When the port does not support USB PD, prevent transition to PD
    only states when power supply property is written. In this case,
    TCPM transitions to SNK_NEGOTIATE_CAPABILITIES
    which should not be the case given that the port is not pd_capable.
    
    [   84.308251] state change SNK_READY -> SNK_NEGOTIATE_CAPABILITIES [rev3 NONE_AMS]
    [   84.308335] Setting usb_comm capable false
    [   84.323367] set_auto_vbus_discharge_threshold mode:3 pps_active:n vbus:5000 ret:0
    [   84.323376] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS]
    
    Fixes: e9e6e164ed8f6 ("usb: typec: tcpm: Support non-PD mode")
    Cc: stable@vger.kernel.org
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
    Link: https://lore.kernel.org/r/20220817215410.1807477-1-badhri@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e68a2682e9976f8ab1ac45740037c7608e20f324
Author: Utkarsh Patel <utkarsh.h.patel@intel.com>
Date:   Tue Aug 16 13:16:24 2022 +0300

    usb: typec: intel_pmc_mux: Add new ACPI ID for Meteor Lake IOM device
    
    commit 1b1b672cc1d4fb3065dac79efb8901bd6244ef69 upstream.
    
    This adds the necessary ACPI ID for Intel Meteor Lake
    IOM devices.
    
    The callback function is_memory() is modified so that it
    also checks if the resource descriptor passed to it is a
    memory type "Address Space Resource Descriptor".
    
    On Intel Meteor Lake the ACPI memory resource is not
    described using the "32-bit Memory Range Descriptor" because
    the memory is outside of the 32-bit address space. The
    memory resource is described using the "Address Space
    Resource Descriptor" instead.
    
    Intel Meteor Lake is the first platform to describe the
    memory resource for this device with Address Space Resource
    Descriptor, but it most likely will not be the last.
    Therefore the change to the is_memory() callback function
    is made generic.
    
    Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
    Cc: stable@vger.kernel.org
    [ heikki: Rewrote the commit message. ]
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20220816101629.69054-2-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91416070b62ae892bf7206daa4467a4e9fdd1795
Author: Pablo Sun <pablo.sun@mediatek.com>
Date:   Thu Aug 4 11:48:03 2022 +0800

    usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles
    
    commit c1e5c2f0cb8a22ec2e14af92afc7006491bebabb upstream.
    
    Fix incorrect pin assignment values when connecting to a monitor with
    Type-C receptacle instead of a plug.
    
    According to specification, an UFP_D receptacle's pin assignment
    should came from the UFP_D pin assignments field (bit 23:16), while
    an UFP_D plug's assignments are described in the DFP_D pin assignments
    (bit 15:8) during Mode Discovery.
    
    For example the LG 27 UL850-W is a monitor with Type-C receptacle.
    The monitor responds to MODE DISCOVERY command with following
    DisplayPort Capability flag:
    
            dp->alt->vdo=0x140045
    
    The existing logic only take cares of UPF_D plug case,
    and would take the bit 15:8 for this 0x140045 case.
    
    This results in an non-existing pin assignment 0x0 in
    dp_altmode_configure.
    
    To fix this problem a new set of macros are introduced
    to take plug/receptacle differences into consideration.
    
    Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
    Cc: stable@vger.kernel.org
    Co-developed-by: Pablo Sun <pablo.sun@mediatek.com>
    Co-developed-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Reviewed-by: Guillaume Ranquet <granquet@baylibre.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Link: https://lore.kernel.org/r/20220804034803.19486-1-macpaul.lin@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d4044c9e6d2e3f11f1f8b5e0ee8647d3eb1afad
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 23 08:54:55 2022 +0200

    Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()"
    
    commit 5f73aa2cf8bef4a39baa1591c3144ede4788826e upstream.
    
    The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common
    function ucsi_unregister_connectors()") introduced a regression that
    caused NULL dereference at reading the power supply sysfs.  It's a
    stale sysfs entry that should have been removed but remains with NULL
    ops.  The commit changed the error handling to skip the entries after
    a NULL con->wq, and this leaves the power device unreleased.
    
    For addressing the regression, the straight revert is applied here.
    Further code improvements can be done from the scratch again.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1202386
    Link: https://lore.kernel.org/r/87r11cmbx0.wl-tiwai@suse.de
    Fixes: 87d0e2f41b8c ("usb: typec: ucsi: add a common function ucsi_unregister_connectors()")
    Cc: <stable@vger.kernel.org>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220823065455.32579-1-tiwai@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f45b7e93c942b840490b5031b1370ef4366ecea
Author: Slark Xiao <slark_xiao@163.com>
Date:   Wed Aug 10 11:30:50 2022 +0800

    USB: serial: option: add support for Cinterion MV32-WA/WB RmNet mode
    
    commit 8ffe20d08f2c95d702c453020d03a4c568a988f0 upstream.
    
    We added PIDs for MV32-WA/WB MBIM mode before, now we need to add
    support for RmNet mode.
    
    Test evidence as below:
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#=  3 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00f3 Rev=05.04
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00F3 USB Mobile Broadband
    S:  SerialNumber=d7b4be8d
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00f4 Rev=05.04
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00F4 USB Mobile Broadband
    S:  SerialNumber=d095087d
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    Signed-off-by: Slark Xiao <slark_xiao@163.com>
    [ johan: sort entries ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cce30bc7ae4823eba2dfbe0c964f16d9c330c93c
Author: Yonglin Tan <yonglin.tan@outlook.com>
Date:   Tue Jul 19 19:28:00 2022 +0800

    USB: serial: option: add Quectel EM060K modem
    
    commit f766f3abe6dbc9bf8b56a5d53c87e5a17942c154 upstream.
    
    Add usb product id entry for the Quectel EM060K module.
    
    "MBIM mode": DIAG + NMEA + AT + MODEM + MBIM + QDSS
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030b Rev= 5.04
    S:  Manufacturer=Quectel
    S:  Product=EM060K-GL
    S:  SerialNumber=89fb57db
    C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 8 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 8 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 9 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 9 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#=12 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Yonglin Tan <yonglin.tan@outlook.com>
    [ johan: mention QDSS port and sort entries ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a305d1b9055e15ead89a1332c0af7cef3daec4c
Author: Yan Xinyu <sdlyyxy@bupt.edu.cn>
Date:   Thu Jul 14 18:20:37 2022 +0800

    USB: serial: option: add support for OPPO R11 diag port
    
    commit 8d5fc280392735e4441b35de14f2f4860fa8d83c upstream.
    
    Add support for OPPO R11 USB diag serial port to option driver. This
    phone uses Qualcomm Snapdragon 660 SoC.
    
    usb-devices output:
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=22d9 ProdID=276c Rev=04.04
    S:  Manufacturer=OPPO
    S:  Product=SDM660-MTP _SN:09C6BCA7
    S:  SerialNumber=beb2c403
    C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    
    Signed-off-by: Yan Xinyu <sdlyyxy@bupt.edu.cn>
    Link: https://lore.kernel.org/r/20220714102037.4113889-1-sdlyyxy@bupt.edu.cn
    Link: https://lore.kernel.org/r/Yt1WfSZk03Plpnan@hovoldconsulting.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bda33a5038a9045bbd88504cbe36bf2bf9003a9e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Aug 29 16:25:50 2022 +0200

    USB: serial: cp210x: add Decagon UCA device id
    
    commit ceb4038472a4803e7046ed488b03d11551991514 upstream.
    
    Add the device id for Decagon Devices USB Cable Adapter.
    
    Link: https://lore.kernel.org/r/trinity-819f9db2-d3e1-40e9-a669-9c245817c046-1661523546680@msvc-mesg-web108
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40bc52e14011b3b1d01fed5f527e59e1ce7a4bdd
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Aug 31 10:15:25 2022 +0200

    USB: serial: ch341: fix disabled rx timer on older devices
    
    commit 41ca302a697b64a3dab4676e01d0d11bb184737d upstream.
    
    At least one older CH341 appears to have the RX timer enable bit
    inverted so that setting it disables the RX timer and prevents the FIFO
    from emptying until it is full.
    
    Only set the RX timer enable bit for devices with version newer than
    0x27 (even though this probably affects all pre-0x30 devices).
    
    Reported-by: Jonathan Woithe <jwoithe@just42.net>
    Tested-by: Jonathan Woithe <jwoithe@just42.net>
    Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
    Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on reconfiguration")
    Cc: stable@vger.kernel.org      # 4.10
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cffe34a4d070b3e016c37284b5960dedd5661857
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Aug 31 10:15:24 2022 +0200

    USB: serial: ch341: fix lost character on LCR updates
    
    commit 8e83622ae7ca481c76c8fd9579877f6abae64ca2 upstream.
    
    Disable LCR updates for pre-0x30 devices which use a different (unknown)
    protocol for line control and where the current register write causes
    the next received character to be lost.
    
    Note that updating LCR using the INIT command has no effect on these
    devices either.
    
    Reported-by: Jonathan Woithe <jwoithe@just42.net>
    Tested-by: Jonathan Woithe <jwoithe@just42.net>
    Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
    Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on reconfiguration")
    Fixes: 55fa15b5987d ("USB: serial: ch341: fix baud rate and line-control handling")
    Cc: stable@vger.kernel.org      # 4.10
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735e7d0834910af0e004493f1ff17fa582dec0e3
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Thu Aug 4 17:09:53 2022 +0200

    usb: dwc3: fix PHY disable sequence
    
    commit d2ac7bef95c9ead307801ccb6cb6dfbeb14247bf upstream.
    
    Generic PHYs must be powered-off before they can be tore down.
    
    Similarly, suspending legacy PHYs after having powered them off makes no
    sense.
    
    Fix the dwc3_core_exit() (e.g. called during suspend) and open-coded
    dwc3_probe() error-path sequences that got this wrong.
    
    Note that this makes dwc3_core_exit() match the dwc3_core_init() error
    path with respect to powering off the PHYs.
    
    Fixes: 03c1fd622f72 ("usb: dwc3: core: add phy cleanup for probe error handling")
    Fixes: c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
    Cc: stable@vger.kernel.org      # 4.8
    Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220804151001.23612-2-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 492a177db75fa192730e2ea1aeeebbd816c18e40
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Wed Jul 27 19:06:47 2022 -0700

    usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop
    
    commit 040f2dbd2010c43f33ad27249e6dac48456f4d99 upstream.
    
    Relocate the pullups_connected check until after it is ensured that there
    are no runtime PM transitions.  If another context triggered the DWC3
    core's runtime resume, it may have already enabled the Run/Stop.  Do not
    re-run the entire pullup sequence again, as it may issue a core soft
    reset while Run/Stop is already set.
    
    This patch depends on
      commit 69e131d1ac4e ("usb: dwc3: gadget: Prevent repeat pullup()")
    
    Fixes: 77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ea9baeecd21a741fde9b6794c2568d900da6fed
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Thu Aug 25 15:18:36 2022 +0200

    usb: dwc3: disable USB core PHY management
    
    commit 6000b8d900cd5f52fbcd0776d0cc396e88c8c2ea upstream.
    
    The dwc3 driver manages its PHYs itself so the USB core PHY management
    needs to be disabled.
    
    Use the struct xhci_plat_priv hack added by commits 46034a999c07 ("usb:
    host: xhci-plat: add platform data support") and f768e718911e ("usb:
    host: xhci-plat: add priv quirk for skip PHY initialization") to
    propagate the setting for now.
    
    Fixes: 4e88d4c08301 ("usb: add a flag to skip PHY initialization to struct usb_hcd")
    Fixes: 178a0bce05cb ("usb: core: hcd: integrate the PHY wrapper into the HCD core")
    Tested-by: Matthias Kaehlcke <mka@chromium.org>
    Cc: stable <stable@kernel.org>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220825131836.19769-1-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9debf9d563eafbe32e80dab975cb85d5882d794
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Aug 25 18:08:39 2022 +0300

    xhci: Add grace period after xHC start to prevent premature runtime suspend.
    
    commit 33e321586e37b642ad10594b9ef25a613555cd08 upstream.
    
    After xHC controller is started, either in probe or resume, it can take
    a while before any of the connected usb devices are visible to the roothub
    due to link training.
    
    It's possible xhci driver loads, sees no acivity and suspends the host
    before the USB device is visible.
    
    In one testcase with a hotplugged xHC controller the host finally detected
    the connected USB device and generated a wake 500ms after host initial
    start.
    
    If hosts didn't suspend the device duringe training it probablty wouldn't
    take up to 500ms to detect it, but looking at specs reveal USB3 link
    training has a couple long timeout values, such as 120ms
    RxDetectQuietTimeout, and 360ms PollingLFPSTimeout.
    
    So Add a 500ms grace period that keeps polling the roothub for 500ms after
    start, preventing runtime suspend until USB devices are detected.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20220825150840.132216-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d69c738ac9310b56e84c51c8f09fc018a8291bc6
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 26 15:31:40 2022 -0400

    media: mceusb: Use new usb_control_msg_*() routines
    
    commit 608e58a0f4617977178131f5f68a3fce1d3f5316 upstream.
    
    Automatic kernel fuzzing led to a WARN about invalid pipe direction in
    the mceusb driver:
    
    ------------[ cut here ]------------
    usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40
    WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410
    usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
    Modules linked in:
    CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.13.0-1ubuntu1.1 04/01/2014
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
    Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8
    44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b
    e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41
    RSP: 0018:ffffc900032becf0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000
    RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90
    RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000
    R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000
    R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500
    FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0
    Call Trace:
    <TASK>
    usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58
    usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
    usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
    mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]
    mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807
    
    The reason for the warning is clear enough; the driver sends an
    unusual read request on endpoint 0 but does not set the USB_DIR_IN bit
    in the bRequestType field.
    
    More importantly, the whole situation can be avoided and the driver
    simplified by converting it over to the relatively new
    usb_control_msg_recv() and usb_control_msg_send() routines.  That's
    what this fix does.
    
    Link: https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA@mail.gmail.com/
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/YwkfnBFCSEVC6XZu@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d539109b35bc8b3a581093aac35e4fcf648ce29
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Mon Aug 15 15:33:34 2022 +0300

    usb: dwc3: pci: Add support for Intel Raptor Lake
    
    commit bad0d1d726ace2db9e0f39c62b173bc7cc43dd6a upstream.
    
    This adds the necessary PCI device ID for the controller
    inside the Intel Raptor Lake CPU block. The controllers that
    are part of the PCH (chipset) have separate device IDs.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20220815123334.87526-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ef3f00c4230f16a40d45b39cef57864a6745ba7
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Jun 14 18:53:59 2022 +0300

    thunderbolt: Check router generation before connecting xHCI
    
    commit 93a3c0d4e8bfbb15145e5dd7da68a3de4b904aba upstream.
    
    Only Thunderbolt 3 routers need the xHCI connection flow. This also
    ensures the router actually has both lane adapters (1 and 3). While
    there move declaration of the boolean variables inside the block where
    they are being used.
    
    Fixes: 30a4eca69b76 ("thunderbolt: Add internal xHCI connect flows for Thunderbolt 3 devices")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fe0e9937257f4751347a1f4c72b69a356f1e9e0
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Apr 29 17:10:17 2022 +0300

    thunderbolt: Use the actual buffer in tb_async_error()
    
    commit eb100b8fa8e8b59eb3e5fc7a5fd4a1e3c5950f64 upstream.
    
    The received notification packet is held in pkg->buffer and not in pkg
    itself. Fix this by using the correct buffer.
    
    Fixes: 81a54b5e1986 ("thunderbolt: Let the connection manager handle all notifications")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06cb054244cc2612442c4e6276cf42a1ee1f1338
Author: SeongJae Park <sj@kernel.org>
Date:   Wed Aug 31 16:58:24 2022 +0000

    xen-blkfront: Cache feature_persistent value before advertisement
    
    commit fe8f65b018effbf473f53af3538d0c1878b8b329 upstream.
    
    Xen blkfront advertises its support of the persistent grants feature
    when it first setting up and when resuming in 'talk_to_blkback()'.
    Then, blkback reads the advertised value when it connects with blkfront
    and decides if it will use the persistent grants feature or not, and
    advertises its decision to blkfront.  Blkfront reads the blkback's
    decision and it also makes the decision for the use of the feature.
    
    Commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter
    when connect"), however, made the blkfront's read of the parameter for
    disabling the advertisement, namely 'feature_persistent', to be done
    when it negotiate, not when advertise.  Therefore blkfront advertises
    without reading the parameter.  As the field for caching the parameter
    value is zero-initialized, it always advertises as the feature is
    disabled, so that the persistent grants feature becomes always disabled.
    
    This commit fixes the issue by making the blkfront does parmeter caching
    just before the advertisement.
    
    Fixes: 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20220831165824.94815-4-sj@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d4ee444e8c7bebf6d18e6f7f8d1efae718a0fdc
Author: SeongJae Park <sj@kernel.org>
Date:   Wed Aug 31 16:58:23 2022 +0000

    xen-blkfront: Advertise feature-persistent as user requested
    
    commit 9f5e0fe5d05f7e8de7f39b2b10089834eb0ff787 upstream.
    
    The advertisement of the persistent grants feature (writing
    'feature-persistent' to xenbus) should mean not the decision for using
    the feature but only the availability of the feature.  However, commit
    74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent
    grants") made a field of blkfront, which was a place for saving only the
    negotiation result, to be used for yet another purpose: caching of the
    'feature_persistent' parameter value.  As a result, the advertisement,
    which should follow only the parameter value, becomes inconsistent.
    
    This commit fixes the misuse of the semantic by making blkfront saves
    the parameter value in a separate place and advertises the support based
    on only the saved value.
    
    Fixes: 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Suggested-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20220831165824.94815-3-sj@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d925c3bf859347b0cf9207d7107c03445db60589
Author: SeongJae Park <sj@kernel.org>
Date:   Wed Aug 31 16:58:22 2022 +0000

    xen-blkback: Advertise feature-persistent as user requested
    
    commit 06ba5d2e943e97bb66e75c152e87f1d2c7027a67 upstream.
    
    The advertisement of the persistent grants feature (writing
    'feature-persistent' to xenbus) should mean not the decision for using
    the feature but only the availability of the feature.  However, commit
    aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent
    grants") made a field of blkback, which was a place for saving only the
    negotiation result, to be used for yet another purpose: caching of the
    'feature_persistent' parameter value.  As a result, the advertisement,
    which should follow only the parameter value, becomes inconsistent.
    
    This commit fixes the misuse of the semantic by making blkback saves the
    parameter value in a separate place and advertises the support based on
    only the saved value.
    
    Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Suggested-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20220831165824.94815-2-sj@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a108bd6d909580be635a28c527c761755d5c67a
Author: Steven Price <steven.price@arm.com>
Date:   Fri Sep 2 12:26:12 2022 +0100

    mm: pagewalk: Fix race between unmap and page walker
    
    [ Upstream commit 8782fb61cc848364e1e1599d76d3c9dd58a1cc06 ]
    
    The mmap lock protects the page walker from changes to the page tables
    during the walk.  However a read lock is insufficient to protect those
    areas which don't have a VMA as munmap() detaches the VMAs before
    downgrading to a read lock and actually tearing down PTEs/page tables.
    
    For users of walk_page_range() the solution is to simply call pte_hole()
    immediately without checking the actual page tables when a VMA is not
    present. We now never call __walk_page_range() without a valid vma.
    
    For walk_page_range_novma() the locking requirements are tightened to
    require the mmap write lock to be taken, and then walking the pgd
    directly with 'no_vma' set.
    
    This in turn means that all page walkers either have a valid vma, or
    it's that special 'novma' case for page table debugging.  As a result,
    all the odd '(!walk->vma && !walk->no_vma)' tests can be removed.
    
    Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Cc: Konstantin Khlebnikov <koct9i@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3aa6a9f84ba21e9f2e859e428b3a4a187b0c4676
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Sep 1 18:35:20 2022 +0300

    xen/grants: prevent integer overflow in gnttab_dma_alloc_pages()
    
    [ Upstream commit e9ea0b30ada008f4e65933f449db6894832cb242 ]
    
    The change from kcalloc() to kvmalloc() means that arg->nr_pages
    might now be large enough that the "args->nr_pages << PAGE_SHIFT" can
    result in an integer overflow.
    
    Fixes: b3f7931f5c61 ("xen/gntdev: switch from kcalloc() to kvcalloc()")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/YxDROJqu/RPvR0bi@kili
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e2eecb92a183497fb1bf03c7622cd659a6fca38
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Aug 30 08:12:56 2022 -0700

    powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register()
    
    [ Upstream commit 6cf07810e9ef8535d60160d13bf0fd05f2af38e7 ]
    
    Clang warns:
    
      arch/powerpc/platforms/pseries/papr_scm.c:492:6: warning: variable 'rc' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
              if (!p->stat_buffer_len)
                  ^~~~~~~~~~~~~~~~~~~
      arch/powerpc/platforms/pseries/papr_scm.c:523:64: note: uninitialized use occurs here
              dev_info(&p->pdev->dev, "nvdimm pmu didn't register rc=%d\n", rc);
                                                                            ^~
      include/linux/dev_printk.h:150:67: note: expanded from macro 'dev_info'
              dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                                              ^~~~~~~~~~~
      include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                      _p_func(dev, fmt, ##__VA_ARGS__);                       \
                                          ^~~~~~~~~~~
      arch/powerpc/platforms/pseries/papr_scm.c:492:2: note: remove the 'if' if its condition is always false
              if (!p->stat_buffer_len)
              ^~~~~~~~~~~~~~~~~~~~~~~~
      arch/powerpc/platforms/pseries/papr_scm.c:484:8: note: initialize the variable 'rc' to silence this warning
              int rc, nodeid;
                    ^
                    = 0
      1 warning generated.
    
    The call to papr_scm_pmu_check_events() was eliminated but a return code
    was not added to the if statement. Add the same return code from
    papr_scm_pmu_check_events() for this condition so there is no more
    warning.
    
    Fixes: 9b1ac04698a4 ("powerpc/papr_scm: Fix nvdimm event mappings")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1701
    Link: https://lore.kernel.org/r/20220830151256.1473169-1-nathan@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d92ba2628658783cf5ebc5ed32d3748a799f9cd
Author: Jim Mattson <jmattson@google.com>
Date:   Tue Aug 30 10:49:47 2022 -0700

    KVM: x86: Mask off unsupported and unknown bits of IA32_ARCH_CAPABILITIES
    
    [ Upstream commit 0204750bd4c6ccc2fb7417618477f10373b33f56 ]
    
    KVM should not claim to virtualize unknown IA32_ARCH_CAPABILITIES
    bits. When kvm_get_arch_capabilities() was originally written, there
    were only a few bits defined in this MSR, and KVM could virtualize all
    of them. However, over the years, several bits have been defined that
    KVM cannot just blindly pass through to the guest without additional
    work (such as virtualizing an MSR promised by the
    IA32_ARCH_CAPABILITES feature bit).
    
    Define a mask of supported IA32_ARCH_CAPABILITIES bits, and mask off
    any other bits that are set in the hardware MSR.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Fixes: 5b76a3cff011 ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Vipin Sharma <vipinsh@google.com>
    Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Message-Id: <20220830174947.2182144-1-jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e13ef600a247863b75dac100b30b65c1d96cad5e
Author: Sander Vanheule <sander@svanheule.net>
Date:   Sun Aug 7 21:21:15 2022 +0200

    gpio: realtek-otto: switch to 32-bit I/O
    
    [ Upstream commit ee0175b3b44288c74d5292c2a9c2c154f6c0317e ]
    
    By using 16-bit I/O on the GPIO peripheral, which is apparently not safe
    on MIPS, the IMR can end up containing garbage. This then results in
    interrupt triggers for lines that don't have an interrupt handler
    associated. The irq_desc lookup fails, and the ISR will not be cleared,
    keeping the CPU busy until reboot, or until another IMR operation
    restores the correct value. This situation appears to happen very
    rarely, for < 0.5% of IMR writes.
    
    Instead of using 8-bit or 16-bit I/O operations on the 32-bit memory
    mapped peripheral registers, switch to using 32-bit I/O only, operating
    on the entire bank for all single bit line settings. For 2-bit line
    settings, with 16-bit port values, stick to manual (un)packing.
    
    This issue has been seen on RTL8382M (HPE 1920-16G), RTL8391M (Netgear
    GS728TP v2), and RTL8393M (D-Link DGS-1210-52 F3, Zyxel GS1900-48).
    
    Reported-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> # DGS-1210-52
    Reported-by: Birger Koblitz <mail@birger-koblitz.de> # GS728TP
    Reported-by: Jan Hoffmann <jan@3e8.eu> # 1920-16G
    Fixes: 0d82fb1127fb ("gpio: Add Realtek Otto GPIO support")
    Signed-off-by: Sander Vanheule <sander@svanheule.net>
    Cc: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97ca48ec17f73fa86fde87eb7483f70177bc2bd6
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Wed Aug 31 18:37:35 2022 +0800

    gpio: pca953x: Add mutex_lock for regcache sync in PM
    
    [ Upstream commit 518e26f11af2fe4f5bebf9a0351595d508c7077f ]
    
    The regcache sync will set the cache_bypass = true, at that
    time, when there is regmap write operation, it will bypass
    the regmap cache, then the regcache sync will write back the
    value from cache to register, which is not as our expectation.
    
    Though regmap already use its internal lock to avoid such issue,
    but this driver force disable the regmap internal lock in its
    regmap config: disable_locking = true
    
    To avoid this issue, use the driver's own lock to do the protect
    in system PM.
    
    Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3263984c7acdcb0658155b05a724ed45a10de76d
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Tue Aug 30 03:11:01 2022 +0200

    hwmon: (gpio-fan) Fix array out of bounds access
    
    [ Upstream commit f233d2be38dbbb22299192292983037f01ab363c ]
    
    The driver does not check if the cooling state passed to
    gpio_fan_set_cur_state() exceeds the maximum cooling state as
    stored in fan_data->num_speeds. Since the cooling state is later
    used as an array index in set_fan_speed(), an array out of bounds
    access can occur.
    This can be exploited by setting the state of the thermal cooling device
    to arbitrary values, causing for example a kernel oops when unavailable
    memory is accessed this way.
    
    Example kernel oops:
    [  807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064
    [  807.987369] Mem abort info:
    [  807.987398]   ESR = 0x96000005
    [  807.987428]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  807.987477]   SET = 0, FnV = 0
    [  807.987507]   EA = 0, S1PTW = 0
    [  807.987536]   FSC = 0x05: level 1 translation fault
    [  807.987570] Data abort info:
    [  807.987763]   ISV = 0, ISS = 0x00000005
    [  807.987801]   CM = 0, WnR = 0
    [  807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000
    [  807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
    [  807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP
    [  807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
    [  807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G         C        5.15.56-v8+ #1575
    [  807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
    [  807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]
    [  807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
    [  807.988691] sp : ffffffc008cf3bd0
    [  807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000
    [  807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920
    [  807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c
    [  807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000
    [  807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70
    [  807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    [  807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c
    [  807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009
    [  807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8
    [  807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060
    [  807.989084] Call trace:
    [  807.989091]  set_fan_speed.part.5+0x34/0x80 [gpio_fan]
    [  807.989113]  gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
    [  807.989199]  cur_state_store+0x84/0xd0
    [  807.989221]  dev_attr_store+0x20/0x38
    [  807.989262]  sysfs_kf_write+0x4c/0x60
    [  807.989282]  kernfs_fop_write_iter+0x130/0x1c0
    [  807.989298]  new_sync_write+0x10c/0x190
    [  807.989315]  vfs_write+0x254/0x378
    [  807.989362]  ksys_write+0x70/0xf8
    [  807.989379]  __arm64_sys_write+0x24/0x30
    [  807.989424]  invoke_syscall+0x4c/0x110
    [  807.989442]  el0_svc_common.constprop.3+0xfc/0x120
    [  807.989458]  do_el0_svc+0x2c/0x90
    [  807.989473]  el0_svc+0x24/0x60
    [  807.989544]  el0t_64_sync_handler+0x90/0xb8
    [  807.989558]  el0t_64_sync+0x1a0/0x1a4
    [  807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)
    [  807.989627] ---[ end trace 8ded4c918658445b ]---
    
    Fix this by checking the cooling state and return an error if it
    exceeds the maximum cooling state.
    
    Tested on a Raspberry Pi 3.
    
    Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20220830011101.178843-1-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d54f19f7f4f6309c47a4dd6c6a7cd3386bce80f
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Wed Jul 13 17:49:52 2022 +0200

    clk: bcm: rpi: Add missing newline
    
    [ Upstream commit 13b5cf8d6a0d4a5d289e1ed046cadc63b416db85 ]
    
    Some log messages lacks the final newline. So add them.
    
    Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks")
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/20220713154953.3336-3-stefan.wahren@i2se.com
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Ivan T. Ivanov <iivanov@suse.de>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8b04b731d43366824841ebdca4ac715f95e0ea4
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Wed Jul 13 17:49:51 2022 +0200

    clk: bcm: rpi: Prevent out-of-bounds access
    
    [ Upstream commit bc163555603e4ae9c817675ad80d618a4cdbfa2d ]
    
    The while loop in raspberrypi_discover_clocks() relies on the assumption
    that the id of the last clock element is zero. Because this data comes
    from the Videocore firmware and it doesn't guarantuee such a behavior
    this could lead to out-of-bounds access. So fix this by providing
    a sentinel element.
    
    Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks")
    Link: https://github.com/raspberrypi/firmware/issues/1688
    Suggested-by: Phil Elwell <phil@raspberrypi.com>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/20220713154953.3336-2-stefan.wahren@i2se.com
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Ivan T. Ivanov <iivanov@suse.de>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 838dff24979d2c826c52330323f79637e1cd9fa1
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Sat Jun 25 10:36:43 2022 +0200

    clk: bcm: rpi: Fix error handling of raspberrypi_fw_get_rate
    
    [ Upstream commit 35f73cca1cecda0c1f8bb7d8be4ce5cd2d46ae8c ]
    
    The function raspberrypi_fw_get_rate (e.g. used for the recalc_rate
    hook) can fail to get the clock rate from the firmware. In this case
    we cannot return a signed error value, which would be casted to
    unsigned long. Fix this by returning 0 instead.
    
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/20220625083643.4012-1-stefan.wahren@i2se.com
    Fixes: 4e85e535e6cc ("clk: bcm283x: add driver interfacing with Raspberry Pi's firmware")
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a58d2aa45f8d41954d6916337a93b73d8c4f2ad
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Thu Aug 4 13:18:52 2022 +0530

    powerpc/papr_scm: Fix nvdimm event mappings
    
    [ Upstream commit 9b1ac04698a4bfec146322502cdcd9904c1777fa ]
    
    Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
    added performance monitoring support for papr-scm nvdimm devices via
    perf interface. Commit also added an array in papr_scm_priv
    structure called "nvdimm_events_map", which got filled based on the
    result of H_SCM_PERFORMANCE_STATS hcall.
    
    Currently there is an assumption that the order of events in the
    stats buffer, returned by the hypervisor is same. And order also
    happens to matches with the events specified in nvdimm driver code.
    But this assumption is not documented in Power Architecture
    Platform Requirements (PAPR) document. Although the order
    of events happens to be same on current generation od system, but
    it might not be true in future generation systems. Fix the issue, by
    adding a static mapping for nvdimm events to corresponding stat-id,
    and removing the dynamic map from papr_scm_priv structure. Also
    remove the function papr_scm_pmu_check_events from papr_scm.c file,
    as we no longer need to copy stat-ids dynamically.
    
    Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
    Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220804074852.55157-1-kjain@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd5ec5416171a55cd3d6fa2c349e3e5d9364b706
Author: Peter Robinson <pbrobinson@gmail.com>
Date:   Mon Aug 22 16:33:18 2022 -0700

    Input: rk805-pwrkey - fix module autoloading
    
    [ Upstream commit 99077ad668ddd9b4823cc8ce3f3c7a3fc56f6fd9 ]
    
    Add the module alias so the rk805-pwrkey driver will
    autoload when built as a module.
    
    Fixes: 5a35b85c2d92 ("Input: add power key driver for Rockchip RK805 PMIC")
    Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://lore.kernel.org/r/20220612225437.3628788-1-pbrobinson@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e7ddb091ef2b4af6330a0b66604f87afa153bec
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Aug 22 16:14:24 2022 +0800

    clk: core: Fix runtime PM sequence in clk_core_unprepare()
    
    [ Upstream commit 4b592061f7b3971c70e8b72fc42aaead47c24701 ]
    
    In the original commit 9a34b45397e5 ("clk: Add support for runtime PM"),
    the commit message mentioned that pm_runtime_put_sync() would be done
    at the end of clk_core_unprepare(). This mirrors the operations in
    clk_core_prepare() in the opposite order.
    
    However, the actual code that was added wasn't in the order the commit
    message described. Move clk_pm_runtime_put() to the end of
    clk_core_unprepare() so that it is in the correct order.
    
    Fixes: 9a34b45397e5 ("clk: Add support for runtime PM")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20220822081424.1310926-3-wenst@chromium.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27c26c2a585785fff40993604b99819a0d2941a5
Author: Stephen Boyd <sboyd@kernel.org>
Date:   Wed Aug 31 10:53:25 2022 -0700

    Revert "clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops"
    
    [ Upstream commit abb5f3f4b1f5f0ad50eb067a00051d3587dec9fb ]
    
    This reverts commit 35b0fac808b95eea1212f8860baf6ad25b88b087. Alexander
    reports that it causes boot failures on i.MX8M Plus based boards
    (specifically imx8mp-tqma8mpql-mba8mpxl.dts).
    
    Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Cc: Chen-Yu Tsai <wenst@chromium.org>
    Fixes: 35b0fac808b9 ("clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops")
    Link: https://lore.kernel.org/r/12115951.O9o76ZdvQC@steina-w
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lore.kernel.org/r/20220831175326.2523912-1-sboyd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c25e0ca0d981c2ab815c8f1a1fa5806649a4d5b1
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Aug 22 16:14:23 2022 +0800

    clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops
    
    [ Upstream commit 35b0fac808b95eea1212f8860baf6ad25b88b087 ]
    
    In the previous commits that added CLK_OPS_PARENT_ENABLE, support for
    this flag was only added to rate change operations (rate setting and
    reparent) and disabling unused subtree. It was not added to the
    clock gate related operations. Any hardware driver that needs it for
    these operations will either see bogus results, or worse, hang.
    
    This has been seen on MT8192 and MT8195, where the imp_ii2_* clk
    drivers set this, but dumping debugfs clk_summary would cause it
    to hang.
    
    Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
    Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20220822081424.1310926-2-wenst@chromium.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 079ea01fc5f00b1e964ed92f78185e02a2702bc8
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Tue Aug 16 13:02:47 2022 +0800

    drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
    
    [ Upstream commit 233f56745be446b289edac2ba8184c09365c005e ]
    
    There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
    
    Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.king@gmail.com
    Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6c8cc2da50f86a0d17b50d48e736d6040048a97
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jun 21 12:11:18 2022 +0300

    clk: ti: Fix missing of_node_get() ti_find_clock_provider()
    
    [ Upstream commit 26f2da0d2f823dc7180b0505d46318f64d1e0a7a ]
    
    For ti_find_clock_provider() we want to return the np with refcount
    incremented. However we are missing of_node_get() for the
    clock-output-names case that causes refcount warnings.
    
    Fixes: 51f661ef9a10 ("clk: ti: Add ti_find_clock_provider() to use clock-output-names")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220621091118.33930-1-tony@atomide.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26b03f8039b4efbcc3bbf259b92718952f3512db
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Sun Aug 14 15:12:36 2022 +0100

    riscv: kvm: move extern sbi_ext declarations to a header
    
    [ Upstream commit 3e5e56c60a14776e2a49837b55b03bc193fd91f7 ]
    
    Sparse complains about missing statics in the declarations of several
    variables:
    arch/riscv/kvm/vcpu_sbi_replace.c:38:37: warning: symbol 'vcpu_sbi_ext_time' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_replace.c:73:37: warning: symbol 'vcpu_sbi_ext_ipi' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_replace.c:126:37: warning: symbol 'vcpu_sbi_ext_rfence' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_replace.c:170:37: warning: symbol 'vcpu_sbi_ext_srst' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_base.c:69:37: warning: symbol 'vcpu_sbi_ext_base' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_base.c:90:37: warning: symbol 'vcpu_sbi_ext_experimental' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_base.c:96:37: warning: symbol 'vcpu_sbi_ext_vendor' was not declared. Should it be static?
    arch/riscv/kvm/vcpu_sbi_hsm.c:115:37: warning: symbol 'vcpu_sbi_ext_hsm' was not declared. Should it be static?
    
    These variables are however used in vcpu_sbi.c where they are declared
    as extern. Move them to kvm_vcpu_sbi.h which is handily already
    included by the three other files.
    
    Fixes: a046c2d8578c ("RISC-V: KVM: Reorganize SBI code by moving SBI v0.1 to its own file")
    Fixes: 5f862df5585c ("RISC-V: KVM: Add v0.1 replacement SBI extensions defined in v0.2")
    Fixes: 3e1d86569c21 ("RISC-V: KVM: Add SBI HSM extension in KVM")
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Anup Patel <anup@brainfault.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5424fd0429c5f83986220c3f5cf48a6783d5f256
Author: Jim Mattson <jmattson@google.com>
Date:   Wed Aug 10 14:30:50 2022 -0700

    KVM: VMX: Heed the 'msr' argument in msr_write_intercepted()
    
    [ Upstream commit 020dac4187968535f089f83f376a72beb3451311 ]
    
    Regardless of the 'msr' argument passed to the VMX version of
    msr_write_intercepted(), the function always checks to see if a
    specific MSR (IA32_SPEC_CTRL) is intercepted for write.  This behavior
    seems unintentional and unexpected.
    
    Modify the function so that it checks to see if the provided 'msr'
    index is intercepted for write.
    
    Fixes: 67f4b9969c30 ("KVM: nVMX: Handle dynamic MSR intercept toggling")
    Cc: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220810213050.2655000-1-jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38a6b469bf22f153282fbe7d702a24e9eb43f50e
Author: Enzo Matsumiya <ematsumiya@suse.de>
Date:   Tue Aug 30 19:51:51 2022 -0300

    cifs: fix small mempool leak in SMB2_negotiate()
    
    commit 27893dfc1285f80f80f46b3b8c95f5d15d2e66d0 upstream.
    
    In some cases of failure (dialect mismatches) in SMB2_negotiate(), after
    the request is sent, the checks would return -EIO when they should be
    rather setting rc = -EIO and jumping to neg_exit to free the response
    buffer from mempool.
    
    Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
    Cc: stable@vger.kernel.org
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2a97babb0a510f8921891f9e70c5a5ef33cadac
Author: Carlos Llamas <cmllamas@google.com>
Date:   Mon Aug 29 20:12:48 2022 +0000

    binder: fix alloc->vma_vm_mm null-ptr dereference
    
    commit 1da52815d5f1b654c89044db0cdc6adce43da1f1 upstream.
    
    Syzbot reported a couple issues introduced by commit 44e602b4e52f
    ("binder_alloc: add missing mmap_lock calls when using the VMA"), in
    which we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not
    been initialized yet.
    
    This can happen if a binder_proc receives a transaction without having
    previously called mmap() to setup the binder_proc->alloc space in [1].
    Also, a similar issue occurs via binder_alloc_print_pages() when we try
    to dump the debugfs binder stats file in [2].
    
    Sample of syzbot's crash report:
      ==================================================================
      KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]
      CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0
      syz-executor229[3755] cmdline: ./syz-executor2294415195
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
      RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923
      [...]
      Call Trace:
       <TASK>
       lock_acquire kernel/locking/lockdep.c:5666 [inline]
       lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631
       down_read+0x98/0x450 kernel/locking/rwsem.c:1499
       mmap_read_lock include/linux/mmap_lock.h:117 [inline]
       binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]
       binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593
       binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199
       binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986
       binder_ioctl_write_read drivers/android/binder.c:5036 [inline]
       binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:870 [inline]
       __se_sys_ioctl fs/ioctl.c:856 [inline]
       __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
       [...]
      ==================================================================
    
    Fix these issues by setting up alloc->vma_vm_mm pointer during open()
    and caching directly from current->mm. This guarantees we have a valid
    reference to take the mmap_lock during scenarios described above.
    
    [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459
    [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9
    
    Fixes: 44e602b4e52f ("binder_alloc: add missing mmap_lock calls when using the VMA")
    Cc: <stable@vger.kernel.org> # v5.15+
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reported-by: syzbot+f7dc54e5be28950ac459@syzkaller.appspotmail.com
    Reported-by: syzbot+a75ebe0452711c9e56d9@syzkaller.appspotmail.com
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Acked-by: Todd Kjos <tkjos@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20220829201254.1814484-2-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 603a47f2ae56bf68288784d3c0a8c5b8e0a827ed
Author: Carlos Llamas <cmllamas@google.com>
Date:   Mon Aug 1 18:25:11 2022 +0000

    binder: fix UAF of ref->proc caused by race condition
    
    commit a0e44c64b6061dda7e00b7c458e4523e2331b739 upstream.
    
    A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the
    reference for a node. In this case, the target proc normally releases
    the failed reference upon close as expected. However, if the target is
    dying in parallel the call will race with binder_deferred_release(), so
    the target could have released all of its references by now leaving the
    cleanup of the new failed reference unhandled.
    
    The transaction then ends and the target proc gets released making the
    ref->proc now a dangling pointer. Later on, ref->node is closed and we
    attempt to take spin_lock(&ref->proc->inner_lock), which leads to the
    use-after-free bug reported below. Let's fix this by cleaning up the
    failed reference on the spot instead of relying on the target to do so.
    
      ==================================================================
      BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150
      Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590
    
      CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10
      Hardware name: linux,dummy-virt (DT)
      Workqueue: events binder_deferred_func
      Call trace:
       dump_backtrace.part.0+0x1d0/0x1e0
       show_stack+0x18/0x70
       dump_stack_lvl+0x68/0x84
       print_report+0x2e4/0x61c
       kasan_report+0xa4/0x110
       kasan_check_range+0xfc/0x1a4
       __kasan_check_write+0x3c/0x50
       _raw_spin_lock+0xa8/0x150
       binder_deferred_func+0x5e0/0x9b0
       process_one_work+0x38c/0x5f0
       worker_thread+0x9c/0x694
       kthread+0x188/0x190
       ret_from_fork+0x10/0x20
    
    Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Cc: stable <stable@kernel.org> # 4.14+
    Link: https://lore.kernel.org/r/20220801182511.3371447-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71f7644b444f814855a83e11d4bb9ede5c4321ad
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Aug 15 10:33:21 2022 +0300

    mmc: core: Fix inconsistent sd3_bus_mode at UHS-I SD voltage switch failure
    
    commit 63f1560930e4e1c4f6279b8ae715c9841fe1a6d3 upstream.
    
    If re-initialization results is a different signal voltage, because the
    voltage switch failed previously, but not this time (or vice versa), then
    sd3_bus_mode will be inconsistent with the card because the SD_SWITCH
    command is done only upon first initialization.
    
    Fix by always reading SD_SWITCH information during re-initialization, which
    also means it does not need to be re-read later for the 1.8V fixup
    workaround.
    
    Note, brief testing showed SD_SWITCH took about 1.8ms to 2ms which added
    about 1% to 1.5% to the re-initialization time, so it's not particularly
    significant.
    
    Reported-by: Seunghui Lee <sh043.lee@samsung.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Seunghui Lee <sh043.lee@samsung.com>
    Tested-by: Seunghui Lee <sh043.lee@samsung.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220815073321.63382-3-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4be611c2f5f50386b609e8437754bd16bd88f8
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Aug 15 10:33:20 2022 +0300

    mmc: core: Fix UHS-I SD 1.8V workaround branch
    
    commit 15c56208c79c340686869c31595c209d1431c5e8 upstream.
    
    When introduced, upon success, the 1.8V fixup workaround in
    mmc_sd_init_card() would branch to practically the end of the function, to
    a label named "done". Unfortunately, perhaps due to the label name, over
    time new code has been added that really should have come after "done" not
    before it. Let's fix the problem by moving the label to the correct place
    and rename it "cont".
    
    Fixes: 045d705dc1fb ("mmc: core: Enable the MMC host software queue for the SD card")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Seunghui Lee <sh043.lee@samsung.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220815073321.63382-2-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f78dda3c3bb9f5e084495e4a24ccf265f1b5168
Author: Mickaël Salaün <mic@digikod.net>
Date:   Wed Aug 31 22:38:40 2022 +0200

    landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER
    
    commit 55e55920bbe3ccf516022c51f5527e7d026b8f1d upstream.
    
    This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right
    when multiple rulesets/domains are stacked. The expected behaviour was
    that an additional ruleset can only restrict the set of permitted
    operations, but in this particular case, it was potentially possible to
    re-gain the LANDLOCK_ACCESS_FS_REFER right.
    
    With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first
    globally denied-by-default access right.  Indeed, this lifted an initial
    Landlock limitation to rename and link files, which was initially always
    denied when the source or the destination were different directories.
    
    This led to an inconsistent backward compatibility behavior which was
    only taken into account if no domain layer were using the new
    LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with
    a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent
    rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would
    behave as if they were handling this access right and with all their
    rules allowing it. This means that renaming and linking files could
    became allowed by these parent layers, but all the other required
    accesses must also be granted: all layers must allow file removal or
    creation, and renaming and linking operations cannot lead to privilege
    escalation according to the Landlock policy.  See detailed explanation
    in commit b91c3e4ea756 ("landlock: Add support for file reparenting with
    LANDLOCK_ACCESS_FS_REFER").
    
    To say it another way, this bug may lift the renaming and linking
    limitations of the initial Landlock version, and a same ruleset can
    enforce different restrictions depending on previous or next enforced
    ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right
    cannot give access to data not already allowed, but this doesn't follow
    the contract of the first Landlock ABI. This fix puts back the
    limitation for sandboxes that didn't opt-in for this additional right.
    
    For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on
    /dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to
    /dst/file is denied. However, without this fix, stacking a new ruleset
    which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the
    sandboxed thread to rename /src/file to /dst/file .
    
    This change fixes the (absolute) rule access rights, which now always
    forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed
    when creating a rule.
    
    Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial
    approach but there is two downsides:
    * it makes the code more complex because we still want to check that a
      rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the
      ruleset's handled access rights (i.e. ABI v1 != ABI v2);
    * it would not allow to identify if the user created a ruleset
      explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an
      issue to audit Landlock.
    
    Instead, this change adds an ACCESS_INITIALLY_DENIED list of
    denied-by-default rights, which (only) contains
    LANDLOCK_ACCESS_FS_REFER.  All domains are treated as if they are also
    handling this list, but without modifying their fs_access_masks field.
    
    A side effect is that the errno code returned by rename(2) or link(2)
    *may* be changed from EXDEV to EACCES according to the enforced
    restrictions.  Indeed, we now have the mechanic to identify if an access
    is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG,
    LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing
    LANDLOCK_ACCESS_FS_REFER rights.  This may result in different errno
    codes than for the initial Landlock version, but this approach is more
    consistent and better for rename/link compatibility reasons, and it
    wasn't possible before (hence no backport to ABI v1).  The
    layout1.rename_file test reflects this change.
    
    Add 4 layout1.refer_denied_by_default* test suites to check that the
    behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is
    unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e.
    ABI v1 precedence).  Make sure rule's absolute access rights are correct
    by testing with and without a matching path.  Add test_rename() and
    test_exchange() helpers.
    
    Extend layout1.inval tests to check that a denied-by-default access
    right is not necessarily part of a domain's handled access rights.
    
    Test coverage for security/landlock is 95.3% of 599 lines according to
    gcc/gcov-11.
    
    Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER")
    Reviewed-by: Paul Moore <paul@paul-moore.com>
    Reviewed-by: Günther Noack <gnoack3000@gmail.com>
    Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net
    Cc: stable@vger.kernel.org
    [mic: Constify and slightly simplify test helpers]
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23475d8ebcca8c1435c3da99649b7c5ca613c549
Author: Niek Nooijens <niek.nooijens@omron.com>
Date:   Mon Aug 1 10:39:25 2022 +0200

    USB: serial: ftdi_sio: add Omron CS1W-CIF31 device id
    
    commit 001047ea241a9646010b2744451dfbc7289542f3 upstream.
    
    works perfectly with:
    modprobe ftdi_sio
    echo "0590 00b2" | tee
    /sys/module/ftdi_sio/drivers/usb-serial\:ftdi_sio/new_id > /dev/null
    
    but doing this every reboot is a pain in the ass.
    
    Signed-off-by: Niek Nooijens <niek.nooijens@omron.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit baf92485d111be828e1ab84a995515b604b938e5
Author: Russ Weight <russell.h.weight@intel.com>
Date:   Tue Aug 30 17:25:18 2022 -0700

    firmware_loader: Fix memory leak in firmware upload
    
    commit 789bba82f63c3e81dce426ba457fc7905b30ac6e upstream.
    
    In the case of firmware-upload, an instance of struct fw_upload is
    allocated in firmware_upload_register(). This data needs to be freed
    in fw_dev_release(). Create a new fw_upload_free() function in
    sysfs_upload.c to handle the firmware-upload specific memory frees
    and incorporate the missing kfree call for the fw_upload structure.
    
    Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Russ Weight <russell.h.weight@intel.com>
    Link: https://lore.kernel.org/r/20220831002518.465274-1-russell.h.weight@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d380d40930a674c520a5b55f3be1eb17dc634ebc
Author: Russ Weight <russell.h.weight@intel.com>
Date:   Mon Aug 29 10:45:57 2022 -0700

    firmware_loader: Fix use-after-free during unregister
    
    commit 8b40c38e37492b5bdf8e95b46b5cca9517a9957a upstream.
    
    In the following code within firmware_upload_unregister(), the call to
    device_unregister() could result in the dev_release function freeing the
    fw_upload_priv structure before it is dereferenced for the call to
    module_put(). This bug was found by the kernel test robot using
    CONFIG_KASAN while running the firmware selftests.
    
      device_unregister(&fw_sysfs->dev);
      module_put(fw_upload_priv->module);
    
    The problem is fixed by copying fw_upload_priv->module to a local variable
    for use when calling device_unregister().
    
    Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support")
    Cc: stable <stable@kernel.org>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
    Signed-off-by: Russ Weight <russell.h.weight@intel.com>
    Link: https://lore.kernel.org/r/20220829174557.437047-1-russell.h.weight@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0578e603065f120a8759b75e0d6c216c7078a39
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Aug 29 10:05:30 2022 +0200

    misc: fastrpc: fix memory corruption on open
    
    commit d245f43aab2b61195d8ebb64cef7b5a08c590ab4 upstream.
    
    The probe session-duplication overflow check incremented the session
    count also when there were no more available sessions so that memory
    beyond the fixed-size slab-allocated session array could be corrupted in
    fastrpc_session_alloc() on open().
    
    Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
    Cc: stable@vger.kernel.org      # 5.1
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220829080531.29681-3-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0425c2facd9166fa083f90c9f3187ace0c7837a
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Aug 29 10:05:29 2022 +0200

    misc: fastrpc: fix memory corruption on probe
    
    commit 9baa1415d9abdd1e08362ea2dcfadfacee8690b5 upstream.
    
    Add the missing sanity check on the probed-session count to avoid
    corrupting memory beyond the fixed-size slab-allocated session array
    when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
    devicetree.
    
    Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
    Cc: stable@vger.kernel.org      # 5.1
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220829080531.29681-2-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5461b547c204c92377d7e6c928ce01ebb31ac9e4
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Fri Jul 22 15:07:20 2022 +0200

    iio: adc: mcp3911: use correct formula for AD conversion
    
    commit 9e2238e3ae40d371a1130226e0e740aa1601efa6 upstream.
    
    The ADC conversion is actually not rail-to-rail but with a factor 1.5.
    Make use of this factor when calculating actual voltage.
    
    Fixes: 3a89b289df5d ("iio: adc: add support for mcp3911")
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220722130726.7627-4-marcus.folkesson@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2838fdab0c3def0176fceca88e29d8be8a4fcc6f
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Fri Jul 22 15:07:19 2022 +0200

    iio: adc: mcp3911: correct "microchip,device-addr" property
    
    commit cfbd76d5c9c449739bb74288d982bccf9ff822f4 upstream.
    
    Go for the right property name that is documented in the bindings.
    
    Fixes: 3a89b289df5d ("iio: adc: add support for mcp3911")
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220722130726.7627-3-marcus.folkesson@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76608a25fc6c45b00306970f90319f93ffa50265
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Fri Aug 19 11:51:07 2022 +0300

    iio: ad7292: Prevent regulator double disable
    
    commit 22b4277641c6823ec03d5b1cd82628e5e53e75b7 upstream.
    
    The ad7292 tries to add an devm_action for disabling a regulator at
    device detach using devm_add_action_or_reset(). The
    devm_add_action_or_reset() does call the release function should adding
    action fail. The driver inspects the value returned by
    devm_add_action_or_reset() and manually calls regulator_disable() if
    adding the action has failed. This leads to double disable and messes
    the enable count for regulator.
    
    Do not manually call disable if devm_add_action_or_reset() fails.
    
    Fixes: 506d2e317a0a ("iio: adc: Add driver support for AD7292")
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Tested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
    Link: https://lore.kernel.org/r/Yv9O+9sxU7gAv3vM@fedora
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f7f49d8135cfe137c81316af64678f4dca1b82b
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Aug 7 08:37:43 2022 +0200

    iio: light: cm3605: Fix an error handling path in cm3605_probe()
    
    commit 160905549e663019e26395ed9d66c24ee2cf5187 upstream.
    
    The commit in Fixes also introduced a new error handling path which should
    goto the existing error handling path.
    Otherwise some resources leak.
    
    Fixes: 0d31d91e6145 ("iio: light: cm3605: Make use of the helper function dev_err_probe()")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/0e186de2c125b3e17476ebf9c54eae4a5d66f994.1659854238.git.christophe.jaillet@wanadoo.fr
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b533b9d3a0d1327cbb31c201dc8dbbf98c8bfe3c
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sat Aug 27 20:36:27 2022 -0700

    Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag
    
    commit 98e01215708b6d416345465c09dce2bd4868c67a upstream.
    
    syzbot is reporting hung task at __input_unregister_device() [1], for
    iforce_close() waiting at wait_event_interruptible() with dev->mutex held
    is blocking input_disconnect_device() from __input_unregister_device().
    
    It seems that the cause is simply that commit c2b27ef672992a20 ("Input:
    iforce - wait for command completion when closing the device") forgot to
    call wake_up() after clear_bit().
    
    Fix this problem by introducing a helper that calls clear_bit() followed
    by wake_up_all().
    
    Reported-by: syzbot <syzbot+deb6abc36aad4008f407@syzkaller.appspotmail.com>
    Fixes: c2b27ef672992a20 ("Input: iforce - wait for command completion when closing the device")
    Tested-by: syzbot <syzbot+deb6abc36aad4008f407@syzkaller.appspotmail.com>
    Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
    Co-developed-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Link: https://lore.kernel.org/r/887021c3-4f13-40ce-c8b9-aa6e09faa3a7@I-love.SAKURA.ne.jp
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e05af2f827bac7f446a715927ab51ac052639b5
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Sun Aug 21 18:15:27 2022 +0800

    tty: serial: lpuart: disable flow control while waiting for the transmit engine to complete
    
    commit d5a2e0834364377a5d5a2fff1890a0b3f0bafd1f upstream.
    
    When the user initializes the uart port, and waits for the transmit
    engine to complete in lpuart32_set_termios(), if the UART TX fifo has
    dirty data and the UARTMODIR enable the flow control, the TX fifo may
    never be empty. So here we should disable the flow control first to make
    sure the transmit engin can complete.
    
    Fixes: 380c966c093e ("tty: serial: fsl_lpuart: add 32-bit register interface support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Link: https://lore.kernel.org/r/20220821101527.10066-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f130dffc3153c65c590106a32cdf3171fd4ef6d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Aug 18 15:57:20 2022 +0200

    musb: fix USB_MUSB_TUSB6010 dependency
    
    commit a3f2fd22743fc56dd5e3896a3fbddd276df1577f upstream.
    
    Turning on NOP_USB_XCEIV as builtin broke the TUSB6010 driver because
    of an older issue with the depencency.
    
    It is not necessary to forbid NOP_USB_XCEIV=y in combination with
    USB_MUSB_HDRC=m, but only the reverse, which causes the link failure
    from the original Kconfig change.
    
    Use the correct dependency to still allow NOP_USB_XCEIV=n or
    NOP_USB_XCEIV=y but forbid NOP_USB_XCEIV=m when USB_MUSB_HDRC=m
    to fix the multi_v7_defconfig for tusb.
    
    Fixes: ab37a7a890c1 ("ARM: multi_v7_defconfig: Make NOP_USB_XCEIV driver built-in")
    Fixes: c0442479652b ("usb: musb: Fix randconfig build issues for Kconfig options")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20220818135737.3143895-10-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c904fe03c4bd1f356a58797d39e2a5d0ca15cefc
Author: Helge Deller <deller@gmx.de>
Date:   Sat Jul 30 20:50:18 2022 +0200

    vt: Clear selection before changing the font
    
    commit 566f9c9f89337792070b5a6062dff448b3e7977f upstream.
    
    When changing the console font with ioctl(KDFONTOP) the new font size
    can be bigger than the previous font. A previous selection may thus now
    be outside of the new screen size and thus trigger out-of-bounds
    accesses to graphics memory if the selection is removed in
    vc_do_resize().
    
    Prevent such out-of-memory accesses by dropping the selection before the
    various con_font_set() console handlers are called.
    
    Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
    Cc: stable <stable@kernel.org>
    Tested-by: Khalid Masum <khalid.masum.92@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Link: https://lore.kernel.org/r/YuV9apZGNmGfjcor@p100
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b08d4f97233d8e58fff2fd9d5f86397a49733c5
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Aug 23 21:59:52 2022 +1000

    powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
    
    commit 91926d8b7e71aaf5f84f0cf208fc5a8b7a761050 upstream.
    
    The semi-recent changes to MSR handling when entering RTAS (firmware)
    cause crashes on IBM Cell machines. An example trace:
    
      kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
      BUG: Unable to handle kernel instruction fetch
      Faulting instruction address: 0x2fff01a8
      Oops: Kernel access of bad area, sig: 11 [#1]
      BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W          6.0.0-rc2-00433-gede0a8d3307a #207
      NIP:  000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000
      REGS: c0000000015236b0 TRAP: 0400   Tainted: G        W           (6.0.0-rc2-00433-gede0a8d3307a)
      MSR:  0000000008001002 <ME,RI>  CR: 00000000  XER: 20000000
      ...
      NIP 0x2fff01a8
      LR  0x32608
      Call Trace:
        0xc00000000143c5f8 (unreliable)
        .rtas_call+0x224/0x320
        .rtas_get_boot_time+0x70/0x150
        .read_persistent_clock64+0x114/0x140
        .read_persistent_wall_and_boot_offset+0x24/0x80
        .timekeeping_init+0x40/0x29c
        .start_kernel+0x674/0x8f0
        start_here_common+0x1c/0x50
    
    Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell
    machines Linux runs with MSR[HV] set but also uses RTAS, provided by
    SLOF.
    
    Fix it by copying the MSR[HV] bit from the MSR value we've just read
    using mfmsr into the value used for RTAS.
    
    It seems like we could also fix it using an #ifdef CELL to set MSR[HV],
    but that doesn't work because it's possible to build a single kernel
    image that runs on both Cell native and pseries.
    
    Fixes: b6b1c3ce06ca ("powerpc/rtas: Keep MSR[RI] set when calling RTAS")
    Cc: stable@vger.kernel.org # v5.19+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Jordan Niethe <jniethe5@gmail.com>
    Link: https://lore.kernel.org/r/20220823115952.1203106-2-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b29ee155151217a5c90c9fd9233e16466cf90e43
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Aug 21 01:51:29 2022 +0900

    powerpc: align syscall table for ppc32
    
    commit c7acee3d2f128a38b68fb7af85dbbd91bfd0b4ad upstream.
    
    Christophe Leroy reported that commit 7b4537199a4a ("kbuild: link
    symbol CRCs at final link,  removing CONFIG_MODULE_REL_CRCS") broke
    mpc85xx_defconfig + CONFIG_RELOCATABLE=y.
    
        LD      vmlinux
        SYSMAP  System.map
        SORTTAB vmlinux
        CHKREL  vmlinux
      WARNING: 451 bad relocations
      c0b312a9 R_PPC_UADDR32     .head.text-0x3ff9ed54
      c0b312ad R_PPC_UADDR32     .head.text-0x3ffac224
      c0b312b1 R_PPC_UADDR32     .head.text-0x3ffb09f4
      c0b312b5 R_PPC_UADDR32     .head.text-0x3fe184dc
      c0b312b9 R_PPC_UADDR32     .head.text-0x3fe183a8
          ...
    
    The compiler emits a bunch of R_PPC_UADDR32, which is not supported by
    arch/powerpc/kernel/reloc_32.S.
    
    The reason is there exists an unaligned symbol.
    
      $ powerpc-linux-gnu-nm -n vmlinux
        ...
      c0b31258 d spe_aligninfo
      c0b31298 d __func__.0
      c0b312a9 D sys_call_table
      c0b319b8 d __func__.0
    
    Commit 7b4537199a4a is not the root cause. Even before that, I can
    reproduce the same issue for mpc85xx_defconfig + CONFIG_RELOCATABLE=y
    + CONFIG_MODVERSIONS=n.
    
    It is just that nobody noticed because when CONFIG_MODVERSIONS is
    enabled, a __crc_* symbol inserted before sys_call_table was hiding the
    unalignment issue.
    
    Adding alignment to the syscall table for ppc32 fixes the issue.
    
    Cc: stable@vger.kernel.org
    Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Trim change log discussion, add Cc stable]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/lkml/38605f6a-a568-f884-f06f-ea4da5b214f0@csgroup.eu/
    Link: https://lore.kernel.org/r/20220820165129.1147589-1-masahiroy@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b539b5f058b3d1d98e4337dfe2601702f0228d8
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Aug 23 21:59:51 2022 +1000

    Revert "powerpc: Remove unused FW_FEATURE_NATIVE references"
    
    commit 310d1344e3c58cc2d625aa4e52cfcb7d8a26fcbf upstream.
    
    This reverts commit 79b74a68486765a4fe685ac4069bc71366c538f5.
    
    It broke booting on IBM Cell machines when the kernel is also built with
    CONFIG_PPC_PS3=y.
    
    That's because FW_FEATURE_NATIVE_ALWAYS = 0 does have an important
    effect, which is to clear the PS3 ALWAYS features from
    FW_FEATURE_ALWAYS.
    
    Note that CONFIG_PPC_NATIVE has since been renamed
    CONFIG_PPC_HASH_MMU_NATIVE.
    
    Fixes: 79b74a684867 ("powerpc: Remove unused FW_FEATURE_NATIVE references")
    Cc: stable@vger.kernel.org # v5.17+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220823115952.1203106-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaffa77b835958f3c07839d183cf0c92b57dc554
Author: Grzegorz Szymaszek <gszymaszek@short.pl>
Date:   Tue Aug 2 19:18:44 2022 +0200

    staging: r8188eu: add firmware dependency
    
    commit b2fa9e13bbf101c662c4cd974608242a0db98cfc upstream.
    
    The old rtl8188eu module, removed in commit 55dfa29b43d2 ("staging:
    rtl8188eu: remove rtl8188eu driver from staging dir") (Linux kernel
    v5.15-rc1), required (through a MODULE_FIRMWARE call()) the
    rtlwifi/rtl8188eufw.bin firmware file, which the new r8188eu driver no
    longer requires.
    
    I have tested a few RTL8188EUS-based Wi-Fi cards and, while supported by
    both drivers, they do not work when using the new one and the firmware
    wasn't manually loaded. According to Larry Finger, the module
    maintainer, all such cards need the firmware and the driver should
    depend on it (see the linked mails).
    
    Add a proper MODULE_FIRMWARE() call, like it was done in the old driver.
    
    Thanks to Greg Kroah-Hartman and Larry Finger for quick responses to my
    questions.
    
    Cc: stable <stable@kernel.org>
    Link: https://answers.launchpad.net/ubuntu/+source/linux-meta-hwe-5.15/+question/702611
    Link: https://lore.kernel.org/lkml/YukkBu3TNODO3or9@nx64de-df6d00/
    Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
    Link: https://lore.kernel.org/r/YulcdKfhA8dPQ78s@nx64de-df6d00
    Acked-by: Phillip Potter <phil@philpotter.co.uk>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02c09dbb1554c22d9a303bf766812dafe3105d9f
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Aug 14 12:50:27 2022 -0500

    staging: r8188eu: Add Rosewill USB-N150 Nano to device tables
    
    commit e01f5c8d6af231b3b09e23c1fe8a4057cdcc4e42 upstream.
    
    This device is reported as using the RTL8188EUS chip.
    
    It has the improbable USB ID of 0bda:ffef, which normally would belong
    to Realtek, but this ID works for the reporter.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20220814175027.2689-1-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1727def850904e4b8ba384043775672841663a1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Aug 30 17:55:07 2022 +0300

    staging: rtl8712: fix use after free bugs
    
    commit e230a4455ac3e9b112f0367d1b8e255e141afae0 upstream.
    
    _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()
    functions don't do anything except free the "pcmd" pointer.  It
    results in a use after free.  Delete them.
    
    Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
    Cc: stable <stable@kernel.org>
    Reported-by: Zheng Wang <hackerzheng666@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/Yw4ASqkYcUhUfoY2@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 418a52be5d6bcb610d9b89ea4f1651037306f3d0
Author: Sergiu Moga <sergiu.moga@microchip.com>
Date:   Wed Aug 24 17:29:03 2022 +0300

    tty: serial: atmel: Preserve previous USART mode if RS485 disabled
    
    commit 692a8ebcfc24f4a5bea0eb2967e450f584193da6 upstream.
    
    Whenever the atmel_rs485_config() driver method would be called,
    the USART mode is reset to normal mode before even checking if
    RS485 flag is set, thus resulting in losing the previous USART
    mode in the case where the checking fails.
    
    Some tools, such as `linux-serial-test`, lead to the driver calling
    this method when doing the setup of the serial port: after setting the
    port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.),
    `linux-serial-test` tries to enable/disable RS485 depending on
    the commandline arguments that were passed.
    
    Example of how this issue could reveal itself:
    When doing a serial communication with Hardware Flow Control through
    `linux-serial-test`, the tool would lead to the driver roughly doing
    the following:
    - set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the
    ATMEL_US_MR register) through the atmel_set_termios() to enable
    Hardware Flow Control
    - disable RS485 through the atmel_config_rs485() method
    Thus, when the latter is called, the mode will be reset and the
    previously set bit is unset, leaving USART in normal mode instead of
    the expected Hardware Flow Control mode.
    
    This fix ensures that this reset is only done if the checking for
    RS485 succeeds and that the previous mode is preserved otherwise.
    
    Fixes: e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
    Cc: stable <stable@kernel.org>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com>
    Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@microchip.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a17353e3ce85a76bb1502ed3c16115f62ebc0c01
Author: Shenwei Wang <shenwei.wang@nxp.com>
Date:   Fri Aug 5 09:45:29 2022 -0500

    serial: fsl_lpuart: RS485 RTS polariy is inverse
    
    commit 846651eca073e2e02e37490a4a52752415d84781 upstream.
    
    The setting of RS485 RTS polarity is inverse in the current driver.
    
    When the property of 'rs485-rts-active-low' is enabled in the dts node,
    the RTS signal should be LOW during sending. Otherwise, if there is no
    such a property, the RTS should be HIGH during sending.
    
    Fixes: 03895cf41d18 ("tty: serial: fsl_lpuart: Add support for RS-485")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Nicolas Diaz <nicolas.diaz@nxp.com>
    Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
    Link: https://lore.kernel.org/r/20220805144529.604856-1-shenwei.wang@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad936d6dc25b00ae88bb2e9772ae68d2be32c518
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Tue Aug 23 23:19:35 2022 +0300

    platform/mellanox: mlxreg-lc: Fix locking issue
    
    [ Upstream commit 1e092b7faa6b507125b69c92a51bb22c2d549d37 ]
    
    Fix locking issues:
    - mlxreg_lc_state_update() takes a lock when set or clear
      "MLXREG_LC_POWERED".
    - All the devices can be deleted before MLXREG_LC_POWERED flag is cleared.
    
    To fix it:
    - Add lock() / unlock() at the beginning / end of
      mlxreg_lc_event_handler() and remove locking from
      mlxreg_lc_power_on_off() and mlxreg_lc_enable_disable()
    - Add locked version of mlxreg_lc_state_update() -
      mlxreg_lc_state_update_locked() for using outside
      mlxreg_lc_event_handler().
    
    (2) Remove redundant NULL check for of if 'data->notifier'.
    
    Fixes: 62f9529b8d5c87b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20220823201937.46855-3-vadimp@nvidia.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit daa0d0282b3192d9a473ee038b8201f38d43dfca
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Tue Aug 23 23:19:34 2022 +0300

    platform/mellanox: mlxreg-lc: Fix coverity warning
    
    [ Upstream commit 17c2bd6bea4c32fe691c1f9ebcc20fd48d77454a ]
    
    Fix smatch warning:
    drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero to 'PTR_ERR'
    by removing 'err = PTR_ERR(regmap)'.
    
    Fixes: b4b830a34d80 ("platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Link: https://lore.kernel.org/r/20220823201937.46855-2-vadimp@nvidia.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 357321557920c805de2b14832002465c320eea4f
Author: Waiman Long <longman@redhat.com>
Date:   Fri Aug 12 14:30:33 2022 -0400

    mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock
    
    [ Upstream commit 0495e337b7039191dfce6e03f5f830454b1fae6b ]
    
    A circular locking problem is reported by lockdep due to the following
    circular locking dependency.
    
      +--> cpu_hotplug_lock --> slab_mutex --> kn->active --+
      |                                                     |
      +-----------------------------------------------------+
    
    The forward cpu_hotplug_lock ==> slab_mutex ==> kn->active dependency
    happens in
    
      kmem_cache_destroy(): cpus_read_lock(); mutex_lock(&slab_mutex);
      ==> sysfs_slab_unlink()
          ==> kobject_del()
              ==> kernfs_remove()
                  ==> __kernfs_remove()
                      ==> kernfs_drain(): rwsem_acquire(&kn->dep_map, ...);
    
    The backward kn->active ==> cpu_hotplug_lock dependency happens in
    
      kernfs_fop_write_iter(): kernfs_get_active();
      ==> slab_attr_store()
          ==> cpu_partial_store()
              ==> flush_all(): cpus_read_lock()
    
    One way to break this circular locking chain is to avoid holding
    cpu_hotplug_lock and slab_mutex while deleting the kobject in
    sysfs_slab_unlink() which should be equivalent to doing a write_lock
    and write_unlock pair of the kn->active virtual lock.
    
    Since the kobject structures are not protected by slab_mutex or the
    cpu_hotplug_lock, we can certainly release those locks before doing
    the delete operation.
    
    Move sysfs_slab_unlink() and sysfs_slab_release() to the newly
    created kmem_cache_release() and call it outside the slab_mutex &
    cpu_hotplug_lock critical sections. There will be a slight delay
    in the deletion of sysfs files if kmem_cache_release() is called
    indirectly from a work function.
    
    Fixes: 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
    Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
    Acked-by: David Rientjes <rientjes@google.com>
    Link: https://lore.kernel.org/all/YwOImVd+nRUsSAga@hyeyoo/
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b823c22561d477934c89f496a43772ea4fd956f9
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Fri Jul 8 11:47:47 2022 +0100

    soundwire: qcom: fix device status array range
    
    [ Upstream commit 4ef3f2aff1267bfa6d5a90c42a30b927b8aa239b ]
    
    This patch updates device status array range from 11 to 12 as we will
    be reading status from device number 0 to device number 11 inclusive.
    
    Without this patch we can potentially access status array out of range
    during auto-enumeration.
    
    Fixes: aa1262ca6695 ("soundwire: qcom: Check device status before reading devid")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220708104747.8722-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74d2d7a905d158be3be2afcd81ae6115ec951011
Author: Yacan Liu <liuyacan@corp.netease.com>
Date:   Tue Aug 30 23:23:14 2022 +0800

    net/smc: Remove redundant refcount increase
    
    [ Upstream commit a8424a9b4522a3ab9f32175ad6d848739079071f ]
    
    For passive connections, the refcount increment has been done in
    smc_clcsock_accept()-->smc_sock_alloc().
    
    Fixes: 3b2dec2603d5 ("net/smc: restructure client and server code in af_smc")
    Signed-off-by: Yacan Liu <liuyacan@corp.netease.com>
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220830152314.838736-1-liuyacan@corp.netease.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e789ee9b07456bbee663040ddad504ebc3957e3
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Aug 31 20:01:32 2022 -0700

    Revert "sch_cake: Return __NET_XMIT_STOLEN when consuming enqueued skb"
    
    [ Upstream commit 0b4f688d53fdc2a731b9d9cdf0c96255bc024ea6 ]
    
    This reverts commit 90fabae8a2c225c4e4936723c38857887edde5cc.
    
    Patch was applied hastily, revert and let the v2 be reviewed.
    
    Fixes: 90fabae8a2c2 ("sch_cake: Return __NET_XMIT_STOLEN when consuming enqueued skb")
    Link: https://lore.kernel.org/all/87wnao2ha3.fsf@toke.dk/
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c4ef05929299c31d706fefe1c9f85d8901081df
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 30 11:56:55 2022 -0700

    tcp: annotate data-race around challenge_timestamp
    
    [ Upstream commit 8c70521238b7863c2af607e20bcba20f974c969b ]
    
    challenge_timestamp can be read an written by concurrent threads.
    
    This was expected, but we need to annotate the race to avoid potential issues.
    
    Following patch moves challenge_timestamp and challenge_count
    to per-netns storage to provide better isolation.
    
    Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca94a50666767a1186f783ac515a5e11c883c386
Author: Toke Høiland-Jørgensen <toke@toke.dk>
Date:   Wed Aug 31 11:21:03 2022 +0200

    sch_cake: Return __NET_XMIT_STOLEN when consuming enqueued skb
    
    [ Upstream commit 90fabae8a2c225c4e4936723c38857887edde5cc ]
    
    When the GSO splitting feature of sch_cake is enabled, GSO superpackets
    will be broken up and the resulting segments enqueued in place of the
    original skb. In this case, CAKE calls consume_skb() on the original skb,
    but still returns NET_XMIT_SUCCESS. This can confuse parent qdiscs into
    assuming the original skb still exists, when it really has been freed. Fix
    this by adding the __NET_XMIT_STOLEN flag to the return value in this case.
    
    Fixes: 0c850344d388 ("sch_cake: Conditionally split GSO segments")
    Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231
    Link: https://lore.kernel.org/r/20220831092103.442868-1-toke@toke.dk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f865976baa85915c7672f351b74d5974b93215f6
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sat Aug 27 11:13:14 2022 -0700

    kcm: fix strp_init() order and cleanup
    
    [ Upstream commit 8fc29ff3910f3af08a7c40a75d436b5720efe2bf ]
    
    strp_init() is called just a few lines above this csk->sk_user_data
    check, it also initializes strp->work etc., therefore, it is
    unnecessary to call strp_done() to cancel the freshly initialized
    work.
    
    And if sk_user_data is already used by KCM, psock->strp should not be
    touched, particularly strp->work state, so we need to move strp_init()
    after the csk->sk_user_data check.
    
    This also makes a lockdep warning reported by syzbot go away.
    
    Reported-and-tested-by: syzbot+9fc084a4348493ef65d2@syzkaller.appspotmail.com
    Reported-by: syzbot+e696806ef96cdd2d87cd@syzkaller.appspotmail.com
    Fixes: e5571240236c ("kcm: Check if sk_user_data already set in kcm_attach")
    Fixes: dff8baa26117 ("kcm: Call strp_stop before strp_done in kcm_attach")
    Cc: Tom Herbert <tom@herbertland.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/r/20220827181314.193710-1-xiyou.wangcong@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1579573b69d60f48b1ba6e68205aad2fbb3be083
Author: David Thompson <davthompson@nvidia.com>
Date:   Fri Aug 26 11:59:16 2022 -0400

    mlxbf_gige: compute MDIO period based on i1clk
    
    [ Upstream commit 3a1a274e933fca73fdc960cb1f60636cd285a265 ]
    
    This patch adds logic to compute the MDIO period based on
    the i1clk, and thereafter write the MDIO period into the YU
    MDIO config register. The i1clk resource from the ACPI table
    is used to provide addressing to YU bootrecord PLL registers.
    The values in these registers are used to compute MDIO period.
    If the i1clk resource is not present in the ACPI table, then
    the current default hardcorded value of 430Mhz is used.
    The i1clk clock value of 430MHz is only accurate for boards
    with BF2 mid bin and main bin SoCs. The BF2 high bin SoCs
    have i1clk = 500MHz, but can support a slower MDIO period.
    
    Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver")
    Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
    Signed-off-by: David Thompson <davthompson@nvidia.com>
    Link: https://lore.kernel.org/r/20220826155916.12491-1-davthompson@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4854a59b9a9c0ea3829ec86842f29d0a6bc2c22a
Author: Xin Yin <yinxin.x@bytedance.com>
Date:   Thu Aug 25 10:09:45 2022 +0800

    cachefiles: make on-demand request distribution fairer
    
    [ Upstream commit 1122f40072731525c06b1371cfa30112b9b54d27 ]
    
    For now, enqueuing and dequeuing on-demand requests all start from
    idx 0, this makes request distribution unfair. In the weighty
    concurrent I/O scenario, the request stored in higher idx will starve.
    
    Searching requests cyclically in cachefiles_ondemand_daemon_read,
    makes distribution fairer.
    
    Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie")
    Reported-by: Yongqing Li <liyongqing@bytedance.com>
    Signed-off-by: Xin Yin <yinxin.x@bytedance.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeffle Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220817065200.11543-1-yinxin.x@bytedance.com/ # v1
    Link: https://lore.kernel.org/r/20220825020945.2293-1-yinxin.x@bytedance.com/ # v2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dae646810dc8c03c4850dc6128510d83c34ff70c
Author: Sun Ke <sunke32@huawei.com>
Date:   Fri Aug 26 10:35:15 2022 +0800

    cachefiles: fix error return code in cachefiles_ondemand_copen()
    
    [ Upstream commit c93ccd63b18c8d108c57b2bb0e5f3b058b9d2029 ]
    
    The cache_size field of copen is specified by the user daemon.
    If cache_size < 0, then the OPEN request is expected to fail,
    while copen itself shall succeed. However, returning 0 is indeed
    unexpected when cache_size is an invalid error code.
    
    Fix this by returning error when cache_size is an invalid error code.
    
    Changes
    =======
    v4: update the code suggested by Dan
    v3: update the commit log suggested by Jingbo.
    
    Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie")
    Signed-off-by: Sun Ke <sunke32@huawei.com>
    Suggested-by: Jeffle Xu <jefflexu@linux.alibaba.com>
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20220818111935.1683062-1-sunke32@huawei.com/ # v2
    Link: https://lore.kernel.org/r/20220818125038.2247720-1-sunke32@huawei.com/ # v3
    Link: https://lore.kernel.org/r/20220826023515.3437469-1-sunke32@huawei.com/ # v4
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 031089e2eb2e9e691a608b1c2072c2f8c077a5e3
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Aug 27 23:38:15 2022 +0800

    ethernet: rocker: fix sleep in atomic context bug in neigh_timer_handler
    
    [ Upstream commit c0955bf957be4bead01fae1d791476260da7325d ]
    
    The function neigh_timer_handler() is a timer handler that runs in an
    atomic context. When used by rocker, neigh_timer_handler() calls
    "kzalloc(.., GFP_KERNEL)" that may sleep. As a result, the sleep in
    atomic context bug will happen. One of the processes is shown below:
    
    ofdpa_fib4_add()
     ...
     neigh_add_timer()
    
    (wait a timer)
    
    neigh_timer_handler()
     neigh_release()
      neigh_destroy()
       rocker_port_neigh_destroy()
        rocker_world_port_neigh_destroy()
         ofdpa_port_neigh_destroy()
          ofdpa_port_ipv4_neigh()
           kzalloc(sizeof(.., GFP_KERNEL) //may sleep
    
    This patch changes the gfp_t parameter of kzalloc() from GFP_KERNEL to
    GFP_ATOMIC in order to mitigate the bug.
    
    Fixes: 00fc0c51e35b ("rocker: Change world_ops API and implementation to be switchdev independant")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8164b6c32f290609d98d78f0e4f4cf567b29d51e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 26 18:00:30 2022 +0300

    net: lan966x: improve error handle in lan966x_fdma_rx_get_frame()
    
    [ Upstream commit 13a9d08c296228d18289de60b83792c586e1d073 ]
    
    Don't just print a warning.  Clean up and return an error as well.
    
    Fixes: c8349639324a ("net: lan966x: Add FDMA functionality")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Link: https://lore.kernel.org/r/YwjgDm/SVd5c1tQU@kili
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81b7493d7415b861f804f649b612934e35bced36
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Tue Aug 30 08:40:55 2022 +0200

    net: phy: micrel: Make the GPIO to be non-exclusive
    
    [ Upstream commit 4a4ce82212ef014d70f486a427005b2b5bab8e34 ]
    
    The same GPIO line can be shared by multiple phys for the coma mode pin.
    If that is the case then, all the other phys that share the same line
    will failed to be probed because the access to the gpio line is not
    non-exclusive.
    Fix this by making access to the gpio line to be nonexclusive using flag
    GPIOD_FLAGS_BIT_NONEXCLUSIVE. This allows all the other PHYs to be
    probed.
    
    Fixes: 738871b09250ee ("net: phy: micrel: add coma mode GPIO")
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Link: https://lore.kernel.org/r/20220830064055.2340403-1-horatiu.vultur@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c6c522857151ac00150fd01baeebf231fb7d142
Author: Wang Hai <wanghai38@huawei.com>
Date:   Fri Aug 26 17:00:55 2022 +0800

    net/sched: fix netdevice reference leaks in attach_default_qdiscs()
    
    [ Upstream commit f612466ebecb12a00d9152344ddda6f6345f04dc ]
    
    In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails
    to attach qdisc because there is no memory in attach_one_default_qdisc().
    Then dev->qdisc will be noop_qdisc by default. But the other queues may be
    able to successfully attach to default qdisc.
    
    In this case, the fallback to noqueue process will be triggered. If the
    original attached qdisc is not released and a new one is directly
    attached, this will cause netdevice reference leaks.
    
    The following is the bug log:
    
    veth0: default qdisc (fq_codel) fail, fallback to noqueue
    unregister_netdevice: waiting for veth0 to become free. Usage count = 32
    leaked reference.
     qdisc_alloc+0x12e/0x210
     qdisc_create_dflt+0x62/0x140
     attach_one_default_qdisc.constprop.41+0x44/0x70
     dev_activate+0x128/0x290
     __dev_open+0x12a/0x190
     __dev_change_flags+0x1a2/0x1f0
     dev_change_flags+0x23/0x60
     do_setlink+0x332/0x1150
     __rtnl_newlink+0x52f/0x8e0
     rtnl_newlink+0x43/0x70
     rtnetlink_rcv_msg+0x140/0x3b0
     netlink_rcv_skb+0x50/0x100
     netlink_unicast+0x1bb/0x290
     netlink_sendmsg+0x37c/0x4e0
     sock_sendmsg+0x5f/0x70
     ____sys_sendmsg+0x208/0x280
    
    Fix this bug by clearing any non-noop qdiscs that may have been assigned
    before trying to re-attach.
    
    Fixes: bf6dba76d278 ("net: sched: fallback to qdisc noqueue if default qdisc setup fail")
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Link: https://lore.kernel.org/r/20220826090055.24424-1-wanghai38@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb155f6597cd7bc3aeed668c3bb15fc3b7cb257d
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Fri Aug 26 09:39:30 2022 +0800

    net: sched: tbf: don't call qdisc_put() while holding tree lock
    
    [ Upstream commit b05972f01e7d30419987a1f221b5593668fd6448 ]
    
    The issue is the same to commit c2999f7fb05b ("net: sched: multiq: don't
    call qdisc_put() while holding tree lock"). Qdiscs call qdisc_put() while
    holding sch tree spinlock, which results sleeping-while-atomic BUG.
    
    Fixes: c266f64dbfa2 ("net: sched: protect block state with mutex")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Link: https://lore.kernel.org/r/20220826013930.340121-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2798203315f4729bab0b917bf4c17a159abf9f8
Author: Łukasz Bartosik <lb@semihalf.com>
Date:   Tue Feb 1 16:33:54 2022 +0100

    drm/i915: fix null pointer dereference
    
    [ Upstream commit 458ec0c8f35963626ccd51c3d50b752de5f1b9d4 ]
    
    Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
    The root cause is null pointer defeference of bi_next
    in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
    
    BUG: kernel NULL pointer dereference, address: 000000000000002e
    PGD 0 P4D 0
    Oops: 0002 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 1 Comm: swapper/0 Tainted: G     U            5.17.0-rc1
    Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
    RIP: 0010:tgl_get_bw_info+0x2de/0x510
    ...
    [    2.554467] Call Trace:
    [    2.554467]  <TASK>
    [    2.554467]  intel_bw_init_hw+0x14a/0x434
    [    2.554467]  ? _printk+0x59/0x73
    [    2.554467]  ? _dev_err+0x77/0x91
    [    2.554467]  i915_driver_hw_probe+0x329/0x33e
    [    2.554467]  i915_driver_probe+0x4c8/0x638
    [    2.554467]  i915_pci_probe+0xf8/0x14e
    [    2.554467]  ? _raw_spin_unlock_irqrestore+0x12/0x2c
    [    2.554467]  pci_device_probe+0xaa/0x142
    [    2.554467]  really_probe+0x13f/0x2f4
    [    2.554467]  __driver_probe_device+0x9e/0xd3
    [    2.554467]  driver_probe_device+0x24/0x7c
    [    2.554467]  __driver_attach+0xba/0xcf
    [    2.554467]  ? driver_attach+0x1f/0x1f
    [    2.554467]  bus_for_each_dev+0x8c/0xc0
    [    2.554467]  bus_add_driver+0x11b/0x1f7
    [    2.554467]  driver_register+0x60/0xea
    [    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
    [    2.554467]  i915_init+0x2c/0xb9
    [    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
    [    2.554467]  do_one_initcall+0x12e/0x2b3
    [    2.554467]  do_initcall_level+0xd6/0xf3
    [    2.554467]  do_initcalls+0x4e/0x79
    [    2.554467]  kernel_init_freeable+0xed/0x14d
    [    2.554467]  ? rest_init+0xc1/0xc1
    [    2.554467]  kernel_init+0x1a/0x120
    [    2.554467]  ret_from_fork+0x1f/0x30
    [    2.554467]  </TASK>
    ...
    Kernel panic - not syncing: Fatal exception
    
    Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
    Signed-off-by: Łukasz Bartosik <lb@semihalf.com>
    Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220201153354.11971-1-lukasz.bartosik@semihalf.com
    (cherry picked from commit c247cd03898c4c43c3bce6d4014730403bc13032)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca537da42fbd92d74ab998c8cc63a1af37c4046f
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Thu Aug 25 13:36:44 2022 +0200

    net: dsa: xrs700x: Use irqsave variant for u64 stats update
    
    [ Upstream commit 3f8ae9fe0409698799e173f698b714f34570b64b ]
    
    xrs700x_read_port_counters() updates the stats from a worker using the
    u64_stats_update_begin() version. This is okay on 32-UP since on the
    reader side preemption is disabled.
    On 32bit-SMP the writer can be preempted by the reader at which point
    the reader will spin on the seqcount until writer continues and
    completes the update.
    
    Assigning the mib_mutex mutex to the underlying seqcount would ensure
    proper synchronisation. The API for that on the u64_stats_init() side
    isn't available. Since it is the only user, just use disable interrupts
    during the update.
    
    Use u64_stats_update_begin_irqsave() on the writer side to ensure an
    uninterrupted update.
    
    Fixes: ee00b24f32eb8 ("net: dsa: add Arrow SpeedChips XRS700x driver")
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: George McCollister <george.mccollister@gmail.com>
    Cc: Vivien Didelot <vivien.didelot@gmail.com>
    Cc: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: George McCollister <george.mccollister@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 321d2a2b95206c830308185fbba0a08ec87145ea
Author: Tianyu Yuan <tianyu.yuan@corigine.com>
Date:   Thu Aug 25 10:08:45 2022 +0200

    nfp: flower: fix ingress police using matchall filter
    
    [ Upstream commit ebe5555c2f34505cdb1ae5c3de8b24e33740b3e0 ]
    
    Referenced commit introduced nfp_policer_validate in the progress
    installing rate limiter. This validate check the action id and will
    reject police with CONTINUE, which is required to support ingress
    police offload.
    
    Fix this issue by allowing FLOW_ACTION_CONTINUE as notexceed action
    id in nfp_policer_validate
    
    Fixes: d97b4b105ce7 ("flow_offload: reject offload for all drivers with invalid police parameters")
    Signed-off-by: Tianyu Yuan <tianyu.yuan@corigine.com>
    Reviewed-by: Baowen Zheng <baowen.zheng@corigine.com>
    Reviewed-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20220825080845.507534-1-simon.horman@corigine.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0c1c0241917459644326a1a3102207c871ae159
Author: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>
Date:   Thu Aug 25 05:03:26 2022 +0300

    openvswitch: fix memory leak at failed datapath creation
    
    [ Upstream commit a87406f4adee9c53b311d8a1ba2849c69e29a6d0 ]
    
    ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids()
    allocates array via kmalloc.
    If for some reason new_vport() fails during ovs_dp_cmd_new()
    dp->upcall_portids must be freed.
    Add missing kfree.
    
    Kmemleak example:
    unreferenced object 0xffff88800c382500 (size 64):
      comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s)
      hex dump (first 32 bytes):
        5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff  ^.y..z8..!8.....
        03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00  ............(...
      backtrace:
        [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0
        [<000000000187d8bd>] ovs_dp_change+0x63/0xe0
        [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380
        [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150
        [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0
        [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100
        [<000000004959cece>] genl_rcv+0x24/0x40
        [<000000004699ac7f>] netlink_unicast+0x23e/0x360
        [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0
        [<000000006f4aa380>] sock_sendmsg+0x62/0x70
        [<00000000d0068654>] ____sys_sendmsg+0x230/0x270
        [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0
        [<0000000011776020>] __sys_sendmsg+0x59/0xa0
        [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90
        [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: b83d23a2a38b ("openvswitch: Introduce per-cpu upcall dispatch")
    Acked-by: Aaron Conole <aconole@redhat.com>
    Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>
    Link: https://lore.kernel.org/r/20220825020326.664073-1-andrey.zhadchenko@virtuozzo.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2cc359e33e5c28c82bab14412525e1be6b4249a
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Aug 24 19:39:51 2022 -0700

    net: smsc911x: Stop and start PHY during suspend and resume
    
    [ Upstream commit 3ce9f2bef75528936c78a7053301f5725f622f3a ]
    
    Commit 744d23c71af3 ("net: phy: Warn about incorrect
    mdio_bus_phy_resume() state") unveiled that the smsc911x driver was not
    properly stopping and restarting the PHY during suspend/resume. Correct
    that by indicating that the MAC is in charge of PHY PM operations and
    ensure that all MDIO bus activity is quiescent during suspend.
    
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Fixes: 2aa70f864955 ("net: smsc911x: Quieten netif during suspend")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220825023951.3220-1-f.fainelli@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 615391126f5dbb966191355636bd665a035e006a
Author: Casper Andersson <casper.casan@gmail.com>
Date:   Thu Aug 25 10:49:55 2022 +0200

    net: sparx5: fix handling uneven length packets in manual extraction
    
    [ Upstream commit 7498a457ecf7ff2c4d379360aa8f24566bb1543e ]
    
    Packets that are not of length divisible by 4 (e.g. 77, 78, 79) would
    have the checksum included up to next multiple of 4 (a 77 bytes packet
    would have 3 bytes of ethernet checksum included). The check for the
    value expects it in host (Little) endian.
    
    Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
    Signed-off-by: Casper Andersson <casper.casan@gmail.com>
    Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
    Link: https://lore.kernel.org/r/20220825084955.684637-1-casper.casan@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92f7ab56bf35fb0472d5c543421669bd67eda2f6
Author: Zhengping Jiang <jiangzp@google.com>
Date:   Tue Aug 23 10:28:08 2022 -0700

    Bluetooth: hci_sync: hold hdev->lock when cleanup hci_conn
    
    [ Upstream commit 2da8eb834b775a9d1acea6214d3e4a78ac841e6e ]
    
    When disconnecting all devices, hci_conn_failed is used to cleanup
    hci_conn object when the hci_conn object cannot be aborted.
    The function hci_conn_failed requires the caller holds hdev->lock.
    
    Fixes: 9b3628d79b46f ("Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted")
    Signed-off-by: Zhengping Jiang <jiangzp@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f868038a43cdd99e3ec648a582165695f2002b9
Author: Archie Pusaka <apusaka@chromium.org>
Date:   Tue Aug 23 12:39:22 2022 +0800

    Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt
    
    [ Upstream commit f48735a9aaf8258f39918e13adf464ccd7dce33b ]
    
    To prevent multiple conn complete events, we shouldn't look up the
    conn with hci_lookup_le_connect, since it requires the state to be
    BT_CONNECT. By the time the duplicate event is processed, the state
    might have changed, so we end up processing the new event anyway.
    
    Change the lookup function to hci_conn_hash_lookup_ba.
    
    Fixes: d5ebaa7c5f6f6 ("Bluetooth: hci_event: Ignore multiple conn complete events")
    Signed-off-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02e49daf3fa34a2adc234f798fd7a265560ebbeb
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Aug 11 14:20:46 2022 -0700

    Bluetooth: hci_sync: Fix suspend performance regression
    
    [ Upstream commit 1fd02d56dae35b08e4cba8e6bd2c2e7ccff68ecc ]
    
    This attempts to fix suspend performance when there is no connections by
    not updating the event mask.
    
    Fixes: ef61b6ea1544 ("Bluetooth: Always set event mask on suspend")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6b3f3cd7bd7bf8dd32c75b61309dffb980c536a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Aug 7 22:57:40 2022 +0200

    Bluetooth: hci_event: Fix vendor (unknown) opcode status handling
    
    [ Upstream commit b82a26d8633cc89367fac75beb3ec33061bea44a ]
    
    Commit c8992cffbe74 ("Bluetooth: hci_event: Use of a function table to
    handle Command Complete") was (presumably) meant to only refactor things
    without any functional changes.
    
    But it does have one undesirable side-effect, before *status would always
    be set to skb->data[0] and it might be overridden by some of the opcode
    specific handling. While now it always set by the opcode specific handlers.
    This means that if the opcode is not known *status does not get set any
    more at all!
    
    This behavior change has broken bluetooth support for BCM4343A0 HCIs,
    the hci_bcm.c code tries to configure UART attached HCIs at a higher
    baudraute using vendor specific opcodes. The BCM4343A0 does not
    support this and this used to simply fail:
    
    [   25.646442] Bluetooth: hci0: BCM: failed to write clock (-56)
    [   25.646481] Bluetooth: hci0: Failed to set baudrate
    
    After which things would continue with the initial baudraute. But now
    that hci_cmd_complete_evt() no longer sets status for unknown opcodes
    *status is left at 0. This causes the hci_bcm.c code to think the baudraute
    has been changed on the HCI side and to also adjust the UART baudrate,
    after which communication with the HCI is broken, leading to:
    
    [   28.579042] Bluetooth: hci0: command 0x0c03 tx timeout
    [   36.961601] Bluetooth: hci0: BCM: Reset failed (-110)
    
    And non working bluetooth. Fix this by restoring the previous
    default "*status = skb->data[0]" handling for unknown opcodes.
    
    Fixes: c8992cffbe74 ("Bluetooth: hci_event: Use of a function table to handle Command Complete")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2459615a8d7f44ac81f0965bc094e55ccb254717
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Tue Aug 23 20:52:59 2022 +0200

    bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
    
    [ Upstream commit 2fc31465c5373b5ca4edf2e5238558cb62902311 ]
    
    Precision markers need to be propagated whenever we have an ARG_CONST_*
    style argument, as the verifier cannot consider imprecise scalars to be
    equivalent for the purposes of states_equal check when such arguments
    refine the return value (in this case, set mem_size for PTR_TO_MEM). The
    resultant mem_size for the R0 is derived from the constant value, and if
    the verifier incorrectly prunes states considering them equivalent where
    such arguments exist (by seeing that both registers have reg->precise as
    false in regsafe), we can end up with invalid programs passing the
    verifier which can do access beyond what should have been the correct
    mem_size in that explored state.
    
    To show a concrete example of the problem:
    
    0000000000000000 <prog>:
           0:       r2 = *(u32 *)(r1 + 80)
           1:       r1 = *(u32 *)(r1 + 76)
           2:       r3 = r1
           3:       r3 += 4
           4:       if r3 > r2 goto +18 <LBB5_5>
           5:       w2 = 0
           6:       *(u32 *)(r1 + 0) = r2
           7:       r1 = *(u32 *)(r1 + 0)
           8:       r2 = 1
           9:       if w1 == 0 goto +1 <LBB5_3>
          10:       r2 = -1
    
    0000000000000058 <LBB5_3>:
          11:       r1 = 0 ll
          13:       r3 = 0
          14:       call bpf_ringbuf_reserve
          15:       if r0 == 0 goto +7 <LBB5_5>
          16:       r1 = r0
          17:       r1 += 16777215
          18:       w2 = 0
          19:       *(u8 *)(r1 + 0) = r2
          20:       r1 = r0
          21:       r2 = 0
          22:       call bpf_ringbuf_submit
    
    00000000000000b8 <LBB5_5>:
          23:       w0 = 0
          24:       exit
    
    For the first case, the single line execution's exploration will prune
    the search at insn 14 for the branch insn 9's second leg as it will be
    verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will
    always be 0 so at runtime we don't get error for being greater than
    UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just
    sees reg->precise as false for both r2 registers in both states, hence
    considers them equal for purposes of states_equal.
    
    If we propagated precise markers using the backtracking support, we
    would use the precise marking to then ensure that old r2 (UINT_MAX) was
    within the new r2 (1) and this would never be true, so the verification
    would rightfully fail.
    
    The end result is that the out of bounds access at instruction 19 would
    be permitted without this fix.
    
    Note that reg->precise is always set to true when user does not have
    CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static
    or global functions)), hence this is only a problem when precision marks
    need to be explicitly propagated (i.e. privileged users with CAP_BPF).
    
    A simplified test case has been included in the next patch to prevent
    future regressions.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20220823185300.406-2-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10608641b055c4d4cc51030e09ef41aa6cddaf61
Author: Joanne Koong <joannelkoong@gmail.com>
Date:   Tue Jul 12 14:06:03 2022 -0700

    bpf: Tidy up verifier check_func_arg()
    
    [ Upstream commit 8ab4cdcf03d0b060fbf73f76460f199bbd759ff7 ]
    
    This patch does two things:
    
    1. For matching against the arg type, the match should be against the
    base type of the arg type, since the arg type can have different
    bpf_type_flags set on it.
    
    2. Uses switch casing to improve readability + efficiency.
    
    Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
    Acked-by: Hao Luo <haoluo@google.com>
    Link: https://lore.kernel.org/r/20220712210603.123791-1-joannelkoong@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 840fbb6845abb5cecb0dbf417c8d265a7e791b03
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Wed Jun 15 16:48:43 2022 +0300

    bpf: Allow helpers to accept pointers with a fixed size
    
    [ Upstream commit 508362ac66b0478affb4e52cb8da98478312d72d ]
    
    Before this commit, the BPF verifier required ARG_PTR_TO_MEM arguments
    to be followed by ARG_CONST_SIZE holding the size of the memory region.
    The helpers had to check that size in runtime.
    
    There are cases where the size expected by a helper is a compile-time
    constant. Checking it in runtime is an unnecessary overhead and waste of
    BPF registers.
    
    This commit allows helpers to accept pointers to memory without the
    corresponding ARG_CONST_SIZE, given that they define the memory region
    size in struct bpf_func_proto and use ARG_PTR_TO_FIXED_SIZE_MEM type.
    
    arg_size is unionized with arg_btf_id to reduce the kernel image size,
    and it's valid because they are used by different argument types.
    
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20220615134847.3753567-3-maximmi@nvidia.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdbaf57293f0a2b4ad1faa1ebe7dbefd5e519cf9
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Aug 25 18:08:40 2022 +0300

    Revert "xhci: turn off port power in shutdown"
    
    [ Upstream commit 8531aa1659f7278d4f2ec7408cc000eaa8d85217 ]
    
    This reverts commit 83810f84ecf11dfc5a9414a8b762c3501b328185.
    
    Turning off port power in shutdown did cause issues such as a laptop not
    proprly powering off, and some specific usb devies failing to enumerate the
    subsequent boot after a warm reset.
    
    So revert this.
    
    Fixes: 83810f84ecf1 ("xhci: turn off port power in shutdown")
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20220825150840.132216-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7081b2f34ff291ada012bd6abacaf7d51c4cf73f
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Aug 25 18:08:38 2022 +0300

    xhci: Fix null pointer dereference in remove if xHC has only one roothub
    
    [ Upstream commit 4a593a62a9e3a25ab4bc37f612e4edec144f7f43 ]
    
    The remove path in xhci platform driver tries to remove and put both main
    and shared hcds even if only a main hcd exists (one roothub)
    
    This causes a null pointer dereference in reboot for those controllers.
    
    Check that the shared_hcd exists before trying to remove it.
    
    Fixes: e0fe986972f5 ("usb: host: xhci-plat: prepare operation w/o shared hcd")
    Reported-by: Alexey Sheplyakov <asheplyakov@basealt.ru>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20220825150840.132216-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f67a7c661b1a604eb66854ec4c30ca38be43e81
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 4 10:03:21 2022 +0300

    wifi: cfg80211: debugfs: fix return type in ht40allow_map_read()
    
    [ Upstream commit d776763f48084926b5d9e25507a3ddb7c9243d5e ]
    
    The return type is supposed to be ssize_t, which is signed long,
    but "r" was declared as unsigned int.  This means that on 64 bit systems
    we return positive values instead of negative error codes.
    
    Fixes: 80a3511d70e8 ("cfg80211: add debugfs HT40 allow map")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YutvOQeJm0UjLhwU@kili
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57cfdf9edcbc0b9b6e25136d20ee44543d8c278f
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Aug 23 15:24:05 2022 +0300

    ALSA: hda: intel-nhlt: Correct the handling of fmt_config flexible array
    
    [ Upstream commit 2e6481a3f3ee6234ce577454e1d88aca55f51d47 ]
    
    The struct nhlt_format's fmt_config is a flexible array, it must not be
    used as normal array.
    When moving to the next nhlt_fmt_cfg we need to take into account the data
    behind the ->config.caps (indicated by ->config.size).
    
    Fixes: a864e8f159b13 ("ALSA: hda: intel-nhlt: verify config type")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Jaska Uimonen <jaska.uimonen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220823122405.18464-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26eaff38e1fc3366f09676ed6749c8d04e34eb00
Author: Arun R Murthy <arun.r.murthy@intel.com>
Date:   Mon Aug 8 09:27:50 2022 +0530

    drm/i915/display: avoid warnings when registering dual panel backlight
    
    [ Upstream commit 868e8e5156a1f8d92ca83fdbac6fd52798650792 ]
    
    Commit 20f85ef89d94 ("drm/i915/backlight: use unique backlight device
    names") added support for multiple backlight devices on dual panel
    systems, but did so with error handling on -EEXIST from
    backlight_device_register(). Unfortunately, that triggered a warning in
    dmesg all the way down from sysfs_add_file_mode_ns() and
    sysfs_warn_dup().
    
    Instead of optimistically always attempting to register with the default
    name ("intel_backlight", which we have to retain for backward
    compatibility), check if a backlight device with the name exists first,
    and, if so, use the card and connector based name.
    
    v2: reworked on top of the patch commit 20f85ef89d94
    ("drm/i915/backlight: use unique backlight device names")
    v3: fixed the ref count leak(Jani N)
    
    Fixes: 20f85ef89d94 ("drm/i915/backlight: use unique backlight device names")
    Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220808035750.3111046-1-arun.r.murthy@intel.com
    (cherry picked from commit 4234ea30051200fc6016de10e4d58369e60b38f1)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97434cb55bd884bd268626ec41489f79b261b2d4
Author: Matthew Auld <matthew.auld@intel.com>
Date:   Fri Aug 5 14:22:40 2022 +0100

    drm/i915/ttm: fix CCS handling
    
    [ Upstream commit 8d905254162965c8e6be697d82c7dbf5d08f574d ]
    
    Crucible + recent Mesa seems to sometimes hit:
    
    GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)
    
    And it looks like we can also trigger this with gem_lmem_swapping, if we
    modify the test to use slightly larger object sizes.
    
    Looking closer it looks like we have the following issues in
    migrate_copy():
    
      - We are using plain integer in various places, which we can easily
        overflow with a large object.
    
      - We pass the entire object size (when the src is lmem) into
        emit_pte() and then try to copy it, which doesn't work, since we
        only have a few fixed sized windows in which to map the pages and
        perform the copy. With an object > 8M we therefore aren't properly
        copying the pages. And then with an object > 64M we trigger the
        GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER).
    
    So it looks like our copy handling for any object > 8M (which is our
    CHUNK_SZ) is currently broken on DG2.
    
    Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable lmem obj")
    Testcase: igt@gem_lmem_swapping
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Cc: Ramalingam C <ramalingam.c@intel.com>
    Reviewed-by: Ramalingam C<ramalingam.c@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220805132240.442747-2-matthew.auld@intel.com
    (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba632ad0bacb13197a8f38e7526448974e87f292
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Aug 23 14:58:04 2022 -0700

    bpf: Fix a data-race around bpf_jit_limit.
    
    [ Upstream commit 0947ae1121083d363d522ff7518ee72b55bd8d29 ]
    
    While reading bpf_jit_limit, it can be changed concurrently via sysctl,
    WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit
    is long, so we need to add a paired READ_ONCE() to avoid load-tearing.
    
    Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20220823215804.2177-1-kuniyu@amazon.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15f3b89bd521d5770d36a61fc04a77c293138ba6
Author: Lin Ma <linma@zju.edu.cn>
Date:   Mon Aug 8 11:42:24 2022 +0800

    ieee802154/adf7242: defer destroy_workqueue call
    
    [ Upstream commit afe7116f6d3b888778ed6d95e3cf724767b9aedf ]
    
    There is a possible race condition (use-after-free) like below
    
      (FREE)                     |  (USE)
      adf7242_remove             |  adf7242_channel
       cancel_delayed_work_sync  |
        destroy_workqueue (1)    |   adf7242_cmd_rx
                                 |    mod_delayed_work (2)
                                 |
    
    The root cause for this race is that the upper layer (ieee802154) is
    unaware of this detaching event and the function adf7242_channel can
    be called without any checks.
    
    To fix this, we can add a flag write at the beginning of adf7242_remove
    and add flag check in adf7242_channel. Or we can just defer the
    destructive operation like other commit 3e0588c291d6 ("hamradio: defer
    ax25 kfree after unregister_netdev") which let the
    ieee802154_unregister_hw() to handle the synchronization. This patch
    takes the second option.
    
    Fixes: 58e9683d1475 ("net: ieee802154: adf7242: Fix OCL calibration
    runs")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Acked-by: Michael Hennerich <michael.hennerich@analog.com>
    Link: https://lore.kernel.org/r/20220808034224.12642-1-linma@zju.edu.cn
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2914e46f5b0399279ad56e3c0247a2da72fa0f21
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Aug 10 15:55:48 2022 -0600

    drm/i915/gvt: Fix Comet Lake
    
    [ Upstream commit b75ef35bb57791a5d675699ed4a40c870d1da12f ]
    
    Prior to the commit below the GAMT_CHKN_BIT_REG address was setup for
    devices matching (D_KBL | D_CFL), where intel_gvt_get_device_type()
    returns D_CFL for either Coffee Lake or Comet Lake.  Include the missed
    platform.`
    
    Link: https://lore.kernel.org/all/20220808142711.02d16782.alex.williamson@redhat.com
    Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/166016852965.780835.10366587502693016900.stgit@omen
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1a05d3ae58299b040da4d5b27e72e81c2132e0b
Author: Pu Lehui <pulehui@huawei.com>
Date:   Sat Aug 13 21:40:30 2022 +0800

    bpf, cgroup: Fix kernel BUG in purge_effective_progs
    
    [ Upstream commit 7d6620f107bae6ed687ff07668e8e8f855487aa9 ]
    
    Syzkaller reported a triggered kernel BUG as follows:
    
      ------------[ cut here ]------------
      kernel BUG at kernel/bpf/cgroup.c:925!
      invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
      CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0
      Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84
      28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48
      8b 0c5
      RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246
      RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000
      RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578
      RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000
      R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00
      FS:  00007f68213d2b80(0000) GS:ffff88813bc80000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0
      Call Trace:
       <TASK>
       cgroup_bpf_prog_detach+0xcc/0x100
       __sys_bpf+0x2273/0x2a00
       __x64_sys_bpf+0x17/0x20
       do_syscall_64+0x3b/0x90
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7f68214dbcb9
      Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89
      f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
      f0 ff8
      RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
      RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9
      RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009
      RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003
      R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20
      R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0
       </TASK>
      Modules linked in:
      ---[ end trace 0000000000000000 ]---
    
    Repetition steps:
    
    For the following cgroup tree,
    
      root
       |
      cg1
       |
      cg2
    
      1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs
         attach type is NONE or OVERRIDE.
      2. write 1 to /proc/thread-self/fail-nth for failslab.
      3. detach prog1 for cg1, and then kernel BUG occur.
    
    Failslab injection will cause kmalloc fail and fall back to
    purge_effective_progs. The problem is that cg2 have attached another prog,
    so when go through cg2 layer, iteration will add pos to 1, and subsequent
    operations will be skipped by the following condition, and cg will meet
    NULL in the end.
    
      `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))`
    
    The NULL cg means no link or prog match, this is as expected, and it's not
    a bug. So here just skip the no match situation.
    
    Fixes: 4c46091ee985 ("bpf: Fix KASAN use-after-free Read in compute_effective_progs")
    Signed-off-by: Pu Lehui <pulehui@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20220813134030.1972696-1-pulehui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca41835c753aca5068553ce92702cced704c5d45
Author: Eyal Birger <eyal.birger@gmail.com>
Date:   Thu Aug 18 10:41:18 2022 +0300

    ip_tunnel: Respect tunnel key's "flow_flags" in IP tunnels
    
    [ Upstream commit 7ec9fce4b31604f8415136a4c07f7dc8ad431aec ]
    
    Commit 451ef36bd229 ("ip_tunnels: Add new flow flags field to ip_tunnel_key")
    added a "flow_flags" member to struct ip_tunnel_key which was later used by
    the commit in the fixes tag to avoid dropping packets with sources that
    aren't locally configured when set in bpf_set_tunnel_key().
    
    VXLAN and GENEVE were made to respect this flag, ip tunnels like IPIP and GRE
    were not.
    
    This commit fixes this omission by making ip_tunnel_init_flow() receive
    the flow flags from the tunnel key in the relevant collect_md paths.
    
    Fixes: b8fff748521c ("bpf: Set flow flag to allow any source IP in bpf_tunnel_key")
    Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Paul Chaignon <paul@isovalent.com>
    Link: https://lore.kernel.org/bpf/20220818074118.726639-1-eyal.birger@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 257f1447d7c245b81e23fa2ee932c737232c29ac
Author: YiFei Zhu <zhuyifei@google.com>
Date:   Tue Aug 16 20:55:16 2022 +0000

    bpf: Restrict bpf_sys_bpf to CAP_PERFMON
    
    [ Upstream commit 14b20b784f59bdd95f6f1cfb112c9818bcec4d84 ]
    
    The verifier cannot perform sufficient validation of any pointers passed
    into bpf_attr and treats them as integers rather than pointers. The helper
    will then read from arbitrary pointers passed into it. Restrict the helper
    to CAP_PERFMON since the security model in BPF of arbitrary kernel read is
    CAP_BPF + CAP_PERFMON.
    
    Fixes: af2ac3e13e45 ("bpf: Prepare bpf syscall to be used from kernel and user space.")
    Signed-off-by: YiFei Zhu <zhuyifei@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10ee118a1756141f8e9c87aa7344ed12b41630a8
Author: Liu Jian <liujian56@huawei.com>
Date:   Tue Aug 9 17:49:15 2022 +0800

    skmsg: Fix wrong last sg check in sk_msg_recvmsg()
    
    [ Upstream commit 583585e48d965338e73e1eb383768d16e0922d73 ]
    
    Fix one kernel NULL pointer dereference as below:
    
    [  224.462334] Call Trace:
    [  224.462394]  __tcp_bpf_recvmsg+0xd3/0x380
    [  224.462441]  ? sock_has_perm+0x78/0xa0
    [  224.462463]  tcp_bpf_recvmsg+0x12e/0x220
    [  224.462494]  inet_recvmsg+0x5b/0xd0
    [  224.462534]  __sys_recvfrom+0xc8/0x130
    [  224.462574]  ? syscall_trace_enter+0x1df/0x2e0
    [  224.462606]  ? __do_page_fault+0x2de/0x500
    [  224.462635]  __x64_sys_recvfrom+0x24/0x30
    [  224.462660]  do_syscall_64+0x5d/0x1d0
    [  224.462709]  entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    In commit 9974d37ea75f ("skmsg: Fix invalid last sg check in
    sk_msg_recvmsg()"), we change last sg check to sg_is_last(),
    but in sockmap redirection case (without stream_parser/stream_verdict/
    skb_verdict), we did not mark the end of the scatterlist. Check the
    sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all
    do not mark the end of sg. They are expected to use sg.end for end
    judgment. So the judgment of '(i != msg_rx->sg.end)' is added back here.
    
    Fixes: 9974d37ea75f ("skmsg: Fix invalid last sg check in sk_msg_recvmsg()")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20220809094915.150391-1-liujian56@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37e05ea2c5fbb9bcea8b1b1020fb0853fbf7ab0b
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Fri Jul 22 15:07:18 2022 +0200

    iio: adc: mcp3911: make use of the sign bit
    
    [ Upstream commit 8f89e33bf040bbef66386c426198622180233178 ]
    
    The device supports negative values as well.
    
    Fixes: 3a89b289df5d ("iio: adc: add support for mcp3911")
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220722130726.7627-2-marcus.folkesson@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7cf5a0caba9e3b96a2080d055d1eaa31b1be8d9
Author: Lv Ruyi <lv.ruyi@zte.com.cn>
Date:   Wed Apr 13 01:04:25 2022 +0000

    peci: aspeed: fix error check return value of platform_get_irq()
    
    [ Upstream commit e79b548b7202bb3accdfe64f113129a4340bc2f9 ]
    
    platform_get_irq() return negative value on failure, so null check of
    priv->irq is incorrect. Fix it by comparing whether it is less than zero.
    
    Fixes: a85e4c52086c ("peci: Add peci-aspeed controller driver")
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
    Link: https://lore.kernel.org/r/20220413010425.2534887-1-lv.ruyi@zte.com.cn
    Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com>
    Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d5383b8dae2c8d56c0f1ff04093bc82d7588496
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Fri Jul 8 09:26:32 2022 -0700

    drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails
    
    [ Upstream commit 02b9f2636209beb843ca501d47f7fddc8792b2d7 ]
    
    In the event that devm_devfreq_add_device() fails the device's qos freq
    list is left referencing df->idle_freq and df->boost_freq. Attempting to
    initialize devfreq again after a probe deferral will then cause invalid
    memory accesses in dev_pm_qos_add_request().
    
    Fix this by dropping the requests in the error path.
    
    Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/493001/
    Link: https://lore.kernel.org/r/20220708162632.3529864-1-bjorn.andersson@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c75891d56ab6fe5ba0d415bfad91d514a4027cd
Author: Magnus Karlsson <magnus.karlsson@intel.com>
Date:   Fri Aug 12 13:32:59 2022 +0200

    xsk: Fix corrupted packets for XDP_SHARED_UMEM
    
    [ Upstream commit 58ca14ed98c87cfe0d1408cc65a9745d9e9b7a56 ]
    
    Fix an issue in XDP_SHARED_UMEM mode together with aligned mode where
    packets are corrupted for the second and any further sockets bound to
    the same umem. In other words, this does not affect the first socket
    bound to the umem. The culprit for this bug is that the initialization
    of the DMA addresses for the pre-populated xsk buffer pool entries was
    not performed for any socket but the first one bound to the umem. Only
    the linear array of DMA addresses was populated. Fix this by populating
    the DMA addresses in the xsk buffer pool for every socket bound to the
    same umem.
    
    Fixes: 94033cd8e73b8 ("xsk: Optimize for aligned case")
    Reported-by: Alasdair McWilliam <alasdair.mcwilliam@outlook.com>
    Reported-by: Intrusion Shield Team <dnevil@intrusion.com>
    Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Alasdair McWilliam <alasdair.mcwilliam@outlook.com>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/xdp-newbies/6205E10C-292E-4995-9D10-409649354226@outlook.com/
    Link: https://lore.kernel.org/bpf/20220812113259.531-1-magnus.karlsson@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c77b724cddfb8ac1291a60e3e68937e62cbfc5e0
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Aug 10 16:19:34 2022 +0200

    platform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS
    
    [ Upstream commit 2986c51540ed50ac654ffb5a772e546c02628c91 ]
    
    The x86-android-tablets handling for the Chuwi Hi8 is only necessary with
    the Android BIOS and it is causing problems with the Windows BIOS version.
    
    Specifically when trying to register the already present touchscreen
    x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks
    the working of the touchscreen and also leads to an oops:
    
    [   14.248946] ------------[ cut here ]------------
    [   14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00'
    [   14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry
    ...
    [   14.249293]  unregister_irq_proc+0xe0/0x100
    [   14.249305]  free_desc+0x29/0x70
    [   14.249312]  irq_free_descs+0x4b/0x80
    [   14.249320]  mp_unmap_irq+0x5c/0x60
    [   14.249329]  acpi_unregister_gsi_ioapic+0x2a/0x40
    [   14.249338]  x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]
    [   14.249355]  x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]
    
    Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS
    is in use and exits with -ENODEV in that case, fixing this.
    
    Fixes: 84c2dcdd475f ("platform/x86: x86-android-tablets: Add an init() callback to struct x86_dev_info")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220810141934.140771-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d5bed97ff3d89b3799d97161898ca9cfbdcca7d
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Aug 1 14:37:31 2022 +0300

    platform/x86: pmc_atom: Fix SLP_TYPx bitfield mask
    
    [ Upstream commit 0a90ed8d0cfa29735a221eba14d9cb6c735d35b6 ]
    
    On Intel hardware the SLP_TYPx bitfield occupies bits 10-12 as per ACPI
    specification (see Table 4.13 "PM1 Control Registers Fixed Hardware
    Feature Control Bits" for the details).
    
    Fix the mask and other related definitions accordingly.
    
    Fixes: 93e5eadd1f6e ("x86/platform: New Intel Atom SOC power management controller driver")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20220801113734.36131-1-andriy.shevchenko@linux.intel.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0d3a4f4c3f370a3f6c9a8ac38eb89ee130410ca
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Aug 4 07:38:49 2022 -0700

    drm/msm/dsi: Fix number of regulators for SDM660
    
    [ Upstream commit a1653a75987749ba6dba94fa2e62f0f36b387d1a ]
    
    1 regulator is listed but the number 2 is specified. This presumably
    means we try to get a regulator with no name. Fix it.
    
    Fixes: 462f7017a691 ("drm/msm/dsi: Fix DSI and DSI PHY regulator config from SDM660")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/496323/
    Link: https://lore.kernel.org/r/20220804073608.v4.2.I94b3c3e412b7c208061349f05659e126483171b1@changeid
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 847dba3aa345bd3250d87ecd4cd4e3d3e64c094e
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Aug 4 07:38:48 2022 -0700

    drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
    
    [ Upstream commit 1e00d6ac8a3422765bae37aeac2002dfd3c0bda6 ]
    
    3 regulators are listed but the number 2 is specified. Fix it.
    
    Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/496318/
    Link: https://lore.kernel.org/r/20220804073608.v4.1.I1056ee3f77f71287f333279efe4c85f88d403f65@changeid
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b99ab590a5ace2e0da01e38ef9c9134216c19cfb
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Thu Aug 11 15:57:50 2022 -0700

    drm/msm/dp: delete DP_RECOVERED_CLOCK_OUT_EN to fix tps4
    
    [ Upstream commit 032d57960176ac01cc5adff5bcc5eb51317f8781 ]
    
    Data Symbols scrambled is required for tps4 at link training 2.
    Therefore SCRAMBLING_DISABLE bit should not be set for tps4 to
    work.
    
    RECOVERED_CLOCK_OUT_EN is for enable simple EYE test for jitter
    measurement with minimal equipment for embedded applications purpose
    and is not required to be set during normal operation. Current
    implementation always have RECOVERED_CLOCK_OUT_EN bit set which
    cause SCRAMBLING_DISABLE bit wrongly set at tps4 which prevent
    tps4 from working.
    
    This patch delete setting RECOVERED_CLOCK_OUT_EN to fix
    SCRAMBLING_DISABLE be wrongly set at tps4.
    
    Changes in v2:
    -- fix Fixes tag
    
    Changes in v3:
    -- revise commit text
    
    Changes in v4:
    -- fix commit text newline
    
    Changes in v5:
    -- fix commit text line over 75 chars
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/497194/
    Link: https://lore.kernel.org/r/1660258670-4200-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83cc61f72e6a856aec2944792576bcf5b6ad11bd
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Fri Jul 15 12:14:28 2022 -0700

    drm/msm/dpu: populate wb or intf before reset_intf_cfg
    
    [ Upstream commit ef3ac3ae147c6ab370875727791e9b3eaf176cea ]
    
    dpu_encoder_helper_phys_cleanup() was not populating neither
    wb or intf to the intf_cfg before calling the reset_intf_cfg().
    
    This causes the reset of the active bits of wb/intf to be
    skipped which is incorrect.
    
    Fix this by populating the relevant wb or intf indices correctly.
    
    Fixes: ae4d721ce100 ("drm/msm/dpu: add an API to reset the encoder related hw blocks")
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # Trogdor (SC8170)
    Patchwork: https://patchwork.freedesktop.org/patch/494298/
    Link: https://lore.kernel.org/r/1657912468-17254-1-git-send-email-quic_abhinavk@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f490254854f821d75a98514f52a234ca026ff9a
Author: sunliming <sunliming@kylinos.cn>
Date:   Tue Jul 19 09:56:22 2022 +0800

    drm/msm/dsi: fix the inconsistent indenting
    
    [ Upstream commit 2f25a1fb4ec516c5ad67afd754334b491b9f09a5 ]
    
    Fix the inconsistent indenting in function msm_dsi_dphy_timing_calc_v3().
    
    Fix the following smatch warnings:
    
    drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:350 msm_dsi_dphy_timing_calc_v3() warn: inconsistent indenting
    
    Fixes: f1fa7ff44056 ("drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: sunliming <sunliming@kylinos.cn>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/494662/
    Link: https://lore.kernel.org/r/20220719015622.646718-1-sunliming@kylinos.cn
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adbe8cb186354f468c8635afa300751a02137eb2
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Wed Jul 6 12:32:08 2022 -0700

    drm/msm/dp: make eDP panel as the first connected connector
    
    [ Upstream commit deffa2d75db7e7a9a1fe3dad4f99310bff7b6449 ]
    
    Some userspace presumes that the first connected connector is the main
    display, where it's supposed to display e.g. the login screen. For
    laptops, this should be the main panel.
    
    This patch call drm_helper_move_panel_connectors_to_head() after
    drm_bridge_connector_init() to make sure eDP stay at head of
    connected connector list. This fixes unexpected corruption happen
    at eDP panel if eDP is not placed at head of connected connector
    list.
    
    Changes in v2:
    -- move drm_helper_move_panel_connectors_to_head() to
                    dpu_kms_drm_obj_init()
    
    Changes in v4:
    -- move drm_helper_move_panel_connectors_to_head() to msm_drm_init()
    
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Fixes: ef7837ff091c ("drm/msm/dp: Add DP controllers for sc7280")
    Patchwork: https://patchwork.freedesktop.org/patch/492581/
    Link: https://lore.kernel.org/r/1657135928-31195-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>