1. 05 Dec, 2017 1 commit
    • George Cherian's avatar
      ACPI / CPPC: Fix KASAN global out of bounds warning · 1ecbd717
      George Cherian authored
      Default value of pcc_subspace_idx is -1.
      Make sure to check pcc_subspace_idx before using the same as array index.
      This will avoid following KASAN warnings too.
      
      [   15.113449] ==================================================================
      [   15.116983] BUG: KASAN: global-out-of-bounds in cppc_get_perf_caps+0xf3/0x3b0
      [   15.116983] Read of size 8 at addr ffffffffb9a5c0d8 by task swapper/0/1
      [   15.116983] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2+ #2
      [   15.116983] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
      [   15.116983] Call Trace:
      [   15.116983]  dump_stack+0x7c/0xbb
      [   15.116983]  print_address_description+0x1df/0x290
      [   15.116983]  kasan_report+0x28a/0x370
      [   15.116983]  ? cppc_get_perf_caps+0xf3/0x3b0
      [   15.116983]  cppc_get_perf_caps+0xf3/0x3b0
      [   15.116983]  ? cpc_read+0x210/0x210
      [   15.116983]  ? __rdmsr_on_cpu+0x90/0x90
      [   15.116983]  ? rdmsrl_on_cpu+0xa9/0xe0
      [   15.116983]  ? rdmsr_on_cpu+0x100/0x100
      [   15.116983]  ? wrmsrl_on_cpu+0x9c/0xd0
      [   15.116983]  ? wrmsrl_on_cpu+0x9c/0xd0
      [   15.116983]  ? wrmsr_on_cpu+0xe0/0xe0
      [   15.116983]  __intel_pstate_cpu_init.part.16+0x3a2/0x530
      [   15.116983]  ? intel_pstate_init_cpu+0x197/0x390
      [   15.116983]  ? show_no_turbo+0xe0/0xe0
      [   15.116983]  ? __lockdep_init_map+0xa0/0x290
      [   15.116983]  intel_pstate_cpu_init+0x30/0x60
      [   15.116983]  cpufreq_online+0x155/0xac0
      [   15.116983]  cpufreq_add_dev+0x9b/0xb0
      [   15.116983]  subsys_interface_register+0x1ae/0x290
      [   15.116983]  ? bus_unregister_notifier+0x40/0x40
      [   15.116983]  ? mark_held_locks+0x83/0xb0
      [   15.116983]  ? _raw_write_unlock_irqrestore+0x32/0x60
      [   15.116983]  ? intel_pstate_setup+0xc/0x104
      [   15.116983]  ? intel_pstate_setup+0xc/0x104
      [   15.116983]  ? cpufreq_register_driver+0x1ce/0x2b0
      [   15.116983]  cpufreq_register_driver+0x1ce/0x2b0
      [   15.116983]  ? intel_pstate_setup+0x104/0x104
      [   15.116983]  intel_pstate_register_driver+0x3a/0xa0
      [   15.116983]  intel_pstate_init+0x3c4/0x434
      [   15.116983]  ? intel_pstate_setup+0x104/0x104
      [   15.116983]  ? intel_pstate_setup+0x104/0x104
      [   15.116983]  do_one_initcall+0x9c/0x206
      [   15.116983]  ? parameq+0xa0/0xa0
      [   15.116983]  ? initcall_blacklisted+0x150/0x150
      [   15.116983]  ? lock_downgrade+0x2c0/0x2c0
      [   15.116983]  kernel_init_freeable+0x327/0x3f0
      [   15.116983]  ? start_kernel+0x612/0x612
      [   15.116983]  ? _raw_spin_unlock_irq+0x29/0x40
      [   15.116983]  ? finish_task_switch+0xdd/0x320
      [   15.116983]  ? finish_task_switch+0x8e/0x320
      [   15.116983]  ? rest_init+0xd0/0xd0
      [   15.116983]  kernel_init+0xf/0x11a
      [   15.116983]  ? rest_init+0xd0/0xd0
      [   15.116983]  ret_from_fork+0x24/0x30
      
      [   15.116983] The buggy address belongs to the variable:
      [   15.116983]  __key.36299+0x38/0x40
      
      [   15.116983] Memory state around the buggy address:
      [   15.116983]  ffffffffb9a5bf80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [   15.116983]  ffffffffb9a5c000: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [   15.116983] >ffffffffb9a5c080: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00
      [   15.116983]                                                     ^
      [   15.116983]  ffffffffb9a5c100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   15.116983]  ffffffffb9a5c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   15.116983] ==================================================================
      
      Fixes: 85b1407b (ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs)
      Reported-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1ecbd717
  2. 20 Nov, 2017 2 commits
    • Lv Zheng's avatar
      ACPI / EC: Fix regression related to PM ops support in ECDT device · a64a62ce
      Lv Zheng authored
      On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
      EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
      ACPI device. Thus the following commit actually removed post-resume
      acpi_ec_enable_event() invocation for such platforms, and triggered a
      regression on them that after being resumed, EC (actually should be ECDT)
      driver stops handling EC events:
      
       Commit: c2b46d67
       Subject: ACPI / EC: Add PM operations to improve event handling for resume process
      
      Notice that the root cause actually is "ECDT is not an ACPI device" rather
      than "the timing of acpi_ec_enable_event() invocation", this patch fixes
      this issue by enumerating ECDT EC as an ACPI device. Due to the existence
      of the noirq stage, the ability of tuning the timing of
      acpi_ec_enable_event() invocation is still meaningful.
      
      This patch is a little bit different from the posted fix by moving
      acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
      sure that EC event handling won't be stopped as long as the ACPI EC driver
      is bound. Thus the following sequence shouldn't disable EC event handling:
      unbind,suspend,resume,bind.
      
      Fixes: c2b46d67 (ACPI / EC: Add PM operations to improve event handling for resume process)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847Reported-by: default avatarLuya Tshimbalanga <luya@fedoraproject.org>
      Tested-by: default avatarLuya Tshimbalanga <luya@fedoraproject.org>
      Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a64a62ce
    • Hans de Goede's avatar
      ACPI / bus: Leave modalias empty for devices which are not present · 10809bb9
      Hans de Goede authored
      Most Bay and Cherry Trail devices use a generic DSDT with all possible
      peripheral devices present in the DSDT, with their _STA returning 0x00 or
      0x0f based on AML variables which describe what is actually present on
      the board.
      
      Since ACPI device objects with a 0x00 status (not present) still get an
      entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
      modalias, userspace would end up loading modules for non present hardware.
      
      This commit fixes this by leaving the modalias empty for non present
      devices. This results in 10 modules less being loaded with a generic
      distro kernel config on my Cherry Trail test-device (a GPD pocket).
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      10809bb9
  3. 16 Nov, 2017 1 commit
  4. 14 Nov, 2017 1 commit
  5. 12 Nov, 2017 1 commit
    • Dan Williams's avatar
      acpi, nfit: validate commands against the device type · 0e7f0741
      Dan Williams authored
      Fix occasions in acpi_nfit_ctl where we check the command type without
      validating whether we are parsing dimm vs bus level commands. Where the
      command numbers alias between dimms and bus we can make the wrong
      assumption just checking the raw command number. For example, with a
      simple nfit_test mock up of the clear-error command we trigger the
      following:
      
          BUG: unable to handle kernel NULL pointer dereference at 0000000000000094
          IP: acpi_nfit_ctl+0x29b/0x930 [nfit]
          [..]
          Call Trace:
           nfit_test_probe+0xb85/0xc09 [nfit_test]
           platform_drv_probe+0x3b/0xa0
           ? platform_drv_probe+0x3b/0xa0
           driver_probe_device+0x29c/0x450
           ? test_alloc+0x180/0x180 [nfit_test]
           __driver_attach+0xe3/0xf0
           ? driver_probe_device+0x450/0x450
           bus_for_each_dev+0x73/0xc0
           driver_attach+0x1e/0x20
           bus_add_driver+0x173/0x270
           driver_register+0x60/0xe0
           __platform_driver_register+0x36/0x40
           nfit_test_init+0x2a1/0x1000 [nfit_test]
      
      Fixes: 4b27db7e ("acpi, nfit: add support for the _LSI, _LSR, and...")
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Tested-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      0e7f0741
  6. 08 Nov, 2017 8 commits
    • Gustavo A. R. Silva's avatar
      ACPI: Mark expected switch fall-throughs · 1be9c3a0
      Gustavo A. R. Silva authored
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases
      where we are expecting to fall through.
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1be9c3a0
    • Colin Ian King's avatar
      ACPI / LPSS: Remove redundant initialization of clk · 71c50dbe
      Colin Ian King authored
      The pointer clk is being initialized to ERR_PTR(-ENODEV) however
      this value is never read before it is set to clk_data->clk. Thus
      the initialization is redundant and can be mored.
      
      Cleans up clang warning:
      Value stored to 'clk' during its initialization is never read
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      71c50dbe
    • George Cherian's avatar
      ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs · 85b1407b
      George Cherian authored
      Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used,
      all PCC registers, for all processors in the same performance domain
      (as defined by _PSD), must be defined to be in the same subspace.
      
      Based on Section 14.1 of ACPI specification, it is possible to have a
      maximum of 256 PCC subspace IDs. Add support of multiple PCC subspace
      ID instead of using a single global pcc_data structure.
      
      While at that, fix the time_delta check in send_pcc_cmd() so that
      last_mpar_reset and mpar_count are initialized properly.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Reviewed-by: default avatarPrashanth Prakash <pprakash@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      85b1407b
    • Colin Ian King's avatar
      ACPI / sysfs: Make function param_set_trace_method_name() static · 3e87ead4
      Colin Ian King authored
      The function param_set_trace_method_name is local to the source and does
      not need to be in global scope, so make it static.
      
      Cleans up sparse warning:
      symbol 'param_set_trace_method_name' was not declared. Should it be static?
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3e87ead4
    • Hans de Goede's avatar
      ACPI / button: Delay acpi_lid_initialize_state() until first user space open · 84d3f6b7
      Hans de Goede authored
      ACPI _LID methods may depend on OpRegions and do not always handle
      handlers for those OpRegions not being present properly e.g. :
      
                  Method (_LID, 0, NotSerialized)  // _LID: Lid Status
                  {
                      If ((^^I2C5.PMI1.AVBL == One) && (^^GPO2.AVBL == One))
                      {
                          Return (^^GPO2.LPOL) /* \_SB_.GPO2.LPOL */
                      }
                  }
      
      Note the missing Return (1) when either of the OpRegions is not available,
      this causes (in this case) a report of the lid-switch being closed,
      which causes userspace to do an immediate suspend at boot.
      
      This commit delays getting the initial state and thus calling _LID for
      the first time until userspace opens the /dev/input/event# node. This
      ensures that all drivers will have had a chance to load and registerer
      their OpRegions before the first _LID call, fixing this issue.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      84d3f6b7
    • Lv Zheng's avatar
      ACPI / EC: Fix regression related to triggering source of EC event handling · 53c5eaab
      Lv Zheng authored
      Originally the Samsung quirks removed by commit 4c237371 can be covered
      by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956
      changed ec_freeze_events=Y back to N, making this problem re-surface.
      
      Actually, if commit e923e8e7 is robust enough, we can freely change
      ec_freeze_events mode, so this patch fixes the issue by improving
      commit e923e8e7.
      
      Related commits listed in the merged order:
      
       Commit: e923e8e7
       Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected
                after event is enabled
      
       Commit: 4c237371
       Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk
      
       Commit: 9c40f956
       Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix
                a regression
      
      This patch not only fixes the reported post-resume EC event triggering
      source issue, but also fixes an unreported similar issue related to the
      driver bind by adding EC event triggering source in ec_install_handlers().
      
      Fixes: e923e8e7 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled)
      Fixes: 4c237371 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk)
      Fixes: 9c40f956 (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Reported-by: default avatarAlistair Hamilton <ahpatent@gmail.com>
      Tested-by: default avatarAlistair Hamilton <ahpatent@gmail.com>
      Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      53c5eaab
    • Arnd Bergmann's avatar
      APEI / ERST: use 64-bit timestamps · c0041d40
      Arnd Bergmann authored
      32-bit timestamps are deprecated in the kernel, so we should not use
      get_seconds(). In this case, the 'struct cper_record_header' structure
      already contains a 64-bit field, so the only required change is to use
      the safe ktime_get_real_seconds() interface as a replacement.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c0041d40
    • Ville Syrjälä's avatar
      ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock · ff165679
      Ville Syrjälä authored
      acpi_remove_pm_notifier() ends up calling flush_workqueue() while
      holding acpi_pm_notifier_lock, and that same lock is taken by
      by the work via acpi_pm_notify_handler(). This can deadlock.
      
      To fix the problem let's split the single lock into two: one to
      protect the dev->wakeup between the work vs. add/remove, and
      another one to handle notifier installation vs. removal.
      
      After commit a1d14934 "workqueue/lockdep: 'Fix' flush_work()
      annotation" I was able to kill the machine (Intel Braswell)
      very easily with 'powertop --auto-tune', runtime suspending i915,
      and trying to wake it up via the USB keyboard. The cases when
      it didn't die are presumably explained by lockdep getting disabled
      by something else (cpu hotplug locking issues usually).
      
      Fortunately I still got a lockdep report over netconsole
      (trickling in very slowly), even though the machine was
      otherwise practically dead:
      
      [  112.179806] ======================================================
      [  114.670858] WARNING: possible circular locking dependency detected
      [  117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934 #119 Not tainted
      [  119.658101] ------------------------------------------------------
      [  121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
      [  121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
      [  121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
      [  121.313485] usb 1-6: USB disconnect, device number 3
      [  121.313501] usb 1-6.2: USB disconnect, device number 4
      [  134.747383] kworker/0:2/47 is trying to acquire lock:
      [  137.220790]  (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
      [  139.721524]
      [  139.721524] but task is already holding lock:
      [  144.672922]  ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
      [  147.184450]
      [  147.184450] which lock already depends on the new lock.
      [  147.184450]
      [  154.604711]
      [  154.604711] the existing dependency chain (in reverse order) is:
      [  159.447888]
      [  159.447888] -> #2 ((&dpc->work)){+.+.}:
      [  164.183486]        __lock_acquire+0x1255/0x13f0
      [  166.504313]        lock_acquire+0xb5/0x210
      [  168.778973]        process_one_work+0x1b9/0x720
      [  171.030316]        worker_thread+0x4c/0x440
      [  173.257184]        kthread+0x154/0x190
      [  175.456143]        ret_from_fork+0x27/0x40
      [  177.624348]
      [  177.624348] -> #1 ("kacpi_notify"){+.+.}:
      [  181.850351]        __lock_acquire+0x1255/0x13f0
      [  183.941695]        lock_acquire+0xb5/0x210
      [  186.046115]        flush_workqueue+0xdd/0x510
      [  190.408153]        acpi_os_wait_events_complete+0x31/0x40
      [  192.625303]        acpi_remove_notify_handler+0x133/0x188
      [  194.820829]        acpi_remove_pm_notifier+0x56/0x90
      [  196.989068]        acpi_dev_pm_detach+0x5f/0xa0
      [  199.145866]        dev_pm_domain_detach+0x27/0x30
      [  201.285614]        i2c_device_probe+0x100/0x210
      [  203.411118]        driver_probe_device+0x23e/0x310
      [  205.522425]        __driver_attach+0xa3/0xb0
      [  207.634268]        bus_for_each_dev+0x69/0xa0
      [  209.714797]        driver_attach+0x1e/0x20
      [  211.778258]        bus_add_driver+0x1bc/0x230
      [  213.837162]        driver_register+0x60/0xe0
      [  215.868162]        i2c_register_driver+0x42/0x70
      [  217.869551]        0xffffffffa0172017
      [  219.863009]        do_one_initcall+0x45/0x170
      [  221.843863]        do_init_module+0x5f/0x204
      [  223.817915]        load_module+0x225b/0x29b0
      [  225.757234]        SyS_finit_module+0xc6/0xd0
      [  227.661851]        do_syscall_64+0x5c/0x120
      [  229.536819]        return_from_SYSCALL_64+0x0/0x7a
      [  231.392444]
      [  231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
      [  235.124914]        check_prev_add+0x44e/0x8a0
      [  237.024795]        __lock_acquire+0x1255/0x13f0
      [  238.937351]        lock_acquire+0xb5/0x210
      [  240.840799]        __mutex_lock+0x75/0x940
      [  242.709517]        mutex_lock_nested+0x1c/0x20
      [  244.551478]        acpi_pm_notify_handler+0x2f/0x80
      [  246.382052]        acpi_ev_notify_dispatch+0x44/0x5c
      [  248.194412]        acpi_os_execute_deferred+0x14/0x30
      [  250.003925]        process_one_work+0x1ec/0x720
      [  251.803191]        worker_thread+0x4c/0x440
      [  253.605307]        kthread+0x154/0x190
      [  255.387498]        ret_from_fork+0x27/0x40
      [  257.153175]
      [  257.153175] other info that might help us debug this:
      [  257.153175]
      [  262.324392] Chain exists of:
      [  262.324392]   acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
      [  262.324392]
      [  267.391997]  Possible unsafe locking scenario:
      [  267.391997]
      [  270.758262]        CPU0                    CPU1
      [  272.431713]        ----                    ----
      [  274.060756]   lock((&dpc->work));
      [  275.646532]                                lock("kacpi_notify");
      [  277.260772]                                lock((&dpc->work));
      [  278.839146]   lock(acpi_pm_notifier_lock);
      [  280.391902]
      [  280.391902]  *** DEADLOCK ***
      [  280.391902]
      [  284.986385] 2 locks held by kworker/0:2/47:
      [  286.524895]  #0:  ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
      [  288.112927]  #1:  ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
      [  289.727725]
      
      Fixes: c072530f (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ff165679
  7. 07 Nov, 2017 2 commits
  8. 06 Nov, 2017 3 commits
    • Rafael J. Wysocki's avatar
      ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360 · 71630b7a
      Rafael J. Wysocki authored
      At least one Dell XPS13 9360 is reported to have serious issues with
      the Low Power S0 Idle _DSM interface and since this machine model
      generally can do ACPI S3 just fine, add a blacklist entry to disable
      that interface for Dell XPS13 9360.
      
      Fixes: 8110dd28 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196907Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Tested-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
      71630b7a
    • Rafael J. Wysocki's avatar
      ACPI / PM: Take SMART_SUSPEND driver flag into account · 05087360
      Rafael J. Wysocki authored
      Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
      its system suspend callbacks.
      
      [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
      is an optimization, because if is not passed, all of the subsequent
      checks may be skipped and some of them are much more overhead in
      general.]
      
      Also use the observation that if the device is in runtime suspend
      at the beginning of the "late" phase of a system-wide suspend-like
      transition, its state cannot change going forward (runtime PM is
      disabled for it at that time) until the transition is over and the
      subsequent system-wide PM callbacks should be skipped for it (as
      they generally assume the device to not be suspended), so add
      checks for that in acpi_subsys_suspend_late/noirq() and
      acpi_subsys_freeze_late/noirq().
      
      Moreover, if acpi_subsys_resume_noirq() is called during the
      subsequent system-wide resume transition and if the device was left
      in runtime suspend previously, its runtime PM status needs to be
      changed to "active" as it is going to be put into the full-power
      state going forward, so add a check for that too in there.
      
      In turn, if acpi_subsys_thaw_noirq() runs after the device has been
      left in runtime suspend, the subsequent "thaw" callbacks need
      to be skipped for it (as they may not work correctly with a
      suspended device), so set the power.direct_complete flag for the
      device then to make the PM core skip those callbacks.
      
      On top of the above, make the analogous changes in the acpi_lpss
      driver that uses the ACPI PM domain callbacks.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05087360
    • Rafael J. Wysocki's avatar
      PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags · 08810a41
      Rafael J. Wysocki authored
      The motivation for this change is to provide a way to work around
      a problem with the direct-complete mechanism used for avoiding
      system suspend/resume handling for devices in runtime suspend.
      
      The problem is that some middle layer code (the PCI bus type and
      the ACPI PM domain in particular) returns positive values from its
      system suspend ->prepare callbacks regardless of whether the driver's
      ->prepare returns a positive value or 0, which effectively prevents
      drivers from being able to control the direct-complete feature.
      Some drivers need that control, however, and the PCI bus type has
      grown its own flag to deal with this issue, but since it is not
      limited to PCI, it is better to address it by adding driver flags at
      the core level.
      
      To that end, add a driver_flags field to struct dev_pm_info for flags
      that can be set by device drivers at the probe time to inform the PM
      core and/or bus types, PM domains and so on on the capabilities and/or
      preferences of device drivers.  Also add two static inline helpers
      for setting that field and testing it against a given set of flags
      and make the driver core clear it automatically on driver remove
      and probe failures.
      
      Define and document two PM driver flags related to the direct-
      complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
      respectively, to indicate to the PM core that the direct-complete
      mechanism should never be used for the device and to inform the
      middle layer code (bus types, PM domains etc) that it can only
      request the PM core to use the direct-complete mechanism for
      the device (by returning a positive value from its ->prepare
      callback) if it also has been requested by the driver.
      
      While at it, make the core check pm_runtime_suspended() when
      setting power.direct_complete so that it doesn't need to be
      checked by ->prepare callbacks.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      08810a41
  9. 04 Nov, 2017 1 commit
    • Andy Lutomirski's avatar
      Revert "x86/mm: Stop calling leave_mm() in idle code" · 67535736
      Andy Lutomirski authored
      This reverts commit 43858b4f.
      
      The reason I removed the leave_mm() calls in question is because the
      heuristic wasn't needed after that patch.  With the original version
      of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
      kernel thread) due a flush on the loaded mm.
      
      Unfortunately, that caused architectural issues, so now I've
      reinstated these flushes on non-PCID systems in:
      
          commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode").
      
      That, in turn, gives us a power management and occasionally
      performance regression as compared to old kernels: a process that
      goes into a deep idle state on a given CPU and gets its mm flushed
      due to activity on a different CPU will wake the idle CPU.
      
      Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
      intel_idle state that is likely to cause a TLB flush gets its mm
      switched to init_mm before going idle.
      
      FWIW, this heuristic is lousy.  Whether we should change CR3 before
      idle isn't a good hint except insofar as the performance hit is a bit
      lower if the TLB is getting flushed by the idle code anyway.  What we
      really want to know is whether we anticipate being idle long enough
      that the mm is likely to be flushed before we wake up.  This is more a
      matter of the expected latency than the idle state that gets chosen.
      This heuristic also completely fails on systems that don't know
      whether the TLB will be flushed (e.g. AMD systems?).  OTOH it may be a
      bit obsolete anyway -- PCID systems don't presently benefit from this
      heuristic at all.
      
      We also shouldn't do this callback from innermost bit of the idle code
      due to the RCU nastiness it causes.  All the information need is
      available before rcu_idle_enter() needs to happen.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code"
      Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      67535736
  10. 02 Nov, 2017 3 commits
    • Kees Cook's avatar
      ACPI / APEI: Convert timers to use timer_setup() · d5272003
      Kees Cook authored
      In preparation for unconditionally passing the struct timer_list pointer to
      all timer callbacks, switch to using the new timer_setup() and from_timer()
      to pass the timer pointer explicitly.
      
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Tyler Baicar <tbaicar@codeaurora.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
      Cc: Shiju Jose <shiju.jose@huawei.com>
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarTyler Baicar <tbaicar@codeaurora.org>
      d5272003
    • Dave Jiang's avatar
      libnvdimm: move poison list functions to a new 'badrange' file · aa9ad44a
      Dave Jiang authored
      nfit_test needs to use the poison list manipulation code as well. Make
      it more generic and in the process rename poison to badrange, and move
      all the related helpers to a new file.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      [vishal: Add badrange.o to nfit_test's Kbuild]
      [vishal: add a missed include in bus.c for the new badrange functions]
      [vishal: rename all instances of 'be' to 'bre']
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      aa9ad44a
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  11. 31 Oct, 2017 1 commit
    • Kees Cook's avatar
      treewide: Fix function prototypes for module_param_call() · e4dca7b7
      Kees Cook authored
      Several function prototypes for the set/get functions defined by
      module_param_call() have a slightly wrong argument types. This fixes
      those in an effort to clean up the calls when running under type-enforced
      compiler instrumentation for CFI. This is the result of running the
      following semantic patch:
      
      @match_module_param_call_function@
      declarer name module_param_call;
      identifier _name, _set_func, _get_func;
      expression _arg, _mode;
      @@
      
       module_param_call(_name, _set_func, _get_func, _arg, _mode);
      
      @fix_set_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._set_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _set_func(
      -_val_type _val
      +const char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      @fix_get_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._get_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _get_func(
      -_val_type _val
      +char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      Two additional by-hand changes are included for places where the above
      Coccinelle script didn't notice them:
      
      	drivers/platform/x86/thinkpad_acpi.c
      	fs/lockd/svc.c
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJessica Yu <jeyu@kernel.org>
      e4dca7b7
  12. 30 Oct, 2017 1 commit
  13. 29 Oct, 2017 1 commit
  14. 24 Oct, 2017 1 commit
  15. 23 Oct, 2017 1 commit
  16. 21 Oct, 2017 1 commit
  17. 20 Oct, 2017 1 commit
  18. 19 Oct, 2017 1 commit
  19. 17 Oct, 2017 1 commit
  20. 16 Oct, 2017 8 commits
    • Rafael J. Wysocki's avatar
      ACPI / PM: Combine device suspend routines · cbe25ce3
      Rafael J. Wysocki authored
      On top of a previous change getting rid of the PM QoS flag
      PM_QOS_FLAG_REMOTE_WAKEUP, combine two ACPI device suspend routines,
      acpi_dev_runtime_suspend() and acpi_dev_suspend_late(), into one,
      acpi_dev_suspend(), to eliminate some code duplication.
      
      It also avoids enabling wakeup for devices handled by the ACPI
      LPSS middle layer on driver removal.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      cbe25ce3
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Enable SMMUv3/PMCG IORT MSI domain set-up · 65637901
      Lorenzo Pieralisi authored
      ITS specific mappings for SMMUv3/PMCG components can be retrieved
      through special index mapping entries introduced in IORT revision C.
      
      Introduce a new API iort_set_device_domain() to set the MSI domain for
      SMMUv3/PMCG nodes (extendable to any future IORT node requiring special
      index ITS mapping entries) that represent MSI through special index
      mappings in order to enable MSI support for the devices their nodes
      represent.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      65637901
    • Hanjun Guo's avatar
      ACPI/IORT: Add SMMUv3 specific special index mapping handling · 86456a3f
      Hanjun Guo authored
      IORT revision C introduced a mapping entry binding to describe ITS
      device ID mapping for SMMUv3 MSI interrupts.
      
      Enable the single mapping flag (ie that is used by SMMUv3 component for
      its special index mappings) for the SMMUv3 node in the IORT mapping API
      and add IORT code to handle special index mapping entry for the SMMUv3
      IORT nodes to enable their MSI interrupts. In case the ACPICA for
      SMMUv3 device ID mapping is not ready, use the ACPICA version as a guard
      for function iort_get_id_mapping_index().
      Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      [lorenzo.pieralisi@arm.com: patch split, typos fixing, rewrote the log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      86456a3f
    • Hanjun Guo's avatar
      ACPI/IORT: Enable special index ITS group mappings for IORT nodes · 8c8df8dc
      Hanjun Guo authored
      IORT revision C introduced SMMUv3 and PMCG MSI support by adding
      specific mapping entries in the SMMUv3/PMCG subtables to retrieve
      the device ID and the ITS group it maps to for a given SMMUv3/PMCG
      IORT node.
      
      Introduce a mapping function (ie iort_get_id_mapping_index()), that
      for a given IORT node looks up if an ITS specific ID mapping entry
      exists and if so retrieve the corresponding mapping index in the IORT
      node mapping array.
      
      Since an ITS specific index mapping can be present for an IORT
      node that is not a leaf node (eg SMMUv3 - to describe its own
      ITS device ID) special handling is required for two steps mapping
      cases such as PCI/NamedComponent--->SMMUv3--->ITS because the SMMUv3
      ITS specific index mapping entry should be skipped to prevent the
      IORT API from considering the mapping entry as a regular mapping one.
      
      If we take the following IORT topology example:
      
      |----------------------|
      |  Root Complex Node   |
      |----------------------|
      |    map entry[x]      |
      |----------------------|
      |       id value       |
      | output_reference     |
      |---|------------------|
          |
          |   |----------------------|
          |-->|        SMMUv3        |
              |----------------------|
              |     SMMUv3 dev ID    |
              |     mapping index 0  |
              |----------------------|
              |      map entry[0]    |
              |----------------------|
              |       id value       |
              | output_reference-----------> ITS 1 (SMMU MSI domain)
              |----------------------|
              |      map entry[1]    |
              |----------------------|
              |       id value       |
              | output_reference-----------> ITS 2 (PCI MSI domain)
              |----------------------|
      
      where the SMMUv3 ITS specific mapping entry is index 0 and it
      represents the SMMUv3 ITS specific index mapping entry (describing its
      own ITS device ID), we need to skip that mapping entry while carrying
      out the Root Complex Node regular mappings to prevent erroneous
      translations.
      
      Reuse the iort_get_id_mapping_index() function to detect the ITS
      specific mapping index for a specific IORT node and skip it in the IORT
      mapping API (ie iort_node_map_id()) loop to prevent considering it a
      normal PCI/Named Component ID mapping entry.
      Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      [lorenzo.pieralisi@arm.com: split patch/rewrote commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      8c8df8dc
    • Hanjun Guo's avatar
      ACPI/IORT: Look up IORT node through struct fwnode_handle pointer · 0a71d8b9
      Hanjun Guo authored
      Current IORT code provides a function (ie iort_get_fwnode())
      which looks up a struct fwnode_handle pointer through a
      struct acpi_iort_node pointer for SMMU components but it
      lacks a function that implements the reverse look-up, namely
      struct fwnode_handle* -> struct acpi_iort_node*.
      
      Devices that are not IORT named components cannot be retrieved through
      their associated IORT named component scan interface because they just
      are not represented in the ACPI namespace; the reverse look-up is
      therefore required for all platform devices that represent IORT nodes
      (eg SMMUs) so that the struct acpi_iort_node* can be retrieved from the
      struct device->fwnode pointer.
      Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      [lorenzo.pieralisi@arm.com: re-indented/rewrote the commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      0a71d8b9
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Make platform devices initialization code SMMU agnostic · 896dd2c3
      Lorenzo Pieralisi authored
      The way current IORT code initializes platform devices for SMMU nodes
      is somewhat tied (mostly for naming convention) to the SMMU nodes
      themselves but it need not be in that it is completely generic and
      can easily be made so by structures renaming and code reshuffling.
      
      Rework IORT platform devices initialization code to make the functions
      and data structures SMMU agnostic.
      
      No functional changes intended.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      896dd2c3
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Improve functions return type/storage class specifier indentation · e3d49392
      Lorenzo Pieralisi authored
      Some functions definition indentations are using a style that is frowned
      upon with return value type/storage class specifier in a separate line.
      
      Reindent the function definitions to fix them.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      e3d49392
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Remove leftover ACPI_IORT_SMMU_V3_PXM_VALID guard · 75808131
      Lorenzo Pieralisi authored
      The conditional ACPI_IORT_SMMU_V3_PXM_VALID guard around
      arm_smmu_v3_set_proximity() was added to manage a cross tree
      ACPICA merge dependency; with ACPICA changes merged in:
      
      commit c9442300 ("ACPICA: iasl: Update to IORT SMMUv3
      disassembling")
      
      the guard has become useless. Remove it.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
      75808131