1. 10 10月, 2016 1 次提交
    • S
      ACPI / fan: Fix error reading cur_state · 84baf172
      Srinivas Pandruvada 提交于
      On some platforms with ACPI4 variable speed fan, reading cur_state from
      cooling device returns "invalid value" error. This confuses user space
      applications.
      
      This issue occurs as the current driver doesn't take account of
      "FineGrainControl" from _FIF(Fan Information). When the "FineGrainControl"
      is set, _FSL(FSL Set Level) takes argument as a percent, which doesn't
      have to match from any control value from _FPS(Fan Performance States).
      It is also possible that the Fan is not actually running at the requested
      speed returning a lower speed.
      On some platforms the BIOS is setting fan speed to a level during boot,
      which will not have an exact match to _FPS control values. The current
      implementation will treat this level as invalid value.
      
      The simple change is to atleast return state corresponding to a maximum
      control value in the _FPS compared to the current level.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      84baf172
  2. 10 3月, 2016 1 次提交
  3. 16 1月, 2016 1 次提交
  4. 08 7月, 2015 1 次提交
  5. 16 5月, 2015 1 次提交
    • R
      ACPI / PM: Rework device power management to follow ACPI 6 · 20dacb71
      Rafael J. Wysocki 提交于
      The ACPI 6 specification has made some changes in the device power
      management area.  In particular:
      
       * The D3hot power state is now supposed to be always available
         (instead of D3cold) and D3cold is only regarded as valid if the
         _PR3 object is present for the given device.
      
       * The required ordering of transitions into power states deeper than
         D0 is now such that for a transition into state Dx the _PSx method
         is supposed to be executed first, if present, and the states of
         the power resources the device depends on are supposed to be
         changed after that.
      
       * It is now explicitly forbidden to transition devices from
         lower-power (deeper) into higher-power (shallower) power states
         other than D0.
      
      Those changes have been made so the specification reflects the
      Windows' device power management code that the vast majority of
      systems using ACPI is validated against.
      
      To avoid artificial differences in ACPI device power management
      between Windows and Linux, modify the ACPI device power management
      code to follow the new specification.  Add comments explaining the
      code flow in some unclear places.
      
      This only may affect some real corner cases in which the OS behavior
      expected by the firmware is different from the Windows one, but that's
      quite unlikely.  The transition ordering change affects transitions
      to D1 and D2 which are rarely used (if at all) and into D3hot and
      D3cold for devices actually having _PR3, but those are likely to
      be validated against Windows anyway.  The other changes may affect
      code calling acpi_device_get_power() or acpi_device_update_power()
      where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
      (that's why the ACPI fan driver needs to be updated too) and since
      transitions into ACPI_STATE_D3_HOT may remove power now, it is better
      to avoid this one in acpi_pm_device_sleep_state() if the "no power
      off" PM QoS flag is set.
      
      The only existing user of acpi_device_can_poweroff() really cares
      about the case when _PR3 is present, so the change in that function
      should not cause any problems to happen too.
      
      A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
      now and the compatibility with older systems should be covered
      automatically.
      
      In any case, if any real problems result from this, it still will
      be better to follow the Windows' behavior (which now is reflected
      by the specification too) in general and handle the cases when it
      doesn't work via quirks.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      20dacb71
  6. 11 12月, 2014 1 次提交
  7. 10 10月, 2014 6 次提交
  8. 07 10月, 2014 1 次提交
  9. 21 2月, 2014 1 次提交
  10. 13 2月, 2014 1 次提交
  11. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  12. 24 9月, 2013 1 次提交
  13. 30 7月, 2013 1 次提交
  14. 04 7月, 2013 1 次提交
  15. 26 3月, 2013 1 次提交
  16. 26 1月, 2013 1 次提交
  17. 22 9月, 2012 1 次提交
  18. 10 8月, 2012 1 次提交
  19. 01 7月, 2012 2 次提交
  20. 17 7月, 2011 1 次提交
  21. 12 1月, 2011 1 次提交
  22. 16 10月, 2010 1 次提交
  23. 30 9月, 2010 1 次提交
  24. 10 6月, 2010 1 次提交
    • L
      ACPI: fan: fix unbalanced code block · 934231de
      Liang Li 提交于
      The code block braced with CONFIG_ACPI_PROCFS is unblanced. When
      CONFIG_ACPI_PROCFS=n, kernel trace will be produced like:
      
      Call Trace:
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c103b02c>] warn_slowpath_common+0x6c/0xc0
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c103b0c6>] warn_slowpath_fmt+0x26/0x30
       [<c111637d>] remove_proc_entry+0x20d/0x290
       [<c1116bd7>] ? proc_register+0x117/0x1f0
       [<c1116e83>] ? proc_mkdir_mode+0x33/0x50
       [<c14f483c>] ? acpi_fan_init+0x0/0x2c
       [<c14f485f>] acpi_fan_init+0x23/0x2c
       [<c1001123>] do_one_initcall+0x23/0x180
       [<c107dcf7>] ? init_irq_proc+0x67/0x80
       [<c14d43bd>] kernel_init+0x13c/0x20e
       [<c1030e50>] ? schedule_tail+0x20/0x90
       [<c1389e06>] ? syscall_exit+0x5/0x16
       [<c14d4281>] ? kernel_init+0x0/0x20e
       [<c14d4281>] ? kernel_init+0x0/0x20e
       [<c10032f6>] kernel_thread_helper+0x6/0x30
      ---[ end trace a7919e7f17c0a725 ]---
      
      Then also bracket later error checking code with ACPI_PROCFS
      option to avoid mismatch problem.
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      934231de
  25. 16 12月, 2009 1 次提交
  26. 29 8月, 2009 1 次提交
  27. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  28. 20 2月, 2009 1 次提交
  29. 08 11月, 2008 1 次提交
  30. 23 10月, 2008 1 次提交
  31. 11 10月, 2008 1 次提交
  32. 22 7月, 2008 1 次提交
  33. 17 7月, 2008 1 次提交
    • Y
      ACPI: fix acpi fan state set error · 6594d87e
      Yi Yang 提交于
      Under /proc/acpi, there is a fan control interface, a user can
      set 0 or 3 to /proc/acpi/fan/*/state, 0 denotes D0 state, 3
      denotes D3 state, but in current implementation, a user can
      set a fan to D1 state by any char excluding '1', '2' and '3'.
      
      For example:
      
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      
      Obviously, such inputs as "" and "xxxxx" are invalid for fan state.
      
      This patch fixes this issue, it strictly limits fan state only to
      accept 0, 1, 2 and 3, any other inputs are invalid.
      
      Before applying this patch, the test result is:
      
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "3x" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "-1x" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]#
      
      After applying this patch, the test result is:
      
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "-1x" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "4" > //proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "3" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "3x" > //proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]#
      Signed-off-by: NYi Yang <yi.y.yang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      6594d87e
  34. 29 4月, 2008 1 次提交