Commit Graph

441 Commits

Author SHA1 Message Date
Suthikulpanit, Suravee 26095a01d3 ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.

To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.

    acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
    # cat /sys/devices/platform/AMDI0600:00/modalias
    acpi:AMDI0600:010601:

where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code

Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.

    static const struct acpi_device_id ahci_acpi_match[] = {
        { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
        {},
    };

In this case, the corresponded entry in modules.alias file would be:

    alias acpi*:010601:* ahci_platform

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
Rafael J. Wysocki e193cd15ae Merge branch 'acpi-cca'
* acpi-cca:
  ufs: fix TRUE and FALSE re-define build error
  megaraid_sas: fix TRUE and FALSE re-define build error
  amd-xgbe: Unify coherency checking logic with device_dma_is_coherent()
  crypto: ccp - Unify coherency checking logic with device_dma_is_coherent()
  device property: Introduces device_dma_is_coherent()
  arm64 : Introduce support for ACPI _CCA object
  ACPI / scan: Parse _CCA and setup device coherency
2015-06-19 01:17:35 +02:00
Rafael J. Wysocki 4def8a360f Merge branch 'acpi-video'
* acpi-video: (38 commits)
  ACPI / video: Make acpi_video_unregister_backlight() private
  acpi-video-detect: Remove old API
  toshiba-acpi: Port to new backlight interface selection API
  thinkpad-acpi: Port to new backlight interface selection API
  sony-laptop: Port to new backlight interface selection API
  samsung-laptop: Port to new backlight interface selection API
  msi-wmi: Port to new backlight interface selection API
  msi-laptop: Port to new backlight interface selection API
  intel-oaktrail: Port to new backlight interface selection API
  ideapad-laptop: Port to new backlight interface selection API
  fujitsu-laptop: Port to new backlight interface selection API
  eeepc-laptop: Port to new backlight interface selection API
  dell-wmi: Port to new backlight interface selection API
  dell-laptop: Port to new backlight interface selection API
  compal-laptop: Port to new backlight interface selection API
  asus-wmi: Port to new backlight interface selection API
  asus-laptop: Port to new backlight interface selection API
  apple-gmux: Port to new backlight interface selection API
  acer-wmi: Port to new backlight interface selection API
  ACPI / video: Fix acpi_video _register vs _unregister_backlight race
  ...
2015-06-19 01:17:26 +02:00
Rafael J. Wysocki 4f1fd900c2 Merge branches 'acpi-pm', 'acpi-apei', 'acpi-osl' and 'acpi-pci'
* acpi-pm:
  ACPI / PM: Add missing pm_generic_complete() invocation
  ACPI / PM: Turn power resources on and off in the right order during resume
  ACPI / PM: Rework device power management to follow ACPI 6
  ACPI / PM: Drop stale comment from acpi_power_transition()

* acpi-apei:
  GHES: Make NMI handler have a single reader
  GHES: Elliminate double-loop in the NMI handler
  GHES: Panic right after detection
  GHES: Carve out the panic functionality
  GHES: Carve out error queueing in a separate function

* acpi-osl:
  ACPI / osl: use same type for acpi_predefined_names values as in definition

* acpi-pci:
  ACPI / PCI: remove stale list_head in struct acpi_prt_entry
2015-06-19 01:16:21 +02:00
Hans de Goede adc8bb8e0f acpi-video-detect: Move acpi_is_video_device() to acpi/scan.c
This allows video_detect.c to be build as a module, this is a preparation
patch for the backlight interface selection logic cleanup.

Note this commit also causes acpi_is_video_device() to always be build
indepedent of CONFIG_ACPI_VIDEO, as there is no reason to make its
building depend on CONFIG_ACPI_VIDEO.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-19 01:10:26 +02:00
Suthikulpanit, Suravee d056267483 ACPI / scan: Parse _CCA and setup device coherency
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.

The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops() when creating each device enumerated in DSDT
during ACPI scan.

This patch also introduces acpi_dma_is_coherent(), which provides
an interface for device drivers to check the coherency information
similarly to the of_dma_is_coherent().

Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15 14:40:48 +02:00
Mathias Krause 0519ade718 ACPI / scan: constify ACPI device ids
Make the button ACPI device ID array static const. Safes us a little bit
of code.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15 14:31:02 +02:00
Rafael J. Wysocki ee89209402 ACPI / property: Define a symbol for PRP0001
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001
string.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
2015-05-22 23:57:14 +02:00
Rafael J. Wysocki 20dacb71ad ACPI / PM: Rework device power management to follow ACPI 6
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-16 01:55:35 +02:00
Rafael J. Wysocki 7d284352f9 ACPI / scan: Add a scan handler for PRP0001
If the special PRP0001 device ID is present in the given device's list
of ACPI/PNP IDs and the device has a valid "compatible" property in
the _DSD, it should be enumerated using the default mechanism,
unless some scan handlers match the IDs preceding PRP0001 in the
device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
matching the IDs following PRP0001 in that list should be attached
to the device.

To make that happen, define a scan handler that will match PRP0001
and trigger the default enumeration for the matching devices if the
"compatible" property is present for them.

Since that requires the check for platform_id and device->handler
to be removed from acpi_default_enumeration(), move the fallback
invocation of acpi_default_enumeration() to acpi_bus_attach()
(after it's checked if there's a matching ACPI driver for the
device), which is a better place to call it, and do the platform_id
check in there too (device->handler is guaranteed to be unset at
the point where the function is looking for a matching ACPI driver).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
2015-04-24 02:18:01 +02:00
Rafael J. Wysocki 4c533c801d ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
acpi_scan_is_offline() may be called under the physical_node_lock
lock of the given device object's parent, so prevent lockdep from
complaining about that by annotating that instance with
SINGLE_DEPTH_NESTING.

Fixes: caa73ea158 (ACPI / hotplug / driver core: Handle containers in a special way)
Reported-and-tested-by: Xie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-24 02:16:03 +02:00
Rafael J. Wysocki 5f2e3274e5 ACPI / scan: Fix NULL pointer dereference in acpi_companion_match()
Commit e1acdeb0e7 "ACPI / scan: Simplify acpi_match_device()"
introduced code that may lead to a NULL pointer dereference when
trying to unlock a mutex.  Fix that.

Fixes: e1acdeb0e7 "ACPI / scan: Simplify acpi_match_device()"
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-13 21:35:51 +02:00
Rafael J. Wysocki 8765c5ba19 ACPI / scan: Rework modalias creation when "compatible" is present
Currently, the ACPI modalias creation covers two mutually exclusive
cases: If the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs and the "compatible" property is present in _DSD, the
created modalias will follow the OF rules of modalias creation.
Otherwise, ACPI rules are used.

However, that is not really desirable, because the presence of PRP0001
in the list of device IDs generally does not preclude using other
ACPI/PNP IDs with that device and those other IDs may be of higher
priority.  In those cases, the other IDs should take preference over
PRP0001 and therefore they also should be present in the modalias.

For this reason, rework the modalias creation for ACPI so that it
shows both the ACPI-style and OF-style modalias strings if the
device has a non-empty list of ACPI/PNP IDs (other than PRP0001)
and a valid "compatible" property at the same time.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-13 00:29:36 +02:00
Rafael J. Wysocki 2b9c698efa ACPI / scan: Take the PRP0001 position in the list of IDs into account
If the special PRP0001 device ID is present in a device's _CID list,
it should not prevent any ACPI/PNP IDs preceding it in the device's
list of identifiers from being matched first.  That is, only if none
of the IDs preceding PRP0001 in the device's PNP/ACPI IDs list
matches the IDs recognized by the driver, the driver's list of
"compatible" IDs should be matched against the device's "compatible"
property, if present.

In addition to that, drivers can provide both acpi_match_table and
of_match_table at the same time and the of_compatible matching
should be used in that case too if PRP0001 is present in the
device's list of identifiers.

To make that happen, rework acpi_driver_match_device() to do the
"compatible" property check in addition to matching the driver's
list of ACPI IDs against the device's one.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10 16:07:51 +02:00
Rafael J. Wysocki e1acdeb0e7 ACPI / scan: Simplify acpi_match_device()
Redefine acpi_companion_match() to return an ACPI device object
pointer instead of a bool and use it to remove some redundant code
from acpi_match_device().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10 16:07:38 +02:00
Rafael J. Wysocki 54fe9ce385 ACPI / scan: Generalize of_compatible matching
Redefine the function used for matching the device's "compatible"
property against a given list of "compatible" strings to take
a pointer to that list instead of a driver object pointer to
make it more general.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10 16:07:30 +02:00
Aaron Lu fd9caef4e2 ACPI / scan: fix fixed event handler return value
The fixed event handler should return a value that is either 0 or 1
meanning if the event is handled or not, instead of an acpi_status to
mean if the handler runs well or not.

Suggested-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-18 02:06:49 +01:00
Ken Xue 92082a8886 ACPI: add AMD ACPI2Platform device support for x86 system
This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART, GPIO found on AMD CZ and
later chipsets. It based on example intel LPSS. Now, it can
support AMD I2C, UART and GPIO.

Signed-off-by: Ken Xue <Ken.Xue@amd.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06 15:42:16 +01:00
Rafael J. Wysocki 1b1f3e1699 ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it.  Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.

To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.

Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-05 22:49:52 +01:00
Rafael J. Wysocki be10f60d29 Merge branches 'acpi-scan', 'acpi-utils' and 'acpi-pm'
* acpi-scan:
  ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUG

* acpi-utils:
  ACPI / utils: Drop error messages from acpi_evaluate_reference()

* acpi-pm:
  ACPI / PM: Do not disable wakeup GPEs that have not been enabled
2014-12-18 18:42:56 +01:00
Rafael J. Wysocki 80167a24a2 ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUG
Two _DEP-related failure messages are printed as dev_err() which is
unnecessary and annoying.  Use dev_dbg() to print them.

While at it, one of the messages should actually say it is related
to _DEP, so modify it to that effect.

Fixes: 40e7fcb192 (ACPI: Add _DEP support to fix battery issue on Asus T100TA)
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-12 22:48:44 +01:00
Rafael J. Wysocki 69bad361e6 Merge branches 'acpi-scan', 'acpi-pm', 'acpi-lpss' and 'acpi-processor'
* acpi-scan:
  ACPI: Add _DEP support to fix battery issue on Asus T100TA

* acpi-pm:
  ACPI / sleep: Drain outstanding events after disabling multiple GPEs
  ACPI / PM: Fixed a typo in a comment

* acpi-lpss:
  dmaengine: dw: enable runtime PM
  ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
  ACPI / LPSS: allow to use specific PM domain during ->probe()
  ACPI / LPSS: add all LPSS devices to the specific power domain

* acpi-processor:
  ACPI / cpuidle: avoid assigning signed errno to acpi_status
  ACPI / processor: remove unused variabled from acpi_processor_power structure
  ACPI / processor: Update the comments in processor.h
2014-12-08 19:52:16 +01:00
Lan Tianyu 40e7fcb192 ACPI: Add _DEP support to fix battery issue on Asus T100TA
ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate
device objects that OSPM should assign a higher priority in start
ordering due to future operation region accesses.

On Asus T100TA, ACPI battery info are read from a I2C slave device via
I2C operation region. Before I2C operation region handler is installed,
battery _STA always returns 0. There is a _DEP method of designating
start order under battery device node.

This patch is to implement _DEP feature to fix battery issue on the
Asus T100TA.  Introducing acpi_dep_list and adding dep_unmet count
in struct acpi_device. During ACPI namespace scan, create struct
acpi_dep_data for a valid pair of master (device pointed to by _DEP)/
slave(device with _DEP), record master's and slave's ACPI handle in
it and put it into acpi_dep_list. The dep_unmet count will increase
by one if there is a device under its _DEP. Driver's probe() should
return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C
operation region handler is installed, remove all struct acpi_dep_data
on the acpi_dep_list whose master is pointed to I2C host controller
and decrease slave's dep_unmet. When dep_unmet decreases to 0, all
_DEP conditions are met and then do acpi_bus_attach() for the device
in order to resolve battery _STA issue on the Asus T100TA.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011
Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Tested-by: Adam Williamson <adamw@happyassassin.net>
Tested-by: Michael Shigorin <shigorin@gmail.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 01:04:55 +01:00
Rafael J. Wysocki 8a0662d9ed Driver core: Unified interface for firmware node properties
Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).

