1. 21 Jul, 2019 1 commit
    • James Morse's avatar
      drivers: base: cacheinfo: Ensure cpu hotplug work is done before Intel RDT · b6ac72d9
      James Morse authored
      commit 83b44fe343b5abfcb1b2261289bd0cfcfcfd60a8 upstream.
      The cacheinfo structures are alloced/freed by cpu online/offline
      callbacks. Originally these were only used by sysfs to expose the
      cache topology to user space. Without any in-kernel dependencies
      CPUHP_AP_ONLINE_DYN was an appropriate choice.
      resctrl has started using these structures to identify CPUs that
      share a cache. It updates its 'domain' structures from cpu
      online/offline callbacks. These depend on the cacheinfo structures
      These also run as CPUHP_AP_ONLINE_DYN.
      Now that there is an in-kernel dependency, move the cacheinfo
      work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN
      work runs.
      Fixes: 2264d9c7 ("x86/intel_rdt: Build structures for each resource based on cache topology")
      Cc: <stable@vger.kernel.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Reinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Link: https://lore.kernel.org/r/20190624173656.202407-1-james.morse@arm.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 31 May, 2019 1 commit
  3. 25 May, 2019 1 commit
    • John Garry's avatar
      driver core: Postpone DMA tear-down until after devres release for probe failure · ff8af90d
      John Garry authored
      commit 0b777eee88d712256ba8232a9429edb17c4f9ceb upstream.
      In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
      devres release"), we changed the ordering of tearing down the device DMA
      ops and releasing all the device's resources; this was because the DMA ops
      should be maintained until we release the device's managed DMA memories.
      However, we have seen another crash on an arm64 system when a
      device driver probe fails:
        hisi_sas_v3_hw 0000:74:02.0: Adding to iommu group 2
        scsi host1: hisi_sas_v3_hw
        BUG: Bad page state in process swapper/0  pfn:313f5
        page:ffff7e0000c4fd40 count:1 mapcount:0
        mapping:0000000000000000 index:0x0
        flags: 0xfffe00000001000(reserved)
        raw: 0fffe00000001000 ffff7e0000c4fd48 ffff7e0000c4fd48
        raw: 0000000000000000 0000000000000000 00000001ffffffff
        page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
        bad because of flags: 0x1000(reserved)
        Modules linked in:
        CPU: 49 PID: 1 Comm: swapper/0 Not tainted
      5.1.0-rc1-43081-g22d97fd-dirty #1433
        Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI
      RC0 - V1.12.01 01/29/2019
        Call trace:
        Disabling lock debugging due to kernel taint
        BUG: Bad page state in process swapper/0  pfn:313f6
        page:ffff7e0000c4fd80 count:1 mapcount:0
      mapping:0000000000000000 index:0x0
      [   89.322983] flags: 0xfffe00000001000(reserved)
        raw: 0fffe00000001000 ffff7e0000c4fd88 ffff7e0000c4fd88
        raw: 0000000000000000 0000000000000000 00000001ffffffff
      The crash occurs for the same reason.
      In this case, on the really_probe() failure path, we are still clearing
      the DMA ops prior to releasing the device's managed memories.
      This patch fixes this issue by reordering the DMA ops teardown and the
      call to devres_release_all() on the failure path.
      Reported-by: default avatarXiang Chen <chenxiang66@hisilicon.com>
      Tested-by: default avatarXiang Chen <chenxiang66@hisilicon.com>
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      [jpg: backport to 4.19.x and earlier]
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 16 May, 2019 1 commit
  5. 14 May, 2019 1 commit
  6. 20 Apr, 2019 1 commit
  7. 23 Mar, 2019 1 commit
    • Viresh Kumar's avatar
      PM / wakeup: Rework wakeup source timer cancellation · 4e2a61f2
      Viresh Kumar authored
      commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream.
      If wakeup_source_add() is called right after wakeup_source_remove()
      for the same wakeup source, timer_setup() may be called for a
      potentially scheduled timer which is incorrect.
      To avoid that, move the wakeup source timer cancellation from
      wakeup_source_drop() to wakeup_source_remove().
      Moreover, make wakeup_source_remove() clear the timer function after
      canceling the timer to let wakeup_source_not_registered() treat
      unregistered wakeup sources in the same way as the ones that have
      never been registered.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      [ rjw: Subject, changelog, merged two patches together ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 13 Mar, 2019 1 commit
    • Geert Uytterhoeven's avatar
      driver core: Postpone DMA tear-down until after devres release · 6f166975
      Geert Uytterhoeven authored
      commit 376991db4b6464e906d699ef07681e2ffa8ab08c upstream.
      When unbinding the (IOMMU-enabled) R-Car SATA device on Salvator-XS
      (R-Car H3 ES2.0), in preparation of rebinding against vfio-platform for
      device pass-through for virtualization:
          echo ee300000.sata > /sys/bus/platform/drivers/sata_rcar/unbind
      the kernel crashes with:
          Unable to handle kernel paging request at virtual address ffffffbf029ffffc
          Mem abort info:
            ESR = 0x96000006
            Exception class = DABT (current EL), IL = 32 bits
            SET = 0, FnV = 0
            EA = 0, S1PTW = 0
          Data abort info:
            ISV = 0, ISS = 0x00000006
            CM = 0, WnR = 0
          swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000007e8c586c
          [ffffffbf029ffffc] pgd=000000073bfc6003, pud=000000073bfc6003, pmd=0000000000000000
          Internal error: Oops: 96000006 [#1] SMP
          Modules linked in:
          CPU: 0 PID: 1098 Comm: bash Not tainted 5.0.0-rc5-salvator-x-00452-g37596f884f4318ef #287
          Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
          pstate: 60400005 (nZCv daif +PAN -UAO)
          pc : __free_pages+0x8/0x58
          lr : __dma_direct_free_pages+0x50/0x5c
          sp : ffffff801268baa0
          x29: ffffff801268baa0 x28: 0000000000000000
          x27: ffffffc6f9c60bf0 x26: ffffffc6f9c60bf0
          x25: ffffffc6f9c60810 x24: 0000000000000000
          x23: 00000000fffff000 x22: ffffff8012145000
          x21: 0000000000000800 x20: ffffffbf029fffc8
          x19: 0000000000000000 x18: ffffffc6f86c42c8
          x17: 0000000000000000 x16: 0000000000000070
          x15: 0000000000000003 x14: 0000000000000000
          x13: ffffff801103d7f8 x12: 0000000000000028
          x11: ffffff8011117604 x10: 0000000000009ad8
          x9 : ffffff80110126d0 x8 : ffffffc6f7563000
          x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000018
          x5 : ffffff8011cf3cc8 x4 : 0000000000004000
          x3 : 0000000000080000 x2 : 0000000000000001
          x1 : 0000000000000000 x0 : ffffffbf029fffc8
          Process bash (pid: 1098, stack limit = 0x00000000c38e3e32)
          Call trace:
          Code: d51b4234 17fffffa a9bf7bfd 910003fd (b9403404)
          ---[ end trace 8c564cdd3a1a840f ]---
      While I've bisected this to commit e8e683ae9a736407 ("iommu/of: Fix
      probe-deferral"), and reverting that commit on post-v5.0-rc4 kernels
      does fix the problem, this turned out to be a red herring.
      On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL.
      Hence if a driver has used a managed DMA allocation API, the allocated
      DMA memory will be freed using the direct DMA ops, while it may have
      been allocated using a custom DMA ops (iommu_dma_ops in this case).
      Fix this by reversing the order of the calls to devres_release_all() and
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      [rm: backport for 4.12-4.19 - kernels before 5.0 will not see
       the crash above, but may get silent memory corruption instead]
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 12 Feb, 2019 3 commits
  10. 06 Feb, 2019 1 commit
    • Benjamin Herrenschmidt's avatar
      drivers: core: Remove glue dirs from sysfs earlier · 2f4da60e
      Benjamin Herrenschmidt authored
      commit 726e4109 upstream.
      For devices with a class, we create a "glue" directory between
      the parent device and the new device with the class name.
      This directory is never "explicitely" removed when empty however,
      this is left to the implicit sysfs removal done by kobject_release()
      when the object loses its last reference via kobject_put().
      This is problematic because as long as it's not been removed from
      sysfs, it is still present in the class kset and in sysfs directory
      The presence in the class kset exposes a use after free bug fixed
      by the previous patch, but the presence in sysfs means that until
      the kobject is released, which can take a while (especially with
      kobject debugging), any attempt at re-creating such as binding a
      new device for that class/parent pair, will result in a sysfs
      duplicate file name error.
      This fixes it by instead doing an explicit kobject_del() when
      the glue dir is empty, by keeping track of the number of
      child devices of the gluedir.
      This is made easy by the fact that all glue dir operations are
      done with a global mutex, and there's already a function
      (cleanup_glue_dir) called in all the right places taking that
      mutex that can be enhanced for this. It appears that this was
      in fact the intent of the function, but the implementation was
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Guenter Roeck <groeck@google.com>
      Cc: Zubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. 26 Jan, 2019 1 commit
    • Daniel Vetter's avatar
      sysfs: Disable lockdep for driver bind/unbind files · d9c25a6f
      Daniel Vetter authored
      [ Upstream commit 4f4b374332ec0ae9c738ff8ec9bed5cd97ff9adc ]
      This is the much more correct fix for my earlier attempt at:
      Short recap:
      - There's not actually a locking issue, it's just lockdep being a bit
        too eager to complain about a possible deadlock.
      - Contrary to what I claimed the real problem is recursion on
        kn->count. Greg pointed me at sysfs_break_active_protection(), used
        by the scsi subsystem to allow a sysfs file to unbind itself. That
        would be a real deadlock, which isn't what's happening here. Also,
        breaking the active protection means we'd need to manually handle
        all the lifetime fun.
      - With Rafael we discussed the task_work approach, which kinda works,
        but has two downsides: It's a functional change for a lockdep
        annotation issue, and it won't work for the bind file (which needs
        to get the errno from the driver load function back to userspace).
      - Greg also asked why this never showed up: To hit this you need to
        unregister a 2nd driver from the unload code of your first driver. I
        guess only gpus do that. The bug has always been there, but only
        with a recent patch series did we add more locks so that lockdep
        built a chain from unbinding the snd-hda driver to the
        acpi_video_unregister call.
      Full lockdep splat:
      [12301.898799] ============================================
      [12301.898805] WARNING: possible recursive locking detected
      [12301.898811] 4.20.0-rc7+ #84 Not tainted
      [12301.898815] --------------------------------------------
      [12301.898821] bash/5297 is trying to acquire lock:
      [12301.898826] 00000000f61c6093 (kn->count#39){++++}, at: kernfs_remove_by_name_ns+0x3b/0x80
      [12301.898841] but task is already holding lock:
      [12301.898847] 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
      [12301.898856] other info that might help us debug this:
      [12301.898862]  Possible unsafe locking scenario:
      [12301.898867]        CPU0
      [12301.898870]        ----
      [12301.898874]   lock(kn->count#39);
      [12301.898879]   lock(kn->count#39);
      [12301.898883] *** DEADLOCK ***
      [12301.898891]  May be due to missing lock nesting notation
      [12301.898899] 5 locks held by bash/5297:
      [12301.898903]  #0: 00000000cd800e54 (sb_writers#4){.+.+}, at: vfs_write+0x17f/0x1b0
      [12301.898915]  #1: 000000000465e7c2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xd3/0x190
      [12301.898925]  #2: 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
      [12301.898936]  #3: 00000000414ef7ac (&dev->mutex){....}, at: device_release_driver_internal+0x34/0x240
      [12301.898950]  #4: 000000003218fbdf (register_count_mutex){+.+.}, at: acpi_video_unregister+0xe/0x40
      [12301.898960] stack backtrace:
      [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
      [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 68SCF Ver. F.01 03/11/2011
      [12301.898982] Call Trace:
      [12301.898989]  dump_stack+0x67/0x9b
      [12301.898997]  __lock_acquire+0x6ad/0x1410
      [12301.899003]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899010]  ? find_held_lock+0x2d/0x90
      [12301.899017]  ? mutex_spin_on_owner+0xe4/0x150
      [12301.899023]  ? find_held_lock+0x2d/0x90
      [12301.899030]  ? lock_acquire+0x90/0x180
      [12301.899036]  lock_acquire+0x90/0x180
      [12301.899042]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899049]  __kernfs_remove+0x296/0x310
      [12301.899055]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899060]  ? kernfs_name_hash+0xd/0x80
      [12301.899066]  ? kernfs_find_ns+0x6c/0x100
      [12301.899073]  kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899080]  bus_remove_driver+0x92/0xa0
      [12301.899085]  acpi_video_unregister+0x24/0x40
      [12301.899127]  i915_driver_unload+0x42/0x130 [i915]
      [12301.899160]  i915_pci_remove+0x19/0x30 [i915]
      [12301.899169]  pci_device_remove+0x36/0xb0
      [12301.899176]  device_release_driver_internal+0x185/0x240
      [12301.899183]  unbind_store+0xaf/0x180
      [12301.899189]  kernfs_fop_write+0x104/0x190
      [12301.899195]  __vfs_write+0x31/0x180
      [12301.899203]  ? rcu_read_lock_sched_held+0x6f/0x80
      [12301.899209]  ? rcu_sync_lockdep_assert+0x29/0x50
      [12301.899216]  ? __sb_start_write+0x13c/0x1a0
      [12301.899221]  ? vfs_write+0x17f/0x1b0
      [12301.899227]  vfs_write+0xb9/0x1b0
      [12301.899233]  ksys_write+0x50/0xc0
      [12301.899239]  do_syscall_64+0x4b/0x180
      [12301.899247]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [12301.899253] RIP: 0033:0x7f452ac7f7a4
      [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
      [12301.899273] RSP: 002b:00007ffceafa6918 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [12301.899282] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f452ac7f7a4
      [12301.899288] RDX: 000000000000000d RSI: 00005612a1abf7c0 RDI: 0000000000000001
      [12301.899295] RBP: 00005612a1abf7c0 R08: 000000000000000a R09: 00005612a1c46730
      [12301.899301] R10: 000000000000000a R11: 0000000000000246 R12: 000000000000000d
      [12301.899308] R13: 0000000000000001 R14: 00007f452af4a740 R15: 000000000000000d
      Looking around I've noticed that usb and i2c already handle similar
      recursion problems, where a sysfs file can unbind the same type of
      sysfs somewhere else in the hierarchy. Relevant commits are:
      commit 356c05d5
      Author: Alan Stern <stern@rowland.harvard.edu>
      Date:   Mon May 14 13:30:03 2012 -0400
          sysfs: get rid of some lockdep false positives
      commit e9b526fe
      Author: Alexander Sverdlin <alexander.sverdlin@nsn.com>
      Date:   Fri May 17 14:56:35 2013 +0200
          i2c: suppress lockdep warning on delete_device
      Implement the same trick for driver bind/unbind.
      v2: Put the macro into bus.c (Greg).
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ramalingam C <ramalingam.c@intel.com>
      Cc: Arend van Spriel <aspriel@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Bartosz Golaszewski <brgl@bgdev.pl>
      Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
      Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  12. 09 Jan, 2019 1 commit
    • Miquel Raynal's avatar
      platform-msi: Free descriptors in platform_msi_domain_free() · 69beeb1c
      Miquel Raynal authored
      commit 81b1e6e6a8590a19257e37a1633bec098d499c57 upstream.
      Since the addition of platform MSI support, there were two helpers
      supposed to allocate/free IRQs for a device:
      In these helpers, IRQ descriptors are allocated in the "alloc" routine
      while they are freed in the "free" one.
      Later, two other helpers have been added to handle IRQ domains on top
      of MSI domains:
      Seen from the outside, the logic is pretty close with the former
      helpers and people used it with the same logic as before: a
      platform_msi_domain_alloc() call should be balanced with a
      platform_msi_domain_free() call. While this is probably what was
      intended to do, the platform_msi_domain_free() does not remove/free
      the IRQ descriptor(s) created/inserted in
      One effect of such situation is that removing a module that requested
      an IRQ will let one orphaned IRQ descriptor (with an allocated MSI
      entry) in the device descriptors list. Next time the module will be
      inserted back, one will observe that the allocation will happen twice
      in the MSI domain, one time for the remaining descriptor, one time for
      the new one. It also has the side effect to quickly overshoot the
      maximum number of allocated MSI and then prevent any module requesting
      an interrupt in the same domain to be inserted anymore.
      This situation has been met with loops of insertion/removal of the
      mvpp2.ko module (requesting 15 MSIs each time).
      Fixes: 552c494a ("platform-msi: Allow creation of a MSI-based stacked irq domain")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. 01 Dec, 2018 1 commit
  14. 13 Oct, 2018 1 commit
  15. 26 Sep, 2018 1 commit
  16. 23 Sep, 2018 2 commits
  17. 05 Sep, 2018 1 commit
  18. 15 Aug, 2018 1 commit
    • Andi Kleen's avatar
      x86/speculation/l1tf: Add sysfs reporting for l1tf · 3d98de69
      Andi Kleen authored
      commit 17dbca11 upstream
      L1TF core kernel workarounds are cheap and normally always enabled, However
      they still should be reported in sysfs if the system is vulnerable or
      mitigated. Add the necessary CPU feature/bug bits.
      - Extend the existing checks for Meltdowns to determine if the system is
        vulnerable. All CPUs which are not vulnerable to Meltdown are also not
        vulnerable to L1TF
      - Check for 32bit non PAE and emit a warning as there is no practical way
        for mitigation due to the limited physical address bits
      - If the system has more than MAX_PA/2 physical memory the invert page
        workarounds don't protect the system against the L1TF attack anymore,
        because an inverted physical address will also point to valid
        memory. Print a warning in this case and report that the system is
      Add a function which returns the PFN limit for the L1TF mitigation, which
      will be used in follow up patches for sanity and range checks.
      [ tglx: Renamed the CPU feature bit to L1TF_PTEINV ]
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarDave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. 28 Jul, 2018 1 commit
  20. 03 Jul, 2018 3 commits
    • Waldemar Rymarkiewicz's avatar
      PM / OPP: Update voltage in case freq == old_freq · 8b033765
      Waldemar Rymarkiewicz authored
      commit c5c2a97b upstream.
      This commit fixes a rare but possible case when the clk rate is updated
      without update of the regulator voltage.
      At boot up, CPUfreq checks if the system is running at the right freq. This
      is a sanity check in case a bootloader set clk rate that is outside of freq
      table present with cpufreq core. In such cases system can be unstable so
      better to change it to a freq that is preset in freq-table.
      The CPUfreq takes next freq that is >= policy->cur and this is our
      target_freq that needs to be set now.
      dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
      old_freq (a current rate). If these are equal it returns early. If not,
      it searches for OPP (old_opp) that fits best to old_freq (not listed in
      the table) and updates old_freq (!).
      Here, we can end up with old_freq = old_opp.rate = target_freq, which
      is not handled in _generic_set_opp_regulator(). It's supposed to update
      voltage only when freq > old_freq  || freq > old_freq.
      if (freq > old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      if (freq < old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      		if (ret)
      It results in, no voltage update while clk rate is updated.
      freq-table = {
      	1000MHz   1.15V
      	 666MHZ   1.10V
      	 333MHz   1.05V
      boot-up-freq        = 800MHz   # not listed in freq-table
      freq = target_freq  = 1GHz
      old_freq            = 800Mhz
      old_opp = _find_freq_ceil(opp_table, &old_freq);  #(old_freq is modified!)
      old_freq            = 1GHz
      Fixes: 6a0712f6 ("PM / OPP: Add dev_pm_opp_set_rate()")
      Cc: 4.6+ <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarWaldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Rafael J. Wysocki's avatar
      PM / core: Fix supplier device runtime PM usage counter imbalance · ba0be597
      Rafael J. Wysocki authored
      commit 47e5abfb upstream.
      If a device link is added via device_link_add() by the driver of the
      link's consumer device, the supplier's runtime PM usage counter is
      going to be dropped by the pm_runtime_put_suppliers() call in
      driver_probe_device().  However, in that case it is not incremented
      unless the supplier driver is already present and the link is not
      stateless.  That leads to a runtime PM usage counter imbalance for
      the supplier device in a few cases.
      To prevent that from happening, bump up the supplier runtime
      PM usage counter in device_link_add() for all links with the
      DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe
      time.  Use pm_runtime_get_noresume() for that as the callers of
      device_link_add() who want the supplier to be resumed by it are
      expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but
      additionally resume the supplier if the link is added during
      consumer driver probe to retain the existing behavior for the
      callers depending on it.
      Fixes: 21d5c57b (PM / runtime: Use device links)
      Reported-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ulf Hansson's avatar
      PM / Domains: Fix error path during attach in genpd · b7ac0389
      Ulf Hansson authored
      commit 72038df3 upstream.
      In case the PM domain fails to be powered on in genpd_dev_pm_attach(), it
      returns -EPROBE_DEFER, but keeping the device attached to its PM domain.
      This leads to problems when the next attempt to attach is re-tried. More
      precisely, in that situation an -EEXIST error code is returned, because the
      device already has its PM domain pointer assigned, from the first attempt.
      Now, because of the sloppy error handling by the existing callers of
      dev_pm_domain_attach(), probing is allowed to continue when -EEXIST is
      returned. However, in such case there are no guarantees that the PM domain
      is powered on by genpd, which may lead to hangs when buses/drivers tried to
      access their devices.
      Let's fix this behaviour, simply by detaching the device when powering on
      fails in genpd_dev_pm_attach().
      Cc: v4.11+ <stable@vger.kernel.org> # v4.11+
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  21. 26 Jun, 2018 1 commit
  22. 30 May, 2018 1 commit
  23. 22 May, 2018 1 commit
  24. 26 Apr, 2018 2 commits
    • Tony Lindgren's avatar
      PM / wakeirq: Fix unbalanced IRQ enable for wakeirq · c064b7c1
      Tony Lindgren authored
      [ Upstream commit 69728051 ]
      If a device is runtime PM suspended when we enter suspend and has
      a dedicated wake IRQ, we can get the following warning:
      WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
      [  102.087860] Unbalanced enable for IRQ 147
      (enable_irq) from [<c06117a8>] (dev_pm_arm_wake_irq+0x4c/0x60)
      (dev_pm_arm_wake_irq) from [<c0618360>]
      (device_wakeup_arm_wake_irqs) from [<c0615948>]
      (dpm_suspend_noirq) from [<c01ac7ac>]
      (suspend_devices_and_enter) from [<c01adf20>]
      (enter_state) from [<c01ad3ec>] (pm_suspend+0x38/0x98)
      (pm_suspend) from [<c01ab3e8>] (state_store+0x68/0xc8)
      This is because the dedicated wake IRQ for the device may have been
      already enabled earlier by dev_pm_enable_wake_irq_check().  Fix the
      issue by checking for runtime PM suspended status.
      This issue can be easily reproduced by setting serial console log level
      to zero, letting the serial console idle, and suspend the system from
      an ssh terminal.  On resume, dmesg will have the warning above.
      The reason why I have not run into this issue earlier has been that I
      typically run my PM test cases from on a serial console instead over ssh.
      Fixes: c8434559 (PM / wakeirq: Enable dedicated wakeirq for suspend)
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ulf Hansson's avatar
      PM / domains: Fix up domain-idle-states OF parsing · 4b95781c
      Ulf Hansson authored
      [ Upstream commit a3381e3a ]
      Commit b539cc82 (PM / Domains: Ignore domain-idle-states that are
      not compatible), made it possible to ignore non-compatible
      domain-idle-states OF nodes. However, in case that happens while doing
      the OF parsing, the number of elements in the allocated array would
      exceed the numbers actually needed, thus wasting memory.
      Fix this by pre-iterating the genpd OF node and counting the number of
      compatible domain-idle-states nodes, before doing the allocation. While
      doing this, it makes sense to rework the code a bit to avoid open coding,
      of parts responsible for the OF node iteration.
      Let's also take the opportunity to clarify the function header for
      of_genpd_parse_idle_states(), about what is being returned in case of
      Fixes: b539cc82 (PM / Domains: Ignore domain-idle-states that are not compatible)
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLina Iyer <ilina@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  25. 24 Apr, 2018 1 commit
  26. 08 Apr, 2018 1 commit
    • Gaku Inami's avatar
      Revert "base: arch_topology: fix section mismatch build warnings" · 0d3f8c02
      Gaku Inami authored
      commit 9de9a449 upstream.
      This reverts commit 452562ab ("base: arch_topology: fix section
      mismatch build warnings"). It causes the notifier call hangs in some
      In some cases with using maxcpus, some of cpus are booted first and
      then the remaining cpus are booted. As an example, some users who want
      to realize fast boot up often use the following procedure.
        1) Define all CPUs on device tree (CA57x4 + CA53x4)
        2) Add "maxcpus=4" in bootargs
        3) Kernel boot up with CA57x4
        4) After kernel boot up, CA53x4 is booted from user
      When kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still
      unregisterd. This means that "__init init_cpu_capacity_callback()"
      will be called after kernel init sequence. To avoid this problem,
      it needs to remove __init{,data} annotations by reverting this commit.
      Also, this commit was needed to fix kernel compile issue below.
      However, this issue was also fixed by another patch: commit 82d8ba71
      ("arch_topology: Fix section miss match warning due to
      free_raw_capacity()") in v4.15 as well.
      Whereas commit 452562ab added all the missing __init annotations,
      commit 82d8ba71 removed it from free_raw_capacity().
      WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference
      from the function init_cpu_capacity_callback() to the variable
      The function init_cpu_capacity_callback() references
      the variable __init $x.
      This is often because init_cpu_capacity_callback lacks a __init
      annotation or the annotation of $x is wrong.
      Fixes: 82d8ba71 ("arch_topology: Fix section miss match warning due to free_raw_capacity()")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGaku Inami <gaku.inami.xh@renesas.com>
      Reviewed-by: default avatarDietmar Eggemann <dietmar.eggemann@arm.com>
      Tested-by: default avatarDietmar Eggemann <dietmar.eggemann@arm.com>
      Acked-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  27. 19 Mar, 2018 1 commit
  28. 25 Feb, 2018 1 commit
  29. 22 Feb, 2018 1 commit
  30. 17 Jan, 2018 1 commit
  31. 02 Jan, 2018 1 commit
  32. 25 Dec, 2017 1 commit
  33. 14 Dec, 2017 2 commits