libata: acpi: do _GTF only for devices that have ACPI handle

It doesn't make sense to evaluate _GTF for devices that do not have an
ACPI handle, that would cause a NULL handle param to pass to
acpi_evaluate_object, while a NULL handle means the root handle which
isn't what we want.

To avoid this, check ACPI handle before calling ata_dev_get_GTF. To
simplify the code a little bit, remove the unnecessary ata_dev_enabled
call by using ENABLED in ATA device iteration macro.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
libata: acpi: replace ata_dev_acpi_handle with ACPI_HANDLE when possible

When we know the ACPI handling for an ATA device is not disabled, we can
simply use ACPI_HANDLE instead of the ata_dev_acpi_handle call.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
libata: acpi: use struct acpi_device instead of acpi_handle

When we need to communicate with ACPI subsystem, the essential param is
the ACPI handle of the device. For ACPI APIs that take acpi_handle as
their param, the first thing they usually do is converting the acpi_handle
to struct acpi_device pointer. It has been this case for a long time.

With commit 7b1998116bbb "ACPI / driver core: Store an ACPI device
pointer in struct acpi_dev_node", we now have direct access to the ACPI
device pointer of a physical device. Together with some newly introduced
ACPI APIs like acpi_device_set_power that take struct acpi_device pointer
as param, there is no reason we still use the old ACPI APIs like
acpi_bus_set_power that takes acpi_handle as param and internally uses
acpi_bus_get_device to get the struct acpi_device pointer.

To make this happen, this patch changes function ata_dev_acpi_handle to
ata_dev_acpi_device, which servers the same purpose as before but return
an struct acpi_device pointer instead. As a result, the libata-zpodd
could also be simplified a little bit.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>