linux.git/drivers/acpi, branch v3.10-rc7

ACPI / LPSS: Power up LPSS devices during enumeration

2013-06-19T22:49:06+00:00

Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without
_PSC during initialization) introduced a regression on some systems
with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
need to be powered up during initialization, but their device objects
in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
resources).

To work around this problem, make the ACPI LPSS driver power up
devices it knows about by using a new helper function
acpi_device_fix_up_power() that does all of the necessary
sanity checks and calls acpi_dev_pm_explicit_set() to put the
device into D0.

Reported-and-tested-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix error code path for power resources initialization

2013-06-19T22:47:55+00:00

Commit 781d737 (ACPI: Drop power resources driver) introduced a
bug in the power resources initialization error code path causing
a NULL pointer to be referenced in acpi_release_power_resource()
if there's an error triggering a jump to the 'err' label in
acpi_add_power_resource().  This happens because the list_node
field of struct acpi_power_resource has not been initialized yet
at this point and doing a list_del() on it is a bad idea.

To prevent this problem from occuring, initialize the list_node
field of struct acpi_power_resource upfront.

Reported-by: Mika Westerberg 
Tested-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki 
Cc: 3.9+ 
Acked-by: Yasuaki Ishimatsu 
Reviewed-by: Mika Westerberg

ACPI / dock: Take ACPI scan lock in write_undock()

2013-06-19T21:56:30+00:00

Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
called under acpi_scan_lock, but currently the following scenario
violating that requirement is possible:

 write_undock()
  handle_eject_request()
   hotplug_dock_devices()
    dock_remove_acpi_device()
     acpi_bus_trim()

Fix that by making write_undock() acquire acpi_scan_lock before
calling handle_eject_request() as appropriate (begin_undock() is
under the lock too in analogy with acpi_dock_deferred_cb()).

Signed-off-by: Rafael J. Wysocki 
Cc: 3.9+ 
Acked-by: Toshi Kani

ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources

2013-06-19T21:55:59+00:00

acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).

With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:

	ACPI: IRQ 6 override to edge, high
	ACPI: IRQ 7 override to edge, high
	ACPI: IRQ 7 override to edge, high
	ACPI: IRQ 13 override to edge, high

Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:

	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00

The _CSR method for INT33C2 (and INT33C3) device returns following
resource:

	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
	{
		0x00000007,
	}

which states that this is supposed to be level triggered, active low,
shared IRQ instead.

Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.

While we are there, correct pr_warning() to print the right triggering
value.

This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).

[rjw: Changelog]
Signed-off-by: Mika Westerberg 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Do not bind to device objects with a scan handler

2013-06-10T11:00:29+00:00

With the introduction of ACPI scan handlers, ACPI device objects
with an ACPI scan handler attached to them must not be bound to
by ACPI drivers any more.  Unfortunately, however, the ACPI video
driver attempts to do just that if there is a _ROM ACPI control
method defined under a device object with an ACPI scan handler.

Prevent that from happening by making the video driver's "add"
routine check if the device object already has an ACPI scan handler
attached to it and return an error code in that case.

That is not sufficient, though, because acpi_bus_driver_init() would
then clear the device object's driver_data that may be set by its
scan handler, so for the fix to work acpi_bus_driver_init() has to be
modified to leave driver_data as is on errors.

References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Bisected-and-tested-by: Dmitry S. Demin 
Reported-and-tested-by: Jason Cassell 
Tracked-down-by: Aaron Lu 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Aaron Lu

Revert "ACPI / scan: do not match drivers against objects having scan handlers"

2013-06-08T01:33:12+00:00

Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects
having scan handlers") introduced a boot regression on Tony's ia64 HP
rx2600.  Tony says:

  "It panics with the message:

   Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel

   [...] my problem comes from arch/ia64/hp/common/sba_iommu.c
   where the code in sba_init() says:

        acpi_bus_register_driver(&acpi_sba_ioc_driver);
        if (!ioc_list) {

   but because of this change we never managed to call ioc_init()
   so ioc_list doesn't get set up, and we die."

Revert it to avoid this breakage and we'll fix the problem it attempted
to address later.

Reported-by: Tony Luck 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Linus Torvalds

Merge branch 'acpi-fixes'

2013-06-07T10:35:23+00:00

* acpi-fixes:
  ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization
  ACPI / scan: do not match drivers against objects having scan handlers
  ACPI / APEI: fix error return code in ghes_probe()
  ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6
  ACPI / video: ignore BIOS initial backlight value for HP m4
  x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup()

ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization

2013-06-07T10:33:57+00:00

Commit b378549 (ACPI / PM: Do not power manage devices in unknown
initial states) added code to force devices without _PSC, but having
_PS0 defined in the ACPI namespace, into ACPI power state D0 by
executing _PS0 for them.  That turned out to break Toshiba P870-303,
however, so revert that code.

References: https://bugzilla.kernel.org/show_bug.cgi?id=58201
Reported-and-tested-by: Jerome Cantenot 
Tracked-down-by: Lan Tianyu 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki

ACPI / scan: do not match drivers against objects having scan handlers

2013-06-05T11:11:47+00:00

With the introduction of ACPI scan handlers, an ACPI device object
with an ACPI scan handler attached to it must not be bound to an ACPI
driver any more.  Therefore it doesn't make sense to match those
ACPI device objects against a newly registered ACPI driver in
acpi_bus_match(), so make that function return 0 if the device
object passed to it has an ACPI scan handler attached.

This also addresses a regression related to a broken ACPI table in
the BIOS, where it has defined a _ROM method under the PCI root
bridge object.  This causes the video module to treat that object
as a display controller device (since only display devices are
supposed to have a _ROM method defined according to the ACPI spec).
As a result, the ACPI video driver binds to the PCI root bridge
object and overwrites the previously assigned driver_data field of
it, causing subsequent calls to acpi_get_pci_dev() to fail.

[rjw: Subject and changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Reported-by: Jason Cassell 
Reported-and-bisected-by: Dmitry S. Demin 
Cc: 3.9+ 
Signed-off-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki

ACPI / APEI: fix error return code in ghes_probe()

2013-06-05T11:11:47+00:00

Fix to return a negative error code in the acpi_gsi_to_irq() and
request_irq() error handling case instead of 0, as done elsewhere
in this function.

Signed-off-by: Wei Yongjun 
Reviewed-by: Huang Ying 
Signed-off-by: Rafael J. Wysocki