commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced a regression that _OSI string setup fails.

There are 2 paths to setup _OSI string.

DMI:
acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
string to osi_setup_string

Boot command line:
acpi_osi_setup -> copy _OSI string to osi_setup_string

Later, acpi_osi_setup_late will be called to handle osi_setup_string.
If _OSI string is "Linux" or "!Linux", then the call path is,

acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
acpi_osi_setup -> copy _OSI string to osi_setup_string

This actually never installs _OSI string(acpi_install_interface not
called), but just copy the _OSI string to osi_setup_string.

This patch fixes the regression.
Reported-and-tested-by: NLukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch optimizes ACPI MMIO remappings by keeping track of the
remappings on a PAGE_SIZE granularity.

When an ioremap() occurs, the underlying infrastructure works on a 'page'
based granularity.  As such, an ioremap() request for 1 byte for example,
will end up mapping in an entire (PAGE_SIZE) page.  Huang Ying took
advantage of this in commit 15651291 by
checking if subsequent ioremap() requests reside within any of the list's
existing remappings still in place, and if so, incrementing a reference
count on the existing mapping as opposed to performing another ioremap().
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the simple locking introduced earlier for the ACPI MMIO
remappings list to an RCU based locking scheme.
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.

ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT.  If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.

By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped.  This solves BZ 18012.

ACPI "System Event" reference(s):
  ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
  3.8 "System Events", 5.6 "ACPI Event Programming Model".

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012

Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add remapping and unmapping interfaces for ACPI registers that are
backed by memory mapped I/O (MMIO).  These interfaces, along with
the MMIO remapping list, enable accesses of such registers from within
interrupt context.

ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure".
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

For memory mapped I/O (MMIO) remappings, add a list to maintain the
remappings and augment the corresponding mapping and unmapping interface
routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
dynamically add to, and delete from, the list.

The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
end up calling ioremap() when accessing MMIO.  This prevents use of these
methods within interrupt context (IRQ and/or NMI), since ioremap() may
block to allocate memory.  Maintaining a list of MMIO remappings enables
accesses to such areas from within interrupt context provided they have
been pre-mapped.
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The size used for I/O remapping MMIO read and write accesses has not
accounted for the basis of ACPI's Generic Address Structure (GAS)
'Register Bit Width' field which is bits, not bytes.  This patch
adjusts the ioremap() 'size' argument accordingly.

ACPI "Generic Register" reference:
  ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
  Structure".
Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Found by running make namespacecheck on linux-next
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux-2.6.22 initiated a dmesg complaint when it saw BIOS that invoked
OSI(Linux).  Linux-2.6.23 continued that complaint and started our
policy of ignoring the bogus BIOS request.

Past-time for Linux to label that complaint with FW_BUG.
Signed-off-by: NLen Brown <len.brown@intel.com>

This function is not OS-dependent and has been replaced by
acpi_hw_derive_pci_id, which is now in the ACPICA core code.  Local
implementations of acpi_os_derive_pci_id are no longer necessary and
are removed. ACPICA BZ 857.

http://www.acpica.org/bugzilla/show_bug.cgi?id=857Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Adds install/remove interfaces so that the host can dynamically
alter the global _OSI table. Also adds support for _OSI handlers.
Additional support: new debugger command (osi), and test support in
the acpiexec utility. Adds new file, utilities/utosi.c.
ACPICA bugzilla 836.

The Linux OSL _OSI code is also changed.
acpi_osi_setup can't call acpi_install/remove_interface because ACPICA
is not initialized yet at this early time.
So we just save the osi string in acpi_osi_setup and will handle it
later in a new function acpi_osi_setup_late.

http://www.acpica.org/bugzilla/show_bug.cgi?id=836Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com
Signed-off-by: NLen Brown <len.brown@intel.com>

