Linux 5.10.201

 
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>

 
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: 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: 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>

 
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: 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>

 
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: 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: 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>

 
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_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>

 
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: asm9260: use parent index to link the reference clock [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Sep 16 09:17:38 2022 +0300

    clk: asm9260: use parent index to link the reference clock
    
    [ Upstream commit f5290d8e4f0caa81a491448a27dd70e726095d07 ]
    
    Rewrite clk-asm9260 to use parent index to use the reference clock.
    During this rework two helpers are added:
    
    - clk_hw_register_mux_table_parent_data() to supplement
      clk_hw_register_mux_table() but using parent_data instead of
      parent_names
    
    - clk_hw_register_fixed_rate_parent_accuracy() to be used instead of
      directly calling __clk_hw_register_fixed_rate(). The later function is
      an internal API, which is better not to be called directly.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20220916061740.87167-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 84aefafe6b29 ("clk: linux/clk-provider.h: fix kernel-doc warnings and typos")
    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: 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: 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: 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-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: gcc-sm8150: use ARRAY_SIZE instead of specifying num_parents [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Apr 6 01:47:41 2021 +0300

    clk: qcom: gcc-sm8150: use ARRAY_SIZE instead of specifying num_parents
    
    [ Upstream commit 60ca4670fd6436c07cea38472ebcee3b00f03bc7 ]
    
    Use ARRAY_SIZE() instead of manually specifying num_parents. This makes
    adding/removing entries to/from parent_data easy and errorproof.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20210405224743.590029-32-dmitry.baryshkov@linaro.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 7138c244fb29 ("clk: qcom: gcc-sm8150: Fix gcc_sdcc2_apps_clk_src")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-msm8998: Add hardware clockgating registers to some clks [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Date:   Thu Jan 14 23:10:56 2021 +0100

    clk: qcom: mmcc-msm8998: Add hardware clockgating registers to some clks
    
    [ Upstream commit fa92f3b093d6ca624f42d444d5a206f8724b6bb3 ]
    
    Hardware clock gating is supported on some of the clocks declared in
    there: ignoring that it does exist may lead to unstabilities on some
    firmwares.
    Add the HWCG registers where applicable to stop potential crashes.
    
    This was verified on a smartphone shipped with a recent MSM8998
    firmware, which will experience random crashes without this change.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Link: https://lore.kernel.org/r/20210114221059.483390-9-angelogioacchino.delregno@somainline.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 9906c4140897 ("clk: qcom: mmcc-msm8998: Don't check halt bit on some branch clks")
    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: qcom: mmcc-msm8998: Set bimc_smmu_gdsc always on [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Date:   Thu Jan 14 23:10:57 2021 +0100

    clk: qcom: mmcc-msm8998: Set bimc_smmu_gdsc always on
    
    [ Upstream commit 68e1d106eb4dceb61bc2818d829786b364fd502b ]
    
    This GDSC enables (or cuts!) power to the Multimedia Subsystem IOMMU
    (mmss smmu), which has bootloader pre-set secure contexts.
    In the event of a complete power loss, the secure contexts will be
    reset and the hypervisor will crash the SoC.
    
    To prevent this, and get a working multimedia subsystem, set this
    GDSC as always on.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Link: https://lore.kernel.org/r/20210114221059.483390-10-angelogioacchino.delregno@somainline.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 1fc62c834739 ("clk: qcom: mmcc-msm8998: Fix the SMMU GDSC")
    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: Add ti_dt_clk_name() helper to use clock-output-names [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Feb 4 09:14:47 2022 +0200

    clk: ti: Add ti_dt_clk_name() helper to use clock-output-names
    
    [ Upstream commit 2c1593328d7f02fe49de5ad6b42c36296c9d6922 ]
    
    Let's create the clock alias based on the clock-output-names property if
    available. Also the component clock drivers can use ti_dt_clk_name() in
    the following patches.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220204071449.16762-7-tony@atomide.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 7af5b9eadd64 ("clk: ti: fix double free in of_ti_divider_clk_setup()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: ti: change ti_clk_register[_omap_hw]() API [+ + +]
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Sun Nov 13 19:11:46 2022 +0100

    clk: ti: change ti_clk_register[_omap_hw]() API
    
    [ Upstream commit 3400d546a741a2b2001d88e7fa29110d45a3930d ]
    
    The ti_clk_register() and ti_clk_register_omap_hw() functions are always
    called with the parameter of type "struct device" set to NULL, since the
    functions from which they are called always have a parameter of type
    "struct device_node". Replacing "struct device" type parameter with
    "struct device_node" will allow you to register a TI clock to the common
    clock framework by taking advantage of the facilities provided by the
    "struct device_node" type. Further, adding the "of_" prefix to the name
    of these functions explicitly binds them to the "struct device_node"
    type.
    
    The patch has been tested on a Beaglebone board.
    
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20221113181147.1626585-1-dario.binacchi@amarulasolutions.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 7af5b9eadd64 ("clk: ti: fix double free in of_ti_divider_clk_setup()")
    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>

clk: ti: Update component clocks to use ti_dt_clk_name() [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Feb 4 09:14:49 2022 +0200

    clk: ti: Update component clocks to use ti_dt_clk_name()
    
    [ Upstream commit ed06099c5d0b329082cc19c58eace0b20bf7fe70 ]
    
    Let's update all the TI component clocks to use ti_dt_clk_name() instead
    of devicetree node name if available.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220204071449.16762-9-tony@atomide.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 7af5b9eadd64 ("clk: ti: fix double free in of_ti_divider_clk_setup()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: ti: Update pll and clockdomain clocks to use ti_dt_clk_name() [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Feb 4 09:14:48 2022 +0200

    clk: ti: Update pll and clockdomain clocks to use ti_dt_clk_name()
    
    [ Upstream commit 9e56a7d4263ca1c51d867e811cf2dd7e61b6469e ]
    
    Let's update the TI pll and clockdomain clocks to use ti_dt_clk_name()
    instead of devicetree node name if available.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220204071449.16762-8-tony@atomide.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 7af5b9eadd64 ("clk: ti: fix double free in of_ti_divider_clk_setup()")
    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: 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>

crypto: qat - mask device capabilities with soft straps [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Mon Oct 12 21:38:18 2020 +0100

    crypto: qat - mask device capabilities with soft straps
    
    [ Upstream commit 7b07ed5042c5d21467af5aa055f2b49b2e661a83 ]
    
    Enable acceleration engines (AEs) and accelerators based on soft straps
    and fuses. When looping with a number of AEs or accelerators, ignore the
    ones that are disabled.
    
    This patch is based on earlier work done by Conor McLoughlin.
    
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
    Reviewed-by: Wojciech Ziemba <wojciech.ziemba@intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 4e4e2ed22d50 ("crypto: qat - increase size of buffers")
    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>

 
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>

 
drm/bridge: tc358768: Disable non-continuous clock mode [+ + +]
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Oct 3 02:34:46 2021 +0300

    drm/bridge: tc358768: Disable non-continuous clock mode
    
    [ Upstream commit fbc5a90e82c1131869e76ce5b082693b8a75c121 ]
    
    Non-continuous clock mode doesn't work because driver doesn't support it
    properly. The bridge driver programs wrong bitfields that are required by
    the non-continuous mode (BTACNTRL1 register bitfields are swapped in the
    code), but fixing them doesn't help.
    
    Display panel of ASUS Transformer TF700T tablet supports non-continuous
    mode and display doesn't work at all using that mode. There are no
    device-trees that are actively using this DSI bridge in upstream yet,
    so clearly the broken mode wasn't ever tested properly. It's a bit too
    difficult to get LP mode working, hence let's disable the offending mode
    for now and fall back to continuous mode.
    
    Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T
    Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-5-digetx@gmail.com
    Stable-dep-of: 66962d5c3c51 ("drm/bridge: tc358768: Fix bit updates")
    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 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/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/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: 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/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>

 
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: 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 error path of imsttfb_probe() [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sat May 27 11:37:29 2023 +0200

    fbdev: imsttfb: Fix error path of imsttfb_probe()
    
    [ Upstream commit 518ecb6a209f6ff678aeadf9f2bf870c0982ca85 ]
    
    Release ressources when init_imstt() returns failure.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Stable-dep-of: aba6ab57a910 ("fbdev: imsttfb: fix a resource leak in probe")
    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>

 
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: Remove HIDPP_QUIRK_NO_HIDINPUT quirk [+ + +]
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Jan 25 13:17:23 2023 +0100

    HID: logitech-hidpp: Remove HIDPP_QUIRK_NO_HIDINPUT quirk
    
    [ Upstream commit d83956c8855c6c2ed4bd16cec4a5083d63df17e4 ]
    
    HIDPP_QUIRK_NO_HIDINPUT isn't used by any devices but still happens to
    work as HIDPP_QUIRK_DELAYED_INIT is defined to the same value. Remove
    HIDPP_QUIRK_NO_HIDINPUT and use HIDPP_QUIRK_DELAYED_INIT everywhere
    instead.
    
    Tested on a T650 which requires that quirk, and a number of unifying and
    Bluetooth devices that don't.
    
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Link: https://lore.kernel.org/r/20230125121723.3122-2-hadess@hadess.net
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Stable-dep-of: 11ca0322a419 ("HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() only")
    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>

 
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>

 
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: (axi-fan-control) Support temperature vs pwm points [+ + +]
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Wed Aug 11 13:48:53 2021 +0200

    hwmon: (axi-fan-control) Support temperature vs pwm points
    
    [ Upstream commit 2aee7e67bee7a5aa741bad6a0a472f108b29ad40 ]
    
    The HW has some predefined points where it will associate a PWM value.
    However some users might want to better set these points to their
    usecases. This patch exposes these points as pwm auto_points:
    
     * pwm1_auto_point1_temp_hyst: temperature threshold below which PWM should
       be 0%;
     * pwm1_auto_point1_temp: temperature threshold above which PWM should be
       25%;
     * pwm1_auto_point2_temp_hyst: temperature threshold below which PWM should
       be 25%;
     * pwm1_auto_point2_temp: temperature threshold above which PWM should be
       50%;
     * pwm1_auto_point3_temp_hyst: temperature threshold below which PWM should
       be 50%;
     * pwm1_auto_point3_temp: temperature threshold above which PWM should be
       75%;
     * pwm1_auto_point4_temp_hyst: temperature threshold below which PWM should
       be 75%;
     * pwm1_auto_point4_temp: temperature threshold above which PWM should be
       100%;
    
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210811114853.159298-4-nuno.sa@analog.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Stable-dep-of: 2a5b3370a1d9 ("hwmon: (axi-fan-control) Fix possible NULL pointer dereference")
    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>

 
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>

 
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>

 
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>

 
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: 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>

 
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>

 
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>

 
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>

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

    Linux 5.10.201
    
    Link: https://lore.kernel.org/r/20231115204644.490636297@linuxfoundation.org
    Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    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: 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: 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: 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: 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: 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>

 
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 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>

 
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/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: 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: 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: nft_redir: use `struct nf_nat_range2` throughout and deduplicate eval call-backs [+ + +]
Author: Jeremy Sowden <jeremy@azazel.net>
Date:   Wed Mar 15 21:48:01 2023 +0000

    netfilter: nft_redir: use `struct nf_nat_range2` throughout and deduplicate eval call-backs
    
    [ Upstream commit 6f56ad1b92328997e1b1792047099df6f8d7acb5 ]
    
    `nf_nat_redirect_ipv4` takes a `struct nf_nat_ipv4_multi_range_compat`,
    but converts it internally to a `struct nf_nat_range2`.  Change the
    function to take the latter, factor out the code now shared with
    `nf_nat_redirect_ipv6`, move the conversion to the xt_REDIRECT module,
    and update the ipv4 range initialization in the nft_redir module.
    
    Replace a bare hex constant for 127.0.0.1 with a macro.
    
    Remove `WARN_ON`.  `nf_nat_setup_info` calls `nf_ct_is_confirmed`:
    
            /* Can't setup nat info for confirmed ct. */
            if (nf_ct_is_confirmed(ct))
                    return NF_ACCEPT;
    
    This means that `ct` cannot be null or the kernel will crash, and
    implies that `ctinfo` is `IP_CT_NEW` or `IP_CT_RELATED`.
    
    nft_redir has separate ipv4 and ipv6 call-backs which share much of
    their code, and an inet one switch containing a switch that calls one of
    the others based on the family of the packet.  Merge the ipv4 and ipv6
    ones into the inet one in order to get rid of the duplicate code.
    
    Const-qualify the `priv` pointer since we don't need to write through
    it.
    
    Assign `priv->flags` to the range instead of OR-ing it in.
    
    Set the `NF_NAT_RANGE_PROTO_SPECIFIED` flag once during init, rather
    than on every eval.
    
    Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: 80abbe8a8263 ("netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses")
    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>

 
overflow: Implement size_t saturating arithmetic helpers [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Sat Sep 18 15:17:53 2021 -0700

    overflow: Implement size_t saturating arithmetic helpers
    
    [ Upstream commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f ]
    
    In order to perform more open-coded replacements of common allocation
    size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
    multiplication, addition, and subtraction. For example, it is common in
    allocators, especially on realloc, to add to an existing size:
    
        p = krealloc(map->patch,
                     sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
                     GFP_KERNEL);
    
    There is no existing saturating replacement for this calculation, and
    just leaving the addition open coded inside array_size() could
    potentially overflow as well. For example, an overflow in an expression
    for a size_t argument might wrap to zero:
    
        array_size(anything, something_at_size_max + 1) == 0
    
    Introduce size_mul(), size_add(), and size_sub() helpers that
    implicitly promote arguments to size_t and saturated calculations for
    use in allocations. With these helpers it is also possible to redefine
    array_size(), array3_size(), flex_array_size(), and struct_size() in
    terms of the new helpers.
    
    As with the check_*_overflow() helpers, the new helpers use __must_check,
    though what is really desired is a way to make sure that assignment is
    only to a size_t lvalue. Without this, it's still possible to introduce
    overflow/underflow via type conversion (i.e. from size_t to int).
    Enforcing this will currently need to be left to static analysis or
    future use of -Wconversion.
    
    Additionally update the overflow unit tests to force runtime evaluation
    for the pathological cases.
    
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: Keith Busch <kbusch@kernel.org>
    Cc: Len Baker <len.baker@gmx.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Stable-dep-of: d692873cbe86 ("gve: Use size_add() in call to struct_size()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
padata: Convert from atomic_t to refcount_t on parallel_data->refcnt [+ + +]
Author: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Date:   Tue Jul 20 11:05:11 2021 -0400

    padata: Convert from atomic_t to refcount_t on parallel_data->refcnt
    
    [ Upstream commit d5ee8e750c9449e9849a09ce6fb6b8adeaa66adc ]
    
    refcount_t type and corresponding API can protect refcounters from
    accidental underflow and overflow and further use-after-free situations.
    
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 7ddc21e317b3 ("padata: Fix refcnt handling in padata_free_shell()")
    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>

 
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 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 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>

 
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>

platform/x86: wmi: remove unnecessary initializations [+ + +]
Author: Barnabás Pőcze <pobrn@protonmail.com>
Date:   Sat Sep 4 17:55:10 2021 +0000

    platform/x86: wmi: remove unnecessary initializations
    
    [ Upstream commit 43aacf838ef7384d985ef5385ecb0124f8c70007 ]
    
    Some pointers are initialized when they are defined,
    but they are almost immediately reassigned in the
    following lines. Remove these superfluous assignments.
    
    Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
    Link: https://lore.kernel.org/r/20210904175450.156801-6-pobrn@protonmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Stable-dep-of: eba9ac7abab9 ("platform/x86: wmi: Fix opening of char device")
    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>

 
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/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>

 
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: Avoid conditional gotos [+ + +]
Author: Thierry Reding <thierry.reding@gmail.com>
Date:   Wed Nov 11 19:24:29 2020 +0100

    pwm: sti: Avoid conditional gotos
    
    [ Upstream commit fd3ae02bb66f091e55f363d32eca7b4039977bf5 ]
    
    Using gotos for conditional code complicates this code significantly.
    Convert the code to simple conditional blocks to increase readability.
    
    Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Stable-dep-of: 2d6812b41e0d ("pwm: sti: Reduce number of allocations and drop usage of chip_data")
    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>

r8169: use tp_to_dev instead of open code [+ + +]
Author: Juhee Kang <claudiajkang@gmail.com>
Date:   Wed Nov 30 01:12:44 2022 +0900

    r8169: use tp_to_dev instead of open code
    
    [ Upstream commit 4b6c6065fca123d419afef005a696f51e6590470 ]
    
    The open code is defined as a helper function(tp_to_dev) on r8169_main.c,
    which the open code is &tp->pci_dev->dev. The helper function was added
    in commit 1e1205b7d3e9 ("r8169: add helper tp_to_dev"). And then later,
    commit f1e911d5d0df ("r8169: add basic phylib support") added
    r8169_phylink_handler function but it didn't use the helper function.
    Thus, tp_to_dev() replaces the open code. This patch doesn't change logic.
    
    Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/20221129161244.5356-1-claudiajkang@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 621735f59064 ("r8169: fix rare issue with broken rx after link-down on RTL8125")
    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: 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>

 
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>

 
Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures" [+ + +]
Author: Bastien Nocera <hadess@hadess.net>
Date:   Tue Dec 20 16:43:43 2022 +0100

    Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures"
    
    [ Upstream commit cae253d6033da885e71c29c1591b22838a52de76 ]
    
    Now that we're in 2022, and the majority of desktop environments can and
    should support touchpad gestures through libinput, remove the legacy
    module parameter that made it possible to use gestures implemented in
    firmware.
    
    This will eventually allow simplifying the driver's initialisation code.
    
    This reverts commit 9188dbaed68a4b23dc96eba165265c08caa7dc2a.
    
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20221220154345.474596-1-hadess@hadess.net
    Stable-dep-of: 11ca0322a419 ("HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() only")
    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>

 
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>

 
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>

 
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/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>

 
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>

 
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: 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>

 
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: 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>

 
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>

tools: iio: iio_generic_buffer: Fix some integer type and calculation [+ + +]
Author: Chenyuan Mi <michenyuan@huawei.com>
Date:   Tue Jul 25 09:24:07 2023 +0000

    tools: iio: iio_generic_buffer: Fix some integer type and calculation
    
    [ Upstream commit 49d736313d0975ddeb156f4f59801da833f78b30 ]
    
    In function size_from_channelarray(), the return value 'bytes' is defined
    as int type. However, the calcution of 'bytes' in this function is designed
    to use the unsigned int type. So it is necessary to change 'bytes' type to
    unsigned int to avoid integer overflow.
    
    The size_from_channelarray() is called in main() function, its return value
    is directly multipled by 'buf_len' and then used as the malloc() parameter.
    The 'buf_len' is completely controllable by user, thus a multiplication
    overflow may occur here. This could allocate an unexpected small area.
    
    Signed-off-by: Chenyuan Mi <michenyuan@huawei.com>
    Link: https://lore.kernel.org/r/20230725092407.62545-1-michenyuan@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 2d3dff577dd0 ("tools: iio: iio_generic_buffer ensure alignment")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: iio: privatize globals and functions in iio_generic_buffer.c file [+ + +]
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Mon Feb 15 12:40:42 2021 +0200

    tools: iio: privatize globals and functions in iio_generic_buffer.c file
    
    [ Upstream commit ebe5112535b5cf389ca7d337cf6a0c1d885f9880 ]
    
    Mostly a tidy-up.
    But also helps to understand the limits of scope of these functions and
    globals.
    
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Link: https://lore.kernel.org/r/20210215104043.91251-24-alexandru.ardelean@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 2d3dff577dd0 ("tools: iio: iio_generic_buffer ensure alignment")
    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>

 
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>

 
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: 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>

 
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/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: Share definition of __is_canonical_address() [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Jan 31 09:24:50 2022 +0200

    x86: Share definition of __is_canonical_address()
    
    [ Upstream commit 1fb85d06ad6754796cd1b920639ca9d8840abefd ]
    
    Reduce code duplication by moving canonical address code to a common header
    file.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220131072453.2839535-3-adrian.hunter@intel.com
    Stable-dep-of: f79936545fb1 ("x86/sev-es: Allow copy_from_kernel_nofault() in earlier boot")
    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>

 
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>