The following functions are provided:

fwnode_property_present()
fwnode_property_read_u8()
fwnode_property_read_u16()
fwnode_property_read_u32()
fwnode_property_read_u64()
fwnode_property_read_string()
fwnode_property_read_u8_array()
fwnode_property_read_u16_array()
fwnode_property_read_u32_array()
fwnode_property_read_u64_array()
fwnode_property_read_string_array()

in analogy with the corresponding functions for struct device added
previously.  For all of them, the first argument is a pointer to struct
fwnode_handle (new type) that allows a device description object
(depending on what platform firmware interface is in use) to be
obtained.

Add a new macro device_for_each_child_node() for iterating over the
children of the device description object associated with a given
device and a new function device_get_child_node_count() returning the
number of a given device's child nodes.

The interface covers both ACPI and Device Trees.

Suggested-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 21:58:23 +01:00
Mika Westerberg 733e625139 ACPI: Allow drivers to match using Device Tree compatible property
We have lots of existing Device Tree enabled drivers and allocating
separate _HID for each is not feasible. Instead we allocate special _HID
"PRP0001" that means that the match should be done using Device Tree
compatible property using driver's .of_match_table instead if the driver
is missing .acpi_match_table.

If there is a need to distinguish from where the device is enumerated
(DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev).

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 21:58:21 +01:00
Mika Westerberg ffdcd955c3 ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.

ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.

