Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 3月, 2009 1 次提交
  3. 17 1月, 2009 1 次提交
  5. 08 11月, 2008 1 次提交
  7. 07 11月, 2008 1 次提交
    • K
      ACPI: struct device - replace bus_id with dev_name(), dev_set_name() · 0794469d
      由 Kay Sievers 提交于 
      This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".

To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.

We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.

We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NLen Brown <len.brown@intel.com>
      0794469d
  9. 23 10月, 2008 1 次提交
  11. 17 10月, 2008 1 次提交
  13. 11 10月, 2008 2 次提交
  15. 22 7月, 2008 1 次提交
  17. 18 7月, 2008 1 次提交
  19. 12 6月, 2008 1 次提交
  21. 29 4月, 2008 4 次提交
  23. 28 4月, 2008 1 次提交
  25. 09 4月, 2008 1 次提交
  27. 13 3月, 2008 1 次提交
  29. 02 2月, 2008 5 次提交
  31. 07 12月, 2007 1 次提交
  33. 10 10月, 2007 1 次提交
    • J
      drivers/firmware: const-ify DMI API and internals · 1855256c
      由 Jeff Garzik 提交于 
      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: NJeff Garzik <jgarzik@redhat.com>
      1855256c
  35. 06 9月, 2007 1 次提交
  37. 05 9月, 2007 1 次提交
    • L
      ACPI: thermal: use round_jiffies when thermal zone polling is enabled · 21bc42ab
      由 Len Brown 提交于 
      Properly functioning systems do not use thermal zone polling,
they use event-based notification.

However, some users enable periodic thermal zone polling
to work around bugs on their platforms, and at least one
platform exists with a real _TZP that requests polling.

While thermal zone polling (_TZP) is specified in units to 0.1 seconds,
it actually has a maximum granularity of 1 second.  Thus, we can safely
round up the _TZP timeout to occur on the next 1-second boundary.
This will batch it with other 1-second-granularity timers in the
system and thus potentially extend processor idle duration.

Note that the same timer is used both for _TZP
and for passive processor thermal throttling.
We can not round up the timeout when it is used
for passive thermal throttling.

Also, we can not make this a deferrable timer,
as temperature is just as relevant during idle
as it is during non-idle.
Signed-off-by: NLen Brown <len.brown@intel.com>
      21bc42ab
  39. 25 8月, 2007 1 次提交
  41. 24 8月, 2007 2 次提交
    • L
      ACPI: Schedule /proc/acpi/event for removal · 14e04fb3
      由 Len Brown 提交于 
      Schedule /proc/acpi/event for removal in 6 months.

Re-name acpi_bus_generate_event() to acpi_bus_generate_proc_event()
to make sure there is no confusion that it is for /proc/acpi/event only.

Add CONFIG_ACPI_PROC_EVENT to allow removal of /proc/acpi/event.
There is no functional change if CONFIG_ACPI_PROC_EVENT=y
Signed-off-by: NLen Brown <len.brown@intel.com>
      14e04fb3
    • Z
      ACPI: don't duplicate input events on netlink · 962ce8ca
      由 Zhang Rui 提交于 
      The previous events patch added a netlink event for every
user of the legacy /proc/acpi/event interface.

However, some users of /proc/acpi/event are really input events,
and they already report their events via the input layer.

Introduce a new interface, acpi_bus_generate_netlink_event(),
which is explicitly called by devices that want to repoprt
events via netlink.  This allows the input-like events
to opt-out of generating netlink events.  In summary:

events that are sent via netlink:
	ac/battery/sbs
	thermal
	processor
	thinkpad_acpi dock/bay

events that are sent via input layer:
	button
	video hotkey
	thinkpad_acpi hotkey
	asus_acpi/asus-laptop hotkey
	sonypi/sonylaptop
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      962ce8ca
  43. 21 8月, 2007 1 次提交
  45. 15 8月, 2007 2 次提交
  47. 12 8月, 2007 6 次提交
    • L
      ACPI: thermal: add DMI hooks to handle AOpen's broken Award BIOS · 0b5bfa1c
      由 Len Brown 提交于 
      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: NLen Brown <len.brown@intel.com>
      0b5bfa1c
    • L
      ACPI: thermal: create "thermal.act=" to disable or override active trip point · f8707ec9
      由 Len Brown 提交于 
      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: NLen Brown <len.brown@intel.com>
      f8707ec9
    • L
      ACPI: thermal: create "thermal.nocrt" to disable critical actions · f5487145
      由 Len Brown 提交于 
      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: NLen Brown <len.brown@intel.com>
      f5487145
    • L
      ACPI: thermal: create "thermal.psv=" to override passive trip points · a70cdc52
      由 Len Brown 提交于 
      "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: NLen Brown <len.brown@intel.com>
      a70cdc52
    • L
      ACPI: thermal: expose "thermal.tzp=" to set global polling frequency · 730ff34d
      由 Len Brown 提交于 
      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: NLen Brown <len.brown@intel.com>
      730ff34d
    • L
      ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support · 72b33ef8
      由 Len Brown 提交于 
      "thermal.off=1" disables all ACPI thermal support at boot time.

CONFIG_ACPI_THERMAL=n can do this at build time.
"# rmmod thermal" can do this at run time,
as long as thermal is built as a module.

WARNING: On some systems, disabling ACPI thermal support
will cause the system to run hotter and reduce the
lifetime of the hardware.
Signed-off-by: NLen Brown <len.brown@intel.com>
      72b33ef8
  49. 24 7月, 2007 1 次提交