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

 
ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Sep 20 15:05:06 2023 +0200

    ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx
    
    commit cd4aece493f99f95d41edcce32927d70a5dde923 upstream.
    
    Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx.
    There is a quirk entry for 2 15-c..... laptops, this is
    for a new version which has 15-dk1xxx as identifier.
    
    This fixes the LID switch and rfkill and brightness hotkeys
    not working.
    
    Closes: https://github.com/systemd/systemd/issues/28942
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Sep 12 12:08:27 2023 +0200

    ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA
    
    commit c1ed72171ed580fbf159e703b77685aa4b0d0df5 upstream.
    
    Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA
    has an ACPI DSDT table that describes IRQ 1 as ActiveLow while
    the kernel overrides it to EdgeHigh.
    
    This prevents the keyboard from working. To fix this issue, add this laptop
    to the skip_override_table so that the kernel does not override IRQ 1.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901
    Cc: [email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ALSA: hda/realtek - ALC287 I2S speaker platform support [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Wed Sep 6 16:50:41 2023 +0800

    ALSA: hda/realtek - ALC287 I2S speaker platform support
    
    [ Upstream commit e43252db7e207a2e194e6a4883a43a31a776a968 ]
    
    0x17 was only speaker pin, DAC assigned will be 0x03. Headphone
    assigned to 0x02.
    Playback via headphone will get EQ filter processing. So,it needs to
    swap DAC.
    
    Tested-by: Mark Pearson <[email protected]>
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Thu Sep 21 15:20:41 2023 +0800

    ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP
    
    [ Upstream commit d93eeca627db512a56145285dc94feac5b88a1d4 ]
    
    This is merge model ALC287_FIXUP_THINKPAD_I2S_SPK and
    ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Fixes: f7b069cf0881 ("ALSA: hda/realtek: Fix generic fixup definition for cs35l41 amp")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek - Fixed two speaker platform [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Tue Sep 12 15:31:49 2023 +0800

    ALSA: hda/realtek - Fixed two speaker platform
    
    commit fb6254df09bba303db2a1002085f6c0b90a456ed upstream.
    
    If system has two speakers and one connect to 0x14 pin, use this
    function will disable it.
    
    Fixes: e43252db7e20 ("ALSA: hda/realtek - ALC287 I2S speaker platform support")
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add quirk for HP Victus 16-d1xxx to enable mute LED [+ + +]
Author: SungHwan Jung <[email protected]>
Date:   Wed Aug 23 20:40:51 2023 +0900

    ALSA: hda/realtek: Add quirk for HP Victus 16-d1xxx to enable mute LED
    
    [ Upstream commit 93dc18e11b1ab2d485b69f91c973e6b83e47ebd0 ]
    
    This quirk enables mute LED on HP Victus 16-d1xxx (8A25) laptops, which
    use ALC245 codec.
    
    Signed-off-by: SungHwan Jung <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek: Add quirk for mute LEDs on HP ENVY x360 15-eu0xxx [+ + +]
Author: Fabian Vogt <[email protected]>
Date:   Thu Aug 24 20:39:48 2023 +0200

    ALSA: hda/realtek: Add quirk for mute LEDs on HP ENVY x360 15-eu0xxx
    
    [ Upstream commit c99c26b16c1544534ebd6a5f27a034f3e44d2597 ]
    
    The LED for the mic mute button is controlled by GPIO2.
    The mute button LED is slightly more complex, it's controlled by two bits
    in coeff 0x0b.
    
    Signed-off-by: Fabian Vogt <[email protected]>
    Link: https://lore.kernel.org/r/2693091.mvXUDI8C0e@fabians-envy
    Signed-off-by: Takashi Iwai <[email protected]>
    Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek: Change model for Intel RVP board [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Fri Oct 6 14:47:37 2023 +0800

    ALSA: hda/realtek: Change model for Intel RVP board
    
    commit ccbd88be057a38531f835e8a04948ebf80cb0c5d upstream.
    
    Intel RVP board (0x12cc) has Headset Mic issue for reboot.
    If system plugged headset when system reboot the headset Mic was gone.
    
    Fixes: 1a93f10c5b12 ("ALSA: hda/realtek: Add "Intel Reference board" and "NUC 13" SSID in the ALC256")
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: usb-audio: Fix microphone sound on Nexigo webcam. [+ + +]
Author: Christos Skevis <[email protected]>
Date:   Fri Oct 6 17:53:30 2023 +0200

    ALSA: usb-audio: Fix microphone sound on Nexigo webcam.
    
    commit 4a63e68a295187ae3c1cb3fa0c583c96a959714f upstream.
    
    I own an external usb Webcam, model NexiGo N930AF, which had low mic volume and
    inconsistent sound quality. Video works as expected.
    
    (snip)
    [  +0.047857] usb 5-1: new high-speed USB device number 2 using xhci_hcd
    [  +0.003406] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17
    [  +0.000007] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [  +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam
    [  +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD
    [  +0.000004] usb 5-1: SerialNumber: 20201217011
    [  +0.003900] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283)
    [  +0.025726] usb 5-1: 3:1: cannot get usb sound sample rate freq at ep 0x86
    [  +0.071482] usb 5-1: 3:2: cannot get usb sound sample rate freq at ep 0x86
    [  +0.004679] usb 5-1: 3:3: cannot get usb sound sample rate freq at ep 0x86
    [  +0.051607] usb 5-1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong.
    [  +0.000005] usb 5-1: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1
    
    Set up quirk cval->res to 16 for 256 levels,
    Set GET_SAMPLE_RATE quirk flag to stop trying to get the sample rate.
    Confirmed that happened anyway later due to the backoff mechanism, after 3 failures
    
    All audio stream on device interfaces share the same values,
    apart from wMaxPacketSize and tSamFreq :
    
    (snip)
    Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        3
          bAlternateSetting       3
          bNumEndpoints           1
          bInterfaceClass         1 Audio
          bInterfaceSubClass      2 Streaming
          bInterfaceProtocol      0
          iInterface              0
          AudioStreaming Interface Descriptor:
            bLength                 7
            bDescriptorType        36
            bDescriptorSubtype      1 (AS_GENERAL)
            bTerminalLink           8
            bDelay                  1 frames
            wFormatTag         0x0001 PCM
          AudioStreaming Interface Descriptor:
            bLength                11
            bDescriptorType        36
            bDescriptorSubtype      2 (FORMAT_TYPE)
            bFormatType             1 (FORMAT_TYPE_I)
            bNrChannels             1
            bSubframeSize           2
            bBitResolution         16
            bSamFreqType            1 Discrete
            tSamFreq[ 0]        44100
          Endpoint Descriptor:
            bLength                 9
            bDescriptorType         5
            bEndpointAddress     0x86  EP 6 IN
            bmAttributes            5
              Transfer Type            Isochronous
              Synch Type               Asynchronous
              Usage Type               Data
            wMaxPacketSize     0x005c  1x 92 bytes
            bInterval               4
            bRefresh                0
            bSynchAddress           0
            AudioStreaming Endpoint Descriptor:
              bLength                 7
              bDescriptorType        37
              bDescriptorSubtype      1 (EP_GENERAL)
              bmAttributes         0x01
                Sampling Frequency
              bLockDelayUnits         0 Undefined
              wLockDelay         0x0000
    (snip)
    
    Based on the usb data about manufacturer, SPCA2281B3 is the most likely controller IC
    Manufacturer does not provide link for datasheet nor detailed specs.
    No way to confirm if the firmware supports any other way of getting the sample rate.
    
    Testing patch provides consistent good sound recording quality and volume range.
    
    (snip)
    [  +0.045764] usb 5-1: new high-speed USB device number 2 using xhci_hcd
    [  +0.106290] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17
    [  +0.000006] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [  +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam
    [  +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD
    [  +0.000004] usb 5-1: SerialNumber: 20201217011
    [  +0.043700] usb 5-1: set resolution quirk: cval->res = 16
    [  +0.002585] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283)
    
    Signed-off-by: Christos Skevis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: usb-audio: Fix microphone sound on Opencomm2 Headset [+ + +]
Author: WhaleChang <[email protected]>
Date:   Fri Oct 6 12:48:49 2023 +0800

    ALSA: usb-audio: Fix microphone sound on Opencomm2 Headset
    
    commit 6a83d6f3bb3c329a73e3483651fb77b78bac1878 upstream.
    
    When a Opencomm2 Headset is connected to a Bluetooth USB dongle,
    the audio playback functions properly, but the microphone does not work.
    
    In the dmesg logs, there are messages indicating that the init_pitch
    function fails when the capture process begins.
    
    The microphone only functions when the ep pitch control is not set.
    
    Toggling the pitch control off bypasses the init_piatch function
    and allows the microphone to work.
    
    Signed-off-by: WhaleChang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB [+ + +]
Author: Macpaul Lin <[email protected]>
Date:   Tue Oct 3 13:13:44 2023 +0200

    arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB
    
    commit 25389c03c21c9587dd21c768d1cbfa514a3ca211 upstream.
    
    The onboard dram of mt8195-demo board is 8GB.
    
    Cc: [email protected]      # 6.1, 6.4, 6.5
    Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board")
    Signed-off-by: Macpaul Lin <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions [+ + +]
Author: Macpaul Lin <[email protected]>
Date:   Tue Oct 3 13:13:45 2023 +0200

    arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions
    
    commit 6cd2a30b96a4b2d270bc1ef1611429dc3fa63327 upstream.
    
    The dts file of the MediaTek MT8195 demo board has been updated to include
    new reserved memory regions.
    These reserved memory regions are:
     - SCP
     - VPU,
     - Sound DMA
     - APU.
    
    These regions are defined with the "shared-dma-pool" compatible property.
    In addition, the existing reserved memory regions have been reordered by
    their addresses to improve readability and maintainability of the DTS
    file.
    
    Cc: [email protected]      # 6.1, 6.4, 6.5
    Fixes: e4a417520101 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon")
    Signed-off-by: Macpaul Lin <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: mediatek: mt8195: Set DSU PMU status to fail [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue Oct 3 13:13:47 2023 +0200

    arm64: dts: mediatek: mt8195: Set DSU PMU status to fail
    
    [ Upstream commit d192615c307ec9f74cd0582880ece698533eb99b ]
    
    The DSU PMU allows monitoring performance events in the DSU cluster,
    which is done by configuring and reading back values from the DSU PMU
    system registers. However, for write-access to be allowed by ELs lower
    than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3
    register, as it is disallowed by default.
    
    That configuration is not done on the firmware used by the MT8195 SoC,
    as a consequence, booting a MT8195-based machine like
    mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel
    just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the
    instruction faults to EL3, and BL31 apparently just re-runs the
    instruction over and over.
    
    Mark the DSU PMU node in the Devicetree with status "fail", as the
    machine doesn't have a suitable firmware to make use of it from the
    kernel, and allowing its driver to probe would hang the kernel.
    
    Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8150: extend the size of the PDC resource [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Tue Sep 5 15:19:26 2023 +0200

    arm64: dts: qcom: sm8150: extend the size of the PDC resource
    
    commit cf5716acbfc6190b3f97f4614affdf5991aed7b2 upstream.
    
    Follow the example of other platforms and extend the PDC resource region
    to 0x30000, so that the PDC driver can read the PDC_VERSION register.
    
    Fixes: 397ad94668c1 ("arm64: dts: qcom: sm8150: Add pdc interrupt controller node")
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/20230905-topic-sm8x50-upstream-pdc-ver-v4-2-fc633c7df84b@linaro.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM [+ + +]
Author: Sven Frotscher <[email protected]>
Date:   Thu Sep 28 00:36:07 2023 +0200

    ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM
    
    commit 1948fa64727685ac3f6584755212e2e738b6b051 upstream.
    
    Like the Lenovo 82TL, 82V2, 82QF and 82UG, the 82YM (Yoga 7 14ARP8)
    requires an entry in the quirk list to enable the internal microphone.
    The latter two received similar fixes in commit 1263cc0f414d
    ("ASoC: amd: yc: Fix non-functional mic on Lenovo 82QF and 82UG").
    
    Fixes: c008323fe361 ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ")
    Cc: [email protected]
    Signed-off-by: Sven Frotscher <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: fsl_sai: Don't disable bitclock for i.MX8MP [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Tue Sep 19 17:42:13 2023 +0800

    ASoC: fsl_sai: Don't disable bitclock for i.MX8MP
    
    [ Upstream commit 197c53c8ecb34f2cd5922f4bdcffa8f701a134eb ]
    
    On i.MX8MP, the BCE and TERE bit are binding with mclk
    enablement, if BCE and TERE are cleared the MCLK also be
    disabled on output pin, that cause the external codec (wm8960)
    in wrong state.
    
    Codec (wm8960) is using the mclk to generate PLL clock,
    if mclk is disabled before disabling PLL, the codec (wm8960)
    won't generate bclk and frameclk when sysclk switch to
    MCLK source in next test case.
    
    The test case:
    $aplay -r44100 test1.wav (PLL source)
    $aplay -r48000 test2.wav (MCLK source)
    aplay: pcm_write:2127: write error: Input/output error
    
    Fixes: 269f399dc19f ("ASoC: fsl_sai: Disable bit clock with transmitter")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: fsl_sai: MCLK bind with TX/RX enable bit [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Fri May 5 15:55:22 2023 +0800

    ASoC: fsl_sai: MCLK bind with TX/RX enable bit
    
    [ Upstream commit 3e4a826129980fed0e3e746a7822f2f204dfc24a ]
    
    On i.MX8MP, the sai MCLK is bound with TX/RX enable bit,
    which means the TX/RE enable bit need to be enabled then
    MCLK can be output on PAD.
    
    Some codec (for example: WM8962) needs the MCLK output
    earlier, otherwise there will be issue for codec
    configuration.
    
    Add new soc data "mclk_with_tere" for this platform and
    enable the MCLK output in startup stage.
    
    As "mclk_with_tere" only applied to i.MX8MP, currently
    The soc data is shared with i.MX8MN, so need to add
    an i.MX8MN own soc data with "mclk_with_tere" disabled.
    
    Signed-off-by: Shengjiu Wang <[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]
    Stable-dep-of: 197c53c8ecb3 ("ASoC: fsl_sai: Don't disable bitclock for i.MX8MP")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in MTL match table [+ + +]
Author: Balamurugan C <[email protected]>
Date:   Tue Sep 19 17:11:36 2023 +0800

    ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in MTL match table
    
    commit d1f67278d4b2de3bf544ea9bcd9f64d03584df87 upstream.
    
    Adding HDMI-In capture via I2S feature support in MTL platform.
    
    Signed-off-by: Balamurugan C <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Bard Liao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: Intel: soc-acpi: Add entry for sof_es8336 in MTL match table. [+ + +]
Author: Balamurugan C <[email protected]>
Date:   Tue Sep 19 17:11:35 2023 +0800

    ASoC: Intel: soc-acpi: Add entry for sof_es8336 in MTL match table.
    
    commit 381ddcd5875e496f2eae06bb65853271b7150fee upstream.
    
    Adding support for ES83x6 codec in MTL match table.
    
    Signed-off-by: Balamurugan C <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Bard Liao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: Intel: sof_sdw: add support for SKU 0B14 [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Tue Sep 19 17:21:25 2023 +0800

    ASoC: Intel: sof_sdw: add support for SKU 0B14
    
    commit fb0b8d299781be8d46b3612aa96cef28da0d93f4 upstream.
    
    One more missing SKU in the list.
    
    Closes: https://github.com/thesofproject/linux/issues/4543
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Chao Song <[email protected]>
    Signed-off-by: Bard Liao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: simple-card-utils: fixup simple_util_startup() error handling [+ + +]
Author: Kuninori Morimoto <[email protected]>
Date:   Tue Sep 19 01:22:57 2023 +0000

    ASoC: simple-card-utils: fixup simple_util_startup() error handling
    
    commit 69cf63b6560205a390a736b88d112374655adb28 upstream.
    
    It should use "goto" instead of "return"
    
    Fixes: 5ca2ab459817 ("ASoC: simple-card-utils: Add new system-clock-fixed flag")
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: SOF: amd: fix for firmware reload failure after playback [+ + +]
Author: Vijendar Mukunda <[email protected]>
Date:   Wed Sep 27 12:44:10 2023 +0530

    ASoC: SOF: amd: fix for firmware reload failure after playback
    
    commit 7e1fe5d9e7eae67e218f878195d1d348d01f9af7 upstream.
    
    Setting ACP ACLK as clock source when ACP enters D0 state causing
    firmware load failure as mentioned in below scenario.
    
    - Load snd_sof_amd_rembrandt
    - Play or Record audio
    - Stop audio
    - Unload snd_sof_amd_rembrandt
    - Reload snd_sof_amd_rembrandt
    
    If acp_clkmux_sel register field is set, then clock source will be
    set to ACP ACLK when ACP enters D0 state.
    
    During stream stop, if there is no active stream is running then
    acp firmware will set the ACP ACLK value to zero.
    
    When driver is reloaded and clock source is selected as ACP ACLK,
    as ACP ACLK is programmed to zero, firmware loading will fail.
    
    For RMB platform, remove the clock mux selection field so that
    ACP will use internal clock source when ACP enters D0 state.
    
    Fixes: 41cb85bc4b52 ("ASoC: SOF: amd: Add support for Rembrandt plaform.")
    Reported-by: coolstar <[email protected]>
    Closes: https://github.com/thesofproject/sof/issues/8137
    Signed-off-by: Vijendar Mukunda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: Use of_property_read_bool() for boolean properties [+ + +]
Author: Rob Herring <[email protected]>
Date:   Fri Mar 10 08:47:32 2023 -0600

    ASoC: Use of_property_read_bool() for boolean properties
    
    [ Upstream commit 2d2998b84330899bf88a0414f3356869be4a69eb ]
    
    It is preferred to use typed property access functions (i.e.
    of_property_read_<type> functions) rather than low-level
    of_get_property/of_find_property functions for reading properties.
    Convert reading boolean properties to to of_property_read_bool().
    
    Signed-off-by: Rob Herring <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 197c53c8ecb3 ("ASoC: fsl_sai: Don't disable bitclock for i.MX8MP")
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: libata-scsi: Disable scsi device manage_system_start_stop [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Sat Aug 26 09:43:39 2023 +0900

    ata: libata-scsi: Disable scsi device manage_system_start_stop
    
    commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 upstream.
    
    The introduction of a device link to create a consumer/supplier
    relationship between the scsi device of an ATA device and the ATA port
    of that ATA device fixes the ordering of system suspend and resume
    operations. For suspend, the scsi device is suspended first and the ata
    port after it. This is fine as this allows the synchronize cache and
    START STOP UNIT commands issued by the scsi disk driver to be executed
    before the ata port is disabled.
    
    For resume operations, the ata port is resumed first, followed
    by the scsi device. This allows having the request queue of the scsi
    device to be unfrozen after the ata port resume is scheduled in EH,
    thus avoiding to see new requests prematurely issued to the ATA device.
    Since libata sets manage_system_start_stop to 1, the scsi disk resume
    operation also results in issuing a START STOP UNIT command to the
    device being resumed so that the device exits standby power mode.
    
    However, restoring the ATA device to the active power mode must be
    synchronized with libata EH processing of the port resume operation to
    avoid either 1) seeing the start stop unit command being received too
    early when the port is not yet resumed and ready to accept commands, or
    after the port resume process issues commands such as IDENTIFY to
    revalidate the device. In this last case, the risk is that the device
    revalidation fails with timeout errors as the drive is still spun down.
    
    Commit 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
    disabled issuing the START STOP UNIT command to avoid issues with it.
    But this is incorrect as transitioning a device to the active power
    mode from the standby power mode set on suspend requires a media access
    command. The IDENTIFY, READ LOG and SET FEATURES commands executed in
    libata EH context triggered by the ata port resume operation may thus
    fail.
    
    Fix these synchronization issues is by handling a device power mode
    transitions for system suspend and resume directly in libata EH context,
    without relying on the scsi disk driver management triggered with the
    manage_system_start_stop flag.
    
    To do this, the following libata helper functions are introduced:
    
    1) ata_dev_power_set_standby():
    
    This function issues a STANDBY IMMEDIATE command to transitiom a device
    to the standby power mode. For HDDs, this spins down the disks. This
    function applies only to ATA and ZAC devices and does nothing otherwise.
    This function also does nothing for devices that have the
    ATA_FLAG_NO_POWEROFF_SPINDOWN or ATA_FLAG_NO_HIBERNATE_SPINDOWN flag
    set.
    
    For suspend, call ata_dev_power_set_standby() in
    ata_eh_handle_port_suspend() before the port is disabled and frozen.
    ata_eh_unload() is also modified to transition all enabled devices to
    the standby power mode when the system is shutdown or devices removed.
    
    2) ata_dev_power_set_active() and
    
    This function applies to ATA or ZAC devices and issues a VERIFY command
    for 1 sector at LBA 0 to transition the device to the active power mode.
    For HDDs, since this function will complete only once the disk spin up.
    Its execution uses the same timeouts as for reset, to give the drive
    enough time to complete spinup without triggering a command timeout.
    
    For resume, call ata_dev_power_set_active() in
    ata_eh_revalidate_and_attach() after the port has been enabled and
    before any other command is issued to the device.
    
    With these changes, the manage_system_start_stop and no_start_on_resume
    scsi device flags do not need to be set in ata_scsi_dev_config(). The
    flag manage_runtime_start_stop is still set to allow the sd driver to
    spinup/spindown a disk through the sd runtime operations.
    
    Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
    Cc: [email protected]
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bpf: Fix verifier log for async callback return values [+ + +]
Author: David Vernet <[email protected]>
Date:   Mon Oct 9 11:14:13 2023 -0500

    bpf: Fix verifier log for async callback return values
    
    [ Upstream commit 829955981c557c7fc7416581c4cd68a8a0c28620 ]
    
    The verifier, as part of check_return_code(), verifies that async
    callbacks such as from e.g. timers, will return 0. It does this by
    correctly checking that R0->var_off is in tnum_const(0), which
    effectively checks that it's in a range of 0. If this condition fails,
    however, it prints an error message which says that the value should
    have been in (0x0; 0x1). This results in possibly confusing output such
    as the following in which an async callback returns 1:
    
      At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1)
    
    The fix is easy -- we should just pass the tnum_const(0) as the correct
    range to verbose_invalid_scalar(), which will then print the following:
    
      At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0)
    
    Fixes: bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.")
    Signed-off-by: David Vernet <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior [+ + +]
Author: Lukas Magel <[email protected]>
Date:   Sun Aug 27 09:22:05 2023 +0000

    can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior
    
    [ Upstream commit d9c2ba65e651467de739324d978b04ed8729f483 ]
    
    With patch [1], isotp_poll was updated to also queue the poller in the
    so->wait queue, which is used for send state changes. Since the queue
    now also contains polling tasks that are not interested in sending, the
    queue fill state can no longer be used as an indication of send
    readiness. As a consequence, nonblocking writes can lead to a race and
    lock-up of the socket if there is a second task polling the socket in
    parallel.
    
    With this patch, isotp_sendmsg does not consult wq_has_sleepers but
    instead tries to atomically set so->tx.state and waits on so->wait if it
    is unable to do so. This behavior is in alignment with isotp_poll, which
    also checks so->tx.state to determine send readiness.
    
    V2:
    - Revert direct exit to goto err_event_drop
    
    [1] https://lore.kernel.org/all/[email protected]
    
    Reported-by: Maxime Jayat <[email protected]>
    Closes: https://lore.kernel.org/linux-can/[email protected]/
    Signed-off-by: Lukas Magel <[email protected]>
    Reviewed-by: Oliver Hartkopp <[email protected]>
    Fixes: 79e19fa79cb5 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events")
    Link: https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set [+ + +]
Author: John Watts <[email protected]>
Date:   Wed Sep 6 09:13:43 2023 +1000

    can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set
    
    [ Upstream commit 1f223208ebdef84f21c15e9958c005a93c871aa2 ]
    
    When adding the RISCV option I didn't gate it behind ARCH_SUNXI.
    As a result this option shows up with Allwinner support isn't enabled.
    Fix that by requiring ARCH_SUNXI to be set if RISCV is set.
    
    Fixes: 8abb95250ae6 ("can: sun4i_can: Add support for the Allwinner D1")
    Reported-by: Geert Uytterhoeven <[email protected]>
    Closes: https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/
    Signed-off-by: John Watts <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ceph: fix incorrect revoked caps assert in ceph_fill_file_size() [+ + +]
Author: Xiubo Li <[email protected]>
Date:   Wed Sep 6 14:22:07 2023 +0800

    ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
    
    commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream.
    
    When truncating the inode the MDS will acquire the xlock for the
    ifile Locker, which will revoke the 'Frwsxl' caps from the clients.
    But when the client just releases and flushes the 'Fw' caps to MDS,
    for exmaple, and once the MDS receives the caps flushing msg it
    just thought the revocation has finished. Then the MDS will continue
    truncating the inode and then issued the truncate notification to
    all the clients. While just before the clients receives the cap
    flushing ack they receive the truncation notification, the clients
    will detecte that the 'issued | dirty' is still holding the 'Fw'
    caps.
    
    Cc: [email protected]
    Link: https://tracker.ceph.com/issues/56693
    Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex")
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Milind Changire <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ceph: fix type promotion bug on 32bit systems [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Sat Oct 7 11:52:39 2023 +0300

    ceph: fix type promotion bug on 32bit systems
    
    commit 07bb00ef00ace88dd6f695fadbba76565756e55c upstream.
    
    In this code "ret" is type long and "src_objlen" is unsigned int.  The
    problem is that on 32bit systems, when we do the comparison signed longs
    are type promoted to unsigned int.  So negative error codes from
    do_splice_direct() are treated as success instead of failure.
    
    Cc: [email protected]
    Fixes: 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cgroup: Remove duplicates in cgroup v1 tasks file [+ + +]
Author: Michal Koutný <[email protected]>
Date:   Mon Oct 9 15:58:11 2023 +0200

    cgroup: Remove duplicates in cgroup v1 tasks file
    
    commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream.
    
    One PID may appear multiple times in a preloaded pidlist.
    (Possibly due to PID recycling but we have reports of the same
    task_struct appearing with different PIDs, thus possibly involving
    transfer of PID via de_thread().)
    
    Because v1 seq_file iterator uses PIDs as position, it leads to
    a message:
    > seq_file: buggy .next function kernfs_seq_next did not update position index
    
    Conservative and quick fix consists of removing duplicates from `tasks`
    file (as opposed to removing pidlists altogether). It doesn't affect
    correctness (it's sufficient to show a PID once), performance impact
    would be hidden by unconditional sorting of the pidlist already in place
    (asymptotically).
    
    Link: https://lore.kernel.org/r/[email protected]/
    Suggested-by: Firo Yang <[email protected]>
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
counter: chrdev: fix getting array extensions [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Tue Aug 29 15:40:22 2023 +0200

    counter: chrdev: fix getting array extensions
    
    commit 3170256d7bc1ef81587caf4b83573eb1f5bb4fb6 upstream.
    
    When trying to watch a component array extension, and the array isn't the
    first extended element, it fails as the type comparison is always done on
    the 1st element. Fix it by indexing the 'ext' array.
    
    Example on a dummy struct counter_comp:
    static struct counter_comp dummy[] = {
            COUNTER_COMP_DIRECTION(..),
            ...,
            COUNTER_COMP_ARRAY_CAPTURE(...),
    };
    static struct counter_count dummy_cnt = {
            ...
            .ext = dummy,
            .num_ext = ARRAY_SIZE(dummy),
    }
    
    Currently, counter_get_ext() returns -EINVAL when trying to add a watch
    event on one of the capture array element in such example.
    
    Fixes: d2011be1e22f ("counter: Introduce the COUNTER_COMP_ARRAY component type")
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: William Breathitt Gray <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

counter: microchip-tcb-capture: Fix the use of internal GCLK logic [+ + +]
Author: Dharma Balasubiramani <[email protected]>
Date:   Tue Sep 5 15:38:35 2023 +0530

    counter: microchip-tcb-capture: Fix the use of internal GCLK logic
    
    commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.
    
    As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should
    be set to 0 while using the internal GCLK (TIMER_CLOCK1).
    
    Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
    Signed-off-by: Dharma Balasubiramani <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: William Breathitt Gray <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dma-buf: add dma_fence_timestamp helper [+ + +]
Author: Christian König <[email protected]>
Date:   Fri Sep 8 10:27:23 2023 +0200

    dma-buf: add dma_fence_timestamp helper
    
    commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 upstream.
    
    When a fence signals there is a very small race window where the timestamp
    isn't updated yet. sync_file solves this by busy waiting for the
    timestamp to appear, but on other ocassions didn't handled this
    correctly.
    
    Provide a dma_fence_timestamp() helper function for this and use it in
    all appropriate cases.
    
    Another alternative would be to grab the spinlock when that happens.
    
    v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case
       the accurate timestamp is needed and/or the timestamp is not based on
       ktime (e.g. hw timestamp)
    v3 chk: drop the parameter again for unified handling
    
    Signed-off-by: Yunxiang Li <[email protected]>
    Signed-off-by: Christian König <[email protected]>
    Fixes: 1774baa64f93 ("drm/scheduler: Change scheduled fence track v2")
    Reviewed-by: Alex Deucher <[email protected]>
    CC: [email protected]
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq [+ + +]
Author: Rex Zhang <[email protected]>
Date:   Sat Sep 16 14:06:19 2023 +0800

    dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq
    
    [ Upstream commit c0409dd3d151f661e7e57b901a81a02565df163c ]
    
    In idxd_cmd_exec(), wait_event_lock_irq() explicitly calls
    spin_unlock_irq()/spin_lock_irq(). If the interrupt is on before entering
    wait_event_lock_irq(), it will become off status after
    wait_event_lock_irq() is called. Later, wait_for_completion() may go to
    sleep but irq is disabled. The scenario is warned in might_sleep().
    
    Fix it by using spin_lock_irqsave() instead of the primitive spin_lock()
    to save the irq status before entering wait_event_lock_irq() and using
    spin_unlock_irqrestore() instead of the primitive spin_unlock() to restore
    the irq status before entering wait_for_completion().
    
    Before the change:
    idxd_cmd_exec() {
    interrupt is on
    spin_lock()                        // interrupt is on
            wait_event_lock_irq()
                    spin_unlock_irq()  // interrupt is enabled
                    ...
                    spin_lock_irq()    // interrupt is disabled
    spin_unlock()                      // interrupt is still disabled
    wait_for_completion()              // report "BUG: sleeping function
                                       // called from invalid context...
                                       // in_atomic() irqs_disabled()"
    }
    
    After applying spin_lock_irqsave():
    idxd_cmd_exec() {
    interrupt is on
    spin_lock_irqsave()                // save the on state
                                       // interrupt is disabled
            wait_event_lock_irq()
                    spin_unlock_irq()  // interrupt is enabled
                    ...
                    spin_lock_irq()    // interrupt is disabled
    spin_unlock_irqrestore()           // interrupt is restored to on
    wait_for_completion()              // No Call trace
    }
    
    Fixes: f9f4082dbc56 ("dmaengine: idxd: remove interrupt disable for cmd_lock")
    Signed-off-by: Rex Zhang <[email protected]>
    Signed-off-by: Lijun Pan <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Fenghua Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: mediatek: Fix deadlock caused by synchronize_irq() [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Sun Aug 6 11:25:11 2023 +0800

    dmaengine: mediatek: Fix deadlock caused by synchronize_irq()
    
    [ Upstream commit 01f1ae2733e2bb4de92fefcea5fda847d92aede1 ]
    
    The synchronize_irq(c->irq) will not return until the IRQ handler
    mtk_uart_apdma_irq_handler() is completed. If the synchronize_irq()
    holds a spin_lock and waits the IRQ handler to complete, but the
    IRQ handler also needs the same spin_lock. The deadlock will happen.
    The process is shown below:
    
              cpu0                        cpu1
    mtk_uart_apdma_device_pause() | mtk_uart_apdma_irq_handler()
      spin_lock_irqsave()         |
                                  |   spin_lock_irqsave()
      //hold the lock to wait     |
      synchronize_irq()           |
    
    This patch reorders the synchronize_irq(c->irq) outside the spin_lock
    in order to mitigate the bug.
    
    Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support")
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Eugen Hristev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: stm32-dma: fix residue in case of MDMA chaining [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Wed Oct 4 17:50:24 2023 +0200

    dmaengine: stm32-dma: fix residue in case of MDMA chaining
    
    commit 67e13e89742c3b21ce177f612bf9ef32caae6047 upstream.
    
    In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM)
    with two periods, but if transfer has been prepared with _prep_slave_sg(),
    the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM
    is activated for MDMA chaining, residue computation must take into account
    cyclic constraints.
    
    With only two periods in MDMA chaining, and no update due to Transfer
    Complete interrupt masked, n_sg is always 0. If DMA current memory address
    (depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg
    should be increased.
    Then, the residue of the current period is the one read from SxNDTR and
    should not be overwritten with the full period length.
    
    Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Wed Oct 4 17:50:23 2023 +0200

    dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining
    
    commit 2df467e908ce463cff1431ca1b00f650f7a514b4 upstream.
    
    Current Target (CT) have to be reset when starting an MDMA chaining use
    case, as Double Buffer mode is activated. It ensures the DMA will start
    processing the first memory target (pointed with SxM0AR).
    
    Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: stm32-mdma: abort resume if no ongoing transfer [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Wed Oct 4 18:35:28 2023 +0200

    dmaengine: stm32-mdma: abort resume if no ongoing transfer
    
    commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream.
    
    chan->desc can be null, if transfer is terminated when resume is called,
    leading to a NULL pointer when retrieving the hwdesc.
    To avoid this case, check that chan->desc is not null and channel is
    disabled (transfer previously paused or terminated).
    
    Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Wed Oct 4 18:35:30 2023 +0200

    dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set
    
    commit 584970421725b7805db84714b857851fdf7203a9 upstream.
    
    CRQA flag is set by hardware when the channel request become active and
    the channel is enabled. It is cleared by hardware, when the channel request
    is completed.
    So when it is set, it means MDMA is transferring bytes.
    This information is useful in case of STM32 DMA and MDMA chaining,
    especially when the user pauses DMA before stopping it, to trig one last
    MDMA transfer to get the latest bytes of the SRAM buffer to the
    destination buffer.
    STM32 DCMI driver can then use this to know if the last MDMA transfer in
    case of chaining is done.
    
    Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: stm32-mdma: use Link Address Register to compute residue [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Wed Oct 4 18:35:29 2023 +0200

    dmaengine: stm32-mdma: use Link Address Register to compute residue
    
    commit a4b306eb83579c07b63dc65cd5bae53b7b4019d0 upstream.
    
    Current implementation relies on curr_hwdesc index. But to keep this index
    up to date, Block Transfer interrupt (BTIE) has to be enabled.
    If it is not, curr_hwdesc is not updated, and then residue is not reliable.
    Rely on Link Address Register instead. And disable BTIE interrupt
    in stm32_mdma_setup_xfer() because it is no more needed in case of
    _prep_slave_sg() to maintain curr_hwdesc up to date.
    It avoids extra interrupts and also ensures a reliable residue. These
    improvements are required for STM32 DCMI camera capture use case, which
    need STM32 DMA and MDMA chaining for good performance.
    
    Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/display: Don't set dpms_off for seamless boot [+ + +]
Author: Daniel Miess <[email protected]>
Date:   Fri Sep 29 13:04:33 2023 -0400

    drm/amd/display: Don't set dpms_off for seamless boot
    
    commit 23645bca98304a2772f0de96f97370dd567d0ae6 upstream.
    
    [Why]
    eDPs fail to light up with seamless boot enabled
    
    [How]
    When seamless boot is enabled don't configure dpms_off
    in disable_vbios_mode_if_required.
    
    Reviewed-by: Charlene Liu <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Acked-by: Tom Chung <[email protected]>
    Signed-off-by: Daniel Miess <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: add missing NULL check [+ + +]
Author: Christian König <[email protected]>
Date:   Fri Oct 6 14:04:04 2023 +0200

    drm/amdgpu: add missing NULL check
    
    commit ff89f064dca38e2203790bf876cc7756b8ab2961 upstream.
    
    bo->tbo.resource can easily be NULL here.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2902
    Signed-off-by: Christian König <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    CC: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/atomic-helper: relax unregistered connector check [+ + +]
Author: Simon Ser <[email protected]>
Date:   Thu Oct 5 13:16:32 2023 +0000

    drm/atomic-helper: relax unregistered connector check
    
    commit 2b7947bd32e243c52870d54141d3b4ea6775e63d upstream.
    
    The driver might pull connectors which weren't submitted by
    user-space into the atomic state. For instance,
    intel_dp_mst_atomic_master_trans_check() pulls in connectors
    sharing the same DP-MST stream. However, if the connector is
    unregistered, this later fails with:
    
        [  559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered
    
    Skip the unregistered connector check to allow user-space to turn
    off connectors one-by-one.
    
    See this wlroots issue:
    https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407
    
    Previous discussion:
    https://lore.kernel.org/intel-gfx/[email protected]/
    
    Signed-off-by: Simon Ser <[email protected]>
    Cc: [email protected]
    Reviewed-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Lyude Paul <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Imre Deak <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux inval [+ + +]
Author: Nirmoy Das <[email protected]>
Date:   Tue Sep 26 16:24:01 2023 +0200

    drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux inval
    
    [ Upstream commit 128c20eda73bd3e78505c574fb17adb46195c98b ]
    
    PIPE_CONTROL_FLUSH_L3 is not needed for aux invalidation
    so don't set that.
    
    Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before invalidation")
    Cc: Jonathan Cavitt <[email protected]>
    Cc: Andi Shyti <[email protected]>
    Cc: <[email protected]> # v5.8+
    Cc: Andrzej Hajda <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Matt Roper <[email protected]>
    Cc: Tejas Upadhyay <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Prathap Kumar Valsan <[email protected]>
    Cc: Tapani Pälli <[email protected]>
    Cc: Mark Janes <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Signed-off-by: Nirmoy Das <[email protected]>
    Acked-by: Matt Roper <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Tested-by: Tapani Pälli <[email protected]>
    Reviewed-by: Andrzej Hajda <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 03d681412b38558aefe4fb0f46e36efa94bb21ef)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dp: Add newlines to debug printks [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Fri Aug 25 16:01:08 2023 -0700

    drm/msm/dp: Add newlines to debug printks
    
    [ Upstream commit eba8c99a0fc45da1c8d5b5f5bd1dc2e79229a767 ]
    
    These debug printks are missing newlines, causing drm debug logs to be
    hard to read. Add newlines so that the messages are on their own line.
    
    Cc: Kuogee Hsieh <[email protected]>
    Cc: Vinod Polimera <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of debugging")
    Fixes: cd779808cccd ("drm/msm/dp: Add basic PSR support for eDP")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/554533/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abhinav Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dp: do not reinitialize phy unless retry during link training [+ + +]
Author: Kuogee Hsieh <[email protected]>
Date:   Tue Aug 8 15:19:50 2023 -0700

    drm/msm/dp: do not reinitialize phy unless retry during link training
    
    [ Upstream commit 0c1a2e69bcb506f48ebf94bd199bab0b93f66da2 ]
    
    DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will
    cause PLL unlocked initially and then PLL gets locked at the end of
    initialization. PLL_UNLOCKED interrupt will fire during this time if the
    interrupt mask is enabled.
    
    However currently DP driver link training implementation incorrectly
    re-initializes PHY unconditionally during link training as the PHY was
    already configured in dp_ctrl_enable_mainlink_clocks().
    
    Fix this by re-initializing the PHY only if the previous link training
    failed.
    
    [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/30
    Signed-off-by: Kuogee Hsieh <[email protected]>
    Tested-by: Abhinav Kumar <[email protected]> # sc7280
    Reviewed-by: Abhinav Kumar <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/551847/
    Link: https://lore.kernel.org/r/[email protected]
    [[email protected]: added line break in commit text]
    Signed-off-by: Abhinav Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow [+ + +]
Author: Abhinav Kumar <[email protected]>
Date:   Thu Sep 7 18:26:16 2023 -0700

    drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow
    
    [ Upstream commit 95e681ca3b65e4ce3d2537b47672d787b7d30375 ]
    
    _dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
    used during plane bandwidth calculations. However for high resolution
    displays this overflows easily and leads to below errors
    
    [dpu error]crtc83 failed performance check -7
    
    Promote the intermediate variables to u64 to avoid overflow.
    
    changes in v2:
            - change to u64 where actually needed in the math
    
    Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reported-by: Nia Espera <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/32
    Tested-by: Nia Espera <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/556288/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abhinav Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dsi: fix irq_of_parse_and_map() error checking [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Sep 15 15:59:40 2023 +0300

    drm/msm/dsi: fix irq_of_parse_and_map() error checking
    
    [ Upstream commit 6a1d4c7976dd1ee7c9f80bc8e62801ec7b1f2f58 ]
    
    The irq_of_parse_and_map() function returns zero on error.  It
    never returns negative error codes.  Fix the check.
    
    Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/557715/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abhinav Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dsi: skip the wait for video mode done if not applicable [+ + +]
Author: Abhinav Kumar <[email protected]>
Date:   Fri Sep 15 13:44:25 2023 -0700

    drm/msm/dsi: skip the wait for video mode done if not applicable
    
    [ Upstream commit ab483e3adcc178254eb1ce0fbdfbea65f86f1006 ]
    
    dsi_wait4video_done() API waits for the DSI video mode engine to
    become idle so that we can transmit the DCS commands in the
    beginning of BLLP. However, with the current sequence, the MDP
    timing engine is turned on after the panel's pre_enable() callback
    which can send out the DCS commands needed to power up the panel.
    
    During those cases, this API will always timeout and print out the
    error spam leading to long bootup times and log flooding.
    
    Fix this by checking if the DSI video engine was actually busy before
    waiting for it to become idle otherwise this is a redundant wait.
    
    changes in v2:
            - move the reg read below the video mode check
            - minor fixes in commit text
    
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/34
    Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
    Signed-off-by: Abhinav Kumar <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/557853/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: fix typo of sizeof argument [+ + +]
Author: Konstantin Meskhidze <[email protected]>
Date:   Tue Sep 5 18:02:03 2023 +0800

    drm/vmwgfx: fix typo of sizeof argument
    
    [ Upstream commit 39465cac283702a7d4a507a558db81898029c6d3 ]
    
    Since size of 'header' pointer and '*header' structure is equal on 64-bit
    machines issue probably didn't cause any wrong behavior. But anyway,
    fixing typo is required.
    
    Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.")
    Co-developed-by: Ivanov Mikhail <[email protected]>
    Signed-off-by: Konstantin Meskhidze <[email protected]>
    Reviewed-by: Zack Rusin <[email protected]>
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Update description for '#interrupt-cells' property [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Fri Jul 22 16:11:54 2022 +0100

    dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Update description for '#interrupt-cells' property
    
    commit cfa1f9db6d6088118ef311c0927c66072665b47e upstream.
    
    Update description for '#interrupt-cells' property to utilize the
    RZG2L_{NMI,IRQX} for the first cell defined in the
    include/dt-bindings/interrupt-controller/irqc-rzg2l.h file.
    
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Fixes: 96fed779d3d4cb3c ("dt-bindings: interrupt-controller: Add Renesas RZ/G2L Interrupt Controller")
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Thu Oct 5 20:26:38 2023 +0200

    HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
    
    commit dac501397b9d81e4782232c39f94f4307b137452 upstream.
    
    hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
    races when it races with itself.
    
    hidpp_connect_event() primarily runs from a workqueue but it also runs
    on probe() and if a "device-connected" packet is received by the hw
    when the thread running hidpp_connect_event() from probe() is waiting on
    the hw, then a second thread running hidpp_connect_event() will be
    started from the workqueue.
    
    This opens the following races (note the below code is simplified):
    
    1. Retrieving + printing the protocol (harmless race):
    
            if (!hidpp->protocol_major) {
                    hidpp_root_get_protocol_version()
                    hidpp->protocol_major = response.rap.params[0];
            }
    
    We can actually see this race hit in the dmesg in the abrt output
    attached to rhbz#2227968:
    
    [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
    [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
    
    Testing with extra logging added has shown that after this the 2 threads
    take turn grabbing the hw access mutex (send_mutex) so they ping-pong
    through all the other TOCTOU cases managing to hit all of them:
    
    2. Updating the name to the HIDPP name (harmless race):
    
            if (hidpp->name == hdev->name) {
                    ...
                    hidpp->name = new_name;
            }
    
    3. Initializing the power_supply class for the battery (problematic!):
    
    hidpp_initialize_battery()
    {
            if (hidpp->battery.ps)
                    return 0;
    
            probe_battery(); /* Blocks, threads take turns executing this */
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    }
    
    4. Creating delayed input_device (potentially problematic):
    
            if (hidpp->delayed_input)
                    return;
    
            hidpp->delayed_input = hidpp_allocate_input(hdev);
    
    The really big problem here is 3. Hitting the race leads to the following
    sequence:
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    
            ...
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    
    So now we have registered 2 power supplies for the same battery,
    which looks a bit weird from userspace's pov but this is not even
    the really big problem.
    
    Notice how:
    
    1. This is all devm-maganaged
    2. The hidpp->battery.desc struct is shared between the 2 power supplies
    3. hidpp->battery.desc.properties points to the result from the second
       devm_kmemdup()
    
    This causes a use after free scenario on USB disconnect of the receiver:
    1. The last registered power supply class device gets unregistered
    2. The memory from the last devm_kmemdup() call gets freed,
       hidpp->battery.desc.properties now points to freed memory
    3. The first registered power supply class device gets unregistered,
       this involves sending a remove uevent to userspace which invokes
       power_supply_uevent() to fill the uevent data
    4. power_supply_uevent() uses hidpp->battery.desc.properties which
       now points to freed memory leading to backtraces like this one:
    
    Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
    ...
    Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
    Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
    ...
    Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
    Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
    Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
    Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
    Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
    Sep 22 20:01:35 eric kernel:  power_supply_unregister+0x8e/0xa0
    Sep 22 20:01:35 eric kernel:  release_nodes+0x3d/0xb0
    Sep 22 20:01:35 eric kernel:  devres_release_group+0xfc/0x130
    Sep 22 20:01:35 eric kernel:  hid_device_remove+0x56/0xa0
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
    Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
    Sep 22 20:01:35 eric kernel:  logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4]
    Sep 22 20:01:35 eric kernel:  hid_device_remove+0x44/0xa0
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
    Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
    Sep 22 20:01:35 eric kernel:  usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3]
    Sep 22 20:01:35 eric kernel:  usb_unbind_interface+0x90/0x270
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? kobject_put+0xa0/0x1d0
    Sep 22 20:01:35 eric kernel:  usb_disable_device+0xcd/0x1e0
    Sep 22 20:01:35 eric kernel:  usb_disconnect+0xde/0x2c0
    Sep 22 20:01:35 eric kernel:  usb_disconnect+0xc3/0x2c0
    Sep 22 20:01:35 eric kernel:  hub_event+0xe80/0x1c10
    
    There have been quite a few bug reports (see Link tags) about this crash.
    
    Fix all the TOCTOU issues, including the really bad power-supply related
    system crash on USB disconnect, by making probe() use the workqueue for
    running hidpp_connect_event() too, so that it can never run more then once.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58
    Cc: [email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ieee802154: ca8210: Fix a potential UAF in ca8210_probe [+ + +]
Author: Dinghao Liu <[email protected]>
Date:   Sat Oct 7 11:30:49 2023 +0800

    ieee802154: ca8210: Fix a potential UAF in ca8210_probe
    
    [ Upstream commit f990874b1c98fe8e57ee9385669f501822979258 ]
    
    If of_clk_add_provider() fails in ca8210_register_ext_clock(),
    it calls clk_unregister() to release priv->clk and returns an
    error. However, the caller ca8210_probe() then calls ca8210_remove(),
    where priv->clk is freed again in ca8210_unregister_ext_clock(). In
    this case, a use-after-free may happen in the second time we call
    clk_unregister().
    
    Fix this by removing the first clk_unregister(). Also, priv->clk could
    be an error code on failure of clk_register_fixed_rate(). Use
    IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
    
    Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
    Signed-off-by: Dinghao Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: adc: imx8qxp: Fix address for command buffer registers [+ + +]
Author: Philipp Rossak <[email protected]>
Date:   Tue Sep 5 00:02:04 2023 +0200

    iio: adc: imx8qxp: Fix address for command buffer registers
    
    commit 850101b3598277794f92a9e363a60a66e0d42890 upstream.
    
    The ADC Command Buffer Register high and low are currently pointing to
    the wrong address and makes it impossible to perform correct
    ADC measurements over all channels.
    
    According to the datasheet of the imx8qxp the ADC_CMDL register starts
    at address 0x100 and the ADC_CMDH register starts at address 0x104.
    
    This bug seems to be in the kernel since the introduction of this
    driver.
    
    This can be observed by checking all raw voltages of the adc and they
    are all nearly identical:
    
    cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw
    3498
    3494
    3491
    3491
    3489
    3490
    3490
    3490
    
    Fixes: 1e23dcaa1a9fa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC")
    Signed-off-by: Philipp Rossak <[email protected]>
    Acked-by: Haibo Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: addac: Kconfig: update ad74413r selections [+ + +]
Author: Antoniu Miclaus <[email protected]>
Date:   Tue Sep 12 11:54:21 2023 +0300

    iio: addac: Kconfig: update ad74413r selections
    
    commit b120dd3a15582fb7a959cecb05e4d9814fcba386 upstream.
    
    Building ad74413r without selecting IIO_BUFFER and
    IIO_TRIGGERED_BUFFER generates error with respect to the iio trigger
    functions that are used within the driver.
    Update the Kconfig accordingly.
    
    Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
    Signed-off-by: Antoniu Miclaus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: admv1013: add mixer_vgate corner cases [+ + +]
Author: Antoniu Miclaus <[email protected]>
Date:   Mon Aug 7 17:38:05 2023 +0300

    iio: admv1013: add mixer_vgate corner cases
    
    commit 287d998af24326b009ae0956820a3188501b34a0 upstream.
    
    Include the corner cases in the computation of the MIXER_VGATE register
    value.
    
    According to the datasheet: The MIXER_VGATE values follows the VCM such
    as, that for a 0V to 1.8V VCM, MIXER_VGATE = 23.89 VCM + 81, and for a >
    1.8V to 2.6V VCM, MIXER_VGATE = 23.75 VCM + 1.25.
    
    Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013")
    Signed-off-by: Antoniu Miclaus <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: ad3552r: Correct device IDs [+ + +]
Author: Marcelo Schmitt <[email protected]>
Date:   Thu Aug 3 16:56:23 2023 -0300

    iio: dac: ad3552r: Correct device IDs
    
    commit 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 upstream.
    
    Device IDs for AD3542R and AD3552R were swapped leading to unintended
    collection of DAC output ranges being used for each design.
    Change device ID values so they are correct for each DAC chip.
    
    Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support")
    Signed-off-by: Marcelo Schmitt <[email protected]>
    Reported-by: Chandrakant Minajigi <[email protected]>
    Link: https://lore.kernel.org/r/011f480220799fbfabdd53896f8a2f251ad995ad.1691091324.git.marcelo.schmitt1@gmail.com
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: imu: bno055: Fix missing Kconfig dependencies [+ + +]
Author: Jonathan Cameron <[email protected]>
Date:   Sun Sep 3 12:30:52 2023 +0100

    iio: imu: bno055: Fix missing Kconfig dependencies
    
    commit c9b9cfe7d342683f624a89c3b617be18aff879e8 upstream.
    
    This driver uses IIO triggered buffers so it needs to select them in
    Kconfig.
    
    on riscv-32bit:
    
    /opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367':
    bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext'
    
    Reported-by: Randy Dunlap <[email protected]>
    Closes: https://lore.kernel.org/linux-next/[email protected]/
    Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver")
    Cc: Andrea Merello <[email protected]>
    Acked-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: pressure: bmp280: Fix NULL pointer exception [+ + +]
Author: Phil Elwell <[email protected]>
Date:   Fri Aug 11 16:58:29 2023 +0100

    iio: pressure: bmp280: Fix NULL pointer exception
    
    commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream.
    
    The bmp085 EOC IRQ support is optional, but the driver's common probe
    function queries the IRQ properties whether or not it exists, which
    can trigger a NULL pointer exception. Avoid any exception by making
    the query conditional on the possession of a valid IRQ.
    
    Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
    Signed-off-by: Phil Elwell <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: pressure: dps310: Adjust Timeout Settings [+ + +]
Author: Lakshmi Yadlapati <[email protected]>
Date:   Tue Aug 29 13:02:22 2023 -0500

    iio: pressure: dps310: Adjust Timeout Settings
    
    commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream.
    
    The DPS310 sensor chip has been encountering intermittent errors while
    reading the sensor device across various system designs. This issue causes
    the chip to become "stuck," preventing the indication of "ready" status
    for pressure and temperature measurements in the MEAS_CFG register.
    
    To address this issue, this commit fixes the timeout settings to improve
    sensor stability:
    - After sending a reset command to the chip, the timeout has been extended
      from 2.5 ms to 15 ms, aligning with the DPS310 specification.
    - The read timeout value of the MEAS_CFG register has been adjusted from
      20ms to 30ms to match the specification.
    
    Signed-off-by: Lakshmi Yadlapati <[email protected]>
    Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout")
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: pressure: ms5611: ms5611_prom_is_valid false negative bug [+ + +]
Author: Alexander Zangerl <[email protected]>
Date:   Wed Sep 20 10:01:10 2023 +1000

    iio: pressure: ms5611: ms5611_prom_is_valid false negative bug
    
    commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream.
    
    The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips
    with "PROM integrity check failed" because it doesn't accept a prom crc
    value of zero as legitimate.
    
    According to the datasheet for this chip (and the manufacturer's
    application note about the PROM CRC), none of the possible values for the
    CRC are excluded - but the current code in ms5611_prom_is_valid() ends with
    
    return crc_orig != 0x0000 && crc == crc_orig
    
    Discussed with the driver author (Tomasz Duszynski) and he indicated that
    at that time (2015) he was dealing with some faulty chip samples which
    returned blank data under some circumstances and/or followed example code
    which indicated CRC zero being bad.
    
    As far as I can tell this exception should not be applied anymore; We've
    got a few hundred custom boards here with this chip where large numbers
    of the prom have a legitimate CRC value 0, and do work fine, but which the
    current driver code wrongly rejects.
    
    Signed-off-by: Alexander Zangerl <[email protected]>
    Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor")
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Oct 4 07:18:31 2023 -0700

    Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case
    
    commit 423622a90abb243944d1517b9f57db53729e45c4 upstream.
    
    Add a special case for gpio_count == 1 && gpio_int_idx == 0 to
    goodix_add_acpi_gpio_mappings().
    
    It seems that on newer x86/ACPI devices the reset and irq GPIOs are no
    longer listed as GPIO resources instead there is only 1 GpioInt resource
    and _PS0 does the whole reset sequence for us.
    
    This means that we must call acpi_device_fix_up_power() on these devices
    to ensure that the chip is reset before we try to use it.
    
    This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call
    acpi_device_fix_up_power() in some cases") by adding a call to
    acpi_device_fix_up_power() to the generic "Unexpected ACPI resources"
    catch all.
    
    But it turns out that this case on some hw needs some more special
    handling. Specifically the firmware may bootup with the IRQ pin in
    output mode. The reset sequence from ACPI _PS0 (executed by
    acpi_device_fix_up_power()) should put the pin in input mode,
    but the GPIO subsystem has cached the direction at bootup, causing
    request_irq() to fail due to gpiochip_lock_as_irq() failure:
    
    [    9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0
    [    9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060
    [    9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8
    [    9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
    [    9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ
    [    9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio
    [    9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5
    
    Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0
    which adds an ACPI GPIO lookup table for the int GPIO even though we cannot
    use it for reset purposes (as there is no reset GPIO).
    
    Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call
    succeed, which will explicitly set the direction to input fixing the issue.
    
    Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since
    there is only 1 GPIO in the ACPI resources the reset entry in that
    lookup table will amount to a no-op.
    
    Reported-and-tested-by: Michael Smith <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table [+ + +]
Author: Szilard Fabian <[email protected]>
Date:   Wed Oct 4 05:47:01 2023 -0700

    Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table
    
    commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 upstream.
    
    In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411
    refuses to work and it's not possible to type for example a dm-crypt
    passphrase without the help of an external keyboard.
    
    i8042.nomux kernel parameter resolves this issue but using that a PS/2
    mouse is detected. This input device is unused even when the i2c-hid-acpi
    kernel module is blacklisted making the integrated ELAN touchpad
    (04F3:308A) not working at all.
    
    Since the integrated touchpad is managed by the i2c_designware input
    driver in the Linux kernel and you can't find a PS/2 mouse port on the
    computer I think it's safe to not use the PS/2 mouse port at all.
    
    Signed-off-by: Szilard Fabian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: powermate - fix use-after-free in powermate_config_complete [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Fri Oct 13 20:11:33 2023 -0700

    Input: powermate - fix use-after-free in powermate_config_complete
    
    commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream.
    
    syzbot has found a use-after-free bug [1] in the powermate driver. This
    happens when the device is disconnected, which leads to a memory free from
    the powermate_device struct.  When an asynchronous control message
    completes after the kfree and its callback is invoked, the lock does not
    exist anymore and hence the bug.
    
    Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
    device disconnection.
    
    [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
    
    Signed-off-by: Javier Carrasco <[email protected]>
    Reported-by: [email protected]
    Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: psmouse - fix fast_reconnect function for PS/2 mode [+ + +]
Author: Jeffery Miller <[email protected]>
Date:   Fri Oct 13 15:23:49 2023 -0700

    Input: psmouse - fix fast_reconnect function for PS/2 mode
    
    commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream.
    
    When the SMBus connection is attempted psmouse_smbus_init() sets
    the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus
    initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will
    fallback to PS/2 mode, replacing the psmouse private data. This can cause
    issues on resume, since psmouse_smbus_reconnect() expects to find an
    instance of struct psmouse_smbus_dev in psmouse->private.
    
    The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add
    delay when deactivating for SMBus mode") psmouse_smbus_reconnect()
    started attempting to use more of the data structure. The commit was
    since reverted, not because it was at fault, but because there was found
    a better way of doing what it was attempting to do.
    
    Fix the problem by resetting the fast_reconnect pointer in psmouse
    structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2
    mode is used.
    
    Reported-by: Thorsten Leemhuis <[email protected]>
    Tested-by: Thorsten Leemhuis <[email protected]>
    Signed-off-by: Jeffery Miller <[email protected]>
    Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: xpad - add PXN V900 support [+ + +]
Author: Matthias Berndt <[email protected]>
Date:   Fri Oct 13 15:04:36 2023 -0700

    Input: xpad - add PXN V900 support
    
    commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream.
    
    Add VID and PID to the xpad_device table to allow driver to use the PXN
    V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode.
    
    Signed-off-by: Matthias Berndt <[email protected]>
    Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
irqchip: renesas-rzg2l: Fix logic to clear TINT interrupt source [+ + +]
Author: Biju Das <[email protected]>
Date:   Mon Sep 18 13:24:09 2023 +0100

    irqchip: renesas-rzg2l: Fix logic to clear TINT interrupt source
    
    commit 9b8df572ba3f4e544366196820a719a40774433e upstream.
    
    The logic to clear the TINT interrupt source in rzg2l_irqc_irq_disable()
    is wrong as the mask is correct only for LSB on the TSSR register.
    This issue is found when testing with two TINT interrupt sources. So fix
    the logic for all TINTs by using the macro TSSEL_SHIFT() to multiply
    tssr_offset with 8.
    
    Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver")
    Signed-off-by: Biju Das <[email protected]>
    Tested-by: Claudiu Beznea <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ixgbe: fix crash with empty VF macvlan list [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Oct 6 15:53:09 2023 +0300

    ixgbe: fix crash with empty VF macvlan list
    
    [ Upstream commit 7b5add9af567c44e12196107f0fe106e194034fd ]
    
    The adapter->vf_mvs.l list needs to be initialized even if the list is
    empty.  Otherwise it will lead to crashes.
    
    Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Jesse Brandeburg <[email protected]>
    Link: https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KEYS: trusted: Remove redundant static calls usage [+ + +]
Author: Sumit Garg <[email protected]>
Date:   Fri Oct 6 10:48:01 2023 +0530

    KEYS: trusted: Remove redundant static calls usage
    
    commit 01bbafc63b65689cb179ca537971286bc27f3b74 upstream.
    
    Static calls invocations aren't well supported from module __init and
    __exit functions. Especially the static call from cleanup_trusted() led
    to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y.
    
    However, the usage of static call invocations for trusted_key_init()
    and trusted_key_exit() don't add any value from either a performance or
    security perspective. Hence switch to use indirect function calls instead.
    
    Note here that although it will fix the current crash report, ultimately
    the static call infrastructure should be fixed to either support its
    future usage from module __init and __exit functions or not.
    
    Reported-and-tested-by: Hyeonggon Yoo <[email protected]>
    Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t
    Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
    Signed-off-by: Sumit Garg <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ksmbd: not allow to open file if delelete on close bit is set [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Fri Oct 6 10:41:36 2023 +0900

    ksmbd: not allow to open file if delelete on close bit is set
    
    commit f43328357defc0dc9d28dbd06dc3361fd2b22e28 upstream.
    
    Cthon test fail with the following error.
    
    check for proper open/unlink operation
    nfsjunk files before unlink:
      -rwxr-xr-x 1 root root 0  9ì›” 25 11:03 ./nfs2y8Jm9
    ./nfs2y8Jm9 open; unlink ret = 0
    nfsjunk files after unlink:
      -rwxr-xr-x 1 root root 0  9ì›” 25 11:03 ./nfs2y8Jm9
    data compare ok
    nfsjunk files after close:
      ls: cannot access './nfs2y8Jm9': No such file or directory
    special tests failed
    
    Cthon expect to second unlink failure when file is already unlinked.
    ksmbd can not allow to open file if flags of ksmbd inode is set with
    S_DEL_ON_CLS flags.
    
    Cc: [email protected]
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
libceph: use kernel_connect() [+ + +]
Author: Jordan Rife <[email protected]>
Date:   Wed Oct 4 18:38:27 2023 -0500

    libceph: use kernel_connect()
    
    commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.
    
    Direct calls to ops->connect() can overwrite the address parameter when
    used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
    kernel_connect() ensure that callers are insulated from such side
    effects. This patch wraps the direct call to ops->connect() with
    kernel_connect() to prevent unexpected changes to the address passed to
    ceph_tcp_connect().
    
    This change was originally part of a larger patch targeting the net tree
    addressing all instances of unprotected calls to ops->connect()
    throughout the kernel, but this change was split up into several patches
    targeting various trees.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/netdev/[email protected]/
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
    Signed-off-by: Jordan Rife <[email protected]>
    Reviewed-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.1.59 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Oct 19 23:08:58 2023 +0200

    Linux 6.1.59
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ricardo B. Marliere <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mcb: remove is_added flag from mcb_device struct [+ + +]
Author: Jorge Sanjuan Garcia <[email protected]>
Date:   Wed Sep 6 11:49:26 2023 +0000

    mcb: remove is_added flag from mcb_device struct
    
    commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream.
    
    When calling mcb_bus_add_devices(), both mcb devices and the mcb
    bus will attempt to attach a device to a driver because they share
    the same bus_type. This causes an issue when trying to cast the
    container of the device to mcb_device struct using to_mcb_device(),
    leading to a wrong cast when the mcb_bus is added. A crash occurs
    when freing the ida resources as the bus numbering of mcb_bus gets
    confused with the is_added flag on the mcb_device struct.
    
    The only reason for this cast was to keep an is_added flag on the
    mcb_device struct that does not seem necessary. The function
    device_attach() handles already bound devices and the mcb subsystem
    does nothing special with this is_added flag so remove it completely.
    
    Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device")
    Cc: stable <[email protected]>
    Signed-off-by: Jorge Sanjuan Garcia <[email protected]>
    Co-developed-by: Jose Javier Rodriguez Barbarin <[email protected]>
    Signed-off-by: Jose Javier Rodriguez Barbarin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mctp: perform route lookups under a RCU read-side lock [+ + +]
Author: Jeremy Kerr <[email protected]>
Date:   Mon Oct 9 15:56:45 2023 +0800

    mctp: perform route lookups under a RCU read-side lock
    
    commit 5093bbfc10ab6636b32728e35813cbd79feb063c upstream.
    
    Our current route lookups (mctp_route_lookup and mctp_route_lookup_null)
    traverse the net's route list without the RCU read lock held. This means
    the route lookup is subject to preemption, resulting in an potential
    grace period expiry, and so an eventual kfree() while we still have the
    route pointer.
    
    Add the proper read-side critical section locks around the route
    lookups, preventing premption and a possible parallel kfree.
    
    The remaining net->mctp.routes accesses are already under a
    rcu_read_lock, or protected by the RTNL for updates.
    
    Based on an analysis from Sili Luo <[email protected]>, where
    introducing a delay in the route lookup could cause a UAF on
    simultaneous sendmsg() and route deletion.
    
    Reported-by: Sili Luo <[email protected]>
    Fixes: 889b7da23abf ("mctp: Add initial routing framework")
    Cc: [email protected]
    Signed-off-by: Jeremy Kerr <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/29c4b0e67dc1bf3571df3982de87df90cae9b631.1696837310.git.jk@codeconstruct.com.au
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mlxsw: fix mlxsw_sp2_nve_vxlan_learning_set() return type [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Oct 5 17:00:12 2023 +0300

    mlxsw: fix mlxsw_sp2_nve_vxlan_learning_set() return type
    
    [ Upstream commit 1e0b72a2a6432c0ef67ee5ce8d9172a7c20bba25 ]
    
    The mlxsw_sp2_nve_vxlan_learning_set() function is supposed to return
    zero on success or negative error codes.  So it needs to be type int
    instead of bool.
    
    Fixes: 4ee70efab68d ("mlxsw: spectrum_nve: Add support for VXLAN on Spectrum-2")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Petr Machata <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mptcp: fix delegated action races [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Wed Oct 4 13:38:11 2023 -0700

    mptcp: fix delegated action races
    
    [ Upstream commit a5efdbcece83af94180e8d7c0a6e22947318499d ]
    
    The delegated action infrastructure is prone to the following
    race: different CPUs can try to schedule different delegated
    actions on the same subflow at the same time.
    
    Each of them will check different bits via mptcp_subflow_delegate(),
    and will try to schedule the action on the related per-cpu napi
    instance.
    
    Depending on the timing, both can observe an empty delegated list
    node, causing the same entry to be added simultaneously on two different
    lists.
    
    The root cause is that the delegated actions infra does not provide
    a single synchronization point. Address the issue reserving an additional
    bit to mark the subflow as scheduled for delegation. Acquiring such bit
    guarantee the caller to own the delegated list node, and being able to
    safely schedule the subflow.
    
    Clear such bit only when the subflow scheduling is completed, ensuring
    proper barrier in place.
    
    Additionally swap the meaning of the delegated_action bitmask, to allow
    the usage of the existing helper to set multiple bit at once.
    
    Fixes: bcd97734318d ("mptcp: use delegate action to schedule 3rd ack retrans")
    Cc: [email protected]
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp [+ + +]
Author: Will Mortensen <[email protected]>
Date:   Thu Oct 5 22:37:06 2023 -0700

    net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp
    
    [ Upstream commit da6192ca72d5ad913d109d43dc896290ad05d98f ]
    
    Commit 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs
    flag change") seems to have accidentally inverted the logic added in
    commit 0bc73ad46a76 ("net/mlx5e: Mutually exclude RX-FCS and
    RX-port-timestamp").
    
    The impact of this is a little unclear since it seems the FCS scattered
    with RX-FCS is (usually?) correct regardless.
    
    Fixes: 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change")
    Tested-by: Charlotte Tan <[email protected]>
    Reviewed-by: Charlotte Tan <[email protected]>
    Cc: Adham Faris <[email protected]>
    Cc: Aya Levin <[email protected]>
    Cc: Tariq Toukan <[email protected]>
    Cc: Moshe Shemesh <[email protected]>
    Cc: Saeed Mahameed <[email protected]>
    Signed-off-by: Will Mortensen <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: macsec: use update_pn flag instead of PN comparation [+ + +]
Author: Radu Pirea (NXP OSS) <[email protected]>
Date:   Thu Oct 5 21:06:36 2023 +0300

    net/mlx5e: macsec: use update_pn flag instead of PN comparation
    
    [ Upstream commit fde2f2d7f23d39f2fc699ba6d91ac3f4a2e637ca ]
    
    When updating the SA, use the new update_pn flags instead of comparing the
    new PN with the initial one.
    
    Comparing the initial PN value with the new value will allow the user
    to update the SA using the initial PN value as a parameter like this:
    $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
    ead3664f508eb06c40ac7104cdae4ce5
    $ ip macsec set macsec0 tx sa 0 pn 1 off
    
    Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support")
    Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support")
    Signed-off-by: Radu Pirea (NXP OSS) <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/smc: Fix pos miscalculation in statistics [+ + +]
Author: Nils Hoppmann <[email protected]>
Date:   Mon Oct 9 16:40:48 2023 +0200

    net/smc: Fix pos miscalculation in statistics
    
    [ Upstream commit a950a5921db450c74212327f69950ff03419483a ]
    
    SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) will calculate
    wrong bucket positions for payloads of exactly 4096 bytes and
    (1 << (m + 12)) bytes, with m == SMC_BUF_MAX - 1.
    
    Intended bucket distribution:
    Assume l == size of payload, m == SMC_BUF_MAX - 1.
    
    Bucket 0                : 0 < l <= 2^13
    Bucket n, 1 <= n <= m-1 : 2^(n+12) < l <= 2^(n+13)
    Bucket m                : l > 2^(m+12)
    
    Current solution:
    _pos = fls64((l) >> 13)
    [...]
    _pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m
    
    For l == 4096, _pos == -1, but should be _pos == 0.
    For l == (1 << (m + 12)), _pos == m, but should be _pos == m - 1.
    
    In order to avoid special treatment of these corner cases, the
    calculation is adjusted. The new solution first subtracts the length by
    one, and then calculates the correct bucket by shifting accordingly,
    i.e. _pos = fls64((l - 1) >> 13), l > 0.
    This not only fixes the issues named above, but also makes the whole
    bucket assignment easier to follow.
    
    Same is done for SMC_STAT_RMB_SIZE_SUB(_smc_stats, _tech, k, _len),
    where the calculation of the bucket position is similar to the one
    named above.
    
    Fixes: e0e4b8fa5338 ("net/smc: Add SMC statistics support")
    Suggested-by: Halil Pasic <[email protected]>
    Signed-off-by: Nils Hoppmann <[email protected]>
    Reviewed-by: Halil Pasic <[email protected]>
    Reviewed-by: Wenjia Zhang <[email protected]>
    Reviewed-by: Dust Li <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames [+ + +]
Author: Marek Behún <[email protected]>
Date:   Wed Oct 4 11:19:04 2023 +0200

    net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames
    
    [ Upstream commit 526c8ee04bdbd4d8d19a583b1f3b06700229a815 ]
    
    Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus
    also Micron ethernet PHY (dedicated to the WAN port).
    
    We've been experiencing a strange behavior of the WAN ethernet
    interface, wherein the WAN PHY started timing out the MDIO accesses, for
    example when the interface was brought down and then back up.
    
    Bisecting led to commit 2cd548566384 ("net: dsa: qca8k: add support for
    phy read/write with mgmt Ethernet"), which added support to access the
    QCA8337 switch's internal PHYs via management ethernet frames.
    
    Connecting the MDIO bus pins onto an oscilloscope, I was able to see
    that the MDIO bus was active whenever a request to read/write an
    internal PHY register was done via an management ethernet frame.
    
    My theory is that when the switch core always communicates with the
    internal PHYs via the MDIO bus, even when externally we request the
    access via ethernet. This MDIO bus is the same one via which the switch
    and internal PHYs are accessible to the board, and the board may have
    other devices connected on this bus. An ASCII illustration may give more
    insight:
    
               +---------+
          +----|         |
          |    | WAN PHY |
          | +--|         |
          | |  +---------+
          | |
          | |  +----------------------------------+
          | |  | QCA8337                          |
    MDC   | |  |                        +-------+ |
    ------o-+--|--------o------------o--|       | |
    MDIO    |  |        |            |  | PHY 1 |-|--to RJ45
    --------o--|---o----+---------o--+--|       | |
               |   |    |         |  |  +-------+ |
               | +-------------+  |  o--|       | |
               | | MDIO MDC    |  |  |  | PHY 2 |-|--to RJ45
    eth1       | |             |  o--+--|       | |
    -----------|-|port0        |  |  |  +-------+ |
               | |             |  |  o--|       | |
               | | switch core |  |  |  | PHY 3 |-|--to RJ45
               | +-------------+  o--+--|       | |
               |                  |  |  +-------+ |
               |                  |  o--|  ...  | |
               +----------------------------------+
    
    When we send a request to read an internal PHY register via an ethernet
    management frame via eth1, the switch core receives the ethernet frame
    on port 0 and then communicates with the internal PHY via MDIO. At this
    time, other potential devices, such as the WAN PHY on Turris 1.x, cannot
    use the MDIO bus, since it may cause a bus conflict.
    
    Fix this issue by locking the MDIO bus even when we are accessing the
    PHY registers via ethernet management frames.
    
    Fixes: 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet")
    Signed-off-by: Marek Behún <[email protected]>
    Reviewed-by: Christian Marangi <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: macsec: indicate next pn update when offloading [+ + +]
Author: Radu Pirea (NXP OSS) <[email protected]>
Date:   Thu Oct 5 21:06:33 2023 +0300

    net: macsec: indicate next pn update when offloading
    
    [ Upstream commit 0412cc846a1ef38697c3f321f9b174da91ecd3b5 ]
    
    Indicate next PN update using update_pn flag in macsec_context.
    Offloaded MACsec implementations does not know whether or not the
    MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume
    that next PN should always updated, but this is not always true.
    
    The PN can be reset to its initial value using the following command:
    $ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case
    
    Or, the update PN command will succeed even if the driver does not support
    PN updates.
    $ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case
    
    Comparing the initial PN with the new PN value is not a solution. When
    the user updates the PN using its initial value the command will
    succeed, even if the driver does not support it. Like this:
    $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
    ead3664f508eb06c40ac7104cdae4ce5
    $ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case
    
    Signed-off-by: Radu Pirea (NXP OSS) <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: e0a8c918daa5 ("net: phy: mscc: macsec: reject PN update requests")
    Signed-off-by: Sasha Levin <[email protected]>

net: mana: Fix TX CQE error handling [+ + +]
Author: Haiyang Zhang <[email protected]>
Date:   Fri Sep 29 13:42:25 2023 -0700

    net: mana: Fix TX CQE error handling
    
    [ Upstream commit b2b000069a4c307b09548dc2243f31f3ca0eac9c ]
    
    For an unknown TX CQE error type (probably from a newer hardware),
    still free the SKB, update the queue tail, etc., otherwise the
    accounting will be wrong.
    
    Also, TX errors can be triggered by injecting corrupted packets, so
    replace the WARN_ONCE to ratelimited error logging.
    
    Cc: [email protected]
    Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
    Signed-off-by: Haiyang Zhang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Shradha Gupta <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 9 12:31:10 2023 +0000

    net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
    
    [ Upstream commit 31c07dffafce914c1d1543c135382a11ff058d93 ]
    
    Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
    
    Getting a reference on the socket found in a lookup while
    holding a lock should happen before releasing the lock.
    
    nfc_llcp_sock_get_sn() has a similar problem.
    
    Finally nfc_llcp_recv_snl() needs to make sure the socket
    found by nfc_llcp_sock_from_sn() does not disappear.
    
    Fixes: 8f50020ed9b8 ("NFC: LLCP late binding")
    Reported-by: Sili Luo <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: mscc: macsec: reject PN update requests [+ + +]
Author: Radu Pirea (NXP OSS) <[email protected]>
Date:   Thu Oct 5 21:06:35 2023 +0300

    net: phy: mscc: macsec: reject PN update requests
    
    [ Upstream commit e0a8c918daa58700609ebd45e3fcd49965be8bbc ]
    
    Updating the PN is not supported.
    Return -EINVAL if update_pn is true.
    
    The following command succeeded, but it should fail because the driver
    does not update the PN:
    ip macsec set macsec0 tx sa 0 pn 232 on
    
    Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
    Signed-off-by: Radu Pirea (NXP OSS) <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: prevent address rewrite in kernel_bind() [+ + +]
Author: Jordan Rife <[email protected]>
Date:   Thu Sep 21 18:46:42 2023 -0500

    net: prevent address rewrite in kernel_bind()
    
    commit c889a99a21bf124c3db08d09df919f0eccc5ea4c upstream.
    
    Similar to the change in commit 0bdf399342c5("net: Avoid address
    overwrite in kernel_connect"), BPF hooks run on bind may rewrite the
    address passed to kernel_bind(). This change
    
    1) Makes a copy of the bind address in kernel_bind() to insulate
       callers.
    2) Replaces direct calls to sock->ops->bind() in net with kernel_bind()
    
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind")
    Cc: [email protected]
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: Jordan Rife <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: refine debug info in skb_checksum_help() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 6 17:33:54 2023 +0000

    net: refine debug info in skb_checksum_help()
    
    [ Upstream commit 26c29961b142444cd99361644c30fa1e9b3da6be ]
    
    syzbot uses panic_on_warn.
    
    This means that the skb_dump() I added in the blamed commit are
    not even called.
    
    Rewrite this so that we get the needed skb dump before syzbot crashes.
    
    Fixes: eeee4b77dc52 ("net: add more debug info in skb_checksum_help()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Tue Oct 10 00:26:14 2023 +0200

    net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read
    
    commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream.
    
    syzbot has found an uninit-value bug triggered by the dm9601 driver [1].
    
    This error happens because the variable res is not updated if the call
    to dm_read_shared_word returns an error. In this particular case -EPROTO
    was returned and res stayed uninitialized.
    
    This can be avoided by checking the return value of dm_read_shared_word
    and propagating the error if the read operation failed.
    
    [1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955
    
    Cc: [email protected]
    Signed-off-by: Javier Carrasco <[email protected]>
    Reported-and-tested-by: [email protected]
    Acked-by: Peter Korsgaard <[email protected]>
    Fixes: d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver")
    Link: https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nfc: nci: assert requested protocol is valid [+ + +]
Author: Jeremy Cline <[email protected]>
Date:   Mon Oct 9 16:00:54 2023 -0400

    nfc: nci: assert requested protocol is valid
    
    [ Upstream commit 354a6e707e29cb0c007176ee5b8db8be7bd2dee0 ]
    
    The protocol is used in a bit mask to determine if the protocol is
    supported. Assert the provided protocol is less than the maximum
    defined so it doesn't potentially perform a shift-out-of-bounds and
    provide a clearer error for undefined protocols vs unsupported ones.
    
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=0839b78e119aae1fec78
    Signed-off-by: Jeremy Cline <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfp: flower: avoid rmmod nfp crash issues [+ + +]
Author: Yanguo Li <[email protected]>
Date:   Mon Oct 9 13:21:55 2023 +0200

    nfp: flower: avoid rmmod nfp crash issues
    
    commit 14690995c14109852c7ba6e316045c02e4254272 upstream.
    
    When there are CT table entries, and you rmmod nfp, the following
    events can happen:
    
    task1:
        nfp_net_pci_remove
              ↓
        nfp_flower_stop->(asynchronous)tcf_ct_flow_table_cleanup_work(3)
              ↓
        nfp_zone_table_entry_destroy(1)
    
    task2:
        nfp_fl_ct_handle_nft_flow(2)
    
    When the execution order is (1)->(2)->(3), it will crash. Therefore, in
    the function nfp_fl_ct_del_flow, nf_flow_table_offload_del_cb needs to
    be executed synchronously.
    
    At the same time, in order to solve the deadlock problem and the problem
    of rtnl_lock sometimes failing, replace rtnl_lock with the private
    nfp_fl_lock.
    
    Fixes: 7cc93d888df7 ("nfp: flower-ct: remove callback delete deadlock")
    Cc: [email protected]
    Signed-off-by: Yanguo Li <[email protected]>
    Signed-off-by: Louis Peens <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7 [+ + +]
Author: Jing Zhang <[email protected]>
Date:   Mon Sep 25 11:22:32 2023 +0800

    perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7
    
    [ Upstream commit 7f949f6f54ff593123ab95b6247bfa4542a65580 ]
    
    The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7
    to 0. But in arm_cmn_handle_irq(), only handled the overflow status of
    Bits[3:0] which results in unhandled overflow status of counters 4 to 7.
    
    So let the overflow status of DTC counters 4 to 7 to be handled.
    
    Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
    Signed-off-by: Jing Zhang <[email protected]>
    Reviewed-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/x86/lbr: Filter vsyscall addresses [+ + +]
Author: JP Kobryn <[email protected]>
Date:   Fri Oct 6 11:57:26 2023 -0700

    perf/x86/lbr: Filter vsyscall addresses
    
    commit e53899771a02f798d436655efbd9d4b46c0f9265 upstream.
    
    We found that a panic can occur when a vsyscall is made while LBR sampling
    is active. If the vsyscall is interrupted (NMI) for perf sampling, this
    call sequence can occur (most recent at top):
    
        __insn_get_emulate_prefix()
        insn_get_emulate_prefix()
        insn_get_prefixes()
        insn_get_opcode()
        decode_branch_type()
        get_branch_type()
        intel_pmu_lbr_filter()
        intel_pmu_handle_irq()
        perf_event_nmi_handler()
    
    Within __insn_get_emulate_prefix() at frame 0, a macro is called:
    
        peek_nbyte_next(insn_byte_t, insn, i)
    
    Within this macro, this dereference occurs:
    
        (insn)->next_byte
    
    Inspecting registers at this point, the value of the next_byte field is the
    address of the vsyscall made, for example the location of the vsyscall
    version of gettimeofday() at 0xffffffffff600000. The access to an address
    in the vsyscall region will trigger an oops due to an unhandled page fault.
    
    To fix the bug, filtering for vsyscalls can be done when
    determining the branch type. This patch will return
    a "none" branch if a kernel address if found to lie in the
    vsyscall region.
    
    Suggested-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: JP Kobryn <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
phy: lynx-28g: cancel the CDR check work item on the remove path [+ + +]
Author: Ioana Ciornei <[email protected]>
Date:   Wed Oct 4 14:17:06 2023 +0300

    phy: lynx-28g: cancel the CDR check work item on the remove path
    
    [ Upstream commit f200bab3756fe81493a1b280180dafa1d9ccdcf7 ]
    
    The blamed commit added the CDR check work item but didn't cancel it on
    the remove path. Fix this by adding a remove function which takes care
    of it.
    
    Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")
    Signed-off-by: Ioana Ciornei <[email protected]>
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

phy: lynx-28g: lock PHY while performing CDR lock workaround [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Wed Oct 4 14:17:07 2023 +0300

    phy: lynx-28g: lock PHY while performing CDR lock workaround
    
    [ Upstream commit 0ac87fe54a171d18c5fb5345e3ee8d14e1b06f4b ]
    
    lynx_28g_cdr_lock_check() runs once per second in a workqueue to reset
    the lane receiver if the CDR has not locked onto bit transitions in the
    RX stream. But the PHY consumer may do stuff with the PHY simultaneously,
    and that isn't okay. Block concurrent generic PHY calls by holding the
    PHY mutex from this workqueue.
    
    Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Wed Oct 4 14:17:08 2023 +0300

    phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers
    
    [ Upstream commit 139ad1143151a07be93bf741d4ea7c89e59f89ce ]
    
    The protocol converter configuration registers PCC8, PCCC, PCCD
    (implemented by the driver), as well as others, control protocol
    converters from multiple lanes (each represented as a different
    struct phy). So, if there are simultaneous calls to phy_set_mode_ext()
    to lanes sharing the same PCC register (either for the "old" or for the
    "new" protocol), corruption of the values programmed to hardware is
    possible, because lynx_28g_rmw() has no locking.
    
    Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take
    the global spinlock from the phy_ops :: set_mode() implementation. There
    are no other callers which modify PCC registers.
    
    Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pinctrl: avoid unsafe code pattern in find_pinctrl() [+ + +]
Author: Dmitry Torokhov <[email protected]>
Date:   Wed Sep 20 11:09:10 2023 -0700

    pinctrl: avoid unsafe code pattern in find_pinctrl()
    
    commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream.
    
    The code in find_pinctrl() takes a mutex and traverses a list of pinctrl
    structures. Later the caller bumps up reference count on the found
    structure. Such pattern is not safe as pinctrl that was found may get
    deleted before the caller gets around to increasing the reference count.
    
    Fix this by taking the reference count in find_pinctrl(), while it still
    holds the mutex.
    
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pinctrl: nuvoton: wpcm450: fix out of bounds write [+ + +]
Author: Mikhail Kobuk <[email protected]>
Date:   Fri Aug 25 13:15:28 2023 +0300

    pinctrl: nuvoton: wpcm450: fix out of bounds write
    
    [ Upstream commit 87d315a34133edcb29c4cadbf196ec6c30dfd47b ]
    
    Write into 'pctrl->gpio_bank' happens before the check for GPIO index
    validity, so out of bounds write may happen.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: a1d1e0e3d80a ("pinctrl: nuvoton: Add driver for WPCM450")
    Signed-off-by: Mikhail Kobuk <[email protected]>
    Reviewed-by: Alexey Khoroshilov <[email protected]>
    Reviewed-by: Jonathan Neuschäfer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: renesas: rzn1: Enable missing PINMUX [+ + +]
Author: Ralph Siemsen <[email protected]>
Date:   Wed Oct 4 16:00:08 2023 -0400

    pinctrl: renesas: rzn1: Enable missing PINMUX
    
    [ Upstream commit f055ff23c331f28aa4ace4b72dc56f63b9a726c8 ]
    
    Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO
    pins will be configured as specified by the pinmux in the DTS.
    
    This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS,
    however that was removed, since the RZ/N1 driver does not call any of
    the generic pinmux functions.
    
    Fixes: 1308fb4e4eae14e6 ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}")
    Signed-off-by: Ralph Siemsen <[email protected]>
    Reviewed-by: Miquel Raynal <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section mismatch warning [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Oct 4 13:16:24 2023 +0200

    platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section mismatch warning
    
    [ Upstream commit 5b44abbc39ca15df80d0da4756078c98c831090f ]
    
    As described in the added code comment, a reference to .exit.text is ok
    for drivers registered via module_platform_driver_probe(). Make this
    explicit to prevent a section mismatch warning:
    
            WARNING: modpost: drivers/platform/x86/hp/hp-wmi: section mismatch in reference: hp_wmi_driver+0x8 (section: .data) -> hp_wmi_bios_remove (section: .exit.text)
    
    Fixes: c165b80cfecc ("hp-wmi: fix handling of platform device")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: think-lmi: Fix reference leak [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Mon Sep 25 16:28:18 2023 +0200

    platform/x86: think-lmi: Fix reference leak
    
    [ Upstream commit 528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81 ]
    
    If a duplicate attribute is found using kset_find_obj(), a reference
    to that attribute is returned which needs to be disposed accordingly
    using kobject_put(). Move the setting name validation into a separate
    function to allow for this change without having to duplicate the
    cleanup code for this setting.
    As a side note, a very similar bug was fixed in
    commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),
    so it seems that the bug was copied from that driver.
    
    Compile-tested only.
    
    Fixes: 1bcad8e510b2 ("platform/x86: think-lmi: Fix issues with duplicate attributes")
    Reviewed-by: Mark Pearson <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/47x: Fix 47x syscall return crash [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Tue Oct 10 22:47:50 2023 +1100

    powerpc/47x: Fix 47x syscall return crash
    
    commit f0eee815babed70a749d2496a7678be5b45b4c14 upstream.
    
    Eddie reported that newer kernels were crashing during boot on his 476
    FSP2 system:
    
      kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)
      BUG: Unable to handle kernel instruction fetch
      Faulting instruction address: 0xb7ee2000
      Oops: Kernel access of bad area, sig: 11 [#1]
      BE PAGE_SIZE=4K FSP-2
      Modules linked in:
      CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
      Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
      NIP:  b7ee2000 LR: 8c008000 CTR: 00000000
      REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2)
      MSR:  00000030 <IR,DR>  CR: 00001000  XER: 20000000
      GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000
      GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000
      GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0
      GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0
      NIP [b7ee2000] 0xb7ee2000
      LR [8c008000] 0x8c008000
      Call Trace:
      Instruction dump:
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      ---[ end trace 0000000000000000 ]---
    
    The problem is in ret_from_syscall where the check for
    icache_44x_need_flush is done. When the flush is needed the code jumps
    out-of-line to do the flush, and then intends to jump back to continue
    the syscall return.
    
    However the branch back to label 1b doesn't return to the correct
    location, instead branching back just prior to the return to userspace,
    causing bogus register values to be used by the rfi.
    
    The breakage was introduced by commit 6f76a01173cc
    ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which
    inadvertently removed the "1" label and reused it elsewhere.
    
    Fix it by adding named local labels in the correct locations. Note that
    the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n
    compiles.
    
    Fixes: 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32")
    Cc: [email protected] # v5.12+
    Reported-by: Eddie James <[email protected]>
    Tested-by: Eddie James <[email protected]>
    Link: https://lore.kernel.org/linuxppc-dev/[email protected]/
    Signed-off-by: Michael Ellerman <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/64e: Fix wrong test in __ptep_test_and_clear_young() [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon Sep 25 20:31:16 2023 +0200

    powerpc/64e: Fix wrong test in __ptep_test_and_clear_young()
    
    [ Upstream commit 5ea0bbaa32e8f54e9a57cfee4a3b8769b80be0d2 ]
    
    Commit 45201c879469 ("powerpc/nohash: Remove hash related code from
    nohash headers.") replaced:
    
      if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0)
            return 0;
    
    By:
    
      if (pte_young(*ptep))
            return 0;
    
    But it should be:
    
      if (!pte_young(*ptep))
            return 0;
    
    Fix it.
    
    Fixes: 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/8bb7f06494e21adada724ede47a4c3d97e879d40.1695659959.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/8xx: Fix pte_access_permitted() for PAGE_NONE [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon Sep 25 20:31:15 2023 +0200

    powerpc/8xx: Fix pte_access_permitted() for PAGE_NONE
    
    [ Upstream commit 5d9cea8a552ee122e21fbd5a3c5d4eb85f648e06 ]
    
    On 8xx, PAGE_NONE is handled by setting _PAGE_NA instead of clearing
    _PAGE_USER.
    
    But then pte_user() returns 1 also for PAGE_NONE.
    
    As _PAGE_NA prevent reads, add a specific version of pte_read()
    that returns 0 when _PAGE_NA is set instead of always returning 1.
    
    Fixes: 351750331fc1 ("powerpc/mm: Introduce _PAGE_NA")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/57bcfbe578e43123f9ed73e040229b80f1ad56ec.1695659959.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
quota: Fix slow quotaoff [+ + +]
Author: Jan Kara <[email protected]>
Date:   Wed Oct 4 15:32:01 2023 +0200

    quota: Fix slow quotaoff
    
    commit 869b6ea1609f655a43251bf41757aa44e5350a8f upstream.
    
    Eric has reported that commit dabc8b207566 ("quota: fix dqput() to
    follow the guarantees dquot_srcu should provide") heavily increases
    runtime of generic/270 xfstest for ext4 in nojournal mode. The reason
    for this is that ext4 in nojournal mode leaves dquots dirty until the last
    dqput() and thus the cleanup done in quota_release_workfn() has to write
    them all. Due to the way quota_release_workfn() is written this results
    in synchronize_srcu() call for each dirty dquot which makes the dquot
    cleanup when turning quotas off extremely slow.
    
    To be able to avoid synchronize_srcu() for each dirty dquot we need to
    rework how we track dquots to be cleaned up. Instead of keeping the last
    dquot reference while it is on releasing_dquots list, we drop it right
    away and mark the dquot with new DQ_RELEASING_B bit instead. This way we
    can we can remove dquot from releasing_dquots list when new reference to
    it is acquired and thus there's no need to call synchronize_srcu() each
    time we drop dq_list_lock.
    
    References: https://lore.kernel.org/all/ZRytn6CxFK2oECUt@debian-BULLSEYE-live-builder-AMD64
    Reported-by: Eric Whitney <[email protected]>
    Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    CC: [email protected]
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ravb: Fix up dma_free_coherent() call in ravb_remove() [+ + +]
Author: Yoshihiro Shimoda <[email protected]>
Date:   Thu Oct 5 10:12:00 2023 +0900

    ravb: Fix up dma_free_coherent() call in ravb_remove()
    
    [ Upstream commit e6864af61493113558c502b5cd0d754c19b93277 ]
    
    In ravb_remove(), dma_free_coherent() should be call after
    unregister_netdev(). Otherwise, this controller is possible to use
    the freed buffer.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yoshihiro Shimoda <[email protected]>
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ravb: Fix use-after-free issue in ravb_tx_timeout_work() [+ + +]
Author: Yoshihiro Shimoda <[email protected]>
Date:   Thu Oct 5 10:12:01 2023 +0900

    ravb: Fix use-after-free issue in ravb_tx_timeout_work()
    
    [ Upstream commit 3971442870713de527684398416970cf025b4f89 ]
    
    The ravb_stop() should call cancel_work_sync(). Otherwise,
    ravb_tx_timeout_work() is possible to use the freed priv after
    ravb_remove() was called like below:
    
    CPU0                    CPU1
                            ravb_tx_timeout()
    ravb_remove()
    unregister_netdev()
    free_netdev(ndev)
    // free priv
                            ravb_tx_timeout_work()
                            // use priv
    
    unregister_netdev() will call .ndo_stop() so that ravb_stop() is
    called. And, after phy_stop() is called, netif_carrier_off()
    is also called. So that .ndo_tx_timeout() will not be called
    after phy_stop().
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reported-by: Zheng Wang <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Yoshihiro Shimoda <[email protected]>
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cxgb4: Check skb value for failure to allocate [+ + +]
Author: Artem Chernyshev <[email protected]>
Date:   Tue Sep 5 15:40:48 2023 +0300

    RDMA/cxgb4: Check skb value for failure to allocate
    
    [ Upstream commit 8fb8a82086f5bda6893ea6557c5a458e4549c6d7 ]
    
    get_skb() can fail to allocate skb, so check it.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 5be78ee924ae ("RDMA/cxgb4: Fix LE hash collision bug for active open connection")
    Signed-off-by: Artem Chernyshev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
riscv, bpf: Factor out emit_call for kernel and bpf context [+ + +]
Author: Pu Lehui <[email protected]>
Date:   Wed Feb 15 21:52:03 2023 +0800

    riscv, bpf: Factor out emit_call for kernel and bpf context
    
    [ Upstream commit 0fd1fd0104954380477353aea29c347e85dff16d ]
    
    The current emit_call function is not suitable for kernel function call as
    it store return value to bpf R0 register. We can separate it out for common
    use. Meanwhile, simplify judgment logic, that is, fixed function address
    can use jal or auipc+jalr, while the unfixed can use only auipc+jalr.
    
    Signed-off-by: Pu Lehui <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Tested-by: Björn Töpel <[email protected]>
    Acked-by: Björn Töpel <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 2f1b0d3d7331 ("riscv, bpf: Sign-extend return values")
    Signed-off-by: Sasha Levin <[email protected]>

riscv, bpf: Sign-extend return values [+ + +]
Author: Björn Töpel <[email protected]>
Date:   Wed Oct 4 14:07:05 2023 +0200

    riscv, bpf: Sign-extend return values
    
    [ Upstream commit 2f1b0d3d733169eb11680bfa97c266ae5e757148 ]
    
    The RISC-V architecture does not expose sub-registers, and hold all
    32-bit values in a sign-extended format [1] [2]:
    
      | The compiler and calling convention maintain an invariant that all
      | 32-bit values are held in a sign-extended format in 64-bit
      | registers. Even 32-bit unsigned integers extend bit 31 into bits
      | 63 through 32. Consequently, conversion between unsigned and
      | signed 32-bit integers is a no-op, as is conversion from a signed
      | 32-bit integer to a signed 64-bit integer.
    
    While BPF, on the other hand, exposes sub-registers, and use
    zero-extension (similar to arm64/x86).
    
    This has led to some subtle bugs, where a BPF JITted program has not
    sign-extended the a0 register (return value in RISC-V land), passed
    the return value up the kernel, e.g.:
    
      | int from_bpf(void);
      |
      | long foo(void)
      | {
      |    return from_bpf();
      | }
    
    Here, a0 would be 0xffff_ffff, instead of the expected
    0xffff_ffff_ffff_ffff.
    
    Internally, the RISC-V JIT uses a5 as a dedicated register for BPF
    return values.
    
    Keep a5 zero-extended, but explicitly sign-extend a0 (which is used
    outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs,
    a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL).
    
    Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G")
    Signed-off-by: Björn Töpel <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2]
    Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2]
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: Do not rescan devices with a suspended queue [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Wed Oct 4 17:50:49 2023 +0900

    scsi: Do not rescan devices with a suspended queue
    
    commit 626b13f015e080e434b1dee9a0c116ddbf4fb695 upstream.
    
    Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")
    modified scsi_rescan_device() to avoid attempting rescanning a suspended
    device. However, the modification added a check to verify that a SCSI
    device is in the running state without checking if the device request
    queue (in the case of block device) is also running, thus allowing the
    exectuion of internal requests. Without checking the device request
    queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can
    still happen. Use blk_queue_pm_only() to check if the device request
    queue allows executing commands in addition to checking the SCSI device
    state.
    
    Reported-by: Petr Tesarik <[email protected]>
    Fixes: ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")
    Cc: [email protected]
    Tested-by: Petr Tesarik <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: core: Correct clear TM error log [+ + +]
Author: Peter Wang <[email protected]>
Date:   Tue Oct 3 10:20:02 2023 +0800

    scsi: ufs: core: Correct clear TM error log
    
    commit a20c4350c6a12405b7f732b3ee6801ffe2cc45ce upstream.
    
    The clear TM function error log status was inverted.
    
    Fixes: 4693fad7d6d4 ("scsi: ufs: core: Log error handler activity")
    Signed-off-by: Peter Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Stanley Chu <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tcp: enforce receive buffer memory limits by allowing the tcp window to shrink [+ + +]
Author: [email protected] <[email protected]>
Date:   Sun Jun 11 22:05:24 2023 -0500

    tcp: enforce receive buffer memory limits by allowing the tcp window to shrink
    
    [ Upstream commit b650d953cd391595e536153ce30b4aab385643ac ]
    
    Under certain circumstances, the tcp receive buffer memory limit
    set by autotuning (sk_rcvbuf) is increased due to incoming data
    packets as a result of the window not closing when it should be.
    This can result in the receive buffer growing all the way up to
    tcp_rmem[2], even for tcp sessions with a low BDP.
    
    To reproduce:  Connect a TCP session with the receiver doing
    nothing and the sender sending small packets (an infinite loop
    of socket send() with 4 bytes of payload with a sleep of 1 ms
    in between each send()).  This will cause the tcp receive buffer
    to grow all the way up to tcp_rmem[2].
    
    As a result, a host can have individual tcp sessions with receive
    buffers of size tcp_rmem[2], and the host itself can reach tcp_mem
    limits, causing the host to go into tcp memory pressure mode.
    
    The fundamental issue is the relationship between the granularity
    of the window scaling factor and the number of byte ACKed back
    to the sender.  This problem has previously been identified in
    RFC 7323, appendix F [1].
    
    The Linux kernel currently adheres to never shrinking the window.
    
    In addition to the overallocation of memory mentioned above, the
    current behavior is functionally incorrect, because once tcp_rmem[2]
    is reached when no remediations remain (i.e. tcp collapse fails to
    free up any more memory and there are no packets to prune from the
    out-of-order queue), the receiver will drop in-window packets
    resulting in retransmissions and an eventual timeout of the tcp
    session.  A receive buffer full condition should instead result
    in a zero window and an indefinite wait.
    
    In practice, this problem is largely hidden for most flows.  It
    is not applicable to mice flows.  Elephant flows can send data
    fast enough to "overrun" the sk_rcvbuf limit (in a single ACK),
    triggering a zero window.
    
    But this problem does show up for other types of flows.  Examples
    are websockets and other type of flows that send small amounts of
    data spaced apart slightly in time.  In these cases, we directly
    encounter the problem described in [1].
    
    RFC 7323, section 2.4 [2], says there are instances when a retracted
    window can be offered, and that TCP implementations MUST ensure
    that they handle a shrinking window, as specified in RFC 1122,
    section 4.2.2.16 [3].  All prior RFCs on the topic of tcp window
    management have made clear that sender must accept a shrunk window
    from the receiver, including RFC 793 [4] and RFC 1323 [5].
    
    This patch implements the functionality to shrink the tcp window
    when necessary to keep the right edge within the memory limit by
    autotuning (sk_rcvbuf).  This new functionality is enabled with
    the new sysctl: net.ipv4.tcp_shrink_window
    
    Additional information can be found at:
    https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/
    
    [1] https://www.rfc-editor.org/rfc/rfc7323#appendix-F
    [2] https://www.rfc-editor.org/rfc/rfc7323#section-2.4
    [3] https://www.rfc-editor.org/rfc/rfc1122#page-91
    [4] https://www.rfc-editor.org/rfc/rfc793
    [5] https://www.rfc-editor.org/rfc/rfc1323
    
    Signed-off-by: Mike Freemon <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session [+ + +]
Author: Rijo Thomas <[email protected]>
Date:   Fri Sep 29 12:30:24 2023 +0530

    tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
    
    commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream.
    
    There is a potential race condition in amdtee_close_session that may
    cause use-after-free in amdtee_open_session. For instance, if a session
    has refcount == 1, and one thread tries to free this session via:
    
        kref_put(&sess->refcount, destroy_session);
    
    the reference count will get decremented, and the next step would be to
    call destroy_session(). However, if in another thread,
    amdtee_open_session() is called before destroy_session() has completed
    execution, alloc_session() may return 'sess' that will be freed up
    later in destroy_session() leading to use-after-free in
    amdtee_open_session.
    
    To fix this issue, treat decrement of sess->refcount and removal of
    'sess' from session list in destroy_session() as a critical section, so
    that it is executed atomically.
    
    Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
    Cc: [email protected]
    Signed-off-by: Rijo Thomas <[email protected]>
    Reviewed-by: Sumit Garg <[email protected]>
    Signed-off-by: Jens Wiklander <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Aug 22 16:36:18 2023 +0300

    thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding
    
    commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.
    
    Marek reported that when BlackMagic UltraStudio device is connected the
    kernel repeatedly tries to enable lane bonding without success making
    the device non-functional. It looks like the device does not have lane 1
    connected at all so even though it is enabled we should not try to bond
    the lanes. For this reason check that lane 1 is in fact CL0 (connected,
    active) before attempting to bond the lanes.
    
    Reported-by: Marek Å anta <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Restart XDomain discovery handshake after failure [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Thu Sep 7 16:02:30 2023 +0300

    thunderbolt: Restart XDomain discovery handshake after failure
    
    commit 308092d080852f8997126e5b3507536162416f4a upstream.
    
    Alex reported that after rebooting the other host the peer-to-peer link
    does not come up anymore. The reason for this is that the host that was
    not rebooted tries to send the UUID request only 10 times according to
    the USB4 Inter-Domain spec and gives up if it does not get reply. Then
    when the other side is actually ready it cannot get the link established
    anymore. The USB4 Inter-Domain spec requires that the discovery protocol
    is restarted in that case so implement this now.
    
    Reported-by: Alex Balcanquall <[email protected]>
    Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Fri Aug 18 15:27:46 2023 +0300

    thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge
    
    commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream.
    
    On some systems the IOMMU blocks the first couple of driver ready
    messages to the connection manager firmware as can be seen in below
    excerpts:
    
      thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]
    
    or
    
      DMAR: DRHD: handling fault status reg 2
      DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set
    
    The reason is unknown and hard to debug because we were not able to
    reproduce this locally. This only happens on certain systems with Intel
    Maple Ridge Thunderbolt controller. If there is a device connected when
    the driver is loaded the issue does not happen either. Only when there
    is nothing connected (so typically when the system is booted up).
    
    We can work this around by sending the driver ready several times. After
    a couple of retries the message goes through and the controller works
    just fine. For this reason make the number of retries a parameter for
    icm_request() and then for Maple Ridge (and Titan Ridge as they us the
    same function but this should not matter) increase number of retries
    while shortening the timeout accordingly.
    
    Reported-by: Werner Sembach <[email protected]>
    Reported-by: Konrad J Hambrick <[email protected]>
    Reported-by: Calvin Walton <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: cdns3: Modify the return value of cdns_set_active () to void when CONFIG_PM_SLEEP is disabled [+ + +]
Author: Xiaolei Wang <[email protected]>
Date:   Tue Sep 26 15:53:33 2023 +0800

    usb: cdns3: Modify the return value of cdns_set_active () to void when CONFIG_PM_SLEEP is disabled
    
    commit 9f35d612da5592f1bf1cae44ec1e023df37bea12 upstream.
    
    The return type of cdns_set_active () is inconsistent
    depending on whether CONFIG_PM_SLEEP is enabled, so the
    return value is modified to void type.
    
    Reported-by: Pavel Machek <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: 2319b9c87fe2 ("usb: cdns3: Put the cdns set active part outside the spin lock")
    Cc: [email protected]
    Signed-off-by: Xiaolei Wang <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>
    Reviewed-by: Roger Quadros <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: cdnsp: Fixes issue with dequeuing not queued requests [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Thu Jul 13 04:14:29 2023 -0400

    usb: cdnsp: Fixes issue with dequeuing not queued requests
    
    commit 34f08eb0ba6e4869bbfb682bf3d7d0494ffd2f87 upstream.
    
    Gadget ACM while unloading module try to dequeue not queued usb
    request which causes the kernel to crash.
    Patch adds extra condition to check whether usb request is processed
    by CDNSP driver.
    
    cc: [email protected]
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc3: Soft reset phy on probe for host [+ + +]
Author: Thinh Nguyen <[email protected]>
Date:   Wed Sep 13 00:52:15 2023 +0000

    usb: dwc3: Soft reset phy on probe for host
    
    commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream.
    
    When there's phy initialization, we need to initiate a soft-reset
    sequence. That's done through USBCMD.HCRST in the xHCI driver and its
    initialization, However, the dwc3 driver may modify core configs before
    the soft-reset. This may result in some connection instability. So,
    ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR
    or other settings by issuing phy soft-reset.
    
    Note that some host-mode configurations may not expose device registers
    to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset
    through GUSB3PIPECTL and GUSB2PHYCFG instead.
    
    Cc: [email protected]
    Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
    Reported-by: Kenta Sato <[email protected]>
    Closes: https://lore.kernel.org/linux-usb/[email protected]/
    Signed-off-by: Thinh Nguyen <[email protected]>
    Tested-by: Kenta Sato <[email protected]>
    Link: https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call [+ + +]
Author: Krishna Kurapati <[email protected]>
Date:   Wed Sep 27 16:28:58 2023 +0530

    usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call
    
    commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream.
    
    When NCM is used with hosts like Windows PC, it is observed that there are
    multiple NTB's contained in one usb request giveback. Since the driver
    unwraps the obtained request data assuming only one NTB is present, we
    loose the subsequent NTB's present resulting in data loss.
    
    Fix this by checking the parsed block length with the obtained data
    length in usb request and continue parsing after the last byte of current
    NTB.
    
    Cc: [email protected]
    Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
    Signed-off-by: Krishna Kurapati <[email protected]>
    Reviewed-by: Maciej Å»enczykowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: udc-xilinx: replace memcpy with memcpy_toio [+ + +]
Author: Piyush Mehta <[email protected]>
Date:   Fri Sep 29 17:45:14 2023 +0530

    usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
    
    commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream.
    
    For ARM processor, unaligned access to device memory is not allowed.
    Method memcpy does not take care of alignment.
    
    USB detection failure with the unalingned address of memory, with
    below kernel crash. To fix the unalingned address kernel panic,
    replace memcpy with memcpy_toio method.
    
    Kernel crash:
    Unable to handle kernel paging request at virtual address ffff80000c05008a
    Mem abort info:
      ESR = 0x96000061
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x21: alignment fault
    Data abort info:
      ISV = 0, ISS = 0x00000061
      CM = 0, WnR = 1
    swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000
    [ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003,
    pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713
    Internal error: Oops: 96000061 [#1] SMP
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
    Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
    pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __memcpy+0x30/0x260
    lr : __xudc_ep0_queue+0xf0/0x110
    sp : ffff800008003d00
    x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
    x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
    x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
    x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
    x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
    x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
    x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0
    x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112
    x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80
    x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088
    Call trace:
     __memcpy+0x30/0x260
     xudc_ep0_queue+0x3c/0x60
     usb_ep_queue+0x38/0x44
     composite_ep0_queue.constprop.0+0x2c/0xc0
     composite_setup+0x8d0/0x185c
     configfs_composite_setup+0x74/0xb0
     xudc_irq+0x570/0xa40
     __handle_irq_event_percpu+0x58/0x170
     handle_irq_event+0x60/0x120
     handle_fasteoi_irq+0xc0/0x220
     handle_domain_irq+0x60/0x90
     gic_handle_irq+0x74/0xa0
     call_on_irq_stack+0x2c/0x60
     do_interrupt_handler+0x54/0x60
     el1_interrupt+0x30/0x50
     el1h_64_irq_handler+0x18/0x24
     el1h_64_irq+0x78/0x7c
     arch_cpu_idle+0x18/0x2c
     do_idle+0xdc/0x15c
     cpu_startup_entry+0x28/0x60
     rest_init+0xc8/0xe0
     arch_call_rest_init+0x10/0x1c
     start_kernel+0x694/0x6d4
     __primary_switched+0xa4/0xac
    
    Fixes: 1f7c51660034 ("usb: gadget: Add xilinx usb2 device support")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Cc: [email protected]
    Signed-off-by: Piyush Mehta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: hub: Guard against accesses to uninitialized BOS descriptors [+ + +]
Author: Ricardo Cañuelo <[email protected]>
Date:   Wed Aug 30 12:04:18 2023 +0200

    usb: hub: Guard against accesses to uninitialized BOS descriptors
    
    commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream.
    
    Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
    access fields inside udev->bos without checking if it was allocated and
    initialized. If usb_get_bos_descriptor() fails for whatever
    reason, udev->bos will be NULL and those accesses will result in a
    crash:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000018
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
    Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:hub_port_reset+0x193/0x788
    Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
    RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
    RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
    RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
    R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
    R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
    Call Trace:
    hub_event+0x73f/0x156e
    ? hub_activate+0x5b7/0x68f
    process_one_work+0x1a2/0x487
    worker_thread+0x11a/0x288
    kthread+0x13a/0x152
    ? process_one_work+0x487/0x487
    ? kthread_associate_blkcg+0x70/0x70
    ret_from_fork+0x1f/0x30
    
    Fall back to a default behavior if the BOS descriptor isn't accessible
    and skip all the functionalities that depend on it: LPM support checks,
    Super Speed capabilitiy checks, U1/U2 states setup.
    
    Signed-off-by: Ricardo Cañuelo <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: musb: Get the musb_qh poniter after musb_giveback [+ + +]
Author: Xingxing Luo <[email protected]>
Date:   Tue Sep 19 11:30:55 2023 +0800

    usb: musb: Get the musb_qh poniter after musb_giveback
    
    commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream.
    
    When multiple threads are performing USB transmission, musb->lock will be
    unlocked when musb_giveback is executed. At this time, qh may be released
    in the dequeue process in other threads, resulting in a wild pointer, so
    it needs to be here get qh again, and judge whether qh is NULL, and when
    dequeue, you need to set qh to NULL.
    
    Fixes: dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
    Cc: [email protected]
    Signed-off-by: Xingxing Luo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: musb: Modify the "HWVers" register address [+ + +]
Author: Xingxing Luo <[email protected]>
Date:   Fri Sep 22 15:59:29 2023 +0800

    usb: musb: Modify the "HWVers" register address
    
    commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream.
    
    musb HWVers rgister address is not 0x69, if we operate the
    wrong address 0x69, it will cause a kernel crash, because
    there is no register corresponding to this address in the
    additional control register of musb. In fact, HWVers has
    been defined in musb_register.h, and the name is
    "MUSB_HWVERS", so We need to use this macro instead of 0x69.
    
    Fixes: c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines")
    Cc: [email protected]
    Signed-off-by: Xingxing Luo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: altmodes/displayport: Signal hpd low when exiting mode [+ + +]
Author: RD Babiera <[email protected]>
Date:   Mon Oct 9 21:00:58 2023 +0000

    usb: typec: altmodes/displayport: Signal hpd low when exiting mode
    
    commit 89434b069e460967624903b049e5cf5c9e6b99b9 upstream.
    
    Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort
    driver currently resets the status and configuration of the port partner.
    The hpd signal is not updated despite being part of the status, so the
    Display stack can still transmit video despite typec_altmode_exit placing
    the lanes in a Safe State.
    
    Set hpd to low when a sent EXIT_MODE message is ACK'ed.
    
    Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
    Cc: [email protected]
    Signed-off-by: RD Babiera <[email protected]>
    Acked-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails [+ + +]
Author: Prashanth K <[email protected]>
Date:   Mon Sep 11 14:34:15 2023 +0530

    usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails
    
    commit a00e197daec52bcd955e118f5f57d706da5bfe50 upstream.
    
    Currently if ucsi_send_command() fails, then we bail out without
    clearing EVENT_PENDING flag. So when the next connector change
    event comes, ucsi_connector_change() won't queue the con->work,
    because of which none of the new events will be processed.
    
    Fix this by clearing EVENT_PENDING flag if ucsi_send_command()
    fails.
    
    Cc: [email protected] # 5.16
    Fixes: 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue")
    Signed-off-by: Prashanth K <[email protected]>
    Acked-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Mon Oct 9 13:46:43 2023 -0500

    usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope
    
    commit c9ca8de2eb15f9da24113e652980c61f95a47530 upstream.
    
    On some OEM systems, adding a W7900 dGPU triggers RAS errors and hangs
    at a black screen on startup.  This issue occurs only if `ucsi_acpi` has
    loaded before `amdgpu` has loaded.  The reason for this failure is that
    `amdgpu` uses power_supply_is_system_supplied() to determine if running
    on AC or DC power at startup. If this value is reported incorrectly the
    dGPU will also be programmed incorrectly and trigger errors.
    
    power_supply_is_system_supplied() reports the wrong value because UCSI
    power supplies provided as part of the system don't properly report the
    scope as "DEVICE" scope (not powering the system).
    
    In order to fix this issue check the capabilities reported from the UCSI
    power supply to ensure that it supports charging a battery and that it can
    be powered by AC.  Mark the scope accordingly.
    
    Cc: [email protected]
    Fixes: a7fbfd44c020 ("usb: typec: ucsi: Mark dGPUs as DEVICE scope")
    Link: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb-type-c-ucsi-spec.html p28
    Reviewed-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Acked-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer [+ + +]
Author: Wesley Cheng <[email protected]>
Date:   Fri Sep 15 17:31:05 2023 +0300

    usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer
    
    commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream.
    
    As mentioned in:
      commit 474ed23a6257 ("xhci: align the last trb before link if it is
    easily splittable.")
    
    A bounce buffer is utilized for ensuring that transfers that span across
    ring segments are aligned to the EP's max packet size.  However, the device
    that is used to map the DMA buffer to is currently using the XHCI HCD,
    which does not carry any DMA operations in certain configrations.
    Migration to using the sysdev entry was introduced for DWC3 based
    implementations where the IOMMU operations are present.
    
    Replace the reference to the controller device to sysdev instead.  This
    allows the bounce buffer to be properly mapped to any implementations that
    have an IOMMU involved.
    
    cc: [email protected]
    Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
    Signed-off-by: Wesley Cheng <[email protected]>
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
workqueue: Override implicit ordered attribute in workqueue_apply_unbound_cpumask() [+ + +]
Author: Waiman Long <[email protected]>
Date:   Tue Oct 10 22:48:42 2023 -0400

    workqueue: Override implicit ordered attribute in workqueue_apply_unbound_cpumask()
    
    [ Upstream commit ca10d851b9ad0338c19e8e3089e24d565ebfffd7 ]
    
    Commit 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1
    to be ordered") enabled implicit ordered attribute to be added to
    WQ_UNBOUND workqueues with max_active of 1. This prevented the changing
    of attributes to these workqueues leading to fix commit 0a94efb5acbb
    ("workqueue: implicit ordered attribute should be overridable").
    
    However, workqueue_apply_unbound_cpumask() was not updated at that time.
    So sysfs changes to wq_unbound_cpumask has no effect on WQ_UNBOUND
    workqueues with implicit ordered attribute. Since not all WQ_UNBOUND
    workqueues are visible on sysfs, we are not able to make all the
    necessary cpumask changes even if we iterates all the workqueue cpumasks
    in sysfs and changing them one by one.
    
    Fix this problem by applying the corresponding change made
    to apply_workqueue_attrs_locked() in the fix commit to
    workqueue_apply_unbound_cpumask().
    
    Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
    Signed-off-by: Waiman Long <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/alternatives: Disable KASAN in apply_alternatives() [+ + +]
Author: Kirill A. Shutemov <[email protected]>
Date:   Thu Oct 12 13:04:24 2023 +0300

    x86/alternatives: Disable KASAN in apply_alternatives()
    
    commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream.
    
    Fei has reported that KASAN triggers during apply_alternatives() on
    a 5-level paging machine:
    
            BUG: KASAN: out-of-bounds in rcu_is_watching()
            Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
            ...
            __asan_load4()
            rcu_is_watching()
            trace_hardirqs_on()
            text_poke_early()
            apply_alternatives()
            ...
    
    On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
    gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
    __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
    
    KASAN gets confused when apply_alternatives() patches the
    KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
    static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
    
    Fix it for real by disabling KASAN while the kernel is patching alternatives.
    
    [ mingo: updated the changelog ]
    
    Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")
    Reported-by: Fei Yang <[email protected]>
    Signed-off-by: Kirill A. Shutemov <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kirill A. Shutemov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Sat Oct 7 12:57:02 2023 +0200

    x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs
    
    commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.
    
    Fix erratum #1485 on Zen4 parts where running with STIBP disabled can
    cause an #UD exception. The performance impact of the fix is negligible.
    
    Reported-by: René Rebe <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Tested-by: René Rebe <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xen-netback: use default TX queue size for vifs [+ + +]
Author: Roger Pau Monne <[email protected]>
Date:   Thu Oct 5 16:08:31 2023 +0200

    xen-netback: use default TX queue size for vifs
    
    [ Upstream commit 66cf7435a26917c0c4d6245ad9137e7606e84fdf ]
    
    Do not set netback interfaces (vifs) default TX queue size to the ring size.
    The TX queue size is not related to the ring size, and using the ring size (32)
    as the queue size can lead to packet drops.  Note the TX side of the vif
    interface in the netback domain is the one receiving packets to be injected
    to the guest.
    
    Do not explicitly set the TX queue length to any value when creating the
    interface, and instead use the system default.  Note that the queue length can
    also be adjusted at runtime.
    
    Fixes: f942dc2552b8 ('xen network backend driver')
    Signed-off-by: Roger Pau Monné <[email protected]>
    Reviewed-by: Ross Lagerwall <[email protected]>
    Acked-by: Wei Liu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>