In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.

If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:

	Name (_DSD, Package () {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
			Package () {"name1", <VALUE1>},
			Package () {"name2", <VALUE2>},
			...
		}
	})

The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].

We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.

The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.

[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 21:58:21 +01:00
Mika Westerberg 52870786ff ACPI: Use ACPI companion to match only the first physical device
Commit 6ab3430129 ("mfd: Add ACPI support") made the MFD subdevices
share the parent MFD ACPI companion if no _HID/_CID is specified for
the subdevice in mfd_cell description. However, since all the subdevices
share the ACPI companion, the match and modalias generation logic started
to use the ACPI companion as well resulting this:

  # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
  acpi:INT33D1:PNP0C50:

instead of the expected one

  # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
  platform:HID-SENSOR-200041

In other words the subdevice modalias is overwritten by the one taken from
ACPI companion. This causes udev not to load the driver anymore.

It is useful to be able to share the ACPI companion so that MFD subdevices
(and possibly other devices as well) can access the ACPI resources even if
they do not have ACPI representation in the namespace themselves.

An example where this is used is Minnowboard LPC driver that creates GPIO
as a subdevice among other things. Without the ACPI companion gpiolib is
not able to lookup the corresponding GPIO controller from ACPI GpioIo
resource.

To fix this, restrict the match and modalias logic to be limited to the
first (primary) physical device associated with the given ACPI comapnion.
The secondary devices will still be able to access the ACPI companion,
but they will be matched in a different way.

Fixes: 6ab3430129 (mfd: Add ACPI support)
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-27 18:41:46 +01:00
Linus Torvalds 1c45d9a920 ACPI and power management updates for 3.18-rc2
- Fix for a recent PCI power management change that overlooked
    the fact that some IRQ chips might not be able to configure
    PCIe PME for system wakeup from Lucas Stach.
 
  - Fix for a bug introduced in 3.17 where acpi_device_wakeup()
    is called with a wrong ordering of arguments from Zhang Rui.
 
  - A bunch of intel_pstate driver fixes (all -stable candidates)
    from Dirk Brandewie, Gabriele Mazzotta and Pali Rohár.
 
  - Fixes for a rather long-standing problem with the OOM killer
    and the freezer that frozen processes killed by the OOM do
    not actually release any memory until they are thawed, so
    OOM-killing them is rather pointless, with a couple of
    cleanups on top (Michal Hocko, Cong Wang, Rafael J Wysocki).
 
  - ACPICA update to upstream release 20140926, inlcuding mostly
    cleanups reducing differences between the upstream ACPICA and
    the kernel code, tools changes (acpidump, acpiexec) and
    support for the _DDN object (Bob Moore, Lv Zheng).
 
  - New PM QoS class for memory bandwidth from Tomeu Vizoso.
 
  - Default 32-bit DMA mask for platform devices enumerated by ACPI
    (this change is mostly needed for some drivers development in
    progress targeted at 3.19) from Heikki Krogerus.
 
  - ACPI EC driver cleanups, mostly related to debugging, from
    Lv Zheng.
 
  - cpufreq-dt driver updates from Thomas Petazzoni.
 
  - powernv cpuidle driver update from Preeti U Murthy.
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJUSjZFAAoJEILEb/54YlRxyfIP/irc/f7DDb0mElF755ANtSXp
 CTVIQSn6uZ2P//ElQO0+nckZSo39jrBkHVu11vDxmVt2PJE2VBgNjHJLyf1boaPI
 9aR5kzVmL6jzJ9wA3gYqr91uCVegY1KDFx2KrAlrNomrlc2xtTGf6F17I4tI9qHL
 pgc8jhJZ1swn4wL0qnqffLsmx3Hoq3uIO5PNAXD+qUSgm5+8zZwLLlvnrM8upOO4
 cHTvxh+ZwXrak4RO4NciYZPKJQAD47MTcJCDR/bg7MKxeiJPrzLrR+WrbCYr5md1
 iSiVThZDZnnYTiDLPiemcXoe3jpG2bigXncxJVRDJ7MBOO7ZX7mppwdNnMaNM5kN
 92kvLOy269NSS2SFJ0N/B6Xr1jQ0HEdwj7erl4xJIkobKRuvN9fYyVWkoL9i3sj4
 OQ7fqhXoEON9CW0KwC5FRAswIungB//o5OjN7VlNKTBKfPdWAjgVQOyeeZ+gSoQo
 9tbR/QEEEcHn8fiQpBM9cQw2NL0Rx1ZzHXs7dB0U6ynfG5Drge4OTTwl/Gm4mavB
 8Tv3ji26VvQdFr+It2SsijjjjjzVIsdK5iUpSHYo876u4l20CEH3gSpVA/jNhgH6
 HaAN5DYIot4Qq5ifjDydRT6WGIyxsVMk3SqehjF47TDaX4l1FbSYWGVyKxfjnQs3
 2rWJ3yuDjH28Cfmi0MO0
 =4Q8f
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI and power management updates from Rafael Wysocki:
 "This is material that didn't make it to my 3.18-rc1 pull request for
  various reasons, mostly related to timing and travel (LinuxCon EU /
  LPC) plus a couple of fixes for recent bugs.

  The only really new thing here is the PM QoS class for memory
  bandwidth, but it is simple enough and users of it will be added in
  the next cycle.  One major change in behavior is that platform devices
  enumerated by ACPI will use 32-bit DMA mask by default.  Also included
  is an ACPICA update to a new upstream release, but that's mostly
  cleanups, changes in tools and similar.  The rest is fixes and
  cleanups mostly.

  Specifics:

   - Fix for a recent PCI power management change that overlooked the
     fact that some IRQ chips might not be able to configure PCIe PME
     for system wakeup from Lucas Stach.

   - Fix for a bug introduced in 3.17 where acpi_device_wakeup() is
     called with a wrong ordering of arguments from Zhang Rui.

   - A bunch of intel_pstate driver fixes (all -stable candidates) from
     Dirk Brandewie, Gabriele Mazzotta and Pali Rohár.

   - Fixes for a rather long-standing problem with the OOM killer and
     the freezer that frozen processes killed by the OOM do not actually
     release any memory until they are thawed, so OOM-killing them is
     rather pointless, with a couple of cleanups on top (Michal Hocko,
     Cong Wang, Rafael J Wysocki).

   - ACPICA update to upstream release 20140926, inlcuding mostly
     cleanups reducing differences between the upstream ACPICA and the
     kernel code, tools changes (acpidump, acpiexec) and support for the
     _DDN object (Bob Moore, Lv Zheng).

   - New PM QoS class for memory bandwidth from Tomeu Vizoso.

   - Default 32-bit DMA mask for platform devices enumerated by ACPI
     (this change is mostly needed for some drivers development in
     progress targeted at 3.19) from Heikki Krogerus.

   - ACPI EC driver cleanups, mostly related to debugging, from Lv
     Zheng.

   - cpufreq-dt driver updates from Thomas Petazzoni.

   - powernv cpuidle driver update from Preeti U Murthy"

* tag 'pm+acpi-3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (34 commits)
  intel_pstate: Correct BYT VID values.
  intel_pstate: Fix BYT frequency reporting
  intel_pstate: Don't lose sysfs settings during cpu offline
  cpufreq: intel_pstate: Reflect current no_turbo state correctly
  cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
  cpufreq: intel_pstate: Fix setting max_perf_pct in performance policy
  PCI / PM: handle failure to enable wakeup on PCIe PME
  ACPI: invoke acpi_device_wakeup() with correct parameters
  PM / freezer: Clean up code after recent fixes
  PM: convert do_each_thread to for_each_process_thread
  OOM, PM: OOM killed task shouldn't escape PM suspend
  freezer: remove obsolete comments in __thaw_task()
  freezer: Do not freeze tasks killed by OOM killer
  ACPI / platform: provide default DMA mask
  cpuidle: powernv: Populate cpuidle state details by querying the device-tree
  cpufreq: cpufreq-dt: adjust message related to regulators
  cpufreq: cpufreq-dt: extend with platform_data
  cpufreq: allow driver-specific data
  ACPI / EC: Cleanup coding style.
  ACPI / EC: Refine event/query debugging messages.
  ...
2014-10-24 11:29:31 -07:00
Linus Torvalds 8264fce6de Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal management updates from Zhang Rui:
 "Sorry that I missed the merge window as there is a bug found in the
  last minute, and I have to fix it and wait for the code to be tested
  in linux-next tree for a few days.  Now the buggy patch has been
  dropped entirely from my next branch.  Thus I hope those changes can
  still be merged in 3.18-rc2 as most of them are platform thermal
  driver changes.

  Specifics:

   - introduce ACPI INT340X thermal drivers.

     Newer laptops and tablets may have thermal sensors and other
     devices with thermal control capabilities that are exposed for the
     OS to use via the ACPI INT340x device objects.  Several drivers are
     introduced to expose the temperature information and cooling
     ability from these objects to user-space via the normal thermal
     framework.

     From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui.

   - introduce a new thermal governor, which just uses a hysteresis to
     switch abruptly on/off a cooling device.  This governor can be used
     to control certain fan devices that can not be throttled but just
     switched on or off.  From: Peter Feuerer.

   - introduce support for some new thermal interrupt functions on
     i.MX6SX, in IMX thermal driver.  From: Anson, Huang.

   - introduce tracing support on thermal framework.  From: Punit
     Agrawal.

   - small fixes in OF thermal and thermal step_wise governor"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits)
  Thermal: int340x thermal: select ACPI fan driver
  Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs
  Thermal: int340x_thermal: expose acpi thermal relationship tables
  Thermal: introduce int3403 thermal driver
  Thermal: introduce INT3402 thermal driver
  Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h
  ACPI / Fan: support INT3404 thermal device
  ACPI / Fan: add ACPI 4.0 style fan support
  ACPI / fan: convert to platform driver
  ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant
  ACPI / fan: remove no need check for device pointer
  ACPI / fan: remove unused macro
  Thermal: int3400 thermal: register to thermal framework
  Thermal: int3400 thermal: add capability to detect supporting UUIDs
  Thermal: introduce int3400 thermal driver
  ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package()
  ACPI: make acpi_create_platform_device() an external API
  thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
  ACPI: introduce ACPI int340x thermal scan handler
  thermal: Added Bang-bang thermal governor
  ...
2014-10-24 11:21:43 -07:00
Lv Zheng 2f8572344e ACPICA: Events: Reduce source code difference for the ACPI_EVENT_FLAG_HANDLE renaming.
This patch is partial linuxized result of the following ACPICA commit:
  ACPICA commit: a73b66c6aa1846d055bb6390d9c9b9902f7d804d
  Subject: Add "has handler" flag to event/gpe status interfaces.
  This change adds a new flag, ACPI_EVENT_FLAGS_HAS_HANDLER to the
  acpi_get_event_status and acpi_get_gpe_status external interfaces. It
  is set if the event/gpe currently has a handler associated with it.
This patch contains the code to rename ACPI_EVENT_FLAG_HANDLE to
ACPI_EVENT_FLAG_HAS_HANDLER, and the corresponding updates of its usages.

Link: https://github.com/acpica/acpica/commit/a73b66c6
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 00:39:40 +02:00
Rafael J. Wysocki 9ef5a306ef Merge branches 'acpi-hotplug', 'acpi-scan', 'acpi-lpss', 'acpi-gpio' and 'acpi-video'
* acpi-hotplug:
  ACPI / hotplug: Generate online uevents for ACPI containers

* acpi-scan:
  ACPI / scan: Correct error return value of create_modalias()

* acpi-lpss:
  ACPI / platform / LPSS: disable async suspend/resume of LPSS devices

* acpi-gpio:
  gpio / ACPI: Use pin index and bit length
  ACPICA: Update to GPIO region handler interface.

* acpi-video:
  ACPI / video: disable native backlight for ThinkPad X201s
2014-09-25 22:59:30 +02:00
Mika Westerberg 98d28d0e59 ACPI / scan: Correct error return value of create_modalias()
There is a typo, it should be negative -errno instead.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-22 14:11:43 +02:00
Rafael J. Wysocki 8ab17fc92e ACPI / hotplug: Generate online uevents for ACPI containers
Commit 46394fd01 (ACPI / hotplug: Move container-specific code out of
the core) removed the generation of "online" uevents for containers,
because "add" uevents are now generated for them automatically when
container system devices are registered.  However, there are user
space tools that need to be notified when the container and all of
its children have been enumerated, which doesn't happen any more.

For this reason, add a mechanism allowing "online" uevents to be
generated for ACPI containers after enumerating the container along
with all of its children.

Fixes: 46394fd01 (ACPI / hotplug: Move container-specific code out of the core)
Reported-and-tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-21 02:58:18 +02:00
Zhang Rui 3230bbfce8 ACPI: introduce ACPI int340x thermal scan handler
Newer laptops and tablets that use ACPI may have thermal sensors and
other devices with thermal control capabilities outside the core CPU/SOC,
for thermal safety reasons.
They are exposed for the OS to use via
1) INT3400 ACPI device object as the master.
2) INT3401 ~ INT340B ACPI device objects as the slaves.

