1. 22 Jun, 2022 14 commits
  2. 16 Jun, 2022 12 commits
  3. 14 Jun, 2022 14 commits
    • Greg Kroah-Hartman's avatar
    • Eric Dumazet's avatar
      tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd · 9ba2b4ac
      Eric Dumazet authored
      commit 11825765 upstream.
      
      syzbot got a new report [1] finally pointing to a very old bug,
      added in initial support for MTU probing.
      
      tcp_mtu_probe() has checks about starting an MTU probe if
      tcp_snd_cwnd(tp) >= 11.
      
      But nothing prevents tcp_snd_cwnd(tp) to be reduced later
      and before the MTU probe succeeds.
      
      This bug would lead to potential zero-divides.
      
      Debugging added in commit 40570375 ("tcp: add accessors
      to read/set tp->snd_cwnd") has paid off :)
      
      While we are at it, address potential overflows in this code.
      
      [1]
      WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
      Modules linked in:
      CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb9 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
      RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
      Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
      RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
      RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
      RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
      RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
      R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
      R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
      FS:  00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356
       tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861
       tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973
       tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476
       sk_backlog_rcv include/net/sock.h:1061 [inline]
       __release_sock+0x1d8/0x4c0 net/core/sock.c:2849
       release_sock+0x5d/0x1c0 net/core/sock.c:3404
       sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145
       tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410
       tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448
       sock_sendmsg_nosec net/socket.c:714 [inline]
       sock_sendmsg net/socket.c:734 [inline]
       __sys_sendto+0x439/0x5c0 net/socket.c:2119
       __do_sys_sendto net/socket.c:2131 [inline]
       __se_sys_sendto net/socket.c:2127 [inline]
       __x64_sys_sendto+0xda/0xf0 net/socket.c:2127
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      RIP: 0033:0x7f6431289109
      Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109
      RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a
      RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
      
      Fixes: 5d424d5a
      
       ("[TCP]: MTU probing")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ba2b4ac
    • Dave Jiang's avatar
      dmaengine: idxd: add missing callback function to support DMA_INTERRUPT · 5e34b497
      Dave Jiang authored
      commit 2112b8f4 upstream.
      
      When setting DMA_INTERRUPT capability, a callback function
      dma->device_prep_dma_interrupt() is needed to support this capability.
      Without setting the callback, dma_async_device_register() will fail dma
      capability check.
      
      Fixes: 4e5a4eb2
      
       ("dmaengine: idxd: set DMA_INTERRUPT cap bit")
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Link: https://lore.kernel.org/r/165101232637.3951447.15765792791591763119.stgit@djiang5-desk3.ch.intel.com
      
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e34b497
    • Damien Le Moal's avatar
      zonefs: fix handling of explicit_open option on mount · b8c17121
      Damien Le Moal authored
      commit a2a513be upstream.
      
      Ignoring the explicit_open mount option on mount for devices that do not
      have a limit on the number of open zones must be done after the mount
      options are parsed and set in s_mount_opts. Move the check to ignore
      the explicit_open option after the call to zonefs_parse_options() in
      zonefs_fill_super().
      
      Fixes: b5c00e97
      
       ("zonefs: open/close zone on file open/close")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8c17121
    • Johan Hovold's avatar
      PCI: qcom: Fix pipe clock imbalance · ef519977
      Johan Hovold authored
      commit fdf6a2f5 upstream.
      
      Fix a clock imbalance introduced by ed8cc3b1 ("PCI: qcom: Add support
      for SDM845 PCIe controller"), which enables the pipe clock both in init()
      and in post_init() but only disables in post_deinit().
      
      Note that the pipe clock was also never disabled in the init() error
      paths and that enabling the clock before powering up the PHY looks
      questionable.
      
      Link: https://lore.kernel.org/r/20220401133351.10113-1-johan+linaro@kernel.org
      Fixes: ed8cc3b1
      
       ("PCI: qcom: Add support for SDM845 PCIe controller")
      Signed-off-by: default avatarJohan Hovold <johan+linaro@kernel.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Cc: stable@vger.kernel.org      # 5.6
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef519977
    • Pascal Hambourg's avatar
      md/raid0: Ignore RAID0 layout if the second zone has only one device · 63bcb9da
      Pascal Hambourg authored
      commit ea23994e
      
       upstream.
      
      The RAID0 layout is irrelevant if all members have the same size so the
      array has only one zone. It is *also* irrelevant if the array has two
      zones and the second zone has only one device, for example if the array
      has two members of different sizes.
      
      So in that case it makes sense to allow assembly even when the layout is
      undefined, like what is done when the array has only one zone.
      Reviewed-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarPascal Hambourg <pascal@plouf.fr.eu.org>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63bcb9da
    • Stephen Boyd's avatar
      interconnect: Restore sync state by ignoring ipa-virt in provider count · 418db40c
      Stephen Boyd authored
      commit 20ce30fb upstream.
      
      Ignore compatible strings for the IPA virt drivers that were removed in
      commits 2fb251c2 ("interconnect: qcom: sdx55: Drop IP0
      interconnects") and 2f372493 ("interconnect: qcom: sc7180: Drop IP0
      interconnects") so that the sync state logic can kick in again.
      Otherwise all the interconnects in the system will stay pegged at max
      speeds because 'providers_count' is always going to be one larger than
      the number of drivers that will ever probe on sc7180 or sdx55. This
      fixes suspend on sc7180 and sdx55 devices when you don't have a
      devicetree patch to remove the ipa-virt compatible node.
      
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Doug Anderson <dianders@chromium.org>
      Cc: Alex Elder <elder@linaro.org>
      Cc: Taniya Das <quic_tdas@quicinc.com>
      Cc: Mike Tipton <quic_mdtipton@quicinc.com>
      Cc: <stable@vger.kernel.org>	# 5.10.x
      Fixes: 2fb251c2 ("interconnect: qcom: sdx55: Drop IP0 interconnects")
      Fixes: 2f372493
      
       ("interconnect: qcom: sc7180: Drop IP0 interconnects")
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20220427013226.341209-1-swboyd@chromium.org
      
      Signed-off-by: default avatarGeorgi Djakov <djakov@kernel.org>
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      418db40c
    • Stephen Boyd's avatar
      interconnect: qcom: sc7180: Drop IP0 interconnects · bcae8f83
      Stephen Boyd authored
      commit 2f372493 upstream.
      
      The IPA BCM resource ("IP0") on sc7180 was moved to the clk-rpmh driver
      in commit bcd63d22 ("clk: qcom: rpmh: Add IPA clock for SC7180") and
      modeled as a clk, but this interconnect driver still had it modeled as
      an interconnect. This was mostly OK because nobody used the interconnect
      definition, until the interconnect framework started dropping bandwidth
      requests on interconnects that aren't used via the sync_state callback
      in commit 7d3b0b0d ("interconnect: qcom: Use icc_sync_state"). Once
      that patch was applied the IP0 resource was going to be controlled from
      two places, the clk framework and the interconnect framework.
      
      Even then, things were probably going to be OK, because commit
      b95b668e ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in
      pre_aggregate") was needed to actually drop bandwidth requests on unused
      interconnects, of which the IPA was one of the interconnect that wasn't
      getting dropped to zero. Combining the three commits together leads to
      bad behavior where the interconnect framework is disabling the IP0
      resource because it has no users while the clk framework thinks the IP0
      resource is on because the only user, the IPA driver, has turned it on
      via clk_prepare_enable(). Depending on when sync_state is called, we can
      get into a situation like below:
      
        IPA driver probes
        IPA driver gets notified modem started
         runtime PM get()
          IPA clk enabled -> IP0 resource is ON
        sync_state runs
         interconnect zeroes out the IP0 resource -> IP0 resource is off
        IPA driver tries to access a register and blows up
      
      The crash is an unclocked access that manifest as an SError.
      
       SError Interrupt on CPU0, code 0xbe000011 -- SError
       CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166
       Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
       pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
       pc : mutex_lock+0x4c/0x80
       lr : mutex_lock+0x30/0x80
       sp : ffffffc00da9b9c0
       x29: ffffffc00da9b9c0 x28: 0000000000000000 x27: 0000000000000000
       x26: ffffffc00da9bc90 x25: ffffff80c2024010 x24: ffffff80c2024000
       x23: ffffff8083100000 x22: ffffff80831000d0 x21: ffffff80831000a8
       x20: ffffff80831000a8 x19: ffffff8083100070 x18: 00000000ffff0a00
       x17: 000000002f7254f1 x16: 0000000000000100 x15: 0000000000000000
       x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
       x11: 000000000001f0b8 x10: ffffffc00931f0b8 x9 : 0000000000000000
       x8 : 0000000000000000 x7 : fefefefefeff2f60 x6 : 0000808080808080
       x5 : 0000000000000000 x4 : 8080808080800000 x3 : ffffff80d2d4ee28
       x2 : ffffff808c1d6e40 x1 : 0000000000000000 x0 : ffffff8083100070
       Kernel panic - not syncing: Asynchronous SError Interrupt
       CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166
       Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
       Call trace:
        dump_backtrace+0xf4/0x114
        show_stack+0x24/0x30
        dump_stack_lvl+0x64/0x7c
        dump_stack+0x18/0x38
        panic+0x150/0x38c
        nmi_panic+0x88/0xa0
        arm64_serror_panic+0x74/0x80
        do_serror+0x0/0x80
        do_serror+0x58/0x80
        el1h_64_error_handler+0x34/0x4c
        el1h_64_error+0x78/0x7c
        mutex_lock+0x4c/0x80
        __gsi_channel_start+0x50/0x17c
        gsi_channel_start+0x54/0x90
        ipa_endpoint_enable_one+0x34/0xc0
        ipa_open+0x4c/0x120
      
      Remove all IP0 resource management from the interconnect driver so that
      clk-rpmh is the sole owner. This fixes the issue by preventing the
      interconnect driver from overwriting the IP0 resource data that the
      clk-rpmh driver wrote.
      
      Cc: Alex Elder <elder@linaro.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Taniya Das <quic_tdas@quicinc.com>
      Cc: Mike Tipton <quic_mdtipton@quicinc.com>
      Cc: <stable@vger.kernel.org>	# 5.10.x
      Fixes: b95b668e ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate")
      Fixes: bcd63d22 ("clk: qcom: rpmh: Add IPA clock for SC7180")
      Fixes: 7d3b0b0d
      
       ("interconnect: qcom: Use icc_sync_state")
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Tested-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Link: https://lore.kernel.org/r/20220412220033.1273607-2-swboyd@chromium.org
      
      Signed-off-by: default avatarGeorgi Djakov <djakov@kernel.org>
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcae8f83
    • Alexey Kardashevskiy's avatar
      powerpc/mm: Switch obsolete dssall to .long · fe6caf51
      Alexey Kardashevskiy authored
      commit d51f86cf
      
       upstream.
      
      The dssall ("Data Stream Stop All") instruction is obsolete altogether
      with other Data Cache Instructions since ISA 2.03 (year 2006).
      
      LLVM IAS does not support it but PPC970 seems to be using it.
      This switches dssall to .long as there is no much point in fixing LLVM.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20211221055904.555763-6-aik@ozlabs.ru
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe6caf51
    • Michael Ellerman's avatar
      powerpc/32: Fix overread/overwrite of thread_struct via ptrace · 3be74fc0
      Michael Ellerman authored
      commit 8e127844 upstream.
      
      The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
      to read/write registers of another process.
      
      To get/set a register, the API takes an index into an imaginary address
      space called the "USER area", where the registers of the process are
      laid out in some fashion.
      
      The kernel then maps that index to a particular register in its own data
      structures and gets/sets the value.
      
      The API only allows a single machine-word to be read/written at a time.
      So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels.
      
      The way floating point registers (FPRs) are addressed is somewhat
      complicated, because double precision float values are 64-bit even on
      32-bit CPUs. That means on 32-bit kernels each FPR occupies two
      word-sized locations in the USER area. On 64-bit kernels each FPR
      occupies one word-sized location in the USER area.
      
      Internally the kernel stores the FPRs in an array of u64s, or if VSX is
      enabled, an array of pairs of u64s where one half of each pair stores
      the FPR. Which half of the pair stores the FPR depends on the kernel's
      endianness.
      
      To handle the different layouts of the FPRs depending on VSX/no-VSX and
      big/little endian, the TS_FPR() macro was introduced.
      
      Unfortunately the TS_FPR() macro does not take into account the fact
      that the addressing of each FPR differs between 32-bit and 64-bit
      kernels. It just takes the index into the "USER area" passed from
      userspace and indexes into the fp_state.fpr array.
      
      On 32-bit there are 64 indexes that address FPRs, but only 32 entries in
      the fp_state.fpr array, meaning the user can read/write 256 bytes past
      the end of the array. Because the fp_state sits in the middle of the
      thread_struct there are various fields than can be overwritten,
      including some pointers. As such it may be exploitable.
      
      It has also been observed to cause systems to hang or otherwise
      misbehave when using gdbserver, and is probably the root cause of this
      report which could not be easily reproduced:
        https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@keymile.com/
      
      Rather than trying to make the TS_FPR() macro even more complicated to
      fix the bug, or add more macros, instead add a special-case for 32-bit
      kernels. This is more obvious and hopefully avoids a similar bug
      happening again in future.
      
      Note that because 32-bit kernels never have VSX enabled the code doesn't
      need to consider TS_FPRWIDTH/OFFSET at all. Add a BUILD_BUG_ON() to
      ensure that 32-bit && VSX is never enabled.
      
      Fixes: 87fec051
      
       ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds")
      Cc: stable@vger.kernel.org # v3.13+
      Reported-by: default avatarAriel Miculas <ariel.miculas@belden.com>
      Tested-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3be74fc0
    • Brian Norris's avatar
      drm/atomic: Force bridge self-refresh-exit on CRTC switch · fa0d3d71
      Brian Norris authored
      commit e54a4424 upstream.
      
      It's possible to change which CRTC is in use for a given
      connector/encoder/bridge while we're in self-refresh without fully
      disabling the connector/encoder/bridge along the way. This can confuse
      the bridge encoder/bridge, because
      (a) it needs to track the SR state (trying to perform "active"
          operations while the panel is still in SR can be Bad(TM)); and
      (b) it tracks the SR state via the CRTC state (and after the switch, the
          previous SR state is lost).
      
      Thus, we need to either somehow carry the self-refresh state over to the
      new CRTC, or else force an encoder/bridge self-refresh transition during
      such a switch.
      
      I choose the latter, so we disable the encoder (and exit PSR) before
      attaching it to the new CRTC (where we can continue to assume a clean
      (non-self-refresh) state).
      
      This fixes PSR issues seen on Rockchip RK3399 systems with
      drivers/gpu/drm/bridge/analogix/analogix_dp_core.c.
      
      Change in v2:
      
      - Drop "->enable" condition; this could possibly be "->active" to
        reflect the intended hardware state, but it also is a little
        over-specific. We want to make a transition through "disabled" any
        time we're exiting PSR at the same time as a CRTC switch.
        (Thanks Liu Ying)
      
      Cc: Liu Ying <victor.liu@oss.nxp.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 1452c25b
      
       ("drm: Add helpers to kick off self refresh mode in drivers")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa0d3d71
    • Brian Norris's avatar
      drm/bridge: analogix_dp: Support PSR-exit to disable transition · dbe04e87
      Brian Norris authored
      commit ca871659 upstream.
      
      Most eDP panel functions only work correctly when the panel is not in
      self-refresh. In particular, analogix_dp_bridge_disable() tends to hit
      AUX channel errors if the panel is in self-refresh.
      
      Given the above, it appears that so far, this driver assumes that we are
      never in self-refresh when it comes time to fully disable the bridge.
      Prior to commit 846c7dfc ("drm/atomic: Try to preserve the crtc
      enabled state in drm_atomic_remove_fb, v2."), this tended to be true,
      because we would automatically disable the pipe when framebuffers were
      removed, and so we'd typically disable the bridge shortly after the last
      display activity.
      
      However, that is not guaranteed: an idle (self-refresh) display pipe may
      be disabled, e.g., when switching CRTCs. We need to exit PSR first.
      
      Stable notes: this is definitely a bugfix, and the bug has likely
      existed in some form for quite a while. It may predate the "PSR helpers"
      refactor, but the code looked very different before that, and it's
      probably not worth rewriting the fix.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 6c836d96
      
       ("drm/rockchip: Use the helpers for PSR")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.1.I161904be17ba14526f78536ccd78b85818449b51@changeid
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbe04e87
    • Mathias Nyman's avatar
      Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag · 61297ee0
      Mathias Nyman authored
      commit c42e6566
      
       upstream.
      
      The bcm5974 driver does the allocation and dma mapping of the usb urb
      data buffer, but driver does not set the URB_NO_TRANSFER_DMA_MAP flag
      to let usb core know the buffer is already mapped.
      
      usb core tries to map the already mapped buffer, causing a warning:
      "xhci_hcd 0000:00:14.0: rejecting DMA map of vmalloc memory"
      
      Fix this by setting the URB_NO_TRANSFER_DMA_MAP, letting usb core
      know buffer is already mapped by bcm5974 driver
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: stable@vger.kernel.org
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=215890
      Link: https://lore.kernel.org/r/20220606113636.588955-1-mathias.nyman@linux.intel.com
      
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61297ee0
    • Olivier Matz's avatar
      ixgbe: fix unexpected VLAN Rx in promisc mode on VF · 2dba96d1
      Olivier Matz authored
      commit 7bb0fb7c upstream.
      
      When the promiscuous mode is enabled on a VF, the IXGBE_VMOLR_VPE
      bit (VLAN Promiscuous Enable) is set. This means that the VF will
      receive packets whose VLAN is not the same than the VLAN of the VF.
      
      For instance, in this situation:
      
      ┌────────┐    ┌────────┐    ┌────────┐
      │        │    │        │    │        │
      │        │    │        │    │        │
      │     VF0├────┤VF1  VF2├────┤VF3     │
      │        │    │        │    │        │
      └────────┘    └────────┘    └────────┘
         VM1           VM2           VM3
      
      vf 0:  vlan 1000
      vf 1:  vlan 1000
      vf 2:  vlan 1001
      vf 3:  vlan 1001
      
      If we tcpdump on VF3, we see all the packets, even those transmitted
      on vlan 1000.
      
      This behavior prevents to bridge VF1 and VF2 in VM2, because it will
      create a loop: packets transmitted on VF1 will be received by VF2 and
      vice-versa, and bridged again through the software bridge.
      
      This patch remove the activation of VLAN Promiscuous when a VF enables
      the promiscuous mode. However, the IXGBE_VMOLR_UPE bit (Unicast
      Promiscuous) is kept, so that a VF receives all packets that has the
      same VLAN, whatever the destination MAC address.
      
      Fixes: 8443c1a4
      
       ("ixgbe, ixgbevf: Add new mbox API xcast mode")
      Cc: stable@vger.kernel.org
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarOlivier Matz <olivier.matz@6wind.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2dba96d1