1. 12 2月, 2018 7 次提交
  2. 08 2月, 2018 1 次提交
  3. 07 2月, 2018 4 次提交
  4. 06 2月, 2018 1 次提交
  5. 04 2月, 2018 8 次提交
    • S
      ACPI / LPIT: Export lpit_read_residency_count_address() · 9383bbad
      Srinivas Pandruvada 提交于
      Export lpit_read_residency_count_address(), so that it can be used from
      drivers built as module. With the recent changes, the builtin_pci
      functionality of the intel_pmc_core driver is removed and now it can be
      built as a module to read this exported interface to calculate the PMC base
      address.
      
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: linux-acpi@vger.kernel.org
      Acked-by: NRafael J. Wysocki <rafael@kernel.org>
      Tested-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      9383bbad
    • Y
      ACPI / processor: Set default C1 idle state description · 248e8841
      Yazen Ghannam 提交于
      The ACPI idle driver will default to ACPI_CSTATE_HALT for C1 if a _CST
      object for C1 is not defined. However, the description will not be set,
      so users will see "<null>" when reading the description from sysfs.
      
      Set the C1 state description when defaulting to ACPI_CSTATE_HALT.
      Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      248e8841
    • K
      ACPI / battery: Add quirk for Asus UX360UA and UX410UAK · 4446823e
      Kai Heng Feng 提交于
      Same issue as other Asus laptops, ACPI incorrectly reports discharging
      when battery is full and AC is plugged.
      
      Use the same battery quirk can workaround the issue.
      
      Link: https://bugs.launchpad.net/bugs/1661876
      Link: https://bugs.launchpad.net/bugs/1745032Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4446823e
    • C
      ACPI: processor_perflib: Do not send _PPC change notification if not ready · ba1edb9a
      Chen Yu 提交于
      The following warning was triggered after resumed from S3 -
      if all the nonboot CPUs were put offline before suspend:
      
      [ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30)
      [ 1840.329516] Call Trace:
      [ 1840.329521]  __rdmsr_on_cpu+0x33/0x50
      [ 1840.329525]  generic_exec_single+0x81/0xb0
      [ 1840.329527]  smp_call_function_single+0xd2/0x100
      [ 1840.329530]  ? acpi_ds_result_pop+0xdd/0xf2
      [ 1840.329532]  ? acpi_ds_create_operand+0x215/0x23c
      [ 1840.329534]  rdmsrl_on_cpu+0x57/0x80
      [ 1840.329536]  ? cpumask_next+0x1b/0x20
      [ 1840.329538]  ? rdmsrl_on_cpu+0x57/0x80
      [ 1840.329541]  intel_pstate_update_perf_limits+0xf3/0x220
      [ 1840.329544]  ? notifier_call_chain+0x4a/0x70
      [ 1840.329546]  intel_pstate_set_policy+0x4e/0x150
      [ 1840.329548]  cpufreq_set_policy+0xcd/0x2f0
      [ 1840.329550]  cpufreq_update_policy+0xb2/0x130
      [ 1840.329552]  ? cpufreq_update_policy+0x130/0x130
      [ 1840.329556]  acpi_processor_ppc_has_changed+0x65/0x80
      [ 1840.329558]  acpi_processor_notify+0x80/0x100
      [ 1840.329561]  acpi_ev_notify_dispatch+0x44/0x5c
      [ 1840.329563]  acpi_os_execute_deferred+0x14/0x20
      [ 1840.329565]  process_one_work+0x193/0x3c0
      [ 1840.329567]  worker_thread+0x35/0x3b0
      [ 1840.329569]  kthread+0x125/0x140
      [ 1840.329571]  ? process_one_work+0x3c0/0x3c0
      [ 1840.329572]  ? kthread_park+0x60/0x60
      [ 1840.329575]  ? do_syscall_64+0x67/0x180
      [ 1840.329577]  ret_from_fork+0x25/0x30
      [ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30)
      [ 1840.329586] Call Trace:
      [ 1840.329587]  __wrmsr_on_cpu+0x37/0x40
      [ 1840.329589]  generic_exec_single+0x81/0xb0
      [ 1840.329592]  smp_call_function_single+0xd2/0x100
      [ 1840.329594]  ? acpi_ds_create_operand+0x215/0x23c
      [ 1840.329595]  ? cpumask_next+0x1b/0x20
      [ 1840.329597]  wrmsrl_on_cpu+0x57/0x70
      [ 1840.329598]  ? rdmsrl_on_cpu+0x57/0x80
      [ 1840.329599]  ? wrmsrl_on_cpu+0x57/0x70
      [ 1840.329602]  intel_pstate_hwp_set+0xd3/0x150
      [ 1840.329604]  intel_pstate_set_policy+0x119/0x150
      [ 1840.329606]  cpufreq_set_policy+0xcd/0x2f0
      [ 1840.329607]  cpufreq_update_policy+0xb2/0x130
      [ 1840.329610]  ? cpufreq_update_policy+0x130/0x130
      [ 1840.329613]  acpi_processor_ppc_has_changed+0x65/0x80
      [ 1840.329615]  acpi_processor_notify+0x80/0x100
      [ 1840.329617]  acpi_ev_notify_dispatch+0x44/0x5c
      [ 1840.329619]  acpi_os_execute_deferred+0x14/0x20
      [ 1840.329620]  process_one_work+0x193/0x3c0
      [ 1840.329622]  worker_thread+0x35/0x3b0
      [ 1840.329624]  kthread+0x125/0x140
      [ 1840.329625]  ? process_one_work+0x3c0/0x3c0
      [ 1840.329626]  ? kthread_park+0x60/0x60
      [ 1840.329628]  ? do_syscall_64+0x67/0x180
      [ 1840.329631]  ret_from_fork+0x25/0x30
      
      This is because if there's only one online CPU, the MSR_PM_ENABLE
      (package wide)can not be enabled after resumed, due to
      intel_pstate_hwp_enable() will only be invoked on AP's online
      process after resumed - if there's no AP online, the HWP remains
      disabled after resumed (BIOS has disabled it in S3). Then if
      there comes a _PPC change notification which touches HWP register
      during this stage, the warning is triggered.
      
      Since we don't call acpi_processor_register_performance() when
      HWP is enabled, the pr->performance will be NULL. When this is
      NULL we don't need to do _PPC change notification.
      Reported-by: NDoug Smythies <dsmythies@telus.net>
      Suggested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NYu Chen <yu.c.chen@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ba1edb9a
    • H
      ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs · 63347db0
      Hans de Goede 提交于
      The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some
      code to handle certain device quirks, in some cases we also need this
      quirk handling for the initial _STA call.
      
      Specifically on some devices calling _STA before all _DEP dependencies
      are met results in errors like these:
      
      [    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
                     [GenericSerialBus] (20170831/evregion-166)
      [    0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
                     (20170831/exfldio-299)
      [    0.123618] ACPI Error: Method parse/execution failed
                     \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
      
      acpi_get_bus_status already has code to avoid this, so by using it we
      also silence these errors from the initial _STA call.
      
      Note that in order for the acpi_get_bus_status handling for this to work,
      we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called,
      this means that battery devices will be instantiated with an initial
      status of 0. This is not a problem, acpi_bus_attach will get called soon
      after the instantiation anyways and it will update the status as first
      point of order.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      63347db0
    • H
      ACPI / bus: Do not call _STA on battery devices with unmet dependencies · 54ddce70
      Hans de Goede 提交于
      The battery code uses acpi_device->dep_unmet to check for unmet deps and
      if there are unmet deps it does not bind to the device to avoid errors
      about missing OpRegions when calling ACPI methods on the device.
      
      The missing OpRegions when there are unmet deps problem also applies to
      the _STA method of some battery devices and calling it too early results
      in errors like these:
      
      [    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
                     [GenericSerialBus] (20170831/evregion-166)
      [    0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
                     (20170831/exfldio-299)
      [    0.123618] ACPI Error: Method parse/execution failed
                     \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
      
      This commit fixes these errors happening when acpi_get_bus_status gets
      called by checking dep_unmet for battery devices and reporting a status
      of 0 until all dependencies are met.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      54ddce70
    • H
      ACPI: export acpi_bus_get_status_handle() · 5a98231f
      Hans de Goede 提交于
      Some modular drivers need this, export it.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5a98231f
    • G
      ACPI / video: Use true for boolean value · 97e45dd6
      Gustavo A. R. Silva 提交于
      Assign true or false to boolean variables instead of an integer value.
      
      This issue was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      97e45dd6
  6. 03 2月, 2018 1 次提交
  7. 02 2月, 2018 2 次提交
  8. 24 1月, 2018 2 次提交
  9. 17 1月, 2018 1 次提交
  10. 16 1月, 2018 1 次提交
    • H
      ACPI / LPSS: Do not instiate platform_dev for devs without MMIO resources · e1681599
      Hans de Goede 提交于
      acpi_lpss_create_device() skips handling LPSS devices which do not have
      a mmio resources in their resource list (typically these devices are
      disabled by the firmware). But since the LPSS code does not bind to the
      device, acpi_bus_attach() ends up still creating a platform device for
      it and the regular platform_driver for the ACPI HID still tries to bind
      to it.
      
      This happens e.g. on some boards which do not use the pwm-controller
      and have an empty or invalid resource-table for it. Currently this causes
      these error messages to get logged:
      
      [    3.281966] pwm-lpss 80862288:00: invalid resource
      [    3.287098] pwm-lpss: probe of 80862288:00 failed with error -22
      
      This commit stops the undesirable creation of a platform_device for
      disabled LPSS devices by setting pnp.type.platform_id to 0. Note that
      acpi_scan_attach_handler() also sets pnp.type.platform_id to 0 when there
      is a matching handler for the device and that handler has no attach
      callback, so we simply behave as a handler without an attach function
      in this case.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e1681599
  11. 15 1月, 2018 1 次提交
  12. 12 1月, 2018 1 次提交
  13. 11 1月, 2018 1 次提交
  14. 10 1月, 2018 1 次提交
  15. 09 1月, 2018 1 次提交
  16. 05 1月, 2018 7 次提交