linux.git/drivers/acpi/scan.c, branch v4.13

ACPI: EC: Fix regression related to wrong ECDT initialization order

2017-08-17T18:52:19+00:00

Commit 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle
EC events) introduced acpi_ec_ecdt_start(), but that function is
invoked before acpi_ec_query_init(), which is too early.  This causes
the kernel to crash if an EC event occurs after boot, when ec_query_wq
is not valid:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000102
 ...
 Workqueue: events acpi_ec_event_handler
 task: ffff9f539790dac0 task.stack: ffffb437c0e10000
 RIP: 0010:__queue_work+0x32/0x430

Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start()
is actually a no-op in the majority of cases.  However, commit
c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
caused the probing of the DSDT EC as the "boot EC" to be skipped when
the ECDT EC is valid and uncovered the bug.

Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init()
in acpi_ec_init().

Link: https://jira01.devtools.intel.com/browse/LCK-4348
Fixes: 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events)
Fixes: c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
Reported-by: Wang Wendy 
Tested-by: Feng Chenzhou 
Signed-off-by: Lv Zheng 
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki

Merge tag 'devprop-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2017-07-10T22:23:45+00:00

Pull device properties framework updates from Rafael Wysocki:
 "These mostly rearrange the device properties core code and add a few
  helper functions to it as a foundation for future work.

  Specifics:

   - Rearrange the core device properties code by moving the code
     specific to each supported platform configuration framework (ACPI,
     DT and build-in) into a separate file (Sakari Ailus).

   - Add helper functions for accessing device properties in a
     firmware-agnostic way (Sakari Ailus, Kieran Bingham)"

* tag 'devprop-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  device property: Add fwnode_graph_get_port_parent
  device property: Add FW type agnostic fwnode_graph_get_remote_node
  device property: Introduce fwnode_device_is_available()
  device property: Move fwnode graph ops to firmware specific locations
  device property: Move FW type specific functionality to FW specific files
  ACPI: Constify argument to acpi_device_is_present()

Merge branches 'acpi-spcr', 'acpi-osi', 'acpi-bus', 'acpi-scan' and 'acpi-misc'

2017-07-10T20:46:21+00:00

* acpi-spcr:
  ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
  ACPI: SPCR: Use access width to determine mmio usage

* acpi-osi:
  ACPI / osi: Make local function acpi_osi_dmi_linux() static

* acpi-bus:
  ACPI / bus: handle ACPI hotplug schedule errors completely

* acpi-scan:
  ACPI / scan: Indicate to platform when hot remove returns busy

* acpi-misc:
  ACPI / DPTF: constify attribute_group structures
  ACPI / LPSS: constify attribute_group structures
  ACPI: BGRT: constify attribute_group structures
  ACPI / power: constify attribute_group structures

ACPI / scan: Indicate to platform when hot remove returns busy

2017-07-04T19:45:41+00:00

In hotplug logic, it always indicates non-specific failure to
platform through _OST when handing ACPI hot-remove event failed. Then
platform terminates the hot-remove process but it can not identify
the reason.

Base on current hot-remove code, there have two situations that it
returns busy:

 - OSPM try to offline an individual device, but the device offline
   function returns "busy".

 - When the ejection event is applied to an "not offlined yet"
   container.  OSPM sends a kobject change event to userspace and
   returns "busy".

Both of them will returns -EBUSY to ACPI device hotplug function.
Then, the hotplug function indicates non-specific failure to platform
just like for any other error, e.g. -ENODEV or -EIO.

The benefit to the platform for identifying the OS "busy" state is
that it can use a different approach to handle the "busy" instead of
simply terminating the hot-remove operation for an unknown reason.
For example, the platform can wait for a while and then re-trigger
hot-remove.

Signed-off-by: "Lee, Chun-Yi" 
Reviewed-by: Andy Shevchenko 
[ rjw: Changelog massage ]
Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-pm'

2017-07-03T12:23:09+00:00

