pvpanic: handle missing _STA correctly

pvpanic was not properly detected when _STA was missing.

ACPI 6.0 April 2015, 6.3.7 _STA (Status)
  If a device object (including the processor object) does not have an
  _STA object, then OSPM assumes that all of the above bits are set
  (i.e., the device is present, enabled, shown in the UI, and
  functioning).

Not adhering to the specification made pvpanic dormant under QEMU 2.3.

The original patch used acpi_bus_get_status_handle, which was not
being exported, so module build blew up;  switch to acpi_bus_get_status
and use the status it populates.

Populated status is a bitfield so we can make the code self-documenting.
We do not check 'present' because 'enabled' has to be false in that case
by specification.  Older QEMUs set 0xff to status and newer ones do 0xb.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[dvhart@linux.intel.com: Merge acpi_bug_get_status fix to avoid bisect breakage]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

drivers/platform/x86/pvpanic.c

@@ -92,13 +92,13 @@ pvpanic_walk_resources(struct acpi_resource *res, void *context)
 
 static int pvpanic_add(struct acpi_device *device)
 {
-	acpi_status status;
-	u64 ret;
+	int ret;
 
-	status = acpi_evaluate_integer(device->handle, "_STA", NULL,
-				       &ret);
+	ret = acpi_bus_get_status(device);
+	if (ret < 0)
+		return ret;
 
-	if (ACPI_FAILURE(status) || (ret & 0x0B) != 0x0B)
+	if (!device->status.enabled || !device->status.functional)
 		return -ENODEV;
 
 	acpi_walk_resources(device->handle, METHOD_NAME__CRS,