From: Andrew Lunn <andrew@lunn.ch>
To: Timur Tabi <timur@codeaurora.org>
Cc: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>,
hpuranik@codeaurora.org, yu.zheng@hxt-semitech.com,
netdev@vger.kernel.org, Marcin Wojtas <mw@semihalf.com>
Subject: Re: [RFC] net: qcom/emac: mdiobus-dev fwnode should point to emac-adev
Date: Thu, 25 Jan 2018 16:59:56 +0100 [thread overview]
Message-ID: <20180125155956.GB7026@lunn.ch> (raw)
In-Reply-To: <25f763a5-ffcf-c668-105f-6534555c3595@codeaurora.org>
On Thu, Jan 25, 2018 at 09:40:45AM -0600, Timur Tabi wrote:
> On 01/25/2018 08:15 AM, Andrew Lunn wrote:
> >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.
>
> Just FYI, the MDIO controller in the EMAC is integrated, so I can't see us
> creating a separate Device Tree or ACPI node/property for it. Granted, the
> code in emac-phy.c:emac_phy_config() that registers the MDIO bus is
> convoluted, so maybe there's an opportunity to replace some/all of that code
> with some generic API. Maybe we need something like acpi_mdiobus_register()
> like we have of_mdiobus_register().
Hi Timur
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().
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.
Andrew
next prev parent reply other threads:[~2018-01-25 16:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 6:14 [RFC] net: qcom/emac: mdiobus-dev fwnode should point to emac-adev Wang Dongsheng
2018-01-25 14:15 ` Andrew Lunn
2018-01-25 15:40 ` Timur Tabi
2018-01-25 15:59 ` Andrew Lunn [this message]
2018-01-25 16:05 ` Timur Tabi
2018-01-26 7:20 ` Wang, Dongsheng
2018-01-30 13:21 ` Andrew Lunn
2018-01-25 14:36 ` Timur Tabi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180125155956.GB7026@lunn.ch \
--to=andrew@lunn.ch \
--cc=dongsheng.wang@hxt-semitech.com \
--cc=hpuranik@codeaurora.org \
--cc=mw@semihalf.com \
--cc=netdev@vger.kernel.org \
--cc=timur@codeaurora.org \
--cc=yu.zheng@hxt-semitech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).