acpi: read a child's properties through its ACPI handle

[yarshure_gmail.com]

Summary

bus_generic_get_property() forwards a request up the tree with the original
child, so acpi_bus_get_prop() can be reached with a child that is not its
own. It read that child's ivars as a struct acpi_device, which only holds
where the intervening bus went out of its way to make them one -- dpaa2_mc(4)
and memac_mdio(4) synthesise acpi_device ivars precisely so that forwarding
works. An ACPI-described i2c bus keeps its own layout, and a miibus PHY has
no ACPI ivars at all; reading either as ours faults.

Reach the child through acpi_get_handle() instead. That goes through
BUS_READ_IVAR, which every bus answers for its own children or declines --
and declining leaves the handle NULL, which is the right answer here.

Split the _DSD handling into evaluation, lookup and value conversion so both
paths can share it: acpi_device_get_prop() keeps using the copy cached in
struct acpi_device, while the handle-based path evaluates _DSD per call and
frees it again. A property whose value would be returned by reference into
that package -- a sub-package -- is therefore not served that way; nothing in
tree asks for one.

Also check that _DSD itself is a package of at least two elements before
indexing it, and take the address of the handle in the ACPI_TYPE_LOCAL_REFERENCE
case rather than copying from the namespace node it points at.

Depends on D60062

Test Plan

arm64 GENERIC, and a variant with iicbus/dpaa2 as modules.

On a SolidRun CEX7 (NXP LX2160A) under UEFI/ACPI:

• dpaa2_mc(4)'s DPMAC children and memac_mdio(4)'s PHY children still read their properties and attach. Those buses forward with their own child but synthesise its ivars as a struct acpi_device, and both paths keep working through the handle instead.

• pca954x(4), once it attaches on an ACPI-enumerated i2c bus (earlier in this series), calls device_has_property(). Its ivars are a struct acpi_iicbus_ivars; with the request forwarded to acpi0 carrying that child and the ivars read as ours, that faulted:
  
  pca954x0: <PCA9547 I2C Mux> at addr 0x77 on iicbus0 Fatal data abort panic: vm_fault failed pca954x_attach() at pca954x_attach+0xac
  
  With this change the property is reported absent instead, and the following commits make it actually readable.

• a miibus PHY has no ACPI ivars at all; acpi_get_handle() answers NULL for it and the property is reported absent rather than read out of miibus's ivars.