Prototype in acpiosxf.h had the output value pointer as a (u32 *).
Should be a (u64 *).
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some minor improvements in error handling, but overall it was mostly dead
code.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently, during initialization ACPICA walks the entire ACPI
namespace in search of any device objects with assciated _PRW
methods.  All of the _PRW methods found are executed in the process
to extract the GPE information returned by them, so that the GPEs in
question can be marked as "able to wakeup" (more precisely, the
ACPI_GPE_CAN_WAKE flag is set for them).  The only purpose of this
exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
if there are _Lxx/_Exx methods associated with them.  However, it is
both costly and unnecessary, because the host OS has to execute the
_PRW methods anyway to check which devices can wake up the system
from sleep states.  Moreover, it then uses full information
returned by _PRW, including the GPE information, so it can take care
of disabling the GPEs if necessary.

Remove the code that walks the namespace and executes _PRW from
ACPICA and modify comments to reflect that change.  Make
acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
so that they don't cause spurious wakeup events to be signaled.
This not only reduces the complexity of the ACPICA initialization
code, but in some cases it should reduce the kernel boot time as
well.

Unfortunately, for this purpose we need a new ACPICA function,
acpi_gpe_can_wake(), to be called by the host OS in order to disable
the GPEs that can wake up the system and were previously enabled by
acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
should be disabled only once, because the initialization code enables
it only once, but it may be pointed to by _PRW for multiple devices
and that's why the additional function is necessary).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI works need to be executed on cpu0 and acpi/osl.c achieves this by
creating singlethread workqueue and then binding it to cpu0 from a
work which is quite unorthodox.  Make it create regular workqueues and
use queue_work_on() instead.  This is in preparation of concurrency
managed workqueue and the extra workers won't be a problem after it's
implemented.
Signed-off-by: NTejun Heo <tj@kernel.org>

When the user passes the kernel parameter acpi_enforce_resources=lax,
the ACPI resources are no longer protected, so a native driver can
make use of them. In that case, we do not want the asus_atk0110 to be
loaded. Unfortunately, this driver loads automatically due to its
MODULE_DEVICE_TABLE, so the user ends up with two drivers loaded for
the same device - this is bad.

So I suggest that we prevent the asus_atk0110 driver from loading if
acpi_enforce_resources=lax.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NLuca Tettamanti <kronos.it@gmail.com>
Cc: Len Brown <lenb@kernel.org>

By default, ACPI resource conflict messages are logged at level
KERN_ERR. This is a rather high level for a message that is more a
warning than an indication of a real kernel error. Also, KERN_ERR level
messages can appear over some boot splash screens, and this message is
not serious enough to warrant such treatment. Thus, the log level has
been reduced to KERN_WARNING.

[lenb changed to KERN_WARNING rather than all the way to KERN_INFO]

Also, cleanup message to use %pR resource printing format.
Signed-off-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

fixes a false alarm from lockdep, as acpi hotplug workqueue waits other
workqueues.
http://bugzilla.kernel.org/show_bug.cgi?id=14553
https://bugzilla.kernel.org/show_bug.cgi?id=15521

Original-patch-from: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

[Ss]ytem => [Ss]ystem
udpate => update
paramters => parameters
orginal => original
Signed-off-by: NThomas Weber <swirl@gmx.li>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_check_resource_conflict() doesn't change the resource
it operates on, so the res parameter can be marked const.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).

I propose to reword the message to:

ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver

which I think is more correct. Comments and suggestions welcome.

I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().

Reference: http://lkml.org/lkml/2008/11/6/448Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We had two functions, acpi_os_execute_deferred() and
acpi_os_execute_hp_deferred() that differed only in that the
latter did acpi_os_wait_events_complete(NULL) before executing
the deferred function.

This patch consolidates those two functions and uses a flag in
the struct acpi_os_dpc to determine whether to do the wait.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=13620

If the dynamic region is created and added to resource list over and over again,
it has the potential to be a memory leak by growing the list every time.

This patch fixes the memory leak, as below

1) add a new field "count" to struct acpi_res_list.

   When inserting, if the region(addr, len) is already in the resource
   list, we just increase "count", otherwise, the region is inserted
   with count=1.

   When deleting, the "count" is decreased, if it's decreased to 0,
   the region is deleted from the resource list.

   With "count", the region with same address and length can only be
   inserted to the resource list once, so prevent potential memory leak.

2) add a new function acpi_os_invalidate_address, which is called when
   region is deleted.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

