1. 13 Sep, 2019 2 commits
    • Ulf Hansson's avatar
      mmc: tmio: Fixup runtime PM management during probe · aa86f1a3
      Ulf Hansson authored
      The tmio_mmc_host_probe() calls pm_runtime_set_active() to update the
      runtime PM status of the device, as to make it reflect the current status
      of the HW. This works fine for most cases, but unfortunate not for all.
      Especially, there is a generic problem when the device has a genpd attached
      and that genpd have the ->start|stop() callbacks assigned.
      More precisely, if the driver calls pm_runtime_set_active() during
      ->probe(), genpd does not get to invoke the ->start() callback for it,
      which means the HW isn't really fully powered on. Furthermore, in the next
      phase, when the device becomes runtime suspended, genpd will invoke the
      ->stop() callback for it, potentially leading to usage count imbalance
      problems, depending on what's implemented behind the callbacks of course.
      To fix this problem, convert to call pm_runtime_get_sync() from
      tmio_mmc_host_probe() rather than pm_runtime_set_active(). Additionally, to
      avoid bumping usage counters and unnecessary re-initializing the HW the
      first time the tmio driver's ->runtime_resume() callback is called,
      introduce a state flag to keeping track of this.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
    • Ulf Hansson's avatar
      Revert "mmc: tmio: move runtime PM enablement to the driver implementations" · 8861474a
      Ulf Hansson authored
      This reverts commit 7ff21319.
      It turns out that the above commit introduces other problems. For example,
      calling pm_runtime_set_active() must not be done prior calling
      pm_runtime_enable() as that makes it fail. This leads to additional
      problems, such as clock enables being wrongly balanced.
      Rather than fixing the problem on top, let's start over by doing a revert.
      Fixes: 7ff21319
       ("mmc: tmio: move runtime PM enablement to the driver implementations")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
  2. 11 Sep, 2019 2 commits
  3. 06 Sep, 2019 3 commits
  4. 05 Sep, 2019 1 commit
    • Dan Carpenter's avatar
      drm/vmwgfx: Fix double free in vmw_recv_msg() · 08b0c891
      Dan Carpenter authored
      We recently added a kfree() after the end of the loop:
      	if (retries == RETRIES) {
      		return -EINVAL;
      There are two problems.  First the test is wrong and because retries
      equals RETRIES if we succeed on the last iteration through the loop.
      Second if we fail on the last iteration through the loop then the kfree
      is a double free.
      When you're reading this code, please note the break statement at the
      end of the while loop.  This patch changes the loop so that if it's not
      successful then "reply" is NULL and we can test for that afterward.
      Cc: <stable@vger.kernel.org>
      Fixes: 6b7c3b86
       ("drm/vmwgfx: fix memory leak when too many retries have occurred")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
  5. 04 Sep, 2019 7 commits
  6. 03 Sep, 2019 2 commits
    • Jan Kaisrlik's avatar
      Revert "mmc: core: do not retry CMD6 in __mmc_switch()" · 8ad8e02c
      Jan Kaisrlik authored
      Turns out the commit 3a0681c7 ("mmc: core: do not retry CMD6 in
      __mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card,
      when using the meson-gx-mmc.c driver on a custom board based on Amlogic
      The CMD6 that switches the card into HS200 mode is then one that fails and
      according to the below printed messages from the log:
      [    1.648951] mmc0: mmc_select_hs200 failed, error -84
      [    1.648988] mmc0: error -84 whilst initialising MMC card
      After some analyze, it turns out that adding a delay of ~5ms inside
      mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed,
      also fixes the problem. Adding yet some more debug code, trying to figure
      out if potentially the card could be in a busy state, both by using CMD13
      and ->card_busy() ops concluded that this was not the case.
      Therefore, let's simply revert the commit that dropped support for retrying
      of CMD6, as this also fixes the problem.
      Fixes: 3a0681c7
       ("mmc: core: do not retry CMD6 in __mmc_switch()")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJan Kaisrlik <ja.kaisrlik@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
    • Jacob Pan's avatar
      iommu/vt-d: Remove global page flush support · 8744daf4
      Jacob Pan authored
      Global pages support is removed from VT-d spec 3.0. Since global pages G
      flag only affects first-level paging structures and because DMA request
      with PASID are only supported by VT-d spec. 3.0 and onward, we can
      safely remove global pages support.
      For kernel shared virtual address IOTLB invalidation, PASID
      granularity and page selective within PASID will be used. There is
      no global granularity supported. Without this fix, IOTLB invalidation
      will cause invalid descriptor error in the queued invalidation (QI)
      Fixes: 1c4f88b7
       ("iommu/vt-d: Shared virtual address in scalable mode")
      Reported-by: default avatarSanjay K Kumar <sanjay.k.kumar@intel.com>
      Signed-off-by: default avatarJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
  7. 02 Sep, 2019 1 commit
  8. 01 Sep, 2019 9 commits
  9. 31 Aug, 2019 1 commit
  10. 30 Aug, 2019 12 commits