óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 6.1.74

 
ACPI: resource: Add another DMI match for the TongFang GMxXGxx [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 23 15:57:06 2023 +0100

    ACPI: resource: Add another DMI match for the TongFang GMxXGxx
    
    commit df0cced74159c79e36ce7971f0bf250673296d93 upstream.
    
    The TongFang GMxXGxx, which needs IRQ overriding for the keyboard to work,
    is also sold as the Eluktronics RP-15 which does not use the standard
    TongFang GMxXGxx DMI board_name.
    
    Add an entry for this laptop to the irq1_edge_low_force_override[] DMI
    table to make the internal keyboard functional.
    
    Reported-by: Luis Acuna <ldacuna@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda - Fix speaker and headset mic pin config for CHUWI CoreBook XPro [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Fri Nov 17 20:09:23 2023 +0300

    ALSA: hda - Fix speaker and headset mic pin config for CHUWI CoreBook XPro
    
    [ Upstream commit 7c9caa299335df94ad1c58f70a22f16a540eab60 ]
    
    This patch corrected the speaker and headset mic pin config to the more
    appropriate values.
    
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20231117170923.106822-1-kovalev@altlinux.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Add quirks for ASUS Zenbook 2022 Models [+ + +]
Author: Stefan Binding <sbinding@opensource.cirrus.com>
Date:   Mon Dec 18 15:12:19 2023 +0000

    ALSA: hda/realtek: Add quirks for ASUS Zenbook 2022 Models
    
    [ Upstream commit 51d976079976c800ef19ed1b542602fcf63f0edb ]
    
    These models use 2xCS35L41amps with HDA using SPI and I2C.
    Models use internal and external boost.
    All models require DSD support to be added inside
    cs35l41_hda_property.c
    
    Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231218151221.388745-6-sbinding@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxx [+ + +]
Author: Tom Jason Schwanke <tom@catboys.cloud>
Date:   Mon Jan 8 16:15:21 2024 +0100

    ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxx
    
    commit 6b3d14b7f9b1acaf7303d8499836bf78ee9c470c upstream.
    
    This enables the mute and mic-mute LEDs on the HP Envy X360 13-ay0xxx
    convertibles.
    The quirk 'ALC245_FIXUP_HP_X360_MUTE_LEDS' already exists and is now
    enabled for this device.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216197
    Signed-off-by: Tom Jason Schwanke <tom@catboys.cloud>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/651b26e9-e86b-45dd-aa90-3e43d6b99823@catboys.cloud
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: intel-nhlt: Ignore vbps when looking for DMIC 32 bps format [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Mon Nov 27 13:16:58 2023 +0200

    ALSA: hda: intel-nhlt: Ignore vbps when looking for DMIC 32 bps format
    
    [ Upstream commit 7b4c93a50a2ebbbaf656cc4fa6aca74a6166d85b ]
    
    When looking up DMIC blob from the NHLT table and the format is 32 bits,
    ignore the vbps matching for 32 bps for DMIC since some NHLT table have
    the vbps as 24, some have it as 32.
    The DMIC hardware supports only one type of 32 bit sample size, which is
    24 bit sampling on the MSB side and bits[1:0] is used for indicating the
    channel number.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20231127111658.17275-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARC: fix spare error [+ + +]
Author: Vineet Gupta <vgupta@kernel.org>
Date:   Fri Dec 8 15:57:07 2023 -0800

    ARC: fix spare error
    
    [ Upstream commit aca02d933f63ba8bc84258bf35f9ffaf6b664336 ]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312082320.VDN5A9hb-lkp@intel.com/
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Thu Nov 30 13:18:29 2023 -0600

    arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru
    
    [ Upstream commit c13c823a78b77ea0e5f1f73112d910e259911101 ]
    
    The rk3399-gru PCI node addresses are wrong.
    
    In rk3399-gru-scarlet, the bus number in the address should be 0. This is
    because bus number assignment is dynamic and not known up front. For FDT,
    the bus number is simply ignored.
    
    In rk3399-gru-chromebook, the addresses are simply invalid. The first
    "reg" entry must be the configuration space for the device. The entry
    should be all 0s except for device/slot and function numbers. The existing
    64-bit memory space (0x83000000) entries are not valid because they must
    have the BAR address in the lower byte of the first cell.
    
    Warnings for these are enabled by adding the missing 'device_type = "pci"'
    for the root port node.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh@kernel.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix rk356x pcie msg interrupt name [+ + +]
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Tue Nov 14 16:38:34 2023 +0100

    arm64: dts: rockchip: fix rk356x pcie msg interrupt name
    
    [ Upstream commit 3cee9c635f27d1003d46f624d816f3455698b625 ]
    
    The expected name by the binding at this position is "msg" and the SoC's
    manual also calls the interrupt in question "msg", so fix the rk356x dtsi
    to use the correct name.
    
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://lore.kernel.org/r/20231114153834.934978-1-heiko@sntech.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: sun9i: smp: fix return code check of of_property_match_string [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Thu Dec 28 20:39:03 2023 +0100

    ARM: sun9i: smp: fix return code check of of_property_match_string
    
    [ Upstream commit 643fe70e7bcdcc9e2d96952f7fc2bab56385cce5 ]
    
    of_property_match_string returns an int; either an index from 0 or
    greater if successful or negative on failure. Even it's very
    unlikely that the DT CPU node contains multiple enable-methods
    these checks should be fixed.
    
    This patch was inspired by the work of Nick Desaulniers.
    
    Link: https://lore.kernel.org/lkml/20230516-sunxi-v1-1-ac4b9651a8c1@google.com/T/
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20231228193903.9078-2-wahrenst@gmx.net
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: yc: Add DMI entry to support System76 Pangolin 13 [+ + +]
Author: Jeremy Soller <jeremy@system76.com>
Date:   Mon Nov 27 11:42:38 2023 -0700

    ASoC: amd: yc: Add DMI entry to support System76 Pangolin 13
    
    [ Upstream commit 19650c0f402f53abe48a55a1c49c8ed9576a088c ]
    
    Add pang13 quirk to enable the internal microphone.
    
    Signed-off-by: Jeremy Soller <jeremy@system76.com>
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Link: https://lore.kernel.org/r/20231127184237.32077-2-tcrawford@system76.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs43130: Fix incorrect frame delay configuration [+ + +]
Author: Maciej Strozek <mstrozek@opensource.cirrus.com>
Date:   Fri Nov 17 14:13:39 2023 +0000

    ASoC: cs43130: Fix incorrect frame delay configuration
    
    [ Upstream commit aa7e8e5e4011571022dc06e4d7a2f108feb53d1a ]
    
    Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231117141344.64320-3-mstrozek@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs43130: Fix the position of const qualifier [+ + +]
Author: Maciej Strozek <mstrozek@opensource.cirrus.com>
Date:   Fri Nov 17 14:13:38 2023 +0000

    ASoC: cs43130: Fix the position of const qualifier
    
    [ Upstream commit e7f289a59e76a5890a57bc27b198f69f175f75d9 ]
    
    Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231117141344.64320-2-mstrozek@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: da7219: Support low DC impedance headset [+ + +]
Author: David Rau <David.Rau.opensource@dm.renesas.com>
Date:   Fri Dec 1 12:29:33 2023 +0800

    ASoC: da7219: Support low DC impedance headset
    
    [ Upstream commit 5f44de697383fcc9a9a1a78f99e09d1838704b90 ]
    
    Change the default MIC detection impedance threshold to 200ohm
    to support low mic DC impedance headset.
    
    Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com>
    Link: https://lore.kernel.org/r/20231201042933.26392-1-David.Rau.opensource@dm.renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: hdac_hda: Conditionally register dais for HDMI and Analog [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Nov 28 14:39:14 2023 +0200

    ASoC: hdac_hda: Conditionally register dais for HDMI and Analog
    
    [ Upstream commit a0575b4add21a243cc3257e75ad913cd5377d5f2 ]
    
    The current driver is registering the same dais for each hdev found in the
    system which results duplicated widgets to be registered and the kernel
    log contains similar prints:
    snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten
    snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Codec Output Pin1 overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec Input Pin1 overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Analog Codec Playback overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Digital Codec Playback overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt Analog Codec Playback overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Analog Codec Capture overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Digital Codec Capture overwritten
    skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt Analog Codec Capture overwritten
    
    To avoid such issue, split the dai array into HDMI and non HDMI array and
    register them conditionally:
    for HDMI hdev only register the dais needed for HDMI
    for non HDMI hdev do not  register the HDMI dais.
    
    Depends-on: 3d1dc8b1030d ("ASoC: Intel: skl_hda_dsp_generic: Drop HDMI routes when HDMI is not available")
    Link: https://github.com/thesofproject/linux/issues/4509
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20231128123914.3986-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: bytcr_rt5640: Add new swapped-speakers quirk [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Dec 17 22:32:21 2023 +0100

    ASoC: Intel: bytcr_rt5640: Add new swapped-speakers quirk
    
    [ Upstream commit b1b6131bca35a55a69fadc39d51577968fa2ee97 ]
    
    Some BYTCR x86 tablets with a rt5640 codec have the left and right channels
    of their speakers swapped.
    
    Add a new BYT_RT5640_SWAPPED_SPEAKERS quirk for this which sets
    cfg-spk:swapped in the components string to let userspace know
    about the swapping so that the UCM profile can configure the mixer
    to correct this.
    
    Enable this new quirk on the Medion Lifetab S10346 which has its
    speakers swapped.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://msgid.link/r/20231217213221.49424-2-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: bytcr_rt5640: Add quirk for the Medion Lifetab S10346 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Dec 17 22:32:20 2023 +0100

    ASoC: Intel: bytcr_rt5640: Add quirk for the Medion Lifetab S10346
    
    [ Upstream commit 99c7bb44f5749373bc01b73af02b50b69bcbf43d ]
    
    Add a quirk for the Medion Lifetab S10346, this BYTCR tablet has no CHAN
    package in its ACPI tables and uses SSP0-AIF1 rather then SSP0-AIF2 which
    is the default for BYTCR devices.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://msgid.link/r/20231217213221.49424-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: skl_hda_dsp_generic: Drop HDMI routes when HDMI is not available [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Fri Nov 24 14:40:15 2023 +0200

    ASoC: Intel: skl_hda_dsp_generic: Drop HDMI routes when HDMI is not available
    
    [ Upstream commit 3d1dc8b1030df8ca0fdfd4905c88ee10db943bf8 ]
    
    When the HDMI is not present due to disabled display support
    we will use dummy codec and the HDMI routes will refer to non existent
    DAPM widgets.
    
    Trim the route list from the HDMI routes to be able to probe the card even
    if the HDMI dais are not registered.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20231124124015.15878-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: Fix mem leak in few functions [+ + +]
Author: Kamil Duljas <kamil.duljas@gmail.com>
Date:   Thu Nov 16 13:51:50 2023 +0100

    ASoC: Intel: Skylake: Fix mem leak in few functions
    
    [ Upstream commit d5c65be34df73fa01ed05611aafb73b440d89e29 ]
    
    The resources should be freed when function return error.
    
    Signed-off-by: Kamil Duljas <kamil.duljas@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231116125150.1436-1-kamil.duljas@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: mem leak in skl register function [+ + +]
Author: Kamil Duljas <kamil.duljas@gmail.com>
Date:   Thu Nov 16 23:41:13 2023 +0100

    ASoC: Intel: Skylake: mem leak in skl register function
    
    [ Upstream commit f8ba14b780273fd290ddf7ee0d7d7decb44cc365 ]
    
    skl_platform_register() uses krealloc. When krealloc is fail,
    then previous memory is not freed. The leak is also when soc
    component registration failed.
    
    Signed-off-by: Kamil Duljas <kamil.duljas@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231116224112.2209-2-kamil.duljas@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16 [+ + +]
Author: David Lin <CTLIN0@nuvoton.com>
Date:   Fri Nov 17 12:30:12 2023 +0800

    ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16
    
    [ Upstream commit c1501f2597dd08601acd42256a4b0a0fc36bf302 ]
    
    This issue is reproduced when W=1 build in compiler gcc-12.
    The following are sparse warnings:
    
    sound/soc/codecs/nau8822.c:199:25: sparse: sparse: incorrect type in assignment
    sound/soc/codecs/nau8822.c:199:25: sparse: expected unsigned short
    sound/soc/codecs/nau8822.c:199:25: sparse: got restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202311122320.T1opZVkP-lkp@intel.com/
    Signed-off-by: David Lin <CTLIN0@nuvoton.com>
    Link: https://lore.kernel.org/r/20231117043011.1747594-1-CTLIN0@nuvoton.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: ops: add correct range check for limiting volume [+ + +]
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Dec 4 12:47:35 2023 +0000

    ASoC: ops: add correct range check for limiting volume
    
    [ Upstream commit fb9ad24485087e0f00d84bee7a5914640b2b9024 ]
    
    Volume can have ranges that start with negative values, ex: -84dB to
    +40dB. Apply correct range check in snd_soc_limit_volume before setting
    the platform_max. Without this patch, for example setting a 0dB limit on
    a volume range of -84dB to +40dB would fail.
    
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231204124736.132185-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5650: add mutex to avoid the jack detection failure [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Wed Nov 22 18:01:23 2023 +0800

    ASoC: rt5650: add mutex to avoid the jack detection failure
    
    [ Upstream commit cdba4301adda7c60a2064bf808e48fccd352aaa9 ]
    
    This patch adds the jd_mutex to protect the jack detection control flow.
    And only the headset type could check the button status.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Link: https://lore.kernel.org/r/20231122100123.2831753-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: hda-codec: Delay the codec device registration [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Thu Dec 7 11:54:25 2023 +0200

    ASoC: SOF: Intel: hda-codec: Delay the codec device registration
    
    commit c344ef36dbc2fe920ec7291b68b11fe867a2c8f6 upstream.
    
    The current code flow is:
    1. snd_hdac_device_register()
    2. set parameters needed by the hdac driver
    3. request_codec_module()
       the hdac driver is probed at this point
    
    During boot the codec drivers are not loaded when the hdac device is
    registered, it is going to be probed later when loading the codec module,
    which point the parameters are set.
    
    On module remove/insert
    rmmod snd_sof_pci_intel_tgl
    modprobe snd_sof_pci_intel_tgl
    
    The codec module remains loaded and the driver will be probed when the
    hdac device is created right away, before the parameters for the driver
    has been configured:
    
    1. snd_hdac_device_register()
       the hdac driver is probed at this point
    2. set parameters needed by the hdac driver
    3. request_codec_module()
       will be a NOP as the module is already loaded
    
    Move the snd_hdac_device_register() later, to be done right before
    requesting the codec module to make sure that the parameters are all set
    before the device is created:
    
    1. set parameters needed by the hdac driver
    2. snd_hdac_device_register()
    3. request_codec_module()
    
    This way at the hdac driver probe all parameters will be set in all cases.
    
    Link: https://github.com/thesofproject/linux/issues/4731
    Fixes: a0575b4add21 ("ASoC: hdac_hda: Conditionally register dais for HDMI and Analog")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20231207095425.19597-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/ZYvUIxtrqBQZbNlC@shine.dominikbrodowski.net
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218304
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: wm8974: Correct boost mixer inputs [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Mon Nov 13 15:59:16 2023 +0000

    ASoC: wm8974: Correct boost mixer inputs
    
    [ Upstream commit 37e6fd0cebf0b9f71afb38fd95b10408799d1f0b ]
    
    Bit 6 of INPPGA (INPPGAMUTE) does not control the Aux path, it controls
    the input PGA path, as can been seen from Figure 8 Input Boost Stage in
    the datasheet. Update the naming of things in the driver to match this
    and update the routing to also reflect this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231113155916.1741027-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: fix comment on binder_alloc_new_buf() return value [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:36 2023 +0000

    binder: fix comment on binder_alloc_new_buf() return value
    
    commit e1090371e02b601cbfcea175c2a6cc7c955fa830 upstream.
    
    Update the comments of binder_alloc_new_buf() to reflect that the return
    value of the function is now ERR_PTR(-errno) on failure.
    
    No functional changes in this patch.
    
    Cc: stable@vger.kernel.org
    Fixes: 57ada2fb2250 ("binder: add log information for binder transaction failures")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-8-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix trivial typo of binder_free_buf_locked() [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:35 2023 +0000

    binder: fix trivial typo of binder_free_buf_locked()
    
    commit 122a3c1cb0ff304c2b8934584fcfea4edb2fe5e3 upstream.
    
    Fix minor misspelling of the function in the comment section.
    
    No functional changes in this patch.
    
    Cc: stable@vger.kernel.org
    Fixes: 0f966cba95c7 ("binder: add flag to clear buffer on txn complete")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-7-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix use-after-free in shinker's callback [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:31 2023 +0000

    binder: fix use-after-free in shinker's callback
    
    commit 3f489c2067c5824528212b0fc18b28d51332d906 upstream.
    
    The mmap read lock is used during the shrinker's callback, which means
    that using alloc->vma pointer isn't safe as it can race with munmap().
    As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
    munmap") the mmap lock is downgraded after the vma has been isolated.
    
    I was able to reproduce this issue by manually adding some delays and
    triggering page reclaiming through the shrinker's debug sysfs. The
    following KASAN report confirms the UAF:
    
      ==================================================================
      BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
      Read of size 8 at addr ffff356ed50e50f0 by task bash/478
    
      CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       zap_page_range_single+0x470/0x4b8
       binder_alloc_free_page+0x608/0xadc
       __list_lru_walk_one+0x130/0x3b0
       list_lru_walk_node+0xc4/0x22c
       binder_shrink_scan+0x108/0x1dc
       shrinker_debugfs_scan_write+0x2b4/0x500
       full_proxy_write+0xd4/0x140
       vfs_write+0x1ac/0x758
       ksys_write+0xf0/0x1dc
       __arm64_sys_write+0x6c/0x9c
    
      Allocated by task 492:
       kmem_cache_alloc+0x130/0x368
       vm_area_alloc+0x2c/0x190
       mmap_region+0x258/0x18bc
       do_mmap+0x694/0xa60
       vm_mmap_pgoff+0x170/0x29c
       ksys_mmap_pgoff+0x290/0x3a0
       __arm64_sys_mmap+0xcc/0x144
    
      Freed by task 491:
       kmem_cache_free+0x17c/0x3c8
       vm_area_free_rcu_cb+0x74/0x98
       rcu_core+0xa38/0x26d4
       rcu_core_si+0x10/0x1c
       __do_softirq+0x2fc/0xd24
    
      Last potentially related work creation:
       __call_rcu_common.constprop.0+0x6c/0xba0
       call_rcu+0x10/0x1c
       vm_area_free+0x18/0x24
       remove_vma+0xe4/0x118
       do_vmi_align_munmap.isra.0+0x718/0xb5c
       do_vmi_munmap+0xdc/0x1fc
       __vm_munmap+0x10c/0x278
       __arm64_sys_munmap+0x58/0x7c
    
    Fix this issue by performing instead a vma_lookup() which will fail to
    find the vma that was isolated before the mmap lock downgrade. Note that
    this option has better performance than upgrading to a mmap write lock
    which would increase contention. Plus, mmap_write_trylock() has been
    recently removed anyway.
    
    Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
    Cc: stable@vger.kernel.org
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-3-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: use EPOLLERR from eventpoll.h [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:30 2023 +0000

    binder: use EPOLLERR from eventpoll.h
    
    commit 6ac061db9c58ca5b9270b1b3940d2464fb3ff183 upstream.
    
    Use EPOLLERR instead of POLLERR to make sure it is cast to the correct
    __poll_t type. This fixes the following sparse issue:
    
      drivers/android/binder.c:5030:24: warning: incorrect type in return expression (different base types)
      drivers/android/binder.c:5030:24:    expected restricted __poll_t
      drivers/android/binder.c:5030:24:    got int
    
    Fixes: f88982679f54 ("binder: check for binder_thread allocation failure in binder_poll()")
    Cc: stable@vger.kernel.org
    Cc: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-2-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
blk-mq: don't count completed flush data request as inflight in case of quiesce [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Dec 1 16:56:05 2023 +0800

    blk-mq: don't count completed flush data request as inflight in case of quiesce
    
    [ Upstream commit 0e4237ae8d159e3d28f3cd83146a46f576ffb586 ]
    
    Request queue quiesce may interrupt flush sequence, and the original request
    may have been marked as COMPLETE, but can't get finished because of
    queue quiesce.
    
    This way is fine from driver viewpoint, because flush sequence is block
    layer concept, and it isn't related with driver.
    
    However, driver(such as dm-rq) can call blk_mq_queue_inflight() to count &
    drain inflight requests, then the wait & drain never gets done because
    the completed & not-finished flush request is counted as inflight.
    
    Fix this issue by not counting completed flush data request as inflight in
    case of quiesce.
    
    Cc: Mike Snitzer <snitzer@kernel.org>
    Cc: David Jeffery <djeffery@redhat.com>
    Cc: John Pittman <jpittman@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20231201085605.577730-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add --skip_encoding_btf_inconsistent_proto, --btf_gen_optimized to pahole flags for v1.25 [+ + +]
Author: Alan Maguire <alan.maguire@oracle.com>
Date:   Wed May 10 14:02:41 2023 +0100

    bpf: Add --skip_encoding_btf_inconsistent_proto, --btf_gen_optimized to pahole flags for v1.25
    
    commit 7b99f75942da332e3f4f865e55a10fec95a30d4f upstream.
    
    v1.25 of pahole supports filtering out functions with multiple inconsistent
    function prototypes or optimized-out parameters from the BTF representation.
    These present problems because there is no additional info in BTF saying which
    inconsistent prototype matches which function instance to help guide attachment,
    and functions with optimized-out parameters can lead to incorrect assumptions
    about register contents.
    
    So for now, filter out such functions while adding BTF representations for
    functions that have "."-suffixes (foo.isra.0) but not optimized-out parameters.
    This patch assumes that below linked changes land in pahole for v1.25.
    
    Issues with pahole filtering being too aggressive in removing functions
    appear to be resolved now, but CI and further testing will confirm.
    
    Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20230510130241.1696561-1-alan.maguire@oracle.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btf, scripts: Exclude Rust CUs with pahole [+ + +]
Author: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Date:   Wed Jan 11 12:20:50 2023 -0300

    btf, scripts: Exclude Rust CUs with pahole
    
    commit c1177979af9c616661a126a80dd486ad0543b836 upstream.
    
    Version 1.24 of pahole has the capability to exclude compilation units (CUs)
    of specific languages [1] [2]. Rust, as of writing, is not currently supported
    by pahole and if it's used with a build that has BTF debugging enabled it
    results in malformed kernel and module binaries [3]. So it's better for pahole
    to exclude Rust CUs until support for it arrives.
    
    Co-developed-by: Eric Curtin <ecurtin@redhat.com>
    Signed-off-by: Eric Curtin <ecurtin@redhat.com>
    Signed-off-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Eric Curtin <ecurtin@redhat.com>
    Reviewed-by: Neal Gompa <neal@gompa.dev>
    Acked-by: Miguel Ojeda <ojeda@kernel.org>
    Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Link: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=49358dfe2aaae4e90b072332c3e324019826783f [1]
    Link: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=8ee363790b7437283c53090a85a9fec2f0b0fbc4 [2]
    Link: https://github.com/Rust-for-Linux/linux/issues/735 [3]
    Link: https://lore.kernel.org/bpf/20230111152050.559334-1-yakoyoku@gmail.com
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clk: rockchip: rk3128: Fix HCLK_OTG gate register [+ + +]
Author: Weihao Li <cn.liweihao@gmail.com>
Date:   Tue Oct 31 19:18:16 2023 +0800

    clk: rockchip: rk3128: Fix HCLK_OTG gate register
    
    [ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]
    
    The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.
    
    Signed-off-by: Weihao Li <cn.liweihao@gmail.com>
    Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: rockchip: rk3568: Add PLL rate for 292.5MHz [+ + +]
Author: Chris Morgan <macromorgan@hotmail.com>
Date:   Wed Oct 18 10:33:55 2023 -0500

    clk: rockchip: rk3568: Add PLL rate for 292.5MHz
    
    [ Upstream commit 1af27671f62ce919f1fb76082ed81f71cb090989 ]
    
    Add support for a PLL rate of 292.5MHz so that the Powkiddy RGB30 panel
    can run at a requested 60hz (59.96, close enough).
    
    I have confirmed this rate fits with all the constraints
    listed in the TRM for the VPLL (as an integer PLL) in Part 1 "Chapter
    2 Clock & Reset Unit (CRU)."
    
    Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
    Link: https://lore.kernel.org/r/20231018153357.343142-2-macroalpha82@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
coresight: etm4x: Fix width of CCITMIN field [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Nov 1 11:52:06 2023 +0000

    coresight: etm4x: Fix width of CCITMIN field
    
    commit cc0271a339cc70cae914c3ec20edc2a8058407da upstream.
    
    CCITMIN is a 12 bit field and doesn't fit in a u8, so extend it to u16.
    This probably wasn't an issue previously because values higher than 255
    never occurred.
    
    But since commit 4aff040bcc8d ("coresight: etm: Override TRCIDR3.CCITMIN
    on errata affected cpus"), a comparison with 256 was done to enable the
    errata, generating the following W=1 build error:
    
      coresight-etm4x-core.c:1188:24: error: result of comparison of
      constant 256 with expression of type 'u8' (aka 'unsigned char') is
      always false [-Werror,-Wtautological-constant-out-of-range-compare]
    
       if (drvdata->ccitmin == 256)
    
    Cc: stable@vger.kernel.org
    Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310302043.as36UFED-lkp@intel.com/
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: James Clark <james.clark@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20231101115206.70810-1-james.clark@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
debugfs: fix automount d_fsdata usage [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Nov 24 17:25:24 2023 +0100

    debugfs: fix automount d_fsdata usage
    
    [ Upstream commit 0ed04a1847a10297595ac24dc7d46b35fb35f90a ]
    
    debugfs_create_automount() stores a function pointer in d_fsdata,
    but since commit 7c8d469877b1 ("debugfs: add support for more
    elaborate ->d_fsdata") debugfs_release_dentry() will free it, now
    conditionally on DEBUGFS_FSDATA_IS_REAL_FOPS_BIT, but that's not
    set for the function pointer in automount. As a result, removing
    an automount dentry would attempt to free the function pointer.
    Luckily, the only user of this (tracing) never removes it.
    
    Nevertheless, it's safer if we just handle the fsdata in one way,
    namely either DEBUGFS_FSDATA_IS_REAL_FOPS_BIT or allocated. Thus,
    change the automount to allocate it, and use the real_fops in the
    data to indicate whether or not automount is filled, rather than
    adding a type tag. At least for now this isn't actually needed,
    but the next changes will require it.
    
    Also check in debugfs_file_get() that it gets only called
    on regular files, just to make things clearer.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm audit: fix Kconfig so DM_AUDIT depends on BLK_DEV_DM [+ + +]
Author: Mike Snitzer <snitzer@kernel.org>
Date:   Wed Dec 13 14:46:19 2023 -0500

    dm audit: fix Kconfig so DM_AUDIT depends on BLK_DEV_DM
    
    [ Upstream commit 6849302fdff126997765d16df355b73231f130d4 ]
    
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: get dprefclk ss info from integration info table [+ + +]
Author: Charlene Liu <charlene.liu@amd.com>
Date:   Wed Dec 6 17:14:48 2023 -0500

    drm/amd/display: get dprefclk ss info from integration info table
    
    [ Upstream commit 51e7b64690776a9981355428b537af9048308a95 ]
    
    [why & how]
    we have two SSC_En:
    we get ssc_info from dce_info for MPLL_SSC_EN.
    we used to call VBIOS cmdtbl's smu_info's SS persentage for DPRECLK SS info,
    is used for DP AUDIO and VBIOS' smu_info table was from systemIntegrationInfoTable.
    
    since dcn35 VBIOS removed smu_info, driver need to use integrationInfotable directly.
    
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Charlene Liu <charlene.liu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: update dcn315 lpddr pstate latency [+ + +]
Author: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Date:   Fri Nov 3 14:55:37 2023 -0400

    drm/amd/display: update dcn315 lpddr pstate latency
    
    [ Upstream commit c92da0403d373c03ea5c65c0260c7db6762013b0 ]
    
    [WHY/HOW]
    Increase the pstate latency to improve ac/dc transition
    
    Reviewed-by: Charlene Liu <charlene.liu@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Add NULL checks for function pointers [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Wed Nov 29 12:37:34 2023 +0530

    drm/amdgpu: Add NULL checks for function pointers
    
    [ Upstream commit 81577503efb49f4ad76af22f9941d72900ef4aab ]
    
    Check if function is implemented before making the call.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix cat debugfs amdgpu_regs_didt causes kernel null pointer [+ + +]
Author: Lu Yao <yaolu@kylinos.cn>
Date:   Thu Nov 23 09:22:34 2023 +0800

    drm/amdgpu: Fix cat debugfs amdgpu_regs_didt causes kernel null pointer
    
    [ Upstream commit 2161e09cd05a50d80736fe397145340d2e8f6c05 ]
    
    For 'AMDGPU_FAMILY_SI' family cards, in 'si_common_early_init' func, init
    'didt_rreg' and 'didt_wreg' to 'NULL'. But in func
    'amdgpu_debugfs_regs_didt_read/write', using 'RREG32_DIDT' 'WREG32_DIDT'
    lacks of relevant judgment. And other 'amdgpu_ip_block_version' that use
    these two definitions won't be added for 'AMDGPU_FAMILY_SI'.
    
    So, add null pointer judgment before calling.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Lu Yao <yaolu@kylinos.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/crtc: Fix uninit-value bug in drm_mode_setcrtc [+ + +]
Author: Ziqi Zhao <astrajoan@yahoo.com>
Date:   Fri Jul 21 09:14:46 2023 -0700

    drm/crtc: Fix uninit-value bug in drm_mode_setcrtc
    
    [ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
    
    The connector_set contains uninitialized values when allocated with
    kmalloc_array. However, in the "out" branch, the logic assumes that any
    element in connector_set would be equal to NULL if failed to
    initialize, which causes the bug reported by Syzbot. The fix is to use
    an extra variable to keep track of how many connectors are initialized
    indeed, and use that variable to decrease any refcounts in the "out"
    branch.
    
    Reported-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Signed-off-by: Ziqi Zhao <astrajoan@yahoo.com>
    Reported-and-tested-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Link: https://lore.kernel.org/r/20230721161446.8602-1-astrajoan@yahoo.com
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/crtc: fix uninitialized variable use [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Dec 8 15:12:38 2023 +0200

    drm/crtc: fix uninitialized variable use
    
    [ Upstream commit 6e455f5dcdd15fa28edf0ffb5b44d3508512dccf ]
    
    Commit 3823119b9c2b ("drm/crtc: Fix uninit-value bug in
    drm_mode_setcrtc") was supposed to fix use of an uninitialized variable,
    but introduced another.
    
    num_connectors is only initialized if crtc_req->count_connectors > 0,
    but it's used regardless. Fix it.
    
    Fixes: 3823119b9c2b ("drm/crtc: Fix uninit-value bug in drm_mode_setcrtc")
    Cc: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Cc: Ziqi Zhao <astrajoan@yahoo.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231208131238.2924571-1-jani.nikula@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos: fix a potential error pointer dereference [+ + +]
Author: Xiang Yang <xiangyang3@huawei.com>
Date:   Sat Aug 12 14:27:48 2023 +0800

    drm/exynos: fix a potential error pointer dereference
    
    [ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]
    
    Smatch reports the warning below:
    drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
    error: 'crtc' dereferencing possible ERR_PTR()
    
    The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
    which can not be used directly. Fix this by checking the return value
    before using it.
    
    Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/exynos: fix a wrong error checking [+ + +]
Author: Inki Dae <inki.dae@samsung.com>
Date:   Wed Nov 1 18:36:51 2023 +0900

    drm/exynos: fix a wrong error checking
    
    [ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]
    
    Fix a wrong error checking in exynos_drm_dma.c module.
    
    In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
    and iommu_get_domain_for_dev() functions are expected to return NULL as
    an error.
    
    However, the error checking is performed using the statement
    if(IS_ERR(mapping)), which doesn't provide a suitable error value.
    So check if 'mapping' is NULL, and if it is, return -ENODEV.
    
    This issue[1] was reported by Dan.
    
    Changelog v1:
    - fix build warning.
    
    [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
    
    Reported-by : Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: explicitly null-terminate the xattr list [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Nov 6 20:44:34 2023 -0800

    f2fs: explicitly null-terminate the xattr list
    
    commit e26b6d39270f5eab0087453d9b544189a38c8564 upstream.
    
    When setting an xattr, explicitly null-terminate the xattr list.  This
    eliminates the fragile assumption that the unused xattr space is always
    zeroed.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
HID: nintendo: fix initializer element is not constant error [+ + +]
Author: Ryan McClelland <rymcclel@gmail.com>
Date:   Thu Dec 14 09:25:41 2023 -0800

    HID: nintendo: fix initializer element is not constant error
    
    [ Upstream commit 0b7dd38c1c520b650a889a81919838671b689eb9 ]
    
    With gcc-7 builds, an error happens with the controller button values being
    defined as const. Change to a define.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312141227.C2h1IzfI-lkp@intel.com/
    
    Signed-off-by: Ryan McClelland <rymcclel@gmail.com>
    Reviewed-by: Daniel J. Ogorchock <djogorchock@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: nintendo: Prevent divide-by-zero on code [+ + +]
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Tue Dec 5 18:15:51 2023 -0300

    HID: nintendo: Prevent divide-by-zero on code
    
    [ Upstream commit 6eb04ca8c52e3f8c8ea7102ade81d642eee87f4a ]
    
    It was reported [0] that adding a generic joycon to the system caused
    a kernel crash on Steam Deck, with the below panic spew:
    
    divide error: 0000 [#1] PREEMPT SMP NOPTI
    [...]
    Hardware name: Valve Jupiter/Jupiter, BIOS F7A0119 10/24/2023
    RIP: 0010:nintendo_hid_event+0x340/0xcc1 [hid_nintendo]
    [...]
    Call Trace:
     [...]
     ? exc_divide_error+0x38/0x50
     ? nintendo_hid_event+0x340/0xcc1 [hid_nintendo]
     ? asm_exc_divide_error+0x1a/0x20
     ? nintendo_hid_event+0x307/0xcc1 [hid_nintendo]
     hid_input_report+0x143/0x160
     hidp_session_run+0x1ce/0x700 [hidp]
    
    Since it's a divide-by-0 error, by tracking the code for potential
    denominator issues, we've spotted 2 places in which this could happen;
    so let's guard against the possibility and log in the kernel if the
    condition happens. This is specially useful since some data that
    fills some denominators are read from the joycon HW in some cases,
    increasing the potential for flaws.
    
    [0] https://github.com/ValveSoftware/SteamOS/issues/1070
    
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Tested-by: Sam Lantinga <slouken@libsdl.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (corsair-psu) Fix probe when built-in [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Thu Dec 7 22:07:23 2023 +0100

    hwmon: (corsair-psu) Fix probe when built-in
    
    [ Upstream commit 307004e8b254ad28e150b63f299ab9caa4bc7c3e ]
    
    It seems that when the driver is built-in, the HID bus is
    initialized after the driver is loaded, which whould cause
    module_hid_driver() to fail.
    Fix this by registering the driver after the HID bus using
    late_initcall() in accordance with other hwmon HID drivers.
    
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20231207210723.222552-1-W_Armin@gmx.de
    [groeck: Dropped "compile tested" comment; the patch has been tested
     but the tester did not provide a Tested-by: tag]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwtracing: hisi_ptt: Don't try to attach a task [+ + +]
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Tue Oct 10 16:47:30 2023 +0800

    hwtracing: hisi_ptt: Don't try to attach a task
    
    [ Upstream commit aff787f64ad7cbb54614b51b82c682fe06411ef3 ]
    
    PTT is an uncore PMU and shouldn't be attached to any task. Block
    the usage in pmu::event_init().
    
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20231010084731.30450-5-yangyicong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwtracing: hisi_ptt: Handle the interrupt in hardirq context [+ + +]
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Tue Oct 10 16:47:28 2023 +0800

    hwtracing: hisi_ptt: Handle the interrupt in hardirq context
    
    [ Upstream commit e0dd27ad8af00f147ac3c9de88e0687986afc3ea ]
    
    Handle the trace interrupt in the hardirq context, make sure the irq
    core won't threaded it by declaring IRQF_NO_THREAD and userspace won't
    balance it by declaring IRQF_NOBALANCING. Otherwise we may violate the
    synchronization requirements of the perf core, referenced to the
    change of arm-ccn PMU
      commit 0811ef7e2f54 ("bus: arm-ccn: fix PMU interrupt flags").
    
    In the interrupt handler we mainly doing 2 things:
    - Copy the data from the local DMA buffer to the AUX buffer
    - Commit the data in the AUX buffer
    
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    [ Fixed commit description to suppress checkpatch warning ]
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20231010084731.30450-3-yangyicong@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: rk3x: fix potential spinlock recursion on poll [+ + +]
Author: Jensen Huang <jensenhuang@friendlyarm.com>
Date:   Thu Dec 7 16:21:59 2023 +0800

    i2c: rk3x: fix potential spinlock recursion on poll
    
    [ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]
    
    Possible deadlock scenario (on reboot):
    rk3x_i2c_xfer_common(polling)
        -> rk3x_i2c_wait_xfer_poll()
            -> rk3x_i2c_irq(0, i2c);
                --> spin_lock(&i2c->lock);
                ...
            <rk3x i2c interrupt>
            -> rk3x_i2c_irq(0, i2c);
                --> spin_lock(&i2c->lock); (deadlock here)
    
    Store the IRQ number and disable/enable it around the polling transfer.
    This patch has been tested on NanoPC-T4.
    
    Signed-off-by: Jensen Huang <jensenhuang@friendlyarm.com>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ida: Fix crash in ida_free when the bitmap is empty [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Dec 21 16:53:57 2023 +0000

    ida: Fix crash in ida_free when the bitmap is empty
    
    [ Upstream commit af73483f4e8b6f5c68c9aa63257bdd929a9c194a ]
    
    The IDA usually detects double-frees, but that detection failed to
    consider the case when there are no nearby IDs allocated and so we have a
    NULL bitmap rather than simply having a clear bit.  Add some tests to the
    test-suite to be sure we don't inadvertently reintroduce this problem.
    Unfortunately they're quite noisy so include a message to disregard
    the warnings.
    
    Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: atkbd - skip ATKBD_CMD_GETID in translated mode [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 24 19:59:24 2023 -0800

    Input: atkbd - skip ATKBD_CMD_GETID in translated mode
    
    [ Upstream commit 936e4d49ecbc8c404790504386e1422b599dec39 ]
    
    There have been multiple reports of keyboard issues on recent laptop models
    which can be worked around by setting i8042.dumbkbd, with the downside
    being this breaks the capslock LED.
    
    It seems that these issues are caused by recent laptops getting confused by
    ATKBD_CMD_GETID. Rather then adding and endless growing list of quirks for
    this, just skip ATKBD_CMD_GETID alltogether on laptops in translated mode.
    
    The main goal of sending ATKBD_CMD_GETID is to skip binding to ps/2
    mice/touchpads and those are never used in translated mode.
    
    Examples of laptop models which benefit from skipping ATKBD_CMD_GETID:
    
    * "HP Laptop 15s-fq2xxx", "HP laptop 15s-fq4xxx" and "HP Laptop 15-dy2xxx"
      models the kbd stops working for the first 2 - 5 minutes after boot
      (waiting for EC watchdog reset?)
    
    * On "HP Spectre x360 13-aw2xxx" atkbd fails to probe the keyboard
    
    * At least 9 different Lenovo models have issues with ATKBD_CMD_GETID, see:
      https://github.com/yescallop/atkbd-nogetid
    
    This has been tested on:
    
    1. A MSI B550M PRO-VDH WIFI desktop, where the i8042 controller is not
       in translated mode when no keyboard is plugged in and with a ps/2 kbd
       a "AT Translated Set 2 keyboard" /dev/input/event# node shows up
    
    2. A Lenovo ThinkPad X1 Yoga gen 8 (always has a translated set 2 keyboard)
    
    Reported-by: Shang Ye <yesh25@mail2.sysu.edu.cn>
    Closes: https://lore.kernel.org/linux-input/886D6167733841AE+20231017135318.11142-1-yesh25@mail2.sysu.edu.cn/
    Closes: https://github.com/yescallop/atkbd-nogetid
    Reported-by: gurevitch <mail@gurevit.ch>
    Closes: https://lore.kernel.org/linux-input/2iAJTwqZV6lQs26cTb38RNYqxvsink6SRmrZ5h0cBUSuf9NT0tZTsf9fEAbbto2maavHJEOP8GA1evlKa6xjKOsaskDhtJWxjcnrgPigzVo=@gurevit.ch/
    Reported-by: Egor Ignatov <egori@altlinux.org>
    Closes: https://lore.kernel.org/all/20210609073333.8425-1-egori@altlinux.org/
    Reported-by: Anton Zhilyaev <anton@cpp.in>
    Closes: https://lore.kernel.org/linux-input/20210201160336.16008-1-anton@cpp.in/
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2086156
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231115174625.7462-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: i8042 - add nomux quirk for Acer P459-G2-M [+ + +]
Author: Esther Shimanovich <eshimanovich@chromium.org>
Date:   Thu Nov 30 19:56:19 2023 +0000

    Input: i8042 - add nomux quirk for Acer P459-G2-M
    
    [ Upstream commit 335fe00319e030d481a54d5e0e68d50c5e672c0e ]
    
    After the laptop lid is opened, and the device resumes from S3 deep
    sleep, if the user presses a keyboard key while the screen is still black,
    the mouse and keyboard become unusable.
    
    Enabling this quirk prevents this behavior from occurring.
    
    Signed-off-by: Esther Shimanovich <eshimanovich@chromium.org>
    Link: https://lore.kernel.org/r/20231130195615.v2.1.Ibe78a9df97ecd18dc227a5cff67d3029631d9c11@changeid
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: psmouse - enable Synaptics InterTouch for ThinkPad L14 G1 [+ + +]
Author: José Pekkarinen <jose.pekkarinen@foxhound.fi>
Date:   Wed Nov 15 16:50:23 2023 +0000

    Input: psmouse - enable Synaptics InterTouch for ThinkPad L14 G1
    
    [ Upstream commit c1f342f35f820b33390571293498c3e2e9bc77ec ]
    
    Observed on dmesg of my laptop I see the following
    output:
    
    [   19.898700] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
    [   19.936057] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
    [   19.936076] psmouse serio1: synaptics: Your touchpad (PNP: LEN0411 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
    [   20.008901] psmouse serio1: synaptics: Touchpad model: 1, fw: 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board id: 3471, fw id: 2909640
    [   20.008925] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
    [   20.053344] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7
    [   20.397608] mousedev: PS/2 mouse device common for all mice
    
    This patch will add its pnp id to the smbus list to
    produce the setup of intertouch for the device.
    
    Signed-off-by: José Pekkarinen <jose.pekkarinen@foxhound.fi>
    Link: https://lore.kernel.org/r/20231114063607.71772-1-jose.pekkarinen@foxhound.fi
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: xpad - add Razer Wolverine V2 support [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Sat Nov 25 17:22:15 2023 +0100

    Input: xpad - add Razer Wolverine V2 support
    
    [ Upstream commit c3d1610345b79cbe29ef6ca04a4780eff0d360c7 ]
    
    Add the VID and PID of Razer Wolverine V2 to xpad_device.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Link: https://lore.kernel.org/r/20231125-razer-wolverine-v2-v1-1-979fe9f9288e@z3ntu.xyz
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jbd2: correct the printing of write_flags in jbd2_write_superblock() [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Wed Nov 29 19:47:39 2023 +0800

    jbd2: correct the printing of write_flags in jbd2_write_superblock()
    
    [ Upstream commit 85559227211020b270728104c3b89918f7af27ac ]
    
    The write_flags print in the trace of jbd2_write_superblock() is not
    real, so move the modification before the trace.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231129114740.2686201-1-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: fix soft lockup in journal_finish_inode_data_buffers() [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Dec 11 19:25:44 2023 +0800

    jbd2: fix soft lockup in journal_finish_inode_data_buffers()
    
    [ Upstream commit 6c02757c936063f0631b4e43fe156f8c8f1f351f ]
    
    There's issue when do io test:
    WARN: soft lockup - CPU#45 stuck for 11s! [jbd2/dm-2-8:4170]
    CPU: 45 PID: 4170 Comm: jbd2/dm-2-8 Kdump: loaded Tainted: G  OE
    Call trace:
     dump_backtrace+0x0/0x1a0
     show_stack+0x24/0x30
     dump_stack+0xb0/0x100
     watchdog_timer_fn+0x254/0x3f8
     __hrtimer_run_queues+0x11c/0x380
     hrtimer_interrupt+0xfc/0x2f8
     arch_timer_handler_phys+0x38/0x58
     handle_percpu_devid_irq+0x90/0x248
     generic_handle_irq+0x3c/0x58
     __handle_domain_irq+0x68/0xc0
     gic_handle_irq+0x90/0x320
     el1_irq+0xcc/0x180
     queued_spin_lock_slowpath+0x1d8/0x320
     jbd2_journal_commit_transaction+0x10f4/0x1c78 [jbd2]
     kjournald2+0xec/0x2f0 [jbd2]
     kthread+0x134/0x138
     ret_from_fork+0x10/0x18
    
    Analyzed informations from vmcore as follows:
    (1) There are about 5k+ jbd2_inode in 'commit_transaction->t_inode_list';
    (2) Now is processing the 855th jbd2_inode;
    (3) JBD2 task has TIF_NEED_RESCHED flag;
    (4) There's no pags in address_space around the 855th jbd2_inode;
    (5) There are some process is doing drop caches;
    (6) Mounted with 'nodioread_nolock' option;
    (7) 128 CPUs;
    
    According to informations from vmcore we know 'journal->j_list_lock' spin lock
    competition is fierce. So journal_finish_inode_data_buffers() maybe process
    slowly. Theoretically, there is scheduling point in the filemap_fdatawait_range_keep_errors().
    However, if inode's address_space has no pages which taged with PAGECACHE_TAG_WRITEBACK,
    will not call cond_resched(). So may lead to soft lockup.
    journal_finish_inode_data_buffers
      filemap_fdatawait_range_keep_errors
        __filemap_fdatawait_range
          while (index <= end)
            nr_pages = pagevec_lookup_range_tag(&pvec, mapping, &index, end, PAGECACHE_TAG_WRITEBACK);
            if (!nr_pages)
               break;    --> If 'nr_pages' is equal zero will break, then will not call cond_resched()
            for (i = 0; i < nr_pages; i++)
              wait_on_page_writeback(page);
            cond_resched();
    
    To solve above issue, add scheduling point in the journal_finish_inode_data_buffers();
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231211112544.3879780-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: increase the journal IO's priority [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Wed Nov 29 19:47:40 2023 +0800

    jbd2: increase the journal IO's priority
    
    [ Upstream commit 6a3afb6ac6dfab158ebdd4b87941178f58c8939f ]
    
    Current jbd2 only add REQ_SYNC for descriptor block, metadata log
    buffer, commit buffer and superblock buffer, the submitted IO could be
    throttled by writeback throttle in block layer, that could lead to
    priority inversion in some cases. The log IO looks like a kind of high
    priority metadata IO, so it should not be throttled by WBT like QOS
    policies in block layer, let's add REQ_SYNC | REQ_IDLE to exempt from
    writeback throttle, and also add REQ_META together indicates it's a
    metadata IO.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231129114740.2686201-2-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kselftest: alsa: fixed a print formatting warning [+ + +]
Author: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Date:   Sun Dec 17 13:30:19 2023 +0530

    kselftest: alsa: fixed a print formatting warning
    
    [ Upstream commit 13d605e32e4cfdedcecdf3d98d21710ffe887708 ]
    
    A statement used %d print formatter where %s should have
    been used. The same has been fixed in this commit.
    
    Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
    Link: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest")
    Link: https://lore.kernel.org/r/20231217080019.1063476-1-ghanshyam1898@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: don't allow O_TRUNC open on read-only share [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 7 21:24:07 2024 +0900

    ksmbd: don't allow O_TRUNC open on read-only share
    
    commit d592a9158a112d419f341f035d18d02f8d232def upstream.
    
    When file is changed using notepad on read-only share(read_only = yes in
    ksmbd.conf), There is a problem where existing data is truncated.
    notepad in windows try to O_TRUNC open(FILE_OVERWRITE_IF) and all data
    in file is truncated. This patch don't allow  O_TRUNC open on read-only
    share and add KSMBD_TREE_CONN_FLAG_WRITABLE check in smb2_set_info().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: free ppace array on error in parse_dacl [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Tue Jan 9 17:14:44 2024 +0300

    ksmbd: free ppace array on error in parse_dacl
    
    commit 8cf9bedfc3c47d24bb0de386f808f925dc52863e upstream.
    
    The ppace array is not freed if one of the init_acl_state() calls inside
    parse_dacl() fails. At the moment the function may fail only due to the
    memory allocation errors so it's highly unlikely in this case but
    nevertheless a fix is needed.
    
    Move ppace allocation after the init_acl_state() calls with proper error
    handling.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
leds: ledtrig-tty: Free allocated ttyname buffer on deactivate [+ + +]
Author: Florian Eckert <fe@dev.tdt.de>
Date:   Mon Nov 27 09:16:21 2023 +0100

    leds: ledtrig-tty: Free allocated ttyname buffer on deactivate
    
    commit 25054b232681c286fca9c678854f56494d1352cc upstream.
    
    The ttyname buffer for the ledtrig_tty_data struct is allocated in the
    sysfs ttyname_store() function. This buffer must be released on trigger
    deactivation. This was missing and is thus a memory leak.
    
    While we are at it, the TTY handler in the ledtrig_tty_data struct should
    also be returned in case of the trigger deactivation call.
    
    Cc: stable@vger.kernel.org
    Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
    Signed-off-by: Florian Eckert <fe@dev.tdt.de>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20231127081621.774866-1-fe@dev.tdt.de
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.1.74 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jan 20 11:50:11 2024 +0100

    Linux 6.1.74
    
    Link: https://lore.kernel.org/r/20240118104310.892180084@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Sven Joachim <svenjoac@gmx.de>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Preserve syscall nr across execve() [+ + +]
Author: Hengqi Chen <hengqi.chen@gmail.com>
Date:   Sat Dec 9 15:49:15 2023 +0800

    LoongArch: Preserve syscall nr across execve()
    
    [ Upstream commit d6c5f06e46a836e6a70c7cfd95bb38a67d9252ec ]
    
    Currently, we store syscall nr in pt_regs::regs[11] and syscall execve()
    accidentally overrides it during its execution:
    
        sys_execve()
          -> do_execve()
            -> do_execveat_common()
              -> bprm_execve()
                -> exec_binprm()
                  -> search_binary_handler()
                    -> load_elf_binary()
                      -> ELF_PLAT_INIT()
    
    ELF_PLAT_INIT() reset regs[11] to 0, so in syscall_exit_to_user_mode()
    we later get a wrong syscall nr. This breaks tools like execsnoop since
    it relies on execve() tracepoints.
    
    Skip pt_regs::regs[11] reset in ELF_PLAT_INIT() to fix the issue.
    
    Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: dts: loongson: drop incorrect dwmac fallback compatible [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Dec 11 18:33:54 2023 +0800

    MIPS: dts: loongson: drop incorrect dwmac fallback compatible
    
    [ Upstream commit 4907a3f54b12b8209864572a312cf967befcae80 ]
    
    Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
    so checking for some other compatible does not make sense.  It cannot be
    bound to unsupported platform.
    
    Drop useless, incorrect (space in between) and undocumented compatible.
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: fix uninit-value in mptcp_incoming_options [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Thu Nov 23 09:23:39 2023 +0800

    mptcp: fix uninit-value in mptcp_incoming_options
    
    [ Upstream commit 237ff253f2d4f6307b7b20434d7cbcc67693298b ]
    
    Added initialization use_ack to mptcp_parse_option().
    
    Reported-by: syzbot+b834a6b2decad004cfa1@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
neighbour: Don't let neigh_forced_gc() disable preemption for long [+ + +]
Author: Judy Hsiao <judyhsiao@chromium.org>
Date:   Wed Dec 6 03:38:33 2023 +0000

    neighbour: Don't let neigh_forced_gc() disable preemption for long
    
    [ Upstream commit e5dc5afff62f3e97e86c3643ec9fcad23de4f2d3 ]
    
    We are seeing cases where neigh_cleanup_and_release() is called by
    neigh_forced_gc() many times in a row with preemption turned off.
    When running on a low powered CPU at a low CPU frequency, this has
    been measured to keep preemption off for ~10 ms. That's not great on a
    system with HZ=1000 which expects tasks to be able to schedule in
    with ~1ms latency.
    
    Suggested-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/tg3: fix race condition in tg3_reset_task() [+ + +]
Author: Thinh Tran <thinhtr@linux.vnet.ibm.com>
Date:   Thu Nov 30 18:19:11 2023 -0600

    net/tg3: fix race condition in tg3_reset_task()
    
    [ Upstream commit 16b55b1f2269962fb6b5154b8bf43f37c9a96637 ]
    
    When an EEH error is encountered by a PCI adapter, the EEH driver
    modifies the PCI channel's state as shown below:
    
       enum {
          /* I/O channel is in normal state */
          pci_channel_io_normal = (__force pci_channel_state_t) 1,
    
          /* I/O to channel is blocked */
          pci_channel_io_frozen = (__force pci_channel_state_t) 2,
    
          /* PCI card is dead */
          pci_channel_io_perm_failure = (__force pci_channel_state_t) 3,
       };
    
    If the same EEH error then causes the tg3 driver's transmit timeout
    logic to execute, the tg3_tx_timeout() function schedules a reset
    task via tg3_reset_task_schedule(), which may cause a race condition
    between the tg3 and EEH driver as both attempt to recover the HW via
    a reset action.
    
    EEH driver gets error event
    --> eeh_set_channel_state()
        and set device to one of
        error state above           scheduler: tg3_reset_task() get
                                    returned error from tg3_init_hw()
                                 --> dev_close() shuts down the interface
    tg3_io_slot_reset() and
    tg3_io_resume() fail to
    reset/resume the device
    
    To resolve this issue, we avoid the race condition by checking the PCI
    channel state in the tg3_reset_task() function and skip the tg3 driver
    initiated reset when the PCI channel is not in the normal state.  (The
    driver has no access to tg3 device registers at this point and cannot
    even complete the reset task successfully without external assistance.)
    We'll leave the reset procedure to be managed by the EEH driver which
    calls the tg3_io_error_detected(), tg3_io_slot_reset() and
    tg3_io_resume() functions as appropriate.
    
    Adding the same checking in tg3_dump_state() to avoid dumping all
    device registers when the PCI channel is not in the normal state.
    
    Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com>
    Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com>
    Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20231201001911.656-1-thinhtr@linux.vnet.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: qrtr: ns: Return 0 if server port is not present [+ + +]
Author: Sarannya S <quic_sarannya@quicinc.com>
Date:   Thu Dec 21 15:36:51 2023 +0530

    net: qrtr: ns: Return 0 if server port is not present
    
    [ Upstream commit 9bf2e9165f90dc9f416af53c902be7e33930f728 ]
    
    When a 'DEL_CLIENT' message is received from the remote, the corresponding
    server port gets deleted. A DEL_SERVER message is then announced for this
    server. As part of handling the subsequent DEL_SERVER message, the name-
    server attempts to delete the server port which results in a '-ENOENT' error.
    The return value from server_del() is then propagated back to qrtr_ns_worker,
    causing excessive error prints.
    To address this, return 0 from control_cmd_del_server() without checking the
    return value of server_del(), since the above scenario is not an error case
    and hence server_del() doesn't have any other error return value.
    
    Signed-off-by: Sarannya Sasikumar <quic_sarannya@quicinc.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nouveau/tu102: flush all pdbs on vmm flush [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Nov 30 11:08:52 2023 +1000

    nouveau/tu102: flush all pdbs on vmm flush
    
    [ Upstream commit cb9c919364653eeafb49e7ff5cd32f1ad64063ac ]
    
    This is a hack around a bug exposed with the GSP code, I'm not sure
    what is happening exactly, but it appears some of our flushes don't
    result in proper tlb invalidation for out BAR2 and we get a BAR2
    fault from GSP and it all dies.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231130010852.4034774-1-airlied@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-core: check for too small lba shift [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue Nov 28 09:36:04 2023 -0800

    nvme-core: check for too small lba shift
    
    [ Upstream commit 74fbc88e161424b3b96a22b23a8e3e1edab9d05c ]
    
    The block layer doesn't support logical block sizes smaller than 512
    bytes. The nvme spec doesn't support that small either, but the driver
    isn't checking to make sure the device responded with usable data.
    Failing to catch this will result in a kernel bug, either from a
    division by zero when stacking, or a zero length bio.
    
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme-core: fix a memory leak in nvme_ns_info_from_identify() [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Thu Nov 23 15:07:41 2023 +0100

    nvme-core: fix a memory leak in nvme_ns_info_from_identify()
    
    [ Upstream commit e3139cef8257fcab1725441e2fd5fd0ccb5481b1 ]
    
    In case of error, free the nvme_id_ns structure that was allocated
    by nvme_identify_ns().
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: introduce helper function to get ctrl state [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Mon Oct 30 08:13:09 2023 -0700

    nvme: introduce helper function to get ctrl state
    
    [ Upstream commit 5c687c287c46fadb14644091823298875a5216aa ]
    
    The controller state is typically written by another CPU, so reading it
    should ensure no optimizations are taken. This is a repeated pattern in
    the driver, so start with adding a convenience function that returns the
    controller state with READ_ONCE().
    
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: prevent potential spectre v1 gadget [+ + +]
Author: Nitesh Shetty <nj.shetty@samsung.com>
Date:   Tue Nov 28 17:59:57 2023 +0530

    nvme: prevent potential spectre v1 gadget
    
    [ Upstream commit 20dc66f2d76b4a410df14e4675e373b718babc34 ]
    
    This patch fixes the smatch warning, "nvmet_ns_ana_grpid_store() warn:
    potential spectre issue 'nvmet_ana_group_enabled' [w] (local cap)"
    Prevent the contents of kernel memory from being leaked to  user space
    via speculative execution by using array_index_nospec.
    
    Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parport: parport_serial: Add Brainboxes BAR details [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Thu Nov 2 21:07:05 2023 +0000

    parport: parport_serial: Add Brainboxes BAR details
    
    commit 65fde134b0a4ffe838729f9ee11b459a2f6f2815 upstream.
    
    Add BAR/enum entries for Brainboxes serial/parallel cards.
    
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/r/AS4PR02MB79035155C2D5C3333AE6FA52C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parport: parport_serial: Add Brainboxes device IDs and geometry [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Thu Nov 2 21:07:06 2023 +0000

    parport: parport_serial: Add Brainboxes device IDs and geometry
    
    commit 6aa1fc5a8085bbc01687aa708dcf2dbe637a5ee3 upstream.
    
    Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475,
    IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry"
    for the cards.
    This patch requires part 1 of this series.
    
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: Add ACS quirk for more Zhaoxin Root Ports [+ + +]
Author: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
Date:   Mon Dec 11 17:15:43 2023 +0800

    PCI: Add ACS quirk for more Zhaoxin Root Ports
    
    commit e367e3c765f5477b2e79da0f1399aed49e2d1e37 upstream.
    
    Add more Root Port Device IDs to pci_quirk_zhaoxin_pcie_ports_acs() for
    some new Zhaoxin platforms.
    
    Fixes: 299bd044a6f3 ("PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports")
    Link: https://lore.kernel.org/r/20231211091543.735903-1-LeoLiu-oc@zhaoxin.com
    Signed-off-by: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
    [bhelgaas: update subject, drop changelog, add Fixes, add stable tag, fix
    whitespace, wrap code comment]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: <stable@vger.kernel.org>    # 5.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pinctrl: cy8c95x0: Fix get_pincfg [+ + +]
Author: Patrick Rudolph <patrick.rudolph@9elements.com>
Date:   Tue Dec 19 13:51:18 2023 +0100

    pinctrl: cy8c95x0: Fix get_pincfg
    
    [ Upstream commit 94c71705cc49092cef60ece13a28680809096fd4 ]
    
    Invert the register value for PIN_CONFIG_OUTPUT_ENABLE to return
    the opposite of PIN_CONFIG_INPUT_ENABLE.
    
    Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
    Link: https://lore.kernel.org/r/20231219125120.4028862-3-patrick.rudolph@9elements.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: cy8c95x0: Fix typo [+ + +]
Author: Patrick Rudolph <patrick.rudolph@9elements.com>
Date:   Tue Dec 19 13:51:16 2023 +0100

    pinctrl: cy8c95x0: Fix typo
    
    [ Upstream commit 47b1fa48116238208c1b1198dba10f56fc1b6eb2 ]
    
    Fix typo to make pinctrl-cy8c95x compile again.
    
    Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
    Link: https://lore.kernel.org/r/20231219125120.4028862-1-patrick.rudolph@9elements.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: lochnagar: Don't build on MIPS [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Wed Nov 15 16:28:53 2023 +0000

    pinctrl: lochnagar: Don't build on MIPS
    
    [ Upstream commit 6588732445ff19f6183f0fa72ddedf67e5a5be32 ]
    
    MIPS appears to define a RST symbol at a high level, which clashes
    with some register naming in the driver. Since there is currently
    no case for running this driver on MIPS devices simply cut off the
    build of this driver on MIPS.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202311071303.JJMAOjy4-lkp@intel.com/
    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231115162853.1891940-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: intel-vbtn: Fix missing tablet-mode-switch events [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 4 16:06:01 2023 +0100

    platform/x86: intel-vbtn: Fix missing tablet-mode-switch events
    
    [ Upstream commit 14c200b7ca46b9a9f4af9e81d258a58274320b6f ]
    
    2 issues have been reported on the Dell Inspiron 7352:
    
    1. Sometimes the tablet-mode-switch stops reporting tablet-mode
       change events.
    
       Add a "VBDL" call to notify_handler() to work around this.
    
    2. Sometimes the tablet-mode is incorrect after suspend/resume
    
       Add a detect_tablet_mode() to resume() to fix this.
    
    Reported-by: Arnold Gozum <arngozum@gmail.com>
    Closes: https://lore.kernel.org/platform-driver-x86/87271a74-c831-4eec-b7a4-1371d0e42471@gmail.com/
    Tested-by: Arnold Gozum <arngozum@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20231204150601.46976-1-hdegoede@redhat.com
    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: thinkpad_acpi: fix for incorrect fan reporting on some ThinkPad systems [+ + +]
Author: Vishnu Sankar <vishnuocv@gmail.com>
Date:   Thu Dec 14 22:47:02 2023 +0900

    platform/x86: thinkpad_acpi: fix for incorrect fan reporting on some ThinkPad systems
    
    [ Upstream commit 66e92e23a72761f5b53f970aeb1badc5fd92fc74 ]
    
    Some ThinkPad systems ECFW use non-standard addresses for fan control
    and reporting. This patch adds support for such ECFW so that it can report
    the correct fan values.
    Tested on Thinkpads L13 Yoga Gen 2 and X13 Yoga Gen 2.
    
    Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20231214134702.166464-1-vishnuocv@gmail.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Aug 10 11:13:00 2023 +0200

    reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning
    
    [ Upstream commit b5ec294472794ed9ecba0cb4b8208372842e7e0d ]
    
    'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
    causes:
    
      hi6220_reset.c:166:9: error: cast to smaller integer type 'enum hi6220_reset_ctrl_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230810091300.70197-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" [+ + +]
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Wed Nov 8 10:22:16 2023 -0800

    Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"
    
    commit bed9e27baf52a09b7ba2a3714f1e24e17ced386d upstream.
    
    This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74.
    
    That commit introduced the following race and can cause system hung.
    
     md_write_start:             raid5d:
     // mddev->in_sync == 1
     set "MD_SB_CHANGE_PENDING"
                                // running before md_write_start wakeup it
                                 waiting "MD_SB_CHANGE_PENDING" cleared
                                 >>>>>>>>> hung
     wakeup mddev->thread
     ...
     waiting "MD_SB_CHANGE_PENDING" cleared
     >>>> hung, raid5d should clear this flag
     but get hung by same flag.
    
    The issue reverted commit fixing is fixed by last patch in a new way.
    
    Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d")
    Cc: stable@vger.kernel.org # v5.19+
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20231108182216.73611-2-junxiao.bi@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Dec 13 17:54:03 2023 -0500

    ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI
    
    [ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
    
    As the ring buffer recording requires cmpxchg() to work, if the
    architecture does not support cmpxchg in NMI, then do not do any recording
    within an NMI.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231213175403.6fc18540@gandalf.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/scm: fix virtual vs physical address confusion [+ + +]
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Thu Nov 23 22:52:53 2023 +0100

    s390/scm: fix virtual vs physical address confusion
    
    [ Upstream commit b1a6a1a77f0666a5a6dc0893ab6ec8fcae46f24c ]
    
    Fix virtual vs physical address confusion (which currently are the same).
    
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/decode_stacktrace.sh: optionally use LLVM utilities [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Sep 29 03:48:17 2023 +0000

    scripts/decode_stacktrace.sh: optionally use LLVM utilities
    
    commit efbd6398353315b7018e6943e41fee9ec35e875f upstream.
    
    GNU's addr2line can have problems parsing a vmlinux built with LLVM,
    particularly when LTO was used.  In order to decode the traces correctly
    this patch adds the ability to switch to LLVM's utilities readelf and
    addr2line.  The same approach is followed by Will in [1].
    
    Before:
      $ scripts/decode_stacktrace.sh vmlinux < kernel.log
      [17716.240635] Call trace:
      [17716.240646] skb_cow_data (??:?)
      [17716.240654] esp6_input (ld-temp.o:?)
      [17716.240666] xfrm_input (ld-temp.o:?)
      [17716.240674] xfrm6_rcv (??:?)
      [...]
    
    After:
      $ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log
      [17716.240635] Call trace:
      [17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503)
      [17716.240654] esp6_input (net/ipv6/esp6.c:977)
      [17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659)
      [17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172)
      [...]
    
    Note that one could set CROSS_COMPILE=llvm- instead to hack around this
    issue.  However, doing so can break the decodecode routine as it will
    force the selection of other LLVM utilities down the line e.g.  llvm-as.
    
    [1] https://lore.kernel.org/all/20230914131225.13415-3-will@kernel.org/
    
    Link: https://lkml.kernel.org/r/20230929034836.403735-1-cmllamas@google.com
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
    Tested-by: Justin Stitt <justinstitt@google.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: John Stultz <jstultz@google.com>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Tom Rix <trix@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb: client, common: fix fortify warnings [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Nov 28 13:53:47 2023 +0300

    smb: client, common: fix fortify warnings
    
    [ Upstream commit 0015eb6e12384ff1c589928e84deac2ad1ceb236 ]
    
    When compiling with gcc version 14.0.0 20231126 (experimental)
    and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
    
    In file included from ./include/linux/string.h:295,
                     from ./include/linux/bitmap.h:12,
                     from ./include/linux/cpumask.h:12,
                     from ./arch/x86/include/asm/paravirt.h:17,
                     from ./arch/x86/include/asm/cpuid.h:62,
                     from ./arch/x86/include/asm/processor.h:19,
                     from ./arch/x86/include/asm/cpufeature.h:5,
                     from ./arch/x86/include/asm/thread_info.h:53,
                     from ./include/linux/thread_info.h:60,
                     from ./arch/x86/include/asm/preempt.h:9,
                     from ./include/linux/preempt.h:79,
                     from ./include/linux/spinlock.h:56,
                     from ./include/linux/wait.h:9,
                     from ./include/linux/wait_bit.h:8,
                     from ./include/linux/fs.h:6,
                     from fs/smb/client/smb2pdu.c:18:
    In function 'fortify_memcpy_chk',
        inlined from '__SMB2_close' at fs/smb/client/smb2pdu.c:3480:4:
    ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
    declared with attribute warning: detected read beyond size of field (2nd parameter);
    maybe use struct_group()? [-Wattribute-warning]
      588 |                         __read_overflow2_field(q_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    and:
    
    In file included from ./include/linux/string.h:295,
                     from ./include/linux/bitmap.h:12,
                     from ./include/linux/cpumask.h:12,
                     from ./arch/x86/include/asm/paravirt.h:17,
                     from ./arch/x86/include/asm/cpuid.h:62,
                     from ./arch/x86/include/asm/processor.h:19,
                     from ./arch/x86/include/asm/cpufeature.h:5,
                     from ./arch/x86/include/asm/thread_info.h:53,
                     from ./include/linux/thread_info.h:60,
                     from ./arch/x86/include/asm/preempt.h:9,
                     from ./include/linux/preempt.h:79,
                     from ./include/linux/spinlock.h:56,
                     from ./include/linux/wait.h:9,
                     from ./include/linux/wait_bit.h:8,
                     from ./include/linux/fs.h:6,
                     from fs/smb/client/cifssmb.c:17:
    In function 'fortify_memcpy_chk',
        inlined from 'CIFS_open' at fs/smb/client/cifssmb.c:1248:3:
    ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
    declared with attribute warning: detected read beyond size of field (2nd parameter);
    maybe use struct_group()? [-Wattribute-warning]
      588 |                         __read_overflow2_field(q_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    In both cases, the fortification logic inteprets calls to 'memcpy()' as an
    attempts to copy an amount of data which exceeds the size of the specified
    field (i.e. more than 8 bytes from __le64 value) and thus issues an overread
    warning. Both of these warnings may be silenced by using the convenient
    'struct_group()' quirk.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smb: client: fix potential OOB in smb2_dump_detail() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Tue Dec 19 13:10:31 2023 -0300

    smb: client: fix potential OOB in smb2_dump_detail()
    
    [ Upstream commit 567320c46a60a3c39b69aa1df802d753817a3f86 ]
    
    Validate SMB message with ->check_message() before calling
    ->calc_smb_size().
    
    This fixes CVE-2023-6610.
    
    Reported-by: j51569436@gmail.com
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218219
    Cc; stable@vger.kernel.org
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
stmmac: dwmac-loongson: drop useless check for compatible fallback [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Dec 11 18:33:53 2023 +0800

    stmmac: dwmac-loongson: drop useless check for compatible fallback
    
    [ Upstream commit 31fea092c6f9f8fb2c40a08137907f5fbeae55dd ]
    
    Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
    so checking for some other compatible does not make sense.  It cannot be
    bound to unsupported platform.
    
    Drop useless, incorrect (space in between) and undocumented compatible.
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: Add size check when printing trace_marker output [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Dec 12 08:44:44 2023 -0500

    tracing: Add size check when printing trace_marker output
    
    [ Upstream commit 60be76eeabb3d83858cc6577fc65c7d0f36ffd42 ]
    
    If for some reason the trace_marker write does not have a nul byte for the
    string, it will overflow the print:
    
      trace_seq_printf(s, ": %s", field->buf);
    
    The field->buf could be missing the nul byte. To prevent overflow, add the
    max size that the buf can be by using the event size and the field
    location.
    
      int max = iter->ent_size - offsetof(struct print_entry, buf);
    
      trace_seq_printf(s, ": %*.s", max, field->buf);
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231212084444.4619b8ce@gandalf.local.home
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Fix uaf issue when open the hist or hist_debug file [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Thu Dec 14 09:21:53 2023 +0800

    tracing: Fix uaf issue when open the hist or hist_debug file
    
    [ Upstream commit 1cc111b9cddc71ce161cd388f11f0e9048edffdb ]
    
    KASAN report following issue. The root cause is when opening 'hist'
    file of an instance and accessing 'trace_event_file' in hist_show(),
    but 'trace_event_file' has been freed due to the instance being removed.
    'hist_debug' file has the same problem. To fix it, call
    tracing_{open,release}_file_tr() in file_operations callback to have
    the ref count and avoid 'trace_event_file' being freed.
    
      BUG: KASAN: slab-use-after-free in hist_show+0x11e0/0x1278
      Read of size 8 at addr ffff242541e336b8 by task head/190
    
      CPU: 4 PID: 190 Comm: head Not tainted 6.7.0-rc5-g26aff849438c #133
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       dump_backtrace+0x98/0xf8
       show_stack+0x1c/0x30
       dump_stack_lvl+0x44/0x58
       print_report+0xf0/0x5a0
       kasan_report+0x80/0xc0
       __asan_report_load8_noabort+0x1c/0x28
       hist_show+0x11e0/0x1278
       seq_read_iter+0x344/0xd78
       seq_read+0x128/0x1c0
       vfs_read+0x198/0x6c8
       ksys_read+0xf4/0x1e0
       __arm64_sys_read+0x70/0xa8
       invoke_syscall+0x70/0x260
       el0_svc_common.constprop.0+0xb0/0x280
       do_el0_svc+0x44/0x60
       el0_svc+0x34/0x68
       el0t_64_sync_handler+0xb8/0xc0
       el0t_64_sync+0x168/0x170
    
      Allocated by task 188:
       kasan_save_stack+0x28/0x50
       kasan_set_track+0x28/0x38
       kasan_save_alloc_info+0x20/0x30
       __kasan_slab_alloc+0x6c/0x80
       kmem_cache_alloc+0x15c/0x4a8
       trace_create_new_event+0x84/0x348
       __trace_add_new_event+0x18/0x88
       event_trace_add_tracer+0xc4/0x1a0
       trace_array_create_dir+0x6c/0x100
       trace_array_create+0x2e8/0x568
       instance_mkdir+0x48/0x80
       tracefs_syscall_mkdir+0x90/0xe8
       vfs_mkdir+0x3c4/0x610
       do_mkdirat+0x144/0x200
       __arm64_sys_mkdirat+0x8c/0xc0
       invoke_syscall+0x70/0x260
       el0_svc_common.constprop.0+0xb0/0x280
       do_el0_svc+0x44/0x60
       el0_svc+0x34/0x68
       el0t_64_sync_handler+0xb8/0xc0
       el0t_64_sync+0x168/0x170
    
      Freed by task 191:
       kasan_save_stack+0x28/0x50
       kasan_set_track+0x28/0x38
       kasan_save_free_info+0x34/0x58
       __kasan_slab_free+0xe4/0x158
       kmem_cache_free+0x19c/0x508
       event_file_put+0xa0/0x120
       remove_event_file_dir+0x180/0x320
       event_trace_del_tracer+0xb0/0x180
       __remove_instance+0x224/0x508
       instance_rmdir+0x44/0x78
       tracefs_syscall_rmdir+0xbc/0x140
       vfs_rmdir+0x1cc/0x4c8
       do_rmdir+0x220/0x2b8
       __arm64_sys_unlinkat+0xc0/0x100
       invoke_syscall+0x70/0x260
       el0_svc_common.constprop.0+0xb0/0x280
       do_el0_svc+0x44/0x60
       el0_svc+0x34/0x68
       el0t_64_sync_handler+0xb8/0xc0
       el0t_64_sync+0x168/0x170
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231214012153.676155-1-zhengyejian1@huawei.com
    
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Dec 9 17:10:58 2023 -0500

    tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing
    
    [ Upstream commit b55b0a0d7c4aa2dac3579aa7e6802d1f57445096 ]
    
    If a large event was added to the ring buffer that is larger than what the
    trace_seq can handle, it just drops the output:
    
     ~# cat /sys/kernel/tracing/trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 2/2   #P:8
     #
     #                                _-----=> irqs-off/BH-disabled
     #                               / _----=> need-resched
     #                              | / _---=> hardirq/softirq
     #                              || / _--=> preempt-depth
     #                              ||| / _-=> migrate-disable
     #                              |||| /     delay
     #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
     #              | |         |   |||||     |         |
                <...>-859     [001] .....   141.118951: tracing_mark_write           <...>-859     [001] .....   141.148201: tracing_mark_write: 78901234
    
    Instead, catch this case and add some context:
    
     ~# cat /sys/kernel/tracing/trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 2/2   #P:8
     #
     #                                _-----=> irqs-off/BH-disabled
     #                               / _----=> need-resched
     #                              | / _---=> hardirq/softirq
     #                              || / _--=> preempt-depth
     #                              ||| / _-=> migrate-disable
     #                              |||| /     delay
     #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
     #              | |         |   |||||     |         |
                <...>-852     [001] .....   121.550551: tracing_mark_write[LINE TOO BIG]
                <...>-852     [001] .....   121.550581: tracing_mark_write: 78901234
    
    This now emulates the same output as trace_pipe.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231209171058.78c1a026@gandalf.local.home
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
uio: Fix use-after-free in uio_open [+ + +]
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>
Date:   Thu Dec 21 17:57:43 2023 +0800

    uio: Fix use-after-free in uio_open
    
    commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream.
    
    core-1                          core-2
    -------------------------------------------------------
    uio_unregister_device           uio_open
                                    idev = idr_find()
    device_unregister(&idev->dev)
    put_device(&idev->dev)
    uio_device_release
                                    get_device(&idev->dev)
    kfree(idev)
    uio_free_minor(minor)
                                    uio_release
                                    put_device(&idev->dev)
                                    kfree(idev)
    -------------------------------------------------------
    
    In the core-1 uio_unregister_device(), the device_unregister will kfree
    idev when the idev->dev kobject ref is 1. But after core-1
    device_unregister, put_device and before doing kfree, the core-2 may
    get_device. Then:
    1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
    2. When core-2 do uio_release and put_device, the idev will be double
       freed.
    
    To address this issue, we can get idev atomic & inc idev reference with
    minor_lock.
    
    Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtio_blk: fix snprintf truncation compiler warning [+ + +]
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Mon Dec 4 09:07:43 2023 -0500

    virtio_blk: fix snprintf truncation compiler warning
    
    [ Upstream commit b8e0792449928943c15d1af9f63816911d139267 ]
    
    Commit 4e0400525691 ("virtio-blk: support polling I/O") triggers the
    following gcc 13 W=1 warnings:
    
    drivers/block/virtio_blk.c: In function ‘init_vq’:
    drivers/block/virtio_blk.c:1077:68: warning: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 7 [-Wformat-truncation=]
     1077 |                 snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
          |                                                                    ^~
    drivers/block/virtio_blk.c:1077:58: note: directive argument in the range [-2147483648, 65534]
     1077 |                 snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
          |                                                          ^~~~~~~~~~~~~
    drivers/block/virtio_blk.c:1077:17: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 16
     1077 |                 snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This is a false positive because the lower bound -2147483648 is
    incorrect. The true range of i is [0, num_vqs - 1] where 0 < num_vqs <
    65536.
    
    The code mixes int, unsigned short, and unsigned int types in addition
    to using "%d" for an unsigned value. Use unsigned short and "%u"
    consistently to solve the compiler warning.
    
    Cc: Suwan Kim <suwan.kim027@gmail.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312041509.DIyvEt9h-lkp@intel.com/
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Message-Id: <20231204140743.1487843-1-stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: avoid offset calculation on NULL pointer [+ + +]
Author: Michael-CY Lee <michael-cy.lee@mediatek.com>
Date:   Wed Nov 22 11:02:37 2023 +0800

    wifi: avoid offset calculation on NULL pointer
    
    [ Upstream commit ef5828805842204dd0259ecfc132b5916c8a77ae ]
    
    ieee80211_he_6ghz_oper() can be passed a NULL pointer
    and checks for that, but already did the calculation
    to inside of it before. Move it after the check.
    
    Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
    Link: https://lore.kernel.org/r/20231122030237.31276-1-michael-cy.lee@mediatek.com
    [rewrite commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: lock wiphy mutex for rfkill poll [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Nov 8 13:41:25 2023 +0100

    wifi: cfg80211: lock wiphy mutex for rfkill poll
    
    [ Upstream commit 8e2f6f2366219b3304b227bdd2f04b64c92e3e12 ]
    
    We want to guarantee the mutex is held for pretty much
    all operations, so ensure that here as well.
    
    Reported-by: syzbot+7e59a5bfc7a897247e18@syzkaller.appspotmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: pcie: avoid a NULL pointer dereference [+ + +]
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Thu Dec 7 04:50:17 2023 +0200

    wifi: iwlwifi: pcie: avoid a NULL pointer dereference
    
    [ Upstream commit ce038edfce43fb345f8dfdca0f7b17f535896701 ]
    
    It possible that while the rx rb is being handled, the transport has
    been stopped and re-started. In this case the tx queue pointer is not
    yet initialized, which will lead to a NULL pointer dereference.
    Fix it.
    
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231207044813.cd0898cafd89.I0b84daae753ba9612092bf383f5c6f761446e964@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: handle 320 MHz in ieee80211_ht_cap_ie_to_sta_ht_cap [+ + +]
Author: Ben Greear <greearb@candelatech.com>
Date:   Thu Nov 9 10:22:01 2023 -0800

    wifi: mac80211: handle 320 MHz in ieee80211_ht_cap_ie_to_sta_ht_cap
    
    [ Upstream commit 00f7d153f3358a7c7e35aef66fcd9ceb95d90430 ]
    
    The new 320 MHz channel width wasn't handled, so connecting
    a station to a 320 MHz AP would limit the station to 20 MHz
    (on HT) after a warning, handle 320 MHz to fix that.
    
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Link: https://lore.kernel.org/r/20231109182201.495381-1-greearb@candelatech.com
    [write a proper commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>