On Wed, Jan 24, 2018 at 10:14:39PM -0800, Wang Dongsheng wrote: > 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.
Hi Wang People are working on an ACPI description for MDIO. There have been some discussion about this in the thread "Armada 7k/8k PP2 ACPI support". If i'm reading your patch correctly, you are looking for the MDIO reset in the MAC node. This is wrong. It is an MDIO property, so should be in the MDIO device. Once we have figured out how to represent MDIO busses in ACPI, the reset will be in the MDIO node. I don't recommend you do this. It will mean your device is different to every other device using ACPI for MDIO. A better approach is to take part in the discussion about how to represent MDIO busses and PHYs in ACPI. Andrew