On 08/12/2015 11:36 PM, David Daney wrote:

On 08/12/2015 08:23 AM, Catalin Marinas wrote:

quoted

On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote:

quoted

On 08/11/2015 11:49 AM, David Miller wrote:

quoted

From: David Daney <redacted>
Date: Mon, 10 Aug 2015 17:58:35 -0700

quoted

Change from v1:  Drop PHY binding part, use fwnode_property* APIs.

The first patch (1/2) rearranges the existing code a little with no
functional change to get ready for the second.  The second (2/2) does
the actual work of adding support to extract the needed information
from the ACPI tables.

Series applied.

Thank you very much.

quoted

In the future it might be better structured to try and get the OF
node, and if that fails then try and use the ACPI method to obtain
these values.

Our current approach, as you can see in the patch, is the opposite.
If ACPI
is being used, prefer that over the OF device tree.

You seem to be recommending precedence for OF.  It should be consistent
across all drivers/sub-systems, so do you really think that OF before
ACPI
is the way to go?

On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI
if both arm provided to the kernel (and it's a fair assumption given
that ACPI on ARM is still in the early days). You could also force ACPI
with acpi=force on the kernel cmd line and the arch code will not
unflatten the DT even if it is provided, therefore is_of_node(fwnode)
returning false.

Yes. on the other hand, if no DT is provided, will try ACPI even
if no acpi=force on the kernel cmd line.

quoted

I haven't looked at your driver in detail but something like AMD's
xgbe_probe() uses a single function for both DT and ACPI with
device_property_read_*() functions getting the information from the
correct place in either case. The ACPI vs DT precedence is handled by
the arch boot code, we never mix the two and confuse the drivers.

My long term plan is to create something like
firmware_get_mac_address(), that would encapsulate  of_get_mac_address()
and the ACPI equivalent.

Same for firmware_phy_find_device().

I'm very keen on seeing that happens :)

Thanks
Hanjun