This patch introduces a scan handler to enumerate the INT3400
ACPI device object to platform bus, and prevent its slaves
from being enumerated before the controller driver being probed.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2014-09-11 23:35:15 +08:00
Yasuaki Ishimatsu a383b68d9f ACPI / scan: not cache _SUN value in struct acpi_device_pnp
The _SUN device indentification object is not guaranteed to return
the same value every time it is executed, so we should not cache its
return value, but rather execute it every time as needed.  If it is
cached, an incorrect stale value may be used in some situations.

This issue was exposed by commit 202317a573 (ACPI / scan: Add
acpi_device objects for all device nodes in the namespace).  Fix it
by avoiding to cache the return value of _SUN.

Fixes: 202317a573 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-03 22:41:14 +02:00
Lan Tianyu 236105db63 ACPI: Run fixed event device notifications in process context
Currently, notify callbacks for fixed button events are run from
interrupt context.  That is not necessary and after commit 0bf6368ee8
(ACPI / button: Add ACPI Button event via netlink routine) it causes
netlink routines to be called from interrupt context which is not
correct.

Also, that is different from non-fixed device events (including
non-fixed button events) whose notify callbacks are all executed from
process context.

For the above reasons, make fixed button device notify callbacks run
in process context which will avoid the deadlock when using netlink
to report button events to user space.

