Skip to content
  1. Feb 05, 2022
    • Maxime Ripard's avatar
      drm/vc4: hdmi: Make sure the device is powered with CEC · d5e81e3a
      Maxime Ripard authored
      Commit 20b0dfa8 upstream.
      
      The original commit depended on a rework commit (724fc856
      
       ("drm/vc4:
      hdmi: Split the CEC disable / enable functions in two")) that
      (rightfully) didn't reach stable.
      
      However, probably because the context changed, when the patch was
      applied to stable the pm_runtime_put called got moved to the end of the
      vc4_hdmi_cec_adap_enable function (that would have become
      vc4_hdmi_cec_disable with the rework) to vc4_hdmi_cec_init.
      
      This means that at probe time, we now drop our reference to the clocks
      and power domains and thus end up with a CPU hang when the CPU tries to
      access registers.
      
      The call to pm_runtime_resume_and_get() is also problematic since the
      .adap_enable CEC hook is called both to enable and to disable the
      controller. That means that we'll now call pm_runtime_resume_and_get()
      at disable time as well, messing with the reference counting.
      
      The behaviour we should have though would be to have
      pm_runtime_resume_and_get() called when the CEC controller is enabled,
      and pm_runtime_put when it's disabled.
      
      We need to move things around a bit to behave that way, but it aligns
      stable with upstream.
      
      Cc: <stable@vger.kernel.org> # 5.10.x
      Cc: <stable@vger.kernel.org> # 5.15.x
      Cc: <stable@vger.kernel.org> # 5.16.x
      Reported-by: default avatarMichael Stapelberg <michael+drm@stapelberg.ch>
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5e81e3a
    • Alex Elder's avatar
      net: ipa: prevent concurrent replenish · dffeeca9
      Alex Elder authored
      commit 998c0bd2 upstream.
      
      We have seen cases where an endpoint RX completion interrupt arrives
      while replenishing for the endpoint is underway.  This causes another
      instance of replenishing to begin as part of completing the receive
      transaction.  If this occurs it can lead to transaction corruption.
      
      Use a new flag to ensure only one replenish instance for an endpoint
      executes at a time.
      
      Fixes: 84f9bd12
      
       ("soc: qcom: ipa: IPA endpoints")
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dffeeca9
    • Alex Elder's avatar
      net: ipa: use a bitmap for endpoint replenish_enabled · 5f4ed982
      Alex Elder authored
      commit c1aaa01d
      
       upstream.
      
      Define a new replenish_flags bitmap to contain Boolean flags
      associated with an endpoint's replenishing state.  Replace the
      replenish_enabled field with a flag in that bitmap.  This is to
      prepare for the next patch, which adds another flag.
      
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f4ed982
    • Paolo Abeni's avatar
      selftests: mptcp: fix ipv6 routing setup · ee782b80
      Paolo Abeni authored
      commit 9846921d upstream.
      
      MPJ ipv6 selftests currently lack per link route to the server
      net. Additionally, ipv6 subflows endpoints are created without any
      interface specified. The end-result is that in ipv6 self-tests
      subflows are created all on the same link, leading to expected delays
      and sporadic self-tests failures.
      
      Fix the issue by adding the missing setup bits.
      
      Fixes: 523514ed
      
       ("selftests: mptcp: add ADD_ADDR IPv6 test cases")
      Reported-and-tested-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee782b80
    • Lukas Wunner's avatar
      PCI: pciehp: Fix infinite loop in IRQ handler upon power fault · 1db58c65
      Lukas Wunner authored
      commit 23584c1e upstream.
      
      The Power Fault Detected bit in the Slot Status register differs from
      all other hotplug events in that it is sticky:  It can only be cleared
      after turning off slot power.  Per PCIe r5.0, sec. 6.7.1.8:
      
        If a power controller detects a main power fault on the hot-plug slot,
        it must automatically set its internal main power fault latch [...].
        The main power fault latch is cleared when software turns off power to
        the hot-plug slot.
      
      The stickiness used to cause interrupt storms and infinite loops which
      were fixed in 2009 by commits 5651c48c ("PCI pciehp: fix power fault
      interrupt storm problem") and 99f0169c ("PCI: pciehp: enable
      software notification on empty slots").
      
      Unfortunately in 2020 the infinite loop issue was inadvertently
      reintroduced by commit 8edf5332 ("PCI: pciehp: Fix MSI interrupt
      race"):  The hardirq handler pciehp_isr() clears the PFD bit until
      pciehp's power_fault_detected flag is set.  That happens in the IRQ
      thread pciehp_ist(), which never learns of the event because the hardirq
      handler is stuck in an infinite loop.  Fix by setting the
      power_fault_detected flag already in the hardirq handler.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=214989
      Link: https://lore.kernel.org/linux-pci/DM8PR11MB5702255A6A92F735D90A4446868B9@DM8PR11MB5702.namprd11.prod.outlook.com
      Fixes: 8edf5332
      
       ("PCI: pciehp: Fix MSI interrupt race")
      Link: https://lore.kernel.org/r/66eaeef31d4997ceea357ad93259f290ededecfd.1637187226.git.lukas@wunner.de
      Reported-by: default avatarJoseph Bao <joseph.bao@intel.com>
      Tested-by: default avatarJoseph Bao <joseph.bao@intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v4.19+
      Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1db58c65
  2. Feb 02, 2022