dpaa2: pass the child up when memac_mdio reads an ivar

[yarshure_gmail.com]

Summary

memac_mdio_read_ivar() handed its own device to the parent instead of the
child being asked about. Its children are PHYs it added itself from firmware
nodes, so a request for one of them has to reach our own parent still naming
that PHY; answering with the MDIO bus's own ivars hands out the bus's ACPI
handle rather than the PHY's.

Until the previous commit this was mostly latent. BUS_GET_PROPERTY reached
the child's ivars directly, and memac_mdio(4) synthesises those as a struct
acpi_device, so "phy-channel" and "compatible" were still found and the PHY
attached. What the bug did corrupt is acpi_get_handle() on a PHY, which
memacphy_acpi_attach() uses to read _UID -- it got the MDIO bus's _UID
instead of the PHY's. Now that a property is looked up through the child's
own ACPI handle, the same bug loses "phy-channel" as well and attach fails
with ENXIO, so fix it here.

dpaa2_mc_acpi_read_ivar() forwards the same way for the same reason, and says
so in a comment.

Depends on D60064

Test Plan

arm64 GENERIC, and a variant with dpaa2 as a module.

On a SolidRun CEX7 (NXP LX2160A) under UEFI/ACPI, with a property now looked
up through the child's own ACPI handle (previous commit), the RGMII port's
PHY attaches:

memac_mdio_acpi0 <Freescale XGMAC MDIO Bus> _HID=NXP0006 handle=\_SB_.MDI0
  memacphy_acpi0 <MEMAC PHY (acpi)>
    miibus0 <MII bus>
      atphy0 <Atheros F1 10/100/1000 PHY> oui=0xc82e model=0x7 at phyno=1

Without it memacphy_acpi(4) is handed the MDIO bus's handle, reads the bus's
_UID and _DSD instead of the PHY's, finds no "phy-channel" and fails attach
with ENXIO.