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: Jeff Garzik <jgarzik@redhat.com>
Slab destructors were no longer supported after Christoph's
c59def9f22 change. They've been
BUGs for both slab and slub, and slob never supported them
either.
This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Need to check for special case "acpi_osi=!Linux" before handling the
general case "acpi_osi=!*", or it will have no effect.
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In Linux-2.6.22 we expanded the boot parameter osi=
so that it can enable and !enable an OSI string.
_OSI(Linux) is a special case because we know that there
are both systems that require it set, and systems
require that it _not_ to be set. In the long term it can't
be set, for the same reason _OS(Linux) can't be enabled --
it tends to confuse BIOS that are not properly
validated with Linux. Further, the semantics and version
information of _OSI(Linux) were never actually defined.
The kernel prints out a message if it sees _OSI(Linux)
requested, and there is a DMI workaround to invoke
"osi=Linux" automatically for existing systems that need it.
http://bugzilla.kernel.org/show_bug.cgi?id=7787
Signed-off-by: Len Brown <len.brown@intel.com>
Add __init to:
acpi_initialize_subsystem() (and un-export it)
acpi_os_initialize()
Add __initdata to:
acpi_osl_dmi_table[]
Signed-off-by: Len Brown <len.brown@intel.com>
_OSI("Linux") is like _OS("Linux"), it is ill-defined and
virtually no BIOS vendors test interaction with it.
As a result, it can do more damage than good because
it causes the BIOS to follow un-tested paths.
Recently, several machines have turned up that erroneously
test this string in a way which causes them to _not_ test other
compatibility strings, including the ZI9 and Toshiba.
So it appears that this bad code has made it into
a BIOS vendor's reference BIOS.
Linux has no choice but to stop advertising compatibility
with _OSI string "Linux" - as there are an unbounded
number of possible incompatibilities going forward.
But some BIOSes have already shipped which do use it
for things like conditionally re-enabling video on resume
from S3. (Too bad they didn't do that unconditionally)
Add special case code for _OSI(Linux)
Squawk to dmesg if _OSI(Linux) is requested
Add DMI list both to enable and disable _OSI(Linux)
But for now, keep the default enabled via
#define OSI_LINUX_ENABLED.
http://bugzilla.kernel.org/show_bug.cgi?id=7787
Signed-off-by: Len Brown <len.brown@intel.com>
The boot option "acpi_osi=" has always disabled Linux _OSI support,
thus disabling all OS Interface strings which are advertised
by Linux to the BIOS.
Now...
acpi_osi="string" adds the interface string, and
acpi_osi="!string" invalidates the pre-defined interface string
eg. acpi_osi="!Windows 2006"
would disable Linux's claim of Vista compatibility.
Signed-off-by: Len Brown <len.brown@intel.com>
HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.
Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.
In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.
To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel stack
overflow.
First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.
http://bugzilla.kernel.org/show_bug.cgi?id=5534http://bugzilla.kernel.org/show_bug.cgi?id=8385
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.
Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use NULL for pointers
drivers/acpi/osl.c:208:10: warning: Using plain integer as NULL pointer
drivers/acpi/tables/tbxface.c:411:49: warning: Using plain integer as NULL pointer
drivers/acpi/processor_core.c:1008:10: warning: Using plain integer as NULL pointer
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Len Brown <len.brown@intel.com>
cosmetic only
Make "module name" actually match the file name.
Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care.
Fix indentation where Lindent did get confused.
Signed-off-by: Len Brown <len.brown@intel.com>
Resources described by the FADT aren't really a good fit for the
ACPI motherboard driver.
The motherboard driver cares about PNP0C01 and PNP0C02 devices and
their resources.
The FADT describes some resources used by the ACPI core. Often, they
are also described by by the _CRS of a motherboard device, but I think
it's better to reserve them specifically in the ACPI osl.c because
(a) the motherboard driver is optional and ACPI uses the resources even
if the driver is absent, and (b) I want to remove the ACPI motherboard
driver because it's mostly redundant with the PNP system.c driver.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.
For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.
To make this work, an extra flag is introduced into the management side of the
work_struct. This governs auto-release of the structure upon execution.
Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function. This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated.. This is a
problem if the auxiliary data is taken away (as done by the last patch).
However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems. But then the work function must itself release the
work_struct by calling work_release().
In most cases, automatic release is fine, so this is the default. Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: David Howells <dhowells@redhat.com>
Jeff Garzik
Len Brown
Paul Mundt
Adrian Bunk
Len Brown
Alexey Starikovskiy
Randy Dunlap
Bjorn Helgaas
David Howells