Linux 5.15.61

 
9p: Add client parameter to p9_req_put() [+ + +]
Author: Kent Overstreet <kent.overstreet@gmail.com>
Date:   Sun Jul 3 21:08:18 2022 -0400

    9p: Add client parameter to p9_req_put()
    
    [ Upstream commit 8b11ff098af42b1fa57fc817daadd53c8b244a0c ]
    
    This is to aid in adding mempools, in the next patch.
    
    Link: https://lkml.kernel.org/r/20220704014243.153050-2-kent.overstreet@gmail.com
    Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

9p: Drop kref usage [+ + +]
Author: Kent Overstreet <kent.overstreet@gmail.com>
Date:   Sun Jul 3 21:02:49 2022 -0400

    9p: Drop kref usage
    
    [ Upstream commit 6cda12864cb0f99810a5809e11e3ee5b102c9a47 ]
    
    An upcoming patch is going to require passing the client through
    p9_req_put() -> p9_req_free(), but that's awkward with the kref
    indirection - so this patch switches to using refcount_t directly.
    
    Link: https://lkml.kernel.org/r/20220704014243.153050-1-kent.overstreet@gmail.com
    Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

9p: fix a bunch of checkpatch warnings [+ + +]
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Tue Nov 2 22:16:43 2021 +0900

    9p: fix a bunch of checkpatch warnings
    
    [ Upstream commit 6e195b0f7c8e50927fa31946369c22a0534ec7e2 ]
    
    Sohaib Mohamed started a serie of tiny and incomplete checkpatch fixes but
    seemingly stopped halfway -- take over and do most of it.
    This is still missing net/9p/trans* and net/9p/protocol.c for a later
    time...
    
    Link: http://lkml.kernel.org/r/20211102134608.1588018-3-dominique.martinet@atmark-techno.com
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
__follow_mount_rcu(): verify that mount_lock remains unchanged [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Jul 4 17:26:29 2022 -0400

    __follow_mount_rcu(): verify that mount_lock remains unchanged
    
    commit 20aac6c60981f5bfacd66661d090d907bf1482f0 upstream.
    
    Validate mount_lock seqcount as soon as we cross into mount in RCU
    mode.  Sure, ->mnt_root is pinned and will remain so until we
    do rcu_read_unlock() anyway, and we will eventually fail to unlazy if
    the mount_lock had been touched, but we might run into a hard error
    (e.g. -ENOENT) before trying to unlazy.  And it's possible to end
    up with RCU pathwalk racing with rename() and umount() in a way
    that would fail with -ENOENT while non-RCU pathwalk would've
    succeeded with any timings.
    
    Once upon a time we hadn't needed that, but analysis had been subtle,
    brittle and went out of window as soon as RENAME_EXCHANGE had been
    added.
    
    It's narrow, hard to hit and won't get you anything other than
    stray -ENOENT that could be arranged in much easier way with the
    same priveleges, but it's a bug all the same.
    
    Cc: stable@kernel.org
    X-sky-is-falling: unlikely
    Fixes: da1ce0670c14 "vfs: add cross-rename"
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ACPI: APEI: explicit init of HEST and GHES in apci_init() [+ + +]
Author: Shuai Xue <xueshuai@linux.alibaba.com>
Date:   Sun Feb 27 20:25:45 2022 +0800

    ACPI: APEI: explicit init of HEST and GHES in apci_init()
    
    [ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]
    
    From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
    memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage
    the estatus memory pool. On the other hand, ghes_init() relies on
    sdei_init() to detect the SDEI version and (un)register events. The
    dependencies are as follows:
    
        ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
        ghes_init() => sdei_init()
    
    HEST is not PCI-specific and initcall ordering is implicit and not
    well-defined within a level.
    
    Based on above, remove acpi_hest_init() from acpi_pci_root_init() and
    convert ghes_init() and sdei_init() from initcalls to explicit calls in the
    following order:
    
        acpi_hest_init()
        ghes_init()
            sdei_init()
    
    Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Jun 24 16:05:26 2022 -0700

    ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP
    
    [ Upstream commit b13a3e5fd40b7d1b394c5ecbb5eb301a4c38e7b2 ]
    
    When a platform marks a memory range as "special purpose" it is not
    onlined as System RAM by default. However, it is still suitable for
    error injection. Add IORES_DESC_SOFT_RESERVED to einj_error_inject() as
    a permissible memory type in the sanity checking of the arguments to
    _EINJ.
    
    Fixes: 262b45ae3ab4 ("x86/efi: EFI soft reservation to E820 enumeration")
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Reported-by: Omar Avelar <omar.avelar@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: CPPC: Do not prevent CPPC from working in the future [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jul 21 19:41:10 2022 +0200

    ACPI: CPPC: Do not prevent CPPC from working in the future
    
    [ Upstream commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 ]
    
    There is a problem with the current revision checks in
    is_cppc_supported() that they essentially prevent the CPPC support
    from working if a new _CPC package format revision being a proper
    superset of the v3 and only causing _CPC to return a package with more
    entries (while retaining the types and meaning of the entries defined by
    the v3) is introduced in the future and used by the platform firmware.
    
    In that case, as long as the number of entries in the _CPC return
    package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to
    use the v3 support code and disregard the additional package entries
    added by the new package format revision.
    
    For this reason, drop is_cppc_supported() altogether, put the revision
    checks directly into acpi_cppc_processor_probe() so they are easier to
    follow and rework them to take the case mentioned above into account.
    
    Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3")
    Cc: 4.18+ <stable@vger.kernel.org> # 4.18+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: EC: Drop the EC_FLAGS_IGNORE_DSDT_GPE quirk [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jun 20 11:25:44 2022 +0200

    ACPI: EC: Drop the EC_FLAGS_IGNORE_DSDT_GPE quirk
    
    [ Upstream commit f7090e0ef360d674f08a22fab90e4e209fb1f658 ]
    
    It seems that these quirks are no longer necessary since
    commit 69b957c26b32 ("ACPI: EC: Fix possible issues related to EC
    initialization order"), which has fixed this in a generic manner.
    
    There are 3 commits adding DMI entries with this quirk (adding multiple
    DMI entries per commit). 2/3 commits are from before the generic fix.
    
    Which leaves commit 6306f0431914 ("ACPI: EC: Make more Asus laptops
    use ECDT _GPE"), which was committed way after the generic fix.
    But this was just due to slow upstreaming of it. This commit stems
    from Endless from 15 Aug 2017 (committed upstream 20 May 2021):
    https://github.com/endlessm/linux/pull/288
    
    The current code should work fine without this:
    
     1. The EC_FLAGS_IGNORE_DSDT_GPE flag is only checked in ec_parse_device(),
        like this:
    
            if (boot_ec && boot_ec_is_ecdt && EC_FLAGS_IGNORE_DSDT_GPE) {
                    ec->gpe = boot_ec->gpe;
            } else {
                    /* parse GPE */
            }
    
     2. ec_parse_device() is only called from acpi_ec_add() and
        acpi_ec_dsdt_probe()
    
     3. acpi_ec_dsdt_probe() starts with:
    
            if (boot_ec)
                    return;
    
        so it only calls ec_parse_device() when boot_ec == NULL, meaning that
        the quirk never triggers for this call. So only the call in
        acpi_ec_add() matters.
    
     4. acpi_ec_add() does the following after the ec_parse_device() call:
    
            if (boot_ec && ec->command_addr == boot_ec->command_addr &&
                ec->data_addr == boot_ec->data_addr &&
                !EC_FLAGS_TRUST_DSDT_GPE) {
                    /*
                     * Trust PNP0C09 namespace location rather than
                     * ECDT ID. But trust ECDT GPE rather than _GPE
                     * because of ASUS quirks, so do not change
                     * boot_ec->gpe to ec->gpe.
                     */
                    boot_ec->handle = ec->handle;
                    acpi_handle_debug(ec->handle, "duplicated.\n");
                    acpi_ec_free(ec);
                    ec = boot_ec;
            }
    
    The quirk only matters if boot_ec != NULL and EC_FLAGS_TRUST_DSDT_GPE
    is never set at the same time as EC_FLAGS_IGNORE_DSDT_GPE.
    
    That means that if the addresses match we always enter this if block and
    then only the ec->handle part of the data stored in ec by ec_parse_device()
    is used and the rest is thrown away, after which ec is made to point
    to boot_ec, at which point ec->gpe == boot_ec->gpe, so the same result
    as with the quirk set, independent of the value of the quirk.
    
    Also note the comment in this block which indicates that the gpe result
    from ec_parse_device() is deliberately not taken to deal with buggy
    Asus laptops and all DMI quirks setting EC_FLAGS_IGNORE_DSDT_GPE are for
    Asus laptops.
    
    Based on the above I believe that unless on some quirked laptops
    the ECDT and DSDT EC addresses do not match we can drop the quirk.
    
    I've checked dmesg output to ensure the ECDT and DSDT EC addresses match
    for quirked models using https://linux-hardware.org hw-probe reports.
    
    I've been able to confirm that the addresses match for the following
    models this way: GL702VMK, X505BA, X505BP, X550VXK, X580VD.
    Whereas for the following models I could find any dmesg output:
    FX502VD, FX502VE, X542BA, X542BP.
    
    Note the models without dmesg all were submitted in patches with a batch
    of models and other models from the same batch checkout ok.
    
    This, combined with that all the code adding the quirks was written before
    the generic fix makes me believe that it is safe to remove this quirk now.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Daniel Drake <drake@endlessos.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: EC: Remove duplicate ThinkPad X1 Carbon 6th entry from DMI quirks [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jun 20 11:25:43 2022 +0200

    ACPI: EC: Remove duplicate ThinkPad X1 Carbon 6th entry from DMI quirks
    
    [ Upstream commit 0dd6db359e5f206cbf1dd1fd40dd211588cd2725 ]
    
    Somehow the "ThinkPad X1 Carbon 6th" entry ended up twice in the
    struct dmi_system_id acpi_ec_no_wakeup[] array. Remove one of
    the entries.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: LPSS: Fix missing check in register_device_clock() [+ + +]
Author: huhai <huhai@kylinos.cn>
Date:   Thu Jun 23 21:21:27 2022 +0800

    ACPI: LPSS: Fix missing check in register_device_clock()
    
    [ Upstream commit b4f1f61ed5928b1128e60e38d0dffa16966f06dc ]
    
    register_device_clock() misses a check for platform_device_register_simple().
    Add a check to fix it.
    
    Signed-off-by: huhai <huhai@kylinos.cn>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: PM: save NVS memory for Lenovo G40-45 [+ + +]
Author: Manyi Li <limanyi@uniontech.com>
Date:   Wed Jun 22 15:42:48 2022 +0800

    ACPI: PM: save NVS memory for Lenovo G40-45
    
    [ Upstream commit 4b7ef7b05afcde44142225c184bf43a0cd9e2178 ]
    
    [821d6f0359b0614792ab8e2fb93b503e25a65079] is to make machines
    produced from 2012 to now not saving NVS region to accelerate S3.
    
    But, Lenovo G40-45, a platform released in 2015, still needs NVS memory
    saving during S3. A quirk is introduced for this platform.
    
    Signed-off-by: Manyi Li <limanyi@uniontech.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: processor/idle: Annotate more functions to live in cpuidle section [+ + +]
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Tue Jun 7 19:24:58 2022 -0300

    ACPI: processor/idle: Annotate more functions to live in cpuidle section
    
    [ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ]
    
    Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
    introduced a new text section called cpuidle; with that, we have a mechanism
    to add idling functions in such section and skip them from nmi_backtrace
    output, since they're useless and potentially flooding for such report.
    
    Happens that inlining might cause some real idle functions to end-up
    outside of such section; this is currently the case of ACPI processor_idle
    driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(),
    hence they stay out of the cpuidle section.
    Fix that by marking such functions to also live in the cpuidle section.
    
    Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus")
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: VIOT: Fix ACS setup [+ + +]
Author: Eric Auger <eric.auger@redhat.com>
Date:   Thu Jun 30 11:40:59 2022 +0200

    ACPI: VIOT: Fix ACS setup
    
    [ Upstream commit 3dcb861dbc6ab101838a1548b1efddd00ca3c3ec ]
    
    Currently acpi_viot_init() gets called after the pci
    device has been scanned and pci_enable_acs() has been called.
    So pci_request_acs() fails to be taken into account leading
    to wrong single iommu group topologies when dealing with
    multi-function root ports for instance.
    
    We cannot simply move the acpi_viot_init() earlier, similarly
    as the IORT init because the VIOT parsing relies on the pci
    scan. However we can detect VIOT is present earlier and in
    such a case, request ACS. Introduce a new acpi_viot_early_init()
    routine that allows to call pci_request_acs() before the scan.
    
    While at it, guard the call to pci_request_acs() with #ifdef
    CONFIG_PCI.
    
    Fixes: 3cf485540e7b ("ACPI: Add driver for the VIOT table")
    Signed-off-by: Eric Auger <eric.auger@redhat.com>
    Reported-by: Jin Liu <jinl@redhat.com>
    Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Tested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: add barriers to buffer_uptodate and set_buffer_uptodate [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Aug 9 14:32:13 2022 -0400

    add barriers to buffer_uptodate and set_buffer_uptodate
    
    commit d4252071b97d2027d246f6a82cbee4d52f618b47 upstream.
    
    Let's have a look at this piece of code in __bread_slow:
    
            get_bh(bh);
            bh->b_end_io = end_buffer_read_sync;
            submit_bh(REQ_OP_READ, 0, bh);
            wait_on_buffer(bh);
            if (buffer_uptodate(bh))
                    return bh;
    
    Neither wait_on_buffer nor buffer_uptodate contain any memory barrier.
    Consequently, if someone calls sb_bread and then reads the buffer data,
    the read of buffer data may be executed before wait_on_buffer(bh) on
    architectures with weak memory ordering and it may return invalid data.
    
    Fix this bug by adding a memory barrier to set_buffer_uptodate and an
    acquire barrier to buffer_uptodate (in a similar way as
    folio_test_uptodate and folio_mark_uptodate).
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: bcd2000: Fix a UAF bug on the error path of probing [+ + +]
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Fri Jul 15 09:05:15 2022 +0800

    ALSA: bcd2000: Fix a UAF bug on the error path of probing
    
    commit ffb2759df7efbc00187bfd9d1072434a13a54139 upstream.
    
    When the driver fails in snd_card_register() at probe time, it will free
    the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug.
    
    The following log can reveal it:
    
    [   50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
    [   50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0
    [   50.729530] Call Trace:
    [   50.732899]  bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
    
    Fix this by adding usb_kill_urb() before usb_free_urb().
    
    Fixes: b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device")
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220715010515.2087925-1-zheyuma97@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/cirrus - support for iMac 12,1 model [+ + +]
Author: Allen Ballway <ballway@chromium.org>
Date:   Wed Aug 10 15:27:22 2022 +0000

    ALSA: hda/cirrus - support for iMac 12,1 model
    
    commit 74bba640d69914cf832b87f6bbb700e5ba430672 upstream.
    
    The 12,1 model requires the same configuration as the 12,2 model
    to enable headphones but has a different codec SSID. Adds
    12,1 SSID for matching quirk.
    
    [ re-sorted in SSID order by tiwai ]
    
    Signed-off-by: Allen Ballway <ballway@chromium.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220810152701.1.I902c2e591bbf8de9acb649d1322fa1f291849266@changeid
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model [+ + +]
Author: Meng Tang <tangmeng@uniontech.com>
Date:   Mon Aug 8 15:34:06 2022 +0800

    ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model
    
    commit f83bb2592482fe94c6eea07a8121763c80f36ce5 upstream.
    
    There is another LENOVO 20149 (Type1Sku0) Notebook model with
    CX20590, the device PCI SSID is 17aa:3977, which headphones are
    not responding, that requires the quirk CXT_PINCFG_LENOVO_NOTEBOOK.
    Add the corresponding entry to the quirk table.
    
    Signed-off-by: Meng Tang <tangmeng@uniontech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220808073406.19460-1-tangmeng@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add a quirk for HP OMEN 15 (8786) mute LED [+ + +]
Author: Bedant Patnaik <bedant.patnaik@gmail.com>
Date:   Tue Aug 9 19:54:55 2022 +0530

    ALSA: hda/realtek: Add a quirk for HP OMEN 15 (8786) mute LED
    
    commit 30267718fe2d4dbea49015b022f6f1fe16ca31ab upstream.
    
    Board ID 8786 seems to be another variant of the Omen 15 that needs
    ALC285_FIXUP_HP_MUTE_LED for working mute LED.
    
    Signed-off-by: Bedant Patnaik <bedant.patnaik@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220809142455.6473-1-bedant.patnaik@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for another Asus K42JZ model [+ + +]
Author: Meng Tang <tangmeng@uniontech.com>
Date:   Fri Aug 5 15:45:34 2022 +0800

    ALSA: hda/realtek: Add quirk for another Asus K42JZ model
    
    commit f882c4bef9cb914d9f7be171afb10ed26536bfa7 upstream.
    
    There is another Asus K42JZ model with the PCI SSID 1043:1313
    that requires the quirk ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE.
    Add the corresponding entry to the quirk table.
    
    Signed-off-by: Meng Tang <tangmeng@uniontech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220805074534.20003-1-tangmeng@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for Clevo NV45PZ [+ + +]
Author: Tim Crawford <tcrawford@system76.com>
Date:   Sat Jul 30 21:22:43 2022 -0600

    ALSA: hda/realtek: Add quirk for Clevo NV45PZ
    
    commit be561ffad708f0cee18aee4231f80ffafaf7a419 upstream.
    
    Fixes headset detection on Clevo NV45PZ.
    
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220731032243.4300-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for HP Spectre x360 15-eb0xxx [+ + +]
Author: Ivan Hasenkampf <ivan.hasenkampf@gmail.com>
Date:   Wed Aug 3 18:40:01 2022 +0200

    ALSA: hda/realtek: Add quirk for HP Spectre x360 15-eb0xxx
    
    commit 24df5428ef9d1ca1edd54eca7eb667110f2dfae3 upstream.
    
    Fixes speaker output on HP Spectre x360 15-eb0xxx
    
    [ re-sorted in SSID order by tiwai ]
    
    Signed-off-by: Ivan Hasenkampf <ivan.hasenkampf@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220803164001.290394-1-ivan.hasenkampf@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add quirk for Behringer UMC202HD [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 22 16:39:48 2022 +0200

    ALSA: usb-audio: Add quirk for Behringer UMC202HD
    
    commit e086c37f876fd1f551e2b4f9be97d4a1923cd219 upstream.
    
    Just like other Behringer models, UMC202HD (USB ID 1397:0507) requires
    the quirk for the stable streaming, too.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215934
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220722143948.29804-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
android: binder: stop saving a pointer to the VMA [+ + +]
Author: Liam R. Howlett <Liam.Howlett@oracle.com>
Date:   Mon Jun 20 21:09:09 2022 -0400

    android: binder: stop saving a pointer to the VMA
    
    [ Upstream commit a43cfc87caaf46710c8027a8c23b8a55f1078f19 ]
    
    Do not record a pointer to a VMA outside of the mmap_lock for later use.
    This is unsafe and there are a number of failure paths *after* the
    recorded VMA pointer may be freed during setup.  There is no callback to
    the driver to clear the saved pointer from generic mm code.  Furthermore,
    the VMA pointer may become stale if any number of VMA operations end up
    freeing the VMA so saving it was fragile to being with.
    
    Instead, change the binder_alloc struct to record the start address of the
    VMA and use vma_lookup() to get the vma when needed.  Add lockdep
    mmap_lock checks on updates to the vma pointer to ensure the lock is held
    and depend on that lock for synchronization of readers and writers - which
    was already the case anyways, so the smp_wmb()/smp_rmb() was not
    necessary.
    
    [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]
    Link: https://lkml.kernel.org/r/20220621140212.vpkio64idahetbyf@revolver
    Fixes: da1b9564e85b ("android: binder: fix the race mmap and alloc_new_buf_locked")
    Reported-by: syzbot+58b51ac2b04e388ab7b0@syzkaller.appspotmail.com
    Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Christian Brauner (Microsoft) <brauner@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Hridya Valsaraju <hridya@google.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Cc: Martijn Coenen <maco@android.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Todd Kjos <tkjos@android.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arch: make TRACE_IRQFLAGS_NMI_SUPPORT generic [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed May 11 14:17:32 2022 +0100

    arch: make TRACE_IRQFLAGS_NMI_SUPPORT generic
    
    [ Upstream commit 4510bffb4d0246cdcc1f14c7367c026b807a862d ]
    
    On most architectures, IRQ flag tracing is disabled in NMI context, and
    architectures need to define and select TRACE_IRQFLAGS_NMI_SUPPORT in
    order to enable this.
    
    Commit:
    
      859d069ee1ddd878 ("lockdep: Prepare for NMI IRQ state tracking")
    
    Permitted IRQ flag tracing in NMI context, allowing lockdep to work in
    NMI context where an architecture had suitable entry logic. At the time,
    most architectures did not have such suitable entry logic, and this broke
    lockdep on such architectures. Thus, this was partially disabled in
    commit:
    
      ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs")
    
    ... with architectures needing to select TRACE_IRQFLAGS_NMI_SUPPORT to
    enable IRQ flag tracing in NMI context.
    
    Currently TRACE_IRQFLAGS_NMI_SUPPORT is defined under
    arch/x86/Kconfig.debug. Move it to arch/Kconfig so architectures can
    select it without having to provide their own definition.
    
    Since the regular TRACE_IRQFLAGS_SUPPORT is selected by
    arch/x86/Kconfig, the select of TRACE_IRQFLAGS_NMI_SUPPORT is moved
    there too.
    
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220511131733.4074499-2-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: cpufeature: Allow different PMU versions in ID_DFR0_EL1 [+ + +]
Author: Alexandru Elisei <alexandru.elisei@arm.com>
Date:   Fri Jun 17 12:13:32 2022 +0100

    arm64: cpufeature: Allow different PMU versions in ID_DFR0_EL1
    
    [ Upstream commit 506506cad3947b942425b119ffa2b06715d5d804 ]
    
    Commit b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in
    PMU implementations") made it possible to run Linux on a machine with PMUs
    with different versions without tainting the kernel. The patch relaxed the
    restriction only for the ID_AA64DFR0_EL1.PMUVer field, and missed doing the
    same for ID_DFR0_EL1.PerfMon , which also reports the PMU version, but for
    the AArch32 state.
    
    For example, with Linux running on two clusters with different PMU
    versions, the kernel is tainted when bringing up secondaries with the
    following message:
    
    [    0.097027] smp: Bringing up secondary CPUs ...
    [..]
    [    0.142805] Detected PIPT I-cache on CPU4
    [    0.142805] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_DFR0_EL1. Boot CPU: 0x00000004011088, CPU4: 0x00000005011088
    [    0.143555] CPU features: Unsupported CPU feature variation detected.
    [    0.143702] GICv3: CPU4: found redistributor 10000 region 0:0x000000002f180000
    [    0.143702] GICv3: CPU4: using allocated LPI pending table @0x00000008800d0000
    [    0.144888] CPU4: Booted secondary processor 0x0000010000 [0x410fd0f0]
    
    The boot CPU implements FEAT_PMUv3p1 (ID_DFR0_EL1.PerfMon, bits 27:24, is
    0b0100), but CPU4, part of the other cluster, implements FEAT_PMUv3p4
    (ID_DFR0_EL1.PerfMon = 0b0101).
    
    Treat the PerfMon field as FTR_NONSTRICT and FTR_EXACT to pass the sanity
    check and to match how PMUVer is treated for the 64bit ID register.
    
    Fixes: b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in PMU implementations")
    Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
    Link: https://lore.kernel.org/r/20220617111332.203061-1-alexandru.elisei@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: Do not forget syscall when starting a new thread. [+ + +]
Author: Francis Laniel <flaniel@linux.microsoft.com>
Date:   Wed Jun 8 17:24:46 2022 +0100

    arm64: Do not forget syscall when starting a new thread.
    
    [ Upstream commit de6921856f99c11d3986c6702d851e1328d4f7f6 ]
    
    Enable tracing of the execve*() system calls with the
    syscalls:sys_exit_execve tracepoint by removing the call to
    forget_syscall() when starting a new thread and preserving the value of
    regs->syscallno across exec.
    
    Signed-off-by: Francis Laniel <flaniel@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20220608162447.666494-2-flaniel@linux.microsoft.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: allwinner: a64: orangepi-win: Fix LED node name [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Sat Jul 2 08:28:15 2022 -0500

    arm64: dts: allwinner: a64: orangepi-win: Fix LED node name
    
    [ Upstream commit b8eb2df19fbf97aa1e950cf491232c2e3bef8357 ]
    
    "status" does not match any pattern in the gpio-leds binding. Rename the
    node to the preferred pattern. This fixes a `make dtbs_check` error.
    
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://lore.kernel.org/r/20220702132816.46456-1-samuel@sholland.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt7622: fix BPI-R64 WPS button [+ + +]
Author: Nick Hainke <vincent@systemli.org>
Date:   Thu Jun 30 13:16:57 2022 +0200

    arm64: dts: mt7622: fix BPI-R64 WPS button
    
    [ Upstream commit c98e6e683632386a3bd284acda4342e68aec4c41 ]
    
    The bananapi R64 (BPI-R64) experiences wrong WPS button signals.
    In OpenWrt pushing the WPS button while powering on the device will set
    it to recovery mode. Currently, this also happens without any user
    interaction. In particular, the wrong signals appear while booting the
    device or restarting it, e.g. after doing a system upgrade. If the
    device is in recovery mode the user needs to manually power cycle or
    restart it.
    
    The official BPI-R64 sources set the WPS button to GPIO_ACTIVE_LOW in
    the device tree. This setting seems to suppress the unwanted WPS button
    press signals. So this commit changes the button from GPIO_ACTIVE_HIGH to
    GPIO_ACTIVE_LOW.
    
    The official BPI-R64 sources can be found on
    https://github.com/BPI-SINOVOIP/BPI-R64-openwrt
    
    Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board")
    
    Suggested-by: INAGAKI Hiroshi <musashino.open@gmail.com>
    Signed-off-by: Nick Hainke <vincent@systemli.org>
    Link: https://lore.kernel.org/r/20220630111746.4098-1-vincent@systemli.org
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt8192: Fix idle-states entry-method [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Fri Jun 17 19:31:50 2022 -0400

    arm64: dts: mt8192: Fix idle-states entry-method
    
    [ Upstream commit 2e599740f7e423ee89fb027896cb2635dd43784f ]
    
    The entry-method property of the idle-states node should be "psci" as
    described in the idle-states binding, since this is already the value of
    enable-method in the CPU nodes. Fix it to get rid of a dtbs_check
    warning.
    
    Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20220617233150.2466344-3-nfraprado@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt8192: Fix idle-states nodes naming scheme [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Fri Jun 17 19:31:49 2022 -0400

    arm64: dts: mt8192: Fix idle-states nodes naming scheme
    
    [ Upstream commit 399e23ad51caaf62400a531c9268ad3c453c3d76 ]
    
    Tweak the name of the idle-states subnodes so that they follow the
    binding pattern, getting rid of dtbs_check warnings.
    
    Only the usage of "-" in the name was necessary, but "off" was also
    exchanged for "sleep" since that seems to be a more common wording in
    other dts files.
    
    Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20220617233150.2466344-2-nfraprado@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: ipq8074: fix NAND node name [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Tue Jun 21 14:06:42 2022 +0200

    arm64: dts: qcom: ipq8074: fix NAND node name
    
    [ Upstream commit b39961659ffc3c3a9e3d0d43b0476547b5f35d49 ]
    
    Per schema it should be nand-controller@79b0000 instead of nand@79b0000.
    Fix it to match nand-controller.yaml requirements.
    
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220621120642.518575-1-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node [+ + +]
Author: Sireesh Kodali <sireeshkodali1@gmail.com>
Date:   Thu May 26 19:47:40 2022 +0530

    arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node
    
    [ Upstream commit 5458d6f2827cd30218570f266b8d238417461f2f ]
    
    The smem-state properties for the pronto node were incorrectly labelled,
    reading `qcom,state*` rather than `qcom,smem-state*`. Fix that, allowing
    the stop state to be used.
    
    Fixes: 88106096cbf8 ("ARM: dts: msm8916: Add and enable wcnss node")
    Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220526141740.15834-3-sireeshkodali1@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: qcs404: Fix incorrect USB2 PHYs assignment [+ + +]
Author: Sumit Garg <sumit.garg@linaro.org>
Date:   Mon Jul 11 14:00:38 2022 +0530

    arm64: dts: qcom: qcs404: Fix incorrect USB2 PHYs assignment
    
    [ Upstream commit 58577966a42fc0b660b5e2c7c9e5a2241363ea83 ]
    
    Currently the DT for QCS404 SoC has setup for 2 USB2 PHYs with one each
    assigned to USB3 controller and USB2 controller. This assignment is
    incorrect which only works by luck: as when each USB HCI comes up it
    configures the *other* controllers PHY which is enough to make them
    happy. If, for any reason, we were to disable one of the controllers then
    both would stop working.
    
    This was a difficult inconsistency to be caught which was found while
    trying to enable USB support in u-boot. So with all the required drivers
    ported to u-boot, I couldn't get the same USB storage device enumerated
    in u-boot which was being enumerated fine by the kernel.
    
    The root cause of the problem came out to be that I wasn't enabling USB2
    PHY: "usb2_phy_prim" in u-boot. Then I realised that via simply disabling
    the same USB2 PHY currently assigned to USB2 host controller in the
    kernel disabled enumeration for USB3 host controller as well.
    
    So fix this inconsistency by correctly assigning USB2 PHYs.
    
    Fixes: 9375e7d719b3 ("arm64: dts: qcom: qcs404: Add USB devices and PHYs")
    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220711083038.1518529-1-sumit.garg@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7180: Remove ipa_fw_mem node on trogdor [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Tue May 17 12:33:07 2022 -0700

    arm64: dts: qcom: sc7180: Remove ipa_fw_mem node on trogdor
    
    [ Upstream commit e60414644cf3a703e10ed4429c15263095945ffe ]
    
    We don't use this carveout on trogdor boards, and having it defined in
    the sc7180 SoC file causes an overlap message to be printed at boot.
    
     OF: reserved mem: OVERLAP DETECTED!
     memory@86000000 (0x0000000086000000--0x000000008ec00000) overlaps with memory@8b700000 (0x000000008b700000--0x000000008b710000)
    
    Delete the node in the trogdor dtsi file to fix the overlap problem and
    remove the error message.
    
    Cc: Alex Elder <elder@linaro.org>
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Fixes: 310b266655a3 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220517193307.3034602-1-swboyd@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm630: disable GPU by default [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat May 21 23:27:00 2022 +0300

    arm64: dts: qcom: sdm630: disable GPU by default
    
    [ Upstream commit 1c047919763b4548381d1ab3320af1df66ab83df ]
    
    The SoC's device tree file disables gpucc and adreno's SMMU by default.
    So let's disable the GPU too. Moreover it looks like SMMU might be not
    usable without additional patches (which means that GPU is unusable
    too). No board uses GPU at this moment.
    
    Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220521202708.1509308-4-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm630: fix gpu's interconnect path [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat May 21 23:27:04 2022 +0300

    arm64: dts: qcom: sdm630: fix gpu's interconnect path
    
    [ Upstream commit 3cd1c4f41d64a40ea6bc4575ae28e37542123d77 ]
    
    ICC path for the GPU incorrectly states <&gnoc 1 &bimc 5>, which is
    a path from SLAVE_GNOC_BIMC to SLAVE_EBI. According to the downstream
    kernel sources, the GPU uses MASTER_OXILI here, which is equivalent to
    <&bimc 1 ...>.
    
    While we are at it, use defined names instead of the numbers for this
    interconnect path.
    
    Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration")
    Reported-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220521202708.1509308-8-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm630: fix the qusb2phy ref clock [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat May 21 23:27:01 2022 +0300

    arm64: dts: qcom: sdm630: fix the qusb2phy ref clock
    
    [ Upstream commit 924bbd8dd60e094344711c3526a5b308d71dc008 ]
    
    According to the downstram DT file, the qusb2phy ref clock should be
    GCC_RX0_USB2_CLKREF_CLK, not GCC_RX1_USB2_CLKREF_CLK.
    
    Fixes: c65a4ed2ea8b ("arm64: dts: qcom: sdm630: Add USB configuration")
    Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220521202708.1509308-5-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm636-sony-xperia-ganges-mermaid: correct sdc2 pinconf [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat May 21 23:27:05 2022 +0300

    arm64: dts: qcom: sdm636-sony-xperia-ganges-mermaid: correct sdc2 pinconf
    
    [ Upstream commit 3a04cec9cba393abfe70fc62e523f381c9baec2e ]
    
    Fix the device tree node in the &sdc2_state_on override. The sdm630 uses
    'clk' rather than 'pinconf-clk'.
    
    Fixes: 4c1d849ec047 ("arm64: dts: qcom: sdm630-xperia: Retire sdm630-sony-xperia-ganges.dtsi")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220521202708.1509308-9-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm6125: Append -state suffix to pinctrl nodes [+ + +]
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Sun May 8 12:03:34 2022 +0200

    arm64: dts: qcom: sm6125: Append -state suffix to pinctrl nodes
    
    [ Upstream commit cbfb5668aece448877fa7826cde81c9d06f4a4ac ]
    
    According to qcom,sm6125-pinctrl.yaml all nodes inside the tlmm must be
    suffixed by -state:
    
        qcom/sm6125-sony-xperia-seine-pdx201.dtb: pinctrl@500000: 'sdc2-off', 'sdc2-on' do not match any of the regexes: '-state$', 'pinctrl-[0-9]+'
    
    The label names have been updated to match, going from sdc2_state_X to
    sdc2_X_state.
    
    Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
    Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220508100336.127176-2-marijn.suijten@somainline.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm6125: Move sdc2 pinctrl from seine-pdx201 to sm6125 [+ + +]
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Sun May 8 12:03:33 2022 +0200

    arm64: dts: qcom: sm6125: Move sdc2 pinctrl from seine-pdx201 to sm6125
    
    [ Upstream commit 6990640a93ba4e76dd62ca3ea1082a7354db09d7 ]
    
    Both the sdc2-on and sdc2-off pinctrl nodes are used by the
    sdhci@4784000 node in sm6125.dtsi.  Surprisingly sdc2-off is defined in
    sm6125, yet its sdc2-on counterpart is only defined in board-specific DT
    for the Sony Seine PDX201 board/device resulting in an "undefined label
    &sdc2_state_on" error if sm6125.dtsi were included elsewhere.
    This sm6125 base dtsi should not rely on externally defined labels; the
    properties referencing it should then also be written externally.
    Since the sdc2-on pin configuration is board-independent just like
    sdc2-off, move it from seine-pdx201.dts into sm6125.dtsi.
    
    The SDCard-detect pin (gpio98) is however board-specific, and remains as
    an overwrite in seine-pdx201.dts for both the on and off state.
    
    As a drive-by cleanup, reorder bias- and drive-strength properties.
    
    Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
    Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220508100336.127176-1-marijn.suijten@somainline.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250: add missing PCIe PHY clock-cells [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue Jul 5 13:40:20 2022 +0200

    arm64: dts: qcom: sm8250: add missing PCIe PHY clock-cells
    
    [ Upstream commit d9fd162ce764c227fcfd4242f6c1639895a9481f ]
    
    Add the missing '#clock-cells' properties to the PCIe QMP PHY nodes.
    
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220705114032.22787-3-johan+linaro@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: renesas: beacon: Fix regulator node names [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed May 11 12:14:06 2022 +0200

    arm64: dts: renesas: beacon: Fix regulator node names
    
    [ Upstream commit 7512af9f78dedea7e04225f665dad6750df7d095 ]
    
    Currently there are two nodes named "regulator_camera".  This causes the
    former to be overwritten by the latter.
    
    Fix this by renaming them to unique names, using the preferred hyphen
    instead of an underscore.
    
    While at it, update the name of the audio regulator (which was added in
    the same commit) to use a hyphen.
    
    Fixes: a1d8a344f1ca0709 ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/a9ac82bdf108162487289d091c53a9b3de393f13.1652263918.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: renesas: Fix thermal-sensors on single-zone sensors [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jun 15 16:04:26 2022 +0200

    arm64: dts: renesas: Fix thermal-sensors on single-zone sensors
    
    [ Upstream commit 62e8a53431145e06e503b71625a34eaa87b72b2c ]
    
    "make dtbs_check":
    
        arch/arm64/boot/dts/renesas/r8a774c0-cat874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[74], [0]] is too long
        arch/arm64/boot/dts/renesas/r8a774c0-ek874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[79], [0]] is too long
        arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[82], [0]] is too long
        arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[87], [0]] is too long
        arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[105], [0]] is too long
                From schema: Documentation/devicetree/bindings/thermal/thermal-zones.yaml
    
    Indeed, the thermal sensors on R-Car E3 and RZ/G2E support only a single
    zone, hence #thermal-sensor-cells = <0>.
    
    Fix this by dropping the bogus zero cell from the thermal sensor
    specifiers.
    
    Fixes: 8fa7d18f9ee2dc20 ("arm64: dts: renesas: r8a77990: Create thermal zone to support IPA")
    Fixes: 8438bfda9d768157 ("arm64: dts: renesas: r8a774c0: Create thermal zone to support IPA")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Link: https://lore.kernel.org/r/28b812fdd1fc3698311fac984ab8b91d3d655c1c.1655301684.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: uniphier: Fix USB interrupts for PXs3 SoC [+ + +]
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Tue Aug 2 22:36:47 2022 +0900

    arm64: dts: uniphier: Fix USB interrupts for PXs3 SoC
    
    commit fe17b91a7777df140d0f1433991da67ba658796c upstream.
    
    An interrupt for USB device are shared with USB host. Set interrupt-names
    property to common "dwc_usb3" instead of "host" and "peripheral".
    
    Cc: stable@vger.kernel.org
    Fixes: d7b9beb830d7 ("arm64: dts: uniphier: Add USB3 controller nodes")
    Reported-by: Ryuta NAKANISHI <nakanishi.ryuta@socionext.com>
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: fix oops in concurrently setting insn_emulation sysctls [+ + +]
Author: haibinzhang (张海斌) <haibinzhang@tencent.com>
Date:   Sat Jul 2 05:43:19 2022 +0000

    arm64: fix oops in concurrently setting insn_emulation sysctls
    
    [ Upstream commit af483947d472eccb79e42059276c4deed76f99a6 ]
    
    emulation_proc_handler() changes table->data for proc_dointvec_minmax
    and can generate the following Oops if called concurrently with itself:
    
     | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
     | Internal error: Oops: 96000006 [#1] SMP
     | Call trace:
     | update_insn_emulation_mode+0xc0/0x148
     | emulation_proc_handler+0x64/0xb8
     | proc_sys_call_handler+0x9c/0xf8
     | proc_sys_write+0x18/0x20
     | __vfs_write+0x20/0x48
     | vfs_write+0xe4/0x1d0
     | ksys_write+0x70/0xf8
     | __arm64_sys_write+0x20/0x28
     | el0_svc_common.constprop.0+0x7c/0x1c0
     | el0_svc_handler+0x2c/0xa0
     | el0_svc+0x8/0x200
    
    To fix this issue, keep the table->data as &insn->current_mode and
    use container_of() to retrieve the insn pointer. Another mutex is
    used to protect against the current_mode update but not for retrieving
    insn_emulation as table->data is no longer changing.
    
    Co-developed-by: hewenliang <hewenliang4@huawei.com>
    Signed-off-by: hewenliang <hewenliang4@huawei.com>
    Signed-off-by: Haibin Zhang <haibinzhang@tencent.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Link: https://lore.kernel.org/r/20220128090324.2727688-1-hewenliang4@huawei.com
    Link: https://lore.kernel.org/r/9A004C03-250B-46C5-BF39-782D7551B00E@tencent.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags" [+ + +]
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Fri Jun 10 16:21:41 2022 +0100

    arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags"
    
    [ Upstream commit 20794545c14692094a882d2221c251c4573e6adf ]
    
    This reverts commit e5b8d9218951e59df986f627ec93569a0d22149b.
    
    Pages mapped in user-space with PROT_MTE have the allocation tags either
    zeroed or copied/restored to some user values. In order for the kernel
    to access such pages via page_address(), resetting the tag in
    page->flags was necessary. This tag resetting was deferred to
    set_pte_at() -> mte_sync_page_tags() but it can race with another CPU
    reading the flags (via page_to_virt()):
    
    P0 (mte_sync_page_tags):        P1 (memcpy from virt_to_page):
                                      Rflags!=0xff
      Wflags=0xff
      DMB (doesn't help)
      Wtags=0
                                      Rtags=0   // fault
    
    Since now the post_alloc_hook() function resets the page->flags tag when
    unpoisoning is skipped for user pages (including the __GFP_ZEROTAGS
    case), revert the arm64 commit calling page_kasan_tag_reset().
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Peter Collingbourne <pcc@google.com>
    Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Acked-by: Andrey Konovalov <andreyknvl@gmail.com>
    Link: https://lore.kernel.org/r/20220610152141.2148929-5-catalin.marinas@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: select TRACE_IRQFLAGS_NMI_SUPPORT [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed May 11 14:17:33 2022 +0100

    arm64: select TRACE_IRQFLAGS_NMI_SUPPORT
    
    [ Upstream commit 3381da254fab37ba08c4b7c4f19b4ee28b1a27ec ]
    
    Due to an oversight, on arm64 lockdep IRQ state tracking doesn't work as
    intended in NMI context. This demonstrably results in bogus warnings
    from lockdep, and in theory could mask a variety of issues.
    
    On arm64, we've consistently tracked IRQ flag state for NMIs (and
    saved/restored the state of the interrupted context) since commit:
    
      f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
    
    That commit fixed most lockdep issues with NMI by virtue of the
    save/restore of the lockdep state of the interrupted context. However,
    for lockdep IRQ state tracking to consistently take effect in NMI
    context it has been necessary to select TRACE_IRQFLAGS_NMI_SUPPORT since
    commit:
    
      ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs")
    
    As arm64 does not select TRACE_IRQFLAGS_NMI_SUPPORT, this means that the
    lockdep state can be stale in NMI context, and some uses of that state
    can consume stale data.
    
    When an NMI is taken arm64 entry code will call arm64_enter_nmi(). This
    will enter NMI context via __nmi_enter() before calling
    lockdep_hardirqs_off() to inform lockdep that IRQs have been masked.
    Where TRACE_IRQFLAGS_NMI_SUPPORT is not selected, lockdep_hardirqs_off()
    will not update lockdep state if called in NMI context. Thus if IRQs
    were enabled in the original context, lockdep will continue to believe
    that IRQs are enabled despite the call to lockdep_hardirqs_off().
    
    However, the lockdep_assert_*() checks do take effect in NMI context,
    and will consume the stale lockdep state. If an NMI is taken from a
    context which had IRQs enabled, and during the handling of the NMI
    something calls lockdep_assert_irqs_disabled(), this will result in a
    spurious warning based upon the stale lockdep state.
    
    This can be seen when using perf with GICv3 pseudo-NMIs. Within the perf
    NMI handler we may attempt a uaccess to record the userspace callchain,
    and is this faults the el1_abort() call in the nested context will call
    exit_to_kernel_mode() when returning, which has a
    lockdep_assert_irqs_disabled() assertion:
    
    | # ./perf record -a -g sh
    | ------------[ cut here ]------------
    | WARNING: CPU: 0 PID: 164 at arch/arm64/kernel/entry-common.c:73 exit_to_kernel_mode+0x118/0x1ac
    | Modules linked in:
    | CPU: 0 PID: 164 Comm: perf Not tainted 5.18.0-rc5 #1
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 004003c5 (nzcv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : exit_to_kernel_mode+0x118/0x1ac
    | lr : el1_abort+0x80/0xbc
    | sp : ffff8000080039f0
    | pmr_save: 000000f0
    | x29: ffff8000080039f0 x28: ffff6831054e4980 x27: ffff683103adb400
    | x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001
    | x23: 00000000804000c5 x22: 00000000000000c0 x21: 0000000000000001
    | x20: ffffbd51e635ec44 x19: ffff800008003a60 x18: 0000000000000000
    | x17: ffffaadf98d23000 x16: ffff800008004000 x15: 0000ffffd14f25c0
    | x14: 0000000000000000 x13: 00000000000018eb x12: 0000000000000040
    | x11: 000000000000001e x10: 000000002b820020 x9 : 0000000100110000
    | x8 : 000000000045cac0 x7 : 0000ffffd14f25c0 x6 : ffffbd51e639b000
    | x5 : 00000000000003e5 x4 : ffffbd51e58543b0 x3 : 0000000000000001
    | x2 : ffffaadf98d23000 x1 : ffff6831054e4980 x0 : 0000000100110000
    | Call trace:
    |  exit_to_kernel_mode+0x118/0x1ac
    |  el1_abort+0x80/0xbc
    |  el1h_64_sync_handler+0xa4/0xd0
    |  el1h_64_sync+0x74/0x78
    |  __arch_copy_from_user+0xa4/0x230
    |  get_perf_callchain+0x134/0x1e4
    |  perf_callchain+0x7c/0xa0
    |  perf_prepare_sample+0x414/0x660
    |  perf_event_output_forward+0x80/0x180
    |  __perf_event_overflow+0x70/0x13c
    |  perf_event_overflow+0x1c/0x30
    |  armv8pmu_handle_irq+0xe8/0x160
    |  armpmu_dispatch_irq+0x2c/0x70
    |  handle_percpu_devid_fasteoi_nmi+0x7c/0xbc
    |  generic_handle_domain_nmi+0x3c/0x60
    |  gic_handle_irq+0x1dc/0x310
    |  call_on_irq_stack+0x2c/0x54
    |  do_interrupt_handler+0x80/0x94
    |  el1_interrupt+0xb0/0xe4
    |  el1h_64_irq_handler+0x18/0x24
    |  el1h_64_irq+0x74/0x78
    |  lockdep_hardirqs_off+0x50/0x120
    |  trace_hardirqs_off+0x38/0x214
    |  _raw_spin_lock_irq+0x98/0xa0
    |  pipe_read+0x1f8/0x404
    |  new_sync_read+0x140/0x150
    |  vfs_read+0x190/0x1dc
    |  ksys_read+0xdc/0xfc
    |  __arm64_sys_read+0x20/0x30
    |  invoke_syscall+0x48/0x114
    |  el0_svc_common.constprop.0+0x158/0x17c
    |  do_el0_svc+0x28/0x90
    |  el0_svc+0x60/0x150
    |  el0t_64_sync_handler+0xa4/0x130
    |  el0t_64_sync+0x19c/0x1a0
    | irq event stamp: 483
    | hardirqs last  enabled at (483): [<ffffbd51e636aa24>] _raw_spin_unlock_irqrestore+0xa4/0xb0
    | hardirqs last disabled at (482): [<ffffbd51e636acd0>] _raw_spin_lock_irqsave+0xb0/0xb4
    | softirqs last  enabled at (468): [<ffffbd51e5216f58>] put_cpu_fpsimd_context+0x28/0x70
    | softirqs last disabled at (466): [<ffffbd51e5216ed4>] get_cpu_fpsimd_context+0x0/0x5c
    | ---[ end trace 0000000000000000 ]---
    
    Note that as lockdep_assert_irqs_disabled() uses WARN_ON_ONCE(), and
    this uses a BRK, the warning is logged with the real PSTATE at the time
    of the warning, which clearly has DAIF.I set, meaning IRQs (and
    pseudo-NMIs) were definitely masked and the warning is spurious.
    
    Fix this by selecting TRACE_IRQFLAGS_NMI_SUPPORT such that the existing
    entry tracking takes effect, as we had originally intended when the
    arm64 entry code was fixed for transitions to/from NMI.
    
    Arguably the lockdep_assert_*() functions should have the same NMI
    checks as the rest of the code to prevent spurious warnings when
    TRACE_IRQFLAGS_NMI_SUPPORT is not selected, but the real fix for any
    architecture is to explicitly handle the transitions to/from NMI in the
    entry code.
    
    Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220511131733.4074499-3-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Fix SDMMC1 CD on P2888 [+ + +]
Author: Tamás Szűcs <tszucs@protonmail.ch>
Date:   Sun Jun 12 14:59:45 2022 +0000

    arm64: tegra: Fix SDMMC1 CD on P2888
    
    [ Upstream commit b415bb7c976f1d595ed752001c0938f702645dab ]
    
    Hook SDMMC1 CD up with CVM GPIO02 (SOC_GPIO11) used for card detection on J4
    (uSD socket) on the carrier.
    
    Fixes: ef633bfc21e9 ("arm64: tegra: Enable card detect for SD card on P2888")
    Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Fixup SYSRAM references [+ + +]
Author: Thierry Reding <treding@nvidia.com>
Date:   Fri Nov 12 13:35:37 2021 +0100

    arm64: tegra: Fixup SYSRAM references
    
    [ Upstream commit 7fa307524a4d721d4a04523018509882c5414e72 ]
    
    The json-schema bindings for SRAM expect the nodes to be called "sram"
    rather than "sysram" or "shmem". Furthermore, place the brackets around
    the SYSRAM references such that a two-element array is created rather
    than a two-element array nested in a single-element array. This is not
    relevant for device tree itself, but allows the nodes to be properly
    validated against json-schema bindings.
    
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Mark BPMP channels as no-memory-wc [+ + +]
Author: Mikko Perttunen <mperttunen@nvidia.com>
Date:   Wed Jun 22 16:23:00 2022 +0300

    arm64: tegra: Mark BPMP channels as no-memory-wc
    
    [ Upstream commit 61192a9d8a6367ae1b8234876941b037910a2459 ]
    
    The Tegra SYSRAM contains regions access to which is restricted to
    certain hardware blocks on the system, and speculative accesses to
    those will cause issues.
    
    Patch 'misc: sram: Only map reserved areas in Tegra SYSRAM' attempted
    to resolve this by only mapping the regions specified in the device
    tree on the assumption that there are no such restricted areas within
    the 64K-aligned area of memory that contains the memory we wish to map.
    
    Turns out this assumption is wrong, as there are such areas above the
    4K pages described in the device trees. As such, we need to use the
    bigger hammer that is no-memory-wc, which causes the memory to be
    mapped as Device memory to which speculative accesses are disallowed.
    
    As such, the previous patch in the series,
      'firmware: tegra: bpmp: do only aligned access to IPC memory area',
    is required with this patch to make the BPMP driver only issue aligned
    memory accesses as those are also required with Device memory.
    
    Fixes: fec29bf04994 ("misc: sram: Only map reserved areas in Tegra SYSRAM")
    Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
    Reviewed-by: Yousaf Kaukab <ykaukab@suse.de>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Update Tegra234 BPMP channel addresses [+ + +]
Author: Mikko Perttunen <mperttunen@nvidia.com>
Date:   Fri Nov 12 13:35:39 2021 +0100

    arm64: tegra: Update Tegra234 BPMP channel addresses
    
    [ Upstream commit 98094be152d34f8014ca67fbdc210e5261c4b09d ]
    
    On final Tegra234 systems, shared memory for communication with BPMP is
    located at offset 0x70000 in SYSRAM.
    
    Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: bcm: Fix refcount leak in bcm_kona_smc_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 12:13:25 2022 +0400

    ARM: bcm: Fix refcount leak in bcm_kona_smc_init
    
    [ Upstream commit cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76 ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b8eb35fd594a ("ARM: bcm281xx: Add L2 cache enable code")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: ast2500-evb: fix board compatible [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun May 29 12:49:25 2022 +0200

    ARM: dts: ast2500-evb: fix board compatible
    
    [ Upstream commit 30b276fca5c0644f3cb17bceb1bd6a626c670184 ]
    
    The AST2500 EVB board should have dedicated compatible.
    
    Fixes: 02440622656d ("arm/dst: Add Aspeed ast2500 device tree")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220529104928.79636-4-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: ast2600-evb-a1: fix board compatible [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun May 29 12:49:27 2022 +0200

    ARM: dts: ast2600-evb-a1: fix board compatible
    
    [ Upstream commit 33c39140cc298e0d4e36083cb9a665a837773a60 ]
    
    The AST2600 EVB A1 board should have dedicated compatible.
    
    Fixes: a72955180372 ("ARM: dts: aspeed: ast2600evb: Add dts file for A1 and A0")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220529104928.79636-6-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: ast2600-evb: fix board compatible [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun May 29 12:49:26 2022 +0200

    ARM: dts: ast2600-evb: fix board compatible
    
    [ Upstream commit aa5e06208500a0db41473caebdee5a2e81d5a277 ]
    
    The AST2600 EVB board should have dedicated compatible.
    
    Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220529104928.79636-5-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM5301X: Add DT for Meraki MR26 [+ + +]
Author: Christian Lamparter <chunkeey@gmail.com>
Date:   Sat Jun 18 00:00:29 2022 +0200

    ARM: dts: BCM5301X: Add DT for Meraki MR26
    
    [ Upstream commit 935327a73553001f8d81375c76985d05f604507f ]
    
    Meraki MR26 is an EOL wireless access point featuring a
    PoE ethernet port and two dual-band 3x3 MIMO 802.11n
    radios and 1x1 dual-band WIFI dedicated to scanning.
    
    Thank you Amir for the unit and PSU.
    
    Hardware info:
    SOC   : Broadcom BCM53015A1KFEBG (dual-core Cortex-A9 CPU at 800 MHz)
    RAM   : SK Hynix Inc. H5TQ1G63EFR, 1 GBit DDR3 SDRAM = 128 MiB
    NAND  : Spansion S34ML01G100TF100, 1 GBit SLC NAND Flash = 128 MiB
    ETH   : 1 GBit Ethernet Port - PoE (TPS23754 PoE Interface)
    WIFI0 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn (3x3:3)
    WIFI1 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn (3x3:3)
    WIFI2 : Broadcom BCM43428 "Air Marshal" 802.11 abgn (1x1:1)
    BUTTON: One reset key behind a small hole next to the Ethernet Port
    LEDS  : One amber (fault), one white (indicator) LED, separate RGB-LED
    MISC  : Atmel AT24C64 8KiB EEPROM i2c
          : Ti INA219 26V, 12-bit, i2c output current/voltage/power monitor
    
    SERIAL:
          WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
          The Serial setting is 115200-8-N-1. The board has a populated
          right angle 1x4 0.1" pinheader.
          The pinout is: VCC (next to J3, has the pin 1 indicator), RX, TX, GND.
    
    Odd stuff:
    
    - uboot does not support lzma compression, but gzip'd uImage/DTB work.
    - uboot claims to support FIT, but fails to pass the DTB to the kernel.
      Appending the dtb after the kernel image works.
    - RGB-controller is supported through an external userspace program.
    - The ubi partition contains a "board-config" volume. It stores the
      MAC Address (0x66 in binary) and Serial No. (0x7c alpha-numerical).
    - SoC's temperature sensor always reports that it is on fire.
      This causes the system to immediately shutdown! Looking at reported
      "418 degree Celsius" suggests that this sensor is not working.
    
    WIFI:
    b43 is able to initialize all three WIFIs @ 802.11bg.
    | b43-phy0: Broadcom 43431 WLAN found (core revision 29)
    | bcma-pci-bridge 0000:01:00.0: bus1: Switched to core: 0x812
    | b43-phy0: Found PHY: Analog 9, Type 7 (HT), Revision 1
    | b43-phy0: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1
    | b43-phy0 warning: 5 GHz band is unsupported on this PHY
    | b43-phy1: Broadcom 43431 WLAN found (core revision 29)
    | bcma-pci-bridge 0001:01:00.0: bus2: Switched to core: 0x812
    | b43-phy1: Found PHY: Analog 9, Type 7 (HT), Revision 1
    | b43-phy1: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1
    | b43-phy1 warning: 5 GHz band is unsupported on this PHY
    | b43-phy2: Broadcom 43228 WLAN found (core revision 30)
    | bcma-pci-bridge 0002:01:00.0: bus3: Switched to core: 0x812
    | b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
    | b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
    | Broadcom 43xx driver loaded [ Features: NL ]
    
    Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: add missing properties for sram [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:51 2022 +0200

    ARM: dts: imx6ul: add missing properties for sram
    
    [ Upstream commit 5655699cf5cff9f4c4ee703792156bdd05d1addf ]
    
    All 3 properties are required by sram.yaml. Fixes the dtbs_check
    warning:
    sram@900000: '#address-cells' is a required property
    sram@900000: '#size-cells' is a required property
    sram@900000: 'ranges' is a required property
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: change operating-points to uint32-matrix [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:52 2022 +0200

    ARM: dts: imx6ul: change operating-points to uint32-matrix
    
    [ Upstream commit edb67843983bbdf61b4c8c3c50618003d38bb4ae ]
    
    operating-points is a uint32-matrix as per opp-v1.yaml. Change it
    accordingly. While at it, change fsl,soc-operating-points as well,
    although there is no bindings file (yet). But they should have the same
    format. Fixes the dt_binding_check warning:
    cpu@0: operating-points:0: [696000, 1275000, 528000, 1175000, 396000,
    1025000, 198000, 950000] is too long
    cpu@0: operating-points:0: Additional items are not allowed (528000,
    1175000, 396000, 1025000, 198000, 950000 were unexpected)
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: fix csi node compatible [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:55 2022 +0200

    ARM: dts: imx6ul: fix csi node compatible
    
    [ Upstream commit e0aca931a2c7c29c88ebf37f9c3cd045e083483d ]
    
    "fsl,imx6ul-csi" was never listed as compatible to "fsl,imx7-csi", neither
    in yaml bindings, nor previous txt binding. Remove the imx7 part. Fixes
    the dt schema check warning:
    csi@21c4000: compatible: 'oneOf' conditional failed, one must be fixed:
    ['fsl,imx6ul-csi', 'fsl,imx7-csi'] is too long
    Additional items are not allowed ('fsl,imx7-csi' was unexpected)
    'fsl,imx8mm-csi' was expected
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: fix keypad compatible [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:53 2022 +0200

    ARM: dts: imx6ul: fix keypad compatible
    
    [ Upstream commit 7d15e0c9a515494af2e3199741cdac7002928a0e ]
    
    According to binding, the compatible shall only contain imx6ul and imx21
    compatibles. Fixes the dt_binding_check warning:
    keypad@20b8000: compatible: 'oneOf' conditional failed, one must be fixed:
    ['fsl,imx6ul-kpp', 'fsl,imx6q-kpp', 'fsl,imx21-kpp'] is too long
    Additional items are not allowed ('fsl,imx6q-kpp', 'fsl,imx21-kpp' were
    unexpected)
    Additional items are not allowed ('fsl,imx21-kpp' was unexpected)
    'fsl,imx21-kpp' was expected
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: fix lcdif node compatible [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:56 2022 +0200

    ARM: dts: imx6ul: fix lcdif node compatible
    
    [ Upstream commit 1a884d17ca324531634cce82e9f64c0302bdf7de ]
    
    In yaml binding "fsl,imx6ul-lcdif" is listed as compatible to imx6sx-lcdif,
    but not imx28-lcdif. Change the list accordingly. Fixes the
    dt_binding_check warning:
    lcdif@21c8000: compatible: 'oneOf' conditional failed, one must be fixed:
    ['fsl,imx6ul-lcdif', 'fsl,imx28-lcdif'] is too long
    Additional items are not allowed ('fsl,imx28-lcdif' was unexpected)
    'fsl,imx6ul-lcdif' is not one of ['fsl,imx23-lcdif', 'fsl,imx28-lcdif',
    'fsl,imx6sx-lcdif']
    'fsl,imx6sx-lcdif' was expected
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul: fix qspi node compatible [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Jun 13 14:33:57 2022 +0200

    ARM: dts: imx6ul: fix qspi node compatible
    
    [ Upstream commit 0c6cf86e1ab433b2d421880fdd9c6e954f404948 ]
    
    imx6ul is not compatible to imx6sx, both have different erratas.
    Fixes the dt_binding_check warning:
    spi@21e0000: compatible: 'oneOf' conditional failed, one must be fixed:
    ['fsl,imx6ul-qspi', 'fsl,imx6sx-qspi'] is too long
    Additional items are not allowed ('fsl,imx6sx-qspi' was unexpected)
    'fsl,imx6ul-qspi' is not one of ['fsl,ls1043a-qspi']
    'fsl,imx6ul-qspi' is not one of ['fsl,imx8mq-qspi']
    'fsl,ls1021a-qspi' was expected
    'fsl,imx7d-qspi' was expected
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7d-colibri-emmc: add cpu1 supply [+ + +]
Author: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Date:   Mon May 16 15:47:23 2022 +0200

    ARM: dts: imx7d-colibri-emmc: add cpu1 supply
    
    [ Upstream commit ba28db60d34271e8a3cf4d7158d71607e8b1e57f ]
    
    Each cpu-core is supposed to list its supply separately, add supply for
    cpu1.
    
    Fixes: 2d7401f8632f ("ARM: dts: imx7d: Add cpu1 supply")
    Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom-msm8974: fix irq type on blsp2_uart1 [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Sun May 22 10:36:18 2022 +0200

    ARM: dts: qcom-msm8974: fix irq type on blsp2_uart1
    
    [ Upstream commit ab1489017aa7a9f02e24bee73cf9ec8079cd3909 ]
    
    IRQ_TYPE_NONE is invalid, so use the correct interrupt type.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Fixes: b05f82b152c9 ("ARM: dts: qcom: msm8974: Add blsp2_uart7 for bluetooth on sirius")
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220522083618.17894-1-luca@z3ntu.xyz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: mdm9615: add missing PMIC GPIO reg [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat May 7 21:49:12 2022 +0200

    ARM: dts: qcom: mdm9615: add missing PMIC GPIO reg
    
    [ Upstream commit dc590cdc31f636ea15658f1206c3e380a53fb78e ]
    
    'reg' property is required in SSBI children:
      qcom-mdm9615-wp8548-mangoh-green.dtb: gpio@150: 'reg' is a required property
    
    Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220507194913.261121-11-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: pm8841: add required thermal-sensor-cells [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Jun 8 13:27:02 2022 +0200

    ARM: dts: qcom: pm8841: add required thermal-sensor-cells
    
    [ Upstream commit e2759fa0676c9a32bbddb9aff955b54bb35066ad ]
    
    The PM8841 temperature sensor has to define thermal-sensor-cells.
    
    Fixes: dab8134ca072 ("ARM: dts: qcom: Add PM8841 functions device nodes")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220608112702.80873-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx55: Fix the IRQ trigger type for UART [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Mon May 30 13:38:40 2022 +0530

    ARM: dts: qcom: sdx55: Fix the IRQ trigger type for UART
    
    [ Upstream commit ae500b351ab0006d933d804a2b7507fe1e98cecc ]
    
    The trigger type should be LEVEL_HIGH. So fix it!
    
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220530080842.37024-2-manivannan.sadhasivam@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: uniphier: Fix USB interrupts for PXs2 SoC [+ + +]
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Tue Aug 2 22:36:25 2022 +0900

    ARM: dts: uniphier: Fix USB interrupts for PXs2 SoC
    
    commit 9b0dc7abb5cc43a2dbf90690c3c6011dcadc574d upstream.
    
    An interrupt for USB device are shared with USB host. Set interrupt-names
    property to common "dwc_usb3" instead of "host" and "peripheral".
    
    Cc: stable@vger.kernel.org
    Fixes: 45be1573ad19 ("ARM: dts: uniphier: Add USB3 controller nodes")
    Reported-by: Ryuta NAKANISHI <nakanishi.ryuta@socionext.com>
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: ux500: Fix Codina accelerometer mounting matrix [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sat Jun 11 22:42:49 2022 +0200

    ARM: dts: ux500: Fix Codina accelerometer mounting matrix
    
    [ Upstream commit 0b2152e428ab91533a02888ff24e52e788dc4637 ]
    
    This was fixed wrong so fix it again. Now verified by using
    iio-sensor-proxy monitor-sensor test program.
    
    Link: https://lore.kernel.org/r/20220611204249.472250-1-linus.walleij@linaro.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: ux500: Fix Gavini accelerometer mounting matrix [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sat Jun 11 22:51:38 2022 +0200

    ARM: dts: ux500: Fix Gavini accelerometer mounting matrix
    
    [ Upstream commit e24c75f02a81d6ddac0072cbd7a03e799c19d558 ]
    
    This was fixed wrong so fix it. Now verified by using
    iio-sensor-proxy monitor-sensor test program.
    
    Link: https://lore.kernel.org/r/20220611205138.491513-1-linus.walleij@linaro.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: findbit: fix overflowing offset [+ + +]
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Tue Jul 26 23:51:48 2022 +0100

    ARM: findbit: fix overflowing offset
    
    [ Upstream commit ec85bd369fd2bfaed6f45dd678706429d4f75b48 ]
    
    When offset is larger than the size of the bit array, we should not
    attempt to access the array as we can perform an access beyond the
    end of the array. Fix this by changing the pre-condition.
    
    Using "cmp r2, r1; bhs ..." covers us for the size == 0 case, since
    this will always take the branch when r1 is zero, irrespective of
    the value of r2. This means we can fix this bug without adding any
    additional code!
    
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: display: Fix refcount leak bug [+ + +]
Author: Liang He <windhl@126.com>
Date:   Fri Jun 17 22:58:03 2022 +0800

    ARM: OMAP2+: display: Fix refcount leak bug
    
    [ Upstream commit 50b87a32a79bca6e275918a711fb8cc55e16d739 ]
    
    In omapdss_init_fbdev(), of_find_node_by_name() will return a node
    pointer with refcount incremented. We should use of_node_put() when
    it is not used anymore.
    
    Signed-off-by: Liang He <windhl@126.com>
    Message-Id: <20220617145803.4050918-1-windhl@126.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 11:37:24 2022 +0400

    ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init
    
    [ Upstream commit 942228fbf5d4901112178b93d41225be7c0dd9de ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 1e037794f7f0 ("ARM: OMAP3+: PRM: register interrupt information from DT")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Message-Id: <20220526073724.21169-1-linmq006@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: Fix refcount leak in omapdss_init_of [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 08:48:58 2022 +0400

    ARM: OMAP2+: Fix refcount leak in omapdss_init_of
    
    [ Upstream commit 9705db1eff38d6b9114121f9e253746199b759c9 ]
    
    omapdss_find_dss_of_node() calls of_find_compatible_node() to get device
    node. of_find_compatible_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() in later error path and normal path.
    
    Fixes: e0c827aca0730 ("drm/omap: Populate DSS children in omapdss driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Message-Id: <20220601044858.3352-1-linmq006@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: pdata-quirks: Fix refcount leak bug [+ + +]
Author: Liang He <windhl@126.com>
Date:   Sat Jun 18 10:06:03 2022 +0800

    ARM: OMAP2+: pdata-quirks: Fix refcount leak bug
    
    [ Upstream commit 5cdbab96bab314c6f2f5e4e8b8a019181328bf5f ]
    
    In pdata_quirks_init_clocks(), the loop contains
    of_find_node_by_name() but without corresponding of_node_put().
    
    Signed-off-by: Liang He <windhl@126.com>
    Message-Id: <20220618020603.4055792-1-windhl@126.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: remove some dead code [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Oct 5 09:15:34 2021 +0200

    ARM: remove some dead code
    
    [ Upstream commit 08572cd41955166e387d9b4984294d37f8f7526c ]
    
    This code appears to be no longer used so let's get rid of it.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Tested-by: Keith Packard <keithpac@amazon.com>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: shmobile: rcar-gen2: Increase refcount for new reference [+ + +]
Author: Liang He <windhl@126.com>
Date:   Fri Jul 1 20:18:04 2022 +0800

    ARM: shmobile: rcar-gen2: Increase refcount for new reference
    
    [ Upstream commit 75a185fb92e58ccd3670258d8d3b826bd2fa6d29 ]
    
    In rcar_gen2_regulator_quirk(), for_each_matching_node_and_match() will
    automatically increase and decrease the refcount.  However, we should
    call of_node_get() for the new reference created in 'quirk->np'.
    Besides, we also should call of_node_put() before the 'quirk' being
    freed.
    
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220701121804.234223-1-windhl@126.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: audio-graph-card: Add of_node_put() in fail path [+ + +]
Author: Liang He <windhl@126.com>
Date:   Thu Jul 21 22:43:08 2022 +0800

    ASoC: audio-graph-card: Add of_node_put() in fail path
    
    [ Upstream commit 65fb8e2ef3531a6e950060fca6e551c923fb0f0e ]
    
    In asoc_simple_parse_dai(), we should call of_node_put() for the
    reference returned by of_graph_get_port_parent() in fail path.
    
    Fixes: ae30a694da4c ("ASoC: simple-card-utils: add asoc_simple_card_parse_dai()")
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220721144308.1301587-1-windhl@126.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: codecs: da7210: add check for i2c_add_driver [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue May 31 17:47:12 2022 +0800

    ASoC: codecs: da7210: add check for i2c_add_driver
    
    [ Upstream commit 82fa8f581a954ddeec1602bed9f8b4a09d100e6e ]
    
    As i2c_add_driver could return error if fails, it should be
    better to check the return value.
    However, if the CONFIG_I2C and CONFIG_SPI_MASTER are both true,
    the return value of i2c_add_driver will be covered by
    spi_register_driver.
    Therefore, it is necessary to add check and return error if fails.
    
    Fixes: aa0e25caafb7 ("ASoC: da7210: Add support for spi regmap")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20220531094712.2376759-1-jiasheng@iscas.ac.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: codecs: msm8916-wcd-digital: move gains from SX_TLV to S8_TLV [+ + +]
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Thu Jun 9 12:19:00 2022 +0100

    ASoC: codecs: msm8916-wcd-digital: move gains from SX_TLV to S8_TLV
    
    [ Upstream commit 5babb012c847beb6c8c7108fd78f650b7a2c6054 ]
    
    move all the digital gains form using SX_TLV to S8_TLV, these gains are
    actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB
    
    rest of the Qualcomm wcd codecs uses these properly.
    
    Fixes: ef8a4757a6db ("ASoC: msm8916-wcd-digital: Add sidetone support")
    Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220609111901.318047-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: codecs: wcd9335: move gains from SX_TLV to S8_TLV [+ + +]
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Thu Jun 9 12:19:01 2022 +0100

    ASoC: codecs: wcd9335: move gains from SX_TLV to S8_TLV
    
    [ Upstream commit 2fbe0953732e06b471cdedbf6f615b84235580d8 ]
    
    move all the digital gains form using SX_TLV to S8_TLV, these gains are
    actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB
    
    rest of the Qualcomm wcd codecs uses these properly.
    
    Fixes: 8c4f021d806a ("ASoC: wcd9335: add basic controls")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220609111901.318047-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 17:10:43 2022 +0400

    ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe
    
    [ Upstream commit 0a034d93ee929a9ea89f3fa5f1d8492435b9ee6e ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b6bc07d4360d ("ASoC: cros_ec_codec: support WoV")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Link: https://lore.kernel.org/r/20220603131043.38907-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl-asoc-card: force cast the asrc_format type [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Thu Jul 21 18:29:51 2022 +0800

    ASoC: fsl-asoc-card: force cast the asrc_format type
    
    [ Upstream commit 6c7b077dad62178c33f9a3ae17f90d6b0bf6e2e5 ]
    
    Fix sparse warning:
    sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: warning: incorrect type in argument 3 (different base types)
    sound/soc/fsl/fsl-asoc-card.c:833:45: sparse:    expected unsigned int [usertype] *out_value
    sound/soc/fsl/fsl-asoc-card.c:833:45: sparse:    got restricted snd_pcm_format_t *
    
    Fixes: 859e364302c5 ("ASoC: fsl-asoc-card: Support new property fsl, asrc-format")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1658399393-28777-4-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_asrc: force cast the asrc_format type [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Thu Jul 21 18:29:50 2022 +0800

    ASoC: fsl_asrc: force cast the asrc_format type
    
    [ Upstream commit c49932726de24405d45516b3f8ad2735714fdf05 ]
    
    Fix sparse warning:
    sound/soc/fsl/fsl_asrc.c:1177:60: sparse: warning: incorrect type in argument 3 (different base types)
    sound/soc/fsl/fsl_asrc.c:1177:60: sparse:    expected unsigned int [usertype] *out_value
    sound/soc/fsl/fsl_asrc.c:1177:60: sparse:    got restricted snd_pcm_format_t *
    sound/soc/fsl/fsl_asrc.c:1200:47: sparse: warning: restricted snd_pcm_format_t degrades to integer
    
    Fixes: 4520af41fd21 ("ASoC: fsl_asrc: Support new property fsl,asrc-format")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1658399393-28777-3-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_easrc: use snd_pcm_format_t type for sample_format [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Thu Jul 21 18:29:52 2022 +0800

    ASoC: fsl_easrc: use snd_pcm_format_t type for sample_format
    
    [ Upstream commit de27216cf2d645c2fd14e513707bdcd54e5b1de4 ]
    
    Fix sparse warning:
    sound/soc/fsl/fsl_easrc.c:562:33: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:563:34: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:565:38: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:566:39: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:608:33: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:609:34: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:615:40: sparse: warning: restricted snd_pcm_format_t degrades to integer
    sound/soc/fsl/fsl_easrc.c:616:41: sparse: warning: restricted snd_pcm_format_t degrades to integer
    
    sound/soc/fsl/fsl_easrc.c:1465:51: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/fsl_easrc.c:1465:51: sparse:    expected unsigned int sample_format
    sound/soc/fsl/fsl_easrc.c:1465:51: sparse:    got restricted snd_pcm_format_t [usertype] format
    sound/soc/fsl/fsl_easrc.c:1467:52: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/fsl_easrc.c:1467:52: sparse:    expected unsigned int sample_format
    sound/soc/fsl/fsl_easrc.c:1467:52: sparse:    got restricted snd_pcm_format_t [usertype] asrc_format
    sound/soc/fsl/fsl_easrc.c:1470:52: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/fsl_easrc.c:1470:52: sparse:    expected unsigned int sample_format
    sound/soc/fsl/fsl_easrc.c:1470:52: sparse:    got restricted snd_pcm_format_t [usertype] format
    sound/soc/fsl/fsl_easrc.c:1472:51: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/fsl_easrc.c:1472:51: sparse:    expected unsigned int sample_format
    sound/soc/fsl/fsl_easrc.c:1472:51: sparse:    got restricted snd_pcm_format_t [usertype] asrc_format
    sound/soc/fsl/fsl_easrc.c:1484:41: sparse: warning: incorrect type in argument 2 (different base types)
    sound/soc/fsl/fsl_easrc.c:1484:41: sparse:    expected restricted snd_pcm_format_t [usertype] *in_raw_format
    sound/soc/fsl/fsl_easrc.c:1484:41: sparse:    got unsigned int *
    sound/soc/fsl/fsl_easrc.c:1485:41: sparse: warning: incorrect type in argument 3 (different base types)
    sound/soc/fsl/fsl_easrc.c:1485:41: sparse:    expected restricted snd_pcm_format_t [usertype] *out_raw_format
    sound/soc/fsl/fsl_easrc.c:1485:41: sparse:    got unsigned int *
    sound/soc/fsl/fsl_easrc.c:1937:60: sparse: warning: incorrect type in argument 3 (different base types)
    sound/soc/fsl/fsl_easrc.c:1937:60: sparse:    expected unsigned int [usertype] *out_value
    sound/soc/fsl/fsl_easrc.c:1937:60: sparse:    got restricted snd_pcm_format_t *
    sound/soc/fsl/fsl_easrc.c:1943:49: sparse: warning: restricted snd_pcm_format_t degrades to integer
    
    Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1658399393-28777-5-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: imx-audmux: Silence a clang warning [+ + +]
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed May 25 22:05:43 2022 -0300

    ASoC: imx-audmux: Silence a clang warning
    
    [ Upstream commit 2f4a8171da06609bb6a063630ed546ee3d93dad7 ]
    
    Change the of_device_get_match_data() cast to (uintptr_t)
    to silence the following clang warning:
    
    sound/soc/fsl/imx-audmux.c:301:16: warning: cast to smaller integer type 'enum imx_audmux_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 6a8b8b582db1 ("ASoC: imx-audmux: Remove unused .id_table")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Link: https://lore.kernel.org/r/20220526010543.1164793-1-festevam@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: imx-card: Fix DSD/PDM mclk frequency [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Wed Jul 6 17:42:55 2022 +0800

    ASoC: imx-card: Fix DSD/PDM mclk frequency
    
    [ Upstream commit c0fabd12a8570cb932f13d9388f3d887ad44369b ]
    
    The DSD/PDM rate not only DSD64/128/256/512, which are the
    multiple rate of 44.1kHz,  but also support the multiple
    rate of 8kHz, so can't force all mclk frequency to be
    22579200Hz, need to assign the frequency according to
    rate.
    
    Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1657100575-8261-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: imx-card: use snd_pcm_format_t type for asrc_format [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Thu Jul 21 18:29:53 2022 +0800

    ASoC: imx-card: use snd_pcm_format_t type for asrc_format
    
    [ Upstream commit 409a8652e909e323c715f3088e6c3133e37c8881 ]
    
    Fix sparse warning:
    sound/soc/fsl/imx-card.c:653:59: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/imx-card.c:653:59: sparse:    expected unsigned int [usertype] asrc_format
    sound/soc/fsl/imx-card.c:653:59: sparse:    got restricted snd_pcm_format_t [usertype]
    sound/soc/fsl/imx-card.c:655:59: sparse: warning: incorrect type in assignment (different base types)
    sound/soc/fsl/imx-card.c:655:59: sparse:    expected unsigned int [usertype] asrc_format
    sound/soc/fsl/imx-card.c:655:59: sparse:    got restricted snd_pcm_format_t [usertype]
    
    Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1658399393-28777-6-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mchp-spdifrx: disable end of block interrupt on failures [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Jul 27 12:08:13 2022 +0300

    ASoC: mchp-spdifrx: disable end of block interrupt on failures
    
    [ Upstream commit 768ac4f12ca0fda935f58eb8c5120e9d795bc6e3 ]
    
    Disable end of block interrupt in case of wait for completion timeout
    or errors to undo previously enable operation (done in
    mchp_spdifrx_isr_blockend_en()). Otherwise we can end up with an
    unbalanced reference counter for this interrupt.
    
    Fixes: ef265c55c1ac ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20220727090814.2446111-2-claudiu.beznea@microchip.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 16:42:41 2022 +0400

    ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe
    
    [ Upstream commit efe2178d1a32492f99e7f1f2568eea5c88a85729 ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Fix refcount leak in some error paths.
    
    Fixes: 0f83f9296d5c ("ASoC: mediatek: Add machine driver for ALC5650 codec")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220603124243.31358-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Jun 2 07:41:42 2022 +0400

    ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe
    
    [ Upstream commit ae4f11c1ed2d67192fdf3d89db719ee439827c11 ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Fix missing of_node_put() in error paths.
    
    Fixes: 94319ba10eca ("ASoC: mediatek: Use platform_of_node for machine drivers")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220602034144.60159-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mt6359: Fix refcount leak bug [+ + +]
Author: Liang He <windhl@126.com>
Date:   Wed Jul 13 18:20:13 2022 +0800

    ASoC: mt6359: Fix refcount leak bug
    
    [ Upstream commit a8d5df69e2ec702d979f7d04ed519caf8691a032 ]
    
    In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call
    of_node_put() for the reference returned by of_get_child_by_name()
    which has increased the refcount.
    
    Fixes: 683530285316 ("ASoC: mt6359: fix failed to parse DT properties")
    Fixes: eef07b9e0925 ("ASoC: mediatek: mt6359: add MT6359 accdet jack driver")
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220713102013.367336-1-windhl@126.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 12:34:15 2022 +0400

    ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe
    
    [ Upstream commit 7472eb8d7dd12b6b9b1a4f4527719cc9c7f5965f ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: f0ab0bf250da ("ASoC: add mt6797-mt6351 driver and config option")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220603083417.9011-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: qcom: Fix missing of_node_put() in asoc_qcom_lpass_cpu_platform_probe() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Sat Jul 2 10:01:09 2022 +0800

    ASoC: qcom: Fix missing of_node_put() in asoc_qcom_lpass_cpu_platform_probe()
    
    [ Upstream commit f507c0c67dac57d2bcd5dcae4b6139b0305d8957 ]
    
    We should call of_node_put() for the reference 'dsp_of_node' returned by
    of_parse_phandle() which will increase the refcount.
    
    Fixes: 9bae4880acee ("ASoC: qcom: move ipq806x specific bits out of lpass driver.")
    Co-authored-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220702020109.263980-1-windhl@126.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: qcom: q6dsp: Fix an off-by-one in q6adm_alloc_copp() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Jul 21 11:02:22 2022 +0200

    ASoC: qcom: q6dsp: Fix an off-by-one in q6adm_alloc_copp()
    
    [ Upstream commit 673f58f62ca6fc98979d1cf3fe89c3ff33f29b2e ]
    
    find_first_zero_bit() returns MAX_COPPS_PER_PORT at max here.
    So 'idx' should be tested with ">=" or the test can't match.
    
    Fixes: 7b20b2be51e1 ("ASoC: qdsp6: q6adm: Add q6adm driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/0fca3271649736053eb9649d87e1ca01b056be40.1658394124.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: samsung: change gpiod_speaker_power and rx1950_audio from global to static variables [+ + +]
Author: Tom Rix <trix@redhat.com>
Date:   Wed Jun 29 14:53:45 2022 -0400

    ASoC: samsung: change gpiod_speaker_power and rx1950_audio from global to static variables
    
    [ Upstream commit d2294461b90e0c5b3bbfaaf2c8baff4fd3e2bb13 ]
    
    sparse reports
    sound/soc/samsung/rx1950_uda1380.c:131:18: warning: symbol 'gpiod_speaker_power' was not declared. Should it be static?
    sound/soc/samsung/rx1950_uda1380.c:231:24: warning: symbol 'rx1950_audio' was not declared. Should it be static?
    
    Both gpiod_speaker_power and rx1950_audio are only used in rx1950_uda1380.c,
    so their storage class specifiers should be static.
    
    Fixes: 83d74e354200 ("ASoC: samsung: rx1950: turn into platform driver")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220629185345.910406-1-trix@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: samsung: Fix error handling in aries_audio_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 17:06:39 2022 +0400

    ASoC: samsung: Fix error handling in aries_audio_probe
    
    [ Upstream commit 3e2649c5e8643bea0867bb1dd970fedadb0eb7f3 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    This function is missing of_node_put(cpu) in the error path.
    Fix this by goto out label. of_node_put() will check NULL pointer.
    
    Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220603130640.37624-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: samsung: h1940_uda1380: include proepr GPIO consumer header [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jun 27 16:19:00 2022 +0200

    ASoC: samsung: h1940_uda1380: include proepr GPIO consumer header
    
    [ Upstream commit bd10b0dafdcf0ec1677cad70101e1f97b9e28f2e ]
    
    h1940_uda1380 uses gpiod*/GPIOD* so it should include GPIO consumer
    header.
    
    Fixes: 9666e27f90b9 ("ASoC: samsung: h1940: turn into platform driver")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220627141900.470469-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ath10k: do not enforce interrupt trigger type [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed May 18 10:27:26 2022 +0300

    ath10k: do not enforce interrupt trigger type
    
    [ Upstream commit 1ee6c5abebd3cacf2ac4378d0ed4f57fd4850421 ]
    
    Interrupt line can be configured on different hardware in different way,
    even inverted.  Therefore driver should not enforce specific trigger
    type - edge rising - but instead rely on Devicetree to configure it.
    
    All Qualcomm DTSI with WCN3990 define the interrupt type as level high,
    so the mismatch between DTSI and driver causes rebind issues:
    
      $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/unbind
      $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/bind
      [   44.763114] irq: type mismatch, failed to map hwirq-446 for interrupt-controller@17a00000!
      [   44.763130] ath10k_snoc 18800000.wifi: error -ENXIO: IRQ index 0 not found
      [   44.763140] ath10k_snoc 18800000.wifi: failed to initialize resource: -6
    
    Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.0.c8-00009-QCAHLSWSC8180XMTPLZ-1
    Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
    
    Fixes: c963a683e701 ("ath10k: add resource init and deinit for WCN3990")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220513151516.357549-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ath11k: Fix incorrect debug_mask mappings [+ + +]
Author: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Date:   Thu Jun 2 17:26:21 2022 +0530

    ath11k: Fix incorrect debug_mask mappings
    
    [ Upstream commit 9331f7d3c54a263bede5055e106e40b28d0bd937 ]
    
    Currently a couple of debug_mask entries are mapped to the same value,
    this could enable unintended driver logging. If enabling DP_TX logs was
    the intention, then this could also enable PCI logs flooding the dmesg
    buffer or vice versa. Fix this by correctly assigning the debug masks.
    
    Found during code review.
    
    Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
    
    Fixes: aa2092a9bab3f ("ath11k: add raw mode and software crypto support")
    Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220602115621.15339-1-quic_mpubbise@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ath11k: fix netdev open race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Sun May 22 15:33:16 2022 +0300

    ath11k: fix netdev open race
    
    [ Upstream commit d4ba1ff87b17e81686ada8f429300876f55f95ad ]
    
    Make sure to allocate resources needed before registering the device.
    
    This specifically avoids having a racing open() trigger a BUG_ON() in
    mod_timer() when ath11k_mac_op_start() is called before the
    mon_reap_timer as been set up.
    
    I did not see this issue with next-20220310, but I hit it on every probe
    with next-20220511. Perhaps some timing changed in between.
    
    Here's the backtrace:
    
    [   51.346947] kernel BUG at kernel/time/timer.c:990!
    [   51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    ...
    [   51.578225] Call trace:
    [   51.583293]  __mod_timer+0x298/0x390
    [   51.589518]  mod_timer+0x14/0x20
    [   51.595368]  ath11k_mac_op_start+0x41c/0x4a0 [ath11k]
    [   51.603165]  drv_start+0x38/0x60 [mac80211]
    [   51.610110]  ieee80211_do_open+0x29c/0x7d0 [mac80211]
    [   51.617945]  ieee80211_open+0x60/0xb0 [mac80211]
    [   51.625311]  __dev_open+0x100/0x1c0
    [   51.631420]  __dev_change_flags+0x194/0x210
    [   51.638214]  dev_change_flags+0x24/0x70
    [   51.644646]  do_setlink+0x228/0xdb0
    [   51.650723]  __rtnl_newlink+0x460/0x830
    [   51.657162]  rtnl_newlink+0x4c/0x80
    [   51.663229]  rtnetlink_rcv_msg+0x124/0x390
    [   51.669917]  netlink_rcv_skb+0x58/0x130
    [   51.676314]  rtnetlink_rcv+0x18/0x30
    [   51.682460]  netlink_unicast+0x250/0x310
    [   51.688960]  netlink_sendmsg+0x19c/0x3e0
    [   51.695458]  ____sys_sendmsg+0x220/0x290
    [   51.701938]  ___sys_sendmsg+0x7c/0xc0
    [   51.708148]  __sys_sendmsg+0x68/0xd0
    [   51.714254]  __arm64_sys_sendmsg+0x28/0x40
    [   51.720900]  invoke_syscall+0x48/0x120
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Fixes: 840c36fa727a ("ath11k: dp: stop rx pktlog before suspend")
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220517103436.15867-1-johan+linaro@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ath9k: fix use-after-free in ath9k_hif_usb_rx_cb [+ + +]
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon Jun 13 21:43:59 2022 +0300

    ath9k: fix use-after-free in ath9k_hif_usb_rx_cb
    
    [ Upstream commit 0ac4827f78c7ffe8eef074bc010e7e34bc22f533 ]
    
    Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
    problem was in incorrect htc_handle->drv_priv initialization.
    
    Probable call trace which can trigger use-after-free:
    
    ath9k_htc_probe_device()
      /* htc_handle->drv_priv = priv; */
      ath9k_htc_wait_for_target()      <--- Failed
      ieee80211_free_hw()              <--- priv pointer is freed
    
    <IRQ>
    ...
    ath9k_hif_usb_rx_cb()
      ath9k_hif_usb_rx_stream()
       RX_STAT_INC()                <--- htc_handle->drv_priv access
    
    In order to not add fancy protection for drv_priv we can move
    htc_handle->drv_priv initialization at the end of the
    ath9k_htc_probe_device() and add helper macro to make
    all *_STAT_* macros NULL safe, since syzbot has reported related NULL
    deref in that macros [1]
    
    Link: https://syzkaller.appspot.com/bug?id=6ead44e37afb6866ac0c7dd121b4ce07cb665f60 [0]
    Link: https://syzkaller.appspot.com/bug?id=b8101ffcec107c0567a0cd8acbbacec91e9ee8de [1]
    Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
    Reported-and-tested-by: syzbot+03110230a11411024147@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+c6dde1f690b60e0b9fbe@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/d57bbedc857950659bfacac0ab48790c1eda00c8.1655145743.git.paskripkin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: fix redefinition of seq_file attributes [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Jul 1 18:20:41 2022 +0000

    binder: fix redefinition of seq_file attributes
    
    [ Upstream commit b7e241bbff24f9e106bf616408fd58bcedc44bae ]
    
    The patchset in [1] exported some definitions to binder_internal.h in
    order to make the debugfs entries such as 'stats' and 'transaction_log'
    available in a binderfs instance. However, the DEFINE_SHOW_ATTRIBUTE
    macro expands into a static function/variable pair, which in turn get
    redefined each time a source file includes this internal header.
    
    This problem was made evident after a report from the kernel test robot
    <lkp@intel.com> where several W=1 build warnings are seen in downstream
    kernels. See the following example:
    
      include/../drivers/android/binder_internal.h:111:23: warning: 'binder_stats_fops' defined but not used [-Wunused-const-variable=]
         111 | DEFINE_SHOW_ATTRIBUTE(binder_stats);
             |                       ^~~~~~~~~~~~
      include/linux/seq_file.h:174:37: note: in definition of macro 'DEFINE_SHOW_ATTRIBUTE'
         174 | static const struct file_operations __name ## _fops = {                 \
             |                                     ^~~~~~
    
    This patch fixes the above issues by moving back the definitions into
    binder.c and instead creates an array of the debugfs entries which is
    more convenient to share with binderfs and iterate through.
    
      [1] https://lore.kernel.org/all/20190903161655.107408-1-hridya@google.com/
    
    Fixes: 0e13e452dafc ("binder: Add stats, state and transactions files")
    Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20220701182041.2134313-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-mq: don't create hctx debugfs dir until q->debugfs_dir is created [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Jul 11 17:08:08 2022 +0800

    blk-mq: don't create hctx debugfs dir until q->debugfs_dir is created
    
    [ Upstream commit f3ec5d11554778c24ac8915e847223ed71d104fc ]
    
    blk_mq_debugfs_register_hctx() can be called by blk_mq_update_nr_hw_queues
    when gendisk isn't added yet, such as nvme tcp.
    
    Fixes the warning of 'debugfs: Directory 'hctx0' with parent '/' already present!'
    which can be observed reliably when running blktests nvme/005.
    
    Fixes: 6cfc0081b046 ("blk-mq: no need to check return value of debugfs_create functions")
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220711090808.259682-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blktrace: Trace remapped requests correctly [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Jul 14 11:06:36 2022 -0700

    blktrace: Trace remapped requests correctly
    
    [ Upstream commit 22c80aac882f712897b88b7ea8f5a74ea19019df ]
    
    Trace the remapped operation and its flags instead of only the data
    direction of remapped operations. This issue was detected by analyzing
    the warnings reported by sparse related to the new blk_opf_t type.
    
    Reviewed-by: Jun'ichi Nomura <junichi.nomura@nec.com>
    Cc: Mike Snitzer <snitzer@kernel.org>
    Cc: Mike Christie <michael.christie@oracle.com>
    Cc: Li Zefan <lizf@cn.fujitsu.com>
    Cc: Chaitanya Kulkarni <kch@nvidia.com>
    Fixes: 1b9a9ab78b0a ("blktrace: use op accessors")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20220714180729.1065367-11-bvanassche@acm.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/bio: remove duplicate append pages code [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Fri Jun 10 12:58:21 2022 -0700

    block/bio: remove duplicate append pages code
    
    [ Upstream commit c58c0074c54c2e2bb3bb0d5a4d8896bb660cc8bc ]
    
    The getting pages setup for zone append and normal IO are identical. Use
    common code for each.
    
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220610195830.3574005-3-kbusch@fb.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/rnbd-srv: Set keep_id to true after mutex_trylock [+ + +]
Author: Md Haris Iqbal <haris.iqbal@ionos.com>
Date:   Thu Jul 7 16:31:21 2022 +0200

    block/rnbd-srv: Set keep_id to true after mutex_trylock
    
    [ Upstream commit 4bc14f3101364877dd59085f39e068a2a7ec9f2d ]
    
    After setting keep_id if the mutex trylock fails, the keep_id stays set
    for the rest of the sess_dev lifetime.
    
    Therefore, set keep_id to true after mutex_trylock succeeds, so that a
    failure of trylock does'nt touch keep_id.
    
    Fixes: b168e1d85cf3 ("block/rnbd-srv: Prevent a deadlock generated by accessing sysfs in parallel")
    Cc: gi-oh.kim@ionos.com
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Link: https://lore.kernel.org/r/20220707143122.460362-2-haris.iqbal@ionos.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: don't allow the same type rq_qos add more than once [+ + +]
Author: Jinke Han <hanjinke.666@bytedance.com>
Date:   Wed Jul 20 17:36:16 2022 +0800

    block: don't allow the same type rq_qos add more than once
    
    [ Upstream commit 14a6e2eb7df5c7897c15b109cba29ab0c4a791b6 ]
    
    In our test of iocost, we encountered some list add/del corruptions of
    inner_walk list in ioc_timer_fn.
    
    The reason can be described as follows:
    
    cpu 0                                   cpu 1
    ioc_qos_write                           ioc_qos_write
    
    ioc = q_to_ioc(queue);
    if (!ioc) {
            ioc = kzalloc();
                                            ioc = q_to_ioc(queue);
                                            if (!ioc) {
                                                    ioc = kzalloc();
                                                    ...
                                                    rq_qos_add(q, rqos);
                                            }
            ...
            rq_qos_add(q, rqos);
            ...
    }
    
    When the io.cost.qos file is written by two cpus concurrently, rq_qos may
    be added to one disk twice. In that case, there will be two iocs enabled
    and running on one disk. They own different iocgs on their active list. In
    the ioc_timer_fn function, because of the iocgs from two iocs have the
    same root iocg, the root iocg's walk_list may be overwritten by each other
    and this leads to list add/del corruptions in building or destroying the
    inner_walk list.
    
    And so far, the blk-rq-qos framework works in case that one instance for
    one type rq_qos per queue by default. This patch make this explicit and
    also fix the crash above.
    
    Signed-off-by: Jinke Han <hanjinke.666@bytedance.com>
    Reviewed-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220720093616.70584-1-hanjinke.666@bytedance.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: ensure iov_iter advances for added pages [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue Jul 12 08:32:54 2022 -0700

    block: ensure iov_iter advances for added pages
    
    [ Upstream commit 325347d965e7ccf5424a05398807a6d801846612 ]
    
    There are cases where a bio may not accept additional pages, and the iov
    needs to advance to the last data length that was accepted. The zone
    append used to handle this correctly, but was inadvertently broken when
    the setup was made common with the normal r/w case.
    
    Fixes: 576ed9135489c ("block: use bio_add_page in bio_iov_iter_get_pages")
    Fixes: c58c0074c54c2 ("block/bio: remove duplicate append pages code")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Link: https://lore.kernel.org/r/20220712153256.2202024-1-kbusch@fb.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: fix infinite loop for invalid zone append [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Fri Jun 10 12:58:20 2022 -0700

    block: fix infinite loop for invalid zone append
    
    [ Upstream commit b82d9fa257cb3725c49d94d2aeafc4677c34448a ]
    
    Returning 0 early from __bio_iov_append_get_pages() for the
    max_append_sectors warning just creates an infinite loop since 0 means
    success, and the bio will never fill from the unadvancing iov_iter. We
    could turn the return into an error value, but it will already be turned
    into an error value later on, so just remove the warning. Clearly no one
    ever hit it anyway.
    
    Fixes: 0512a75b98f84 ("block: Introduce REQ_OP_ZONE_APPEND")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20220610195830.3574005-2-kbusch@fb.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: remove the struct blk_queue_ctx forward declaration [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Sep 20 14:33:22 2021 +0200

    block: remove the struct blk_queue_ctx forward declaration
    
    [ Upstream commit 9778ac77c2027827ffdbb33d3e936b3a0ae9f0f9 ]
    
    This type doesn't exist at all, so no need to forward declare it.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20210920123328.1399408-12-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: hci_intel: Add check for platform_driver_register [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Jun 3 09:24:36 2022 +0800

    Bluetooth: hci_intel: Add check for platform_driver_register
    
    [ Upstream commit ab2d2a982ff721f4b029282d9a40602ea46a745e ]
    
    As platform_driver_register() could fail, it should be better
    to deal with the return value in order to maintain the code
    consisitency.
    
    Fixes: 1ab1f239bf17 ("Bluetooth: hci_intel: Add support for platform driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Aug 1 13:52:07 2022 -0700

    Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression
    
    commit 332f1795ca202489c665a75e62e18ff6284de077 upstream.
    
    The patch d0be8347c623: "Bluetooth: L2CAP: Fix use-after-free caused
    by l2cap_chan_put" from Jul 21, 2022, leads to the following Smatch
    static checker warning:
    
            net/bluetooth/l2cap_core.c:1977 l2cap_global_chan_by_psm()
            error: we previously assumed 'c' could be null (see line 1996)
    
    Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bpf: Fix KASAN use-after-free Read in compute_effective_progs [+ + +]
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Tue May 17 11:04:20 2022 -0700

    bpf: Fix KASAN use-after-free Read in compute_effective_progs
    
    commit 4c46091ee985ae84c60c5e95055d779fcd291d87 upstream.
    
    Syzbot found a Use After Free bug in compute_effective_progs().
    The reproducer creates a number of BPF links, and causes a fault
    injected alloc to fail, while calling bpf_link_detach on them.
    Link detach triggers the link to be freed by bpf_link_free(),
    which calls __cgroup_bpf_detach() and update_effective_progs().
    If the memory allocation in this function fails, the function restores
    the pointer to the bpf_cgroup_link on the cgroup list, but the memory
    gets freed just after it returns. After this, every subsequent call to
    update_effective_progs() causes this already deallocated pointer to be
    dereferenced in prog_list_length(), and triggers KASAN UAF error.
    
    To fix this issue don't preserve the pointer to the prog or link in the
    list, but remove it and replace it with a dummy prog without shrinking
    the table. The subsequent call to __cgroup_bpf_detach() or
    __cgroup_bpf_detach() will correct it.
    
    Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
    Reported-by: <syzbot+f264bffdfbd5614f3bb2@syzkaller.appspotmail.com>
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369db4
    Link: https://lore.kernel.org/bpf/20220517180420.87954-1-tadeusz.struk@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Fix subprog names in stack traces. [+ + +]
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Thu Jul 14 14:16:37 2022 -0700

    bpf: Fix subprog names in stack traces.
    
    [ Upstream commit 9c7c48d6a1e2eb5192ad5294c1c4dbd42a88e88b ]
    
    The commit 7337224fc150 ("bpf: Improve the info.func_info and info.func_info_rec_size behavior")
    accidently made bpf_prog_ksym_set_name() conservative for bpf subprograms.
    Fixed it so instead of "bpf_prog_tag_F" the stack traces print "bpf_prog_tag_full_subprog_name".
    
    Fixes: 7337224fc150 ("bpf: Improve the info.func_info and info.func_info_rec_size behavior")
    Reported-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20220714211637.17150-1-alexei.starovoitov@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: ensure pages are unlocked on cow_file_range() failure [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Jun 21 15:40:59 2022 +0900

    btrfs: ensure pages are unlocked on cow_file_range() failure
    
    [ Upstream commit 9ce7466f372d83054c7494f6b3e4b9abaf3f0355 ]
    
    There is a hung_task report on zoned btrfs like below.
    
    https://github.com/naota/linux/issues/59
    
      [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds.
      [726.329839]       Not tainted 5.16.0-rc1+ #1
      [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [726.331603] task:rocksdb:high0   state:D stack:    0 pid:11085 ppid: 11082 flags:0x00000000
      [726.331608] Call Trace:
      [726.331611]  <TASK>
      [726.331614]  __schedule+0x2e5/0x9d0
      [726.331622]  schedule+0x58/0xd0
      [726.331626]  io_schedule+0x3f/0x70
      [726.331629]  __folio_lock+0x125/0x200
      [726.331634]  ? find_get_entries+0x1bc/0x240
      [726.331638]  ? filemap_invalidate_unlock_two+0x40/0x40
      [726.331642]  truncate_inode_pages_range+0x5b2/0x770
      [726.331649]  truncate_inode_pages_final+0x44/0x50
      [726.331653]  btrfs_evict_inode+0x67/0x480
      [726.331658]  evict+0xd0/0x180
      [726.331661]  iput+0x13f/0x200
      [726.331664]  do_unlinkat+0x1c0/0x2b0
      [726.331668]  __x64_sys_unlink+0x23/0x30
      [726.331670]  do_syscall_64+0x3b/0xc0
      [726.331674]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [726.331677] RIP: 0033:0x7fb9490a171b
      [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
      [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b
      [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300
      [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000
      [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000
      [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260
      [726.331693]  </TASK>
    
    While we debug the issue, we found running fstests generic/551 on 5GB
    non-zoned null_blk device in the emulated zoned mode also had a
    similar hung issue.
    
    Also, we can reproduce the same symptom with an error injected
    cow_file_range() setup.
    
    The hang occurs when cow_file_range() fails in the middle of
    allocation. cow_file_range() called from do_allocation_zoned() can
    split the give region ([start, end]) for allocation depending on
    current block group usages. When btrfs can allocate bytes for one part
    of the split regions but fails for the other region (e.g. because of
    -ENOSPC), we return the error leaving the pages in the succeeded regions
    locked. Technically, this occurs only when @unlock == 0. Otherwise, we
    unlock the pages in an allocated region after creating an ordered
    extent.
    
    Considering the callers of cow_file_range(unlock=0) won't write out
    the pages, we can unlock the pages on error exit from
    cow_file_range(). So, we can ensure all the pages except @locked_page
    are unlocked on error case.
    
    In summary, cow_file_range now behaves like this:
    
    - page_started == 1 (return value)
      - All the pages are unlocked. IO is started.
    - unlock == 1
      - All the pages except @locked_page are unlocked in any case
    - unlock == 0
      - On success, all the pages are locked for writing out them
      - On failure, all the pages except @locked_page are unlocked
    
    Fixes: 42c011000963 ("btrfs: zoned: introduce dedicated data write path for zoned filesystems")
    CC: stable@vger.kernel.org # 5.12+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: properly flag filesystem with BTRFS_FEATURE_INCOMPAT_BIG_METADATA [+ + +]
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Thu Jun 23 10:55:47 2022 +0300

    btrfs: properly flag filesystem with BTRFS_FEATURE_INCOMPAT_BIG_METADATA
    
    [ Upstream commit e26b04c4c91925dba57324db177a24e18e2d0013 ]
    
    Commit 6f93e834fa7c seemingly inadvertently moved the code responsible
    for flagging the filesystem as having BIG_METADATA to a place where
    setting the flag was essentially lost. This means that
    filesystems created with kernels containing this bug (starting with 5.15)
    can potentially be mounted by older (pre-3.4) kernels. In reality
    chances for this happening are low because there are other incompat
    flags introduced in the mean time. Still the correct behavior is to set
    INCOMPAT_BIG_METADATA flag and persist this in the superblock.
    
    Fixes: 6f93e834fa7c ("btrfs: fix upper limit for max_inline for page size 64K")
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: reject log replay if there is unsupported RO compat flag [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jun 7 19:48:24 2022 +0800

    btrfs: reject log replay if there is unsupported RO compat flag
    
    commit dc4d31684974d140250f3ee612c3f0cab13b3146 upstream.
    
    [BUG]
    If we have a btrfs image with dirty log, along with an unsupported RO
    compatible flag:
    
    log_root                30474240
    ...
    compat_flags            0x0
    compat_ro_flags         0x40000003
                            ( FREE_SPACE_TREE |
                              FREE_SPACE_TREE_VALID |
                              unknown flag: 0x40000000 )
    
    Then even if we can only mount it RO, we will still cause metadata
    update for log replay:
    
      BTRFS info (device dm-1): flagging fs with big metadata feature
      BTRFS info (device dm-1): using free space tree
      BTRFS info (device dm-1): has skinny extents
      BTRFS info (device dm-1): start tree-log replay
    
    This is definitely against RO compact flag requirement.
    
    [CAUSE]
    RO compact flag only forces us to do RO mount, but we will still do log
    replay for plain RO mount.
    
    Thus this will result us to do log replay and update metadata.
    
    This can be very problematic for new RO compat flag, for example older
    kernel can not understand v2 cache, and if we allow metadata update on
    RO mount and invalidate/corrupt v2 cache.
    
    [FIX]
    Just reject the mount unless rescue=nologreplay is provided:
    
      BTRFS error (device dm-1): cannot replay dirty log with unsupport optional features (0x40000000), try rescue=nologreplay instead
    
    We don't want to set rescue=nologreply directly, as this would make the
    end user to read the old data, and cause confusion.
    
    Since the such case is really rare, we're mostly fine to just reject the
    mount with an error message, which also includes the proper workaround.
    
    CC: stable@vger.kernel.org #4.9+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: reset block group chunk force if we have to wait [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Jun 13 18:31:17 2022 -0400

    btrfs: reset block group chunk force if we have to wait
    
    [ Upstream commit 1314ca78b2c35d3e7d0f097268a2ee6dc0d369ef ]
    
    If you try to force a chunk allocation, but you race with another chunk
    allocation, you will end up waiting on the chunk allocation that just
    occurred and then allocate another chunk.  If you have many threads all
    doing this at once you can way over-allocate chunks.
    
    Fix this by resetting force to NO_FORCE, that way if we think we need to
    allocate we can, otherwise we don't force another chunk allocation if
    one is already happening.
    
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bus: hisi_lpc: fix missing platform_device_put() in hisi_lpc_acpi_probe() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Jul 1 17:43:52 2022 +0800

    bus: hisi_lpc: fix missing platform_device_put() in hisi_lpc_acpi_probe()
    
    [ Upstream commit 54872fea6a5ac967ec2272aea525d1438ac6735a ]
    
    In error case in hisi_lpc_acpi_probe() after calling platform_device_add(),
    hisi_lpc_acpi_remove() can't release the failed 'pdev', so it will be leak,
    call platform_device_put() to fix this problem.
    I'v constructed this error case and tested this patch on D05 board.
    
    Fixes: 99c0228d6ff1 ("HISI LPC: Re-Add ACPI child enumeration support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: error: specify the values of data[5..7] of CAN error frames [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:48 2022 +0900

    can: error: specify the values of data[5..7] of CAN error frames
    
    [ Upstream commit e70a3263a7eed768d5f947b8f2aff8d2a79c9d97 ]
    
    Currently, data[5..7] of struct can_frame, when used as a CAN error
    frame, are defined as being "controller specific". Device specific
    behaviours are problematic because it prevents someone from writing
    code which is portable between devices.
    
    As a matter of fact, data[5] is never used, data[6] is always used to
    report TX error counter and data[7] is always used to report RX error
    counter. can-utils also relies on this.
    
    This patch updates the comment in the uapi header to specify that
    data[5] is reserved (and thus should not be used) and that data[6..7]
    are used for error counters.
    
    Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module")
    Link: https://lore.kernel.org/all/20220719143550.3681-11-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: hi311x: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:43 2022 +0900

    can: hi311x: do not report txerr and rxerr during bus-off
    
    [ Upstream commit a22bd630cfff496b270211745536e50e98eb3a45 ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
    Link: https://lore.kernel.org/all/20220719143550.3681-6-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_hydra: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:45 2022 +0900

    can: kvaser_usb_hydra: do not report txerr and rxerr during bus-off
    
    [ Upstream commit 936e90595376e64b6247c72d3ea8b8b164b7ac96 ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family")
    Link: https://lore.kernel.org/all/20220719143550.3681-8-mailhol.vincent@wanadoo.fr
    CC: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_leaf: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:46 2022 +0900

    can: kvaser_usb_leaf: do not report txerr and rxerr during bus-off
    
    [ Upstream commit a57732084e06791d37ea1ea447cca46220737abd ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 7259124eac7d1 ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c")
    Link: https://lore.kernel.org/all/20220719143550.3681-9-mailhol.vincent@wanadoo.fr
    CC: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sat Jun 11 16:20:58 2022 +0200

    can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback
    
    [ Upstream commit 7e193a42c37cf40eba8ac5af2d5e8eeb8b9506f9 ]
    
    Usually CAN devices support configurable bit rates. The limits are
    defined by struct can_priv::bittiming_const. Another way is to
    implement the struct can_priv::do_set_bittiming callback.
    
    If the bit rate is configured via netlink, the can_changelink()
    function checks that either can_priv::bittiming_const or struct
    can_priv::do_set_bittiming is implemented.
    
    In commit 431af779256c ("can: dev: add CAN interface API for fixed
    bitrates") an API for configuring bit rates on CAN interfaces that
    only support fixed bit rates was added. The supported bit rates are
    defined by struct can_priv::bitrate_const.
    
    However the above mentioned commit forgot to add the struct
    can_priv::bitrate_const to the check in can_changelink().
    
    In order to avoid to implement a no-op can_priv::do_set_bittiming
    callback on devices with fixed bit rates, extend the check in
    can_changelink() accordingly.
    
    Link: https://lore.kernel.org/all/20220611144248.3924903-1-mkl@pengutronix.de
    Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates")
    Reported-by: Max Staudt <max@enpas.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callback [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sat Jun 11 16:20:58 2022 +0200

    can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callback
    
    [ Upstream commit ec30c109391c5eac9b1d689a61e4bfed88148947 ]
    
    This patch is similar to 7e193a42c37c ("can: netlink: allow
    configuring of fixed bit rates without need for do_set_bittiming
    callback") but for data bit rates instead of bit rates.
    
    Usually CAN devices support configurable data bit rates. The limits
    are defined by struct can_priv::data_bittiming_const. Another way is
    to implement the struct can_priv::do_set_data_bittiming callback.
    
    If the bit rate is configured via netlink, the can_changelink()
    function checks that either can_priv::data_bittiming_const or struct
    can_priv::do_set_data_bittiming is implemented.
    
    In commit 431af779256c ("can: dev: add CAN interface API for fixed
    bitrates") an API for configuring bit rates on CAN interfaces that
    only support fixed bit rates was added. The supported bit rates are
    defined by struct can_priv::bitrate_const.
    
    However the above mentioned commit forgot to add the struct
    can_priv::data_bitrate_const to the check in can_changelink().
    
    In order to avoid to implement a no-op can_priv::do_set_data_bittiming
    callback on devices with fixed data bit rates, extend the check in
    can_changelink() accordingly.
    
    Link: https://lore.kernel.org/all/20220613143633.4151884-1-mkl@pengutronix.de
    Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates")
    Acked-by: Max Staudt <max@enpas.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: pch_can: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:39 2022 +0900

    can: pch_can: do not report txerr and rxerr during bus-off
    
    [ Upstream commit 3a5c7e4611ddcf0ef37a3a17296b964d986161a6 ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 0c78ab76a05c ("pch_can: Add setting TEC/REC statistics processing")
    Link: https://lore.kernel.org/all/20220719143550.3681-2-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: pch_can: pch_can_error(): initialize errc before using it [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Fri Jul 22 01:00:32 2022 +0900

    can: pch_can: pch_can_error(): initialize errc before using it
    
    [ Upstream commit 9950f11211331180269867aef848c7cf56861742 ]
    
    After commit 3a5c7e4611dd, the variable errc is accessed before being
    initialized, c.f. below W=2 warning:
    
    | In function 'pch_can_error',
    |     inlined from 'pch_can_poll' at drivers/net/can/pch_can.c:739:4:
    | drivers/net/can/pch_can.c:501:29: warning: 'errc' may be used uninitialized [-Wmaybe-uninitialized]
    |   501 |                 cf->data[6] = errc & PCH_TEC;
    |       |                             ^
    | drivers/net/can/pch_can.c: In function 'pch_can_poll':
    | drivers/net/can/pch_can.c:484:13: note: 'errc' was declared here
    |   484 |         u32 errc, lec;
    |       |             ^~~~
    
    Moving errc initialization up solves this issue.
    
    Fixes: 3a5c7e4611dd ("can: pch_can: do not report txerr and rxerr during bus-off")
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/all/20220721160032.9348-1-mailhol.vincent@wanadoo.fr
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: rcar_can: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:40 2022 +0900

    can: rcar_can: do not report txerr and rxerr during bus-off
    
    [ Upstream commit a37b7245e831a641df360ca41db6a71c023d3746 ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver")
    Link: https://lore.kernel.org/all/20220719143550.3681-3-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: sja1000: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:41 2022 +0900

    can: sja1000: do not report txerr and rxerr during bus-off
    
    [ Upstream commit 164d7cb2d5a30f1b3a5ab4fab1a27731fb1494a8 ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 215db1856e83 ("can: sja1000: Consolidate and unify state change handling")
    Link: https://lore.kernel.org/all/20220719143550.3681-4-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: sun4i_can: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:44 2022 +0900

    can: sun4i_can: do not report txerr and rxerr during bus-off
    
    [ Upstream commit 0ac15a8f661b941519379831d09bfb12271b23ee ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
    Link: https://lore.kernel.org/all/20220719143550.3681-7-mailhol.vincent@wanadoo.fr
    CC: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: usb_8dev: do not report txerr and rxerr during bus-off [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Jul 19 23:35:47 2022 +0900

    can: usb_8dev: do not report txerr and rxerr during bus-off
    
    [ Upstream commit aebe8a2433cd090ccdc222861f44bddb75eb01de ]
    
    During bus off, the error count is greater than 255 and can not fit in
    a u8.
    
    Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
    Link: https://lore.kernel.org/all/20220719143550.3681-10-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: mediatek: reset: Fix written reset bit offset [+ + +]
Author: Rex-BC Chen <rex-bc.chen@mediatek.com>
Date:   Mon May 23 17:33:29 2022 +0800

    clk: mediatek: reset: Fix written reset bit offset
    
    [ Upstream commit edabcf71d100fd433a0fc2d0c97057c446c33b2a ]
    
    Original assert/deassert bit is BIT(0), but it's more resonable to modify
    them to BIT(id % 32) which is based on id.
    
    This patch will not influence any previous driver because the reset is
    only used for thermal. The id (MT8183_INFRACFG_AO_THERM_SW_RST) is 0.
    
    Fixes: 64ebb57a3df6 ("clk: reset: Modify reset-controller driver")
    Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    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/20220523093346.28493-3-rex-bc.chen@mediatek.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: camcc-sdm845: Fix topology around titan_top power domain [+ + +]
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Fri May 20 00:41:32 2022 +0300

    clk: qcom: camcc-sdm845: Fix topology around titan_top power domain
    
    [ Upstream commit 103dd2338bbff567bce7acd00fc5a09c806b38ec ]
    
    On SDM845 two found VFE GDSC power domains shall not be operated, if
    titan top is turned off, thus the former power domains will be set as
    subdomains by a GDSC registration routine.
    
    Fixes: 78412c262004 ("clk: qcom: Add camera clock controller driver for SDM845")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220519214133.1728979-2-vladimir.zapolskiy@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: camcc-sm8250: Fix halt on boot by reducing driver's init level [+ + +]
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Wed May 18 13:35:54 2022 +0300

    clk: qcom: camcc-sm8250: Fix halt on boot by reducing driver's init level
    
    [ Upstream commit c4f40351901a10cd662ac2c081396d8fb04f584d ]
    
    Access to I/O of SM8250 camera clock controller IP depends on enabled
    GCC_CAMERA_AHB_CLK clock supplied by global clock controller, the latter
    one is inited on subsys level, so, to satisfy the dependency, it would
    make sense to deprive the init level of camcc-sm8250 driver.
    
    If both drivers are compiled as built-in, there is a change that a board
    won't boot up due to a race, which happens on the same init level.
    
    Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220518103554.949511-1-vladimir.zapolskiy@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: camcc-sm8250: Fix topology around titan_top power domain [+ + +]
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Fri May 20 00:41:33 2022 +0300

    clk: qcom: camcc-sm8250: Fix topology around titan_top power domain
    
    [ Upstream commit f8acf01a6a4f84baf05181e24bd48def4ba23f5b ]
    
    On SM8250 two found VFE GDSC power domains shall not be operated, if
    titan top is turned off, thus the former power domains will be set as
    subdomains by a GDSC registration routine.
    
    Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220519214133.1728979-3-vladimir.zapolskiy@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-krait: unlock spin after mux completion [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Sat Apr 30 07:44:57 2022 +0200

    clk: qcom: clk-krait: unlock spin after mux completion
    
    [ Upstream commit df83d2c9e72910416f650ade1e07cc314ff02731 ]
    
    Unlock spinlock after the mux switch is completed to prevent any corner
    case of mux request while the switch still needs to be done.
    
    Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks")
    Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220430054458.31321-3-ansuelsmth@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled. [+ + +]
Author: Nikita Travkin <nikita@trvn.ru>
Date:   Sun Jun 12 19:59:52 2022 +0500

    clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled.
    
    [ Upstream commit bdafb609c3bb848d710ad9cd4debd2ee9d6a4049 ]
    
    In cases when MND is not enabled (e.g. when only Half Integer Divider is
    used), setting D registers makes no effect.
    
    Fail instead of making ineffective write.
    
    Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG")
    Signed-off-by: Nikita Travkin <nikita@trvn.ru>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220612145955.385787-2-nikita@trvn.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-rcg2: Make sure to not write d=0 to the NMD register [+ + +]
Author: Nikita Travkin <nikita@trvn.ru>
Date:   Sun Jun 12 19:59:53 2022 +0500

    clk: qcom: clk-rcg2: Make sure to not write d=0 to the NMD register
    
    [ Upstream commit d0696770cef35a1fd16ea2167e2198c18aa6fbfe ]
    
    Sometimes calculation of d value may result in 0 because of the
    rounding after integer division. This causes the following error:
    
    [  113.969689] camss_gp1_clk_src: rcg didn't update its configuration.
    [  113.969754] WARNING: CPU: 3 PID: 35 at drivers/clk/qcom/clk-rcg2.c:122 update_config+0xc8/0xdc
    
    Make sure that D value is never zero.
    
    Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG")
    Signed-off-by: Nikita Travkin <nikita@trvn.ru>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220612145955.385787-3-nikita@trvn.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8939: Add missing system_mm_noc_bfdcd_clk_src [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed May 4 17:38:34 2022 +0100

    clk: qcom: gcc-msm8939: Add missing system_mm_noc_bfdcd_clk_src
    
    [ Upstream commit dd363e2f7196278e7a30f509a0e8a841cb763b14 ]
    
    The msm8939 has an additional higher operating point for the multi-media
    peripherals. The higher throughput MM componets operate off of the
    system-mm noc not the system noc.
    
    system_mm_noc_bfdcd_clk_src is the source clock for the higher frequency
    capable system noc mm.
    
    Maximum frequency for the MM SNOC is 400 MHz.
    
    Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220504163835.40130-4-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8939: Add missing SYSTEM_MM_NOC_BFDCD_CLK_SRC [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed May 4 17:38:32 2022 +0100

    clk: qcom: gcc-msm8939: Add missing SYSTEM_MM_NOC_BFDCD_CLK_SRC
    
    [ Upstream commit 07e7fcf1714c5f9930ad27613fea940aedba68da ]
    
    When adding in the indexes for this clock-controller we missed
    SYSTEM_MM_NOC_BFDCD_CLK_SRC.
    
    Add it in now.
    
    Fixes: 4c71d6abc4fc ("clk: qcom: Add DT bindings for MSM8939 GCC")
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
    Cc: devicetree@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220504163835.40130-2-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8939: Fix bimc_ddr_clk_src rcgr base address [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed May 4 17:38:33 2022 +0100

    clk: qcom: gcc-msm8939: Fix bimc_ddr_clk_src rcgr base address
    
    [ Upstream commit 63d42708320d6d2ca9ed505123d50ff4a542c36f ]
    
    Reviewing qcom docs for the 8939 we can see the command rcgr is pointing to
    the wrong address. bimc_ddr_clk_src_rcgr is @ 0x01832024 not 0x01832004.
    
    Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220504163835.40130-3-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8939: Fix weird field spacing in ftbl_gcc_camss_cci_clk [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Tue Jul 12 13:59:17 2022 +0100

    clk: qcom: gcc-msm8939: Fix weird field spacing in ftbl_gcc_camss_cci_clk
    
    [ Upstream commit 2bc308ebc453ba22f3f120f777b9ac48f973ee80 ]
    
    Adding a new item to this frequency table I see the existing indentation is
    incorrect.
    
    Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220712125922.3461675-2-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8939: Point MM peripherals to system_mm_noc clock [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed May 4 17:38:35 2022 +0100

    clk: qcom: gcc-msm8939: Point MM peripherals to system_mm_noc clock
    
    [ Upstream commit 05eed0990927aa9634682fec58660e30f7b7ae30 ]
    
    Qcom docs indciate the following peripherals operating from System NOC
    MM not from System NOC clocks.
    
    - MDP
    - VFE
    - JPEGe
    - Venus
    
    Switch over the relevant parent pointers.
    
    Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220504163835.40130-5-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq8074: fix NSS core PLL-s [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Sun May 15 23:00:38 2022 +0200

    clk: qcom: ipq8074: fix NSS core PLL-s
    
    [ Upstream commit ca41ec1b30434636c56c5600b24a8d964d359d9c ]
    
    Like in IPQ6018 the NSS related Alpha PLL-s require initial configuration
    to work.
    
    So, obtain the regmap that is required for the Alpha PLL configuration
    and thus utilize the qcom_cc_really_probe() as we already have the regmap.
    Then utilize the Alpha PLL configs from the downstream QCA 5.4 based
    kernel to configure them.
    
    This fixes the UBI32 and NSS crypto PLL-s failing to get enabled by the
    kernel.
    
    Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s")
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220515210048.483898-1-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq8074: fix NSS port frequency tables [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Sun May 15 23:00:40 2022 +0200

    clk: qcom: ipq8074: fix NSS port frequency tables
    
    [ Upstream commit 0e9e61a2815b5cd34f1b495b2d72e8127ce9b794 ]
    
    NSS port 5 and 6 frequency tables are currently broken and are causing a
    wide ranges of issue like 1G not working at all on port 6 or port 5 being
    clocked with 312 instead of 125 MHz as UNIPHY1 gets selected.
    
    So, update the frequency tables with the ones from the downstream QCA 5.4
    based kernel which has already fixed this.
    
    Fixes: 7117a51ed303 ("clk: qcom: ipq8074: add NSS ethernet port clocks")
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220515210048.483898-3-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq8074: set BRANCH_HALT_DELAY flag for UBI clocks [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Sun May 15 23:00:43 2022 +0200

    clk: qcom: ipq8074: set BRANCH_HALT_DELAY flag for UBI clocks
    
    [ Upstream commit 2bd357e698207e2e65db03007e4be65bf9d6a7b3 ]
    
    Currently, attempting to enable the UBI clocks will cause the stuck at
    off warning to be printed and clk_enable will fail.
    
    [   14.936694] gcc_ubi1_ahb_clk status stuck at 'off'
    
    Downstream 5.4 QCA kernel has fixed this by seting the BRANCH_HALT_DELAY
    flag on UBI clocks, so lets do the same.
    
    Fixes: 5736294aef83 ("clk: qcom: ipq8074: add NSS clocks")
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220515210048.483898-6-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq8074: SW workaround for UBI32 PLL lock [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Sun May 15 23:00:39 2022 +0200

    clk: qcom: ipq8074: SW workaround for UBI32 PLL lock
    
    [ Upstream commit 3401ea2856ef84f39b75f0dc5ebcaeda81cb90ec ]
    
    UBI32 Huayra PLL fails to lock in 5 us in some SoC silicon and thus it
    will cause the wait_for_pll() to timeout and thus return the error
    indicating that the PLL failed to lock.
    
    This is bug in Huayra PLL HW for which SW workaround
    is to set bit 26 of TEST_CTL register.
    
    This is ported from the QCA 5.4 based downstream kernel.
    
    Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s")
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220515210048.483898-2-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: r9a06g032: Fix UART clkgrp bitsel [+ + +]
Author: Ralph Siemsen <ralph.siemsen@linaro.org>
Date:   Wed May 18 14:25:27 2022 -0400

    clk: renesas: r9a06g032: Fix UART clkgrp bitsel
    
    [ Upstream commit 2dee50ab9e72a3cae75b65e5934c8dd3e9bf01bc ]
    
    There are two UART clock groups, each having a mux to select its
    upstream clock source. The register/bit definitions for accessing these
    two muxes appear to have been reversed since introduction. Correct them
    so as to match the hardware manual.
    
    Fixes: 4c3d88526eba ("clk: renesas: Renesas R9A06G032 clock driver")
    
    Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
    Reviewed-by: Phil Edworthy <phil.edworthy@renesas.com>
    Link: https://lore.kernel.org/r/20220518182527.1693156-1-ralph.siemsen@linaro.org
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
coresight: Clear the connection field properly [+ + +]
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue Jun 14 22:40:24 2022 +0100

    coresight: Clear the connection field properly
    
    commit 2af89ebacf299b7fba5f3087d35e8a286ec33706 upstream.
    
    coresight devices track their connections (output connections) and
    hold a reference to the fwnode. When a device goes away, we walk through
    the devices on the coresight bus and make sure that the references
    are dropped. This happens both ways:
     a) For all output connections from the device, drop the reference to
        the target device via coresight_release_platform_data()
    
    b) Iterate over all the devices on the coresight bus and drop the
       reference to fwnode if *this* device is the target of the output
       connection, via coresight_remove_conns()->coresight_remove_match().
    
    However, the coresight_remove_match() doesn't clear the fwnode field,
    after dropping the reference, this causes use-after-free and
    additional refcount drops on the fwnode.
    
    e.g., if we have two devices, A and B, with a connection, A -> B.
    If we remove B first, B would clear the reference on B, from A
    via coresight_remove_match(). But when A is removed, it still has
    a connection with fwnode still pointing to B. Thus it tries to  drops
    the reference in coresight_release_platform_data(), raising the bells
    like :
    
    [   91.990153] ------------[ cut here ]------------
    [   91.990163] refcount_t: addition on 0; use-after-free.
    [   91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
    [   91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)
     crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]
    [   91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G        W       T 5.19.0-rc2+ #53
    [   91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb  1 2019
    [   91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   91.990454] pc : refcount_warn_saturate+0xa0/0x144
    [   91.990476] lr : refcount_warn_saturate+0xa0/0x144
    [   91.990496] sp : ffff80000c843640
    [   91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8
    [   91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8
    [   91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2
    [   91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40
    [   91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0
    [   91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375
    [   91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28
    [   91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572
    [   91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027
    [   91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00
    [   91.991000] Call trace:
    [   91.991012]  refcount_warn_saturate+0xa0/0x144
    [   91.991034]  kobject_get+0xac/0xb0
    [   91.991055]  of_node_get+0x2c/0x40
    [   91.991076]  of_fwnode_get+0x40/0x60
    [   91.991094]  fwnode_handle_get+0x3c/0x60
    [   91.991116]  fwnode_get_nth_parent+0xf4/0x110
    [   91.991137]  fwnode_full_name_string+0x48/0xc0
    [   91.991158]  device_node_string+0x41c/0x530
    [   91.991178]  pointer+0x320/0x3ec
    [   91.991198]  vsnprintf+0x23c/0x750
    [   91.991217]  vprintk_store+0x104/0x4b0
    [   91.991238]  vprintk_emit+0x8c/0x360
    [   91.991257]  vprintk_default+0x44/0x50
    [   91.991276]  vprintk+0xcc/0xf0
    [   91.991295]  _printk+0x68/0x90
    [   91.991315]  of_node_release+0x13c/0x14c
    [   91.991334]  kobject_put+0x98/0x114
    [   91.991354]  of_node_put+0x24/0x34
    [   91.991372]  of_fwnode_put+0x40/0x5c
    [   91.991390]  fwnode_handle_put+0x38/0x50
    [   91.991411]  coresight_release_platform_data+0x74/0xb0 [coresight]
    [   91.991472]  coresight_unregister+0x64/0xcc [coresight]
    [   91.991525]  etm4_remove_dev+0x64/0x78 [coresight_etm4x]
    [   91.991563]  etm4_remove_amba+0x1c/0x2c [coresight_etm4x]
    [   91.991598]  amba_remove+0x3c/0x19c
    
    Reproducible by: (Build all coresight components as modules):
    
      #!/bin/sh
      while true
      do
         for m in tmc stm cpu_debug etm4x replicator funnel
         do
            modprobe coresight_${m}
         done
    
         for m in tmc stm cpu_debug etm4x replicator funnel
         do
            rmmode coresight_${m}
         done
      done
    
    Cc: stable@vger.kernel.org
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Fixes: 37ea1ffddffa ("coresight: Use fwnode handle instead of device names")
    Link: https://lore.kernel.org/r/20220614214024.3005275-1-suzuki.poulose@arm.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: zynq: Fix refcount leak in zynq_get_revision [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 12:28:07 2022 +0400

    cpufreq: zynq: Fix refcount leak in zynq_get_revision
    
    [ Upstream commit d1ff2559cef0f6f8d97fba6337b28adb10689e16 ]
    
    of_find_compatible_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 00f7dc636366 ("ARM: zynq: Add support for SOC_BUS")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220605082807.21526-1-linmq006@gmail.com
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: arm64/gcm - Select AEAD for GHASH_ARM64_CE [+ + +]
Author: Qian Cai <quic_qiancai@quicinc.com>
Date:   Fri Jun 24 07:13:38 2022 -0400

    crypto: arm64/gcm - Select AEAD for GHASH_ARM64_CE
    
    [ Upstream commit fac76f2260893dde5aa05bb693b4c13e8ed0454b ]
    
    Otherwise, we could fail to compile.
    
    ld: arch/arm64/crypto/ghash-ce-glue.o: in function 'ghash_ce_mod_exit':
    ghash-ce-glue.c:(.exit.text+0x24): undefined reference to 'crypto_unregister_aead'
    ld: arch/arm64/crypto/ghash-ce-glue.o: in function 'ghash_ce_mod_init':
    ghash-ce-glue.c:(.init.text+0x34): undefined reference to 'crypto_register_aead'
    
    Fixes: 537c1445ab0b ("crypto: arm64/gcm - implement native driver using v8 Crypto Extensions")
    Signed-off-by: Qian Cai <quic_qiancai@quicinc.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: blake2s - remove shash module [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat May 28 21:44:07 2022 +0200

    crypto: blake2s - remove shash module
    
    [ Upstream commit 2d16803c562ecc644803d42ba98a8e0aef9c014e ]
    
    BLAKE2s has no currently known use as an shash. Just remove all of this
    unnecessary plumbing. Removing this shash was something we talked about
    back when we were making BLAKE2s a built-in, but I simply never got
    around to doing it. So this completes that project.
    
    Importantly, this fixs a bug in which the lib code depends on
    crypto_simd_disabled_for_test, causing linker errors.
    
    Also add more alignment tests to the selftests and compare SIMD and
    non-SIMD compression functions, to make up for what we lose from
    testmgr.c.
    
    Reported-by: gaochao <gaochao49@huawei.com>
    Cc: Eric Biggers <ebiggers@kernel.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccp - During shutdown, check SEV data pointer before using [+ + +]
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Thu Jun 16 10:26:18 2022 -0500

    crypto: ccp - During shutdown, check SEV data pointer before using
    
    [ Upstream commit 1b05ece0c931536c0a38a9385e243a7962e933f6 ]
    
    On shutdown, each CCP device instance performs shutdown processing.
    However, __sev_platform_shutdown_locked() uses the controlling psp
    structure to obtain the pointer to the sev_device structure. However,
    during driver initialization, it is possible that an error can be received
    from the firmware that results in the sev_data pointer being cleared from
    the controlling psp structure. The __sev_platform_shutdown_locked()
    function does not check for this situation and will segfault.
    
    While not common, this scenario should be accounted for. Add a check for a
    NULL sev_device structure before attempting to use it.
    
    Fixes: 5441a07a127f ("crypto: ccp - shutdown SEV firmware on kexec")
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak [+ + +]
Author: John Allen <john.allen@amd.com>
Date:   Wed May 18 15:31:26 2022 +0000

    crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak
    
    commit 13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae upstream.
    
    For some sev ioctl interfaces, input may be passed that is less than or
    equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP
    firmware returns. In this case, kmalloc will allocate memory that is the
    size of the input rather than the size of the data. Since PSP firmware
    doesn't fully overwrite the buffer, the sev ioctl interfaces with the
    issue may return uninitialized slab memory.
    
    Currently, all of the ioctl interfaces in the ccp driver are safe, but
    to prevent future problems, change all ioctl interfaces that allocate
    memory with kmalloc to use kzalloc and memset the data buffer to zero
    in sev_ioctl_do_platform_status.
    
    Fixes: 38103671aad3 ("crypto: ccp: Use the stack and common buffer for status commands")
    Fixes: e799035609e15 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command")
    Fixes: 76a2b524a4b1d ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command")
    Fixes: d6112ea0cb344 ("crypto: ccp - introduce SEV_GET_ID2 command")
    Cc: stable@vger.kernel.org
    Reported-by: Andy Nguyen <theflow@google.com>
    Suggested-by: David Rientjes <rientjes@google.com>
    Suggested-by: Peter Gonda <pgonda@google.com>
    Signed-off-by: John Allen <john.allen@amd.com>
    Reviewed-by: Peter Gonda <pgonda@google.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: hisilicon - Kunpeng916 crypto driver don't sleep when in softirq [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Fri Jul 1 09:59:54 2022 +0800

    crypto: hisilicon - Kunpeng916 crypto driver don't sleep when in softirq
    
    [ Upstream commit 68740ab505431f268dc1ee26a54b871e75f0ddaa ]
    
    When kunpeng916 encryption driver is used to deencrypt and decrypt
    packets during the softirq, it is not allowed to use mutex lock.
    
    Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Tue Jul 19 12:23:23 2022 +0800

    crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq
    
    [ Upstream commit 98dfa9343f37bdd4112966292751e3a93aaf2e56 ]
    
    The hpre encryption driver may be used to encrypt and decrypt packets
    during the rx softirq, it is not allowed to use GFP_KERNEL.
    
    Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/sec - don't sleep when in softirq [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Fri Jul 1 09:55:11 2022 +0800

    crypto: hisilicon/sec - don't sleep when in softirq
    
    [ Upstream commit 02884a4f12de11f54d4ca67a07dd1f111d96fdbd ]
    
    When kunpeng920 encryption driver is used to deencrypt and decrypt
    packets during the softirq, it is not allowed to use mutex lock. The
    kernel will report the following error:
    
    BUG: scheduling while atomic: swapper/57/0/0x00000300
    Call trace:
    dump_backtrace+0x0/0x1e4
    show_stack+0x20/0x2c
    dump_stack+0xd8/0x140
    __schedule_bug+0x68/0x80
    __schedule+0x728/0x840
    schedule+0x50/0xe0
    schedule_preempt_disabled+0x18/0x24
    __mutex_lock.constprop.0+0x594/0x5dc
    __mutex_lock_slowpath+0x1c/0x30
    mutex_lock+0x50/0x60
    sec_request_init+0x8c/0x1a0 [hisi_sec2]
    sec_process+0x28/0x1ac [hisi_sec2]
    sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2]
    sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2]
    crypto_skcipher_encrypt+0x2c/0x40
    crypto_authenc_encrypt+0xc8/0xfc [authenc]
    crypto_aead_encrypt+0x2c/0x40
    echainiv_encrypt+0x144/0x1a0 [echainiv]
    crypto_aead_encrypt+0x2c/0x40
    esp_output_tail+0x348/0x5c0 [esp4]
    esp_output+0x120/0x19c [esp4]
    xfrm_output_one+0x25c/0x4d4
    xfrm_output_resume+0x6c/0x1fc
    xfrm_output+0xac/0x3c0
    xfrm4_output+0x64/0x130
    ip_build_and_send_pkt+0x158/0x20c
    tcp_v4_send_synack+0xdc/0x1f0
    tcp_conn_request+0x7d0/0x994
    tcp_v4_conn_request+0x58/0x6c
    tcp_v6_conn_request+0xf0/0x100
    tcp_rcv_state_process+0x1cc/0xd60
    tcp_v4_do_rcv+0x10c/0x250
    tcp_v4_rcv+0xfc4/0x10a4
    ip_protocol_deliver_rcu+0xf4/0x200
    ip_local_deliver_finish+0x58/0x70
    ip_local_deliver+0x68/0x120
    ip_sublist_rcv_finish+0x70/0x94
    ip_list_rcv_finish.constprop.0+0x17c/0x1d0
    ip_sublist_rcv+0x40/0xb0
    ip_list_rcv+0x140/0x1dc
    __netif_receive_skb_list_core+0x154/0x28c
    __netif_receive_skb_list+0x120/0x1a0
    netif_receive_skb_list_internal+0xe4/0x1f0
    napi_complete_done+0x70/0x1f0
    gro_cell_poll+0x9c/0xb0
    napi_poll+0xcc/0x264
    net_rx_action+0xd4/0x21c
    __do_softirq+0x130/0x358
    irq_exit+0x11c/0x13c
    __handle_domain_irq+0x88/0xf0
    gic_handle_irq+0x78/0x2c0
    el1_irq+0xb8/0x140
    arch_cpu_idle+0x18/0x40
    default_idle_call+0x5c/0x1c0
    cpuidle_idle_call+0x174/0x1b0
    do_idle+0xc8/0x160
    cpu_startup_entry+0x30/0x11c
    secondary_start_kernel+0x158/0x1e4
    softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with
    preempt_count 00000100, exited with fffffe00?
    
    Fixes: 416d82204df4 ("crypto: hisilicon - add HiSilicon SEC V2 driver")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/sec - fix auth key size error [+ + +]
Author: Kai Ye <yekai13@huawei.com>
Date:   Thu Jul 21 10:18:31 2022 +0800

    crypto: hisilicon/sec - fix auth key size error
    
    [ Upstream commit 45f5d0176d8426cc1ab0bab84fbd8ef5c57526c6 ]
    
    The authentication algorithm supports a maximum of 128-byte keys.
    The allocated key memory is insufficient.
    
    Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2")
    Signed-off-by: Kai Ye <yekai13@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: inside-secure - Add missing MODULE_DEVICE_TABLE for of [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Jul 19 09:54:03 2022 +0200

    crypto: inside-secure - Add missing MODULE_DEVICE_TABLE for of
    
    [ Upstream commit fa4d57b85786ec0e16565c75a51c208834b0c24d ]
    
    Without MODULE_DEVICE_TABLE, crypto_safexcel.ko module is not automatically
    loaded on platforms where inside-secure crypto HW is specified in device
    tree (e.g. Armada 3720). So add missing MODULE_DEVICE_TABLE for of.
    
    Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Acked-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: lib/blake2s - reduce stack frame usage in self test [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 20 09:52:43 2022 +0200

    crypto: lib/blake2s - reduce stack frame usage in self test
    
    commit d6c14da474bf260d73953fbf7992c98d9112aec7 upstream.
    
    Using 3 blocks here doesn't give us much more than using 2, and it
    causes a stack frame size warning on certain compiler/config/arch
    combinations:
    
       lib/crypto/blake2s-selftest.c: In function 'blake2s_selftest':
    >> lib/crypto/blake2s-selftest.c:632:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
         632 | }
             | ^
    
    So this patch just reduces the block from 3 to 2, which makes the
    warning go away.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/linux-crypto/202206200851.gE3MHCgd-lkp@intel.com
    Fixes: 2d16803c562e ("crypto: blake2s - remove shash module")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: sun8i-ss - do not allocate memory when handling hash requests [+ + +]
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon May 2 20:19:19 2022 +0000

    crypto: sun8i-ss - do not allocate memory when handling hash requests
    
    [ Upstream commit 8eec4563f152981a441693fc97c5459843dc5e6e ]
    
    Instead of allocate memory on each requests, it is easier to
    pre-allocate buffers.
    This made error path easier.
    
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sun8i-ss - fix error codes in allocate_flows() [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 18 20:33:44 2022 +0300

    crypto: sun8i-ss - fix error codes in allocate_flows()
    
    [ Upstream commit d2765e1b9ac4b2d5a5d5bf17f468c9b3566c3770 ]
    
    These failure paths should return -ENOMEM.  Currently they return
    success.
    
    Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
    Fixes: 8eec4563f152 ("crypto: sun8i-ss - do not allocate memory when handling hash requests")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sun8i-ss - fix infinite loop in sun8i_ss_setup_ivs() [+ + +]
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Jun 10 21:27:15 2022 +0300

    crypto: sun8i-ss - fix infinite loop in sun8i_ss_setup_ivs()
    
    [ Upstream commit d61a7b3decf7f0cf4121a7204303deefd2c7151b ]
    
    There is no i decrement in while (i >= 0) loop.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
    Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp: put dccp_qpolicy_full() and dccp_qpolicy_push() in the same lock [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Fri Jul 29 19:00:27 2022 +0800

    dccp: put dccp_qpolicy_full() and dccp_qpolicy_push() in the same lock
    
    [ Upstream commit a41b17ff9dacd22f5f118ee53d82da0f3e52d5e3 ]
    
    In the case of sk->dccps_qpolicy == DCCPQ_POLICY_PRIO, dccp_qpolicy_full
    will drop a skb when qpolicy is full. And the lock in dccp_sendmsg is
    released before sock_alloc_send_skb and then relocked after
    sock_alloc_send_skb. The following conditions may lead dccp_qpolicy_push
    to add skb to an already full sk_write_queue:
    
    thread1--->lock
    thread1--->dccp_qpolicy_full: queue is full. drop a skb
    thread1--->unlock
    thread2--->lock
    thread2--->dccp_qpolicy_full: queue is not full. no need to drop.
    thread2--->unlock
    thread1--->lock
    thread1--->dccp_qpolicy_push: add a skb. queue is full.
    thread1--->unlock
    thread2--->lock
    thread2--->dccp_qpolicy_push: add a skb!
    thread2--->unlock
    
    Fix this by moving dccp_qpolicy_full.
    
    Fixes: b1308dc015eb ("[DCCP]: Set TX Queue Length Bounds via Sysctl")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220729110027.40569-1-hbh25y@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm raid: fix address sanitizer warning in raid_resume [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sun Jul 24 14:33:52 2022 -0400

    dm raid: fix address sanitizer warning in raid_resume
    
    [ Upstream commit 7dad24db59d2d2803576f2e3645728866a056dab ]
    
    There is a KASAN warning in raid_resume when running the lvm test
    lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks
    is greater than rs->raid_disks, so the loop touches one entry beyond
    the allocated length.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm raid: fix address sanitizer warning in raid_status [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sun Jul 24 14:31:35 2022 -0400

    dm raid: fix address sanitizer warning in raid_status
    
    [ Upstream commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 ]
    
    There is this warning when using a kernel with the address sanitizer
    and running this testsuite:
    https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
    Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
    CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6a/0x9c
     print_address_description.constprop.0+0x1f/0x1e0
     print_report.cold+0x55/0x244
     kasan_report+0xc9/0x100
     raid_status+0x1747/0x2820 [dm_raid]
     dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
     table_load+0x35c/0x630 [dm_mod]
     ctl_ioctl+0x411/0x630 [dm_mod]
     dm_ctl_ioctl+0xa/0x10 [dm_mod]
     __x64_sys_ioctl+0x12a/0x1a0
     do_syscall_64+0x5b/0x80
    
    The warning is caused by reading conf->max_nr_stripes in raid_status. The
    code in raid_status reads mddev->private, casts it to struct r5conf and
    reads the entry max_nr_stripes.
    
    However, if we have different raid type than 4/5/6, mddev->private
    doesn't point to struct r5conf; it may point to struct r0conf, struct
    r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
    of these structs to struct r5conf, we will be reading invalid memory
    and KASAN warns about it.
    
    Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm thin: fix use-after-free crash in dm_sm_register_threshold_callback [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Thu Jul 14 19:28:25 2022 +0800

    dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
    
    [ Upstream commit 3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 ]
    
    Fault inject on pool metadata device reports:
      BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
      Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950
    
      CPU: 7 PID: 950 Comm: dmsetup Tainted: G        W         5.19.0-rc6 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x34/0x44
       print_address_description.constprop.0.cold+0xeb/0x3f4
       kasan_report.cold+0xe6/0x147
       dm_pool_register_metadata_threshold+0x40/0x80
       pool_ctr+0xa0a/0x1150
       dm_table_add_target+0x2c8/0x640
       table_load+0x1fd/0x430
       ctl_ioctl+0x2c4/0x5a0
       dm_ctl_ioctl+0xa/0x10
       __x64_sys_ioctl+0xb3/0xd0
       do_syscall_64+0x35/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    This can be easily reproduced using:
      echo offline > /sys/block/sda/device/state
      dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10
      dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"
    
    If a metadata commit fails, the transaction will be aborted and the
    metadata space maps will be destroyed. If a DM table reload then
    happens for this failed thin-pool, a use-after-free will occur in
    dm_sm_register_threshold_callback (called from
    dm_pool_register_metadata_threshold).
    
    Fix this by in dm_pool_register_metadata_threshold() by returning the
    -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()
    with a new error message: "Error registering metadata threshold".
    
    Fixes: ac8c3f3df65e4 ("dm thin: generate event when metadata threshold passed")
    Cc: stable@vger.kernel.org
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm writecache: count number of blocks discarded, not number of discard bios [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jul 11 16:31:52 2022 -0400

    dm writecache: count number of blocks discarded, not number of discard bios
    
    [ Upstream commit 2ee73ef60db4d79b9f9b8cd501e8188b5179449f ]
    
    Change dm-writecache, so that it counts the number of blocks discarded
    instead of the number of discard bios. Make it consistent with the
    read and write statistics counters that were changed to count the
    number of blocks instead of bios.
    
    Fixes: e3a35d03407c ("dm writecache: add event counters")
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm writecache: count number of blocks read, not number of read bios [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jul 11 16:30:52 2022 -0400

    dm writecache: count number of blocks read, not number of read bios
    
    [ Upstream commit 2c6e755b49d273243431f5f1184654e71221fc78 ]
    
    Change dm-writecache, so that it counts the number of blocks read
    instead of the number of read bios. Bios can be split and requeued
    using the dm_accept_partial_bio function, so counting bios caused
    inaccurate results.
    
    Fixes: e3a35d03407c ("dm writecache: add event counters")
    Reported-by: Yu Kuai <yukuai1@huaweicloud.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm writecache: count number of blocks written, not number of write bios [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jul 11 16:31:26 2022 -0400

    dm writecache: count number of blocks written, not number of write bios
    
    [ Upstream commit b2676e1482af89714af6988ce5d31a84692e2530 ]
    
    Change dm-writecache, so that it counts the number of blocks written
    instead of the number of write bios. Bios can be split and requeued
    using the dm_accept_partial_bio function, so counting bios caused
    inaccurate results.
    
    Fixes: e3a35d03407c ("dm writecache: add event counters")
    Reported-by: Yu Kuai <yukuai1@huaweicloud.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm writecache: return void from functions [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jul 11 16:30:27 2022 -0400

    dm writecache: return void from functions
    
    [ Upstream commit 9bc0c92e4b82adb017026dbb2aa816b1ac2bef31 ]
    
    The functions writecache_map_remap_origin and writecache_bio_copy_ssd
    only return a single value, thus they can be made to return void.
    
    This helps simplify the following IO accounting changes.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm writecache: set a default MAX_WRITEBACK_JOBS [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jul 13 07:09:04 2022 -0400

    dm writecache: set a default MAX_WRITEBACK_JOBS
    
    [ Upstream commit ca7dc242e358e46d963b32f9d9dd829785a9e957 ]
    
    dm-writecache has the capability to limit the number of writeback jobs
    in progress. However, this feature was off by default. As such there
    were some out-of-memory crashes observed when lowering the low
    watermark while the cache is full.
    
    This commit enables writeback limit by default. It is set to 256MiB or
    1/16 of total system memory, whichever is smaller.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm: return early from dm_pr_call() if DM device is suspended [+ + +]
Author: Mike Snitzer <snitzer@kernel.org>
Date:   Fri Jul 22 15:31:23 2022 -0400

    dm: return early from dm_pr_call() if DM device is suspended
    
    [ Upstream commit e120a5f1e78fab6223544e425015f393d90d6f0d ]
    
    Otherwise PR ops may be issued while the broader DM device is being
    reconfigured, etc.
    
    Fixes: 9c72bad1f31a ("dm: call PR reserve/unreserve on each underlying device")
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Tue May 24 10:21:57 2022 -0500

    dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics
    
    [ Upstream commit c1e33979171da63cf47e56243ccb8ba82363c7d3 ]
    
    In accordance with [1, 2] the DW eDMA controller has been created to be
    part of the DW PCIe Root Port and DW PCIe End-point controllers and to
    offload the transferring of large blocks of data between application and
    remote PCIe domains leaving the system CPU free for other tasks. In the
    first case (eDMA being part of DW PCIe Root Port) the eDMA controller is
    always accessible via the CPU DBI interface and never over the PCIe wire.
    
    The latter case is more complex. Depending on the DW PCIe End-Point IP-core
    synthesize parameters it's possible to have the eDMA registers accessible
    not only from the application CPU side, but also via mapping the eDMA CSRs
    over a dedicated endpoint BAR. So based on the specifics denoted above the
    eDMA driver is supposed to support two types of the DMA controller setups:
    
      1) eDMA embedded into the DW PCIe Root Port/End-point and accessible over
         the local CPU from the application side.
    
      2) eDMA embedded into the DW PCIe End-point and accessible via the PCIe
         wire with MWr/MRd TLPs generated by the CPU PCIe host controller.
    
    Since the CPU memory resides different sides in these cases the semantics
    of the MEM_TO_DEV and DEV_TO_MEM operations is flipped with respect to the
    Tx and Rx DMA channels. So MEM_TO_DEV/DEV_TO_MEM corresponds to the Tx/Rx
    channels in setup 1) and to the Rx/Tx channels in case of setup 2).
    
    The DW eDMA driver has supported the case 2) since e63d79d1ffcd
    ("dmaengine: Add Synopsys eDMA IP core driver") in the framework of the
    drivers/dma/dw-edma/dw-edma-pcie.c driver.
    
    The case 1) support was added later by bd96f1b2f43a ("dmaengine: dw-edma:
    support local dma device transfer semantics").  Afterwards the driver was
    supposed to cover the both possible eDMA setups, but the latter commit
    turned out to be not fully correct.
    
    The problem was that the commit together with the new functionality support
    also changed the channel direction semantics so the eDMA Read-channel
    (corresponding to the DMA_DEV_TO_MEM direction for case 1) now uses the
    sgl/cyclic base addresses as the Source addresses of the DMA transfers and
    dma_slave_config.dst_addr as the Destination address of the DMA transfers.
    
    Similarly the eDMA Write-channel (corresponding to the DMA_MEM_TO_DEV
    direction for case 1) now uses dma_slave_config.src_addr as a source
    address of the DMA transfers and sgl/cyclic base address as the Destination
    address of the DMA transfers. This contradicts the logic of the
    DMA-interface, which implies that DEV side is supposed to belong to the
    PCIe device memory and MEM - to the CPU/Application memory. Indeed it seems
    irrational to have the SG-list defined in the PCIe bus space, while
    expecting a contiguous buffer allocated in the CPU memory. Moreover the
    passed SG-list and cyclic DMA buffers are supposed to be mapped in a way so
    to be seen by the DW eDMA Application (CPU) interface.
    
    So in order to have the correct DW eDMA interface we need to invert the
    eDMA Rd/Wr-channels and DMA-slave directions semantics by selecting the
    src/dst addresses based on the DMA transfer direction instead of using the
    channel direction capability.
    
    [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
        v.5.40a, March 2019, p.1092
    [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
        v.5.40a, March 2019, p.1189
    
    Co-developed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics")
    Link: https://lore.kernel.org/r/20220524152159.2370739-7-Frank.Li@nxp.com
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-By: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t) [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Jul 6 08:13:27 2022 -0300

    dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t)
    
    [ Upstream commit c3266ee185b59e5aab3e0f982e5b7f95d31555a7 ]
    
    Change the of_device_get_match_data() cast to (uintptr_t)
    to silence the following clang warning:
    
    drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 0ab785c894e6 ("dmaengine: imx-dma: Remove unused .id_table")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Link: https://lore.kernel.org/r/20220706111327.940764-1-festevam@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: sf-pdma: Add multithread support for a DMA channel [+ + +]
Author: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
Date:   Fri Jul 1 11:29:42 2022 +0300

    dmaengine: sf-pdma: Add multithread support for a DMA channel
    
    [ Upstream commit b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc ]
    
    When we get a DMA channel and try to use it in multiple threads it
    will cause oops and hanging the system.
    
    % echo 64 > /sys/module/dmatest/parameters/threads_per_chan
    % echo 10000 > /sys/module/dmatest/parameters/iterations
    % echo 1 > /sys/module/dmatest/parameters/run
    [   89.480664] Unable to handle kernel NULL pointer dereference at virtual
                   address 00000000000000a0
    [   89.488725] Oops [#1]
    [   89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted
                   5.17.0-rc5
    [   89.509385] epc : vchan_find_desc+0x32/0x46
    [   89.513553]  ra : sf_pdma_tx_status+0xca/0xd6
    
    This happens because of data race. Each thread rewrite channels's
    descriptor as soon as device_prep_dma_memcpy() is called. It leads to the
    situation when the driver thinks that it uses right descriptor that
    actually is freed or substituted for other one.
    
    With current fixes a descriptor changes its value only when it has
    been used. A new descriptor is acquired from vc->desc_issued queue that
    is already filled with descriptors that are ready to be sent. Threads
    have no direct access to DMA channel descriptor. Now it is just possible
    to queue a descriptor for further processing.
    
    Fixes: 6973886ad58e ("dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00")
    Signed-off-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
    Link: https://lore.kernel.org/r/20220701082942.12835-1-v.v.mitrofanov@yadro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
driver core: fix potential deadlock in __driver_attach [+ + +]
Author: Zhang Wensheng <zhangwensheng5@huawei.com>
Date:   Wed Jun 22 15:43:27 2022 +0800

    driver core: fix potential deadlock in __driver_attach
    
    [ Upstream commit 70fe758352cafdee72a7b13bf9db065f9613ced8 ]
    
    In __driver_attach function, There are also AA deadlock problem,
    like the commit b232b02bf3c2 ("driver core: fix deadlock in
    __device_attach").
    
    stack like commit b232b02bf3c2 ("driver core: fix deadlock in
    __device_attach").
    list below:
        In __driver_attach function, The lock holding logic is as follows:
        ...
        __driver_attach
        if (driver_allows_async_probing(drv))
          device_lock(dev)      // get lock dev
            async_schedule_dev(__driver_attach_async_helper, dev); // func
              async_schedule_node
                async_schedule_node_domain(func)
                  entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
                  /* when fail or work limit, sync to execute func, but
                     __driver_attach_async_helper will get lock dev as
                     will, which will lead to A-A deadlock.  */
                  if (!entry || atomic_read(&entry_count) > MAX_WORK) {
                    func;
                  else
                    queue_work_node(node, system_unbound_wq, &entry->work)
          device_unlock(dev)
    
        As above show, when it is allowed to do async probes, because of
        out of memory or work limit, async work is not be allowed, to do
        sync execute instead. it will lead to A-A deadlock because of
        __driver_attach_async_helper getting lock dev.
    
    Reproduce:
    and it can be reproduce by make the condition
    (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
    below:
    
    [  370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
    this message.
    [  370.787154] task:swapper/0       state:D stack:    0 pid:    1 ppid:
    0 flags:0x00004000
    [  370.788865] Call Trace:
    [  370.789374]  <TASK>
    [  370.789841]  __schedule+0x482/0x1050
    [  370.790613]  schedule+0x92/0x1a0
    [  370.791290]  schedule_preempt_disabled+0x2c/0x50
    [  370.792256]  __mutex_lock.isra.0+0x757/0xec0
    [  370.793158]  __mutex_lock_slowpath+0x1f/0x30
    [  370.794079]  mutex_lock+0x50/0x60
    [  370.794795]  __device_driver_lock+0x2f/0x70
    [  370.795677]  ? driver_probe_device+0xd0/0xd0
    [  370.796576]  __driver_attach_async_helper+0x1d/0xd0
    [  370.797318]  ? driver_probe_device+0xd0/0xd0
    [  370.797957]  async_schedule_node_domain+0xa5/0xc0
    [  370.798652]  async_schedule_node+0x19/0x30
    [  370.799243]  __driver_attach+0x246/0x290
    [  370.799828]  ? driver_allows_async_probing+0xa0/0xa0
    [  370.800548]  bus_for_each_dev+0x9d/0x130
    [  370.801132]  driver_attach+0x22/0x30
    [  370.801666]  bus_add_driver+0x290/0x340
    [  370.802246]  driver_register+0x88/0x140
    [  370.802817]  ? virtio_scsi_init+0x116/0x116
    [  370.803425]  scsi_register_driver+0x1a/0x30
    [  370.804057]  init_sd+0x184/0x226
    [  370.804533]  do_one_initcall+0x71/0x3a0
    [  370.805107]  kernel_init_freeable+0x39a/0x43a
    [  370.805759]  ? rest_init+0x150/0x150
    [  370.806283]  kernel_init+0x26/0x230
    [  370.806799]  ret_from_fork+0x1f/0x30
    
    To fix the deadlock, move the async_schedule_dev outside device_lock,
    as we can see, in async_schedule_node_domain, the parameter of
    queue_work_node is system_unbound_wq, so it can accept concurrent
    operations. which will also not change the code logic, and will
    not lead to deadlock.
    
    Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver")
    Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
    Link: https://lore.kernel.org/r/20220622074327.497102-1-zhangwensheng5@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/iio: Remove all strcpy() uses [+ + +]
Author: Len Baker <len.baker@gmx.com>
Date:   Sun Aug 15 19:42:04 2021 +0200

    drivers/iio: Remove all strcpy() uses
    
    [ Upstream commit d722f1e06fbc53eb369b39646945c1fa92068e74 ]
    
    strcpy() performs no bounds checking on the destination buffer. This
    could result in linear overflows beyond the end of the buffer, leading
    to all kinds of misbehaviors. So, remove all the uses and add
    devm_kstrdup() or devm_kasprintf() instead.
    
    Also, modify the "for" loop conditions to clarify the access to the
    st->orientation.rotation buffer.
    
    This patch is an effort to clean up the proliferation of str*()
    functions in the kernel and a previous step in the path to remove
    the strcpy function from the kernel entirely [1].
    
    [1] https://github.com/KSPP/linux/issues/88
    
    Signed-off-by: Len Baker <len.baker@gmx.com>
    Link: https://lore.kernel.org/r/20210815174204.126593-1-len.baker@gmx.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/perf: arm_spe: Fix consistency of SYS_PMSCR_EL1.CX [+ + +]
Author: Anshuman Khandual <anshuman.khandual@arm.com>
Date:   Thu Jul 14 11:43:02 2022 +0530

    drivers/perf: arm_spe: Fix consistency of SYS_PMSCR_EL1.CX
    
    [ Upstream commit 92f2b8bafa3d6e89c750e9d301a8b7ab76aaa8b6 ]
    
    The arm_spe_pmu driver will enable SYS_PMSCR_EL1.CX in order to add CONTEXT
    packets into the traces, if the owner of the perf event runs with required
    capabilities i.e CAP_PERFMON or CAP_SYS_ADMIN via perfmon_capable() helper.
    
    The value of this bit is computed in the arm_spe_event_to_pmscr() function
    but the check for capabilities happens in the pmu event init callback i.e
    arm_spe_pmu_event_init(). This suggests that the value of the CX bit should
    remain consistent for the duration of the perf session.
    
    However, the function arm_spe_event_to_pmscr() may be called later during
    the event start callback i.e arm_spe_pmu_start() when the "current" process
    is not the owner of the perf session, hence the CX bit setting is currently
    not consistent.
    
    One way to fix this, is by caching the required value of the CX bit during
    the initialization of the PMU event, so that it remains consistent for the
    duration of the session. It uses currently unused 'event->hw.flags' element
    to cache perfmon_capable() value, which can be referred during event start
    callback to compute SYS_PMSCR_EL1.CX. This ensures consistent availability
    of context packets in the trace as per event owner capabilities.
    
    Drop BIT(SYS_PMSCR_EL1_CX_SHIFT) check in arm_spe_pmu_event_init(), because
    now CX bit cannot be set in arm_spe_event_to_pmscr() with perfmon_capable()
    disabled.
    
    Cc: Will Deacon <will@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension")
    Reported-by: German Gomez <german.gomez@arm.com>
    Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20220714061302.2715102-1-anshuman.khandual@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Check BO's requested pinning domains against its preferred_domains [+ + +]
Author: Leo Li <sunpeng.li@amd.com>
Date:   Tue Jul 12 12:30:29 2022 -0400

    drm/amdgpu: Check BO's requested pinning domains against its preferred_domains
    
    commit f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 upstream.
    
    When pinning a buffer, we should check to see if there are any
    additional restrictions imposed by bo->preferred_domains. This will
    prevent the BO from being moved to an invalid domain when pinning.
    
    For example, this can happen if the user requests to create a BO in GTT
    domain for display scanout. amdgpu_dm will allow pinning to either VRAM
    or GTT domains, since DCN can scanout from either or. However, in
    amdgpu_bo_pin_restricted(), pinning to VRAM is preferred if there is
    adequate carveout. This can lead to pinning to VRAM despite the user
    requesting GTT placement for the BO.
    
    v2: Allow the kernel to override the domain, which can happen when
        exporting a BO to a V4L camera (for example).
    
    Signed-off-by: Leo Li <sunpeng.li@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix check in fbdev init [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jul 19 14:56:59 2022 -0400

    drm/amdgpu: fix check in fbdev init
    
    The new vkms virtual display code is atomic so there is
    no need to call drm_helper_disable_unused_functions()
    when it is enabled.  Doing so can result in a segfault.
    When the driver switched from the old virtual display code
    to the new atomic virtual display code, it was missed that
    we enable virtual display unconditionally under SR-IOV
    so the checks here missed that case.  Add the missing
    check for SR-IOV.
    
    There is no equivalent of this patch for Linus' tree
    because the relevant code no longer exists.  This patch
    is only relevant to kernels 5.15 and 5.16.
    
    Fixes: 84ec374bd580 ("drm/amdgpu: create amdgpu_vkms (v4)")
    Cc: stable@vger.kernel.org # 5.15.x
    Cc: hgoffin@amazon.com
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Remove one duplicated ef removal [+ + +]
Author: xinhui pan <xinhui.pan@amd.com>
Date:   Fri Jul 8 09:22:44 2022 +0800

    drm/amdgpu: Remove one duplicated ef removal
    
    [ Upstream commit e1aadbab445b06e072013a1365fd0cf2aa25e843 ]
    
    That has been done in BO release notify.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2074
    Signed-off-by: xinhui pan <xinhui.pan@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: Add a function to abstract away panels [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Fri Sep 10 15:09:39 2021 +0200

    drm/bridge: Add a function to abstract away panels
    
    [ Upstream commit 87ea95808d53e56b03e620e8f8f3add48899a88d ]
    
    Display drivers so far need to have a lot of boilerplate to first
    retrieve either the panel or bridge that they are connected to using
    drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
    functions or create a drm panel bridge through drm_panel_bridge_add.
    
    In order to reduce the boilerplate and hopefully create a path of least
    resistance towards using the DRM panel bridge layer, let's create the
    function devm_drm_of_get_bridge() to reduce that boilerplate.
    
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210910130941.1740182-2-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt9611uxc: Cancel only driver's work [+ + +]
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Wed Jun 1 16:38:18 2022 -0700

    drm/bridge: lt9611uxc: Cancel only driver's work
    
    [ Upstream commit dfa687bffc8a4a21ed929c7dececf01b8f1f52ee ]
    
    During device remove care needs to be taken that no work is pending
    before it removes the underlying DRM bridge etc, but this can be done on
    the specific work rather than waiting for the flush of the system-wide
    workqueue.
    
    Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220601233818.1877963-1-bjorn.andersson@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Fri Sep 17 20:09:25 2021 +0200

    drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c
    
    commit d4ae66f10c8b9959dce1766d9a87070e567236eb upstream.
    
    By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge()
    introduces a circular dependency between the modules drm (where
    devm_drm_of_get_bridge() ends up) and drm_kms_helper (where
    devm_drm_panel_bridge_add() is).
    
    Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus
    drm_kms_helper.
    
    Fixes: 87ea95808d53 ("drm/bridge: Add a function to abstract away panels")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Tested-by: Heiko Stuebner <heiko@sntech.de>
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210917180925.2602266-1-maxime@cerno.tech
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/bridge: tc358767: Fix (e)DP bridge endpoint parsing in dedicated function [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Apr 28 23:31:32 2022 +0200

    drm/bridge: tc358767: Fix (e)DP bridge endpoint parsing in dedicated function
    
    commit 9030a9e571b3ba250d3d450a98310e3c74ecaff4 upstream.
    
    Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP
    port is optional. In case this port is not described in DT, the bridge
    driver operates in DPI-to-DP mode. The drm_of_find_panel_or_bridge()
    call in tc_probe_edp_bridge_endpoint() returns -ENODEV in case port@2
    is not present in DT and this specific return value is incorrectly
    propagated outside of tc_probe_edp_bridge_endpoint() function. All
    other error values must be propagated and are propagated correctly.
    
    Return 0 in case the port@2 is missing instead, that reinstates the
    original behavior before the commit this patch fixes.
    
    Fixes: 8478095a8c4b ("drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Jonas Karlman <jonas@kwiboo.se>
    Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Marek Vasut <marex@denx.de>
    Cc: Maxime Ripard <maxime@cerno.tech>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Cc: Robert Foss <robert.foss@linaro.org>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220428213132.447890-1-marex@denx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Tue Mar 29 10:50:10 2022 +0200

    drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function
    
    [ Upstream commit 8478095a8c4bcea3c83b0767d6c9127434160761 ]
    
    The TC358767/TC358867/TC9595 are all capable of operating in multiple
    modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
    currently supported. In order to support the rest of the modes without
    making the tc_probe() overly long, split the bridge endpoint parsing
    into dedicated function, where the necessary logic to detect the bridge
    mode based on which endpoints are connected, can be implemented.
    
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Lucas Stach <l.stach@pengutronix.de> # In both DPI to eDP and DSI to DPI mode.
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Jonas Karlman <jonas@kwiboo.se>
    Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
    Cc: Maxime Ripard <maxime@cerno.tech>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220329085015.39159-7-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/dp/mst: Read the extended DPCD capabilities during system resume [+ + +]
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Jun 14 12:45:37 2022 +0300

    drm/dp/mst: Read the extended DPCD capabilities during system resume
    
    [ Upstream commit 7a710a8bc909313951eb9252d8419924c771d7c2 ]
    
    The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
    from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
    registers are not read subsequently also as required.
    
    Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
    done during connector detection. While at it also fix up the same call
    in drm_dp_mst_dump_topology().
    
    Cc: Lyude Paul <lyude@redhat.com>
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Cc: <stable@vger.kernel.org> # v5.14+
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220614094537.885472-1-imre.deak@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/dp: Export symbol / kerneldoc fixes for DP AUX bus [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue May 10 12:29:41 2022 -0700

    drm/dp: Export symbol / kerneldoc fixes for DP AUX bus
    
    [ Upstream commit 39c28cdfb719f0e306b447f0827dfd712f81858b ]
    
    While working on the DP AUX bus code I found a few small things that
    should be fixed. Namely the non-devm version of
    of_dp_aux_populate_ep_devices() was missing an export. There was also
    an extra blank line in a kerneldoc and a kerneldoc that incorrectly
    documented a return value. Fix these.
    
    Fixes: aeb33699fc2c ("drm: Introduce the DP AUX bus")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.1.Ia91f4849adfc5eb9da1eb37ba79aa65fb3c95a0f@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed. [+ + +]
Author: Jian Zhang <zhangjian210@huawei.com>
Date:   Tue Jul 12 13:56:11 2022 +0900

    drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed.
    
    [ Upstream commit 48b927770f8ad3f8cf4a024a552abf272af9f592 ]
    
    In exynos7_decon_resume, When it fails, we must use clk_disable_unprepare()
    to free resource that have been used.
    
    Fixes: 6f83d20838c09 ("drm/exynos: use DRM_DEV_ERROR to print out error
    message")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Jian Zhang <zhangjian210@huawei.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error [+ + +]
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Thu Jun 30 23:04:04 2022 +0300

    drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error
    
    commit 2939deac1fa220bc82b89235f146df1d9b52e876 upstream.
    
    Use ww_acquire_fini() in the error code paths. Otherwise lockdep
    thinks that lock is held when lock's memory is freed after the
    drm_gem_lock_reservations() error. The ww_acquire_context needs to be
    annotated as "released", which fixes the noisy "WARNING: held lock freed!"
    splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.
    
    Cc: stable@vger.kernel.org
    Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO reservations.")
    Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220630200405.1883897-2-dmitry.osipenko@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/hyperv-drm: Include framebuffer and EDID headers [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Wed Jun 22 10:34:13 2022 +0200

    drm/hyperv-drm: Include framebuffer and EDID headers
    
    commit 009a3a52791f31c57d755a73f6bc66fbdd8bd76c upstream.
    
    Fix a number of compile errors by including the correct header
    files. Examples are shown below.
    
      ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect':
      ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer'
       25 |         struct hyperv_drm_device *hv = to_hv(fb->dev);
          |                                                ^~
    
      ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes':
      ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration]
       59 |         count = drm_add_modes_noedid(connector,
          |                 ^~~~~~~~~~~~~~~~~~~~
    
      ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration]
       62 |         drm_set_preferred_mode(connector, hv->preferred_width,
          |         ^~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device")
    Fixes: 720cf96d8fec ("drm: Drop drm_framebuffer.h from drm_crtc.h")
    Fixes: 255490f9150d ("drm: Drop drm_edid.h from drm_crtc.h")
    Cc: Deepak Rawat <drawat.floss@gmail.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: linux-hyperv@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v5.14+
    Acked-by: Maxime Ripard <maxime@cerno.tech>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220622083413.12573-1-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/mcde: Fix refcount leak in mcde_dsi_bind [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 25 15:54:11 2022 +0400

    drm/mcde: Fix refcount leak in mcde_dsi_bind
    
    [ Upstream commit 3a149169e4a2f9127022fec6ef5d71b4e804b3b9 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    the reference counter of the previous node. There is no decrement
    when break out from the loop and results in refcount leak.
    Add missing of_node_put() to fix this.
    
    Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220525115411.65455-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mediatek: Add pull-down MIPI operation in mtk_dsi_poweroff function [+ + +]
Author: Xinlei Lee <xinlei.lee@mediatek.com>
Date:   Fri May 20 10:00:07 2022 +0800

    drm/mediatek: Add pull-down MIPI operation in mtk_dsi_poweroff function
    
    [ Upstream commit fa5d0a0205c34734c5b8daa77e39ac2817f63a10 ]
    
    In the dsi_enable function, mtk_dsi_rxtx_control is to
    pull up the MIPI signal operation. Before dsi_disable,
    MIPI should also be pulled down by writing a register
    instead of disabling dsi.
    
    If disable dsi without pulling the mipi signal low, the value of
    the register will still maintain the setting of the mipi signal being
    pulled high.
    After resume, even if the mipi signal is not pulled high, it will still
    be in the high state.
    
    Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
    
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-5-git-send-email-xinlei.lee@mediatek.com/
    Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Allow commands to be sent during video mode [+ + +]
Author: Julien STEPHAN <jstephan@baylibre.com>
Date:   Mon Feb 14 10:27:42 2022 +0100

    drm/mediatek: Allow commands to be sent during video mode
    
    [ Upstream commit 81cc7e51c4f1686b71e30046437056ece6b2cb4d ]
    
    Mipi dsi panel drivers can use mipi_dsi_dcs_{set,get}_display_brightness()
    to request backlight changes.
    
    This can be done during panel initialization (dsi is in command mode)
    or afterwards (dsi is in Video Mode).
    
    When the DSI is in Video Mode, all commands are rejected.
    
    Detect current DSI mode in mtk_dsi_host_transfer() and switch modes
    temporarily to allow commands to be sent.
    
    Signed-off-by: Julien STEPHAN <jstephan@baylibre.com>
    Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: dpi: Only enable dpi after the bridge is enabled [+ + +]
Author: Guillaume Ranquet <granquet@baylibre.com>
Date:   Fri Jul 1 11:58:44 2022 +0800

    drm/mediatek: dpi: Only enable dpi after the bridge is enabled
    
    [ Upstream commit aed61ef6beb911cc043af0f2f291167663995065 ]
    
    Enabling the dpi too early causes glitches on screen.
    
    Move the call to mtk_dpi_enable() at the end of the bridge_enable
    callback to ensure everything is setup properly before enabling dpi.
    
    Fixes: 9e629c17aa8d ("drm/mediatek: Add DPI sub driver")
    Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
    Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
    Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220701035845.16458-16-rex-bc.chen@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: dpi: Remove output format of YUV [+ + +]
Author: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Date:   Fri Jul 1 11:58:33 2022 +0800

    drm/mediatek: dpi: Remove output format of YUV
    
    [ Upstream commit c9ed0713b3c35fc45677707ba47f432cad95da56 ]
    
    DPI is not support output format as YUV, but there is the setting of
    configuring output YUV. Therefore, remove them in this patch.
    
    Fixes: 9e629c17aa8d ("drm/mediatek: Add DPI sub driver")
    Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220701035845.16458-5-rex-bc.chen@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Keep dsi as LP00 before dcs cmds transfer [+ + +]
Author: Jitao Shi <jitao.shi@mediatek.com>
Date:   Fri May 20 10:00:06 2022 +0800

    drm/mediatek: Keep dsi as LP00 before dcs cmds transfer
    
    [ Upstream commit 39e8d062b03c3dc257d880d82bd55cdd9e185a3b ]
    
    To comply with the panel sequence, hold the mipi signal to LP00 before
    the dcs cmds transmission, and pull the mipi signal high from LP00 to
    LP11 until the start of the dcs cmds transmission.
    
    The normal panel timing is :
    (1) pp1800 DC pull up
    (2) avdd & avee AC pull high
    (3) lcm_reset pull high -> pull low -> pull high
    (4) Pull MIPI signal high (LP11) -> initial code -> send video data
        (HS mode)
    
    The power-off sequence is reversed.
    If dsi is not in cmd mode, then dsi will pull the mipi signal high in
    the mtk_output_dsi_enable function. The delay in lane_ready func is
    the reaction time of dsi_rx after pulling up the mipi signal.
    
    Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API")
    
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-4-git-send-email-xinlei.lee@mediatek.com/
    Cc: <stable@vger.kernel.org> # 5.10.x: 7f6335c6a258: drm/mediatek: Modify dsi funcs to atomic operations
    Cc: <stable@vger.kernel.org> # 5.10.x: cde7e2e35c28: drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs
    Cc: <stable@vger.kernel.org> # 5.10.x
    Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Modify dsi funcs to atomic operations [+ + +]
Author: Xinlei Lee <xinlei.lee@mediatek.com>
Date:   Fri May 20 10:00:04 2022 +0800

    drm/mediatek: Modify dsi funcs to atomic operations
    
    [ Upstream commit 7f6335c6a258edf4d5ff1b904bc033188dc7b48b ]
    
    Because .enable & .disable are deprecated.
    Use .atomic_enable & .atomic_disable instead.
    
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-2-git-send-email-xinlei.lee@mediatek.com/
    Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs [+ + +]
Author: Jitao Shi <jitao.shi@mediatek.com>
Date:   Fri May 20 10:00:05 2022 +0800

    drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs
    
    [ Upstream commit cde7e2e35c2866d22a3a012e72a41052dfcc255d ]
    
    In order to match the changes of "Use the drm_panel_bridge API",
    the poweron/poweroff of dsi is extracted from enable/disable and
    defined as new funcs (atomic_pre_enable/atomic_post_disable).
    
    Since dsi_poweron is moved from dsi_enable to pre_enable function, in
    order to avoid poweron failure, the operation of dsi register fails to
    cause bus hang. Therefore, the protection mechanism is added to the
    dsi_enable function.
    
    Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API")
    
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-3-git-send-email-xinlei.lee@mediatek.com/
    Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 07:39:27 2022 +0400

    drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init
    
    [ Upstream commit d82a5a4aae9d0203234737caed1bf470aa317568 ]
    
    of_graph_get_remote_node() returns remote device nodepointer with
    refcount incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: e67f6037ae1b ("drm/meson: split out encoder from meson_dw_hdmi")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220601033927.47814-3-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR [+ + +]
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Wed Oct 20 14:39:45 2021 +0200

    drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR
    
    [ Upstream commit 0af5e0b41110e2da872030395231ab19c45be931 ]
    
    This implements the necessary change to no more use the embedded
    connector in dw-hdmi and use the dedicated bridge connector driver
    by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call.
    
    The necessary connector properties are added to handle the same
    functionalities as the embedded dw-hdmi connector, i.e. the HDR
    metadata, the CEC notifier & other flags.
    
    The dw-hdmi output_port is set to 1 in order to look for a connector
    next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
    
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211020123947.2585572-5-narmstrong@baylibre.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/meson: Fix refcount leak in meson_encoder_hdmi_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 09:40:51 2022 +0400

    drm/meson: Fix refcount leak in meson_encoder_hdmi_init
    
    commit 7381076809586528e2a812a709e2758916318a99 upstream.
    
    of_find_device_by_node() takes reference, we should use put_device()
    to release it when not need anymore.
    Add missing put_device() in error path to avoid refcount
    leak.
    
    Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220511054052.51981-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/mipi-dbi: align max_chunk to 2 in spi_transfer [+ + +]
Author: Yunhao Tian <t123yh.xyz@gmail.com>
Date:   Tue May 10 11:02:19 2022 +0800

    drm/mipi-dbi: align max_chunk to 2 in spi_transfer
    
    [ Upstream commit 435c249008cba04ed6a7975e9411f3b934620204 ]
    
    In __spi_validate, there's a validation that no partial transfers
    are accepted (xfer->len % w_size must be zero). When
    max_chunk is not a multiple of bpw (e.g. max_chunk = 65535,
    bpw = 16), the transfer will be rejected.
    
    This patch aligns max_chunk to 2 bytes (the maximum value of bpw is 16),
    so that no partial transfer will occur.
    
    Fixes: d23d4d4dac01 ("drm/tinydrm: Move tinydrm_spi_transfer()")
    
    Signed-off-by: Yunhao Tian <t123yh.xyz@gmail.com>
    Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220510030219.2486687-1-t123yh.xyz@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: Fix for non-visible planes [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Thu Jul 7 14:20:00 2022 -0700

    drm/msm/dpu: Fix for non-visible planes
    
    [ Upstream commit cb77085b1f0a86ef9dfba86b5f3ed6c3340c2ea3 ]
    
    Fixes `kms_cursor_crc --run-subtest cursor-offscreen`.. when the cursor
    moves offscreen the plane becomes non-visible, so we need to skip over
    it in crtc atomic test and mixer setup.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/492819/
    Link: https://lore.kernel.org/r/20220707212003.1710163-1-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/mdp5: Fix global state lock backoff [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Thu Jul 7 09:20:37 2022 -0700

    drm/msm/mdp5: Fix global state lock backoff
    
    [ Upstream commit 92ef86ab513593c6329d04146e61f9a670e72fc5 ]
    
    We need to grab the lock after the early return for !hwpipe case.
    Otherwise, we could have hit contention yet still returned 0.
    
    Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged
    in CI:
    
       WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154
       Modules linked in:
       CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G        W         5.19.0-rc2-15930-g875cc8bc536a #1
       Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
       pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
       pc : drm_modeset_lock+0xf8/0x154
       lr : drm_atomic_get_private_obj_state+0x84/0x170
       sp : ffff80000cfab6a0
       x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00
       x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58
       x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001
       x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038
       x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0
       x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47
       x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610
       x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000
       x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029
       x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58
       Call trace:
        drm_modeset_lock+0xf8/0x154
        drm_atomic_get_private_obj_state+0x84/0x170
        mdp5_get_global_state+0x54/0x6c
        mdp5_pipe_release+0x2c/0xd4
        mdp5_plane_atomic_check+0x2ec/0x414
        drm_atomic_helper_check_planes+0xd8/0x210
        drm_atomic_helper_check+0x54/0xb0
        ...
       ---[ end trace 0000000000000000 ]---
       drm_modeset_lock attempting to lock a contended lock without backoff:
          drm_modeset_lock+0x148/0x154
          mdp5_get_global_state+0x30/0x6c
          mdp5_pipe_release+0x2c/0xd4
          mdp5_plane_atomic_check+0x290/0x414
          drm_atomic_helper_check_planes+0xd8/0x210
          drm_atomic_helper_check+0x54/0xb0
          drm_atomic_check_only+0x4b0/0x8f4
          drm_atomic_commit+0x68/0xe0
    
    Fixes: d59be579fa93 ("drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/492701/
    Link: https://lore.kernel.org/r/20220707162040.1594855-1-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm: Avoid dirtyfb stalls on video mode displays (v2) [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Feb 23 11:11:08 2022 -0800

    drm/msm: Avoid dirtyfb stalls on video mode displays (v2)
    
    [ Upstream commit 9e4dde28e9cd34ee13a6b7247f0857fb49fd3f19 ]
    
    Someone on IRC once asked an innocent enough sounding question:  Why
    with xf86-video-modesetting is es2gears limited at 120fps.
    
    So I broke out the perfetto tracing mesa MR and took a look.  It turns
    out the problem was drm_atomic_helper_dirtyfb(), which would end up
    waiting for vblank.. es2gears would rapidly push two frames to Xorg,
    which would blit them to screen and in idle hook (I assume) call the
    DIRTYFB ioctl.  Which in turn would do an atomic update to flush the
    dirty rects, which would stall until the next vblank.  And then the
    whole process would repeat.
    
    But this is a bit silly, we only need dirtyfb for command mode DSI
    panels.  So track in plane state whether dirtyfb is required, and
    track in the fb how many attached planes require dirtyfb so that we
    can skip it when not required.  (Note, mdp4 does not actually have
    cmd mode support.)
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20220223191118.881321-1-robdclark@gmail.com
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm: Fix dirtyfb refcounting [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Fri Mar 4 12:21:45 2022 -0800

    drm/msm: Fix dirtyfb refcounting
    
    commit 9225b337072a10bf9b09df8bf281437488dd8a26 upstream.
    
    refcount_t complains about 0->1 transitions, which isn't *quite* what we
    wanted.  So use dirtyfb==1 to mean that the fb is not connected to any
    output that requires dirtyfb flushing, so that we can keep the underflow
    and overflow checking.
    
    Fixes: 9e4dde28e9cd ("drm/msm: Avoid dirtyfb stalls on video mode displays (v2)")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Link: https://lore.kernel.org/r/20220304202146.845566-1-robdclark@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from pm_runtime [+ + +]
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Jul 14 13:42:33 2022 -0400

    drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from pm_runtime
    
    commit 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 upstream.
    
    Since this isn't actually a failure.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: David Airlie <airlied@linux.ie>
    Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early")
    Cc: <stable@vger.kernel.org> # v4.19+
    Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-2-lyude@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/nouveau/kms: Fix failure path for creating DP connectors [+ + +]
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu May 26 16:43:13 2022 -0400

    drm/nouveau/kms: Fix failure path for creating DP connectors
    
    commit ca0367ca5d9216644b41f86348d6661f8d9e32d8 upstream.
    
    It looks like that when we moved nouveau over to using drm_dp_aux_init()
    and registering it's aux bus during late connector registration, we totally
    forgot to fix the failure codepath in nouveau_connector_create() - as it
    still seems to assume that drm_dp_aux_init() can fail (it can't).
    
    So, let's fix that and also add a missing check to ensure that we've
    properly allocated nv_connector->aux.name while we're at it.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: David Airlie <airlied@linux.ie>
    Fixes: fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister")
    Cc: <stable@vger.kernel.org> # v5.14+
    Link: https://patchwork.freedesktop.org/patch/msgid/20220526204313.656473-1-lyude@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/nouveau: Don't pm_runtime_put_sync(), only pm_runtime_put_autosuspend() [+ + +]
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Jul 14 13:42:34 2022 -0400

    drm/nouveau: Don't pm_runtime_put_sync(), only pm_runtime_put_autosuspend()
    
    commit c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 upstream.
    
    While trying to fix another issue, it occurred to me that I don't actually
    think there is any situation where we want pm_runtime_put() in nouveau to
    be synchronous. In fact, this kind of just seems like it would cause
    issues where we may unexpectedly block a thread we don't expect to be
    blocked.
    
    So, let's only use pm_runtime_put_autosuspend().
    
    Changes since v1:
    * Use pm_runtime_put_autosuspend(), not pm_runtime_put()
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: David Airlie <airlied@linux.ie>
    Fixes: 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: <stable@vger.kernel.org> # v4.10+
    Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-3-lyude@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/nouveau: fix another off-by-one in nvbios_addr [+ + +]
Author: Timur Tabi <ttabi@nvidia.com>
Date:   Wed May 11 11:37:16 2022 -0500

    drm/nouveau: fix another off-by-one in nvbios_addr
    
    commit c441d28945fb113220d48d6c86ebc0b090a2b677 upstream.
    
    This check determines whether a given address is part of
    image 0 or image 1.  Image 1 starts at offset image0_size,
    so that address should be included.
    
    Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image")
    Cc: <stable@vger.kernel.org> # v4.8+
    Signed-off-by: Timur Tabi <ttabi@nvidia.com>
    Reviewed-by: Karol Herbst <kherbst@redhat.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220511163716.3520591-1-ttabi@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/panel: Fix build error when CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m [+ + +]
Author: Gao Chao <gaochao49@huawei.com>
Date:   Tue May 24 10:45:51 2022 +0800

    drm/panel: Fix build error when CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m
    
    [ Upstream commit a67664860f7833015a683ea295f7c79ac2901332 ]
    
    If CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m,
    bulding fails:
    
    drivers/gpu/drm/panel/panel-samsung-atna33xc20.o: In function `atana33xc20_probe':
    panel-samsung-atna33xc20.c:(.text+0x744): undefined reference to
     `drm_panel_dp_aux_backlight'
    make: *** [vmlinux] Error 1
    
    Let CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20 select DRM_DISPLAY_DP_HELPER and
    CONFIG_DRM_DISPLAY_HELPER to fix this error.
    
    Fixes: 32ce3b320343 ("drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panel")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Gao Chao <gaochao49@huawei.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220524024551.539-1-gaochao49@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: fix incorrrect SPDX-License-Identifiers [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Jun 15 12:02:08 2022 -0400

    drm/radeon: fix incorrrect SPDX-License-Identifiers
    
    [ Upstream commit 1f43b8903f3aae4a26a603c36f6d5dd25d6edb51 ]
    
    radeon is MIT.  This were incorrectly changed in
    commit b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license")
    and
    commit d198b34f3855 (".gitignore: add SPDX License Identifier")
    and:
    commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")
    
    Fixes: d198b34f3855 (".gitignore: add SPDX License Identifier")
    Fixes: ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")
    Fixes: b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2053
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() [+ + +]
Author: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Date:   Mon Jun 6 16:50:54 2022 +0300

    drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()
    
    [ Upstream commit 136f614931a2bb73616b292cf542da3a18daefd5 ]
    
    The last case label can write two buffers 'mc_reg_address[j]' and
    'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE
    since there are no checks for this value in both case labels after the
    last 'j++'.
    
    Instead of changing '>' to '>=' there, add the bounds check at the start
    of the second 'case' (the first one already has it).
    
    Also, remove redundant last checks for 'j' index bigger than array size.
    The expression is always false. Moreover, before or after the patch
    'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it
    seems it can be a valid value.
    
    Detected using the static analysis tool - Svace.
    Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)")
    Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: Fix an error handling path rockchip_dp_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 18 19:08:05 2022 +0200

    drm/rockchip: Fix an error handling path rockchip_dp_probe()
    
    [ Upstream commit 5074376822fe99fa4ce344b851c5016d00c0444f ]
    
    Should component_add() fail, we should call analogix_dp_remove() in the
    error handling path, as already done in the remove function.
    
    Fixes: 152cce0006ab ("drm/bridge: analogix_dp: Split bind() into probe() and real bind()")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/b719d9061bb97eb85145fbd3c5e63f4549f2e13e.1655572071.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop: Don't crash for invalid duplicate_state() [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Jun 17 17:26:52 2022 -0700

    drm/rockchip: vop: Don't crash for invalid duplicate_state()
    
    [ Upstream commit 1449110b0dade8b638d2c17ab7c5b0ff696bfccb ]
    
    It's possible for users to try to duplicate the CRTC state even when the
    state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
    users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
    with a WARN_ON() instead of crashing, so let's do that here too.
    
    Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220617172623.1.I62db228170b1559ada60b8d3e1637e1688424926@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/shmem-helper: Add missing vunmap on error [+ + +]
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Thu Jun 30 23:00:57 2022 +0300

    drm/shmem-helper: Add missing vunmap on error
    
    commit df4aaf015775221dde8a51ee09edb919981f091e upstream.
    
    The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM
    mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM
    before erroring out.
    
    Cc: stable@vger.kernel.org
    Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends")
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220630200058.1883506-2-dmitry.osipenko@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/shmem-helper: Export dedicated wrappers for GEM object functions [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Mon Nov 8 10:31:48 2021 +0100

    drm/shmem-helper: Export dedicated wrappers for GEM object functions
    
    [ Upstream commit c7fbcb7149ff9321bbbcc93c9920de534ea8102c ]
    
    Wrap GEM SHMEM functions for struct drm_gem_object_funcs and update
    all callers. This will allow for an update of the public interfaces
    of the GEM SHMEM helper library.
    
    v2:
            * fix docs for drm_gem_shmem_object_print_info()
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211108093149.7226-3-tzimmermann@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/shmem-helper: Pass GEM shmem object in public interfaces [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Mon Nov 8 10:31:49 2021 +0100

    drm/shmem-helper: Pass GEM shmem object in public interfaces
    
    [ Upstream commit a193f3b4e050e35c506a34d0870c838d8e0b0449 ]
    
    Change all GEM SHMEM object functions that receive a GEM object
    of type struct drm_gem_object to expect an object of type
    struct drm_gem_shmem_object instead.
    
    This change reduces the number of upcasts from struct drm_gem_object
    by moving them into callers. The C compiler can now verify that the
    GEM SHMEM functions are called with the correct type.
    
    For consistency, the patch also renames drm_gem_shmem_free_object to
    drm_gem_shmem_free. It further updates documentation for a number of
    functions.
    
    v3:
            * fix docs for drm_gem_shmem_object_free()
    v2:
            * mention _object_ callbacks in docs (Daniel)
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211108093149.7226-4-tzimmermann@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/shmem-helper: Unexport drm_gem_shmem_create_with_handle() [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Mon Nov 8 10:31:47 2021 +0100

    drm/shmem-helper: Unexport drm_gem_shmem_create_with_handle()
    
    [ Upstream commit 5a363c20673308e968b6640deb73d7bf77e8b463 ]
    
    Turn drm_gem_shmem_create_with_handle() into an internal helper
    function. It's not used outside of the compilation unit.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211108093149.7226-2-tzimmermann@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/st7735r: Fix module autoloading for Okaya RH128128T [+ + +]
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Fri May 20 11:16:02 2022 +0200

    drm/st7735r: Fix module autoloading for Okaya RH128128T
    
    [ Upstream commit 9ad6f181ad9a19a26bda73a7b199df44ccfcdaba ]
    
    The SPI core always reports a "MODALIAS=spi:<foo>", even if the device was
    registered via OF. This means that the st7735r.ko module won't autoload if
    a DT has a node with a compatible "okaya,rh128128t" string.
    
    In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but
    instead will get a "MODALIAS=spi:rh128128t", which is not present in the
    list of aliases:
    
      $ modinfo drivers/gpu/drm/tiny/st7735r.ko | grep alias
      alias:          of:N*T*Cokaya,rh128128tC*
      alias:          of:N*T*Cokaya,rh128128t
      alias:          of:N*T*Cjianda,jd-t18003-t01C*
      alias:          of:N*T*Cjianda,jd-t18003-t01
      alias:          spi:jd-t18003-t01
    
    To workaround this issue, add in the SPI table an entry for that device.
    
    Fixes: d1d511d516f7 ("drm: tiny: st7735r: Add support for Okaya RH128128T")
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: David Lechner <david@lechnology.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220520091602.179078-1-javierm@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vc4: change vc4_dma_range_matches from a global to static [+ + +]
Author: Tom Rix <trix@redhat.com>
Date:   Wed Jun 29 16:01:01 2022 -0400

    drm/vc4: change vc4_dma_range_matches from a global to static
    
    commit 63569d90863ff26c8b10c8971d1271c17a45224b upstream.
    
    sparse reports
    drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches' was not declared. Should it be static?
    
    vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier
    should be static.
    
    Fixes: da8e393e23ef ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220629200101.498138-1-trix@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:28 2022 +0200

    drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component
    
    [ Upstream commit da8e393e23efb60eba8959856c7df88f9859f6eb ]
    
    vc4_drv isn't necessarily under the /soc node in DT as it is a
    virtual device, but it is the one that does the allocations.
    The DMA addresses are consumed by primarily the HVS or V3D, and
    those require VideoCore cache alias address mapping, and so will be
    under /soc.
    
    During probe find the a suitable device node for HVS or V3D,
    and adopt the DMA configuration of that node.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-2-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iteration [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:43 2022 +0200

    drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iteration
    
    [ Upstream commit 7bcb9c8d0bc9f3cab8ac2634b056c2e6b63945ca ]
    
    vc4_dsi_encoder_disable is partially an open coded version of
    drm_bridge_chain_disable, but it missed a termination condition
    in the loop for ->disable which meant that no post_disable
    calls were made.
    
    Add in the termination clause.
    
    Fixes: 033bfe7538a1 ("drm/vc4: dsi: Fix bridge chain handling")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-17-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Correct DSI divider calculations [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:39 2022 +0200

    drm/vc4: dsi: Correct DSI divider calculations
    
    [ Upstream commit 3b45eee87da171caa28f61240ddb5c21170cda53 ]
    
    The divider calculations tried to find the divider just faster than the
    clock requested. However if it required a divider of 7 then the for loop
    aborted without handling the "error" case, and could end up with a clock
    lower than requested.
    
    The integer divider from parent PLL to DSI clock is also capable of
    going up to /255, not just /7 that the driver was trying.  This allows
    for slower link frequencies on the DSI bus where the resolution permits.
    
    Correct the loop so that we always have a clock greater than requested,
    and covering the whole range of dividers.
    
    Fixes: 86c1b9eff3f2 ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-13-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Correct pixel order for DSI0 [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:40 2022 +0200

    drm/vc4: dsi: Correct pixel order for DSI0
    
    [ Upstream commit edfe84ae0df16be1251b5a8e840d95f1f3827500 ]
    
    For slightly unknown reasons, dsi0 takes a different pixel format
    to dsi1, and that has to be set in the pixel valve.
    
    Amend the setup accordingly.
    
    Fixes: a86773d120d7 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-14-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Fix dsi0 interrupt support [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:42 2022 +0200

    drm/vc4: dsi: Fix dsi0 interrupt support
    
    [ Upstream commit bc5b815e06f90cccdb6461aba1e49fdc2f3c8cd1 ]
    
    DSI0 seemingly had very little or no testing as a load of
    the register mappings were incorrect/missing, so host
    transfers always timed out due to enabling/checking incorrect
    bits in the interrupt enable and status registers.
    
    Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-16-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Register dsi0 as the correct vc4 encoder type [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:41 2022 +0200

    drm/vc4: dsi: Register dsi0 as the correct vc4 encoder type
    
    [ Upstream commit 4d9273c978d4c1af15d7874c10c732ec83d444d0 ]
    
    vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1
    which seemed to work OK for a single DSI display, but fails
    if there are two DSI displays connected.
    
    Update to register the correct type.
    
    Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-15-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Release workaround buffer and DMA [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:38 2022 +0200

    drm/vc4: dsi: Release workaround buffer and DMA
    
    [ Upstream commit 89c4bbe2a01ea401c2b0fabc104720809084b77f ]
    
    On Pi0-3 the driver allocates a buffer and requests a DMA channel
    because the ARM can't write to DSI1's registers directly.
    
    However, we never release that buffer or channel. Let's add a
    device-managed action to release each.
    
    Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-12-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: dsi: Switch to devm_drm_of_get_bridge [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Fri Sep 10 15:09:41 2021 +0200

    drm/vc4: dsi: Switch to devm_drm_of_get_bridge
    
    [ Upstream commit a43dd76bacd0d5441a4c84f60d64bdfaedc95bac ]
    
    The new devm_drm_of_get_bridge removes most of the boilerplate we
    have to deal with. Let's switch to it.
    
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210910130941.1740182-4-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: hdmi: Avoid full hdmi audio fifo writes [+ + +]
Author: Dom Cobley <popcornmix@gmail.com>
Date:   Mon Jun 13 16:47:47 2022 +0200

    drm/vc4: hdmi: Avoid full hdmi audio fifo writes
    
    [ Upstream commit 1c594eeccf92368177c2e22f1d3ee4933dfb8567 ]
    
    We are getting occasional VC4_HD_MAI_CTL_ERRORF in
    HDMI_MAI_CTL which seem to correspond with audio dropouts.
    
    Reduce the threshold where we deassert DREQ to avoid the fifo
    overfilling
    
    Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
    Signed-off-by: Dom Cobley <popcornmix@gmail.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:59 2022 +0200

    drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes
    
    [ Upstream commit fb10dc451c0f15e3c19798a2f41d357f3f7576f5 ]
    
    For interlaced modes the timings were not being correctly
    programmed into the HDMI block, so correct them.
    
    Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-33-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: hdmi: Disable audio if dmas property is present but empty [+ + +]
Author: Phil Elwell <phil@raspberrypi.org>
Date:   Mon Jun 13 16:47:44 2022 +0200

    drm/vc4: hdmi: Disable audio if dmas property is present but empty
    
    commit db2b927f8668adf3ac765e0921cd2720f5c04172 upstream.
    
    The dmas property is used to hold the dmaengine channel used for audio
    output.
    
    Older device trees were missing that property, so if it's not there we
    disable the audio output entirely.
    
    However, some overlays have set an empty value to that property, mostly
    to workaround the fact that overlays cannot remove a property. Let's add
    a test for that case and if it's empty, let's disable it as well.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Phil Elwell <phil@raspberrypi.org>
    Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/vc4: hdmi: Fix HPD GPIO detection [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Mon Oct 25 17:28:55 2021 +0200

    drm/vc4: hdmi: Fix HPD GPIO detection
    
    [ Upstream commit e32e5723256a99c5324824503572f743377dd0fe ]
    
    Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the
    detect hook, if we had an HPD GPIO we would only rely on it and return
    whatever state it was in.
    
    However, that commit changed that by mistake to only consider the case
    where we have a GPIO and it returns a logical high, and would fall back
    to the other methods otherwise.
    
    Since we can read the EDIDs when the HPD signal is low on some displays,
    we changed the detection status from disconnected to connected, and we
    would ignore an HPD pulse.
    
    Fixes: 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod")
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20211025152903.1088803-3-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: hdmi: Fix timings for interlaced modes [+ + +]
Author: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Date:   Mon Jun 13 16:47:57 2022 +0200

    drm/vc4: hdmi: Fix timings for interlaced modes
    
    [ Upstream commit 0ee5a40152b15f200ed3a0d51e8aa782ea979c6a ]
    
    Increase the number of post-sync blanking lines on odd fields instead of
    decreasing it on even fields. This makes the total number of lines
    properly match the modelines.
    
    Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take
    pixels_per_clock into account, causing some displays to invert the
    fields when driven by bcm2711.
    
    Fixes: 682e62c45406 ("drm/vc4: Fix support for interlaced modes on HDMI.")
    Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: hdmi: Reset HDMI MISC_CONTROL register [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:48 2022 +0200

    drm/vc4: hdmi: Reset HDMI MISC_CONTROL register
    
    [ Upstream commit 35dc00c12a72700a9c4592afee7d136ecb280cbd ]
    
    The HDMI block can repeat pixels for double clocked modes,
    and the firmware is now configuring the block to do this as
    the PV is doing it incorrectly when at 2pixels/clock.
    If the kernel doesn't reset it then we end up with strange
    modes.
    
    Reset MISC_CONTROL.
    
    Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: plane: Fix margin calculations for the right/bottom edges [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Jun 13 16:47:32 2022 +0200

    drm/vc4: plane: Fix margin calculations for the right/bottom edges
    
    [ Upstream commit b7c3d6821627861f4ea3e1f2b595d0ed9e80aac8 ]
    
    The current plane margin calculation code clips the right and bottom
    edges of the range based using the left and top margins.
    
    This is obviously wrong, so let's fix it.
    
    Fixes: 666e73587f90 ("drm/vc4: Take margin setup into account when updating planes")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-6-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: plane: Remove subpixel positioning check [+ + +]
Author: Dom Cobley <popcornmix@gmail.com>
Date:   Mon Jun 13 16:47:31 2022 +0200

    drm/vc4: plane: Remove subpixel positioning check
    
    [ Upstream commit 517db1ab1566dba3093dbdb8de4263ba4aa66416 ]
    
    There is little harm in ignoring fractional coordinates
    (they just get truncated).
    
    Without this:
    modetest -M vc4 -F tiles,gradient -s 32:1920x1080-60 -P89@74:1920x1080*.1.1@XR24
    
    is rejected. We have the same issue in Kodi when trying to
    use zoom options on video.
    
    Note: even if all coordinates are fully integer. e.g.
    src:[0,0,1920,1080] dest:[-10,-10,1940,1100]
    
    it will still get rejected as drm_atomic_helper_check_plane_state
    uses drm_rect_clip_scaled which transforms this to fractional src coords
    
    Fixes: 21af94cf1a4c ("drm/vc4: Add support for scaling of display planes.")
    Signed-off-by: Dom Cobley <popcornmix@gmail.com>
    Link: https://lore.kernel.org/r/20220613144800.326124-5-maxime@cerno.tech
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: Use of_device_get_match_data() [+ + +]
Author: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn>
Date:   Mon Feb 14 02:05:30 2022 +0000

    drm/vc4: Use of_device_get_match_data()
    
    [ Upstream commit 9cbe89ede58294d23af06ec12c20f2ce6acc1892 ]
    
    Use of_device_get_match_data() to simplify the code.
    
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220214020530.1714631-1-chi.minghao@zte.com.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Jun 2 14:42:22 2022 +0400

    drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init
    
    [ Upstream commit c24968734abfed81c8f93dc5f44a7b7a9aecadfa ]
    
    Since drm_prime_pages_to_sg() function return error pointers.
    The drm_gem_shmem_get_sg_table() function returns error pointers too.
    Using IS_ERR() to check the return value to fix this.
    
    Fixes: 2f2aa13724d5 ("drm/virtio: move virtio_gpu_mem_entry initialization to new function")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20220602104223.54527-1-linmq006@gmail.com
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: adv7511: override i2c address of cec before accessing it [+ + +]
Author: Antonio Borneo <antonio.borneo@foss.st.com>
Date:   Tue Jun 7 23:31:44 2022 +0200

    drm: adv7511: override i2c address of cec before accessing it
    
    [ Upstream commit 9cc4853e4781bf0dd0f35355dc92d97c9da02f5d ]
    
    Commit 680532c50bca ("drm: adv7511: Add support for
    i2c_new_secondary_device") allows a device tree node to override
    the default addresses of the secondary i2c devices. This is useful
    for solving address conflicts on the i2c bus.
    
    In adv7511_init_cec_regmap() the new i2c address of cec device is
    read from device tree and immediately accessed, well before it is
    written in the proper register to override the default address.
    This can cause an i2c error during probe and a consequent probe
    failure.
    
    Once the new i2c address is read from the device tree, override
    the default address before any attempt to access the cec.
    
    Tested with adv7533 and stm32mp157f.
    
    Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
    Fixes: 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device")
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220607213144.427177-1-antonio.borneo@foss.st.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: adv7511: Add check for mipi_dsi_driver_register [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Jun 2 18:34:01 2022 +0800

    drm: bridge: adv7511: Add check for mipi_dsi_driver_register
    
    [ Upstream commit 831463667b5f4f1e5bce9c3b94e9e794d2bc8923 ]
    
    As mipi_dsi_driver_register could return error if fails,
    it should be better to check the return value and return error
    if fails.
    Moreover, if i2c_add_driver fails,  mipi_dsi_driver_register
    should be reverted.
    
    Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220602103401.2980938-1-jiasheng@iscas.ac.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: sii8620: fix possible off-by-one [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Wed May 18 14:58:56 2022 +0800

    drm: bridge: sii8620: fix possible off-by-one
    
    [ Upstream commit 21779cc21c732c5eff8ea1624be6590450baa30f ]
    
    The next call to sii8620_burst_get_tx_buf will result in off-by-one
    When ctx->burst.tx_count + size == ARRAY_SIZE(ctx->burst.tx_buf). The same
    thing happens in sii8620_burst_get_rx_buf.
    
    This patch also change tx_count and tx_buf to rx_count and rx_buf in
    sii8620_burst_get_rx_buf. It is unreasonable to check tx_buf's size and
    use rx_buf.
    
    Fixes: e19e9c692f81 ("drm/bridge/sii8620: add support for burst eMSC transmissions")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220518065856.18936-1-hbh25y@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: iio: accel: Add DT binding doc for ADXL355 [+ + +]
Author: Puranjay Mohan <puranjay12@gmail.com>
Date:   Wed Aug 11 13:00:26 2021 +0530

    dt-bindings: iio: accel: Add DT binding doc for ADXL355
    
    [ Upstream commit bf43a71a0a7f396434f6460b46e33eb00752f78d ]
    
    Add devicetree binding document for ADXL355, a 3-Axis MEMS Accelerometer.
    
    Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20210811073027.124619-2-puranjay12@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: riscv: fix SiFive l2-cache's cache-sets [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Wed Aug 3 19:54:00 2022 +0100

    dt-bindings: riscv: fix SiFive l2-cache's cache-sets
    
    commit b60cf8e59e61133b6c9514ff8d8c8d7049d040ef upstream.
    
    Fix device tree schema validation error messages for the SiFive
    Unmatched: ' cache-sets:0:0: 1024 was expected'.
    
    The existing bindings allow for just 1024 cache-sets but the fu740 on
    Unmatched the has 2048 cache-sets. The ISA itself permits any arbitrary
    power of two, however this is not supported by dt-schema. The RTL for
    the IP, to which the number of cache-sets is a tunable parameter, has
    been released publicly so speculatively adding a small number of
    "reasonable" values seems unwise also.
    
    Instead, as the binding only supports two distinct controllers: add 2048
    and explicitly lock it to the fu740's l2 cache while limiting 1024 to
    the l2 cache on the fu540.
    
    Fixes: af951c3a113b ("dt-bindings: riscv: Update l2 cache DT documentation to add support for SiFive FU740")
    Reported-by: Atul Khare <atulkhare@rivosinc.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220803185359.942928-1-mail@conchuod.ie
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
eeprom: idt_89hpesx: uninitialized data in idt_dbgfs_csr_write() [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 8 16:46:38 2022 +0300

    eeprom: idt_89hpesx: uninitialized data in idt_dbgfs_csr_write()
    
    [ Upstream commit 71d46f1ff2212ced4852c7e77c5176382a1bdcec ]
    
    The simple_write_to_buffer() function will return positive/success if it
    is able to write a single byte anywhere within the buffer.  However that
    potentially leaves a lot of the buffer uninitialized.
    
    In this code it's better to return 0 if the offset is non-zero.  This
    code is not written to support partial writes.  And then return -EFAULT
    if the buffer is not completely initialized.
    
    Fixes: cfad6425382e ("eeprom: Add IDT 89HPESx EEPROM/CSR driver")
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/Ysg1Pu/nzSMe3r1q@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
epoll: autoremove wakers even more aggressively [+ + +]
Author: Benjamin Segall <bsegall@google.com>
Date:   Wed Jun 15 14:24:23 2022 -0700

    epoll: autoremove wakers even more aggressively
    
    commit a16ceb13961068f7209e34d7984f8e42d2c06159 upstream.
    
    If a process is killed or otherwise exits while having active network
    connections and many threads waiting on epoll_wait, the threads will all
    be woken immediately, but not removed from ep->wq.  Then when network
    traffic scans ep->wq in wake_up, every wakeup attempt will fail, and will
    not remove the entries from the list.
    
    This means that the cost of the wakeup attempt is far higher than usual,
    does not decrease, and this also competes with the dying threads trying to
    actually make progress and remove themselves from the wq.
    
    Handle this by removing visited epoll wq entries unconditionally, rather
    than only when the wakeup succeeds - the structure of ep_poll means that
    the only potential loss is the timed_out->eavail heuristic, which now can
    race and result in a redundant ep_send_events attempt.  (But only when
    incoming data and a timeout actually race, not on every timeout)
    
    Shakeel added:
    
    : We are seeing this issue in production with real workloads and it has
    : caused hard lockups.  Particularly network heavy workloads with a lot
    : of threads in epoll_wait() can easily trigger this issue if they get
    : killed (oom-killed in our case).
    
    Link: https://lkml.kernel.org/r/xm26fsjotqda.fsf@google.com
    Signed-off-by: Ben Segall <bsegall@google.com>
    Tested-by: Shakeel Butt <shakeelb@google.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Roman Penyaev <rpenyaev@suse.de>
    Cc: Jason Baron <jbaron@akamai.com>
    Cc: Khazhismel Kumykov <khazhy@google.com>
    Cc: Heiher <r@hev.cc>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
erofs: avoid consecutive detection for Highmem memory [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Fri Jul 8 18:10:01 2022 +0800

    erofs: avoid consecutive detection for Highmem memory
    
    [ Upstream commit 448b5a1548d87c246c3d0c3df8480d3c6eb6c11a ]
    
    Currently, vmap()s are avoided if physical addresses are
    consecutive for decompressed buffers.
    
    I observed that is very common for 4KiB pclusters since the
    numbers of decompressed pages are almost 2 or 3.
    
    However, such detection doesn't work for Highmem pages on
    32-bit machines, let's fix it now.
    
    Reported-by: Liu Jinbao <liujinbao1@xiaomi.com>
    Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
    Link: https://lore.kernel.org/r/20220708101001.21242-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext2: Add more validity checks for inode counts [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 26 13:13:50 2022 +0200

    ext2: Add more validity checks for inode counts
    
    [ Upstream commit fa78f336937240d1bc598db817d638086060e7e9 ]
    
    Add checks verifying number of inodes stored in the superblock matches
    the number computed from number of inodes per group. Also verify we have
    at least one block worth of inodes per group. This prevents crashes on
    corrupted filesystems.
    
    Reported-by: syzbot+d273f7d7f58afd93be48@syzkaller.appspotmail.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jun 16 10:13:55 2022 +0800

    ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h
    
    [ Upstream commit 179b14152dcb6a24c3415200603aebca70ff13af ]
    
    When adding an xattr to an inode, we must ensure that the inode_size is
    not less than EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. Otherwise,
    the end position may be greater than the start position, resulting in UAF.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220616021358.2504451-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: check if directory block is within i_size [+ + +]
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Mon Jul 4 16:27:20 2022 +0200

    ext4: check if directory block is within i_size
    
    [ Upstream commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233 ]
    
    Currently ext4 directory handling code implicitly assumes that the
    directory blocks are always within the i_size. In fact ext4_append()
    will attempt to allocate next directory block based solely on i_size and
    the i_size is then appropriately increased after a successful
    allocation.
    
    However, for this to work it requires i_size to be correct. If, for any
    reason, the directory inode i_size is corrupted in a way that the
    directory tree refers to a valid directory block past i_size, we could
    end up corrupting parts of the directory tree structure by overwriting
    already used directory blocks when modifying the directory.
    
    Fix it by catching the corruption early in __ext4_read_dirblock().
    
    Addresses Red-Hat-Bugzilla: #2070205
    CVE: CVE-2022-1184
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20220704142721.157985-1-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: correct max_inline_xattr_value_size computing [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jun 16 10:13:57 2022 +0800

    ext4: correct max_inline_xattr_value_size computing
    
    [ Upstream commit c9fd167d57133c5b748d16913c4eabc55e531c73 ]
    
    If the ext4 inode does not have xattr space, 0 is returned in the
    get_max_inline_xattr_value_size function. Otherwise, the function returns
    a negative value when the inode does not contain EXT4_STATE_XATTR.
    
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220616021358.2504451-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: correct the misjudgment in ext4_iget_extra_inode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jun 16 10:13:58 2022 +0800

    ext4: correct the misjudgment in ext4_iget_extra_inode
    
    [ Upstream commit fd7e672ea98b95b9d4c9dae316639f03c16a749d ]
    
    Use the EXT4_INODE_HAS_XATTR_SPACE macro to more accurately
    determine whether the inode have xattr space.
    
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220616021358.2504451-5-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix extent status tree race in writeback error recovery path [+ + +]
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Wed Jun 15 12:05:30 2022 -0400

    ext4: fix extent status tree race in writeback error recovery path
    
    [ Upstream commit 7f0d8e1d607c1a4fa9a27362a108921d82230874 ]
    
    A race can occur in the unlikely event ext4 is unable to allocate a
    physical cluster for a delayed allocation in a bigalloc file system
    during writeback.  Failure to allocate a cluster forces error recovery
    that includes a call to mpage_release_unused_pages().  That function
    removes any corresponding delayed allocated blocks from the extent
    status tree.  If a new delayed write is in progress on the same cluster
    simultaneously, resulting in the addition of an new extent containing
    one or more blocks in that cluster to the extent status tree, delayed
    block accounting can be thrown off if that delayed write then encounters
    a similar cluster allocation failure during future writeback.
    
    Write lock the i_data_sem in mpage_release_unused_pages() to fix this
    problem.  Ext4's block/cluster accounting code for bigalloc relies on
    i_data_sem for mutual exclusion, as is found in the delayed write path,
    and the locking in mpage_release_unused_pages() is missing.
    
    Cc: stable@kernel.org
    Reported-by: Ye Bin <yebin10@huawei.com>
    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Link: https://lore.kernel.org/r/20220615160530.1928801-1-enwlinux@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix race when reusing xattr blocks [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:24 2022 +0200

    ext4: fix race when reusing xattr blocks
    
    [ Upstream commit 65f8b80053a1b2fd602daa6814e62d6fa90e5e9b ]
    
    When ext4_xattr_block_set() decides to remove xattr block the following
    race can happen:
    
    CPU1                                    CPU2
    ext4_xattr_block_set()                  ext4_xattr_release_block()
      new_bh = ext4_xattr_block_cache_find()
    
                                              lock_buffer(bh);
                                              ref = le32_to_cpu(BHDR(bh)->h_refcount);
                                              if (ref == 1) {
                                                ...
                                                mb_cache_entry_delete();
                                                unlock_buffer(bh);
                                                ext4_free_blocks();
                                                  ...
                                                  ext4_forget(..., bh, ...);
                                                    jbd2_journal_revoke(..., bh);
    
      ext4_journal_get_write_access(..., new_bh, ...)
        do_get_write_access()
          jbd2_journal_cancel_revoke(..., new_bh);
    
    Later the code in ext4_xattr_block_set() finds out the block got freed
    and cancels reusal of the block but the revoke stays canceled and so in
    case of block reuse and journal replay the filesystem can get corrupted.
    If the race works out slightly differently, we can also hit assertions
    in the jbd2 code.
    
    Fix the problem by making sure that once matching mbcache entry is
    found, code dropping the last xattr block reference (or trying to modify
    xattr block in place) waits until the mbcache entry reference is
    dropped. This way code trying to reuse xattr block is protected from
    someone trying to drop the last reference to xattr block.
    
    Reported-and-tested-by: Ritesh Harjani <ritesh.list@gmail.com>
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-5-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix use-after-free in ext4_xattr_set_entry [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jun 16 10:13:56 2022 +0800

    ext4: fix use-after-free in ext4_xattr_set_entry
    
    [ Upstream commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3 ]
    
    Hulk Robot reported a issue:
    ==================================================================
    BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x18ab/0x3500
    Write of size 4105 at addr ffff8881675ef5f4 by task syz-executor.0/7092
    
    CPU: 1 PID: 7092 Comm: syz-executor.0 Not tainted 4.19.90-dirty #17
    Call Trace:
    [...]
     memcpy+0x34/0x50 mm/kasan/kasan.c:303
     ext4_xattr_set_entry+0x18ab/0x3500 fs/ext4/xattr.c:1747
     ext4_xattr_ibody_inline_set+0x86/0x2a0 fs/ext4/xattr.c:2205
     ext4_xattr_set_handle+0x940/0x1300 fs/ext4/xattr.c:2386
     ext4_xattr_set+0x1da/0x300 fs/ext4/xattr.c:2498
     __vfs_setxattr+0x112/0x170 fs/xattr.c:149
     __vfs_setxattr_noperm+0x11b/0x2a0 fs/xattr.c:180
     __vfs_setxattr_locked+0x17b/0x250 fs/xattr.c:238
     vfs_setxattr+0xed/0x270 fs/xattr.c:255
     setxattr+0x235/0x330 fs/xattr.c:520
     path_setxattr+0x176/0x190 fs/xattr.c:539
     __do_sys_lsetxattr fs/xattr.c:561 [inline]
     __se_sys_lsetxattr fs/xattr.c:557 [inline]
     __x64_sys_lsetxattr+0xc2/0x160 fs/xattr.c:557
     do_syscall_64+0xdf/0x530 arch/x86/entry/common.c:298
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x459fe9
    RSP: 002b:00007fa5e54b4c08 EFLAGS: 00000246 ORIG_RAX: 00000000000000bd
    RAX: ffffffffffffffda RBX: 000000000051bf60 RCX: 0000000000459fe9
    RDX: 00000000200003c0 RSI: 0000000020000180 RDI: 0000000020000140
    RBP: 000000000051bf60 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000001009 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffc73c93fc0 R14: 000000000051bf60 R15: 00007fa5e54b4d80
    [...]
    ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    ext4_xattr_set
      ext4_xattr_set_handle
        ext4_xattr_ibody_find
          >> s->end < s->base
          >> no EXT4_STATE_XATTR
          >> xattr_check_inode is not executed
        ext4_xattr_ibody_set
          ext4_xattr_set_entry
           >> size_t min_offs = s->end - s->base
           >> UAF in memcpy
    
    we can easily reproduce this problem with the following commands:
        mkfs.ext4 -F /dev/sda
        mount -o debug_want_extra_isize=128 /dev/sda /mnt
        touch /mnt/file
        setfattr -n user.cat -v `seq -s z 4096|tr -d '[:digit:]'` /mnt/file
    
    In ext4_xattr_ibody_find, we have the following assignment logic:
      header = IHDR(inode, raw_inode)
             = raw_inode + EXT4_GOOD_OLD_INODE_SIZE + i_extra_isize
      is->s.base = IFIRST(header)
                 = header + sizeof(struct ext4_xattr_ibody_header)
      is->s.end = raw_inode + s_inode_size
    
    In ext4_xattr_set_entry
      min_offs = s->end - s->base
               = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize -
                 sizeof(struct ext4_xattr_ibody_header)
      last = s->first
      free = min_offs - ((void *)last - s->base) - sizeof(__u32)
           = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize -
             sizeof(struct ext4_xattr_ibody_header) - sizeof(__u32)
    
    In the calculation formula, all values except s_inode_size and
    i_extra_size are fixed values. When i_extra_size is the maximum value
    s_inode_size - EXT4_GOOD_OLD_INODE_SIZE, min_offs is -4 and free is -8.
    The value overflows. As a result, the preceding issue is triggered when
    memcpy is executed.
    
    Therefore, when finding xattr or setting xattr, check whether
    there is space for storing xattr in the inode to resolve this issue.
    
    Cc: stable@kernel.org
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220616021358.2504451-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix warning in ext4_iomap_begin as race between bmap and write [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Fri Jun 17 09:39:35 2022 +0800

    ext4: fix warning in ext4_iomap_begin as race between bmap and write
    
    [ Upstream commit 51ae846cff568c8c29921b1b28eb2dfbcd4ac12d ]
    
    We got issue as follows:
    ------------[ cut here ]------------
    WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0
    RIP: 0010:ext4_iomap_begin+0x182/0x5d0
    RSP: 0018:ffff88812460fa08 EFLAGS: 00010293
    RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
    RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f
    R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001
    R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee
    FS:  00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     iomap_apply+0x119/0x570
     iomap_bmap+0x124/0x150
     ext4_bmap+0x14f/0x250
     bmap+0x55/0x80
     do_vfs_ioctl+0x952/0xbd0
     __x64_sys_ioctl+0xc6/0x170
     do_syscall_64+0x33/0x40
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Above issue may happen as follows:
              bmap                    write
    bmap
      ext4_bmap
        iomap_bmap
          ext4_iomap_begin
                                ext4_file_write_iter
                                  ext4_buffered_write_iter
                                    generic_perform_write
                                      ext4_da_write_begin
                                        ext4_da_write_inline_data_begin
                                          ext4_prepare_inline_data
                                            ext4_create_inline_data
                                              ext4_set_inode_flag(inode,
                                                    EXT4_INODE_INLINE_DATA);
          if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on
    
    To solved above issue hold inode lock in ext4_bamp.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20220617013935.397596-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: make sure ext4_append() always allocates new block [+ + +]
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Mon Jul 4 16:27:21 2022 +0200

    ext4: make sure ext4_append() always allocates new block
    
    [ Upstream commit b8a04fe77ef1360fbf73c80fddbdfeaa9407ed1b ]
    
    ext4_append() must always allocate a new block, otherwise we run the
    risk of overwriting existing directory block corrupting the directory
    tree in the process resulting in all manner of problems later on.
    
    Add a sanity check to see if the logical block is already allocated and
    error out if it is.
    
    Cc: stable@kernel.org
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20220704142721.157985-2-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: recover csum seed of tmp_inode after migrating to extents [+ + +]
Author: Li Lingfeng <lilingfeng3@huawei.com>
Date:   Fri Jun 17 14:25:15 2022 +0800

    ext4: recover csum seed of tmp_inode after migrating to extents
    
    [ Upstream commit 07ea7a617d6b278fb7acedb5cbe1a81ce2de7d0c ]
    
    When migrating to extents, the checksum seed of temporary inode
    need to be replaced by inode's, otherwise the inode checksums
    will be incorrect when swapping the inodes data.
    
    However, the temporary inode can not match it's checksum to
    itself since it has lost it's own checksum seed.
    
    mkfs.ext4 -F /dev/sdc
    mount /dev/sdc /mnt/sdc
    xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/sdc/testfile
    chattr -e /mnt/sdc/testfile
    chattr +e /mnt/sdc/testfile
    umount /dev/sdc
    fsck -fn /dev/sdc
    
    ========
    ...
    Pass 1: Checking inodes, blocks, and sizes
    Inode 13 passes checks, but checksum does not match inode.  Fix? no
    ...
    ========
    
    The fix is simple, save the checksum seed of temporary inode, and
    recover it after migrating to extents.
    
    Fixes: e81c9302a6c3 ("ext4: set csum seed in tmp inode while migrating to extents")
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220617062515.2113438-1-lilingfeng3@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: remove EA inode entry from mbcache on inode eviction [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:22 2022 +0200

    ext4: remove EA inode entry from mbcache on inode eviction
    
    [ Upstream commit 6bc0d63dad7f9f54d381925ee855b402f652fa39 ]
    
    Currently we remove EA inode from mbcache as soon as its xattr refcount
    drops to zero. However there can be pending attempts to reuse the inode
    and thus refcount handling code has to handle the situation when
    refcount increases from zero anyway. So save some work and just keep EA
    inode in mbcache until it is getting evicted. At that moment we are sure
    following iget() of EA inode will fail anyway (or wait for eviction to
    finish and load things from the disk again) and so removing mbcache
    entry at that moment is fine and simplifies the code a bit.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-3-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: unindent codeblock in ext4_xattr_block_set() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:23 2022 +0200

    ext4: unindent codeblock in ext4_xattr_block_set()
    
    [ Upstream commit fd48e9acdf26d0cbd80051de07d4a735d05d29b2 ]
    
    Remove unnecessary else (and thus indentation level) from a code block
    in ext4_xattr_block_set(). It will also make following code changes
    easier. No functional changes.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-4-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: update s_overhead_clusters in the superblock during an on-line resize [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jun 29 00:00:25 2022 -0400

    ext4: update s_overhead_clusters in the superblock during an on-line resize
    
    [ Upstream commit de394a86658ffe4e89e5328fd4993abfe41b7435 ]
    
    When doing an online resize, the on-disk superblock on-disk wasn't
    updated.  This means that when the file system is unmounted and
    remounted, and the on-disk overhead value is non-zero, this would
    result in the results of statfs(2) to be incorrect.
    
    This was partially fixed by Commits 10b01ee92df5 ("ext4: fix overhead
    calculation to account for the reserved gdt blocks"), 85d825dbf489
    ("ext4: force overhead calculation if the s_overhead_cluster makes no
    sense"), and eb7054212eac ("ext4: update the cached overhead value in
    the superblock").
    
    However, since it was too expensive to forcibly recalculate the
    overhead for bigalloc file systems at every mount, this didn't fix the
    problem for bigalloc file systems.  This commit should address the
    problem when resizing file systems with the bigalloc feature enabled.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20220629040026.112371-1-tytso@mit.edu
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: use kmemdup() to replace kmalloc + memcpy [+ + +]
Author: Shuqi Zhang <zhangshuqi3@huawei.com>
Date:   Wed May 25 11:01:20 2022 +0800

    ext4: use kmemdup() to replace kmalloc + memcpy
    
    [ Upstream commit 4efd9f0d120c55b08852ee5605dbb02a77089a5d ]
    
    Replace kmalloc + memcpy with kmemdup()
    
    Signed-off-by: Shuqi Zhang <zhangshuqi3@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220525030120.803330-1-zhangshuqi3@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: allow compression for mmap files in compress_mode=user [+ + +]
Author: Sungjong Seo <sj1557.seo@samsung.com>
Date:   Tue May 24 10:29:11 2022 +0900

    f2fs: allow compression for mmap files in compress_mode=user
    
    [ Upstream commit 66d34fcbbe63ebd8584b792e0d741f6648100894 ]
    
    Since commit e3c548323d32 ("f2fs: let's allow compression for mmap files"),
    it has been allowed to compress mmap files. However, in compress_mode=user,
    it is not allowed yet. To keep the same concept in both compress_modes,
    f2fs_ioc_(de)compress_file() should also allow it.
    
    Let's remove checking mmap files in f2fs_ioc_(de)compress_file() so that
    the compression for mmap files is also allowed in compress_mode=user.
    
    Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: do not allow to decompress files have FI_COMPRESS_RELEASED [+ + +]
Author: Jaewook Kim <jw5454.kim@samsung.com>
Date:   Wed Aug 3 17:53:58 2022 +0900

    f2fs: do not allow to decompress files have FI_COMPRESS_RELEASED
    
    [ Upstream commit 90be48bd9d29ece3965e5e8b21499b6db166e57b ]
    
    If a file has FI_COMPRESS_RELEASED, all writes for it should not be
    allowed. However, as of now, in case of compress_mode=user, writes
    triggered by IOCTLs like F2FS_IOC_DE/COMPRESS_FILE are allowed unexpectly,
    which could crash that file.
    To fix it, let's do not allow F2FS_IOC_DE/COMPRESS_IOCTL if a file already
    has FI_COMPRESS_RELEASED flag.
    
    This is the reproduction process:
    1.  $ touch ./file
    2.  $ chattr +c ./file
    3.  $ dd if=/dev/random of=./file bs=4096 count=30 conv=notrunc
    4.  $ dd if=/dev/zero of=./file bs=4096 count=34 seek=30 conv=notrunc
    5.  $ sync
    6.  $ do_compress ./file      ; call F2FS_IOC_COMPRESS_FILE
    7.  $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS
    8.  $ release ./file          ; call F2FS_IOC_RELEASE_COMPRESS_BLOCKS
    9.  $ do_compress ./file      ; call F2FS_IOC_COMPRESS_FILE again
    10. $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS again
    
    This reproduction process is tested in 128kb cluster size.
    You can find compr_blocks has a negative value.
    
    Fixes: 5fdb322ff2c2b ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE")
    
    Signed-off-by: Junbeom Yeom <junbeom.yeom@samsung.com>
    Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com>
    Signed-off-by: Youngjin Gil <youngjin.gil@samsung.com>
    Signed-off-by: Jaewook Kim <jw5454.kim@samsung.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to remove F2FS_COMPR_FL and tag F2FS_NOCOMP_FL at the same time [+ + +]
Author: Chao Liu <liuchao@coolpad.com>
Date:   Mon Jul 25 18:16:33 2022 +0800

    f2fs: fix to remove F2FS_COMPR_FL and tag F2FS_NOCOMP_FL at the same time
    
    [ Upstream commit 8ee236dcaa690d09ca612622e8bc8d09c302021d ]
    
    If the inode has the compress flag, it will fail to use
    'chattr -c +m' to remove its compress flag and tag no compress flag.
    However, the same command will be successful when executed again,
    as shown below:
    
      $ touch foo.txt
      $ chattr +c foo.txt
      $ chattr -c +m foo.txt
      chattr: Invalid argument while setting flags on foo.txt
      $ chattr -c +m foo.txt
      $ f2fs_io getflags foo.txt
      get a flag on foo.txt ret=0, flags=nocompression,inline_data
    
    Fix this by removing some checks in f2fs_setflags_common()
    that do not affect the original logic. I go through all the
    possible scenarios, and the results are as follows. Bold is
    the only thing that has changed.
    
    +---------------+-----------+-----------+----------+
    |               |            file flags            |
    + command       +-----------+-----------+----------+
    |               | no flag   | compr     | nocompr  |
    +---------------+-----------+-----------+----------+
    | chattr +c     | compr     | compr     | -EINVAL  |
    | chattr -c     | no flag   | no flag   | nocompr  |
    | chattr +m     | nocompr   | -EINVAL   | nocompr  |
    | chattr -m     | no flag   | compr     | no flag  |
    | chattr +c +m  | -EINVAL   | -EINVAL   | -EINVAL  |
    | chattr +c -m  | compr     | compr     | compr    |
    | chattr -c +m  | nocompr   | *nocompr* | nocompr  |
    | chattr -c -m  | no flag   | no flag   | no flag  |
    +---------------+-----------+-----------+----------+
    
    Link: https://lore.kernel.org/linux-f2fs-devel/20220621064833.1079383-1-chaoliu719@gmail.com/
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Chao Liu <liuchao@coolpad.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbcon: Fix accelerated fbdev scrolling while logo is still shown [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Thu Jun 2 22:08:38 2022 +0200

    fbcon: Fix accelerated fbdev scrolling while logo is still shown
    
    commit 3866cba87dcd0162fb41e9b3b653d0af68fad5ec upstream.
    
    There is no need to directly skip over to the SCROLL_REDRAW case while
    the logo is still shown.
    
    When using DRM, this change has no effect because the code will reach
    the SCROLL_REDRAW case immediately anyway.
    
    But if you run an accelerated fbdev driver and have
    FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is
    slowed down by factors so that it feels as if you use a 9600 baud
    terminal.
    
    So, drop those unnecessary checks and speed up fbdev console
    acceleration during bootup.
    
    Cc: stable@vger.kernel.org # v5.10+
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/YpkYxk7wsBPx3po+@p100
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Thu Jun 2 22:06:28 2022 +0200

    fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters
    
    commit cad564ca557f8d3bb3b1fa965d9a2b3f6490ec69 upstream.
    
    The user may use the fbcon=vc:<n1>-<n2> option to tell fbcon to take
    over the given range (n1...n2) of consoles. The value for n1 and n2
    needs to be a positive number and up to (MAX_NR_CONSOLES - 1).
    The given values were not fully checked against those boundaries yet.
    
    To fix the issue, convert first_fb_vc and last_fb_vc to unsigned
    integers and check them against the upper boundary, and make sure that
    first_fb_vc is smaller than last_fb_vc.
    
    Cc: stable@vger.kernel.org # v4.19+
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/YpkYRMojilrtZIgM@p100
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails [+ + +]
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Fri Jul 1 17:03:10 2022 +0100

    firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails
    
    [ Upstream commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 ]
    
    When scpi probe fails, at any point, we need to ensure that the scpi_info
    is not set and will remain NULL until the probe succeeds. If it is not
    taken care, then it could result use-after-free as the value is exported
    via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
    but freed when the probe fails.
    
    Link: https://lore.kernel.org/r/20220701160310.148344-1-sudeep.holla@arm.com
    Cc: stable@vger.kernel.org # 4.19+
    Reported-by: huhai <huhai@kylinos.cn>
    Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: tegra: Fix error check return value of debugfs_create_file() [+ + +]
Author: Lv Ruyi <lv.ruyi@zte.com.cn>
Date:   Tue Apr 19 01:36:48 2022 +0000

    firmware: tegra: Fix error check return value of debugfs_create_file()
    
    [ Upstream commit afcdb8e55c91c6ff0700ab272fd0f74e899ab884 ]
    
    If an error occurs, debugfs_create_file() will return ERR_PTR(-ERROR),
    so use IS_ERR() to check it.
    
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: fix short copy handling in copy_mc_pipe_to_iter() [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jun 12 19:50:29 2022 -0400

    fix short copy handling in copy_mc_pipe_to_iter()
    
    commit c3497fd009ef2c59eea60d21c3ac22de3585ed7d upstream.
    
    Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can
    result in a short copy.  In that case we need to trim the unused
    buffers, as well as the length of partially filled one - it's not
    enough to set ->head, ->iov_offset and ->count to reflect how
    much had we copied.  Not hard to fix, fortunately...
    
    I'd put a helper (pipe_discard_from(pipe, head)) into pipe_fs_i.h,
    rather than iov_iter.c - it has nothing to do with iov_iter and
    having it will allow us to avoid an ugly kludge in fs/splice.c.
    We could put it into lib/iov_iter.c for now and move it later,
    but I don't see the point going that way...
    
    Cc: stable@kernel.org # 4.19+
    Fixes: ca146f6f091e "lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe()"
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fpga: altera-pr-ip: fix unsigned comparison with less than zero [+ + +]
Author: Marco Pagani <marpagan@redhat.com>
Date:   Thu Jun 9 16:05:19 2022 +0200

    fpga: altera-pr-ip: fix unsigned comparison with less than zero
    
    [ Upstream commit 2df84a757d87fd62869fc401119d429735377ec5 ]
    
    Fix the "comparison with less than zero" warning reported by
    cppcheck for the unsigned (size_t) parameter count of the
    alt_pr_fpga_write() function.
    
    Fixes: d201cc17a8a3 ("fpga pr ip: Core driver support for Altera Partial Reconfiguration IP")
    Reviewed-by: Tom Rix <trix@redhat.com>
    Acked-by: Xu Yilun <yilun.xu@intel.com>
    Signed-off-by: Marco Pagani <marpagan@redhat.com>
    Link: https://lore.kernel.org/r/20220609140520.42662-1-marpagan@redhat.com
    Signed-off-by: Xu Yilun <yilun.xu@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: Add missing umask strip in vfs_tmpfile [+ + +]
Author: Yang Xu <xuyang2018.jy@fujitsu.com>
Date:   Thu Jul 14 14:11:26 2022 +0800

    fs: Add missing umask strip in vfs_tmpfile
    
    commit ac6800e279a22b28f4fc21439843025a0d5bf03e upstream.
    
    All creation paths except for O_TMPFILE handle umask in the vfs directly
    if the filesystem doesn't support or enable POSIX ACLs. If the filesystem
    does then umask handling is deferred until posix_acl_create().
    Because, O_TMPFILE misses umask handling in the vfs it will not honor
    umask settings. Fix this by adding the missing umask handling.
    
    Link: https://lore.kernel.org/r/1657779088-2242-2-git-send-email-xuyang2018.jy@fujitsu.com
    Fixes: 60545d0d4610 ("[O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...")
    Cc: <stable@vger.kernel.org> # 4.19+
    Reported-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-and-Tested-by: Jeff Layton <jlayton@kernel.org>
    Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs: check FMODE_LSEEK to control internal pipe splicing [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jun 29 15:06:58 2022 +0200

    fs: check FMODE_LSEEK to control internal pipe splicing
    
    [ Upstream commit 97ef77c52b789ec1411d360ed99dca1efe4b2c81 ]
    
    The original direct splicing mechanism from Jens required the input to
    be a regular file because it was avoiding the special socket case. It
    also recognized blkdevs as being close enough to a regular file. But it
    forgot about chardevs, which behave the same way and work fine here.
    
    This is an okayish heuristic, but it doesn't totally work. For example,
    a few chardevs should be spliceable here. And a few regular files
    shouldn't. This patch fixes this by instead checking whether FMODE_LSEEK
    is set, which represents decently enough what we need rewinding for when
    splicing to internal pipes.
    
    Fixes: b92ce5589374 ("[PATCH] splice: add direct fd <-> fd splicing support")
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ftrace/x86: Add back ftrace_expected assignment [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Jul 26 10:18:51 2022 -0400

    ftrace/x86: Add back ftrace_expected assignment
    
    commit ac6c1b2ca77e722a1e5d651f12f437f2f237e658 upstream.
    
    When a ftrace_bug happens (where ftrace fails to modify a location) it is
    helpful to have what was at that location as well as what was expected to
    be there.
    
    But with the conversion to text_poke() the variable that assigns the
    expected for debugging was dropped. Unfortunately, I noticed this when I
    needed it. Add it back.
    
    Link: https://lkml.kernel.org/r/20220726101851.069d2e70@gandalf.local.home
    
    Cc: "x86@kernel.org" <x86@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fuse: ioctl: translate ENOSYS [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Jul 21 16:06:18 2022 +0200

    fuse: ioctl: translate ENOSYS
    
    commit 02c0cab8e7345b06f1c0838df444e2902e4138d3 upstream.
    
    Overlayfs may fail to complete updates when a filesystem lacks
    fileattr/xattr syscall support and responds with an ENOSYS error code,
    resulting in an unexpected "Function not implemented" error.
    
    This bug may occur with FUSE filesystems, such as davfs2.
    
    Steps to reproduce:
    
      # install davfs2, e.g., apk add davfs2
      mkdir /test mkdir /test/lower /test/upper /test/work /test/mnt
      yes '' | mount -t davfs -o ro http://some-web-dav-server/path \
        /test/lower
      mount -t overlay -o upperdir=/test/upper,lowerdir=/test/lower \
        -o workdir=/test/work overlay /test/mnt
    
      # when "some-file" exists in the lowerdir, this fails with "Function
      # not implemented", with dmesg showing "overlayfs: failed to retrieve
      # lower fileattr (/some-file, err=-38)"
      touch /test/mnt/some-file
    
    The underlying cause of this regresion is actually in FUSE, which fails to
    translate the ENOSYS error code returned by userspace filesystem (which
    means that the ioctl operation is not supported) to ENOTTY.
    
    Reported-by: Christian Kohlschütter <christian@kohlschutter.com>
    Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags")
    Fixes: 59efec7b9039 ("fuse: implement ioctl support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fuse: limit nsec [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Jul 21 16:06:18 2022 +0200

    fuse: limit nsec
    
    commit 47912eaa061a6a81e4aa790591a1874c650733c0 upstream.
    
    Limit nanoseconds to 0..999999999.
    
    Fixes: d8a5ba45457e ("[PATCH] FUSE - core")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fuse: Remove the control interface for virtio-fs [+ + +]
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Mon Jul 18 16:50:12 2022 +0800

    fuse: Remove the control interface for virtio-fs
    
    [ Upstream commit c64797809a64c73497082aa05e401a062ec1af34 ]
    
    The commit 15c8e72e88e0 ("fuse: allow skipping control interface and forced
    unmount") tries to remove the control interface for virtio-fs since it does
    not support aborting requests which are being processed. But it doesn't
    work now.
    
    This patch fixes it by skipping creating the control interface if
    fuse_conn->no_control is set.
    
    Fixes: 15c8e72e88e0 ("fuse: allow skipping control interface and forced unmount")
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
genelf: Use HAVE_LIBCRYPTO_SUPPORT, not the never defined HAVE_LIBCRYPTO [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Aug 2 15:13:22 2022 -0300

    genelf: Use HAVE_LIBCRYPTO_SUPPORT, not the never defined HAVE_LIBCRYPTO
    
    [ Upstream commit 91cea6be90e436c55cde8770a15e4dac9d3032d0 ]
    
    When genelf was introduced it tested for HAVE_LIBCRYPTO not
    HAVE_LIBCRYPTO_SUPPORT, which is the define the feature test for openssl
    defines, fix it.
    
    This also adds disables the deprecation warning, someone has to fix this
    to build with openssl 3.0 before the warning becomes a hard error.
    
    Fixes: 9b07e27f88b9cd78 ("perf inject: Add jitdump mmap injection support")
    Reported-by: 谭梓煊 <tanzixuan.me@gmail.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andrii@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lore.kernel.org/lkml/YulpPqXSOG0Q4J1o@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
genirq: Don't return error on missing optional irq_request_resources() [+ + +]
Author: Antonio Borneo <antonio.borneo@foss.st.com>
Date:   Thu May 12 18:05:44 2022 +0200

    genirq: Don't return error on missing optional irq_request_resources()
    
    [ Upstream commit 95001b756467ecc9f5973eb5e74e97699d9bbdf1 ]
    
    Function irq_chip::irq_request_resources() is reported as optional
    in the declaration of struct irq_chip.
    If the parent irq_chip does not implement it, we should ignore it
    and return.
    
    Don't return error if the functions is missing.
    
    Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220512160544.13561-1-antonio.borneo@foss.st.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

genirq: GENERIC_IRQ_IPI depends on SMP [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Fri Jul 1 15:00:50 2022 -0500

    genirq: GENERIC_IRQ_IPI depends on SMP
    
    [ Upstream commit 0f5209fee90b4544c58b4278d944425292789967 ]
    
    The generic IPI code depends on the IRQ affinity mask being allocated
    and initialized. This will not be the case if SMP is disabled. Fix up
    the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220701200056.46555-3-samuel@sholland.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: gpiolib-of: Fix refcount bugs in of_mm_gpiochip_add_data() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Mon Jul 11 20:52:38 2022 +0800

    gpio: gpiolib-of: Fix refcount bugs in of_mm_gpiochip_add_data()
    
    [ Upstream commit 5d07a692f9562f9c06e62cce369e9dd108173a0f ]
    
    We should use of_node_get() when a new reference of device_node
    is created. It is noted that the old reference stored in
    'mm_gc->gc.of_node' should also be decreased.
    
    This patch is based on the fact that there is a call site in function
    'qe_add_gpiochips()' of src file 'drivers\soc\fsl\qe\gpio.c'. In this
    function, of_mm_gpiochip_add_data() is contained in an iteration of
    for_each_compatible_node() which will automatically increase and
    decrease the refcount. So we need additional of_node_get() for the
    reference escape in of_mm_gpiochip_add_data().
    
    Fixes: a19e3da5bc5f ("of/gpio: Kill of_gpio_chip and add members directly to gpio_chip")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: alps: Declare U1_UNICORN_LEGACY support [+ + +]
Author: Artem Borisov <dedsa2002@gmail.com>
Date:   Tue Jul 19 17:53:24 2022 +0300

    HID: alps: Declare U1_UNICORN_LEGACY support
    
    [ Upstream commit 1117d182c5d72abd7eb8b7d5e7b8c3373181c3ab ]
    
    U1_UNICORN_LEGACY id was added to the driver, but was not declared
    in the device id table, making it impossible to use.
    
    Fixes: 640e403 ("HID: alps: Add AUI1657 device ID")
    Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: amd_sfh: Add NULL check for hid device [+ + +]
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Tue Jul 12 23:48:26 2022 +0530

    HID: amd_sfh: Add NULL check for hid device
    
    [ Upstream commit 06aa2a43c307cf4096f422dcb575e5d2913e528f ]
    
    On removal of hid device during SFH set report may cause NULL pointer
    exception. Hence add NULL check for hid device before accessing.
    
    Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)")
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: amd_sfh: Don't show client init failed as error when discovery fails [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Thu May 12 13:18:48 2022 -0500

    HID: amd_sfh: Don't show client init failed as error when discovery fails
    
    [ Upstream commit e51d8d3ea3d773334d2c047c8d1623dba66f592a ]
    
    When sensor discovery fails, this means that the system doesn't have
    any sensors connected and a user should only be notified at most one time.
    A message is already displayed at WARN level of "failed to discover,
    sensors not enabled".  It's pointless to show that the client init failed
    at ERR level for the same condition.
    
    Check the return code and don't display this message in those conditions.
    
    Fixes: b5d7f43e97da ("HID: amd_sfh: Add support for sensor discovery")
    Reported-by: David Chang <David.Chang@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: amd_sfh: Handle condition of "no sensors" [+ + +]
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Sat Jul 23 11:40:33 2022 +0530

    HID: amd_sfh: Handle condition of "no sensors"
    
    [ Upstream commit 5d4d0f15657535f6a122ab26d47230b5c2b944af ]
    
    Add a check for num_hid_devices to handle special case the situation
    of "no sensors".
    
    Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)")
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: cp2112: prevent a buffer overflow in cp2112_xfer() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Wed Jun 8 05:26:09 2022 -0700

    HID: cp2112: prevent a buffer overflow in cp2112_xfer()
    
    [ Upstream commit 381583845d19cb4bd21c8193449385f3fefa9caf ]
    
    Smatch warnings:
    drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy()
    'data->block[1]' too small (33 vs 255)
    drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too
    small (64 vs 255)
    
    The 'read_length' variable is provided by 'data->block[0]' which comes
    from user and it(read_length) can take a value between 0-255. Add an
    upper bound to 'read_length' variable to prevent a buffer overflow in
    memcpy().
    
    Fixes: 542134c0375b ("HID: cp2112: Fix I2C_BLOCK_DATA transactions")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: hid-input: add Surface Go battery quirk [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu May 26 01:08:27 2022 +0200

    HID: hid-input: add Surface Go battery quirk
    
    commit db925d809011c37b246434fdce71209fc2e6c0c2 upstream.
    
    Similar to the Surface Go (1), the (Elantech) touchscreen/digitizer in
    the Surface Go 2 mistakenly reports the battery of the stylus. Instead
    of over the touchscreen device, battery information is provided via
    bluetooth and the touchscreen device reports an empty battery.
    
    Apply the HID_BATTERY_QUIRK_IGNORE quirk to ignore this battery and
    prevent the erroneous low battery warnings.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: mcp2221: prevent a buffer overflow in mcp_smbus_write() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Mon Jun 20 09:28:24 2022 -0700

    HID: mcp2221: prevent a buffer overflow in mcp_smbus_write()
    
    [ Upstream commit 62ac2473553a00229e67bdf3cb023b62cf7f5a9a ]
    
    Smatch Warning:
    drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy()
    '&mcp->txbuf[5]' too small (59 vs 255)
    drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf'
    too small (34 vs 255)
    
    The 'len' variable can take a value between 0-255 as it can come from
    data->block[0] and it is user data. So add an bound check to prevent a
    buffer overflow in memcpy().
    
    Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: wacom: Don't register pad_input for touch switch [+ + +]
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Fri May 13 14:52:37 2022 -0700

    HID: wacom: Don't register pad_input for touch switch
    
    commit d6b675687a4ab4dba684716d97c8c6f81bf10905 upstream.
    
    Touch switch state is received through WACOM_PAD_FIELD. However, it
    is reported by touch_input. Don't register pad_input if no other pad
    events require the interface.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: Only report rotation for art pen [+ + +]
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Fri May 13 14:51:56 2022 -0700

    HID: wacom: Only report rotation for art pen
    
    commit 7ccced33a0ba39b0103ae1dfbf7f1dffdc0a1bc2 upstream.
    
    The generic routine, wacom_wac_pen_event, turns rotation value 90
    degree anti-clockwise before posting the events. This non-zero
    event trggers a non-zero ABS_Z event for non art pen tools. However,
    HID_DG_TWIST is only supported by art pen.
    
    [jkosina@suse.cz: fix build: add missing brace]
    Cc: stable@vger.kernel.org
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hinic: Use the bitmap API when applicable [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jun 26 18:27:45 2022 +0200

    hinic: Use the bitmap API when applicable
    
    [ Upstream commit 7c2c57263af41cfd8b5022274e6801542831bb69 ]
    
    'vlan_bitmap' is a bitmap and is used as such. So allocate it with
    devm_bitmap_zalloc() and its explicit bit size (i.e. VLAN_N_VID).
    
    This avoids the need of the VLAN_BITMAP_SIZE macro which:
       - needlessly has a 'nic_dev' parameter
       - should be "long" (and not byte) aligned, so that the bitmap semantic
         is respected
    
    This is in fact not an issue because VLAN_N_VID is 4096 at the time
    being, but devm_bitmap_zalloc() is less verbose and easier to understand.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/6ff7b7d21414240794a77dc2456914412718a145.1656260842.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (dell-smm) Add Dell XPS 13 7390 to fan control whitelist [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Sun Jun 12 06:18:06 2022 +0200

    hwmon: (dell-smm) Add Dell XPS 13 7390 to fan control whitelist
    
    [ Upstream commit 385e5f57053ff293282fea84c1c27186d53f66e1 ]
    
    A user reported that the program dell-bios-fan-control
    worked on his Dell XPS 13 7390 to switch off automatic
    fan control.
    Since it uses the same mechanism as the dell_smm_hwmon
    module, add this model to the fan control whitelist.
    
    Compile-tested only.
    
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Acked-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20220612041806.11367-1-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (drivetemp) Add module alias [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Jul 12 23:46:24 2022 +0200

    hwmon: (drivetemp) Add module alias
    
    [ Upstream commit 5918036cfa8ded7aa8094db70295011ce2275447 ]
    
    Adding a MODULE_ALIAS() to drivetemp will make the driver easier
    for modprobe to autoprobe.
    
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20220712214624.1845158-1-linus.walleij@linaro.org
    Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (sht15) Fix wrong assumptions in device remove callback [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Jul 25 21:43:44 2022 +0200

    hwmon: (sht15) Fix wrong assumptions in device remove callback
    
    [ Upstream commit 7d4edccc9bbfe1dcdff641343f7b0c6763fbe774 ]
    
    Taking a lock at the beginning of .remove() doesn't prevent new readers.
    With the existing approach it can happen, that a read occurs just when
    the lock was taken blocking the reader until the lock is released at the
    end of the remove callback which then accessed *data that is already
    freed then.
    
    To actually fix this problem the hwmon core needs some adaption. Until
    this is implemented take the optimistic approach of assuming that all
    readers are gone after hwmon_device_unregister() and
    sysfs_remove_group() as most other drivers do. (And once the core
    implements that, taking the lock would deadlock.)
    
    So drop the lock, move the reset to after device unregistration to keep
    the device in a workable state until it's deregistered. Also add a error
    message in case the reset fails and return 0 anyhow. (Returning an error
    code, doesn't stop the platform device unregistration and only results
    in a little helpful error message before the devm cleanup handlers are
    called.)
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220725194344.150098-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: cadence: Support PEC for SMBus block read [+ + +]
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Sun Jul 17 16:52:44 2022 +0200

    i2c: cadence: Support PEC for SMBus block read
    
    [ Upstream commit 9fdf6d97f03035ad5298e2d1635036c74c2090ed ]
    
    SMBus packet error checking (PEC) is implemented by appending one
    additional byte of checksum data at the end of the message. This provides
    additional protection and allows to detect data corruption on the I2C bus.
    
    SMBus block reads support variable length reads. The first byte in the read
    message is the number of available data bytes.
    
    The combination of PEC and block read is currently not supported by the
    Cadence I2C driver.
     * When PEC is enabled the maximum transfer length for block reads
       increases from 33 to 34 bytes.
     * The I2C core smbus emulation layer relies on the driver updating the
       `i2c_msg` `len` field with the number of received bytes. The updated
       length is used when checking the PEC.
    
    Add support to the Cadence I2C driver for handling SMBus block reads with
    PEC. To determine the maximum transfer length uses the initial `len` value
    of the `i2c_msg`. When PEC is enabled this will be 2, when it is disabled
    it will be 1.
    
    Once a read transfer is done also increment the `len` field by the amount
    of received data bytes.
    
    This change has been tested with a UCM90320 PMBus power monitor, which
    requires block reads to access certain data fields, but also has PEC
    enabled by default.
    
    Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Tested-by: Shubhrajyoti Datta <Shubhrajyoti.datta@amd.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: Fix a potential use after free [+ + +]
Author: Xu Wang <vulab@iscas.ac.cn>
Date:   Fri Dec 27 09:34:32 2019 +0000

    i2c: Fix a potential use after free
    
    [ Upstream commit e4c72c06c367758a14f227c847f9d623f1994ecf ]
    
    Free the adap structure only after we are done using it.
    This patch just moves the put_device() down a bit to avoid the
    use after free.
    
    Fixes: 611e12ea0f12 ("i2c: core: manage i2c bus device refcount in i2c_[get|put]_adapter")
    Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
    [wsa: added comment to the code, added Fixes tag]
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: mux-gpmux: Add of_node_put() when breaking out of loop [+ + +]
Author: Liang He <windhl@126.com>
Date:   Fri Jul 22 09:24:01 2022 +0800

    i2c: mux-gpmux: Add of_node_put() when breaking out of loop
    
    [ Upstream commit 6435319c34704994e19b0767f6a4e6f37439867b ]
    
    In i2c_mux_probe(), we should call of_node_put() when breaking out
    of for_each_child_of_node() which will automatically increase and
    decrease the refcount.
    
    Fixes: ac8498f0ce53 ("i2c: i2c-mux-gpmux: new driver")
    Signed-off-by: Liang He <windhl@126.com>
    Acked-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: mxs: Silence a clang warning [+ + +]
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed May 25 22:09:14 2022 -0300

    i2c: mxs: Silence a clang warning
    
    [ Upstream commit 3d43273d7d1e1a5374d531e901d3c537b4c97bbf ]
    
    Change the of_device_get_match_data() cast to (uintptr_t)
    to silence the following clang warning:
    
    drivers/i2c/busses/i2c-mxs.c:802:18: warning: cast to smaller integer type 'enum mxs_i2c_devtype' from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: c32abd8b5691 ("i2c: mxs: Remove unneeded platform_device_id")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: npcm: Correct slave role behavior [+ + +]
Author: Tali Perry <tali.perry1@gmail.com>
Date:   Wed May 25 11:23:39 2022 +0800

    i2c: npcm: Correct slave role behavior
    
    [ Upstream commit d7aa1b149b8fc04d802879cf4662010aa4a42deb ]
    
    Correct the slave transaction logic to be compatible with the generic
    slave backend driver.
    
    Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")
    Signed-off-by: Tali Perry <tali.perry1@gmail.com>
    Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: npcm: Remove own slave addresses 2:10 [+ + +]
Author: Tali Perry <tali.perry1@gmail.com>
Date:   Wed May 25 11:23:38 2022 +0800

    i2c: npcm: Remove own slave addresses 2:10
    
    [ Upstream commit 47d506d1a28fd10a9fb1f33df5622d88fae72095 ]
    
    NPCM can support up to 10 own slave addresses. In practice, only one
    address is actually being used. In order to access addresses 2 and above,
    need to switch register banks. The switch needs spinlock.
    To avoid using spinlock for this useless feature removed support of SA >=
    2. Also fix returned slave event enum.
    
    Remove some comment since the bank selection is not required. The bank
    selection is not required since the supported slave addresses are reduced.
    
    Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")
    Signed-off-by: Tali Perry <tali.perry1@gmail.com>
    Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr() [+ + +]
Author: Alexander Lobakin <alexandr.lobakin@intel.com>
Date:   Fri Jun 24 14:13:05 2022 +0200

    ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr()
    
    commit e5a16a5c4602c119262f350274021f90465f479d upstream.
    
    test_bit(), as any other bitmap op, takes `unsigned long *` as a
    second argument (pointer to the actual bitmap), as any bitmap
    itself is an array of unsigned longs. However, the ia64_get_irr()
    code passes a ref to `u64` as a second argument.
    This works with the ia64 bitops implementation due to that they
    have `void *` as the second argument and then cast it later on.
    This works with the bitmap API itself due to that `unsigned long`
    has the same size on ia64 as `u64` (`unsigned long long`), but
    from the compiler PoV those two are different.
    Define @irr as `unsigned long` to fix that. That implies no
    functional changes. Has been hidden for 16 years!
    
    Fixes: a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")
    Cc: stable@vger.kernel.org # 2.6.16+
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iavf: Fix 'tc qdisc show' listing too many queues [+ + +]
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Wed Jun 15 15:36:29 2022 +0200

    iavf: Fix 'tc qdisc show' listing too many queues
    
    [ Upstream commit 93cb804edab1b9a5bb7bb7b6824012dbb20abf22 ]
    
    Fix tc qdisc show dev <ethX> root displaying too many fq_codel qdiscs.
    tc_modify_qdisc, which is caller of ndo_setup_tc, expects driver to call
    netif_set_real_num_tx_queues, which prepares qdiscs.
    Without this patch, fq_codel qdiscs would not be adjusted to number of
    queues on VF.
    e.g.:
    tc qdisc show dev <ethX>
    qdisc mq 0: root
    qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    tc qdisc add dev <ethX> root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit
    tc qdisc show dev <ethX>
    qdisc mqprio 8003: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                 queues:(0:0) (1:1)
                 mode:channel
                 shaper:bw_rlimit   max_rate:5Gbit 150Mbit
    qdisc fq_codel 0: parent 8003:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent 8003:3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent 8003:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent 8003:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    
    While after fix:
    tc qdisc add dev <ethX> root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit
    tc qdisc show dev <ethX> #should show 2, shows 4
    qdisc mqprio 8004: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                 queues:(0:0) (1:1)
                 mode:channel
                 shaper:bw_rlimit   max_rate:5Gbit 150Mbit
    qdisc fq_codel 0: parent 8004:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    qdisc fq_codel 0: parent 8004:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
    
    Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Co-developed-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Co-developed-by: Kiran Patil <kiran.patil@intel.com>
    Signed-off-by: Kiran Patil <kiran.patil@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iavf: Fix max_rate limiting [+ + +]
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Mon Jun 13 18:41:23 2022 -0400

    iavf: Fix max_rate limiting
    
    [ Upstream commit ec60d54cb9a3d43a02c5612a03093c18233e6601 ]
    
    Fix max_rate option in TC, check for proper quanta boundaries.
    Check for minimum value provided and if it fits expected 50Mbps
    quanta.
    
    Without this patch, iavf could send settings for max_rate limiting
    that would be accepted from by PF even the max_rate option is less
    than expected 50Mbps quanta. It results in no rate limiting
    on traffic as rate limiting will be floored to 0.
    
    Example:
    tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \
    2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \
    max_rate 50Mbps 500Mbps 500Mbps
    
    Should limit TC0 to circa 50 Mbps
    
    tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \
    2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \
    max_rate 0Mbps 100Kbit 500Mbps
    
    Should return error
    
    Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Jun Zhang <xuejun.zhang@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ieee80211: add EHT 1K aggregation definitions [+ + +]
Author: Mordechay Goodstein <mordechay.goodstein@intel.com>
Date:   Mon Feb 14 17:29:52 2022 +0100

    ieee80211: add EHT 1K aggregation definitions
    
    [ Upstream commit 2a2c86f15e17c5013b9897b67d895e64a25ae3cb ]
    
    We add the fields for parsing extended ADDBA request/respond,
    and new max 1K aggregation for limit ADDBA request/respond.
    
    Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF ->
    IEEE80211_MAX_AMPDU_BUF_HE.
    
    Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
    Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: accel: bma400: Fix the scale min and max macro values [+ + +]
Author: Jagath Jog J <jagathjog1996@gmail.com>
Date:   Thu May 5 19:00:12 2022 +0530

    iio: accel: bma400: Fix the scale min and max macro values
    
    [ Upstream commit 747c7cf1592e226d40543231b26502b332d0ea2f ]
    
    Changing the scale macro values to match the bma400 sensitivity
    for 1 LSB of all the available ranges.
    
    Fixes: 465c811f1f20 ("iio: accel: Add driver for the BMA400")
    Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220505133021.22362-2-jagathjog1996@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: accel: bma400: Reordering of header files [+ + +]
Author: Jagath Jog J <jagathjog1996@gmail.com>
Date:   Thu May 5 19:00:13 2022 +0530

    iio: accel: bma400: Reordering of header files
    
    [ Upstream commit 1bd2dc6ea863690aee5c45ebf09c9194c7a42c0d ]
    
    Reordering of header files and removing the iio/sysfs.h since
    custom attributes are not being used in the driver.
    
    Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220505133021.22362-3-jagathjog1996@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: cros: Register FIFO callback after sensor is registered [+ + +]
Author: Gwendal Grignou <gwendal@chromium.org>
Date:   Mon Jul 11 07:47:16 2022 -0700

    iio: cros: Register FIFO callback after sensor is registered
    
    [ Upstream commit 0b4ae3f6d1210c11f9baf159009c7227eacf90f2 ]
    
    Instead of registering callback to process sensor events right at
    initialization time, wait for the sensor to be register in the iio
    subsystem.
    
    Events can come at probe time (in case the kernel rebooted abruptly
    without switching the sensor off for  instance), and be sent to IIO core
    before the sensor is fully registered.
    
    Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")
    Reported-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20220711144716.642617-1-gwendal@chromium.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: fix iio_format_avail_range() printing for none IIO_VAL_INT [+ + +]
Author: Fawzi Khaber <fawzi.khaber@tdk.com>
Date:   Mon Jul 18 15:07:06 2022 +0200

    iio: fix iio_format_avail_range() printing for none IIO_VAL_INT
    
    commit 5e1f91850365de55ca74945866c002fda8f00331 upstream.
    
    iio_format_avail_range() should print range as follow [min, step, max], so
    the function was previously calling iio_format_list() with length = 3,
    length variable refers to the array size of values not the number of
    elements. In case of non IIO_VAL_INT values each element has integer part
    and decimal part. With length = 3 this would cause premature end of loop
    and result in printing only one element.
    
    Signed-off-by: Fawzi Khaber <fawzi.khaber@tdk.com>
    Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
    Fixes: eda20ba1e25e ("iio: core: Consolidate iio_format_avail_{list,range}()")
    Link: https://lore.kernel.org/r/20220718130706.32571-1-jmaneyrol@invensense.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: light: isl29028: Fix the warning in isl29028_remove() [+ + +]
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sun Jul 17 08:42:41 2022 +0800

    iio: light: isl29028: Fix the warning in isl29028_remove()
    
    commit 06674fc7c003b9d0aa1d37fef7ab2c24802cc6ad upstream.
    
    The driver use the non-managed form of the register function in
    isl29028_remove(). To keep the release order as mirroring the ordering
    in probe, the driver should use non-managed form in probe, too.
    
    The following log reveals it:
    
    [   32.374955] isl29028 0-0010: remove
    [   32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI
    [   32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
    [   32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0
    [   32.385461] Call Trace:
    [   32.385807]  sysfs_unmerge_group+0x59/0x110
    [   32.386110]  dpm_sysfs_remove+0x58/0xc0
    [   32.386391]  device_del+0x296/0xe50
    [   32.386959]  cdev_device_del+0x1d/0xd0
    [   32.387231]  devm_iio_device_unreg+0x27/0xb0
    [   32.387542]  devres_release_group+0x319/0x3d0
    [   32.388162]  i2c_device_remove+0x93/0x1f0
    
    Fixes: 2db5054ac28d ("staging: iio: isl29028: add runtime power management support")
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/20220717004241.2281028-1-zheyuma97@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>

 
inet: add READ_ONCE(sk->sk_bound_dev_if) in INET_MATCH() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 12 09:56:01 2022 -0700

    inet: add READ_ONCE(sk->sk_bound_dev_if) in INET_MATCH()
    
    [ Upstream commit 4915d50e300e96929d2462041d6f6c6f061167fd ]
    
    INET_MATCH() runs without holding a lock on the socket.
    
    We probably need to annotate most reads.
    
    This patch makes INET_MATCH() an inline function
    to ease our changes.
    
    v2:
    
    We remove the 32bit version of it, as modern compilers
    should generate the same code really, no need to
    try to be smarter.
    
    Also make 'struct net *net' the first argument.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: gscps2 - check return value of ioremap() in gscps2_probe() [+ + +]
Author: Xie Shaowen <studentxswpy@163.com>
Date:   Tue Aug 2 15:20:33 2022 +0800

    Input: gscps2 - check return value of ioremap() in gscps2_probe()
    
    commit e61b3125a4f036b3c6b87ffd656fc1ab00440ae9 upstream.
    
    The function ioremap() in gscps2_probe() can fail, so
    its return value should be checked.
    
    Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache")
    Cc: <stable@vger.kernel.org> # v5.6+
    Reported-by: Hacash Robot <hacashRobot@santino.com>
    Signed-off-by: Xie Shaowen <studentxswpy@163.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
intel_th: Fix a resource leak in an error handling path [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Jul 5 11:26:32 2022 +0300

    intel_th: Fix a resource leak in an error handling path
    
    [ Upstream commit 086c28ab7c5699256aced0049aae9c42f1410313 ]
    
    If an error occurs after calling 'pci_alloc_irq_vectors()',
    'pci_free_irq_vectors()' must be called as already done in the remove
    function.
    
    Fixes: 7b7036d47c35 ("intel_th: pci: Use MSI interrupt signalling")
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

intel_th: msu-sink: Potential dereference of null pointer [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Jul 5 11:26:33 2022 +0300

    intel_th: msu-sink: Potential dereference of null pointer
    
    [ Upstream commit 82f76a4a720791d889de775b5f7541d601efc8bd ]
    
    The return value of dma_alloc_coherent() needs to be checked.
    To avoid use of null pointer in sg_set_buf() in case of the failure of
    alloc.
    
    Fixes: f220df66f676 ("intel_th: msu-sink: An example msu buffer "sink"")
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-3-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

intel_th: msu: Fix vmalloced buffers [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jul 5 11:26:34 2022 +0300

    intel_th: msu: Fix vmalloced buffers
    
    [ Upstream commit ac12ad3ccf6d386e64a9d6a890595a2509d24edd ]
    
    After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's
    a chance of DMA buffer getting allocated via vmalloc(), which messes up
    the mmapping code:
    
    > RIP: msc_mmap_fault [intel_th_msu]
    > Call Trace:
    >  <TASK>
    >  __do_fault
    >  do_fault
    ...
    
    Fix this by accounting for vmalloc possibility.
    
    Fixes: ba39bd830605 ("intel_th: msu: Switch over to scatterlist")
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-4-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

intel_th: pci: Add Meteor Lake-P support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jul 5 11:26:35 2022 +0300

    intel_th: pci: Add Meteor Lake-P support
    
    [ Upstream commit 802a9a0b1d91274ef10d9fe429b4cc1e8c200aef ]
    
    Add support for the Trace Hub in Meteor Lake-P.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-5-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

intel_th: pci: Add Raptor Lake-S CPU support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jul 5 11:26:37 2022 +0300

    intel_th: pci: Add Raptor Lake-S CPU support
    
    [ Upstream commit ff46a601afc5a66a81c3945b83d0a2caeb88e8bc ]
    
    Add support for the Trace Hub in Raptor Lake-S CPU.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-7-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

intel_th: pci: Add Raptor Lake-S PCH support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jul 5 11:26:36 2022 +0300

    intel_th: pci: Add Raptor Lake-S PCH support
    
    [ Upstream commit 23e2de5826e2fc4dd43e08bab3a2ea1a5338b063 ]
    
    Add support for the Trace Hub in Raptor Lake-S PCH.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20220705082637.59979-6-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
interconnect: imx: fix max_node_id [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Jul 3 17:11:26 2022 +0800

    interconnect: imx: fix max_node_id
    
    [ Upstream commit bd734481e172b4827af09c9ab06c51d2ab7201e6 ]
    
    max_node_id not equal to the ARRAY_SIZE of node array, need increase 1,
    otherwise xlate will fail for the last entry. And rename max_node_id
    to num_nodes to reflect the reality.
    
    Fixes: f0d8048525d7d ("interconnect: Add imx core driver")
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20220703091132.1412063-5-peng.fan@oss.nxp.com
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring: mem-account pbuf buckets [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Aug 4 15:13:46 2022 +0100

    io_uring: mem-account pbuf buckets
    
    commit cc18cc5e82033d406f54144ad6f8092206004684 upstream.
    
    Potentially, someone may create as many pbuf bucket as there are indexes
    in an xarray without any other restrictions bounding our memory usage,
    put memory needed for the buckets under memory accounting.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/d34c452e45793e978d26e2606211ec9070d329ea.1659622312.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/arm-smmu: qcom_iommu: Add of_node_put() when breaking out of loop [+ + +]
Author: Liang He <windhl@126.com>
Date:   Tue Jul 19 20:49:55 2022 +0800

    iommu/arm-smmu: qcom_iommu: Add of_node_put() when breaking out of loop
    
    [ Upstream commit a91eb6803c1c715738682fece095145cbd68fe0b ]
    
    In qcom_iommu_has_secure_context(), we should call of_node_put()
    for the reference 'child' when breaking out of for_each_child_of_node()
    which will automatically increase and decrease the refcount.
    
    Fixes: d051f28c8807 ("iommu/qcom: Initialize secure page table")
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220719124955.1242171-1-windhl@126.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/exynos: Handle failed IOMMU device registration properly [+ + +]
Author: Sam Protsenko <semen.protsenko@linaro.org>
Date:   Thu Jul 14 19:55:46 2022 +0300

    iommu/exynos: Handle failed IOMMU device registration properly
    
    [ Upstream commit fce398d2d02c0a9a2bedf7c7201b123e153e8963 ]
    
    If iommu_device_register() fails in exynos_sysmmu_probe(), the previous
    calls have to be cleaned up. In this case, the iommu_device_sysfs_add()
    should be cleaned up, by calling its remove counterpart call.
    
    Fixes: d2c302b6e8b1 ("iommu/exynos: Make use of iommu_device_register interface")
    Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20220714165550.8884-3-semen.protsenko@linaro.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) [+ + +]
Author: Alexander Lobakin <alexandr.lobakin@intel.com>
Date:   Tue Jul 12 17:38:36 2022 +0200

    iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
    
    [ Upstream commit b0b0b77ea611e3088e9523e60860f4f41b62b235 ]
    
    KASAN reports:
    
    [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
    [    4.676149][    T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
    [    4.683454][    T0]
    [    4.685638][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
    [    4.694331][    T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
    [    4.703196][    T0] Call Trace:
    [    4.706334][    T0]  <TASK>
    [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
    
    after converting the type of the first argument (@nr, bit number)
    of arch_test_bit() from `long` to `unsigned long`[0].
    
    Under certain conditions (for example, when ACPI NUMA is disabled
    via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).
    It is valid 'magic' number of NUMA node, but not valid bit number
    to use in bitops.
    node_online() eventually descends to test_bit() without checking
    for the input, assuming it's on caller side (which might be good
    for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads
    to an insane array index when calculating bit position in memory.
    
    For now, add an explicit check for @node being not %NUMA_NO_NODE
    before calling test_bit(). The actual logics didn't change here
    at all.
    
    [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d
    
    Fixes: ee34b32d8c29 ("dmar: support for parsing Remapping Hardware Static Affinity structure")
    Cc: stable@vger.kernel.org # 2.6.33+
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: add READ_ONCE(sk->sk_bound_dev_if) in INET6_MATCH() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 13 11:55:49 2022 -0700

    ipv6: add READ_ONCE(sk->sk_bound_dev_if) in INET6_MATCH()
    
    [ Upstream commit 5d368f03280d3678433a7f119efe15dfbbb87bc8 ]
    
    INET6_MATCH() runs without holding a lock on the socket.
    
    We probably need to annotate most reads.
    
    This patch makes INET6_MATCH() an inline function
    to ease our changes.
    
    v2: inline function only defined if IS_ENABLED(CONFIG_IPV6)
        Change the name to inet6_match(), this is no longer a macro.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/mips-gic: Check the return value of ioremap() in gic_of_init() [+ + +]
Author: William Dean <williamsukatube@163.com>
Date:   Sat Jul 23 18:01:28 2022 +0800

    irqchip/mips-gic: Check the return value of ioremap() in gic_of_init()
    
    [ Upstream commit 71349cc85e5930dce78ed87084dee098eba24b59 ]
    
    The function ioremap() in gic_of_init() can fail, so
    its return value should be checked.
    
    Reported-by: Hacash Robot <hacashRobot@santino.com>
    Signed-off-by: William Dean <williamsukatube@163.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220723100128.2964304-1-williamsukatube@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

irqchip/mips-gic: Only register IPI domain when SMP is enabled [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Fri Jul 1 15:00:49 2022 -0500

    irqchip/mips-gic: Only register IPI domain when SMP is enabled
    
    [ Upstream commit 8190cc572981f2f13b6ffc26c7cfa7899e5d3ccc ]
    
    The MIPS GIC irqchip driver may be selected in a uniprocessor
    configuration, but it unconditionally registers an IPI domain.
    
    Limit the part of the driver dealing with IPIs to only be compiled when
    GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220701200056.46555-2-samuel@sholland.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqdomain: Report irq number for NOMAP domains [+ + +]
Author: Xu Qiang <xuqiang36@huawei.com>
Date:   Tue Jul 19 06:36:40 2022 +0000

    irqdomain: Report irq number for NOMAP domains
    
    [ Upstream commit 6f194c99f466147148cc08452718b46664112548 ]
    
    When using a NOMAP domain, __irq_resolve_mapping() doesn't store
    the Linux IRQ number at the address optionally provided by the caller.
    While this isn't a huge deal (the returned value is guaranteed
    to the hwirq that was passed as a parameter), let's honour the letter
    of the API by writing the expected value.
    
    Fixes: d22558dd0a6c (“irqdomain: Introduce irq_resolve_mapping()”)
    Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
    [maz: commit message]
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220719063641.56541-2-xuqiang36@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Jul 15 20:51:52 2022 +0800

    jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted
    
    [ Upstream commit 4a734f0869f970b8a9b65062ea40b09a5da9dba8 ]
    
    Following process will fail assertion 'jh->b_frozen_data == NULL' in
    jbd2_journal_dirty_metadata():
    
                       jbd2_journal_commit_transaction
    unlink(dir/a)
     jh->b_transaction = trans1
     jh->b_jlist = BJ_Metadata
                        journal->j_running_transaction = NULL
                        trans1->t_state = T_COMMIT
    unlink(dir/b)
     handle->h_trans = trans2
     do_get_write_access
      jh->b_modified = 0
      jh->b_frozen_data = frozen_buffer
      jh->b_next_transaction = trans2
     jbd2_journal_dirty_metadata
      is_handle_aborted
       is_journal_aborted // return false
    
               --> jbd2 abort <--
    
                         while (commit_transaction->t_buffers)
                          if (is_journal_aborted)
                           jbd2_journal_refile_buffer
                            __jbd2_journal_refile_buffer
                             WRITE_ONCE(jh->b_transaction,
                                                    jh->b_next_transaction)
                             WRITE_ONCE(jh->b_next_transaction, NULL)
                             __jbd2_journal_file_buffer(jh, BJ_Reserved)
            J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !
    
    The reproducer (See detail in [Link]) reports:
     ------------[ cut here ]------------
     kernel BUG at fs/jbd2/transaction.c:1629!
     invalid opcode: 0000 [#1] PREEMPT SMP
     CPU: 2 PID: 584 Comm: unlink Tainted: G        W
     5.19.0-rc6-00115-g4a57a8400075-dirty #697
     RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470
     RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202
     Call Trace:
      <TASK>
      __ext4_handle_dirty_metadata+0xa0/0x290
      ext4_handle_dirty_dirblock+0x10c/0x1d0
      ext4_delete_entry+0x104/0x200
      __ext4_unlink+0x22b/0x360
      ext4_unlink+0x275/0x390
      vfs_unlink+0x20b/0x4c0
      do_unlinkat+0x42f/0x4c0
      __x64_sys_unlink+0x37/0x50
      do_syscall_64+0x35/0x80
    
    After journal aborting, __jbd2_journal_refile_buffer() is executed with
    holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()'
    into the area protected by @jh->b_state_lock.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216251
    Fixes: 470decc613ab20 ("[PATCH] jbd2: initial copy of files from jbd")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20220715125152.4022726-1-chengzhihao1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: fix outstanding credits assert in jbd2_journal_commit_transaction() [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat Jun 11 21:04:26 2022 +0800

    jbd2: fix outstanding credits assert in jbd2_journal_commit_transaction()
    
    [ Upstream commit a89573ce4ad32f19f43ec669771726817e185be0 ]
    
    We catch an assert problem in jbd2_journal_commit_transaction() when
    doing fsstress and request falut injection tests. The problem is
    happened in a race condition between jbd2_journal_commit_transaction()
    and ext4_end_io_end(). Firstly, ext4_writepages() writeback dirty pages
    and start reserved handle, and then the journal was aborted due to some
    previous metadata IO error, jbd2_journal_abort() start to commit current
    running transaction, the committing procedure could be raced by
    ext4_end_io_end() and lead to subtract j_reserved_credits twice from
    commit_transaction->t_outstanding_credits, finally the
    t_outstanding_credits is mistakenly smaller than t_nr_buffers and
    trigger assert.
    
    kjournald2           kworker
    
    jbd2_journal_commit_transaction()
     write_unlock(&journal->j_state_lock);
     atomic_sub(j_reserved_credits, t_outstanding_credits); //sub once
    
                         jbd2_journal_start_reserved()
                          start_this_handle()  //detect aborted journal
                          jbd2_journal_free_reserved()  //get running transaction
                           read_lock(&journal->j_state_lock)
                            __jbd2_journal_unreserve_handle()
                           atomic_sub(j_reserved_credits, t_outstanding_credits);
                           //sub again
                           read_unlock(&journal->j_state_lock);
    
     journal->j_running_transaction = NULL;
     J_ASSERT(t_nr_buffers <= t_outstanding_credits) //bomb!!!
    
    Fix this issue by using journal->j_state_lock to protect the subtraction
    in jbd2_journal_commit_transaction().
    
    Fixes: 96f1e0974575 ("jbd2: avoid long hold times of j_state_lock while committing a transaction")
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220611130426.2013258-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kasan: test: Silence GCC 12 warnings [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 8 14:40:24 2022 -0700

    kasan: test: Silence GCC 12 warnings
    
    [ Upstream commit aaf50b1969d7933a51ea421b11432a7fb90974e3 ]
    
    GCC 12 continues to get smarter about array accesses. The KASAN tests
    are expecting to explicitly test out-of-bounds conditions at run-time,
    so hide the variable from GCC, to avoid warnings like:
    
    ../lib/test_kasan.c: In function 'ksize_uaf':
    ../lib/test_kasan.c:790:61: warning: array subscript 120 is outside array bounds of 'void[120]' [-Warray-bounds]
      790 |         KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[size]);
          |                                       ~~~~~~~~~~~~~~~~~~~~~~^~~~~~
    ../lib/test_kasan.c:97:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
       97 |         expression; \
          |         ^~~~~~~~~~
    
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: kasan-dev@googlegroups.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220608214024.1068451-1-keescook@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification [+ + +]
Author: Michal Suchanek <msuchanek@suse.de>
Date:   Thu Jul 14 21:40:27 2022 +0800

    kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification
    
    [ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ]
    
    commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
    adds support for KEXEC_SIG verification with keys from platform keyring
    but the built-in keys and secondary keyring are not used.
    
    Add support for the built-in keys and secondary keyring as x86 does.
    
    Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
    Cc: stable@vger.kernel.org
    Cc: Philipp Rudo <prudo@linux.ibm.com>
    Cc: kexec@lists.infradead.org
    Cc: keyrings@vger.kernel.org
    Cc: linux-security-module@vger.kernel.org
    Signed-off-by: Michal Suchanek <msuchanek@suse.de>
    Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
    Acked-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KEYS: asymmetric: enforce SM2 signature use pkey algo [+ + +]
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Tue Jun 28 11:37:20 2022 +0800

    KEYS: asymmetric: enforce SM2 signature use pkey algo
    
    [ Upstream commit 0815291a8fd66cdcf7db1445d4d99b0d16065829 ]
    
    The signature verification of SM2 needs to add the Za value and
    recalculate sig->digest, which requires the detection of the pkey_algo
    in public_key_verify_signature(). As Eric Biggers said, the pkey_algo
    field in sig is attacker-controlled and should be use pkey->pkey_algo
    instead of sig->pkey_algo, and secondly, if sig->pkey_algo is NULL, it
    will also cause signature verification failure.
    
    The software_key_determine_akcipher() already forces the algorithms
    are matched, so the SM3 algorithm is enforced in the SM2 signature,
    although this has been checked, we still avoid using any algorithm
    information in the signature as input.
    
    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
    Reported-by: Eric Biggers <ebiggers@google.com>
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kfifo: fix kfifo_to_user() return type [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 24 08:30:04 2022 +0300

    kfifo: fix kfifo_to_user() return type
    
    [ Upstream commit 045ed31e23aea840648c290dbde04797064960db ]
    
    The kfifo_to_user() macro is supposed to return zero for success or
    negative error codes.  Unfortunately, there is a signedness bug so it
    returns unsigned int.  This only affects callers which try to save the
    result in ssize_t and as far as I can see the only place which does that
    is line6_hwdep_read().
    
    TL;DR: s/_uint/_int/.
    
    Link: https://lkml.kernel.org/r/YrVL3OJVLlNhIMFs@kili
    Fixes: 144ecf310eb5 ("kfifo: fix kfifo_alloc() to return a signed int value")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Stefani Seibold <stefani@seibold.net>
    Cc: Randy Dunlap <randy.dunlap@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kprobes: Forbid probing on trampoline and BPF code areas [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Mon Aug 1 11:37:19 2022 +0800

    kprobes: Forbid probing on trampoline and BPF code areas
    
    [ Upstream commit 28f6c37a2910f565b4f5960df52b2eccae28c891 ]
    
    kernel_text_address() treats ftrace_trampoline, kprobe_insn_slot
    and bpf_text_address as valid kprobe addresses - which is not ideal.
    
    These text areas are removable and changeable without any notification
    to kprobes, and probing on them can trigger unexpected behavior:
    
      https://lkml.org/lkml/2022/7/26/1148
    
    Considering that jump_label and static_call text are already
    forbiden to probe, kernel_text_address() should be replaced with
    core_kernel_text() and is_module_text_address() to check other text
    areas which are unsafe to kprobe.
    
    [ mingo: Rewrote the changelog. ]
    
    Fixes: 5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text area")
    Fixes: 74451e66d516 ("bpf: make jited programs visible in traces")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Link: https://lore.kernel.org/r/20220801033719.228248-1-chenzhongjin@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: fix memory leak in smb2_handle_negotiate [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu Jul 28 21:56:19 2022 +0900

    ksmbd: fix memory leak in smb2_handle_negotiate
    
    commit aa7253c2393f6dcd6a1468b0792f6da76edad917 upstream.
    
    The allocated memory didn't free under an error
    path in smb2_handle_negotiate().
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17815
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: fix use-after-free bug in smb2_tree_disconect [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu Jul 28 21:57:08 2022 +0900

    ksmbd: fix use-after-free bug in smb2_tree_disconect
    
    commit cf6531d98190fa2cf92a6d8bbc8af0a4740a223c upstream.
    
    smb2_tree_disconnect() freed the struct ksmbd_tree_connect,
    but it left the dangling pointer. It can be accessed
    again under compound requests.
    
    This bug can lead an oops looking something link:
    
    [ 1685.468014 ] BUG: KASAN: use-after-free in ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
    [ 1685.468068 ] Read of size 4 at addr ffff888102172180 by task kworker/1:2/4807
    ...
    [ 1685.468130 ] Call Trace:
    [ 1685.468132 ]  <TASK>
    [ 1685.468135 ]  dump_stack_lvl+0x49/0x5f
    [ 1685.468141 ]  print_report.cold+0x5e/0x5cf
    [ 1685.468145 ]  ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
    [ 1685.468157 ]  kasan_report+0xaa/0x120
    [ 1685.468194 ]  ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
    [ 1685.468206 ]  __asan_report_load4_noabort+0x14/0x20
    [ 1685.468210 ]  ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]
    [ 1685.468222 ]  smb2_tree_disconnect+0x175/0x250 [ksmbd]
    [ 1685.468235 ]  handle_ksmbd_work+0x30e/0x1020 [ksmbd]
    [ 1685.468247 ]  process_one_work+0x778/0x11c0
    [ 1685.468251 ]  ? _raw_spin_lock_irq+0x8e/0xe0
    [ 1685.468289 ]  worker_thread+0x544/0x1180
    [ 1685.468293 ]  ? __cpuidle_text_end+0x4/0x4
    [ 1685.468297 ]  kthread+0x282/0x320
    [ 1685.468301 ]  ? process_one_work+0x11c0/0x11c0
    [ 1685.468305 ]  ? kthread_complete_and_exit+0x30/0x30
    [ 1685.468309 ]  ret_from_fork+0x1f/0x30
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17816
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: prevent out of bound read for SMB2_TREE_CONNNECT [+ + +]
Author: Hyunchul Lee <hyc.lee@gmail.com>
Date:   Thu Jul 28 21:58:53 2022 +0900

    ksmbd: prevent out of bound read for SMB2_TREE_CONNNECT
    
    commit 824d4f64c20093275f72fc8101394d75ff6a249e upstream.
    
    if Status is not 0 and PathLength is long,
    smb_strndup_from_utf16 could make out of bound
    read in smb2_tree_connnect.
    
    This bug can lead an oops looking something like:
    
    [ 1553.882047] BUG: KASAN: slab-out-of-bounds in smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
    [ 1553.882064] Read of size 2 at addr ffff88802c4eda04 by task kworker/0:2/42805
    ...
    [ 1553.882095] Call Trace:
    [ 1553.882098]  <TASK>
    [ 1553.882101]  dump_stack_lvl+0x49/0x5f
    [ 1553.882107]  print_report.cold+0x5e/0x5cf
    [ 1553.882112]  ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
    [ 1553.882122]  kasan_report+0xaa/0x120
    [ 1553.882128]  ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
    [ 1553.882139]  __asan_report_load_n_noabort+0xf/0x20
    [ 1553.882143]  smb_strndup_from_utf16+0x469/0x4c0 [ksmbd]
    [ 1553.882155]  ? smb_strtoUTF16+0x3b0/0x3b0 [ksmbd]
    [ 1553.882166]  ? __kmalloc_node+0x185/0x430
    [ 1553.882171]  smb2_tree_connect+0x140/0xab0 [ksmbd]
    [ 1553.882185]  handle_ksmbd_work+0x30e/0x1020 [ksmbd]
    [ 1553.882197]  process_one_work+0x778/0x11c0
    [ 1553.882201]  ? _raw_spin_lock_irq+0x8e/0xe0
    [ 1553.882206]  worker_thread+0x544/0x1180
    [ 1553.882209]  ? __cpuidle_text_end+0x4/0x4
    [ 1553.882214]  kthread+0x282/0x320
    [ 1553.882218]  ? process_one_work+0x11c0/0x11c0
    [ 1553.882221]  ? kthread_complete_and_exit+0x30/0x30
    [ 1553.882225]  ret_from_fork+0x1f/0x30
    [ 1553.882231]  </TASK>
    
    There is no need to check error request validation in server.
    This check allow invalid requests not to validate message.
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17818
    Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: arm64: Don't return from void function [+ + +]
Author: Quentin Perret <qperret@google.com>
Date:   Tue Jul 5 14:23:10 2022 +0000

    KVM: arm64: Don't return from void function
    
    [ Upstream commit 1c3ace2b8b3995d3213c5e2d2aca01a0577a3b0f ]
    
    Although harmless, the return statement in kvm_unexpected_el2_exception
    is rather confusing as the function itself has a void return type. The
    C standard is also pretty clear that "A return statement with an
    expression shall not appear in a function whose return type is void".
    Given that this return statement does not seem to add any actual value,
    let's not pointlessly violate the standard.
    
    Build-tested with GCC 10 and CLANG 13 for good measure, the disassembled
    code is identical with or without the return statement.
    
    Fixes: e9ee186bb735 ("KVM: arm64: Add kvm_extable for vaxorcism code")
    Signed-off-by: Quentin Perret <qperret@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220705142310.3847918-1-qperret@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: Don't set Accessed/Dirty bits for ZERO_PAGE [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Apr 29 01:04:09 2022 +0000

    KVM: Don't set Accessed/Dirty bits for ZERO_PAGE
    
    [ Upstream commit a1040b0d42acf69bb4f6dbdc54c2dcd78eea1de5 ]
    
    Don't set Accessed/Dirty bits for a struct page with PG_reserved set,
    i.e. don't set A/D bits for the ZERO_PAGE.  The ZERO_PAGE (or pages
    depending on the architecture) should obviously never be written, and
    similarly there's no point in marking it accessed as the page will never
    be swapped out or reclaimed.  The comment in page-flags.h is quite clear
    that PG_reserved pages should be managed only by their owner, and
    strictly following that mandate also simplifies KVM's logic.
    
    Fixes: 7df003c85218 ("KVM: fix overflow of zero page refcount with ksm running")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220429010416.2788472-4-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: nVMX: Account for KVM reserved CR4 bits in consistency checks [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 7 21:35:51 2022 +0000

    KVM: nVMX: Account for KVM reserved CR4 bits in consistency checks
    
    commit ca58f3aa53d165afe4ab74c755bc2f6d168617ac upstream.
    
    Check that the guest (L2) and host (L1) CR4 values that would be loaded
    by nested VM-Enter and VM-Exit respectively are valid with respect to
    KVM's (L0 host) allowed CR4 bits.  Failure to check KVM reserved bits
    would allow L1 to load an illegal CR4 (or trigger hardware VM-Fail or
    failed VM-Entry) by massaging guest CPUID to allow features that are not
    supported by KVM.  Amusingly, KVM itself is an accomplice in its doom, as
    KVM adjusts L1's MSR_IA32_VMX_CR4_FIXED1 to allow L1 to enable bits for
    L2 based on L1's CPUID model.
    
    Note, although nested_{guest,host}_cr4_valid() are _currently_ used if
    and only if the vCPU is post-VMXON (nested.vmxon == true), that may not
    be true in the future, e.g. emulating VMXON has a bug where it doesn't
    check the allowed/required CR0/CR4 bits.
    
    Cc: stable@vger.kernel.org
    Fixes: 3899152ccbf4 ("KVM: nVMX: fix checks on CR{0,4} during virtual VMX operation")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220607213604.3346000-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Always enable TSC scaling for L2 when it was enabled for L1 [+ + +]
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Tue Jul 12 15:50:09 2022 +0200

    KVM: nVMX: Always enable TSC scaling for L2 when it was enabled for L1
    
    commit 156b9d76e8822f2956c15029acf2d4b171502f3a upstream.
    
    Windows 10/11 guests with Hyper-V role (WSL2) enabled are observed to
    hang upon boot or shortly after when a non-default TSC frequency was
    set for L1. The issue is observed on a host where TSC scaling is
    supported. The problem appears to be that Windows doesn't use TSC
    scaling for its guests, even when the feature is advertised, and KVM
    filters SECONDARY_EXEC_TSC_SCALING out when creating L2 controls from
    L1's VMCS. This leads to L2 running with the default frequency (matching
    host's) while L1 is running with an altered one.
    
    Keep SECONDARY_EXEC_TSC_SCALING in secondary exec controls for L2 when
    it was set for L1. TSC_MULTIPLIER is already correctly computed and
    written by prepare_vmcs02().
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Fixes: d041b5ea93352b ("KVM: nVMX: Enable nested TSC scaling")
    Cc: stable@vger.kernel.org
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Link: https://lore.kernel.org/r/20220712135009.952805-1-vkuznets@redhat.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Attempt to load PERF_GLOBAL_CTRL on nVMX xfer iff it exists [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Jul 22 22:44:08 2022 +0000

    KVM: nVMX: Attempt to load PERF_GLOBAL_CTRL on nVMX xfer iff it exists
    
    [ Upstream commit 4496a6f9b45e8cd83343ad86a3984d614e22cf54 ]
    
    Attempt to load PERF_GLOBAL_CTRL during nested VM-Enter/VM-Exit if and
    only if the MSR exists (according to the guest vCPU model).  KVM has very
    misguided handling of VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL and
    attempts to force the nVMX MSR settings to match the vPMU model, i.e. to
    hide/expose the control based on whether or not the MSR exists from the
    guest's perspective.
    
    KVM's modifications fail to handle the scenario where the vPMU is hidden
    from the guest _after_ being exposed to the guest, e.g. by userspace
    doing multiple KVM_SET_CPUID2 calls, which is allowed if done before any
    KVM_RUN.  nested_vmx_pmu_refresh() is called if and only if there's a
    recognized vPMU, i.e. KVM will leave the bits in the allow state and then
    ultimately reject the MSR load and WARN.
    
    KVM should not force the VMX MSRs in the first place.  KVM taking control
    of the MSRs was a misguided attempt at mimicking what commit 5f76f6f5ff96
    ("KVM: nVMX: Do not expose MPX VMX controls when guest MPX disabled",
    2018-10-01) did for MPX.  However, the MPX commit was a workaround for
    another KVM bug and not something that should be imitated (and it should
    never been done in the first place).
    
    In other words, KVM's ABI _should_ be that userspace has full control
    over the MSRs, at which point triggering the WARN that loading the MSR
    must not fail is trivial.
    
    The intent of the WARN is still valid; KVM has consistency checks to
    ensure that vmcs12->{guest,host}_ia32_perf_global_ctrl is valid.  The
    problem is that '0' must be considered a valid value at all times, and so
    the simple/obvious solution is to just not actually load the MSR when it
    does not exist.  It is userspace's responsibility to provide a sane vCPU
    model, i.e. KVM is well within its ABI and Intel's VMX architecture to
    skip the loads if the MSR does not exist.
    
    Fixes: 03a8871add95 ("KVM: nVMX: Expose load IA32_PERF_GLOBAL_CTRL VM-{Entry,Exit} control")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220722224409.1336532-5-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4 [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 7 21:35:52 2022 +0000

    KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4
    
    commit c7d855c2aff2d511fd60ee2e356134c4fb394799 upstream.
    
    Inject a #UD if L1 attempts VMXON with a CR0 or CR4 that is disallowed
    per the associated nested VMX MSRs' fixed0/1 settings.  KVM cannot rely
    on hardware to perform the checks, even for the few checks that have
    higher priority than VM-Exit, as (a) KVM may have forced CR0/CR4 bits in
    hardware while running the guest, (b) there may incompatible CR0/CR4 bits
    that have lower priority than VM-Exit, e.g. CR0.NE, and (c) userspace may
    have further restricted the allowed CR0/CR4 values by manipulating the
    guest's nested VMX MSRs.
    
    Note, despite a very strong desire to throw shade at Jim, commit
    70f3aac964ae ("kvm: nVMX: Remove superfluous VMX instruction fault checks")
    is not to blame for the buggy behavior (though the comment...).  That
    commit only removed the CR0.PE, EFLAGS.VM, and COMPATIBILITY mode checks
    (though it did erroneously drop the CPL check, but that has already been
    remedied).  KVM may force CR0.PE=1, but will do so only when also
    forcing EFLAGS.VM=1 to emulate Real Mode, i.e. hardware will still #UD.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216033
    Fixes: ec378aeef9df ("KVM: nVMX: Implement VMXON and VMXOFF")
    Reported-by: Eric Li <ercli@ucdavis.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220607213604.3346000-4-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Let userspace set nVMX MSR to any _host_ supported value [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 7 21:35:54 2022 +0000

    KVM: nVMX: Let userspace set nVMX MSR to any _host_ supported value
    
    commit f8ae08f9789ad59d318ea75b570caa454aceda81 upstream.
    
    Restrict the nVMX MSRs based on KVM's config, not based on the guest's
    current config.  Using the guest's config to audit the new config
    prevents userspace from restoring the original config (KVM's config) if
    at any point in the past the guest's config was restricted in any way.
    
    Fixes: 62cc6b9dc61e ("KVM: nVMX: support restore of VMX capability MSRs")
    Cc: stable@vger.kernel.org
    Cc: David Matlack <dmatlack@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220607213604.3346000-6-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Set UMIP bit CR4_FIXED1 MSR when emulating UMIP [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 7 21:36:00 2022 +0000

    KVM: nVMX: Set UMIP bit CR4_FIXED1 MSR when emulating UMIP
    
    [ Upstream commit a910b5ab6b250a88fff1866bf708642d83317466 ]
    
    Make UMIP an "allowed-1" bit CR4_FIXED1 MSR when KVM is emulating UMIP.
    KVM emulates UMIP for both L1 and L2, and so should enumerate that L2 is
    allowed to have CR4.UMIP=1.  Not setting the bit doesn't immediately
    break nVMX, as KVM does set/clear the bit in CR4_FIXED1 in response to a
    guest CPUID update, i.e. KVM will correctly (dis)allow nested VM-Entry
    based on whether or not UMIP is exposed to L1.  That said, KVM should
    enumerate the bit as being allowed from time zero, e.g. userspace will
    see the wrong value if the MSR is read before CPUID is written.
    
    Fixes: 0367f205a3b7 ("KVM: vmx: add support for emulating UMIP")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220607213604.3346000-12-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: nVMX: Snapshot pre-VM-Enter BNDCFGS for !nested_run_pending case [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 14 21:58:27 2022 +0000

    KVM: nVMX: Snapshot pre-VM-Enter BNDCFGS for !nested_run_pending case
    
    commit fa578398a0ba2c079fa1170da21fa5baae0cedb2 upstream.
    
    If a nested run isn't pending, snapshot vmcs01.GUEST_BNDCFGS irrespective
    of whether or not VM_ENTRY_LOAD_BNDCFGS is set in vmcs12.  When restoring
    nested state, e.g. after migration, without a nested run pending,
    prepare_vmcs02() will propagate nested.vmcs01_guest_bndcfgs to vmcs02,
    i.e. will load garbage/zeros into vmcs02.GUEST_BNDCFGS.
    
    If userspace restores nested state before MSRs, then loading garbage is a
    non-issue as loading BNDCFGS will also update vmcs02.  But if usersepace
    restores MSRs first, then KVM is responsible for propagating L2's value,
    which is actually thrown into vmcs01, into vmcs02.
    
    Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state
    is all kinds of bizarre and ideally would not be supported.  Sadly, some
    VMMs do exactly that and rely on KVM to make things work.
    
    Note, there's still a lurking SMM bug, as propagating vmcs01.GUEST_BNDFGS
    to vmcs02 across RSM may corrupt L2's BNDCFGS.  But KVM's entire VMX+SMM
    emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the
    "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor.
    
    Link: https://lore.kernel.org/all/Yobt1XwOfb5M6Dfa@google.com
    Fixes: 62cf9bd8118c ("KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS")
    Cc: stable@vger.kernel.org
    Cc: Lei Wang <lei4.wang@intel.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220614215831.3762138-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Snapshot pre-VM-Enter DEBUGCTL for !nested_run_pending case [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 14 21:58:28 2022 +0000

    KVM: nVMX: Snapshot pre-VM-Enter DEBUGCTL for !nested_run_pending case
    
    commit 764643a6be07445308e492a528197044c801b3ba upstream.
    
    If a nested run isn't pending, snapshot vmcs01.GUEST_IA32_DEBUGCTL
    irrespective of whether or not VM_ENTRY_LOAD_DEBUG_CONTROLS is set in
    vmcs12.  When restoring nested state, e.g. after migration, without a
    nested run pending, prepare_vmcs02() will propagate
    nested.vmcs01_debugctl to vmcs02, i.e. will load garbage/zeros into
    vmcs02.GUEST_IA32_DEBUGCTL.
    
    If userspace restores nested state before MSRs, then loading garbage is a
    non-issue as loading DEBUGCTL will also update vmcs02.  But if usersepace
    restores MSRs first, then KVM is responsible for propagating L2's value,
    which is actually thrown into vmcs01, into vmcs02.
    
    Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state
    is all kinds of bizarre and ideally would not be supported.  Sadly, some
    VMMs do exactly that and rely on KVM to make things work.
    
    Note, there's still a lurking SMM bug, as propagating vmcs01's DEBUGCTL
    to vmcs02 across RSM may corrupt L2's DEBUGCTL.  But KVM's entire VMX+SMM
    emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the
    "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor.
    
    Link: https://lore.kernel.org/all/Yobt1XwOfb5M6Dfa@google.com
    Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220614215831.3762138-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: s390: pv: don't present the ecall interrupt twice [+ + +]
Author: Nico Boehr <nrb@linux.ibm.com>
Date:   Mon Jul 18 15:04:34 2022 +0200

    KVM: s390: pv: don't present the ecall interrupt twice
    
    commit c3f0e5fd2d33d80c5a5a8b5e5d2bab2841709cc8 upstream.
    
    When the SIGP interpretation facility is present and a VCPU sends an
    ecall to another VCPU in enabled wait, the sending VCPU receives a 56
    intercept (partial execution), so KVM can wake up the receiving CPU.
    Note that the SIGP interpretation facility will take care of the
    interrupt delivery and KVM's only job is to wake the receiving VCPU.
    
    For PV, the sending VCPU will receive a 108 intercept (pv notify) and
    should continue like in the non-PV case, i.e. wake the receiving VCPU.
    
    For PV and non-PV guests the interrupt delivery will occur through the
    SIGP interpretation facility on SIE entry when SIE finds the X bit in
    the status field set.
    
    However, in handle_pv_notification(), there was no special handling for
    SIGP, which leads to interrupt injection being requested by KVM for the
    next SIE entry. This results in the interrupt being delivered twice:
    once by the SIGP interpretation facility and once by KVM through the
    IICTL.
    
    Add the necessary special handling in handle_pv_notification(), similar
    to handle_partial_execution(), which simply wakes the receiving VCPU and
    leave interrupt delivery to the SIGP interpretation facility.
    
    In contrast to external calls, emergency calls are not interpreted but
    also cause a 108 intercept, which is why we still need to call
    handle_instruction() for SIGP orders other than ecall.
    
    Since kvm_s390_handle_sigp_pei() is now called for all SIGP orders which
    cause a 108 intercept - even if they are actually handled by
    handle_instruction() - move the tracepoint in kvm_s390_handle_sigp_pei()
    to avoid possibly confusing trace messages.
    
    Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
    Cc: <stable@vger.kernel.org> # 5.7
    Fixes: da24a0cc58ed ("KVM: s390: protvirt: Instruction emulation")
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220718130434.73302-1-nrb@linux.ibm.com
    Message-Id: <20220718130434.73302-1-nrb@linux.ibm.com>
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: s390: pv: leak the topmost page table when destroy fails [+ + +]
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Tue Jun 28 15:56:02 2022 +0200

    KVM: s390: pv: leak the topmost page table when destroy fails
    
    [ Upstream commit faa2f72cb3569256480c5540d242c84e99965160 ]
    
    Each secure guest must have a unique ASCE (address space control
    element); we must avoid that new guests use the same page for their
    ASCE, to avoid errors.
    
    Since the ASCE mostly consists of the address of the topmost page table
    (plus some flags), we must not return that memory to the pool unless
    the ASCE is no longer in use.
    
    Only a successful Destroy Secure Configuration UVC will make the ASCE
    reusable again.
    
    If the Destroy Configuration UVC fails, the ASCE cannot be reused for a
    secure guest (either for the ASCE or for other memory areas). To avoid
    a collision, it must not be used again. This is a permanent error and
    the page becomes in practice unusable, so we set it aside and leak it.
    On failure we already leak other memory that belongs to the ultravisor
    (i.e. the variable and base storage for a guest) and not leaking the
    topmost page table was an oversight.
    
    This error (and thus the leakage) should not happen unless the hardware
    is broken or KVM has some unknown serious bug.
    
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Fixes: 29b40f105ec8d55 ("KVM: s390: protvirt: Add initial vm and cpu lifecycle handling")
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220628135619.32410-2-imbrenda@linux.ibm.com
    Message-Id: <20220628135619.32410-2-imbrenda@linux.ibm.com>
    Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: set_msr_mce: Permit guests to ignore single-bit ECC errors [+ + +]
Author: Lev Kujawski <lkujaw@member.fsf.org>
Date:   Sat May 21 08:15:11 2022 +0000

    KVM: set_msr_mce: Permit guests to ignore single-bit ECC errors
    
    [ Upstream commit 0471a7bd1bca2a47a5f378f2222c5cf39ce94152 ]
    
    Certain guest operating systems (e.g., UNIXWARE) clear bit 0 of
    MC1_CTL to ignore single-bit ECC data errors.  Single-bit ECC data
    errors are always correctable and thus are safe to ignore because they
    are informational in nature rather than signaling a loss of data
    integrity.
    
    Prior to this patch, these guests would crash upon writing MC1_CTL,
    with resultant error messages like the following:
    
    error: kvm run failed Operation not permitted
    EAX=fffffffe EBX=fffffffe ECX=00000404 EDX=ffffffff
    ESI=ffffffff EDI=00000001 EBP=fffdaba4 ESP=fffdab20
    EIP=c01333a5 EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
    ES =0108 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
    CS =0100 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
    SS =0108 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
    DS =0108 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
    FS =0000 00000000 ffffffff 00c00000
    GS =0000 00000000 ffffffff 00c00000
    LDT=0118 c1026390 00000047 00008200 DPL=0 LDT
    TR =0110 ffff5af0 00000067 00008b00 DPL=0 TSS32-busy
    GDT=     ffff5020 000002cf
    IDT=     ffff52f0 000007ff
    CR0=8001003b CR2=00000000 CR3=0100a000 CR4=00000230
    DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
    DR6=ffff0ff0 DR7=00000400
    EFER=0000000000000000
    Code=08 89 01 89 51 04 c3 8b 4c 24 08 8b 01 8b 51 04 8b 4c 24 04 <0f>
    30 c3 f7 05 a4 6d ff ff 10 00 00 00 74 03 0f 31 c3 33 c0 33 d2 c3 8d
    74 26 00 0f 31 c3
    
    Signed-off-by: Lev Kujawski <lkujaw@member.fsf.org>
    Message-Id: <20220521081511.187388-1-lkujaw@member.fsf.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 [+ + +]
Author: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Date:   Mon May 2 00:07:26 2022 +0200

    KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
    
    commit f17c31c48e5cde9895a491d91c424eeeada3e134 upstream.
    
    Don't BUG/WARN on interrupt injection due to GIF being cleared,
    since it's trivial for userspace to force the situation via
    KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct
    for KVM internally generated injections).
    
      kernel BUG at arch/x86/kvm/svm/svm.c:3386!
      invalid opcode: 0000 [#1] SMP
      CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
      Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
      RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
      RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
      RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
      FS:  0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
      Call Trace:
       <TASK>
       inject_pending_event+0x2f7/0x4c0 [kvm]
       kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]
       kvm_vcpu_ioctl+0x26d/0x650 [kvm]
       __x64_sys_ioctl+0x82/0xb0
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
       </TASK>
    
    Fixes: 219b65dcf6c0 ("KVM: SVM: Improve nested interrupt injection")
    Cc: stable@vger.kernel.org
    Co-developed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Message-Id: <35426af6e123cbe91ec7ce5132ce72521f02b1b5.1651440202.git.maciej.szmigiero@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: SVM: Stuff next_rip on emulated INT3 injection if NRIPS is supported [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon May 2 00:07:28 2022 +0200

    KVM: SVM: Stuff next_rip on emulated INT3 injection if NRIPS is supported
    
    [ Upstream commit 3741aec4c38fa4123ab08ae552f05366d4fd05d8 ]
    
    If NRIPS is supported in hardware but disabled in KVM, set next_rip to
    the next RIP when advancing RIP as part of emulating INT3 injection.
    There is no flag to tell the CPU that KVM isn't using next_rip, and so
    leaving next_rip is left as is will result in the CPU pushing garbage
    onto the stack when vectoring the injected event.
    
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Fixes: 66b7138f9136 ("KVM: SVM: Emulate nRIP feature when reinjecting INT3")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Message-Id: <cd328309a3b88604daa2359ad56f36cb565ce2d4.1651440202.git.maciej.szmigiero@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails" [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon May 2 00:07:27 2022 +0200

    KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails"
    
    [ Upstream commit cd9e6da8048c5b40315ee2d929b6230ce1252c3c ]
    
    Unwind the RIP advancement done by svm_queue_exception() when injecting
    an INT3 ultimately "fails" due to the CPU encountering a VM-Exit while
    vectoring the injected event, even if the exception reported by the CPU
    isn't the same event that was injected.  If vectoring INT3 encounters an
    exception, e.g. #NP, and vectoring the #NP encounters an intercepted
    exception, e.g. #PF when KVM is using shadow paging, then the #NP will
    be reported as the event that was in-progress.
    
    Note, this is still imperfect, as it will get a false positive if the
    INT3 is cleanly injected, no VM-Exit occurs before the IRET from the INT3
    handler in the guest, the instruction following the INT3 generates an
    exception (directly or indirectly), _and_ vectoring that exception
    encounters an exception that is intercepted by KVM.  The false positives
    could theoretically be solved by further analyzing the vectoring event,
    e.g. by comparing the error code against the expected error code were an
    exception to occur when vectoring the original injected exception, but
    SVM without NRIPS is a complete disaster, trying to make it 100% correct
    is a waste of time.
    
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Fixes: 66b7138f9136 ("KVM: SVM: Emulate nRIP feature when reinjecting INT3")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Message-Id: <450133cf0a026cb9825a2ff55d02cb136a1cb111.1651440202.git.maciej.szmigiero@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Add helper to check if the guest PMU has PERF_GLOBAL_CTRL [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Jul 22 22:44:07 2022 +0000

    KVM: VMX: Add helper to check if the guest PMU has PERF_GLOBAL_CTRL
    
    [ Upstream commit b663f0b5f3d665c261256d1f76e98f077c6e56af ]
    
    Add a helper to check of the guest PMU has PERF_GLOBAL_CTRL, which is
    unintuitive _and_ diverges from Intel's architecturally defined behavior.
    Even worse, KVM currently implements the check using two different (but
    equivalent) checks, _and_ there has been at least one attempt to add a
    _third_ flavor.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220722224409.1336532-4-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Mark all PERF_GLOBAL_(OVF)_CTRL bits reserved if there's no vPMU [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Jul 22 22:44:06 2022 +0000

    KVM: VMX: Mark all PERF_GLOBAL_(OVF)_CTRL bits reserved if there's no vPMU
    
    [ Upstream commit 93255bf92939d948bc86d81c6bb70bb0fecc5db1 ]
    
    Mark all MSR_CORE_PERF_GLOBAL_CTRL and MSR_CORE_PERF_GLOBAL_OVF_CTRL bits
    as reserved if there is no guest vPMU.  The nVMX VM-Entry consistency
    checks do not check for a valid vPMU prior to consuming the masks via
    kvm_valid_perf_global_ctrl(), i.e. may incorrectly allow a non-zero mask
    to be loaded via VM-Enter or VM-Exit (well, attempted to be loaded, the
    actual MSR load will be rejected by intel_is_valid_msr()).
    
    Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220722224409.1336532-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/pmu: Ignore pmu->global_ctrl check if vPMU doesn't support global_ctrl [+ + +]
Author: Like Xu <likexu@tencent.com>
Date:   Mon May 9 18:22:02 2022 +0800

    KVM: x86/pmu: Ignore pmu->global_ctrl check if vPMU doesn't support global_ctrl
    
    [ Upstream commit 98defd2e17803263f49548fea930cfc974d505aa ]
    
    MSR_CORE_PERF_GLOBAL_CTRL is introduced as part of Architecture PMU V2,
    as indicated by Intel SDM 19.2.2 and the intel_is_valid_msr() function.
    
    So in the absence of global_ctrl support, all PMCs are enabled as AMD does.
    
    Signed-off-by: Like Xu <likexu@tencent.com>
    Message-Id: <20220509102204.62389-1-likexu@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/pmu: Introduce the ctrl_mask value for fixed counter [+ + +]
Author: Like Xu <like.xu@linux.intel.com>
Date:   Mon Apr 11 18:19:34 2022 +0800

    KVM: x86/pmu: Introduce the ctrl_mask value for fixed counter
    
    [ Upstream commit 2c985527dd8d283e786ad7a67e532ef7f6f00fac ]
    
    The mask value of fixed counter control register should be dynamic
    adjusted with the number of fixed counters. This patch introduces a
    variable that includes the reserved bits of fixed counter control
    registers. This is a generic code refactoring.
    
    Co-developed-by: Luwei Kang <luwei.kang@intel.com>
    Signed-off-by: Luwei Kang <luwei.kang@intel.com>
    Signed-off-by: Like Xu <like.xu@linux.intel.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Message-Id: <20220411101946.20262-6-likexu@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86: do not report preemption if the steal time cache is stale [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Aug 4 15:28:32 2022 +0200

    KVM: x86: do not report preemption if the steal time cache is stale
    
    commit c3c28d24d910a746b02f496d190e0e8c6560224b upstream.
    
    Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time
    / preempted status", 2021-11-11) open coded the previous call to
    kvm_map_gfn, but in doing so it dropped the comparison between the cached
    guest physical address and the one in the MSR.  This cause an incorrect
    cache hit if the guest modifies the steal time address while the memslots
    remain the same.  This can happen with kexec, in which case the preempted
    bit is written at the address used by the old kernel instead of
    the old one.
    
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: stable@vger.kernel.org
    Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Mark TSS busy during LTR emulation _after_ all fault checks [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon Jul 11 23:27:48 2022 +0000

    KVM: x86: Mark TSS busy during LTR emulation _after_ all fault checks
    
    commit ec6e4d863258d4bfb36d48d5e3ef68140234d688 upstream.
    
    Wait to mark the TSS as busy during LTR emulation until after all fault
    checks for the LTR have passed.  Specifically, don't mark the TSS busy if
    the new TSS base is non-canonical.
    
    Opportunistically drop the one-off !seg_desc.PRESENT check for TR as the
    only reason for the early check was to avoid marking a !PRESENT TSS as
    busy, i.e. the common !PRESENT is now done before setting the busy bit.
    
    Fixes: e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR")
    Reported-by: syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Cc: Hou Wenlong <houwenlong.hwl@antgroup.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Link: https://lore.kernel.org/r/20220711232750.1092012-2-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: revalidate steal time cache if MSR value changes [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Aug 4 15:28:32 2022 +0200

    KVM: x86: revalidate steal time cache if MSR value changes
    
    commit 901d3765fa804ce42812f1d5b1f3de2dfbb26723 upstream.
    
    Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time
    / preempted status", 2021-11-11) open coded the previous call to
    kvm_map_gfn, but in doing so it dropped the comparison between the cached
    guest physical address and the one in the MSR.  This cause an incorrect
    cache hit if the guest modifies the steal time address while the memslots
    remain the same.  This can happen with kexec, in which case the steal
    time data is written at the address used by the old kernel instead of
    the old one.
    
    While at it, rename the variable from gfn to gpa since it is a plain
    physical address and not a right-shifted one.
    
    Reported-by: Dave Young <ruyang@redhat.com>
    Reported-by: Xiaoying Yan  <yiyan@redhat.com>
    Analyzed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: stable@vger.kernel.org
    Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Set error code to segment selector on LLDT/LTR non-canonical #GP [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon Jul 11 23:27:49 2022 +0000

    KVM: x86: Set error code to segment selector on LLDT/LTR non-canonical #GP
    
    commit 2626206963ace9e8bf92b6eea5ff78dd674c555c upstream.
    
    When injecting a #GP on LLDT/LTR due to a non-canonical LDT/TSS base, set
    the error code to the selector.  Intel SDM's says nothing about the #GP,
    but AMD's APM explicitly states that both LLDT and LTR set the error code
    to the selector, not zero.
    
    Note, a non-canonical memory operand on LLDT/LTR does generate a #GP(0),
    but the KVM code in question is specific to the base from the descriptor.
    
    Fixes: e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Link: https://lore.kernel.org/r/20220711232750.1092012-3-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Signal #GP, not -EPERM, on bad WRMSR(MCi_CTL/STATUS) [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu May 12 22:27:14 2022 +0000

    KVM: x86: Signal #GP, not -EPERM, on bad WRMSR(MCi_CTL/STATUS)
    
    [ Upstream commit 2368048bf5c2ec4b604ac3431564071e89a0bc71 ]
    
    Return '1', not '-1', when handling an illegal WRMSR to a MCi_CTL or
    MCi_STATUS MSR.  The behavior of "all zeros' or "all ones" for CTL MSRs
    is architectural, as is the "only zeros" behavior for STATUS MSRs.  I.e.
    the intent is to inject a #GP, not exit to userspace due to an unhandled
    emulation case.  Returning '-1' gets interpreted as -EPERM up the stack
    and effecitvely kills the guest.
    
    Fixes: 890ca9aefa78 ("KVM: Add MCE support")
    Fixes: 9ffd986c6e4e ("KVM: X86: #GP when guest attempts to write MCi_STATUS register w/o 0")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Link: https://lore.kernel.org/r/20220512222716.4112548-2-seanjc@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86: Split kvm_is_valid_cr4() and export only the non-vendor bits [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 7 21:35:50 2022 +0000

    KVM: x86: Split kvm_is_valid_cr4() and export only the non-vendor bits
    
    commit c33f6f2228fe8517e38941a508e9f905f99ecba9 upstream.
    
    Split the common x86 parts of kvm_is_valid_cr4(), i.e. the reserved bits
    checks, into a separate helper, __kvm_is_valid_cr4(), and export only the
    inner helper to vendor code in order to prevent nested VMX from calling
    back into vmx_is_valid_cr4() via kvm_is_valid_cr4().
    
    On SVM, this is a nop as SVM doesn't place any additional restrictions on
    CR4.
    
    On VMX, this is also currently a nop, but only because nested VMX is
    missing checks on reserved CR4 bits for nested VM-Enter.  That bug will
    be fixed in a future patch, and could simply use kvm_is_valid_cr4() as-is,
    but nVMX has _another_ bug where VMXON emulation doesn't enforce VMX's
    restrictions on CR0/CR4.  The cleanest and most intuitive way to fix the
    VMXON bug is to use nested_host_cr{0,4}_valid().  If the CR4 variant
    routes through kvm_is_valid_cr4(), using nested_host_cr4_valid() won't do
    the right thing for the VMXON case as vmx_is_valid_cr4() enforces VMX's
    restrictions if and only if the vCPU is post-VMXON.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220607213604.3346000-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Tag kvm_mmu_x86_module_init() with __init [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Aug 3 22:49:55 2022 +0000

    KVM: x86: Tag kvm_mmu_x86_module_init() with __init
    
    commit 982bae43f11c37b51d2f1961bb25ef7cac3746fa upstream.
    
    Mark kvm_mmu_x86_module_init() with __init, the entire reason it exists
    is to initialize variables when kvm.ko is loaded, i.e. it must never be
    called after module initialization.
    
    Fixes: 1d0e84806047 ("KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded")
    Cc: stable@vger.kernel.org
    Reviewed-by: Kai Huang <kai.huang@intel.com>
    Tested-by: Michael Roth <michael.roth@amd.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220803224957.1285926-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lib/smp_processor_id: fix imbalanced instrumentation_end() call [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Wed Jun 22 14:46:31 2022 +0900

    lib/smp_processor_id: fix imbalanced instrumentation_end() call
    
    [ Upstream commit bd27acaac24e4b252ee28dddcabaee80456d0faf ]
    
    Currently instrumentation_end() won't be called if printk_ratelimit()
    returned false.
    
    Link: https://lkml.kernel.org/r/a636d8e0-ad32-5888-acac-671f7f553bb3@I-love.SAKURA.ne.jp
    Fixes: 126f21f0e8d46e2c ("lib/smp_processor_id: Move it into noinstr section")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lib/test_hmm: avoid accessing uninitialized pages [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Thu Jun 9 21:08:35 2022 +0800

    lib/test_hmm: avoid accessing uninitialized pages
    
    [ Upstream commit ed913b055a74b723976f8e885a3395162a0371e6 ]
    
    If make_device_exclusive_range() fails or returns pages marked for
    exclusive access less than required, remaining fields of pages will left
    uninitialized.  So dmirror_atomic_map() will access those yet
    uninitialized fields of pages.  To fix it, do dmirror_atomic_map() iff all
    pages are marked for exclusive access (we will break if mapped is less
    than required anyway) so we won't access those uninitialized fields of
    pages.
    
    Link: https://lkml.kernel.org/r/20220609130835.35110-1-linmiaohe@huawei.com
    Fixes: b659baea7546 ("mm: selftests for exclusive device memory")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Alistair Popple <apopple@nvidia.com>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Ralph Campbell <rcampbell@nvidia.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libbpf: fix an snprintf() overflow check [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jul 19 12:51:28 2022 +0300

    libbpf: fix an snprintf() overflow check
    
    [ Upstream commit b77ffb30cfc5f58e957571d8541c6a7e3da19221 ]
    
    The snprintf() function returns the number of bytes it *would* have
    copied if there were enough space.  So it can return > the
    sizeof(gen->attach_target).
    
    Fixes: 67234743736a ("libbpf: Generate loader program out of BPF ELF file.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/YtZ+oAySqIhFl6/J@kili
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

libbpf: Fix the name of a reused map [+ + +]
Author: Anquan Wu <leiqi96@hotmail.com>
Date:   Tue Jul 12 11:15:40 2022 +0800

    libbpf: Fix the name of a reused map
    
    [ Upstream commit bf3f00378524adae16628cbadbd11ba7211863bb ]
    
    BPF map name is limited to BPF_OBJ_NAME_LEN.
    A map name is defined as being longer than BPF_OBJ_NAME_LEN,
    it will be truncated to BPF_OBJ_NAME_LEN when a userspace program
    calls libbpf to create the map. A pinned map also generates a path
    in the /sys. If the previous program wanted to reuse the map,
    it can not get bpf_map by name, because the name of the map is only
    partially the same as the name which get from pinned path.
    
    The syscall information below show that map name "process_pinned_map"
    is truncated to "process_pinned_".
    
        bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/process_pinned_map",
        bpf_fd=0, file_flags=0}, 144) = -1 ENOENT (No such file or directory)
    
        bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4,
        value_size=4,max_entries=1024, map_flags=0, inner_map_fd=0,
        map_name="process_pinned_",map_ifindex=0, btf_fd=3, btf_key_type_id=6,
        btf_value_type_id=10,btf_vmlinux_value_type_id=0}, 72) = 4
    
    This patch check that if the name of pinned map are the same as the
    actual name for the first (BPF_OBJ_NAME_LEN - 1),
    bpf map still uses the name which is included in bpf object.
    
    Fixes: 26736eb9a483 ("tools: libbpf: allow map reuse")
    Signed-off-by: Anquan Wu <leiqi96@hotmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/OSZP286MB1725CEA1C95C5CB8E7CCC53FB8869@OSZP286MB1725.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.61 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 17 14:24:32 2022 +0200

    Linux 5.15.61
    
    Link: https://lore.kernel.org/r/20220815180337.130757997@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://lore.kernel.org/r/20220816124544.577833376@linuxfoundation.org
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lockd: detect and reject lock arguments that overflow [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Mon Aug 1 15:57:26 2022 -0400

    lockd: detect and reject lock arguments that overflow
    
    commit 6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde upstream.
    
    lockd doesn't currently vet the start and length in nlm4 requests like
    it should, and can end up generating lock requests with arguments that
    overflow when passed to the filesystem.
    
    The NLM4 protocol uses unsigned 64-bit arguments for both start and
    length, whereas struct file_lock tracks the start and end as loff_t
    values. By the time we get around to calling nlm4svc_retrieve_args,
    we've lost the information that would allow us to determine if there was
    an overflow.
    
    Start tracking the actual start and len for NLM4 requests in the
    nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they
    won't cause an overflow, and return NLM4_FBIG if they do.
    
    Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392
    Reported-by: Jan Kasiak <j.kasiak@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Cc: <stable@vger.kernel.org> # 5.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
locking/csd_lock: Change csdlock_debug from early_param to __setup [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Tue May 10 17:46:39 2022 +0800

    locking/csd_lock: Change csdlock_debug from early_param to __setup
    
    [ Upstream commit 9c9b26b0df270d4f9246e483a44686fca951a29c ]
    
    The csdlock_debug kernel-boot parameter is parsed by the
    early_param() function csdlock_debug().  If set, csdlock_debug()
    invokes static_branch_enable() to enable csd_lock_wait feature, which
    triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and
    CONFIG_SPARSEMEM_VMEMMAP=n.
    
    With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in
    static_key_enable() and returns NULL, resulting in a NULL dereference
    because mem_section is initialized only later in sparse_init().
    
    This is also a problem for powerpc because early_param() functions
    are invoked earlier than jump_label_init(), also resulting in
    static_key_enable() failures.  These failures cause the warning "static
    key 'xxx' used before call to jump_label_init()".
    
    Thus, early_param is too early for csd_lock_wait to run
    static_branch_enable(), so changes it to __setup to fix these.
    
    Fixes: 8d0968cc6b8f ("locking/csd_lock: Add boot parameter for controlling CSD lock debugging")
    Cc: stable@vger.kernel.org
    Reported-by: Chen jingwen <chenjingwen6@huawei.com>
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
locking/lockdep: Fix lockdep_init_map_*() confusion [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 17 15:26:06 2022 +0200

    locking/lockdep: Fix lockdep_init_map_*() confusion
    
    [ Upstream commit eae6d58d67d9739be5f7ae2dbead1d0ef6528243 ]
    
    Commit dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t") added yet
    another lockdep_init_map_*() variant, but forgot to update all the
    existing users of the most complicated version.
    
    This could lead to a loss of lock_type and hence an incorrect report.
    Given the relative rarity of both local_lock and these annotations,
    this is unlikely to happen in practise, still, best fix things.
    
    Fixes: dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/YqyEDtoan20K0CVD@worktop.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mac80211: fix a memory leak where sta_info is not freed [+ + +]
Author: Ahmed Zaki <anzaki@gmail.com>
Date:   Sat Oct 2 08:53:29 2021 -0600

    mac80211: fix a memory leak where sta_info is not freed
    
    commit 8f9dcc29566626f683843ccac6113a12208315ca upstream.
    
    The following is from a system that went OOM due to a memory leak:
    
    wlan0: Allocated STA 74:83:c2:64:0b:87
    wlan0: Allocated STA 74:83:c2:64:0b:87
    wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_add_sta)
    wlan0: Adding new IBSS station 74:83:c2:64:0b:87
    wlan0: moving STA 74:83:c2:64:0b:87 to state 2
    wlan0: moving STA 74:83:c2:64:0b:87 to state 3
    wlan0: Inserted STA 74:83:c2:64:0b:87
    wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_work)
    wlan0: Adding new IBSS station 74:83:c2:64:0b:87
    wlan0: moving STA 74:83:c2:64:0b:87 to state 2
    wlan0: moving STA 74:83:c2:64:0b:87 to state 3
    .
    .
    wlan0: expiring inactive not authorized STA 74:83:c2:64:0b:87
    wlan0: moving STA 74:83:c2:64:0b:87 to state 2
    wlan0: moving STA 74:83:c2:64:0b:87 to state 1
    wlan0: Removed STA 74:83:c2:64:0b:87
    wlan0: Destroyed STA 74:83:c2:64:0b:87
    
    The ieee80211_ibss_finish_sta() is called twice on the same STA from 2
    different locations. On the second attempt, the allocated STA is not
    destroyed creating a kernel memory leak.
    
    This is happening because sta_info_insert_finish() does not call
    sta_info_free() the second time when the STA already exists (returns
    -EEXIST). Note that the caller sta_info_insert_rcu() assumes STA is
    destroyed upon errors.
    
    Same fix is applied to -ENOMEM.
    
    Signed-off-by: Ahmed Zaki <anzaki@gmail.com>
    Link: https://lore.kernel.org/r/20211002145329.3125293-1-anzaki@gmail.com
    [change the error path label to use the existing code]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Viacheslav Sablin <sablin@ispras.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Makefile: link with -z noexecstack --no-warn-rwx-segments [+ + +]
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Wed Aug 10 15:24:40 2022 -0700

    Makefile: link with -z noexecstack --no-warn-rwx-segments
    
    commit 0d362be5b14200b77ecc2127936a5ff82fbffe41 upstream.
    
    Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
    instances of a new warning when linking kernels in the form:
    
      ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack
      ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
      ld: warning: vmlinux has a LOAD segment with RWX permissions
    
    Generally, we would like to avoid the stack being executable.  Because
    there could be a need for the stack to be executable, assembler sources
    have to opt-in to this security feature via explicit creation of the
    .note.GNU-stack feature (which compilers create by default) or command
    line flag --noexecstack.  Or we can simply tell the linker the
    production of such sections is irrelevant and to link the stack as
    --noexecstack.
    
    LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
    strictly necessary when linking with LLD, only BFD, but it doesn't hurt
    to be explicit here for all linkers IMO.  --no-warn-rwx-segments is
    currently BFD specific and only available in the current latest release,
    so it's wrapped in an ld-option check.
    
    While the kernel makes extensive usage of ELF sections, it doesn't use
    permissions from ELF segments.
    
    Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/
    Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
    Link: https://github.com/llvm/llvm-project/issues/57009
    Reported-and-tested-by: Jens Axboe <axboe@kernel.dk>
    Suggested-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
mbcache: add functions to delete entry if unused [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:21 2022 +0200

    mbcache: add functions to delete entry if unused
    
    commit 3dc96bba65f53daa217f0a8f43edad145286a8f5 upstream.
    
    Add function mb_cache_entry_delete_or_get() to delete mbcache entry if
    it is unused and also add a function to wait for entry to become unused
    - mb_cache_entry_wait_unused(). We do not share code between the two
    deleting function as one of them will go away soon.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-2-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mbcache: don't reclaim used entries [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:20 2022 +0200

    mbcache: don't reclaim used entries
    
    commit 58318914186c157477b978b1739dfe2f1b9dc0fe upstream.
    
    Do not reclaim entries that are currently used by somebody from a
    shrinker. Firstly, these entries are likely useful. Secondly, we will
    need to keep such entries to protect pending increment of xattr block
    refcount.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md-raid10: fix KASAN warning [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jul 26 04:33:12 2022 -0400

    md-raid10: fix KASAN warning
    
    commit d17f744e883b2f8d13cca252d71cfe8ace346f7d upstream.
    
    There's a KASAN warning in raid10_remove_disk when running the lvm
    test lvconvert-raid-reshape.sh. We fix this warning by verifying that the
    value "number" is valid.
    
    BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
    Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682
    
    CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x34/0x44
     print_report.cold+0x45/0x57a
     ? __lock_text_start+0x18/0x18
     ? raid10_remove_disk+0x61/0x2a0 [raid10]
     kasan_report+0xa8/0xe0
     ? raid10_remove_disk+0x61/0x2a0 [raid10]
     raid10_remove_disk+0x61/0x2a0 [raid10]
    Buffer I/O error on dev dm-76, logical block 15344, async page read
     ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0
     remove_and_add_spares+0x367/0x8a0 [md_mod]
     ? super_written+0x1c0/0x1c0 [md_mod]
     ? mutex_trylock+0xac/0x120
     ? _raw_spin_lock+0x72/0xc0
     ? _raw_spin_lock_bh+0xc0/0xc0
     md_check_recovery+0x848/0x960 [md_mod]
     raid10d+0xcf/0x3360 [raid10]
     ? sched_clock_cpu+0x185/0x1a0
     ? rb_erase+0x4d4/0x620
     ? var_wake_function+0xe0/0xe0
     ? psi_group_change+0x411/0x500
     ? preempt_count_sub+0xf/0xc0
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? __lock_text_start+0x18/0x18
     ? raid10_sync_request+0x36c0/0x36c0 [raid10]
     ? preempt_count_sub+0xf/0xc0
     ? _raw_spin_unlock_irqrestore+0x19/0x40
     ? del_timer_sync+0xa9/0x100
     ? try_to_del_timer_sync+0xc0/0xc0
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? __lock_text_start+0x18/0x18
     ? _raw_spin_unlock_irq+0x11/0x24
     ? __list_del_entry_valid+0x68/0xa0
     ? finish_wait+0xa3/0x100
     md_thread+0x161/0x260 [md_mod]
     ? unregister_md_personality+0xa0/0xa0 [md_mod]
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? prepare_to_wait_event+0x2c0/0x2c0
     ? unregister_md_personality+0xa0/0xa0 [md_mod]
     kthread+0x148/0x180
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Allocated by task 124495:
     kasan_save_stack+0x1e/0x40
     __kasan_kmalloc+0x80/0xa0
     setup_conf+0x140/0x5c0 [raid10]
     raid10_run+0x4cd/0x740 [raid10]
     md_run+0x6f9/0x1300 [md_mod]
     raid_ctr+0x2531/0x4ac0 [dm_raid]
     dm_table_add_target+0x2b0/0x620 [dm_mod]
     table_load+0x1c8/0x400 [dm_mod]
     ctl_ioctl+0x29e/0x560 [dm_mod]
     dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
     __do_compat_sys_ioctl+0xfa/0x160
     do_syscall_64+0x90/0xc0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Last potentially related work creation:
     kasan_save_stack+0x1e/0x40
     __kasan_record_aux_stack+0x9e/0xc0
     kvfree_call_rcu+0x84/0x480
     timerfd_release+0x82/0x140
    L __fput+0xfa/0x400
     task_work_run+0x80/0xc0
     exit_to_user_mode_prepare+0x155/0x160
     syscall_exit_to_user_mode+0x12/0x40
     do_syscall_64+0x42/0xc0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Second to last potentially related work creation:
     kasan_save_stack+0x1e/0x40
     __kasan_record_aux_stack+0x9e/0xc0
     kvfree_call_rcu+0x84/0x480
     timerfd_release+0x82/0x140
     __fput+0xfa/0x400
     task_work_run+0x80/0xc0
     exit_to_user_mode_prepare+0x155/0x160
     syscall_exit_to_user_mode+0x12/0x40
     do_syscall_64+0x42/0xc0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    The buggy address belongs to the object at ffff889108f3d200
     which belongs to the cache kmalloc-256 of size 256
    The buggy address is located 0 bytes to the right of
     256-byte region [ffff889108f3d200, ffff889108f3d300)
    
    The buggy address belongs to the physical page:
    page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c
    head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0
    flags: 0x4000000000010200(slab|head|zone=2)
    raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40
    raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff889108f3d280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff889108f3d300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                       ^
     ffff889108f3d380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff889108f3d400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md-raid: destroy the bitmap after destroying the thread [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sun Jul 24 14:26:12 2022 -0400

    md-raid: destroy the bitmap after destroying the thread
    
    commit e151db8ecfb019b7da31d076130a794574c89f6f upstream.
    
    When we ran the lvm test "shell/integrity-blocksize-3.sh" on a kernel with
    kasan, we got failure in write_page.
    
    The reason for the failure is that md_bitmap_destroy is called before
    destroying the thread and the thread may be waiting in the function
    write_page for the bio to complete. When the thread finishes waiting, it
    executes "if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags))", which
    triggers the kasan warning.
    
    Note that the commit 48df498daf62 that caused this bug claims that it is
    neede for md-cluster, you should check md-cluster and possibly find
    another bugfix for it.
    
    BUG: KASAN: use-after-free in write_page+0x18d/0x680 [md_mod]
    Read of size 8 at addr ffff889162030c78 by task mdX_raid1/5539
    
    CPU: 10 PID: 5539 Comm: mdX_raid1 Not tainted 5.19.0-rc2 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x34/0x44
     print_report.cold+0x45/0x57a
     ? __lock_text_start+0x18/0x18
     ? write_page+0x18d/0x680 [md_mod]
     kasan_report+0xa8/0xe0
     ? write_page+0x18d/0x680 [md_mod]
     kasan_check_range+0x13f/0x180
     write_page+0x18d/0x680 [md_mod]
     ? super_sync+0x4d5/0x560 [dm_raid]
     ? md_bitmap_file_kick+0xa0/0xa0 [md_mod]
     ? rs_set_dev_and_array_sectors+0x2e0/0x2e0 [dm_raid]
     ? mutex_trylock+0x120/0x120
     ? preempt_count_add+0x6b/0xc0
     ? preempt_count_sub+0xf/0xc0
     md_update_sb+0x707/0xe40 [md_mod]
     md_reap_sync_thread+0x1b2/0x4a0 [md_mod]
     md_check_recovery+0x533/0x960 [md_mod]
     raid1d+0xc8/0x2a20 [raid1]
     ? var_wake_function+0xe0/0xe0
     ? psi_group_change+0x411/0x500
     ? preempt_count_sub+0xf/0xc0
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? __lock_text_start+0x18/0x18
     ? raid1_end_read_request+0x2a0/0x2a0 [raid1]
     ? preempt_count_sub+0xf/0xc0
     ? _raw_spin_unlock_irqrestore+0x19/0x40
     ? del_timer_sync+0xa9/0x100
     ? try_to_del_timer_sync+0xc0/0xc0
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? __lock_text_start+0x18/0x18
     ? __list_del_entry_valid+0x68/0xa0
     ? finish_wait+0xa3/0x100
     md_thread+0x161/0x260 [md_mod]
     ? unregister_md_personality+0xa0/0xa0 [md_mod]
     ? _raw_spin_lock_irqsave+0x78/0xc0
     ? prepare_to_wait_event+0x2c0/0x2c0
     ? unregister_md_personality+0xa0/0xa0 [md_mod]
     kthread+0x148/0x180
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Allocated by task 5522:
     kasan_save_stack+0x1e/0x40
     __kasan_kmalloc+0x80/0xa0
     md_bitmap_create+0xa8/0xe80 [md_mod]
     md_run+0x777/0x1300 [md_mod]
     raid_ctr+0x249c/0x4a30 [dm_raid]
     dm_table_add_target+0x2b0/0x620 [dm_mod]
     table_load+0x1c8/0x400 [dm_mod]
     ctl_ioctl+0x29e/0x560 [dm_mod]
     dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
     __do_compat_sys_ioctl+0xfa/0x160
     do_syscall_64+0x90/0xc0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Freed by task 5680:
     kasan_save_stack+0x1e/0x40
     kasan_set_track+0x21/0x40
     kasan_set_free_info+0x20/0x40
     __kasan_slab_free+0xf7/0x140
     kfree+0x80/0x240
     md_bitmap_free+0x1c3/0x280 [md_mod]
     __md_stop+0x21/0x120 [md_mod]
     md_stop+0x9/0x40 [md_mod]
     raid_dtr+0x1b/0x40 [dm_raid]
     dm_table_destroy+0x98/0x1e0 [dm_mod]
     __dm_destroy+0x199/0x360 [dm_mod]
     dev_remove+0x10c/0x160 [dm_mod]
     ctl_ioctl+0x29e/0x560 [dm_mod]
     dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
     __do_compat_sys_ioctl+0xfa/0x160
     do_syscall_64+0x90/0xc0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 48df498daf62 ("md: move bitmap_destroy to the beginning of __md_stop")
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: [PATCH] pci: atomisp_cmd: fix three missing checks on list iterator [+ + +]
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Thu Apr 14 05:14:15 2022 +0100

    media: [PATCH] pci: atomisp_cmd: fix three missing checks on list iterator
    
    commit 09b204eb9de9fdf07d028c41c4331b5cfeb70dd7 upstream.
    
    The three bugs are here:
            __func__, s3a_buf->s3a_data->exp_id);
            __func__, md_buf->metadata->exp_id);
            __func__, dis_buf->dis_data->exp_id);
    
    The list iterator 's3a_buf/md_buf/dis_buf' will point to a bogus
    position containing HEAD if the list is empty or no element is found.
    This case must be checked before any use of the iterator, otherwise
    it will lead to a invalid memory access.
    
    To fix this bug, add an check. Use a new variable '*_iter' as the
    list iterator, while use the old variable '*_buf' as a dedicated
    pointer to point to the found element.
    
    Link: https://lore.kernel.org/linux-media/20220414041415.3342-1-xiam0nd.tong@gmail.com
    Cc: stable@vger.kernel.org
    Fixes: ad85094b293e4 ("Revert "media: staging: atomisp: Remove driver"")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: atmel: atmel-sama7g5-isc: fix warning in configs without OF [+ + +]
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Tue May 3 12:12:16 2022 +0100

    media: atmel: atmel-sama7g5-isc: fix warning in configs without OF
    
    [ Upstream commit b2bae4b8e637dd751d27918a6b27bd5abcd08859 ]
    
    All warnings (new ones prefixed by >>):
    
    >> drivers/media/platform/atmel/atmel-sama7g5-isc.c:610:34: warning: unused variable 'microchip_xisc_of_match' [-Wunused-const-variable]
       static const struct of_device_id microchip_xisc_of_match[] = {
                                        ^
       13 warnings generated.
    
    vim +/microchip_xisc_of_match +610 drivers/media/platform/atmel/atmel-sama7g5-isc.c
    
       609
     > 610  static const struct of_device_id microchip_xisc_of_match[] = {
       611          { .compatible = "microchip,sama7g5-isc" },
       612          { }
       613  };
       614  MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
       615
    
    Fixed warning by guarding the atmel_isc_of_match by CONFIG_OF.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: c9aa973884a1 ("media: atmel: atmel-isc: add microchip-xisc driver")
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cedrus: h265: Fix flag name [+ + +]
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Mon Jun 20 18:55:11 2022 +0100

    media: cedrus: h265: Fix flag name
    
    [ Upstream commit 104a70e1d0bcef28db13c4192b8729086089651c ]
    
    Bit 21 in register 0x24 (slice header info 1) actually represents
    negated version of low delay flag. This can be seen in vendor Cedar
    library source code. While this flag is not part of the standard, it can
    be found in reference HEVC implementation.
    
    Fix macro name and change it to flag.
    
    Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cedrus: hevc: Add check for invalid timestamp [+ + +]
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Mon Jul 18 18:56:49 2022 +0200

    media: cedrus: hevc: Add check for invalid timestamp
    
    [ Upstream commit 143201a6435bf65f0115435e9dc6d95c66b908e9 ]
    
    Not all DPB entries will be used most of the time. Unused entries will
    thus have invalid timestamps. They will produce negative buffer index
    which is not specifically handled. This works just by chance in current
    code. It will even produce bogus pointer, but since it's not used, it
    won't do any harm.
    
    Let's fix that brittle design by skipping writing DPB entry altogether
    if timestamp is invalid.
    
    Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: driver/nxp/imx-jpeg: fix a unexpected return value problem [+ + +]
Author: Jian Zhang <zhangjian210@huawei.com>
Date:   Mon Jun 20 09:34:23 2022 +0100

    media: driver/nxp/imx-jpeg: fix a unexpected return value problem
    
    [ Upstream commit 5b304046a81eda221b5d06a9c62f7b5e45530fa5 ]
    
    In function mxc_jpeg_probe(), when devm_clk_get() fail, the return value
    will be unexpected, and it should be the devm_clk_get's error code.
    
    Fixes: 4c2e5156d9fa6 ("media: imx-jpeg: Add pm-runtime support for imx-jpeg")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Jian Zhang <zhangjian210@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: hantro: postproc: Fix motion vector space size [+ + +]
Author: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date:   Tue Nov 16 14:38:31 2021 +0000

    media: hantro: postproc: Fix motion vector space size
    
    [ Upstream commit 9393761aec4c56b7f2f19d21f806d316731401c1 ]
    
    When the post-processor hardware block is enabled, the driver
    allocates an internal queue of buffers for the decoder enginer,
    and uses the vb2 queue for the post-processor engine.
    
    For instance, on a G1 core, the decoder engine produces NV12 buffers
    and the post-processor engine can produce YUY2 buffers. The decoder
    engine expects motion vectors to be appended to the NV12 buffers,
    but this is only required for CODECs that need motion vectors,
    such as H.264.
    
    Fix the post-processor logic accordingly.
    
    Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
    Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: hantro: Simplify postprocessor [+ + +]
Author: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date:   Tue Nov 16 14:38:33 2021 +0000

    media: hantro: Simplify postprocessor
    
    [ Upstream commit 53a3e71095c572333ceea30762565dbedec951ca ]
    
    Add a 'postprocessed' boolean property to struct hantro_fmt
    to signal that a format is produced by the post-processor.
    This will allow to introduce the G2 post-processor in a simple way.
    
    Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
    Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: hdpvr: fix error value returns in hdpvr_read [+ + +]
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Tue Jun 14 18:50:02 2022 +0100

    media: hdpvr: fix error value returns in hdpvr_read
    
    [ Upstream commit 359c27c6ddbde404f44a9c0d3ec88ccd1e2042f2 ]
    
    Error return values are supposed to be negative in hdpvr_read. Most
    error returns are currently handled via an unsigned integer "ret". When
    setting a negative error value to "ret", the value actually becomes a
    large positive value, because "ret" is unsigned. Later on, the "ret"
    value is returned. But as ssize_t is a 64-bit signed number, the error
    return value stays a large positive integer instead of a negative
    integer. This can cause an error value to be interpreted as the read
    size, which can cause a buffer overread for applications relying on the
    returned size.
    
    Fixes: 9aba42efe85b ("V4L/DVB (11096): V4L2 Driver for the Hauppauge HD PVR usb capture device")
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: hevc: Embedded indexes in RPS [+ + +]
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date:   Fri Jan 7 16:54:55 2022 +0100

    media: hevc: Embedded indexes in RPS
    
    [ Upstream commit d95a63daca85f4bca3b70e622c75586b5bf0ea5c ]
    
    Reference Picture Set lists provide indices of short and long term
    reference in DBP array.
    Fix Hantro to not do a look up in DBP entries.
    Make documentation more clear about it.
    
    [hverkuil: fix typo in commit log]
    
    Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
    Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Add pm-runtime support for imx-jpeg [+ + +]
Author: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
Date:   Thu Oct 7 17:30:38 2021 +0100

    media: imx-jpeg: Add pm-runtime support for imx-jpeg
    
    [ Upstream commit 4c2e5156d9fa63a3f41c2bf56b694ad42df825d7 ]
    
    Save some power by disabling/enabling the jpeg clocks with
    every stream stop/start.
    Do not use DL_FLAG_RPM_ACTIVE in mxc_jpeg_attach_pm_domains,
    to ensure power domains are off after probe.
    
    Signed-off-by: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Align upwards buffer size [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon May 30 08:49:19 2022 +0100

    media: imx-jpeg: Align upwards buffer size
    
    [ Upstream commit 9e7aa76cdb02923ee23a0ddd48f38bdc3512f92b ]
    
    The hardware can support any image size WxH,
    with arbitrary W (image width) and H (image height) dimensions.
    
    Align upwards buffer size for both encoder and decoder.
    and leave the picture resolution unchanged.
    
    For decoder, the risk of memory out of bounds can be avoided.
    For both encoder and decoder, the driver will lift the limitation of
    resolution alignment.
    
    For example, the decoder can support jpeg whose resolution is 227x149
    the encoder can support nv12 1080P, won't change it to 1920x1072.
    
    Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Correct some definition according specification [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon May 30 08:47:31 2022 +0100

    media: imx-jpeg: Correct some definition according specification
    
    [ Upstream commit 5a601f89e846c1b6005ab274d039e5036fc22015 ]
    
    the register CAST_NOMFRSIZE_LO should be equal to CAST_STATUS16
    the register CAST_NOMFRSIZE_HI should be equal to CAST_STATUS17
    the register CAST_OFBSIZE_LO should be equal to CAST_STATUS18
    the register CAST_OFBSIZE_HI should be equal to CAST_STATUS19
    
    Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Disable slot interrupt when frame done [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Jun 10 03:00:57 2022 +0100

    media: imx-jpeg: Disable slot interrupt when frame done
    
    [ Upstream commit 22a2bc88c139dc9757bdb1d0a3665ac27edc79a5 ]
    
    The interrupt STMBUF_HALF may be triggered after frame done.
    It may led to system hang if driver try to access the register after
    power off.
    
    Disable the slot interrupt when frame done.
    
    Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Tested-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Handle source change in a function [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Wed Mar 23 10:05:57 2022 +0100

    media: imx-jpeg: Handle source change in a function
    
    [ Upstream commit 831f87424dd3973612782983ef7352789795b4df ]
    
    Refine code to support dynamic resolution change
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Identify and handle precision correctly [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Wed Mar 23 10:05:55 2022 +0100

    media: imx-jpeg: Identify and handle precision correctly
    
    [ Upstream commit bec0a3a67389ede106d0661a007edf832878d8b2 ]
    
    The decoder will save the precision that was detected from jpeg header
    and use it later, when choosing the pixel format and also calculate
    bytesperline according to precision.
    
    The 12bit jpeg is not supported yet,
    but driver shouldn't led to serious problem if user enqueue a 12 bit jpeg.
    And the 12bit jpeg is supported by hardware, driver may support it later.
    
    [hverkuil: document the new precision field]
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Implement drain using v4l2-mem2mem helpers [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon May 30 08:50:02 2022 +0100

    media: imx-jpeg: Implement drain using v4l2-mem2mem helpers
    
    [ Upstream commit 4911c5acf9351c4caf692895c7cf6a4fa46c26b0 ]
    
    v4l2 m2m has supplied some helper function to handle drain,
    so the driver can use the helper function directly.
    
    Fixes: d8ebe298d008c ("media: imx-jpeg: Set V4L2_BUF_FLAG_LAST at eos")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Leave a blank space before the configuration data [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon May 30 08:48:37 2022 +0100

    media: imx-jpeg: Leave a blank space before the configuration data
    
    [ Upstream commit 6285cdea19daf764bf00f662a59fc83ef67345cf ]
    
    There is a hardware bug that it will load
    the first 128 bytes of configuration data twice,
    it will led to some configure error.
    so shift the configuration data 128 bytes,
    and make the first 128 bytes all zero,
    then hardware will load the 128 zero twice,
    and ignore them as garbage.
    then the configuration data can be loaded correctly
    
    Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Reviewed-by: Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Refactor function mxc_jpeg_parse [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Wed Mar 23 10:05:54 2022 +0100

    media: imx-jpeg: Refactor function mxc_jpeg_parse
    
    [ Upstream commit 8dd504a3a0a5f73b4c137ce3afc35936a4ecd871 ]
    
    Refine code to support dynamic resolution change
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Set V4L2_BUF_FLAG_LAST at eos [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Feb 22 16:41:16 2022 +0800

    media: imx-jpeg: Set V4L2_BUF_FLAG_LAST at eos
    
    [ Upstream commit d8ebe298d008ccbae3011cbeb139707f01a730c8 ]
    
    The V4L2_EVENT_EOS event is a deprecated behavior,
    the V4L2_BUF_FLAG_LAST buffer flag should be used instead.
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Support dynamic resolution change [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Wed Mar 23 10:05:58 2022 +0100

    media: imx-jpeg: Support dynamic resolution change
    
    [ Upstream commit b4e1fb8643daabba850e97df532191acffc23e6a ]
    
    To support dynamic resolution change,
    driver should meet the following conditions:
    1. the previous pictures are all decoded before source change event.
    2. prevent decoding new resolution pictures with incorrect capture
       buffer, until user handle source change event and setup capture.
    3. report correct fmt and resolution during source change.
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: use NV12M to represent non contiguous NV12 [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Dec 24 04:02:41 2021 +0100

    media: imx-jpeg: use NV12M to represent non contiguous NV12
    
    [ Upstream commit 784a1883cff07e7510a81ad3041d6ec443d51944 ]
    
    V4L2_PIX_FMT_NV12 requires num_planes equals to 1,
    V4L2_PIX_FMT_NV12M requires num_planes equals to 2.
    and mxc-jpeg supports 2 planes for nv12,
    so we should use 4L2_PIX_FMT_NV12M instead of V4L2_PIX_FMT_NV12,
    otherwise it will confuses gstreamer and prevent encoding and decoding.
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Shijie Qin <shijie.qin@nxp.com>
    Signed-off-by: Zhou Peng <eagle.zhou@nxp.com>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: platform: mtk-mdp: Fix mdp_ipi_comm structure alignment [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Jun 23 14:55:46 2022 +0100

    media: platform: mtk-mdp: Fix mdp_ipi_comm structure alignment
    
    [ Upstream commit ab14c99c035da7156a3b66fa171171295bc4b89a ]
    
    The mdp_ipi_comm structure defines a command that is either
    PROCESS (start processing) or DEINIT (destroy instance); we
    are using this one to send PROCESS or DEINIT commands from Linux
    to an MDP instance through a VPU write but, while the first wants
    us to stay 4-bytes aligned, the VPU instead requires an 8-bytes
    data alignment.
    
    Keeping in mind that these commands are executed immediately
    after sending them (hence not chained with others before the
    VPU/MDP "actually" start executing), it is fine to simply add
    a padding of 4 bytes to this structure: this keeps the same
    performance as before, as we're still stack-allocating it,
    while avoiding hackery inside of mtk-vpu to ensure alignment
    bringing a definitely bigger performance impact.
    
    Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
    Reviewed-by: Irui Wang <irui.wang@mediatek.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: staging: media: hantro: Fix typos [+ + +]
Author: Sebastian Fricke <sebastian.fricke@collabora.com>
Date:   Sat Mar 26 19:36:03 2022 +0100

    media: staging: media: hantro: Fix typos
    
    [ Upstream commit d8f6f1c56d5469e22eeb7cc1f3580b29e2f0fef5 ]
    
    Fix typos in comments within the Hantro driver.
    
    Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: tw686x: Fix memory leak in tw686x_video_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Jun 21 06:30:30 2022 +0100

    media: tw686x: Fix memory leak in tw686x_video_init
    
    [ Upstream commit e0b212ec9d8177d6f7c404315293f6a085d6ee42 ]
    
    video_device_alloc() allocates memory for vdev,
    when video_register_device() fails, it doesn't release the memory and
    leads to memory leak, call video_device_release() to fix this.
    
    Fixes: 704a84ccdbf1 ("[media] media: Support Intersil/Techwell TW686x-based video capture cards")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: tw686x: Register the irq at the end of probe [+ + +]
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sat May 21 07:24:01 2022 +0100

    media: tw686x: Register the irq at the end of probe
    
    [ Upstream commit fb730334e0f759d00f72168fbc555e5a95e35210 ]
    
    We got the following warning when booting the kernel:
    
    [    3.243674] INFO: trying to register non-static key.
    [    3.243922] The code is fine but needs lockdep annotation, or maybe
    [    3.244230] you didn't initialize this object before use?
    [    3.245642] Call Trace:
    [    3.247836]  lock_acquire+0xff/0x2d0
    [    3.248727]  tw686x_audio_irq+0x1a5/0xcc0 [tw686x]
    [    3.249211]  tw686x_irq+0x1f9/0x480 [tw686x]
    
    The lock 'vc->qlock' will be initialized in tw686x_video_init(), but the
    driver registers the irq before calling the tw686x_video_init(), and we
    got the warning.
    
    Fix this by registering the irq at the end of probe
    
    Fixes: 704a84ccdbf1 ("[media] media: Support Intersil/Techwell TW686x-based video capture cards")
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: v4l2-mem2mem: prevent pollerr when last_buffer_dequeued is set [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Wed Jun 15 04:19:20 2022 +0100

    media: v4l2-mem2mem: prevent pollerr when last_buffer_dequeued is set
    
    [ Upstream commit d4de27a9b1eadd33a2e40de87a646d1bf5fef756 ]
    
    If the last buffer was dequeued from the capture queue,
    signal userspace. DQBUF(CAPTURE) will return -EPIPE.
    
    But if output queue is empty and capture queue is empty,
    v4l2_m2m_poll_for_data will return EPOLLERR,
    This is very easy to happen in drain.
    
    When last_buffer_dequeued is set, we shouldn't return EPOLLERR,
    but return EPOLLIN | EPOLLRDNORM.
    
    Fixes: 1698a7f151126 ("media: v4l2-mem2mem: simplify poll logic")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mediatek: mt76: eeprom: fix missing of_node_put() in mt76_find_power_limits_node() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Mon Jul 4 16:34:21 2022 +0800

    mediatek: mt76: eeprom: fix missing of_node_put() in mt76_find_power_limits_node()
    
    [ Upstream commit 3bd53ea02d77917c2314ec7be9e2d05be22f87d3 ]
    
    We should use of_node_put() for the reference 'np' returned by
    of_get_child_by_name() which will increase the refcount.
    
    Fixes: 22b980badc0f ("mt76: add functions for parsing rate power limits from DT")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mediatek: mt76: mac80211: Fix missing of_node_put() in mt76_led_init() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Mon Jul 4 16:34:20 2022 +0800

    mediatek: mt76: mac80211: Fix missing of_node_put() in mt76_led_init()
    
    [ Upstream commit 0a14c1d0113f121151edf34333cdf212dd209190 ]
    
    We should use of_node_put() for the reference 'np' returned by
    of_get_child_by_name() which will increase the refcount.
    
    Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memremap: remove support for external pgmap refcounts [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Oct 28 17:10:17 2021 +0200

    memremap: remove support for external pgmap refcounts
    
    [ Upstream commit b80892ca022e9eb484771a66eb68e12364695a2a ]
    
    No driver is left using the external pgmap refcount, so remove the
    code to support it.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/20211028151017.50234-1-hch@lst.de
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memstick/ms_block: Fix a memory leak [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 25 14:55:56 2022 +0200

    memstick/ms_block: Fix a memory leak
    
    [ Upstream commit 54eb7a55be6779c4d0c25eaf5056498a28595049 ]
    
    'erased_blocks_bitmap' is never freed. As it is allocated at the same time
    as 'used_blocks_bitmap', it is likely that it should be freed also at the
    same time.
    
    Add the corresponding bitmap_free() in msb_data_clear().
    
    Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/b3b78926569445962ea5c3b6e9102418a9effb88.1656155715.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memstick/ms_block: Fix some incorrect memory allocation [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 25 14:55:25 2022 +0200

    memstick/ms_block: Fix some incorrect memory allocation
    
    [ Upstream commit 2e531bc3e0d86362fcd8a577b3278d9ef3cc2ba0 ]
    
    Some functions of the bitmap API take advantage of the fact that a bitmap
    is an array of long.
    
    So, to make sure this assertion is correct, allocate bitmaps with
    bitmap_zalloc() instead of kzalloc()+hand-computed number of bytes.
    
    While at it, also use bitmap_free() instead of kfree() to keep the
    semantic.
    
    Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/dbf633c48c24ae6d95f852557e8d8b3bbdef65fe.1656155715.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue May 24 10:57:29 2022 +0400

    meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init
    
    [ Upstream commit a2106f38077e78afcb4bf98fdda3e162118cfb3d ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 5e68c0fc8df8 ("soc: amlogic: Add Meson6/Meson8/Meson8b/Meson8m2 SoC Information driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20220524065729.33689-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mfd: max77620: Fix refcount leak in max77620_initialise_fps [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 08:32:22 2022 +0400

    mfd: max77620: Fix refcount leak in max77620_initialise_fps
    
    [ Upstream commit 1520669c8255bd637c6b248b2be910e2688d38dd ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 327156c59360 ("mfd: max77620: Add core driver for MAX77620/MAX20024")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20220601043222.64441-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mfd: t7l66xb: Drop platform disable callback [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon May 30 21:24:28 2022 +0200

    mfd: t7l66xb: Drop platform disable callback
    
    [ Upstream commit 128ac294e1b437cb8a7f2ff8ede1cde9082bddbe ]
    
    None of the in-tree instantiations of struct t7l66xb_platform_data
    provides a disable callback. So better don't dereference this function
    pointer unconditionally. As there is no user, drop it completely instead
    of calling it conditional.
    
    This is a preparation for making platform remove callbacks return void.
    
    Fixes: 1f192015ca5b ("mfd: driver for the T7L66XB TMIO SoC")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20220530192430.2108217-3-u.kleine-koenig@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Thu Jul 14 16:41:34 2022 +0800

    MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK
    
    commit e1a534f5d074db45ae5cbac41d8912b98e96a006 upstream.
    
    When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
    cpu_max_bits_warn() generates a runtime warning similar as below while
    we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
    instead of NR_CPUS to iterate CPUs.
    
    [    3.052463] ------------[ cut here ]------------
    [    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
    [    3.070072] Modules linked in: efivarfs autofs4
    [    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
    [    3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27
    [    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
    [    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
    [    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
    [    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
    [    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
    [    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
    [    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
    [    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000
    [    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
    [    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
    [    3.195868]         ...
    [    3.199917] Call Trace:
    [    3.203941] [<98000000002086d8>] show_stack+0x38/0x14c
    [    3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88
    [    3.217625] [<980000000023d268>] __warn+0xd0/0x100
    [    3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
    [    3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0
    [    3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4
    [    3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4
    [    3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0
    [    3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100
    [    3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94
    [    3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160
    [    3.281824] ---[ end trace 8b484262b4b8c24c ]---
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Fixed __debug_virt_addr_valid() [+ + +]
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Jul 14 15:25:12 2022 -0700

    MIPS: Fixed __debug_virt_addr_valid()
    
    [ Upstream commit 8a2b456665d1e797123669581524cbb095fb003b ]
    
    It is permissible for kernel code to call virt_to_phys() against virtual
    addresses that are in KSEG0 or KSEG1 and we need to be dealing with both
    types. Rewrite the test condition to ensure that the kernel virtual
    addresses are above PAGE_OFFSET which they must be, and below KSEG2
    where the non-linear mapping starts.
    
    For EVA, there is not much that we can do given the linear address range
    that is offered, so just return any virtual address as being valid.
    
    Finally, when HIGHMEM is not enabled, all virtual addresses are assumed
    to be valid as well.
    
    Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: vdso: Utilize __pa() for gic_pfn [+ + +]
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Jul 7 13:27:58 2022 -0700

    MIPS: vdso: Utilize __pa() for gic_pfn
    
    [ Upstream commit 8baa65126e19af5ee9f3c07e7bb53da41c39e4b1 ]
    
    The GIC user offset is mapped into every process' virtual address and is
    therefore part of the hot-path of arch_setup_additional_pages(). Utilize
    __pa() such that we are more optimal even when CONFIG_DEBUG_VIRTUAL is
    enabled, and while at it utilize PFN_DOWN() instead of open-coding the
    right shift by PAGE_SHIFT.
    
    Reported-by: Greg Ungerer <gerg@kernel.org>
    Suggested-by: Serge Semin <fancer.lancer@gmail.com>
    Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Acked-by: Greg Ungerer <gerg@kernel.org>
    Tested-by: Greg Ungerer <gerg@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: rtsx: Fix an error handling path in rtsx_pci_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 15 07:33:44 2022 +0200

    misc: rtsx: Fix an error handling path in rtsx_pci_probe()
    
    [ Upstream commit 44fd1917314e9d4f53dd95dd65df1c152f503d3a ]
    
    If an error occurs after a successful idr_alloc() call, the corresponding
    resource must be released with idr_remove() as already done in the .remove
    function.
    
    Update the error handling path to add the missing idr_remove() call.
    
    Fixes: ada8a8a13b13 ("mfd: Add realtek pcie card reader driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/e8dc41716cbf52fb37a12e70d8972848e69df6d6.1655271216.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/mempolicy: fix get_nodes out of bound access [+ + +]
Author: Tianyu Li <tianyu.li@arm.com>
Date:   Wed Jun 1 17:32:11 2022 +0800

    mm/mempolicy: fix get_nodes out of bound access
    
    [ Upstream commit 000eca5d044d1ee23b4ca311793cf3fc528da6c6 ]
    
    When user specified more nodes than supported, get_nodes will access nmask
    array out of bounds.
    
    Link: https://lkml.kernel.org/r/20220601093211.2970565-1-tianyu.li@arm.com
    Fixes: e130242dc351 ("mm: simplify compat numa syscalls")
    Signed-off-by: Tianyu Li <tianyu.li@arm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/memremap: fix memunmap_pages() race with get_dev_pagemap() [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Thu Jun 9 20:13:05 2022 +0800

    mm/memremap: fix memunmap_pages() race with get_dev_pagemap()
    
    [ Upstream commit 1e57ffb6e3fd9583268c6462c4e3853575b21701 ]
    
    Think about the below scene:
    
     CPU1                   CPU2
     memunmap_pages
       percpu_ref_exit
         __percpu_ref_exit
           free_percpu(percpu_count);
             /* percpu_count is freed here! */
                             get_dev_pagemap
                               xa_load(&pgmap_array, PHYS_PFN(phys))
                                 /* pgmap still in the pgmap_array */
                               percpu_ref_tryget_live(&pgmap->ref)
                                 if __ref_is_percpu
                                   /* __PERCPU_REF_ATOMIC_DEAD not set yet */
                                   this_cpu_inc(*percpu_count)
                                     /* access freed percpu_count here! */
          ref->percpu_count_ptr = __PERCPU_REF_ATOMIC_DEAD;
            /* too late... */
       pageunmap_range
    
    To fix the issue, do percpu_ref_exit() after pgmap_array is emptied. So
    we won't do percpu_ref_tryget_live() against a being freed percpu_ref.
    
    Link: https://lkml.kernel.org/r/20220609121305.2508-1-linmiaohe@huawei.com
    Fixes: b7b3c01b1915 ("mm/memremap_pages: support multiple ranges per invocation")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/mmap.c: fix missing call to vm_unacct_memory in mmap_region [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Sat Jun 18 16:20:27 2022 +0800

    mm/mmap.c: fix missing call to vm_unacct_memory in mmap_region
    
    [ Upstream commit 7f82f922319ede486540e8746769865b9508d2c2 ]
    
    Since the beginning, charged is set to 0 to avoid calling vm_unacct_memory
    twice because vm_unacct_memory will be called by above unmap_region.  But
    since commit 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from
    the unmap_vmas() interfaces"), unmap_region doesn't call vm_unacct_memory
    anymore.  So charged shouldn't be set to 0 now otherwise the calling to
    paired vm_unacct_memory will be missed and leads to imbalanced account.
    
    Link: https://lkml.kernel.org/r/20220618082027.43391-1-linmiaohe@huawei.com
    Fixes: 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from the unmap_vmas() interfaces")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: block: Add single read for 4k sector cards [+ + +]
Author: Christian Loehle <CLoehle@hyperstone.com>
Date:   Fri Jul 1 12:43:09 2022 +0000

    mmc: block: Add single read for 4k sector cards
    
    [ Upstream commit b3fa3e6dccc465969721b8bd2824213bd235efeb ]
    
    Cards with 4k native sector size may only be read 4k-aligned,
    accommodate for this in the single read recovery and use it.
    
    Fixes: 81196976ed946 (mmc: block: Add blk-mq support)
    Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Link: https://lore.kernel.org/r/cf4f316274c5474586d0d99b17db4a4c@hyperstone.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: cavium-octeon: Add of_node_put() when breaking out of loop [+ + +]
Author: Liang He <windhl@126.com>
Date:   Tue Jul 19 17:52:15 2022 +0800

    mmc: cavium-octeon: Add of_node_put() when breaking out of loop
    
    [ Upstream commit 19bbb49acf8d7a03cb83e05624363741a4c3ec6f ]
    
    In octeon_mmc_probe(), we should call of_node_put() when breaking
    out of for_each_child_of_node() which has increased and decreased
    the refcount during each iteration.
    
    Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.")
    Signed-off-by: Liang He <windhl@126.com>
    Acked-by: Robert Richter <rric@kernel.org>
    Link: https://lore.kernel.org/r/20220719095216.1241601-1-windhl@126.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: cavium-thunderx: Add of_node_put() when breaking out of loop [+ + +]
Author: Liang He <windhl@126.com>
Date:   Tue Jul 19 17:52:16 2022 +0800

    mmc: cavium-thunderx: Add of_node_put() when breaking out of loop
    
    [ Upstream commit 7ee480795e41db314f2c445c65ed854a5d6e8e32 ]
    
    In thunder_mmc_probe(), we should call of_node_put() when breaking
    out of for_each_child_of_node() which has increased and decreased
    the refcount during each iteration.
    
    Fixes: 166bac38c3c5 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs")
    Signed-off-by: Liang He <windhl@126.com>
    Acked-by: Robert Richter <rric@kernel.org>
    Link: https://lore.kernel.org/r/20220719095216.1241601-2-windhl@126.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: mxcmmc: Silence a clang warning [+ + +]
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed May 25 22:00:22 2022 -0300

    mmc: mxcmmc: Silence a clang warning
    
    [ Upstream commit 7dc65e3c0ef4b746a583b7c58f99873fddf5ccfa ]
    
    Change the of_device_get_match_data() cast to (uintptr_t)
    to silence the following clang warning:
    
    drivers/mmc/host/mxcmmc.c:1028:18: warning: cast to smaller integer type 'enum mxcmci_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 8223e885e74b ("mmc: mxc: Convert the driver to DT-only")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Link: https://lore.kernel.org/r/20220526010022.1163483-1-festevam@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: renesas_sdhi: Get the reset handle early in the probe [+ + +]
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Fri Jun 24 19:14:37 2022 +0100

    mmc: renesas_sdhi: Get the reset handle early in the probe
    
    [ Upstream commit 0dac1e498f8130fdacfdd5289e3a7ac87ec1b9ad ]
    
    In case of devm_reset_control_get_optional_exclusive() failure we returned
    directly instead of jumping to the error path to roll back initialization.
    
    This patch moves devm_reset_control_get_optional_exclusive() early in the
    probe so that we have the reset handle prior to initialization of the
    hardware.
    
    Fixes: b4d86f37eacb7 ("mmc: renesas_sdhi: do hard reset if possible")
    Reported-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/20220624181438.4355-2-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci-of-at91: fix set_uhs_signaling rewriting of MC1R [+ + +]
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Jun 30 12:09:26 2022 +0300

    mmc: sdhci-of-at91: fix set_uhs_signaling rewriting of MC1R
    
    [ Upstream commit 5987e6ded29d52e42fc7b06aa575c60a25eee38e ]
    
    In set_uhs_signaling, the DDR bit is being set by fully writing the MC1R
    register.
    This can lead to accidental erase of certain bits in this register.
    Avoid this by doing a read-modify-write operation.
    
    Fixes: d0918764c17b ("mmc: sdhci-of-at91: fix MMC_DDR_52 timing selection")
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Tested-by: Karl Olsen <karl@micro-technic.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20220630090926.15061-1-eugen.hristev@microchip.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 18:42:54 2022 +0400

    mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch
    
    [ Upstream commit b5899a3e2f783a27b268e38d37f9b24c71bddf45 ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    of_node_put() checks null pointer.
    
    Fixes: ea35645a3c66 ("mmc: sdhci-of-esdhc: add support for signal voltage switch")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220523144255.10310-1-linmq006@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mt76: mt7615: do not update pm stats in case of error [+ + +]
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Jun 13 14:03:28 2022 +0200

    mt76: mt7615: do not update pm stats in case of error
    
    [ Upstream commit 79717c4eeeae9dec894794fbe8af72f08f03ebdd ]
    
    Do not update pm stats if mt7615_mcu_fw_pmctrl returns an error.
    
    Fixes: abe912ae3cd42 ("mt76: mt7663: add awake and doze time accounting")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg [+ + +]
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Tue May 17 18:37:07 2022 +0200

    mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg
    
    [ Upstream commit cffd93411575afd987788e2ec3cb8eaff70f0215 ]
    
    Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.
    
    Fixes: 4c89ff2c74e39 ("mt76: split __mt76u_mcu_send_msg and mt76u_mcu_send_msg routines")
    Co-developed-by: Gergo Koteles <soyer@irl.hu>
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mt76: mt7921: enlarge maximum VHT MPDU length to 11454 [+ + +]
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Sat Jun 18 18:56:44 2022 +0800

    mt76: mt7921: enlarge maximum VHT MPDU length to 11454
    
    [ Upstream commit 31f3248a75932b111bc90c66b1f6c7d89eedca8e ]
    
    Enlarge maximum MPDU length to 11454 that both mt7921/mt7922 can support.
    After this fixing, we can get better performance.
    
    Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support")
    Tested-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mt76: mt7921: fix aggregation subframes setting to HE max [+ + +]
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Thu Jun 16 23:57:43 2022 +0800

    mt76: mt7921: fix aggregation subframes setting to HE max
    
    [ Upstream commit d5a50e6bd1972c481f82befa846dce0b9866f025 ]
    
    mt7921/mt7922 support HE max aggregation subframes 256 for both tx/rx.
    Get better throughput then before.
    
    Fixes: 94bb18b03d43 ("mt76: mt7921: fix max aggregation subframes setting")
    Tested-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
    Reviewed-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mtd: dataflash: Add SPI ID table [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Jun 20 16:23:13 2022 +0100

    mtd: dataflash: Add SPI ID table
    
    [ Upstream commit ac4f83482afbfd927d0fe118151b747cf175e724 ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding an id_table listing the
    SPI IDs for everything.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220620152313.708768-1-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: maps: Fix refcount leak in ap_flash_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 18:32:55 2022 +0400

    mtd: maps: Fix refcount leak in ap_flash_init
    
    [ Upstream commit 77087a04c8fd554134bddcb8a9ff87b21f357926 ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220523143255.4376-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: maps: Fix refcount leak in of_flash_probe_versatile [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 18:02:05 2022 +0400

    mtd: maps: Fix refcount leak in of_flash_probe_versatile
    
    [ Upstream commit 33ec82a6d2b119938f26e5c8040ed5d92378eb54 ]
    
    of_find_matching_node_and_match() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220523140205.48625-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 11:07:23 2022 +0400

    mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset
    
    [ Upstream commit e607879b0da18c451de5e91daf239cc2f2f8ff2d ]
    
    of_find_node_by_path() returns a node pointer with refcount incremented,
    we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: bb17230c61a6 ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220605070726.5979-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: partitions: Fix refcount leak in parse_redboot_of [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 15:06:49 2022 +0400

    mtd: partitions: Fix refcount leak in parse_redboot_of
    
    [ Upstream commit 9f7e62815cf3cbbcb1b8cb21649fb4dfdb3aa016 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 237960880960 ("mtd: partitions: redboot: seek fis-index-block in the right node")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220526110652.64849-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: rawnand: arasan: Fix clock rate in NV-DDR [+ + +]
Author: Olga Kitaina <okitain@gmail.com>
Date:   Tue Jun 28 21:18:24 2022 +0530

    mtd: rawnand: arasan: Fix clock rate in NV-DDR
    
    commit e16eceea863b417fd328588b1be1a79de0bc937f upstream.
    
    According to the Arasan NAND controller spec, the flash clock rate for SDR
    must be <= 100 MHz, while for NV-DDR it must be the same as the rate of the
    CLK line for the mode. The driver previously always set 100 MHz for NV-DDR,
    which would result in incorrect behavior for NV-DDR modes 0-4.
    
    The appropriate clock rate can be calculated from the NV-DDR timing
    parameters as 1/tCK, or for rates measured in picoseconds,
    10^12 / nand_nvddr_timings->tCK_min.
    
    Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller")
    CC: stable@vger.kernel.org # 5.8+
    Signed-off-by: Olga Kitaina <okitain@gmail.com>
    Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220628154824.12222-3-amit.kumar-mahapatra@xilinx.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: arasan: Update NAND bus clock instead of system clock [+ + +]
Author: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com>
Date:   Tue Jun 28 21:18:23 2022 +0530

    mtd: rawnand: arasan: Update NAND bus clock instead of system clock
    
    commit 7499bfeedb47efc1ee4dc793b92c610d46e6d6a6 upstream.
    
    In current implementation the Arasan NAND driver is updating the
    system clock(i.e., anand->clk) in accordance to the timing modes
    (i.e., SDR or NVDDR). But as per the Arasan NAND controller spec the
    flash clock or the NAND bus clock(i.e., nfc->bus_clk), need to be
    updated instead. This patch keeps the system clock unchanged and updates
    the NAND bus clock as per the timing modes.
    
    Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller")
    CC: stable@vger.kernel.org # 5.8+
    Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220628154824.12222-2-amit.kumar-mahapatra@xilinx.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: meson: Fix a potential double free issue [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri May 20 18:41:40 2022 +0200

    mtd: rawnand: meson: Fix a potential double free issue
    
    [ Upstream commit ec0da06337751b18f6dee06b6526e0f0d6e80369 ]
    
    When meson_nfc_nand_chip_cleanup() is called, it will call:
            meson_nfc_free_buffer(&meson_chip->nand);
            nand_cleanup(&meson_chip->nand);
    
    nand_cleanup() in turn will call nand_detach() which calls the
    .detach_chip() which is here meson_nand_detach_chip().
    
    meson_nand_detach_chip() already calls meson_nfc_free_buffer(), so we
    could double free some memory.
    
    Fix it by removing the unneeded explicit call to meson_nfc_free_buffer().
    
    Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Liang Yang <liang.yang@amlogic.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/ec15c358b8063f7c50ff4cd628cf0d2e14e43f49.1653064877.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: sm_ftl: Fix deadlock caused by cancel_work_sync in sm_release [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue May 24 12:48:41 2022 +0800

    mtd: sm_ftl: Fix deadlock caused by cancel_work_sync in sm_release
    
    [ Upstream commit a61528d997619a518ee8c51cf0ef0513021afaff ]
    
    There is a deadlock between sm_release and sm_cache_flush_work
    which is a work item. The cancel_work_sync in sm_release will
    not return until sm_cache_flush_work is finished. If we hold
    mutex_lock and use cancel_work_sync to wait the work item to
    finish, the work item also requires mutex_lock. As a result,
    the sm_release will be blocked forever. The race condition is
    shown below:
    
        (Thread 1)             |   (Thread 2)
    sm_release                 |
      mutex_lock(&ftl->mutex)  | sm_cache_flush_work
                               |   mutex_lock(&ftl->mutex)
      cancel_work_sync         |   ...
    
    This patch moves del_timer_sync and cancel_work_sync out of
    mutex_lock in order to mitigate deadlock.
    
    Fixes: 7d17c02a01a1 ("mtd: Add new SmartMedia/xD FTL")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220524044841.10517-1-duoming@zju.edu.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: spi-nor: fix spi_nor_spimem_setup_op() call in spi_nor_erase_{sector,chip}() [+ + +]
Author: Patrice Chotard <patrice.chotard@foss.st.com>
Date:   Wed Jun 29 15:30:13 2022 +0200

    mtd: spi-nor: fix spi_nor_spimem_setup_op() call in spi_nor_erase_{sector,chip}()
    
    [ Upstream commit f8cd9f632f4415b1e8838bdca8ab42cfb37a6584 ]
    
    For erase operations, reg_proto must be used as indicated in
    struct spi_nor description in spi-nor.h.
    
    This issue was found when DT property spi-tx-bus-width is set to 4.
    In this case the spi_mem_op->addr.buswidth is set to 4 for erase command
    which is not correct.
    
    Tested on stm32mp157c-ev1 board with mx66l51235f spi-nor.
    
    Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol")
    Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
    [ta: use nor->reg_proto in spi_nor_controller_ops_erase()]
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Tested-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
    Link: https://lore.kernel.org/r/20220629133013.3382393-1-patrice.chotard@foss.st.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: st_spi_fsm: Add a clk_disable_unprepare() in .probe()'s error path [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Jun 7 17:24:55 2022 +0200

    mtd: st_spi_fsm: Add a clk_disable_unprepare() in .probe()'s error path
    
    [ Upstream commit 28607b426c3d050714f250d0faeb99d2e9106e90 ]
    
    For all but one error path clk_disable_unprepare() is already there. Add
    it to the one location where it's missing.
    
    Fixes: 481815a6193b ("mtd: st_spi_fsm: Handle clk_prepare_enable/clk_disable_unprepare.")
    Fixes: 69d5af8d016c ("mtd: st_spi_fsm: Obtain and use EMI clock")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20220607152458.232847-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Jun 7 11:26:26 2022 +0800

    mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv
    
    [ Upstream commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc ]
    
    There are sleep in atomic context bugs when uploading device dump
    data in mwifiex. The root cause is that dev_coredumpv could not
    be used in atomic contexts, because it calls dev_set_name which
    include operations that may sleep. The call tree shows execution
    paths that could lead to bugs:
    
       (Interrupt context)
    fw_dump_timer_fn
      mwifiex_upload_device_dump
        dev_coredumpv(..., GFP_KERNEL)
          dev_coredumpm()
            kzalloc(sizeof(*devcd), gfp); //may sleep
            dev_set_name
              kobject_set_name_vargs
                kvasprintf_const(GFP_KERNEL, ...); //may sleep
                kstrdup(s, GFP_KERNEL); //may sleep
    
    The corresponding fail log is shown below:
    
    [  135.275938] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start
    [  135.281029] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
    ...
    [  135.293613] Call Trace:
    [  135.293613]  <IRQ>
    [  135.293613]  dump_stack_lvl+0x57/0x7d
    [  135.293613]  __might_resched.cold+0x138/0x173
    [  135.293613]  ? dev_coredumpm+0xca/0x2e0
    [  135.293613]  kmem_cache_alloc_trace+0x189/0x1f0
    [  135.293613]  ? devcd_match_failing+0x30/0x30
    [  135.293613]  dev_coredumpm+0xca/0x2e0
    [  135.293613]  ? devcd_freev+0x10/0x10
    [  135.293613]  dev_coredumpv+0x1c/0x20
    [  135.293613]  ? devcd_match_failing+0x30/0x30
    [  135.293613]  mwifiex_upload_device_dump+0x65/0xb0
    [  135.293613]  ? mwifiex_dnld_fw+0x1b0/0x1b0
    [  135.293613]  call_timer_fn+0x122/0x3d0
    [  135.293613]  ? msleep_interruptible+0xb0/0xb0
    [  135.293613]  ? lock_downgrade+0x3c0/0x3c0
    [  135.293613]  ? __next_timer_interrupt+0x13c/0x160
    [  135.293613]  ? lockdep_hardirqs_on_prepare+0xe/0x220
    [  135.293613]  ? mwifiex_dnld_fw+0x1b0/0x1b0
    [  135.293613]  __run_timers.part.0+0x3f8/0x540
    [  135.293613]  ? call_timer_fn+0x3d0/0x3d0
    [  135.293613]  ? arch_restore_msi_irqs+0x10/0x10
    [  135.293613]  ? lapic_next_event+0x31/0x40
    [  135.293613]  run_timer_softirq+0x4f/0xb0
    [  135.293613]  __do_softirq+0x1c2/0x651
    ...
    [  135.293613] RIP: 0010:default_idle+0xb/0x10
    [  135.293613] RSP: 0018:ffff888006317e68 EFLAGS: 00000246
    [  135.293613] RAX: ffffffff82ad8d10 RBX: ffff888006301cc0 RCX: ffffffff82ac90e1
    [  135.293613] RDX: ffffed100d9ff1b4 RSI: ffffffff831ad140 RDI: ffffffff82ad8f20
    [  135.293613] RBP: 0000000000000003 R08: 0000000000000000 R09: ffff88806cff8d9b
    [  135.293613] R10: ffffed100d9ff1b3 R11: 0000000000000001 R12: ffffffff84593410
    [  135.293613] R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff11000c62fd2
    ...
    [  135.389205] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end
    
    This patch uses delayed work to replace timer and moves the operations
    that may sleep into a delayed work in order to mitigate bugs, it was
    tested on Marvell 88W8801 chip whose port is usb and the firmware is
    usb8801_uapsta.bin. The following is the result after using delayed
    work to replace timer.
    
    [  134.936453] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start
    [  135.043344] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end
    
    As we can see, there is no bug now.
    
    Fixes: f5ecd02a8b20 ("mwifiex: device dump support for usb interface")
    Reviewed-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/b63b77fc84ed3e8a6bef02378e17c7c71a0bc3be.1654569290.git.duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mwifiex: Ignore BTCOEX events from the 88W8897 firmware [+ + +]
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Wed Nov 3 21:58:27 2021 +0100

    mwifiex: Ignore BTCOEX events from the 88W8897 firmware
    
    [ Upstream commit 84d94e16efa268e4f2887d858cd67ee37b870f25 ]
    
    The firmware of the 88W8897 PCIe+USB card sends those events very
    unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no
    COEX event comes in, and sometimes bluetooth is disabled but the
    coexistance mode doesn't get disabled.
    
    This means we sometimes end up capping the rx/tx window size while
    bluetooth is not enabled anymore, artifically limiting wifi speeds even
    though bluetooth is not being used.
    
    Since we can't fix the firmware, let's just ignore those events on the
    88W8897 device. From some Wireshark capture sessions it seems that the
    Windows driver also doesn't change the rx/tx window sizes when bluetooth
    gets enabled or disabled, so this is fairly consistent with the Windows
    driver.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211103205827.14559-1-verdre@v0yd.nl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/9p: Initialize the iounit field during fid creation [+ + +]
Author: Tyler Hicks <tyhicks@linux.microsoft.com>
Date:   Sun Jul 10 09:14:02 2022 -0500

    net/9p: Initialize the iounit field during fid creation
    
    [ Upstream commit aa7aeee169480e98cf41d83c01290a37e569be6d ]
    
    Ensure that the fid's iounit field is set to zero when a new fid is
    created. Certain 9P operations, such as OPEN and CREATE, allow the
    server to reply with an iounit size which the client code assigns to the
    p9_fid struct shortly after the fid is created by p9_fid_create(). On
    the other hand, an XATTRWALK operation doesn't allow for the server to
    specify an iounit value. The iounit field of the newly allocated p9_fid
    struct remained uninitialized in that case. Depending on allocation
    patterns, the iounit value could have been something reasonable that was
    carried over from previously freed fids or, in the worst case, could
    have been arbitrary values from non-fid related usages of the memory
    location.
    
    The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel
    after the uninitialized iounit field resulted in the typical sequence of
    two getxattr(2) syscalls, one to get the size of an xattr and another
    after allocating a sufficiently sized buffer to fit the xattr value, to
    hit an unexpected ERANGE error in the second call to getxattr(2). An
    uninitialized iounit field would sometimes force rsize to be smaller
    than the xattr value size in p9_client_read_once() and the 9P server in
    WSL refused to chunk up the READ on the attr_fid and, instead, returned
    ERANGE to the client. The virtfs server in QEMU seems happy to chunk up
    the READ and this problem goes undetected there.
    
    Link: https://lkml.kernel.org/r/20220710141402.803295-1-tyhicks@linux.microsoft.com
    Fixes: ebf46264a004 ("fs/9p: Add support user. xattr")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Adjust log_max_qp to be 18 at most [+ + +]
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Sun Jul 24 11:28:21 2022 +0300

    net/mlx5: Adjust log_max_qp to be 18 at most
    
    [ Upstream commit a6e9085d791f8306084fd5bc44dd3fdd4e1ac27b ]
    
    The cited commit limited log_max_qp to be 17 due to FW capabilities.
    Recently, it turned out that there are old FW versions that supported
    more than 17, so the cited commit caused a degradation.
    
    Thus, set the maximum log_max_qp back to 18 as it was before the
    cited commit.
    
    Fixes: 7f839965b2d7 ("net/mlx5: Update log_max_qp value to be 17 at most")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Fix the value of MLX5E_MAX_RQ_NUM_MTTS [+ + +]
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Thu May 26 16:48:47 2022 +0300

    net/mlx5e: Fix the value of MLX5E_MAX_RQ_NUM_MTTS
    
    [ Upstream commit 562696c3c62c7c23dd896e9447252ce9268cb812 ]
    
    MLX5E_MAX_RQ_NUM_MTTS should be the maximum value, so that
    MLX5_MTT_OCTW(MLX5E_MAX_RQ_NUM_MTTS) fits into u16. The current value of
    1 << 17 results in MLX5_MTT_OCTW(1 << 17) = 1 << 16, which doesn't fit
    into u16. This commit replaces it with the maximum value that still
    fits u16.
    
    Fixes: 73281b78a37a ("net/mlx5e: Derive Striding RQ size from MTU")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Remove WARN_ON when trying to offload an unsupported TLS cipher/version [+ + +]
Author: Gal Pressman <gal@nvidia.com>
Date:   Wed Jul 13 13:57:03 2022 +0300

    net/mlx5e: Remove WARN_ON when trying to offload an unsupported TLS cipher/version
    
    [ Upstream commit 115d9f95ea7ab780ef315dc356bebba2e07cb731 ]
    
    The driver reports whether TX/RX TLS device offloads are supported, but
    not which ciphers/versions, these should be handled by returning
    -EOPNOTSUPP when .tls_dev_add() is called.
    
    Remove the WARN_ON kernel trace when the driver gets a request to
    offload a cipher/version that is not supported as it is expected.
    
    Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: 9p: fix refcount leak in p9_read_work() error handling [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Wed Jul 13 09:55:11 2022 +0900

    net: 9p: fix refcount leak in p9_read_work() error handling
    
    [ Upstream commit 4ac7573e1f9333073fa8d303acc941c9b7ab7f61 ]
    
    p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid
    temporary refcount leak.
    
    Link: https://lkml.kernel.org/r/20220712104438.30800-1-hbh25y@gmail.com
    Fixes: 728356dedeff ("9p: Add refcount to p9_req_t")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: allow unbound socket for packets in VRF when tcp_l3mdev_accept set [+ + +]
Author: Mike Manning <mvrmanning@gmail.com>
Date:   Mon Jul 25 19:14:42 2022 +0100

    net: allow unbound socket for packets in VRF when tcp_l3mdev_accept set
    
    [ Upstream commit 944fd1aeacb627fa617f85f8e5a34f7ae8ea4d8e ]
    
    The commit 3c82a21f4320 ("net: allow binding socket in a VRF when
    there's an unbound socket") changed the inet socket lookup to avoid
    packets in a VRF from matching an unbound socket. This is to ensure the
    necessary isolation between the default and other VRFs for routing and
    forwarding. VRF-unaware processes running in the default VRF cannot
    access another VRF and have to be run with 'ip vrf exec <vrf>'. This is
    to be expected with tcp_l3mdev_accept disabled, but could be reallowed
    when this sysctl option is enabled. So instead of directly checking dif
    and sdif in inet[6]_match, here call inet_sk_bound_dev_eq(). This
    allows a match on unbound socket for non-zero sdif i.e. for packets in
    a VRF, if tcp_l3mdev_accept is enabled.
    
    Fixes: 3c82a21f4320 ("net: allow binding socket in a VRF when there's an unbound socket")
    Signed-off-by: Mike Manning <mvrmanning@gmail.com>
    Link: https://lore.kernel.org/netdev/a54c149aed38fded2d3b5fdb1a6c89e36a083b74.camel@lasnet.de/
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix sk_wmem_schedule() and sk_rmem_schedule() errors [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 8 23:34:10 2022 -0700

    net: fix sk_wmem_schedule() and sk_rmem_schedule() errors
    
    [ Upstream commit 7c80b038d23e1f4c7fcc311f43f83b8c60e7fb80 ]
    
    If sk->sk_forward_alloc is 150000, and we need to schedule 150001 bytes,
    we want to allocate 1 byte more (rounded up to one page),
    instead of 150001 :/
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hinic: avoid kernel hung in hinic_get_stats64() [+ + +]
Author: Qiao Ma <mqaio@linux.alibaba.com>
Date:   Tue Jul 5 19:22:23 2022 +0800

    net: hinic: avoid kernel hung in hinic_get_stats64()
    
    [ Upstream commit 98f9fcdee35add80505b6c73f72de5f750d5c03c ]
    
    When using hinic device as a bond slave device, and reading device stats
    of master bond device, the kernel may hung.
    
    The kernel panic calltrace as follows:
    Kernel panic - not syncing: softlockup: hung tasks
    Call trace:
      native_queued_spin_lock_slowpath+0x1ec/0x31c
      dev_get_stats+0x60/0xcc
      dev_seq_printf_stats+0x40/0x120
      dev_seq_show+0x1c/0x40
      seq_read_iter+0x3c8/0x4dc
      seq_read+0xe0/0x130
      proc_reg_read+0xa8/0xe0
      vfs_read+0xb0/0x1d4
      ksys_read+0x70/0xfc
      __arm64_sys_read+0x20/0x30
      el0_svc_common+0x88/0x234
      do_el0_svc+0x2c/0x90
      el0_svc+0x1c/0x30
      el0_sync_handler+0xa8/0xb0
      el0_sync+0x148/0x180
    
    And the calltrace of task that actually caused kernel hungs as follows:
      __switch_to+124
      __schedule+548
      schedule+72
      schedule_timeout+348
      __down_common+188
      __down+24
      down+104
      hinic_get_stats64+44 [hinic]
      dev_get_stats+92
      bond_get_stats+172 [bonding]
      dev_get_stats+92
      dev_seq_printf_stats+60
      dev_seq_show+24
      seq_read_iter+964
      seq_read+220
      proc_reg_read+164
      vfs_read+172
      ksys_read+108
      __arm64_sys_read+28
      el0_svc_common+132
      do_el0_svc+40
      el0_svc+24
      el0_sync_handler+164
      el0_sync+324
    
    When getting device stats from bond, kernel will call bond_get_stats().
    It first holds the spinlock bond->stats_lock, and then call
    hinic_get_stats64() to collect hinic device's stats.
    However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to
    protect its critical section, which may schedule current task out.
    And if system is under high pressure, the task cannot be woken up
    immediately, which eventually triggers kernel hung panic.
    
    Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local
    variable in hinic_get_stats64(), there is nothing need to be protected
    by lock, so just removing down()/up() is ok.
    
    Fixes: edd384f682cc ("net-next/hinic: Add ethtool and stats")
    Signed-off-by: Qiao Ma <mqaio@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hinic: fix bug that ethtool get wrong stats [+ + +]
Author: Qiao Ma <mqaio@linux.alibaba.com>
Date:   Tue Jul 5 19:22:22 2022 +0800

    net: hinic: fix bug that ethtool get wrong stats
    
    [ Upstream commit 67dffd3db98570af8ff54c934f7d14664c0d182a ]
    
    Function hinic_get_stats64() will do two operations:
    1. reads stats from every hinic_rxq/txq and accumulates them
    2. calls hinic_rxq/txq_clean_stats() to clean every rxq/txq's stats
    
    For hinic_get_stats64(), it could get right data, because it sums all
    data to nic_dev->rx_stats/tx_stats.
    But it is wrong for get_drv_queue_stats(), this function will read
    hinic_rxq's stats, which have been cleared to zero by hinic_get_stats64().
    
    I have observed hinic's cleanup operation by using such command:
    > watch -n 1 "cat ethtool -S eth4 | tail -40"
    
    Result before:
         ...
         rxq7_pkts: 1
         rxq7_bytes: 90
         rxq7_errors: 0
         rxq7_csum_errors: 0
         rxq7_other_errors: 0
         ...
         rxq9_pkts: 11
         rxq9_bytes: 726
         rxq9_errors: 0
         rxq9_csum_errors: 0
         rxq9_other_errors: 0
         ...
         rxq11_pkts: 0
         rxq11_bytes: 0
         rxq11_errors: 0
         rxq11_csum_errors: 0
         rxq11_other_errors: 0
    
    Result after a few seconds:
         ...
         rxq7_pkts: 0
         rxq7_bytes: 0
         rxq7_errors: 0
         rxq7_csum_errors: 0
         rxq7_other_errors: 0
         ...
         rxq9_pkts: 2
         rxq9_bytes: 132
         rxq9_errors: 0
         rxq9_csum_errors: 0
         rxq9_other_errors: 0
         ...
         rxq11_pkts: 1
         rxq11_bytes: 170
         rxq11_errors: 0
         rxq11_csum_errors: 0
         rxq11_other_errors: 0
    
    To solve this problem, we just keep every queue's total stats in their own
    queue (aka hinic_{rxq|txq}), and simply sum all per-queue stats every time
    calling hinic_get_stats64().
    With that solution, there is no need to clean per-queue stats now,
    and there is no need to maintain global hinic_dev.{tx|rx}_stats, too.
    
    Fixes: edd384f682cc ("net-next/hinic: Add ethtool and stats")
    Signed-off-by: Qiao Ma <mqaio@linux.alibaba.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ionic: fix error check for vlan flags in ionic_set_nic_features() [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Fri Jul 29 18:17:55 2022 +0800

    net: ionic: fix error check for vlan flags in ionic_set_nic_features()
    
    [ Upstream commit a86e86db5e6d72c82724a63ca1c5293409a21518 ]
    
    The prototype of input features of ionic_set_nic_features() is
    netdev_features_t, but the vlan_flags is using the private
    definition of ionic drivers. It should use the variable
    ctx.cmd.lif_setattr.features, rather than features to check
    the vlan flags. So fixes it.
    
    Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Acked-by: Shannon Nelson <snelson@pensando.io>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: smsc: Disable Energy Detect Power-Down in interrupt mode [+ + +]
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Jun 20 13:04:50 2022 +0200

    net: phy: smsc: Disable Energy Detect Power-Down in interrupt mode
    
    commit 2642cc6c3bbe0900ba15bab078fd15ad8baccbc5 upstream.
    
    Simon reports that if two LAN9514 USB adapters are directly connected
    without an intermediate switch, the link fails to come up and link LEDs
    remain dark.  The issue was introduced by commit 1ce8b37241ed ("usbnet:
    smsc95xx: Forward PHY interrupts to PHY driver to avoid polling").
    
    The PHY suffers from a known erratum wherein link detection becomes
    unreliable if Energy Detect Power-Down is used.  In poll mode, the
    driver works around the erratum by briefly disabling EDPD for 640 msec
    to detect a neighbor, then re-enabling it to save power.
    
    In interrupt mode, no interrupt is signaled if EDPD is used by both link
    partners, so it must not be enabled at all.
    
    We'll recoup the power savings by enabling SUSPEND1 mode on affected
    LAN95xx chips in a forthcoming commit.
    
    Fixes: 1ce8b37241ed ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling")
    Reported-by: Simon Han <z.han@kunbus.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Link: https://lore.kernel.org/r/439a3f3168c2f9d44b5fd9bb8d2b551711316be6.1655714438.git.lukas@wunner.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: rose: fix netdev reference changes [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jul 29 09:12:32 2022 +0000

    net: rose: fix netdev reference changes
    
    [ Upstream commit 931027820e4dafabc78aff82af59f8c1c4bd3128 ]
    
    Bernard reported that trying to unload rose module would lead
    to infamous messages:
    
    unregistered_netdevice: waiting for rose0 to become free. Usage count = xx
    
    This patch solves the issue, by making sure each socket referring to
    a netdevice holds a reference count on it, and properly releases it
    in rose_release().
    
    rose_dev_first() is also fixed to take a device reference
    before leaving the rcu_read_locked section.
    
    Following patch will add ref_tracker annotations to ease
    future bug hunting.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Bernard Pidoux <f6bvp@free.fr>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Bernard Pidoux <f6bvp@free.fr>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: make USB_RTL8153_ECM non user configurable [+ + +]
Author: Maciej Żenczykowski <maze@google.com>
Date:   Sat Jul 30 16:01:13 2022 -0700

    net: usb: make USB_RTL8153_ECM non user configurable
    
    [ Upstream commit f56530dcdb0684406661ac9f1accf48319d07600 ]
    
    This refixes:
    
        commit 7da17624e7948d5d9660b910f8079d26d26ce453
        nt: usb: USB_RTL8153_ECM should not default to y
    
        In general, device drivers should not be enabled by default.
    
    which basically broke the commit it claimed to fix, ie:
    
        commit 657bc1d10bfc23ac06d5d687ce45826c760744f9
        r8153_ecm: avoid to be prior to r8152 driver
    
        Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled
        as modules. Otherwise, the r8153_ecm would be used, even though the
        device is supported by r8152 driver.
    
    this commit amounted to:
    
    drivers/net/usb/Kconfig:
    
    +config USB_RTL8153_ECM
    +       tristate "RTL8153 ECM support"
    +       depends on USB_NET_CDCETHER && (USB_RTL8152 || USB_RTL8152=n)
    +       default y
    +       help
    +         This option supports ECM mode for RTL8153 ethernet adapter, when
    +         CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not
    +         supported by r8152 driver.
    
    drivers/net/usb/Makefile:
    
    -obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r8153_ecm.o
    +obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
    +obj-$(CONFIG_USB_RTL8153_ECM)  += r8153_ecm.o
    
    And as can be seen it pulls a piece of the cdc_ether driver out into
    a separate config option to be able to make this piece modular in case
    cdc_ether is builtin, while r8152 is modular.
    
    While in general, device drivers should indeed not be enabled by default:
    this isn't a device driver per say, but rather this is support code for
    the CDCETHER (ECM) driver, and should thus be enabled if it is enabled.
    
    See also email thread at:
      https://www.spinics.net/lists/netdev/msg767649.html
    
    In:
      https://www.spinics.net/lists/netdev/msg768284.html
    
    Jakub wrote:
      And when we say "removed" we can just hide it from what's prompted
      to the user (whatever such internal options are called)? I believe
      this way we don't bring back Marek's complaint.
    
    Side note: these incorrect defaults will result in Android 13
    on 5.15 GKI kernels lacking USB_RTL8153_ECM support while having
    USB_NET_CDCETHER (luckily we also have USB_RTL8150 and USB_RTL8152,
    so it's probably only an issue for very new RTL815x hardware with
    no native 5.15 driver).
    
    Fixes: 7da17624e7948d5d ("nt: usb: USB_RTL8153_ECM should not default to y")
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Hayes Wang <hayeswang@realtek.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20220730230113.4138858-1-zenczykowski@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net_sched: cls_route: remove from list when handle is 0 [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:05:18 2022 -0300

    net_sched: cls_route: remove from list when handle is 0
    
    commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream.
    
    When a route filter is replaced and the old filter has a 0 handle, the old
    one won't be removed from the hashtable, while it will still be freed.
    
    The test was there since before commit 1109c00547fc ("net: sched: RCU
    cls_route"), when a new filter was not allocated when there was an old one.
    The old filter was reused and the reinserting would only be necessary if an
    old filter was replaced. That was still wrong for the same case where the
    old handle was 0.
    
    Remove the old filter from the list independently from its handle value.
    
    This fixes CVE-2022-2588, also reported as ZDI-CAN-17440.
    
    Reported-by: Zhenpeng Lin <zplin@u.northwestern.edu>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Reviewed-by: Kamal Mostafa <kamal@canonical.com>
    Cc: <stable@vger.kernel.org>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20220809170518.164662-1-cascardo@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netdevsim: Avoid allocation warnings triggered from user space [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Jul 26 14:36:05 2022 -0700

    netdevsim: Avoid allocation warnings triggered from user space
    
    [ Upstream commit d0b80a9edb1a029ff913e81b47540e57ad034329 ]
    
    We need to suppress warnings from sily map sizes. Also switch
    from GFP_USER to GFP_KERNEL_ACCOUNT, I'm pretty sure I misunderstood
    the flags when writing this code.
    
    Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload")
    Reported-by: syzbot+ad24705d3fd6463b18c6@syzkaller.appspotmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20220726213605.154204-1-kuba@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netdevsim: fib: Fix reference count leak on route deletion failure [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Thu Jul 28 14:45:33 2022 +0300

    netdevsim: fib: Fix reference count leak on route deletion failure
    
    [ Upstream commit 180a6a3ee60a7cb69ed1232388460644f6a21f00 ]
    
    As part of FIB offload simulation, netdevsim stores IPv4 and IPv6 routes
    and holds a reference on FIB info structures that in turn hold a
    reference on the associated nexthop device(s).
    
    In the unlikely case where we are unable to allocate memory to process a
    route deletion request, netdevsim will not release the reference from
    the associated FIB info structure, thereby preventing the associated
    nexthop device(s) from ever being removed [1].
    
    Fix this by scheduling a work item that will flush netdevsim's FIB table
    upon route deletion failure. This will cause netdevsim to release its
    reference from all the FIB info structures in its table.
    
    Reported by Lucas Leong of Trend Micro Zero Day Initiative.
    
    Fixes: 0ae3eb7b4611 ("netdevsim: fib: Perform the route programming in a non-atomic context")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: do not allow CHAIN_ID to refer to another table [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:01:47 2022 -0300

    netfilter: nf_tables: do not allow CHAIN_ID to refer to another table
    
    commit 95f466d22364a33d183509629d0879885b4f547e upstream.
    
    When doing lookups for chains on the same batch by using its ID, a chain
    from a different table can be used. If a rule is added to a table but
    refers to a chain in a different table, it will be linked to the chain in
    table2, but would have expressions referring to objects in table1.
    
    Then, when table1 is removed, the rule will not be removed as its linked to
    a chain in table2. When expressions in the rule are processed or removed,
    that will lead to a use-after-free.
    
    When looking for chains by ID, use the table that was used for the lookup
    by name, and only return chains belonging to that same table.
    
    Fixes: 837830a4b439 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: do not allow RULE_ID to refer to another chain [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:01:48 2022 -0300

    netfilter: nf_tables: do not allow RULE_ID to refer to another chain
    
    commit 36d5b2913219ac853908b0f1c664345e04313856 upstream.
    
    When doing lookups for rules on the same batch by using its ID, a rule from
    a different chain can be used. If a rule is added to a chain but tries to
    be positioned next to a rule from a different chain, it will be linked to
    chain2, but the use counter on chain1 would be the one to be incremented.
    
    When looking for rules by ID, use the chain that was used for the lookup by
    name. The chain used in the context copied to the transaction needs to
    match that same chain. That way, struct nft_rule does not need to get
    enlarged with another member.
    
    Fixes: 1a94e38d254b ("netfilter: nf_tables: add NFTA_RULE_ID attribute")
    Fixes: 75dd48e2e420 ("netfilter: nf_tables: Support RULE_ID reference in new rule")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: do not allow SET_ID to refer to another table [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:01:46 2022 -0300

    netfilter: nf_tables: do not allow SET_ID to refer to another table
    
    commit 470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2 upstream.
    
    When doing lookups for sets on the same batch by using its ID, a set from a
    different table can be used.
    
    Then, when the table is removed, a reference to the set may be kept after
    the set is freed, leading to a potential use-after-free.
    
    When looking for sets by ID, use the table that was used for the lookup by
    name, and only return sets belonging to that same table.
    
    This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.
    
    Reported-by: Team Orca of Sea Security (@seasecresponse)
    Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: fix null deref due to zeroed list head [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 9 18:34:02 2022 +0200

    netfilter: nf_tables: fix null deref due to zeroed list head
    
    commit 580077855a40741cf511766129702d97ff02f4d9 upstream.
    
    In nf_tables_updtable, if nf_tables_table_enable returns an error,
    nft_trans_destroy is called to free the transaction object.
    
    nft_trans_destroy() calls list_del(), but the transaction was never
    placed on a list -- the list head is all zeroes, this results in
    a null dereference:
    
    BUG: KASAN: null-ptr-deref in nft_trans_destroy+0x26/0x59
    Call Trace:
     nft_trans_destroy+0x26/0x59
     nf_tables_newtable+0x4bc/0x9bc
     [..]
    
    Its sane to assume that nft_trans_destroy() can be called
    on the transaction object returned by nft_trans_alloc(), so
    make sure the list head is initialised.
    
    Fixes: 55dd6f93076b ("netfilter: nf_tables: use new transaction infrastructure to handle table")
    Reported-by: mingi cho <mgcho.minic@gmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: xtables: Bring SPDX identifier back [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Jun 6 17:23:45 2022 +0200

    netfilter: xtables: Bring SPDX identifier back
    
    [ Upstream commit 20646f5b1e798bcc20044ae90ac3702f177bf254 ]
    
    Commit e2be04c7f995 ("License cleanup: add SPDX license identifier to
    uapi header files with a license") added the correct SPDX identifier to
    include/uapi/linux/netfilter/xt_IDLETIMER.h.
    
    A subsequent commit removed it for no reason and reintroduced the UAPI
    license incorrectness as the file is now missing the UAPI exception
    again.
    
    Add it back and remove the GPLv2 boilerplate while at it.
    
    Fixes: 68983a354a65 ("netfilter: xtables: Add snapshot of hardidletimer target")
    Cc: Manoj Basapathi <manojbm@codeaurora.org>
    Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: netfilter-devel@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: Clean up the show_nf_flags() macro [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sun Mar 27 16:43:03 2022 -0400

    NFSD: Clean up the show_nf_flags() macro
    
    commit bb283ca18d1e67c82d22a329c96c9d6036a74790 upstream.
    
    The flags are defined using C macros, so TRACE_DEFINE_ENUM is
    unnecessary.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: eliminate the NFSD_FILE_BREAK_* flags [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Jul 29 17:01:07 2022 -0400

    nfsd: eliminate the NFSD_FILE_BREAK_* flags
    
    commit 23ba98de6dcec665e15c0ca19244379bb0d30932 upstream.
    
    We had a report from the spring Bake-a-thon of data corruption in some
    nfstest_interop tests. Looking at the traces showed the NFS server
    allowing a v3 WRITE to proceed while a read delegation was still
    outstanding.
    
    Currently, we only set NFSD_FILE_BREAK_* flags if
    NFSD_MAY_NOT_BREAK_LEASE was set when we call nfsd_file_alloc.
    NFSD_MAY_NOT_BREAK_LEASE was intended to be set when finding files for
    COMMIT ops, where we need a writeable filehandle but don't need to
    break read leases.
    
    It doesn't make any sense to consult that flag when allocating a file
    since the file may be used on subsequent calls where we do want to break
    the lease (and the usage of it here seems to be reverse from what it
    should be anyway).
    
    Also, after calling nfsd_open_break_lease, we don't want to clear the
    BREAK_* bits. A lease could end up being set on it later (more than
    once) and we need to be able to break those leases as well.
    
    This means that the NFSD_FILE_BREAK_* flags now just mirror
    NFSD_MAY_{READ,WRITE} flags, so there's no need for them at all. Just
    drop those flags and unconditionally call nfsd_open_break_lease every
    time.
    
    Reported-by: Olga Kornieskaia <kolga@netapp.com>
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2107360
    Fixes: 65294c1f2c5e (nfsd: add a new struct file caching facility to nfsd)
    Cc: <stable@vger.kernel.org> # 5.4.x : bb283ca18d1e NFSD: Clean up the show_nf_flags() macro
    Cc: <stable@vger.kernel.org> # 5.4.x
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt() [+ + +]
Author: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Date:   Tue Jun 28 11:22:59 2022 +0200

    nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt()
    
    [ Upstream commit 5c66d1b9b30f737fcef85a0b75bfe0590e16b62a ]
    
    dequeue_task_rt() only decrements 'rt_rq->rt_nr_running' after having
    called sched_update_tick_dependency() preventing it from re-enabling the
    tick on systems that no longer have pending SCHED_RT tasks but have
    multiple runnable SCHED_OTHER tasks:
    
      dequeue_task_rt()
        dequeue_rt_entity()
          dequeue_rt_stack()
            dequeue_top_rt_rq()
              sub_nr_running()      // decrements rq->nr_running
                sched_update_tick_dependency()
                  sched_can_stop_tick()     // checks rq->rt.rt_nr_running,
                  ...
            __dequeue_rt_entity()
              dec_rt_tasks()        // decrements rq->rt.rt_nr_running
              ...
    
    Every other scheduler class performs the operation in the opposite
    order, and sched_update_tick_dependency() expects the values to be
    updated as such. So avoid the misbehaviour by inverting the order in
    which the above operations are performed in the RT scheduler.
    
    Fixes: 76d92ac305f2 ("sched: Migrate sched to use new tick dependency mask model")
    Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Reviewed-by: Phil Auld <pauld@redhat.com>
    Link: https://lore.kernel.org/r/20220628092259.330171-1-nsaenzju@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
null_blk: fix ida error handling in null_add_dev() [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 15 11:12:14 2022 +0300

    null_blk: fix ida error handling in null_add_dev()
    
    [ Upstream commit ee452a8d984f94fa8e894f003a52e776e4572881 ]
    
    There needs to be some error checking if ida_simple_get() fails.
    Also call ida_free() if there are errors later.
    
    Fixes: 94bc02e30fb8 ("nullb: use ida to manage index")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YtEhXsr6vJeoiYhd@kili
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: catch -ENODEV from nvme_revalidate_zones again [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jul 21 07:56:35 2022 +0200

    nvme: catch -ENODEV from nvme_revalidate_zones again
    
    [ Upstream commit e06b425bc835ead08b9fd935bf5e47eef473e7a0 ]
    
    nvme_revalidate_zones can also return -ENODEV if e.g. zone sizes aren't
    constant or not a power of two.  In that case we should jump to marking
    the gendisk hidden and only support pass through.
    
    Fixes: 602e57c9799c ("nvme: also mark passthrough-only namespaces ready in nvme_update_ns_info")
    Reported-by: Joel Granados <j.granados@samsung.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Joel Granados <j.granados@samsung.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: define compat_ioctl again to unbreak 32-bit userspace. [+ + +]
Author: Nick Bowler <nbowler@draconx.ca>
Date:   Wed Jul 20 23:57:35 2022 -0400

    nvme: define compat_ioctl again to unbreak 32-bit userspace.
    
    [ Upstream commit a25d4261582cf00dad884c194d21084836663d3d ]
    
    Commit 89b3d6e60550 ("nvme: simplify the compat ioctl handling") removed
    the initialization of compat_ioctl from the nvme block_device_operations
    structures.
    
    Presumably the expectation was that 32-bit ioctls would be directed
    through the regular handler but this is not the case: failing to assign
    .compat_ioctl actually means that the compat case is disabled entirely,
    and any attempt to submit nvme ioctls from 32-bit userspace fails
    outright with -ENOTTY.
    
    For example:
    
      % smartctl -x /dev/nvme0n1
      [...]
      Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device
    
    The blkdev_compat_ptr_ioctl helper can be used to direct compat calls
    through the main ioctl handler and makes things work again.
    
    Fixes: 89b3d6e60550 ("nvme: simplify the compat ioctl handling")
    Signed-off-by: Nick Bowler <nbowler@draconx.ca>
    Reviewed-by: Guixin Liu <kanie@linux.alibaba.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: disable namespace access for unsupported metadata [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue Nov 30 08:14:54 2021 -0800

    nvme: disable namespace access for unsupported metadata
    
    [ Upstream commit d39ad2a45c0e38def3e0c95f5b90d9af4274c939 ]
    
    The only fabrics target that supports metadata handling through the
    separate integrity buffer is RDMA. It is currently usable only if the
    size is 8B per block and formatted for protection information. If an
    rdma target were to export a namespace with a different format (ex:
    4k+64B), the driver will not be able to submit valid read/write commands
    for that namespace.
    
    Suppress setting the metadata feature in the namespace so that the
    gendisk capacity will be set to 0. This will prevent read/write access
    through the block stack, but will continue to allow ioctl passthrough
    commands.
    
    Cc: Max Gurtovoy <mgurtovoy@nvidia.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: don't return an error from nvme_configure_metadata [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Feb 16 15:07:15 2022 +0100

    nvme: don't return an error from nvme_configure_metadata
    
    [ Upstream commit 363f6368603743072e5f318c668c632bccb097a3 ]
    
    When a fabrics controller claims to support an invalidate metadata
    configuration we already warn and disable metadata support.  No need to
    also return an error during revalidation.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Daniel Wagner <dwagner@suse.de>
    Tested-by: Kanchan Joshi <joshi.k@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: use command_id instead of req->tag in trace_nvme_complete_rq() [+ + +]
Author: Bean Huo <beanhuo@micron.com>
Date:   Fri Jul 15 23:27:21 2022 +0200

    nvme: use command_id instead of req->tag in trace_nvme_complete_rq()
    
    [ Upstream commit 679c54f2de672b7d79d02f8c4ad483ff6dd8ce2e ]
    
    Use command_id instead of req->tag in trace_nvme_complete_rq(),
    because of commit e7006de6c238 ("nvme: code command_id with a genctr
    for use authentication after release"), cmd->common.command_id is set to
    ((genctl & 0xf)< 12 | req->tag), no longer req->tag, which makes cid in
    trace_nvme_complete_rq and trace_nvme_setup_cmd are not the same.
    
    Fixes: e7006de6c238 ("nvme: code command_id with a genctr for use authentication after release")
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of/fdt: declared return type does not match actual return type [+ + +]
Author: Xu Qiang <xuqiang36@huawei.com>
Date:   Mon Aug 1 12:05:06 2022 +0000

    of/fdt: declared return type does not match actual return type
    
    [ Upstream commit 7913145afa51bbed9eaf8e5b4ee55fa9884a71e5 ]
    
    The commit 649cab56de8e (“of: properly check for error returned
    by fdt_get_name()”) changed the return value type from bool to int,
    but forgot to change the return value simultaneously.
    
    populate_node was only called in unflatten_dt_nodes, and returns
    with values greater than or equal to 0 were discarded without further
    processing. Considering that return 0 usually indicates success,
    return 0 instead of return true.
    
    Fixes: 649cab56de8e (“of: properly check for error returned by fdt_get_name()”)
    Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220801120506.11461-2-xuqiang36@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: check previous kernel's ima-kexec-buffer against memory bounds [+ + +]
Author: Vaibhav Jain <vaibhav@linux.ibm.com>
Date:   Tue May 31 09:44:46 2022 +0530

    of: check previous kernel's ima-kexec-buffer against memory bounds
    
    [ Upstream commit cbf9c4b9617b6767886a913705ca14b7600c77db ]
    
    Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
    ima-kexec-buffer lies outside the addressable memory range. This can result
    in a kernel panic if the new kernel is booted with 'mem=X' arg and the
    ima-kexec-buffer was allocated beyond that range by the previous kernel.
    The panic is usually of the form below:
    
    $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
    
    <snip>
     BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
     Faulting instruction address: 0xc000000000837974
     Oops: Kernel access of bad area, sig: 11 [#1]
    <snip>
     NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
     LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
     Call Trace:
     [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
     [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
     [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
     [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
     [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
     [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
     [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
     Instruction dump:
     f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
     7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010
     ---[ end trace 0000000000000000 ]---
    
    Fix this issue by checking returned PFN range of previous kernel's
    ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.
    
    Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel")
    Cc: Frank Rowand <frowand.list@gmail.com>
    Cc: Prakhar Srivastava <prsriva@linux.microsoft.com>
    Cc: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
    Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Ritesh Harjani <ritesh.list@gmail.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220531041446.3334259-1-vaibhav@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer [+ + +]
Author: Liang He <windhl@126.com>
Date:   Sat Jul 2 09:44:49 2022 +0800

    of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer
    
    [ Upstream commit d17e37c41b7ed38459957a5d2968ba61516fd5c2 ]
    
    We should use of_node_put() for the reference 'node' returned by
    of_parse_phandle() which will increase the refcount.
    
    Fixes: fec9b625095f ("of: Add plumbing for restricted DMA pool")
    Co-authored-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220702014449.263772-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
opp: Fix error check in dev_pm_opp_attach_genpd() [+ + +]
Author: Tang Bin <tangbin@cmss.chinamobile.com>
Date:   Tue May 24 20:31:51 2022 +0800

    opp: Fix error check in dev_pm_opp_attach_genpd()
    
    [ Upstream commit 4ea9496cbc959eb5c78f3e379199aca9ef4e386b ]
    
    dev_pm_domain_attach_by_name() may return NULL in some cases,
    so IS_ERR() doesn't meet the requirements. Thus fix it.
    
    Fixes: 6319aee10e53 ("opp: Attach genpds to devices from within OPP core")
    Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
    [ Viresh: Replace ENODATA with ENODEV ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh() [+ + +]
Author: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Date:   Thu Jul 28 19:49:15 2022 +0800

    ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh()
    
    commit dd524b7f317de8d31d638cbfdc7be4cf9b770e42 upstream.
    
    Some code paths cannot guarantee the inode have any dentry alias. So
    WARN_ON() all !dentry may flood the kernel logs.
    
    For example, when an overlayfs inode is watched by inotifywait (1), and
    someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD,
    at that time if the dentry has been reclaimed by kernel (such as
    echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The
    printed call stack would be like:
    
        ? show_mark_fhandle+0xf0/0xf0
        show_mark_fhandle+0x4a/0xf0
        ? show_mark_fhandle+0xf0/0xf0
        ? seq_vprintf+0x30/0x50
        ? seq_printf+0x53/0x70
        ? show_mark_fhandle+0xf0/0xf0
        inotify_fdinfo+0x70/0x90
        show_fdinfo.isra.4+0x53/0x70
        seq_show+0x130/0x170
        seq_read+0x153/0x440
        vfs_read+0x94/0x150
        ksys_read+0x5f/0xe0
        do_syscall_64+0x59/0x1e0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    So let's drop WARN_ON() to avoid kernel log flooding.
    
    Reported-by: Hongbo Yin <yinhongbo@bytedance.com>
    Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
    Signed-off-by: Tianci Zhang <zhangtianci.1997@bytedance.com>
    Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles")
    Cc: <stable@vger.kernel.org> # v4.16
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
parisc: Check the return value of ioremap() in lba_driver_probe() [+ + +]
Author: William Dean <williamsukatube@gmail.com>
Date:   Fri Jul 22 10:57:09 2022 +0800

    parisc: Check the return value of ioremap() in lba_driver_probe()
    
    commit cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 upstream.
    
    The function ioremap() in lba_driver_probe() can fail, so
    its return value should be checked.
    
    Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache")
    Reported-by: Hacash Robot <hacashRobot@santino.com>
    Signed-off-by: William Dean <williamsukatube@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v5.6+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Drop pa_swapper_pg_lock spinlock [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Tue Jul 19 06:19:41 2022 +0200

    parisc: Drop pa_swapper_pg_lock spinlock
    
    commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream.
    
    This spinlock was dropped with commit b7795074a046 ("parisc: Optimize
    per-pagetable spinlocks") in kernel v5.12.
    
    Remove it to silence a sparse warning.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: <stable@vger.kernel.org> # v5.12+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Fix device names in /proc/iomem [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Mon Jul 18 17:06:47 2022 +0200

    parisc: Fix device names in /proc/iomem
    
    commit cab56b51ec0e69128909cef4650e1907248d821b upstream.
    
    Fix the output of /proc/iomem to show the real hardware device name
    including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]".
    Up to now only the pa_pathname ("[8:16.0]") was shown.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Mon Aug 1 17:36:15 2022 +0200

    parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode
    
    commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream.
    
    For all syscalls in 32-bit compat mode on 64-bit kernels the upper
    32-bits of the 64-bit registers are zeroed out, so a negative 32-bit
    signed value will show up as positive 64-bit signed value.
    
    This behaviour breaks the io_pgetevents_time64() syscall which expects
    signed 64-bit values for the "min_nr" and "nr" parameters.
    Fix this by switching to the compat_sys_io_pgetevents_time64() syscall,
    which uses "compat_long_t" types for those parameters.
    
    Cc: <stable@vger.kernel.org> # v5.1+
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI/AER: Iterate over error counters instead of error strings [+ + +]
Author: Mohamed Khalfella <mkhalfella@purestorage.com>
Date:   Mon May 9 18:14:41 2022 +0000

    PCI/AER: Iterate over error counters instead of error strings
    
    [ Upstream commit 5e6ae050955b566484f3cc6a66e3925eae87a0ed ]
    
    Previously we iterated over AER stat *names*, e.g.,
    aer_correctable_error_string[32], but the actual stat *counters* may not be
    that large, e.g., pdev->aer_stats->dev_cor_errs[16], which means that we
    printed junk in the sysfs stats files.
    
    Iterate over the stat counter arrays instead of the names to avoid this
    junk.
    
    Also, added a build time check to make sure all
    counters have entries in strings array.
    
    Fixes: 0678e3109a3c ("PCI/AER: Simplify __aer_print_error()")
    Link: https://lore.kernel.org/r/20220509181441.31884-1-mkhalfella@purestorage.com
    Reported-by: Meeta Saggi <msaggi@purestorage.com>
    Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Meeta Saggi <msaggi@purestorage.com>
    Reviewed-by: Eric Badger <ebadger@purestorage.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/portdrv: Don't disable AER reporting in get_port_device_capability() [+ + +]
Author: Stefan Roese <sr@denx.de>
Date:   Tue Jan 25 08:18:19 2022 +0100

    PCI/portdrv: Don't disable AER reporting in get_port_device_capability()
    
    [ Upstream commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 ]
    
    AER reporting is currently disabled in the DevCtl registers of all non Root
    Port PCIe devices on systems using pcie_ports_native || host->native_aer,
    disabling AER completely in such systems. This is because 2bd50dd800b5
    ("PCI: PCIe: Disable PCIe port services during port initialization"), added
    a call to pci_disable_pcie_error_reporting() *after* the AER setup was
    completed for the PCIe device tree.
    
    Here a longer analysis about the current status of AER enabling /
    disabling upon bootup provided by Bjorn:
    
      pcie_portdrv_probe
        pcie_port_device_register
          get_port_device_capability
            pci_disable_pcie_error_reporting
              clear CERE NFERE FERE URRE               # <-- disable for RP USP DSP
          pcie_device_init
            device_register                            # new AER service device
              aer_probe
                aer_enable_rootport                    # RP only
                  set_downstream_devices_error_reporting
                    set_device_error_reporting         # self (RP)
                      if (RP || USP || DSP)
                        pci_enable_pcie_error_reporting
                          set CERE NFERE FERE URRE     # <-- enable for RP
                    pci_walk_bus
                      set_device_error_reporting
                        if (RP || USP || DSP)
                          pci_enable_pcie_error_reporting
                            set CERE NFERE FERE URRE   # <-- enable for USP DSP
    
    In a typical Root Port -> Endpoint hierarchy, the above:
      - Disables Error Reporting for the Root Port,
      - Enables Error Reporting for the Root Port,
      - Does NOT enable Error Reporting for the Endpoint because it is not a
        Root Port or Switch Port.
    
    In a deeper Root Port -> Upstream Switch Port -> Downstream Switch
    Port -> Endpoint hierarchy:
      - Disables Error Reporting for the Root Port,
      - Enables Error Reporting for the Root Port,
      - Enables Error Reporting for both Switch Ports,
      - Does NOT enable Error Reporting for the Endpoint because it is not a
        Root Port or Switch Port,
      - Disables Error Reporting for the Switch Ports when pcie_portdrv_probe()
        claims them.  AER does not re-enable it because these are not Root
        Ports.
    
    Remove this call to pci_disable_pcie_error_reporting() from
    get_port_device_capability(), leaving the already enabled AER configuration
    intact. With this change, AER is enabled in the Root Port and the PCIe
    switch upstream and downstream ports. Only the PCIe Endpoints don't have
    AER enabled yet. A follow-up patch will take care of this Endpoint
    enabling.
    
    Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization")
    Link: https://lore.kernel.org/r/20220125071820.2247260-3-sr@denx.de
    Signed-off-by: Stefan Roese <sr@denx.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Pali Rohár <pali@kernel.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: Yao Hongbo <yaohongbo@linux.alibaba.com>
    Cc: Naveen Naidu <naveennaidu479@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: Add defines for normal and subtractive PCI bridges [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Feb 14 12:41:08 2022 +0100

    PCI: Add defines for normal and subtractive PCI bridges
    
    commit 904b10fb189cc15376e9bfce1ef0282e68b0b004 upstream.
    
    Add these PCI class codes to pci_ids.h:
    
      PCI_CLASS_BRIDGE_PCI_NORMAL
      PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE
    
    Use these defines in all kernel code for describing PCI class codes for
    normal and subtractive PCI bridges.
    
    [bhelgaas: similar change in pci-mvebu.c]
    Link: https://lore.kernel.org/r/20220214114109.26809-1-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Guenter Roeck <linux@roeck-us.net>a
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    [ gregkh - take only the pci_ids.h portion for stable backports ]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu() [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:12 2022 +0300

    PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu()
    
    [ Upstream commit d1cf738f2b65a5640234e1da90a68d3523fbed83 ]
    
    dw_pcie_disable_atu() was introduced by f8aed6ec624f ("PCI: dwc:
    designware: Add EP mode support") and supported only the viewport version
    of the iATU CSRs.
    
    DW PCIe IP cores v4.80a and newer also support unrolled iATU/eDMA space.
    Callers of dw_pcie_disable_atu(), including pci_epc_ops.clear_bar(),
    pci_epc_ops.unmap_addr(), and dw_pcie_setup_rc(), don't work correctly when
    it is enabled.
    
    Add dw_pcie_disable_atu() support for controllers with unrolled iATU CSRs
    enabled.
    
    [bhelgaas: commit log]
    Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
    Link: https://lore.kernel.org/r/20220624143428.8334-3-Sergey.Semin@baikalelectronics.ru
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: Always enable CDM check if "snps,enable-cdm-check" exists [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:16 2022 +0300

    PCI: dwc: Always enable CDM check if "snps,enable-cdm-check" exists
    
    [ Upstream commit ec7b952f453ce7eabe7e1bea584626934d44f668 ]
    
    If the "snps,enable-cdm-check" property exists, we should enable the CDM
    check.  But previously dw_pcie_setup() could exit before doing so if the
    "num-lanes" property was absent or invalid.
    
    Move the CDM enable earlier so we do it regardless of whether "num-lanes"
    is present.
    
    [bhelgaas: commit log]
    Fixes: 07f123def73e ("PCI: dwc: Add support to enable CDM register check")
    Link: https://lore.kernel.org/r/20220624143428.8334-7-Sergey.Semin@baikalelectronics.ru
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:15 2022 +0300

    PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
    
    [ Upstream commit 8161e9626b50892eaedbd8070ecb1586ecedb109 ]
    
    If dw_pcie_ep_init() fails to perform any action after the EPC memory is
    initialized and the MSI memory region is allocated, the latter parts won't
    be undone thus causing a memory leak.  Add a cleanup-on-error path to fix
    these leaks.
    
    [bhelgaas: commit log]
    Fixes: 2fd0c9d966cc ("PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init")
    Link: https://lore.kernel.org/r/20220624143428.8334-6-Sergey.Semin@baikalelectronics.ru
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: Disable outbound windows only for controllers using iATU [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:13 2022 +0300

    PCI: dwc: Disable outbound windows only for controllers using iATU
    
    [ Upstream commit d60a2e281e9de2b2f67343b2e39417ca0f4fd54e ]
    
    Some DWC-based controllers (e.g., pcie-al.c and pci-keystone.c, identified
    by the fact that they override the default dw_child_pcie_ops) use their own
    address translation approach instead of the DWC internal ATU (iATU).  For
    those controllers, skip disabling the iATU outbound windows.
    
    [bhelgaas: commit log, update multiple window comment]
    Fixes: 458ad06c4cdd ("PCI: dwc: Ensure all outbound ATU windows are reset")
    Link: https://lore.kernel.org/r/20220624143428.8334-4-Sergey.Semin@baikalelectronics.ru
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: Set INCREASE_REGION_SIZE flag based on limit address [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:14 2022 +0300

    PCI: dwc: Set INCREASE_REGION_SIZE flag based on limit address
    
    [ Upstream commit 777e7c3ab73036105e6fc4a67ed950179dbffbab ]
    
    We program the 64-bit ATU limit address (in PCIE_ATU_LIMIT/
    PCIE_ATU_UPPER_LIMIT or PCIE_ATU_UNR_LOWER_LIMIT/PCIE_ATU_UNR_UPPER_LIMIT),
    but in addition, the PCIE_ATU_INCREASE_REGION_SIZE bit must be set if the
    upper 32 bits of the limit address differ from the upper 32 bits of the
    base address (see [1,2]).
    
    5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") set
    PCIE_ATU_INCREASE_REGION_SIZE, but only when the *size* was greater than
    4GB.  It did not set it when a smaller region crossed a 4GB boundary, e.g.,
    [mem 0x0_f0000000-0x1_0fffffff].
    
    Set PCIE_ATU_INCREASE_REGION_SIZE whenever PCIE_ATU_UPPER_LIMIT is
    greater than PCIE_ATU_UPPER_BASE.
    
    [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
        v5.40a, March 2019, fig.3-36, p.175
    [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
        v5.40a, March 2019, fig.3-37, p.176
    
    [bhelgaas: commit log]
    Fixes: 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU")
    Link: https://lore.kernel.org/r/20220624143428.8334-5-Sergey.Semin@baikalelectronics.ru
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: Stop link on host_init errors and de-initialization [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 24 17:34:11 2022 +0300

    PCI: dwc: Stop link on host_init errors and de-initialization
    
    [ Upstream commit 113fa857b74c947137d845e7e635afcf6a59c43a ]
    
    It's logically correct to undo everything that was done when an error is
    discovered or in the corresponding cleanup counterpart. Otherwise the host
    controller will be left in an undetermined state. Since the link is set up
    in the host_init method, deactivate it there in the cleanup-on-error block
    and stop the link in the antagonistic routine - dw_pcie_host_deinit(). Link
    deactivation is platform-specific and should be implemented in
    dw_pcie_ops.stop_link().
    
    Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code")
    Link: https://lore.kernel.org/r/20220624143428.8334-2-Sergey.Semin@baikalelectronics.ru
    Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: endpoint: Don't stop controller when unbinding endpoint function [+ + +]
Author: Shunsuke Mie <mie@igel.co.jp>
Date:   Wed Jun 22 13:09:24 2022 +0900

    PCI: endpoint: Don't stop controller when unbinding endpoint function
    
    [ Upstream commit 1bc2b7bfba6e2f64edf5e246f3af2967261f6c3d ]
    
    Unbinding an endpoint function from the endpoint controller shouldn't stop
    the controller.  This is especially a problem for multi-function endpoints
    where other endpoints may still be active.
    
    Don't stop the controller when unbinding one of its endpoints.  Normally
    the controller is stopped via configfs.
    
    Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI")
    Link: https://lore.kernel.org/r/20220622040924.113279-1-mie@igel.co.jp
    Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 08:12:58 2022 +0400

    PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains()
    
    [ Upstream commit bf038503d5fe90189743124233fe7aeb0984e961 ]
    
    of_get_child_by_name() returns a node pointer with refcount incremented, so
    we should use of_node_put() on it when we don't need it anymore.
    
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 814cceebba9b ("PCI: mediatek-gen3: Add INTx support")
    Link: https://lore.kernel.org/r/20220601041259.56185-1-linmq006@gmail.com
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Miles Chen <miles.chen@mediatek.com>
    Acked-by: Jianjun Wang <jianjun.wang@mediatek.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 09:51:23 2022 +0400

    PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains()
    
    [ Upstream commit f030304fdeb87ec8f1b518c73703214aec6cc24a ]
    
    of_get_next_child() returns a node pointer with refcount incremented, so we
    should use of_node_put() on it when we don't need it anymore.
    
    mc_pcie_init_irq_domains() only calls of_node_put() in the normal path,
    missing it in some error paths.  Add missing of_node_put() to avoid
    refcount leak.
    
    Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver")
    Link: https://lore.kernel.org/r/20220605055123.59127-1-linmq006@gmail.com
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: qcom: Power on PHY before IPQ8074 DBI register accesses [+ + +]
Author: Robert Marko <robimarko@gmail.com>
Date:   Thu Jun 23 17:50:03 2022 +0200

    PCI: qcom: Power on PHY before IPQ8074 DBI register accesses
    
    [ Upstream commit a0e43bb9973b06ce5c666f0901e104e2037c1b34 ]
    
    Currently the Gen2 port in IPQ8074 will cause the system to hang as it
    accesses DBI registers in qcom_pcie_init_2_3_3(), and those are only
    accesible after phy_power_on().
    
    Move the DBI read/writes to a new qcom_pcie_post_init_2_3_3(), which is
    executed after phy_power_on().
    
    Link: https://lore.kernel.org/r/20220623155004.688090-1-robimarko@gmail.com
    Fixes: a0fd361db8e5 ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code")
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Cc: stable@vger.kernel.org      # v5.11+
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Sat Jul 9 00:27:43 2022 +0200

    PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks
    
    [ Upstream commit 38f897ae3d44900f627cad708a15db498ce2ca31 ]
    
    We currently enable clocks BEFORE we write to PARF_PHY_CTRL reg to enable
    clocks and resets. This causes the driver to never set to a ready state
    with the error 'Phy link never came up'.
    
    This is caused by the PHY clock getting enabled before setting the required
    bits in the PARF regs.
    
    A workaround for this was set but with this new discovery we can drop
    the workaround and use a proper solution to the problem by just enabling
    the clock only AFTER the PARF_PHY_CTRL bit is set.
    
    This correctly sets up the PCIe link and makes it usable even when a
    bootloader leaves the PCIe link in an undefined state.
    
    Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
    Link: https://lore.kernel.org/r/20220708222743.27019-1-ansuelsmth@gmail.com
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: tegra194: Fix link up retry sequence [+ + +]
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Thu Jul 21 19:50:50 2022 +0530

    PCI: tegra194: Fix link up retry sequence
    
    [ Upstream commit e05fd6ae77c3e2cc0dba283005d24b6d56d2b1fa ]
    
    Add the missing DLF capability offset while clearing DL_FEATURE_EXCHANGE_EN
    bit during link up retry.
    
    Link: https://lore.kernel.org/r/20220721142052.25971-15-vidyas@nvidia.com
    Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support")
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: tegra194: Fix PM error handling in tegra_pcie_config_ep() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Jun 2 07:19:08 2022 +0400

    PCI: tegra194: Fix PM error handling in tegra_pcie_config_ep()
    
    [ Upstream commit e8fbd344a5ea62663554b8546b6bf9f88b93785a ]
    
    pm_runtime_enable() will increase power disable depth.  If
    dw_pcie_ep_init() fails, we should use pm_runtime_disable() to balance it
    with pm_runtime_enable().
    
    Add missing pm_runtime_disable() for tegra_pcie_config_ep().
    
    Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
    Link: https://lore.kernel.org/r/20220602031910.55859-1-linmq006@gmail.com
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: tegra194: Fix Root Port interrupt handling [+ + +]
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Thu Jul 21 19:50:46 2022 +0530

    PCI: tegra194: Fix Root Port interrupt handling
    
    [ Upstream commit 6646e99bcec627e866bc84365af37942c72b4b76 ]
    
    As part of Root Port interrupt handling, level-0 register is read first and
    based on the bits set in that, corresponding level-1 registers are read for
    further interrupt processing. Since both these values are currently read
    into the same 'val' variable, checking level-0 bits the second time around
    is happening on the 'val' variable value of level-1 register contents
    instead of freshly reading the level-0 value again.
    
    Fix by using different variables to store level-0 and level-1 registers
    contents.
    
    Link: https://lore.kernel.org/r/20220721142052.25971-11-vidyas@nvidia.com
    Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support")
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf symbol: Fail to read phdr workaround [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Sun Jul 31 09:49:23 2022 -0700

    perf symbol: Fail to read phdr workaround
    
    [ Upstream commit 6d518ac7be6223811ab947897273b1bbef846180 ]
    
    The perf jvmti agent doesn't create program headers, in this case
    fallback on section headers as happened previously.
    
    Committer notes:
    
    To test this, from a public post by Ian:
    
    1) download a Java workload dacapo-9.12-MR1-bach.jar from
    https://sourceforge.net/projects/dacapobench/
    
    2) build perf such as "make -C tools/perf O=/tmp/perf NO_LIBBFD=1" it
    should detect Java and create /tmp/perf/libperf-jvmti.so
    
    3) run perf with the jvmti agent:
    
      perf record -k 1 java -agentpath:/tmp/perf/libperf-jvmti.so -jar dacapo-9.12-MR1-bach.jar -n 10 fop
    
    4) run perf inject:
    
      perf inject -i perf.data -o perf-injected.data -j
    
    5) run perf report
    
      perf report -i perf-injected.data | grep org.apache.fop
    
    With this patch reverted I see lots of symbols like:
    
         0.00%  java             jitted-388040-4656.so  [.] org.apache.fop.fo.FObj.bind(org.apache.fop.fo.PropertyList)
    
    With the patch (2d86612aacb7805f ("perf symbol: Correct address for bss
    symbols")) I see lots of:
    
      dso__load_sym_internal: failed to find program header for symbol:
      Lorg/apache/fop/fo/FObj;bind(Lorg/apache/fop/fo/PropertyList;)V
      st_value: 0x40
    
    Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols")
    Reviewed-by: Leo Yan <leo.yan@linaro.org>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Tested-by: Leo Yan <leo.yan@linaro.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lore.kernel.org/lkml/20220731164923.691193-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tools: Fix dso_id inode generation comparison [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Jul 11 12:31:44 2022 +0300

    perf tools: Fix dso_id inode generation comparison
    
    [ Upstream commit 68566a7cf56bf3148797c218ed45a9de078ef47c ]
    
    Synthesized MMAP events have zero ino_generation, so do not compare
    them to DSOs with a real ino_generation otherwise we end up with a DSO
    without a build id.
    
    Fixes: 0e3149f86b99ddab ("perf dso: Move dso_id from 'struct map' to 'struct dso'")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: kvm@vger.kernel.org
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20220711093218.10967-2-adrian.hunter@intel.com
    [ Added clarification to the comment from Ian + more detailed explanation from Adrian ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: samsung: exynosautov9-ufs: correct TSRV register configurations [+ + +]
Author: Chanho Park <chanho61.park@samsung.com>
Date:   Fri Jun 3 14:05:36 2022 +0900

    phy: samsung: exynosautov9-ufs: correct TSRV register configurations
    
    [ Upstream commit f7fdc4db071f7ee7d408ea3f083222a060c76623 ]
    
    For exynos auto v9's UFS MPHY, We should use 0x50 offset of TSRV register
    configurations. So, it must be
    
    s/PHY_TRSV_REG_CFG/PHY_TRSV_REG_CFG_AUTOV9/g
    
    Fixes: d64519249e1d ("phy: samsung-ufs: support exynosauto ufs phy driver")
    Signed-off-by: Chanho Park <chanho61.park@samsung.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220603050536.61957-1-chanho61.park@samsung.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: stm32: fix error return in stm32_usbphyc_phy_init [+ + +]
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Wed Jul 13 15:39:53 2022 +0200

    phy: stm32: fix error return in stm32_usbphyc_phy_init
    
    [ Upstream commit 32b378a9179ae4db61cfc5d502717214e6cd1e1c ]
    
    Error code is overridden, in case the PLL doesn't lock. So, the USB
    initialization can continue. This leads to a platform freeze.
    This can be avoided by returning proper error code to avoid USB probe
    freezing the platform. It also displays proper errors in log.
    
    Fixes: 5b1af71280ab ("phy: stm32: rework PLL Lock detection")
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20220713133953.595134-1-fabrice.gasnier@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/chrome: cros_ec: Always expose last resume result [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Tue Jun 14 00:57:26 2022 -0700

    platform/chrome: cros_ec: Always expose last resume result
    
    [ Upstream commit 74bb746407bf0d7c7d126c7731dbcd66d467619b ]
    
    The last resume result exposing logic in cros_ec_sleep_event()
    incorrectly requires S0ix support, which doesn't work on ARM based
    systems where S0ix doesn't exist. That's because cros_ec_sleep_event()
    only reports the last resume result when the EC indicates the last sleep
    event was an S0ix resume. On ARM systems, the last sleep event is always
    S3 resume, but the EC can still detect sleep hang events in case some
    other part of the AP is blocking sleep.
    
    Always expose the last resume result if the EC supports it so that this
    works on all devices regardless of S0ix support. This fixes sleep hang
    detection on ARM based chromebooks like Trogdor.
    
    Cc: Rajat Jain <rajatja@chromium.org>
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Cc: Hsin-Yi Wang <hsinyi@chromium.org>
    Cc: Tzung-Bi Shih <tzungbi@kernel.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Evan Green <evgreen@chromium.org>
    Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/olpc: Fix uninitialized data in debugfs write [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 20 21:23:38 2022 +0300

    platform/olpc: Fix uninitialized data in debugfs write
    
    [ Upstream commit 40ec787e1adf302c11668d4cc69838f4d584187d ]
    
    The call to:
    
            size = simple_write_to_buffer(cmdbuf, sizeof(cmdbuf), ppos, buf, size);
    
    will succeed if at least one byte is written to the "cmdbuf" buffer.
    The "*ppos" value controls which byte is written.  Another problem is
    that this code does not check for errors so it's possible for the entire
    buffer to be uninitialized.
    
    Inintialize the struct to zero to prevent reading uninitialized stack
    data.
    
    Debugfs is normally only writable by root so the impact of this bug is
    very minimal.
    
    Fixes: 6cca83d498bd ("Platform: OLPC: move debugfs support from x86 EC driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YthIKn+TfZSZMEcM@kili
    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>

 
PM: domains: Ensure genpd_debugfs_dir exists before remove [+ + +]
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Wed Jul 6 01:16:49 2022 +0800

    PM: domains: Ensure genpd_debugfs_dir exists before remove
    
    [ Upstream commit 37101d3c719386040ded735a5ec06974f1d94d1f ]
    
    Both genpd_debug_add() and genpd_debug_remove() may be called
    indirectly by other drivers while genpd_debugfs_dir is not yet
    set. For example, drivers can call pm_genpd_init() in probe or
    pm_genpd_init() in probe fail/cleanup path:
    
    pm_genpd_init()
     --> genpd_debug_add()
    
    pm_genpd_remove()
     --> genpd_remove()
       --> genpd_debug_remove()
    
    At this time, genpd_debug_init() may not yet be called.
    
    genpd_debug_add() checks that if genpd_debugfs_dir is NULL, it
    will return directly. Make sure this is also checked
    in pm_genpd_remove(), otherwise components under debugfs root
    which has the same name as other components under pm_genpd may
    be accidentally removed, since NULL represents debugfs root.
    
    Fixes: 718072ceb211 ("PM: domains: create debugfs nodes when adding power domains")
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: hibernate: defer device probing when resuming from hibernation [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Jul 15 14:49:58 2022 +0900

    PM: hibernate: defer device probing when resuming from hibernation
    
    [ Upstream commit 8386c414e27caba8501119948e9551e52b527f59 ]
    
    syzbot is reporting hung task at misc_open() [1], for there is a race
    window of AB-BA deadlock which involves probe_count variable. Currently
    wait_for_device_probe() from snapshot_open() from misc_open() can sleep
    forever with misc_mtx held if probe_count cannot become 0.
    
    When a device is probed by hub_event() work function, probe_count is
    incremented before the probe function starts, and probe_count is
    decremented after the probe function completed.
    
    There are three cases that can prevent probe_count from dropping to 0.
    
      (a) A device being probed stopped responding (i.e. broken/malicious
          hardware).
    
      (b) A process emulating a USB device using /dev/raw-gadget interface
          stopped responding for some reason.
    
      (c) New device probe requests keeps coming in before existing device
          probe requests complete.
    
    The phenomenon syzbot is reporting is (b). A process which is holding
    system_transition_mutex and misc_mtx is waiting for probe_count to become
    0 inside wait_for_device_probe(), but the probe function which is called
     from hub_event() work function is waiting for the processes which are
    blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.
    
    This patch mitigates (b) by deferring wait_for_device_probe() from
    snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that
    the possibility of (b) remains as long as any thread which is emulating a
    USB device via /dev/raw-gadget interface can be blocked by uninterruptible
    blocking operations (e.g. mutex_lock()).
    
    Please also note that (a) and (c) are not addressed. Regarding (c), we
    should change the code to wait for only one device which contains the
    image for resuming from hibernation. I don't know how to address (a), for
    use of timeout for wait_for_device_probe() might result in loss of user
    data in the image. Maybe we should require the userland to wait for the
    image device before opening /dev/snapshot interface.
    
    Link: https://syzkaller.appspot.com/bug?extid=358c9ab4c93da7b7238c [1]
    Reported-by: syzbot <syzbot+358c9ab4c93da7b7238c@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: syzbot <syzbot+358c9ab4c93da7b7238c@syzkaller.appspotmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pNFS/flexfiles: Report RDMA connection errors to the server [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed May 18 16:09:06 2022 -0400

    pNFS/flexfiles: Report RDMA connection errors to the server
    
    commit 7836d75467e9d214bdf5c693b32721de729a6e38 upstream.
    
    The RPC/RDMA driver will return -EPROTO and -ENODEV as connection errors
    under certain circumstances. Make sure that we handle them and report
    them to the server. If not, we can end up cycling forever in a
    LAYOUTGET/LAYOUTRETURN loop.
    
    Fixes: a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family")
    Cc: stable@vger.kernel.org # 5.11.x
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
posix-cpu-timers: Cleanup CPU timers before freeing them during exec [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:07:51 2022 -0300

    posix-cpu-timers: Cleanup CPU timers before freeing them during exec
    
    commit e362359ace6f87c201531872486ff295df306d13 upstream.
    
    Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a
    task") started looking up tasks by PID when deleting a CPU timer.
    
    When a non-leader thread calls execve, it will switch PIDs with the leader
    process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find
    the task because the timer still points out to the old PID.
    
    That means that armed timers won't be disarmed, that is, they won't be
    removed from the timerqueue_list. exit_itimers will still release their
    memory, and when that list is later processed, it leads to a
    use-after-free.
    
    Clean up the timers from the de-threaded task before freeing them. This
    prevents a reported use-after-free.
    
    Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220809170751.164716-1-cascardo@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping. [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Jun 14 12:34:08 2022 +0200

    powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping.
    
    [ Upstream commit 980bbf7ca72012d317617fcdbfabe8708e4cef29 ]
    
    mark_initmem_nx() calls either mmu_mark_initmem_nx() or
    set_memory_attr() based on return from v_block_mapped()
    of _sinittext.
    
    But we can now handle text and data independently, so that
    text may be mapped by block even when data is mapped by pages.
    
    On the 8xx for instance, at startup 32Mbytes of memory are
    pinned in TLB. So the pinned entries need to go away for sinittext.
    
    In next patch a BAT will be set to also covers sinittext on book3s/32.
    So it will also be needed to call mmu_mark_initmem_nx() even when
    data above sinittext is not mapped with BATs.
    
    As this is highly dependent on the platform, call mmu_mark_initmem_nx()
    regardless of data block mapping. Then the platform will know what to
    do.
    
    Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified
    only when pagealloc debug and kfence are not active, otherwise inittext
    is mapped with standard pages. And don't do anything on kernel text
    which is already mapped with PAGE_KERNEL_TEXT.
    
    Fixes: da1adea07576 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/db3fc14f3bfa6215b0786ef58a6e2bc1e1f964d7.1655202804.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32 [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Jul 11 16:19:29 2022 +0200

    powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32
    
    [ Upstream commit 9be013b2a9ecb29b5168e4b9db0e48ed53acf37c ]
    
    Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
    enlarged the CPU selection logic to PPC32 by removing depend to
    PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU.
    Fortunately that got unnoticed because -mcpu=8540 will override the
    -mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's
    fragile and may no be right in the future.
    
    Add back the depend PPC64 on E5500_CPU and E6500_CPU.
    
    Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/8abab4888da69ff78b73a56f64d9678a7bf684e9.1657549153.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/64s: Disable stack variable initialisation for prom_init [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Jul 18 23:44:18 2022 +1000

    powerpc/64s: Disable stack variable initialisation for prom_init
    
    [ Upstream commit be640317a1d0b9cf42fedb2debc2887a7cfa38de ]
    
    With GCC 12 allmodconfig prom_init fails to build:
    
      Error: External symbol 'memset' referenced from prom_init.c
      make[2]: *** [arch/powerpc/kernel/Makefile:204: arch/powerpc/kernel/prom_init_check] Error 1
    
    The allmodconfig build enables KASAN, so all calls to memset in
    prom_init should be converted to __memset by the #ifdefs in
    asm/string.h, because prom_init must use the non-KASAN instrumented
    versions.
    
    The build failure happens because there's a call to memset that hasn't
    been caught by the pre-processor and converted to __memset. Typically
    that's because it's a memset generated by the compiler itself, and that
    is the case here.
    
    With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which
    causes the compiler to emit memset calls to initialise on-stack
    variables with a pattern.
    
    Because prom_init is non-user-facing boot-time only code, as a
    workaround just disable stack variable initialisation to unbreak the
    build.
    
    Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220718134418.354114-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 10:51:29 2022 +0400

    powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address
    
    [ Upstream commit df5d4b616ee76abc97e5bd348e22659c2b095b1c ]
    
    of_get_next_parent() returns a node pointer with refcount incremented,
    we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() in the error path to avoid refcount leak.
    
    Fixes: ce21b3c9648a ("[CELL] add support for MSI on Axon-based Cell systems")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220605065129.63906-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/fsl-pci: Fix Class Code of PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Wed Jul 6 12:10:43 2022 +0200

    powerpc/fsl-pci: Fix Class Code of PCIe Root Port
    
    commit 0c551abfa004ce154d487d91777bf221c808a64f upstream.
    
    By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class
    Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020
    board which has this pre-3.0 controller:
    
      $ lspci -bvnn
      00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21)
              !!! Invalid class 0b20 for header type 01
              Capabilities: [4c] Express Root Port (Slot-), MSI 00
    
    Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root
    Port to the Freescale specific PCIe register 0x474.
    
    With this change lspci -b output is:
    
      $ lspci -bvnn
      00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode])
              Capabilities: [4c] Express Root Port (Slot-), MSI 00
    
    Without any "Invalid class" error. So class code was properly reflected
    into standard (read-only) PCI register 0x08.
    
    Same fix is already implemented in U-Boot pcie_fsl.c driver in commit:
    http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b
    
    Fix activated by U-Boot stay active also after booting Linux kernel.
    But boards which use older U-Boot version without that fix are affected and
    still require this fix.
    
    So implement this class code fix also in kernel fsl_pci.c driver.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220706101043.4867-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case [+ + +]
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Thu Jul 14 18:11:19 2022 +1000

    powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case
    
    [ Upstream commit d80f6de9d601c30b53c17f00cb7cfe3169f2ddad ]
    
    The existing iommu_table_in_use() helper checks if the kernel is using
    any of TCEs. There are some reserved TCEs:
    1) the very first one if DMA window starts from 0 to avoid having a zero
    but still valid DMA handle;
    2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case
    the default window spans across that - this is the default for the first
    DMA window on PowerNV.
    
    When 1) is the case and 2) is not the helper does not skip 1) and returns
    wrong status.
    
    This only seems occurring when passing through a PCI device to a nested
    guest (not something we support really well) so it has not been seen
    before.
    
    This fixes the bug by adding a special case for no MMIO32 reservation.
    
    Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper")
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220714081119.3714605-1-aik@ozlabs.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pci: Fix PHB numbering when using opal-phbid [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Aug 2 20:38:32 2022 +1000

    powerpc/pci: Fix PHB numbering when using opal-phbid
    
    [ Upstream commit f4b39e88b42d13366b831270306326b5c20971ca ]
    
    The recent change to the PHB numbering logic has a logic error in the
    handling of "ibm,opal-phbid".
    
    When an "ibm,opal-phbid" property is present, &prop is written to and
    ret is set to zero.
    
    The following call to of_alias_get_id() is skipped because ret == 0.
    
    But then the if (ret >= 0) is true, and the body of that if statement
    sets prop = ret which throws away the value that was just read from
    "ibm,opal-phbid".
    
    Fix the logic by only doing the ret >= 0 check in the of_alias_get_id()
    case.
    
    Fixes: 0fe1e96fef0a ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias")
    Reviewed-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220802105723.1055178-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Wed Jul 6 12:21:48 2022 +0200

    powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias
    
    [ Upstream commit 0fe1e96fef0a5c53b4c0d1500d356f3906000f81 ]
    
    Other Linux architectures use DT property 'linux,pci-domain' for
    specifying fixed PCI domain of PCI controller specified in Device-Tree.
    
    And lot of Freescale powerpc boards have defined numbered pci alias in
    Device-Tree for every PCIe controller which number specify preferred PCI
    domain.
    
    So prefer usage of DT property 'linux,pci-domain' (via function
    of_get_pci_domain_nr()) and DT pci alias (via function
    of_alias_get_id()) on powerpc architecture for assigning PCI domain to
    PCI controller.
    
    Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220706102148.5060-2-pali@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable [+ + +]
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Sun May 22 19:52:56 2022 +0530

    powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable
    
    [ Upstream commit 890005a7d98f7452cfe86dcfb2aeeb7df01132ce ]
    
    commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
    pending PMI before resetting an overflown PMC") added a new
    function "pmi_irq_pending" in hw_irq.h. This function is to check
    if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is
    used in power_pmu_disable in a WARN_ON. The intention here is to
    provide a warning if there is PMI pending, but no counter is found
    overflown.
    
    During some of the perf runs, below warning is hit:
    
    WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0
     Modules linked in:
     -----
    
     NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0
     LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0
     Call Trace:
     [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)
     [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60
     [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100
     [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240
     [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140
     [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0
     [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300
     [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100
     [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40
     [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250
     [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0
     [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0
     [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80
     [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0
     [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140
     [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8
     [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0
     [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220
    
    This means that there is no PMC overflown among the active events
    in the PMU, but there is a PMU pending in Paca. The function
    "any_pmc_overflown" checks the PMCs on active events in
    cpuhw->n_events. Code snippet:
    
    <<>>
    if (any_pmc_overflown(cpuhw))
            clear_pmi_irq_pending();
     else
            WARN_ON(pmi_irq_pending());
    <<>>
    
    Here the PMC overflown is not from active event. Example: When we do
    perf record, default cycles and instructions will be running on PMC6
    and PMC5 respectively. It could happen that overflowed event is currently
    not active and pending PMI is for the inactive event. Debug logs from
    trace_printk:
    
    <<>>
    any_pmc_overflown: idx is 5: pmc value is 0xd9a
    power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011
    <<>>
    
    Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).
    When we handle PMI interrupt for such cases, if the PMC overflown is
    from inactive event, it will be ignored. Reference commit:
    commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")
    
    Patch addresses two changes:
    1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )
       We were printing warning if no PMC is found overflown among active PMU
       events, but PMI pending in PACA. But this could happen in cases where
       PMC overflown is not in active PMC. An inactive event could have caused
       the overflow. Hence the warning is not needed. To know pending PMI is
       from an inactive event, we need to loop through all PMC's which will
       cause more SPR reads via mfspr and increase in context switch. Also in
       existing function: perf_event_interrupt, already we ignore PMI's
       overflown when it is from an inactive PMC.
    
    2) Fix 2: optimization in clearing pending PMI.
       Currently we check for any active PMC overflown before clearing PMI
       pending in Paca. This is causing additional SPR read also. From point 1,
       we know that if PMI pending in Paca from inactive cases, that is going
       to be ignored during replay. Hence if there is pending PMI in Paca, just
       clear it irrespective of PMC overflown or not.
    
    In summary, remove the any_pmc_overflown check entirely in
    power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since
    we are in pmu_disable. There could be cases where PMI is pending because
    of inactive PMC ( which later when replayed also will get ignored ), so
    WARN_ON could give false warning. Hence removing it.
    
    Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC")
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220522142256.24699-1-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powernv/kvm: Use darn for H_RANDOM on Power9 [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jul 28 00:32:18 2022 +1000

    powerpc/powernv/kvm: Use darn for H_RANDOM on Power9
    
    [ Upstream commit 7ef3d06f1bc4a5e62273726f3dc2bd258ae1c71f ]
    
    The existing logic in KVM to support guests calling H_RANDOM only works
    on Power8, because it looks for an RNG in the device tree, but on Power9
    we just use darn.
    
    In addition the existing code needs to work in real mode, so we have the
    special cased powernv_get_random_real_mode() to deal with that.
    
    Instead just have KVM call ppc_md.get_random_seed(), and do the real
    mode check inside of there, that way we use whatever RNG is available,
    including darn on Power9.
    
    Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.")
    Cc: stable@vger.kernel.org # v4.1+
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Tested-by: Sachin Sant <sachinp@linux.ibm.com>
    [mpe: Rebase on previous commit, update change log appropriately]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220727143219.2684192-2-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powernv: Avoid crashing if rng is NULL [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Jul 28 00:32:17 2022 +1000

    powerpc/powernv: Avoid crashing if rng is NULL
    
    commit 90b5d4fe0b3ba7f589c6723c6bfb559d9e83956a upstream.
    
    On a bare-metal Power8 system that doesn't have an "ibm,power-rng", a
    malicious QEMU and guest that ignore the absence of the
    KVM_CAP_PPC_HWRNG flag, and calls H_RANDOM anyway, will dereference a
    NULL pointer.
    
    In practice all Power8 machines have an "ibm,power-rng", but let's not
    rely on that, add a NULL check and early return in
    powernv_get_random_real_mode().
    
    Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.")
    Cc: stable@vger.kernel.org # v4.1+
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220727143219.2684192-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/ptdump: Fix display of RW pages on FSL_BOOK3E [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Jun 28 16:43:35 2022 +0200

    powerpc/ptdump: Fix display of RW pages on FSL_BOOK3E
    
    commit dd8de84b57b02ba9c1fe530a6d916c0853f136bd upstream.
    
    On FSL_BOOK3E, _PAGE_RW is defined with two bits, one for user and one
    for supervisor. As soon as one of the two bits is set, the page has
    to be display as RW. But the way it is implemented today requires both
    bits to be set in order to display it as RW.
    
    Instead of display RW when _PAGE_RW bits are set and R otherwise,
    reverse the logic and display R when _PAGE_RW bits are all 0 and
    RW otherwise.
    
    This change has no impact on other platforms as _PAGE_RW is a single
    bit on all of them.
    
    Fixes: 8eb07b187000 ("powerpc/mm: Dump linux pagetables")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/0c33b96317811edf691e81698aaee8fa45ec3449.1656427391.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 16:15:42 2022 +0400

    powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader
    
    [ Upstream commit 6ac059dacffa8ab2f7798f20e4bd3333890c541c ]
    
    of_find_node_by_path() returns remote device nodepointer with
    refcount incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 0afacde3df4c ("[POWERPC] spufs: allow isolated mode apps by starting the SPE loader")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220603121543.22884-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/xive: Fix refcount leak in xive_get_max_prio [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 09:32:23 2022 +0400

    powerpc/xive: Fix refcount leak in xive_get_max_prio
    
    [ Upstream commit 255b650cbec6849443ce2e0cdd187fd5e61c218c ]
    
    of_find_node_by_path() returns a node pointer with
    refcount incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220605053225.56125-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: Fix eh field when calling lwarx on PPC32 [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Aug 2 11:02:36 2022 +0200

    powerpc: Fix eh field when calling lwarx on PPC32
    
    commit 18db466a9a306406dab3b134014d9f6ed642471c upstream.
    
    Commit 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of
    PPC_LWARX/LDARX macros") properly handled the eh field of lwarx
    in asm/bitops.h but failed to clear it for PPC32 in
    asm/simple_spinlock.h
    
    So, do as in arch_atomic_try_cmpxchg_lock(), set it to 1 if PPC64
    but set it to 0 if PPC32. For that use IS_ENABLED(CONFIG_PPC64) which
    returns 1 when CONFIG_PPC64 is set and 0 otherwise.
    
    Fixes: 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros")
    Cc: stable@vger.kernel.org # v5.15+
    Reported-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Tested-by: Pali Rohár <pali@kernel.org>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    [mpe: Use symbolic names, use 'n' constraint per Segher]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/a1176e19e627dd6a1b8d24c6c457a8ab874b7d12.1659430931.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
proc: fix a dentry lock race between release_task and lookup [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Wed Jul 13 21:00:29 2022 +0800

    proc: fix a dentry lock race between release_task and lookup
    
    [ Upstream commit d919a1e79bac890421537cf02ae773007bf55e6b ]
    
    Commit 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc")
    moved proc_flush_task() behind __exit_signal().  Then, process systemd can
    take long period high cpu usage during releasing task in following
    concurrent processes:
    
      systemd                                 ps
    kernel_waitid                 stat(/proc/tgid)
      do_wait                       filename_lookup
        wait_consider_task            lookup_fast
          release_task
            __exit_signal
              __unhash_process
                detach_pid
                  __change_pid // remove task->pid_links
                                         d_revalidate -> pid_revalidate  // 0
                                         d_invalidate(/proc/tgid)
                                           shrink_dcache_parent(/proc/tgid)
                                             d_walk(/proc/tgid)
                                               spin_lock_nested(/proc/tgid/fd)
                                               // iterating opened fd
            proc_flush_pid                                    |
               d_invalidate (/proc/tgid/fd)                   |
                  shrink_dcache_parent(/proc/tgid/fd)         |
                    shrink_dentry_list(subdirs)               ↓
                      shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock
    
    Function d_invalidate() will remove dentry from hash firstly, but why does
    proc_flush_pid() process dentry '/proc/tgid/fd' before dentry
    '/proc/tgid'?  That's because proc_pid_make_inode() adds proc inode in
    reverse order by invoking hlist_add_head_rcu().  But proc should not add
    any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by
    adding inode into 'pid->inodes' only if the inode is /proc/tgid or
    /proc/tgid/task/pid.
    
    Performance regression:
    Create 200 tasks, each task open one file for 50,000 times. Kill all
    tasks when opened files exceed 10,000,000 (cat /proc/sys/fs/file-nr).
    
    Before fix:
    $ time killall -wq aa
      real    4m40.946s   # During this period, we can see 'ps' and 'systemd'
                            taking high cpu usage.
    
    After fix:
    $ time killall -wq aa
      real    1m20.732s   # During this period, we can see 'systemd' taking
                            high cpu usage.
    
    Link: https://lkml.kernel.org/r/20220713130029.4133533-1-chengzhihao1@huawei.com
    Fixes: 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Suggested-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Kalesh Singh <kaleshsingh@google.com>
    Cc: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
profiling: fix shift too large makes kernel panic [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Tue May 31 09:28:54 2022 +0800

    profiling: fix shift too large makes kernel panic
    
    [ Upstream commit 0fe6ee8f123a4dfb529a5aff07536bb481f34043 ]
    
    2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs") limits shift
    value by [0, BITS_PER_LONG -1], which means [0, 63].
    
    However, syzbot found that the max shift value should be the bit number of
    (_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
    be zero and will cause kzalloc(0).  Then the kernel panics due to
    dereferencing the returned pointer 16.
    
    This can be easily reproduced by passing a large number like 60 to enable
    profiling and then run readprofile.
    
    LOGS:
     BUG: kernel NULL pointer dereference, address: 0000000000000010
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
     PREEMPT SMP
     CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ #162
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
     RIP: 0010:read_profile+0x104/0x220
     RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
     RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
     RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
     R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
     R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
     FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
     Call Trace:
      <TASK>
      proc_reg_read+0x56/0x70
      vfs_read+0x9a/0x1b0
      ksys_read+0xa1/0xe0
      ? fpregs_assert_state_consistent+0x1e/0x40
      do_syscall_64+0x3a/0x80
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
     RIP: 0033:0x4d4b4e
     RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
     RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
     RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
     RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
     R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
     R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
      </TASK>
     Modules linked in:
     CR2: 0000000000000010
    Killed
     ---[ end trace 0000000000000000 ]---
    
    Check prof_len in profile_init() to prevent it be zero.
    
    Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: lpc18xx-sct: Reduce number of devm memory allocations [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Nov 10 09:49:49 2021 +0100

    pwm: lpc18xx-sct: Reduce number of devm memory allocations
    
    [ Upstream commit 20d9de9c4d6642bb40c935233697723b56573cbc ]
    
    Each devm allocations has an overhead of 24 bytes to store the related
    struct devres_node additionally to the fragmentation of the allocator.
    So allocating 16 struct lpc18xx_pwm_data (which only hold a single int)
    adds quite some overhead. Instead put the per-channel data into the
    driver data struct and allocate it in one go.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: lpc18xx-sct: Simplify driver by not using pwm_[gs]et_chip_data() [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Nov 10 09:49:50 2021 +0100

    pwm: lpc18xx-sct: Simplify driver by not using pwm_[gs]et_chip_data()
    
    [ Upstream commit 9136a39e6cf69e49803ac6123a4ac4431bc915a2 ]
    
    The per-channel data is available directly in the driver data struct. So
    use it without making use of pwm_[gs]et_chip_data().
    
    The relevant change introduced by this patch to lpc18xx_pwm_disable() at
    the assembler level (for an arm lpc18xx_defconfig build) is:
    
            push    {r3, r4, r5, lr}
            mov     r4, r0
            mov     r0, r1
            mov     r5, r1
            bl      0 <pwm_get_chip_data>
            ldr     r3, [r0, #0]
    
    changes to
    
            ldr     r3, [r1, #8]
            push    {r4, lr}
            add.w   r3, r0, r3, lsl #2
            ldr     r3, [r3, #92]   ; 0x5c
    
    So this reduces stack usage, has an improved runtime behavior because of
    better pipeline usage, doesn't branch to an external function and the
    generated code is a bit smaller occupying less memory.
    
    The codesize of lpc18xx_pwm_probe() is reduced by 32 bytes.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: lpc18xx: Fix period handling [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Jul 12 18:15:19 2022 +0200

    pwm: lpc18xx: Fix period handling
    
    [ Upstream commit 8933d30c5f468d6cc1e4bf9bb535149da35f202e ]
    
    The calculation:
    
            val = (u64)NSEC_PER_SEC * LPC18XX_PWM_TIMER_MAX;
            do_div(val, lpc18xx_pwm->clk_rate);
            lpc18xx_pwm->max_period_ns = val;
    
    is bogus because with NSEC_PER_SEC = 1000000000,
    LPC18XX_PWM_TIMER_MAX = 0xffffffff and clk_rate < NSEC_PER_SEC this
    overflows the (on lpc18xx (i.e. ARM32) 32 bit wide) unsigned int
    .max_period_ns. This results (dependant of the actual clk rate) in an
    arbitrary limitation of the maximal period.  E.g. for clkrate =
    333333333 (Hz) we get max_period_ns = 9 instead of 12884901897.
    
    So make .max_period_ns an u64 and pass period and duty as u64 to not
    discard relevant digits. And also make use of mul_u64_u64_div_u64()
    which prevents all overflows assuming clk_rate < NSEC_PER_SEC.
    
    Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: sifive: Ensure the clk is enabled exactly once per running PWM [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 21 12:31:28 2022 +0200

    pwm: sifive: Ensure the clk is enabled exactly once per running PWM
    
    [ Upstream commit ace41d7564e655c39f709a78c035188a460c7cbd ]
    
    .apply() assumes the clk to be for a given PWM iff the PWM is enabled.
    So make sure this is the case when .probe() completes. And in .remove()
    disable the according number of times.
    
    This fixes a clk enable/disable imbalance, if some PWMs are already running
    at probe time.
    
    Fixes: 9e37a53eb051 (pwm: sifive: Add a driver for SiFive SoC PWM)
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: sifive: Shut down hardware only after pwmchip_remove() completed [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 21 12:31:29 2022 +0200

    pwm: sifive: Shut down hardware only after pwmchip_remove() completed
    
    [ Upstream commit 2375e964d541bb09158cd2dff67b5d74e8de61cd ]
    
    The PWMs are expected to be functional until pwmchip_remove() is called.
    So disable the clks only afterwards.
    
    Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: sifive: Simplify offset calculation for PWMCMP registers [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 21 12:31:23 2022 +0200

    pwm: sifive: Simplify offset calculation for PWMCMP registers
    
    [ Upstream commit 20550a61880fc55e68a0d290ad195b74729c0e7b ]
    
    Instead of explicitly using PWM_SIFIVE_PWMCMP0 + pwm->hwpwm *
    PWM_SIFIVE_SIZE_PWMCMP for each access to one of the PWMCMP registers,
    introduce a macro that takes the hwpwm id as parameter.
    
    For the register definition using a plain 4 instead of the cpp constant
    PWM_SIFIVE_SIZE_PWMCMP is easier to read, so define the offset macro
    without the constant. The latter can then be dropped as there are no
    users left.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcutorture: Don't cpuhp_remove_state() if cpuhp_setup_state() failed [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Fri Aug 6 08:57:26 2021 -0700

    rcutorture: Don't cpuhp_remove_state() if cpuhp_setup_state() failed
    
    [ Upstream commit fd13fe16db0d82612b260640f4e26f6d9d1e11fd ]
    
    Currently, in CONFIG_RCU_BOOST kernels, if the rcu_torture_init()
    function's call to cpuhp_setup_state() fails, rcu_torture_cleanup()
    gamely passes nonsense to cpuhp_remove_state().  This results in
    strange and misleading splats.  This commit therefore ensures that if
    the rcu_torture_init() function's call to cpuhp_setup_state() fails,
    rcu_torture_cleanup() avoids invoking cpuhp_remove_state().
    
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rcutorture: Fix ksoftirqd boosting timing and iteration [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Fri Jun 10 15:03:57 2022 +0200

    rcutorture: Fix ksoftirqd boosting timing and iteration
    
    [ Upstream commit 3002153a91a9732a6d1d0bb95138593c7da15743 ]
    
    The RCU priority boosting can fail in two situations:
    
    1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs
    is higher than those brought online at boot, then torture_onoff() may
    later bring up CPUs that weren't online on boot. Now since rcutorture
    initialization only boosts the ksoftirqds of the CPUs that have been
    set online on boot, the CPUs later set online by torture_onoff won't
    benefit from the boost, making RCU priority boosting fail.
    
    2) The ksoftirqd kthreads are boosted after the creation of
    rcu_torture_boost() kthreads, which opens a window large enough for these
    rcu_torture_boost() kthreads to wait (despite running at FIFO priority)
    for ksoftirqds that are still running at SCHED_NORMAL priority.
    
    The issues can trigger for example with:
    
            ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y"
    
            [   34.968561] rcu-torture: !!!
            [   34.968627] ------------[ cut here ]------------
            [   35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610
            [   35.052043] Modules linked in:
            [   35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1
            [   35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
            [   35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610
            [   35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82
            [   37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202
            [   37.277320] rcu: De-offloading 8
            [   37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
            [   37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff
            [   37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff
            [   37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20
            [   37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0
            [   37.290427] FS:  0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000
            [   37.290448] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
            [   37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0
            [   37.290470] Call Trace:
            [   37.295049]  <TASK>
            [   37.295065]  ? preempt_count_add+0x63/0x90
            [   37.295095]  ? _raw_spin_lock_irqsave+0x12/0x40
            [   37.295125]  ? rcu_torture_stats_print+0x610/0x610
            [   37.295143]  rcu_torture_stats+0x29/0x70
            [   37.295160]  kthread+0xe3/0x110
            [   37.295176]  ? kthread_complete_and_exit+0x20/0x20
            [   37.295193]  ret_from_fork+0x22/0x30
            [   37.295218]  </TASK>
    
    Fix this with boosting the ksoftirqds kthreads from the boosting
    hotplug callback itself and before the boosting kthreads are created.
    
    Fixes: ea6d962e80b6 ("rcutorture: Judge RCU priority boosting on grace periods, not callbacks")
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rcutorture: Warn on individual rcu_torture_init() error conditions [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu Aug 5 13:28:24 2021 -0700

    rcutorture: Warn on individual rcu_torture_init() error conditions
    
    [ Upstream commit efeff6b39b9de4480572c7b0c5eb77204795cb57 ]
    
    When running rcutorture as a module, any rcu_torture_init() issues will be
    reflected in the error code from modprobe or insmod, as the case may be.
    However, these error codes are not available when running rcutorture
    built-in, for example, when using the kvm.sh script.  This commit
    therefore adds WARN_ON_ONCE() to allow distinguishing rcu_torture_init()
    errors when running rcutorture built-in.
    
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hfi1: fix potential memory leak in setup_base_ctxt() [+ + +]
Author: Jianglei Nie <niejianglei2021@163.com>
Date:   Mon Jul 11 15:07:18 2022 +0800

    RDMA/hfi1: fix potential memory leak in setup_base_ctxt()
    
    [ Upstream commit aa2a1df3a2c85f855af7d54466ac10bd48645d63 ]
    
    setup_base_ctxt() allocates a memory chunk for uctxt->groups with
    hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups
    is not released, which will lead to a memory leak.
    
    We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups()
    when init_user_ctxt() fails.
    
    Fixes: e87473bc1b6c ("IB/hfi1: Only set fd pointer when base context is completely initialized")
    Link: https://lore.kernel.org/r/20220711070718.2318320-1-niejianglei2021@163.com
    Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
    Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hns: Fix incorrect clearing of interrupt status register [+ + +]
Author: Haoyue Xu <xuhaoyue1@hisilicon.com>
Date:   Thu Jul 14 21:43:51 2022 +0800

    RDMA/hns: Fix incorrect clearing of interrupt status register
    
    [ Upstream commit ecb4db5c3590aa956b4b2c352081a5b632d1f9f9 ]
    
    The driver will clear all the interrupts in the same area
    when the driver handles the interrupt of type AEQ overflow.
    It should only set the interrupt status bit of type AEQ overflow.
    
    Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08")
    Link: https://lore.kernel.org/r/20220714134353.16700-4-liangwenpeng@huawei.com
    Signed-off-by: Haoyue Xu <xuhaoyue1@hisilicon.com>
    Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/irdma: Fix a window for use-after-free [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Tue Jul 5 18:08:13 2022 -0500

    RDMA/irdma: Fix a window for use-after-free
    
    [ Upstream commit 8ecef7890b3aea78c8bbb501a4b5b8134367b821 ]
    
    During a destroy CQ an interrupt may cause processing of a CQE after CQ
    resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call
    to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is
    called under the cq_lock.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Link: https://lore.kernel.org/r/20220705230815.265-6-shiraz.saleem@intel.com
    Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Fix setting of QP context err_rq_idx_valid field [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Tue Jul 5 18:08:15 2022 -0500

    RDMA/irdma: Fix setting of QP context err_rq_idx_valid field
    
    [ Upstream commit 3a844596ed71b7c12ac602f6f6b7b0f17e4d6a90 ]
    
    Setting err_rq_idx_valid field in QP context when the AE source of the
    AEQE is not associated with an RQ causes the firmware flush to fail.
    
    Set err_rq_idx_valid field in QP context only if it is associated with an
    RQ. Additionally, cleanup the redundant setting of this field in
    irdma_process_aeq.
    
    Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
    Link: https://lore.kernel.org/r/20220705230815.265-8-shiraz.saleem@intel.com
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Fix VLAN connection with wildcard address [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Tue Jul 5 18:08:14 2022 -0500

    RDMA/irdma: Fix VLAN connection with wildcard address
    
    [ Upstream commit 82ab2b52654c43ba24a3f6603fec40874cc5a7e5 ]
    
    When an application listens on a wildcard address, and there are VLAN and
    non-VLAN IP addresses, iWARP connection establishemnt can fail if the listen
    node VLAN ID does not match.
    
    Fix this by checking the vlan_id only if not a wildcard listen node.
    
    Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager")
    Link: https://lore.kernel.org/r/20220705230815.265-7-shiraz.saleem@intel.com
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/mlx5: Add missing check for return value in get namespace flow [+ + +]
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Sun Jul 31 11:29:08 2022 +0300

    RDMA/mlx5: Add missing check for return value in get namespace flow
    
    [ Upstream commit c9776457bd5eaad4ce4ecb17af8d8f3cc6957c0b ]
    
    Add missing check for return value when calling to
    mlx5_ib_ft_type_to_namespace, even though it can't really fail in this
    specific call.
    
    Fixes: 52438be44112 ("RDMA/mlx5: Allow inserting a steering rule to the FDB")
    Link: https://lore.kernel.org/r/7b9ceda217d9368a51dc47a46b769bad4af9ac92.1659256069.git.leonro@nvidia.com
    Reviewed-by: Itay Aveksis <itayav@nvidia.com>
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() [+ + +]
Author: Jianglei Nie <niejianglei2021@163.com>
Date:   Thu Jul 14 14:15:05 2022 +0800

    RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()
    
    [ Upstream commit b3236a64ddd125a455ef5b5316c1b9051b732974 ]
    
    __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with
    init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"
    is released while "mr->info.pbl_table" is not released, which will lead
    to a memory leak.
    
    We should release the "mr->info.pbl_table" with qedr_free_pbl() when error
    occurs to fix the memory leak.
    
    Fixes: e0290cce6ac0 ("qedr: Add support for memory registeration verbs")
    Link: https://lore.kernel.org/r/20220714061505.2342759-1-niejianglei2021@163.com
    Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
    Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rtrs-clt: Rename rtrs_clt_sess to rtrs_clt_path [+ + +]
Author: Vaishali Thakkar <vaishali.thakkar@ionos.com>
Date:   Wed Jan 5 19:07:06 2022 +0100

    RDMA/rtrs-clt: Rename rtrs_clt_sess to rtrs_clt_path
    
    [ Upstream commit caa84d95c78f35168847e2ab861a3a7f87033d36 ]
    
    rtrs_clt_sess is used for paths and not sessions on the client side. This
    creates confusion so let's rename it to rtrs_clt_path. Also, rename
    related variables and functions.
    
    Coccinelle is used to do the transformations for most of the occurrences
    and remaining ones were handled manually.
    
    Link: https://lore.kernel.org/r/20220105180708.7774-4-jinpu.wang@ionos.com
    Signed-off-by: Vaishali Thakkar <vaishali.thakkar@ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs-clt: Replace list_next_or_null_rr_rcu with an inline function [+ + +]
Author: Md Haris Iqbal <haris.iqbal@ionos.com>
Date:   Tue Jul 12 12:31:12 2022 +0200

    RDMA/rtrs-clt: Replace list_next_or_null_rr_rcu with an inline function
    
    [ Upstream commit c14adff285ad1bb8eefc5d8fc202ceb1f7e3a2f1 ]
    
    removes list_next_or_null_rr_rcu macro to fix below warnings.
    That macro is used only twice.
    CHECK:MACRO_ARG_REUSE: Macro argument reuse 'head' - possible side-effects?
    CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ptr' - possible side-effects?
    CHECK:MACRO_ARG_REUSE: Macro argument reuse 'memb' - possible side-effects?
    
    Replaces that macro with an inline function.
    
    Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
    Cc: jinpu.wang@ionos.com
    Link: https://lore.kernel.org/r/20220712103113.617754-5-haris.iqbal@ionos.com
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rtrs-srv: Fix modinfo output for stringify [+ + +]
Author: Jack Wang <jinpu.wang@ionos.com>
Date:   Tue Jul 12 12:31:09 2022 +0200

    RDMA/rtrs-srv: Fix modinfo output for stringify
    
    [ Upstream commit ed6e53820ee4f68ed927de17e5675ff2a07a47e2 ]
    
    stringify works with define, not enum.
    
    Fixes: 91fddedd439c ("RDMA/rtrs: private headers with rtrs protocol structs and helpers")
    Cc: jinpu.wang@ionos.com
    Link: https://lore.kernel.org/r/20220712103113.617754-2-haris.iqbal@ionos.com
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Reviewed-by: Aleksei Marov <aleksei.marov@ionos.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs-srv: Rename rtrs_srv_sess to rtrs_srv_path [+ + +]
Author: Vaishali Thakkar <vaishali.thakkar@ionos.com>
Date:   Wed Jan 5 19:07:05 2022 +0100

    RDMA/rtrs-srv: Rename rtrs_srv_sess to rtrs_srv_path
    
    [ Upstream commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 ]
    
    rtrs_srv_sess is used for paths and not sessions on the server side. This
    creates confusion so let's rename it to rtrs_srv_path. Also, rename
    related variables and functions.
    
    Coccinelle is used to do the transformations for most of the occurrences
    and remaining ones were handled manually.
    
    Link: https://lore.kernel.org/r/20220105180708.7774-3-jinpu.wang@ionos.com
    Signed-off-by: Vaishali Thakkar <vaishali.thakkar@ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rtrs: Do not allow sessname to contain special symbols / and . [+ + +]
Author: Md Haris Iqbal <haris.iqbal@ionos.com>
Date:   Wed Sep 22 14:53:32 2021 +0200

    RDMA/rtrs: Do not allow sessname to contain special symbols / and .
    
    [ Upstream commit dea7bb3ad3e08f96815330f88a62c24d7a9dacae ]
    
    Allowing these characters in sessname can lead to unexpected results,
    particularly because / is used as a separator between files in a path, and
    . points to the current directory.
    
    Link: https://lore.kernel.org/r/20210922125333.351454-7-haris.iqbal@ionos.com
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Reviewed-by: Gioh Kim <gi-oh.kim@ionos.com>
    Reviewed-by: Aleksei Marov <aleksei.marov@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs: Fix warning when use poll mode on client side. [+ + +]
Author: Jack Wang <jinpu.wang@ionos.com>
Date:   Wed Sep 22 14:53:29 2021 +0200

    RDMA/rtrs: Fix warning when use poll mode on client side.
    
    [ Upstream commit 4b6afe9bc955bee44c0527005c3fb0edac91ac30 ]
    
    When testing with poll mode, it will fail and lead to warning below on
    client side:
    
    $ echo "sessname=bla path=gid:fe80::2:c903:4e:d0b3@gid:fe80::2:c903:8:ca17 device_path=/dev/nullb2 nr_poll_queues=-1" | \
      sudo tee /sys/devices/virtual/rnbd-client/ctl/map_device
    
    rnbd_client L597: Mapping device /dev/nullb2 on session bla, (access_mode: rw, nr_poll_queues: 8)
    WARNING: CPU: 3 PID: 9886 at drivers/infiniband/core/cq.c:447 ib_cq_pool_get+0x26f/0x2a0 [ib_core]
    
    The problem is in case of poll queue, we need to still call
    ib_alloc_cq/ib_free_cq, we can't use cq_poll api for poll queue.
    
    As both client and server use shared function from rtrs, set irq_con_num
    to con_num on server side, which is number of total connection of the
    session, this way we can differ if the rtrs_con requires pollqueue.
    
    Following up patches will replace the duplicate code with helpers.
    
    Link: https://lore.kernel.org/r/20210922125333.351454-4-haris.iqbal@ionos.com
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Reviewed-by: Gioh Kim <gi-oh.kim@ionos.com>
    Signed-off-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs: Introduce destroy_cq helper [+ + +]
Author: Md Haris Iqbal <haris.iqbal@ionos.com>
Date:   Wed Sep 22 14:53:31 2021 +0200

    RDMA/rtrs: Introduce destroy_cq helper
    
    [ Upstream commit 6f5649afd3984e35c4b862a05c4511c6d18b27af ]
    
    The same code snip used twice, to avoid duplicate, replace it with a
    destroy_cq helper.
    
    Link: https://lore.kernel.org/r/20210922125333.351454-6-haris.iqbal@ionos.com
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs: Rename rtrs_sess to rtrs_path [+ + +]
Author: Vaishali Thakkar <vaishali.thakkar@ionos.com>
Date:   Wed Jan 5 19:07:04 2022 +0100

    RDMA/rtrs: Rename rtrs_sess to rtrs_path
    
    [ Upstream commit d9372794717f44b6e746d8fbab66763b6d753e71 ]
    
    rtrs_sess is in fact a path. This makes it confusing and difficult to get
    into the code. So let's rename the structure and related use cases of it.
    
    Coccinelle was used to do the transformation for most of the occurrences
    and remaining ones were handled manually.
    
    Link: https://lore.kernel.org/r/20220105180708.7774-2-jinpu.wang@ionos.com
    Signed-off-by: Vaishali Thakkar <vaishali.thakkar@ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rtrs: Replace duplicate check with is_pollqueue helper [+ + +]
Author: Jack Wang <jinpu.wang@ionos.com>
Date:   Wed Sep 22 14:53:30 2021 +0200

    RDMA/rtrs: Replace duplicate check with is_pollqueue helper
    
    [ Upstream commit 36332ded46b6292296bc7170fada6e238a0802cc ]
    
    if (con->cid >= con->sess->irq_con_num) check can be replaced with a
    is_pollqueue helper.
    
    Link: https://lore.kernel.org/r/20210922125333.351454-5-haris.iqbal@ionos.com
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rxe: Add memory barriers to kernel queues [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Tue Sep 14 11:42:03 2021 -0500

    RDMA/rxe: Add memory barriers to kernel queues
    
    [ Upstream commit ae6e843fe08d0ea8e158815809dcc20e3a1afc22 ]
    
    Earlier patches added memory barriers to protect user space to kernel
    space communications. The user space queues were previously shown to have
    occasional memory synchonization errors which were removed by adding
    smp_load_acquire, smp_store_release barriers.  This patch extends that to
    the case where queues are used between kernel space threads.
    
    This patch also extends the queue types to include kernel ULP queues which
    access the other end of the queues in kernel verbs calls like poll_cq and
    post_send/recv.
    
    Link: https://lore.kernel.org/r/20210914164206.19768-2-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix deadlock in rxe_do_local_ops() [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Mon May 23 17:32:52 2022 -0500

    RDMA/rxe: Fix deadlock in rxe_do_local_ops()
    
    [ Upstream commit 7cb33d1bc1ac8e51fd88928f96674d392f8e07c4 ]
    
    When a local operation (invalidate mr, reg mr, bind mw) is finished there
    will be no ack packet coming from a responder to cause the wqe to be
    completed. This may happen anyway if a subsequent wqe performs
    IO. Currently if the wqe is signalled the completer tasklet is scheduled
    immediately but not otherwise.
    
    This leads to a deadlock if the next wqe has the fence bit set in send
    flags and the operation is not signalled. This patch removes the condition
    that the wqe must be signalled in order to schedule the completer tasklet
    which is the simplest fix for this deadlock and is fairly low cost. This
    is the analog for local operations of always setting the ackreq bit in all
    last or only request packets even if the operation is not signalled.
    
    Link: https://lore.kernel.org/r/20220523223251.15350-1-rpearsonhpe@gmail.com
    Reported-by: Jenny Hack <jhack@hpe.com>
    Fixes: c1a411268a4b ("RDMA/rxe: Move local ops to subroutine")
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix error unwind in rxe_create_qp() [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Sun Jul 31 02:36:21 2022 -0400

    RDMA/rxe: Fix error unwind in rxe_create_qp()
    
    [ Upstream commit fd5382c5805c4bcb50fd25b7246247d3f7114733 ]
    
    In the function rxe_create_qp(), rxe_qp_from_init() is called to
    initialize qp, internally things like the spin locks are not setup until
    rxe_qp_init_req().
    
    If an error occures before this point then the unwind will call
    rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()
    which will oops when trying to access the uninitialized spinlock.
    
    Move the spinlock initializations earlier before any failures.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20220731063621.298405-1-yanjun.zhu@linux.dev
    Reported-by: syzbot+833061116fa28df97f3b@syzkaller.appspotmail.com
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix mw bind to allow any consumer key portion [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Thu Jul 14 15:46:20 2022 -0500

    RDMA/rxe: Fix mw bind to allow any consumer key portion
    
    [ Upstream commit 1603f89935ec86d40a7667e1250392626976ccc2 ]
    
    The current implementation of rxe_check_bind_mw() in rxe_mw.c is incorrect
    since it requires the new key portion provided by the mw consumer to be
    different than the previous key portion. This is not required by the
    IBA. Remove the test.
    
    Link: https://lore.kernel.org/linux-rdma/fb4614e7-4cac-0dc7-3ef7-766dfd10e8f2@gmail.com/
    Fixes: 32a577b4c3a9 ("Add support for bind MW work requests")
    Link: https://lore.kernel.org/r/20220714204619.13396-1-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: For invalidate compare according to set keys in mr [+ + +]
Author: Md Haris Iqbal <haris.phnx@gmail.com>
Date:   Thu Jul 7 09:30:06 2022 +0200

    RDMA/rxe: For invalidate compare according to set keys in mr
    
    [ Upstream commit 174e7b137042f19b5ce88beb4fc0ff4ec6b0c72a ]
    
    The 'rkey' input can be an lkey or rkey, and in rxe the lkey or rkey have
    the same value, including the variant bits.
    
    So, if mr->rkey is set, compare the invalidate key with it, otherwise
    compare with the mr->lkey.
    
    Since we already did a lookup on the non-varient bits to get this far, the
    check's only purpose is to confirm that the wqe has the correct variant
    bits.
    
    Fixes: 001345339f4c ("RDMA/rxe: Separate HW and SW l/rkeys")
    Link: https://lore.kernel.org/r/20220707073006.328737-1-haris.phnx@gmail.com
    Signed-off-by: Md Haris Iqbal <haris.phnx@gmail.com>
    Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Remove the is_user members of struct rxe_sq/rxe_rq/rxe_srq [+ + +]
Author: Xiao Yang <yangx.jy@fujitsu.com>
Date:   Thu Sep 30 17:48:10 2021 +0800

    RDMA/rxe: Remove the is_user members of struct rxe_sq/rxe_rq/rxe_srq
    
    [ Upstream commit 1cf2ce8272802e677398fab47a73713bc6e1fd5c ]
    
    The is_user members of struct rxe_sq/rxe_rq/rxe_srq are unsed since
    commit ae6e843fe08d ("RDMA/rxe: Add memory barriers to kernel queues").
    In this case, it is fine to remove them directly.
    
    Link: https://lore.kernel.org/r/20210930094813.226888-2-yangx.jy@fujitsu.com
    Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event [+ + +]
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Thu Jul 14 09:30:47 2022 +0800

    RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event
    
    [ Upstream commit 3056fc6c32e613b760422b94c7617ac9a24a4721 ]
    
    If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't
    been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY
    in this case. This may trigger a call trace in iw_cm. A simple way to
    trigger this:
     server: ib_send_lat
     client: ib_send_lat -R <server_ip>
    
    The call trace looks like this:
    
     kernel BUG at drivers/infiniband/core/iwcm.c:894!
     invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
     <...>
     Workqueue: iw_cm_wq cm_work_handler [iw_cm]
     Call Trace:
      <TASK>
      cm_work_handler+0x1dd/0x370 [iw_cm]
      process_one_work+0x1e2/0x3b0
      worker_thread+0x49/0x2e0
      ? rescuer_thread+0x370/0x370
      kthread+0xe5/0x110
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x1f/0x30
      </TASK>
    
    Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
    Link: https://lore.kernel.org/r/dae34b5fd5c2ea2bd9744812c1d2653a34a94c67.1657706960.git.chengyou@linux.alibaba.com
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/srpt: Duplicate port name members [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Jul 27 12:34:13 2022 -0700

    RDMA/srpt: Duplicate port name members
    
    [ Upstream commit b03b1ae2a3125d4475452e4f19f5d3a6e910ff6e ]
    
    Prepare for decoupling the lifetimes of struct srpt_port and struct
    srpt_port_id by duplicating the port name into struct srpt_port.
    
    Link: https://lore.kernel.org/r/20220727193415.1583860-2-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/srpt: Fix a use-after-free [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Jul 27 12:34:15 2022 -0700

    RDMA/srpt: Fix a use-after-free
    
    [ Upstream commit b5605148e6ce36bb21020d49010b617693933128 ]
    
    Change the LIO port members inside struct srpt_port from regular members
    into pointers. Allocate the LIO port data structures from inside
    srpt_make_tport() and free these from inside srpt_make_tport(). Keep
    struct srpt_device as long as either an RDMA port or a LIO target port is
    associated with it. This patch decouples the lifetime of struct srpt_port
    (controlled by the RDMA core) and struct srpt_port_id (controlled by LIO).
    This patch fixes the following KASAN complaint:
    
      BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt]
      Read of size 8 at addr ffff888141cc34b8 by task check/5093
    
      Call Trace:
       <TASK>
       show_stack+0x4e/0x53
       dump_stack_lvl+0x51/0x66
       print_address_description.constprop.0.cold+0xea/0x41e
       print_report.cold+0x90/0x205
       kasan_report+0xb9/0xf0
       __asan_load8+0x69/0x90
       srpt_enable_tpg+0x31/0x70 [ib_srpt]
       target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod]
       configfs_write_iter+0x18b/0x210
       new_sync_write+0x1f2/0x2f0
       vfs_write+0x3e3/0x540
       ksys_write+0xbb/0x140
       __x64_sys_write+0x42/0x50
       do_syscall_64+0x34/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
       </TASK>
    
    Link: https://lore.kernel.org/r/20220727193415.1583860-4-bvanassche@acm.org
    Reported-by: Li Zhijian <lizhijian@fujitsu.com>
    Tested-by: Li Zhijian <lizhijian@fujitsu.com>
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/srpt: Introduce a reference count in struct srpt_device [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Jul 27 12:34:14 2022 -0700

    RDMA/srpt: Introduce a reference count in struct srpt_device
    
    [ Upstream commit aa7dfbb41b5a60ab90e244d6f586b8cb5c791c3e ]
    
    This will be used to keep struct srpt_device around as long as either the
    RDMA port exists or a LIO target port is associated with the struct
    srpt_device.
    
    Link: https://lore.kernel.org/r/20220727193415.1583860-3-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: of: Fix refcount leak bug in of_get_regulation_constraints() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Fri Jul 15 19:10:27 2022 +0800

    regulator: of: Fix refcount leak bug in of_get_regulation_constraints()
    
    [ Upstream commit 66efb665cd5ad69b27dca8571bf89fc6b9c628a4 ]
    
    We should call the of_node_put() for the reference returned by
    of_get_child_by_name() which has increased the refcount.
    
    Fixes: 40e20d68bb3f ("regulator: of: Add support for parsing regulator_state for suspend state")
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220715111027.391032-1-windhl@126.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: qcom_smd: Fix pm8916_pldo range [+ + +]
Author: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Date:   Thu Jun 23 11:46:12 2022 +0200

    regulator: qcom_smd: Fix pm8916_pldo range
    
    [ Upstream commit e8977917e116d1571dacb8e9864474551c1c12bd ]
    
    The PM8916 device specification [1] documents a programmable range of
    1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This
    range is also used when controlling the regulator directly using the
    qcom_spmi-regulator driver ("ult_pldo" there).
    
    However, for some reason the qcom_smd-regulator driver allows a much
    larger range for the same hardware component. This could be simply a
    typo, since the start of the range is essentially just missing a '1'.
    
    In practice this does not cause any major problems, since the driver
    just sends the actual voltage to the RPM firmware instead of making use
    of the incorrect voltage selector. Still, having the wrong range there
    is confusing and prevents the regulator core from validating requests
    correctly.
    
    [1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf
    
    Fixes: 57d6567680ed ("regulator: qcom-smd: Add PM8916 support")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
    Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 12 08:55:58 2022 +0400

    remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init
    
    [ Upstream commit 61afafe8b938bc74841cf4b1a73dd08b9d287c5a ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not needed anymore.
    This function has two paths missing of_node_put().
    
    Fixes: 6e962bfe56b9 ("remoteproc: imx_rproc: add missing of_node_put")
    Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220512045558.7142-1-linmq006@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 12:33:34 2022 +0400

    remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init
    
    [ Upstream commit fa220c05d282e7479abe08b54e3bdffd06c25e97 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    the reference count of the previous node.
    When breaking early from a for_each_available_child_of_node() loop,
    we need to explicitly call of_node_put() on the child node.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Acked-by: Suman Anna <s-anna@ti.com>
    Link: https://lore.kernel.org/r/20220605083334.23942-1-linmq006@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

remoteproc: qcom: pas: Check if coredump is enabled [+ + +]
Author: Siddharth Gupta <sidgup@codeaurora.org>
Date:   Tue Jul 5 17:38:17 2022 +0530

    remoteproc: qcom: pas: Check if coredump is enabled
    
    [ Upstream commit 7b6ece968fca4ec9e42d34caff7e06dc84c45717 ]
    
    Client drivers need to check if coredump is enabled for the rproc before
    continuing with coredump generation. This change adds a check in the PAS
    driver.
    
    Fixes: 8ed8485c4f05 ("remoteproc: qcom: Add capability to collect minidumps")
    Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
    Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/1657022900-2049-5-git-send-email-quic_sibis@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

remoteproc: qcom: wcnss: Fix handling of IRQs [+ + +]
Author: Sireesh Kodali <sireeshkodali1@gmail.com>
Date:   Thu May 26 19:47:39 2022 +0530

    remoteproc: qcom: wcnss: Fix handling of IRQs
    
    [ Upstream commit bed0adac1ded4cb486ba19a3a7e730fbd9a1c9c6 ]
    
    The wcnss_get_irq function is expected to return a value > 0 in the
    event that an IRQ is succssfully obtained, but it instead returns 0.
    This causes the stop and ready IRQs to never actually be used despite
    being defined in the device-tree. This patch fixes that.
    
    Fixes: aed361adca9f ("remoteproc: qcom: Introduce WCNSS peripheral image loader")
    Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220526141740.15834-2-sireeshkodali1@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

remoteproc: sysmon: Wait for SSCTL service to come up [+ + +]
Author: Sibi Sankar <quic_sibis@quicinc.com>
Date:   Tue Jul 5 17:38:19 2022 +0530

    remoteproc: sysmon: Wait for SSCTL service to come up
    
    [ Upstream commit 47c04e00eff86a81cd357c3feed04c86089bcb85 ]
    
    The SSCTL service comes up after a finite time when the remote Q6 comes
    out of reset. Any graceful shutdowns requested during this period will
    be a NOP and abrupt tearing down of the glink channel might lead to pending
    transactions on the remote Q6 side and will ultimately lead to a fatal
    error. Fix this by waiting for the SSCTL service when a graceful shutdown
    is requested.
    
    Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/1657022900-2049-7-git-send-email-quic_sibis@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Jun 27 16:35:59 2022 +0200

    Revert "mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv"
    
    commit 5f8954e099b8ae96e7de1bb95950e00c85bedd40 upstream.
    
    This reverts commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc as it
    causes build problems in linux-next.  It needs to be reintroduced in a
    way that can allow the api to evolve and not require a "flag day" to
    catch all users.
    
    Link: https://lore.kernel.org/r/20220623160723.7a44b573@canb.auug.org.au
    Cc: Duoming Zhou <duoming@zju.edu.cn>
    Cc: Brian Norris <briannorris@chromium.org>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP" [+ + +]
Author: Jose Alonso <joalonsof@gmail.com>
Date:   Mon Aug 8 08:35:04 2022 -0300

    Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP"
    
    commit 6fd2c17fb6e02a8c0ab51df1cfec82ce96b8e83d upstream.
    
    This reverts commit 36a15e1cb134c0395261ba1940762703f778438c.
    
    The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware
    versions that have no issues.
    
    The FLAG_SEND_ZLP is not safe to use in this context.
    See:
    https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378
    The original problem needs another way to solve.
    
    Fixes: 36a15e1cb134 ("net: usb: ax88179_178a needs FLAG_SEND_ZLP")
    Cc: stable@vger.kernel.org
    Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327
    Link: https://bugs.archlinux.org/task/75491
    Signed-off-by: Jose Alonso <joalonsof@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "pNFS: nfs3_set_ds_client should set NFS_CS_NOPING" [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed May 18 16:37:56 2022 -0400

    Revert "pNFS: nfs3_set_ds_client should set NFS_CS_NOPING"
    
    commit 9597152d98840c2517230740952df97cfcc07e2f upstream.
    
    This reverts commit c6eb58435b98bd843d3179664a0195ff25adb2c3.
    If a transport is down, then we want to fail over to other transports if
    they are listed in the GETDEVICEINFO reply.
    
    Fixes: c6eb58435b98 ("pNFS: nfs3_set_ds_client should set NFS_CS_NOPING")
    Cc: stable@vger.kernel.org # 5.11.x
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "s390/smp: enforce lowcore protection on CPU restart" [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Sat Aug 6 09:29:46 2022 +0200

    Revert "s390/smp: enforce lowcore protection on CPU restart"
    
    commit 953503751a426413ea8aee2299ae3ee971b70d9b upstream.
    
    This reverts commit 6f5c672d17f583b081e283927f5040f726c54598.
    
    This breaks normal crash dump when CPU0 is offline.
    
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RISC-V: Add modules to virtual kernel memory layout dump [+ + +]
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Thu Aug 11 15:41:48 2022 +0800

    RISC-V: Add modules to virtual kernel memory layout dump
    
    commit f9293ad46d8ba9909187a37b7215324420ad4596 upstream.
    
    Modules always live before the kernel, MODULES_END is fixed but
    MODULES_VADDR isn't fixed, it depends on the kernel size.
    Let's add it to virtual kernel memory layout dump.
    
    As MODULES is only defined for CONFIG_64BIT, so we dump it when
    CONFIG_64BIT=y.
    
    eg,
    MODULES_VADDR - MODULES_END
    0xffffffff01133000 - 0xffffffff80000000
    
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220811074150.3020189-5-xianting.tian@linux.alibaba.com
    Cc: stable@vger.kernel.org
    Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping")
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RISC-V: Fixup get incorrect user mode PC for kernel mode regs [+ + +]
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Thu Aug 11 15:41:46 2022 +0800

    RISC-V: Fixup get incorrect user mode PC for kernel mode regs
    
    commit 59c026c359c30f116fef6ee958e24d04983efbb0 upstream.
    
    When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
    will be called to save regs for vmcore, we found "epc" value 00ffffffa5537400
    is not a valid kernel virtual address, but is a user virtual address. Other
    regs(eg, ra, sp, gp...) are correct kernel virtual address.
    Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
    is saved in the task's stack.
    
    [   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
    [   21.201979] Hardware name: riscv-virtio,qemu (DT)
    [   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
    [   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
    [   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
    [   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
    [   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
    [   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
    [   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
    [   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
    [   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
    [   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
    [   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
    [   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
    
    With the incorrect PC, the backtrace showed by crash tool as below, the first
    stack frame is abnormal,
    
    crash> bt
    PID: 113      TASK: ff60000002269600  CPU: 0    COMMAND: "sh"
     #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
     #1 [ff2000001039bcf0] panic at ffffffff806578ba
     #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
     #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
     #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
     #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
     #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
     #7 [ff2000001039be80] ksys_write at ffffffff80152ece
     #8 [ff2000001039bed0] sys_write at ffffffff80152f46
    
    With the patch, we can get current kernel mode PC, the output as below,
    
    [   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
    [   17.607937] Hardware name: riscv-virtio,qemu (DT)
    [   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
    [   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
    [   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
    [   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
    [   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
    [   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
    [   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
    [   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
    [   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
    [   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
    [   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
    [   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
    
    With the correct PC, the backtrace showed by crash tool as below,
    
    crash> bt
    PID: 113      TASK: ff6000000226c200  CPU: 0    COMMAND: "sh"
     #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
     #1 [ff20000010333cf0] panic at ffffffff806578c6
     #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
     #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
     #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
     #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
     #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
     #7 [ff20000010333e80] ksys_write at ffffffff80152eda
     #8 [ff20000010333ed0] sys_write at ffffffff80152f52
    
    Fixes: e53d28180d4d ("RISC-V: Add kdump support")
    Co-developed-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220811074150.3020189-3-xianting.tian@linux.alibaba.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RISC-V: Fixup schedule out issue in machine_crash_shutdown() [+ + +]
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Thu Aug 11 15:41:47 2022 +0800

    RISC-V: Fixup schedule out issue in machine_crash_shutdown()
    
    commit ad943893d5f1d0aeea892bf7b781cf8062b36d58 upstream.
    
    Current task of executing crash kexec will be schedule out when panic is
    triggered by RCU Stall, as it needs to wait rcu completion. It lead to
    inability to enter the crash system.
    
    The implementation of machine_crash_shutdown() is non-standard for RISC-V
    according to other Arch's implementation(eg, x86, arm64), we need to send
    IPI to stop secondary harts.
    
    [224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
    [224521.883471] rcu:    0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793 fqs=2495
    [224521.891742]         (detected by 2, t=5255 jiffies, g=60855593, q=328)
    [224521.897754] Task dump for CPU 0:
    [224521.901074] task:swapper/0     state:R  running task   stack:  0 pid:  0 ppid:   0 flags:0x00000008
    [224521.911090] Call Trace:
    [224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea
    [224521.918957] Kernel panic - not syncing: RCU Stall
    [224521.923773] bad: scheduling from the idle thread!
    [224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G   O  5.10.113-yocto-standard #1
    [224521.938658] Call Trace:
    [224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa
    [224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e
    [224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2
    [224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c
    [224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40
    [224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea
    [224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4
    [224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170
    [224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2
    [224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a
    [224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66
    [224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6
    [224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c
    [224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a
    [224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118
    [224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a
    [224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6
    [224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6
    [224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8
    [224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a
    [224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102
    [224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318
    [224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228
    [224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48
    [224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c
    [224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122
    [224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60
    [224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc
    [224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8
    
    With the patch, it can enter crash system when RCU Stall occur.
    
    Fixes: e53d28180d4d ("RISC-V: Add kdump support")
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220811074150.3020189-4-xianting.tian@linux.alibaba.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context [+ + +]
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Thu Aug 11 15:41:45 2022 +0800

    RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context
    
    commit 357628e68f5c08ad578a718dc62a0031e06dbe91 upstream.
    
    Use __smp_processor_id() to avoid check the preemption context when
    CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no
    return.
    
    Without the patch,
    [  103.781044] sysrq: Trigger a crash
    [  103.784625] Kernel panic - not syncing: sysrq triggered crash
    [  103.837634] CPU1: off
    [  103.889668] CPU2: off
    [  103.933479] CPU3: off
    [  103.939424] Starting crashdump kernel...
    [  103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346
    [  103.950884] caller is debug_smp_processor_id+0x1c/0x26
    [  103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted 5.10.113-00002-gce03f03bf4ec-dirty #149
    [  103.965355] Call Trace:
    [  103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2
    [  103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e
    [  103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e
    [  103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c
    [  103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa
    [  103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26
    [  104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0
    [  104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4
    [  104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0
    [  104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70
    [  104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154
    [  104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a
    [  104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4
    [  104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254
    [  104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe
    [  104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16
    [  104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2
    [  104.067863] Will call new kernel at ecc00000 from hart id 0
    [  104.074939] FDT image at fc5ee000
    [  104.079523] Bye...
    
    With the patch we can got clear output,
    [   67.740553] sysrq: Trigger a crash
    [   67.744166] Kernel panic - not syncing: sysrq triggered crash
    [   67.809123] CPU1: off
    [   67.865210] CPU2: off
    [   67.909075] CPU3: off
    [   67.919123] Starting crashdump kernel...
    [   67.924900] Will call new kernel at ecc00000 from hart id 0
    [   67.932045] FDT image at fc5ee000
    [   67.935560] Bye...
    
    Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec")
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Atish Patra <atishp@rivosinc.com>
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220811074150.3020189-2-xianting.tian@linux.alibaba.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: set default pm_power_off to NULL [+ + +]
Author: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Date:   Tue Sep 7 01:28:47 2021 +0100

    riscv: set default pm_power_off to NULL
    
    commit f2928e224d85e7cc139009ab17cefdfec2df5d11 upstream.
    
    Set pm_power_off to NULL like on all other architectures, check if it
    is set in machine_halt() and machine_power_off() and fallback to
    default_power_off if no other power driver got registered.
    
    This brings riscv architecture inline with all other architectures,
    and allows to reuse exiting power drivers unmodified.
    
    Kernels without legacy SBI v0.1 extensions (CONFIG_RISCV_SBI_V01 is
    not set), do not set pm_power_off to sbi_shutdown(). There is no
    support for SBI v0.3 system reset extension either. This prevents
    using gpio_poweroff on SiFive HiFive Unmatched.
    
    Tested on SiFive HiFive unmatched, with a dtb specifying gpio-poweroff
    node and kernel complied without CONFIG_RISCV_SBI_V01.
    
    BugLink: https://bugs.launchpad.net/bugs/1942806
    Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Tested-by: Ron Economos <w6rz@comcast.net>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: riscv:uprobe fix SR_SPIE set/clear handling [+ + +]
Author: Yipeng Zou <zouyipeng@huawei.com>
Date:   Thu Jul 21 14:58:20 2022 +0800

    riscv:uprobe fix SR_SPIE set/clear handling
    
    commit 3dbe5829408bc1586f75b4667ef60e5aab0209c7 upstream.
    
    In riscv the process of uprobe going to clear spie before exec
    the origin insn,and set spie after that.But When access the page
    which origin insn has been placed a page fault may happen and
    irq was disabled in arch_uprobe_pre_xol function,It cause a WARN
    as follows.
    There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.
    We can just remove it.
    
    [   31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
    [   31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
    [   31.684929] preempt_count: 0, expected: 0
    [   31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
    [   31.686542] Hardware name: riscv-virtio,qemu (DT)
    [   31.686797] Call Trace:
    [   31.687053] [<ffffffff80006442>] dump_backtrace+0x30/0x38
    [   31.687699] [<ffffffff80812118>] show_stack+0x40/0x4c
    [   31.688141] [<ffffffff8081817a>] dump_stack_lvl+0x44/0x5c
    [   31.688396] [<ffffffff808181aa>] dump_stack+0x18/0x20
    [   31.688653] [<ffffffff8003e454>] __might_resched+0x114/0x122
    [   31.688948] [<ffffffff8003e4b2>] __might_sleep+0x50/0x7a
    [   31.689435] [<ffffffff80822676>] down_read+0x30/0x130
    [   31.689728] [<ffffffff8000b650>] do_page_fault+0x166/x446
    [   31.689997] [<ffffffff80003c0c>] ret_from_exception+0x0/0xc
    
    Fixes: 74784081aac8 ("riscv: Add uprobes supported")
    Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220721065820.245755-1-zouyipeng@huawei.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rpmsg: char: Add mutex protection for rpmsg_eptdev_open() [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Sat May 21 11:35:05 2022 +0800

    rpmsg: char: Add mutex protection for rpmsg_eptdev_open()
    
    [ Upstream commit abe13e9a561d6b3e82b21362c0d6dd3ecd8a5b13 ]
    
    There is no mutex protection for rpmsg_eptdev_open(),
    especially for eptdev->ept read and write operation.
    It may cause issues when multiple instances call
    rpmsg_eptdev_open() in parallel,the return state
    may be success or EBUSY.
    
    Fixes: 964e8bedd5a1 ("rpmsg: char: Return an error if device already open")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1653104105-16779-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rpmsg: mtk_rpmsg: Fix circular locking dependency [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Wed May 25 11:12:01 2022 +0200

    rpmsg: mtk_rpmsg: Fix circular locking dependency
    
    [ Upstream commit 353d9214682e65c55cdffad8c82139a3321c5f13 ]
    
    During execution of the worker that's used to register rpmsg devices
    we are safely locking the channels mutex but, when creating a new
    endpoint for such devices, we are registering a IPI on the SCP, which
    then makes the SCP to trigger an interrupt, lock its own mutex and in
    turn register more subdevices.
    This creates a circular locking dependency situation, as the mtk_rpmsg
    channels_lock will then depend on the SCP IPI lock.
    
    [   15.447736] ======================================================
    [   15.460158] WARNING: possible circular locking dependency detected
    [   15.460161] 5.17.0-next-20220324+ #399 Not tainted
    [   15.460165] ------------------------------------------------------
    [   15.460166] kworker/0:3/155 is trying to acquire lock:
    [   15.460170] ffff5b4d0eaf1308 (&scp->ipi_desc[i].lock){+.+.}-{4:4}, at: scp_ipi_lock+0x34/0x50 [mtk_scp_ipi]
    [   15.504958]
    []                but task is already holding lock:
    [   15.504960] ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg]
    [   15.504978]
    []                which lock already depends on the new lock.
    
    [   15.504980]
    []                the existing dependency chain (in reverse order) is:
    [   15.504982]
    []               -> #1 (&mtk_subdev->channels_lock){+.+.}-{4:4}:
    [   15.504990]        lock_acquire+0x68/0x84
    [   15.504999]        __mutex_lock+0xa4/0x3e0
    [   15.505007]        mutex_lock_nested+0x40/0x70
    [   15.505012]        mtk_rpmsg_ns_cb+0xe4/0x134 [mtk_rpmsg]
    [   15.641684]        mtk_rpmsg_ipi_handler+0x38/0x64 [mtk_rpmsg]
    [   15.641693]        scp_ipi_handler+0xbc/0x180 [mtk_scp]
    [   15.663905]        mt8192_scp_irq_handler+0x44/0xa4 [mtk_scp]
    [   15.663915]        scp_irq_handler+0x6c/0xa0 [mtk_scp]
    [   15.685779]        irq_thread_fn+0x34/0xa0
    [   15.685785]        irq_thread+0x18c/0x240
    [   15.685789]        kthread+0x104/0x110
    [   15.709579]        ret_from_fork+0x10/0x20
    [   15.709586]
    []               -> #0 (&scp->ipi_desc[i].lock){+.+.}-{4:4}:
    [   15.731271]        __lock_acquire+0x11e4/0x1910
    [   15.740367]        lock_acquire.part.0+0xd8/0x220
    [   15.749813]        lock_acquire+0x68/0x84
    [   15.757861]        __mutex_lock+0xa4/0x3e0
    [   15.766084]        mutex_lock_nested+0x40/0x70
    [   15.775006]        scp_ipi_lock+0x34/0x50 [mtk_scp_ipi]
    [   15.785503]        scp_ipi_register+0x40/0xa4 [mtk_scp_ipi]
    [   15.796697]        scp_register_ipi+0x1c/0x30 [mtk_scp]
    [   15.807194]        mtk_rpmsg_create_ept+0xa0/0x108 [mtk_rpmsg]
    [   15.818912]        rpmsg_create_ept+0x44/0x60
    [   15.827660]        cros_ec_rpmsg_probe+0x15c/0x1f0
    [   15.837282]        rpmsg_dev_probe+0x128/0x1d0
    [   15.846203]        really_probe.part.0+0xa4/0x2a0
    [   15.855649]        __driver_probe_device+0xa0/0x150
    [   15.865443]        driver_probe_device+0x48/0x150
    [   15.877157]        __device_attach_driver+0xc0/0x12c
    [   15.889359]        bus_for_each_drv+0x80/0xe0
    [   15.900330]        __device_attach+0xe4/0x190
    [   15.911303]        device_initial_probe+0x1c/0x2c
    [   15.922969]        bus_probe_device+0xa8/0xb0
    [   15.933927]        device_add+0x3a8/0x8a0
    [   15.944193]        device_register+0x28/0x40
    [   15.954970]        rpmsg_register_device+0x5c/0xa0
    [   15.966782]        mtk_register_device_work_function+0x148/0x1cc [mtk_rpmsg]
    [   15.983146]        process_one_work+0x294/0x664
    [   15.994458]        worker_thread+0x7c/0x45c
    [   16.005069]        kthread+0x104/0x110
    [   16.014789]        ret_from_fork+0x10/0x20
    [   16.025201]
    []               other info that might help us debug this:
    
    [   16.047769]  Possible unsafe locking scenario:
    
    [   16.063942]        CPU0                    CPU1
    [   16.075166]        ----                    ----
    [   16.086376]   lock(&mtk_subdev->channels_lock);
    [   16.097592]                                lock(&scp->ipi_desc[i].lock);
    [   16.113188]                                lock(&mtk_subdev->channels_lock);
    [   16.129482]   lock(&scp->ipi_desc[i].lock);
    [   16.140020]
    []                *** DEADLOCK ***
    
    [   16.158282] 4 locks held by kworker/0:3/155:
    [   16.168978]  #0: ffff5b4d00008748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664
    [   16.190017]  #1: ffff80000953bdc8 ((work_completion)(&mtk_subdev->register_work)){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664
    [   16.215269]  #2: ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg]
    [   16.242131]  #3: ffff5b4d05964190 (&dev->mutex){....}-{4:4}, at: __device_attach+0x44/0x190
    
    To solve this, simply unlock the channels_lock mutex before calling
    mtk_rpmsg_register_device() and relock it right after, as safety is
    still ensured by the locking mechanism that happens right after
    through SCP.
    
    Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20220525091201.14210-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 16:07:37 2022 +0400

    rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge
    
    [ Upstream commit 65382585f067d4256ba087934f30f85c9b6984de ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    
    Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220511120737.57374-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtc: rx8025: fix 12/24 hour mode detection on RX-8035 [+ + +]
Author: Mathew McBride <matt@traverse.com.au>
Date:   Wed Jul 6 07:42:36 2022 +0000

    rtc: rx8025: fix 12/24 hour mode detection on RX-8035
    
    commit 71af91565052214ad86f288e0d8ffb165f790995 upstream.
    
    The 12/24hr flag in the RX-8035 can be found in the hour register,
    instead of the CTRL1 on the RX-8025. This was overlooked when
    support for the RX-8035 was added, and was causing read errors when
    the hour register 'overflowed'.
    
    To deal with the relevant register not always being visible in
    the relevant functions, determine the 12/24 mode at startup and
    store it in the driver state.
    
    Signed-off-by: Mathew McBride <matt@traverse.com.au>
    Fixes: f120e2e33ac8 ("rtc: rx8025: implement RX-8035 support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220706074236.24011-1-matt@traverse.com.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/crash: fix incorrect number of bytes to copy to user space [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Fri Jul 15 12:59:33 2022 +0200

    s390/crash: fix incorrect number of bytes to copy to user space
    
    [ Upstream commit f6749da17a34eb08c9665f072ce7c812ff68aad2 ]
    
    The number of bytes in a chunk is correctly calculated, but instead
    the total number of bytes is passed to copy_to_user_real() function.
    
    Reported-by: Matthew Wilcox <willy@infradead.org>
    Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions")
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/dump: fix old lowcore virtual vs physical address confusion [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Sat Jan 29 08:38:56 2022 +0100

    s390/dump: fix old lowcore virtual vs physical address confusion
    
    [ Upstream commit dc306186a130c6d9feb0aabc1c71b8ed1674a3bf ]
    
    Virtual addresses of vmcore_info and os_info members are
    wrongly passed to copy_oldmem_kernel(), while the function
    expects physical address of the source. Instead, __pa()
    macro should have been applied.
    
    Yet, use of __pa() macro could be somehow confusing, since
    copy_oldmem_kernel() may treat the source as an offset, not
    as a direct physical address (that depens from the oldmem
    availability and location).
    
    Fix the virtual vs physical address confusion and make the
    way the old lowcore is read consistent across all sources.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/dump: fix os_info virtual vs physical address confusion [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Wed Jan 26 13:47:59 2022 +0100

    s390/dump: fix os_info virtual vs physical address confusion
    
    [ Upstream commit 9de209c7d584d6e06ad92f120d83d4f27c200497 ]
    
    Due to historical reasons os_info handling functions misuse
    the notion of physical vs virtual addresses difference.
    
    Note: this does not fix a bug currently, since virtual
    and physical addresses are identical.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/maccess: fix semantics of memcpy_real() and its callers [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Sat Jan 29 09:24:50 2022 +0100

    s390/maccess: fix semantics of memcpy_real() and its callers
    
    [ Upstream commit 303fd988ed644c7daa260410f3ac99266573557d ]
    
    There is a confusion with regard to the source address of
    memcpy_real() and calling functions. While the declared
    type for a source assumes a virtual address, in fact it
    always called with physical address of the source.
    
    This confusion led to bugs in copy_oldmem_kernel() and
    copy_oldmem_user() functions, where __pa() macro applied
    mistakenly to physical addresses. It does not lead to a
    real issue, since virtual and physical addresses are
    currently the same.
    
    Fix both the bugs and memcpy_real() prototype by making
    type of source address consistent to the function name
    and the way it actually used.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/maccess: rework absolute lowcore accessors [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Thu Mar 17 15:03:03 2022 +0100

    s390/maccess: rework absolute lowcore accessors
    
    [ Upstream commit ed0192bc644f3553d64a5cb461bdd0b1fbae3fdf ]
    
    Macro mem_assign_absolute() is able to access the whole memory, but
    is only used and makes sense when updating the absolute lowcore.
    Instead, introduce get_abs_lowcore() and put_abs_lowcore() macros
    that limit access to absolute lowcore addresses only.
    
    Suggested-by: Heiko Carstens <hca@linux.ibm.com>
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/smp: cleanup control register update routines [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Thu Mar 17 15:03:02 2022 +0100

    s390/smp: cleanup control register update routines
    
    [ Upstream commit 9097fc793f74ef9c677f8c4aed0c24f6f07f0133 ]
    
    Get rid of duplicate code and redundant data.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/smp: cleanup target CPU callback starting [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Thu Mar 17 15:03:01 2022 +0100

    s390/smp: cleanup target CPU callback starting
    
    [ Upstream commit dc2ab23b992c9d5dab93b9bf01b10b10465e537e ]
    
    Macro mem_assign_absolute() is used to initialize a target
    CPU lowcore callback parameters. But despite the macro name
    it writes to the absolute lowcore only if the target CPU is
    offline. In case the CPU is online the macro does implicitly
    write to the normal memory.
    
    That behaviour is correct, but extremely subtle. Sacrifice
    few program bits in favour of clarity and distinguish between
    online vs offline CPUs and normal vs absolute lowcore pointer.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/smp: enforce lowcore protection on CPU restart [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Wed Jul 20 07:24:03 2022 +0200

    s390/smp: enforce lowcore protection on CPU restart
    
    [ Upstream commit 6f5c672d17f583b081e283927f5040f726c54598 ]
    
    As result of commit 915fea04f932 ("s390/smp: enable DAT before
    CPU restart callback is called") the low-address protection bit
    gets mistakenly unset in control register 0 save area of the
    absolute zero memory. That area is used when manual PSW restart
    happened to hit an offline CPU. In this case the low-address
    protection for that CPU will be dropped.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Fixes: 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called")
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/zcore: fix race when reading from hardware system area [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Tue Jul 19 07:16:33 2022 +0200

    s390/zcore: fix race when reading from hardware system area
    
    [ Upstream commit 9ffed254d938c9e99eb7761c7f739294c84e0367 ]
    
    Memory buffer used for reading out data from hardware system
    area is not protected against concurrent access.
    
    Reported-by: Matthew Wilcox <willy@infradead.org>
    Fixes: 411ed3225733 ("[S390] zfcpdump support.")
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Link: https://lore.kernel.org/r/e68137f0f9a0d2558f37becc20af18e2939934f6.1658206891.git.agordeev@linux.ibm.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Tue Aug 2 21:54:51 2022 -0400

    sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed
    
    [ Upstream commit b6e8d40d43ae4dec00c8fea2593eeea3114b8f44 ]
    
    With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating
    that the cpuset will just use the effective CPUs of its parent. So
    cpuset_can_attach() can call task_can_attach() with an empty mask.
    This can lead to cpumask_any_and() returns nr_cpu_ids causing the call
    to dl_bw_of() to crash due to percpu value access of an out of bound
    CPU value. For example:
    
            [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0
              :
            [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0
              :
            [80468.207946] Call Trace:
            [80468.208947]  cpuset_can_attach+0xa0/0x140
            [80468.209953]  cgroup_migrate_execute+0x8c/0x490
            [80468.210931]  cgroup_update_dfl_csses+0x254/0x270
            [80468.211898]  cgroup_subtree_control_write+0x322/0x400
            [80468.212854]  kernfs_fop_write_iter+0x11c/0x1b0
            [80468.213777]  new_sync_write+0x11f/0x1b0
            [80468.214689]  vfs_write+0x1eb/0x280
            [80468.215592]  ksys_write+0x5f/0xe0
            [80468.216463]  do_syscall_64+0x5c/0x80
            [80468.224287]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fix that by using effective_cpus instead. For cgroup v1, effective_cpus
    is the same as cpus_allowed. For v2, effective_cpus is the real cpumask
    to be used by tasks within the cpuset anyway.
    
    Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to
    reflect the change. In addition, a check is added to task_can_attach()
    to guard against the possibility that cpumask_any_and() may return a
    value >= nr_cpu_ids.
    
    Fixes: 7f51412a415d ("sched/deadline: Fix bandwidth check/update when migrating tasks between exclusive cpusets")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://lore.kernel.org/r/20220803015451.2219567-1-longman@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/core: Always flush pending blk_plug [+ + +]
Author: John Keeping <john@metanate.com>
Date:   Fri Jul 8 17:27:02 2022 +0100

    sched/core: Always flush pending blk_plug
    
    [ Upstream commit 401e4963bf45c800e3e9ea0d3a0289d738005fd4 ]
    
    With CONFIG_PREEMPT_RT, it is possible to hit a deadlock between two
    normal priority tasks (SCHED_OTHER, nice level zero):
    
            INFO: task kworker/u8:0:8 blocked for more than 491 seconds.
                  Not tainted 5.15.49-rt46 #1
            "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
            task:kworker/u8:0    state:D stack:    0 pid:    8 ppid:     2 flags:0x00000000
            Workqueue: writeback wb_workfn (flush-7:0)
            [<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134)
            [<c08a3d84>] (schedule) from [<c08a65a0>] (rt_mutex_slowlock_block.constprop.0+0xb8/0x174)
            [<c08a65a0>] (rt_mutex_slowlock_block.constprop.0) from [<c08a6708>]
            +(rt_mutex_slowlock.constprop.0+0xac/0x174)
            [<c08a6708>] (rt_mutex_slowlock.constprop.0) from [<c0374d60>] (fat_write_inode+0x34/0x54)
            [<c0374d60>] (fat_write_inode) from [<c0297304>] (__writeback_single_inode+0x354/0x3ec)
            [<c0297304>] (__writeback_single_inode) from [<c0297998>] (writeback_sb_inodes+0x250/0x45c)
            [<c0297998>] (writeback_sb_inodes) from [<c0297c20>] (__writeback_inodes_wb+0x7c/0xb8)
            [<c0297c20>] (__writeback_inodes_wb) from [<c0297f24>] (wb_writeback+0x2c8/0x2e4)
            [<c0297f24>] (wb_writeback) from [<c0298c40>] (wb_workfn+0x1a4/0x3e4)
            [<c0298c40>] (wb_workfn) from [<c0138ab8>] (process_one_work+0x1fc/0x32c)
            [<c0138ab8>] (process_one_work) from [<c0139120>] (worker_thread+0x22c/0x2d8)
            [<c0139120>] (worker_thread) from [<c013e6e0>] (kthread+0x16c/0x178)
            [<c013e6e0>] (kthread) from [<c01000fc>] (ret_from_fork+0x14/0x38)
            Exception stack(0xc10e3fb0 to 0xc10e3ff8)
            3fa0:                                     00000000 00000000 00000000 00000000
            3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
            3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
    
            INFO: task tar:2083 blocked for more than 491 seconds.
                  Not tainted 5.15.49-rt46 #1
            "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
            task:tar             state:D stack:    0 pid: 2083 ppid:  2082 flags:0x00000000
            [<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134)
            [<c08a3d84>] (schedule) from [<c08a41b0>] (io_schedule+0x14/0x24)
            [<c08a41b0>] (io_schedule) from [<c08a455c>] (bit_wait_io+0xc/0x30)
            [<c08a455c>] (bit_wait_io) from [<c08a441c>] (__wait_on_bit_lock+0x54/0xa8)
            [<c08a441c>] (__wait_on_bit_lock) from [<c08a44f4>] (out_of_line_wait_on_bit_lock+0x84/0xb0)
            [<c08a44f4>] (out_of_line_wait_on_bit_lock) from [<c0371fb0>] (fat_mirror_bhs+0xa0/0x144)
            [<c0371fb0>] (fat_mirror_bhs) from [<c0372a68>] (fat_alloc_clusters+0x138/0x2a4)
            [<c0372a68>] (fat_alloc_clusters) from [<c0370b14>] (fat_alloc_new_dir+0x34/0x250)
            [<c0370b14>] (fat_alloc_new_dir) from [<c03787c0>] (vfat_mkdir+0x58/0x148)
            [<c03787c0>] (vfat_mkdir) from [<c0277b60>] (vfs_mkdir+0x68/0x98)
            [<c0277b60>] (vfs_mkdir) from [<c027b484>] (do_mkdirat+0xb0/0xec)
            [<c027b484>] (do_mkdirat) from [<c0100060>] (ret_fast_syscall+0x0/0x1c)
            Exception stack(0xc2e1bfa8 to 0xc2e1bff0)
            bfa0:                   01ee42f0 01ee4208 01ee42f0 000041ed 00000000 00004000
            bfc0: 01ee42f0 01ee4208 00000000 00000027 01ee4302 00000004 000dcb00 01ee4190
            bfe0: 000dc368 bed11924 0006d4b0 b6ebddfc
    
    Here the kworker is waiting on msdos_sb_info::s_lock which is held by
    tar which is in turn waiting for a buffer which is locked waiting to be
    flushed, but this operation is plugged in the kworker.
    
    The lock is a normal struct mutex, so tsk_is_pi_blocked() will always
    return false on !RT and thus the behaviour changes for RT.
    
    It seems that the intent here is to skip blk_flush_plug() in the case
    where a non-preemptible lock (such as a spinlock) has been converted to
    a rtmutex on RT, which is the case covered by the SM_RTLOCK_WAIT
    schedule flag.  But sched_submit_work() is only called from schedule()
    which is never called in this scenario, so the check can simply be
    deleted.
    
    Looking at the history of the -rt patchset, in fact this change was
    present from v5.9.1-rt20 until being dropped in v5.13-rt1 as it was part
    of a larger patch [1] most of which was replaced by commit b4bfa3fcfe3b
    ("sched/core: Rework the __schedule() preempt argument").
    
    As described in [1]:
    
       The schedule process must distinguish between blocking on a regular
       sleeping lock (rwsem and mutex) and a RT-only sleeping lock (spinlock
       and rwlock):
       - rwsem and mutex must flush block requests (blk_schedule_flush_plug())
         even if blocked on a lock. This can not deadlock because this also
         happens for non-RT.
         There should be a warning if the scheduling point is within a RCU read
         section.
    
       - spinlock and rwlock must not flush block requests. This will deadlock
         if the callback attempts to acquire a lock which is already acquired.
         Similarly to being preempted, there should be no warning if the
         scheduling point is within a RCU read section.
    
    and with the tsk_is_pi_blocked() in the scheduler path, we hit the first
    issue.
    
    [1] https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/0022-locking-rtmutex-Use-custom-scheduling-function-for-s.patch?h=linux-5.10.y-rt-patches
    
    Signed-off-by: John Keeping <john@metanate.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Link: https://lkml.kernel.org/r/20220708162702.1758865-1-john@metanate.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/core: Do not requeue task on CPU excluded from cpus_mask [+ + +]
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Thu Aug 4 10:21:19 2022 +0100

    sched/core: Do not requeue task on CPU excluded from cpus_mask
    
    [ Upstream commit 751d4cbc43879229dbc124afefe240b70fd29a85 ]
    
    The following warning was triggered on a large machine early in boot on
    a distribution kernel but the same problem should also affect mainline.
    
       WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440
       Call Trace:
        <TASK>
        rescuer_thread+0x1f6/0x360
        kthread+0x156/0x180
        ret_from_fork+0x22/0x30
        </TASK>
    
    Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
    optimises ttwu by queueing a task that is descheduling on the wakelist,
    but does not check if the task descheduling is still allowed to run on that CPU.
    
    In this warning, the problematic task is a workqueue rescue thread which
    checks if the rescue is for a per-cpu workqueue and running on the wrong CPU.
    While this is early in boot and it should be possible to create workers,
    the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached
    or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue
    thread is being used frequently.
    
    Tracing confirmed that the task should have migrated properly using the
    stopper thread to handle the migration. However, a parallel wakeup from udev
    running on another CPU that does not share CPU cache observes p->on_cpu and
    uses task_cpu(p), queues the task on the old CPU and triggers the warning.
    
    Check that the wakee task that is descheduling is still allowed to run
    on its current CPU and if not, wait for the descheduling to complete
    and select an allowed CPU.
    
    Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20220804092119.20137-1-mgorman@techsingularity.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/deadline: Merge dl_task_can_attach() and dl_cpu_busy() [+ + +]
Author: Dietmar Eggemann <dietmar.eggemann@arm.com>
Date:   Wed Mar 2 19:34:30 2022 +0100

    sched/deadline: Merge dl_task_can_attach() and dl_cpu_busy()
    
    [ Upstream commit 772b6539fdda31462cc08368e78df60b31a58bab ]
    
    Both functions are doing almost the same, that is checking if admission
    control is still respected.
    
    With exclusive cpusets, dl_task_can_attach() checks if the destination
    cpuset (i.e. its root domain) has enough CPU capacity to accommodate the
    task.
    dl_cpu_busy() checks if there is enough CPU capacity in the cpuset in
    case the CPU is hot-plugged out.
    
    dl_task_can_attach() is used to check if a task can be admitted while
    dl_cpu_busy() is used to check if a CPU can be hotplugged out.
    
    Make dl_cpu_busy() able to deal with a task and use it instead of
    dl_task_can_attach() in task_can_attach().
    
    Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://lore.kernel.org/r/20220302183433.333029-4-dietmar.eggemann@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg [+ + +]
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Mon Jun 13 00:34:28 2022 +0800

    sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg
    
    [ Upstream commit 70fb5ccf2ebb09a0c8ebba775041567812d45f86 ]
    
    [Problem Statement]
    select_idle_cpu() might spend too much time searching for an idle CPU,
    when the system is overloaded.
    
    The following histogram is the time spent in select_idle_cpu(),
    when running 224 instances of netperf on a system with 112 CPUs
    per LLC domain:
    
    @usecs:
    [0]                  533 |                                                    |
    [1]                 5495 |                                                    |
    [2, 4)             12008 |                                                    |
    [4, 8)            239252 |                                                    |
    [8, 16)          4041924 |@@@@@@@@@@@@@@                                      |
    [16, 32)        12357398 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@         |
    [32, 64)        14820255 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
    [64, 128)       13047682 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@       |
    [128, 256)       8235013 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@                        |
    [256, 512)       4507667 |@@@@@@@@@@@@@@@                                     |
    [512, 1K)        2600472 |@@@@@@@@@                                           |
    [1K, 2K)          927912 |@@@                                                 |
    [2K, 4K)          218720 |                                                    |
    [4K, 8K)           98161 |                                                    |
    [8K, 16K)          37722 |                                                    |
    [16K, 32K)          6715 |                                                    |
    [32K, 64K)           477 |                                                    |
    [64K, 128K)            7 |                                                    |
    
    netperf latency usecs:
    =======
    case                    load                Lat_99th        std%
    TCP_RR                  thread-224            257.39    (  0.21)
    
    The time spent in select_idle_cpu() is visible to netperf and might have a negative
    impact.
    
    [Symptom analysis]
    The patch [1] from Mel Gorman has been applied to track the efficiency
    of select_idle_sibling. Copy the indicators here:
    
    SIS Search Efficiency(se_eff%):
            A ratio expressed as a percentage of runqueues scanned versus
            idle CPUs found. A 100% efficiency indicates that the target,
            prev or recent CPU of a task was idle at wakeup. The lower the
            efficiency, the more runqueues were scanned before an idle CPU
            was found.
    
    SIS Domain Search Efficiency(dom_eff%):
            Similar, except only for the slower SIS
            patch.
    
    SIS Fast Success Rate(fast_rate%):
            Percentage of SIS that used target, prev or
            recent CPUs.
    
    SIS Success rate(success_rate%):
            Percentage of scans that found an idle CPU.
    
    The test is based on Aubrey's schedtests tool, including netperf, hackbench,
    schbench and tbench.
    
    Test on vanilla kernel:
    schedstat_parse.py -f netperf_vanilla.log
    case            load        se_eff%         dom_eff%      fast_rate%    success_rate%
    TCP_RR     28 threads        99.978           18.535          99.995         100.000
    TCP_RR     56 threads        99.397            5.671          99.964         100.000
    TCP_RR     84 threads        21.721            6.818          73.632         100.000
    TCP_RR    112 threads        12.500            5.533          59.000         100.000
    TCP_RR    140 threads         8.524            4.535          49.020         100.000
    TCP_RR    168 threads         6.438            3.945          40.309          99.999
    TCP_RR    196 threads         5.397            3.718          32.320          99.982
    TCP_RR    224 threads         4.874            3.661          25.775          99.767
    UDP_RR     28 threads        99.988           17.704          99.997         100.000
    UDP_RR     56 threads        99.528            5.977          99.970         100.000
    UDP_RR     84 threads        24.219            6.992          76.479         100.000
    UDP_RR    112 threads        13.907            5.706          62.538         100.000
    UDP_RR    140 threads         9.408            4.699          52.519         100.000
    UDP_RR    168 threads         7.095            4.077          44.352         100.000
    UDP_RR    196 threads         5.757            3.775          35.764          99.991
    UDP_RR    224 threads         5.124            3.704          28.748          99.860
    
    schedstat_parse.py -f schbench_vanilla.log
    (each group has 28 tasks)
    case            load        se_eff%         dom_eff%      fast_rate%    success_rate%
    normal     1   mthread       99.152            6.400          99.941         100.000
    normal     2   mthreads      97.844            4.003          99.908         100.000
    normal     3   mthreads      96.395            2.118          99.917          99.998
    normal     4   mthreads      55.288            1.451          98.615          99.804
    normal     5   mthreads       7.004            1.870          45.597          61.036
    normal     6   mthreads       3.354            1.346          20.777          34.230
    normal     7   mthreads       2.183            1.028          11.257          21.055
    normal     8   mthreads       1.653            0.825           7.849          15.549
    
    schedstat_parse.py -f hackbench_vanilla.log
    (each group has 28 tasks)
    case                    load            se_eff%     dom_eff%      fast_rate%    success_rate%
    process-pipe         1 group             99.991        7.692          99.999         100.000
    process-pipe        2 groups             99.934        4.615          99.997         100.000
    process-pipe        3 groups             99.597        3.198          99.987         100.000
    process-pipe        4 groups             98.378        2.464          99.958         100.000
    process-pipe        5 groups             27.474        3.653          89.811          99.800
    process-pipe        6 groups             20.201        4.098          82.763          99.570
    process-pipe        7 groups             16.423        4.156          77.398          99.316
    process-pipe        8 groups             13.165        3.920          72.232          98.828
    process-sockets      1 group             99.977        5.882          99.999         100.000
    process-sockets     2 groups             99.927        5.505          99.996         100.000
    process-sockets     3 groups             99.397        3.250          99.980         100.000
    process-sockets     4 groups             79.680        4.258          98.864          99.998
    process-sockets     5 groups              7.673        2.503          63.659          92.115
    process-sockets     6 groups              4.642        1.584          58.946          88.048
    process-sockets     7 groups              3.493        1.379          49.816          81.164
    process-sockets     8 groups              3.015        1.407          40.845          75.500
    threads-pipe         1 group             99.997        0.000         100.000         100.000
    threads-pipe        2 groups             99.894        2.932          99.997         100.000
    threads-pipe        3 groups             99.611        4.117          99.983         100.000
    threads-pipe        4 groups             97.703        2.624          99.937         100.000
    threads-pipe        5 groups             22.919        3.623          87.150          99.764
    threads-pipe        6 groups             18.016        4.038          80.491          99.557
    threads-pipe        7 groups             14.663        3.991          75.239          99.247
    threads-pipe        8 groups             12.242        3.808          70.651          98.644
    threads-sockets      1 group             99.990        6.667          99.999         100.000
    threads-sockets     2 groups             99.940        5.114          99.997         100.000
    threads-sockets     3 groups             99.469        4.115          99.977         100.000
    threads-sockets     4 groups             87.528        4.038          99.400         100.000
    threads-sockets     5 groups              6.942        2.398          59.244          88.337
    threads-sockets     6 groups              4.359        1.954          49.448          87.860
    threads-sockets     7 groups              2.845        1.345          41.198          77.102
    threads-sockets     8 groups              2.871        1.404          38.512          74.312
    
    schedstat_parse.py -f tbench_vanilla.log
    case                    load          se_eff%       dom_eff%      fast_rate%    success_rate%
    loopback          28 threads           99.976         18.369          99.995         100.000
    loopback          56 threads           99.222          7.799          99.934         100.000
    loopback          84 threads           19.723          6.819          70.215         100.000
    loopback         112 threads           11.283          5.371          55.371          99.999
    loopback         140 threads            0.000          0.000           0.000           0.000
    loopback         168 threads            0.000          0.000           0.000           0.000
    loopback         196 threads            0.000          0.000           0.000           0.000
    loopback         224 threads            0.000          0.000           0.000           0.000
    
    According to the test above, if the system becomes busy, the
    SIS Search Efficiency(se_eff%) drops significantly. Although some
    benchmarks would finally find an idle CPU(success_rate% = 100%), it is
    doubtful whether it is worth it to search the whole LLC domain.
    
    [Proposal]
    It would be ideal to have a crystal ball to answer this question:
    How many CPUs must a wakeup path walk down, before it can find an idle
    CPU? Many potential metrics could be used to predict the number.
    One candidate is the sum of util_avg in this LLC domain. The benefit
    of choosing util_avg is that it is a metric of accumulated historic
    activity, which seems to be smoother than instantaneous metrics
    (such as rq->nr_running). Besides, choosing the sum of util_avg
    would help predict the load of the LLC domain more precisely, because
    SIS_PROP uses one CPU's idle time to estimate the total LLC domain idle
    time.
    
    In summary, the lower the util_avg is, the more select_idle_cpu()
    should scan for idle CPU, and vice versa. When the sum of util_avg
    in this LLC domain hits 85% or above, the scan stops. The reason to
    choose 85% as the threshold is that this is the imbalance_pct(117)
    when a LLC sched group is overloaded.
    
    Introduce the quadratic function:
    
    y = SCHED_CAPACITY_SCALE - p * x^2
    and y'= y / SCHED_CAPACITY_SCALE
    
    x is the ratio of sum_util compared to the CPU capacity:
    x = sum_util / (llc_weight * SCHED_CAPACITY_SCALE)
    y' is the ratio of CPUs to be scanned in the LLC domain,
    and the number of CPUs to scan is calculated by:
    
    nr_scan = llc_weight * y'
    
    Choosing quadratic function is because:
    [1] Compared to the linear function, it scans more aggressively when the
        sum_util is low.
    [2] Compared to the exponential function, it is easier to calculate.
    [3] It seems that there is no accurate mapping between the sum of util_avg
        and the number of CPUs to be scanned. Use heuristic scan for now.
    
    For a platform with 112 CPUs per LLC, the number of CPUs to scan is:
    sum_util%   0    5   15   25  35  45  55   65   75   85   86 ...
    scan_nr   112  111  108  102  93  81  65   47   25    1    0 ...
    
    For a platform with 16 CPUs per LLC, the number of CPUs to scan is:
    sum_util%   0    5   15   25  35  45  55   65   75   85   86 ...
    scan_nr    16   15   15   14  13  11   9    6    3    0    0 ...
    
    Furthermore, to minimize the overhead of calculating the metrics in
    select_idle_cpu(), borrow the statistics from periodic load balance.
    As mentioned by Abel, on a platform with 112 CPUs per LLC, the
    sum_util calculated by periodic load balance after 112 ms would
    decay to about 0.5 * 0.5 * 0.5 * 0.7 = 8.75%, thus bringing a delay
    in reflecting the latest utilization. But it is a trade-off.
    Checking the util_avg in newidle load balance would be more frequent,
    but it brings overhead - multiple CPUs write/read the per-LLC shared
    variable and introduces cache contention. Tim also mentioned that,
    it is allowed to be non-optimal in terms of scheduling for the
    short-term variations, but if there is a long-term trend in the load
    behavior, the scheduler can adjust for that.
    
    When SIS_UTIL is enabled, the select_idle_cpu() uses the nr_scan
    calculated by SIS_UTIL instead of the one from SIS_PROP. As Peter and
    Mel suggested, SIS_UTIL should be enabled by default.
    
    This patch is based on the util_avg, which is very sensitive to the
    CPU frequency invariance. There is an issue that, when the max frequency
    has been clamp, the util_avg would decay insanely fast when
    the CPU is idle. Commit addca285120b ("cpufreq: intel_pstate: Handle no_turbo
    in frequency invariance") could be used to mitigate this symptom, by adjusting
    the arch_max_freq_ratio when turbo is disabled. But this issue is still
    not thoroughly fixed, because the current code is unaware of the user-specified
    max CPU frequency.
    
    [Test result]
    
    netperf and tbench were launched with 25% 50% 75% 100% 125% 150%
    175% 200% of CPU number respectively. Hackbench and schbench were launched
    by 1, 2 ,4, 8 groups. Each test lasts for 100 seconds and repeats 3 times.
    
    The following is the benchmark result comparison between
    baseline:vanilla v5.19-rc1 and compare:patched kernel. Positive compare%
    indicates better performance.
    
    Each netperf test is a:
    netperf -4 -H 127.0.1 -t TCP/UDP_RR -c -C -l 100
    netperf.throughput
    =======
    case                    load            baseline(std%)  compare%( std%)
    TCP_RR                  28 threads       1.00 (  0.34)   -0.16 (  0.40)
    TCP_RR                  56 threads       1.00 (  0.19)   -0.02 (  0.20)
    TCP_RR                  84 threads       1.00 (  0.39)   -0.47 (  0.40)
    TCP_RR                  112 threads      1.00 (  0.21)   -0.66 (  0.22)
    TCP_RR                  140 threads      1.00 (  0.19)   -0.69 (  0.19)
    TCP_RR                  168 threads      1.00 (  0.18)   -0.48 (  0.18)
    TCP_RR                  196 threads      1.00 (  0.16)  +194.70 ( 16.43)
    TCP_RR                  224 threads      1.00 (  0.16)  +197.30 (  7.85)
    UDP_RR                  28 threads       1.00 (  0.37)   +0.35 (  0.33)
    UDP_RR                  56 threads       1.00 ( 11.18)   -0.32 (  0.21)
    UDP_RR                  84 threads       1.00 (  1.46)   -0.98 (  0.32)
    UDP_RR                  112 threads      1.00 ( 28.85)   -2.48 ( 19.61)
    UDP_RR                  140 threads      1.00 (  0.70)   -0.71 ( 14.04)
    UDP_RR                  168 threads      1.00 ( 14.33)   -0.26 ( 11.16)
    UDP_RR                  196 threads      1.00 ( 12.92)  +186.92 ( 20.93)
    UDP_RR                  224 threads      1.00 ( 11.74)  +196.79 ( 18.62)
    
    Take the 224 threads as an example, the SIS search metrics changes are
    illustrated below:
    
        vanilla                    patched
       4544492          +237.5%   15338634        sched_debug.cpu.sis_domain_search.avg
         38539        +39686.8%   15333634        sched_debug.cpu.sis_failed.avg
      128300000          -87.9%   15551326        sched_debug.cpu.sis_scanned.avg
       5842896          +162.7%   15347978        sched_debug.cpu.sis_search.avg
    
    There is -87.9% less CPU scans after patched, which indicates lower overhead.
    Besides, with this patch applied, there is -13% less rq lock contention
    in perf-profile.calltrace.cycles-pp._raw_spin_lock.raw_spin_rq_lock_nested
    .try_to_wake_up.default_wake_function.woken_wake_function.
    This might help explain the performance improvement - Because this patch allows
    the waking task to remain on the previous CPU, rather than grabbing other CPUs'
    lock.
    
    Each hackbench test is a:
    hackbench -g $job --process/threads --pipe/sockets -l 1000000 -s 100
    hackbench.throughput
    =========
    case                    load            baseline(std%)  compare%( std%)
    process-pipe            1 group          1.00 (  1.29)   +0.57 (  0.47)
    process-pipe            2 groups         1.00 (  0.27)   +0.77 (  0.81)
    process-pipe            4 groups         1.00 (  0.26)   +1.17 (  0.02)
    process-pipe            8 groups         1.00 (  0.15)   -4.79 (  0.02)
    process-sockets         1 group          1.00 (  0.63)   -0.92 (  0.13)
    process-sockets         2 groups         1.00 (  0.03)   -0.83 (  0.14)
    process-sockets         4 groups         1.00 (  0.40)   +5.20 (  0.26)
    process-sockets         8 groups         1.00 (  0.04)   +3.52 (  0.03)
    threads-pipe            1 group          1.00 (  1.28)   +0.07 (  0.14)
    threads-pipe            2 groups         1.00 (  0.22)   -0.49 (  0.74)
    threads-pipe            4 groups         1.00 (  0.05)   +1.88 (  0.13)
    threads-pipe            8 groups         1.00 (  0.09)   -4.90 (  0.06)
    threads-sockets         1 group          1.00 (  0.25)   -0.70 (  0.53)
    threads-sockets         2 groups         1.00 (  0.10)   -0.63 (  0.26)
    threads-sockets         4 groups         1.00 (  0.19)  +11.92 (  0.24)
    threads-sockets         8 groups         1.00 (  0.08)   +4.31 (  0.11)
    
    Each tbench test is a:
    tbench -t 100 $job 127.0.0.1
    tbench.throughput
    ======
    case                    load            baseline(std%)  compare%( std%)
    loopback                28 threads       1.00 (  0.06)   -0.14 (  0.09)
    loopback                56 threads       1.00 (  0.03)   -0.04 (  0.17)
    loopback                84 threads       1.00 (  0.05)   +0.36 (  0.13)
    loopback                112 threads      1.00 (  0.03)   +0.51 (  0.03)
    loopback                140 threads      1.00 (  0.02)   -1.67 (  0.19)
    loopback                168 threads      1.00 (  0.38)   +1.27 (  0.27)
    loopback                196 threads      1.00 (  0.11)   +1.34 (  0.17)
    loopback                224 threads      1.00 (  0.11)   +1.67 (  0.22)
    
    Each schbench test is a:
    schbench -m $job -t 28 -r 100 -s 30000 -c 30000
    schbench.latency_90%_us
    ========
    case                    load            baseline(std%)  compare%( std%)
    normal                  1 mthread        1.00 ( 31.22)   -7.36 ( 20.25)*
    normal                  2 mthreads       1.00 (  2.45)   -0.48 (  1.79)
    normal                  4 mthreads       1.00 (  1.69)   +0.45 (  0.64)
    normal                  8 mthreads       1.00 (  5.47)   +9.81 ( 14.28)
    
    *Consider the Standard Deviation, this -7.36% regression might not be valid.
    
    Also, a OLTP workload with a commercial RDBMS has been tested, and there
    is no significant change.
    
    There were concerns that unbalanced tasks among CPUs would cause problems.
    For example, suppose the LLC domain is composed of 8 CPUs, and 7 tasks are
    bound to CPU0~CPU6, while CPU7 is idle:
    
              CPU0    CPU1    CPU2    CPU3    CPU4    CPU5    CPU6    CPU7
    util_avg  1024    1024    1024    1024    1024    1024    1024    0
    
    Since the util_avg ratio is 87.5%( = 7/8 ), which is higher than 85%,
    select_idle_cpu() will not scan, thus CPU7 is undetected during scan.
    But according to Mel, it is unlikely the CPU7 will be idle all the time
    because CPU7 could pull some tasks via CPU_NEWLY_IDLE.
    
    lkp(kernel test robot) has reported a regression on stress-ng.sock on a
    very busy system. According to the sched_debug statistics, it might be caused
    by SIS_UTIL terminates the scan and chooses a previous CPU earlier, and this
    might introduce more context switch, especially involuntary preemption, which
    impacts a busy stress-ng. This regression has shown that, not all benchmarks
    in every scenario benefit from idle CPU scan limit, and it needs further
    investigation.
    
    Besides, there is slight regression in hackbench's 16 groups case when the
    LLC domain has 16 CPUs. Prateek mentioned that we should scan aggressively
    in an LLC domain with 16 CPUs. Because the cost to search for an idle one
    among 16 CPUs is negligible. The current patch aims to propose a generic
    solution and only considers the util_avg. Something like the below could
    be applied on top of the current patch to fulfill the requirement:
    
            if (llc_weight <= 16)
                    nr_scan = nr_scan * 32 / llc_weight;
    
    For LLC domain with 16 CPUs, the nr_scan will be expanded to 2 times large.
    The smaller the CPU number this LLC domain has, the larger nr_scan will be
    expanded. This needs further investigation.
    
    There is also ongoing work[2] from Abel to filter out the busy CPUs during
    wakeup, to further speed up the idle CPU scan. And it could be a following-up
    optimization on top of this change.
    
    Suggested-by: Tim Chen <tim.c.chen@intel.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Yicong Yang <yangyicong@hisilicon.com>
    Tested-by: Mohini Narkhede <mohini.narkhede@intel.com>
    Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Link: https://lore.kernel.org/r/20220612163428.849378-1-yu.c.chen@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched: Fix the check of nr_running at queue wakelist [+ + +]
Author: Tianchen Ding <dtcccc@linux.alibaba.com>
Date:   Thu Jun 9 07:34:11 2022 +0800

    sched: Fix the check of nr_running at queue wakelist
    
    [ Upstream commit 28156108fecb1f808b21d216e8ea8f0d205a530c ]
    
    The commit 2ebb17717550 ("sched/core: Offload wakee task activation if it
    the wakee is descheduling") checked rq->nr_running <= 1 to avoid task
    stacking when WF_ON_CPU.
    
    Per the ordering of writes to p->on_rq and p->on_cpu, observing p->on_cpu
    (WF_ON_CPU) in ttwu_queue_cond() implies !p->on_rq, IOW p has gone through
    the deactivate_task() in __schedule(), thus p has been accounted out of
    rq->nr_running. As such, the task being the only runnable task on the rq
    implies reading rq->nr_running == 0 at that point.
    
    The benchmark result is in [1].
    
    [1] https://lore.kernel.org/all/e34de686-4e85-bde1-9f3c-9bbc86b38627@linux.alibaba.com/
    
    Suggested-by: Valentin Schneider <vschneid@redhat.com>
    Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Link: https://lore.kernel.org/r/20220608233412.327341-2-dtcccc@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched: Remove the limitation of WF_ON_CPU on wakelist if wakee cpu is idle [+ + +]
Author: Tianchen Ding <dtcccc@linux.alibaba.com>
Date:   Thu Jun 9 07:34:12 2022 +0800

    sched: Remove the limitation of WF_ON_CPU on wakelist if wakee cpu is idle
    
    [ Upstream commit f3dd3f674555bd9455c5ae7fafce0696bd9931b3 ]
    
    Wakelist can help avoid cache bouncing and offload the overhead of waker
    cpu. So far, using wakelist within the same llc only happens on
    WF_ON_CPU, and this limitation could be removed to further improve
    wakeup performance.
    
    The commit 518cd6234178 ("sched: Only queue remote wakeups when
    crossing cache boundaries") disabled queuing tasks on wakelist when
    the cpus share llc. This is because, at that time, the scheduler must
    send IPIs to do ttwu_queue_wakelist. Nowadays, ttwu_queue_wakelist also
    supports TIF_POLLING, so this is not a problem now when the wakee cpu is
    in idle polling.
    
    Benefits:
      Queuing the task on idle cpu can help improving performance on waker cpu
      and utilization on wakee cpu, and further improve locality because
      the wakee cpu can handle its own rq. This patch helps improving rt on
      our real java workloads where wakeup happens frequently.
    
      Consider the normal condition (CPU0 and CPU1 share same llc)
      Before this patch:
    
             CPU0                                       CPU1
    
        select_task_rq()                                idle
        rq_lock(CPU1->rq)
        enqueue_task(CPU1->rq)
        notify CPU1 (by sending IPI or CPU1 polling)
    
                                                        resched()
    
      After this patch:
    
             CPU0                                       CPU1
    
        select_task_rq()                                idle
        add to wakelist of CPU1
        notify CPU1 (by sending IPI or CPU1 polling)
    
                                                        rq_lock(CPU1->rq)
                                                        enqueue_task(CPU1->rq)
                                                        resched()
    
      We see CPU0 can finish its work earlier. It only needs to put task to
      wakelist and return.
      While CPU1 is idle, so let itself handle its own runqueue data.
    
    This patch brings no difference about IPI.
      This patch only takes effect when the wakee cpu is:
      1) idle polling
      2) idle not polling
    
      For 1), there will be no IPI with or without this patch.
    
      For 2), there will always be an IPI before or after this patch.
      Before this patch: waker cpu will enqueue task and check preempt. Since
      "idle" will be sure to be preempted, waker cpu must send a resched IPI.
      After this patch: waker cpu will put the task to the wakelist of wakee
      cpu, and send an IPI.
    
    Benchmark:
    We've tested schbench, unixbench, and hachbench on both x86 and arm64.
    
    On x86 (Intel Xeon Platinum 8269CY):
      schbench -m 2 -t 8
    
        Latency percentiles (usec)              before        after
            50.0000th:                             8            6
            75.0000th:                            10            7
            90.0000th:                            11            8
            95.0000th:                            12            8
            *99.0000th:                           13           10
            99.5000th:                            15           11
            99.9000th:                            18           14
    
      Unixbench with full threads (104)
                                                before        after
        Dhrystone 2 using register variables  3011862938    3009935994  -0.06%
        Double-Precision Whetstone              617119.3      617298.5   0.03%
        Execl Throughput                         27667.3       27627.3  -0.14%
        File Copy 1024 bufsize 2000 maxblocks   785871.4      784906.2  -0.12%
        File Copy 256 bufsize 500 maxblocks     210113.6      212635.4   1.20%
        File Copy 4096 bufsize 8000 maxblocks  2328862.2     2320529.1  -0.36%
        Pipe Throughput                      145535622.8   145323033.2  -0.15%
        Pipe-based Context Switching           3221686.4     3583975.4  11.25%
        Process Creation                        101347.1      103345.4   1.97%
        Shell Scripts (1 concurrent)            120193.5      123977.8   3.15%
        Shell Scripts (8 concurrent)             17233.4       17138.4  -0.55%
        System Call Overhead                   5300604.8     5312213.6   0.22%
    
      hackbench -g 1 -l 100000
                                                before        after
        Time                                     3.246        2.251
    
    On arm64 (Ampere Altra):
      schbench -m 2 -t 8
    
        Latency percentiles (usec)              before        after
            50.0000th:                            14           10
            75.0000th:                            19           14
            90.0000th:                            22           16
            95.0000th:                            23           16
            *99.0000th:                           24           17
            99.5000th:                            24           17
            99.9000th:                            28           25
    
      Unixbench with full threads (80)
                                                before        after
        Dhrystone 2 using register variables  3536194249    3537019613   0.02%
        Double-Precision Whetstone              629383.6      629431.6   0.01%
        Execl Throughput                         65920.5       65846.2  -0.11%
        File Copy 1024 bufsize 2000 maxblocks  1063722.8     1064026.8   0.03%
        File Copy 256 bufsize 500 maxblocks     322684.5      318724.5  -1.23%
        File Copy 4096 bufsize 8000 maxblocks  2348285.3     2328804.8  -0.83%
        Pipe Throughput                      133542875.3   131619389.8  -1.44%
        Pipe-based Context Switching           3215356.1     3576945.1  11.25%
        Process Creation                        108520.5      120184.6  10.75%
        Shell Scripts (1 concurrent)            122636.3        121888  -0.61%
        Shell Scripts (8 concurrent)             17462.1       17381.4  -0.46%
        System Call Overhead                   4429998.9     4435006.7   0.11%
    
      hackbench -g 1 -l 100000
                                                before        after
        Time                                     4.217        2.916
    
    Our patch has improvement on schbench, hackbench
    and Pipe-based Context Switching of unixbench
    when there exists idle cpus,
    and no obvious regression on other tests of unixbench.
    This can help improve rt in scenes where wakeup happens frequently.
    
    Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Link: https://lore.kernel.org/r/20220608233412.327341-3-dtcccc@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/faddr2line: Fix vmlinux detection on arm64 [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Thu Jul 21 11:01:23 2022 -0700

    scripts/faddr2line: Fix vmlinux detection on arm64
    
    [ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ]
    
    Since commit dcea997beed6 ("faddr2line: Fix overlapping text section
    failures, the sequel"), faddr2line is completely broken on arm64.
    
    For some reason, on arm64, the vmlinux ELF object file type is ET_DYN
    rather than ET_EXEC.  Check for both when determining whether the object
    is vmlinux.
    
    Modules and vmlinux.o have type ET_REL on all arches.
    
    Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel")
    Reported-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: John Garry <john.garry@huawei.com>
    Link: https://lore.kernel.org/r/dad1999737471b06d6188ce4cdb11329aa41682c.1658426357.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/gdb: fix 'lx-dmesg' on 32 bits arch [+ + +]
Author: Antonio Borneo <antonio.borneo@foss.st.com>
Date:   Tue Jul 19 14:28:31 2022 +0200

    scripts/gdb: fix 'lx-dmesg' on 32 bits arch
    
    [ Upstream commit e3c8d33e0d62175c31ca7ab7ab01b18f0b6318d3 ]
    
    The type atomic_long_t can have size 4 or 8 bytes, depending on
    CONFIG_64BIT; it's only content, the field 'counter', is either an
    int or a s64 value.
    
    Current code incorrectly uses the fixed size utils.read_u64() to
    read the field 'counter' inside atomic_long_t.
    
    On 32 bits architectures reading the last element 'tail_id' of the
    struct prb_desc_ring:
            struct prb_desc_ring {
                    ...
                    atomic_long_t tail_id;
            };
    causes the utils.read_u64() to access outside the boundary of the
    struct and the gdb command 'lx-dmesg' exits with error:
            Python Exception <class 'IndexError'>: index out of range
            Error occurred in Python: index out of range
    
    Query the really used atomic_long_t counter type size.
    
    Link: https://lore.kernel.org/r/20220617143758.137307-1-antonio.borneo@foss.st.com
    Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer")
    Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
    [pmladek@suse.com: Query the really used atomic_long_t counter type size]
    Tested-by: Antonio Borneo <antonio.borneo@foss.st.com>
    Reviewed-by: John Ogness <john.ogness@linutronix.de>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20220719122831.19890-1-pmladek@suse.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scripts/gdb: lx-dmesg: read records individually [+ + +]
Author: John Ogness <john.ogness@linutronix.de>
Date:   Wed Dec 15 16:16:22 2021 +0106

    scripts/gdb: lx-dmesg: read records individually
    
    [ Upstream commit deaee2704a157dfcca77301ddaa10c62a9840952 ]
    
    For the gdb command lx-dmesg, the entire descriptor, info, and text
    data regions are read into memory before printing any records. For
    large kernel log buffers, this not only causes a huge delay before
    seeing any records, but it may also lead to python errors of too
    much memory allocation.
    
    Rather than reading in all these regions in advance, read them as
    needed and only read the regions for the particular record that is
    being printed.
    
    The gdb macro "dmesg" in Documentation/admin-guide/kdump/gdbmacros.txt
    already prints out the kernel log buffer like this.
    
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/874k79c3a9.fsf@jogness.linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: hisi_sas: Use managed PCI functions [+ + +]
Author: Xiang Chen <chenxiang66@hisilicon.com>
Date:   Tue Aug 24 18:00:56 2021 +0800

    scsi: hisi_sas: Use managed PCI functions
    
    [ Upstream commit 4f6094f1663e2ed26a940f1842cdaa15c1dd649a ]
    
    Use managed PCI functions such as pcim_enable_device() and
    pcim_iomap_regions() to simplify exception handling code.
    
    Link: https://lore.kernel.org/r/1629799260-120116-2-git-send-email-john.garry@huawei.com
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Add helper to remove a session from the kernel [+ + +]
Author: Mike Christie <michael.christie@oracle.com>
Date:   Thu Jun 16 17:27:36 2022 -0500

    scsi: iscsi: Add helper to remove a session from the kernel
    
    [ Upstream commit bb42856bfd54fda1cbc7c470fcf5db1596938f4f ]
    
    During qedi shutdown we need to stop the iSCSI layer from sending new nops
    as pings and from responding to target ones and make sure there is no
    running connection cleanups. Commit d1f2ce77638d ("scsi: qedi: Fix host
    removal with running sessions") converted the driver to use the libicsi
    helper to drive session removal, so the above issues could be handled. The
    problem is that during system shutdown iscsid will not be running so when
    we try to remove the root session we will hang waiting for userspace to
    reply.
    
    Add a helper that will drive the destruction of sessions like these during
    system shutdown.
    
    Link: https://lore.kernel.org/r/20220616222738.5722-5-michael.christie@oracle.com
    Tested-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Allow iscsi_if_stop_conn() to be called from kernel [+ + +]
Author: Mike Christie <michael.christie@oracle.com>
Date:   Thu Jun 16 17:27:34 2022 -0500

    scsi: iscsi: Allow iscsi_if_stop_conn() to be called from kernel
    
    [ Upstream commit 3328333b47f4163504267440ec0a36087a407a5f ]
    
    iscsi_if_stop_conn() is only called from the userspace interface but in a
    subsequent commit we will want to call it from the kernel interface to
    allow drivers like qedi to remove sessions from inside the kernel during
    shutdown. This removes the iscsi_uevent code from iscsi_if_stop_conn() so we
    can call it in a new helper.
    
    Link: https://lore.kernel.org/r/20220616222738.5722-3-michael.christie@oracle.com
    Tested-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Fix session removal on shutdown [+ + +]
Author: Mike Christie <michael.christie@oracle.com>
Date:   Thu Jun 16 17:27:38 2022 -0500

    scsi: iscsi: Fix session removal on shutdown
    
    [ Upstream commit 31500e902759322ba3c64b60dabae2704e738df8 ]
    
    When the system is shutting down, iscsid is not running so we will not get
    a response to the ISCSI_ERR_INVALID_HOST error event. The system shutdown
    will then hang waiting on userspace to remove the session.
    
    This has libiscsi force the destruction of the session from the kernel when
    iscsi_host_remove() is called from a driver's shutdown callout.
    
    This fixes a regression added in qedi boot with commit d1f2ce77638d ("scsi:
    qedi: Fix host removal with running sessions") which made qedi use the
    common session removal function that waits on userspace instead of rolling
    its own kernel based removal.
    
    Link: https://lore.kernel.org/r/20220616222738.5722-7-michael.christie@oracle.com
    Fixes: d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions")
    Tested-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Reviewed-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Fix EEH support for NVMe I/O [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Sep 10 16:31:54 2021 -0700

    scsi: lpfc: Fix EEH support for NVMe I/O
    
    [ Upstream commit 25ac2c970be32993f1dff607f8354f3c053d42bc ]
    
    Injecting errors on the PCI slot while the driver is handling NVMe I/O will
    cause crashes and hangs.
    
    There are several rather difficult scenarios occurring. The main issue is
    that the adapter can report a PCI error before or simultaneously to the PCI
    subsystem reporting the error. Both paths have different entry points and
    currently there is no interlock between them. Thus multiple teardown paths
    are competing and all heck breaks loose.
    
    Complicating things is the NVMs path. To a large degree, I/O was able to be
    shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
    similar call. At best, it works on a per-controller basis, but even at the
    controller level, it's a controller "reset" call. All of which means I/O is
    still flowing on different CPUs with reset paths expecting hw access
    (mailbox commands) to execute properly.
    
    The following modifications are made:
    
     - A new flag is set in PCI error entrypoints so the driver can track being
       called by that path.
    
     - An interlock is added in the SLI hw error path and the PCI error path
       such that only one of the paths proceeds with the teardown logic.
    
     - RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
       cmds in cases of hw error.
    
     - If entering the SLI port re-init calls, a case where SLI error teardown
       was quick and beat the PCI calls now reporting error, check whether the
       SLI port is still live on the PCI bus.
    
     - In the PCI reset code to bring the adapter back, recheck the IRQ
       settings. Different checks for SLI3 vs SLI4.
    
     - In I/O completions, that may be called as part of the cleanup or
       underway just before the hw error, check the state of the adapter.  If
       in error, shortcut handling that would expect further adapter
       completions as the hw error won't be sending them.
    
     - In routines waiting on I/O completions, which may have been in progress
       prior to the hw error, detect the device is being torn down and abort
       from their waits and just give up. This points to a larger issue in the
       driver on ref-counting for data structures, as it doesn't have
       ref-counting on q and port structures. We'll do this fix for now as it
       would be a major rework to be done differently.
    
     - Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
       failed back due to hw error.
    
     - In I/O buf allocation, done at the start of new I/Os, check hw state and
       fail if hw error.
    
    Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Fix element offset in __lpfc_sli_release_iocbq_s4() [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu May 5 20:55:08 2022 -0700

    scsi: lpfc: Fix element offset in __lpfc_sli_release_iocbq_s4()
    
    commit 84c6f99e39074d45f75986e42ca28e27c140fd0d upstream.
    
    The prior commit that moved from iocb elements to explicit wqe elements
    missed a name change.
    
    Correct __lpfc_sli_release_iocbq_s4() to reference wqe rather than iocb.
    
    Link: https://lore.kernel.org/r/20220506035519.50908-2-jsmart2021@gmail.com
    Fixes: a680a9298e7b ("scsi: lpfc: SLI path split: Refactor lpfc_iocbq")
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: Fix locking for lpfc_sli_iocbq_lookup() [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Wed Mar 23 13:55:45 2022 -0700

    scsi: lpfc: Fix locking for lpfc_sli_iocbq_lookup()
    
    commit c26bd6602e1d348bfa754dc55e5608c922dd2801 upstream.
    
    The rules changed for lpfc_sli_iocbq_lookup() vs locking. Prior, the
    routine properly took out the lock. In newly refactored code, the locks
    must be held when calling the routine.
    
    Fix lpfc_sli_process_sol_iocb() to take the locks before calling the
    routine.
    
    Fix lpfc_sli_handle_fast_ring_event() to not release the locks to call the
    routine.
    
    Link: https://lore.kernel.org/r/20220323205545.81814-3-jsmart2021@gmail.com
    Fixes: 1b64aa9eae28 ("scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4")
    Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: Remove extra atomic_inc on cmd_pending in queuecommand after VMID [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jul 1 14:14:17 2022 -0700

    scsi: lpfc: Remove extra atomic_inc on cmd_pending in queuecommand after VMID
    
    [ Upstream commit 0948a9c5386095baae4012190a6b65aba684a907 ]
    
    VMID introduced an extra increment of cmd_pending, causing double-counting
    of the I/O. The normal increment ios performed in lpfc_get_scsi_buf.
    
    Link: https://lore.kernel.org/r/20220701211425.2708-5-jsmart2021@gmail.com
    Fixes: 33c79741deaf ("scsi: lpfc: vmid: Introduce VMID in I/O path")
    Cc: <stable@vger.kernel.org> # v5.14+
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Resolve some cleanup issues following SLI path refactoring [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:23 2022 -0700

    scsi: lpfc: Resolve some cleanup issues following SLI path refactoring
    
    commit e27f05147bff21408c1b8410ad8e90cd286e7952 upstream.
    
    Following refactoring and consolidation in SLI processing, fix up some
    minor issues related to SLI path:
    
     - Correct the setting of LPFC_EXCHANGE_BUSY flag in response IOCB.
    
     - Fix some typographical errors.
    
     - Fix duplicate log messages.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-4-jsmart2021@gmail.com
    Fixes: 1b64aa9eae28 ("scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4")
    Cc: <stable@vger.kernel.org> # v5.18
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4 [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Feb 24 18:22:53 2022 -0800

    scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4
    
    [ Upstream commit 1b64aa9eae28ac598a03ed3d62a63ac5e5b295fc ]
    
    Convert the SLI4 fast and slow paths to use native SLI4 wqe constructs
    instead of iocb SLI3-isms.
    
    Includes the following:
    
     - Create simple get_xxx and set_xxx routines to wrapper access to common
       elements in both SLI3 and SLI4 commands - allowing calling routines to
       avoid sli-rev-specific structures to access the elements.
    
     - using the wqe in the job structure as the primary element
    
     - use defines from SLI-4, not SLI-3
    
     - Removal of iocb to wqe conversion from fast and slow path
    
     - Add below routines to handle fast path
            lpfc_prep_embed_io - prepares the wqe for fast path
            lpfc_wqe_bpl2sgl   - manages bpl to sgl conversion
            lpfc_sli_wqe2iocb  - converts a WQE to IOCB for SLI-3 path
    
     - Add lpfc_sli3_iocb2wcqecmpl in completion path to convert an SLI-3
       iocb completion to wcqe completion
    
     - Refactor some of the code that works on both revs for clarity
    
    Link: https://lore.kernel.org/r/20220225022308.16486-3-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: SLI path split: Refactor lpfc_iocbq [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Feb 24 18:22:52 2022 -0800

    scsi: lpfc: SLI path split: Refactor lpfc_iocbq
    
    [ Upstream commit a680a9298e7b4ff344aca3456177356b276e5038 ]
    
    Currently, SLI3 and SLI4 data paths use the same lpfc_iocbq structure.
    This is a "common" structure but many of the components refer to sli-rev
    specific entities which can lead the developer astray as to what they
    actually mean, should be set to, or when they should be used.
    
    This first patch prepares the lpfc_iocbq structure so that elements common
    to both SLI3 and SLI4 data paths are more appropriately named, making it
    clear they apply generically.
    
    Fieldnames based on 'iocb' (sli3) or 'wqe' (sli4) which are actually
    generic to the paths are renamed to 'cmd':
    
     - iocb_flag is renamed to cmd_flag
    
     - lpfc_vmid_iocb_tag is renamed to lpfc_vmid_tag
    
     - fabric_iocb_cmpl is renamed to fabric_cmd_cmpl
    
     - wait_iocb_cmpl is renamed to wait_cmd_cmpl
    
     - iocb_cmpl and wqe_cmpl are combined and renamed to cmd_cmpl
    
     - rsvd2 member is renamed to num_bdes due to pre-existing usage
    
    The structure name itself will retain the iocb reference as changing to a
    more relevant "job" or "cmd" title induces many hundreds of line changes
    for only a name change.
    
    lpfc_post_buffer is also renamed to lpfc_sli3_post_buffer to indicate use
    in the SLI3 path only.
    
    Link: https://lore.kernel.org/r/20220225022308.16486-2-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: SLI path split: Refactor SCSI paths [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Feb 24 18:23:04 2022 -0800

    scsi: lpfc: SLI path split: Refactor SCSI paths
    
    [ Upstream commit 3512ac0942938d6977e7999ee69765d948d2faf1 ]
    
    This patch refactors the SCSI paths to use SLI-4 as the primary interface.
    
     - Conversion away from using SLI-3 iocb structures to set/access fields in
       common routines. Use the new generic get/set routines that were added.
       This move changes code from indirect structure references to using local
       variables with the generic routines.
    
     - Refactor routines when setting non-generic fields, to have both SLI3 and
       SLI4 specific sections. This replaces the set-as-SLI3 then translate to
       SLI4 behavior of the past.
    
    Link: https://lore.kernel.org/r/20220225022308.16486-14-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Check correct variable in qla24xx_async_gffid() [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 22 09:21:55 2022 +0300

    scsi: qla2xxx: Check correct variable in qla24xx_async_gffid()
    
    [ Upstream commit 7c33e477bd883f79cccec418980cb8f7f2d50347 ]
    
    There is a copy and paste bug here.  It should check ".rsp" instead of
    ".req".  The error message is copy and pasted as well so update that too.
    
    Link: https://lore.kernel.org/r/YrK1A/t3L6HKnswO@kili
    Fixes: 9c40c36e75ff ("scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Add retry for ELS passthrough [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:23 2022 -0700

    scsi: qla2xxx: edif: Add retry for ELS passthrough
    
    [ Upstream commit 0b3f3143d473b489a7aa0779c43bcdb344bd3014 ]
    
    Relating to EDIF, when sending IKE message, updating key or deleting key,
    driver can encounter IOCB queue full. Add additional retries to reduce
    higher level recovery.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-8-njavali@marvell.com
    Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix inconsistent check of db_flags [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:10 2021 -0700

    scsi: qla2xxx: edif: Fix inconsistent check of db_flags
    
    [ Upstream commit 36f468bfe98c7de7916ab3391ee5dd6fd2549979 ]
    
    db_flags field is a bit field. Replace value check with bit flag check.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-12-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix n2n discovery issue with secure target [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:25 2022 -0700

    scsi: qla2xxx: edif: Fix n2n discovery issue with secure target
    
    [ Upstream commit 789d54a4178634850e441f60c0326124138e7269 ]
    
    User failed to see disk via n2n topology. Driver used up all login retries
    before authentication application started. When authentication application
    started, driver did not have enough login retries to connect securely. On
    app_start, driver will reset the login retry attempt count.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-10-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix n2n login retry for secure device [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:26 2022 -0700

    scsi: qla2xxx: edif: Fix n2n login retry for secure device
    
    [ Upstream commit aec55325ddec975216119da000092cb8664a3399 ]
    
    After initiator has burned up all login retries, target authentication
    application begins to run. This triggers a link bounce on target side.
    Initiator will attempt another login. Due to N2N, the PRLI [nvme | fcp] can
    fail because of the mode mismatch with target. This patch add a few more
    login retries to revive the connection.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-11-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix no login after app start [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:43 2022 -0700

    scsi: qla2xxx: edif: Fix no login after app start
    
    [ Upstream commit 24c796098f5395477f7f7ebf8e24f3f08a139f71 ]
    
    The scenario is this: User loaded driver but has not started authentication
    app. All sessions to secure device will exhaust all login attempts, fail,
    and in stay in deleted state. Then some time later the app is started. The
    driver will replenish the login retry count, trigger delete to prepare for
    secure login. After deletion, relogin is triggered.
    
    For the session that is already deleted, the delete trigger is a no-op. If
    none of the sessions trigger a relogin, no progress is made.
    
    Add a relogin trigger.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-5-njavali@marvell.com
    Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix no logout on delete for N2N [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:46 2022 -0700

    scsi: qla2xxx: edif: Fix no logout on delete for N2N
    
    [ Upstream commit ec538eb838f334453b10e7e9b260f0c358018a37 ]
    
    The driver failed to send implicit logout on session delete. For edif, this
    failed to flush any lingering SA index in FW.
    
    Set a flag to turn on implicit logout early in the session recovery to make
    sure the logout will go out in case of error.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-8-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix potential stuck session in sa update [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:21 2022 -0700

    scsi: qla2xxx: edif: Fix potential stuck session in sa update
    
    [ Upstream commit e0fb8ce2bb9e52c846e54ad2c58b5b7beb13eb09 ]
    
    When a thread is in the process of reestablish a session, a flag is set to
    prevent multiple threads/triggers from doing the same task. This flag was
    left on, and any attempt to relogin was locked out. Clear this flag if the
    attempt has failed.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-6-njavali@marvell.com
    Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Fix session thrash [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:45 2022 -0700

    scsi: qla2xxx: edif: Fix session thrash
    
    [ Upstream commit a8fdfb0b39c2b31722c70bdf2272b949d5af4b7b ]
    
    Current code prematurely sends out PRLI before authentication application
    has given the OK to do so. This causes PRLI failure and session teardown.
    
    Prevents PRLI from going out before authentication app gives the OK.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-7-njavali@marvell.com
    Fixes: 91f6f5fbe87b ("scsi: qla2xxx: edif: Reduce connection thrash")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Reduce connection thrash [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:08 2021 -0700

    scsi: qla2xxx: edif: Reduce connection thrash
    
    [ Upstream commit 91f6f5fbe87ba834133fcc61d34881cb8ec9e518 ]
    
    On ipsec start by remote port, target port may use RSCN to trigger
    initiator to relogin. If driver is already in the process of a relogin,
    then ignore the RSCN and allow the current relogin to continue. This
    reduces thrashing of the connection.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-10-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Reduce disruption due to multiple app start [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:42 2022 -0700

    scsi: qla2xxx: edif: Reduce disruption due to multiple app start
    
    [ Upstream commit 0dbfce5255fe8d069a1a3b712a25b263264cfa58 ]
    
    Multiple app start can trigger a session bounce. Make driver skip over
    session teardown if app start is seen more than once.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-4-njavali@marvell.com
    Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:17 2022 -0700

    scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing
    
    [ Upstream commit 9c40c36e75ffd49952cd4ead0672defc4b4dbdf7 ]
    
    This patch uses GFFID switch command to scan whether remote device is
    Target or Initiator mode.  Based on that info, driver will not pass up
    Initiator info to authentication application. This helps reduce unnecessary
    stress for authentication application to deal with unused connections.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-2-njavali@marvell.com
    Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Send LOGO for unexpected IKE message [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:41 2022 -0700

    scsi: qla2xxx: edif: Send LOGO for unexpected IKE message
    
    [ Upstream commit 2b659ed67a12f39f56d8dcad9b5d5a74d67c01b3 ]
    
    If the session is down and the local port continues to receive AUTH ELS
    messages, the driver needs to send back LOGO so that the remote device
    knows to tear down its session. Terminate and clean up the AUTH ELS
    exchange followed by a passthrough LOGO.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-3-njavali@marvell.com
    Fixes: 225479296c4f ("scsi: qla2xxx: edif: Reject AUTH ELS on session down")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Synchronize NPIV deletion with authentication application [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Mon Jun 6 21:46:22 2022 -0700

    scsi: qla2xxx: edif: Synchronize NPIV deletion with authentication application
    
    [ Upstream commit cf79716e6636400ae38c37bc8a652b1e522abbba ]
    
    Notify authentication application of a NPIV deletion event is about to
    occur. This allows app to perform cleanup.
    
    Link: https://lore.kernel.org/r/20220607044627.19563-7-njavali@marvell.com
    Fixes: 9efea843a906 ("scsi: qla2xxx: edif: Add detection of secure device")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: edif: Tear down session if keys have been removed [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 8 04:58:44 2022 -0700

    scsi: qla2xxx: edif: Tear down session if keys have been removed
    
    [ Upstream commit d7e2e4a68fc047a025afcd200e6b7e1fbc8b1999 ]
    
    If all keys for a session have been deleted, trigger a session teardown.
    
    Link: https://lore.kernel.org/r/20220608115849.16693-6-njavali@marvell.com
    Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Jun 15 22:35:02 2022 -0700

    scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts
    
    commit c39587bc0abaf16593f7abcdf8aeec3c038c7d52 upstream.
    
    Ensure SRB is returned during I/O timeout error escalation. If that is not
    possible fail the escalation path.
    
    Following crash stack was seen:
    
    BUG: unable to handle kernel paging request at 0000002f56aa90f8
    IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]
    Call Trace:
     ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]
     ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]
     ? dma_pool_alloc+0x1d6/0x210
     ? mempool_alloc+0x54/0x130
     ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]
     ? qla_do_work+0x2d/0x40 [qla2xxx]
     ? process_one_work+0x14c/0x390
    
    Link: https://lore.kernel.org/r/20220616053508.27186-6-njavali@marvell.com
    Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix discovery issues in FC-AL topology [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Tue Jul 12 22:20:42 2022 -0700

    scsi: qla2xxx: Fix discovery issues in FC-AL topology
    
    commit 47ccb113cead905bdc236571bf8ac6fed90321b3 upstream.
    
    A direct attach tape device, when gets swapped with another, was not
    discovered. Fix this by looking at loop map and reinitialize link if there
    are devices present.
    
    Link: https://lore.kernel.org/linux-scsi/baef87c3-5dad-3b47-44c1-6914bfc90108@cybernetics.com/
    Link: https://lore.kernel.org/r/20220713052045.10683-8-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reported-by: Tony Battersby <tonyb@cybernetics.com>
    Tested-by: Tony Battersby <tonyb@cybernetics.com>
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix erroneous mailbox timeout after PCI error injection [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 15 22:35:07 2022 -0700

    scsi: qla2xxx: Fix erroneous mailbox timeout after PCI error injection
    
    commit f260694e6463b63ae550aad25ddefe94cb1904da upstream.
    
    Clear wait for mailbox interrupt flag to prevent stale mailbox:
    
    Feb 22 05:22:56 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-500a:4: LOOP UP detected (16 Gbps).
    Feb 22 05:22:59 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-d04c:4: MBX Command timeout for cmd 69, ...
    
    To fix the issue, driver needs to clear the MBX_INTR_WAIT flag on purging
    the mailbox. When the stale mailbox completion does arrive, it will be
    dropped.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-11-njavali@marvell.com
    Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request")
    Cc: Naresh Bannoth <nbannoth@in.ibm.com>
    Cc: Kyle Mahlkuch <Kyle.Mahlkuch@ibm.com>
    Cc: stable@vger.kernel.org
    Reported-by: Naresh Bannoth <nbannoth@in.ibm.com>
    Tested-by: Naresh Bannoth <nbannoth@in.ibm.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix excessive I/O error messages by default [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Jun 15 22:34:58 2022 -0700

    scsi: qla2xxx: Fix excessive I/O error messages by default
    
    commit bff4873c709085e09d0ffae0c25b8e65256e3205 upstream.
    
    Disable printing I/O error messages by default.  The messages will be
    printed only when logging was enabled.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-2-njavali@marvell.com
    Fixes: 8e2d81c6b5be ("scsi: qla2xxx: Fix excessive messages during device logout")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix imbalance vha->vref_count [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Jul 12 22:20:41 2022 -0700

    scsi: qla2xxx: Fix imbalance vha->vref_count
    
    commit 63fa7f2644b4b48e1913af33092c044bf48e9321 upstream.
    
    vref_count took an extra decrement in the task management path.  Add an
    extra ref count to compensate the imbalance.
    
    Link: https://lore.kernel.org/r/20220713052045.10683-7-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix incorrect display of max frame size [+ + +]
Author: Bikash Hazarika <bhazarika@marvell.com>
Date:   Tue Jul 12 22:20:37 2022 -0700

    scsi: qla2xxx: Fix incorrect display of max frame size
    
    commit cf3b4fb655796674e605268bd4bfb47a47c8bce6 upstream.
    
    Replace display field with the correct field.
    
    Link: https://lore.kernel.org/r/20220713052045.10683-3-njavali@marvell.com
    Fixes: 8777e4314d39 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Bikash Hazarika <bhazarika@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix losing FCP-2 targets during port perturbation tests [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Jun 15 22:35:03 2022 -0700

    scsi: qla2xxx: Fix losing FCP-2 targets during port perturbation tests
    
    commit 58d1c124cd79ea686b512043c5bd515590b2ed95 upstream.
    
    When a mix of FCP-2 (tape) and non-FCP-2 targets are present, FCP-2 target
    state was incorrectly transitioned when both of the targets were gone. Fix
    this by ignoring state transition for FCP-2 targets.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-7-njavali@marvell.com
    Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix losing FCP-2 targets on long port disable with I/Os [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Jun 15 22:35:06 2022 -0700

    scsi: qla2xxx: Fix losing FCP-2 targets on long port disable with I/Os
    
    commit 2416ccd3815ba1613e10a6da0a24ef21acfe5633 upstream.
    
    FCP-2 devices were not coming back online once they were lost, login
    retries exhausted, and then came back up.  Fix this by accepting RSCN when
    the device is not online.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-10-njavali@marvell.com
    Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix losing target when it reappears during delete [+ + +]
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Jun 15 22:35:04 2022 -0700

    scsi: qla2xxx: Fix losing target when it reappears during delete
    
    commit 118b0c863c8f5629cc5271fc24d72d926e0715d9 upstream.
    
    FC target disappeared during port perturbation tests due to a race that
    tramples target state.  Fix the issue by adding state checks before
    proceeding.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-8-njavali@marvell.com
    Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Turn off multi-queue for 8G adapters [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 15 22:35:01 2022 -0700

    scsi: qla2xxx: Turn off multi-queue for 8G adapters
    
    commit 5304673bdb1635e27555bd636fd5d6956f1cd552 upstream.
    
    For 8G adapters, multi-queue was enabled accidentally. Make sure
    multi-queue is not enabled.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-5-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Wind down adapter after PCIe error [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Jun 15 22:35:00 2022 -0700

    scsi: qla2xxx: Wind down adapter after PCIe error
    
    commit d3117c83ba316b3200d9f2fe900f2b9a5525a25c upstream.
    
    Put adapter into a wind down state if OS does not make any attempt to
    recover the adapter after PCIe error.
    
    Link: https://lore.kernel.org/r/20220616053508.27186-4-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Zero undefined mailbox IN registers [+ + +]
Author: Bikash Hazarika <bhazarika@marvell.com>
Date:   Tue Jul 12 22:20:38 2022 -0700

    scsi: qla2xxx: Zero undefined mailbox IN registers
    
    commit 6c96a3c7d49593ef15805f5e497601c87695abc9 upstream.
    
    While requesting a new mailbox command, driver does not write any data to
    unused registers.  Initialize the unused register value to zero while
    requesting a new mailbox command to prevent stale entry access by firmware.
    
    Link: https://lore.kernel.org/r/20220713052045.10683-4-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Bikash Hazarika <bhazarika@marvell.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: Revert "scsi: qla2xxx: Fix disk failure to rediscover" [+ + +]
Author: Nilesh Javali <njavali@marvell.com>
Date:   Tue Jul 12 22:20:36 2022 -0700

    scsi: Revert "scsi: qla2xxx: Fix disk failure to rediscover"
    
    commit 5bc7b01c513a4a9b4cfe306e8d1720cfcfd3b8a3 upstream.
    
    This fixes the regression of NVMe discovery failure during driver load
    time.
    
    This reverts commit 6a45c8e137d4e2c72eecf1ac7cf64f2fdfcead99.
    
    Link: https://lore.kernel.org/r/20220713052045.10683-2-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: sg: Allow waiting for commands to complete on removed device [+ + +]
Author: Tony Battersby <tonyb@cybernetics.com>
Date:   Mon Jul 11 10:51:32 2022 -0400

    scsi: sg: Allow waiting for commands to complete on removed device
    
    commit 3455607fd7be10b449f5135c00dc306b85dc0d21 upstream.
    
    When a SCSI device is removed while in active use, currently sg will
    immediately return -ENODEV on any attempt to wait for active commands that
    were sent before the removal.  This is problematic for commands that use
    SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel
    when userspace frees or reuses it after getting ENODEV, leading to
    corrupted userspace memory (in the case of READ-type commands) or corrupted
    data being sent to the device (in the case of WRITE-type commands).  This
    has been seen in practice when logging out of a iscsi_tcp session, where
    the iSCSI driver may still be processing commands after the device has been
    marked for removal.
    
    Change the policy to allow userspace to wait for active sg commands even
    when the device is being removed.  Return -ENODEV only when there are no
    more responses to read.
    
    Link: https://lore.kernel.org/r/5ebea46f-fe83-2d0b-233d-d0dcb362dd0a@cybernetics.com
    Cc: <stable@vger.kernel.org>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: smartpqi: Fix DMA direction for RAID requests [+ + +]
Author: Mahesh Rajashekhara <Mahesh.Rajashekhara@microchip.com>
Date:   Fri Jul 8 13:47:36 2022 -0500

    scsi: smartpqi: Fix DMA direction for RAID requests
    
    [ Upstream commit 69695aeaa6621bc49cdd7a8e5a8d1042461e496e ]
    
    Correct a SOP READ and WRITE DMA flags for some requests.
    
    This update corrects DMA direction issues with SCSI commands removed from
    the controller's internal lookup table.
    
    Currently, SCSI READ BLOCK LIMITS (0x5) was removed from the controller
    lookup table and exposed a DMA direction flag issue.
    
    SCSI READ BLOCK LIMITS was recently removed from our controller lookup
    table so the controller uses the respective IU flag field to set the DMA
    data direction. Since the DMA direction is incorrect the FW never completes
    the request causing a hang.
    
    Some SCSI commands which use SCSI READ BLOCK LIMITS
    
          * sg_map
          * mt -f /dev/stX status
    
    After updating controller firmware, users may notice their tape units
    failing. This patch resolves the issue.
    
    Also, the AIO path DMA direction is correct.
    
    The DMA direction flag is a day-one bug with no reported BZ.
    
    Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver")
    Link: https://lore.kernel.org/r/165730605618.177165.9054223644512926624.stgit@brunhilda
    Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
    Reviewed-by: Scott Teel <scott.teel@microchip.com>
    Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
    Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@microchip.com>
    Signed-off-by: Don Brace <don.brace@microchip.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Correct ufshcd_shutdown() flow [+ + +]
Author: Peter Wang <peter.wang@mediatek.com>
Date:   Wed Jul 27 11:05:26 2022 +0800

    scsi: ufs: core: Correct ufshcd_shutdown() flow
    
    commit 00511d2abf5708ad05dd5d1c36adb2468d274698 upstream.
    
    After ufshcd_wl_shutdown() set device power off and link off,
    ufshcd_shutdown() could turn off clock/power. Also remove
    pm_runtime_get_sync.
    
    The reason why it is safe to remove pm_runtime_get_sync() is because:
    
     - ufshcd_wl_shutdown() -> pm_runtime_get_sync() will resume hba->dev too.
    
     - device resume(turn on clk/power) is not required, even if device is in
       RPM_SUSPENDED.
    
    Link: https://lore.kernel.org/r/20220727030526.31022-1-peter.wang@mediatek.com
    Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun")
    Cc: <stable@vger.kernel.org> # 5.15.x
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Peter Wang <peter.wang@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: zfcp: Fix missing auto port scan and thus missing target ports [+ + +]
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Fri Jul 29 18:25:29 2022 +0200

    scsi: zfcp: Fix missing auto port scan and thus missing target ports
    
    commit 4da8c5f76825269f28d6a89fa752934a4bcb6dfa upstream.
    
    Case (1):
      The only waiter on wka_port->completion_wq is zfcp_fc_wka_port_get()
      trying to open a WKA port. As such it should only be woken up by WKA port
      *open* responses, not by WKA port close responses.
    
    Case (2):
      A close WKA port response coming in just after having sent a new open WKA
      port request and before blocking for the open response with wait_event()
      in zfcp_fc_wka_port_get() erroneously renders the wait_event a NOP
      because the close handler overwrites wka_port->status. Hence the
      wait_event condition is erroneously true and it does not enter blocking
      state.
    
    With non-negligible probability, the following time space sequence happens
    depending on timing without this fix:
    
    user process        ERP thread zfcp work queue tasklet system work queue
    ============        ========== =============== ======= =================
    $ echo 1 > online
    zfcp_ccw_set_online
    zfcp_ccw_activate
    zfcp_erp_adapter_reopen
    msleep scan backoff zfcp_erp_strategy
    |                   ...
    |                   zfcp_erp_action_cleanup
    |                   ...
    |                   queue delayed scan_work
    |                   queue ns_up_work
    |                              ns_up_work:
    |                              zfcp_fc_wka_port_get
    |                               open wka request
    |                                              open response
    |                              GSPN FC-GS
    |                              RSPN FC-GS [NPIV-only]
    |                              zfcp_fc_wka_port_put
    |                               (--wka->refcount==0)
    |                               sched delayed wka->work
    |
    ~~~Case (1)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    zfcp_erp_wait
    flush scan_work
    |                                                      wka->work:
    |                                                      wka->status=CLOSING
    |                                                      close wka request
    |                              scan_work:
    |                              zfcp_fc_wka_port_get
    |                               (wka->status==CLOSING)
    |                               wka->status=OPENING
    |                               open wka request
    |                               wait_event
    |                               |              close response
    |                               |              wka->status=OFFLINE
    |                               |              wake_up /*WRONG*/
    ~~~Case (2)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    |                                                      wka->work:
    |                                                      wka->status=CLOSING
    |                                                      close wka request
    zfcp_erp_wait
    flush scan_work
    |                              scan_work:
    |                              zfcp_fc_wka_port_get
    |                               (wka->status==CLOSING)
    |                               wka->status=OPENING
    |                               open wka request
    |                                              close response
    |                                              wka->status=OFFLINE
    |                                              wake_up /*WRONG&NOP*/
    |                               wait_event /*NOP*/
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    |                               (wka->status!=ONLINE)
    |                               return -EIO
    |                              return early
                                                   open response
                                                   wka->status=ONLINE
                                                   wake_up /*NOP*/
    
    So we erroneously end up with no automatic port scan. This is a big problem
    when it happens during boot. The timing is influenced by v3.19 commit
    18f87a67e6d6 ("zfcp: auto port scan resiliency").
    
    Fix it by fully mutually excluding zfcp_fc_wka_port_get() and
    zfcp_fc_wka_port_offline(). For that to work, we make the latter block
    until we got the response for a close WKA port. In order not to penalize
    the system workqueue, we move wka_port->work to our own adapter workqueue.
    Note that before v2.6.30 commit 828bc1212a68 ("[SCSI] zfcp: Set WKA-port to
    offline on adapter deactivation"), zfcp did block in
    zfcp_fc_wka_port_offline() as well, but with a different condition.
    
    While at it, make non-functional cleanups to improve code reading in
    zfcp_fc_wka_port_get(). If we cannot send the WKA port open request, don't
    rely on the subsequent wait_event condition to immediately let this case
    pass without blocking. Also don't want to rely on the additional condition
    handling the refcount to be skipped just to finally return with -EIO.
    
    Link: https://lore.kernel.org/r/20220729162529.1620730-1-maier@linux.ibm.com
    Fixes: 5ab944f97e09 ("[SCSI] zfcp: attach and release SAN nameserver port on demand")
    Cc: <stable@vger.kernel.org> #v2.6.28+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/bpf: fix a test for snprintf() overflow [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jul 19 12:50:32 2022 +0300

    selftests/bpf: fix a test for snprintf() overflow
    
    [ Upstream commit c5d22f4cfe8dfb93f1db0a1e7e2e7ebc41395d98 ]
    
    The snprintf() function returns the number of bytes which *would*
    have been copied if there were space.  In other words, it can be
    > sizeof(pin_path).
    
    Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/YtZ+aD/tZMkgOUw+@kili
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/livepatch: better synchronize test_klp_callbacks_busy [+ + +]
Author: Joe Lawrence <joe.lawrence@redhat.com>
Date:   Thu Jun 2 16:32:33 2022 -0400

    selftests/livepatch: better synchronize test_klp_callbacks_busy
    
    [ Upstream commit 55eb9a6c8bf3e2099863118ef53e02d9f44f85a8 ]
    
    The test_klp_callbacks_busy module conditionally blocks a future
    livepatch transition by busy waiting inside its workqueue function,
    busymod_work_func().  After scheduling this work, a test livepatch is
    loaded, introducing the transition under test.
    
    Both events are marked in the kernel log for later verification, but
    there is no synchronization to ensure that busymod_work_func() logs its
    function entry message before subsequent selftest commands log their own
    messages.  This can lead to a rare test failure due to unexpected
    ordering like:
    
    #  --- expected
    #  +++ result
    #  @@ -1,7 +1,7 @@
    #   % modprobe test_klp_callbacks_busy block_transition=Y
    #   test_klp_callbacks_busy: test_klp_callbacks_busy_init
    #  -test_klp_callbacks_busy: busymod_work_func enter
    #   % modprobe test_klp_callbacks_demo
    #  +test_klp_callbacks_busy: busymod_work_func enter
    #   livepatch: enabling patch 'test_klp_callbacks_demo'
    #   livepatch: 'test_klp_callbacks_demo': initializing patching transition
    #   test_klp_callbacks_demo: pre_patch_callback: vmlinux
    
    Force the module init function to wait until busymod_work_func() has
    started (and logged its message), before exiting to the next selftest
    steps.
    
    Fixes: 547840bd5ae5 ("selftests/livepatch: simplify test-klp-callbacks busy target tests")
    Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20220602203233.979681-1-joe.lawrence@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/seccomp: Fix compile warning when CC=clang [+ + +]
Author: YiFei Zhu <zhuyifei@google.com>
Date:   Thu May 26 22:34:07 2022 +0000

    selftests/seccomp: Fix compile warning when CC=clang
    
    [ Upstream commit 3ce4b78f73e8e00fb86bad67ee7f6fe12019707e ]
    
    clang has -Wconstant-conversion by default, and the constant 0xAAAAAAAAA
    (9 As) being converted to an int, which is generally 32 bits, results
    in the compile warning:
    
      clang -Wl,-no-as-needed -Wall -isystem ../../../../usr/include/  -lpthread  seccomp_bpf.c -lcap -o seccomp_bpf
      seccomp_bpf.c:812:67: warning: implicit conversion from 'long' to 'int' changes value from 45812984490 to -1431655766 [-Wconstant-conversion]
              int kill = kill_how == KILL_PROCESS ? SECCOMP_RET_KILL_PROCESS : 0xAAAAAAAAA;
                  ~~~~                                                         ^~~~~~~~~~~
      1 warning generated.
    
    -1431655766 is the expected truncation, 0xAAAAAAAA (8 As), so use
    this directly in the code to avoid the warning.
    
    Fixes: 3932fcecd962 ("selftests/seccomp: Add test for unknown SECCOMP_RET kill behavior")
    Signed-off-by: YiFei Zhu <zhuyifei@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220526223407.1686936-1-zhuyifei@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/xsk: Destroy BPF resources only when ctx refcount drops to 0 [+ + +]
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Wed Jun 29 16:34:58 2022 +0200

    selftests/xsk: Destroy BPF resources only when ctx refcount drops to 0
    
    [ Upstream commit 39e940d4abfabb08b6937a315546b24d10be67e3 ]
    
    Currently, xsk_socket__delete frees BPF resources regardless of ctx
    refcount. Xdpxceiver has a test to verify whether underlying BPF
    resources would not be wiped out after closing XSK socket that was
    bound to interface with other active sockets. From library's xsk part
    perspective it also means that the internal xsk context is shared and
    its refcount is bumped accordingly.
    
    After a switch to loading XDP prog based on previously opened XSK
    socket, mentioned xdpxceiver test fails with:
    
      not ok 16 [xdpxceiver.c:swap_xsk_resources:1334]: ERROR: 9/"Bad file descriptor
    
    which means that in swap_xsk_resources(), xsk_socket__delete() released
    xskmap which in turn caused a failure of xsk_socket__update_xskmap().
    
    To fix this, when deleting socket, decrement ctx refcount before
    releasing BPF resources and do so only when refcount dropped to 0 which
    means there are no more active sockets for this ctx so BPF resources can
    be freed safely.
    
    Fixes: 2f6324a3937f ("libbpf: Support shared umems between queues and devices")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Link: https://lore.kernel.org/bpf/20220629143458.934337-5-maciej.fijalkowski@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: kvm: set rax before vmcall [+ + +]
Author: Andrei Vagin <avagin@google.com>
Date:   Fri Jul 22 16:02:40 2022 -0700

    selftests: kvm: set rax before vmcall
    
    [ Upstream commit 281106f938d3daaea6f8b6723a8217a2a1ef6936 ]
    
    kvm_hypercall has to place the hypercall number in rax.
    
    Trace events show that kvm_pv_test doesn't work properly:
         kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0
         kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0
         kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0
    
    With this change, it starts working as expected:
         kvm_pv_test-54285: kvm_hypercall: nr 0x5 a0 0x0 a1 0x0 a2 0x0 a3 0x0
         kvm_pv_test-54285: kvm_hypercall: nr 0xa a0 0x0 a1 0x0 a2 0x0 a3 0x0
         kvm_pv_test-54285: kvm_hypercall: nr 0xb a0 0x0 a1 0x0 a2 0x0 a3 0x0
    
    Signed-off-by: Andrei Vagin <avagin@google.com>
    Message-Id: <20220722230241.1944655-5-avagin@google.com>
    Fixes: ac4a4d6de22e ("selftests: kvm: test enforcement of paravirtual cpuid features")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: timers: clocksource-switch: fix passing errors from child [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Jul 13 22:46:17 2022 +0200

    selftests: timers: clocksource-switch: fix passing errors from child
    
    [ Upstream commit 4d8f52ac5fa9eede7b7aa2f2d67c841d9eeb655f ]
    
    The return value from system() is a waitpid-style integer. Do not return
    it directly because with the implicit masking in exit() it will always
    return 0. Access it with appropriate macros to really pass on errors.
    
    Fixes: 7290ce1423c3 ("selftests/timers: Add clocksource-switch test from timetest suite")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: John Stultz <jstultz@google.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: timers: valid-adjtimex: build fix for newer toolchains [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Jul 13 22:46:13 2022 +0200

    selftests: timers: valid-adjtimex: build fix for newer toolchains
    
    [ Upstream commit 9a162977d20436be5678a8e21a8e58eb4616d86a ]
    
    Toolchains with an include file 'sys/timex.h' based on 3.18 will have a
    'clock_adjtime' definition added, so it can't be static in the code:
    
    valid-adjtimex.c:43:12: error: static declaration of ‘clock_adjtime’ follows non-static declaration
    
    Fixes: e03a58c320e1 ("kselftests: timers: Add adjtimex SETOFFSET validity tests")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: John Stultz <jstultz@google.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selinux: Add boundary check in put_entry() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Tue Jun 14 10:14:49 2022 +0800

    selinux: Add boundary check in put_entry()
    
    [ Upstream commit 15ec76fb29be31df2bccb30fc09875274cba2776 ]
    
    Just like next_entry(), boundary check is necessary to prevent memory
    out-of-bound access.
    
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selinux: fix memleak in security_read_state_kernel() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Mon Jun 13 21:59:53 2022 +0800

    selinux: fix memleak in security_read_state_kernel()
    
    [ Upstream commit 73de1befcc53a7c68b0c5e76b9b5ac41c517760f ]
    
    In this function, it directly returns the result of __security_read_policy
    without freeing the allocated memory in *data, cause memory leak issue,
    so free the memory if __security_read_policy failed.
    
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    [PM: subject line tweak]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250: Add proper clock handling for OxSemi PCIe devices [+ + +]
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Mon Apr 18 16:27:33 2022 +0100

    serial: 8250: Add proper clock handling for OxSemi PCIe devices
    
    [ Upstream commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c ]
    
    Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven
    by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock.
    
    We currently drive the device using its default oversampling rate of 16
    and the clock prescaler disabled, consequently yielding the baud base of
    3906250.  This base is inadequate for some of the high-speed baud rates
    such as 460800bps, for which the closest rate possible can be obtained
    by dividing the baud base by 8, yielding the baud rate of 488281.25bps,
    which is off by 5.9638%.  This is enough for data communication to break
    with the remote end talking actual 460800bps, where missed stop bits
    have been observed.
    
    We can do better however, by taking advantage of a reduced oversampling
    rate, which can be set to any integer value from 4 to 16 inclusive by
    programming the TCR register, and by using the clock prescaler, which
    can be set to any value from 1 to 63.875 in increments of 0.125 in the
    CPR/CPR2 register pair.  The prescaler has to be explicitly enabled
    though by setting bit 7 in the MCR or otherwise it is bypassed (in the
    enhanced mode that we enable) as if the value of 1 was used.
    
    Make use of these features then as follows:
    
    - Set the baud base to 15625000, reflecting the minimum oversampling
      rate of 4 with the clock prescaler and divisor both set to 1.
    
    - Override the `set_mctrl' and set the MCR shadow there so as to have
      MCR[7] always set and have the 8250 core propagate these settings.
    
    - Override the `get_divisor' handler and determine a good combination of
      parameters by using a lookup table with predetermined value pairs of
      the oversampling rate and the clock prescaler and finding a pair that
      divides the input clock such that the quotient, when rounded to the
      nearest integer, deviates the least from the exact result.  Calculate
      the clock divisor accordingly.
    
      Scale the resulting oversampling rate (only by powers of two) if
      possible so as to maximise it, reducing the divisor accordingly, and
      avoid a divisor overflow for very low baud rates by scaling the
      oversampling rate and/or the prescaler even if that causes some
      accuracy loss.
    
      Also handle the historic spd_cust feature so as to allow one to set
      all the three parameters manually to arbitrary values, by keeping the
      low 16 bits for the divisor and then putting TCR in bits 19:16 and
      CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as
      to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875.
      This preserves compatibility with any existing setups, that is where
      requesting a custom divisor that only has any bits set among the low
      16 the oversampling rate of 16 and the clock prescaler of 33.875 will
      be used as with the original 8250.
    
      Finally abuse the `frac' argument to store the determined bit patterns
      for the TCR, CPR and CPR2 registers.
    
    - Override the `set_divisor' handler so as to set the TCR, CPR and CPR2
      registers from the `frac' value supplied.  Set the divisor as usual.
    
    With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX
    limitation imposed by `serial8250_get_baud_rate' standard baud rates
    below 300bps become unavailable in the regular way, e.g. the rate of
    200bps requires the baud base to be divided by 78125 and that is beyond
    the unsigned 16-bit range.  The historic spd_cust feature can still be
    used to obtain such rates if so required.
    
    See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details.
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181519450.9383@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250: dma: Allow driver operations before starting DMA transfers [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Fri Apr 22 20:06:11 2022 +0200

    serial: 8250: dma: Allow driver operations before starting DMA transfers
    
    [ Upstream commit e4fb03fe10c5e7a5d9aef7cefe815253274fb9ee ]
    
    One situation where this could be used is when configuring the UART
    controller to be the DMA flow controller. This is a typical case where
    the driver might need to program a few more registers before starting a
    DMA transfer. Provide the necessary infrastructure to support this
    case.
    
    Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20220422180615.9098-6-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250: Export ICR access helpers for internal use [+ + +]
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Mon Apr 18 16:27:27 2022 +0100

    serial: 8250: Export ICR access helpers for internal use
    
    [ Upstream commit cb5a40e3143bc64437858b337273fd63cc42e9c2 ]
    
    Make ICR access helpers available outside 8250_port.c, however retain
    them as ordinary static functions so as not to regress code generation.
    
    This is because `serial_icr_write' is currently automatically inlined by
    GCC, however `serial_icr_read' is not.  Making them both static inline
    would grow code produced, e.g.:
    
    $ i386-linux-gnu-size --format=gnu 8250_port-{old,new}.o
          text       data        bss      total filename
         15065       3378          0      18443 8250_port-old.o
         15289       3378          0      18667 8250_port-new.o
    
    and:
    
    $ riscv64-linux-gnu-size --format=gnu 8250_port-{old,new}.o
          text       data        bss      total filename
         16980       5306          0      22286 8250_port-old.o
         17124       5306          0      22430 8250_port-new.o
    
    while making them external would needlessly add a new module interface
    and lose the benefit from `serial_icr_write' getting inlined outside
    8250_port.o.
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181517500.9383@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250: Fold EndRun device support into OxSemi Tornado code [+ + +]
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Mon Apr 18 16:27:22 2022 +0100

    serial: 8250: Fold EndRun device support into OxSemi Tornado code
    
    [ Upstream commit 1f32c65bad24b9787d3e52843de375430e3df822 ]
    
    The EndRun PTP/1588 dual serial port device is based on the Oxford
    Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set
    for EndRun Technologies and uses the same sequence to determine the
    number of ports available.  Despite that we have duplicate code
    specific to the EndRun device.
    
    Remove redundant code then and factor out OxSemi Tornado device
    detection.
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181516220.9383@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_bcm7271: Save/restore RTS in suspend/resume [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Wed Jul 13 20:13:15 2022 -0700

    serial: 8250_bcm7271: Save/restore RTS in suspend/resume
    
    [ Upstream commit 3182efd036c1b955403d131258234896cbd9fbeb ]
    
    Commit 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming
    from S2") prevented an early enabling of RTS during resume, but it did
    not actively restore the RTS state after resume.
    
    Fixes: 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220714031316.404918-1-f.fainelli@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_dw: Store LSR into lsr_saved_flags in dw8250_tx_wait_empty() [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Wed Jun 8 12:54:31 2022 +0300

    serial: 8250_dw: Store LSR into lsr_saved_flags in dw8250_tx_wait_empty()
    
    [ Upstream commit af14f3007e2dca0d112f10f6717ba43093f74e81 ]
    
    Make sure LSR flags are preserved in dw8250_tx_wait_empty(). This
    function is called from a low-level out function and therefore cannot
    call serial_lsr_in() as it would lead to infinite recursion.
    
    It is borderline if the flags need to be saved here at all since this
    code relates to writing LCR register which usually implies no important
    characters should be arriving.
    
    Fixes: 914eaf935ec7 ("serial: 8250_dw: Allow TX FIFO to drain before writing to UART_LCR")
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220608095431.18376-7-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_fsl: Don't report FE, PE and OE twice [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Jul 4 10:51:19 2022 +0200

    serial: 8250_fsl: Don't report FE, PE and OE twice
    
    [ Upstream commit 9d3aaceb73acadf134596a2f8db9c451c1332d3d ]
    
    Some Freescale 8250 implementations have the problem that a single long
    break results in one irq per character frame time. The code in
    fsl8250_handle_irq() that is supposed to handle that uses the BI bit in
    lsr_saved_flags to detect such a situation and then skip the second
    received character. However it also stores other error bits and so after
    a single frame error the character received in the next irq handling is
    passed to the upper layer with a frame error, too.
    
    So after a spike on the data line (which is correctly recognized as a
    frame error) the following valid character is thrown away, because the
    driver reports a frame error for that one, too.
    
    To weaken this problem restrict saving LSR to only the BI bit.
    
    Note however that the handling is still broken:
    
     - lsr_saved_flags is updated using orig_lsr which is the LSR content
       for the first received char, but there might be more in the FIFO, so
       a character is thrown away that is received later and not necessarily
       the one following the break.
     - The doubled break might be the 2nd and 3rd char in the FIFO, so the
       workaround doesn't catch these, because serial8250_rx_chars() doesn't
       handle the workaround.
     - lsr_saved_flags might have set UART_LSR_BI at the entry of
       fsl8250_handle_irq() which doesn't originate from
       fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr &
       UART_LSR_BI;" but from e.g. from serial8250_tx_empty().
     - For a long or a short break this isn't about two characters, but more
       or only a single one.
    
    Fixes: 9deaa53ac7fa ("serial: add irq handler for Freescale 16550 errata.")
    Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220704085119.55900-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_pci: Refactor the loop in pci_ite887x_init() [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Oct 22 16:51:45 2021 +0300

    serial: 8250_pci: Refactor the loop in pci_ite887x_init()
    
    [ Upstream commit 35b4f17231923e2f64521bdf7a2793ce2c3c74a6 ]
    
    The loop can be refactored by using ARRAY_SIZE() instead of NULL terminator.
    This reduces code base and makes it easier to read and understand.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Jiri Slaby <jslaby@kernel.org>
    Link: https://lore.kernel.org/r/20211022135147.70965-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_pci: Replace dev_*() by pci_*() macros [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Oct 22 16:51:47 2021 +0300

    serial: 8250_pci: Replace dev_*() by pci_*() macros
    
    [ Upstream commit 1177384179416c7136e1348f07609e0da1ae6b91 ]
    
    PCI subsystem provides convenient shortcut macros for message printing.
    Use those macros instead of dev_*().
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Jiri Slaby <jslaby@kernel.org>
    Link: https://lore.kernel.org/r/20211022135147.70965-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: mvebu-uart: uart2 error bits clearing [+ + +]
Author: Narendra Hadke <nhadke@marvell.com>
Date:   Tue Jul 26 11:12:21 2022 +0200

    serial: mvebu-uart: uart2 error bits clearing
    
    commit a7209541239e5dd44d981289e5f9059222d40fd1 upstream.
    
    For mvebu uart2, error bits are not cleared on buffer read.
    This causes interrupt loop and system hang.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Yi Guo <yi.guo@cavium.com>
    Reviewed-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Narendra Hadke <nhadke@marvell.com>
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20220726091221.12358-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
skmsg: Fix invalid last sg check in sk_msg_recvmsg() [+ + +]
Author: Liu Jian <liujian56@huawei.com>
Date:   Tue Jun 28 20:36:16 2022 +0800

    skmsg: Fix invalid last sg check in sk_msg_recvmsg()
    
    [ Upstream commit 9974d37ea75f01b47d16072b5dad305bd8d23fcc ]
    
    In sk_psock_skb_ingress_enqueue function, if the linear area + nr_frags +
    frag_list of the SKB has NR_MSG_FRAG_IDS blocks in total, skb_to_sgvec
    will return NR_MSG_FRAG_IDS, then msg->sg.end will be set to
    NR_MSG_FRAG_IDS, and in addition, (NR_MSG_FRAG_IDS - 1) is set to the last
    SG of msg. Recv the msg in sk_msg_recvmsg, when i is (NR_MSG_FRAG_IDS - 1),
    the sk_msg_iter_var_next(i) will change i to 0 (not NR_MSG_FRAG_IDS), the
    judgment condition "msg_rx->sg.start==msg_rx->sg.end" and
    "i != msg_rx->sg.end" can not work.
    
    As a result, the processed msg cannot be deleted from ingress_msg list.
    But the length of all the sge of the msg has changed to 0. Then the next
    recvmsg syscall will process the msg repeatedly, because the length of sge
    is 0, the -EFAULT error is always returned.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20220628123616.186950-1-liujian56@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
SMB3: fix lease break timeout when multiple deferred close handles for the same file. [+ + +]
Author: Bharath SM <bharathsm@microsoft.com>
Date:   Thu Aug 11 19:46:11 2022 +0000

    SMB3: fix lease break timeout when multiple deferred close handles for the same file.
    
    commit 9e31678fb403eae0f4fe37c6374be098835c73cd upstream.
    
    Solution is to send lease break ack immediately even in case of
    deferred close handles to avoid lease break request timing out
    and let deferred closed handle gets closed as scheduled.
    Later patches could optimize cases where we then close some
    of these handles sooner for the cases where lease break is to 'none'
    
    Cc: stable@kernel.org
    Signed-off-by: Bharath SM <bharathsm@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: amlogic: Fix refcount leak in meson-secure-pwrc.c [+ + +]
Author: Liang He <windhl@126.com>
Date:   Thu Jun 16 22:49:15 2022 +0800

    soc: amlogic: Fix refcount leak in meson-secure-pwrc.c
    
    [ Upstream commit d18529a4c12f66d83daac78045ea54063bd43257 ]
    
    In meson_secure_pwrc_probe(), there is a refcount leak in one fail
    path.
    
    Signed-off-by: Liang He <windhl@126.com>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Fixes: b3dde5013e13 ("soc: amlogic: Add support for Secure power domains controller")
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20220616144915.3988071-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: fsl: guts: machine variable might be unset [+ + +]
Author: Michael Walle <michael@walle.cc>
Date:   Mon Apr 4 11:56:03 2022 +0200

    soc: fsl: guts: machine variable might be unset
    
    [ Upstream commit ab3f045774f704c4e7b6a878102f4e9d4ae7bc74 ]
    
    If both the model and the compatible properties are missing, then
    machine will not be set. Initialize it with NULL.
    
    Fixes: 34c1c21e94ac ("soc: fsl: fix section mismatch build warnings")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon J