mdiobus always try to get a GPIO "reset" consumer, based on ACPI
the GPIO should be described in emac-adev _DSD or _CRS.
ACPI uses mido common API to register, however mdio->dev->fwnode is not
pointing to any adev. So the "reset" consumer can never be found.
OF has done this by using an of_mdiobus_register. The mdiobus get emac
of_node and go through the of_node to find a GPIO "reset" consumer.
Not sure, ACPI needs to add the same API for mdio just like OF because
mdio isn't a real entity in ACPI. So I think there isn't any work in
ACPI, the mac driver needs to take adev to mdiobus when mido-bus is
registering.
Signed-off-by: Wang Dongsheng <dongsheng.w...@hxt-semitech.com>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 53dbf1e..69171d5 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -117,6 +117,10 @@ int emac_phy_config(struct platform_device *pdev, struct
emac_adapter *adpt)
if (has_acpi_companion(&pdev->dev)) {
u32 phy_addr;
+ struct fwnode_handle *fwnode;
+
+ fwnode = acpi_fwnode_handle(ACPI_COMPANION(&pdev->dev));
+ mii_bus->dev.fwnode = fwnode;
ret = mdiobus_register(mii_bus);
if (ret) {
--
2.7.4