* acpi-pm:
  PM / core: Drop run_wake flag from struct dev_pm_info
  PCI / PM: Simplify device wakeup settings code
  PCI / PM: Drop pme_interrupt flag from struct pci_dev
  ACPI / PM: Consolidate device wakeup settings code
  ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags
  ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems
  platform: x86: intel-hid: Wake up the system from suspend-to-idle
  platform: x86: intel-vbtn: Wake up the system from suspend-to-idle
  ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
  platform/x86: Add driver for ACPI INT0002 Virtual GPIO device
  PCI / PM: Restore PME Enable if skipping wakeup setup
  PM / sleep: Print timing information if debug is enabled
  ACPI / PM: Clean up device wakeup enable/disable code
  ACPI / PM: Change log level of wakeup-related message
  USB / PCI / PM: Allow the PCI core to do the resume cleanup
  ACPI / PM: Run wakeup notify handlers synchronously

Conflicts:
	drivers/base/power/main.c

ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags

2017-06-27T23:52:15+00:00

The run_wake flag in struct acpi_device_wakeup_flags stores the
information on whether or not the device can generate wakeup
signals at run time, but in ACPI that really is equivalent to
being able to generate wakeup signals at all.

In fact, run_wake will always be set after successful executeion of
acpi_setup_gpe_for_wake(), but if that fails, the device will not be
able to use a wakeup GPE at all, so it won't be able to wake up the
systems from sleep states too.  Hence, run_wake actually means that
the device is capable of triggering wakeup and so it is equivalent
to the valid flag.

For this reason, drop run_wake from struct acpi_device_wakeup_flags
and make sure that the valid flag is only set if
acpi_setup_gpe_for_wake() has been successful.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Acked-by: Bjorn Helgaas

device property: Move FW type specific functionality to FW specific files

2017-06-22T00:55:34+00:00

The device and fwnode property API supports Devicetree, ACPI and pset
properties. The implementation of this functionality for each firmware
type was embedded in the fwnode property core. Move it out to firmware
type specific locations, making it easier to maintain.

Depends-on: ("of: Move OF property and graph API from base.c to property.c")
Signed-off-by: Sakari Ailus 
Reviewed-by: Mika Westerberg 
Acked-by: Rob Herring 
Signed-off-by: Rafael J. Wysocki

ACPI: Constify argument to acpi_device_is_present()

2017-06-22T00:55:34+00:00

This will be needed in constifying the fwnode API.

The side effects the function had have been moved to the callers.

Signed-off-by: Sakari Ailus 
Reviewed-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki

ACPI / scan: Fix enumeration for special SPI and I2C devices

2017-06-21T21:14:55+00:00

Commit f406270bf73d ("ACPI / scan: Set the visited flag for all
enumerated devices") caused that two group of special SPI or I2C
devices do not enumerate. SPI and I2C devices are expected to be
enumerated by the SPI and I2C subsystems but change caused that
acpi_bus_attach() marks those devices with acpi_device_set_enumerated().

First group of devices are matched using Device Tree compatible property
with special _HID "PRP0001". Those devices have matched scan handler,
acpi_scan_attach_handler() retuns 1 and acpi_bus_attach() marks them
with acpi_device_set_enumerated().

Second group of devices without valid _HID such as "LNXVIDEO" have
device->pnp.type.platform_id set to zero and change again marks them
with acpi_device_set_enumerated().

Fix this by flagging the SPI and I2C devices during struct acpi_device
object initialization time and let the code in acpi_bus_attach() to go
through the device_attach() and acpi_default_enumeration() path for all
SPI and I2C devices.

Fixes: f406270bf73d (ACPI / scan: Set the visited flag for all enumerated devices)
Signed-off-by: Jarkko Nikula 
Acked-by: Mika Westerberg 
Cc: 4.11+  # 4.11+
Signed-off-by: Rafael J. Wysocki

ACPI/IORT: Ignore all errors except EPROBE_DEFER

2017-05-30T09:31:32+00:00

While deferring the probe of IOMMU masters, xlate and
add_device callbacks called from iort_iommu_configure
can pass back error values like -ENODEV, which means
the IOMMU cannot be connected with that master for real
reasons. Before the IOMMU probe deferral, all such errors
were ignored. Now all those errors are propagated back,
killing the master's probe for such errors. Instead ignore
all the errors except EPROBE_DEFER, which is the only one
of concern and let the master work without IOMMU, thus
restoring the old behavior. Also make explicit that
acpi_dma_configure handles only -EPROBE_DEFER from
iort_iommu_configure.

Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error")
Signed-off-by: Sricharan R 
Signed-off-by: Joerg Roedel