On some machines, a software-initiated SMI causes corruption unless the
SMI runs on CPU 0.  An SMI can be initiated by any AML, but typically it's
done in GPE-related methods that are run via workqueues, so we can avoid
the known corruption cases by binding the workqueues to CPU 0.

References:
    http://bugzilla.kernel.org/show_bug.cgi?id=13751
    https://bugs.launchpad.net/bugs/157171
    https://bugs.launchpad.net/bugs/157691Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

we used to run the hotplug code in keventd_wq.
But when hot removing the ACPI battery device,
power_supply_unregister invokes flush_scheduled_work.
This causes a deadlock. i.e
1. When dock is unplugged, all the hotplug code is run on kevent_wq.
2. the hotplug code removes all the child devices of dock device.
3. removing the child device may invoke flush_scheduled_work
4. flush_scheduled_work waits until all the work on kevent_wq to be
   finished, while this will never be true because the hotplug code
   is running on keventd_wq...

Introduce a new workqueue for hotplug in this patch.
http://bugzilla.kernel.org/show_bug.cgi?id=13533Tested-by: NPaul Martin <pm@debian.org>
Tested-by: NVojtech Gondzala <vojtech.gondzala@gmail.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This counter may prove useful in debugging some
spurious interrupt issues seen in the field.
Signed-off-by: NLen Brown <len.brown@intel.com>

Enforce strict resource checking - disallowing access by native
drivers to IO ports and memory regions claimed by ACPI firmware.

The patch is mainly aimed to block native hwmon drivers from touching
monitoring chips that ACPI thinks it own.

If this causes a regression, boot with "acpi_enforce_resources=lax"
which was the previous default.

http://bugzilla.kernel.org/show_bug.cgi?id=12376
http://bugzilla.kernel.org/show_bug.cgi?id=12541Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Acked-by: NPavel Machek <pavel@suse.cz>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 5ec5d38a.
because it caused spurious dmesg warmings.
We'll implement the check for off-limit ports
in a more clever way in the future.

http://bugzilla.kernel.org/show_bug.cgi?id=12758Signed-off-by: NLen Brown <len.brown@intel.com>

early_acpi_os_unmap_memory() is an __init function, and
acpi_os_unmap_memory() is allowed to access an __init function
until acpi_gbl_permanent_mmap is set up.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

to prevent wrongly overwriting fixmap that still want to use.

ACPI used to rely on low mappings being all linearly mapped and
grew a habit: it never really unmapped certain kinds of tables
after use.

This can cause problems - for example the hypothetical case
when some spurious access still references it.

v2: remove prev_map and prev_size in __apci_map_table
v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
early_acpi_os_unmap_memory
v4: fix typo in one acpi_get_table_with_size calling
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing peaces here for the acpi subsystem.
Signed-off-by: NFrank Seidel <frank@f-seidel.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPICA exports acpi_os_validate_address() so the OS
can prevent BIOS AML from accessing specified addresses.

Start using this interface to prevent AML from accessing
some well known IO addresses that the OS "owns".
Signed-off-by: NLen Brown <len.brown@intel.com>

return_ACPI_STATUS is an internal acpica function, replace it with return.
acpi_gbl_permanent_mmap moved from acglobal.h to acpixf.h for external use
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.

So delete the black-list,
and stop soliciting user-feedback on the console.
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core.
So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...)
and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...)

We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see
-------------------------------------------------------------
commit 6468463a
Author: Len Brown <len.brown@intel.com>
Date:   Mon Jun 26 23:41:38 2006 -0400

    ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)
Signed-off-by: NLen Brown <len.brown@intel.com>
-------------------------------------------------------------
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

As of version 2.0, ACPI can return 64-bit integers.  The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.

lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The hotplug notification handler and drivers' notification handler all
run in one workqueue.  Before hotplug removes an acpi device, the
device driver's notification handler is already be recorded to run just
after global notification handler.  After hotplug notification handler
runs, acpica will notice a NULL notification handler and crash.

So now we run run hotplug in another workqueue and wait
for all acpi notication handlers finish.
This was found in battery hotplug, but actually all
hotplug can be affected.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>