1. 12 Oct, 2007 1 commit
    • Kay Sievers's avatar
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      Kay Sievers authored
      This changes the uevent buffer functions to use a struct instead of a
      long list of parameters. It does no longer require the caller to do the
      proper buffer termination and size accounting, which is currently wrong
      in some places. It fixes a known bug where parts of the uevent
      environment are overwritten because of wrong index calculations.
      
      Many thanks to Mathieu Desnoyers for finding bugs and improving the
      error handling.
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      7eff2e7a
  2. 11 Oct, 2007 1 commit
  3. 09 Oct, 2007 1 commit
    • Jeff Garzik's avatar
      drivers/firmware: const-ify DMI API and internals · 1855256c
      Jeff Garzik authored
      Three main sets of changes:
      
      1) dmi_get_system_info() return value should have been marked const,
         since callers should not be changing that data.
      
      2) const-ify DMI internals, since DMI firmware tables should,
         whenever possible, be marked const to ensure we never ever write to
         that data area.
      
      3) const-ify DMI API, to enable marking tables const where possible
         in low-level drivers.
      
      And if we're really lucky, this might enable some additional
      optimizations on the part of the compiler.
      
      The bulk of the changes are #2 and #3, which are interrelated.  #1 could
      have been a separate patch, but it was so small compared to the others,
      it was easier to roll it into this changeset.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      1855256c
  4. 25 Sep, 2007 2 commits
  5. 22 Sep, 2007 1 commit
    • Thomas Gleixner's avatar
      ACPI: disable lower idle C-states across suspend/resume · b04e7bdb
      Thomas Gleixner authored
      device_suspend() calls ACPI suspend functions, which seems to have undesired
      side effects on lower idle C-states. It took me some time to realize that
      especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
      show this effect. I'm quite sure that other bug reports against suspend/resume
      about turning the system into a brick have the same root cause.
      
      After fishing in the dark for quite some time, I realized that removing the ACPI
      processor module before suspend (this removes the lower C-state functionality)
      made the problem disappear. Interestingly enough the propability of having a
      bricked box is influenced by various factors (interrupts, size of the ram image,
      ...). Even adding a bunch of printks in the wrong places made the problem go
      away. The previous periodic tick implementation simply pampered over the
      problem, which explains why the dyntick / clockevents changes made this more
      prominent.
      
      We avoid complex functionality during the boot process and we have to do the
      same during suspend/resume. It is a similar scenario and equaly fragile.
      
      Add suspend / resume functions to the ACPI processor code and disable the lower
      idle C-states across suspend/resume. Fall back to the default idle
      implementation (halt) instead.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b04e7bdb
  6. 21 Sep, 2007 1 commit
  7. 20 Sep, 2007 1 commit
  8. 18 Sep, 2007 2 commits
    • Maik Broemme's avatar
      ACPI: video: remove dmesg spam · 7f10cc4e
      Maik Broemme authored
      i am actually heavily using the ACPI video extension for my Thinkpad X61
      Tablet. I have bound the input events triggered by the brightness
      up/down keys to a simple
      
      echo <value> > /sys/class/backlight/acpi_video1/brightness
      
      but everytime the event is triggered and acpi_video_device_lcd_set_level()
      is called i got a notificication in my kernel log like:
      
      set_level status: 0
      set_level status: 0
      set_level status: 0
      set_level status: 0
      ...
      Signed-off-by: default avatarMaik Broemme <mbroemme@plusserver.de>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7f10cc4e
    • Zhang Rui's avatar
      ACPI: video: _DOS=0 by default to prevent hotkey hang · a21101c4
      Zhang Rui authored
      In the past, the Linux/ACPI video driver invoked _DOS
      (Display Output Switch) with the parameter 1
      to tell the BIOS to switch the video output display for us.
      
      But this conflicts with Linux native graphics drivers,
      and can cause all sorts of issues, including hanging the system.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=6001
      
      Here we change the Linux default to evaluate _DOS=0,
      which tells the BIOS to simply send us a hotkey event
      and not touch the graphics hardware.
      
      The acpi video driver sends the display switch hotkey
      event up through the intput layer, and X can interpret
      that and use its native graphics driver to switch the display.
      
      For the case where Linux has no native graphics driver running,
      or the graphics driver doesn't know how to switch video and
      the BIOS (safely) does, the previous behaviour can be restored with:
      
      # echo 1 > /proc/acpi/video/*/DOS
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      a21101c4
  9. 16 Sep, 2007 1 commit
  10. 03 Sep, 2007 1 commit
  11. 30 Aug, 2007 1 commit
  12. 28 Aug, 2007 1 commit
  13. 27 Aug, 2007 1 commit
    • Hugh Dickins's avatar
      reverse CONFIG_ACPI_PROC_EVENT default · 721ebe00
      Hugh Dickins authored
      Sigh.  Again an ACPI assault on the Thinkpad's Fn+F4 to suspend to RAM.
      The default and text for CONFIG_THINKPAD_ACPI_INPUT_ENABLED were fixed
      in -rc3, but now commit 14e04fb3 ("ACPI:
      Schedule /proc/acpi/event for removal") introduces the ACPI_PROC_EVENT
      config entry, and defaults it to 'n' to disable it again.
      
      Change default to y, and add comment to make it clearer that n is for
      future distros.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <len.brown@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      721ebe00
  14. 25 Aug, 2007 1 commit
  15. 24 Aug, 2007 8 commits
  16. 23 Aug, 2007 6 commits
  17. 20 Aug, 2007 1 commit
  18. 14 Aug, 2007 3 commits
  19. 13 Aug, 2007 1 commit
  20. 11 Aug, 2007 5 commits
    • Len Brown's avatar
      ACPI: thermal: add DMI hooks to handle AOpen's broken Award BIOS · 0b5bfa1c
      Len Brown authored
      Use DMI to:
      1. enable polling (BIOS thermal events are broken)
      2. disable active trip points (BIOS fan control is broken)
      3. disable passive trip point (BIOS hard-codes it too low)
      
      The actual temperature reading does work,
      and with the aid of polling, the critical
      trip point should work too.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=8842Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      0b5bfa1c
    • Len Brown's avatar
      ACPI: thermal: create "thermal.act=" to disable or override active trip point · f8707ec9
      Len Brown authored
      thermal.act=-1 disables all active trip points
      in all ACPI thermal zones.
      
      thermal.act=C, where C > 0, overrides all lowest temperature
      active trip points in all thermal zones to C degrees Celsius.
      Raising this trip-point may allow you to keep your system silent
      up to a higher temperature.  However, it will not allow you to
      raise the lowest temperature trip point above the next higher
      trip point (if there is one).  Lowering this trip point may
      kick in the fan sooner.
      
      Note that overriding this trip-point will disable any BIOS attempts
      to implement hysteresis around the lowest temperature trip point.
      This may result in the fan starting and stopping frequently
      if temperature frequently crosses C.
      
      WARNING: raising trip points above the manufacturer's defaults
      may cause the system to run at higher temperature and shorten
      its life.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      f8707ec9
    • Len Brown's avatar
      ACPI: thermal: create "thermal.nocrt" to disable critical actions · f5487145
      Len Brown authored
      thermal.nocrt=1 disables actions on _CRT and _HOT
      ACPI thermal zone trip-points.  They will be marked
      as <disabled> in /proc/acpi/thermal_zone/*/trip_points.
      
      There are two cases where this option is used:
      
      1. Debugging a hot system crossing valid trip point.
      
         If your system fan is spinning at full speed,
         be sure that the vent is not clogged with dust.
         Many laptops have very fine thermal fins that are easily blocked.
      
         Check that the processor fan-sink is properly seated,
         has the proper thermal grease, and is really spinning.
      
         Check for fan related options in BIOS SETUP.
         Sometimes there is a performance vs quiet option.
         Defaults are generally the most conservative.
      
         If your fan is not spinning, yet /proc/acpi/fan/
         has files in it, please file a Linux/ACPI bug.
      
         WARNING: you risk shortening the lifetime of your
         hardware if you use this parameter on a hot system.
         Note that this refers to all system components,
         including the disk drive.
      
      2. Working around a cool system crossing critical
         trip point due to erroneous temperature reading.
      
         Try again with CONFIG_HWMON=n
         There is known potential for conflict between the
         the hwmon sub-system and the ACPI BIOS.
         If this fixes it, notify lm-sensors@lm-sensors.org
         and linux-acpi@vger.kernel.org
      
         Otherwise, file a Linux/ACPI bug, or notify
         just linux-acpi@vger.kernel.org.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      f5487145
    • Len Brown's avatar
      ACPI: thermal: create "thermal.psv=" to override passive trip points · a70cdc52
      Len Brown authored
      "thermal.psv=-1" disables passive trip points
      for all ACPI thermal zones.
      
      "thermal.psv=C", where 'C' is degrees Celsius,
      overrides all existing passive trip points
      for all ACPI thermal zones.
      
      thermal.psv is checked at module load time,
      and in response to trip-point change events.
      
      Note that if the system does not deliver thermal zone
      temperature change events near the new trip-point,
      then it will not be noticed.  To force your custom
      trip point to be noticed, you may need to enable polling:
      eg. thermal.tzp=3000 invokes polling every 5 minutes.
      
      Note that once passive thermal throttling is invoked,
      it has its own internal Thermal Sampling Period (_TSP),
      that is unrelated to _TZP.
      
      WARNING: disabling or raising a thermal trip point
      may result in increased running temperature and
      shorter hardware lifetime on some systems.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      a70cdc52
    • Len Brown's avatar
      ACPI: thermal: expose "thermal.tzp=" to set global polling frequency · 730ff34d
      Len Brown authored
      Thermal Zone Polling frequency (_TZP) is an optional ACPI object
      recommending the rate that the OS should poll the associated thermal zone.
      
      If _TZP is 0, no polling should be used.
      If _TZP is non-zero, then the platform recommends that
      the OS poll the thermal zone at the specified rate.
      The minimum period is 30 seconds.
      The maximum period is 5 minutes.
      
      (note _TZP and thermal.tzp units are in deci-seconds,
       so _TZP = 300 corresponds to 30 seconds)
      
      If _TZP is not present, ACPI 3.0b recommends that the
      thermal zone be polled at an "OS provided default frequency".
      
      However, common industry practice is:
      1. The BIOS never specifies any _TZP
      2. High volume OS's from this century never poll any thermal zones
      
      Ie. The OS depends on the platform's ability to
      provoke thermal events when necessary, and
      the "OS provided default frequency" is "never":-)
      
      There is a proposal that ACPI 4.0 be updated to reflect
      common industry practice -- ie. no _TZP, no polling.
      
      The Linux kernel already follows this practice --
      thermal zones are not polled unless _TZP is present and non-zero.
      
      But thermal zone polling is useful as a workaround for systems
      which have ACPI thermal control, but have an issue preventing
      thermal events.  Indeed, some Linux distributions still
      set a non-zero thermal polling frequency for this reason.
      
      But rather than ask the user to write a polling frequency
      into all the /proc/acpi/thermal_zone/*/polling_frequency
      files, here we simply document and expose the already
      existing module parameter to do the same at system level,
      to simplify debugging those broken platforms.
      
      Note that thermal.tzp is a module-load time parameter only.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      730ff34d