From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Subject: Re: [RFC] net: qcom/emac: mdiobus-dev fwnode should point to emac-adev Date: Thu, 25 Jan 2018 10:05:02 -0600 Message-ID: <17532535-1f9d-0394-b1f9-ce8de3e0d834@codeaurora.org> References: <1516860879-15798-1-git-send-email-dongsheng.wang@hxt-semitech.com> <20180125141515.GB16547@lunn.ch> <25f763a5-ffcf-c668-105f-6534555c3595@codeaurora.org> <20180125155956.GB7026@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Wang Dongsheng , hpuranik@codeaurora.org, yu.zheng@hxt-semitech.com, netdev@vger.kernel.org, Marcin Wojtas To: Andrew Lunn Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:52734 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbeAYQFE (ORCPT ); Thu, 25 Jan 2018 11:05:04 -0500 In-Reply-To: <20180125155956.GB7026@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 01/25/2018 09:59 AM, Andrew Lunn wrote: > I expect we will implement something like acpi_mdiobus_register(), and > it will take a pointer to an ACPI node. And maybe on top of > of_mdiobus_register() and of_mdiobus_register() we will add a > device_mdiobus_register(). Makes sense. If you remember, please CC me on any patches. > What i'm trying to avoid is drivers ending up with different ACPI > bindings. If you don't want to add an ACPI node/property then no > problems, just don't expect to be able to use any of the optional > features of the MDIO core, like the GPIOs for reset. Well, if a new binding is created, we will update our ACPI tables and drivers use it. But we may need to keep the legacy code in emac-phy.c for backwards compatibility with older firmware. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.