Fixes: 0bf6368ee8 (ACPI / button: Add ACPI Button event via netlink routine)
Link: https://lkml.org/lkml/2014/8/21/606
Reported-by: Benjamin Block <bebl@mageta.org>
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Function names, subject and changelog.]
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-26 01:29:24 +02:00
Rafael J. Wysocki fc2e0a8326 ACPI / scan: Allow ACPI drivers to bind to PNP device objects
We generally don't allow ACPI drivers to bind to ACPI device objects
that companion "physical" device objects are created for to avoid
situations in which two different drivers may attempt to handle one
device at the same time.  Recent ACPI device enumeration rework
extended that approach to ACPI PNP devices by starting to use a scan
handler for enumerating them.  However, we previously allowed ACPI
drivers to bind to ACPI device objects with existing PNP device
companions and changing that led to functional regressions on some
systems.

For this reason, add a special check for PNP devices in
acpi_device_probe() so that ACPI drivers can bind to ACPI device
objects having existing PNP device companions as before.

Fixes: eec15edbb0 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971
Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-26 01:29:21 +02:00
Rafael J. Wysocki 21c806d9b1 Merge branches 'acpi-processor', 'acpi-hotplug' and 'acpi-battery'
* acpi-processor:
  ACPI / processor: Make acpi_cpu_soft_notify() process CPU FROZEN events

