Linux 6.5.12

 
9p/net: fix possible memory leak in p9_check_errors() [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Fri Oct 27 11:03:02 2023 +0800

    9p/net: fix possible memory leak in p9_check_errors()
    
    [ Upstream commit ce07087964208eee2ca2f9ee4a98f8b5d9027fe6 ]
    
    When p9pdu_readf() is called with "s?d" attribute, it allocates a pointer
    that will store a string. But when p9pdu_readf() fails while handling "d"
    then this pointer will not be freed in p9_check_errors().
    
    Fixes: 51a87c552dfd ("9p: rework client code to use new protocol support functions")
    Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Message-ID: <20231027030302.11927-1-hbh25y@gmail.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
accel/habanalabs/gaudi2: Fix incorrect string length computation in gaudi2_psoc_razwi_get_engines() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Sep 4 21:18:36 2023 +0200

    accel/habanalabs/gaudi2: Fix incorrect string length computation in gaudi2_psoc_razwi_get_engines()
    
    [ Upstream commit 90f3de616259cbb5666f00f8daf5420cd7d71d18 ]
    
    snprintf() returns the "number of characters which *would* be generated for
    the given input", not the size *really* generated.
    
    In order to avoid too large values for 'str_size' (and potential negative
    values for "PSOC_RAZWI_ENG_STR_SIZE - str_size") use scnprintf()
    instead of snprintf().
    
    Fixes: c0e6df916050 ("accel/habanalabs: fix address decode RAZWI handling")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
    Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Mon Jul 10 13:02:59 2023 -0700

    ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window
    
    [ Upstream commit 8f1004679987302b155f14b966ca6d4335814fcb ]
    
    Commit fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each
    CFMWS not in SRAT") did not account for the case where the BIOS
    only partially describes a CFMWS Window in the SRAT. That means
    the omitted address ranges, of a partially described CFMWS Window,
    do not get assigned to a NUMA node.
    
    Replace the call to phys_to_target_node() with numa_add_memblks().
    Numa_add_memblks() searches an HPA range for existing memblk(s)
    and extends those memblk(s) to fill the entire CFMWS Window.
    
    Extending the existing memblks is a simple strategy that reuses
    SRAT defined proximity domains from part of a window to fill out
    the entire window, based on the knowledge* that all of a CFMWS
    window is of a similar performance class.
    
    *Note that this heuristic will evolve when CFMWS Windows present
    a wider range of characteristics. The extension of the proximity
    domain, implemented here, is likely a step in developing a more
    sophisticated performance profile in the future.
    
    There is no change in behavior when the SRAT does not describe
    the CFMWS Window at all. In that case, a new NUMA node with a
    single memblk covering the entire CFMWS Window is created.
    
    Fixes: fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT")
    Reported-by: Derick Marks <derick.w.marks@intel.com>
    Suggested-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Tested-by: Derick Marks <derick.w.marks@intel.com>
    Link: https://lore.kernel.org/all/eaa0b7cffb0951a126223eef3cbe7b55b8300ad9.1689018477.git.alison.schofield%40intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: property: Allow _DSD buffer data only for byte accessors [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Oct 2 16:46:29 2023 +0300

    ACPI: property: Allow _DSD buffer data only for byte accessors
    
    [ Upstream commit 046ece773cc77ef5d2a1431b188ac3d0840ed150 ]
    
    In accordance with ACPI specificication and _DSD data buffer
    representation the data there is an array of bytes. Hence,
    accessing it with something longer will create a sparse data
    which is against of how device property APIs work in general
    and also not defined in the ACPI specification (see [1]).
    Fix the code to emit an error if non-byte accessor is used to
    retrieve _DSD buffer data.
    
    Fixes: 369af6bf2c28 ("ACPI: property: Read buffer properties as integers")
    Link: https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html#buffer-declare-buffer-object # [1]
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    [ rjw: Add missing braces ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Oct 23 20:32:54 2023 +0200

    ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()
    
    [ Upstream commit 48cf49d31994ff97b33c4044e618560ec84d35fb ]
    
    snprintf() does not return negative values on error.
    
    To know if the buffer was too small, the returned value needs to be
    compared with the length of the passed buffer. If it is greater or
    equal, the output has been truncated, so add checks for the truncation
    to create_pnp_modalias() and create_of_modalias(). Also make them
    return -ENOMEM in that case, as they already do that elsewhere.
    
    Moreover, the remaining size of the buffer used by snprintf() needs to
    be updated after the first write to avoid out-of-bounds access as
    already done correctly in create_pnp_modalias(), but not in
    create_of_modalias(), so change the latter accordingly.
    
    Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    [ rjw: Merge two patches into one, combine changelogs, add subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add acpi_backlight=vendor quirk for Toshiba Portégé R100 [+ + +]
Author: Ondrej Zary <linux@zary.sk>
Date:   Fri Sep 29 22:20:55 2023 +0200

    ACPI: video: Add acpi_backlight=vendor quirk for Toshiba Portégé R100
    
    [ Upstream commit 35a341c9b25da6a479bd8013bcb11a680a7233e3 ]
    
    Toshiba Portégé R100 has both acpi_video and toshiba_acpi vendor
    backlight driver working. But none of them gets activated as it has
    a VGA with no kernel driver (Trident CyberBlade XP4m32).
    
    The DMI strings are very generic ("Portable PC") so add a custom
    callback function to check for Trident CyberBlade XP4m32 PCI device
    before enabling the vendor backlight driver (better than acpi_video
    as it has more brightness steps).
    
    Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default")
    Signed-off-by: Ondrej Zary <linux@zary.sk>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/realtek: Add support dual speaker for Dell [+ + +]
Author: Kailang Yang <kailang@realtek.com>
Date:   Wed Nov 8 15:45:00 2023 +0800

    ALSA: hda/realtek: Add support dual speaker for Dell
    
    [ Upstream commit f0d9da19d7de9e845e7a93a901c4b9658df6b492 ]
    
    Dell new platform support dual speaker. But BIOS verb table only show one speaker.
    It will fill verb table for second speaker. Then bind with CS AMP model.
    
    Fixes: de90f5165b1c ("ALSA: hda/realtek: Add support for DELL Oasis 13/14/16 laptops")
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/r/4dd390a77bf742b8a518ac2deee00b0f@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: cs35l41: Fix unbalanced pm_runtime_get() [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:08 2023 +0300

    ALSA: hda: cs35l41: Fix unbalanced pm_runtime_get()
    
    [ Upstream commit 486465508f8a5fe441939a7d97607f4460a60891 ]
    
    If component_add() fails, probe() returns without calling
    pm_runtime_put(), which leaves the runtime PM usage counter incremented.
    
    Fix the issue by jumping to err_pm label and drop the now unnecessary
    pm_runtime_disable() call.
    
    Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-10-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: cs35l41: Undo runtime PM changes at driver exit time [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:09 2023 +0300

    ALSA: hda: cs35l41: Undo runtime PM changes at driver exit time
    
    [ Upstream commit 85a1bf86fac0c195929768b4e92c78cad107523b ]
    
    According to the documentation, drivers are responsible for undoing at
    removal time all runtime PM changes done during probing.
    
    Hence, add the missing calls to pm_runtime_dont_use_autosuspend(), which
    are necessary for undoing pm_runtime_use_autosuspend().
    
    Fixes: 1873ebd30cc8 ("ALSA: hda: cs35l41: Support Hibernation during Suspend")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-11-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
apparmor: fix invalid reference on profile->disconnected [+ + +]
Author: Georgia Garcia <georgia.garcia@canonical.com>
Date:   Mon Aug 21 15:37:24 2023 -0300

    apparmor: fix invalid reference on profile->disconnected
    
    [ Upstream commit 8884ba07786c718771cf7b78cb3024924b27ec2b ]
    
    profile->disconnected was storing an invalid reference to the
    disconnected path. Fix it by duplicating the string using
    aa_unpack_strdup and freeing accordingly.
    
    Fixes: 72c8a768641d ("apparmor: allow profiles to provide info to disconnected paths")
    Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64/arm: arm_pmuv3: perf: Don't truncate 64-bit registers [+ + +]
Author: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Date:   Thu Nov 2 11:30:12 2023 -0700

    arm64/arm: arm_pmuv3: perf: Don't truncate 64-bit registers
    
    [ Upstream commit 403edfa436286b21f5ffe6856ae5b36396e8966c ]
    
    The driver used to truncate several 64-bit registers such as PMCEID[n]
    registers used to describe whether architectural and microarchitectural
    events in range 0x4000-0x401f exist. Due to discarding the bits, the
    driver made the events invisible, even if they existed.
    
    Moreover, PMCCFILTR and PMCR registers have additional bits in the upper
    32 bits. This patch makes them available although they aren't currently
    used. Finally, functions handling PMXEVCNTR and PMXEVTYPER registers are
    removed as they not being used at all.
    
    Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away")
    Reported-by: Carl Worth <carl@os.amperecomputing.com>
    Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
    Acked-by: Will Deacon <will@kernel.org>
    Closes: https://lore.kernel.org/..
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Link: https://lore.kernel.org/r/20231102183012.1251410-1-ilkka@os.amperecomputing.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64/arm: xen: enlighten: Fix KPTI checks [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Oct 16 11:24:25 2023 +0100

    arm64/arm: xen: enlighten: Fix KPTI checks
    
    [ Upstream commit 20f3b8eafe0ba5d3c69d5011a9b07739e9645132 ]
    
    When KPTI is in use, we cannot register a runstate region as XEN
    requires that this is always a valid VA, which we cannot guarantee. Due
    to this, xen_starting_cpu() must avoid registering each CPU's runstate
    region, and xen_guest_init() must avoid setting up features that depend
    upon it.
    
    We tried to ensure that in commit:
    
      f88af7229f6f22ce (" xen/arm: do not setup the runstate info page if kpti is enabled")
    
    ... where we added checks for xen_kernel_unmapped_at_usr(), which wraps
    arm64_kernel_unmapped_at_el0() on arm64 and is always false on 32-bit
    arm.
    
    Unfortunately, as xen_guest_init() is an early_initcall, this happens
    before secondary CPUs are booted and arm64 has finalized the
    ARM64_UNMAP_KERNEL_AT_EL0 cpucap which backs
    arm64_kernel_unmapped_at_el0(), and so this can subsequently be set as
    secondary CPUs are onlined. On a big.LITTLE system where the boot CPU
    does not require KPTI but some secondary CPUs do, this will result in
    xen_guest_init() intializing features that depend on the runstate
    region, and xen_starting_cpu() registering the runstate region on some
    CPUs before KPTI is subsequent enabled, resulting the the problems the
    aforementioned commit tried to avoid.
    
    Handle this more robsutly by deferring the initialization of the
    runstate region until secondary CPUs have been initialized and the
    ARM64_UNMAP_KERNEL_AT_EL0 cpucap has been finalized. The per-cpu work is
    moved into a new hotplug starting function which is registered later
    when we're certain that KPTI will not be used.
    
    Fixes: f88af7229f6f ("xen/arm: do not setup the runstate info page if kpti is enabled")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Bertrand Marquis <bertrand.marquis@arm.com>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Stefano Stabellini <sstabellini@kernel.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8mm: Add sound-dai-cells to micfil node [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Wed Oct 4 18:01:58 2023 -0500

    arm64: dts: imx8mm: Add sound-dai-cells to micfil node
    
    [ Upstream commit 0e6cc2b8bb7d67733f4a47720787eff1ce2666f2 ]
    
    Per the DT bindings, the micfil node should have a sound-dai-cells
    entry.
    
    Fixes: 3bd0788c43d9 ("arm64: dts: imx8mm: Add support for micfil")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mn: Add sound-dai-cells to micfil node [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Wed Oct 4 18:01:59 2023 -0500

    arm64: dts: imx8mn: Add sound-dai-cells to micfil node
    
    [ Upstream commit db1925454a2e7cadcac8756442ca7c3198332336 ]
    
    Per the DT bindings, the micfil node should have a sound-dai-cells
    entry.
    
    Fixes: cca69ef6eba5 ("arm64: dts: imx8mn: Add support for micfil")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp-debix-model-a: Remove USB hub reset-gpios [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Fri Sep 29 10:11:23 2023 -0300

    arm64: dts: imx8mp-debix-model-a: Remove USB hub reset-gpios
    
    [ Upstream commit 0ce9a2c121e3ab354cf66aeecd3ed0758f3c5067 ]
    
    The SAI2_TXC pin is left unconnected per the imx8mp-debix-model-a
    schematics:
    
    https://debix.io/Uploads/Temp/file/20230331/DEBIX%20Model%20A%20Schematics.pdf
    
    Also, the RTS5411E USB hub chip does not have a reset pin.
    
    Remove this pin description to properly describe the hardware.
    
    This also fixes the following schema warning:
    
    hub@1: 'reset-gpios' does not match any of the regexes: 'pinctrl-[0-9]+'
    from schema $id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml#
    
    Fixes: 0253e1cb6300 ("arm64: dts: imx8mp-debix: add USB host support")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8qm-ss-img: Fix jpegenc compatible entry [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Tue Sep 26 11:27:36 2023 -0300

    arm64: dts: imx8qm-ss-img: Fix jpegenc compatible entry
    
    [ Upstream commit 1d33cd614d89b0ec024d25ec45acf4632211b5a7 ]
    
    The first compatible entry for the jpegenc should be 'nxp,imx8qm-jpgenc'.
    
    Change it accordingly to fix the following schema warning:
    
    imx8qm-apalis-eval.dtb: jpegenc@58450000: compatible: 'oneOf' conditional failed, one must be fixed:
            'nxp,imx8qm-jpgdec' is not one of ['nxp,imx8qxp-jpgdec', 'nxp,imx8qxp-jpgenc']
            'nxp,imx8qm-jpgenc' was expected
            'nxp,imx8qxp-jpgdec' was expected
    
    Fixes: 5bb279171afc ("arm64: dts: imx8: Add jpeg encoder/decoder nodes")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins [+ + +]
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Mon Aug 21 10:51:25 2023 +1200

    ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins
    
    [ Upstream commit 0878fd86f554ab98aa493996c7e0c72dff58437f ]
    
    Both the CN9130-CRB and CN9130-DB use the SPI1 interface but had the
    pinctrl node labelled as "cp0_spi0_pins". Use the label "cp0_spi1_pins"
    and update the node name to "cp0-spi-pins-1" to avoid confusion with the
    pinctrl options for SPI0.
    
    Fixes: 4c43a41e5b8c ("arm64: dts: cn913x: add device trees for topology B boards")
    Fixes: 5c0ee54723f3 ("arm64: dts: add support for Marvell cn9130-crb platform")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: qcom: apq8016-sbc: Add missing ADV7533 regulators [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Fri Sep 22 12:49:55 2023 +0200

    arm64: dts: qcom: apq8016-sbc: Add missing ADV7533 regulators
    
    [ Upstream commit 33e9032a1875bb1aee3c68a4540f5a577ff44130 ]
    
    Add the missing regulator supplies to the ADV7533 HDMI bridge to fix
    the following dtbs_check warnings. They are all also supplied by
    pm8916_l6 so there is no functional difference.
    
    apq8016-sbc.dtb: bridge@39: 'dvdd-supply' is a required property
    apq8016-sbc.dtb: bridge@39: 'pvdd-supply' is a required property
    apq8016-sbc.dtb: bridge@39: 'a2vdd-supply' is a required property
            from schema display/bridge/adi,adv7533.yaml
    
    Fixes: 28546b095511 ("arm64: dts: apq8016-sbc: Add HDMI display support")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230922-db410c-adv7533-regulators-v1-1-68aba71e529b@gerhold.net
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Fix iommu local address range [+ + +]
Author: Gaurav Kohli <quic_gkohli@quicinc.com>
Date:   Fri Sep 15 20:03:04 2023 +0530

    arm64: dts: qcom: msm8916: Fix iommu local address range
    
    [ Upstream commit 2de8ee9f58fa51f707c71f8fbcd8470ab0078102 ]
    
    Fix the apps iommu local address space range as per data sheet.
    
    Fixes: 6a6729f38436 ("arm64: dts: qcom: msm8916: Add IOMMU support")
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230915143304.477-1-quic_gkohli@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8939: Fix iommu local address range [+ + +]
Author: Gaurav Kohli <quic_gkohli@quicinc.com>
Date:   Sun Sep 17 19:30:39 2023 +0530

    arm64: dts: qcom: msm8939: Fix iommu local address range
    
    [ Upstream commit d40291e52d5ac4d0ff18ca433e84e6ddccc13427 ]
    
    Fix the apps iommu local address space range as per data sheet.
    
    Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
    Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20230917140039.25283-1-quic_gkohli@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8976: Fix ipc bit shifts [+ + +]
Author: Adam Skladowski <a39.skl@gmail.com>
Date:   Sat Aug 12 13:24:50 2023 +0200

    arm64: dts: qcom: msm8976: Fix ipc bit shifts
    
    [ Upstream commit 684277525c70f329300cc687e27248e405a4ff9e ]
    
    Update bits to match downstream irq-bitmask values.
    
    Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs")
    Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
    Link: https://lore.kernel.org/r/20230812112534.8610-8-a39.skl@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8992-libra: drop duplicated reserved memory [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jul 20 09:20:48 2023 +0200

    arm64: dts: qcom: msm8992-libra: drop duplicated reserved memory
    
    [ Upstream commit f32096602c19e68fb9bf04b494d13f1190602554 ]
    
    There are two entries for similar reserved memory: qseecom@cb400000 and
    audio@cb400000.  Keep the qseecom as it is longer.
    
      Warning (unique_unit_address_if_enabled): /reserved-memory/audio@cb400000: duplicate unit-address (also used in node /reserved-memory/qseecom@cb400000)
    
    Fixes: 69876bc6fd4d ("arm64: dts: qcom: msm8992-libra: Fix the memory map")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230720072048.10093-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: qrb2210-rb1: Swap UART index [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Sep 6 11:24:55 2023 +0200

    arm64: dts: qcom: qrb2210-rb1: Swap UART index
    
    [ Upstream commit 973c015facabcbd320063648010942c51992c1a1 ]
    
    Newer RB1 board revisions have a debug UART on QUP0. Sadly, it looks
    like even when ordering one in retail, customers receive prototype
    boards with "Enginering Sample" written on them.
    
    Use QUP4 for UART to make all known RB1 boards boot.
    
    Fixes: e18771961336 ("arm64: dts: qcom: Add initial QTI RB1 device tree")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230906-topic-rb1_features_sans_icc-v1-1-e92ce6fbde16@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7280: Add missing LMH interrupts [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 22:58:22 2023 +0200

    arm64: dts: qcom: sc7280: Add missing LMH interrupts
    
    [ Upstream commit 3f93d119c9d6e1744d55cd48af764160a1a3aca3 ]
    
    Hook up the interrupts that signal the Limits Management Hardware has
    started some sort of throttling action.
    
    Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-7280_lmhirq-v1-1-c262b6a25c8f@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7280: drop incorrect EUD port on SoC side [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Aug 20 09:56:26 2023 +0200

    arm64: dts: qcom: sc7280: drop incorrect EUD port on SoC side
    
    [ Upstream commit 39c8af78cbefb8c71a5ad1fa088e761ef418f0a0 ]
    
    Qualcomm Embedded USB Debugger (EUD) second port should point to Type-C
    USB connector.  Such connector was defined directly in root node of
    sc7280.dtsi which is clearly wrong.  SC7280 is a chip, so physically it
    does not have USB Type-C port.  The connector is usually accessible
    through some USB switch or controller.
    
    Doug Anderson said that he wasn't ever able to use EUD on Herobrine
    boards, probably because of invalid or missing DTS description - DTS is
    saying EUD is on usb_2 node, which is connected to a USB Hub, not to the
    Type-C port.
    
    Correct the EUD/USB connector topology by removing the top-level fake
    USB connector and EUD port pointing to it, and disabling the incomplete
    EUD device node.
    
    This fixes also dtbs_check warnings:
    
      sc7280-herobrine-crd.dtb: connector: ports:port@0: 'reg' is a required property
    
    Link: https://lore.kernel.org/all/CAD=FV=Xt26=rBf99mzkAuwwtb2f-jnKtnHaEhXnthz0a5zke4Q@mail.gmail.com/
    Fixes: 9ee402ccfeb1 ("arm64: dts: qcom: sc7280: Fix EUD dt node syntax")
    Cc: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
    Cc: Bhupesh Sharma <bhupesh.sharma@linaro.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20230820075626.22600-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7280: link usb3_phy_wrapper_gcc_usb30_pipe_clk [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Jul 11 15:09:12 2023 +0300

    arm64: dts: qcom: sc7280: link usb3_phy_wrapper_gcc_usb30_pipe_clk
    
    [ Upstream commit 70c4a1ca13b333b00e01266d299605fa1041b0d5 ]
    
    Use usb_1_ssphy's clock as gcc's usb3_phy_wrapper_gcc_usb30_pipe_clk
    clock source.
    
    Suggested-by: Neil Armstrong <neil.armstrong@linaro.org>
    Fixes: 1c39e6f9b534 ("arm64: dts: qcom: sc7280: Add USB related nodes")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230711120916.4165894-7-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845-mtp: fix WiFi configuration [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Aug 27 01:19:11 2023 +0300

    arm64: dts: qcom: sdm845-mtp: fix WiFi configuration
    
    [ Upstream commit b33868a52f342d9b1f20aa5bffe40cbd69bd0a4b ]
    
    Enable the host-cap-8bit quirk on this device. It is required for the
    WiFi to function properly.
    
    Fixes: 022bccb840b7 ("arm64: dts: sdm845: Add WCN3990 WLAN module device node")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230826221915.846937-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845: cheza doesn't support LMh node [+ + +]
Author: David Heidelberg <david@ixit.cz>
Date:   Tue Sep 12 12:42:04 2023 +0530

    arm64: dts: qcom: sdm845: cheza doesn't support LMh node
    
    [ Upstream commit 197ae69d1caedb3203e0b189a39efb820675fd5c ]
    
    Cheza firmware doesn't allow controlling LMh from the operating system.
    
    Fixes: 36c6581214c4 ("arm64: dts: qcom: sdm845: Add support for LMh node")
    Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: David Heidelberg <david@ixit.cz>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20230912071205.11502-2-david@ixit.cz
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845: Fix PSCI power domain names [+ + +]
Author: David Heidelberg <david@ixit.cz>
Date:   Tue Sep 12 12:42:03 2023 +0530

    arm64: dts: qcom: sdm845: Fix PSCI power domain names
    
    [ Upstream commit a5f01673d3946e424091e6b8ff274716f9c21454 ]
    
    The original commit hasn't been updated according to
    refactoring done in sdm845.dtsi.
    
    Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI")
    Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: David Heidelberg <david@ixit.cz>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20230912071205.11502-1-david@ixit.cz
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm6125: Pad APPS IOMMU address to 8 characters [+ + +]
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Sun Jul 23 18:08:40 2023 +0200

    arm64: dts: qcom: sm6125: Pad APPS IOMMU address to 8 characters
    
    [ Upstream commit 310cdafc4a56827d1aeda7cc297939034adb8f99 ]
    
    APPS IOMMU is the only node in sm6125.dtsi that doesn't have its
    address padded to 8 hexadecimals; fix this by prepending a 0.
    
    Fixes: 8ddb4bc3d3b5 ("arm64: dts: qcom: sm6125: Configure APPS SMMU")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Link: https://lore.kernel.org/r/20230723-sm6125-dpu-v4-2-a3f287dd6c07@somainline.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8150: add ref clock to PCIe PHYs [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Aug 20 17:20:31 2023 +0300

    arm64: dts: qcom: sm8150: add ref clock to PCIe PHYs
    
    [ Upstream commit c204b3709409279ac019f3d374e444bb0b1424f0 ]
    
    Follow the rest of the platforms and add "ref" clocks to both PCIe PHYs
    found on the Qualcomm SM8150 platform.
    
    Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230820142035.89903-15-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8350: fix pinctrl for UART18 [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat Aug 26 00:45:48 2023 +0300

    arm64: dts: qcom: sm8350: fix pinctrl for UART18
    
    [ Upstream commit c1efa960114f743924b884da098298512a7e9983 ]
    
    On sm8350 QUP18 uses GPIO 68/69, not 58/59. Fix correponding UART18
    pinconf configuraion.
    
    Fixes: 98374e6925b8 ("arm64: dts: qcom: sm8350: Set up WRAP2 QUPs")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230825214550.1650938-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: ti: k3-am625-beagleplay: Fix typo in ramoops reg [+ + +]
Author: Wadim Egorov <w.egorov@phytec.de>
Date:   Mon Sep 25 17:14:44 2023 +0200

    arm64: dts: ti: k3-am625-beagleplay: Fix typo in ramoops reg
    
    [ Upstream commit 33269ac0b768b07da017df173d52952625c57870 ]
    
    Seems like the address value of the reg property was mistyped.
    Update reg to 0x9ca00000 to match node's definition.
    
    Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay")
    Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
    Reviewed-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20230925151444.1856852-1-w.egorov@phytec.de
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: ti: k3-am62a7-sk: Drop i2c-1 to 100Khz [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Tue Oct 3 14:41:32 2023 +0530

    arm64: dts: ti: k3-am62a7-sk: Drop i2c-1 to 100Khz
    
    [ Upstream commit 63e5aa69b821472a3203a29e17c025329c1b151f ]
    
    The TLV320AIC3106 audio codec is interfaced on the i2c-1 bus. With the
    default rate of 400Khz the i2c register writes fail to sync:
    
    [   36.026387] tlv320aic3x 1-001b: Unable to sync registers 0x16-0x16. -110
    [   38.101130] omap_i2c 20010000.i2c: controller timed out
    
    Dropping the rate to 100Khz fixes the issue.
    
    Fixes: 38c4a08c820c ("arm64: dts: ti: Add support for AM62A7-SK")
    Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
    Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-3-2b631ff319ca@ti.com
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Fix P3767 card detect polarity [+ + +]
Author: Brad Griffis <bgriffis@nvidia.com>
Date:   Mon Jun 26 18:09:19 2023 +0000

    arm64: tegra: Fix P3767 card detect polarity
    
    [ Upstream commit c6b7a1d11d0fa6333078141251908f48042016e1 ]
    
    The SD card detect pin is active-low on all Orin Nano and NX SKUs that
    have an SD card slot.
    
    Fixes: 13b0aca303e9 ("arm64: tegra: Support Jetson Orin NX")
    Signed-off-by: Brad Griffis <bgriffis@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Fix P3767 QSPI speed [+ + +]
Author: Brad Griffis <bgriffis@nvidia.com>
Date:   Mon Jun 26 18:09:20 2023 +0000

    arm64: tegra: Fix P3767 QSPI speed
    
    [ Upstream commit 57ea99ba176913c325fc8324a24a1b5e8a6cf520 ]
    
    The QSPI device used on Jetson Orin NX and Nano modules (p3767) is
    the same as Jetson AGX Orin (p3701) and should have a maximum speed of
    102 MHz.
    
    Fixes: 13b0aca303e9 ("arm64: tegra: Support Jetson Orin NX")
    Signed-off-by: Brad Griffis <bgriffis@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Use correct interrupts for Tegra234 TKE [+ + +]
Author: Thierry Reding <treding@nvidia.com>
Date:   Thu Oct 12 14:43:11 2023 +0200

    arm64: tegra: Use correct interrupts for Tegra234 TKE
    
    [ Upstream commit c0b80988eb78d6423249ab530bfbc6b238790a26 ]
    
    The shared interrupts 0-9 of the TKE are mapped to interrupts 0-9, but
    shared interrupts 10-15 are mapped to 256-261. Correct the mapping for
    the final 6 interrupts. This prevents the TKE from requesting the RTC
    interrupt (along with several GTE and watchdog interrupts).
    
    Reported-by: Shubhi Garg <shgarg@nvidia.com>
    Fixes: 28d860ed02c2 ("arm64: tegra: Enable native timers on Tegra234")
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: 9321/1: memset: cast the constant byte to unsigned char [+ + +]
Author: Kursad Oney <kursad.oney@broadcom.com>
Date:   Tue Aug 22 15:06:06 2023 +0100

    ARM: 9321/1: memset: cast the constant byte to unsigned char
    
    [ Upstream commit c0e824661f443b8cab3897006c1bbc69fd0e7bc4 ]
    
    memset() description in ISO/IEC 9899:1999 (and elsewhere) says:
    
            The memset function copies the value of c (converted to an
            unsigned char) into each of the first n characters of the
            object pointed to by s.
    
    The kernel's arm32 memset does not cast c to unsigned char. This results
    in the following code to produce erroneous output:
    
            char a[128];
            memset(a, -128, sizeof(a));
    
    This is because gcc will generally emit the following code before
    it calls memset() :
    
            mov   r0, r7
            mvn   r1, #127        ; 0x7f
            bl    00000000 <memset>
    
    r1 ends up with 0xffffff80 before being used by memset() and the
    'a' array will have -128 once in every four bytes while the other
    bytes will be set incorrectly to -1 like this (printing the first
    8 bytes) :
    
            test_module: -128 -1 -1 -1
            test_module: -1 -1 -1 -128
    
    The change here is to 'and' r1 with 255 before it is used.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Kursad Oney <kursad.oney@broadcom.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: 9323/1: mm: Fix ARCH_LOW_ADDRESS_LIMIT when CONFIG_ZONE_DMA [+ + +]
Author: wahrenst <wahrenst@gmx.net>
Date:   Wed Sep 6 22:40:12 2023 +0100

    ARM: 9323/1: mm: Fix ARCH_LOW_ADDRESS_LIMIT when CONFIG_ZONE_DMA
    
    [ Upstream commit 399da29ff5eb3f675c71423bec4cf2208f218576 ]
    
    Configuring VMSPLIT_2G + LPAE on Raspberry Pi 4 leads to SWIOTLB
    buffer allocation beyond platform dma_zone_size of SZ_1G, which
    results in broken SD card boot.
    
    So fix this be setting ARCH_LOW_ADDRESS_LIMIT in CONFIG_ZONE_DMA
    case.
    
    Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
    Fixes: e9faf9b0b07a ("ARM: add multi_v7_lpae_defconfig")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: am3517-evm: Fix LED3/4 pinmux [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Wed Oct 4 19:04:01 2023 -0500

    ARM: dts: am3517-evm: Fix LED3/4 pinmux
    
    [ Upstream commit 2ab6b437c65233f06bdd2988fd5913baeca5f159 ]
    
    The pinmux for LED3 and LED4 are incorrectly attached to the
    omap3_pmx_core when they should be connected to the omap3_pmx_wkup
    pin mux.  This was likely masked by the fact that the bootloader
    used to do all the pinmuxing.
    
    Fixes: 0dbf99542caf ("ARM: dts: am3517-evm: Add User LEDs and Pushbutton")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Message-ID: <20231005000402.50879-1-aford173@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM5301X: Explicitly disable unused switch CPU ports [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Oct 13 12:33:13 2023 +0200

    ARM: dts: BCM5301X: Explicitly disable unused switch CPU ports
    
    [ Upstream commit 473baeab929444295b0530f8766e4becb6a08973 ]
    
    When redescribing ports I assumed that missing "label" (like "cpu")
    means switch port isn't used. That was incorrect and I realized my
    change made Linux always use the first (5) CPU port (there are 3 of
    them).
    
    While above should technically be possible it often isn't correct:
    1. Non-default switch ports are often connected to Ethernet interfaces
       not fully covered by vendor setup (they may miss MACs)
    2. On some devices non-default ports require specifying fixed link
    
    This fixes network connectivity for some devices. It was reported &
    tested for Netgear R8000. It also affects Linksys EA9200 with its
    downstream DTS.
    
    Fixes: ba4aebce23b2 ("ARM: dts: BCM5301X: Describe switch ports in the main DTS")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20231013103314.10306-1-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensor [+ + +]
Author: Matti Lehtimäki <matti.lehtimaki@gmail.com>
Date:   Fri Sep 22 04:12:11 2023 +0300

    ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensor
    
    [ Upstream commit 0b73519790d29e4bc71afc4882a9aa9ea649bcf7 ]
    
    Fix hall sensor GPIO polarity and also allow disabling the sensor.
    Remove unneeded interrupt.
    
    Fixes: f15623bda1dc ("ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 (SM-T530)")
    Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
    Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
    Link: https://lore.kernel.org/r/20230922011211.115234-1-matti.lehtimaki@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Sep 24 20:39:13 2023 +0200

    ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator
    
    [ Upstream commit 09f8ee81b6da5f76de8b83c8bfc4475b54e101e0 ]
    
    Fixed regulator put under "regulators" node will not be populated,
    unless simple-bus or something similar is used.  Drop the "regulators"
    wrapper node to fix this.
    
    Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230924183914.51414-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: renesas: blanche: Fix typo in GP_11_2 pin name [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Aug 30 17:21:38 2023 +0200

    ARM: dts: renesas: blanche: Fix typo in GP_11_2 pin name
    
    [ Upstream commit edc6ef026fe69154bb6b70dd6e7f278cfd7d6919 ]
    
    On blanche, the GPIO keyboard fails to probe with:
    
        sh-pfc e6060000.pinctrl: could not map pin config for "GP_11_02"
    
    Fix this by correcting the name for this pin to "GP_11_2".
    
    Fixes: 1f27fedead91eb60 ("ARM: dts: blanche: Configure pull-up for SOFT_SW and SW25 GPIO keys")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/203128eca2261ffc33b83637818dd39c488f42b0.1693408326.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: ams-delta.c: use component after check [+ + +]
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Fri Oct 27 00:09:56 2023 +0000

    ASoC: ams-delta.c: use component after check
    
    [ Upstream commit bd0f7498bc9084d8cccc5484cd004b40f314b763 ]
    
            static void cx81801_close()
            {
                    ...
    (A)             struct snd_soc_dapm_context *dapm = &component->card->dapm;
                    ...
    (B)             if (!component)
                            return;
            }
    
    (A) uses component before NULL check (B). This patch moves it after (B).
    
    Fixes: d0fdfe34080c ("ASoC: cx20442: replace codec to component")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/3e608474-e99a-4866-ae98-3054a4221f09@moroto.mountain
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/87ttqdq623.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l41: Handle mdsync_down reg write errors [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:00 2023 +0300

    ASoC: cs35l41: Handle mdsync_down reg write errors
    
    [ Upstream commit a9a3f54a23d844971c274f352500dddeadb4412c ]
    
    The return code of regmap_multi_reg_write() call related to "MDSYNC
    down" sequence is shadowed by the subsequent
    wait_for_completion_timeout() invocation, which is expected to time
    timeout in case the write operation failed.
    
    Let cs35l41_global_enable() return the correct error code instead of
    -ETIMEDOUT.
    
    Fixes: f5030564938b ("ALSA: cs35l41: Add shared boost feature")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-2-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l41: Initialize completion object before requesting IRQ [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:02 2023 +0300

    ASoC: cs35l41: Initialize completion object before requesting IRQ
    
    [ Upstream commit 5ad668a9ce83d819701fb7abc1c2236049ec15c2 ]
    
    Technically, an interrupt handler can be called before probe() finishes
    its execution, hence ensure the pll_lock completion object is always
    initialized before being accessed in cs35l41_irq().
    
    Fixes: f5030564938b ("ALSA: cs35l41: Add shared boost feature")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-4-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l41: Undo runtime PM changes at driver exit time [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:05 2023 +0300

    ASoC: cs35l41: Undo runtime PM changes at driver exit time
    
    [ Upstream commit 2d5661e6008ae1a1cd6df7cc844908fb8b982c58 ]
    
    According to the documentation, drivers are responsible for undoing at
    removal time all runtime PM changes done during probing.
    
    Hence, add the missing calls to pm_runtime_dont_use_autosuspend(), which
    are necessary for undoing pm_runtime_use_autosuspend().
    
    Note this would have been handled implicitly by
    devm_pm_runtime_enable(), but there is a need to continue using
    pm_runtime_enable()/pm_runtime_disable() in order to ensure the runtime
    PM is disabled as soon as the remove() callback is entered.
    
    Fixes: f517ba4924ad ("ASoC: cs35l41: Add support for hibernate memory retention mode")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-7-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l41: Verify PM runtime resume errors in IRQ handler [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Thu Sep 7 20:10:04 2023 +0300

    ASoC: cs35l41: Verify PM runtime resume errors in IRQ handler
    
    [ Upstream commit 9f8948db9849d202dee3570507d3a0642f92d632 ]
    
    The interrupt handler invokes pm_runtime_get_sync() without checking the
    returned error code.
    
    Add a proper verification and switch to pm_runtime_resume_and_get(), to
    avoid the need to call pm_runtime_put_noidle() for decrementing the PM
    usage counter before returning from the error condition.
    
    Fixes: f517ba4924ad ("ASoC: cs35l41: Add support for hibernate memory retention mode")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20230907171010.1447274-6-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: dapm: fix clock get name [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Mon Nov 6 11:37:09 2023 +0100

    ASoC: dapm: fix clock get name
    
    [ Upstream commit 4bdcbc31ad2112385ad525b28972c45015e6ad70 ]
    
    The name currently used to get the clock includes the dapm prefix.
    It should use the name as provided to the widget, without the prefix.
    
    Fixes: 3caac759681e ("ASoC: soc-dapm.c: fixup snd_soc_dapm_new_control_unlocked() error handling")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20231106103712.703962-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl-asoc-card: Add comment for mclk in the codec_priv [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Sat Oct 7 12:01:17 2023 +0800

    ASoC: fsl-asoc-card: Add comment for mclk in the codec_priv
    
    [ Upstream commit fbfe616ad40c06d68b83b657a94cd2e709dda37b ]
    
    Otherwise a warning will be detected as below:
    warning: Function parameter or member 'mclk' not described in
    'codec_priv'
    
    Fixes: 1075df4bdeb3 ("ASoC: fsl-asoc-card: add nau8822 support")
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20231007040117.22446-1-hui.wang@canonical.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probe [+ + +]
Author: Zhang Shurong <zhang_shurong@foxmail.com>
Date:   Thu Oct 12 21:03:15 2023 +0800

    ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probe
    
    [ Upstream commit 9e630efb5a4af56fdb15aa10405f5cfd3f5f5b83 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context. We fix it by calling
    pm_runtime_disable when error returns.
    
    Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
    Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_C0D62E6D89818179A02A04A0C248F0DDC40A@qq.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl: mpc5200_dma.c: Fix warning of Function parameter or member not described [+ + +]
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Mon Oct 9 23:39:43 2023 +0000

    ASoC: fsl: mpc5200_dma.c: Fix warning of Function parameter or member not described
    
    [ Upstream commit 4a221b2e3340f4a3c2b414c46c846a26c6caf820 ]
    
    This patch fixes the warnings of "Function parameter or member 'xxx'
    not described".
    
    >> sound/soc/fsl/mpc5200_dma.c:116: warning: Function parameter or member 'component' not described in 'psc_dma_trigger'
       sound/soc/fsl/mpc5200_dma.c:116: warning: Function parameter or member 'substream' not described in 'psc_dma_trigger'
       sound/soc/fsl/mpc5200_dma.c:116: warning: Function parameter or member 'cmd' not described in 'psc_dma_trigger'
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310061914.jJuekdHs-lkp@intel.com/
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Fixes: 6d1048bc1152 ("ASoC: fsl: mpc5200_dma: remove snd_pcm_ops")
    Link: https://lore.kernel.org/r/87il7fcqm8.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: hdmi-codec: register hpd callback on component probe [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Mon Nov 6 11:40:11 2023 +0100

    ASoC: hdmi-codec: register hpd callback on component probe
    
    [ Upstream commit 15be353d55f9e12e34f9a819f51eb41fdef5eda8 ]
    
    The HDMI hotplug callback to the hdmi-codec is currently registered when
    jack is set.
    
    The hotplug not only serves to report the ASoC jack state but also to get
    the ELD. It should be registered when the component probes instead, so it
    does not depend on the card driver registering a jack for the HDMI to
    properly report the ELD.
    
    Fixes: 25ce4f2b3593 ("ASoC: hdmi-codec: Get ELD in before reporting plugged event")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20231106104013.704356-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: Fix mem leak when parsing UUIDs fails [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Thu Oct 26 10:25:58 2023 +0200

    ASoC: Intel: Skylake: Fix mem leak when parsing UUIDs fails
    
    [ Upstream commit 168d97844a61db302dec76d44406e9d4d7106b8e ]
    
    Error path in snd_skl_parse_uuids() shall free last allocated module if
    its instance_id allocation fails.
    
    Fixes: f8e066521192 ("ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231026082558.1864910-1-amadeuszx.slawinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: sof_sdw_rt_sdca_jack_common: add rt713 support [+ + +]
Author: Bard Liao <yung-chuan.liao@linux.intel.com>
Date:   Thu Oct 12 15:08:07 2023 -0400

    ASoC: Intel: sof_sdw_rt_sdca_jack_common: add rt713 support
    
    [ Upstream commit b6d6e5abf64562985fdbbdbdfe8088cde634d834 ]
    
    Adding rt713 support to sof_sdw_rt_sdca_jack_common.c.
    
    Fixes: fbaaf80d8cf6 ("ASoC: Intel: sof_sdw: add rt713 support")
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20231012190826.142619-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8186_mt6366_rt1019_rt5682s: trivial: fix error messages [+ + +]
Author: Eugen Hristev <eugen.hristev@collabora.com>
Date:   Tue Oct 31 12:31:39 2023 +0200

    ASoC: mediatek: mt8186_mt6366_rt1019_rt5682s: trivial: fix error messages
    
    [ Upstream commit 004fc58edea6f00db9ad07b40b882e8d976f7a54 ]
    
    Property 'playback-codecs' is referenced as 'speaker-codec' in the error
    message, and this can lead to confusion.
    Correct the error message such that the correct property name is
    referenced.
    
    Fixes: 0da16e370dd7 ("ASoC: mediatek: mt8186: add machine driver with mt6366, rt1019 and rt5682s")
    Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20231031103139.77395-1-eugen.hristev@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm.c: Make sure DAI parameters cleared if the DAI becomes inactive [+ + +]
Author: Chancel Liu <chancel.liu@nxp.com>
Date:   Wed Sep 20 23:36:21 2023 +0800

    ASoC: soc-pcm.c: Make sure DAI parameters cleared if the DAI becomes inactive
    
    [ Upstream commit 3efcb471f871cc095841d411f98c593228ecbac6 ]
    
    The commit 1da681e52853 ("ASoC: soc-pcm.c: Clear DAIs parameters after
    stream_active is updated") tries to make sure DAI parameters can be
    cleared properly through moving the cleanup to the place where stream
    active status is updated. However, it will cause the cleanup only
    happening in soc_pcm_close().
    
    Suppose a case: aplay -Dhw:0 44100.wav 48000.wav. The case calls
    soc_pcm_open()->soc_pcm_hw_params()->soc_pcm_hw_free()->
    soc_pcm_hw_params()->soc_pcm_hw_free()->soc_pcm_close() in order. The
    parameters would be remained in the system even if the playback of
    44100.wav is finished.
    
    The case requires us clearing parameters in phase of soc_pcm_hw_free().
    However, moving the DAI parameters cleanup back to soc_pcm_hw_free()
    has the risk that DAIs parameters never be cleared if there're more
    than one stream, see commit 1da681e52853 ("ASoC: soc-pcm.c: Clear DAIs
    parameters after stream_active is updated") for more details.
    
    To meet all these requirements, in addition to do DAI parameters
    cleanup in soc_pcm_hw_free(), also check it in soc_pcm_close() to make
    sure DAI parameters cleared if the DAI becomes inactive.
    
    Fixes: 1da681e52853 ("ASoC: soc-pcm.c: Clear DAIs parameters after stream_active is updated")
    Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
    Link: https://lore.kernel.org/r/20230920153621.711373-2-chancel.liu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: core: Ensure sof_ops_free() is still called when probe never ran. [+ + +]
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Oct 9 13:54:25 2023 +0200

    ASoC: SOF: core: Ensure sof_ops_free() is still called when probe never ran.
    
    [ Upstream commit f549a82aff57865c47b5abd17336b23cd9bb2d2c ]
    
    In an effort to not call sof_ops_free twice, we stopped running it when
    probe was aborted.
    
    Check the result of cancel_work_sync to see if this was the case.
    
    Fixes: 31bb7bd9ffee ("ASoC: SOF: core: Only call sof_ops_free() on remove if the probe was successful")
    Cc: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: https://lore.kernel.org/r/20231009115437.99976-2-maarten.lankhorst@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: ipc4-topology: Use size_add() in call to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 13:09:11 2023 -0600

    ASoC: SOF: ipc4-topology: Use size_add() in call to struct_size()
    
    [ Upstream commit 3746284c233d5cf5f456400e61cd4a46a69c6e8c ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound,
    the protection that `struct_size()` adds against potential integer
    overflows is defeated. Fix this by hardening call to `struct_size()`
    with `size_add()`.
    
    Fixes: f9efae954905 ("ASoC: SOF: ipc4-topology: Add support for base config extension")
    Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/ZQSr15AYJpDpipg6@work
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
backlight: pwm_bl: Disable PWM on shutdown, suspend and remove [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Oct 9 11:32:23 2023 +0200

    backlight: pwm_bl: Disable PWM on shutdown, suspend and remove
    
    [ Upstream commit 40da4737717b252fd01d92ff38d3b95a491167cc ]
    
    Since commit 00e7e698bff1 ("backlight: pwm_bl: Configure pwm only once
    per backlight toggle") calling pwm_backlight_power_off() doesn't disable
    the PWM any more. However this is necessary to suspend because PWM
    drivers usually refuse to suspend if they are still enabled.
    
    Also adapt shutdown and remove callbacks to disable the PWM for similar
    reasons.
    
    Fixes: 00e7e698bff1 ("backlight: pwm_bl: Configure pwm only once per backlight toggle")
    Reported-by: Aisheng Dong <aisheng.dong@nxp.com>
    Tested-by: Aisheng Dong <aisheng.dong@nxp.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Link: https://lore.kernel.org/r/20231009093223.227286-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-core: use pr_warn_ratelimited() in bio_check_ro() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Nov 7 19:12:47 2023 +0800

    blk-core: use pr_warn_ratelimited() in bio_check_ro()
    
    [ Upstream commit 1b0a151c10a6d823f033023b9fdd9af72a89591b ]
    
    If one of the underlying disks of raid or dm is set to read-only, then
    each io will generate new log, which will cause message storm. This
    environment is indeed problematic, however we can't make sure our
    naive custormer won't do this, hence use pr_warn_ratelimited() to
    prevent message storm in this case.
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Fixes: 57e95e4670d1 ("block: fix and cleanup bio_check_ro")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20231107111247.2157820-1-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: hci_sync: Fix Opcode prints in bt_dev_dbg/err [+ + +]
Author: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Date:   Wed Oct 18 16:47:35 2023 +0200

    Bluetooth: hci_sync: Fix Opcode prints in bt_dev_dbg/err
    
    [ Upstream commit 530886897c789cf77c9a0d4a7cc5549f0768b5f8 ]
    
    Printed Opcodes may be missing leading zeros:
    
            Bluetooth: hci0: Opcode 0x c03 failed: -110
    
    Fix this by always printing leading zeros:
    
            Bluetooth: hci0: Opcode 0x0c03 failed: -110
    
    Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages")
    Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution")
    Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Pass BIG encryption info through QoS [+ + +]
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date:   Wed Sep 6 17:01:03 2023 +0300

    Bluetooth: ISO: Pass BIG encryption info through QoS
    
    [ Upstream commit 1d11d70d1f6b23e7d3fc00396c17b90b876162a4 ]
    
    This enables a broadcast sink to be informed if the PA
    it has synced with is associated with an encrypted BIG,
    by retrieving the socket QoS and checking the encryption
    field.
    
    After PA sync has been successfully established and the
    first BIGInfo advertising report is received, a new hcon
    is added and notified to the ISO layer. The ISO layer
    sets the encryption field of the socket and hcon QoS
    according to the encryption parameter of the BIGInfo
    advertising report event.
    
    After that, the userspace is woken up, and the QoS of the
    new PA sync socket can be read, to inspect the encryption
    field and follow up accordingly.
    
    Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync [+ + +]
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date:   Thu Aug 17 09:44:27 2023 +0300

    Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync
    
    [ Upstream commit fbdc4bc47268953c80853489f696e02d61f9a2c6 ]
    
    This commit implements defer setup support for the Broadcast Sink
    scenario: By setting defer setup on a broadcast socket before calling
    listen, the user is able to trigger the PA sync and BIG sync procedures
    separately.
    
    This is useful if the user first wants to synchronize to the periodic
    advertising transmitted by a Broadcast Source, and trigger the BIG sync
    procedure later on.
    
    If defer setup is set, once a PA sync established event arrives, a new
    hcon is created and notified to the ISO layer. A child socket associated
    with the PA sync connection will be added to the accept queue of the
    listening socket.
    
    Once the accept call returns the fd for the PA sync child socket, the
    user should call read on that fd. This will trigger the BIG create sync
    procedure, and the PA sync socket will become a listening socket itself.
    
    When the BIG sync established event is notified to the ISO layer, the
    bis connections will be added to the accept queue of the PA sync parent.
    The user should call accept on the PA sync socket to get the final bis
    connections.
    
    Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Make handle of hci_conn be unique [+ + +]
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Wed Oct 11 17:57:31 2023 +0800

    Bluetooth: Make handle of hci_conn be unique
    
    [ Upstream commit 181a42edddf51d5d9697ecdf365d72ebeab5afb0 ]
    
    The handle of new hci_conn is always HCI_CONN_HANDLE_MAX + 1 if
    the handle of the first hci_conn entry in hci_dev->conn_hash->list
    is not HCI_CONN_HANDLE_MAX + 1. Use ida to manage the allocation of
    hci_conn->handle to make it be unique.
    
    Fixes: 9f78191cc9f1 ("Bluetooth: hci_conn: Always allocate unique handles")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, x64: Fix tailcall infinite loop [+ + +]
Author: Leon Hwang <hffilwlqm@gmail.com>
Date:   Tue Sep 12 23:04:41 2023 +0800

    bpf, x64: Fix tailcall infinite loop
    
    [ Upstream commit 2b5dcb31a19a2e0acd869b12c9db9b2d696ef544 ]
    
    From commit ebf7d1f508a73871 ("bpf, x64: rework pro/epilogue and tailcall
    handling in JIT"), the tailcall on x64 works better than before.
    
    From commit e411901c0b775a3a ("bpf: allow for tailcalls in BPF subprograms
    for x64 JIT"), tailcall is able to run in BPF subprograms on x64.
    
    From commit 5b92a28aae4dd0f8 ("bpf: Support attaching tracing BPF program
    to other BPF programs"), BPF program is able to trace other BPF programs.
    
    How about combining them all together?
    
    1. FENTRY/FEXIT on a BPF subprogram.
    2. A tailcall runs in the BPF subprogram.
    3. The tailcall calls the subprogram's caller.
    
    As a result, a tailcall infinite loop comes up. And the loop would halt
    the machine.
    
    As we know, in tail call context, the tail_call_cnt propagates by stack
    and rax register between BPF subprograms. So do in trampolines.
    
    Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
    Fixes: e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT")
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
    Link: https://lore.kernel.org/r/20230912150442.2009-3-hffilwlqm@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, x86: allow function arguments up to 12 for TRACING [+ + +]
Author: Menglong Dong <imagedong@tencent.com>
Date:   Thu Jul 13 12:07:37 2023 +0800

    bpf, x86: allow function arguments up to 12 for TRACING
    
    [ Upstream commit 473e3150e30a2db4199e6bad68c0be11279d1c34 ]
    
    For now, the BPF program of type BPF_PROG_TYPE_TRACING can only be used
    on the kernel functions whose arguments count less than or equal to 6, if
    not considering '> 8 bytes' struct argument. This is not friendly at all,
    as too many functions have arguments count more than 6.
    
    According to the current kernel version, below is a statistics of the
    function arguments count:
    
    argument count | function count
    7              | 704
    8              | 270
    9              | 84
    10             | 47
    11             | 47
    12             | 27
    13             | 22
    14             | 5
    15             | 0
    16             | 1
    
    Therefore, let's enhance it by increasing the function arguments count
    allowed in arch_prepare_bpf_trampoline(), for now, only x86_64.
    
    For the case that we don't need to call origin function, which means
    without BPF_TRAMP_F_CALL_ORIG, we need only copy the function arguments
    that stored in the frame of the caller to current frame. The 7th and later
    arguments are stored in "$rbp + 0x18", and they will be copied to the
    stack area following where register values are saved.
    
    For the case with BPF_TRAMP_F_CALL_ORIG, we need prepare the arguments
    in stack before call origin function, which means we need alloc extra
    "8 * (arg_count - 6)" memory in the top of the stack. Note, there should
    not be any data be pushed to the stack before calling the origin function.
    So 'rbx' value will be stored on a stack position higher than where stack
    arguments are stored for BPF_TRAMP_F_CALL_ORIG.
    
    According to the research of Yonghong, struct members should be all in
    register or all on the stack. Meanwhile, the compiler will pass the
    argument on regs if the remaining regs can hold the argument. Therefore,
    we need save the arguments in order. Otherwise, disorder of the args can
    happen. For example:
    
      struct foo_struct {
          long a;
          int b;
      };
      int foo(char, char, char, char, char, struct foo_struct,
              char);
    
    the arg1-5,arg7 will be passed by regs, and arg6 will by stack. Therefore,
    we should save/restore the arguments in the same order with the
    declaration of foo(). And the args used as ctx in stack will be like this:
    
      reg_arg6   -- copy from regs
      stack_arg2 -- copy from stack
      stack_arg1
      reg_arg5   -- copy from regs
      reg_arg4
      reg_arg3
      reg_arg2
      reg_arg1
    
    We use EMIT3_off32() or EMIT4() for "lea" and "sub". The range of the
    imm in "lea" and "sub" is [-128, 127] if EMIT4() is used. Therefore,
    we use EMIT3_off32() instead if the imm out of the range.
    
    It works well for the FENTRY/FEXIT/MODIFY_RETURN.
    
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20230713040738.1789742-3-imagedong@tencent.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: 2b5dcb31a19a ("bpf, x64: Fix tailcall infinite loop")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, x86: initialize the variable "first_off" in save_args() [+ + +]
Author: Menglong Dong <imagedong@tencent.com>
Date:   Wed Jul 19 19:03:30 2023 +0800

    bpf, x86: initialize the variable "first_off" in save_args()
    
    commit 492e797fdab25f2d8eb1b6bb3236f4aac474f878 upstream.
    
    As Dan Carpenter reported, the variable "first_off" which is passed to
    clean_stack_garbage() in save_args() can be uninitialized, which can
    cause runtime warnings with KMEMsan. Therefore, init it with 0.
    
    Fixes: 473e3150e30a ("bpf, x86: allow function arguments up to 12 for TRACING")
    Cc: Hao Peng <flyingpeng@tencent.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/bpf/09784025-a812-493f-9829-5e26c8691e07@moroto.mountain/
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Link: https://lore.kernel.org/r/20230719110330.2007949-1-imagedong@tencent.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf, x86: save/restore regs with BPF_DW size [+ + +]
Author: Menglong Dong <imagedong@tencent.com>
Date:   Thu Jul 13 12:07:36 2023 +0800

    bpf, x86: save/restore regs with BPF_DW size
    
    [ Upstream commit 02a6dfa8ff43efb1c989f87a4d862aedf436088a ]
    
    As we already reserve 8 byte in the stack for each reg, it is ok to
    store/restore the regs in BPF_DW size. This will make the code in
    save_regs()/restore_regs() simpler.
    
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20230713040738.1789742-2-imagedong@tencent.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: 2b5dcb31a19a ("bpf, x64: Fix tailcall infinite loop")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Check map->usercnt after timer->timer is assigned [+ + +]
Author: Hou Tao <houtao1@huawei.com>
Date:   Mon Oct 30 14:36:16 2023 +0800

    bpf: Check map->usercnt after timer->timer is assigned
    
    [ Upstream commit fd381ce60a2d79cc967506208085336d3d268ae0 ]
    
    When there are concurrent uref release and bpf timer init operations,
    the following sequence diagram is possible. It will break the guarantee
    provided by bpf_timer: bpf_timer will still be alive after userspace
    application releases or unpins the map. It also will lead to kmemleak
    for old kernel version which doesn't release bpf_timer when map is
    released.
    
    bpf program X:
    
    bpf_timer_init()
      lock timer->lock
        read timer->timer as NULL
        read map->usercnt != 0
    
                    process Y:
    
                    close(map_fd)
                      // put last uref
                      bpf_map_put_uref()
                        atomic_dec_and_test(map->usercnt)
                          array_map_free_timers()
                            bpf_timer_cancel_and_free()
                              // just return
                              read timer->timer is NULL
    
        t = bpf_map_kmalloc_node()
        timer->timer = t
      unlock timer->lock
    
    Fix the problem by checking map->usercnt after timer->timer is assigned,
    so when there are concurrent uref release and bpf timer init, either
    bpf_timer_cancel_and_free() from uref release reads a no-NULL timer
    or the newly-added atomic64_read() returns a zero usercnt.
    
    Because atomic_dec_and_test(map->usercnt) and READ_ONCE(timer->timer)
    in bpf_timer_cancel_and_free() are not protected by a lock, so add
    a memory barrier to guarantee the order between map->usercnt and
    timer->timer. Also use WRITE_ONCE(timer->timer, x) to match the lockless
    read of timer->timer in bpf_timer_cancel_and_free().
    
    Reported-by: Hsin-Wei Hung <hsinweih@uci.edu>
    Closes: https://lore.kernel.org/bpf/CABcoxUaT2k9hWsS1tNgXyoU3E-=PuOgMn737qK984fbFmfYixQ@mail.gmail.com
    Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20231030063616.1653024-1-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix kfunc callback register type handling [+ + +]
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Wed Sep 13 01:32:10 2023 +0200

    bpf: Fix kfunc callback register type handling
    
    [ Upstream commit 06d686f771ddc27a8554cd8f5b22e071040dc90e ]
    
    The kfunc code to handle KF_ARG_PTR_TO_CALLBACK does not check the reg
    type before using reg->subprogno. This can accidently permit invalid
    pointers from being passed into callback helpers (e.g. silently from
    different paths). Likewise, reg->subprogno from the per-register type
    union may not be meaningful either. We need to reject any other type
    except PTR_TO_FUNC.
    
    Acked-by: Dave Marchevsky <davemarchevsky@fb.com>
    Fixes: 5d92ddc3de1b ("bpf: Add callback validation to kfunc verifier logic")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20230912233214.1518551-14-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix missed rcu read lock in bpf_task_under_cgroup() [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Sat Oct 7 13:59:44 2023 +0000

    bpf: Fix missed rcu read lock in bpf_task_under_cgroup()
    
    [ Upstream commit 29a7e00ffadddd8d68eff311de1bf12ae10687bb ]
    
    When employed within a sleepable program not under RCU protection, the
    use of 'bpf_task_under_cgroup()' may trigger a warning in the kernel log,
    particularly when CONFIG_PROVE_RCU is enabled:
    
      [ 1259.662357] WARNING: suspicious RCU usage
      [ 1259.662358] 6.5.0+ #33 Not tainted
      [ 1259.662360] -----------------------------
      [ 1259.662361] include/linux/cgroup.h:423 suspicious rcu_dereference_check() usage!
    
    Other info that might help to debug this:
    
      [ 1259.662366] rcu_scheduler_active = 2, debug_locks = 1
      [ 1259.662368] 1 lock held by trace/72954:
      [ 1259.662369]  #0: ffffffffb5e3eda0 (rcu_read_lock_trace){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x0/0xb0
    
    Stack backtrace:
    
      [ 1259.662385] CPU: 50 PID: 72954 Comm: trace Kdump: loaded Not tainted 6.5.0+ #33
      [ 1259.662391] Call Trace:
      [ 1259.662393]  <TASK>
      [ 1259.662395]  dump_stack_lvl+0x6e/0x90
      [ 1259.662401]  dump_stack+0x10/0x20
      [ 1259.662404]  lockdep_rcu_suspicious+0x163/0x1b0
      [ 1259.662412]  task_css_set.part.0+0x23/0x30
      [ 1259.662417]  bpf_task_under_cgroup+0xe7/0xf0
      [ 1259.662422]  bpf_prog_7fffba481a3bcf88_lsm_run+0x5c/0x93
      [ 1259.662431]  bpf_trampoline_6442505574+0x60/0x1000
      [ 1259.662439]  bpf_lsm_bpf+0x5/0x20
      [ 1259.662443]  ? security_bpf+0x32/0x50
      [ 1259.662452]  __sys_bpf+0xe6/0xdd0
      [ 1259.662463]  __x64_sys_bpf+0x1a/0x30
      [ 1259.662467]  do_syscall_64+0x38/0x90
      [ 1259.662472]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      [ 1259.662479] RIP: 0033:0x7f487baf8e29
      [...]
      [ 1259.662504]  </TASK>
    
    This issue can be reproduced by executing a straightforward program, as
    demonstrated below:
    
    SEC("lsm.s/bpf")
    int BPF_PROG(lsm_run, int cmd, union bpf_attr *attr, unsigned int size)
    {
            struct cgroup *cgrp = NULL;
            struct task_struct *task;
            int ret = 0;
    
            if (cmd != BPF_LINK_CREATE)
                    return 0;
    
            // The cgroup2 should be mounted first
            cgrp = bpf_cgroup_from_id(1);
            if (!cgrp)
                    goto out;
            task = bpf_get_current_task_btf();
            if (bpf_task_under_cgroup(task, cgrp))
                    ret = -1;
            bpf_cgroup_release(cgrp);
    
    out:
            return ret;
    }
    
    After running the program, if you subsequently execute another BPF program,
    you will encounter the warning.
    
    It's worth noting that task_under_cgroup_hierarchy() is also utilized by
    bpf_current_task_under_cgroup(). However, bpf_current_task_under_cgroup()
    doesn't exhibit this issue because it cannot be used in sleepable BPF
    programs.
    
    Fixes: b5ad4cdc46c7 ("bpf: Add bpf_task_under_cgroup() kfunc")
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Cc: Feng Zhou <zhoufeng.zf@bytedance.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Link: https://lore.kernel.org/bpf/20231007135945.4306-1-laoar.shao@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix unnecessary -EBUSY from htab_lock_bucket [+ + +]
Author: Song Liu <song@kernel.org>
Date:   Wed Oct 11 22:57:41 2023 -0700

    bpf: Fix unnecessary -EBUSY from htab_lock_bucket
    
    [ Upstream commit d35381aa73f7e1e8b25f3ed5283287a64d9ddff5 ]
    
    htab_lock_bucket uses the following logic to avoid recursion:
    
    1. preempt_disable();
    2. check percpu counter htab->map_locked[hash] for recursion;
       2.1. if map_lock[hash] is already taken, return -BUSY;
    3. raw_spin_lock_irqsave();
    
    However, if an IRQ hits between 2 and 3, BPF programs attached to the IRQ
    logic will not able to access the same hash of the hashtab and get -EBUSY.
    
    This -EBUSY is not really necessary. Fix it by disabling IRQ before
    checking map_locked:
    
    1. preempt_disable();
    2. local_irq_save();
    3. check percpu counter htab->map_locked[hash] for recursion;
       3.1. if map_lock[hash] is already taken, return -BUSY;
    4. raw_spin_lock().
    
    Similarly, use raw_spin_unlock() and local_irq_restore() in
    htab_unlock_bucket().
    
    Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked")
    Suggested-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/7a9576222aa40b1c84ad3a9ba3e64011d1a04d41.camel@linux.ibm.com
    Link: https://lore.kernel.org/bpf/20231012055741.3375999-1-song@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: make found_logical_ret parameter mandatory for function queue_scrub_stripe() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Oct 28 13:28:45 2023 +1030

    btrfs: make found_logical_ret parameter mandatory for function queue_scrub_stripe()
    
    [ Upstream commit 47e2b06b7b5cb356a987ba3429550c3a89ea89d6 ]
    
    [BUG]
    There is a compilation warning reported on commit ae76d8e3e135 ("btrfs:
    scrub: fix grouping of read IO"), where gcc (14.0.0 20231022 experimental)
    is reporting the following uninitialized variable:
    
      fs/btrfs/scrub.c: In function ‘scrub_simple_mirror.isra’:
      fs/btrfs/scrub.c:2075:29: error: ‘found_logical’ may be used uninitialized [-Werror=maybe-uninitialized[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized]]
       2075 |                 cur_logical = found_logical + BTRFS_STRIPE_LEN;
      fs/btrfs/scrub.c:2040:21: note: ‘found_logical’ was declared here
       2040 |                 u64 found_logical;
            |                     ^~~~~~~~~~~~~
    
    [CAUSE]
    This is a false alert, as @found_logical is passed as parameter
    @found_logical_ret of function queue_scrub_stripe().
    
    As long as queue_scrub_stripe() returned 0, we would update
    @found_logical_ret.  And if queue_scrub_stripe() returned >0 or <0, the
    caller would not utilized @found_logical, thus there should be nothing
    wrong.
    
    Although the triggering gcc is still experimental, it looks like the
    extra check on "if (found_logical_ret)" can sometimes confuse the
    compiler.
    
    Meanwhile the only caller of queue_scrub_stripe() is always passing a
    valid pointer, there is no need for such check at all.
    
    [FIX]
    Although the report itself is a false alert, we can still make it more
    explicit by:
    
    - Replace the check for @found_logical_ret with ASSERT()
    
    - Initialize @found_logical to U64_MAX
    
    - Add one extra ASSERT() to make sure @found_logical got updated
    
    Link: https://lore.kernel.org/linux-btrfs/87fs1x1p93.fsf@gentoo.org/
    Fixes: ae76d8e3e135 ("btrfs: scrub: fix grouping of read IO")
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    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: Sasha Levin <sashal@kernel.org>

btrfs: use u64 for buffer sizes in the tree search ioctls [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Oct 13 10:05:48 2023 +0100

    btrfs: use u64 for buffer sizes in the tree search ioctls
    
    [ Upstream commit dec96fc2dcb59723e041416b8dc53e011b4bfc2e ]
    
    In the tree search v2 ioctl we use the type size_t, which is an unsigned
    long, to track the buffer size in the local variable 'buf_size'. An
    unsigned long is 32 bits wide on a 32 bits architecture. The buffer size
    defined in struct btrfs_ioctl_search_args_v2 is a u64, so when we later
    try to copy the local variable 'buf_size' to the argument struct, when
    the search returns -EOVERFLOW, we copy only 32 bits which will be a
    problem on big endian systems.
    
    Fix this by using a u64 type for the buffer sizes, not only at
    btrfs_ioctl_tree_search_v2(), but also everywhere down the call chain
    so that we can use the u64 at btrfs_ioctl_tree_search_v2().
    
    Fixes: cc68a8a5a433 ("btrfs: new ioctl TREE_SEARCH_V2")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/linux-btrfs/ce6f4bd6-9453-4ffe-ba00-cee35495e10f@moroto.mountain/
    Signed-off-by: Filipe Manana <fdmanana@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>

 
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Sep 29 10:23:47 2023 +0200

    can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
    
    [ Upstream commit 6411959c10fe917288cbb1038886999148560057 ]
    
    If the "struct can_priv::echoo_skb" is accessed out of bounds, this
    would cause a kernel crash. Instead, issue a meaningful warning
    message and return with an error.
    
    Fixes: a6e4bc530403 ("can: make the number of echo skb's configurable")
    Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-5-91b5c1fd922c@pengutronix.de
    Reviewed-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: dev: can_restart(): don't crash kernel if carrier is OK [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Sep 28 21:58:23 2023 +0200

    can: dev: can_restart(): don't crash kernel if carrier is OK
    
    [ Upstream commit fe5c9940dfd8ba0c73672dddb30acd1b7a11d4c7 ]
    
    During testing, I triggered a can_restart() with the netif carrier
    being OK [1]. The BUG_ON, which checks if the carrier is OK, results
    in a fatal kernel crash. This is neither helpful for debugging nor for
    a production system.
    
    [1] The root cause is a race condition in can_restart() which will be
    fixed in the next patch.
    
    Do not crash the kernel, issue an error message instead, and continue
    restarting the CAN device anyway.
    
    Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
    Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-1-91b5c1fd922c@pengutronix.de
    Reviewed-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: dev: can_restart(): fix race condition between controller restart and netif_carrier_on() [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Sep 29 10:25:11 2023 +0200

    can: dev: can_restart(): fix race condition between controller restart and netif_carrier_on()
    
    [ Upstream commit 6841cab8c4504835e4011689cbdb3351dec693fd ]
    
    This race condition was discovered while updating the at91_can driver
    to use can_bus_off(). The following scenario describes how the
    converted at91_can driver would behave.
    
    When a CAN device goes into BUS-OFF state, the driver usually
    stops/resets the CAN device and calls can_bus_off().
    
    This function sets the netif carrier to off, and (if configured by
    user space) schedules a delayed work that calls can_restart() to
    restart the CAN device.
    
    The can_restart() function first checks if the carrier is off and
    triggers an error message if the carrier is OK.
    
    Then it calls the driver's do_set_mode() function to restart the
    device, then it sets the netif carrier to on. There is a race window
    between these two calls.
    
    The at91 CAN controller (observed on the sama5d3, a single core 32 bit
    ARM CPU) has a hardware limitation. If the device goes into bus-off
    while sending a CAN frame, there is no way to abort the sending of
    this frame. After the controller is enabled again, another attempt is
    made to send it.
    
    If the bus is still faulty, the device immediately goes back to the
    bus-off state. The driver calls can_bus_off(), the netif carrier is
    switched off and another can_restart is scheduled. This occurs within
    the race window before the original can_restart() handler marks the
    netif carrier as OK. This would cause the 2nd can_restart() to be
    called with an OK netif carrier, resulting in an error message.
    
    The flow of the 1st can_restart() looks like this:
    
    can_restart()
        // bail out if netif_carrier is OK
    
        netif_carrier_ok(dev)
        priv->do_set_mode(dev, CAN_MODE_START)
            // enable CAN controller
            // sama5d3 restarts sending old message
    
            // CAN devices goes into BUS_OFF, triggers IRQ
    
    // IRQ handler start
        at91_irq()
            at91_irq_err_line()
                can_bus_off()
                    netif_carrier_off()
                    schedule_delayed_work()
    // IRQ handler end
    
        netif_carrier_on()
    
    The 2nd can_restart() will be called with an OK netif carrier and the
    error message will be printed.
    
    To close the race window, first set the netif carrier to on, then
    restart the controller. In case the restart fails with an error code,
    roll back the netif carrier to off.
    
    Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
    Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-2-91b5c1fd922c@pengutronix.de
    Reviewed-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: etas_es58x: add missing a blank line after declaration [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Sun Sep 24 20:06:48 2023 +0900

    can: etas_es58x: add missing a blank line after declaration
    
    [ Upstream commit 4f8005092cafc194ba6a8e5f39626ba0b9f08271 ]
    
    Fix below checkpatch warning:
    
      WARNING: Missing a blank line after declarations
      #2233: FILE: drivers/net/can/usb/etas_es58x/es58x_core.c:2233:
      +             int ret = es58x_init_netdev(es58x_dev, ch_idx);
      +             if (ret) {
    
    Fixes: d8f26fd689dd ("can: etas_es58x: remove es58x_get_product_info()")
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://lore.kernel.org/all/20230924110914.183898-3-mailhol.vincent@wanadoo.fr
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: etas_es58x: rework the version check logic to silence -Wformat-truncation [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Sun Sep 24 20:06:47 2023 +0900

    can: etas_es58x: rework the version check logic to silence -Wformat-truncation
    
    [ Upstream commit 107e6f6fe6f38577baecf0e01f517c8607a3a625 ]
    
    Following [1], es58x_devlink.c now triggers the following
    format-truncation GCC warnings:
    
      drivers/net/can/usb/etas_es58x/es58x_devlink.c: In function ‘es58x_devlink_info_get’:
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=]
        201 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |                                         ^~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:30: note: directive argument in the range [0, 255]
        201 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |                              ^~~~~~~~~~~~~~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9
        201 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        202 |     fw_ver->major, fw_ver->minor, fw_ver->revision);
            |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=]
        211 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |                                         ^~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:30: note: directive argument in the range [0, 255]
        211 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |                              ^~~~~~~~~~~~~~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9
        211 |   snprintf(buf, sizeof(buf), "%02u.%02u.%02u",
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        212 |     bl_ver->major, bl_ver->minor, bl_ver->revision);
            |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:38: warning: ‘%03u’ directive output may be truncated writing between 3 and 5 bytes into a region of size between 2 and 4 [-Wformat-truncation=]
        221 |   snprintf(buf, sizeof(buf), "%c%03u/%03u",
            |                                      ^~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:30: note: directive argument in the range [0, 65535]
        221 |   snprintf(buf, sizeof(buf), "%c%03u/%03u",
            |                              ^~~~~~~~~~~~~
      drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:3: note: ‘snprintf’ output between 9 and 13 bytes into a destination of size 9
        221 |   snprintf(buf, sizeof(buf), "%c%03u/%03u",
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        222 |     hw_rev->letter, hw_rev->major, hw_rev->minor);
            |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This is not an actual bug because the sscanf() parsing makes sure that
    the u8 are only two digits long and the u16 only three digits long.
    Thus below declaration:
    
            char buf[max(sizeof("xx.xx.xx"), sizeof("axxx/xxx"))];
    
    allocates just what is needed to represent either of the versions.
    
    This warning was known but ignored because, at the time of writing,
    -Wformat-truncation was not present in the kernel, not even at W=3 [2].
    
    One way to silence this warning is to check the range of all sub
    version numbers are valid: [0, 99] for u8 and range [0, 999] for u16.
    
    The module already has a logic which considers that when all the sub
    version numbers are zero, the version number is not set. Note that not
    having access to the device specification, this was an arbitrary
    decision. This logic can thus be removed in favor of global check that
    would cover both cases:
    
      - the version number is not set (parsing failed)
      - the version number is not valid (paranoiac check to please gcc)
    
    Before starting to parse the product info string, set the version
    sub-numbers to the maximum unsigned integer thus violating the
    definitions of struct es58x_sw_version or struct es58x_hw_revision.
    
    Then, rework the es58x_sw_version_is_set() and
    es58x_hw_revision_is_set() functions: remove the check that the
    sub-numbers are non zero and replace it by a check that they fit in
    the expected number of digits. This done, rename the functions to
    reflect the change and rewrite the documentation. While doing so, also
    add a description of the return value.
    
    Finally, the previous version only checked that
    &es58x_hw_revision.letter was not the null character. Replace this
    check by an alphanumeric character check to make sure that we never
    return a special character or a non-printable one and update the
    documentation of struct es58x_hw_revision accordingly.
    
    All those extra checks are paranoid but have the merit to silence the
    newly introduced W=1 format-truncation warning [1].
    
    [1] commit 6d4ab2e97dcf ("extrawarn: enable format and stringop overflow warnings in W=1")
    Link: https://git.kernel.org/torvalds/c/6d4ab2e97dcf
    
    [2] https://lore.kernel.org/all/CAMZ6Rq+K+6gbaZ35SOJcR9qQaTJ7KR0jW=XoDKFkobjhj8CHhw@mail.gmail.com/
    
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Closes: https://lore.kernel.org/linux-can/20230914-carrousel-wrecker-720a08e173e9-mkl@pengutronix.de/
    Fixes: 9f06631c3f1f ("can: etas_es58x: export product information through devlink_ops::info_get()")
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://lore.kernel.org/all/20230924110914.183898-2-mailhol.vincent@wanadoo.fr
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
certs: Break circular dependency when selftest is modular [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Oct 16 13:21:44 2023 +0800

    certs: Break circular dependency when selftest is modular
    
    [ Upstream commit 04a93202ed7c3b451bf22d3ff4bcd379df27f299 ]
    
    The modular build fails because the self-test code depends on pkcs7
    which in turn depends on x509 which contains the self-test.
    
    Split the self-test out into its own module to break the cycle.
    
    Fixes: 3cde3174eb91 ("certs: Add FIPS selftests")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
chtls: fix tp->rcv_tstamp initialization [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Oct 20 12:57:36 2023 +0000

    chtls: fix tp->rcv_tstamp initialization
    
    [ Upstream commit 225d9ddbacb102621af6d28ff7bf5a0b4ce249d8 ]
    
    tp->rcv_tstamp should be set to tcp_jiffies, not tcp_time_stamp().
    
    Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Ayush Sawal <ayush.sawal@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: imx: imx8mq: correct error handling path [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Oct 1 20:26:18 2023 +0800

    clk: imx: imx8mq: correct error handling path
    
    [ Upstream commit 577ad169966e6e75b10e004389a3f79813e84b5d ]
    
    Avoid memory leak in error handling path. It does not make
    much sense for the SoC without clk driver, to make program behavior
    correct, let's fix it.
    
    Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202309240551.e46NllPa-lkp@intel.com/
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20231001122618.194498-1-peng.fan@oss.nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: imx8qxp: Fix elcdif_pll clock [+ + +]
Author: Robert Chiras <robert.chiras@nxp.com>
Date:   Tue Sep 12 17:19:00 2023 +0800

    clk: imx: imx8qxp: Fix elcdif_pll clock
    
    [ Upstream commit 15cee75dacb82ade710d61bfd536011933ef9bf2 ]
    
    Move the elcdif_pll clock initialization before the lcd_clk, since the
    elcdif_clk needs to be initialized ahead of lcd_clk, being its parent.
    This change fixes issues with the LCD clocks during suspend/resume.
    
    Fixes: babfaa9556d7 ("clk: imx: scu: add more scu clocks")
    Suggested-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
    Acked-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
    Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20230912-imx8-clk-v1-v1-2-69a34bcfcae1@nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: Select MXC_CLK for CLK_IMX8QXP [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Thu Sep 21 12:23:54 2023 +0300

    clk: imx: Select MXC_CLK for CLK_IMX8QXP
    
    [ Upstream commit 317e69c49b4ceef8aebb47d771498ccb3571bdf9 ]
    
    If the i.MX8QXP clock provider is built-in but the MXC_CLK is
    built as module, build fails:
    
    aarch64-linux-ld: drivers/clk/imx/clk-imx8-acm.o: in function `imx8_acm_clk_probe':
    clk-imx8-acm.c:(.text+0x3d0): undefined reference to `imx_check_clk_hws'
    
    Fix that by selecting MXC_CLK in case of CLK_IMX8QXP.
    
    Fixes: c2cccb6d0b33 ("clk: imx: add imx8qxp clk driver")
    Closes: https://lore.kernel.org/all/8b77219e-b59e-40f1-96f1-980a0b2debcf@infradead.org/
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: keystone: pll: fix a couple NULL vs IS_ERR() checks [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Oct 5 17:01:57 2023 +0300

    clk: keystone: pll: fix a couple NULL vs IS_ERR() checks
    
    [ Upstream commit a5d14f8b551eb1551c10053653ee8e27f19672fa ]
    
    The clk_register_divider() and clk_register_mux() functions returns
    error pointers on error but this code checks for NULL.  Fix that.
    
    Fixes: b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/d9da4c97-0da9-499f-9a21-1f8e3f148dc1@moroto.mountain
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: linux/clk-provider.h: fix kernel-doc warnings and typos [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Sep 30 15:14:26 2023 -0700

    clk: linux/clk-provider.h: fix kernel-doc warnings and typos
    
    [ Upstream commit 84aefafe6b294041b7fa0757414c4a29c1bdeea2 ]
    
    Fix spelling of "Structure".
    
    Fix multiple kernel-doc warnings:
    
    clk-provider.h:269: warning: Function parameter or member 'recalc_rate' not described in 'clk_ops'
    clk-provider.h:468: warning: Function parameter or member 'parent_data' not described in 'clk_hw_register_fixed_rate_with_accuracy_parent_data'
    clk-provider.h:468: warning: Excess function parameter 'parent_name' description in 'clk_hw_register_fixed_rate_with_accuracy_parent_data'
    clk-provider.h:482: warning: Function parameter or member 'parent_data' not described in 'clk_hw_register_fixed_rate_parent_accuracy'
    clk-provider.h:482: warning: Excess function parameter 'parent_name' description in 'clk_hw_register_fixed_rate_parent_accuracy'
    clk-provider.h:687: warning: Function parameter or member 'flags' not described in 'clk_divider'
    clk-provider.h:1164: warning: Function parameter or member 'flags' not described in 'clk_fractional_divider'
    clk-provider.h:1164: warning: Function parameter or member 'approximation' not described in 'clk_fractional_divider'
    clk-provider.h:1213: warning: Function parameter or member 'flags' not described in 'clk_multiplier'
    
    Fixes: 9fba738a53dd ("clk: add duty cycle support")
    Fixes: b2476490ef11 ("clk: introduce the common clock framework")
    Fixes: 2d34f09e79c9 ("clk: fixed-rate: Add support for specifying parents via DT/pointers")
    Fixes: f5290d8e4f0c ("clk: asm9260: use parent index to link the reference clock")
    Fixes: 9d9f78ed9af0 ("clk: basic clock hardware types")
    Fixes: e2d0e90fae82 ("clk: new basic clk type for fractional divider")
    Fixes: f2e0a53271a4 ("clk: Add a basic multiplier clock")
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-clk@vger.kernel.org
    Link: https://lore.kernel.org/r/20230930221428.18463-1-rdunlap@infradead.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Sep 1 10:46:58 2023 +0800

    clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230901024658.23405-1-jiasheng@iscas.ac.cn
    Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:03 2023 +0800

    clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data
    
    [ Upstream commit b82681042724924ae3ba0f2f2eeec217fa31e830 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 1aca9939bf72 ("clk: mediatek: Add MT6765 clock support")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-1-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:04 2023 +0800

    clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 1f57f78fbacf630430bf954e5a84caafdfea30c0 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-2-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:05 2023 +0800

    clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 606f6366a35a3329545e38129804d65ef26ed7d2 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 96596aa06628 ("clk: mediatek: add clk support for MT6797")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-3-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:06 2023 +0800

    clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 0884393c63cc9a1772f7121a6645ba7bd76feeb9 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 3b5e748615e7 ("clk: mediatek: add clock support for MT7629 SoC")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-4-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:07 2023 +0800

    clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 2befa515c1bb6cdd33c262b909d93d1973a219aa ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 3b5e748615e7 ("clk: mediatek: add clock support for MT7629 SoC")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-5-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: fix double free in mtk_clk_register_pllfh() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Oct 24 08:00:53 2023 +0300

    clk: mediatek: fix double free in mtk_clk_register_pllfh()
    
    [ Upstream commit bd54ccc0f147019dac38e7841876a7415459b875 ]
    
    The mtk_clk_register_pll_ops() currently frees the "pll" parameter.
    The function has two callers, mtk_clk_register_pll() and
    mtk_clk_register_pllfh().  The first one, the _pll() function relies on
    the free, but for the second _pllfh() function it causes a double free
    bug.
    
    Really the frees should be done in the caller because that's where
    the allocation is.
    
    Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/cd7fa365-28cc-4c34-ac64-6da57c98baa6@moroto.mountain
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: npcm7xx: Fix incorrect kfree [+ + +]
Author: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Date:   Sat Sep 23 15:31:27 2023 +0200

    clk: npcm7xx: Fix incorrect kfree
    
    [ Upstream commit bbc5080bef4a245106aa8e8d424ba8847ca7c0ca ]
    
    The corresponding allocation is:
    
    > npcm7xx_clk_data = kzalloc(struct_size(npcm7xx_clk_data, hws,
    >                            NPCM7XX_NUM_CLOCKS), GFP_KERNEL);
    
    ... so, kfree should be applied to npcm7xx_clk_data, not
    npcm7xx_clk_data->hws.
    
    Fixes: fcfd14369856 ("clk: npcm7xx: add clock controller")
    Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
    Link: https://lore.kernel.org/r/20230923133127.1815621-1-j.neuschaefer@gmx.net
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config [+ + +]
Author: Varadarajan Narayanan <quic_varada@quicinc.com>
Date:   Fri Oct 20 11:49:34 2023 +0530

    clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config
    
    [ Upstream commit 5b7a4d3d2b33398330aef69e0ff5656273483587 ]
    
    The earlier 'l' value of 0x3e is for 1.5GHz. Not all SKUs support
    this frequency. Hence set it to 0x2d to get 1.1GHz which is
    supported in all SKUs.
    
    The frequency can still increase above this initial configuration
    made here when the cpufreq driver picks a different OPP.
    
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Fixes: c7ef7fbb1ccf ("clk: qcom: apss-ipq-pll: add support for IPQ5332")
    Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
    Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Link: https://lore.kernel.org/r/00e6be6cb9cee56628123a64ade118d0a752018b.1697781921.git.quic_varada@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll [+ + +]
Author: Varadarajan Narayanan <quic_varada@quicinc.com>
Date:   Fri Oct 20 11:49:33 2023 +0530

    clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll
    
    [ Upstream commit 267e29198436a8cb6770213471f72502c895096a ]
    
    The set rate and determine rate operations are different between
    Stromer and Stromer Plus PLLs. Since the programming sequence is
    different, the PLLs dont get configured properly and random,
    inexplicable crash/freeze is seen. Hence, use stromer plus ops
    for ipq_pll_stromer_plus.
    
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Fixes: c7ef7fbb1ccf ("clk: qcom: apss-ipq-pll: add support for IPQ5332")
    Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
    Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Link: https://lore.kernel.org/r/c86ecaa23dc4f39650bcf4a3bd54a617a932e4fd.1697781921.git.quic_varada@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-alpha-pll: introduce stromer plus ops [+ + +]
Author: Varadarajan Narayanan <quic_varada@quicinc.com>
Date:   Fri Oct 20 11:49:32 2023 +0530

    clk: qcom: clk-alpha-pll: introduce stromer plus ops
    
    [ Upstream commit 84da48921a97cee3dd1391659e93ee01d122b78b ]
    
    Stromer plus APSS PLL does not support dynamic frequency scaling.
    To switch between frequencies, we have to shut down the PLL,
    configure the L and ALPHA values and turn on again. So introduce the
    separate set of ops for Stromer Plus PLL.
    
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
    Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Link: https://lore.kernel.org/r/2affa6c63ff0c4342230623a7d4eef02ec7c02d4.1697781921.git.quic_varada@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 267e29198436 ("clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-rcg2: Fix clock rate overflow for high parent frequencies [+ + +]
Author: Devi Priya <quic_devipriy@quicinc.com>
Date:   Fri Sep 1 13:06:40 2023 +0530

    clk: qcom: clk-rcg2: Fix clock rate overflow for high parent frequencies
    
    [ Upstream commit f7b7d30158cff246667273bd2a62fc93ee0725d2 ]
    
    If the parent clock rate is greater than unsigned long max/2 then
    integer overflow happens when calculating the clock rate on 32-bit systems.
    As RCG2 uses half integer dividers, the clock rate is first being
    multiplied by 2 which will overflow the unsigned long max value.
    Hence, replace the common pattern of doing 64-bit multiplication
    and then a do_div() call with simpler mult_frac call.
    
    Fixes: bcd61c0f535a ("clk: qcom: Add support for root clock generators (RCGs)")
    Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Link: https://lore.kernel.org/r/20230901073640.4973-1-quic_devipriy@quicinc.com
    [bjorn: Also drop unnecessary {} around single statements]
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: config IPQ_APSS_6018 should depend on QCOM_SMEM [+ + +]
Author: Varadarajan Narayanan <quic_varada@quicinc.com>
Date:   Fri Oct 20 11:49:31 2023 +0530

    clk: qcom: config IPQ_APSS_6018 should depend on QCOM_SMEM
    
    [ Upstream commit 6a15647d0adc686226045e8046369f34d6ab03ed ]
    
    The config IPQ_APSS_6018 should depend on QCOM_SMEM, to
    avoid the following error reported by 'kernel test robot'
    
            loongarch64-linux-ld: drivers/clk/qcom/apss-ipq6018.o: in function `apss_ipq6018_probe':
            >> apss-ipq6018.c:(.text+0xd0): undefined reference to `qcom_smem_get_soc_id'
    
    Fixes: 5e77b4ef1b19 ("clk: qcom: Add ipq6018 apss clock controller")
    Reported-by: kernel test robot <yujie.liu@intel.com>
    Closes: https://lore.kernel.org/r/202310181650.g8THtfsm-lkp@intel.com/
    Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Link: https://lore.kernel.org/r/f4c4d65a7cb71e807d6d472c63c7718408c8f5f0.1697781921.git.quic_varada@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-msm8996: Remove RPM bus clocks [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Thu Aug 31 11:39:14 2023 +0200

    clk: qcom: gcc-msm8996: Remove RPM bus clocks
    
    [ Upstream commit 4afda5f6bcdf673ef2556fcfa458daf3a5a648d8 ]
    
    The GCC driver contains clocks that are owned (meaning configured and
    scaled) by the RPM core.
    
    Remove them from Linux to stop interjecting the RPM's logic.
    
    Fixes: b1e010c0730a ("clk: qcom: Add MSM8996 Global Clock Control (GCC) driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230830-topic-rpmbusclocks8996gcc-v1-1-9e99bedcdc3b@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm8150: Fix gcc_sdcc2_apps_clk_src [+ + +]
Author: Danila Tikhonov <danila@jiaxyga.com>
Date:   Wed Sep 13 20:56:11 2023 +0300

    clk: qcom: gcc-sm8150: Fix gcc_sdcc2_apps_clk_src
    
    [ Upstream commit 7138c244fb293f24ce8ab782961022eff00a10c4 ]
    
    Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg
    didn't update its configuration" error.
    
    Fixes: 2a1d7eb854bb ("clk: qcom: gcc: Add global clock controller driver for SM8150")
    Tested-by: Arseniy Velikanov <adomerlee@gmail.com>
    Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230913175612.8685-1-danila@jiaxyga.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq5332: Drop set rate parent from gpll0 dependent clocks [+ + +]
Author: Varadarajan Narayanan <quic_varada@quicinc.com>
Date:   Thu Aug 31 14:58:53 2023 +0530

    clk: qcom: ipq5332: Drop set rate parent from gpll0 dependent clocks
    
    [ Upstream commit ccd8ab030643040600a663edde56b434b6f4fb6c ]
    
    IPQ5332's GPLL0's nominal/turbo frequency is 800MHz.
    This must not be scaled based on the requirement of
    dependent clocks. Hence remove the CLK_SET_RATE_PARENT
    flag.
    
    Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC")
    Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Reviewed-by: Kathiravan T <quic_kathirav@quicinc.com>
    Link: https://lore.kernel.org/r/1693474133-10467-1-git-send-email-quic_varada@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq5332: drop the CLK_SET_RATE_PARENT flag from GPLL clocks [+ + +]
Author: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Date:   Thu Sep 14 12:29:55 2023 +0530

    clk: qcom: ipq5332: drop the CLK_SET_RATE_PARENT flag from GPLL clocks
    
    [ Upstream commit 5635ef0bd1052420bc659a00be6fd0c60cec5cb9 ]
    
    GPLL clock rates are fixed and shouldn't be scaled based on the
    request from dependent clocks. Doing so will result in the unexpected
    behaviour. So drop the CLK_SET_RATE_PARENT flag from the GPLL clocks.
    
    Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC")
    Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-5-c8ceb1a37680@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq9574: drop the CLK_SET_RATE_PARENT flag from GPLL clocks [+ + +]
Author: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Date:   Thu Sep 14 12:29:54 2023 +0530

    clk: qcom: ipq9574: drop the CLK_SET_RATE_PARENT flag from GPLL clocks
    
    [ Upstream commit 99a8f8764b70158a712992640a6be46a8fd79d15 ]
    
    GPLL clock rates are fixed and shouldn't be scaled based on the request
    from dependent clocks. Doing so will result in the unexpected behaviour.
    So drop the CLK_SET_RATE_PARENT flag from the GPLL clocks.
    
    ----
    Changes in V2:
            - No changes
    
    Fixes: d75b82cff488 ("clk: qcom: Add Global Clock Controller driver for IPQ9574")
    Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-4-c8ceb1a37680@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-msm8998: Don't check halt bit on some branch clks [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Aug 9 21:20:27 2023 +0200

    clk: qcom: mmcc-msm8998: Don't check halt bit on some branch clks
    
    [ Upstream commit 9906c4140897bbdbff7bb71c6ae67903cb9954ce ]
    
    Some branch clocks are governed externally and we're only supposed to
    send a request concerning their shutdown, not actually ensure it happens.
    
    Use the BRANCH_HALT_SKIP define to skip checking the halt bit.
    
    Fixes: d14b15b5931c ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver")
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230531-topic-8998_mmssclk-v3-4-ba1b1fd9ee75@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-msm8998: Fix the SMMU GDSC [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Aug 9 21:20:28 2023 +0200

    clk: qcom: mmcc-msm8998: Fix the SMMU GDSC
    
    [ Upstream commit 1fc62c8347397faf4e18249e88ecd4470c0a5357 ]
    
    The SMMU GDSC doesn't have to be ALWAYS-ON and shouldn't feature the
    HW_CTRL flag (it's separate from hw_ctrl_addr).  In addition to that,
    it should feature a cxc entry for bimc_smmu_axi_clk and be marked as
    votable.
    
    Fix all of these issues.
    
    Fixes: d14b15b5931c ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://lore.kernel.org/r/20230531-topic-8998_mmssclk-v3-5-ba1b1fd9ee75@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: ralink: mtmips: quiet unused variable warning [+ + +]
Author: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Date:   Sun Aug 27 04:39:32 2023 +0200

    clk: ralink: mtmips: quiet unused variable warning
    
    [ Upstream commit 619102313466eaf8a6ac188e711f5df749dac6d4 ]
    
    When CONFIG_OF is disabled then the matching table is not referenced and
    the following warning appears:
    
    drivers/clk/ralink/clk-mtmips.c:821:34: warning: unused variable 'mtmips_of_match' [-Wunused-const-variable]
    821 |   static const struct of_device_id mtmips_of_match[] = {
        |                          ^
    
    There are two match tables in the driver: one for the clock driver and the
    other for the reset driver. The only difference between them is that the
    clock driver uses 'data' and does not have 'ralink,rt2880-reset' compatible.
    Both just can be merged into a single one just by adding the compatible
    'ralink,rt2880-reset' entry to 'mtmips_of_match[]', which will allow it to
    be used for 'mtmips_clk_driver' (which doesn't use the data) as well as for
    'mtmips_clk_init()' (which doesn't need get called for 'ralink,rt2880-reset').
    
    Doing in this way ensures that 'CONFIG_OF' is not disabled anymore so the
    above warning disapears.
    
    Fixes: 6f3b15586eef ("clk: ralink: add clock and reset driver for MTMIPS SoCs")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202307242310.CdOnd2py-lkp@intel.com/
    Suggested-by: Arnd Bergmann <arnd@kernel.org>
    Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
    Link: https://lore.kernel.org/r/20230827023932.501102-1-sergio.paracuellos@gmail.com
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rcar-gen3: Extend SDnH divider table [+ + +]
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Thu Sep 28 10:03:17 2023 +0200

    clk: renesas: rcar-gen3: Extend SDnH divider table
    
    [ Upstream commit d5252d9697a3e7007c741e9c103073868955a304 ]
    
    The clock dividers might be used with clock stop bit enabled or not.
    Current tables only support recommended values from the datasheet.  This
    might result in warnings like below because no valid clock divider is
    found. Resulting in a 0 divider.
    
    There are Renesas ARM Trusted Firmware version out there which e.g.
    configure 0x201 (shifted logical right by 2: 0x80) and with this match
    the added { STPnHCK | 0, 1 }:
    
    https://github.com/renesas-rcar/arm-trusted-firmware/blob/rcar_gen3_v2.3/drivers/renesas/rcar/emmc/emmc_init.c#L108
    
    ------------[ cut here ]------------
    sd1h: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
    WARNING: CPU: 1 PID: 1 at drivers/clk/clk-divider.c:141 divider_recalc_rate+0x48/0x70
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.52 #1
    Hardware name: Custom board based on r8a7796 (DT)
    pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : divider_recalc_rate+0x48/0x70
    ...
    ------------[ cut here ]------------
    
    Fixes: bb6d3fa98a41 ("clk: renesas: rcar-gen3: Switch to new SD clock handling")
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    [wsa: extended the table to 5 entries, added comments, reword commit message a little]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230928080317.28224-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rzg2l: Fix computation formula [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Fri Sep 29 08:38:52 2023 +0300

    clk: renesas: rzg2l: Fix computation formula
    
    [ Upstream commit a2b23159499efd36b2d63b3c4534075d12ddc97a ]
    
    According to the hardware manual for RZ/G2L
    (r01uh0914ej0130-rzg2l-rzg2lc.pdf), the computation formula for PLL rate
    is as follows:
    
        Fout = ((m + k/65536) * Fin) / (p * 2^s)
    
    and k has values in the range [-32768, 32767].  Dividing k by 65536 with
    integer arithmetic gives zero all the time, causing slight differences
    b/w what has been set vs. what is displayed.  Thus, get rid of this and
    decompose the formula before dividing k by 65536.
    
    Fixes: ef3c613ccd68a ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230929053915.1530607-6-claudiu.beznea@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rzg2l: Lock around writes to mux register [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Fri Sep 29 08:38:50 2023 +0300

    clk: renesas: rzg2l: Lock around writes to mux register
    
    [ Upstream commit d2692ed490e680a41401cef879adebcfafb4298f ]
    
    The SD MUX output (SD0) is further divided by 4 in G2{L,UL}.  The
    divided clock is SD0_DIV4. SD0_DIV4 is registered with
    CLK_SET_RATE_PARENT which means a rate request for it is propagated to
    the MUX and could reach rzg2l_cpg_sd_clk_mux_set_parent() concurrently
    with the users of SD0.
    Add proper locking to avoid concurrent accesses on SD MUX set rate
    registers.
    
    Fixes: eaff33646f4cb ("clk: renesas: rzg2l: Add SDHI clk mux support")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230929053915.1530607-4-claudiu.beznea@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rzg2l: Trust value returned by hardware [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Fri Sep 29 08:38:51 2023 +0300

    clk: renesas: rzg2l: Trust value returned by hardware
    
    [ Upstream commit bf51d3b2d048c312764a55d91d67a85ee5535e31 ]
    
    The onitial value of the CPG_PL2SDHI_DSEL bits 0..1 or 4..6 is 01b.  The
    hardware user's manual (r01uh0914ej0130-rzg2l-rzg2lc.pdf) specifies that
    setting 0 is prohibited.  Hence rzg2l_cpg_sd_clk_mux_get_parent() should
    just read CPG_PL2SDHI_DSEL, trust the value, and return the proper clock
    parent index based on the value read.
    
    Fixes: eaff33646f4cb ("clk: renesas: rzg2l: Add SDHI clk mux support")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230929053915.1530607-5-claudiu.beznea@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rzg2l: Use FIELD_GET() for PLL register fields [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Tue Sep 12 07:51:33 2023 +0300

    clk: renesas: rzg2l: Use FIELD_GET() for PLL register fields
    
    [ Upstream commit 72977f07b035e488c3f1928832a1616c6cae7278 ]
    
    Use FIELD_GET() for PLL register fields.  This is its purpose.
    
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230912045157.177966-14-claudiu.beznea.uj@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Stable-dep-of: a2b23159499e ("clk: renesas: rzg2l: Fix computation formula")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: rzg2l: Wait for status bit of SD mux before continuing [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Fri Sep 29 08:38:49 2023 +0300

    clk: renesas: rzg2l: Wait for status bit of SD mux before continuing
    
    [ Upstream commit 549f4ae2601f968e2474c6031fb4799468882f64 ]
    
    The hardware user manual for RZ/G2L (r01uh0914ej0130-rzg2l-rzg2lc.pdf,
    chapter 7.4.7 Procedure for Switching Clocks by the Dynamic Switching
    Frequency Selectors) specifies that we need to check CPG_PL2SDHI_DSEL
    for SD clock switching status.
    
    Fixes: eaff33646f4cb ("clk: renesas: rzg2l: Add SDHI clk mux support")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230929053915.1530607-3-claudiu.beznea@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: scmi: Free scmi_clk allocated when the clocks with invalid info are skipped [+ + +]
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Wed Oct 4 20:36:00 2023 +0100

    clk: scmi: Free scmi_clk allocated when the clocks with invalid info are skipped
    
    [ Upstream commit 3537a75e73f3420614a358d0c8b390ea483cc87d ]
    
    Add the missing devm_kfree() when we skip the clocks with invalid or
    missing information from the firmware.
    
    Cc: Cristian Marussi <cristian.marussi@arm.com>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-clk@vger.kernel.org
    Fixes: 6d6a1d82eaef ("clk: add support for clocks provided by SCMI")
    Link: https://lore.kernel.org/r/20231004193600.66232-1-sudeep.holla@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: ti: fix double free in of_ti_divider_clk_setup() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Oct 2 10:04:36 2023 +0300

    clk: ti: fix double free in of_ti_divider_clk_setup()
    
    [ Upstream commit 7af5b9eadd64c9e02a71f97c45bcdf3b64841f6b ]
    
    The "div" pointer is freed in _register_divider() and again in
    of_ti_divider_clk_setup().  Delete the free in _register_divider()
    
    Fixes: fbbc18591585 ("clk: ti: divider: cleanup _register_divider and ti_clk_get_div_table")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/6d36eeec-6c8a-4f11-a579-aa3cd7c38749@moroto.mountain
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clocksource/drivers/arm_arch_timer: limit XGene-1 workaround [+ + +]
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Mon Oct 16 16:31:27 2023 +0100

    clocksource/drivers/arm_arch_timer: limit XGene-1 workaround
    
    [ Upstream commit 851354cbd12bb9500909733c3d4054306f61df87 ]
    
    The AppliedMicro XGene-1 CPU has an erratum where the timer condition
    would only consider TVAL, not CVAL. We currently apply a workaround when
    seeing the PartNum field of MIDR_EL1 being 0x000, under the assumption
    that this would match only the XGene-1 CPU model.
    However even the Ampere eMAG (aka XGene-3) uses that same part number, and
    only differs in the "Variant" and "Revision" fields: XGene-1's MIDR is
    0x500f0000, our eMAG reports 0x503f0002. Experiments show the latter
    doesn't show the faulty behaviour.
    
    Increase the specificity of the check to only consider partnum 0x000 and
    variant 0x00, to exclude the Ampere eMAG.
    
    Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations")
    Reported-by: Ross Burton <ross.burton@arm.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20231016153127.116101-1-andre.przywara@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu/hotplug: Remove dependancy against cpu_primary_thread_mask [+ + +]
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Wed Jul 5 16:51:34 2023 +0200

    cpu/hotplug: Remove dependancy against cpu_primary_thread_mask
    
    [ Upstream commit 7a4dcb4a5de1214c4a59448a759e2e264c2c4473 ]
    
    The commit 18415f33e2ac ("cpu/hotplug: Allow "parallel" bringup up to
    CPUHP_BP_KICK_AP_STATE") introduce a dependancy against a global variable
    cpu_primary_thread_mask exported by the X86 code. This variable is only
    used when CONFIG_HOTPLUG_PARALLEL is set.
    
    Since cpuhp_get_primary_thread_mask() and cpuhp_smt_aware() are only used
    when CONFIG_HOTPLUG_PARALLEL is set, don't define them when it is not set.
    
    No functional change.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20230705145143.40545-2-ldufour@linux.ibm.com
    Stable-dep-of: d91bdd96b55c ("cpu/SMT: Make SMT control more robust against enumeration failures")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu/SMT: Create topology_smt_thread_allowed() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Jul 5 16:51:39 2023 +0200

    cpu/SMT: Create topology_smt_thread_allowed()
    
    [ Upstream commit 38253464bc821d6de6bba81bb1412ebb36f6cbd1 ]
    
    Some architectures allows partial SMT states, i.e. when not all SMT threads
    are brought online.
    
    To support that, add an architecture helper which checks whether a given
    CPU is allowed to be brought online depending on how many SMT threads are
    currently enabled. Since this is only applicable to architecture supporting
    partial SMT, only these architectures should select the new configuration
    variable CONFIG_SMT_NUM_THREADS_DYNAMIC. For the other architectures, not
    supporting the partial SMT states, there is no need to define
    topology_cpu_smt_allowed(), the generic code assumed that all the threads
    are allowed or only the primary ones.
    
    Call the helper from cpu_smt_enable(), and cpu_smt_allowed() when SMT is
    enabled, to check if the particular thread should be onlined. Notably,
    also call it from cpu_smt_disable() if CPU_SMT_ENABLED, to allow
    offlining some threads to move from a higher to lower number of threads
    online.
    
    [ ldufour: Slightly reword the commit's description ]
    [ ldufour: Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC ]
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20230705145143.40545-7-ldufour@linux.ibm.com
    Stable-dep-of: d91bdd96b55c ("cpu/SMT: Make SMT control more robust against enumeration failures")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpu/SMT: Make SMT control more robust against enumeration failures [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Aug 14 10:18:27 2023 +0200

    cpu/SMT: Make SMT control more robust against enumeration failures
    
    [ Upstream commit d91bdd96b55cc3ce98d883a60f133713821b80a6 ]
    
    The SMT control mechanism got added as speculation attack vector
    mitigation. The implemented logic relies on the primary thread mask to
    be set up properly.
    
    This turns out to be an issue with XEN/PV guests because their CPU hotplug
    mechanics do not enumerate APICs and therefore the mask is never correctly
    populated.
    
    This went unnoticed so far because by chance XEN/PV ends up with
    smp_num_siblings == 2. So smt_hotplug_control stays at its default value
    CPU_SMT_ENABLED and the primary thread mask is never evaluated in the
    context of CPU hotplug.
    
    This stopped "working" with the upcoming overhaul of the topology
    evaluation which legitimately provides a fake topology for XEN/PV. That
    sets smp_num_siblings to 1, which causes the core CPU hot-plug core to
    refuse to bring up the APs.
    
    This happens because smt_hotplug_control is set to CPU_SMT_NOT_SUPPORTED
    which causes cpu_smt_allowed() to evaluate the unpopulated primary thread
    mask with the conclusion that all non-boot CPUs are not valid to be
    plugged.
    
    Make cpu_smt_allowed() more robust and take CPU_SMT_NOT_SUPPORTED and
    CPU_SMT_NOT_IMPLEMENTED into account. Rename it to cpu_bootable() while at
    it as that makes it more clear what the function is about.
    
    The primary mask issue on x86 XEN/PV needs to be addressed separately as
    there are users outside of the CPU hotplug code too.
    
    Fixes: 05736e4ac13c ("cpu/hotplug: Provide knobs to control SMT")
    Reported-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Juergen Gross <jgross@suse.com>
    Tested-by: Sohil Mehta <sohil.mehta@intel.com>
    Tested-by: Michael Kelley <mikelley@microsoft.com>
    Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230814085112.149440843@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpufreq: tegra194: fix warning due to missing opp_put [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Tue Aug 29 14:13:22 2023 +0530

    cpufreq: tegra194: fix warning due to missing opp_put
    
    [ Upstream commit bae8222a6c291dbe58c908dab5c2abd3a75d0d63 ]
    
    Fix the warning due to missing dev_pm_opp_put() call and hence
    wrong refcount value. This causes below warning message when
    trying to remove the module.
    
     Call trace:
      dev_pm_opp_put_opp_table+0x154/0x15c
      dev_pm_opp_remove_table+0x34/0xa0
      _dev_pm_opp_cpumask_remove_table+0x7c/0xbc
      dev_pm_opp_of_cpumask_remove_table+0x10/0x18
      tegra194_cpufreq_exit+0x24/0x34 [tegra194_cpufreq]
      cpufreq_remove_dev+0xa8/0xf8
      subsys_interface_unregister+0x90/0xe8
      cpufreq_unregister_driver+0x54/0x9c
      tegra194_cpufreq_remove+0x18/0x2c [tegra194_cpufreq]
      platform_remove+0x24/0x74
      device_remove+0x48/0x78
      device_release_driver_internal+0xc8/0x160
      driver_detach+0x4c/0x90
      bus_remove_driver+0x68/0xb8
      driver_unregister+0x2c/0x58
      platform_driver_unregister+0x10/0x18
      tegra194_ccplex_driver_exit+0x14/0x1e0 [tegra194_cpufreq]
      __arm64_sys_delete_module+0x184/0x270
    
    Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth")
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    [ Viresh: Add a blank line ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpupower: fix reference to nonexistent document [+ + +]
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Sun Oct 22 20:54:46 2023 +0200

    cpupower: fix reference to nonexistent document
    
    [ Upstream commit 6feb1a9641197ee630bf43b5c34ea1d9f8b4a0aa ]
    
    This file was renamed from .txt to .rst and left a dangling reference.
    Fix it.
    
    Fixes: 151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Len Brown <len.brown@intel.com>
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: caam/jr - fix Chacha20 + Poly1305 self test failure [+ + +]
Author: Gaurav Jain <gaurav.jain@nxp.com>
Date:   Thu Sep 21 18:12:37 2023 +0530

    crypto: caam/jr - fix Chacha20 + Poly1305 self test failure
    
    [ Upstream commit a8d3cdcc092fb2f2882acb6c20473a1be0ef4484 ]
    
    key buffer is not copied in chachapoly_setkey function,
    results in wrong output for encryption/decryption operation.
    
    fix this by memcpy the key in caam_ctx key arrary
    
    Fixes: d6bbd4eea243 ("crypto: caam/jr - add support for Chacha20 + Poly1305")
    Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: caam/qi2 - fix Chacha20 + Poly1305 self test failure [+ + +]
Author: Gaurav Jain <gaurav.jain@nxp.com>
Date:   Thu Sep 21 15:14:44 2023 +0530

    crypto: caam/qi2 - fix Chacha20 + Poly1305 self test failure
    
    [ Upstream commit 7b8c6aee0d5b864e70c0da82583f9862e374eaf3 ]
    
    key buffer is not copied in chachapoly_setkey function,
    results in wrong output for encryption/decryption operation.
    
    fix this by memcpy the key in caam_ctx key arrary
    
    Fixes: c10a53367901 ("crypto: caam/qi2 - add support for Chacha20 + Poly1305")
    Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/hpre - Fix a erroneous check after snprintf() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Sep 4 22:17:29 2023 +0200

    crypto: hisilicon/hpre - Fix a erroneous check after snprintf()
    
    [ Upstream commit c977950146720abff14e46d8c53f5638b06a9182 ]
    
    This error handling looks really strange.
    Check if the string has been truncated instead.
    
    Fixes: 02ab994635eb ("crypto: hisilicon - Fixed some tiny bugs of HPRE")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/qm - fix PF queue parameter issue [+ + +]
Author: Longfang Liu <liulongfang@huawei.com>
Date:   Thu Sep 28 16:57:22 2023 +0800

    crypto: hisilicon/qm - fix PF queue parameter issue
    
    [ Upstream commit 5831fc1fd4a578232fea708b82de0c666ed17153 ]
    
    If the queue isolation feature is enabled, the number of queues
    supported by the device changes. When PF is enabled using the
    current default number of queues, the default number of queues may
    be greater than the number supported by the device. As a result,
    the PF fails to be bound to the driver.
    
    After modification, if queue isolation feature is enabled, when
    the default queue parameter is greater than the number supported
    by the device, the number of enabled queues will be changed to
    the number supported by the device, so that the PF and driver
    can be properly bound.
    
    Fixes: 8bbecfb402f7 ("crypto: hisilicon/qm - add queue isolation support for Kunpeng930")
    Signed-off-by: Longfang Liu <liulongfang@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - fix deadlock in backlog processing [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Fri Oct 20 16:33:21 2023 +0100

    crypto: qat - fix deadlock in backlog processing
    
    [ Upstream commit 203b01001c4d741205b9c329acddc5193ed56fbd ]
    
    If a request has the flag CRYPTO_TFM_REQ_MAY_BACKLOG set, the function
    qat_alg_send_message_maybacklog(), enqueues it in a backlog list if
    either (1) there is already at least one request in the backlog list, or
    (2) the HW ring is nearly full or (3) the enqueue to the HW ring fails.
    If an interrupt occurs right before the lock in qat_alg_backlog_req() is
    taken and the backlog queue is being emptied, then there is no request
    in the HW queues that can trigger a subsequent interrupt that can clear
    the backlog queue. In addition subsequent requests are enqueued to the
    backlog list and not sent to the hardware.
    
    Fix it by holding the lock while taking the decision if the request
    needs to be included in the backlog queue or not. This synchronizes the
    flow with the interrupt handler that drains the backlog queue.
    
    For performance reasons, the logic has been changed to try to enqueue
    first without holding the lock.
    
    Fixes: 386823839732 ("crypto: qat - add backlog mechanism")
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Closes: https://lore.kernel.org/all/af9581e2-58f9-cc19-428f-6f18f1f83d54@redhat.com/T/
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - fix state machines cleanup paths [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Sep 14 10:55:45 2023 +0100

    crypto: qat - fix state machines cleanup paths
    
    [ Upstream commit c9ca9756f376f51f985130a0e599d956065d4c44 ]
    
    Commit 1bdc85550a2b ("crypto: qat - fix concurrency issue when device
    state changes") introduced the function adf_dev_down() which wraps the
    functions adf_dev_stop() and adf_dev_shutdown().
    In a subsequent change, the sequence adf_dev_stop() followed by
    adf_dev_shutdown() was then replaced across the driver with just a call
    to the function adf_dev_down().
    
    The functions adf_dev_stop() and adf_dev_shutdown() are called in error
    paths to stop the accelerator and free up resources and can be called
    even if the counterparts adf_dev_init() and adf_dev_start() did not
    complete successfully.
    However, the implementation of adf_dev_down() prevents the stop/shutdown
    sequence if the device is found already down.
    For example, if adf_dev_init() fails, the device status is not set as
    started and therefore a call to adf_dev_down() won't be calling
    adf_dev_shutdown() to undo what adf_dev_init() did.
    
    Do not check if a device is started in adf_dev_down() but do the
    equivalent check in adf_sysfs.c when handling a DEV_DOWN command from
    the user.
    
    Fixes: 2b60f79c7b81 ("crypto: qat - replace state machine calls")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Adam Guerin <adam.guerin@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - fix unregistration of compression algorithms [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Sep 14 10:55:49 2023 +0100

    crypto: qat - fix unregistration of compression algorithms
    
    [ Upstream commit 11af152f784d9eca54e193140891ac52de36e9a9 ]
    
    The function adf_dev_init(), through the subsystem qat_compression,
    populates the list of list of compression instances
    accel_dev->compression_list. If the list of instances is not empty,
    the function adf_dev_start() will then call qat_compression_registers()
    register the compression algorithms into the crypto framework.
    
    If any of the functions in adf_dev_start() fail, the caller of such
    function, in the error path calls adf_dev_down() which in turn call
    adf_dev_stop() and adf_dev_shutdown(), see for example the function
    state_store in adf_sriov.c.
    However, if the registration of compression algorithms is not done,
    adf_dev_stop() will try to unregister the algorithms regardless.
    This might cause the counter active_devs in qat_compression.c to get
    to a negative value.
    
    Add a new state, ADF_STATUS_COMPRESSION_ALGS_REGISTERED, which tracks
    if the compression algorithms are registered into the crypto framework.
    Then use this to unregister the algorithms if such flag is set. This
    ensures that the compression algorithms are only unregistered if
    previously registered.
    
    Fixes: 1198ae56c9a5 ("crypto: qat - expose deflate through acomp api for QAT GEN2")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Adam Guerin <adam.guerin@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - fix unregistration of crypto algorithms [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Sep 14 10:55:48 2023 +0100

    crypto: qat - fix unregistration of crypto algorithms
    
    [ Upstream commit 9b2f33a1bfcda90b857431a764c9c8f9a412bbe5 ]
    
    The function adf_dev_init(), through the subsystem qat_crypto, populates
    the list of list of crypto instances accel_dev->crypto_list.
    If the list of instances is not empty, the function adf_dev_start() will
    then call qat_algs_registers() and qat_asym_algs_register() to register
    the crypto algorithms into the crypto framework.
    
    If any of the functions in adf_dev_start() fail, the caller of such
    function, in the error path calls adf_dev_down() which in turn call
    adf_dev_stop() and adf_dev_shutdown(), see for example the function
    state_store in adf_sriov.c.
    However, if the registration of crypto algorithms is not done,
    adf_dev_stop() will try to unregister the algorithms regardless.
    This might cause the counter active_devs in qat_algs.c and
    qat_asym_algs.c to get to a negative value.
    
    Add a new state, ADF_STATUS_CRYPTO_ALGS_REGISTERED, which tracks if the
    crypto algorithms are registered into the crypto framework. Then use
    this to unregister the algorithms if such flag is set. This ensures that
    the crypto algorithms are only unregistered if previously registered.
    
    Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Adam Guerin <adam.guerin@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - ignore subsequent state up commands [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Sep 14 10:55:47 2023 +0100

    crypto: qat - ignore subsequent state up commands
    
    [ Upstream commit 9c20cb8b1847dedddec3d5163079290542bf00bf ]
    
    If the device is already in the up state, a subsequent write of `up` to
    the sysfs attribute /sys/bus/pci/devices/<BDF>/qat/state brings the
    device down.
    Fix this behaviour by ignoring subsequent `up` commands if the device is
    already in the up state.
    
    Fixes: 1bdc85550a2b ("crypto: qat - fix concurrency issue when device state changes")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Adam Guerin <adam.guerin@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - increase size of buffers [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Fri Sep 22 10:03:47 2023 +0100

    crypto: qat - increase size of buffers
    
    [ Upstream commit 4e4e2ed22d505c5bacf65c6a39bfb6d120d24785 ]
    
    Increase the size of the buffers used for composing the names used for
    the transport debugfs entries and the vector name to avoid a potential
    truncation.
    
    This resolves the following errors when compiling the driver with W=1
    and KCFLAGS=-Werror on GCC 12.3.1:
    
        drivers/crypto/intel/qat/qat_common/adf_transport_debug.c: In function ‘adf_ring_debugfs_add’:
        drivers/crypto/intel/qat/qat_common/adf_transport_debug.c:100:60: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
        drivers/crypto/intel/qat/qat_common/adf_isr.c: In function ‘adf_isr_resource_alloc’:
        drivers/crypto/intel/qat/qat_common/adf_isr.c:197:47: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 5 [-Werror=format-truncation=]
    
    Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/core/regs: Rename @dev to @host in struct cxl_register_map [+ + +]
Author: Robert Richter <rrichter@amd.com>
Date:   Wed Oct 18 19:16:55 2023 +0200

    cxl/core/regs: Rename @dev to @host in struct cxl_register_map
    
    [ Upstream commit dd22581f89537163f065e8ef7c125ce0fddf62cc ]
    
    The primary role of @dev is to host the mappings for devm operations.
    @dev is too ambiguous as a name. I.e. when does @dev refer to the
    'struct device *' instance that the registers belong, and when does
    @dev refer to the 'struct device *' instance hosting the mapping for
    devm operations?
    
    Clarify the role of @dev in cxl_register_map by renaming it to @host.
    Also, rename local variables to 'host' where map->host is used.
    
    Signed-off-by: Terry Bowman <terry.bowman@amd.com>
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20231018171713.1883517-3-rrichter@amd.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 33d9c987bf8f ("cxl/port: Fix @host confusion in cxl_dport_setup_regs()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/hdm: Remove broken error path [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Oct 31 14:09:19 2023 -0700

    cxl/hdm: Remove broken error path
    
    [ Upstream commit 5d09c63f11f083707b60c8ea0bb420651c47740f ]
    
    Dan reports that cxl_decoder_commit() potentially leaks a hold of
    cxl_dpa_rwsem. The potential error case is a "should not" happen
    scenario, turn it into a "can not" happen scenario by adding the error
    check to cxl_port_setup_targets() where other setting validation occurs.
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: http://lore.kernel.org/r/63295673-5d63-4919-b851-3b06d48734c0@moroto.mountain
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/mem: Fix shutdown order [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Sep 28 18:02:07 2023 -0700

    cxl/mem: Fix shutdown order
    
    [ Upstream commit 88d3917f82ed4215a2154432c26de1480a61b209 ]
    
    Ira reports that removing cxl_mock_mem causes a crash with the following
    trace:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000044
     [..]
     RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]
     [..]
     Call Trace:
      <TASK>
      cxl_region_detach+0xe8/0x210 [cxl_core]
      cxl_decoder_kill_region+0x27/0x40 [cxl_core]
      cxld_unregister+0x29/0x40 [cxl_core]
      devres_release_all+0xb8/0x110
      device_unbind_cleanup+0xe/0x70
      device_release_driver_internal+0x1d2/0x210
      bus_remove_device+0xd7/0x150
      device_del+0x155/0x3e0
      device_unregister+0x13/0x60
      devm_release_action+0x4d/0x90
      ? __pfx_unregister_port+0x10/0x10 [cxl_core]
      delete_endpoint+0x121/0x130 [cxl_core]
      devres_release_all+0xb8/0x110
      device_unbind_cleanup+0xe/0x70
      device_release_driver_internal+0x1d2/0x210
      bus_remove_device+0xd7/0x150
      device_del+0x155/0x3e0
      ? lock_release+0x142/0x290
      cdev_device_del+0x15/0x50
      cxl_memdev_unregister+0x54/0x70 [cxl_core]
    
    This crash is due to the clearing out the cxl_memdev's driver context
    (@cxlds) before the subsystem is done with it. This is ultimately due to
    the region(s), that this memdev is a member, being torn down and expecting
    to be able to de-reference @cxlds, like here:
    
    static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)
    ...
                    if (cxlds->rcd)
                            goto endpoint_reset;
    ...
    
    Fix it by keeping the driver context valid until memdev-device
    unregistration, and subsequently the entire stack of related
    dependencies, unwinds.
    
    Fixes: 9cc238c7a526 ("cxl/pci: Introduce cdevm_file_operations")
    Reported-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Tested-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/memdev: Fix sanitize vs decoder setup locking [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Oct 4 18:35:01 2023 -0700

    cxl/memdev: Fix sanitize vs decoder setup locking
    
    [ Upstream commit 339818380868e34ff2c482db05031bf47a67d609 ]
    
    The sanitize operation is destructive and the expectation is that the
    device is unmapped while in progress. The current implementation does a
    lockless check for decoders being active, but then does nothing to
    prevent decoders from racing to be committed. Introduce state tracking
    to resolve this race.
    
    This incidentally cleans up unpriveleged userspace from triggering mmio
    read cycles by spinning on reading the 'security/state' attribute. Which
    at a minimum is a waste since the kernel state machine can cache the
    completion result.
    
    Lastly cxl_mem_sanitize() was mistakenly marked EXPORT_SYMBOL() in the
    original implementation, but an export was never required.
    
    Fixes: 0c36b6ad436a ("cxl/mbox: Add sanitization handling machinery")
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/pci: Clarify devm host for memdev relative setup [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Oct 4 16:04:49 2023 -0700

    cxl/pci: Clarify devm host for memdev relative setup
    
    [ Upstream commit f29a824b0b6710328a78b018de3c2cfa9db65876 ]
    
    It is all too easy to get confused about @dev usage in the CXL driver
    stack. Before adding a new cxl_pci_probe() setup operation that has a
    devm lifetime dependent on @cxlds->dev binding, but also references
    @cxlmd->dev, and prints messages, rework the devm_cxl_add_memdev() and
    cxl_memdev_setup_fw_upload() function signatures to make this
    distinction explicit. I.e. pass in the devm context as an @host argument
    rather than infer it from other objects.
    
    This is in preparation for adding a devm_cxl_sanitize_setup_notifier().
    
    Note the whitespace fixup near the change of the devm_cxl_add_memdev()
    signature. That uncaught typo originated in the patch that added
    cxl_memdev_security_init().
    
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 5f2da1971446 ("cxl/pci: Fix sanitize notifier setup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/pci: Cleanup 'sanitize' to always poll [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Sep 29 12:44:20 2023 -0700

    cxl/pci: Cleanup 'sanitize' to always poll
    
    [ Upstream commit e30a106558e7d1e06d1fcfd12466dc646673d03d ]
    
    In preparation for fixing the init/teardown of the 'sanitize' workqueue
    and sysfs notification mechanism, arrange for cxl_mbox_sanitize_work()
    to be the single location where the sysfs attribute is notified. With
    that change there is no distinction between polled mode and interrupt
    mode. All the interrupt does is accelerate the polling interval.
    
    The change to check for "mds->security.sanitize_node" under the lock is
    there to ensure that the interrupt, the work routine and the
    setup/teardown code can all have a consistent view of the registered
    notifier and the workqueue state. I.e. the expectation is that the
    interrupt is live past the point that the sanitize sysfs attribute is
    published, and it may race teardown, so it must be consulted under a
    lock. Given that new locking requirement, cxl_pci_mbox_irq() is moved
    from hard to thread irq context.
    
    Lastly, some opportunistic replacements of
    "queue_delayed_work(system_wq, ...)", which is just open coded
    schedule_delayed_work(), are included.
    
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 5f2da1971446 ("cxl/pci: Fix sanitize notifier setup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/pci: Fix sanitize notifier setup [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Oct 4 16:49:36 2023 -0700

    cxl/pci: Fix sanitize notifier setup
    
    [ Upstream commit 5f2da19714465739da2449253b13ac06cb353a26 ]
    
    Fix a race condition between the mailbox-background command interrupt
    firing and the security-state sysfs attribute being removed.
    
    The race is difficult to see due to the awkward placement of the
    sanitize-notifier setup code and the multiple places the teardown calls
    are made, cxl_memdev_security_init() and cxl_memdev_security_shutdown().
    
    Unify setup in one place, cxl_sanitize_setup_notifier(). Arrange for
    the paired cxl_sanitize_teardown_notifier() to safely quiet the notifier
    and let the cxl_memdev + irq be unregistered later in the flow.
    
    Note: The special wrinkle of the sanitize notifier is that it interacts
    with interrupts, which are enabled early in the flow, and it interacts
    with memdev sysfs which is not initialized until late in the flow. Hence
    why this setup routine takes an @cxlmd argument, and not just @mds.
    
    This fix is also needed as a preparation fix for a memdev unregistration
    crash.
    
    Reported-by: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
    Closes: http://lore.kernel.org/r/20230929100316.00004546@Huawei.com
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Fixes: 0c36b6ad436a ("cxl/mbox: Add sanitization handling machinery")
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/pci: Remove inconsistent usage of dev_err_probe() [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Oct 4 16:24:39 2023 -0700

    cxl/pci: Remove inconsistent usage of dev_err_probe()
    
    [ Upstream commit 2627c995c15dc375f4b5a591d782a14b1c0e3e7d ]
    
    If dev_err_probe() is to be used it should at least be used consistently
    within the same function. It is also worth questioning whether
    every potential -ENOMEM needs an explicit error message.
    
    Remove the cxl_setup_fw_upload() error prints for what are rare /
    hardware-independent failures.
    
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 5f2da1971446 ("cxl/pci: Fix sanitize notifier setup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/pci: Remove unnecessary device reference management in sanitize work [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Sep 29 14:44:46 2023 -0700

    cxl/pci: Remove unnecessary device reference management in sanitize work
    
    [ Upstream commit 76fe8713dd0a1331d84d767e8e5d3f365d959e8a ]
    
    Given that any particular put_device() could be the final put of the
    device, the fact that there are usages of cxlds->dev after
    put_device(cxlds->dev) is a red flag. Drop the reference counting since
    the device is pinned by being registered and will not be unregistered
    without triggering the driver + workqueue to shutdown.
    
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 5f2da1971446 ("cxl/pci: Fix sanitize notifier setup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/port: Fix @host confusion in cxl_dport_setup_regs() [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Oct 18 19:16:56 2023 +0200

    cxl/port: Fix @host confusion in cxl_dport_setup_regs()
    
    [ Upstream commit 33d9c987bf8fb68a9292aba7cc4b1711fcb1be4d ]
    
    commit 5d2ffbe4b81a ("cxl/port: Store the downstream port's Component Register mappings in struct cxl_dport")
    
    ...moved the dport component registers from a raw component_reg_phys
    passed in at dport instantiation time to a 'struct cxl_register_map'
    populated with both the component register data *and* the "host" device
    for mapping operations.
    
    While typical CXL switch dports are mapped by their associated 'struct
    cxl_port', an RCH host bridge dport registered by cxl_acpi needs to wait
    until the cxl_mem driver makes the attachment to map the registers. This
    is because there are no intervening 'struct cxl_port' instances between
    the root cxl_port and the endpoint port in an RCH topology.
    
    For now just mark the host as NULL in the RCH dport case until code that
    needs to map the dport registers arrives.
    
    This patch is not flagged for -stable since nothing in the current
    driver uses the dport->comp_map.
    
    Now, I am slightly uneasy that cxl_setup_comp_regs() sets map->host to a
    wrong value and then cxl_dport_setup_regs() fixes it up, but the
    alternatives I came up with are more messy. For example, adding an
    @logdev to 'struct cxl_register_map' that the dev_printk()s can fall
    back to when @host is NULL. I settled on "post-fixup+comment" since it
    is only RCH dports that have this special case where register probing is
    split between a host-bridge RCRB lookup and when cxl_mem_probe() does
    the association of the cxl_memdev and endpoint port.
    
    [moved rename of @comp_map to @reg_map into next patch]
    
    Fixes: 5d2ffbe4b81a ("cxl/port: Store the downstream port's Component Register mappings in struct cxl_dport")
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20231018171713.1883517-4-rrichter@amd.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/region: Calculate a target position in a region interleave [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Fri Oct 27 13:04:48 2023 -0700

    cxl/region: Calculate a target position in a region interleave
    
    [ Upstream commit a3e00c964fb943934af916f48f0dd43b5110c866 ]
    
    Introduce a calculation to find a target's position in a region
    interleave. Perform a self-test of the calculation on user-defined
    regions.
    
    The region driver uses the kernel sort() function to put region
    targets in relative order. Positions are assigned based on each
    target's index in that sorted list. That relative sort doesn't
    consider the offset of a port into its parent port which causes
    some auto-discovered regions to fail creation. In one failure case,
    a 2 + 2 config (2 host bridges each with 2 endpoints), the sort
    puts all the targets of one port ahead of another port when they
    were expected to be interleaved.
    
    In preparation for repairing the autodiscovery region assembly,
    introduce a new method for discovering a target position in the
    region interleave.
    
    cxl_calc_interleave_pos() adds a method to find the target position by
    ascending from an endpoint to a root decoder. The calculation starts
    with the endpoint's local position and position in the parent port. It
    traverses towards the root decoder and examines both position and ways
    in order to allow the position to be refined all the way to the root
    decoder.
    
    This calculation: position = position * parent_ways + parent_pos;
    applied iteratively yields the correct position.
    
    Include a self-test that exercises this new position calculation against
    every successfully configured user-defined region.
    
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Link: https://lore.kernel.org/r/0ac32c75cf81dd8b86bf07d70ff139d33c2300bc.1698263080.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 0cf36a85c140 ("cxl/region: Use cxl_calc_interleave_pos() for auto-discovery")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/region: Fix cxl_region_rwsem lock held when returning to user space [+ + +]
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Wed Oct 25 16:54:50 2023 +0800

    cxl/region: Fix cxl_region_rwsem lock held when returning to user space
    
    [ Upstream commit 3531b27f1f04a6bc9c95cf00d40efe618d57aa93 ]
    
    Fix a missed "goto out" to unlock on error to cleanup this splat:
    
        WARNING: lock held when returning to user space!
        6.6.0-rc3-lizhijian+ #213 Not tainted
        ------------------------------------------------
        cxl/673 is leaving the kernel with locks still held!
        1 lock held by cxl/673:
         #0: ffffffffa013b9d0 (cxl_region_rwsem){++++}-{3:3}, at: commit_store+0x7d/0x3e0 [cxl_core]
    
    In terms of user visible impact of this bug for backports:
    
    cxl_region_invalidate_memregion() on x86 invokes wbinvd which is a
    problematic instruction for virtualized environments. So, on virtualized
    x86, cxl_region_invalidate_memregion() returns an error. This failure
    case got missed because CXL memory-expander device passthrough is not a
    production use case, and emulation of CXL devices is typically limited
    to kernel development builds with CONFIG_CXL_REGION_INVALIDATION_TEST=y,
    that makes cxl_region_invalidate_memregion() succeed.
    
    In other words, the expected exposure of this bug is limited to CXL
    subsystem development environments using QEMU that neglected
    CONFIG_CXL_REGION_INVALIDATION_TEST=y.
    
    Fixes: d1257d098a5a ("cxl/region: Move cache invalidation before region teardown, and before setup")
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Link: https://lore.kernel.org/r/20231025085450.2514906-1-lizhijian@fujitsu.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/region: Prepare the decoder match range helper for reuse [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Thu Oct 26 08:46:54 2023 -0700

    cxl/region: Prepare the decoder match range helper for reuse
    
    [ Upstream commit 1110581412c7a223439bb3ecdcdd9f4432e08231 ]
    
    match_decoder_by_range() and decoder_match_range() both determine
    if an HPA range matches a decoder. The first does it for root
    decoders and the second one operates on switch decoders.
    
    Tidy these up with clear naming and make the switch helper more
    like the root decoder helper in style and functionality. Make it
    take the actual range, rather than an endpoint decoder from which
    it extracts the range. Require an exact match on switch decoders,
    because unlike a root decoder that maps an entire region, Linux
    only supports 1:1 mapping of switch to endpoint decoders. Note that
    root-decoders are a super-set of switch-decoders and the range they
    cover is a super-set of a region, hence the use of range_contains() for
    that case.
    
    Aside from aesthetics and maintainability, this is in preparation
    for reuse.
    
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Jim Harris <jim.harris@samsung.com>
    Link: https://lore.kernel.org/r/011b1f498e1758bb8df17c5951be00bd8d489e3b.1698263080.git.alison.schofield@intel.com
    [djbw: fixup root decoder vs switch decoder range checks]
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Stable-dep-of: 0cf36a85c140 ("cxl/region: Use cxl_calc_interleave_pos() for auto-discovery")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl/region: Use cxl_calc_interleave_pos() for auto-discovery [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Wed Oct 25 13:01:34 2023 -0700

    cxl/region: Use cxl_calc_interleave_pos() for auto-discovery
    
    [ Upstream commit 0cf36a85c1408f86a967fb1db721de1b89b9e675 ]
    
    For auto-discovered regions the driver must assign each target to
    a valid position in the region interleave set based on the decoder
    topology.
    
    The current implementation fails to parse valid decode topologies,
    as it does not consider the child offset into a parent port. The sort
    put all targets of one port ahead of another port when an interleave
    was expected, causing the region assembly to fail.
    
    Replace the existing relative sort with cxl_calc_interleave_pos() that
    finds the exact position in a region interleave for an endpoint based
    on a walk up the ancestral tree from endpoint to root decoder.
    
    cxl_calc_interleave_pos() was introduced in a prior patch, so the work
    here is to use it in cxl_region_sort_targets().
    
    Remove the obsoleted helper functions from the prior sort.
    
    Testing passes on pre-production hardware with BIOS defined regions
    that natively trigger this autodiscovery path of the region driver.
    Testing passes a CXL unit test using the dev_dbg() calculation test
    (see cxl_region_attach()) across an expanded set of region configs:
    1, 1, 1+1, 1+1+1, 2, 2+2, 2+2+2, 2+2+2+2, 4, 4+4, where each number
    represents the count of endpoints per host bridge.
    
    Fixes: a32320b71f08 ("cxl/region: Add region autodiscovery")
    Reported-by: Dmytro Adamenko <dmytro.adamenko@intel.com>
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Jim Harris <jim.harris@samsung.com>
    Link: https://lore.kernel.org/r/3946cc55ddc19678733eddc9de2c317749f43f3b.1698263080.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Oct 30 13:10:42 2023 -0700

    dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses.
    
    [ Upstream commit 23be1e0e2a83a8543214d2599a31d9a2185a796b ]
    
    Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child
    sockets") introduced security_inet_conn_request() in some functions
    where reqsk is allocated.  The hook is added just after the allocation,
    so reqsk's IPv6 remote address was not initialised then.
    
    However, SELinux/Smack started to read it in netlbl_req_setattr()
    after commit e1adea927080 ("calipso: Allow request sockets to be
    relabelled by the lsm.").
    
    Commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request()
    hooks") fixed that kind of issue only in TCPv4 because IPv6 labeling was
    not supported at that time.  Finally, the same issue was introduced again
    in IPv6.
    
    Let's apply the same fix on DCCPv6 and TCPv6.
    
    Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp: Call security_inet_conn_request() after setting IPv4 addresses. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Oct 30 13:10:41 2023 -0700

    dccp: Call security_inet_conn_request() after setting IPv4 addresses.
    
    [ Upstream commit fa2df45af13091f76b89adb84a28f13818d5d631 ]
    
    Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child
    sockets") introduced security_inet_conn_request() in some functions
    where reqsk is allocated.  The hook is added just after the allocation,
    so reqsk's IPv4 remote address was not initialised then.
    
    However, SELinux/Smack started to read it in netlbl_req_setattr()
    after the cited commits.
    
    This bug was partially fixed by commit 284904aa7946 ("lsm: Relocate
    the IPv4 security_inet_conn_request() hooks").
    
    This patch fixes the last bug in DCCPv4.
    
    Fixes: 389fb800ac8b ("netlabel: Label incoming TCP connections correctly in SELinux")
    Fixes: 07feee8f812f ("netlabel: Cleanup the Smack/NetLabel code to fix incoming TCP connections")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dlm: fix no ack after final message [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Tue Oct 10 18:04:47 2023 -0400

    dlm: fix no ack after final message
    
    [ Upstream commit 6212e4528b248a4bc9b4fe68e029a84689c67461 ]
    
    In case of an final DLM message we can't should not send an ack out
    after the final message. This patch moves the ack message before the
    messages will be transmitted. If it's the final message and the
    receiving node turns into DLM_CLOSED state another ack messages will
    being received and turning the receiving node into DLM_ESTABLISHED
    again.
    
    Fixes: 1696c75f1864 ("fs: dlm: add send ack threshold and append acks to msgs")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: idxd: Register dsa_bus_type before registering idxd sub-drivers [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Sun Sep 24 09:22:32 2023 -0700

    dmaengine: idxd: Register dsa_bus_type before registering idxd sub-drivers
    
    [ Upstream commit 88928addeec577386e8c83b48b5bc24d28ba97fd ]
    
    idxd sub-drivers belong to bus dsa_bus_type. Thus, dsa_bus_type must be
    registered in dsa bus init before idxd drivers can be registered.
    
    But the order is wrong when both idxd and idxd_bus are builtin drivers.
    In this case, idxd driver is compiled and linked before idxd_bus driver.
    Since the initcall order is determined by the link order, idxd sub-drivers
    are registered in idxd initcall before dsa_bus_type is registered
    in idxd_bus initcall. idxd initcall fails:
    
    [   21.562803] calling  idxd_init_module+0x0/0x110 @ 1
    [   21.570761] Driver 'idxd' was unable to register with bus_type 'dsa' because the bus was not initialized.
    [   21.586475] initcall idxd_init_module+0x0/0x110 returned -22 after 15717 usecs
    [   21.597178] calling  dsa_bus_init+0x0/0x20 @ 1
    
    To fix the issue, compile and link idxd_bus driver before idxd driver
    to ensure the right registration order.
    
    Fixes: d9e5481fca74 ("dmaengine: dsa: move dsa_bus_type out of idxd driver to standalone")
    Reported-by: Michael Prinke <michael.prinke@intel.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Lijun Pan <lijun.pan@intel.com>
    Tested-by: Lijun Pan <lijun.pan@intel.com>
    Link: https://lore.kernel.org/r/20230924162232.1409454-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: pxa_dma: Remove an erroneous BUG_ON() in pxad_free_desc() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Oct 7 13:13:09 2023 +0200

    dmaengine: pxa_dma: Remove an erroneous BUG_ON() in pxad_free_desc()
    
    [ Upstream commit 83c761f568733277ce1f7eb9dc9e890649c29a8c ]
    
    If pxad_alloc_desc() fails on the first dma_pool_alloc() call, then
    sw_desc->nb_desc is zero.
    In such a case pxad_free_desc() is called and it will BUG_ON().
    
    Remove this erroneous BUG_ON().
    
    It is also useless, because if "sw_desc->nb_desc == 0", then, on the first
    iteration of the for loop, i is -1 and the loop will not be executed.
    (both i and sw_desc->nb_desc are 'int')
    
    Fixes: a57e16cf0333 ("dmaengine: pxa: add pxa dmaengine driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/c8fc5563c9593c914fde41f0f7d1489a21b45a9a.1696676782.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: edma: handle irq_of_parse_and_map() errors [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Sep 15 15:59:59 2023 +0300

    dmaengine: ti: edma: handle irq_of_parse_and_map() errors
    
    [ Upstream commit 14f6d317913f634920a640e9047aa2e66f5bdcb7 ]
    
    Zero is not a valid IRQ for in-kernel code and the irq_of_parse_and_map()
    function returns zero on error.  So this check for valid IRQs should only
    accept values > 0.
    
    Fixes: 2b6b3b742019 ("ARM/dmaengine: edma: Merge the two drivers under drivers/dma/")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/f15cb6a7-8449-4f79-98b6-34072f04edbc@moroto.mountain
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/clocksource/timer-ti-dm: Don't call clk_get_rate() in stop function [+ + +]
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Date:   Tue Oct 3 08:50:20 2023 +0300

    drivers/clocksource/timer-ti-dm: Don't call clk_get_rate() in stop function
    
    [ Upstream commit 12590d4d0e331d3cb9e6b3494515cd61c8a6624e ]
    
    clk_get_rate() might sleep, and that prevents dm-timer based PWM from being
    used from atomic context.
    
    Fix that by getting fclk rate in probe() and using a notifier in case rate
    changes.
    
    Fixes: af04aa856e93 ("ARM: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource")
    Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/1696312220-11550-1-git-send-email-ivo.g.dimitrov.75@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process [+ + +]
Author: Hao Chen <chenhao418@huawei.com>
Date:   Thu Oct 19 17:13:52 2023 +0800

    drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
    
    [ Upstream commit 50b560783f7f71790bcf70e9e9855155fb0af8c1 ]
    
    When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
    callbacks after the device has been unregistered, leading to fireworks
    when we try to execute empty function callbacks within the driver:
    
      | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1
      | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
      | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
      | pc : perf_pmu_migrate_context+0x98/0x38c
      | lr : perf_pmu_migrate_context+0x94/0x38c
      |
      | Call trace:
      |  perf_pmu_migrate_context+0x98/0x38c
      |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]
    
    Use cpuhp_state_remove_instance_nocalls() instead of
    cpuhp_state_remove_instance() so that the notifiers don't execute after
    the PMU device has been unregistered.
    
    Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
    Signed-off-by: Hao Chen <chenhao418@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20231019091352.998964-1-shaojijie@huawei.com
    [will: Rewrote commit message]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers/perf: hisi_pcie: Check the type first in pmu::event_init() [+ + +]
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Tue Oct 24 17:29:53 2023 +0800

    drivers/perf: hisi_pcie: Check the type first in pmu::event_init()
    
    [ Upstream commit 6d7d51e88e21c0af1ca96a3617afef334bfeffcf ]
    
    Check whether the event type matches the PMU type firstly in
    pmu::event_init() before touching the event. Otherwise we'll
    change the events of others and lead to incorrect results.
    Since in perf_init_event() we may call every pmu's event_init()
    in a certain case, we should not modify the event if it's not
    ours.
    
    Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20231024092954.42297-2-yangyicong@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Bail from dm_check_crtc_cursor if no relevant change [+ + +]
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Mon Oct 2 16:16:49 2023 +0200

    drm/amd/display: Bail from dm_check_crtc_cursor if no relevant change
    
    [ Upstream commit bc0b79ce2050aa523c38c96b6d26340a96bfbdca ]
    
    If no plane was newly enabled or changed scaling, there can be no new
    scaling mismatch with the cursor plane.
    
    By not pulling non-cursor plane states into all atomic commits while
    the cursor plane is enabled, this avoids synchronizing all cursor plane
    changes to vertical blank, which caused the following IGT tests to fail:
    
    kms_cursor_legacy@cursor-vs-flip.*
    kms_cursor_legacy@flip-vs-cursor.*
    
    Fixes: 003048ddf44b ("drm/amd/display: Check all enabled planes in dm_check_crtc_cursor")
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check all enabled planes in dm_check_crtc_cursor [+ + +]
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Tue Sep 12 12:22:24 2023 +0200

    drm/amd/display: Check all enabled planes in dm_check_crtc_cursor
    
    [ Upstream commit 003048ddf44b1a6cfa57afa5a0cf40673e13f1ba ]
    
    It was only checking planes which had any state changes in the same
    commit. However, it also needs to check other enabled planes.
    
    Not doing this meant that a commit might spuriously "succeed", resulting
    in the cursor plane displaying with incorrect scaling. See
    https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1824263
    for an example.
    
    Fixes: d1bfbe8a3202 ("amd/display: check cursor plane matches underlying plane")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix null pointer dereference in error message [+ + +]
Author: Cong Liu <liucong2@kylinos.cn>
Date:   Tue Sep 26 13:56:17 2023 +0800

    drm/amd/display: Fix null pointer dereference in error message
    
    [ Upstream commit 0c3601a2fbfb265ce283651480e30c8e60459112 ]
    
    This patch fixes a null pointer dereference in the error message that is
    printed when the Display Core (DC) fails to initialize. The original
    message includes the DC version number, which is undefined if the DC is
    not initialized.
    
    Fixes: 9788d087caff ("drm/amd/display: improve the message printed when loading DC")
    Signed-off-by: Cong Liu <liucong2@kylinos.cn>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Refactor dm_get_plane_scale helper [+ + +]
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Mon Oct 2 16:16:48 2023 +0200

    drm/amd/display: Refactor dm_get_plane_scale helper
    
    [ Upstream commit ec4d770bbb155674c2497f255f4199bdc42287a9 ]
    
    Cleanup, no functional change intended.
    
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: bc0b79ce2050 ("drm/amd/display: Bail from dm_check_crtc_cursor if no relevant change")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: Fix a memory leak on an error path [+ + +]
Author: Kunwu.Chan <chentao@kylinos.cn>
Date:   Tue Oct 10 14:10:39 2023 +0800

    drm/amd/pm: Fix a memory leak on an error path
    
    [ Upstream commit 828f8e31379b28fe7f07fb5865b8ed099d223fca ]
    
    Add missing free on an error path.
    
    Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Kunwu.Chan <chentao@kylinos.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/gfx10,11: use memcpy_to/fromio for MQDs [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Oct 26 14:47:57 2023 -0400

    drm/amdgpu/gfx10,11: use memcpy_to/fromio for MQDs
    
    [ Upstream commit b3c942bb6c32a8ddc1d52ee6bc24b8cf732dddf4 ]
    
    Since they were moved to VRAM, we need to use the IO
    variants of memcpy.
    
    Fixes: 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM")
    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/amdgpu: don't put MQDs in VRAM on ARM | ARM64 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Oct 26 14:37:31 2023 -0400

    drm/amdgpu: don't put MQDs in VRAM on ARM | ARM64
    
    [ Upstream commit ba0fb4b48c19a2d2380fc16ca4af236a0871d279 ]
    
    Issues were reported with commit 1cfb4d612127
    ("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere
    Altra Developer Platform (AVA developer platform).
    
    Various ARM systems seem to have problems related
    to PCIe and MMIO access.  In this case, I'm not sure
    if this is specific to the ADLINK platform or ARM
    in general.  Seems to be some coherency issue with
    VRAM.  For now, just don't put MQDs in VRAM on ARM.
    
    Link: https://lists.freedesktop.org/archives/amd-gfx/2023-October/100453.html
    Fixes: 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM")
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: alexey.klimov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Increase IH soft ring size for GFX v9.4.3 dGPU [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Fri Sep 15 15:13:48 2023 -0400

    drm/amdgpu: Increase IH soft ring size for GFX v9.4.3 dGPU
    
    [ Upstream commit bcfb9cee61207b80f37663ffa08c135657a27ad5 ]
    
    On GFX v9.4.3 dGPU, applications have random timeout failure when XNACK
    on, dmesg log has "amdgpu: IH soft ring buffer overflow 0x900, 0x900",
    because dGPU mode has 272 cam entries. After increasing IH soft ring
    to 512 entries, no more IH soft ring overflow message and application
    passed.
    
    Fixes: bf80d34b6c58 ("drm/amdgpu: Increase soft IH ring size")
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Reviewed-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/amdkfd: fix some race conditions in vram buffer alloc/free of svm code [+ + +]
Author: Xiaogang Chen <xiaogang.chen@amd.com>
Date:   Wed Sep 20 11:02:51 2023 -0500

    drm/amdkfd: fix some race conditions in vram buffer alloc/free of svm code
    
    [ Upstream commit 7bfaa160caed8192f8262c4638f552cad94bcf5a ]
    
    This patch fixes:
    1: ref number of prange's svm_bo got decreased by an async call from hmm. When
    wait svm_bo of prange got released we shoul also wait prang->svm_bo become NULL,
    otherwise prange->svm_bo may be set to null after allocate new vram buffer.
    
    2: During waiting svm_bo of prange got released in a while loop should reschedule
    current task to give other tasks oppotunity to run, specially the the workque
    task that handles svm_bo ref release, otherwise we may enter to softlock.
    
    Signed-off-by: Xiaogang.Chen <xiaogang.chen@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/amdkfd: Handle errors from svm validate and map [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Wed Sep 13 10:10:23 2023 -0400

    drm/amdkfd: Handle errors from svm validate and map
    
    [ Upstream commit eb3c357bcb286e89386e89302061fe717fe4e562 ]
    
    If new range is splited to multiple pranges with max_svm_range_pages
    alignment and added to update_list, svm validate and map should keep
    going after error to make sure prange->mapped_to_gpu flag is up to date
    for the whole range.
    
    svm validate and map update set prange->mapped_to_gpu after mapping to
    GPUs successfully, otherwise clear prange->mapped_to_gpu flag (for
    update mapping case) instead of setting error flag, we can remove
    the redundant error flag to simpliy code.
    
    Refactor to remove goto and update prange->mapped_to_gpu flag inside
    svm_range_lock, to guarant we always evict queues or unmap from GPUs if
    there are invalid ranges.
    
    After svm validate and map return error -EAGIN, the caller retry will
    update the mapping for the whole range again.
    
    Fixes: c22b04407097 ("drm/amdkfd: flag added to handle errors from svm validate and map")
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Tested-by: James Zhu <james.zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdkfd: Remove svm range validated_once flag [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Tue Aug 1 11:38:32 2023 -0400

    drm/amdkfd: Remove svm range validated_once flag
    
    [ Upstream commit c99b16128082de519975aa147d9da3e40380de67 ]
    
    The validated_once flag is not used after the prefault was removed, The
    prefault was needed to ensure validate all system memory pages at least
    once before mapping or migrating the range to GPU.
    
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: eb3c357bcb28 ("drm/amdkfd: Handle errors from svm validate and map")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdkfd: retry after EBUSY is returned from hmm_ranges_get_pages [+ + +]
Author: Alex Sierra <alex.sierra@amd.com>
Date:   Tue Aug 15 15:42:52 2023 -0500

    drm/amdkfd: retry after EBUSY is returned from hmm_ranges_get_pages
    
    [ Upstream commit ebac9414a56a5f7c336db5f5c7cc34713b649407 ]
    
    if hmm_range_get_pages returns EBUSY error during
    svm_range_validate_and_map, within the context of a page fault
    interrupt. This should retry through svm_range_restore_pages
    callback. Therefore we treat this as EAGAIN error instead, and defer
    it to restore pages fallback.
    
    Signed-off-by: Alex Sierra <alex.sierra@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: eb3c357bcb28 ("drm/amdkfd: Handle errors from svm validate and map")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/aspeed: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun May 7 18:25:28 2023 +0200

    drm/aspeed: Convert to platform remove callback returning void
    
    [ Upstream commit 9a32dd324c46a0c76cac9d91e5a88abcf83f7b03 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is (mostly) ignored
    and this typically results in resource leaks. To improve here there is a
    quest to make the remove callback return void. In the first step of this
    quest all drivers are converted to .remove_new() which already returns
    void.
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-6-u.kleine-koenig@pengutronix.de
    Stable-dep-of: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: lt8912b: Add missing drm_bridge_attach call [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Aug 4 13:48:13 2023 +0300

    drm/bridge: lt8912b: Add missing drm_bridge_attach call
    
    [ Upstream commit f45acf7acf75921c0409d452f0165f51a19a74fd ]
    
    The driver does not call drm_bridge_attach(), which causes the next
    bridge to not be added to the bridge chain. This causes the pipeline
    init to fail when DRM_BRIDGE_ATTACH_NO_CONNECTOR is used.
    
    Add the call to drm_bridge_attach().
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230804-lt8912b-v1-4-c542692c6a2f@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt8912b: Fix bridge_detach [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Aug 4 13:48:10 2023 +0300

    drm/bridge: lt8912b: Fix bridge_detach
    
    [ Upstream commit 941882a0e96d245f38116e940912b404b6a93c6f ]
    
    The driver calls lt8912_bridge_detach() from its lt8912_remove()
    function. As the DRM core detaches bridges automatically, this leads to
    calling lt8912_bridge_detach() twice. The code probably has tried to
    manage the double-call with the 'is_attached' variable, but the driver
    never sets the variable to false, so its of no help.
    
    Fix the issue by dropping the call to lt8912_bridge_detach() from
    lt8912_remove(), as the DRM core will handle the detach call for us,
    and also drop the useless is_attached field.
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230804-lt8912b-v1-1-c542692c6a2f@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt8912b: Fix crash on bridge detach [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Aug 4 13:48:11 2023 +0300

    drm/bridge: lt8912b: Fix crash on bridge detach
    
    [ Upstream commit 44283993144a03af9df31934d6c32bbd42d1a347 ]
    
    The lt8912b driver, in its bridge detach function, calls
    drm_connector_unregister() and drm_connector_cleanup().
    
    drm_connector_unregister() should be called only for connectors
    explicitly registered with drm_connector_register(), which is not the
    case in lt8912b.
    
    The driver's drm_connector_funcs.destroy hook is set to
    drm_connector_cleanup().
    
    Thus the driver should not call either drm_connector_unregister() nor
    drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a
    crash on bridge detach:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    Mem abort info:
      ESR = 0x0000000096000006
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x06: level 2 translation fault
    Data abort info:
      ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000
    [0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000
    Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
    Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks
    CPU: 3 PID: 462 Comm: rmmod Tainted: G        W          6.5.0-rc2+ #2
    Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
    pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : drm_connector_cleanup+0x78/0x2d4 [drm]
    lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
    sp : ffff800082ed3a90
    x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000
    x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122
    x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000
    x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8
    x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038
    x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e
    x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48
    x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0
    x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008
    x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
    Call trace:
     drm_connector_cleanup+0x78/0x2d4 [drm]
     lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
     drm_bridge_detach+0x44/0x84 [drm]
     drm_encoder_cleanup+0x40/0xb8 [drm]
     drmm_encoder_alloc_release+0x1c/0x30 [drm]
     drm_managed_release+0xac/0x148 [drm]
     drm_dev_put.part.0+0x88/0xb8 [drm]
     devm_drm_dev_init_release+0x14/0x24 [drm]
     devm_action_release+0x14/0x20
     release_nodes+0x5c/0x90
     devres_release_all+0x8c/0xe0
     device_unbind_cleanup+0x18/0x68
     device_release_driver_internal+0x208/0x23c
     driver_detach+0x4c/0x94
     bus_remove_driver+0x70/0xf4
     driver_unregister+0x30/0x60
     platform_driver_unregister+0x14/0x20
     tidss_platform_driver_exit+0x18/0xb2c [tidss]
     __arm64_sys_delete_module+0x1a0/0x2b4
     invoke_syscall+0x48/0x110
     el0_svc_common.constprop.0+0x60/0x10c
     do_el0_svc_compat+0x1c/0x40
     el0_svc_compat+0x40/0xac
     el0t_32_sync_handler+0xb0/0x138
     el0t_32_sync+0x194/0x198
    Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230804-lt8912b-v1-2-c542692c6a2f@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt8912b: Manually disable HPD only if it was enabled [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Aug 4 13:48:12 2023 +0300

    drm/bridge: lt8912b: Manually disable HPD only if it was enabled
    
    [ Upstream commit 6985c5efc4057bc79137807295d84ada3123d051 ]
    
    lt8912b only calls drm_bridge_hpd_enable() if it creates a connector and
    the next bridge has DRM_BRIDGE_OP_HPD set. However, when calling
    drm_bridge_hpd_disable() it misses checking if a connector was created,
    calling drm_bridge_hpd_disable() even if HPD was never enabled. I don't
    see any issues caused by this wrong call, though.
    
    Add the check to avoid wrongly calling drm_bridge_hpd_disable().
    
    Fixes: 3b0a01a6a522 ("drm/bridge: lt8912b: Add hot plug detection")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230804-lt8912b-v1-3-c542692c6a2f@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt9611uxc: fix the race in the error path [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Oct 12 01:00:02 2023 +0300

    drm/bridge: lt9611uxc: fix the race in the error path
    
    [ Upstream commit 15fe53be46eaf4f6339cd433972ecc90513e3076 ]
    
    If DSI host attachment fails, the LT9611UXC driver will remove the
    bridge without ensuring that there is no outstanding HPD work being
    done. In rare cases this can result in the warnings regarding the mutex
    being incorrect. Fix this by forcebly freing IRQ and flushing the work.
    
    DEBUG_LOCKS_WARN_ON(lock->magic != lock)
    WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:582 __mutex_lock+0x468/0x77c
    Modules linked in:
    CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G     U             6.6.0-rc5-next-20231011-gd81f81c2b682-dirty #1206
    Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
    Workqueue: events lt9611uxc_hpd_work
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __mutex_lock+0x468/0x77c
    lr : __mutex_lock+0x468/0x77c
    sp : ffff8000800a3c70
    x29: ffff8000800a3c70 x28: 0000000000000000 x27: ffffd595fe333000
    x26: ffff7c2f0002c005 x25: ffffd595ff1b3000 x24: ffffd595fccda5a0
    x23: 0000000000000000 x22: 0000000000000002 x21: ffff7c2f056d91c8
    x20: 0000000000000000 x19: ffff7c2f056d91c8 x18: fffffffffffe8db0
    x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
    x14: 000000000006efb8 x13: 0000000000000000 x12: 0000000000000037
    x11: 0000000000000001 x10: 0000000000001470 x9 : ffff8000800a3ae0
    x8 : ffff7c2f0027f8d0 x7 : ffff7c2f0027e400 x6 : ffffd595fc702b54
    x5 : 0000000000000000 x4 : ffff8000800a0000 x3 : 0000000000000000
    x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7c2f0027e400
    Call trace:
     __mutex_lock+0x468/0x77c
     mutex_lock_nested+0x24/0x30
     drm_bridge_hpd_notify+0x2c/0x5c
     lt9611uxc_hpd_work+0x6c/0x80
     process_one_work+0x1ec/0x51c
     worker_thread+0x1ec/0x3e4
     kthread+0x120/0x124
     ret_from_fork+0x10/0x20
    irq event stamp: 15799
    hardirqs last  enabled at (15799): [<ffffd595fc702ba4>] finish_task_switch.isra.0+0xa8/0x278
    hardirqs last disabled at (15798): [<ffffd595fd5a1580>] __schedule+0x7b8/0xbd8
    softirqs last  enabled at (15794): [<ffffd595fc690698>] __do_softirq+0x498/0x4e0
    softirqs last disabled at (15771): [<ffffd595fc69615c>] ____do_softirq+0x10/0x1c
    
    Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231011220002.382422-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Clean up clock period code [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:57 2023 +0300

    drm/bridge: tc358768: Clean up clock period code
    
    [ Upstream commit b3aa7b34924a9ed64cf96899cac4d8ea08cd829e ]
    
    The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer
    to clock periods. The original author does not remember where all this
    came from. Effectively the driver is using picoseconds as the unit for
    clock periods, yet referring to them by "nsk".
    
    Clean this up by just saying the periods are in picoseconds.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-10-31725f008a50@ideasonboard.com
    Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Fix bit updates [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:51 2023 +0300

    drm/bridge: tc358768: Fix bit updates
    
    [ Upstream commit 66962d5c3c51377b9b90cae35b7e038950438e02 ]
    
    The driver has a few places where it does:
    
    if (thing_is_enabled_in_config)
            update_thing_bit_in_hw()
    
    This means that if the thing is _not_ enabled, the bit never gets
    cleared. This affects the h/vsyncs and continuous DSI clock bits.
    
    Fix the driver to always update the bit.
    
    Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-4-31725f008a50@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Fix tc358768_ns_to_cnt() [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:58 2023 +0300

    drm/bridge: tc358768: Fix tc358768_ns_to_cnt()
    
    [ Upstream commit f1dabbe645065d20ca863c8d446c74c59ca1ca9d ]
    
    The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up
    operation, but it misses subtracting one from the dividend.
    
    Fix this by just using DIV_ROUND_UP().
    
    Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-11-31725f008a50@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Fix use of uninitialized variable [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:49 2023 +0300

    drm/bridge: tc358768: Fix use of uninitialized variable
    
    [ Upstream commit a2d9036615f0adfa5b0a46bb2ce42ef1d9a04fbe ]
    
    smatch reports:
    
    drivers/gpu/drm/bridge/tc358768.c:223 tc358768_update_bits() error: uninitialized symbol 'orig'.
    
    Fix this by bailing out from tc358768_update_bits() if the
    tc358768_read() produces an error.
    
    Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-2-31725f008a50@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Print logical values, not raw register values [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:54 2023 +0300

    drm/bridge: tc358768: Print logical values, not raw register values
    
    [ Upstream commit 013ea98cdfccef3b7c38b087c1f629488d2ef683 ]
    
    The driver debug prints DSI related timings as raw register values in
    hex. It is much more useful to see the "logical" value of the timing,
    not the register value.
    
    Change the prints to print the values separately, in case a single
    register contains multiple values, and use %u to have it in a more human
    consumable form.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-7-31725f008a50@ideasonboard.com
    Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Rename dsibclk to hsbyteclk [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:56 2023 +0300

    drm/bridge: tc358768: Rename dsibclk to hsbyteclk
    
    [ Upstream commit 699cf62a7d4550759f4a50e614b1952f93de4783 ]
    
    The Toshiba documentation talks about HSByteClk when referring to the
    DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a
    few places the driver calculates the byte clock from the DSI clock, even
    if the byte clock is already available in a variable.
    
    To align the driver with the documentation, change the 'dsibclk'
    variable to 'hsbyteclk'. This also make it easier to visually separate
    'dsibclk' and 'dsiclk' variables.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-9-31725f008a50@ideasonboard.com
    Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Use dev for dbg prints, not priv->dev [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:55 2023 +0300

    drm/bridge: tc358768: Use dev for dbg prints, not priv->dev
    
    [ Upstream commit 89cfd50e13f1bead4350998a3a77422bef1ee0a5 ]
    
    Simplify the code by capturing the priv->dev value to dev variable, and
    use it.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-8-31725f008a50@ideasonboard.com
    Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358768: Use struct videomode [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Sep 6 09:50:53 2023 +0300

    drm/bridge: tc358768: Use struct videomode
    
    [ Upstream commit e5fb21678136a9d009d5c43821881eb4c34fae97 ]
    
    The TC358768 documentation uses HFP, HBP, etc. values to deal with the
    video mode, while the driver currently uses the DRM display mode
    (htotal, hsync_start, etc).
    
    Change the driver to convert the DRM display mode to struct videomode,
    which then allows us to use the same units the documentation uses. This
    makes it much easier to work on the code when using the TC358768
    documentation as a reference.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-6-31725f008a50@ideasonboard.com
    Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mediatek: Add mmsys_dev_num to mt8188 vdosys0 driver data [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Wed Oct 4 10:40:05 2023 +0800

    drm/mediatek: Add mmsys_dev_num to mt8188 vdosys0 driver data
    
    [ Upstream commit ff64e4c31d969cdba20a41969edb3def15f3aaa0 ]
    
    Add missing mmsys_dev_num to mt8188 vdosys0 driver data.
    
    Fixes: 54b48080278a ("drm/mediatek: Add mediatek-drm of vdosys0 support for mt8188")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Fei Shao <fshao@chromium.org>
    Tested-by: Fei Shao <fshao@chromium.org>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20231004024013.18956-2-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix coverity issue with unintentional integer overflow [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Thu Sep 7 17:14:25 2023 +0800

    drm/mediatek: Fix coverity issue with unintentional integer overflow
    
    [ Upstream commit b0b0d811eac6b4c52cb9ad632fa6384cf48869e7 ]
    
    1. Instead of multiplying 2 variable of different types. Change to
    assign a value of one variable and then multiply the other variable.
    
    2. Add a int variable for multiplier calculation instead of calculating
    different types multiplier with dma_addr_t variable directly.
    
    Fixes: 1a64a7aff8da ("drm/mediatek: Fix cursor plane no update")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230907091425.9526-1-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix iommu fault by swapping FBs after updating plane state [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Wed Aug 9 20:57:21 2023 +0800

    drm/mediatek: Fix iommu fault by swapping FBs after updating plane state
    
    [ Upstream commit 3ec71e05ae6e7f46512e568ed81c92be589003dd ]
    
    According to the comment in drm_atomic_helper_async_commit(),
    we should make sure FBs have been swapped, so that cleanups in the
    new_state performs a cleanup in the old FB.
    
    So we should move swapping FBs after calling mtk_plane_update_new_state(),
    to avoid using the old FB which could be freed.
    
    Fixes: 1a64a7aff8da ("drm/mediatek: Fix cursor plane no update")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230809125722.24112-2-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix iommu fault during crtc enabling [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Wed Aug 9 20:57:22 2023 +0800

    drm/mediatek: Fix iommu fault during crtc enabling
    
    [ Upstream commit 53412dc2905401207f264dc30890f6b9e41524a6 ]
    
    The difference between drm_atomic_helper_commit_tail() and
    drm_atomic_helper_commit_tail_rpm() is
    drm_atomic_helper_commit_tail() will commit plane first and
    then enable crtc, drm_atomic_helper_commit_tail_rpm() will
    enable crtc first and then commit plane.
    
    Before mediatek-drm enables crtc, the power and clk required
    by OVL have not been turned on, so the commit plane cannot be
    committed before crtc is enabled. That means OVL layer should
    not be enabled before crtc is enabled.
    Therefore, the atomic_commit_tail of mediatek-drm is hooked with
    drm_atomic_helper_commit_tail_rpm().
    
    Another reason is that the plane_state of drm_atomic_state is not
    synchronized with the plane_state stored in mtk_crtc during crtc enablng,
    so just set all planes to disabled.
    
    Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230809125722.24112-3-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dsi: free TX buffer in unbind [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Oct 12 04:29:09 2023 +0300

    drm/msm/dsi: free TX buffer in unbind
    
    [ Upstream commit 5e05be78264594634860087953649487f486ffcc ]
    
    If the drm/msm init code gets an error during output modeset
    initialisation, the kernel will report an error regarding DRM memory
    manager not being clean during shutdown. This is because
    msm_dsi_modeset_init() allocates a piece of GEM memory for the TX
    buffer, but destruction of the buffer happens only at
    msm_dsi_host_destroy(), which is called during DSI driver's remove()
    time, much later than the DRM MM shutdown.
    
    To solve this issue, move the TX buffer destruction to dsi_unbind(), so
    that the buffer is destructed at the correct time. Note, we also have to
    store a reference to the address space, because priv->kms->aspace is
    cleared before components are unbound.
    
    Reported-by: Bjorn Andersson <andersson@kernel.org>
    Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/562238/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dsi: use msm_gem_kernel_put to free TX buffer [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Oct 12 04:29:08 2023 +0300

    drm/msm/dsi: use msm_gem_kernel_put to free TX buffer
    
    [ Upstream commit 69b321b2c3df4f7e51a9de587e41f324b0b717b0 ]
    
    Use exiting function to free the allocated GEM object instead of
    open-coding it. This has a bonus of internally calling
    msm_gem_put_vaddr() to compensate for msm_gem_get_vaddr() in
    msm_get_kernel_new().
    
    Fixes: 1e29dff00400 ("drm/msm: Add a common function to free kernel buffer objects")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/562239/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: possible buffer overflow [+ + +]
Author: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date:   Thu Aug 17 19:33:49 2023 +0800

    drm/radeon: possible buffer overflow
    
    [ Upstream commit dd05484f99d16715a88eedfca363828ef9a4c2d4 ]
    
    Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
    checked after access.
    
    Fixes: 5cc4e5fc293b ("drm/radeon: Cleanup HDMI audio interrupt handling for evergreen")
    Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
    Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Sep 2 19:34:31 2023 +0200

    drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe()
    
    [ Upstream commit 44b968d0d0868b7a9b7a5c64464ada464ff4d532 ]
    
    cdn_dp_audio_codec_init() can fail. So add some error handling.
    
    If component_add() fails, the previous cdn_dp_audio_codec_init() call
    should be undone, as already done in the remove function.
    
    Fixes: 88582f564692 ("drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/8494a41602fadb7439630921a9779640698f2f9f.1693676045.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Oct 11 11:01:48 2023 +0300

    drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map()
    
    [ Upstream commit 6471da5ee311d53ef46eebcb7725bc94266cc0cf ]
    
    The "ret" variable is declared as ssize_t and it can hold negative error
    codes but the "rk_obj->base.size" variable is type size_t.  This means
    that when we compare them, they are both type promoted to size_t and the
    negative error code becomes a high unsigned value and is treated as
    success.  Add a cast to fix this.
    
    Fixes: 38f993b7c59e ("drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/2bfa28b5-145d-4b9e-a18a-98819dd686ce@moroto.mountain
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop2: Add missing call to crtc reset helper [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Jun 21 22:33:23 2023 +0000

    drm/rockchip: vop2: Add missing call to crtc reset helper
    
    [ Upstream commit 4d49d87b3606369c6e29b9d051892ee1a6fc4e75 ]
    
    Add missing call to crtc reset helper to properly vblank reset.
    
    Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
    and remove duplicated code.
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621223311.2239547-6-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop2: Don't crash for invalid duplicate_state [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Jun 21 22:33:21 2023 +0000

    drm/rockchip: vop2: Don't crash for invalid duplicate_state
    
    [ Upstream commit 342f7e4967d02b0ec263b15916304fc54841b608 ]
    
    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: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621223311.2239547-5-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop: Fix call to crtc reset helper [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Jun 21 22:33:20 2023 +0000

    drm/rockchip: vop: Fix call to crtc reset helper
    
    [ Upstream commit 5aacd290837828c089a83ac9795c74c4c9e2c923 ]
    
    Allocation of crtc_state may fail in vop_crtc_reset, causing an invalid
    pointer to be passed to __drm_atomic_helper_crtc_reset.
    
    Fix this by adding a NULL check of crtc_state, similar to other drivers.
    
    Fixes: 01e2eaf40c9d ("drm/rockchip: Convert to using __drm_atomic_helper_crtc_reset() for reset.")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621223311.2239547-4-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Jun 21 22:33:17 2023 +0000

    drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs
    
    [ Upstream commit 13fc28804bf10ca0b7bce3efbba95c534836d7ca ]
    
    struct rockchip_crtc_state members such as output_type, output_bpc and
    enable_afbc is always reset to zero in the atomic_duplicate_state crtc
    funcs.
    
    Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
    
    Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621223311.2239547-2-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/stm: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun May 7 18:26:05 2023 +0200

    drm/stm: Convert to platform remove callback returning void
    
    [ Upstream commit 0c259ab1914664a9865ddebe9baf66e0b5a25b08 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is (mostly) ignored
    and this typically results in resource leaks. To improve here there is a
    quest to make the remove callback return void. In the first step of this
    quest all drivers are converted to .remove_new() which already returns
    void.
    
    Trivially convert the stm drm drivers from always returning zero in the
    remove callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-43-u.kleine-koenig@pengutronix.de
    Stable-dep-of: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE [+ + +]
Author: Erik Kurzinger <ekurzinger@nvidia.com>
Date:   Wed Aug 16 09:26:05 2023 -0700

    drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE
    
    [ Upstream commit 101c9f637efa1655f55876644d4439e552267527 ]
    
    If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the
    DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been
    submitted for the given timeline point the call will fail immediately
    with EINVAL. This does not match the intended behavior where the call
    should wait until the fence has been submitted (or the timeout expires).
    
    The following small example program illustrates the issue. It should
    wait for 5 seconds and then print ETIME, but instead it terminates right
    away after printing EINVAL.
    
      #include <stdio.h>
      #include <fcntl.h>
      #include <time.h>
      #include <errno.h>
      #include <xf86drm.h>
      int main(void)
      {
          int fd = open("/dev/dri/card0", O_RDWR);
          uint32_t syncobj;
          drmSyncobjCreate(fd, 0, &syncobj);
          struct timespec ts;
          clock_gettime(CLOCK_MONOTONIC, &ts);
          uint64_t point = 1;
          if (drmSyncobjTimelineWait(fd, &syncobj, &point, 1,
                                     ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s
                                     DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) {
              printf("drmSyncobjTimelineWait failed %d\n", errno);
          }
      }
    
    Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
    Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
    Reviewed by: Simon Ser <contact@emersion.fd>
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/1fac96f1-2f3f-f9f9-4eb0-340f27a8f6c0@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/tve200: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun May 7 18:26:13 2023 +0200

    drm/tve200: Convert to platform remove callback returning void
    
    [ Upstream commit e2fd3192e267dcb01f5de5baa221677c349de828 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is (mostly) ignored
    and this typically results in resource leaks. To improve here there is a
    quest to make the remove callback return void. In the first step of this
    quest all drivers are converted to .remove_new() which already returns
    void.
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-51-u.kleine-koenig@pengutronix.de
    Stable-dep-of: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vc4: tests: Fix UAF in the mock helpers [+ + +]
Author: Maxime Ripard <mripard@kernel.org>
Date:   Tue Oct 24 12:56:40 2023 +0200

    drm/vc4: tests: Fix UAF in the mock helpers
    
    [ Upstream commit cdcd6aef9db5797995d4153ea19fdf56d189f0e4 ]
    
    The VC4 mock helpers allocate the CRTC, encoders and connectors using a
    call to kunit_kzalloc(), but the DRM device they are attache to survives
    for longer than the test itself which leads to use-after-frees reported
    by KASAN.
    
    Switch to drmm_kzalloc to tie the lifetime of these objects to the main
    DRM device.
    
    Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure")
    Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Closes: https://lore.kernel.org/all/CA+G9fYvJA2HGqzR9LGgq63v0SKaUejHAE6f7+z9cwWN-ourJ_g@mail.gmail.com/
    Tested-by: Anders Roxell <anders.roxell@linaro.org>
    Reviewed-by: Maíra Canal <mcanal@igalia.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231024105640.352752-1-mripard@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Aug 3 20:01:37 2023 -0700

    drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
    
    [ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
    
    Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
    might not be set.  This causes Kconfig warnings and a build error.
    
    WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
      Depends on [n]: GENERIC_PHY [=n]
      Selected by [y]:
      - DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y] && OF [=y] && HAS_IOMEM [=y]
      - DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y] && OF [=y] && HAS_IOMEM [=y]
    
    (drm/bridge/cadence/Kconfig was found by inspection.)
    
    aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function `samsung_dsim_set_phy_ctrl':
    drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to `phy_mipi_dphy_get_default_config_for_hsclk'
    
    Prevent these warnings and build error by also selecting GENERIC_PHY
    whenever selecting GENERIC_PHY_MIPI_DPHY.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
    Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Aleksandr Nogikh <nogikh@google.com>
    Link: lore.kernel.org/r/20230803144227.2187749-1-nogikh@google.com
    Cc: Adam Ford <aford173@gmail.com>
    Cc: Maxime Ripard <maxime.ripard@bootlin.com>
    Cc: Guido Günther <agx@sigxcpu.org>
    Cc: Robert Chiras <robert.chiras@nxp.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Cc: Andrzej Hajda <andrzej.hajda@intel.com>
    Cc: Robert Foss <rfoss@kernel.org>
    Cc: David Airlie <airlied@gmail.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Adam Ford <aford173@gmail.com>
    Tested-by: Aleksandr Nogikh <nogikh@google.com>
    Reviewed-by: Guido Günther <agx@sigxcpu.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230804030140.21395-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: it66121: Fix invalid connector dereference [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Fri Sep 1 15:01:23 2023 +0530

    drm: bridge: it66121: Fix invalid connector dereference
    
    [ Upstream commit d0375f6858c4ff7244b62b02eb5e93428e1916cd ]
    
    Fix the NULL pointer dereference when no monitor is connected, and the
    sound card is opened from userspace.
    
    Instead return an empty buffer (of zeroes) as the EDID information to
    the sound framework if there is no connector attached.
    
    Fixes: e0fd83dbe924 ("drm: bridge: it66121: Add audio support")
    Reported-by: Nishanth Menon <nm@ti.com>
    Closes: https://lore.kernel.org/all/20230825105849.crhon42qndxqif4i@gondola/
    Reviewed-by: Helen Koike <helen.koike@collabora.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Tested-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230901-it66121_edid-v2-1-aa59605336b9@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Aug 9 16:56:41 2023 +0200

    drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos
    
    [ Upstream commit 15f389da11257b806da75a070cfa41ca0cc15aae ]
    
    Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
    doesn't report empty level of packer header FIFO. In case of those SoCs,
    use the old way of waiting for empty command tranfsfer FIFO, removed
    recently by commit 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO before transfer").
    
    Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO before transfer")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230809145641.3213210-1-m.szyprowski@samsung.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: samsung-dsim: Initialize ULPS EXIT for i.MX8M DSIM [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Sun Jul 9 15:48:27 2023 +0200

    drm: bridge: samsung-dsim: Initialize ULPS EXIT for i.MX8M DSIM
    
    [ Upstream commit 192948f6a923bedf461b4aa09e70a25cfb8a6041 ]
    
    The ULPS EXIT is initialized to 0xaf in downstream BSP as well as older
    revisions of this patchset, in newer revisions of the DSIM patchset it
    was left out and set to 0. Fix it.
    
    Fixes: 4d562c70c4dc ("drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230709134827.449185-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Sep 1 16:39:56 2023 -0700

    drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers
    
    [ Upstream commit 3c4babae3c4a1ae05f8f3f5f3d50c440ead7ca6a ]
    
    Based on grepping through the source code these drivers appear to be
    missing a call to drm_atomic_helper_shutdown() at system shutdown time
    and at driver remove (or unbind) time. Among other things, this means
    that if a panel is in use that it won't be cleanly powered off at
    system shutdown time.
    
    The fact that we should call drm_atomic_helper_shutdown() in the case
    of OS shutdown/restart and at driver remove (or unbind) time comes
    straight out of the kernel doc "driver instance overview" in
    drm_drv.c.
    
    A few notes about these fixes:
    - I confirmed that these drivers were all DRIVER_MODESET type drivers,
      which I believe makes this relevant.
    - I confirmed that these drivers were all DRIVER_ATOMIC.
    - When adding drm_atomic_helper_shutdown() to the remove/unbind path,
      I added it after drm_kms_helper_poll_fini() when the driver had
      it. This seemed to be what other drivers did. If
      drm_kms_helper_poll_fini() wasn't there I added it straight after
      drm_dev_unregister().
    - This patch deals with drivers using the component model in similar
      ways as the patch ("drm: Call drm_atomic_helper_shutdown() at
      shutdown time for misc drivers")
    - These fixes rely on the patch ("drm/atomic-helper:
      drm_atomic_helper_shutdown(NULL) should be a noop") to simplify
      shutdown.
    
    Suggested-by: Maxime Ripard <mripard@kernel.org>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # tilcdc
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.5.I771eb4bd03d8772b19e7dcfaef3e2c167bce5846@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: mediatek: mtk_dsi: Fix NO_EOT_PACKET settings/handling [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Tue May 23 12:42:34 2023 +0200

    drm: mediatek: mtk_dsi: Fix NO_EOT_PACKET settings/handling
    
    [ Upstream commit 5855d422a6f250f3518f43b49092c8e87a5e42be ]
    
    Due to the initial confusion about MIPI_DSI_MODE_EOT_PACKET, properly
    renamed to MIPI_DSI_MODE_NO_EOT_PACKET, reflecting its actual meaning,
    both the DSI_TXRX_CON register setting for bit (HSTX_)DIS_EOT and the
    later calculation for horizontal sync-active (HSA), back (HBP) and
    front (HFP) porches got incorrect due to the logic being inverted.
    
    This means that a number of settings were wrong because....:
     - DSI_TXRX_CON register setting: bit (HSTX_)DIS_EOT should be
       set in order to disable the End of Transmission packet;
     - Horizontal Sync and Back/Front porches: The delta used to
       calculate all of HSA, HBP and HFP should account for the
       additional EOT packet.
    
    Before this change...
     - Bit (HSTX_)DIS_EOT was being set when EOT packet was enabled;
     - For HSA/HBP/HFP delta... all three were wrong, as words were
       added when EOT disabled, instead of when EOT packet enabled!
    
    Invert the logic around flag MIPI_DSI_MODE_NO_EOT_PACKET in the
    MediaTek DSI driver to fix the aforementioned issues.
    
    Fixes: 8b2b99fd7931 ("drm/mediatek: dsi: Fine tune the line time caused by EOTp")
    Fixes: c87d1c4b5b9a ("drm/mediatek: dsi: Use symbolized register definition")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Tested-by: Michael Walle <mwalle@kernel.org>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230523104234.7849-1-angelogioacchino.delregno@collabora.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: mfd: mt6397: Split out compatible for MediaTek MT6366 PMIC [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Thu Sep 28 16:55:24 2023 +0800

    dt-bindings: mfd: mt6397: Split out compatible for MediaTek MT6366 PMIC
    
    [ Upstream commit 61fdd1f1d2c183ec256527d16d75e75c3582af82 ]
    
    The MT6366 PMIC is mostly, but not fully, compatible with MT6358. It has
    a different set of regulators. Specifically, it lacks the camera related
    VCAM* LDOs and VLDO28, but has additional VM18, VMDDR, and VSRAM_CORE LDOs.
    
    The PMICs contain a chip ID register that can be used to detect which
    exact model is preset, so it is possible to share a common base
    compatible string.
    
    Add a separate compatible for the MT6366 PMIC, with a fallback to the
    MT6358 PMIC.
    
    Fixes: 49be16305587 ("dt-bindings: mfd: Add compatible for the MediaTek MT6366 PMIC")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20230928085537.3246669-2-wenst@chromium.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
erofs: fix erofs_insert_workgroup() lockref usage [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Tue Oct 31 14:05:24 2023 +0800

    erofs: fix erofs_insert_workgroup() lockref usage
    
    [ Upstream commit 1a0ac8bd7a4fa5b2f4ef14c3b1e9d6e5a5faae06 ]
    
    As Linus pointed out [1], lockref_put_return() is fundamentally
    designed to be something that can fail.  It behaves as a fastpath-only
    thing, and the failure case needs to be handled anyway.
    
    Actually, since the new pcluster was just allocated without being
    populated, it won't be accessed by others until it is inserted into
    XArray, so lockref helpers are actually unneeded here.
    
    Let's just set the proper reference count on initializing.
    
    [1] https://lore.kernel.org/r/CAHk-=whCga8BeQnJ3ZBh_Hfm9ctba_wpF444LpwRybVNMzO6Dw@mail.gmail.com
    
    Fixes: 7674a42f35ea ("erofs: use struct lockref to replace handcrafted approach")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20231031060524.1103921-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: move 'ix' sanity check to corrent position [+ + +]
Author: Gou Hao <gouhao@uniontech.com>
Date:   Wed Sep 6 09:33:41 2023 +0800

    ext4: move 'ix' sanity check to corrent position
    
    [ Upstream commit af90a8f4a09ec4a3de20142e37f37205d4687f28 ]
    
    Check 'ix' before it is used.
    
    Fixes: 80e675f906db ("ext4: optimize memmmove lengths in extent/index insertions")
    Signed-off-by: Gou Hao <gouhao@uniontech.com>
    Link: https://lore.kernel.org/r/20230906013341.7199-1-gouhao@uniontech.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: compress: fix deadloop in f2fs_write_cache_pages() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon Aug 28 22:04:14 2023 +0800

    f2fs: compress: fix deadloop in f2fs_write_cache_pages()
    
    [ Upstream commit c5d3f9b7649abb20aa5ab3ebff9421a171eaeb22 ]
    
    With below mount option and testcase, it hangs kernel.
    
    1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs
    2. touch /mnt/f2fs/file
    3. chattr +c /mnt/f2fs/file
    4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1
    5. sync
    6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc
    7. sync
    
    INFO: task sync:4788 blocked for more than 120 seconds.
          Not tainted 6.5.0-rc1+ #322
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:sync            state:D stack:0     pid:4788  ppid:509    flags:0x00000002
    Call Trace:
     <TASK>
     __schedule+0x335/0xf80
     schedule+0x6f/0xf0
     wb_wait_for_completion+0x5e/0x90
     sync_inodes_sb+0xd8/0x2a0
     sync_inodes_one_sb+0x1d/0x30
     iterate_supers+0x99/0xf0
     ksys_sync+0x46/0xb0
     __do_sys_sync+0x12/0x20
     do_syscall_64+0x3f/0x90
     entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    The reason is f2fs_all_cluster_page_ready() assumes that pages array should
    cover at least one cluster, otherwise, it will always return false, result
    in deadloop.
    
    By default, pages array size is 16, and it can cover the case cluster_size
    is equal or less than 16, for the case cluster_size is larger than 16, let's
    allocate memory of pages array dynamically.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: compress: fix to avoid redundant compress extension [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon Aug 28 22:04:17 2023 +0800

    f2fs: compress: fix to avoid redundant compress extension
    
    [ Upstream commit 7e1b150fece033703a824df1bbc03df091ea53cc ]
    
    With below script, redundant compress extension will be parsed and added
    by parse_options(), because parse_options() doesn't check whether the
    extension is existed or not, fix it.
    
    1. mount -t f2fs -o compress_extension=so /dev/vdb /mnt/f2fs
    2. mount -t f2fs -o remount,compress_extension=so /mnt/f2fs
    3. mount|grep f2fs
    
    /dev/vdb on /mnt/f2fs type f2fs (...,compress_extension=so,compress_extension=so,...)
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Fixes: 151b1982be5d ("f2fs: compress: add nocompress extensions support")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: compress: fix to avoid use-after-free on dic [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon Aug 28 22:04:15 2023 +0800

    f2fs: compress: fix to avoid use-after-free on dic
    
    [ Upstream commit b0327c84e91a0f4f0abced8cb83ec86a7083f086 ]
    
    Call trace:
     __memcpy+0x128/0x250
     f2fs_read_multi_pages+0x940/0xf7c
     f2fs_mpage_readpages+0x5a8/0x624
     f2fs_readahead+0x5c/0x110
     page_cache_ra_unbounded+0x1b8/0x590
     do_sync_mmap_readahead+0x1dc/0x2e4
     filemap_fault+0x254/0xa8c
     f2fs_filemap_fault+0x2c/0x104
     __do_fault+0x7c/0x238
     do_handle_mm_fault+0x11bc/0x2d14
     do_mem_abort+0x3a8/0x1004
     el0_da+0x3c/0xa0
     el0t_64_sync_handler+0xc4/0xec
     el0t_64_sync+0x1b4/0x1b8
    
    In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if
    we hit cached page in compress_inode's cache, dic may be released, it needs
    break the loop rather than continuing it, in order to avoid accessing
    invalid dic pointer.
    
    Fixes: 6ce19aff0b8c ("f2fs: compress: add compress_inode to cache compressed blocks")
    Signed-off-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 drop meta_inode's page cache in f2fs_put_super() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Sep 5 12:57:53 2023 +0800

    f2fs: fix to drop meta_inode's page cache in f2fs_put_super()
    
    [ Upstream commit a4639380bbe66172df329f8b54aa7d2e943f0f64 ]
    
    syzbot reports a kernel bug as below:
    
    F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1
    kernel BUG at fs/f2fs/super.c:1639!
    CPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0
    RIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639
    Call Trace:
     generic_shutdown_super+0x161/0x3c0 fs/super.c:693
     kill_block_super+0x3b/0x70 fs/super.c:1646
     kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879
     deactivate_locked_super+0x9a/0x170 fs/super.c:481
     deactivate_super+0xde/0x100 fs/super.c:514
     cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254
     task_work_run+0x14d/0x240 kernel/task_work.c:179
     resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
     exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
     exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204
     __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
     syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296
     do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    In f2fs_put_super(), it tries to do sanity check on dirty and IO
    reference count of f2fs, once there is any reference count leak,
    it will trigger panic.
    
    The root case is, during f2fs_put_super(), if there is any IO error
    in f2fs_wait_on_all_pages(), we missed to truncate meta_inode's page
    cache later, result in panic, fix this case.
    
    Fixes: 20872584b8c0 ("f2fs: fix to drop all dirty meta/node pages during umount()")
    Reported-by: syzbot+ebd7072191e2eddd7d6e@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000a14f020604a62a98@google.com
    Signed-off-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 initialize map.m_pblk in f2fs_precache_extents() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sat Oct 7 15:45:52 2023 +0800

    f2fs: fix to initialize map.m_pblk in f2fs_precache_extents()
    
    [ Upstream commit 8b07c1fb0f1ad139373c8253f2fad8bc43fab07d ]
    
    Otherwise, it may print random physical block address in tracepoint
    of f2fs_map_blocks() as below:
    
    f2fs_map_blocks: dev = (253,16), ino = 2297, file offset = 0, start blkaddr = 0xa356c421, len = 0x0, flags = 0
    
    Fixes: c4020b2da4c9 ("f2fs: support F2FS_IOC_PRECACHE_EXTENTS")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: fsl-diu-fb: mark wr_reg_wa() static [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 8 13:58:42 2023 +0100

    fbdev: fsl-diu-fb: mark wr_reg_wa() static
    
    [ Upstream commit a5035c81847430dfa3482807b07325f29e9e8c09 ]
    
    wr_reg_wa() is not an appropriate name for a global function, and doesn't need
    to be global anyway, so mark it static and avoid the warning:
    
    drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes]
    
    Fixes: 0d9dab39fbbe ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: imsttfb: fix a resource leak in probe [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Oct 27 15:05:44 2023 +0300

    fbdev: imsttfb: fix a resource leak in probe
    
    [ Upstream commit aba6ab57a910ad4b940c2024d15f2cdbf5b7f76b ]
    
    I've re-written the error handling but the bug is that if init_imstt()
    fails we need to call iounmap(par->cmap_regs).
    
    Fixes: c75f5a550610 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: imsttfb: fix double free in probe() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Oct 27 15:04:56 2023 +0300

    fbdev: imsttfb: fix double free in probe()
    
    [ Upstream commit e08c30efda21ef4c0ec084a3a9581c220b442ba9 ]
    
    The init_imstt() function calls framebuffer_release() on error and then
    the probe() function calls it again.  It should only be done in probe.
    
    Fixes: 518ecb6a209f ("fbdev: imsttfb: Fix error path of imsttfb_probe()")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messaging [+ + +]
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Thu Oct 5 15:28:23 2023 +0100

    firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messaging
    
    [ Upstream commit 2d698e8b4fd22374dac0a2d5150ab24d57a222ab ]
    
    An FF-A ABI could support both the SMC32 and SMC64 conventions.
    A callee that runs in the AArch64 execution state and implements such
    an ABI must implement both SMC32 and SMC64 conventions of the ABI.
    
    So the FF-A drivers will need the option to choose the mode irrespective
    of FF-A version and the partition execution mode flag in the partition
    information.
    
    Let us remove the check on the FF-A version for allowing the selection
    of 32bit mode of messaging. The driver will continue to set the 32-bit
    mode if the partition execution mode flag specified that the partition
    supports only 32-bit execution.
    
    Fixes: 106b11b1ccd5 ("firmware: arm_ffa: Set up 32bit execution mode flag using partiion property")
    Link: https://lore.kernel.org/r/20231005142823.278121-1-sudeep.holla@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA device [+ + +]
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Tue Oct 3 09:59:32 2023 +0100

    firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA device
    
    [ Upstream commit 7d0bc6360f17ea323ab25939a34857123d7d87e5 ]
    
    Commit 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical
    partitions") added an ID to the FFA device using ida_alloc() and append
    the same to "arm-ffa" to make up a unique device name. However it missed
    to stash the id value in ffa_dev to help freeing the ID later when the
    device is destroyed.
    
    Due to the missing/unassigned ID in FFA device, we get the following
    warning when the FF-A device is unregistered.
    
      |   ida_free called for id=0 which is not allocated.
      |   WARNING: CPU: 7 PID: 1 at lib/idr.c:525 ida_free+0x114/0x164
      |   CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4 #209
      |   pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
      |   pc : ida_free+0x114/0x164
      |   lr : ida_free+0x114/0x164
      |   Call trace:
      |    ida_free+0x114/0x164
      |    ffa_release_device+0x24/0x3c
      |    device_release+0x34/0x8c
      |    kobject_put+0x94/0xf8
      |    put_device+0x18/0x24
      |    klist_devices_put+0x14/0x20
      |    klist_next+0xc8/0x114
      |    bus_for_each_dev+0xd8/0x144
      |    arm_ffa_bus_exit+0x30/0x54
      |    ffa_init+0x68/0x330
      |    do_one_initcall+0xdc/0x250
      |    do_initcall_level+0x8c/0xac
      |    do_initcalls+0x54/0x94
      |    do_basic_setup+0x1c/0x28
      |    kernel_init_freeable+0x104/0x170
      |    kernel_init+0x20/0x1a0
      |    ret_from_fork+0x10/0x20
    
    Fix the same by actually assigning the ID in the FFA device this time
    for real.
    
    Fixes: 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions")
    Link: https://lore.kernel.org/r/20231003085932.3553985-1-sudeep.holla@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: tegra: Add suspend hook and reset BPMP IPC early on resume [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Mon Oct 9 15:35:56 2023 +0530

    firmware: tegra: Add suspend hook and reset BPMP IPC early on resume
    
    [ Upstream commit ea608a01d4ee66f8b51070e623f9adb8684c0dd4 ]
    
    Add suspend hook and a 'suspended' field in the 'struct tegra_bpmp'
    to mark if BPMP is suspended. Also, add a 'flags' field in the
    'struct tegra_bpmp_message' whose 'TEGRA_BPMP_MESSAGE_RESET' bit can be
    set from the Tegra MC driver to signal that the reset of BPMP IPC
    channels is required before sending MRQ to the BPMP FW. Together both
    the fields allow us to handle any requests that might be sent too soon
    as they can cause hang during system resume.
    
    One case where we see BPMP requests being sent before the BPMP driver
    has resumed is the memory bandwidth requests which are triggered by
    onlining the CPUs during system resume. The CPUs are onlined before the
    BPMP has resumed and we need to reset the BPMP IPC channels to handle
    these requests.
    
    The additional check for 'flags' is done to avoid any un-intended BPMP
    IPC reset if the tegra_bpmp_transfer*() API gets called during suspend
    sequence after the BPMP driver is suspended.
    
    Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth")
    Co-developed-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: ti_sci: Mark driver as non removable [+ + +]
Author: Dhruva Gole <d-gole@ti.com>
Date:   Thu Sep 21 14:40:26 2023 +0530

    firmware: ti_sci: Mark driver as non removable
    
    [ Upstream commit 7b7a224b1ba1703583b25a3641ad9798f34d832a ]
    
    The TI-SCI message protocol provides a way to communicate between
    various compute processors with a central system controller entity. It
    provides the fundamental device management capability and clock control
    in the SOCs that it's used in.
    
    The remove function failed to do all the necessary cleanup if
    there are registered users. Some things are freed however which
    likely results in an oops later on.
    
    Ensure that the driver isn't unbound by suppressing its bind and unbind
    sysfs attributes. As the driver is built-in there is no way to remove
    device once bound.
    
    We can also remove the ti_sci_remove call along with the
    ti_sci_debugfs_destroy as there are no callers for it any longer.
    
    Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Closes: https://lore.kernel.org/linux-arm-kernel/20230216083908.mvmydic5lpi3ogo7@pengutronix.de/
    Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Dhruva Gole <d-gole@ti.com>
    Link: https://lore.kernel.org/r/20230921091025.133130-1-d-gole@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Fix termination state for idr_for_each_entry_ul() [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Tue Oct 24 09:53:33 2023 +1100

    Fix termination state for idr_for_each_entry_ul()
    
    [ Upstream commit e8ae8ad479e2d037daa33756e5e72850a7bd37a9 ]
    
    The comment for idr_for_each_entry_ul() states
    
      after normal termination @entry is left with the value NULL
    
    This is not correct in the case where UINT_MAX has an entry in the idr.
    In that case @entry will be non-NULL after termination.
    No current code depends on the documentation being correct, but to
    save future code we should fix it.
    
    Also fix idr_for_each_entry_continue_ul().  While this is not documented
    as leaving @entry as NULL, the mellanox driver appears to depend on
    it doing so.  So make that explicit in the documentation as well as in
    the code.
    
    Fixes: e33d2b74d805 ("idr: fix overflow case for idr_for_each_entry_ul()")
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Chris Mi <chrism@mellanox.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
futex: Don't include process MM in futex key on no-MMU [+ + +]
Author: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Date:   Thu Oct 19 16:45:49 2023 -0400

    futex: Don't include process MM in futex key on no-MMU
    
    [ Upstream commit c73801ae4f22b390228ebf471d55668e824198b6 ]
    
    On no-MMU, all futexes are treated as private because there is no need
    to map a virtual address to physical to match the futex across
    processes. This doesn't quite work though, because private futexes
    include the current process's mm_struct as part of their key. This makes
    it impossible for one process to wake up a shared futex being waited on
    in another process.
    
    Fix this bug by excluding the mm_struct from the key. With
    a single address space, the futex address is already a unique key.
    
    Fixes: 784bdf3bb694 ("futex: Assume all mappings are private on !MMU systems")
    Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Darren Hart <dvhart@infradead.org>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: André Almeida <andrealmeid@igalia.com>
    Link: https://lore.kernel.org/r/20231019204548.1236437-2-ben.wolsieffer@hefring.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
genirq/matrix: Exclude managed interrupts in irq_matrix_allocated() [+ + +]
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Fri Oct 20 15:25:22 2023 +0800

    genirq/matrix: Exclude managed interrupts in irq_matrix_allocated()
    
    [ Upstream commit a0b0bad10587ae2948a7c36ca4ffc206007fbcf3 ]
    
    When a CPU is about to be offlined, x86 validates that all active
    interrupts which are targeted to this CPU can be migrated to the remaining
    online CPUs. If not, the offline operation is aborted.
    
    The validation uses irq_matrix_allocated() to retrieve the number of
    vectors which are allocated on the outgoing CPU. The returned number of
    allocated vectors includes also vectors which are associated to managed
    interrupts.
    
    That's overaccounting because managed interrupts are:
    
      - not migrated when the affinity mask of the interrupt targets only
        the outgoing CPU
    
      - migrated to another CPU, but in that case the vector is already
        pre-allocated on the potential target CPUs and must not be taken into
        account.
    
    As a consequence the check whether the remaining online CPUs have enough
    capacity for migrating the allocated vectors from the outgoing CPU might
    fail incorrectly.
    
    Let irq_matrix_allocated() return only the number of allocated non-managed
    interrupts to make this validation check correct.
    
    [ tglx: Amend changelog and fixup kernel-doc comment ]
    
    Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator")
    Reported-by: Wendy Wang <wendy.wang@intel.com>
    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20231020072522.557846-1-yu.c.chen@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpu: host1x: Correct allocated size for contexts [+ + +]
Author: Johnny Liu <johnliu@nvidia.com>
Date:   Fri Sep 1 14:59:09 2023 +0300

    gpu: host1x: Correct allocated size for contexts
    
    [ Upstream commit e889a311f74f4ae8bd40755a2c58d02e1c684fef ]
    
    Original implementation over allocates the memory size for the
    contexts list. The size of memory for the contexts list is based
    on the number of iommu groups specified in the device tree.
    
    Fixes: 8aa5bcb61612 ("gpu: host1x: Add context device management code")
    Signed-off-by: Johnny Liu <johnliu@nvidia.com>
    Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230901115910.701518-1-cyndis@kapsi.fi
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gve: Use size_add() in call to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 12:17:49 2023 -0600

    gve: Use size_add() in call to struct_size()
    
    [ Upstream commit d692873cbe861a870cdc9cbfb120eefd113c3dfd ]
    
    If, for any reason, `tx_stats_num + rx_stats_num` wraps around, the
    protection that struct_size() adds against potential integer overflows
    is defeated. Fix this by hardening call to struct_size() with size_add().
    
    Fixes: 691f4077d560 ("gve: Replace zero-length array with flexible-array member")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hid: cp2112: Fix duplicate workqueue initialization [+ + +]
Author: Danny Kaehn <danny.kaehn@plexus.com>
Date:   Tue Sep 19 16:22:45 2023 -0500

    hid: cp2112: Fix duplicate workqueue initialization
    
    [ Upstream commit e3c2d2d144c082dd71596953193adf9891491f42 ]
    
    Previously the cp2112 driver called INIT_DELAYED_WORK within
    cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
    workqueue on subsequent IRQ startups following an initial request. This
    resulted in a warning in set_work_data in workqueue.c, as well as a rare
    NULL dereference within process_one_work in workqueue.c.
    
    Initialize the workqueue within _probe instead.
    
    Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling")
    Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chip [+ + +]
Author: Danny Kaehn <danny.kaehn@plexus.com>
Date:   Wed Oct 11 13:23:17 2023 -0500

    hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chip
    
    [ Upstream commit dc3115e6c5d9863ec1a9ff1acf004ede93c34361 ]
    
    Previously cp2112_gpio_irq_shutdown() always cancelled the
    gpio_poll_worker, even if other IRQs were still active, and did not set
    the gpio_poll flag to false. This resulted in any call to _shutdown()
    resulting in interrupts no longer functioning on the chip until a
    _remove() occurred (a.e. the cp2112 is unplugged or system rebooted).
    
    Only cancel polling if all IRQs are disabled/masked, and correctly set
    the gpio_poll flag, allowing polling to restart when an interrupt is
    next enabled.
    
    Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
    Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling")
    Link: https://lore.kernel.org/r/20231011182317.1053344-1-danny.kaehn@plexus.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: cp2112: Make irq_chip immutable [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jul 3 21:52:13 2023 +0300

    HID: cp2112: Make irq_chip immutable
    
    [ Upstream commit 3e2977c425ad2789ca18084fff913cceacae75a2 ]
    
    Since recently, the kernel is nagging about mutable irq_chips:
    
       "not an immutable chip, please consider fixing it!"
    
    Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new
    helper functions and call the appropriate gpiolib functions.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230703185222.50554-4-andriy.shevchenko@linux.intel.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Stable-dep-of: dc3115e6c5d9 ("hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chip")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() only [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Oct 10 12:20:18 2023 +0200

    HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() only
    
    [ Upstream commit 11ca0322a41920df2b462d2e45b0731e47ff475b ]
    
    Restarting IO causes 2 problems:
    
    1. Some devices do not like IO being restarted this was addressed in
       commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication
       if not necessary"), but that change has issues of its own and needs to
       be reverted.
    
    2. Restarting IO and specifically calling hid_device_io_stop() causes
       received packets to be missed, which may cause connect-events to
       get missed.
    
    Restarting IO was introduced in commit 91cf9a98ae41 ("HID: logitech-hidpp:
    make .probe usbhid capable") to allow to retrieve the device's name and
    serial number and store these in hdev->name and hdev->uniq before
    connecting any hid subdrivers (hid-input, hidraw) exporting this info
    to userspace.
    
    But this does not require restarting IO, this merely requires deferring
    calling hid_connect(). Calling hid_hw_start() with a connect-mask of
    0 makes it skip calling hid_connect(), so hidpp_probe() can simply call
    hid_connect() later without needing to restart IO.
    
    Remove the stop + restart of IO and instead just call hid_connect() later
    to avoid the issues caused by restarting IO.
    
    Now that IO is no longer stopped, hid_hw_close() must be called at the end
    of probe() to balance the hid_hw_open() done at the beginning probe().
    
    This series has been tested on the following devices:
    Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0)
    Logitech M720 Triathlon (bluetooth, HID++ 4.5)
    Logitech M720 Triathlon (unifying, HID++ 4.5)
    Logitech K400 Pro (unifying, HID++ 4.1)
    Logitech K270 (eQUAD nano Lite, HID++ 2.0)
    Logitech M185 (eQUAD nano Lite, HID++ 4.5)
    Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0)
    Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0)
    
    And by bentiss:
    Logitech Touchpad T650 (unifying)
    Logitech Touchpad T651 (bluetooth)
    Logitech MX Master 3B (BLE)
    Logitech G403 (plain USB / Gaming receiver)
    
    Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary")
    Suggested-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231010102029.111003-2-hdegoede@redhat.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-hidpp: Move get_wireless_feature_index() check to hidpp_connect_event() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Oct 10 12:20:20 2023 +0200

    HID: logitech-hidpp: Move get_wireless_feature_index() check to hidpp_connect_event()
    
    [ Upstream commit ba9de350509504fb748837b71e23d7e84c83d93c ]
    
    Calling get_wireless_feature_index() from probe() causes
    the wireless_feature_index to only get set for unifying devices which
    are already connected at probe() time. It does not get set for devices
    which connect later.
    
    Fix this by moving get_wireless_feature_index() to hidpp_connect_event(),
    this does not make a difference for devices connected at probe() since
    probe() will queue the hidpp_connect_event() for those at probe time.
    
    This series has been tested on the following devices:
    Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0)
    Logitech M720 Triathlon (bluetooth, HID++ 4.5)
    Logitech M720 Triathlon (unifying, HID++ 4.5)
    Logitech K400 Pro (unifying, HID++ 4.1)
    Logitech K270 (eQUAD nano Lite, HID++ 2.0)
    Logitech M185 (eQUAD nano Lite, HID++ 4.5)
    Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0)
    Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0)
    
    And by bentiss:
    Logitech Touchpad T650 (unifying)
    Logitech Touchpad T651 (bluetooth)
    Logitech MX Master 3B (BLE)
    Logitech G403 (plain USB / Gaming receiver)
    
    Fixes: 0da0a63b7cba ("HID: logitech-hidpp: Support WirelessDeviceStatus connect events")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231010102029.111003-4-hdegoede@redhat.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-hidpp: Revert "Don't restart communication if not necessary" [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Oct 10 12:20:19 2023 +0200

    HID: logitech-hidpp: Revert "Don't restart communication if not necessary"
    
    [ Upstream commit 55bf70362ffc4ddd7c8745e2fe880edac00e4aff ]
    
    Commit 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable")
    makes hidpp_probe() first call hid_hw_start(hdev, 0) to allow IO
    without connecting any hid subdrivers (hid-input, hidraw).
    
    This is done to allow to retrieve the device's name and serial number
    and store these in hdev->name and hdev->uniq.
    
    Then later on IO was stopped and started again with hid_hw_start(hdev,
    HID_CONNECT_DEFAULT) connecting hid-input and hidraw after the name
    and serial number have been setup.
    
    Commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication
    if not necessary") changed the probe() code to only do the start with
    a 0 connect-mask + restart later for unifying devices.
    
    But for non unifying devices hdev->name and hdev->uniq are updated too.
    So this change re-introduces the problem for which the start with
    a 0 connect-mask + restart later behavior was introduced.
    
    The previous patch in this series changes the unifying path to instead of
    restarting IO only call hid_connect() later. This avoids possible issues
    with restarting IO seen on non unifying devices.
    
    Revert the change to limit the restart behavior to unifying devices to
    fix hdev->name changing after userspace facing devices have already been
    registered.
    
    This series has been tested on the following devices:
    Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0)
    Logitech M720 Triathlon (bluetooth, HID++ 4.5)
    Logitech M720 Triathlon (unifying, HID++ 4.5)
    Logitech K400 Pro (unifying, HID++ 4.1)
    Logitech K270 (eQUAD nano Lite, HID++ 2.0)
    Logitech M185 (eQUAD nano Lite, HID++ 4.5)
    Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0)
    Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0)
    
    And by bentiss:
    Logitech Touchpad T650 (unifying)
    Logitech Touchpad T651 (bluetooth)
    Logitech MX Master 3B (BLE)
    Logitech G403 (plain USB / Gaming receiver)
    
    Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231010102029.111003-3-hdegoede@redhat.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: uclogic: Fix a work->entry not empty bug in __queue_work() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Oct 9 14:42:45 2023 +0800

    HID: uclogic: Fix a work->entry not empty bug in __queue_work()
    
    [ Upstream commit d45f72b3c275101a620dd69881343e0dda72f877 ]
    
    When CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch
    kernel and then the below work->entry not empty bug occurs.
    
    In hid_test_uclogic_exec_event_hook_test(), the filter->work is not
    initialized to be added to p.event_hooks->list, and then the
    schedule_work() in uclogic_exec_event_hook() will call __queue_work(),
    which check whether the work->entry is empty and cause the below
    warning call trace.
    
    So call INIT_WORK() with a fake work to solve the issue. After applying
    this patch, the below work->entry not empty bug never occurs.
    
     WARNING: CPU: 0 PID: 2177 at kernel/workqueue.c:1787 __queue_work.part.0+0x780/0xad0
     Modules linked in:
     CPU: 0 PID: 2177 Comm: kunit_try_catch Tainted: G    B   W        N 6.6.0-rc2+ #30
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
     RIP: 0010:__queue_work.part.0+0x780/0xad0
     Code: 44 24 20 0f b6 00 84 c0 74 08 3c 03 0f 8e 52 03 00 00 f6 83 00 01 00 00 02 74 6f 4c 89 ef e8 c7 d8 f1 02 f3 90 e9 e5 f8 ff ff <0f> 0b e9 63 fc ff ff 89 e9 49 8d 57 68 4c 89 e6 4c 89 ff 83 c9 02
     RSP: 0000:ffff888102bb7ce8 EFLAGS: 00010086
     RAX: 0000000000000000 RBX: ffff888106b8e460 RCX: ffffffff84141cc7
     RDX: 1ffff11020d71c8c RSI: 0000000000000004 RDI: ffff8881001d0118
     RBP: dffffc0000000000 R08: 0000000000000001 R09: ffffed1020576f92
     R10: 0000000000000003 R11: ffff888102bb7980 R12: ffff888106b8e458
     R13: ffff888119c38800 R14: 0000000000000000 R15: ffff8881001d0100
     FS:  0000000000000000(0000) GS:ffff888119c00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffff888119506000 CR3: 0000000005286001 CR4: 0000000000770ef0
     DR0: ffffffff8fdd6ce0 DR1: ffffffff8fdd6ce1 DR2: ffffffff8fdd6ce3
     DR3: ffffffff8fdd6ce5 DR6: 00000000fffe0ff0 DR7: 0000000000000600
     PKRU: 55555554
     Call Trace:
      <TASK>
      ? __warn+0xc9/0x260
      ? __queue_work.part.0+0x780/0xad0
      ? report_bug+0x345/0x400
      ? handle_bug+0x3c/0x70
      ? exc_invalid_op+0x14/0x40
      ? asm_exc_invalid_op+0x16/0x20
      ? _raw_spin_lock+0x87/0xe0
      ? __queue_work.part.0+0x780/0xad0
      ? __queue_work.part.0+0x249/0xad0
      queue_work_on+0x48/0x50
      uclogic_exec_event_hook.isra.0+0xf7/0x160
      hid_test_uclogic_exec_event_hook_test+0x2f1/0x5d0
      ? try_to_wake_up+0x151/0x13e0
      ? uclogic_exec_event_hook.isra.0+0x160/0x160
      ? _raw_spin_lock_irqsave+0x8d/0xe0
      ? __sched_text_end+0xa/0xa
      ? __sched_text_end+0xa/0xa
      ? migrate_enable+0x260/0x260
      ? kunit_try_run_case_cleanup+0xe0/0xe0
      kunit_generic_run_threadfn_adapter+0x4a/0x90
      ? kunit_try_catch_throw+0x80/0x80
      kthread+0x2b5/0x380
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x2d/0x70
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork_asm+0x11/0x20
      </TASK>
    
    Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: José Expósito <jose.exposito89@gmail.com>
    Link: https://lore.kernel.org/r/20231009064245.3573397-3-ruanjinjie@huawei.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: uclogic: Fix user-memory-access bug in uclogic_params_ugee_v2_init_event_hooks() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Oct 9 14:42:44 2023 +0800

    HID: uclogic: Fix user-memory-access bug in uclogic_params_ugee_v2_init_event_hooks()
    
    [ Upstream commit 91cfe0bbaa1c434d4271eb6e1d7aaa1fe8d121f6 ]
    
    When CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch kernel and
    then the below user-memory-access bug occurs.
    
    In hid_test_uclogic_params_cleanup_event_hooks(),it call
    uclogic_params_ugee_v2_init_event_hooks() with the first arg=NULL, so
    when it calls uclogic_params_ugee_v2_has_battery(), the hid_get_drvdata()
    will access hdev->dev with hdev=NULL, which will cause below
    user-memory-access.
    
    So add a fake_device with quirks member and call hid_set_drvdata()
    to assign hdev->dev->driver_data which avoids the null-ptr-def bug
    for drvdata->quirks in uclogic_params_ugee_v2_has_battery(). After applying
    this patch, the below user-memory-access bug never occurs.
    
     general protection fault, probably for non-canonical address 0xdffffc0000000329: 0000 [#1] PREEMPT SMP KASAN
     KASAN: probably user-memory-access in range [0x0000000000001948-0x000000000000194f]
     CPU: 5 PID: 2189 Comm: kunit_try_catch Tainted: G    B   W        N 6.6.0-rc2+ #30
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
     RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600
     Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00
     RSP: 0000:ffff88810679fc88 EFLAGS: 00010202
     RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000
     RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948
     RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0
     R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92
     R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080
     FS:  0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0
     DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6
     DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600
     PKRU: 55555554
     Call Trace:
      <TASK>
      ? die_addr+0x3d/0xa0
      ? exc_general_protection+0x144/0x220
      ? asm_exc_general_protection+0x22/0x30
      ? uclogic_params_ugee_v2_init_event_hooks+0x87/0x600
      ? sched_clock_cpu+0x69/0x550
      ? uclogic_parse_ugee_v2_desc_gen_params+0x70/0x70
      ? load_balance+0x2950/0x2950
      ? rcu_trc_cmpxchg_need_qs+0x67/0xa0
      hid_test_uclogic_params_cleanup_event_hooks+0x9e/0x1a0
      ? uclogic_params_ugee_v2_init_event_hooks+0x600/0x600
      ? __switch_to+0x5cf/0xe60
      ? migrate_enable+0x260/0x260
      ? __kthread_parkme+0x83/0x150
      ? kunit_try_run_case_cleanup+0xe0/0xe0
      kunit_generic_run_threadfn_adapter+0x4a/0x90
      ? kunit_try_catch_throw+0x80/0x80
      kthread+0x2b5/0x380
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x2d/0x70
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork_asm+0x11/0x20
      </TASK>
     Modules linked in:
     Dumping ftrace buffer:
        (ftrace buffer empty)
     ---[ end trace 0000000000000000 ]---
     RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600
     Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00
     RSP: 0000:ffff88810679fc88 EFLAGS: 00010202
     RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000
     RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948
     RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0
     R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92
     R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080
     FS:  0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0
     DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6
     DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600
     PKRU: 55555554
     Kernel panic - not syncing: Fatal exception
     Dumping ftrace buffer:
        (ftrace buffer empty)
     Kernel Offset: disabled
     Rebooting in 1 seconds..
    
    Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: José Expósito <jose.exposito89@gmail.com>
    Link: https://lore.kernel.org/r/20231009064245.3573397-2-ruanjinjie@huawei.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hsr: Prevent use after free in prp_create_tagged_frame() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Oct 27 15:19:01 2023 +0300

    hsr: Prevent use after free in prp_create_tagged_frame()
    
    [ Upstream commit 876f8ab52363f649bcc74072157dfd7adfbabc0d ]
    
    The prp_fill_rct() function can fail.  In that situation, it frees the
    skb and returns NULL.  Meanwhile on the success path, it returns the
    original skb.  So it's straight forward to fix bug by using the returned
    value.
    
    Fixes: 451d8123f897 ("net: prp: add packet handling support")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/57af1f28-7f57-4a96-bcd3-b7a0f2340845@moroto.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hte: tegra: Fix missing error code in tegra_hte_test_probe() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Thu Oct 26 00:53:28 2023 -0700

    hte: tegra: Fix missing error code in tegra_hte_test_probe()
    
    [ Upstream commit b7c3ca3553d1de5e86c85636828e186d30cd0628 ]
    
    The value of 'ret' is zero when of_hte_req_count() fails to get number
    of entitties to timestamp. And returning success(zero) on this failure
    path is incorrect.
    
    Fixes: 9a75a7cd03c9 ("hte: Add Tegra HTE test driver")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Dipen Patel <dipenp@nvidia.com>
    Signed-off-by: Dipen Patel <dipenp@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (axi-fan-control) Fix possible NULL pointer dereference [+ + +]
Author: Dragos Bogdan <dragos.bogdan@analog.com>
Date:   Wed Oct 25 15:21:00 2023 +0200

    hwmon: (axi-fan-control) Fix possible NULL pointer dereference
    
    [ Upstream commit 2a5b3370a1d9750eca325292e291c8c7cb8cf2e0 ]
    
    axi_fan_control_irq_handler(), dependent on the private
    axi_fan_control_data structure, might be called before the hwmon
    device is registered. That will cause an "Unable to handle kernel
    NULL pointer dereference" error.
    
    Fixes: 8412b410fa5e ("hwmon: Support ADI Fan Control IP")
    Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231025132100.649499-1-nuno.sa@analog.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (coretemp) Fix potentially truncated sysfs attribute name [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Wed Oct 25 20:23:16 2023 +0800

    hwmon: (coretemp) Fix potentially truncated sysfs attribute name
    
    [ Upstream commit bbfff736d30e5283ad09e748caff979d75ddef7f ]
    
    When build with W=1 and "-Werror=format-truncation", below error is
    observed in coretemp driver,
    
       drivers/hwmon/coretemp.c: In function 'create_core_data':
    >> drivers/hwmon/coretemp.c:393:34: error: '%s' directive output may be truncated writing likely 5 or more bytes into a region of size between 3 and 13 [-Werror=format-truncation=]
         393 |                          "temp%d_%s", attr_no, suffixes[i]);
             |                                  ^~
       drivers/hwmon/coretemp.c:393:26: note: assuming directive output of 5 bytes
         393 |                          "temp%d_%s", attr_no, suffixes[i]);
             |                          ^~~~~~~~~~~
       drivers/hwmon/coretemp.c:392:17: note: 'snprintf' output 7 or more bytes (assuming 22) into a destination of size 19
         392 |                 snprintf(tdata->attr_name[i], CORETEMP_NAME_LENGTH,
             |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         393 |                          "temp%d_%s", attr_no, suffixes[i]);
             |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       cc1: all warnings being treated as errors
    
    Given that
    1. '%d' could take 10 charactors,
    2. '%s' could take 10 charactors ("crit_alarm"),
    3. "temp", "_" and the NULL terminator take 6 charactors,
    fix the problem by increasing CORETEMP_NAME_LENGTH to 28.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310200443.iD3tUbbK-lkp@intel.com/
    Link: https://lore.kernel.org/r/20231025122316.836400-1-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (nct6775) Fix incorrect variable reuse in fan_div calculation [+ + +]
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Fri Sep 29 13:08:23 2023 -0700

    hwmon: (nct6775) Fix incorrect variable reuse in fan_div calculation
    
    commit 920057ad521dc8669e534736c2a12c14ec9fb2d7 upstream.
    
    In the regmap conversion in commit 4ef2774511dc ("hwmon: (nct6775)
    Convert register access to regmap API") I reused the 'reg' variable
    for all three register reads in the fan speed calculation loop in
    nct6775_update_device(), but failed to notice that the value from the
    first one (data->REG_FAN[i]) is actually used in the call to
    nct6775_select_fan_div() at the end of the loop body.  Since that
    patch the register value passed to nct6775_select_fan_div() has been
    (conditionally) incorrectly clobbered with the value of a different
    register than intended, which has in at least some cases resulted in
    fan speeds being adjusted down to zero.
    
    Fix this by using dedicated temporaries for the two intermediate
    register reads instead of 'reg'.
    
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Fixes: 4ef2774511dc ("hwmon: (nct6775) Convert register access to regmap API")
    Reported-by: Thomas Zajic <zlatko@gmx.at>
    Tested-by: Thomas Zajic <zlatko@gmx.at>
    Cc: stable@vger.kernel.org # v5.19+
    Link: https://lore.kernel.org/r/20230929200822.964-2-zev@bewilderbeest.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hwmon: (sch5627) Disallow write access if virtual registers are locked [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Thu Sep 7 07:26:36 2023 +0200

    hwmon: (sch5627) Disallow write access if virtual registers are locked
    
    [ Upstream commit 7da8a635436029957c5350da3acf51d78ed64071 ]
    
    When the lock bit inside SCH5627_REG_CTRL is set, then the virtual
    registers become read-only until the next power cycle.
    Disallow write access to those registers in such a case.
    
    Tested on a Fujitsu Esprimo P720.
    
    Fixes: aa9f833dfc12 ("hwmon: (sch5627) Add pwmX_auto_channels_temp support")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20230907052639.16491-3-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (sch5627) Use bit macros when accessing the control register [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Thu Sep 7 07:26:35 2023 +0200

    hwmon: (sch5627) Use bit macros when accessing the control register
    
    [ Upstream commit 7f0b28e0653f36b51542d25dd54ed312c397ecfc ]
    
    Use bit macros then accessing SCH5627_REG_CTRL, so that people
    do not need to look at the datasheet to find out what each bit
    does.
    
    Tested on a Fujitsu Esprimo P720.
    
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20230907052639.16491-2-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Stable-dep-of: 7da8a6354360 ("hwmon: (sch5627) Disallow write access if virtual registers are locked")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwrng: bcm2835 - Fix hwrng throughput regression [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Wed Sep 6 01:27:57 2023 +0200

    hwrng: bcm2835 - Fix hwrng throughput regression
    
    [ Upstream commit b58a36008bfa1aadf55f516bcbfae40c779eb54b ]
    
    The last RCU stall fix caused a massive throughput regression of the
    hwrng on Raspberry Pi 0 - 3. hwrng_msleep doesn't sleep precisely enough
    and usleep_range doesn't allow scheduling. So try to restore the
    best possible throughput by introducing hwrng_yield which interruptable
    sleeps for one jiffy.
    
    Some performance measurements on Raspberry Pi 3B+ (arm64/defconfig):
    
    sudo dd if=/dev/hwrng of=/dev/null count=1 bs=10000
    
    cpu_relax              ~138025 Bytes / sec
    hwrng_msleep(1000)         ~13 Bytes / sec
    hwrng_yield              ~2510 Bytes / sec
    
    Fixes: 96cb9d055445 ("hwrng: bcm2835 - use hwrng_msleep() instead of cpu_relax()")
    Link: https://lore.kernel.org/linux-arm-kernel/bc97ece5-44a3-4c4e-77da-2db3eb66b128@gmx.net/
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Reviewed-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>

hwrng: geode - fix accessing registers [+ + +]
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sun Sep 10 10:34:17 2023 +0200

    hwrng: geode - fix accessing registers
    
    [ Upstream commit 464bd8ec2f06707f3773676a1bd2c64832a3c805 ]
    
    When the membase and pci_dev pointer were moved to a new struct in priv,
    the actual membase users were left untouched, and they started reading
    out arbitrary memory behind the struct instead of registers. This
    unfortunately turned the RNG into a constant number generator, depending
    on the content of what was at that offset.
    
    To fix this, update geode_rng_data_{read,present}() to also get the
    membase via amd_geode_priv, and properly read from the right addresses
    again.
    
    Fixes: 9f6ec8dc574e ("hwrng: geode - Fix PCI device refcount leak")
    Reported-by: Timur I. Davletshin <timur.davletshin@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217882
    Tested-by: Timur I. Davletshin <timur.davletshin@gmail.com>
    Suggested-by: Jo-Philipp Wich <jo@mein.io>
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: iproc: handle invalid slave state [+ + +]
Author: Roman Bacik <roman.bacik@broadcom.com>
Date:   Thu Aug 24 14:23:51 2023 -0700

    i2c: iproc: handle invalid slave state
    
    [ Upstream commit ba15a14399c262f91ce30c19fcbdc952262dd1be ]
    
    Add the code to handle an invalid state when both bits S_RX_EVENT
    (indicating a transaction) and S_START_BUSY (indicating the end
    of transaction - transition of START_BUSY from 1 to 0) are set in
    the interrupt status register during a slave read.
    
    Signed-off-by: Roman Bacik <roman.bacik@broadcom.com>
    Fixes: 1ca1b4516088 ("i2c: iproc: handle Master aborted error")
    Acked-by: Ray Jui <ray.jui@broadcom.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Thu Sep 21 16:24:10 2023 +0800

    i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs
    
    [ Upstream commit cab63f64887616e3c4e31cfd8103320be6ebc8d3 ]
    
    put_device() needs to be called on failure of device_register()
    to give up the reference initialized in it to avoid refcount leak.
    
    Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230921082410.25548-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: fix potential memory leaks in i40e_remove() [+ + +]
Author: Andrii Staikov <andrii.staikov@intel.com>
Date:   Fri Sep 8 14:42:01 2023 +0200

    i40e: fix potential memory leaks in i40e_remove()
    
    [ Upstream commit 5ca636d927a106780451d957734f02589b972e2b ]
    
    Instead of freeing memory of a single VSI, make sure
    the memory for all VSIs is cleared before releasing VSIs.
    Add releasing of their resources in a loop with the iteration
    number equal to the number of allocated VSIs.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Andrii Staikov <andrii.staikov@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iavf: Fix promiscuous mode configuration flow messages [+ + +]
Author: Brett Creeley <brett.creeley@intel.com>
Date:   Mon Aug 21 17:01:44 2023 -0600

    iavf: Fix promiscuous mode configuration flow messages
    
    [ Upstream commit 221465de6bd8090ab61267f019866e8d2dd4ea3d ]
    
    Currently when configuring promiscuous mode on the AVF we detect a
    change in the netdev->flags. We use IFF_PROMISC and IFF_ALLMULTI to
    determine whether or not we need to request/release promiscuous mode
    and/or multicast promiscuous mode. The problem is that the AQ calls for
    setting/clearing promiscuous/multicast mode are treated separately. This
    leads to a case where we can trigger two promiscuous mode AQ calls in
    a row with the incorrect state. To fix this make a few changes.
    
    Use IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE instead of the previous
    IAVF_FLAG_AQ_[REQUEST|RELEASE]_[PROMISC|ALLMULTI] flags.
    
    In iavf_set_rx_mode() detect if there is a change in the
    netdev->flags in comparison with adapter->flags and set the
    IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE aq_required bit. Then in
    iavf_process_aq_command() only check for IAVF_FLAG_CONFIGURE_PROMISC_MODE
    and call iavf_set_promiscuous() if it's set.
    
    In iavf_set_promiscuous() check again to see which (if any) promiscuous
    mode bits have changed when comparing the netdev->flags with the
    adapter->flags. Use this to set the flags which get sent to the PF
    driver.
    
    Add a spinlock that is used for updating current_netdev_promisc_flags
    and only allows one promiscuous mode AQ at a time.
    
    [1] Fixes the fact that we will only have one AQ call in the aq_required
    queue at any one time.
    
    [2] Streamlines the change in promiscuous mode to only set one AQ
    required bit.
    
    [3] This allows us to keep track of the current state of the flags and
    also makes it so we can take the most recent netdev->flags promiscuous
    mode state.
    
    [4] This fixes the problem where a change in the netdev->flags can cause
    IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE to be set in iavf_set_rx_mode(),
    but cleared in iavf_set_promiscuous() before the change is ever made via
    AQ call.
    
    Fixes: 47d3483988f6 ("i40evf: Add driver support for promiscuous mode")
    Signed-off-by: Brett Creeley <brett.creeley@intel.com>
    Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF [+ + +]
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Tue Oct 24 13:01:58 2023 -0500

    IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF
    
    [ Upstream commit 2ef422f063b74adcc4a4a9004b0a87bb55e0a836 ]
    
    In the unlikely event that workqueue allocation fails and returns NULL in
    mlx5_mkey_cache_init(), delete the call to
    mlx5r_umr_resource_cleanup() (which frees the QP) in
    mlx5_ib_stage_post_ib_reg_umr_init().  This will avoid attempted double
    free of the same QP when __mlx5_ib_add() does its cleanup.
    
    Resolves a splat:
    
       Syzkaller reported a UAF in ib_destroy_qp_user
    
       workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR
       infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):
       failed to create work queue
       infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):
       mr cache init failed -12
       ==================================================================
       BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)
       Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642
    
       Call Trace:
       <TASK>
       kasan_report (mm/kasan/report.c:590)
       ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)
       mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)
       __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178)
       mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
       ...
       </TASK>
    
       Allocated by task 1642:
       __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026
       mm/slab_common.c:1039)
       create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720
       ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209)
       ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347)
       mlx5r_umr_resource_init (drivers/infiniband/hw/mlx5/umr.c:164)
       mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070)
       __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)
       mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
       ...
    
       Freed by task 1642:
       __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822)
       ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2112)
       mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)
       mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076
       drivers/infiniband/hw/mlx5/main.c:4065)
       __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)
       mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
       ...
    
    Fixes: 04876c12c19e ("RDMA/mlx5: Move init and cleanup of UMR to umr.c")
    Link: https://lore.kernel.org/r/1698170518-4006-1-git-send-email-george.kennedy@oracle.com
    Suggested-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/mlx5: Fix rdma counter binding for RAW QP [+ + +]
Author: Patrisious Haddad <phaddad@nvidia.com>
Date:   Mon Oct 9 13:41:20 2023 +0300

    IB/mlx5: Fix rdma counter binding for RAW QP
    
    [ Upstream commit c1336bb4aa5e809a622a87d74311275514086596 ]
    
    Previously when we had a RAW QP, we bound a counter to it when it moved
    to INIT state, using the counter context inside RQC.
    
    But when we try to modify that counter later in RTS state we used
    modify QP which tries to change the counter inside QPC instead of RQC.
    
    Now we correctly modify the counter set_id inside of RQC instead of QPC
    for the RAW QP.
    
    Fixes: d14133dd4161 ("IB/mlx5: Support set qp counter")
    Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
    Reviewed-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/2e5ab6713784a8fe997d19c508187a0dfecf2dfc.1696847964.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: frequency: adf4350: Use device managed functions and fix power down issue. [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Aug 28 14:27:16 2023 +0800

    iio: frequency: adf4350: Use device managed functions and fix power down issue.
    
    [ Upstream commit 9979cc64853b598518a485c2e554657d5c7a00c8 ]
    
    The devm_clk_get_enabled() helper:
        - calls devm_clk_get()
        - calls clk_prepare_enable() and registers what is needed in order to
          call clk_disable_unprepare() when needed, as a managed resource.
    
    Also replace devm_regulator_get() and regulator_enable() with
    devm_regulator_get_enable() helper and remove regulator_disable().
    
    Replace iio_device_register() with devm_iio_device_register() and remove
    iio_device_unregister().
    
    And st->reg is not used anymore, so remove it.
    
    As Jonathan pointed out, couple of things that are wrong:
    
    1) The device is powered down 'before' we unregister it with the
       subsystem and as such userspace interfaces are still exposed which
       probably won't do the right thing if the chip is powered down.
    
    2) This isn't done in the error paths in probe.
    
    To solve this problem, register a new callback adf4350_power_down()
    with devm_add_action_or_reset(), to enable software power down in both
    error and device detach path. So the remove function can be removed.
    
    Remove spi_set_drvdata() from the probe function, since spi_get_drvdata()
    is not used anymore.
    
    Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20230828062717.2310219-1-ruanjinjie@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
inet: shrink struct flowi_common [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Oct 25 14:10:37 2023 +0000

    inet: shrink struct flowi_common
    
    [ Upstream commit 1726483b79a72e0150734d5367e4a0238bf8fcff ]
    
    I am looking at syzbot reports triggering kernel stack overflows
    involving a cascade of ipvlan devices.
    
    We can save 8 bytes in struct flowi_common.
    
    This patch alone will not fix the issue, but is a start.
    
    Fixes: 24ba14406c5c ("route: Add multipath_hash in flowi_common to make user-define hash")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: wenxu <wenxu@ucloud.cn>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20231025141037.3448203-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sun Oct 29 02:53:36 2023 +0000

    Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
    
    [ Upstream commit eb988e46da2e4eae89f5337e047ce372fe33d5b1 ]
    
    The put_device() calls rmi_release_function() which frees "fn" so the
    dereference on the next line "fn->num_of_irqs" is a use after free.
    Move the put_device() to the end to fix this.
    
    Fixes: 24d28e4f1271 ("Input: synaptics-rmi4 - convert irq distribution to irq_domain")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/706efd36-7561-42f3-adfa-dd1d0bd4f5a1@moroto.mountain
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
interconnect: fix error handling in qnoc_probe() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Aug 3 21:05:21 2023 +0800

    interconnect: fix error handling in qnoc_probe()
    
    [ Upstream commit 273f74a2e7d15a5c216a4a26b84b1563c7092c9d ]
    
    Add missing clk_disable_unprepare() and clk_bulk_disable_unprepare()
    in the error path in qnoc_probe(). And when qcom_icc_qos_set() fails,
    it needs remove nodes and disable clks.
    
    Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20230803130521.959487-1-yangyingliang@huawei.com
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: qdu1000: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:44 2023 +0200

    interconnect: qcom: qdu1000: Set ACV enable_mask
    
    [ Upstream commit 8517824f0e94d52ab82742106314f0b8875e03c4 ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 1f51339f7dd0 ("interconnect: qcom: Add QDU1000/QRU1000 interconnect driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-1-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sc7180: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:22 2023 +0200

    interconnect: qcom: sc7180: Retire DEFINE_QBCM
    
    [ Upstream commit e451b2ea5a11fb3f6d83e1f834ae6a5f55a02bba ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-11-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: 1ad83c479272 ("interconnect: qcom: sc7180: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sc7180: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:45 2023 +0200

    interconnect: qcom: sc7180: Set ACV enable_mask
    
    [ Upstream commit 1ad83c4792722fe134c1352591420702ff7b9091 ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 2d1f95ab9feb ("interconnect: qcom: Add SC7180 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-2-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sc7280: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:46 2023 +0200

    interconnect: qcom: sc7280: Set ACV enable_mask
    
    [ Upstream commit 437b8e7fcd5df792cb8b8095e9f6eccefec6c099 ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 46bdcac533cc ("interconnect: qcom: Add SC7280 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-3-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sc8180x: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:47 2023 +0200

    interconnect: qcom: sc8180x: Set ACV enable_mask
    
    [ Upstream commit 0fcaaed3ff4b99e5b688b799f48989f1e4bb8a8b ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 9c8c6bac1ae8 ("interconnect: qcom: Add SC8180x providers")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-4-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sc8280xp: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:48 2023 +0200

    interconnect: qcom: sc8280xp: Set ACV enable_mask
    
    [ Upstream commit 688ffb3dcf85fc4b7ea82af842493013747a9e2c ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: f29dabda7917 ("interconnect: qcom: Add SC8280XP interconnect provider")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-5-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sdm670: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:23 2023 +0200

    interconnect: qcom: sdm670: Retire DEFINE_QBCM
    
    [ Upstream commit 46cd2018c52addf2031d8aea28f8208b9423af28 ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-12-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: 7b85ea8b9300 ("interconnect: qcom: sdm670: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sdm670: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:49 2023 +0200

    interconnect: qcom: sdm670: Set ACV enable_mask
    
    [ Upstream commit 7b85ea8b9300be5c2818e1f61a274ff2c4c063ee ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 7e438e18874e ("interconnect: qcom: add sdm670 interconnects")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-6-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sdm845: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:24 2023 +0200

    interconnect: qcom: sdm845: Retire DEFINE_QBCM
    
    [ Upstream commit 35f490c5e4e833e81be464d89404b26ee20740ef ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-13-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: f8fe97a9fd20 ("interconnect: qcom: sdm845: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sdm845: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:50 2023 +0200

    interconnect: qcom: sdm845: Set ACV enable_mask
    
    [ Upstream commit f8fe97a9fd2098de0570387029065eef657d50ee ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: b5d2f741077a ("interconnect: qcom: Add sdm845 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-7-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm6350: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:27 2023 +0200

    interconnect: qcom: sm6350: Retire DEFINE_QBCM
    
    [ Upstream commit ab2c1cb5740a7d2240b40b7b494700078db4eb13 ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-16-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: fe7a3abf4111 ("interconnect: qcom: sm6350: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm6350: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:51 2023 +0200

    interconnect: qcom: sm6350: Set ACV enable_mask
    
    [ Upstream commit fe7a3abf4111992af3de51d22383a8e8a0affe1e ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: 6a6eff73a954 ("interconnect: qcom: Add SM6350 driver support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-8-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm8150: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:28 2023 +0200

    interconnect: qcom: sm8150: Retire DEFINE_QBCM
    
    [ Upstream commit 670699a4225b8cba6962f965b227e0175d09ecda ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-17-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: 7ed42176406e ("interconnect: qcom: sm8150: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm8150: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:52 2023 +0200

    interconnect: qcom: sm8150: Set ACV enable_mask
    
    [ Upstream commit 7ed42176406e5a2c9a5767d0d75690c7d1588027 ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: a09b817c8bad ("interconnect: qcom: Add SM8150 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-9-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm8350: Retire DEFINE_QBCM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 14:15:30 2023 +0200

    interconnect: qcom: sm8350: Retire DEFINE_QBCM
    
    [ Upstream commit edd13c04ff0d90ed152902a88f01f466c77a0cf9 ]
    
    The struct definition macros are hard to read and compare, expand them.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/r/20230811-topic-icc_retire_macrosd-v1-19-c03aaeffc769@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: df1b8356a80a ("interconnect: qcom: sm8350: Set ACV enable_mask")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm8350: Set ACV enable_mask [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:20:54 2023 +0200

    interconnect: qcom: sm8350: Set ACV enable_mask
    
    [ Upstream commit df1b8356a80ab47a7623e08facf36fe434ea9722 ]
    
    ACV expects an enable_mask corresponding to the APPS RSC, fill it in.
    
    Fixes: d26a56674497 ("interconnect: qcom: Add SM8350 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-acv-v2-11-765ad70e539a@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/kbuf: Allow the full buffer id space for provided buffers [+ + +]
Author: Gabriel Krisman Bertazi <krisman@suse.de>
Date:   Wed Oct 4 20:05:30 2023 -0400

    io_uring/kbuf: Allow the full buffer id space for provided buffers
    
    [ Upstream commit f74c746e476b9dad51448b9a9421aae72b60e25f ]
    
    nbufs tracks the number of buffers and not the last bgid. In 16-bit, we
    have 2^16 valid buffers, but the check mistakenly rejects the last
    bid. Let's fix it to make the interface consistent with the
    documentation.
    
    Fixes: ddf0322db79c ("io_uring: add IORING_OP_PROVIDE_BUFFERS")
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Link: https://lore.kernel.org/r/20231005000531.30800-3-krisman@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring/kbuf: Fix check of BID wrapping in provided buffers [+ + +]
Author: Gabriel Krisman Bertazi <krisman@suse.de>
Date:   Wed Oct 4 20:05:29 2023 -0400

    io_uring/kbuf: Fix check of BID wrapping in provided buffers
    
    [ Upstream commit ab69838e7c75b0edb699c1a8f42752b30333c46f ]
    
    Commit 3851d25c75ed0 ("io_uring: check for rollover of buffer ID when
    providing buffers") introduced a check to prevent wrapping the BID
    counter when sqe->off is provided, but it's off-by-one too
    restrictive, rejecting the last possible BID (65534).
    
    i.e., the following fails with -EINVAL.
    
         io_uring_prep_provide_buffers(sqe, addr, size, 0xFFFF, 0, 0);
    
    Fixes: 3851d25c75ed ("io_uring: check for rollover of buffer ID when providing buffers")
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Link: https://lore.kernel.org/r/20231005000531.30800-2-krisman@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/net: ensure socket is marked connected on connect retry [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Nov 3 10:35:40 2023 -0600

    io_uring/net: ensure socket is marked connected on connect retry
    
    commit f8f9ab2d98116e79d220f1d089df7464ad4e026d upstream.
    
    io_uring does non-blocking connection attempts, which can yield some
    unexpected results if a connect request is re-attempted by an an
    application. This is equivalent to the following sync syscall sequence:
    
    sock = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP);
    connect(sock, &addr, sizeof(addr);
    
    ret == -1 and errno == EINPROGRESS expected here. Now poll for POLLOUT
    on sock, and when that returns, we expect the socket to be connected.
    But if we follow that procedure with:
    
    connect(sock, &addr, sizeof(addr));
    
    you'd expect ret == -1 and errno == EISCONN here, but you actually get
    ret == 0. If we attempt the connection one more time, then we get EISCON
    as expected.
    
    io_uring used to do this, but turns out that bluetooth fails with EBADFD
    if you attempt to re-connect. Also looks like EISCONN _could_ occur with
    this sequence.
    
    Retain the ->in_progress logic, but work-around a potential EISCONN or
    EBADFD error and only in those cases look at the sock_error(). This
    should work in general and avoid the odd sequence of a repeated connect
    request returning success when the socket is already connected.
    
    This is all a side effect of the socket state being in a CONNECTING
    state when we get EINPROGRESS, and only a re-connect or other related
    operation will turn that into CONNECTED.
    
    Cc: stable@vger.kernel.org
    Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT")
    Link: https://github.com/axboe/liburing/issues/980
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommufd: Add iopt_area_alloc() [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Oct 30 11:26:33 2023 -0300

    iommufd: Add iopt_area_alloc()
    
    [ Upstream commit 361d744ddd61de065fbeb042aaed590d32dd92ec ]
    
    We never initialize the two interval tree nodes, and zero fill is not the
    same as RB_CLEAR_NODE. This can hide issues where we missed adding the
    area to the trees. Factor out the allocation and clear the two nodes.
    
    Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping")
    Link: https://lore.kernel.org/r/20231030145035.GG691768@ziepe.ca
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iov_iter, x86: Be consistent about the __user tag on copy_mc_to_user() [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Mon Sep 25 13:02:59 2023 +0100

    iov_iter, x86: Be consistent about the __user tag on copy_mc_to_user()
    
    [ Upstream commit 066baf92bed934c9fb4bcee97a193f47aa63431c ]
    
    copy_mc_to_user() has the destination marked __user on powerpc, but not on
    x86; the latter results in a sparse warning in lib/iov_iter.c.
    
    Fix this by applying the tag on x86 too.
    
    Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20230925120309.1731676-3-dhowells@redhat.com
    cc: Dan Williams <dan.j.williams@intel.com>
    cc: Thomas Gleixner <tglx@linutronix.de>
    cc: Ingo Molnar <mingo@redhat.com>
    cc: Borislav Petkov <bp@alien8.de>
    cc: Dave Hansen <dave.hansen@linux.intel.com>
    cc: "H. Peter Anvin" <hpa@zytor.com>
    cc: Alexander Viro <viro@zeniv.linux.org.uk>
    cc: Jens Axboe <axboe@kernel.dk>
    cc: Christoph Hellwig <hch@lst.de>
    cc: Christian Brauner <christian@brauner.io>
    cc: Matthew Wilcox <willy@infradead.org>
    cc: Linus Torvalds <torvalds@linux-foundation.org>
    cc: David Laight <David.Laight@ACULAB.COM>
    cc: x86@kernel.org
    cc: linux-block@vger.kernel.org
    cc: linux-fsdevel@vger.kernel.org
    cc: linux-mm@kvack.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: avoid atomic fragment on GSO packets [+ + +]
Author: Yan Zhai <yan@cloudflare.com>
Date:   Tue Oct 24 07:26:40 2023 -0700

    ipv6: avoid atomic fragment on GSO packets
    
    [ Upstream commit 03d6c848bfb406e9ef6d9846d759e97beaeea113 ]
    
    When the ipv6 stack output a GSO packet, if its gso_size is larger than
    dst MTU, then all segments would be fragmented. However, it is possible
    for a GSO packet to have a trailing segment with smaller actual size
    than both gso_size as well as the MTU, which leads to an "atomic
    fragment". Atomic fragments are considered harmful in RFC-8021. An
    Existing report from APNIC also shows that atomic fragments are more
    likely to be dropped even it is equivalent to a no-op [1].
    
    Add an extra check in the GSO slow output path. For each segment from
    the original over-sized packet, if it fits with the path MTU, then avoid
    generating an atomic fragment.
    
    Link: https://www.potaroo.net/presentations/2022-03-01-ipv6-frag.pdf [1]
    Fixes: b210de4f8c97 ("net: ipv6: Validate GSO SKB before finish IPv6 processing")
    Reported-by: David Wragg <dwragg@cloudflare.com>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Link: https://lore.kernel.org/r/90912e3503a242dca0bc36958b11ed03a2696e5e.1698156966.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvlan: properly track tx_errors [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 26 13:14:46 2023 +0000

    ipvlan: properly track tx_errors
    
    [ Upstream commit ff672b9ffeb3f82135488ac16c5c5eb4b992999b ]
    
    Both ipvlan_process_v4_outbound() and ipvlan_process_v6_outbound()
    increment dev->stats.tx_errors in case of errors.
    
    Unfortunately there are two issues :
    
    1) ipvlan_get_stats64() does not propagate dev->stats.tx_errors to user.
    
    2) Increments are not atomic. KCSAN would complain eventually.
    
    Use DEV_STATS_INC() to not miss an update, and change ipvlan_get_stats64()
    to copy the value back to user.
    
    Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Mahesh Bandewar <maheshb@google.com>
    Link: https://lore.kernel.org/r/20231026131446.3933175-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/sifive-plic: Fix syscore registration for multi-socket systems [+ + +]
Author: Anup Patel <apatel@ventanamicro.com>
Date:   Wed Oct 25 19:58:20 2023 +0530

    irqchip/sifive-plic: Fix syscore registration for multi-socket systems
    
    [ Upstream commit f99b926f6543faeadba1b4524d8dc9c102489135 ]
    
    Multi-socket systems have a separate PLIC in each socket, so __plic_init()
    is invoked for each PLIC. __plic_init() registers syscore operations, which
    obviously fails on the second invocation.
    
    Move it into the already existing condition for installing the CPU hotplug
    state so it is only invoked once when the first PLIC is initialized.
    
    [ tglx: Massaged changelog ]
    
    Fixes: e80f0b6a2cf3 ("irqchip/irq-sifive-plic: Add syscore callbacks for hibernation")
    Signed-off-by: Anup Patel <apatel@ventanamicro.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20231025142820.390238-4-apatel@ventanamicro.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KEYS: Include linux/errno.h in linux/verification.h [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sat Aug 26 16:36:41 2023 +0800

    KEYS: Include linux/errno.h in linux/verification.h
    
    [ Upstream commit 0a596b0682a7ce37e26c36629816f105c6459d06 ]
    
    Add inclusion of linux/errno.h as otherwise the reference to EINVAL
    may be invalid.
    
    Fixes: f3cf4134c5c6 ("bpf: Add bpf_lookup_*_key() and bpf_key_put() kfuncs")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202308261414.HKw1Mrip-lkp@intel.com/
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kselftest: vm: fix mdwe's mmap_FIXED test case [+ + +]
Author: Florent Revest <revest@chromium.org>
Date:   Mon Aug 28 17:08:54 2023 +0200

    kselftest: vm: fix mdwe's mmap_FIXED test case
    
    [ Upstream commit a27e2e2d465e4ed73371974040689ac3e78fe3ee ]
    
    I checked with the original author, the mmap_FIXED test case wasn't
    properly tested and fails.  Currently, it maps two consecutive (non
    overlapping) pages and expects the second mapping to be denied by MDWE but
    these two pages have nothing to do with each other so MDWE is actually out
    of the picture here.
    
    What the test actually intended to do was to remap a virtual address using
    MAP_FIXED.  However, this operation unmaps the existing mapping and
    creates a new one so the va is backed by a new page and MDWE is again out
    of the picture, all remappings should succeed.
    
    This patch keeps the test case to make it clear that this situation is
    expected to work: MDWE shouldn't block a MAP_FIXED replacement.
    
    Link: https://lkml.kernel.org/r/20230828150858.393570-3-revest@chromium.org
    Fixes: 4cf1fe34fd18 ("kselftest: vm: add tests for memory-deny-write-execute")
    Signed-off-by: Florent Revest <revest@chromium.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
    Tested-by: Ryan Roberts <ryan.roberts@arm.com>
    Tested-by: Ayush Jain <ayush.jain3@amd.com>
    Cc: Alexey Izbyshev <izbyshev@ispras.ru>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Greg Thelen <gthelen@google.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
    Cc: Topi Miettinen <toiwoton@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kunit: Fix missed memory release in kunit_free_suite_set() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Sep 27 17:03:47 2023 +0800

    kunit: Fix missed memory release in kunit_free_suite_set()
    
    [ Upstream commit a6074cf0126b0bee51ab77a15930dc24a4d5db90 ]
    
    modprobe cpumask_kunit and rmmod cpumask_kunit, kmemleak detect
    a suspected memory leak as below.
    
    If kunit_filter_suites() in kunit_module_init() succeeds, the
    suite_set.start will not be NULL and the kunit_free_suite_set() in
    kunit_module_exit() should free all the memory which has not
    been freed. However the test_cases in suites is left out.
    
    unreferenced object 0xffff54ac47e83200 (size 512):
      comm "modprobe", pid 592, jiffies 4294913238 (age 1367.612s)
      hex dump (first 32 bytes):
        84 13 1a f0 d3 b6 ff ff 30 68 1a f0 d3 b6 ff ff  ........0h......
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000008dec63a2>] slab_post_alloc_hook+0xb8/0x368
        [<00000000ec280d8e>] __kmem_cache_alloc_node+0x174/0x290
        [<00000000896c7740>] __kmalloc+0x60/0x2c0
        [<000000007a50fa06>] kunit_filter_suites+0x254/0x5b8
        [<0000000078cc98e2>] kunit_module_notify+0xf4/0x240
        [<0000000033cea952>] notifier_call_chain+0x98/0x17c
        [<00000000973d05cc>] notifier_call_chain_robust+0x4c/0xa4
        [<000000005f95895f>] blocking_notifier_call_chain_robust+0x4c/0x74
        [<0000000048e36fa7>] load_module+0x1a2c/0x1c40
        [<0000000004eb8a91>] init_module_from_file+0x94/0xcc
        [<0000000037dbba28>] idempotent_init_module+0x184/0x278
        [<00000000161b75cb>] __arm64_sys_finit_module+0x68/0xa8
        [<000000006dc1669b>] invoke_syscall+0x44/0x100
        [<00000000fa87e304>] el0_svc_common.constprop.1+0x68/0xe0
        [<000000009d8ad866>] do_el0_svc+0x1c/0x28
        [<000000005b83c607>] el0_svc+0x3c/0xc4
    
    Fixes: a127b154a8f2 ("kunit: tool: allow filtering test cases via glob")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Rae Moar <rmoar@google.com>
    Reviewed-by: David Gow <davidgow@google.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
leds: pwm: Don't disable the PWM when the LED should be off [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Sep 22 21:28:34 2023 +0200

    leds: pwm: Don't disable the PWM when the LED should be off
    
    [ Upstream commit 76fe464c8e64e71b2e4af11edeef0e5d85eeb6aa ]
    
    Disabling a PWM (i.e. calling pwm_apply_state with .enabled = false)
    gives no guarantees what the PWM output does. It might freeze where it
    currently is, or go in a High-Z state or drive the active or inactive
    state, it might even continue to toggle.
    
    To ensure that the LED gets really disabled, don't disable the PWM even
    when .duty_cycle is zero.
    
    This fixes disabling a leds-pwm LED on i.MX28. The PWM on this SoC is
    one of those that freezes its output on disable, so if you disable an
    LED that is full on, it stays on. If you disable a LED with half
    brightness it goes off in 50% of the cases and full on in the other 50%.
    
    Fixes: 41c42ff5dbe2 ("leds: simple driver for pwm driven LEDs")
    Reported-by: Rogan Dawes <rogan@dawes.za.net>
    Reported-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Fabio Estevam <festevam@denx.de>
    Link: https://lore.kernel.org/r/20230922192834.1695727-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu' [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Sep 23 09:15:38 2023 +0200

    leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'
    
    [ Upstream commit ff50f53276131a3059e8307d11293af388ed2bcd ]
    
    In order to teach the compiler that 'trig->name' will never be truncated,
    we need to tell it that 'cpu' is not negative.
    
    When building with W=1, this fixes the following warnings:
    
      drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
      drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=]
        155 |                 snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
            |                                                        ^~
      drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7]
        155 |                 snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
            |                                                    ^~~~~~~
      drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8
        155 |                 snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
            |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fixes: 8f88731d052d ("led-triggers: create a trigger for CPU activity")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: turris-omnia: Do not use SMBUS calls [+ + +]
Author: Marek Behún <kabel@kernel.org>
Date:   Mon Sep 18 18:11:01 2023 +0200

    leds: turris-omnia: Do not use SMBUS calls
    
    [ Upstream commit 6de283b96b31b4890e3ee8c86caca2a3a30d1011 ]
    
    The leds-turris-omnia driver uses three function for I2C access:
    - i2c_smbus_write_byte_data() and i2c_smbus_read_byte_data(), which
      cause an emulated SMBUS transfer,
    - i2c_master_send(), which causes an ordinary I2C transfer.
    
    The Turris Omnia MCU LED controller is not semantically SMBUS, it
    operates as a simple I2C bus. It does not implement any of the SMBUS
    specific features, like PEC, or procedure calls, or anything. Moreover
    the I2C controller driver also does not implement SMBUS, and so the
    emulated SMBUS procedure from drivers/i2c/i2c-core-smbus.c is used for
    the SMBUS calls, which gives an unnecessary overhead.
    
    When I first wrote the driver, I was unaware of these facts, and I
    simply used the first function that worked.
    
    Drop the I2C SMBUS calls and instead use simple I2C transfers.
    
    Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Link: https://lore.kernel.org/r/20230918161104.20860-2-kabel@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: turris-omnia: Drop unnecessary mutex locking [+ + +]
Author: Marek Behún <kabel@kernel.org>
Date:   Wed Aug 2 18:07:43 2023 +0200

    leds: turris-omnia: Drop unnecessary mutex locking
    
    [ Upstream commit 760b6b7925bf09491aafa4727eef74fc6bf738b0 ]
    
    Do not lock driver mutex in the global LED panel brightness sysfs
    accessors brightness_show() and brightness_store().
    
    The mutex locking is unnecessary here. The I2C transfers are guarded by
    I2C core locking mechanism, and the LED commands itself do not interfere
    with other commands.
    
    Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Reviewed-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/20230802160748.11208-2-kabel@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Stable-dep-of: 6de283b96b31 ("leds: turris-omnia: Do not use SMBUS calls")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libnvdimm/of_pmem: Use devm_kstrdup instead of kstrdup and check its return value [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Thu Sep 14 07:03:27 2023 +0000

    libnvdimm/of_pmem: Use devm_kstrdup instead of kstrdup and check its return value
    
    [ Upstream commit 6fd4ebfc4d61e3097b595ab2725d513e3bbd6739 ]
    
    Use devm_kstrdup() instead of kstrdup() and check its return value to
    avoid memory leak.
    
    Fixes: 49bddc73d15c ("libnvdimm/of_pmem: Provide a unique name for bus provider")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libperf rc_check: Make implicit enabling work for GCC [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Oct 24 15:23:06 2023 -0700

    libperf rc_check: Make implicit enabling work for GCC
    
    [ Upstream commit 75265320d290c5f5891f16967b94883676c46705 ]
    
    Make the implicit REFCOUNT_CHECKING robust to when building with GCC.
    
    Fixes: 9be6ab181b7b ("libperf rc_check: Enable implicitly with sanitizers")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: liuwenyu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Yanteng Si <siyanteng@loongson.cn>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Link: https://lore.kernel.org/r/20231024222353.3024098-4-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.5.12 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Nov 20 11:57:26 2023 +0100

    Linux 6.5.12
    
    Link: https://lore.kernel.org/r/20231115191600.708733204@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
livepatch: Fix missing newline character in klp_resolve_symbols() [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Thu Sep 14 15:26:44 2023 +0800

    livepatch: Fix missing newline character in klp_resolve_symbols()
    
    [ Upstream commit 67e18e132f0fd738f8c8cac3aa1420312073f795 ]
    
    Without the newline character, the log may not be printed immediately
    after the error occurs.
    
    Fixes: ca376a937486 ("livepatch: Prevent module-specific KLP rela sections from referencing vmlinux symbols")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20230914072644.4098857-1-zhengyejian1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
llc: verify mac len before reading mac header [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Oct 25 19:42:38 2023 -0400

    llc: verify mac len before reading mac header
    
    [ Upstream commit 7b3ba18703a63f6fd487183b9262b08e5632da1b ]
    
    LLC reads the mac header with eth_hdr without verifying that the skb
    has an Ethernet header.
    
    Syzbot was able to enter llc_rcv on a tun device. Tun can insert
    packets without mac len and with user configurable skb->protocol
    (passing a tun_pi header when not configuring IFF_NO_PI).
    
        BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
        BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
        llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
        llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
        llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
        __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
        __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
        netif_receive_skb_internal net/core/dev.c:5723 [inline]
        netif_receive_skb+0x58/0x660 net/core/dev.c:5782
        tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
        tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
    
    Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
    
    There are further uses in include/net/llc_pdu.h. All these are
    protected by a test skb->protocol == ETH_P_802_2. Which does not
    protect against this tun scenario.
    
    But the mac_len test added in this patch in llc_fixup_skb will
    indirectly protect those too. That is called from llc_rcv before any
    other LLC code.
    
    It is tempting to just add a blanket mac_len check in llc_rcv, but
    not sure whether that could break valid LLC paths that do not assume
    an Ethernet header. 802.2 LLC may be used on top of non-802.3
    protocols in principle. The below referenced commit shows that used
    to, on top of Token Ring.
    
    At least one of the three eth_hdr uses goes back to before the start
    of git history. But the one that syzbot exercises is introduced in
    this commit. That commit is old enough (2008), that effectively all
    stable kernels should receive this.
    
    Fixes: f83f1768f833 ("[LLC]: skb allocation size for responses")
    Reported-by: syzbot+a8c7be6dee0de1b669cc@syzkaller.appspotmail.com
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20231025234251.3796495-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: amphion: handle firmware debug message [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Thu Sep 7 09:51:00 2023 +0800

    media: amphion: handle firmware debug message
    
    [ Upstream commit 6496617b2b06d7004a5cbd53d48f19567d6b018c ]
    
    decoder firmware may notify host some debug message,
    it can help analyze the state of the firmware in case of error
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: bttv: fix use after free error due to btv->timeout timer [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Thu Apr 13 11:49:42 2023 +0800

    media: bttv: fix use after free error due to btv->timeout timer
    
    [ Upstream commit bd5b50b329e850d467e7bcc07b2b6bde3752fbda ]
    
    There may be some a race condition between timer function
    bttv_irq_timeout and bttv_remove. The timer is setup in
    probe and there is no timer_delete operation in remove
    function. When it hit kfree btv, the function might still be
    invoked, which will cause use after free bug.
    
    This bug is found by static analysis, it may be false positive.
    
    Fix it by adding del_timer_sync invoking to the remove function.
    
    cpu0                cpu1
                      bttv_probe
                        ->timer_setup
                          ->bttv_set_dma
                            ->mod_timer;
    bttv_remove
      ->kfree(btv);
                      ->bttv_irq_timeout
                        ->USE btv
    
    Fixes: 162e6376ac58 ("media: pci: Convert timers to use timer_setup()")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cadence: csi2rx: Unregister v4l2 async notifier [+ + +]
Author: Pratyush Yadav <p.yadav@ti.com>
Date:   Mon Oct 9 18:39:29 2023 +0530

    media: cadence: csi2rx: Unregister v4l2 async notifier
    
    [ Upstream commit b2701715301a49b53d05c7d43f3fedc3b8743bfc ]
    
    The notifier is added to the global notifier list when registered. When
    the module is removed, the struct csi2rx_priv in which the notifier is
    embedded, is destroyed. As a result the notifier list has a reference to
    a notifier that no longer exists. This causes invalid memory accesses
    when the list is iterated over. Similar for when the probe fails.
    Unregister and clean up the notifier to avoid this.
    
    Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
    
    Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
    Tested-by: Julien Massot <julien.massot@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: meson: always include meson sub-directory in Makefile [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Oct 12 12:35:25 2023 +0200

    media: cec: meson: always include meson sub-directory in Makefile
    
    [ Upstream commit 94e27fbeca27d8c772fc2bc807730aaee5886055 ]
    
    'meson' directory contains two separate drivers, so it should be added
    to Makefile compilation hierarchy unconditionally, because otherwise the
    meson-ao-cec-g12a won't be compiled if meson-ao-cec is not selected.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Fixes: 4be5e8648b0c ("media: move CEC platform drivers to a separate directory")
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cedrus: Fix clock/reset sequence [+ + +]
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Mon Sep 11 20:46:12 2023 +0200

    media: cedrus: Fix clock/reset sequence
    
    [ Upstream commit 36fe515c1a3cd5eac148e8a591a82108d92d5522 ]
    
    According to H6 user manual, resets should always be de-asserted before
    clocks are enabled. This is also consistent with vendor driver.
    
    Fixes: d5aecd289bab ("media: cedrus: Implement runtime PM")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-usb-v2: af9035: fix missing unlock [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Oct 6 12:08:45 2023 +0200

    media: dvb-usb-v2: af9035: fix missing unlock
    
    [ Upstream commit f31b2cb85f0ee165d78e1c43f6d69f82cc3b2145 ]
    
    Instead of returning an error, goto the mutex unlock at
    the end of the function.
    
    Fixes smatch warning:
    
    drivers/media/usb/dvb-usb-v2/af9035.c:467 af9035_i2c_master_xfer() warn: inconsistent returns '&d->i2c_mutex'.
      Locked on  : 326,387
      Unlocked on: 465,467
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 7bf744f2de0a ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer")
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: hantro: Check whether reset op is defined before use [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Aug 24 03:38:58 2023 +0200

    media: hantro: Check whether reset op is defined before use
    
    [ Upstream commit 88d4b23a629ebd34f682f770cb6c2116c851f7b8 ]
    
    The i.MX8MM/N/P does not define the .reset op since reset of the VPU is
    done by genpd. Check whether the .reset op is defined before calling it
    to avoid NULL pointer dereference.
    
    Note that the Fixes tag is set to the commit which removed the reset op
    from i.MX8M Hantro G2 implementation, this is because before this commit
    all the implementations did define the .reset op.
    
    Fixes: 6971efb70ac3 ("media: hantro: Allow i.MX8MQ G1 and G2 to run independently")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: max9286: Fix some redundant of_node_put() calls [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 26 00:13:40 2023 +0200

    media: i2c: max9286: Fix some redundant of_node_put() calls
    
    [ Upstream commit 0822315e46b400f611cba1193456ee6a5dc3e41d ]
    
    This is odd to have a of_node_put() just after a for_each_child_of_node()
    or a for_each_endpoint_of_node() loop. It should already be called
    during the last iteration.
    
    Remove these calls.
    
    Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: initiate a drain of the capture queue in dynamic resolution change [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Aug 22 09:45:06 2023 +0800

    media: imx-jpeg: initiate a drain of the capture queue in dynamic resolution change
    
    [ Upstream commit 1c2786632e20c8f0fd4004fae3b3490276e5e5da ]
    
    The last buffer from before the change must be marked,
    with the V4L2_BUF_FLAG_LAST flag,
    similarly to the Drain sequence above.
    
    Meanwhile if V4L2_DEC_CMD_STOP is sent before
    the source change triggered,
    we need to restore the is_draing flag after
    the draining in dynamic resolution change.
    
    Fixes: b4e1fb8643da ("media: imx-jpeg: Support dynamic resolution change")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: notify source chagne event when the first picture parsed [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon Oct 9 14:16:57 2023 +0800

    media: imx-jpeg: notify source chagne event when the first picture parsed
    
    [ Upstream commit b833b178498dafa2156cfb6f4d3ce4581c21f1e5 ]
    
    After gstreamer rework the dynamic resolution change handling, gstreamer
    stop doing capture buffer allocation based on guesses and wait for the
    source change event when available. It requires driver always notify
    source change event in the initialization, even if the size parsed is
    equal to the size set on capture queue. otherwise, the pipeline will be
    stalled.
    
    Currently driver may not notify source change event if the parsed format
    and size are equal to those previously established, but it may stall the
    gstreamer pipeline.
    
    The link of gstreamer patch is
    https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4437
    
    Fixes: b4e1fb8643da ("media: imx-jpeg: Support dynamic resolution change")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mtk-jpegenc: Fix bug in JPEG encode quality selection [+ + +]
Author: Fei Shao <fshao@chromium.org>
Date:   Fri Sep 8 21:28:04 2023 +0800

    media: mtk-jpegenc: Fix bug in JPEG encode quality selection
    
    [ Upstream commit 0aeccc63f3bc4cfd49dc4893da1409402ee6b295 ]
    
    The driver uses the upper-bound approach to decide the target JPEG
    encode quality, but there's a logic bug that if the desired quality is
    higher than what the driver can support, the driver falls back to using
    the worst quality.
    
    Fix the bug by assuming using the best quality in the beginning, and
    with trivial refactor to avoid long lines.
    
    Fixes: 45f13a57d813 ("media: platform: Add jpeg enc feature")
    Signed-off-by: Fei Shao <fshao@chromium.org>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov5640: Fix a memory leak when ov5640_probe fails [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Mon Aug 7 17:05:35 2023 +0800

    media: ov5640: Fix a memory leak when ov5640_probe fails
    
    [ Upstream commit 20290feaaeb76cc719921aad275ccb18662a7c3a ]
    
    sensor->ctrls.handler is initialized in ov5640_init_controls(),
    so when the sensor is not connected and ov5640_sensor_resume()
    fails, sensor->ctrls.handler should be released, otherwise a
    memory leak will be detected:
    
    unreferenced object 0xc674ca80 (size 64):
       comm "swapper/0", pid 1, jiffies 4294938337 (age 204.880s)
       hex dump (first 32 bytes):
         80 55 75 c6 80 54 75 c6 00 55 75 c6 80 52 75 c6 .Uu..Tu..Uu..Ru.
         00 53 75 c6 00 00 00 00 00 00 00 00 00 00 00 00 .Su..........
    
    Fixes: 85644a9b37ec ("media: ov5640: Use runtime PM")
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov5640: fix vblank unchange issue when work at dvp mode [+ + +]
Author: Guoniu.zhou <guoniu.zhou@nxp.com>
Date:   Wed Jul 19 15:30:12 2023 +0800

    media: ov5640: fix vblank unchange issue when work at dvp mode
    
    [ Upstream commit 8fc29e3c9f682d4ad9b0764d44ecc6c19b000051 ]
    
    The value of V4L2_CID_VBLANK control is initialized to default vblank
    value of 640x480 when driver probe. When OV5640 work at DVP mode, the
    control value won't update and lead to sensor can't output data if the
    resolution remain the same as last time since incorrect total vertical
    size. So update it when there is a new value applied.
    
    Fixes: bce93b827de6 ("media: ov5640: Add VBLANK control")
    Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: platform: mtk-mdp3: fix uninitialized variable in mdp_path_config() [+ + +]
Author: Moudy Ho <moudy.ho@mediatek.com>
Date:   Wed Oct 11 11:00:37 2023 +0800

    media: platform: mtk-mdp3: fix uninitialized variable in mdp_path_config()
    
    [ Upstream commit 2a76e7679b594ea3e1b3b7fb6c3d67158114020d ]
    
    Fix the build warnings that were detected by the linux-media
    build scripts tool:
    
    drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c:
            In function 'mdp_path_config.isra':
    drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c:
            warning: 'ctx' may be used uninitialized [-Wmaybe-uninitialized]
          |                    out = CFG_COMP(MT8195, ctx->param, outputs[0]);
          |                                           ~~~^~~~~~~
    drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h: note:
            in definition of macro 'CFG_COMP'
          |         (IS_ERR_OR_NULL(comp) ? 0 : _CFG_COMP(plat, comp, mem))
          |                         ^~~~
    drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c:
            note: 'ctx' was declared here
          |         struct mdp_comp_ctx *ctx;
          |
    
    Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver")
    Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s3c-camif: Avoid inappropriate kfree() [+ + +]
Author: Katya Orlova <e.orlova@ispras.ru>
Date:   Fri Sep 22 14:55:06 2023 +0300

    media: s3c-camif: Avoid inappropriate kfree()
    
    [ Upstream commit 61334819aca018c3416ee6c330a08a49c1524fc3 ]
    
    s3c_camif_register_video_node() works with video_device structure stored
    as a field of camif_vp, so it should not be kfreed.
    But there is video_device_release() on error path that do it.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")
    Signed-off-by: Katya Orlova <e.orlova@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: verisilicon: Do not enable G2 postproc downscale if source is narrower than destination [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Aug 24 03:39:35 2023 +0200

    media: verisilicon: Do not enable G2 postproc downscale if source is narrower than destination
    
    [ Upstream commit 6e481d52d363218a3e6feb31694da74b38b30fad ]
    
    In case of encoded input VP9 data width that is not multiple of macroblock
    size, which is 16 (e.g. 1080x1920 frames, where 1080 is multiple of 8), the
    width is padded to be a multiple of macroblock size (for 1080x1920 frames,
    that is 1088x1920).
    
    The hantro_postproc_g2_enable() checks whether the encoded data width is
    equal to decoded frame width, and if not, enables down-scale mode. For a
    frame where input is 1080x1920 and output is 1088x1920, this is incorrect
    as no down-scale happens, the frame is only padded. Enabling the down-scale
    mode in this case results in corrupted frames.
    
    Fix this by adjusting the check to test whether encoded data width is
    greater than decoded frame width, and only in that case enable the
    down-scale mode.
    
    To generate input test data to trigger this bug, use e.g.:
    $ gst-launch-1.0 videotestsrc ! video/x-raw,width=272,height=256,format=I420 ! \
                     vp9enc ! matroskamux ! filesink location=/tmp/test.vp9
    To trigger the bug upon decoding (note that the NV12 must be forced, as
    that assures the output data would pass the G2 postproc):
    $ gst-launch-1.0 filesrc location=/tmp/test.vp9 ! matroskademux ! vp9parse ! \
                     v4l2slvp9dec ! video/x-raw,format=NV12 ! videoconvert ! fbdevsink
    
    Fixes: 79c987de8b35 ("media: hantro: Use post processor scaling capacities")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: verisilicon: Fixes clock list for rk3588 av1 decoder [+ + +]
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date:   Thu Oct 5 16:51:16 2023 +0200

    media: verisilicon: Fixes clock list for rk3588 av1 decoder
    
    [ Upstream commit 39377f84fb98561b86b645f0b7c33512eba7afaf ]
    
    Mainlined RK3588 clock driver manage by itself the dependency between
    aclk/hclk and their root clocks (aclk_vdpu_root/hclk_vdpu_root).
    RK3588 av1 video decoder do not have to take care of it anymore so
    remove them from the list and be compliant with yaml bindings description.
    
    Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588")
    Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: vidtv: mux: Add check and kfree for kstrdup [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Mon Jun 19 16:12:02 2023 +0800

    media: vidtv: mux: Add check and kfree for kstrdup
    
    [ Upstream commit 1fd6eb12642e0c32692924ff359c07de4b781d78 ]
    
    Add check for the return value of kstrdup() and return the error
    if it fails in order to avoid NULL pointer dereference.
    Moreover, use kfree() in the later error handling in order to avoid
    memory leak.
    
    Fixes: c2f78f0cb294 ("media: vidtv: psi: add a Network Information Table (NIT)")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: vidtv: psi: Add check for kstrdup [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Mon Jun 19 16:12:01 2023 +0800

    media: vidtv: psi: Add check for kstrdup
    
    [ Upstream commit 76a2c5df6ca8bd8ada45e953b8c72b746f42918d ]
    
    Add check for the return value of kstrdup() and return the error
    if it fails in order to avoid NULL pointer dereference.
    
    Fixes: 7a7899f6f58e ("media: vidtv: psi: Implement an Event Information Table (EIT)")
    Fixes: c2f78f0cb294 ("media: vidtv: psi: add a Network Information Table (NIT)")
    Fixes: f90cf6079bf6 ("media: vidtv: add a bridge driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memory: tegra: Set BPMP msg flags to reset IPC channels [+ + +]
Author: Thierry Reding <treding@nvidia.com>
Date:   Mon Oct 9 15:35:57 2023 +0530

    memory: tegra: Set BPMP msg flags to reset IPC channels
    
    [ Upstream commit f344675a34383ae26a8230f4b1cd99cbd0defebd ]
    
    Set the 'TEGRA_BPMP_MESSAGE_RESET' bit in newly added 'flags' field
    of 'struct tegra_bpmp_message' to request for the reset of BPMP IPC
    channels. This is used along with the 'suspended' check in BPMP driver
    for handling early bandwidth requests due to the hotplug of CPU's
    during system resume before the driver gets resumed.
    
    Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth")
    Co-developed-by: Sumit Gupta <sumitg@nvidia.com>
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mfd: arizona-spi: Set pdata.hpdet_channel for ACPI enumerated devs [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Oct 14 22:54:14 2023 +0200

    mfd: arizona-spi: Set pdata.hpdet_channel for ACPI enumerated devs
    
    [ Upstream commit 831d1af85133e1763d41e20414912d9a1058ea72 ]
    
    Commit 9e86b2ad4c11 changed the channel used for HPDET detection
    (headphones vs lineout detection) from being hardcoded to
    ARIZONA_ACCDET_MODE_HPL (HP left channel) to it being configurable
    through arizona_pdata.hpdet_channel the DT/OF parsing added for
    filling arizona_pdata on devicetree platforms ensures that
    arizona_pdata.hpdet_channel gets set to ARIZONA_ACCDET_MODE_HPL
    when not specified in the devicetree-node.
    
    But on ACPI platforms where arizona_pdata is filled by
    arizona_spi_acpi_probe() arizona_pdata.hpdet_channel was not
    getting set, causing it to default to 0 aka ARIZONA_ACCDET_MODE_MIC.
    
    This causes headphones to get misdetected as line-out on some models.
    Fix this by setting hpdet_channel = ARIZONA_ACCDET_MODE_HPL.
    
    Fixes: e933836744a2 ("mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231014205414.59415-1-hdegoede@redhat.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mfd: core: Ensure disabled devices are skipped without aborting [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Fri Aug 18 18:39:17 2023 +0200

    mfd: core: Ensure disabled devices are skipped without aborting
    
    [ Upstream commit 7ba7bdef4d14e3722e2842da3b48cbadb73e52d6 ]
    
    The loop searching for a matching device based on its compatible
    string is aborted when a matching disabled device is found.
    This abort prevents to add devices as soon as one disabled device
    is found.
    
    Continue searching for an other device instead of aborting on the
    first disabled one fixes the issue.
    
    Fixes: 22380b65dc70 ("mfd: mfd-core: Ensure disabled devices are ignored without error")
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Link: https://lore.kernel.org/r/528425d6472176bb1d02d79596b51f8c28a551cc.1692376361.git.christophe.leroy@csgroup.eu
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mfd: core: Un-constify mfd_cell.of_reg [+ + +]
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Mon Aug 28 22:16:11 2023 +0200

    mfd: core: Un-constify mfd_cell.of_reg
    
    [ Upstream commit 3c70342f1f0045dc827bb2f02d814ce31e0e0d05 ]
    
    Enable dynamically filling in the whole mfd_cell structure. All other
    fields already allow that.
    
    Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/b73fe4bc4bd6ba1af90940a640ed65fe254c0408.1693253717.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mfd: dln2: Fix double put in dln2_probe [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Sep 25 10:41:33 2023 +0800

    mfd: dln2: Fix double put in dln2_probe
    
    [ Upstream commit 759c409bc5fc496cbc22cd0b392d3cbb0c0e23eb ]
    
    The dln2_free() already contains usb_put_dev(). Therefore,
    the redundant usb_put_dev() before dln2_free() may lead to
    a double free.
    
    Fixes: 96da8f148396 ("mfd: dln2: Fix memory leak in dln2_probe()")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230925024134.9683-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: st_core: Do not call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Aug 23 11:50:20 2023 +0800

    misc: st_core: Do not call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 4d08c3d12b61022501989f9f071514d2d6f77c47 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with hardware interrupts being disabled.
    So replace kfree_skb() with dev_kfree_skb_irq() under
    spin_lock_irqsave(). Compile tested only.
    
    Fixes: 53618cc1e51e ("Staging: sources for ST core")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20230823035020.1281892-1-ruanjinjie@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mlxsw: Use size_mul() in call to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 13:01:23 2023 -0600

    mlxsw: Use size_mul() in call to struct_size()
    
    [ Upstream commit e22c6ea025013ae447fe269269753ffec763dde5 ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound, the
    protection that `struct_size()` adds against potential integer overflows
    is defeated. Fix this by hardening call to `struct_size()` with `size_mul()`.
    
    Fixes: 2285ec872d9d ("mlxsw: spectrum_acl_bloom_filter: use struct_size() in kzalloc()")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Oct 8 02:04:45 2023 +0900

    modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host
    
    [ Upstream commit ac96a15a0f0c8812a3aaa587b871cd5527f6d736 ]
    
    When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different
    endianness from the target architecture, it results in an incorrect
    MODULE_ALIAS().
    
    For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c
    is built as a module for x86.
    
    If you build it on a little-endian host, you will get the correct
    MODULE_ALIAS:
    
        $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c
        MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}");
    
    However, if you build it on a big-endian host, you will get a wrong
    MODULE_ALIAS:
    
        $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c
        MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}");
    
    This issue has been unnoticed because the x86 kernel is most likely built
    natively on an x86 host.
    
    The guid field must not be reversed because guid_t is an array of __u8.
    
    Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
    Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

modpost: fix tee MODULE_DEVICE_TABLE built on big-endian host [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Oct 8 02:04:44 2023 +0900

    modpost: fix tee MODULE_DEVICE_TABLE built on big-endian host
    
    [ Upstream commit 7f54e00e5842663c2cea501bbbdfa572c94348a3 ]
    
    When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different
    endianness from the target architecture, it results in an incorrect
    MODULE_ALIAS().
    
    For example, see a case where drivers/char/hw_random/optee-rng.c
    is built as a module for ARM little-endian.
    
    If you build it on a little-endian host, you will get the correct
    MODULE_ALIAS:
    
        $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
        MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*");
    
    However, if you build it on a big-endian host, you will get a wrong
    MODULE_ALIAS:
    
        $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c
        MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*");
    
    The same problem also occurs when you enable CONFIG_CPU_BIG_ENDIAN,
    and build it on a little-endian host.
    
    This issue has been unnoticed because the ARM kernel is configured for
    little-endian by default, and most likely built on a little-endian host
    (cross-build on x86 or native-build on ARM).
    
    The uuid field must not be reversed because uuid_t is an array of __u8.
    
    Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
module/decompress: use kvmalloc() consistently [+ + +]
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Thu Nov 2 09:19:14 2023 +0100

    module/decompress: use kvmalloc() consistently
    
    [ Upstream commit 17fc8084aa8f9d5235f252fc3978db657dd77e92 ]
    
    We consistently switched from kmalloc() to vmalloc() in module
    decompression to prevent potential memory allocation failures with large
    modules, however vmalloc() is not as memory-efficient and fast as
    kmalloc().
    
    Since we don't know in general the size of the workspace required by the
    decompression algorithm, it is more reasonable to use kvmalloc()
    consistently, also considering that we don't have special memory
    requirements here.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Tested-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

module/decompress: use vmalloc() for gzip decompression workspace [+ + +]
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Wed Aug 30 17:58:20 2023 +0200

    module/decompress: use vmalloc() for gzip decompression workspace
    
    [ Upstream commit 3737df782c740b944912ed93420c57344b1cf864 ]
    
    Use a similar approach as commit a419beac4a07 ("module/decompress: use
    vmalloc() for zstd decompression workspace") and replace kmalloc() with
    vmalloc() also for the gzip module decompression workspace.
    
    In this case the workspace is represented by struct inflate_workspace
    that can be fairly large for kmalloc() and it can potentially lead to
    allocation errors on certain systems:
    
    $ pahole inflate_workspace
    struct inflate_workspace {
            struct inflate_state       inflate_state;        /*     0  9544 */
            /* --- cacheline 149 boundary (9536 bytes) was 8 bytes ago --- */
            unsigned char              working_window[32768]; /*  9544 32768 */
    
            /* size: 42312, cachelines: 662, members: 2 */
            /* last cacheline: 8 bytes */
    };
    
    Considering that there is no need to use continuous physical memory,
    simply switch to vmalloc() to provide a more reliable in-kernel module
    decompression.
    
    Fixes: b1ae6dc41eaa ("module: add in-kernel support for decompressing")
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: properly account fastopen data [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Oct 23 13:44:35 2023 -0700

    mptcp: properly account fastopen data
    
    [ Upstream commit bf0e96108fb6707613dd055aff5e98b02b99bb14 ]
    
    Currently the socket level counter aggregating the received data
    does not take in account the data received via fastopen.
    
    Address the issue updating the counter as required.
    
    Fixes: 38967f424b5b ("mptcp: track some aggregate data counters")
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231023-send-net-next-20231023-2-v1-2-9dc60939d371@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nbd: fix uaf in nbd_open [+ + +]
Author: Li Lingfeng <lilingfeng3@huawei.com>
Date:   Tue Nov 7 18:34:35 2023 +0800

    nbd: fix uaf in nbd_open
    
    [ Upstream commit 327462725b0f759f093788dfbcb2f1fd132f956b ]
    
    Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
    blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
    disk->private_data as NULL as before. UAF may be triggered in nbd_open()
    if someone tries to open nbd device right after nbd_put() since nbd has
    been free in nbd_dev_remove().
    
    Fix this by implementing ->free_disk and free private data in it.
    
    Fixes: 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk")
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20231107103435.2074904-1-lilingfeng@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nd_btt: Make BTT lanes preemptible [+ + +]
Author: Tomas Glozar <tglozar@redhat.com>
Date:   Wed Sep 20 07:37:12 2023 +0200

    nd_btt: Make BTT lanes preemptible
    
    [ Upstream commit 36c75ce3bd299878fd9b238e9803d3817ddafbf3 ]
    
    nd_region_acquire_lane uses get_cpu, which disables preemption. This is
    an issue on PREEMPT_RT kernels, since btt_write_pg and also
    nd_region_acquire_lane itself take a spin lock, resulting in BUG:
    sleeping function called from invalid context.
    
    Fix the issue by replacing get_cpu with smp_process_id and
    migrate_disable when needed. This makes BTT operations preemptible, thus
    permitting the use of spin_lock.
    
    BUG example occurring when running ndctl tests on PREEMPT_RT kernel:
    
    BUG: sleeping function called from invalid context at
    kernel/locking/spinlock_rt.c:48
    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 4903, name:
    libndctl
    preempt_count: 1, expected: 0
    RCU nest depth: 0, expected: 0
    Preemption disabled at:
    [<ffffffffc1313db5>] nd_region_acquire_lane+0x15/0x90 [libnvdimm]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x8e/0xb0
     __might_resched+0x19b/0x250
     rt_spin_lock+0x4c/0x100
     ? btt_write_pg+0x2d7/0x500 [nd_btt]
     btt_write_pg+0x2d7/0x500 [nd_btt]
     ? local_clock_noinstr+0x9/0xc0
     btt_submit_bio+0x16d/0x270 [nd_btt]
     __submit_bio+0x48/0x80
     __submit_bio_noacct+0x7e/0x1e0
     submit_bio_wait+0x58/0xb0
     __blkdev_direct_IO_simple+0x107/0x240
     ? inode_set_ctime_current+0x51/0x110
     ? __pfx_submit_bio_wait_endio+0x10/0x10
     blkdev_write_iter+0x1d8/0x290
     vfs_write+0x237/0x330
     ...
     </TASK>
    
    Fixes: 5212e11fde4d ("nd_btt: atomic sector updates")
    Signed-off-by: Tomas Glozar <tglozar@redhat.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_ct: Always fill offloading tuple iifidx [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Fri Nov 3 16:14:10 2023 +0100

    net/sched: act_ct: Always fill offloading tuple iifidx
    
    [ Upstream commit 9bc64bd0cd765f696fcd40fc98909b1f7c73b2ba ]
    
    Referenced commit doesn't always set iifidx when offloading the flow to
    hardware. Fix the following cases:
    
    - nf_conn_act_ct_ext_fill() is called before extension is created with
    nf_conn_act_ct_ext_add() in tcf_ct_act(). This can cause rule offload with
    unspecified iifidx when connection is offloaded after only single
    original-direction packet has been processed by tc data path. Always fill
    the new nf_conn_act_ct_ext instance after creating it in
    nf_conn_act_ct_ext_add().
    
    - Offloading of unidirectional UDP NEW connections is now supported, but ct
    flow iifidx field is not updated when connection is promoted to
    bidirectional which can result reply-direction iifidx to be zero when
    refreshing the connection. Fill in the extension and update flow iifidx
    before calling flow_offload_refresh().
    
    Fixes: 9795ded7f924 ("net/sched: act_ct: Fill offloading tuple iifidx")
    Reviewed-by: Paul Blakey <paulb@nvidia.com>
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Fixes: 6a9bad0069cf ("net/sched: act_ct: offload UDP NEW connections")
    Link: https://lore.kernel.org/r/20231103151410.764271-1-vladbu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Fri Nov 3 14:07:39 2023 +0800

    net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc
    
    [ Upstream commit c5bf605ba4f9d6fbbb120595ab95002f4716edcb ]
    
    This patch re-fix the issues mentioned by commit 22a825c541d7
    ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()").
    
    Blocking sending message do solve the issues though, but it also
    prevents the peer to receive the final message. Besides, in logic,
    whether the sndbuf_desc is NULL or not have no impact on the processing
    of cdc message sending.
    
    Hence that, this patch allows the cdc message sending but to check the
    sndbuf_desc with care in smc_cdc_tx_handler().
    
    Fixes: 22a825c541d7 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Fri Nov 3 14:07:38 2023 +0800

    net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT
    
    [ Upstream commit 5211c9729484c923f8d2e06bd29f9322cc42bb8f ]
    
    Considering scenario:
    
                                    smc_cdc_rx_handler
    __smc_release
                                    sock_set_flag
    smc_close_active()
    sock_set_flag
    
    __set_bit(DEAD)                 __set_bit(DONE)
    
    Dues to __set_bit is not atomic, the DEAD or DONE might be lost.
    if the DEAD flag lost, the state SMC_CLOSED  will be never be reached
    in smc_close_passive_work:
    
    if (sock_flag(sk, SOCK_DEAD) &&
            smc_close_sent_any_close(conn)) {
            sk->sk_state = SMC_CLOSED;
    } else {
            /* just shutdown, but not yet closed locally */
            sk->sk_state = SMC_APPFINCLOSEWAIT;
    }
    
    Replace sock_set_flags or __set_bit to set_bit will fix this problem.
    Since set_bit is atomic.
    
    Fixes: b38d732477e4 ("smc: socket closing and linkgroup cleanup")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/smc: put sk reference if close work was canceled [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Fri Nov 3 14:07:40 2023 +0800

    net/smc: put sk reference if close work was canceled
    
    [ Upstream commit aa96fbd6d78d9770323b21e2c92bd38821be8852 ]
    
    Note that we always hold a reference to sock when attempting
    to submit close_work. Therefore, if we have successfully
    canceled close_work from pending, we MUST release that reference
    to avoid potential leaks.
    
    Fixes: 42bfba9eaa33 ("net/smc: immediate termination for SMCD link groups")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: add DEV_STATS_READ() helper [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Sep 21 08:52:16 2023 +0000

    net: add DEV_STATS_READ() helper
    
    [ Upstream commit 0b068c714ca9479d2783cc333fff5bc2d4a6d45c ]
    
    Companion of DEV_STATS_INC() & DEV_STATS_ADD().
    
    This is going to be used in the series.
    
    Use it in macsec_get_stats64().
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: ff672b9ffeb3 ("ipvlan: properly track tx_errors")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: enetc: shorten enetc_setup_xdp_prog() error message to fit NETLINK_MAX_FMTMSG_LEN [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon Nov 6 18:03:11 2023 +0200

    net: enetc: shorten enetc_setup_xdp_prog() error message to fit NETLINK_MAX_FMTMSG_LEN
    
    [ Upstream commit f968c56417f00be4cb62eadeed042a1e3c80dc53 ]
    
    NETLINK_MAX_FMTMSG_LEN is currently hardcoded to 80, and we provide an
    error printf-formatted string having 96 characters including the
    terminating \0. Assuming each %d (representing a queue) gets replaced by
    a number having at most 2 digits (a reasonable assumption), the final
    string is also 96 characters wide, which is too much.
    
    Reduce the verbiage a bit by removing some (partially) redundant words,
    which makes the new printf-formatted string be 73 characters wide with
    the trailing newline.
    
    Fixes: 800db2d125c2 ("net: enetc: ensure we always have a minimum number of TXQs for stack")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/lkml/202311061336.4dsWMT1h-lkp@intel.com/
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Link: https://lore.kernel.org/r/20231106160311.616118-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk_wed: fix EXT_INT_STATUS_RX_FBUF definitions for MT7986 SoC [+ + +]
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Sep 18 12:29:11 2023 +0200

    net: ethernet: mtk_wed: fix EXT_INT_STATUS_RX_FBUF definitions for MT7986 SoC
    
    [ Upstream commit c80471ba74b7f332ac19b985ccb76d852d507acf ]
    
    Fix MTK_WED_EXT_INT_STATUS_RX_FBUF_LO_TH and
    MTK_WED_EXT_INT_STATUS_RX_FBUF_HI_TH definitions for MT7986 (MT7986 is
    the only SoC to use them).
    
    Fixes: de84a090d99a ("net: ethernet: mtk_eth_wed: add wed support for mt7986 chipset")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: page_pool: add missing free_percpu when page_pool_init fail [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Mon Oct 30 17:12:56 2023 +0800

    net: page_pool: add missing free_percpu when page_pool_init fail
    
    [ Upstream commit 8ffbd1669ed1d58939d6e878dffaa2f60bf961a4 ]
    
    When ptr_ring_init() returns failure in page_pool_init(), free_percpu()
    is not called to free pool->recycle_stats, which may cause memory
    leak.
    
    Fixes: ad6fa1e1ab1b ("page_pool: Add recycle stats")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
    Link: https://lore.kernel.org/r/20231030091256.2915394-1-shaojijie@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: r8169: Disable multicast filter for RTL8168H and RTL8107E [+ + +]
Author: Patrick Thompson <ptf@google.com>
Date:   Mon Oct 30 16:50:14 2023 -0400

    net: r8169: Disable multicast filter for RTL8168H and RTL8107E
    
    [ Upstream commit efa5f1311c4998e9e6317c52bc5ee93b3a0f36df ]
    
    RTL8168H and RTL8107E ethernet adapters erroneously filter unicast
    eapol packets unless allmulti is enabled. These devices correspond to
    RTL_GIGA_MAC_VER_46 and VER_48. Add an exception for VER_46 and VER_48
    in the same way that VER_35 has an exception.
    
    Fixes: 6e1d0b898818 ("r8169:add support for RTL8168H and RTL8107E")
    Signed-off-by: Patrick Thompson <ptf@google.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/20231030205031.177855-1-ptf@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: skb_find_text: Ignore patterns extending past 'to' [+ + +]
Author: Phil Sutter <phil@nwl.cc>
Date:   Tue Oct 17 11:39:06 2023 +0200

    net: skb_find_text: Ignore patterns extending past 'to'
    
    [ Upstream commit c4eee56e14fe001e1cff54f0b438a5e2d0dd7454 ]
    
    Assume that caller's 'to' offset really represents an upper boundary for
    the pattern search, so patterns extending past this offset are to be
    rejected.
    
    The old behaviour also was kind of inconsistent when it comes to
    fragmentation (or otherwise non-linear skbs): If the pattern started in
    between 'to' and 'from' offsets but extended to the next fragment, it
    was not found if 'to' offset was still within the current fragment.
    
    Test the new behaviour in a kselftest using iptables' string match.
    
    Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Fixes: f72b948dcbb8 ("[NET]: skb_find_text ignores to argument")
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: spider_net: Use size_add() in call to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 13:25:36 2023 -0600

    net: spider_net: Use size_add() in call to struct_size()
    
    [ Upstream commit 0201409079b975e46cc40e8bdff4bd61329ee10f ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound,
    the protection that `struct_size()` adds against potential integer
    overflows is defeated. Fix this by hardening call to `struct_size()`
    with `size_add()`.
    
    Fixes: 3f1071ec39f7 ("net: spider_net: Use struct_size() helper")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Geoff Levand <geoff@infradead.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: xgmac: Enable support for multiple Flexible PPS outputs [+ + +]
Author: Furong Xu <0x1207@gmail.com>
Date:   Tue Oct 31 10:27:29 2023 +0800

    net: stmmac: xgmac: Enable support for multiple Flexible PPS outputs
    
    [ Upstream commit db456d90a4c1b43b6251fa4348c8adc59b583274 ]
    
    From XGMAC Core 3.20 and later, each Flexible PPS has individual PPSEN bit
    to select Fixed mode or Flexible mode. The PPSEN must be set, or it stays
    in Fixed PPS mode by default.
    XGMAC Core prior 3.20, only PPSEN0(bit 4) is writable. PPSEN{1,2,3} are
    read-only reserved, and they are already in Flexible mode by default, our
    new code always set PPSEN{1,2,3} do not make things worse ;-)
    
    Fixes: 95eaf3cd0a90 ("net: stmmac: dwxgmac: Add Flexible PPS support")
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Furong Xu <0x1207@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Nov 8 13:18:53 2023 +0100

    netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses
    
    [ Upstream commit 80abbe8a8263106fe45a4f293b92b5c74cc9cc8a ]
    
    The ipv6 redirect target was derived from the ipv4 one, i.e. its
    identical to a 'dnat' with the first (primary) address assigned to the
    network interface.  The code has been moved around to make it usable
    from nf_tables too, but its still the same as it was back when this
    was added in 2012.
    
    IPv6, however, has different types of addresses, if the 'wrong' address
    comes first the redirection does not work.
    
    In Daniels case, the addresses are:
      inet6 ::ffff:192 ...
      inet6 2a01: ...
    
    ... so the function attempts to redirect to the mapped address.
    
    Add more checks before the address is deemed correct:
    1. If the packets' daddr is scoped, search for a scoped address too
    2. skip tentative addresses
    3. skip mapped addresses
    
    Use the first address that appears to match our needs.
    
    Reported-by: Daniel Huhardeaux <tech@tootai.net>
    Closes: https://lore.kernel.org/netfilter/71be06b8-6aa0-4cf9-9e0b-e2839b01b22f@tootai.net/
    Fixes: 115e23ac78f8 ("netfilter: ip6tables: add REDIRECT target")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: Drop pointless memset when dumping rules [+ + +]
Author: Phil Sutter <phil@nwl.cc>
Date:   Fri Sep 29 21:19:19 2023 +0200

    netfilter: nf_tables: Drop pointless memset when dumping rules
    
    [ Upstream commit 30fa41a0f6df4c85790cc6499ddc4a926a113bfa ]
    
    None of the dump callbacks uses netlink_callback::args beyond the first
    element, no need to zero the data.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: xt_recent: fix (increase) ipv6 literal buffer length [+ + +]
Author: Maciej Żenczykowski <zenczykowski@gmail.com>
Date:   Sun Nov 5 11:56:00 2023 -0800

    netfilter: xt_recent: fix (increase) ipv6 literal buffer length
    
    [ Upstream commit 7b308feb4fd2d1c06919445c65c8fbf8e9fd1781 ]
    
    in6_pton() supports 'low-32-bit dot-decimal representation'
    (this is useful with DNS64/NAT64 networks for example):
    
      # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT
      # cat /proc/self/net/xt_recent/DEFAULT
      src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829
    
    but the provided buffer is too short:
    
      # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT
      -bash: echo: write error: Invalid argument
    
    Fixes: 079aa88fe717 ("netfilter: xt_recent: IPv6 support")
    Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfsd: Handle EOPENSTALE correctly in the filecache [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Sep 11 14:30:27 2023 -0400

    nfsd: Handle EOPENSTALE correctly in the filecache
    
    [ Upstream commit d59b3515ab021e010fdc58a8f445ea62dd2f7f4c ]
    
    The nfsd_open code handles EOPENSTALE correctly, by retrying the call to
    fh_verify() and __nfsd_open(). However the filecache just drops the
    error on the floor, and immediately returns nfserr_stale to the caller.
    
    This patch ensures that we propagate the EOPENSTALE code back to
    nfsd_file_do_acquire, and that we handle it correctly.
    
    Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Message-Id: <20230911183027.11372-1-trond.myklebust@hammerspace.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
numa: Generalize numa_map_to_online_node() [+ + +]
Author: Yury Norov <yury.norov@gmail.com>
Date:   Sat Aug 19 07:12:33 2023 -0700

    numa: Generalize numa_map_to_online_node()
    
    [ Upstream commit b1f099b1cf51d553c510c6c8141c27d9ba7ea1fe ]
    
    The function in fact searches the nearest node for a given one,
    based on a N_ONLINE state. This is a common pattern to search
    for a nearest node.
    
    This patch converts numa_map_to_online_node() to numa_nearest_node()
    so that others won't need to opencode the logic.
    
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Link: https://lore.kernel.org/r/20230819141239.287290-2-yury.norov@gmail.com
    Stable-dep-of: 617f2c38cb5c ("sched/topology: Fix sched_numa_find_nth_cpu() in CPU-less case")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: fix error-handling for io_uring nvme-passthrough [+ + +]
Author: Anuj Gupta <anuj20.g@samsung.com>
Date:   Thu Oct 19 00:54:30 2023 +0530

    nvme: fix error-handling for io_uring nvme-passthrough
    
    [ Upstream commit 1147dd0503564fa0e03489a039f9e0c748a03db4 ]
    
    Driver may return an error before submitting the command to the device.
    Ensure that such error is propagated up.
    
    Fixes: 456cba386e94 ("nvme: wire-up uring-cmd support for io-passthru on char-device.")
    Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
    Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
    Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
objtool: Propagate early errors [+ + +]
Author: Aaron Plattner <aplattner@nvidia.com>
Date:   Wed Oct 4 17:08:18 2023 -0700

    objtool: Propagate early errors
    
    [ Upstream commit e959c279d391c10b35ce300fb4b0fe3b98e86bd2 ]
    
    If objtool runs into a problem that causes it to exit early, the overall
    tool still returns a status code of 0, which causes the build to
    continue as if nothing went wrong.
    
    Note this only affects early errors, as later errors are still ignored
    by check().
    
    Fixes: b51277eb9775 ("objtool: Ditch subcommands")
    Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
    Link: https://lore.kernel.org/r/cb6a28832d24b2ebfafd26da9abb95f874c83045.1696355111.git.aplattner@nvidia.com
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix error codes [+ + +]
Author: Ratheesh Kannoth <rkannoth@marvell.com>
Date:   Fri Oct 27 07:49:52 2023 +0530

    octeontx2-pf: Fix error codes
    
    [ Upstream commit 96b9a68d1a6e4f889d453874c9e359aa720b520f ]
    
    Some of error codes were wrong. Fix the same.
    
    Fixes: 51afe9026d0c ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]")
    Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Link: https://lore.kernel.org/r/20231027021953.1819959-1-rkannoth@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-pf: Fix holes in error code [+ + +]
Author: Ratheesh Kannoth <rkannoth@marvell.com>
Date:   Fri Oct 27 07:49:53 2023 +0530

    octeontx2-pf: Fix holes in error code
    
    [ Upstream commit 7aeeb2cb7a2570bb69a87ad14018b03e06ce5be5 ]
    
    Error code strings are not getting printed properly
    due to holes. Print error code as well.
    
    Fixes: 51afe9026d0c ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]")
    Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Link: https://lore.kernel.org/r/20231027021953.1819959-2-rkannoth@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-pf: Free pending and dropped SQEs [+ + +]
Author: Geetha sowjanya <gakula@marvell.com>
Date:   Tue Oct 31 16:53:45 2023 +0530

    octeontx2-pf: Free pending and dropped SQEs
    
    [ Upstream commit 3423ca23e08bf285a324237abe88e7e7d9becfe6 ]
    
    On interface down, the pending SQEs in the NIX get dropped
    or drained out during SMQ flush. But skb's pointed by these
    SQEs never get free or updated to the stack as respective CQE
    never get added.
    This patch fixes the issue by freeing all valid skb's in SQ SG list.
    
    Fixes: b1bc8457e9d0 ("octeontx2-pf: Cleanup all receive buffers in SG descriptor")
    Signed-off-by: Geetha sowjanya <gakula@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
padata: Fix refcnt handling in padata_free_shell() [+ + +]
Author: WangJinchao <wangjinchao@xfusion.com>
Date:   Mon Oct 16 09:15:21 2023 +0800

    padata: Fix refcnt handling in padata_free_shell()
    
    [ Upstream commit 7ddc21e317b360c3444de3023bcc83b85fabae2f ]
    
    In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
    to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
    the pcrypt_aead01 function call, I'll describe the problem scenario
    using a simplified model:
    
    Suppose there's a user of padata named `user_function` that adheres to
    the padata requirement of calling `padata_free_shell` after `serial()`
    has been invoked, as demonstrated in the following code:
    
    ```c
    struct request {
        struct padata_priv padata;
        struct completion *done;
    };
    
    void parallel(struct padata_priv *padata) {
        do_something();
    }
    
    void serial(struct padata_priv *padata) {
        struct request *request = container_of(padata,
                                    struct request,
                                    padata);
        complete(request->done);
    }
    
    void user_function() {
        DECLARE_COMPLETION(done)
        padata->parallel = parallel;
        padata->serial = serial;
        padata_do_parallel();
        wait_for_completion(&done);
        padata_free_shell();
    }
    ```
    
    In the corresponding padata.c file, there's the following code:
    
    ```c
    static void padata_serial_worker(struct work_struct *serial_work) {
        ...
        cnt = 0;
    
        while (!list_empty(&local_list)) {
            ...
            padata->serial(padata);
            cnt++;
        }
    
        local_bh_enable();
    
        if (refcount_sub_and_test(cnt, &pd->refcnt))
            padata_free_pd(pd);
    }
    ```
    
    Because of the high system load and the accumulation of unexecuted
    softirq at this moment, `local_bh_enable()` in padata takes longer
    to execute than usual. Subsequently, when accessing `pd->refcnt`,
    `pd` has already been released by `padata_free_shell()`, resulting
    in a UAF issue with `pd->refcnt`.
    
    The fix is straightforward: add `refcount_dec_and_test` before calling
    `padata_free_pd` in `padata_free_shell`.
    
    Fixes: 07928d9bfc81 ("padata: Remove broken queue flushing")
    
    Signed-off-by: WangJinchao <wangjinchao@xfusion.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/MSI: Provide stubs for IMS functions [+ + +]
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Tue Oct 17 10:56:38 2023 -0700

    PCI/MSI: Provide stubs for IMS functions
    
    [ Upstream commit 41efa431244f6498833ff8ee8dde28c4924c5479 ]
    
    The IMS related functions (pci_create_ims_domain(), pci_ims_alloc_irq(),
    and pci_ims_free_irq()) are not declared when CONFIG_PCI_MSI is disabled.
    
    Provide definitions of these functions for use when callers are compiled
    with CONFIG_PCI_MSI disabled.
    
    Fixes: 0194425af0c8 ("PCI/MSI: Provide IMS (Interrupt Message Store) support")
    Fixes: c9e5bea27383 ("PCI/MSI: Provide pci_ims_alloc/free_irq()")
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/14ff656899a3757453f8584c1109d7a9b98fa258.1697564731.git.reinette.chatre@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: endpoint: Fix double free in __pci_epc_create() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Oct 25 14:57:23 2023 +0300

    PCI: endpoint: Fix double free in __pci_epc_create()
    
    [ Upstream commit c9501d268944d6c0475ecb3e740a084a7da9cbfe ]
    
    The pci_epc_release() function frees "epc" so the kfree() on the next line
    is a double free.  Drop the redundant free.
    
    Fixes: 7711cbb4862a ("PCI: endpoint: Fix WARN() when an endpoint driver is removed")
    Link: https://lore.kernel.org/r/2ce68694-87a7-4c06-b8a4-9870c891b580@moroto.mountain
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: vmd: Correct PCI Header Type Register's multi-function check [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Oct 3 15:52:58 2023 +0300

    PCI: vmd: Correct PCI Header Type Register's multi-function check
    
    [ Upstream commit 5827e17d0555b566c32044b0632b46f9f95054fa ]
    
    vmd_domain_reset() attempts to find whether the device may contain multiple
    functions by checking 0x80 (Multi-Function Device), however, the hdr_type
    variable has already been masked with PCI_HEADER_TYPE_MASK so the check can
    never true.
    
    To fix the issue, don't mask the read with PCI_HEADER_TYPE_MASK.
    
    Fixes: 6aab5622296b ("PCI: vmd: Clean up domain before enumeration")
    Link: https://lore.kernel.org/r/20231003125300.5541-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Nirmal Patel <nirmal.patel@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pcmcia: cs: fix possible hung task and memory leak pccardd() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:25:41 2022 +0800

    pcmcia: cs: fix possible hung task and memory leak pccardd()
    
    [ Upstream commit e3ea1b4847e49234e691c0d66bf030bd65bb7f2b ]
    
    If device_register() returns error in pccardd(), it leads two issues:
    
    1. The socket_released has never been completed, it will block
       pcmcia_unregister_socket(), because of waiting for completion
       of socket_released.
    2. The device name allocated by dev_set_name() is leaked.
    
    Fix this two issues by calling put_device() when device_register() fails.
    socket_released can be completed in pcmcia_release_socket(), the name can
    be freed in kobject_cleanup().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pcmcia: ds: fix possible name leak in error path in pcmcia_device_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:29:24 2022 +0800

    pcmcia: ds: fix possible name leak in error path in pcmcia_device_add()
    
    [ Upstream commit 99e1241049a92dd3e9a90a0f91e32ce390133278 ]
    
    Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically.
    Therefore, it needs to be freed, which is done by the driver core for
    us once all references to the device are gone. Therefore, move the
    dev_set_name() call immediately before the call device_register(), which
    either succeeds (then the freeing will be done upon subsequent remvoal),
    or puts the reference in the error call. Also, it is not unusual that the
    return value of dev_set_name is not checked.
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    [linux@dominikbrodowski.net: simplification, commit message modified]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pcmcia: ds: fix refcount leak in pcmcia_device_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:29:23 2022 +0800

    pcmcia: ds: fix refcount leak in pcmcia_device_add()
    
    [ Upstream commit 402ab979b29126068e0b596b641422ff7490214c ]
    
    As the comment of device_register() says, it should use put_device()
    to give up the reference in the error path. Then, insofar resources
    will be freed in pcmcia_release_dev(), the error path is no longer
    needed. In particular, this means that the (previously missing) dropping
    of the reference to &p_dev->function_config->ref is now handled by
    pcmcia_release_dev().
    
    Fixes: 360b65b95bae ("[PATCH] pcmcia: make config_t independent, add reference counting")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    [linux@dominikbrodowski.net: simplification, commit message rewrite]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf build: Add missing comment about NO_LIBTRACEEVENT=1 [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Oct 5 10:46:26 2023 -0300

    perf build: Add missing comment about NO_LIBTRACEEVENT=1
    
    [ Upstream commit c1783ddfb62420c44cdf4672dad2046f056c624b ]
    
    By default perf will fail the build if the development files for
    libtraceevent are not available.
    
    To build perf without libtraceevent support, disabling several features
    such as 'perf trace', one needs to add NO_LIBTRACEVENT=1 to the make
    command line.
    
    Add the missing comments about that to the tools/perf/Makefile.perf
    file, just like all the other such command line toggles.
    
    Fixes: 378ef0f5d9d7f465 ("perf build: Use libtraceevent from the system")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Link: https://lore.kernel.org/r/ZR6+MhXtLnv6ow6E@kernel.org
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf hist: Add missing puts to hist__account_cycles [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Oct 24 15:23:08 2023 -0700

    perf hist: Add missing puts to hist__account_cycles
    
    [ Upstream commit c1149037f65bcf0334886180ebe3d5efcf214912 ]
    
    Caught using reference count checking on perf top with
    "--call-graph=lbr". After this no memory leaks were detected.
    
    Fixes: 57849998e2cd ("perf report: Add processing for cycle histograms")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: liuwenyu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Yanteng Si <siyanteng@loongson.cn>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Link: https://lore.kernel.org/r/20231024222353.3024098-6-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf kwork: Add the supported subcommands to the document [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Sat Aug 12 08:49:03 2023 +0000

    perf kwork: Add the supported subcommands to the document
    
    [ Upstream commit 76e0d8c821bbd952730799cc7af841f9de67b7f7 ]
    
    Add missing report, latency and timehist subcommands to the document.
    
    Fixes: f98919ec4fccdacf ("perf kwork: Implement 'report' subcommand")
    Fixes: ad3d9f7a929ab2df ("perf kwork: Implement perf kwork latency")
    Fixes: bcc8b3e88d6fa1a3 ("perf kwork: Implement perf kwork timehist")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Link: https://lore.kernel.org/r/20230812084917.169338-3-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf kwork: Fix incorrect and missing free atom in work_push_atom() [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Sat Aug 12 08:49:02 2023 +0000

    perf kwork: Fix incorrect and missing free atom in work_push_atom()
    
    [ Upstream commit d39710088d82ef100b33cdf4a9de3546fb0bb5df ]
    
    1. Atoms are managed in page mode and should be released using atom_free()
       instead of free().
    2. When the event does not match, the atom needs to free.
    
    Fixes: f98919ec4fccdacf ("perf kwork: Implement 'report' subcommand")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20230812084917.169338-2-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf kwork: Set ordered_events to true in 'struct perf_tool' [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Sat Aug 12 08:49:04 2023 +0000

    perf kwork: Set ordered_events to true in 'struct perf_tool'
    
    [ Upstream commit 0c526579a4b2b6ecd540472f2e34c2850cf70f76 ]
    
    'perf kwork' processes data based on timestamps and needs to sort events.
    
    Fixes: f98919ec4fccdacf ("perf kwork: Implement 'report' subcommand")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20230812084917.169338-4-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf machine: Avoid out of bounds LBR memory read [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Oct 24 15:23:05 2023 -0700

    perf machine: Avoid out of bounds LBR memory read
    
    [ Upstream commit ab8ce150781d326c6bfbe1e09f175ffde1186f80 ]
    
    Running perf top with address sanitizer and "--call-graph=lbr" fails
    due to reading sample 0 when no samples exist. Add a guard to prevent
    this.
    
    Fixes: e2b23483eb1d ("perf machine: Factor out lbr_callchain_add_lbr_ip()")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: liuwenyu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Yanteng Si <siyanteng@loongson.cn>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Link: https://lore.kernel.org/r/20231024222353.3024098-3-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf mem-events: Avoid uninitialized read [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Mon Oct 9 11:39:10 2023 -0700

    perf mem-events: Avoid uninitialized read
    
    [ Upstream commit 85f73c377b2ac9988a204b119aebb33ca5c60083 ]
    
    pmu should be initialized to NULL before perf_pmus__scan loop. Fix and
    shrink the scope of pmu at the same time. Issue detected by clang-tidy.
    
    Fixes: 5752c20f3787 ("perf mem: Scan all PMUs instead of just core ones")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: llvm@lists.linux.dev
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: Tom Rix <trix@redhat.com>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20231009183920.200859-10-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf parse-events: Fix driver config term [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Mon Sep 4 20:38:05 2023 -0700

    perf parse-events: Fix driver config term
    
    commit 45fc4628c15ab2cb7b2f53354b21db63f0a41f81 upstream.
    
    Inadvertently deleted in commit 30f4ade33d649aa0 ("perf tools: Revert
    enable indices setting syntax for BPF map").
    
    Fixes: 30f4ade33d649aa0 ("perf tools: Revert enable indices setting syntax for BPF map")
    Reported-by: James Clark <james.clark@arm.com>
    Reviewed-by: James Clark <james.clark@arm.com>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/20230905033805.3094293-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf parse-events: Fix for term values that are raw events [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Wed Sep 27 17:44:31 2023 -0700

    perf parse-events: Fix for term values that are raw events
    
    [ Upstream commit b20576fd7fe39554b212095c3c0d7a3dff512515 ]
    
    Raw events can be strings like 'r0xead' but the 0x is optional so they
    can also be 'read'. On IcelakeX uncore_imc_free_running has an event
    called 'read' which may be programmed as:
    ```
    $ perf stat -e 'uncore_imc_free_running/event=read/' -a sleep 1
    ```
    However, the PE_RAW type isn't allowed on the right of a term, even
    though in this case we just want to interpret it as a string. This
    leads to the following error on IcelakeX:
    ```
    $ perf stat -e 'uncore_imc_free_running/event=read/' -a sleep 1
    event syntax error: '..nning/event=read/'
                                      \___ parser error
    Run 'perf list' for a list of valid events
    
     Usage: perf stat [<options>] [<command>]
    
        -e, --event <event> event selector. use 'perf list' to list available events
    ```
    Fix this by allowing raw types on the right of terms and treat them as
    strings, just as is already done for PE_LEGACY_CACHE. Make this
    consistent by just entirely removing name_or_legacy and always using
    name_or_raw that covers all three cases.
    
    Fixes: 6fd1e5191591 ("perf parse-events: Support PMUs for legacy cache events")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/r/20230928004431.1926969-1-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf parse-events: Fix tracepoint name memory leak [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Sep 14 09:40:28 2023 -0700

    perf parse-events: Fix tracepoint name memory leak
    
    [ Upstream commit ede72dca45b1893f3e9236b6ad6c4e790db232f6 ]
    
    Fuzzing found that an invalid tracepoint name would create a memory
    leak with an address sanitizer build:
    ```
    $ perf stat -e '*:o/' true
    event syntax error: '*:o/'
                           \___ parser error
    Run 'perf list' for a list of valid events
    
     Usage: perf stat [<options>] [<command>]
    
        -e, --event <event>   event selector. use 'perf list' to list available events
    
    =================================================================
    ==59380==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 4 byte(s) in 2 object(s) allocated from:
        #0 0x7f38ac07077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439
        #1 0x55f2f41be73b in str util/parse-events.l:49
        #2 0x55f2f41d08e8 in parse_events_lex util/parse-events.l:338
        #3 0x55f2f41dc3b1 in parse_events_parse util/parse-events-bison.c:1464
        #4 0x55f2f410b8b3 in parse_events__scanner util/parse-events.c:1822
        #5 0x55f2f410d1b9 in __parse_events util/parse-events.c:2094
        #6 0x55f2f410e57f in parse_events_option util/parse-events.c:2279
        #7 0x55f2f4427b56 in get_value tools/lib/subcmd/parse-options.c:251
        #8 0x55f2f4428d98 in parse_short_opt tools/lib/subcmd/parse-options.c:351
        #9 0x55f2f4429d80 in parse_options_step tools/lib/subcmd/parse-options.c:539
        #10 0x55f2f442acb9 in parse_options_subcommand tools/lib/subcmd/parse-options.c:654
        #11 0x55f2f3ec99fc in cmd_stat tools/perf/builtin-stat.c:2501
        #12 0x55f2f4093289 in run_builtin tools/perf/perf.c:322
        #13 0x55f2f40937f5 in handle_internal_command tools/perf/perf.c:375
        #14 0x55f2f4093bbd in run_argv tools/perf/perf.c:419
        #15 0x55f2f409412b in main tools/perf/perf.c:535
    
    SUMMARY: AddressSanitizer: 4 byte(s) leaked in 2 allocation(s).
    ```
    Fix by adding the missing destructor.
    
    Fixes: 865582c3f48e ("perf tools: Adds the tracepoint name parsing support")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: He Kuang <hekuang@huawei.com>
    Link: https://lore.kernel.org/r/20230914164028.363220-1-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf parse-events: Remove ABORT_ON [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Jun 27 11:10:30 2023 -0700

    perf parse-events: Remove ABORT_ON
    
    [ Upstream commit 4c11adff675652759a0f0ad2194f4646b5463a42 ]
    
    Prefer informative messages rather than none with ABORT_ON. Document
    one failure mode and add an error message for another.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230627181030.95608-14-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: ede72dca45b1 ("perf parse-events: Fix tracepoint name memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf parse-events: Remove unused PE_KERNEL_PMU_EVENT token [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Jun 27 11:10:19 2023 -0700

    perf parse-events: Remove unused PE_KERNEL_PMU_EVENT token
    
    [ Upstream commit bf7d46b3a088ccb8f8045c5902d5848bc23286f9 ]
    
    Removed by commit 70c90e4a6b2f ("perf parse-events: Avoid scanning
    PMUs before parsing").
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230627181030.95608-3-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: ede72dca45b1 ("perf parse-events: Fix tracepoint name memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf parse-events: Remove unused PE_PMU_EVENT_FAKE token [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Jun 27 11:10:18 2023 -0700

    perf parse-events: Remove unused PE_PMU_EVENT_FAKE token
    
    [ Upstream commit 84efbdb7fb8e0844a3f9c67a6bdcc89db1012e1c ]
    
    Removed by commit 70c90e4a6b2f ("perf parse-events: Avoid scanning
    PMUs before parsing").
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230627181030.95608-2-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: ede72dca45b1 ("perf parse-events: Fix tracepoint name memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf pmu: Remove logic for PMU name being NULL [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Aug 24 19:39:58 2023 -0700

    perf pmu: Remove logic for PMU name being NULL
    
    [ Upstream commit c091ee90897aacf60aee510464cfc28b4041186f ]
    
    The PMU name could be NULL in the case of the fake_pmu. Initialize the
    name for the fake_pmu to "fake" so that all other logic can assume it
    is initialized. Add a const to the type of name so that a literal can
    be used to avoid additional initialization code. Propagate the cost
    through related routines and remove now unnecessary "(char *)"
    casts. Doing this located a bug in builtin-list for the pmu_glob that
    was missing a strdup.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Link: https://lore.kernel.org/r/20230825024002.801955-3-irogers@google.com
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Wei Li <liwei391@huawei.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-perf-users@vger.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 85f73c377b2a ("perf mem-events: Avoid uninitialized read")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf record: Fix BTF type checks in the off-cpu profiling [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Fri Sep 22 16:44:44 2023 -0700

    perf record: Fix BTF type checks in the off-cpu profiling
    
    [ Upstream commit 0e501a65d35bf72414379fed0e31a0b6b81ab57d ]
    
    The BTF func proto for a tracepoint has one more argument than the
    actual tracepoint function since it has a context argument at the
    begining.  So it should compare to 5 when the tracepoint has 4
    arguments.
    
      typedef void (*btf_trace_sched_switch)(void *, bool, struct task_struct *, struct task_struct *, unsigned int);
    
    Also, recent change in the perf tool would use a hand-written minimal
    vmlinux.h to generate BTF in the skeleton.  So it won't have the info
    of the tracepoint.  Anyway it should use the kernel's vmlinux BTF to
    check the type in the kernel.
    
    Fixes: b36888f71c85 ("perf record: Handle argument change in sched_switch")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Acked-by: Song Liu <song@kernel.org>
    Cc: Hao Luo <haoluo@google.com>
    CC: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230922234444.3115821-1-namhyung@kernel.org
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf stat: Fix aggr mode initialization [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Sep 5 17:39:12 2023 -0700

    perf stat: Fix aggr mode initialization
    
    [ Upstream commit a84fbf205609313594b86065c67e823f09ebe29b ]
    
    Generating metrics llc_code_read_mpi_demand_plus_prefetch,
    llc_data_read_mpi_demand_plus_prefetch,
    llc_miss_local_memory_bandwidth_read,
    llc_miss_local_memory_bandwidth_write,
    nllc_miss_remote_memory_bandwidth_read, memory_bandwidth_read,
    memory_bandwidth_write, uncore_frequency, upi_data_transmit_bw,
    C2_Pkg_Residency, C3_Core_Residency, C3_Pkg_Residency,
    C6_Core_Residency, C6_Pkg_Residency, C7_Core_Residency,
    C7_Pkg_Residency, UNCORE_FREQ and tma_info_system_socket_clks would
    trigger an address sanitizer heap-buffer-overflows on a SkylakeX.
    
    ```
    ==2567752==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5020003ed098 at pc 0x5621a816654e bp 0x7fffb55d4da0 sp 0x7fffb55d4d98
    READ of size 4 at 0x5020003eee78 thread T0
        #0 0x558265d6654d in aggr_cpu_id__is_empty tools/perf/util/cpumap.c:694:12
        #1 0x558265c914da in perf_stat__get_aggr tools/perf/builtin-stat.c:1490:6
        #2 0x558265c914da in perf_stat__get_global_cached tools/perf/builtin-stat.c:1530:9
        #3 0x558265e53290 in should_skip_zero_counter tools/perf/util/stat-display.c:947:31
        #4 0x558265e53290 in print_counter_aggrdata tools/perf/util/stat-display.c:985:18
        #5 0x558265e51931 in print_counter tools/perf/util/stat-display.c:1110:3
        #6 0x558265e51931 in evlist__print_counters tools/perf/util/stat-display.c:1571:5
        #7 0x558265c8ec87 in print_counters tools/perf/builtin-stat.c:981:2
        #8 0x558265c8cc71 in cmd_stat tools/perf/builtin-stat.c:2837:3
        #9 0x558265bb9bd4 in run_builtin tools/perf/perf.c:323:11
        #10 0x558265bb98eb in handle_internal_command tools/perf/perf.c:377:8
        #11 0x558265bb9389 in run_argv tools/perf/perf.c:421:2
        #12 0x558265bb9389 in main tools/perf/perf.c:537:3
    ```
    
    The issue was the use of testing a cpumap with NULL rather than using
    empty, as a map containing the dummy value isn't NULL and the -1
    results in an empty aggr map being allocated which legitimately
    overflows when any member is accessed.
    
    Fixes: 8a96f454f5668572 ("perf stat: Avoid SEGV if core.cpus isn't set")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230906003912.3317462-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tools: Do not ignore the default vmlinux.h [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Oct 10 16:42:47 2023 -0700

    perf tools: Do not ignore the default vmlinux.h
    
    [ Upstream commit 1f36b190ad2dea68e3a7e84b7b2f24ce8c4063ea ]
    
    The recent change made it possible to generate vmlinux.h from BTF and
    to ignore the file.  But we also have a minimal vmlinux.h that will be
    used by default.  It should not be ignored by GIT.
    
    Fixes: b7a2d774c9c5 ("perf build: Add ability to build with a generated vmlinux.h")
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310110451.rvdUZJEY-lkp@intel.com/
    Cc: oe-kbuild-all@lists.linux.dev
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf tools: Revert enable indices setting syntax for BPF map [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Jul 27 17:12:11 2023 -0700

    perf tools: Revert enable indices setting syntax for BPF map
    
    [ Upstream commit 30f4ade33d649aa0e8603386721f184ad9d3cb55 ]
    
    This reverts commit e571e029bdbf ("perf tools: Enable indices setting
    syntax for BPF map").
    
    The reverted commit added a notion of arrays that could be set as
    event terms for BPF events. The parsing hasn't worked over multiple
    Linux releases. Given the broken nature of the parsing it appears the
    code isn't in use, nor could I find a way for it to be used to add a
    test.
    
    The original commit contains a test in the commit message,
    however, running it yields:
    ```
    $ perf record -e './test_bpf_map_3.c/map:channel.value[0,1,2,3...5]=101/' usleep 2
    event syntax error: '..pf_map_3.c/map:channel.value[0,1,2,3...5]=101/'
                                      \___ parser error
    Run 'perf list' for a list of valid events
    
     Usage: perf record [<options>] [<command>]
        or: perf record [<options>] -- <command> [<options>]
    
        -e, --event <event>   event selector. use 'perf list' to list available events
    ```
    
    Given the code can't be used this commit reverts and removes it.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Eduard Zingerman <eddyz87@gmail.com>
    Cc: He Kuang <hekuang@huawei.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Cc: YueHaibing <yuehaibing@huawei.com>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20230728001212.457900-3-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: ede72dca45b1 ("perf parse-events: Fix tracepoint name memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf trace: Use the right bpf_probe_read(_str) variant for reading user data [+ + +]
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Thu Oct 19 10:26:42 2023 +0200

    perf trace: Use the right bpf_probe_read(_str) variant for reading user data
    
    [ Upstream commit 5069211e2f0b47e75119805e23ae6352d871e263 ]
    
    Perf test case 111 Check open filename arg using perf trace + vfs_getname
    fails on s390. This is caused by a failing function
    bpf_probe_read() in file util/bpf_skel/augmented_raw_syscalls.bpf.c.
    
    The root cause is the lookup by address. Function bpf_probe_read()
    is used. This function works only for architectures
    with ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE.
    
    On s390 is not possible to determine from the address to which
    address space the address belongs to (user or kernel space).
    
    Replace bpf_probe_read() by bpf_probe_read_kernel()
    and bpf_probe_read_str() by bpf_probe_read_user_str() to
    explicity specify the address space the address refers to.
    
    Output before:
     # ./perf trace -eopen,openat -- touch /tmp/111
     libbpf: prog 'sys_enter': BPF program load failed: Invalid argument
     libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG --
     reg type unsupported for arg#0 function sys_enter#75
     0: R1=ctx(off=0,imm=0) R10=fp0
     ; int sys_enter(struct syscall_enter_args *args)
     0: (bf) r6 = r1           ; R1=ctx(off=0,imm=0) R6_w=ctx(off=0,imm=0)
     ; return bpf_get_current_pid_tgid();
     1: (85) call bpf_get_current_pid_tgid#14      ; R0_w=scalar()
     2: (63) *(u32 *)(r10 -8) = r0 ; R0_w=scalar() R10=fp0 fp-8=????mmmm
     3: (bf) r2 = r10              ; R2_w=fp0 R10=fp0
     ;
     .....
     lines deleted here
     .....
     23: (bf) r3 = r6              ; R3_w=ctx(off=0,imm=0) R6=ctx(off=0,imm=0)
     24: (85) call bpf_probe_read#4
     unknown func bpf_probe_read#4
     processed 23 insns (limit 1000000) max_states_per_insn 0 \
             total_states 2 peak_states 2 mark_read 2
     -- END PROG LOAD LOG --
     libbpf: prog 'sys_enter': failed to load: -22
     libbpf: failed to load object 'augmented_raw_syscalls_bpf'
     libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -22
     ....
    
    Output after:
     # ./perf test -Fv 111
     111: Check open filename arg using perf trace + vfs_getname          :
     --- start ---
         1.085 ( 0.011 ms): touch/320753 openat(dfd: CWD, filename: \
            "/tmp/temporary_file.SWH85", \
            flags: CREAT|NOCTTY|NONBLOCK|WRONLY, mode: IRUGO|IWUGO) = 3
     ---- end ----
     Check open filename arg using perf trace + vfs_getname: Ok
     #
    
    Test with the sleep command shows:
    Output before:
     # ./perf trace -e *sleep sleep 1.234567890
         0.000 (1234.681 ms): sleep/63114 clock_nanosleep(rqtp: \
             { .tv_sec: 0, .tv_nsec: 0 }, rmtp: 0x3ffe0979720) = 0
     #
    
    Output after:
     # ./perf trace -e *sleep sleep 1.234567890
         0.000 (1234.686 ms): sleep/64277 clock_nanosleep(rqtp: \
             { .tv_sec: 1, .tv_nsec: 234567890 }, rmtp: 0x3fff3df9ea0) = 0
     #
    
    Fixes: 14e4b9f4289a ("perf trace: Raw augmented syscalls fix libbpf 1.0+ compatibility")
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Co-developed-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: gor@linux.ibm.com
    Cc: hca@linux.ibm.com
    Cc: sumanthk@linux.ibm.com
    Cc: svens@linux.ibm.com
    Link: https://lore.kernel.org/r/20231019082642.3286650-1-tmricht@linux.ibm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf vendor events intel: Add broadwellde two metrics [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Sep 26 13:59:47 2023 -0700

    perf vendor events intel: Add broadwellde two metrics
    
    [ Upstream commit 19a214bffdf7abb8d472895bb944d9c269ab1699 ]
    
    Add tma_info_system_socket_clks and uncore_freq metrics that require a
    broadwellx style uncore event for UNC_CLOCK.
    
    The associated converter script fix is in:
    https://github.com/intel/perfmon/pull/112
    
    Fixes: 7d124303d620 ("perf vendor events intel: Update broadwell variant events/metrics")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Caleb Biggers <caleb.biggers@intel.com>
    Cc: Perry Taylor <perry.taylor@intel.com>
    Link: https://lore.kernel.org/r/20230926205948.1399594-2-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf vendor events intel: Fix broadwellde tma_info_system_dram_bw_use metric [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Mon Sep 25 20:10:34 2023 -0700

    perf vendor events intel: Fix broadwellde tma_info_system_dram_bw_use metric
    
    [ Upstream commit 3779416eed25a843364b940decee452620a1de4b ]
    
    Broadwell-de has a consumer core and server uncore. The uncore_arb PMU
    isn't present and the broadwellx style cbox PMU should be used
    instead. Fix the tma_info_system_dram_bw_use metric to use the server
    metric rather than client.
    
    The associated converter script fix is in:
    https://github.com/intel/perfmon/pull/111
    
    Fixes: 7d124303d620 ("perf vendor events intel: Update broadwell variant events/metrics")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Caleb Biggers <caleb.biggers@intel.com>
    Cc: Perry Taylor <perry.taylor@intel.com>
    Link: https://lore.kernel.org/r/20230926031034.1201145-1-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf vendor events: Update PMC used in PM_RUN_INST_CMPL event for power10 platform [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Mon Oct 16 20:01:10 2023 +0530

    perf vendor events: Update PMC used in PM_RUN_INST_CMPL event for power10 platform
    
    [ Upstream commit 3f8b6e5b11192dacb721d2d28ea4589917f5e822 ]
    
    The CPI_STALL_RATIO metric group can be used to present the high
    level CPI stall breakdown metrics in powerpc, which will show:
    
    - DISPATCH_STALL_CPI ( Dispatch stall cycles per insn )
    - ISSUE_STALL_CPI ( Issue stall cycles per insn )
    - EXECUTION_STALL_CPI ( Execution stall cycles per insn )
    - COMPLETION_STALL_CPI ( Completion stall cycles per insn )
    
    Commit cf26e043c2a9 ("perf vendor events power10: Add JSON
    metric events to present CPI stall cycles in powerpc)" which added
    the CPI_STALL_RATIO metric group, also modified
    the PMC value used in PM_RUN_INST_CMPL event from PMC4 to PMC5,
    to avoid multiplexing of events.
    But that got revert in recent changes. Fix this issue by changing
    back the PMC value used in PM_RUN_INST_CMPL to PMC5.
    
    Result with the fix:
    
     ./perf stat --metric-no-group -M CPI_STALL_RATIO <workload>
    
     Performance counter stats for 'workload':
    
            68,745,426      PM_CMPL_STALL                    #     0.21 COMPLETION_STALL_CPI
             7,692,827      PM_ISSUE_STALL                   #     0.02 ISSUE_STALL_CPI
           322,638,223      PM_RUN_INST_CMPL                 #     0.05 DISPATCH_STALL_CPI
                                                      #     0.48 EXECUTION_STALL_CPI
            16,858,553      PM_DISP_STALL_CYC
           153,880,133      PM_EXEC_STALL
    
           0.089774592 seconds time elapsed
    
    "--metric-no-group" is used for forcing PM_RUN_INST_CMPL to be scheduled
    in all group for more accuracy.
    
    Fixes: 7d473f475b2a ("perf vendor events: Move JSON/events to appropriate files for power10 platform")
    Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Tested-by: Disha Goel<disgoel@linux.ibm.com>
    Cc: maddy@linux.ibm.com
    Link: https://lore.kernel.org/r/20231016143110.244255-1-kjain@linux.ibm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/arm-cmn: Fix DTC domain detection [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Fri Oct 20 18:51:25 2023 +0100

    perf/arm-cmn: Fix DTC domain detection
    
    [ Upstream commit e3e73f511c49c741f6309862c2248958ad77bbaa ]
    
    It transpires that dtm_unit_info is another register which got shuffled
    in CMN-700 without me noticing. Fix that in a way which also proactively
    fixes the fragile laziness of its consumer, just in case any further
    fields ever get added alongside dtc_domain.
    
    Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
    Link: https://lore.kernel.org/r/3076ee83d0554f6939fbb6ee49ab2bdb28d8c7ee.1697824215.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf: hisi: Fix use-after-free when register pmu fails [+ + +]
Author: Junhao He <hejunhao3@huawei.com>
Date:   Tue Oct 24 19:36:30 2023 +0800

    perf: hisi: Fix use-after-free when register pmu fails
    
    [ Upstream commit b805cafc604bfdb671fae7347a57f51154afa735 ]
    
    When we fail to register the uncore pmu, the pmu context may not been
    allocated. The error handing will call cpuhp_state_remove_instance()
    to call uncore pmu offline callback, which migrate the pmu context.
    Since that's liable to lead to some kind of use-after-free.
    
    Use cpuhp_state_remove_instance_nocalls() instead of
    cpuhp_state_remove_instance() so that the notifiers don't execute after
    the PMU device has been failed to register.
    
    Fixes: a0ab25cd82ee ("drivers/perf: hisi: Add support for HiSilicon PA PMU driver")
    FIxes: 3bf30882c3c7 ("drivers/perf: hisi: Add support for HiSilicon SLLC PMU driver")
    Signed-off-by: Junhao He <hejunhao3@huawei.com>
    Link: https://lore.kernel.org/r/20231024113630.13472-1-hejunhao3@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf: Optimize perf_cgroup_switch() [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Oct 9 23:04:25 2023 +0200

    perf: Optimize perf_cgroup_switch()
    
    [ Upstream commit f06cc667f79909e9175460b167c277b7c64d3df0 ]
    
    Namhyung reported that bd2756811766 ("perf: Rewrite core context handling")
    regresses context switch overhead when perf-cgroup is in use together
    with 'slow' PMUs like uncore.
    
    Specifically, perf_cgroup_switch()'s perf_ctx_disable() /
    ctx_sched_out() etc.. all iterate the full list of active PMUs for
    that CPU, even if they don't have cgroup events.
    
    Previously there was cgrp_cpuctx_list which linked the relevant PMUs
    together, but that got lost in the rework. Instead of re-instruducing
    a similar list, let the perf_event_pmu_context iteration skip those
    that do not have cgroup events. This avoids growing multiple versions
    of the perf_event_pmu_context iteration.
    
    Measured performance (on a slightly different patch):
    
    Before)
    
      $ taskset -c 0 ./perf bench sched pipe -l 10000 -G AAA,BBB
      # Running 'sched/pipe' benchmark:
      # Executed 10000 pipe operations between two processes
    
           Total time: 0.901 [sec]
    
            90.128700 usecs/op
                11095 ops/sec
    
    After)
    
      $ taskset -c 0 ./perf bench sched pipe -l 10000 -G AAA,BBB
      # Running 'sched/pipe' benchmark:
      # Executed 10000 pipe operations between two processes
    
           Total time: 0.065 [sec]
    
             6.560100 usecs/op
               152436 ops/sec
    
    Fixes: bd2756811766 ("perf: Rewrite core context handling")
    Reported-by: Namhyung Kim <namhyung@kernel.org>
    Debugged-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20231009210425.GC6307@noisy.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: renesas: rzg2l: Make reverse order of enable() for disable() [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Mon Sep 18 13:33:54 2023 +0100

    pinctrl: renesas: rzg2l: Make reverse order of enable() for disable()
    
    [ Upstream commit dd462cf53e4dff0f4eba5e6650e31ceddec74c6f ]
    
    We usually do reverse order of enable() for disable(). Currently, the
    ordering of irq_chip_disable_parent() is not correct in
    rzg2l_gpio_irq_disable(). Fix the incorrect order.
    
    Fixes: db2e5f21a48e ("pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230918123355.262115-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/chrome: cros_ec_lpc: Separate host command and irq disable [+ + +]
Author: Lalith Rajendran <lalithkraj@chromium.org>
Date:   Fri Oct 27 16:02:22 2023 -0500

    platform/chrome: cros_ec_lpc: Separate host command and irq disable
    
    [ Upstream commit 47ea0ddb1f5604ba3496baa19110aec6a3151f2e ]
    
    Both cros host command and irq disable were moved to suspend
    prepare stage from late suspend recently. This is causing EC
    to report MKBP event timeouts during suspend stress testing.
    When the MKBP event timeouts happen during suspend, subsequent
    wakeup of AP by EC using MKBP doesn't happen properly. Move the
    irq disabling part back to late suspend stage which is a general
    suggestion from the suspend kernel documentaiton to do irq
    disable as late as possible.
    
    Fixes: 4b9abbc132b8 ("platform/chrome: cros_ec_lpc: Move host command to prepare/complete")
    Signed-off-by: Lalith Rajendran <lalithkraj@chromium.org>
    Link: https://lore.kernel.org/r/20231027160221.v4.1.I1725c3ed27eb7cd9836904e49e8bfa9fb0200a97@changeid
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: wmi: Fix opening of char device [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Fri Oct 20 23:10:04 2023 +0200

    platform/x86: wmi: Fix opening of char device
    
    [ Upstream commit eba9ac7abab91c8f6d351460239108bef5e7a0b6 ]
    
    Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
    file private data"), the miscdevice stores a pointer to itself inside
    filp->private_data, which means that private_data will not be NULL when
    wmi_char_open() is called. This might cause memory corruption should
    wmi_char_open() be unable to find its driver, something which can
    happen when the associated WMI device is deleted in wmi_free_devices().
    
    Fix the problem by using the miscdevice pointer to retrieve the WMI
    device data associated with a char device using container_of(). This
    also avoids wmi_char_open() picking a wrong WMI device bound to a
    driver with the same name as the original driver.
    
    Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: wmi: Fix probe failure when failing to register WMI devices [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Fri Oct 20 23:10:03 2023 +0200

    platform/x86: wmi: Fix probe failure when failing to register WMI devices
    
    [ Upstream commit ed85891a276edaf7a867de0e9acd0837bc3008f2 ]
    
    When a WMI device besides the first one somehow fails to register,
    retval is returned while still containing a negative error code. This
    causes the ACPI device fail to probe, leaving behind zombie WMI devices
    leading to various errors later.
    
    Handle the single error path separately and return 0 unconditionally
    after trying to register all WMI devices to solve the issue. Also
    continue to register WMI devices even if some fail to allocate memory.
    
    Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM / devfreq: rockchip-dfi: Make pmu regmap mandatory [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Jul 4 11:32:17 2023 +0200

    PM / devfreq: rockchip-dfi: Make pmu regmap mandatory
    
    [ Upstream commit 1e0731c05c985deb68a97fa44c1adcd3305dda90 ]
    
    As a matter of fact the regmap_pmu already is mandatory because
    it is used unconditionally in the driver. Bail out gracefully in
    probe() rather than crashing later.
    
    Link: https://lore.kernel.org/lkml/20230704093242.583575-2-s.hauer@pengutronix.de/
    Fixes: b9d1262bca0af ("PM / devfreq: event: support rockchip dfi controller")
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: sleep: Fix symbol export for _SIMPLE_ variants of _PM_OPS() [+ + +]
Author: Raag Jadav <raag.jadav@intel.com>
Date:   Fri Sep 22 11:15:52 2023 +0530

    PM: sleep: Fix symbol export for _SIMPLE_ variants of _PM_OPS()
    
    [ Upstream commit 8d74f1da776da9b0306630b13a3025214fa44618 ]
    
    Currently EXPORT_*_SIMPLE_DEV_PM_OPS() use EXPORT_*_DEV_PM_OPS() set
    of macros to export dev_pm_ops symbol, which export the symbol in case
    CONFIG_PM=y but don't take CONFIG_PM_SLEEP into consideration.
    
    Since _SIMPLE_ variants of _PM_OPS() do not include runtime PM handles
    and are only used in case CONFIG_PM_SLEEP=y, we should not be exporting
    dev_pm_ops symbol for them in case CONFIG_PM_SLEEP=n.
    
    This can be fixed by having two distinct set of export macros for both
    _RUNTIME_ and _SIMPLE_ variants of _PM_OPS(), such that the export of
    dev_pm_ops symbol used in each variant depends on CONFIG_PM and
    CONFIG_PM_SLEEP respectively.
    
    Introduce _DEV_SLEEP_PM_OPS() set of export macros for _SIMPLE_ variants
    of _PM_OPS(), which export dev_pm_ops symbol only in case CONFIG_PM_SLEEP=y
    and discard it otherwise.
    
    Fixes: 34e1ed189fab ("PM: Improve EXPORT_*_DEV_PM_OPS macros")
    Signed-off-by: Raag Jadav <raag.jadav@intel.com>
    Reviewed-by: Paul Cercueil <paul@crapouillou.net>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/40x: Remove stale PTE_ATOMIC_UPDATES macro [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Sep 25 20:31:17 2023 +0200

    powerpc/40x: Remove stale PTE_ATOMIC_UPDATES macro
    
    [ Upstream commit cc8ee288f484a2a59c01ccd4d8a417d6ed3466e3 ]
    
    40x TLB handlers were reworked by commit 2c74e2586bb9 ("powerpc/40x:
    Rework 40x PTE access and TLB miss") to not require PTE_ATOMIC_UPDATES
    anymore.
    
    Then commit 4e1df545e2fa ("powerpc/pgtable: Drop PTE_ATOMIC_UPDATES")
    removed all code related to PTE_ATOMIC_UPDATES.
    
    Remove left over PTE_ATOMIC_UPDATES macro.
    
    Fixes: 2c74e2586bb9 ("powerpc/40x: Rework 40x PTE access and TLB miss")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/f061db5857fcd748f84a6707aad01754686ce97e.1695659959.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/imc-pmu: Use the correct spinlock initializer. [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Thu Mar 9 14:48:31 2023 +0100

    powerpc/imc-pmu: Use the correct spinlock initializer.
    
    [ Upstream commit 007240d59c11f87ac4f6cfc6a1d116630b6b634c ]
    
    The macro __SPIN_LOCK_INITIALIZER() is implementation specific. Users
    that desire to initialize a spinlock in a struct must use
    __SPIN_LOCK_UNLOCKED().
    
    Use __SPIN_LOCK_UNLOCKED() for the spinlock_t in imc_global_refc.
    
    Fixes: 76d588dddc459 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled section")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230309134831.Nz12nqsU@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: fix potential memory leak in init_cpu_associativity() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Wed Dec 14 15:46:23 2022 +0800

    powerpc/pseries: fix potential memory leak in init_cpu_associativity()
    
    [ Upstream commit 95f1a128cd728a7257d78e868f1f5a145fc43736 ]
    
    If the vcpu_associativity alloc memory successfully but the
    pcpu_associativity fails to alloc memory, the vcpu_associativity
    memory leaks.
    
    Fixes: d62c8deeb6e6 ("powerpc/pseries: Provide vcpu dispatch statistics")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Reviewed-by: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/1671003983-10794-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/vas: Limit open window failure messages in log bufffer [+ + +]
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Thu Oct 19 14:50:33 2023 -0700

    powerpc/vas: Limit open window failure messages in log bufffer
    
    [ Upstream commit 73b25505ce043b561028e5571d84dc82aa53c2b4 ]
    
    The VAS open window call prints error message and returns -EBUSY
    after the migration suspend event initiated and until the resume
    event completed on the destination system. It can cause the log
    buffer filled with these error messages if the user space issues
    continuous open window calls.  Similar case even for DLPAR CPU
    remove event when no credits are available until the credits are
    freed or with the other DLPAR CPU add event.
    
    So changes in the patch to use pr_err_ratelimited() instead of
    pr_err() to display open window failure and not-available credits
    error messages.
    
    Use pr_fmt() and make the corresponding changes to have the
    consistencein prefix all pr_*() messages (vas-api.c).
    
    Fixes: 37e6764895ef ("powerpc/pseries/vas: Add VAS migration handler")
    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    [mpe: Use "vas-api" as the prefix to match the file name.]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231019215033.1335251-1-haren@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/xive: Fix endian conversion size [+ + +]
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Wed Oct 11 16:37:00 2023 +1100

    powerpc/xive: Fix endian conversion size
    
    [ Upstream commit ff7a60ab1e065257a0e467c13b519f4debcd7fcf ]
    
    Sparse reports a size mismatch in the endian swap. The Opal
    implementation[1] passes the value as a __be64, and the receiving
    variable out_qsize is a u64, so the use of be32_to_cpu() appears to be
    an error.
    
    [1]: https://github.com/open-power/skiboot/blob/80e2b1dc73/hw/xive.c#L3854
    
    Fixes: 88ec6b93c8e7 ("powerpc/xive: add OPAL extensions for the XIVE native exploitation support")
    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231011053711.93427-2-bgray@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: Hide empty pt_regs at base of the stack [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Aug 24 16:42:10 2023 +1000

    powerpc: Hide empty pt_regs at base of the stack
    
    [ Upstream commit d45c4b48dafb5820e5cc267ff9a6d7784d13a43c ]
    
    A thread started via eg. user_mode_thread() runs in the kernel to begin
    with and then may later return to userspace. While it's running in the
    kernel it has a pt_regs at the base of its kernel stack, but that
    pt_regs is all zeroes.
    
    If the thread oopses in that state, it leads to an ugly stack trace with
    a big block of zero GPRs, as reported by Joel:
    
      Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3
      Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV
      Call Trace:
      [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable)
      [c0000000036afb30] [c00000000013c524] panic+0x178/0x424
      [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324
      [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344
      [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac
      [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0
      [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c
      --- interrupt: 0 at 0x0
      NIP:  0000000000000000 LR: 0000000000000000 CTR: 0000000000000000
      REGS: c0000000036afe80 TRAP: 0000   Not tainted  (6.5.0-rc7-00004-gf7757129e3de-dirty)
      MSR:  0000000000000000 <>  CR: 00000000  XER: 00000000
      CFAR: 0000000000000000 IRQMASK: 0
      GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      NIP [0000000000000000] 0x0
      LR [0000000000000000] 0x0
      --- interrupt: 0
    
    The all-zero pt_regs looks ugly and conveys no useful information, other
    than its presence. So detect that case and just show the presence of the
    frame by printing the interrupt marker, eg:
    
      Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty #301
      Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
      Call Trace:
      [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable)
      [c000000003aabb30] [c00000000014c624] panic+0x178/0x424
      [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324
      [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344
      [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac
      [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0
      [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c
      --- interrupt: 0 at 0x0
    
    To avoid ever suppressing a valid pt_regs make sure the pt_regs has a
    zero MSR and TRAP value, and is located at the very base of the stack.
    
    Fixes: 6895dfc04741 ("powerpc: copy_thread fill in interrupt frame marker and back chain")
    Reported-by: Joel Stanley <joel@jms.id.au>
    Reported-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230824064210.907266-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc: Only define __parse_fpscr() when required [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Sep 22 14:33:13 2023 +0200

    powerpc: Only define __parse_fpscr() when required
    
    [ Upstream commit c7e0d9bb9154c6e6b2ac8746faba27b53393f25e ]
    
    Clang 17 reports:
    
    arch/powerpc/kernel/traps.c:1167:19: error: unused function '__parse_fpscr' [-Werror,-Wunused-function]
    
    __parse_fpscr() is called from two sites. First call is guarded
    by #ifdef CONFIG_PPC_FPU_REGS
    
    Second call is guarded by CONFIG_MATH_EMULATION which selects
    CONFIG_PPC_FPU_REGS.
    
    So only define __parse_fpscr() when CONFIG_PPC_FPU_REGS is defined.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202309210327.WkqSd5Bq-lkp@intel.com/
    Fixes: b6254ced4da6 ("powerpc/signal: Don't manage floating point regs when no FPU")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/5de2998c57f3983563b27b39228ea9a7229d4110.1695385984.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore/platform: Add check for kstrdup [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Jun 23 10:27:06 2023 +0800

    pstore/platform: Add check for kstrdup
    
    [ Upstream commit a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c ]
    
    Add check for the return value of kstrdup() and return the error
    if it fails in order to avoid NULL pointer dereference.
    
    Fixes: 563ca40ddf40 ("pstore/platform: Switch pstore_info::name to const")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230623022706.32125-1-jiasheng@iscas.ac.cn
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Wed Oct 4 10:54:14 2023 -0700

    pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume
    
    [ Upstream commit e9bc4411548aaa738905d37851a0146c16b3bb21 ]
    
    The suspend/resume functions currently utilize
    clk_disable()/clk_enable() respectively which may be no-ops with certain
    clock providers such as SCMI. Fix this to use clk_disable_unprepare()
    and clk_prepare_enable() respectively as we should.
    
    Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support")
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Acked-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: sti: Reduce number of allocations and drop usage of chip_data [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Jul 5 10:06:48 2023 +0200

    pwm: sti: Reduce number of allocations and drop usage of chip_data
    
    [ Upstream commit 2d6812b41e0d832919d72c72ebddf361df53ba1b ]
    
    Instead of using one allocation per capture channel, use a single one. Also
    store it in driver data instead of chip data.
    
    This has several advantages:
    
     - driver data isn't cleared when pwm_put() is called
     - Reduces memory fragmentation
    
    Also register the pwm chip only after the per capture channel data is
    initialized as the capture callback relies on this initialization and it
    might be called even before pwmchip_add() returns.
    
    It would be still better to have struct sti_pwm_compat_data and the
    per-channel data struct sti_cpt_ddata in a single memory chunk, but that's
    not easily possible because the number of capture channels isn't known yet
    when the driver data struct is allocated.
    
    Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
    Reported-by: George Stark <gnstark@sberdevices.ru>
    Fixes: c97267ae831d ("pwm: sti: Add PWM capture callback")
    Link: https://lore.kernel.org/r/20230705080650.2353391-7-u.kleine-koenig@pengutronix.de
    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>

 
r8169: fix rare issue with broken rx after link-down on RTL8125 [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Thu Oct 12 08:51:13 2023 +0200

    r8169: fix rare issue with broken rx after link-down on RTL8125
    
    [ Upstream commit 621735f590643e3048ca2060c285b80551660601 ]
    
    In very rare cases (I've seen two reports so far about different
    RTL8125 chip versions) it seems the MAC locks up when link goes down
    and requires a software reset to get revived.
    Realtek doesn't publish hw errata information, therefore the root cause
    is unknown. Realtek vendor drivers do a full hw re-initialization on
    each link-up event, the slimmed-down variant here was reported to fix
    the issue for the reporting user.
    It's not fully clear which parts of the NIC are reset as part of the
    software reset, therefore I can't rule out side effects.
    
    Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
    Reported-by: Martin Kjær Jørgensen <me@lagy.org>
    Link: https://lore.kernel.org/netdev/97ec2232-3257-316c-c3e7-a08192ce16a6@gmail.com/T/
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/9edde757-9c3b-4730-be3b-0ef3a374ff71@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

r8169: respect userspace disabling IFF_MULTICAST [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Nov 5 23:43:36 2023 +0100

    r8169: respect userspace disabling IFF_MULTICAST
    
    [ Upstream commit 8999ce4cfc87e61b4143ec2e7b93d8e92e11fa7f ]
    
    So far we ignore the setting of IFF_MULTICAST. Fix this and clear bit
    AcceptMulticast if IFF_MULTICAST isn't set.
    
    Note: Based on the implementations I've seen it doesn't seem to be 100% clear
    what a driver is supposed to do if IFF_ALLMULTI is set but IFF_MULTICAST
    is not. This patch is based on the understanding that IFF_MULTICAST has
    precedence.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/4a57ba02-d52d-4369-9f14-3565e6c1f7dc@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/core: Use size_{add,sub,mul}() in calls to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Sun Sep 17 15:21:36 2023 -0600

    RDMA/core: Use size_{add,sub,mul}() in calls to struct_size()
    
    [ Upstream commit 81760bedc65194ff38e1e4faefd5f9f0c95c19a4 ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound,
    the protection that `struct_size()` provides against potential integer
    overflows is defeated. Fix this by hardening calls to `struct_size()`
    with `size_add()`, `size_sub()` and `size_mul()`.
    
    Fixes: 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes")
    Fixes: a4676388e2e2 ("RDMA/core: Simplify how the gid_attrs sysfs is created")
    Fixes: e9dd5daf884c ("IB/umad: Refactor code to use cdev_device_add()")
    Fixes: 324e227ea7c9 ("RDMA/device: Add ib_device_get_by_netdev()")
    Fixes: 5aad26a7eac5 ("IB/core: Use struct_size() in kzalloc()")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/ZQdt4NsJFwwOYxUR@work
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hfi1: Workaround truncation compilation error [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Oct 24 18:07:31 2023 +0300

    RDMA/hfi1: Workaround truncation compilation error
    
    [ Upstream commit d4b2d165714c0ce8777d5131f6e0aad617b7adc4 ]
    
    Increase name array to be large enough to overcome the following
    compilation error.
    
    drivers/infiniband/hw/hfi1/efivar.c: In function ‘read_hfi1_efi_var’:
    drivers/infiniband/hw/hfi1/efivar.c:124:44: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
      124 |         snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                                            ^
    drivers/infiniband/hw/hfi1/efivar.c:124:9: note: ‘snprintf’ output 2 or more bytes (assuming 65) into a destination of size 64
      124 |         snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/infiniband/hw/hfi1/efivar.c:133:52: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
      133 |                 snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                                                    ^
    drivers/infiniband/hw/hfi1/efivar.c:133:17: note: ‘snprintf’ output 2 or more bytes (assuming 65) into a destination of size 64
      133 |                 snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    make[6]: *** [scripts/Makefile.build:243: drivers/infiniband/hw/hfi1/efivar.o] Error 1
    
    Fixes: c03c08d50b3d ("IB/hfi1: Check upper-case EFI variables")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/238fa39a8fd60e87a5ad7e1ca6584fcdf32e9519.1698159993.git.leonro@nvidia.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: Add check for SL [+ + +]
Author: Luoyouming <luoyouming@huawei.com>
Date:   Tue Oct 17 20:52:36 2023 +0800

    RDMA/hns: Add check for SL
    
    [ Upstream commit 5e617c18b1f34ec57ad5dce44f09de603cf6bd6c ]
    
    SL set by users may exceed the capability of devices. So add check
    for this situation.
    
    Fixes: fba429fcf9a5 ("RDMA/hns: Fix missing fields in address vector")
    Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
    Fixes: f0cb411aad23 ("RDMA/hns: Use new interface to modify QP context")
    Signed-off-by: Luoyouming <luoyouming@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20231017125239.164455-5-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix printing level of asynchronous events [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Tue Oct 17 20:52:33 2023 +0800

    RDMA/hns: Fix printing level of asynchronous events
    
    [ Upstream commit 9faef73ef4f6666b97e04d99734ac09251098185 ]
    
    The current driver will print all asynchronous events. Some of the
    print levels are set improperly, e.g. SRQ limit reach and SRQ last
    wqe reach, which may also occur during normal operation of the software.
    Currently, the information of these event is printed as a warning,
    which causes a large amount of printing even during normal use of the
    application. As a result, the service performance deteriorates.
    
    This patch fixes the printing storms by modifying the print level.
    
    Fixes: b00a92c8f2ca ("RDMA/hns: Move all prints out of irq handle")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20231017125239.164455-2-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix signed-unsigned mixed comparisons [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Tue Oct 17 20:52:35 2023 +0800

    RDMA/hns: Fix signed-unsigned mixed comparisons
    
    [ Upstream commit b5f9efff101b06fd06a5e280a2b00b1335f5f476 ]
    
    The ib_mtu_enum_to_int() and uverbs_attr_get_len() may returns a negative
    value. In this case, mixed comparisons of signed and unsigned types will
    throw wrong results.
    
    This patch adds judgement for this situation.
    
    Fixes: 30b707886aeb ("RDMA/hns: Support inline data in extented sge space for RC")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20231017125239.164455-4-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix uninitialized ucmd in hns_roce_create_qp_common() [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Tue Oct 17 20:52:34 2023 +0800

    RDMA/hns: Fix uninitialized ucmd in hns_roce_create_qp_common()
    
    [ Upstream commit c64e9710f9241e38a1c761ed1c1a30854784da66 ]
    
    ucmd in hns_roce_create_qp_common() are not initialized. But it works fine
    until new member sdb_addr is added to struct hns_roce_ib_create_qp.
    
    If the user-mode driver uses an old version ABI, then the value of the new
    member will be undefined after ib_copy_from_udata().
    
    This patch fixes it by initialize this variable to 0. And the default value
    of the new member sdb_addr will be 0 which is invalid.
    
    Fixes: 0425e3e6e0c7 ("RDMA/hns: Support flush cqe for hip08 in kernel space")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20231017125239.164455-3-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: The UD mode can only be configured with DCQCN [+ + +]
Author: Luoyouming <luoyouming@huawei.com>
Date:   Tue Oct 17 20:52:37 2023 +0800

    RDMA/hns: The UD mode can only be configured with DCQCN
    
    [ Upstream commit 27c5fd271d8b8730fc0bb1b6cae953ad7808a874 ]
    
    Due to hardware limitations, only DCQCN is supported for UD. Therefore, the
    default algorithm for UD is set to DCQCN.
    
    Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW")
    Signed-off-by: Luoyouming <luoyouming@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20231017125239.164455-6-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regmap: debugfs: Fix a erroneous check after snprintf() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Sep 4 22:04:06 2023 +0200

    regmap: debugfs: Fix a erroneous check after snprintf()
    
    [ Upstream commit d3601857e14de6369f00ae19564f1d817d175d19 ]
    
    This error handling looks really strange.
    Check if the string has been truncated instead.
    
    Fixes: f0c2319f9f19 ("regmap: Expose the driver name in debugfs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/8595de2462c490561f70020a6d11f4d6b652b468.1693857825.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regmap: prevent noinc writes from clobbering cache [+ + +]
Author: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Date:   Wed Nov 1 10:29:27 2023 -0400

    regmap: prevent noinc writes from clobbering cache
    
    [ Upstream commit 984a4afdc87a1fc226fd657b1cd8255c13d3fc1a ]
    
    Currently, noinc writes are cached as if they were standard incrementing
    writes, overwriting unrelated register values in the cache. Instead, we
    want to cache the last value written to the register, as is done in the
    accelerated noinc handler (regmap_noinc_readwrite).
    
    Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API")
    Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
    Link: https://lore.kernel.org/r/20231101142926.2722603-2-ben.wolsieffer@hefring.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: mt6358: Fail probe on unknown chip ID [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Sep 13 16:29:16 2023 +0800

    regulator: mt6358: Fail probe on unknown chip ID
    
    [ Upstream commit 7442edec72bc657e6ce38ae01de9f10e55decfaa ]
    
    The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have
    a chip ID register, making the chip semi-discoverable.
    
    The driver currently supports two PMICs and expects to be probed on one
    or the other. It does not account for incorrect mfd driver entries or
    device trees. While these should not happen, if they do, it could be
    catastrophic for the device. The driver should be sure the hardware is
    what it expects.
    
    Make the driver fail to probe if the chip ID presented is not a known
    one.
    
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Fixes: f0e3c6261af1 ("regulator: mt6366: Add support for MT6366 regulator")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20230913082919.1631287-2-wenst@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: qcom-rpmh: Fix smps4 regulator for pm8550ve [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Tue Oct 24 16:46:26 2023 +0300

    regulator: qcom-rpmh: Fix smps4 regulator for pm8550ve
    
    [ Upstream commit bc00d9f3813a40bc2d854ae0edab14c6b43a3219 ]
    
    The type of the smps4 regulator from pm8550ve is actually FTSMPS525
    medium voltage. So fix it accordingly.
    
    Fixes: e6e3776d682d ("regulator: qcom-rpmh: Add support for PM8550 regulators")
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20231024134626.2364426-1-abel.vesa@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/ast: report connection status on Display Port." [+ + +]
Author: Sasha Levin <sashal@kernel.org>
Date:   Mon Nov 13 11:36:36 2023 -0500

    Revert "drm/ast: report connection status on Display Port."
    
    This reverts commit f81bb0ac7872893241319ea82504956676ef02fd.
    
    The commit depends on e329cb53b45d ("drm/ast: Add BMC virtual
    connector") and will cause hangs on boot without that dependency.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "hwmon: (sch56xx-common) Add automatic module loading on supported devices" [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Oct 25 14:32:40 2023 -0700

    Revert "hwmon: (sch56xx-common) Add automatic module loading on supported devices"
    
    [ Upstream commit d621a46d05107f4e510383d6a38f2160c62d28f7 ]
    
    This reverts commit 393935baa45e5ccb9603cf7f9f020ed1bc0915f7.
    
    As reported by Ian Nartowicz, this and the next patch
    result in a failure to load the driver on Celsius W280.
    While the alternative would be to add the board to the DMI
    override table, it is quite likely that other systems are
    also affected. Revert the offending patches to avoid future
    problems.
    
    Fixes: 393935baa45e ("hwmon: (sch56xx-common) Add automatic module loading on supported devices")
    Reported-by: Ian Nartowicz <deadbeef@nartowicz.co.uk>
    Closes: https://lore.kernel.org/linux-hwmon/20231025192239.3c5389ae@debian.org/T/#t
    Cc: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Revert "hwmon: (sch56xx-common) Add DMI override table" [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Oct 25 14:28:49 2023 -0700

    Revert "hwmon: (sch56xx-common) Add DMI override table"
    
    [ Upstream commit 28da9dee3594423534f3ea1e1f61e6bb2d2fa651 ]
    
    This reverts commit fd2d53c367ae9983c2100ac733a834e0c79d7537.
    
    As reported by Ian Nartowicz, this and the preceding patch
    result in a failure to load the driver on Celsius W280.
    While the alternative would be to add the board to the DMI
    override table, it is quite likely that other systems are
    also affected. Revert the offending patches to avoid future
    problems.
    
    Fixes: fd2d53c367ae ("hwmon: (sch56xx-common) Add DMI override table")
    Reported-by: Ian Nartowicz <deadbeef@nartowicz.co.uk>
    Closes: https://lore.kernel.org/linux-hwmon/20231025192239.3c5389ae@debian.org/T/#t
    Cc: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "mmc: core: Capture correct oemid-bits for eMMC cards" [+ + +]
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Date:   Fri Nov 3 09:42:20 2023 +0900

    Revert "mmc: core: Capture correct oemid-bits for eMMC cards"
    
    commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream.
    
    This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff.
    
    The commit above made quirks with an OEMID fail to be applied, as they
    were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP
    macros but the field would only contain the bottom 8 bits.
    
    eMMC v5.1A might have bogus values in OEMID's higher bits so another fix
    will be made, but it has been decided to revert this until that is ready.
    
    Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards")
    Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org
    Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Cc: stable@vger.kernel.org
    Cc: Alex Fetters <Alex.Fetters@garmin.com>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "PCI/ASPM: Disable only ASPM_STATE_L1 when driver, disables L1" [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Oct 11 09:36:40 2023 +0200

    Revert "PCI/ASPM: Disable only ASPM_STATE_L1 when driver, disables L1"
    
    commit 3cb4f534bac010258b2688395c2f13459a932be9 upstream.
    
    This reverts commit fb097dcd5a28c0a2325632405c76a66777a6bed9.
    
    After fb097dcd5a28 ("PCI/ASPM: Disable only ASPM_STATE_L1 when driver
    disables L1"), disabling L1 via pci_disable_link_state(PCIE_LINK_STATE_L1),
    then enabling one substate, e.g., L1.1, via sysfs actually enables *all*
    the substates.
    
    For example, r8169 disables L1 because of hardware issues on a number of
    systems, which implicitly disables the L1.1 and L1.2 substates.
    
    On some systems, L1 and L1.1 work fine, but L1.2 causes missed rx packets.
    Enabling L1.1 via the sysfs "aspm_l1_1" attribute unexpectedly enables L1.2
    as well as L1.1.
    
    After fb097dcd5a28, pci_disable_link_state(PCIE_LINK_STATE_L1) adds only
    ASPM_L1 (but not any of the L1.x substates) to the "aspm_disable" mask:
    
      --- Before fb097dcd5a28
      +++ After fb097dcd5a28
    
      # r8169 disables L1:
        pci_disable_link_state(PCIE_LINK_STATE_L1)
      -   disable |= ASPM_L1 | ASPM_L1_1 | ASPM_L1_2 | ...  # disable L1, L1.x
      +   disable |= ASPM_L1                                # disable L1 only
    
      # write "1" to sysfs "aspm_l1_1" attribute:
        l1_1_aspm
          aspm_attr_store_common(state = ASPM_L1_1)
            disable &= ~ASPM_L1_1              # enable L1.1
            if (state & (ASPM_L1_1 | ...))     # if enabling any substate
              disable &= ~ASPM_L1              # enable L1
    
      # final state:
      - disable = ASPM_L1_2 | ...              # L1, L1.1 enabled; L1.2 disabled
      + disable = 0                            # L1, L1.1, L1.2 all enabled
    
    Enabling an L1.x substate removes the substate and L1 from the
    "aspm_disable" mask.  After fb097dcd5a28, the substates were not added to
    the mask when disabling L1, so enabling one substate implicitly enables all
    of them.
    
    Revert fb097dcd5a28 so enabling one substate doesn't enable the others.
    
    Link: https://lore.kernel.org/r/c75931ac-7208-4200-9ca1-821629cf5e28@gmail.com
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    [bhelgaas: work through example in commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RISC-V: Don't fail in riscv_of_parent_hartid() for disabled HARTs [+ + +]
Author: Anup Patel <apatel@ventanamicro.com>
Date:   Fri Oct 27 21:12:53 2023 +0530

    RISC-V: Don't fail in riscv_of_parent_hartid() for disabled HARTs
    
    [ Upstream commit c4676f8dc1e12e68d6511f9ed89707fdad4c962c ]
    
    The riscv_of_processor_hartid() used by riscv_of_parent_hartid() fails
    for HARTs disabled in the DT. This results in the following warning
    thrown by the RISC-V INTC driver for the E-core on SiFive boards:
    
    [    0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
    
    The riscv_of_parent_hartid() is only expected to read the hartid
    from the DT so we directly call of_get_cpu_hwid() instead of calling
    riscv_of_processor_hartid().
    
    Fixes: ad635e723e17 ("riscv: cpu: Add 64bit hartid support on RV64")
    Signed-off-by: Anup Patel <apatel@ventanamicro.com>
    Reviewed-by: Atish Patra <atishp@rivosinc.com>
    Link: https://lore.kernel.org/r/20231027154254.355853-2-apatel@ventanamicro.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: boot: Fix creation of loader.bin [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Oct 24 16:53:18 2023 +0200

    riscv: boot: Fix creation of loader.bin
    
    [ Upstream commit 57a4542cb7c9baa1509c3366b57a08d75b212ead ]
    
    When flashing loader.bin for K210 using kflash:
    
        [ERROR] This is an ELF file and cannot be programmed to flash directly: arch/riscv/boot/loader.bin
    
    Before, loader.bin relied on "OBJCOPYFLAGS := -O binary" in the main
    RISC-V Makefile to create a boot image with the right format.  With this
    removed, the image is now created in the wrong (ELF) format.
    
    Fix this by adding an explicit rule.
    
    Fixes: 505b02957e74f0c5 ("riscv: Remove duplicate objcopy flag")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Link: https://lore.kernel.org/r/1086025809583809538dfecaa899892218f44e7e.1698159066.git.geert+renesas@glider.be
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: dts: allwinner: remove address-cells from intc node [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Sat Sep 16 10:14:00 2023 +0100

    riscv: dts: allwinner: remove address-cells from intc node
    
    [ Upstream commit 267860b10c67dd396c73a9e6e8103670d78a4c01 ]
    
    A recent submission [1] from Rob has added additionalProperties: false
    to the interrupt-controller child node of RISC-V cpus, highlighting that
    the D1 DT has been incorrectly using #address-cells since its
    introduction. It has no child nodes, so #address-cells is not needed.
    Remove it.
    
    Fixes: 077e5f4f5528 ("riscv: dts: allwinner: Add the D1/D1s SoC devicetree")
    Link: https://patchwork.kernel.org/project/linux-riscv/patch/20230915201946.4184468-1-robh@kernel.org/ [1]
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://lore.kernel.org/r/20230916-saddling-dastardly-8cf6d1263c24@spud
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtc: brcmstb-waketimer: support level alarm_irq [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Wed Aug 30 15:47:47 2023 -0700

    rtc: brcmstb-waketimer: support level alarm_irq
    
    [ Upstream commit e005a9b35b464be5b2e0194f717e90e7e496785d ]
    
    Some devices (e.g. BCM72112) use an alarm_irq interrupt that is
    connected to a level interrupt controller rather than an edge
    interrupt controller. In this case, the interrupt cannot be left
    enabled by the irq handler while preserving the hardware wake-up
    signal on wake capable devices or an interrupt storm will occur.
    
    The alarm_expired flag is introduced to allow the disabling of
    the interrupt when an alarm expires and to support balancing the
    calls to disable_irq() and enable_irq() in accordance with the
    existing design.
    
    Fixes: 24304a87158a ("rtc: brcmstb-waketimer: allow use as non-wake alarm")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20230830224747.1663044-1-opendmb@gmail.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: pcf85363: Allow to wake up system without IRQ [+ + +]
Author: Mike Looijmans <mike.looijmans@topic.nl>
Date:   Mon Aug 21 09:20:13 2023 +0200

    rtc: pcf85363: Allow to wake up system without IRQ
    
    [ Upstream commit 1e786b03705938870dafb629f2248f88d507a0ff ]
    
    When wakeup-source is set in the devicetree, set up the device for
    using the output as interrupt instead of clock. This is similar to
    how other RTC devices handle this.
    
    This allows the clock chip to turn on the board when wired to do
    so in hardware.
    
    Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
    Link: https://lore.kernel.org/r/20230821072013.7072-1-mike.looijmans@topic.nl
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 2be36c09b6b0 ("rtc: pcf85363: fix wrong mask/val parameters in regmap_update_bits call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: pcf85363: fix wrong mask/val parameters in regmap_update_bits call [+ + +]
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Fri Oct 13 16:34:21 2023 +0200

    rtc: pcf85363: fix wrong mask/val parameters in regmap_update_bits call
    
    [ Upstream commit 2be36c09b6b07306be33519e1aa70d2e2a2161bb ]
    
    The current implementation passes PIN_IO_INTA_OUT (2) as a mask and
    PIN_IO_INTAPM (GENMASK(1, 0)) as a value.
    Swap the variables to assign mask and value the right way.
    
    This error was first introduced with the alarm support. For better or
    worse it worked as expected because 0x02 was applied as a mask to 0x03,
    resulting 0x02 anyway. This will of course not work for any other value.
    
    Fixes: e5aac267a10a ("rtc: pcf85363: add alarm support")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20231013-topic-pcf85363_regmap_update_bits-v1-1-c454f016f71f@gmail.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtla: Fix uninitialized variable found [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Jul 27 16:01:17 2023 +0100

    rtla: Fix uninitialized variable found
    
    [ Upstream commit 696444a544ecd6d62c1edc89516b376cefb28929 ]
    
    Variable found is not being initialized, in the case where the desired
    mount is not found the variable contains garbage. Fix this by initializing
    it to zero.
    
    Link: https://lore.kernel.org/all/20230727150117.627730-1-colin.i.king@gmail.com/
    
    Fixes: a957cbc02531 ("rtla: Add -C cgroup support")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rxrpc: Fix two connection reaping bugs [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Oct 27 00:49:34 2023 +0100

    rxrpc: Fix two connection reaping bugs
    
    [ Upstream commit 61e4a86600029e6e8d468d1fad6b6c749bebed19 ]
    
    Fix two connection reaping bugs:
    
     (1) rxrpc_connection_expiry is in units of seconds, so
         rxrpc_disconnect_call() needs to multiply it by HZ when adding it to
         jiffies.
    
     (2) rxrpc_client_conn_reap_timeout() should set RXRPC_CLIENT_REAP_TIMER if
         local->kill_all_client_conns is clear, not if it is set (in which case
         we don't need the timer).  Without this, old client connections don't
         get cleaned up until the local endpoint is cleaned up.
    
    Fixes: 5040011d073d ("rxrpc: Make the local endpoint hold a ref on a connected call")
    Fixes: 0d6bf319bc5a ("rxrpc: Move the client conn cache management to the I/O thread")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/783911.1698364174@warthog.procyon.org.uk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/ap: re-init AP queues on config on [+ + +]
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Tue Sep 12 09:54:25 2023 +0200

    s390/ap: re-init AP queues on config on
    
    [ Upstream commit 32d1d9204f8db3360be55e65bd182a1a68f93308 ]
    
    On a state toggle from config off to config on and on the
    state toggle from checkstop to not checkstop the queue's
    internal states was set but the state machine was not
    nudged. This did not care as on the first enqueue of a
    request the state machine kick ran.
    
    However, within an Secure Execution guest a queue is
    only chosen by the scheduler when it has been bound.
    But to bind a queue, it needs to run through the initial
    states (reset, enable interrupts, ...). So this is like
    a chicken-and-egg problem and the result was in fact
    that a queue was unusable after a config off/on toggle.
    
    With some slight rework of the handling of these states
    now the new function _ap_queue_init_state() is called
    which is the core of the ap_queue_init_state() function
    but without locking handling. This has the benefit that
    it can be called on all the places where a (re-)init
    of the AP queue's state machine is needed.
    
    Fixes: 2d72eaf036d2 ("s390/ap: implement SE AP bind, unbind and associate")
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/fair: Fix cfs_rq_is_decayed() on !SMP [+ + +]
Author: Chengming Zhou <zhouchengming@bytedance.com>
Date:   Wed Sep 13 13:20:31 2023 +0000

    sched/fair: Fix cfs_rq_is_decayed() on !SMP
    
    [ Upstream commit c0490bc9bb62d9376f3dd4ec28e03ca0fef97152 ]
    
    We don't need to maintain per-queue leaf_cfs_rq_list on !SMP, since
    it's used for cfs_rq load tracking & balancing on SMP.
    
    But sched debug interface uses it to print per-cfs_rq stats.
    
    This patch fixes the !SMP version of cfs_rq_is_decayed(), so the
    per-queue leaf_cfs_rq_list is also maintained correctly on !SMP,
    to fix the warning in assert_list_leaf_cfs_rq().
    
    Fixes: 0a00a354644e ("sched/fair: Delete useless condition in tg_unthrottle_up()")
    Reported-by: Leo Yu-Chi Liang <ycliang@andestech.com>
    Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: Leo Yu-Chi Liang <ycliang@andestech.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Closes: https://lore.kernel.org/all/ZN87UsqkWcFLDxea@swlinux02/
    Link: https://lore.kernel.org/r/20230913132031.2242151-1-chengming.zhou@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/topology: Fix sched_numa_find_nth_cpu() in CPU-less case [+ + +]
Author: Yury Norov <yury.norov@gmail.com>
Date:   Sat Aug 19 07:12:35 2023 -0700

    sched/topology: Fix sched_numa_find_nth_cpu() in CPU-less case
    
    [ Upstream commit 617f2c38cb5ce60226042081c09e2ee3a90d03f8 ]
    
    When the node provided by user is CPU-less, corresponding record in
    sched_domains_numa_masks is not set. Trying to dereference it in the
    following code leads to kernel crash.
    
    To avoid it, start searching from the nearest node with CPUs.
    
    Fixes: cd7f55359c90 ("sched: add sched_numa_find_nth_cpu()")
    Reported-by: Yicong Yang <yangyicong@hisilicon.com>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Link: https://lore.kernel.org/r/20230819141239.287290-4-yury.norov@gmail.com
    
    Closes: https://lore.kernel.org/lkml/CAAH8bW8C5humYnfpW3y5ypwx0E-09A3QxFE1JFzR66v+mO4XfA@mail.gmail.com/T/
    Closes: https://lore.kernel.org/lkml/ZMHSNQfv39HN068m@yury-ThinkPad/T/#mf6431cb0b7f6f05193c41adeee444bc95bf2b1c4
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/topology: Fix sched_numa_find_nth_cpu() in non-NUMA case [+ + +]
Author: Yury Norov <yury.norov@gmail.com>
Date:   Sat Aug 19 07:12:36 2023 -0700

    sched/topology: Fix sched_numa_find_nth_cpu() in non-NUMA case
    
    [ Upstream commit 8ab63d418d4339d996f80d02a00dbce0aa3ff972 ]
    
    When CONFIG_NUMA is enabled, sched_numa_find_nth_cpu() searches for a
    CPU in sched_domains_numa_masks. The masks includes only online CPUs,
    so effectively offline CPUs are skipped.
    
    When CONFIG_NUMA is disabled, the fallback function should be consistent.
    
    Fixes: cd7f55359c90 ("sched: add sched_numa_find_nth_cpu()")
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Link: https://lore.kernel.org/r/20230819141239.287290-5-yury.norov@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/uclamp: Ignore (util == 0) optimization in feec() when p_util_max = 0 [+ + +]
Author: Qais Yousef <qyousef@layalina.io>
Date:   Sun Sep 17 00:29:54 2023 +0100

    sched/uclamp: Ignore (util == 0) optimization in feec() when p_util_max = 0
    
    [ Upstream commit 23c9519def98ee0fa97ea5871535e9b136f522fc ]
    
    find_energy_efficient_cpu() bails out early if effective util of the
    task is 0 as the delta at this point will be zero and there's nothing
    for EAS to do. When uclamp is being used, this could lead to wrong
    decisions when uclamp_max is set to 0. In this case the task is capped
    to performance point 0, but it is actually running and consuming energy
    and we can benefit from EAS energy calculations.
    
    Rework the condition so that it bails out when both util and uclamp_min
    are 0.
    
    We can do that without needing to use uclamp_task_util(); remove it.
    
    Fixes: d81304bc6193 ("sched/uclamp: Cater for uclamp in find_energy_efficient_cpu()'s early exit condition")
    Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230916232955.2099394-3-qyousef@layalina.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/uclamp: Set max_spare_cap_cpu even if max_spare_cap is 0 [+ + +]
Author: Qais Yousef <qyousef@layalina.io>
Date:   Sun Sep 17 00:29:53 2023 +0100

    sched/uclamp: Set max_spare_cap_cpu even if max_spare_cap is 0
    
    [ Upstream commit 6b00a40147653c8ea748e8f4396510f252763364 ]
    
    When uclamp_max is being used, the util of the task could be higher than
    the spare capacity of the CPU, but due to uclamp_max value we force-fit
    it there.
    
    The way the condition for checking for max_spare_cap in
    find_energy_efficient_cpu() was constructed; it ignored any CPU that has
    its spare_cap less than or _equal_ to max_spare_cap. Since we initialize
    max_spare_cap to 0; this lead to never setting max_spare_cap_cpu and
    hence ending up never performing compute_energy() for this cluster and
    missing an opportunity for a better energy efficient placement to honour
    uclamp_max setting.
    
            max_spare_cap = 0;
            cpu_cap = capacity_of(cpu) - cpu_util(p);  // 0 if cpu_util(p) is high
    
            ...
    
            util_fits_cpu(...);             // will return true if uclamp_max forces it to fit
    
            ...
    
            // this logic will fail to update max_spare_cap_cpu if cpu_cap is 0
            if (cpu_cap > max_spare_cap) {
                    max_spare_cap = cpu_cap;
                    max_spare_cap_cpu = cpu;
            }
    
    prev_spare_cap suffers from a similar problem.
    
    Fix the logic by converting the variables into long and treating -1
    value as 'not populated' instead of 0 which is a viable and correct
    spare capacity value. We need to be careful signed comparison is used
    when comparing with cpu_cap in one of the conditions.
    
    Fixes: 1d42509e475c ("sched/fair: Make EAS wakeup placement consider uclamp restrictions")
    Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230916232955.2099394-2-qyousef@layalina.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched: Fix stop_one_cpu_nowait() vs hotplug [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Oct 10 20:57:39 2023 +0200

    sched: Fix stop_one_cpu_nowait() vs hotplug
    
    [ Upstream commit f0498d2a54e7966ce23cd7c7ff42c64fa0059b07 ]
    
    Kuyo reported sporadic failures on a sched_setaffinity() vs CPU
    hotplug stress-test -- notably affine_move_task() remains stuck in
    wait_for_completion(), leading to a hung-task detector warning.
    
    Specifically, it was reported that stop_one_cpu_nowait(.fn =
    migration_cpu_stop) returns false -- this stopper is responsible for
    the matching complete().
    
    The race scenario is:
    
            CPU0                                    CPU1
    
                                            // doing _cpu_down()
    
      __set_cpus_allowed_ptr()
        task_rq_lock();
                                            takedown_cpu()
                                              stop_machine_cpuslocked(take_cpu_down..)
    
                                            <PREEMPT: cpu_stopper_thread()
                                              MULTI_STOP_PREPARE
                                              ...
        __set_cpus_allowed_ptr_locked()
          affine_move_task()
            task_rq_unlock();
    
      <PREEMPT: cpu_stopper_thread()\>
        ack_state()
                                              MULTI_STOP_RUN
                                                take_cpu_down()
                                                  __cpu_disable();
                                                  stop_machine_park();
                                                    stopper->enabled = false;
                                             />
       />
            stop_one_cpu_nowait(.fn = migration_cpu_stop);
              if (stopper->enabled) // false!!!
    
    That is, by doing stop_one_cpu_nowait() after dropping rq-lock, the
    stopper thread gets a chance to preempt and allows the cpu-down for
    the target CPU to complete.
    
    OTOH, since stop_one_cpu_nowait() / cpu_stop_queue_work() needs to
    issue a wakeup, it must not be ran under the scheduler locks.
    
    Solve this apparent contradiction by keeping preemption disabled over
    the unlock + queue_stopper combination:
    
            preempt_disable();
            task_rq_unlock(...);
            if (!stop_pending)
              stop_one_cpu_nowait(...)
            preempt_enable();
    
    This respects the lock ordering contraints while still avoiding the
    above race. That is, if we find the CPU is online under rq-lock, the
    targeted stop_one_cpu_nowait() must succeed.
    
    Apply this pattern to all similar stop_one_cpu_nowait() invocations.
    
    Fixes: 6d337eab041d ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()")
    Reported-by: "Kuyo Chang (張建文)" <Kuyo.Chang@mediatek.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: "Kuyo Chang (張建文)" <Kuyo.Chang@mediatek.com>
    Link: https://lkml.kernel.org/r/20231010200442.GA16515@noisy.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/gdb: fix usage of MOD_TEXT not defined when CONFIG_MODULES=n [+ + +]
Author: Clément Léger <cleger@rivosinc.com>
Date:   Tue Oct 31 13:49:04 2023 +0000

    scripts/gdb: fix usage of MOD_TEXT not defined when CONFIG_MODULES=n
    
    [ Upstream commit 16501630bdeb107141a0139ddc33f92ab5582c6f ]
    
    MOD_TEXT is only defined if CONFIG_MODULES=y which lead to loading failure
    of the gdb scripts when kernel is built without CONFIG_MODULES=y:
    
    Reading symbols from vmlinux...
    Traceback (most recent call last):
      File "/foo/vmlinux-gdb.py", line 25, in <module>
        import linux.constants
      File "/foo/scripts/gdb/linux/constants.py", line 14, in <module>
        LX_MOD_TEXT = gdb.parse_and_eval("MOD_TEXT")
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    gdb.error: No symbol "MOD_TEXT" in current context.
    
    Add a conditional check on CONFIG_MODULES to fix this error.
    
    Link: https://lkml.kernel.org/r/20231031134848.119391-1-da.gomez@samsung.com
    Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address")
    Signed-off-by: Clément Léger <cleger@rivosinc.com>
    Tested-by: Daniel Gomez <da.gomez@samsung.com>
    Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
    Cc: Jan Kiszka <jan.kiszka@siemens.com>
    Cc: Kieran Bingham <kbingham@kernel.org>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Pankaj Raghav <p.raghav@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: ibmvfc: Fix erroneous use of rtas_busy_delay with hcall return code [+ + +]
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
Date:   Thu Sep 21 17:54:28 2023 -0500

    scsi: ibmvfc: Fix erroneous use of rtas_busy_delay with hcall return code
    
    [ Upstream commit 670106eb4c8b23475f8c2b3416005a312afa622f ]
    
    Commit 0217a272fe13 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ
    during cleanup") wrongly changed the busy loop check to use
    rtas_busy_delay() instead of H_BUSY and H_IS_LONG_BUSY(). The busy return
    codes for RTAS and hypercalls are not the same.
    
    Fix this issue by restoring the use of H_BUSY and H_IS_LONG_BUSY().
    
    Fixes: 0217a272fe13 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ  during cleanup")
    Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230921225435.3537728-5-tyreld@linux.ibm.com
    Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Leave space for '\0' in utf8 desc string [+ + +]
Author: Daniel Mentz <danielmentz@google.com>
Date:   Tue Oct 17 11:20:26 2023 -0700

    scsi: ufs: core: Leave space for '\0' in utf8 desc string
    
    [ Upstream commit a75a16c62a2540f11eeae4f2b50e95deefb652ea ]
    
    utf16s_to_utf8s does not NULL terminate the output string. For us to be
    able to add a NULL character when utf16s_to_utf8s returns, we need to make
    sure that there is space for such NULL character at the end of the output
    buffer. We can achieve this by passing an output buffer size to
    utf16s_to_utf8s that is one character less than what we allocated.
    
    Other call sites of utf16s_to_utf8s appear to be using the same technique
    where they artificially reduce the buffer size by one to leave space for a
    NULL character or line feed character.
    
    Fixes: 4b828fe156a6 ("scsi: ufs: revamp string descriptor reading")
    Reviewed-by: Mars Cheng <marscheng@google.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Yen-lin Lai <yenlinlai@google.com>
    Signed-off-by: Daniel Mentz <danielmentz@google.com>
    Link: https://lore.kernel.org/r/20231017182026.2141163-1-danielmentz@google.com
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Correct map_fd to data_fd in tailcalls [+ + +]
Author: Leon Hwang <hffilwlqm@gmail.com>
Date:   Wed Sep 6 23:42:56 2023 +0800

    selftests/bpf: Correct map_fd to data_fd in tailcalls
    
    [ Upstream commit 96daa9874211d5497aa70fa409b67afc29f0cb86 ]
    
    Get and check data_fd. It should not check map_fd again.
    
    Meanwhile, correct some 'return' to 'goto out'.
    
    Thank the suggestion from Maciej in "bpf, x64: Fix tailcall infinite
    loop"[0] discussions.
    
    [0] https://lore.kernel.org/bpf/e496aef8-1f80-0f8e-dcdd-25a8c300319a@gmail.com/T/#m7d3b601066ba66400d436b7e7579b2df4a101033
    
    Fixes: 79d49ba048ec ("bpf, testing: Add various tail call test cases")
    Fixes: 3b0379111197 ("selftests/bpf: Add tailcall_bpf2bpf tests")
    Fixes: 5e0b0a4c52d3 ("selftests/bpf: Test tail call counting with bpf2bpf and data on stack")
    Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/r/20230906154256.95461-1-hffilwlqm@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Skip module_fentry_shadow test when bpf_testmod is not available [+ + +]
Author: Artem Savkov <asavkov@redhat.com>
Date:   Thu Sep 14 14:49:28 2023 +0200

    selftests/bpf: Skip module_fentry_shadow test when bpf_testmod is not available
    
    [ Upstream commit 971f7c32147f2d0953a815a109b22b8ed45949d4 ]
    
    This test relies on bpf_testmod, so skip it if the module is not available.
    
    Fixes: aa3d65de4b900 ("bpf/selftests: Test fentry attachment to shadowed functions")
    Signed-off-by: Artem Savkov <asavkov@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20230914124928.340701-1-asavkov@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/pidfd: Fix ksft print formats [+ + +]
Author: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Date:   Fri Oct 13 13:36:28 2023 +0200

    selftests/pidfd: Fix ksft print formats
    
    [ Upstream commit 4d7f4e8158b62f63031510cdc24acc520956c091 ]
    
    Compiling pidfd selftest after adding a __printf() attribute to
    ksft_print_msg() and ksft_test_result_pass() exposes -Wformat warnings
    in error_report(), test_pidfd_poll_exec_thread(),
    child_poll_exec_test(), test_pidfd_poll_leader_exit_thread(),
    child_poll_leader_exit_test().
    
    The ksft_test_result_pass() in error_report() expects a string but
    doesn't provide any argument after the format string. All the other
    calls to ksft_print_msg() in the functions mentioned above have format
    strings that don't match with other passed arguments.
    
    Fix format specifiers so they match the passed variables.
    
    Add a missing variable to ksft_test_result_pass() inside
    error_report() so it matches other cases in the switch statement.
    
    Fixes: 2def297ec7fb ("pidfd: add tests for NSpid info in fdinfo")
    
    Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/resctrl: Ensure the benchmark commands fits to its array [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Sep 4 12:53:32 2023 +0300

    selftests/resctrl: Ensure the benchmark commands fits to its array
    
    [ Upstream commit 4a28c7665c2a1ac0400864eabb0c641e135f61aa ]
    
    Benchmark command is copied into an array in the stack. The array is
    BENCHMARK_ARGS items long but the command line could try to provide a
    longer command. Argument size is also fixed by BENCHMARK_ARG_SIZE (63
    bytes of space after fitting the terminating \0 character) and user
    could have inputted argument longer than that.
    
    Return error in case the benchmark command does not fit to the space
    allocated for it.
    
    Fixes: ecdbb911f22d ("selftests/resctrl: Add MBM test")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
    Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
    Reviewed-by: "Wieczor-Retman, Maciej" <maciej.wieczor-retman@intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/x86/lam: Zero out buffer for readlink() [+ + +]
Author: Binbin Wu <binbin.wu@linux.intel.com>
Date:   Mon Oct 16 14:24:46 2023 +0800

    selftests/x86/lam: Zero out buffer for readlink()
    
    [ Upstream commit 29060633411a02f6f2dd9d5245919385d69d81f0 ]
    
    Zero out the buffer for readlink() since readlink() does not append a
    terminating null byte to the buffer.  Also change the buffer length
    passed to readlink() to 'PATH_MAX - 1' to ensure the resulting string
    is always null terminated.
    
    Fixes: 833c12ce0f430 ("selftests/x86/lam: Add inherit test cases for linear-address masking")
    Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Link: https://lore.kernel.org/r/20231016062446.695-1-binbin.wu@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: fix wait_rm_addr/sf parameters [+ + +]
Author: Geliang Tang <geliang.tang@suse.com>
Date:   Wed Oct 25 16:37:03 2023 -0700

    selftests: mptcp: fix wait_rm_addr/sf parameters
    
    commit 9168ea02b898d3dde98b51e4bd3fb082bd438dab upstream.
    
    The second input parameter of 'wait_rm_addr/sf $1 1' is misused. If it's
    1, wait_rm_addr/sf will never break, and will loop ten times, then
    'wait_rm_addr/sf' equals to 'sleep 1'. This delay time is too long,
    which can sometimes make the tests fail.
    
    A better way to use wait_rm_addr/sf is to use rm_addr/sf_count to obtain
    the current value, and then pass into wait_rm_addr/sf.
    
    Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer")
    Cc: stable@vger.kernel.org
    Suggested-by: Matthieu Baerts <matttbe@kernel.org>
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-2-db8f25f798eb@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: netfilter: test for sctp collision processing in nf_conntrack [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Oct 3 13:17:54 2023 -0400

    selftests: netfilter: test for sctp collision processing in nf_conntrack
    
    [ Upstream commit cf791b22bef7d9352ff730a8727d3871942d6001 ]
    
    This patch adds a test case to reproduce the SCTP DATA chunk retransmission
    timeout issue caused by the improper SCTP collision processing in netfilter
    nf_conntrack_proto_sctp.
    
    In this test, client sends a INIT chunk, but the INIT_ACK replied from
    server is delayed until the server sends a INIT chunk to start a new
    connection from its side. After the connection is complete from server
    side, the delayed INIT_ACK arrives in nf_conntrack_proto_sctp.
    
    The delayed INIT_ACK should be dropped in nf_conntrack_proto_sctp instead
    of updating the vtag with the out-of-date init_tag, otherwise, the vtag
    in DATA chunks later sent by client don't match the vtag in the conntrack
    entry and the DATA chunks get dropped.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: c4eee56e14fe ("net: skb_find_text: Ignore patterns extending past 'to'")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: pmtu.sh: fix result checking [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Tue Oct 31 11:47:32 2023 +0800

    selftests: pmtu.sh: fix result checking
    
    [ Upstream commit 63e201916b27260218e528a2f8758be47f99bbf4 ]
    
    In the PMTU test, when all previous tests are skipped and the new test
    passes, the exit code is set to 0. However, the current check mistakenly
    treats this as an assignment, causing the check to pass every time.
    
    Consequently, regardless of how many tests have failed, if the latest test
    passes, the PMTU test will report a pass.
    
    Fixes: 2a9d3716b810 ("selftests: pmtu.sh: improve the test result processing")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sh: bios: Revive earlyprintk support [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Oct 19 11:46:43 2023 +0200

    sh: bios: Revive earlyprintk support
    
    [ Upstream commit 553f7ac78fbb41b2c93ab9b9d78e42274d27daa9 ]
    
    The SuperH BIOS earlyprintk code is protected by CONFIG_EARLY_PRINTK.
    However, when this protection was added, it was missed that SuperH no
    longer defines an EARLY_PRINTK config symbol since commit
    e76fe57447e88916 ("sh: Remove old early serial console code V2"), so
    BIOS earlyprintk can no longer be used.
    
    Fix this by reviving the EARLY_PRINTK config symbol.
    
    Fixes: d0380e6c3c0f6edb ("early_printk: consolidate random copies of identical code")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/c40972dfec3dcc6719808d5df388857360262878.1697708489.git.geert+renesas@glider.be
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: qcom: llcc: Handle a second device without data corruption [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Sep 26 10:32:29 2023 +0200

    soc: qcom: llcc: Handle a second device without data corruption
    
    [ Upstream commit f1a1bc8775b26345aba2be278118999e7f661d3d ]
    
    Usually there is only one llcc device. But if there were a second, even
    a failed probe call would modify the global drv_data pointer. So check
    if drv_data is valid before overwriting it.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Fixes: a3134fb09e0b ("drivers: soc: Add LLCC driver")
    Link: https://lore.kernel.org/r/20230926083229.2073890-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: qcom: pmic_glink: fix connector type to be DisplayPort [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Oct 11 01:52:29 2023 +0300

    soc: qcom: pmic_glink: fix connector type to be DisplayPort
    
    [ Upstream commit f86955f2b1ff9fbc7ae4f6595112b2f896885366 ]
    
    As it was pointed out by Simon Ser, the DRM_MODE_CONNECTOR_USB connector
    is reserved for the GUD devices. Other drivers (i915, amdgpu) use
    DRM_MODE_CONNECTOR_DisplayPort even if the DP stream is handled by the
    USB-C altmode. While we are still working on implementing the proper way
    to let userspace know that the DP is wrapped into USB-C, change
    connector type to be DRM_MODE_CONNECTOR_DisplayPort.
    
    Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support")
    Cc: Simon Ser <contact@emersion.fr>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Acked-by: Simon Ser <contact@emersion.fr>
    Link: https://lore.kernel.org/r/20231010225229.77027-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: nxp-fspi: use the correct ioremap function [+ + +]
Author: Han Xu <han.xu@nxp.com>
Date:   Tue Oct 10 15:15:24 2023 -0500

    spi: nxp-fspi: use the correct ioremap function
    
    [ Upstream commit c3aa5cb264a38ae9bbcce32abca4c155af0456df ]
    
    AHB memory as MMIO should be mapped with ioremap rather than ioremap_wc,
    which should have been used initially just to handle unaligned access as
    a workaround.
    
    Fixes: d166a73503ef ("spi: fspi: dynamically alloc AHB memory")
    Signed-off-by: Han Xu <han.xu@nxp.com>
    Link: https://lore.kernel.org/r/20231010201524.2021340-1-han.xu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: omap2-mcspi: Fix hardcoded reference clock [+ + +]
Author: Vaishnav Achath <vaishnav.a@ti.com>
Date:   Tue Sep 26 17:08:12 2023 +0530

    spi: omap2-mcspi: Fix hardcoded reference clock
    
    [ Upstream commit 2d9f4877988f64f0f336983de65c365b6a7debfb ]
    
    A hardcoded reference clock of 48 MHz is used to calculate the
    clock divisor values, but the reference clock frequency can be
    different across devices and can be configured which can cause
    a mismatch between the reported frequency and actual SPI clock
    frequency observed. Fix this by fetching the clock rate from
    the clock provider and falling back to hardcoded reference only
    if the clock is not supplied.
    
    Fixes: 2cd7d393f461 ("arm64: dts: ti: k3-am654: Add McSPI DT nodes")
    
    Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Link: https://lore.kernel.org/r/20230926113812.30692-1-vaishnav.a@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: omap2-mcspi: remove redundant dev_err_probe() [+ + +]
Author: Zhu Wang <wangzhu9@huawei.com>
Date:   Tue Aug 1 21:54:42 2023 +0800

    spi: omap2-mcspi: remove redundant dev_err_probe()
    
    [ Upstream commit 142c61a5fddeb755c420cb2e23b4bc0c0901308f ]
    
    When platform_get_irq() is called, the error message has been printed,
    so it need not to call dev_err_probe() to print error, we remove the
    redundant platform_get_irq().
    
    Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
    Link: https://lore.kernel.org/r/20230801135442.255604-1-wangzhu9@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 2d9f4877988f ("spi: omap2-mcspi: Fix hardcoded reference clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: omap2-mcspi: switch to use modern name [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Aug 23 11:30:03 2023 +0800

    spi: omap2-mcspi: switch to use modern name
    
    [ Upstream commit ee0f793cc1881225dee04216f1080201603b46bb ]
    
    Change legacy name master/slave to modern name host/target or controller.
    
    No functional changed.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20230823033003.3407403-22-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 2d9f4877988f ("spi: omap2-mcspi: Fix hardcoded reference clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies [+ + +]
Author: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Date:   Sat Nov 4 00:13:51 2023 +0530

    spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies
    
    [ Upstream commit c2ded280a4b1b7bd93e53670528504be08d24967 ]
    
    Zynq QSPI driver has been converted to use spi-mem framework so
    add spi-mem to driver kconfig dependencies.
    
    Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
    Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/1699037031-702858-1-git-send-email-radhey.shyam.pandey@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: tegra: Fix missing IRQ check in tegra_slink_probe() [+ + +]
Author: Zhang Shurong <zhang_shurong@foxmail.com>
Date:   Sat Aug 26 18:02:54 2023 +0800

    spi: tegra: Fix missing IRQ check in tegra_slink_probe()
    
    [ Upstream commit eb9913b511f10968a02cfa5329a896855dd152a3 ]
    
    This func misses checking for platform_get_irq()'s call and may passes the
    negative error codes to request_irq(), which takes unsigned IRQ #,
    causing it to fail with -EINVAL, overriding an original error code.
    
    Fix this by stop calling request_irq() with invalid IRQ #s.
    
    Fixes: dc4dc3605639 ("spi: tegra: add spi driver for SLINK controller")
    Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
    Reviewed-by: Helen Koike <helen.koike@collabora.com>
    Link: https://lore.kernel.org/r/tencent_73FCC06A3D1C14EE5175253C6FB46A07B709@qq.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
srcu: Fix callbacks acceleration mishandling [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Wed Oct 4 01:28:59 2023 +0200

    srcu: Fix callbacks acceleration mishandling
    
    [ Upstream commit 4a8e65b0c348e42107c64381e692e282900be361 ]
    
    SRCU callbacks acceleration might fail if the preceding callbacks
    advance also fails. This can happen when the following steps are met:
    
    1) The RCU_WAIT_TAIL segment has callbacks (say for gp_num 8) and the
       RCU_NEXT_READY_TAIL also has callbacks (say for gp_num 12).
    
    2) The grace period for RCU_WAIT_TAIL is observed as started but not yet
       completed so rcu_seq_current() returns 4 + SRCU_STATE_SCAN1 = 5.
    
    3) This value is passed to rcu_segcblist_advance() which can't move
       any segment forward and fails.
    
    4) srcu_gp_start_if_needed() still proceeds with callback acceleration.
       But then the call to rcu_seq_snap() observes the grace period for the
       RCU_WAIT_TAIL segment (gp_num 8) as completed and the subsequent one
       for the RCU_NEXT_READY_TAIL segment as started
       (ie: 8 + SRCU_STATE_SCAN1 = 9) so it returns a snapshot of the
       next grace period, which is 16.
    
    5) The value of 16 is passed to rcu_segcblist_accelerate() but the
       freshly enqueued callback in RCU_NEXT_TAIL can't move to
       RCU_NEXT_READY_TAIL which already has callbacks for a previous grace
       period (gp_num = 12). So acceleration fails.
    
    6) Note in all these steps, srcu_invoke_callbacks() hadn't had a chance
       to run srcu_invoke_callbacks().
    
    Then some very bad outcome may happen if the following happens:
    
    7) Some other CPU races and starts the grace period number 16 before the
       CPU handling previous steps had a chance. Therefore srcu_gp_start()
       isn't called on the latter sdp to fix the acceleration leak from
       previous steps with a new pair of call to advance/accelerate.
    
    8) The grace period 16 completes and srcu_invoke_callbacks() is finally
       called. All the callbacks from previous grace periods (8 and 12) are
       correctly advanced and executed but callbacks in RCU_NEXT_READY_TAIL
       still remain. Then rcu_segcblist_accelerate() is called with a
       snaphot of 20.
    
    9) Since nothing started the grace period number 20, callbacks stay
       unhandled.
    
    This has been reported in real load:
    
            [3144162.608392] INFO: task kworker/136:12:252684 blocked for more
            than 122 seconds.
            [3144162.615986]       Tainted: G           O  K   5.4.203-1-tlinux4-0011.1 #1
            [3144162.623053] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
            disables this message.
            [3144162.631162] kworker/136:12  D    0 252684      2 0x90004000
            [3144162.631189] Workqueue: kvm-irqfd-cleanup irqfd_shutdown [kvm]
            [3144162.631192] Call Trace:
            [3144162.631202]  __schedule+0x2ee/0x660
            [3144162.631206]  schedule+0x33/0xa0
            [3144162.631209]  schedule_timeout+0x1c4/0x340
            [3144162.631214]  ? update_load_avg+0x82/0x660
            [3144162.631217]  ? raw_spin_rq_lock_nested+0x1f/0x30
            [3144162.631218]  wait_for_completion+0x119/0x180
            [3144162.631220]  ? wake_up_q+0x80/0x80
            [3144162.631224]  __synchronize_srcu.part.19+0x81/0xb0
            [3144162.631226]  ? __bpf_trace_rcu_utilization+0x10/0x10
            [3144162.631227]  synchronize_srcu+0x5f/0xc0
            [3144162.631236]  irqfd_shutdown+0x3c/0xb0 [kvm]
            [3144162.631239]  ? __schedule+0x2f6/0x660
            [3144162.631243]  process_one_work+0x19a/0x3a0
            [3144162.631244]  worker_thread+0x37/0x3a0
            [3144162.631247]  kthread+0x117/0x140
            [3144162.631247]  ? process_one_work+0x3a0/0x3a0
            [3144162.631248]  ? __kthread_cancel_work+0x40/0x40
            [3144162.631250]  ret_from_fork+0x1f/0x30
    
    Fix this with taking the snapshot for acceleration _before_ the read
    of the current grace period number.
    
    The only side effect of this solution is that callbacks advancing happen
    then _after_ the full barrier in rcu_seq_snap(). This is not a problem
    because that barrier only cares about:
    
    1) Ordering accesses of the update side before call_srcu() so they don't
       bleed.
    2) See all the accesses prior to the grace period of the current gp_num
    
    The only things callbacks advancing need to be ordered against are
    carried by snp locking.
    
    Reported-by: Yong He <alexyonghe@tencent.com>
    Co-developed-by:: Yong He <alexyonghe@tencent.com>
    Signed-off-by: Yong He <alexyonghe@tencent.com>
    Co-developed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by:  Joel Fernandes (Google) <joel@joelfernandes.org>
    Co-developed-by: Neeraj upadhyay <Neeraj.Upadhyay@amd.com>
    Signed-off-by: Neeraj upadhyay <Neeraj.Upadhyay@amd.com>
    Link: http://lore.kernel.org/CANZk6aR+CqZaqmMWrC2eRRPY12qAZnDZLwLnHZbNi=xXMB401g@mail.gmail.com
    Fixes: da915ad5cf25 ("srcu: Parallelize callback handling")
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
string: Adjust strtomem() logic to allow for smaller sources [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Oct 18 10:53:58 2023 -0700

    string: Adjust strtomem() logic to allow for smaller sources
    
    [ Upstream commit 0e108725f6cc5b3be9e607f89c9fbcbb236367b7 ]
    
    Arnd noticed we have a case where a shorter source string is being copied
    into a destination byte array, but this results in a strnlen() call that
    exceeds the size of the source. This is seen with -Wstringop-overread:
    
    In file included from ../include/linux/uuid.h:11,
                     from ../include/linux/mod_devicetable.h:14,
                     from ../include/linux/cpufeature.h:12,
                     from ../arch/x86/coco/tdx/tdx.c:7:
    ../arch/x86/coco/tdx/tdx.c: In function 'tdx_panic.constprop':
    ../include/linux/string.h:284:9: error: 'strnlen' specified bound 64 exceeds source size 60 [-Werror=stringop-overread]
      284 |         memcpy_and_pad(dest, _dest_len, src, strnlen(src, _dest_len), pad); \
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../arch/x86/coco/tdx/tdx.c:124:9: note: in expansion of macro 'strtomem_pad'
      124 |         strtomem_pad(message.str, msg, '\0');
          |         ^~~~~~~~~~~~
    
    Use the smaller of the two buffer sizes when calling strnlen(). When
    src length is unknown (SIZE_MAX), it is adjusted to use dest length,
    which is what the original code did.
    
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: dfbafa70bde2 ("string: Introduce strtomem() and strtomem_pad()")
    Tested-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Andy Shevchenko <andy@kernel.org>
    Cc: linux-hardening@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: call tcp_try_undo_recovery when an RTOd TFO SYNACK is ACKed [+ + +]
Author: Aananth V <aananthv@google.com>
Date:   Thu Sep 14 14:36:20 2023 +0000

    tcp: call tcp_try_undo_recovery when an RTOd TFO SYNACK is ACKed
    
    [ Upstream commit e326578a21414738de45f77badd332fb00bd0f58 ]
    
    For passive TCP Fast Open sockets that had SYN/ACK timeout and did not
    send more data in SYN_RECV, upon receiving the final ACK in 3WHS, the
    congestion state may awkwardly stay in CA_Loss mode unless the CA state
    was undone due to TCP timestamp checks. However, if
    tcp_rcv_synrecv_state_fastopen() decides not to undo, then we should
    enter CA_Open, because at that point we have received an ACK covering
    the retransmitted SYNACKs. Currently, the icsk_ca_state is only set to
    CA_Open after we receive an ACK for a data-packet. This is because
    tcp_ack does not call tcp_fastretrans_alert (and tcp_process_loss) if
    !prior_packets
    
    Note that tcp_process_loss() calls tcp_try_undo_recovery(), so having
    tcp_rcv_synrecv_state_fastopen() decide that if we're in CA_Loss we
    should call tcp_try_undo_recovery() is consistent with that, and
    low risk.
    
    Fixes: dad8cea7add9 ("tcp: fix TFO SYNACK undo to avoid double-timestamp-undo")
    Signed-off-by: Aananth V <aananthv@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: fix cookie_init_timestamp() overflows [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Oct 20 12:57:37 2023 +0000

    tcp: fix cookie_init_timestamp() overflows
    
    [ Upstream commit 73ed8e03388d16c12fc577e5c700b58a29045a15 ]
    
    cookie_init_timestamp() is supposed to return a 64bit timestamp
    suitable for both TSval determination and setting of skb->tstamp.
    
    Unfortunately it uses 32bit fields and overflows after
    2^32 * 10^6 nsec (~49 days) of uptime.
    
    Generated TSval are still correct, but skb->tstamp might be set
    far away in the past, potentially confusing other layers.
    
    tcp_ns_to_ts() is changed to return a full 64bit value,
    ts and ts_now variables are changed to u64 type,
    and TSMASK is removed in favor of shifts operations.
    
    While we are at it, change this sequence:
                    ts >>= TSBITS;
                    ts--;
                    ts <<= TSBITS;
                    ts |= options;
    to:
                    ts -= (1UL << TSBITS);
    
    Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
    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>

 
tcp_metrics: add missing barriers on delete [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 22 22:03:53 2023 +0000

    tcp_metrics: add missing barriers on delete
    
    [ Upstream commit cbc3a153222805d65f821e10f4f78b6afce06f86 ]
    
    When removing an item from RCU protected list, we must prevent
    store-tearing, using rcu_assign_pointer() or WRITE_ONCE().
    
    Fixes: 04f721c671656 ("tcp_metrics: Rewrite tcp_metrics_flush_all")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp_metrics: do not create an entry from tcp_init_metrics() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 22 22:03:55 2023 +0000

    tcp_metrics: do not create an entry from tcp_init_metrics()
    
    [ Upstream commit a135798e6e200ecb2f864cecca6d257ba278370c ]
    
    tcp_init_metrics() only wants to get metrics if they were
    previously stored in the cache. Creating an entry is adding
    useless costs, especially when tcp_no_metrics_save is set.
    
    Fixes: 51c5d0c4b169 ("tcp: Maintain dynamic metrics in local cache.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp_metrics: properly set tp->snd_ssthresh in tcp_init_metrics() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 22 22:03:54 2023 +0000

    tcp_metrics: properly set tp->snd_ssthresh in tcp_init_metrics()
    
    [ Upstream commit 081480014a64a69d901f8ef1ffdd56d6085cf87e ]
    
    We need to set tp->snd_ssthresh to TCP_INFINITE_SSTHRESH
    in the case tcp_get_metrics() fails for some reason.
    
    Fixes: 9ad7c049f0f7 ("tcp: RFC2988bis + taking RTT sample from 3WHS for the passive open side")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tg3: power down device only on SYSTEM_POWER_OFF [+ + +]
Author: George Shuklin <george.shuklin@gmail.com>
Date:   Fri Nov 3 13:50:29 2023 +0200

    tg3: power down device only on SYSTEM_POWER_OFF
    
    [ Upstream commit 9fc3bc7643341dc5be7d269f3d3dbe441d8d7ac3 ]
    
    Dell R650xs servers hangs on reboot if tg3 driver calls
    tg3_power_down.
    
    This happens only if network adapters (BCM5720 for R650xs) were
    initialized using SNP (e.g. by booting ipxe.efi).
    
    The actual problem is on Dell side, but this fix allows servers
    to come back alive after reboot.
    
    Signed-off-by: George Shuklin <george.shuklin@gmail.com>
    Fixes: 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER")
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20231103115029.83273-1-george.shuklin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal/drivers/mediatek: Fix probe for THERMAL_V2 [+ + +]
Author: Markus Schneider-Pargmann <msp@baylibre.com>
Date:   Mon Sep 18 12:07:06 2023 +0200

    thermal/drivers/mediatek: Fix probe for THERMAL_V2
    
    [ Upstream commit 5055fadfa7e16f2427d5b3c40b2bf563ddfdab22 ]
    
    Fix the probe function to call mtk_thermal_release_periodic_ts for
    everything != MTK_THERMAL_V1. This was accidentally changed from V1
    to V2 in the original patch.
    
    Reported-by: Frank Wunderlich <frank-w@public-files.de>
    Closes: https://lore.kernel.org/lkml/B0B3775B-B8D1-4284-814F-4F41EC22F532@public-files.de/
    Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Closes: https://lore.kernel.org/lkml/07a569b9-e691-64ea-dd65-3b49842af33d@linaro.org/
    Fixes: 33140e668b10 ("thermal/drivers/mediatek: Control buffer enablement tweaks")
    Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230918100706.1229239-1-msp@baylibre.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal: core: Don't update trip points inside the hysteresis range [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Fri Sep 22 14:44:03 2023 -0400

    thermal: core: Don't update trip points inside the hysteresis range
    
    [ Upstream commit cf3986f8c01d355490d0ac6024391b989a9d1e9d ]
    
    When searching for the trip points that need to be set, the nearest
    higher trip point's temperature is used for the high trip, while the
    nearest lower trip point's temperature minus the hysteresis is used for
    the low trip. The issue with this logic is that when the current
    temperature is inside a trip point's hysteresis range, both high and low
    trips will come from the same trip point. As a consequence instability
    can still occur like this:
    * the temperature rises slightly and enters the hysteresis range of a
      trip point
    * polling happens and updates the trip points to the hysteresis range
    * the temperature falls slightly, exiting the hysteresis range, crossing
      the trip point and triggering an IRQ, the trip points are updated
    * repeat
    
    So even though the current hysteresis implementation prevents
    instability from happening due to IRQs triggering on the same
    temperature value, both ways, it doesn't prevent it from happening due
    to an IRQ on one way and polling on the other.
    
    To properly implement a hysteresis behavior, when inside the hysteresis
    range, don't update the trip points. This way, the previously set trip
    points will stay in effect, which will in a way remember the previous
    state (if the temperature signal came from above or below the range) and
    therefore have the right trip point already set.
    
    The exception is if there was no previous trip point set, in which case
    a previous state doesn't exist, and so it's sensible to allow the
    hysteresis range as trip points.
    
    The following logs show the current behavior when running on a real
    machine:
    
    [  202.524658] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 40000
       203.562817: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=36986 temp=37979
    [  203.562845] thermal thermal_zone0: new temperature boundaries: 37000 < x < 40000
       204.176059: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=37979 temp=40028
    [  204.176089] thermal thermal_zone0: new temperature boundaries: 37000 < x < 100000
       205.226813: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=40028 temp=38652
    [  205.226842] thermal thermal_zone0: new temperature boundaries: 37000 < x < 40000
    
    And with this patch applied:
    
    [  184.933415] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 40000
       185.981182: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=36986 temp=37872
       186.744685: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=37872 temp=40058
    [  186.744716] thermal thermal_zone0: new temperature boundaries: 37000 < x < 100000
       187.773284: thermal_temperature: thermal_zone=vpu0-thermal id=0 temp_prev=40058 temp=38698
    
    Fixes: 060c034a9741 ("thermal: Add support for hardware-tracked trip points")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal: core: prevent potential string overflow [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Oct 7 11:59:39 2023 +0300

    thermal: core: prevent potential string overflow
    
    [ Upstream commit c99626092efca3061b387043d4a7399bf75fbdd5 ]
    
    The dev->id value comes from ida_alloc() so it's a number between zero
    and INT_MAX.  If it's too high then these sprintf()s will overflow.
    
    Fixes: 203d3d4aa482 ("the generic thermal sysfs driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Mon Oct 30 16:55:40 2023 +0900

    tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
    
    [ Upstream commit 19b3f72a41a8751e26bffc093bb7e1cef29ad579 ]
    
    syzbot reported the following uninit-value access issue [1]:
    
    =====================================================
    BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
    BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
     strlen lib/string.c:418 [inline]
     strstr+0xb8/0x2f0 lib/string.c:756
     tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
     genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
     genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
     netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
     genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
     netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
     netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
     netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
     sock_sendmsg_nosec net/socket.c:730 [inline]
     sock_sendmsg net/socket.c:753 [inline]
     ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
     __sys_sendmsg net/socket.c:2624 [inline]
     __do_sys_sendmsg net/socket.c:2633 [inline]
     __se_sys_sendmsg net/socket.c:2631 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was created at:
     slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
     slab_alloc_node mm/slub.c:3478 [inline]
     kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
     kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
     __alloc_skb+0x318/0x740 net/core/skbuff.c:650
     alloc_skb include/linux/skbuff.h:1286 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
     netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
     sock_sendmsg_nosec net/socket.c:730 [inline]
     sock_sendmsg net/socket.c:753 [inline]
     ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
     __sys_sendmsg net/socket.c:2624 [inline]
     __do_sys_sendmsg net/socket.c:2633 [inline]
     __se_sys_sendmsg net/socket.c:2631 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    TIPC bearer-related names including link names must be null-terminated
    strings. If a link name which is not null-terminated is passed through
    netlink, strstr() and similar functions can cause buffer overrun. This
    causes the above issue.
    
    This patch changes the nla_policy for bearer-related names from NLA_STRING
    to NLA_NUL_STRING. This resolves the issue by ensuring that only
    null-terminated strings are accepted as bearer-related names.
    
    syzbot reported similar uninit-value issue related to bearer names [2]. The
    root cause of this issue is that a non-null-terminated bearer name was
    passed. This patch also resolved this issue.
    
    Fixes: 7be57fc69184 ("tipc: add link get/dump to new netlink api")
    Fixes: 0655f6a8635b ("tipc: add bearer disable/enable to new netlink api")
    Reported-and-tested-by: syzbot+5138ca807af9d2b42574@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=5138ca807af9d2b42574 [1]
    Reported-and-tested-by: syzbot+9425c47dccbcb4c17d51@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9425c47dccbcb4c17d51 [2]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20231030075540.3784537-1-syoshida@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tipc: Use size_add() in calls to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 13:16:26 2023 -0600

    tipc: Use size_add() in calls to struct_size()
    
    [ Upstream commit 2506a91734754de690869824fb0d1ac592ec1266 ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound,
    the protection that `struct_size()` adds against potential integer
    overflows is defeated. Fix this by hardening call to `struct_size()`
    with `size_add()`.
    
    Fixes: e034c6d23bc4 ("tipc: Use struct_size() helper")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tls: Use size_add() in call to struct_size() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Sep 15 13:12:38 2023 -0600

    tls: Use size_add() in call to struct_size()
    
    [ Upstream commit a2713257ee2be22827d7bc248302d408c91bfb95 ]
    
    If, for any reason, the open-coded arithmetic causes a wraparound,
    the protection that `struct_size()` adds against potential integer
    overflows is defeated. Fix this by hardening call to `struct_size()`
    with `size_add()`.
    
    Fixes: b89fec54fd61 ("tls: rx: wrap decrypt params in a struct")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/perf: Update call stack check in builtin-lock.c [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Tue Oct 3 14:51:13 2023 +0530

    tools/perf: Update call stack check in builtin-lock.c
    
    [ Upstream commit d7c9ae8d5d1be0c4156d1e20e4369a77b711a4cc ]
    
    The perf test named "kernel lock contention analysis test"
    fails in powerpc system with below error:
    
      [command]# ./perf test 81 -vv
       81: kernel lock contention analysis test                            :
       --- start ---
      test child forked, pid 2140
      Testing perf lock record and perf lock contention
      Testing perf lock contention --use-bpf
      [Skip] No BPF support
      Testing perf lock record and perf lock contention at the same time
      Testing perf lock contention --threads
      Testing perf lock contention --lock-addr
      Testing perf lock contention --type-filter (w/ spinlock)
      Testing perf lock contention --lock-filter (w/ tasklist_lock)
      Testing perf lock contention --callstack-filter (w/ unix_stream)
      [Fail] Recorded result should have a lock from unix_stream:
      test child finished with -1
       ---- end ----
      kernel lock contention analysis test: FAILED!
    
    The test is failing because we get an address entry with 0 in
    perf lock samples for powerpc, and code for lock contention
    option "--callstack-filter" will not check further entries after
    address 0.
    
    Below are some of the samples from test generated perf.data file, which
    have 0 address in the 2nd entry of callstack:
     --------
    sched-messaging    3409 [001]  7152.904029: lock:contention_begin: 0xc00000c80904ef00 (flags=SPIN)
            c0000000001e926c __traceiter_contention_begin+0x6c ([kernel.kallsyms])
                           0 [unknown] ([unknown])
            c000000000f8a178 native_queued_spin_lock_slowpath+0x1f8 ([kernel.kallsyms])
            c000000000f89f44 _raw_spin_lock_irqsave+0x84 ([kernel.kallsyms])
            c0000000001d9fd0 prepare_to_wait+0x50 ([kernel.kallsyms])
            c000000000c80f50 sock_alloc_send_pskb+0x1b0 ([kernel.kallsyms])
            c000000000e82298 unix_stream_sendmsg+0x2b8 ([kernel.kallsyms])
            c000000000c78980 sock_sendmsg+0x80 ([kernel.kallsyms])
    
    sched-messaging    3408 [005]  7152.904036: lock:contention_begin: 0xc00000c80904ef00 (flags=SPIN)
            c0000000001e926c __traceiter_contention_begin+0x6c ([kernel.kallsyms])
                           0 [unknown] ([unknown])
            c000000000f8a178 native_queued_spin_lock_slowpath+0x1f8 ([kernel.kallsyms])
            c000000000f89f44 _raw_spin_lock_irqsave+0x84 ([kernel.kallsyms])
            c0000000001d9fd0 prepare_to_wait+0x50 ([kernel.kallsyms])
            c000000000c80f50 sock_alloc_send_pskb+0x1b0 ([kernel.kallsyms])
            c000000000e82298 unix_stream_sendmsg+0x2b8 ([kernel.kallsyms])
            c000000000c78980 sock_sendmsg+0x80 ([kernel.kallsyms])
     --------
    
    Based on commit 20002ded4d93 ("perf_counter: powerpc: Add callchain support"),
    incase of powerpc, the callchain saved by kernel always includes first
    three entries as the NIP (next instruction pointer), LR (link register), and
    the contents of LR save area in the second stack frame. In certain scenarios
    its possible to have invalid kernel instruction addresses in either of LR or the
    second stack frame's LR. In that case, kernel will store the address as zer0.
    Hence, its possible to have 2nd or 3rd callstack entry as 0.
    
    As per the current code in match_callstack_filter function, we skip the callstack
    check incase we get 0 address. And hence the test case is failing in powerpc.
    
    Fix this issue by updating the check in match_callstack_filter function,
    to not skip callstack check if the 2nd or 3rd entry have 0 address
    for powerpc.
    
    Result in powerpc after patch changes:
    
      [command]# ./perf test 81 -vv
       81: kernel lock contention analysis test                            :
       --- start ---
      test child forked, pid 4570
      Testing perf lock record and perf lock contention
      Testing perf lock contention --use-bpf
      [Skip] No BPF support
      Testing perf lock record and perf lock contention at the same time
      Testing perf lock contention --threads
      Testing perf lock contention --lock-addr
      Testing perf lock contention --type-filter (w/ spinlock)
      Testing perf lock contention --lock-filter (w/ tasklist_lock)
      [Skip] Could not find 'tasklist_lock'
      Testing perf lock contention --callstack-filter (w/ unix_stream)
      Testing perf lock contention --callstack-filter with task aggregation
      Testing perf lock contention CSV output
      [Skip] No BPF support
      test child finished with 0
       ---- end ----
      kernel lock contention analysis test: Ok
    
    Fixes: ebab291641be ("perf lock contention: Support filters for different aggregation")
    Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>
    Tested-by: Disha Goel <disgoel@linux.ibm.com>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Cc: maddy@linux.ibm.com
    Cc: atrajeev@linux.vnet.ibm.com
    Link: https://lore.kernel.org/r/20231003092113.252380-1-kjain@linux.ibm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: iio: iio_generic_buffer ensure alignment [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Tue Oct 3 12:57:47 2023 +0300

    tools: iio: iio_generic_buffer ensure alignment
    
    [ Upstream commit 2d3dff577dd0ea8fe9637a13822f7603c4a881c8 ]
    
    The iio_generic_buffer can return garbage values when the total size of
    scan data is not a multiple of the largest element in the scan. This can be
    demonstrated by reading a scan, consisting, for example of one 4-byte and
    one 2-byte element, where the 4-byte element is first in the buffer.
    
    The IIO generic buffer code does not take into account the last two
    padding bytes that are needed to ensure that the 4-byte data for next
    scan is correctly aligned.
    
    Add the padding bytes required to align the next sample with the scan size.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Fixes: e58537ccce73 ("staging: iio: update example application.")
    Link: https://lore.kernel.org/r/ZRvlm4ktNLu+qmlf@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing/kprobes: Fix the order of argument descriptions [+ + +]
Author: Yujie Liu <yujie.liu@intel.com>
Date:   Tue Oct 31 12:13:05 2023 +0800

    tracing/kprobes: Fix the order of argument descriptions
    
    [ Upstream commit f032c53bea6d2057c14553832d846be2f151cfb2 ]
    
    The order of descriptions should be consistent with the argument list of
    the function, so "kretprobe" should be the second one.
    
    int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe,
                                     const char *name, const char *loc, ...)
    
    Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/
    
    Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions")
    Suggested-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Signed-off-by: Yujie Liu <yujie.liu@intel.com>
    Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: tty_jobctrl: fix pid memleak in disassociate_ctty() [+ + +]
Author: Yi Yang <yiyang13@huawei.com>
Date:   Thu Aug 31 10:33:29 2023 +0800

    tty: tty_jobctrl: fix pid memleak in disassociate_ctty()
    
    [ Upstream commit 11e7f27b79757b6586645d87b95d5b78375ecdfc ]
    
    There is a pid leakage:
    ------------------------------
    unreferenced object 0xffff88810c181940 (size 224):
      comm "sshd", pid 8191, jiffies 4294946950 (age 524.570s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de  .............N..
        ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
      backtrace:
        [<ffffffff814774e6>] kmem_cache_alloc+0x5c6/0x9b0
        [<ffffffff81177342>] alloc_pid+0x72/0x570
        [<ffffffff81140ac4>] copy_process+0x1374/0x2470
        [<ffffffff81141d77>] kernel_clone+0xb7/0x900
        [<ffffffff81142645>] __se_sys_clone+0x85/0xb0
        [<ffffffff8114269b>] __x64_sys_clone+0x2b/0x30
        [<ffffffff83965a72>] do_syscall_64+0x32/0x80
        [<ffffffff83a00085>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    It turns out that there is a race condition between disassociate_ctty() and
    tty_signal_session_leader(), which caused this leakage.
    
    The pid memleak is triggered by the following race:
    task[sshd]                     task[bash]
    -----------------------        -----------------------
                                   disassociate_ctty();
                                   spin_lock_irq(¤t->sighand->siglock);
                                   put_pid(current->signal->tty_old_pgrp);
                                   current->signal->tty_old_pgrp = NULL;
                                   tty = tty_kref_get(current->signal->tty);
                                   spin_unlock_irq(¤t->sighand->siglock);
    tty_vhangup();
    tty_lock(tty);
    ...
    tty_signal_session_leader();
    spin_lock_irq(&p->sighand->siglock);
    ...
    if (tty->ctrl.pgrp) //tty->ctrl.pgrp is not NULL
    p->signal->tty_old_pgrp = get_pid(tty->ctrl.pgrp); //An extra get
    spin_unlock_irq(&p->sighand->siglock);
    ...
    tty_unlock(tty);
                                   if (tty) {
                                       tty_lock(tty);
                                       ...
                                       put_pid(tty->ctrl.pgrp);
                                       tty->ctrl.pgrp = NULL; //It's too late
                                       ...
                                       tty_unlock(tty);
                                   }
    
    The issue is believed to be introduced by commit c8bcd9c5be24 ("tty:
    Fix ->session locking") who moves the unlock of siglock in
    disassociate_ctty() above "if (tty)", making a small window allowing
    tty_signal_session_leader() to kick in. It can be easily reproduced by
    adding a delay before "if (tty)" and at the entrance of
    tty_signal_session_leader().
    
    To fix this issue, we move "put_pid(current->signal->tty_old_pgrp)" after
    "tty->ctrl.pgrp = NULL".
    
    Fixes: c8bcd9c5be24 ("tty: Fix ->session locking")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Co-developed-by: GUO Zihua <guozihua@huawei.com>
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Link: https://lore.kernel.org/r/20230831023329.165737-1-yiyang13@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: add missing WRITE_ONCE() around up->encap_rcv [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:25 2023 +0000

    udp: add missing WRITE_ONCE() around up->encap_rcv
    
    [ Upstream commit 6d5a12eb91224d707f8691dccb40a5719fe5466d ]
    
    UDP_ENCAP_ESPINUDP_NON_IKE setsockopt() writes over up->encap_rcv
    while other cpus read it.
    
    Fixes: 067b207b281d ("[UDP]: Cleanup UDP encapsulation code")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: annotate data-races around udp->encap_type [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:28 2023 +0000

    udp: annotate data-races around udp->encap_type
    
    [ Upstream commit 70a36f571362a8de8b8c02d21ae524fc776287f2 ]
    
    syzbot/KCSAN complained about UDP_ENCAP_L2TPINUDP setsockopt() racing.
    
    Add READ_ONCE()/WRITE_ONCE() to document races on this lockless field.
    
    syzbot report was:
    BUG: KCSAN: data-race in udp_lib_setsockopt / udp_lib_setsockopt
    
    read-write to 0xffff8881083603fa of 1 bytes by task 16557 on cpu 0:
    udp_lib_setsockopt+0x682/0x6c0
    udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2779
    sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
    __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
    __do_sys_setsockopt net/socket.c:2274 [inline]
    __se_sys_setsockopt net/socket.c:2271 [inline]
    __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read-write to 0xffff8881083603fa of 1 bytes by task 16554 on cpu 1:
    udp_lib_setsockopt+0x682/0x6c0
    udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2779
    sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
    __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
    __do_sys_setsockopt net/socket.c:2274 [inline]
    __se_sys_setsockopt net/socket.c:2271 [inline]
    __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x01 -> 0x05
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 16554 Comm: syz-executor.5 Not tainted 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: introduce udp->udp_flags [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:21 2023 +0000

    udp: introduce udp->udp_flags
    
    [ Upstream commit 81b36803ac139827538ac5ce4028e750a3c53f53 ]
    
    According to syzbot, it is time to use proper atomic flags
    for various UDP flags.
    
    Add udp_flags field, and convert udp->corkflag to first
    bit in it.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: a0002127cd74 ("udp: move udp->no_check6_tx to udp->udp_flags")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: lockless UDP_ENCAP_L2TPINUDP / UDP_GRO [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:27 2023 +0000

    udp: lockless UDP_ENCAP_L2TPINUDP / UDP_GRO
    
    [ Upstream commit ac9a7f4ce5dda1472e8f44096f33066c6ec1a3b4 ]
    
    Move udp->encap_enabled to udp->udp_flags.
    
    Add udp_test_and_set_bit() helper to allow lockless
    udp_tunnel_encap_enable() implementation.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 70a36f571362 ("udp: annotate data-races around udp->encap_type")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: move udp->accept_udp_{l4|fraglist} to udp->udp_flags [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:26 2023 +0000

    udp: move udp->accept_udp_{l4|fraglist} to udp->udp_flags
    
    [ Upstream commit f5f52f0884a595ff99ab1a608643fe4025fca2d5 ]
    
    These are read locklessly, move them to udp_flags to fix data-races.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 70a36f571362 ("udp: annotate data-races around udp->encap_type")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: move udp->gro_enabled to udp->udp_flags [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:24 2023 +0000

    udp: move udp->gro_enabled to udp->udp_flags
    
    [ Upstream commit e1dc0615c6b08ef36414f08c011965b8fb56198b ]
    
    syzbot reported that udp->gro_enabled can be read locklessly.
    Use one atomic bit from udp->udp_flags.
    
    Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: move udp->no_check6_rx to udp->udp_flags [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:23 2023 +0000

    udp: move udp->no_check6_rx to udp->udp_flags
    
    [ Upstream commit bcbc1b1de884647aa0318bf74eb7f293d72a1e40 ]
    
    syzbot reported that udp->no_check6_rx can be read locklessly.
    Use one atomic bit from udp->udp_flags.
    
    Fixes: 1c19448c9ba6 ("net: Make enabling of zero UDP6 csums more restrictive")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: move udp->no_check6_tx to udp->udp_flags [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:22 2023 +0000

    udp: move udp->no_check6_tx to udp->udp_flags
    
    [ Upstream commit a0002127cd746fcaa182ad3386ef6931c37f3bda ]
    
    syzbot reported that udp->no_check6_tx can be read locklessly.
    Use one atomic bit from udp->udp_flags
    
    Fixes: 1c19448c9ba6 ("net: Make enabling of zero UDP6 csums more restrictive")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udplite: fix various data-races [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:30 2023 +0000

    udplite: fix various data-races
    
    [ Upstream commit 882af43a0fc37e26d85fb0df0c9edd3bed928de4 ]
    
    udp->pcflag, udp->pcslen and udp->pcrlen reads/writes are racy.
    
    Move udp->pcflag to udp->udp_flags for atomicity,
    and add READ_ONCE()/WRITE_ONCE() annotations for pcslen and pcrlen.
    
    Fixes: ba4e58eca8aa ("[NET]: Supporting UDP-Lite (RFC 3828) in Linux")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udplite: remove UDPLITE_BIT [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 12 09:17:29 2023 +0000

    udplite: remove UDPLITE_BIT
    
    [ Upstream commit 729549aa350c56a777bb342941ed4d69b6585769 ]
    
    This flag is set but never read, we can remove it.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 882af43a0fc3 ("udplite: fix various data-races")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: chipidea: Fix DMA overwrite for Tegra [+ + +]
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Thu Sep 28 23:06:03 2023 +0200

    usb: chipidea: Fix DMA overwrite for Tegra
    
    [ Upstream commit 7ab8716713c931ac79988f2592e1cf8b2e4fec1b ]
    
    Tegra USB controllers seem to issue DMA in full 32-bit words only and thus
    may overwrite unevenly-sized buffers.  One such occurrence is detected by
    SLUB when receiving a reply to a 1-byte buffer (below).  Fix this by
    allocating a bounce buffer also for buffers with sizes not a multiple of 4.
    
    =============================================================================
    BUG kmalloc-64 (Tainted: G    B             ): kmalloc Redzone overwritten
    -----------------------------------------------------------------------------
    
    0x8555cd02-0x8555cd03 @offset=3330. First byte 0x0 instead of 0xcc
    Allocated in usb_get_status+0x2b/0xac age=1 cpu=3 pid=41
     __kmem_cache_alloc_node+0x12f/0x1e4
     __kmalloc+0x33/0x8c
     usb_get_status+0x2b/0xac
     hub_probe+0x5e9/0xcec
     usb_probe_interface+0xbf/0x21c
     really_probe+0xa5/0x2c4
     __driver_probe_device+0x75/0x174
     driver_probe_device+0x31/0x94
     __device_attach_driver+0x65/0xc0
     bus_for_each_drv+0x4b/0x74
     __device_attach+0x69/0x120
     bus_probe_device+0x65/0x6c
     device_add+0x48b/0x5f8
     usb_set_configuration+0x37b/0x6b4
     usb_generic_driver_probe+0x37/0x68
     usb_probe_device+0x35/0xb4
    Slab 0xbf622b80 objects=21 used=18 fp=0x8555cdc0 flags=0x800(slab|zone=0)
    Object 0x8555cd00 @offset=3328 fp=0x00000000
    
    Redzone  8555ccc0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  8555ccd0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  8555cce0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  8555ccf0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   8555cd00: 01 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   8555cd10: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   8555cd20: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   8555cd30: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  8555cd40: cc cc cc cc                                      ....
    Padding  8555cd74: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
    CPU: 3 PID: 41 Comm: kworker/3:1 Tainted: G    B              6.6.0-rc1mq-00118-g59786f827ea1 #1115
    Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
    Workqueue: usb_hub_wq hub_event
    [<8010ca28>] (unwind_backtrace) from [<801090a5>] (show_stack+0x11/0x14)
    [<801090a5>] (show_stack) from [<805da2fb>] (dump_stack_lvl+0x4d/0x7c)
    [<805da2fb>] (dump_stack_lvl) from [<8026464f>] (check_bytes_and_report+0xb3/0xe4)
    [<8026464f>] (check_bytes_and_report) from [<802648e1>] (check_object+0x261/0x290)
    [<802648e1>] (check_object) from [<802671b1>] (free_to_partial_list+0x105/0x3f8)
    [<802671b1>] (free_to_partial_list) from [<80268613>] (__kmem_cache_free+0x103/0x128)
    [<80268613>] (__kmem_cache_free) from [<80425a67>] (usb_get_status+0x73/0xac)
    [<80425a67>] (usb_get_status) from [<80421b31>] (hub_probe+0x5e9/0xcec)
    [<80421b31>] (hub_probe) from [<80428bbb>] (usb_probe_interface+0xbf/0x21c)
    [<80428bbb>] (usb_probe_interface) from [<803ee13d>] (really_probe+0xa5/0x2c4)
    [<803ee13d>] (really_probe) from [<803ee3d1>] (__driver_probe_device+0x75/0x174)
    [<803ee3d1>] (__driver_probe_device) from [<803ee501>] (driver_probe_device+0x31/0x94)
    usb 1-1: device descriptor read/8, error -71
    
    Fixes: fc53d5279094 ("usb: chipidea: tegra: Support host mode")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/ef8466b834c1726f5404c95c3e192e90460146f8.1695934946.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: chipidea: Simplify Tegra DMA alignment code [+ + +]
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Thu Sep 28 23:06:03 2023 +0200

    usb: chipidea: Simplify Tegra DMA alignment code
    
    [ Upstream commit 2ae61a2562c0d1720545b0845829a65fb6a9c2c6 ]
    
    The USB host on Tegra3 works with 32-bit alignment. Previous code tried
    to align the buffer, but it did align the wrapper struct instead, so
    the buffer was at a constant offset of 8 bytes (two pointers) from
    expected alignment.  Since kmalloc() guarantees at least 8-byte
    alignment already, the alignment-extending is removed.
    
    Fixes: fc53d5279094 ("usb: chipidea: tegra: Support host mode")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/a0d917d492b1f91ee0019e68b8e8bca9c585393f.1695934946.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency [+ + +]
Author: Jia-Ju Bai <baijiaju@buaa.edu.cn>
Date:   Tue Sep 26 10:44:04 2023 +0800

    usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
    
    [ Upstream commit ef307bc6ef04e8c1ea843231db58e3afaafa9fa6 ]
    
    In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
    holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
    
        spin_lock_irqsave(&hsotg->lock, flags);
        ...
            if (!urb->hcpriv) {
                    dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
                    goto out;
            }
        rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
        ...
    out:
        spin_unlock_irqrestore(&hsotg->lock, flags);
    
    When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
    concurrently executed, the NULL check of "urb->hcpriv" can be executed
    before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
    in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
    pointer dereference.
    
    This possible bug is found by an experimental static analysis tool
    developed by myself. This tool analyzes the locking APIs to extract
    function pairs that can be concurrently executed, and then analyzes the
    instructions in the paired functions to identify possible concurrency
    bugs including data races and atomicity violations. The above possible
    bug is reported, when my tool analyzes the source code of Linux 6.5.
    
    To fix this possible bug, "urb->hcpriv = NULL" should be executed with
    holding the lock "hsotg->lock". After using this patch, my tool never
    reports the possible bug, with the kernelconfiguration allyesconfig for
    x86_64. Because I have no associated hardware, I cannot test the patch
    in runtime testing, and just verify it according to the code logic.
    
    Fixes: 33ad261aa62b ("usb: dwc2: host: spinlock urb_enqueue")
    Signed-off-by: Jia-Ju Bai <baijiaju@buaa.edu.cn>
    Link: https://lore.kernel.org/r/20230926024404.832096-1-baijiaju@buaa.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: host: xhci-plat: fix possible kernel oops while resuming [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Thu Oct 19 13:29:23 2023 +0300

    usb: host: xhci-plat: fix possible kernel oops while resuming
    
    [ Upstream commit a5f928db59519a15e82ecba4ae3e7cbf5a44715a ]
    
    If this driver enables the xHC clocks while resuming from sleep, it calls
    clk_prepare_enable() without checking for errors and blithely goes on to
    read/write the xHC's registers -- which, with the xHC not being clocked,
    at least on ARM32 usually causes an imprecise external abort exceptions
    which cause kernel oops.  Currently, the chips for which the driver does
    the clock dance on suspend/resume seem to be the Broadcom STB SoCs, based
    on ARM32 CPUs, as it seems...
    
    Found by Linux Verification Center (linuxtesting.org) with the Svace static
    analysis tool.
    
    Fixes: 8bd954c56197 ("usb: host: xhci-plat: suspend and resume clocks")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20231019102924.2797346-19-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: usbip: fix stub_dev hub disconnect [+ + +]
Author: Jonas Blixt <jonas.blixt@actia.se>
Date:   Thu Jun 15 11:28:10 2023 +0200

    USB: usbip: fix stub_dev hub disconnect
    
    [ Upstream commit 97475763484245916735a1aa9a3310a01d46b008 ]
    
    If a hub is disconnected that has device(s) that's attached to the usbip layer
    the disconnect function might fail because it tries to release the port
    on an already disconnected hub.
    
    Fixes: 6080cd0e9239 ("staging: usbip: claim ports used by shared devices")
    Signed-off-by: Jonas Blixt <jonas.blixt@actia.se>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20230615092810.1215490-1-jonas.blixt@actia.se
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfs: fix readahead(2) on block devices [+ + +]
Author: Reuben Hawkins <reubenhwk@gmail.com>
Date:   Mon Oct 2 20:57:04 2023 -0500

    vfs: fix readahead(2) on block devices
    
    [ Upstream commit 7116c0af4b8414b2f19fdb366eea213cbd9d91c2 ]
    
    Readahead was factored to call generic_fadvise.  That refactor added an
    S_ISREG restriction which broke readahead on block devices.
    
    In addition to S_ISREG, this change checks S_ISBLK to fix block device
    readahead.  There is no change in behavior with any file type besides block
    devices in this change.
    
    Fixes: 3d8f7615319b ("vfs: implement readahead(2) using POSIX_FADV_WILLNEED")
    Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
    Link: https://lore.kernel.org/r/20231003015704.2415-1-reubenhwk@gmail.com
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virt: sevguest: Fix passing a stack buffer as a scatterlist target [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Oct 10 12:53:33 2023 -0700

    virt: sevguest: Fix passing a stack buffer as a scatterlist target
    
    [ Upstream commit db10cb9b574675402bfd8fe1a31aafdd45b002df ]
    
    CONFIG_DEBUG_SG highlights that get_{report,ext_report,derived_key)()}
    are passing stack buffers as the @req_buf argument to
    handle_guest_request(), generating a Call Trace of the following form:
    
        WARNING: CPU: 0 PID: 1175 at include/linux/scatterlist.h:187 enc_dec_message+0x518/0x5b0 [sev_guest]
        [..]
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
        RIP: 0010:enc_dec_message+0x518/0x5b0 [sev_guest]
        Call Trace:
         <TASK>
        [..]
         handle_guest_request+0x135/0x520 [sev_guest]
         get_ext_report+0x1ec/0x3e0 [sev_guest]
         snp_guest_ioctl+0x157/0x200 [sev_guest]
    
    Note that the above Call Trace was with the DEBUG_SG BUG_ON()s converted
    to WARN_ON()s.
    
    This is benign as long as there are no hardware crypto accelerators
    loaded for the aead cipher, and no subsequent dma_map_sg() is performed
    on the scatterlist. However, sev-guest can not assume the presence of
    an aead accelerator nor can it assume that CONFIG_DEBUG_SG is disabled.
    
    Resolve this bug by allocating virt_addr_valid() memory, similar to the
    other buffers am @snp_dev instance carries, to marshal requests from
    user buffers to kernel buffers.
    
    Reported-by: Peter Gonda <pgonda@google.com>
    Closes: http://lore.kernel.org/r/CAMkAt6r2VPPMZ__SQfJse8qWsUyYW3AgYbOUVM0S_Vtk=KvkxQ@mail.gmail.com
    Fixes: fce96cf04430 ("virt: Add SEV-SNP guest driver")
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Dionna Glaze <dionnaglaze@google.com>
    Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
    Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_net: use u64_stats_t infra to avoid data-races [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 26 17:18:40 2023 +0000

    virtio_net: use u64_stats_t infra to avoid data-races
    
    [ Upstream commit 61217d8f6360437329af1b16b8bbd9143167718d ]
    
    syzbot reported a data-race in virtnet_poll / virtnet_stats [1]
    
    u64_stats_t infra has very nice accessors that must be used
    to avoid potential load-store tearing.
    
    [1]
    BUG: KCSAN: data-race in virtnet_poll / virtnet_stats
    
    read-write to 0xffff88810271b1a0 of 8 bytes by interrupt on cpu 0:
    virtnet_receive drivers/net/virtio_net.c:2102 [inline]
    virtnet_poll+0x6c8/0xb40 drivers/net/virtio_net.c:2148
    __napi_poll+0x60/0x3b0 net/core/dev.c:6527
    napi_poll net/core/dev.c:6594 [inline]
    net_rx_action+0x32b/0x750 net/core/dev.c:6727
    __do_softirq+0xc1/0x265 kernel/softirq.c:553
    invoke_softirq kernel/softirq.c:427 [inline]
    __irq_exit_rcu kernel/softirq.c:632 [inline]
    irq_exit_rcu+0x3b/0x90 kernel/softirq.c:644
    common_interrupt+0x7f/0x90 arch/x86/kernel/irq.c:247
    asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:636
    __sanitizer_cov_trace_const_cmp8+0x0/0x80 kernel/kcov.c:306
    jbd2_write_access_granted fs/jbd2/transaction.c:1174 [inline]
    jbd2_journal_get_write_access+0x94/0x1c0 fs/jbd2/transaction.c:1239
    __ext4_journal_get_write_access+0x154/0x3f0 fs/ext4/ext4_jbd2.c:241
    ext4_reserve_inode_write+0x14e/0x200 fs/ext4/inode.c:5745
    __ext4_mark_inode_dirty+0x8e/0x440 fs/ext4/inode.c:5919
    ext4_evict_inode+0xaf0/0xdc0 fs/ext4/inode.c:299
    evict+0x1aa/0x410 fs/inode.c:664
    iput_final fs/inode.c:1775 [inline]
    iput+0x42c/0x5b0 fs/inode.c:1801
    do_unlinkat+0x2b9/0x4f0 fs/namei.c:4405
    __do_sys_unlink fs/namei.c:4446 [inline]
    __se_sys_unlink fs/namei.c:4444 [inline]
    __x64_sys_unlink+0x30/0x40 fs/namei.c:4444
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88810271b1a0 of 8 bytes by task 2814 on cpu 1:
    virtnet_stats+0x1b3/0x340 drivers/net/virtio_net.c:2564
    dev_get_stats+0x6d/0x860 net/core/dev.c:10511
    rtnl_fill_stats+0x45/0x320 net/core/rtnetlink.c:1261
    rtnl_fill_ifinfo+0xd0e/0x1120 net/core/rtnetlink.c:1867
    rtnl_dump_ifinfo+0x7f9/0xc20 net/core/rtnetlink.c:2240
    netlink_dump+0x390/0x720 net/netlink/af_netlink.c:2266
    netlink_recvmsg+0x425/0x780 net/netlink/af_netlink.c:1992
    sock_recvmsg_nosec net/socket.c:1027 [inline]
    sock_recvmsg net/socket.c:1049 [inline]
    ____sys_recvmsg+0x156/0x310 net/socket.c:2760
    ___sys_recvmsg net/socket.c:2802 [inline]
    __sys_recvmsg+0x1ea/0x270 net/socket.c:2832
    __do_sys_recvmsg net/socket.c:2842 [inline]
    __se_sys_recvmsg net/socket.c:2839 [inline]
    __x64_sys_recvmsg+0x46/0x50 net/socket.c:2839
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x000000000045c334 -> 0x000000000045c376
    
    Fixes: 3fa2a1df9094 ("virtio-net: per cpu 64 bit stats (v2)")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vsock/virtio: remove socket from connected/bound list on shutdown [+ + +]
Author: Filippo Storniolo <f.storniolo95@gmail.com>
Date:   Fri Nov 3 18:55:48 2023 +0100

    vsock/virtio: remove socket from connected/bound list on shutdown
    
    [ Upstream commit 3a5cc90a4d1756072619fe511d07621bdef7f120 ]
    
    If the same remote peer, using the same port, tries to connect
    to a server on a listening port more than once, the server will
    reject the connection, causing a "connection reset by peer"
    error on the remote peer. This is due to the presence of a
    dangling socket from a previous connection in both the connected
    and bound socket lists.
    The inconsistency of the above lists only occurs when the remote
    peer disconnects and the server remains active.
    
    This bug does not occur when the server socket is closed:
    virtio_transport_release() will eventually schedule a call to
    virtio_transport_do_close() and the latter will remove the socket
    from the bound and connected socket lists and clear the sk_buff.
    
    However, virtio_transport_do_close() will only perform the above
    actions if it has been scheduled, and this will not happen
    if the server is processing the shutdown message from a remote peer.
    
    To fix this, introduce a call to vsock_remove_sock()
    when the server is handling a client disconnect.
    This is to remove the socket from the bound and connected socket
    lists without clearing the sk_buff.
    
    Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
    Reported-by: Daan De Meyer <daan.j.demeyer@gmail.com>
    Tested-by: Daan De Meyer <daan.j.demeyer@gmail.com>
    Co-developed-by: Luigi Leonardi <luigi.leonardi@outlook.com>
    Signed-off-by: Luigi Leonardi <luigi.leonardi@outlook.com>
    Signed-off-by: Filippo Storniolo <f.storniolo95@gmail.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
watchdog: ixp4xx: Make sure restart always works [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Sep 26 11:13:44 2023 +0200

    watchdog: ixp4xx: Make sure restart always works
    
    [ Upstream commit b4075ecfe348a44209534c75ad72392c63a489a6 ]
    
    The IXP4xx watchdog in early "A0" silicon is unreliable and
    cannot be registered, however for some systems such as the
    USRobotics USR8200 the watchdog is the only restart option,
    so implement a "dummy" watchdog that can only support restart
    in this case.
    
    Fixes: 1aea522809e6 ("watchdog: ixp4xx: Implement restart")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20230926-ixp4xx-wdt-restart-v2-1-15cf4639b423@linaro.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath11k: fix boot failure with one MSI vector [+ + +]
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Thu Sep 7 09:56:06 2023 +0800

    wifi: ath11k: fix boot failure with one MSI vector
    
    [ Upstream commit 39564b475ac5a589e6c22c43a08cbd283c295d2c ]
    
    Commit 5b32b6dd96633 ("ath11k: Remove core PCI references from
    PCI common code") breaks with one MSI vector because it moves
    affinity setting after IRQ request, see below log:
    
    [ 1417.278835] ath11k_pci 0000:02:00.0: failed to receive control response completion, polling..
    [ 1418.302829] ath11k_pci 0000:02:00.0: Service connect timeout
    [ 1418.302833] ath11k_pci 0000:02:00.0: failed to connect to HTT: -110
    [ 1418.303669] ath11k_pci 0000:02:00.0: failed to start core: -110
    
    The detail is, if do affinity request after IRQ activated,
    which is done in request_irq(), kernel caches that request and
    returns success directly. Later when a subsequent MHI interrupt is
    fired, kernel will do the real affinity setting work, as a result,
    changs the MSI vector. However at that time host has configured
    old vector to hardware, so host never receives CE or DP interrupts.
    
    Fix it by setting affinity before registering MHI controller
    where host is, for the first time, doing IRQ request.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
    Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
    Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01160-QCAMSLSWPLZ-1
    
    Fixes: 5b32b6dd9663 ("ath11k: Remove core PCI references from PCI common code")
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20230907015606.16297-1-quic_bqiang@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath11k: fix Tx power value during active CAC [+ + +]
Author: Aditya Kumar Singh <quic_adisi@quicinc.com>
Date:   Tue Oct 3 17:26:54 2023 +0300

    wifi: ath11k: fix Tx power value during active CAC
    
    [ Upstream commit 77f1ee6fd8b6e470f721d05a2e269039d5cafcb7 ]
    
    Tx power is fetched from firmware's pdev stats. However, during active
    CAC, firmware does not fill the current Tx power and sends the max
    initialised value filled during firmware init. If host sends this power
    to user space, this is wrong since in certain situations, the Tx power
    could be greater than the max allowed by the regulatory. Hence, host
    should not be fetching the Tx power during an active CAC.
    
    Fix this issue by returning -EAGAIN error so that user space knows that there's
    no valid value available.
    
    Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
    
    Fixes: 9a2aa68afe3d ("wifi: ath11k: add get_txpower mac ops")
    Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20230912051857.2284-4-quic_adisi@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath12k: fix DMA unmap warning on NULL DMA address [+ + +]
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Wed Sep 20 16:43:42 2023 +0300

    wifi: ath12k: fix DMA unmap warning on NULL DMA address
    
    [ Upstream commit 9ae8c496d211155a3f220b63da364fba1a794292 ]
    
    In ath12k_dp_tx(), if we reach fail_dma_unmap due to some errors,
    current code does DMA unmap unconditionally on skb_cb->paddr_ext_desc.
    However, skb_cb->paddr_ext_desc may be NULL and thus we get below
    warning:
    
    kernel: [ 8887.076212] WARNING: CPU: 3 PID: 0 at drivers/iommu/dma-iommu.c:1077 iommu_dma_unmap_page+0x79/0x90
    
    Fix it by checking skb_cb->paddr_ext_desc before unmap it.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20230830021131.5610-1-quic_bqiang@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath12k: fix undefined behavior with __fls in dp [+ + +]
Author: Harshitha Prem <quic_hprem@quicinc.com>
Date:   Sat Aug 26 08:42:44 2023 +0300

    wifi: ath12k: fix undefined behavior with __fls in dp
    
    [ Upstream commit d48f55e773dcce8fcf9e587073452a4944011b11 ]
    
    When max virtual ap interfaces are configured in all the bands
    with ACS and hostapd restart is done every 60s,
    a crash is observed at random times because of handling the
    uninitialized peer fragments with fragment id of packet as 0.
    
    "__fls" would have an undefined behavior if the argument is passed
    as "0". Hence, added changes to handle the same.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20230821130343.29495-3-quic_hprem@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath: dfs_pattern_detector: Fix a memory initialization issue [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Sep 30 07:54:47 2023 +0300

    wifi: ath: dfs_pattern_detector: Fix a memory initialization issue
    
    [ Upstream commit 79bd60ee87e1136718a686d6617ced5de88ee350 ]
    
    If an error occurs and channel_detector_exit() is called, it relies on
    entries of the 'detectors' array to be NULL.
    Otherwise, it may access to un-initialized memory.
    
    Fix it and initialize the memory, as what was done before the commit in
    Fixes.
    
    Fixes: a063b650ce5d ("ath: dfs_pattern_detector: Avoid open coded arithmetic in memory allocation")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/ad8c55b97ee4b330cb053ce2c448123c309cc91c.1695538105.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: add flush functions for wiphy work [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:33 2023 +0200

    wifi: cfg80211: add flush functions for wiphy work
    
    [ Upstream commit 56cfb8ce1f7f6c4e5ca571a2ec0880e131cd0311 ]
    
    There may be sometimes reasons to actually run the work
    if it's pending, add flush functions for both regular and
    delayed wiphy work that will do this.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: eadfb54756ae ("wifi: mac80211: move sched-scan stop work to wiphy work")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: fix kernel-doc for wiphy_delayed_work_flush() [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Sep 13 09:34:25 2023 +0200

    wifi: cfg80211: fix kernel-doc for wiphy_delayed_work_flush()
    
    [ Upstream commit 8c73d5248dcf112611654bcd32352dc330b02397 ]
    
    Clearly, there's no space in the function name, not sure how
    that could've happened. Put the underscore that it should be.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Fixes: 56cfb8ce1f7f ("wifi: cfg80211: add flush functions for wiphy work")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: fix off-by-one in element defrag [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Aug 27 14:05:19 2023 +0300

    wifi: cfg80211: fix off-by-one in element defrag
    
    [ Upstream commit 43125539fc69c6aa63d34b516939431391bddeac ]
    
    If a fragment is the last element, it's erroneously not
    accepted. Fix that.
    
    Fixes: f837a653a097 ("wifi: cfg80211: add element defragmentation helper")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230827135854.adca9fbd3317.I6b2df45eb71513f3e48efd196ae3cddec362dc1c@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: don't use an uninitialized variable [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Wed Aug 30 11:30:54 2023 +0300

    wifi: iwlwifi: don't use an uninitialized variable
    
    [ Upstream commit c46fcc6e43d617252945e706f04e5f82a59f2b8e ]
    
    Don't use variable err uninitialized.
    The reason for removing the check instead of initializing it
    in the beginning of the function is because that way
    static checkers will be able to catch issues if we do something
    wrong in the future.
    
    Fixes: bf976c814c86 ("wifi: iwlwifi: mvm: implement link change ops")
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230830112059.431b01bd8779.I31fc4ab35f551b85a10f974a6b18fc30191e9c35@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: empty overflow queue during flush [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Sun Oct 22 17:55:51 2023 +0300

    wifi: iwlwifi: empty overflow queue during flush
    
    [ Upstream commit 658939fc68d3241f9a0019e224cd7154438c23f2 ]
    
    If a TX queue has no space for new TX frames, the driver will keep
    these frames in the overflow queue, and during reclaim flow it
    will retry to send the frames from that queue.
    But if the reclaim flow was invoked from TX queue flush, we will also
    TX these frames, which is wrong as we don't want to TX anything
    after flush.
    This might also cause assert 0x125F when removing the queue,
    saying that the driver removes a non-empty queue
    Fix this by TXing the overflow queue's frames only if we are
    not in flush queue flow.
    
    Fixes: a44509805895 ("iwlwifi: move reclaim flows to the queue file")
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231022173519.caf06c8709d9.Ibf664ccb3f952e836f8fa461ea58fc08e5c46e88@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: honor the enable_ini value [+ + +]
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed Aug 30 11:30:52 2023 +0300

    wifi: iwlwifi: honor the enable_ini value
    
    [ Upstream commit e0c1ca236e28e4263fba76d47a108ed95dcae33e ]
    
    In case the user sets the enable_ini to some preset, we want to honor
    the value.
    
    Remove the ops to set the value of the module parameter is runtime, we
    don't want to allow to modify the value in runtime since we configure
    the firmware once at the beginning on its life.
    
    Fixes: b49c2b252b58 ("iwlwifi: Configure FW debug preset via module param.")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230830112059.5734e0f374bb.I6698eda8ed2112378dd47ac5d62866ebe7a94f77@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: increase number of RX buffers for EHT devices [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Aug 30 11:31:04 2023 +0300

    wifi: iwlwifi: increase number of RX buffers for EHT devices
    
    [ Upstream commit 2cf254c1e24fa8f01f42f5a8c77617e56bf50b86 ]
    
    EHT devices can support 512 MPDUs in an A-MPDU, each of
    which might be an A-MSDU and thus further contain multiple
    MSDUs, which need their own buffer each. Increase the number
    of buffers to avoid running out in high-throughput scenarios.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230830112059.824e522927f1.Ie5b4a2d3953072b9d76054ae67e2e45900d6bba4@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 08365d3b9140 ("wifi: iwlwifi: mvm: fix netif csum flags")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: change iwl_mvm_flush_sta() API [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 11 13:07:28 2023 +0300

    wifi: iwlwifi: mvm: change iwl_mvm_flush_sta() API
    
    [ Upstream commit 391762969769b089c808defc8fce5544a945f9eb ]
    
    This API is type unsafe and needs an extra parameter to know
    what kind of station was passed, so it has two, but really it
    only needs two values. Just pass the values instead of doing
    this type-unsafe dance, which will also make it better to use
    for multi-link.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231011130030.aeb3bf4204cd.I5b0e6d64a67455784bc8fbdaf9ceaf03699d9ce1@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 43874283ce6c ("wifi: iwlwifi: mvm: fix iwl_mvm_mac_flush_sta()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: Correctly set link configuration [+ + +]
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Wed Oct 4 12:36:34 2023 +0300

    wifi: iwlwifi: mvm: Correctly set link configuration
    
    [ Upstream commit 35b9281fb710ea9fa47dca56774f4a9606fe9154 ]
    
    In case the link puncturing is changed such that the channel
    is no longer punctured, configure the FW correctly indicating
    the EHT parameters changed (with a 0 punctured map).
    
    Allow EHT parameters configuration only when the link really
    supports EHT.
    
    Fixes: 55eb1c5fa4b2 ("wifi: iwlwifi: mvm: add support for the new LINK command")
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231004123422.2666ef86e032.I4b0e95722660acc5345ceefba7e8866a69572e8e@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: Don't always bind/link the P2P Device interface [+ + +]
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Wed Oct 4 12:36:30 2023 +0300

    wifi: iwlwifi: mvm: Don't always bind/link the P2P Device interface
    
    [ Upstream commit 84ef7cbe90e9e54c71c1da4e645ba34e1b33da77 ]
    
    It is not necessary to keep the P2P Device bound/linked to a PHY
    context when there is no active ROC.
    
    Modify the P2P Device flows so the binding/linking would be done
    only while ROC is active. With this change the switch_phy_ctxt()
    is no longer needed so remove it.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231004123422.c5b83b4bf9de.Ia80daf3ba0b5fec7d0919247fcbdbdb58bddf02b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 43874283ce6c ("wifi: iwlwifi: mvm: fix iwl_mvm_mac_flush_sta()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: fix iwl_mvm_mac_flush_sta() [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 11 13:07:29 2023 +0300

    wifi: iwlwifi: mvm: fix iwl_mvm_mac_flush_sta()
    
    [ Upstream commit 43874283ce6c5bd32ac9d30878b2c96a974357cb ]
    
    When I implemented iwl_mvm_mac_flush_sta() I completely botched it;
    it basically always happens after the iwl_mvm_sta_pre_rcu_remove()
    call, and that already clears mvm->fw_id_to_mac_id[] entries, so we
    cannot rely on those at iwl_mvm_mac_flush_sta() time. This means it
    never did anything.
    
    Fix this by just going through the station IDs and now with the new
    API for iwl_mvm_flush_sta(), call those.
    
    Fixes: a6cc6ccb1c8a ("wifi: iwlwifi: mvm: support new flush_sta method")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231011130030.0b5878e93118.I1093e60163052e7be64d2b01424097cd6a272979@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: Fix key flags for IGTK on AP interface [+ + +]
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Wed Oct 11 13:07:20 2023 +0300

    wifi: iwlwifi: mvm: Fix key flags for IGTK on AP interface
    
    [ Upstream commit 8f9a791a8edd87fa64b35037d9c3bce89a1b8d21 ]
    
    When an IGTK is installed for an AP interface, there is no station
    associated with it. However, the MFP flag must be set for the installed
    key as otherwise the FW wouldn't use it.
    
    Fix the security key flag to set the MFP flag also when the AP is
    an AP interface and the key index matches that of an IGTK.
    
    Fixes: 5c75a208c244 ("wifi: iwlwifi: mvm: support new key API")
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231011130030.f67005e2d4d2.I6832c6e87f3c79fff00689eb10a3a30810e1ee83@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: fix netif csum flags [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Oct 17 12:16:41 2023 +0300

    wifi: iwlwifi: mvm: fix netif csum flags
    
    [ Upstream commit 08365d3b9140c751a84f8027ac7d2e662958f768 ]
    
    We shouldn't advertise arbitrary checksum flags since we had
    to remove support for it due to broken hardware.
    
    Fixes: ec18e7d4d20d ("wifi: iwlwifi: mvm: use old checksum for Bz A-step")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231017115047.e37327f1a129.Iaee86b00db4db791cd90adaf15384b8c87d2ad49@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: fix removing pasn station for responder [+ + +]
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Tue Sep 26 11:07:18 2023 +0300

    wifi: iwlwifi: mvm: fix removing pasn station for responder
    
    [ Upstream commit ff2687612c21a87a58c76099f3d59f8db376b995 ]
    
    In case of MLD operation the station should be removed using the
    mld api.
    
    Fixes: fd940de72d49 ("wifi: iwlwifi: mvm: FTM responder MLO support")
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230926110319.7eb353abb95c.I2b30be09b99f5a2379956e010bafaa465ff053ba@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: remove TDLS stations from FW [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 11 13:07:30 2023 +0300

    wifi: iwlwifi: mvm: remove TDLS stations from FW
    
    [ Upstream commit 7b404c5cff3d4270fcd5212b6776c8484623ac74 ]
    
    When we remove TDLS stations, we need to remove them from FW
    immediately, even while associated. Some previous refactoring
    here lost the sta ID condition, add it back.
    
    Fixes: 57974a55d995 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231011130030.933011e710a9.I77c069c781e8b2b698b86cc3f43fc3c7e2dde114@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: update IGTK in mvmvif upon D3 resume [+ + +]
Author: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Date:   Tue Oct 17 12:16:48 2023 +0300

    wifi: iwlwifi: mvm: update IGTK in mvmvif upon D3 resume
    
    [ Upstream commit ac0c6fdc4c56b669abc1c4a323f1c7a3a1422dd2 ]
    
    During the D3 resume flow, all new rekeys are passed from the FW.
    Because the FW supports only one IGTK at a time, every IGTK rekey
    update should be done by removing the last IGTK. The mvmvif holds a
    pointer to the last IGTK for that reason and thus should be updated
    when a new IGTK is passed upon resume.
    
    Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow")
    Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231017115047.8ceaf7e5ece7.Ief444f6a2703ed76648b4d414f12bb4130bab36e@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: update station's MFP flag after association [+ + +]
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Tue Sep 26 11:07:13 2023 +0300

    wifi: iwlwifi: mvm: update station's MFP flag after association
    
    [ Upstream commit 5a86dcb4a908845e6b7ff39b78fb1141b895408f ]
    
    The management frames protection flag is always set when the station
    is not yet authorized. However, it was not cleared after association
    even if the association did not use MFP. As a result, all public
    action frames are not parsed by fw (which will cause FTM to fail,
    for example). Update the station MFP flag after the station is
    authorized.
    
    Fixes: 4c8d5c8d079e ("wifi: iwlwifi: mvm: tell firmware about per-STA MFP enablement")
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230926110319.2488cbd01bde.Ic0f08b7d3efcbdce27ec897f84d740fec8d169ef@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: use correct sta ID for IGTK/BIGTK [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Sep 26 11:07:20 2023 +0300

    wifi: iwlwifi: mvm: use correct sta ID for IGTK/BIGTK
    
    [ Upstream commit 63ef576c9facf5d92702e249ad213fa73eb434bf ]
    
    We don't (yet) send the IGTK down to the firmware, but when
    we do it needs to be with the broadcast station ID, not the
    multicast station ID. Same for the BIGTK, which we may send
    already if firmware advertises it (but it doesn't yet.)
    
    Fixes: a5de7de7e78e ("wifi: iwlwifi: mvm: enable TX beacon protection")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230926110319.dbc653913353.I82e90c86010f0b9588a180d9835fd11f666f5196@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: pcie: synchronize IRQs before NAPI [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Oct 17 12:16:43 2023 +0300

    wifi: iwlwifi: pcie: synchronize IRQs before NAPI
    
    [ Upstream commit 37fb29bd1f90f16d1abc95c0e9f0ff8eec9829ad ]
    
    When we want to synchronize the NAPI, which was added in
    commit 5af2bb3168db ("wifi: iwlwifi: call napi_synchronize()
    before freeing rx/tx queues"), we also need to make sure we
    can't actually reschedule the NAPI. Yes, this happens while
    interrupts are disabled, but interrupts may still be running
    or pending. Also call iwl_pcie_synchronize_irqs() to ensure
    we won't reschedule the NAPI.
    
    Fixes: 4cf2f5904d97 ("iwlwifi: queue: avoid memory leak in reset flow")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231017115047.a0f4104b479a.Id5c50a944f709092aa6256e32d8c63b2b8d8d3ac@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: yoyo: swap cdb and jacket bits values [+ + +]
Author: Rotem Saado <rotem.saado@intel.com>
Date:   Wed Oct 4 12:36:22 2023 +0300

    wifi: iwlwifi: yoyo: swap cdb and jacket bits values
    
    [ Upstream commit 65008777b9dcd2002414ddb2c2158293a6e2fd6f ]
    
    The bits are wrong, the jacket bit should be 5 and cdb bit 4.
    Fix it.
    
    Fixes: 1f171f4f1437 ("iwlwifi: Add support for getting rf id with blank otp")
    Signed-off-by: Rotem Saado <rotem.saado@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231004123422.356d8dacda2f.I349ab888b43a11baa2453a1d6978a6a703e422f0@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: don't recreate driver link debugfs in reconfig [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Sep 28 17:35:24 2023 +0300

    wifi: mac80211: don't recreate driver link debugfs in reconfig
    
    [ Upstream commit 822cab1987a0e028e38b60aecd98af0289b46e7b ]
    
    We can delete any that we want to remove, but we can't
    recreate the links as they already exist.
    
    Fixes: 170cd6a66d9a ("wifi: mac80211: add netdev per-link debugfs data and driver hook")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230928172905.3d0214838421.I512a0ff86f631ff42bf25ea0cb2e8e8616794a94@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix # of MSDU in A-MSDU calculation [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Aug 27 14:05:28 2023 +0300

    wifi: mac80211: fix # of MSDU in A-MSDU calculation
    
    [ Upstream commit 428e8976a15f849ad92b1c1e38dda2a684350ff7 ]
    
    During my refactoring I wanted to get rid of the switch,
    but replaced it with the wrong calculation. Fix that.
    
    Fixes: 175ad2ec89fe ("wifi: mac80211: limit A-MSDU subframes for client too")
    Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230827135854.51bf1b8b0adb.Iffbd337fdad2b86ae12f5a39c69fb82b517f7486@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix check for unusable RX result [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 25 17:24:39 2023 +0200

    wifi: mac80211: fix check for unusable RX result
    
    [ Upstream commit 583058542f46e3e2b0c536316fbd641f62d91dc6 ]
    
    If we just check "result & RX_DROP_UNUSABLE", this really only works
    by accident, because SKB_DROP_REASON_SUBSYS_MAC80211_UNUSABLE got to
    have the value 1, and SKB_DROP_REASON_SUBSYS_MAC80211_MONITOR is 2.
    
    Fix this to really check the entire subsys mask for the value, so it
    doesn't matter what the subsystem value is.
    
    Fixes: 7f4e09700bdc ("wifi: mac80211: report all unusable beacon frames")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix RCU usage warning in mesh fast-xmit [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 11 11:57:52 2023 +0200

    wifi: mac80211: fix RCU usage warning in mesh fast-xmit
    
    [ Upstream commit 5ea82df1f50e42416d0a8a7c42d37cc1df1545fe ]
    
    In mesh_fast_tx_flush_addr() we already hold the lock, so
    don't need additional hashtable RCU protection. Use the
    rhashtable_lookup_fast() variant to avoid RCU protection
    warnings.
    
    Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: Fix setting vif links [+ + +]
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Thu Sep 28 17:35:31 2023 +0300

    wifi: mac80211: Fix setting vif links
    
    [ Upstream commit e7182c4e6bbeafa272612e6c06fa92b42ad107ad ]
    
    When setting the interface links, ignore the change iff both the
    valid links and the dormant links did not change. This is needed
    to support cases where the valid links didn't change but the dormant
    links did.
    
    Fixes: 6d543b34dbcf ("wifi: mac80211: Support disabled links during association")
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230928172905.0357b6306587.I7dbfec347949b629fea680d246a650d6207ff217@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: move offchannel works to wiphy work [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:42 2023 +0200

    wifi: mac80211: move offchannel works to wiphy work
    
    [ Upstream commit 97c19e42b264e6b71a9ff9deea04c19f621805b9 ]
    
    Make the offchannel works wiphy works to have the
    wiphy locked for executing them.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: eadfb54756ae ("wifi: mac80211: move sched-scan stop work to wiphy work")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: move radar detect work to wiphy work [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:38 2023 +0200

    wifi: mac80211: move radar detect work to wiphy work
    
    [ Upstream commit 228e4f931b0e630dacca8dd867ddd863aea53913 ]
    
    Move the radar detect work to wiphy work in order
    to lock the wiphy for it without doing it manually.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: eadfb54756ae ("wifi: mac80211: move sched-scan stop work to wiphy work")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: move scan work to wiphy work [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:39 2023 +0200

    wifi: mac80211: move scan work to wiphy work
    
    [ Upstream commit 201712512cbbda360f62c222a4bab260350462a0 ]
    
    Move the scan work to wiphy work, which also simplifies
    the way we handle the work vs. the scan configuration.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: eadfb54756ae ("wifi: mac80211: move sched-scan stop work to wiphy work")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: move sched-scan stop work to wiphy work [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:45 2023 +0200

    wifi: mac80211: move sched-scan stop work to wiphy work
    
    [ Upstream commit eadfb54756aea5610d8d0a467f66305f777c85dd ]
    
    This also has the wiphy locked here then. We need to use
    the _locked version of cfg80211_sched_scan_stopped() now,
    which also fixes an old deadlock there.
    
    Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver")
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: connac: move connac3 definitions in mt76_connac3_mac.h [+ + +]
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Thu Jun 22 18:50:31 2023 +0200

    wifi: mt76: connac: move connac3 definitions in mt76_connac3_mac.h
    
    [ Upstream commit 4e9011fcdfc4f325df1661e600a0dcd9064c2bd9 ]
    
    Connac3 mac definitions are shared between WiFi7 chipsets so move them in
    mt76_connac3_mac.h
    
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: bde2e77f7626 ("wifi: mt76: mt7996: set correct wcid in txp")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: fix per-band IEEE80211_CONF_MONITOR flag comparison [+ + +]
Author: Shayne Chen <shayne.chen@mediatek.com>
Date:   Thu Aug 31 14:22:18 2023 +0800

    wifi: mt76: fix per-band IEEE80211_CONF_MONITOR flag comparison
    
    [ Upstream commit c685034cabc574dbdf16fa675010e202083cb4c2 ]
    
    Use the correct ieee80211_conf of each band for IEEE80211_CONF_MONITOR
    comparison.
    
    Fixes: 24e69f6bc3ca ("mt76: fix monitor rx FCS error in DFS channel")
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: fix potential memory leak of beacon commands [+ + +]
Author: Bo Jiao <Bo.Jiao@mediatek.com>
Date:   Thu Aug 31 14:22:16 2023 +0800

    wifi: mt76: fix potential memory leak of beacon commands
    
    [ Upstream commit d6a2f91741d9f43b31cb16c82da37f35117a6d1c ]
    
    Fix potential memory leak when setting beacon and inband discovery
    commands.
    
    Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: get rid of false alamrs of tx emission issues [+ + +]
Author: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Date:   Thu Aug 31 14:22:17 2023 +0800

    wifi: mt76: get rid of false alamrs of tx emission issues
    
    [ Upstream commit 413f05d68d11981f5984b49214d3a5a0d88079b1 ]
    
    When the set_chan_info command is set with CH_SWITCH_NORMAL reason,
    even if the action is UNI_CHANNEL_RX_PATH, it'll still generate some
    unexpected tones, which might confuse DFS CAC tests that there are some
    tone leakages. To get rid of these kinds of false alarms, always bypass
    DPD calibration when IEEE80211_CONF_IDLE is set.
    
    Reviewed-by: Evelyn Tsai <evelyn.tsai@mediatek.com>
    Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: c685034cabc5 ("wifi: mt76: fix per-band IEEE80211_CONF_MONITOR flag comparison")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7603: improve stuck beacon handling [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Jul 28 16:21:18 2023 +0200

    wifi: mt76: mt7603: improve stuck beacon handling
    
    [ Upstream commit 3176205933494bd184c6acd70e796c382bc729b5 ]
    
    Before preparing the new beacon, check the queue status, flush out all
    previous beacons and buffered multicast packets, then (if necessary)
    try to recover more gracefully from a stuck beacon condition by making a
    less invasive attempt at getting the MAC un-stuck.
    
    Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7603: improve watchdog reset reliablity [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Jul 28 16:04:40 2023 +0200

    wifi: mt76: mt7603: improve watchdog reset reliablity
    
    [ Upstream commit c677dda165231c3efffb9de4bace249d5d2a51b9 ]
    
    Only trigger PSE reset if PSE was stuck, otherwise it can cause DMA issues.
    Trigger the PSE reset while DMA is fully stopped in order to improve
    reliabilty.
    
    Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7603: rework/fix rx pse hang check [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Jul 28 09:51:01 2023 +0200

    wifi: mt76: mt7603: rework/fix rx pse hang check
    
    [ Upstream commit baa19b2e4b7bbb509a7ca7939c8785477dcd40ee ]
    
    It turns out that the code in mt7603_rx_pse_busy() does not detect actual
    hardware hangs, it only checks for busy conditions in PSE.
    A reset should only be performed if these conditions are true and if there
    is no rx activity as well.
    Reset the counter whenever a rx interrupt occurs. In order to also deal with
    a fully loaded CPU that leaves interrupts disabled with continuous NAPI
    polling, also check for pending rx interrupts in the function itself.
    
    Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7915: fix beamforming availability check [+ + +]
Author: MeiChia Chiu <meichia.chiu@mediatek.com>
Date:   Thu Aug 31 14:22:21 2023 +0800

    wifi: mt76: mt7915: fix beamforming availability check
    
    [ Upstream commit ced1a0b8f3944e44e7f4eb3772dea1bada25d38a ]
    
    Without this patch, when ap sets the tx stream number to 2,
    ap won't send any beamforming packet.
    
    Fixes: f89f297aef28 ("mt76: mt7915: fix txbf starec TLV issues")
    Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: fix beamform mcu cmd configuration [+ + +]
Author: Howard Hsu <howard-yh.hsu@mediatek.com>
Date:   Thu Aug 17 16:01:47 2023 +0800

    wifi: mt76: mt7996: fix beamform mcu cmd configuration
    
    [ Upstream commit d40fd59b7267d2e7722d3edf3935a9a9f03c0115 ]
    
    The bf_num field represents how many bands can support beamform, so set
    the value to 3, and bf_bitmap represents the bitmap of bf_num.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: fix beamformee ss subfield in EHT PHY cap [+ + +]
Author: Howard Hsu <howard-yh.hsu@mediatek.com>
Date:   Thu Aug 17 16:01:48 2023 +0800

    wifi: mt76: mt7996: fix beamformee ss subfield in EHT PHY cap
    
    [ Upstream commit e19028104b2de5510b43282f632c4b6453568c41 ]
    
    According to P802.11be_D3.2 Table 9-404m, the minimum value of
    Beamformee SS field shall be 3. Fix the values to follow the spec.
    
    Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init")
    Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: fix rx rate report for CBW320-2 [+ + +]
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Aug 17 16:01:50 2023 +0800

    wifi: mt76: mt7996: fix rx rate report for CBW320-2
    
    [ Upstream commit 0197923ecf5eb4dbd785f5576040d49611f591a4 ]
    
    RX vector reports channel bandwidth 320-1 and 320-2 with different
    values. Fix it to correctly report rx rate when using CBW320-2.
    
    Fixes: 80f5a31d2856 ("wifi: mt76: mt7996: add support for EHT rate report")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: fix TWT command format [+ + +]
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Aug 17 16:01:51 2023 +0800

    wifi: mt76: mt7996: fix TWT command format
    
    [ Upstream commit 84f313b7392f6501f05d8981105d79859b1252cb ]
    
    Align the command format of UNI_CMD_TWT_ARGT_UPDATE to firmware.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: fix wmm queue mapping [+ + +]
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Aug 17 16:01:49 2023 +0800

    wifi: mt76: mt7996: fix wmm queue mapping
    
    [ Upstream commit 9b11696e5c5bf6030a32571f3f88845226d8b662 ]
    
    Firmware uses access class index (ACI) for wmm parameters update, so
    convert mac80211 queue to ACI in mt7996_conf_tx().
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: mt7996: set correct wcid in txp [+ + +]
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Aug 17 16:01:46 2023 +0800

    wifi: mt76: mt7996: set correct wcid in txp
    
    [ Upstream commit bde2e77f76266fbd81ff74cb12b3d87f9460b1e0 ]
    
    Set correct wcid in txp to let the SDO hw module look into the correct
    wtbl, otherwise the tx descriptor may be wrongly fiiled. This patch also
    fixed the issue that driver could not correctly report sta statistics,
    especially in WDS mode, which misled AQL.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Co-developed-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
    Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: remove unused error path in mt76_connac_tx_complete_skb [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Sep 11 15:15:18 2023 +0200

    wifi: mt76: remove unused error path in mt76_connac_tx_complete_skb
    
    [ Upstream commit 832f42699791e7a90e81c15da0ce886b4f8300b8 ]
    
    The error handling code was added in order to allow tx enqueue to fail after
    calling .tx_prepare_skb. Since this can no longer happen, the error handling
    code is unused.
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: bde2e77f7626 ("wifi: mt76: mt7996: set correct wcid in txp")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: update beacon size limitation [+ + +]
Author: MeiChia Chiu <meichia.chiu@mediatek.com>
Date:   Thu Aug 31 14:22:14 2023 +0800

    wifi: mt76: update beacon size limitation
    
    [ Upstream commit de869f81f994c4a4dea0d70921ac5ab78858b224 ]
    
    To accommodate 11v MBSSID IE and support maximum 16 MBSSIDs, expand the
    beacon size limitation for beacon and inband discovery commands.
    
    Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Co-developed-by: Money Wang <money.wang@mediatek.com>
    Signed-off-by: Money Wang <money.wang@mediatek.com>
    Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: d6a2f91741d9 ("wifi: mt76: fix potential memory leak of beacon commands")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: fix EDCA limit set by BT coexistence [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Thu Sep 28 08:23:19 2023 +0300

    wifi: rtlwifi: fix EDCA limit set by BT coexistence
    
    [ Upstream commit 3391ee7f9ea508c375d443cd712c2e699be235b4 ]
    
    In 'rtl92c_dm_check_edca_turbo()', 'rtl88e_dm_check_edca_turbo()',
    and 'rtl8723e_dm_check_edca_turbo()', the DL limit should be set
    from the corresponding field of 'rtlpriv->btcoexist' rather than
    UL. Compile tested only.
    
    Fixes: 0529c6b81761 ("rtlwifi: rtl8723ae: Update driver to match 06/28/14 Realtek version")
    Fixes: c151aed6aa14 ("rtlwifi: rtl8188ee: Update driver to match Realtek release of 06282014")
    Fixes: beb5bc402043 ("rtlwifi: rtl8192c-common: Convert common dynamic management routines for addition of rtl8192se and rtl8192de")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230928052327.120178-1-dmantipov@yandex.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtw88: debug: Fix the NULL vs IS_ERR() bug for debugfs_create_file() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Tue Sep 19 13:06:50 2023 +0800

    wifi: rtw88: debug: Fix the NULL vs IS_ERR() bug for debugfs_create_file()
    
    [ Upstream commit 74f7957c9b1b95553faaf146a2553e023a9d1720 ]
    
    Since debugfs_create_file() return ERR_PTR and never return NULL, so use
    IS_ERR() to check it instead of checking NULL.
    
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230919050651.962694-1-ruanjinjie@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtw88: Remove duplicate NULL check before calling usb_kill/free_urb() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Sun Oct 8 10:58:52 2023 +0800

    wifi: rtw88: Remove duplicate NULL check before calling usb_kill/free_urb()
    
    [ Upstream commit de8dd096949820ce5656d41ce409a67603e79327 ]
    
    Both usb_kill_urb() and usb_free_urb() do the NULL check itself, so there
    is no need to duplicate it prior to calling.
    
    Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231008025852.1239450-1-ruanjinjie@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: wfx: fix case where rates are out of order [+ + +]
Author: Felipe Negrelli Wolter <felipe.negrelliwolter@silabs.com>
Date:   Wed Oct 4 14:30:39 2023 +0200

    wifi: wfx: fix case where rates are out of order
    
    [ Upstream commit ea2274ab0b18549dbf0e755e41d8c5e8b5232dc3 ]
    
    When frames are sent over the air, the device always applies the data
    rates in descending order. The driver assumed Minstrel also provided
    rate in descending order.
    
    However, in some cases, Minstrel can a choose a fallback rate greater
    than the primary rate. In this case, the two rates was inverted, the
    device try highest rate first and we get many retries.
    
    Since the device always applies rates in descending order, the
    workaround is to drop the rate when it higher than its predecessor in
    the rate list. Thus [ 4, 5, 3 ] becomes [ 4, 3 ].
    
    This patch has been tested in isolated room with a series of
    attenuators. Here are the Minstrel statistics with 80dBm of attenuation:
    
      Without the fix:
    
                      best    ____________rate__________    ____statistics___    _____last____    ______sum-of________
        mode guard #  rate   [name   idx airtime  max_tp]  [avg(tp) avg(prob)]  [retry|suc|att]  [#success | #attempts]
        HT20  LGI  1       S  MCS0     0    1477     5.6       5.2      82.7       3     0 0             3   4
        HT20  LGI  1          MCS1     1     738    10.6       0.0       0.0       0     0 0             0   1
        HT20  LGI  1     D    MCS2     2     492    14.9      13.5      81.5       5     0 0             5   9
        HT20  LGI  1    C     MCS3     3     369    18.8      17.6      84.3       5     0 0            76   96
        HT20  LGI  1  A   P   MCS4     4     246    25.4      22.4      79.5       5     0 0         11268   14026
        HT20  LGI  1   B   S  MCS5     5     185    30.7      19.7      57.7       5     8 9          3918   9793
        HT20  LGI  1          MCS6     6     164    33.0       0.0       0.0       5     0 0             6   102
        HT20  LGI  1          MCS7     7     148    35.1       0.0       0.0       0     0 0             0   44
    
      With the fix:
    
                      best    ____________rate__________    ____statistics___    _____last____    ______sum-of________
        mode guard #  rate   [name   idx airtime  max_tp]  [avg(tp) avg(prob)]  [retry|suc|att]  [#success | #attempts]
        HT20  LGI  1       S  MCS0     0    1477     5.6       1.8      28.6       1     0 0             1   5
        HT20  LGI  1     DP   MCS1     1     738    10.6       9.7      82.6       4     0 0            14   34
        HT20  LGI  1          MCS2     2     492    14.9       9.2      55.4       5     0 0            52   77
        HT20  LGI  1   B   S  MCS3     3     369    18.8      15.6      74.9       5     1 1           417   554
        HT20  LGI  1  A       MCS4     4     246    25.4      16.7      59.2       5     1 1         13812   17951
        HT20  LGI  1    C  S  MCS5     5     185    30.7      14.0      41.0       5     1 5            57   640
        HT20  LGI  1          MCS6     6     164    33.0       0.0       0.0       0     0 1             0   48
        HT20  LGI  1       S  MCS7     7     148    35.1       0.0       0.0       0     0 0             0   36
    
    We can notice the device try now to send with lower rates (and high
    success rates). At the end, we measured 20-25% better throughput with
    this patch.
    
    Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
    Tested-by: Olivier Souloumiac <olivier.souloumiac@silabs.com>
    Tested-by: Alexandr Suslenko <suslenko.o@ajax.systems>
    Reported-by: Alexandr Suslenko <suslenko.o@ajax.systems>
    Co-developed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Signed-off-by: Felipe Negrelli Wolter <felipe.negrelliwolter@silabs.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231004123039.157112-1-jerome.pouiller@silabs.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
writeback, cgroup: switch inodes with dirty timestamps to release dying cgwbs [+ + +]
Author: Jingbo Xu <jefflexu@linux.alibaba.com>
Date:   Sat Oct 14 20:55:11 2023 +0800

    writeback, cgroup: switch inodes with dirty timestamps to release dying cgwbs
    
    [ Upstream commit 6654408a33e6297d8e1d2773409431d487399b95 ]
    
    The cgwb cleanup routine will try to release the dying cgwb by switching
    the attached inodes.  It fetches the attached inodes from wb->b_attached
    list, omitting the fact that inodes only with dirty timestamps reside in
    wb->b_dirty_time list, which is the case when lazytime is enabled.  This
    causes enormous zombie memory cgroup when lazytime is enabled, as inodes
    with dirty timestamps can not be switched to a live cgwb for a long time.
    
    It is reasonable not to switch cgwb for inodes with dirty data, as
    otherwise it may break the bandwidth restrictions.  However since the
    writeback of inode metadata is not accounted for, let's also switch
    inodes with dirty timestamps to avoid zombie memory and block cgroups
    when laztytime is enabled.
    
    Fixes: c22d70a162d3 ("writeback, cgroup: release dying cgwbs by switching attached inodes")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20231014125511.102978-1-jefflexu@linux.alibaba.com
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs [+ + +]
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Thu Aug 3 10:04:30 2023 -0500

    x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs
    
    commit 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc upstream.
    
    Three PCI IDs for DF Function 4 were defined but not used.
    
    Add them to the "link" list.
    
    Fixes: f8faf3496633 ("x86/amd_nb: Add AMD PCI IDs for SMN communication")
    Fixes: 23a5b8bb022c ("x86/amd_nb: Add PCI ID for family 19h model 78h")
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/apic: Fake primary thread mask for XEN/PV [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Aug 14 10:18:28 2023 +0200

    x86/apic: Fake primary thread mask for XEN/PV
    
    [ Upstream commit 965e05ff8af98c44f9937366715c512000373164 ]
    
    The SMT control mechanism got added as speculation attack vector
    mitigation. The implemented logic relies on the primary thread mask to
    be set up properly.
    
    This turns out to be an issue with XEN/PV guests because their CPU hotplug
    mechanics do not enumerate APICs and therefore the mask is never correctly
    populated.
    
    This went unnoticed so far because by chance XEN/PV ends up with
    smp_num_siblings == 2. So cpu_smt_control stays at its default value
    CPU_SMT_ENABLED and the primary thread mask is never evaluated in the
    context of CPU hotplug.
    
    This stopped "working" with the upcoming overhaul of the topology
    evaluation which legitimately provides a fake topology for XEN/PV. That
    sets smp_num_siblings to 1, which causes the core CPU hot-plug core to
    refuse to bring up the APs.
    
    This happens because cpu_smt_control is set to CPU_SMT_NOT_SUPPORTED which
    causes cpu_bootable() to evaluate the unpopulated primary thread mask with
    the conclusion that all non-boot CPUs are not valid to be plugged.
    
    The core code has already been made more robust against this kind of fail,
    but the primary thread mask really wants to be populated to avoid other
    issues all over the place.
    
    Just fake the mask by pretending that all XEN/PV vCPUs are primary threads,
    which is consistent because all of XEN/PVs topology is fake or non-existent.
    
    Fixes: 6a4d2657e048 ("x86/smp: Provide topology_is_primary_thread()")
    Fixes: f54d4434c281 ("x86/apic: Provide cpu_primary_thread mask")
    Reported-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Juergen Gross <jgross@suse.com>
    Tested-by: Sohil Mehta <sohil.mehta@intel.com>
    Tested-by: Michael Kelley <mikelley@microsoft.com>
    Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230814085112.210011520@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/boot: Fix incorrect startup_gdt_descr.size [+ + +]
Author: Yuntao Wang <ytcoode@gmail.com>
Date:   Mon Aug 7 16:45:47 2023 +0800

    x86/boot: Fix incorrect startup_gdt_descr.size
    
    [ Upstream commit 001470fed5959d01faecbd57fcf2f60294da0de1 ]
    
    Since the size value is added to the base address to yield the last valid
    byte address of the GDT, the current size value of startup_gdt_descr is
    incorrect (too large by one), fix it.
    
    [ mingo: This probably never mattered, because startup_gdt[] is only used
             in a very controlled fashion - but make it consistent nevertheless. ]
    
    Fixes: 866b556efa12 ("x86/head/64: Install startup GDT")
    Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lore.kernel.org/r/20230807084547.217390-1-ytcoode@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/nmi: Fix out-of-order NMI nesting checks & false positive warning [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Wed Oct 11 11:40:16 2023 -0700

    x86/nmi: Fix out-of-order NMI nesting checks & false positive warning
    
    [ Upstream commit f44075ecafb726830e63d33fbca29413149eeeb8 ]
    
    The ->idt_seq and ->recv_jiffies variables added by:
    
      1a3ea611fc10 ("x86/nmi: Accumulate NMI-progress evidence in exc_nmi()")
    
    ... place the exit-time check of the bottom bit of ->idt_seq after the
    this_cpu_dec_return() that re-enables NMI nesting.  This can result in
    the following sequence of events on a given CPU in kernels built with
    CONFIG_NMI_CHECK_CPU=y:
    
      o   An NMI arrives, and ->idt_seq is incremented to an odd number.
          In addition, nmi_state is set to NMI_EXECUTING==1.
    
      o   The NMI is processed.
    
      o   The this_cpu_dec_return(nmi_state) zeroes nmi_state and returns
          NMI_EXECUTING==1, thus opting out of the "goto nmi_restart".
    
      o   Another NMI arrives and ->idt_seq is incremented to an even
          number, triggering the warning.  But all is just fine, at least
          assuming we don't get so many closely spaced NMIs that the stack
          overflows or some such.
    
    Experience on the fleet indicates that the MTBF of this false positive
    is about 70 years.  Or, for those who are not quite that patient, the
    MTBF appears to be about one per week per 4,000 systems.
    
    Fix this false-positive warning by moving the "nmi_restart" label before
    the initial ->idt_seq increment/check and moving the this_cpu_dec_return()
    to follow the final ->idt_seq increment/check.  This way, all nested NMIs
    that get past the NMI_NOT_RUNNING check get a clean ->idt_seq slate.
    And if they don't get past that check, they will set nmi_state to
    NMI_LATCHED, which will cause the this_cpu_dec_return(nmi_state)
    to restart.
    
    Fixes: 1a3ea611fc10 ("x86/nmi: Accumulate NMI-progress evidence in exc_nmi()")
    Reported-by: Chris Mason <clm@fb.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lore.kernel.org/r/0cbff831-6e3d-431c-9830-ee65ee7787ff@paulmck-laptop
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/numa: Introduce numa_fill_memblks() [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Mon Jul 10 13:02:58 2023 -0700

    x86/numa: Introduce numa_fill_memblks()
    
    [ Upstream commit 8f012db27c9516be1a7aca93ea4a6ca9c75056c9 ]
    
    numa_fill_memblks() fills in the gaps in numa_meminfo memblks
    over an physical address range.
    
    The ACPI driver will use numa_fill_memblks() to implement a new Linux
    policy that prescribes extending proximity domains in a portion of a
    CFMWS window to the entire window.
    
    Dan Williams offered this explanation of the policy:
    A CFWMS is an ACPI data structure that indicates *potential* locations
    where CXL memory can be placed. It is the playground where the CXL
    driver has free reign to establish regions. That space can be populated
    by BIOS created regions, or driver created regions, after hotplug or
    other reconfiguration.
    
    When BIOS creates a region in a CXL Window it additionally describes
    that subset of the Window range in the other typical ACPI tables SRAT,
    SLIT, and HMAT. The rationale for BIOS not pre-describing the entire
    CXL Window in SRAT, SLIT, and HMAT is that it can not predict the
    future. I.e. there is nothing stopping higher or lower performance
    devices being placed in the same Window. Compare that to ACPI memory
    hotplug that just onlines additional capacity in the proximity domain
    with little freedom for dynamic performance differentiation.
    
    That leaves the OS with a choice, should unpopulated window capacity
    match the proximity domain of an existing region, or should it allocate
    a new one? This patch takes the simple position of minimizing proximity
    domain proliferation by reusing any proximity domain intersection for
    the entire Window. If the Window has no intersections then allocate a
    new proximity domain. Note that SRAT, SLIT and HMAT information can be
    enumerated dynamically in a standard way from device provided data.
    Think of CXL as the end of ACPI needing to describe memory attributes,
    CXL offers a standard discovery model for performance attributes, but
    Linux still needs to interoperate with the old regime.
    
    Reported-by: Derick Marks <derick.w.marks@intel.com>
    Suggested-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Tested-by: Derick Marks <derick.w.marks@intel.com>
    Link: https://lore.kernel.org/all/ef078a6f056ca974e5af85997013c0fda9e3326d.1689018477.git.alison.schofield%40intel.com
    Stable-dep-of: 8f1004679987 ("ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/sev-es: Allow copy_from_kernel_nofault() in earlier boot [+ + +]
Author: Adam Dunlap <acdunlap@google.com>
Date:   Mon Sep 11 17:27:02 2023 -0700

    x86/sev-es: Allow copy_from_kernel_nofault() in earlier boot
    
    [ Upstream commit f79936545fb122856bd78b189d3c7ee59928c751 ]
    
    Previously, if copy_from_kernel_nofault() was called before
    boot_cpu_data.x86_virt_bits was set up, then it would trigger undefined
    behavior due to a shift by 64.
    
    This ended up causing boot failures in the latest version of ubuntu2204
    in the gcp project when using SEV-SNP.
    
    Specifically, this function is called during an early #VC handler which
    is triggered by a CPUID to check if NX is implemented.
    
    Fixes: 1aa9aa8ee517 ("x86/sev-es: Setup GHCB-based boot #VC handler")
    Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Adam Dunlap <acdunlap@google.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: Jacob Xu <jacobhxu@google.com>
    Link: https://lore.kernel.org/r/20230912002703.3924521-2-acdunlap@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/srso: Fix SBPB enablement for (possible) future fixed HW [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Mon Sep 4 22:04:49 2023 -0700

    x86/srso: Fix SBPB enablement for (possible) future fixed HW
    
    [ Upstream commit 1d1142ac51307145dbb256ac3535a1d43a1c9800 ]
    
    Make the SBPB check more robust against the (possible) case where future
    HW has SRSO fixed but doesn't have the SRSO_NO bit set.
    
    Fixes: 1b5277c0ea0b ("x86/srso: Add SRSO_NO support")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/cee5050db750b391c9f35f5334f8ff40e66c01b9.1693889988.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/srso: Fix unret validation dependencies [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Mon Sep 4 22:04:53 2023 -0700

    x86/srso: Fix unret validation dependencies
    
    [ Upstream commit eeb9f34df065f42f0c9195b322ba6df420c9fc92 ]
    
    CONFIG_CPU_SRSO isn't dependent on CONFIG_CPU_UNRET_ENTRY (AMD
    Retbleed), so the two features are independently configurable.  Fix
    several issues for the (presumably rare) case where CONFIG_CPU_SRSO is
    enabled but CONFIG_CPU_UNRET_ENTRY isn't.
    
    Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/299fb7740174d0f2335e91c58af0e9c242b4bac1.1693889988.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/srso: Fix vulnerability reporting for missing microcode [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Mon Sep 4 22:04:52 2023 -0700

    x86/srso: Fix vulnerability reporting for missing microcode
    
    [ Upstream commit dc6306ad5b0dda040baf1fde3cfd458e6abfc4da ]
    
    The SRSO default safe-ret mitigation is reported as "mitigated" even if
    microcode hasn't been updated.  That's wrong because userspace may still
    be vulnerable to SRSO attacks due to IBPB not flushing branch type
    predictions.
    
    Report the safe-ret + !microcode case as vulnerable.
    
    Also report the microcode-only case as vulnerable as it leaves the
    kernel open to attacks.
    
    Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/a8a14f97d1b0e03ec255c81637afdf4cf0ae9c99.1693889988.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/srso: Print mitigation for retbleed IBPB case [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Mon Sep 4 22:04:51 2023 -0700

    x86/srso: Print mitigation for retbleed IBPB case
    
    [ Upstream commit de9f5f7b06a5b7adbfdd8016f011120a4e928add ]
    
    When overriding the requested mitigation with IBPB due to retbleed=ibpb,
    print the mitigation in the usual format instead of a custom error
    message.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/ec3af919e267773d896c240faf30bfc6a1fd6304.1693889988.git.jpoimboe@kernel.org
    Stable-dep-of: dc6306ad5b0d ("x86/srso: Fix vulnerability reporting for missing microcode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro [+ + +]
Author: Kai Huang <kai.huang@intel.com>
Date:   Tue Aug 15 23:01:55 2023 +1200

    x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro
    
    [ Upstream commit 5d092b66119d774853cc9308522620299048a662 ]
    
    In the TDX_HYPERCALL asm, after the TDCALL instruction returns from the
    untrusted VMM, the registers that the TDX guest shares to the VMM need
    to be cleared to avoid speculative execution of VMM-provided values.
    
    RSI is specified in the bitmap of those registers, but it is missing
    when zeroing out those registers in the current TDX_HYPERCALL.
    
    It was there when it was originally added in commit 752d13305c78
    ("x86/tdx: Expand __tdx_hypercall() to handle more arguments"), but was
    later removed in commit 1e70c680375a ("x86/tdx: Do not corrupt
    frame-pointer in __tdx_hypercall()"), which was correct because %rsi is
    later restored in the "pop %rsi".  However a later commit 7a3a401874be
    ("x86/tdx: Drop flags from __tdx_hypercall()") removed that "pop %rsi"
    but forgot to add the "xor %rsi, %rsi" back.
    
    Fix by adding it back.
    
    Fixes: 7a3a401874be ("x86/tdx: Drop flags from __tdx_hypercall()")
    Signed-off-by: Kai Huang <kai.huang@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/all/e7d1157074a0b45d34564d5f17f3e0ffee8115e9.1692096753.git.kai.huang%40intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled [+ + +]
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Mon Oct 16 15:13:25 2023 +0200

    xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled
    
    [ Upstream commit 2c269f42d0f382743ab230308b836ffe5ae9b2ae ]
    
    Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
    the table is filled. Then it disables INTx just before clearing MASKALL
    bit. Currently this approach is rejected by xen-pciback.
    According to the PCIe spec, device cannot use INTx when MSI/MSI-X is
    enabled (in other words: enabling MSI/MSI-X implicitly disables INTx).
    
    Change the logic to consider INTx disabled if MSI/MSI-X is enabled. This
    applies to three places:
     - checking currently enabled interrupts type,
     - transition to MSI/MSI-X - where INTx would be implicitly disabled,
     - clearing INTx disable bit - which can be allowed even if MSI/MSI-X is
       enabled, as device should consider INTx disabled anyway in that case
    
    Fixes: 5e29500eba2a ("xen-pciback: Allow setting PCI_MSIX_FLAGS_MASKALL too")
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Acked-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20231016131348.1734721-1-marmarek@invisiblethingslab.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xenbus: fix error exit in xenbus_init() [+ + +]
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Aug 22 11:11:38 2023 +0200

    xenbus: fix error exit in xenbus_init()
    
    [ Upstream commit 44961b81a9e9059b5c0443643915386db7035227 ]
    
    In case an error occurs in xenbus_init(), xen_store_domain_type should
    be set to XS_UNKNOWN.
    
    Fix one instance where this action is missing.
    
    Fixes: 5b3353949e89 ("xen: add support for initializing xenstore later as HVM domain")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Link: https://lore.kernel.org/r/202304200845.w7m4kXZr-lkp@intel.com/
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Link: https://lore.kernel.org/r/20230822091138.4765-1-jgross@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xhci: Loosen RPM as default policy to cover for AMD xHC 1.1 [+ + +]
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Thu Oct 19 13:29:19 2023 +0300

    xhci: Loosen RPM as default policy to cover for AMD xHC 1.1
    
    [ Upstream commit 4baf1218150985ee3ab0a27220456a1f027ea0ac ]
    
    The AMD USB host controller (1022:43f7) isn't going into PCI D3 by default
    without anything connected. This is because the policy that was introduced
    by commit a611bf473d1f ("xhci-pci: Set runtime PM as default policy on all
    xHC 1.2 or later devices") only covered 1.2 or later.
    
    The 1.1 specification also has the same requirement as the 1.2
    specification for D3 support. So expand the runtime PM as default policy
    to all AMD 1.1 devices as well.
    
    Fixes: a611bf473d1f ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices")
    Link: https://composter.com.ua/documents/xHCI_Specification_for_USB.pdf
    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20231019102924.2797346-15-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>