* acpi-hotplug:
  ACPI / hotplug: Check scan handlers in acpi_scan_hot_remove()

* acpi-battery:
  ACPI / battery: Fix warning message in acpi_battery_get_state()
2014-08-10 16:23:33 +02:00
Tang Chen dee1592638 ACPI / hotplug: Check scan handlers in acpi_scan_hot_remove()
When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach
is not set.  In acpi_scan_attach_handler(), the acpi_device->handler will
not be initialized.

In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL.
If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel
will panic.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
 IP: [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
 PGD 0
 Oops: 0000 [#1] SMP
 Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E)
 CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G            E 3.16.0-rc7--3.16-rc7-tangchen+ #20
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
 Workqueue: kacpi_hotplug acpi_hotplug_work_fn
 task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000
 RIP: 0010:[<ffffffff813e318f>]  [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
 RSP: 0000:ffff880018257da8  EFLAGS: 00000246
 RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246
 RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0
 R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003
 R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
 Stack:
  00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58
  ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00
  0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480
 Call Trace:
  [<ffffffff813dc31d>] acpi_hotplug_work_fn+0x1e/0x29
  [<ffffffff8108eefb>] process_one_work+0x17b/0x460
  [<ffffffff8108f69d>] worker_thread+0x11d/0x5b0
  [<ffffffff8108f580>] ? rescuer_thread+0x3a0/0x3a0
  [<ffffffff81096811>] kthread+0xe1/0x100
  [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0
  [<ffffffff816cc6bc>] ret_from_fork+0x7c/0xb0
  [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0

This patch fixes this problem by checking if acpi_device->handler is NULL
in acpi_scan_hot_remove().

Fixes: d22ddcbc4f (ACPI / hotplug: Add demand_offline hotplug profile flag)
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-07 21:16:23 +02:00
Rafael J. Wysocki e5e0243e36 Merge branches 'acpi-video' and 'acpi-hotplug'
* acpi-video:
  ACPI: move models with win8 brightness problems from win8 blacklist to use_native_backlight
  ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress

* acpi-hotplug:
  ACPI / hotplug / PCI: Fix sparse non static symbol warning
  ACPI / hotplug: Simplify acpi_set_hp_context()
  ACPI / hotplug / PCI: Eliminate acpiphp_dev_to_bridge()
2014-07-27 23:55:54 +02:00
Rafael J. Wysocki bd9b2f9aff ACPI / scan: No implicit wake notification for buttons
The ACPI device enumeration code in Linux assumes that buttons always
are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them
which leads to undesirable side effects.  Namely, that function sets
up implicit device wake notification mechanism for a given GPE if
there is no handler method in the ACPI namespace, which from the
ACPICA's perspective means that there always is a way to handle
that GPE if enabled.  However, we don't handle wake notify events
for buttons, so if there are no handler methods for their GPEs in
the namespace, enabling a button GPE at run time leads to a GPE
storm in some cases (the GPE triggers, ACPICA carries out the
implicit wake notification for it which isn't handled, so the
GPE triggers again and so on).

To prevent that from happening use acpi_mark_gpe_for_wake()
instead of acpi_setup_gpe_for_wake() for buttons which will cause
ACPICA to only enable button GPEs if there are handler methods for
the in the namespace.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-23 23:13:19 +02:00
Rafael J. Wysocki ba574dc856 ACPI / hotplug: Simplify acpi_set_hp_context()
Since all of the acpi_set_hp_context() callers pass at least one NULL
function pointer and one caller passes NULL function pointers only
to it, drop function pointer arguments from acpi_set_hp_context()
and make the callers initialize the function pointers in struct
acpi_hotplug_context by themselves before passing it to
acpi_set_hp_context().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-07-16 01:45:40 +02:00
Rafael J. Wysocki b04c58b1ed Merge branch 'acpi-enumeration'
* acpi-enumeration:
  ACPI / scan: use platform bus type by default for _HID enumeration
  ACPI / scan: always register ACPI LPSS scan handler
  ACPI / scan: always register memory hotplug scan handler
  ACPI / scan: always register container scan handler
  ACPI / scan: Change the meaning of missing .attach() in scan handlers
  ACPI / scan: introduce platform_id device PNP type flag
  ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list
  ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule
  ACPI / PNP: use device ID list for PNPACPI device enumeration
  ACPI / scan: .match() callback for ACPI scan handlers
2014-06-03 23:12:20 +02:00
Rafael J. Wysocki a392f7d4af Merge branch 'acpi-pm'
* acpi-pm:
  ACPI / PM: Export rest of the subsys PM callbacks
  ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
  ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state
  ACPI / PM: Export acpi_target_system_state() to modules
2014-06-03 23:11:42 +02:00
Zhang Rui 48459340b9 ACPI / scan: use platform bus type by default for _HID enumeration
Because of the growing demand for enumerating ACPI devices to
platform bus, change the code to enumerate ACPI device objects to
platform bus by default.  Namely, create platform devices for the
ACPI device objects that
 1. Have pnp.type.platform_id set (device objects with _HID currently).
 2. Do not have a scan handler attached.
 3. Are not SPI/I2C slave devices (that should be enumerated to the
    appropriate buses bus by their parent).

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog, rebase and code cleanup]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 16:04:37 +02:00
Rafael J. Wysocki d34afa9de4 ACPI / scan: Change the meaning of missing .attach() in scan handlers
Currently, some scan handlers can be compiled out entirely, which
leaves the device objects they normally attach to without a scan
handler.  This isn't a problem as long as we don't have any default
enumeration mechanism that applies to all devices without a scan
handler.  However, if such a default enumeration is added, it still
should not be applied to devices that are normally attached to by
scan handlers, because that may result in creating "physical" device
objects of a wrong type for them.

Since we are going to create platform device objects for all ACPI
device objects with pnp.type.platform_id set by default, clear
pnp.type.platform_id where there is a matching scan handler without
an .attach() callback and otherwise simply treat that scan handler
as though the .attach() callback was present but always returned 0.

This will allow us to compile out scan handler callbacks and leave
the device ID lists used by them so as to prevent creating platform
device objects for the matching ACPI devices.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 16:04:36 +02:00
Rafael J. Wysocki 549e68455c ACPI / scan: introduce platform_id device PNP type flag
Only certain types of ACPI device objects can be enumerated as
platform devices, so in order to distinguish them from the others
introduce a new ACPI device PNP type flag, platform_id, and set it
for devices with a valid _HID to start with.

This change is based on a Zhang Rui's prototype.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 16:04:36 +02:00
Zhang Rui eec15edbb0 ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently.  Namely, if an ACPI device
object
 1. Has a _CRS method,
 2. Has an identification of
    "three capital characters followed by four hex digits",
 3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it).  This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.

However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them).  As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices.  That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.

To address that problem it is better to enumerate _HID devices
as platform devices by default.  To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.

The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers.  Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 16:04:35 +02:00
Rafael J. Wysocki aca0a4eb4e ACPI / scan: .match() callback for ACPI scan handlers
Introduce a .match() callback for ACPI scan handlers to allow them to
use more elaborate matching algorithms if necessary.  That is needed
for the upcoming PNP scan handler in particular.

This change is based on a Zhang Rui's prototype.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 16:04:35 +02:00
Rafael J. Wysocki f25c0ae2b4 ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
Rework the ACPI PM domain's PM callbacks to avoid resuming devices
during system suspend (in order to modify their wakeup settings etc.)
if that isn't necessary.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 13:22:48 +02:00