From: Roger Quadros <rogerq@ti.com>
To: Andrew Lunn <andrew@lunn.ch>, Lars-Peter Clausen <lars@metafoo.de>
Cc: davem@davemloft.net, Florian Fainelli <f.fainelli@gmail.com>,
tony@atomide.com, nsekhar@ti.com, jsarha@ti.com,
netdev@vger.kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.
Date: Mon, 24 Apr 2017 12:04:14 +0300 [thread overview]
Message-ID: <551ee7a0-d153-3a36-e025-2c1f70f866b7@ti.com> (raw)
In-Reply-To: <20170423233553.GA23498@lunn.ch>
On 24/04/17 02:35, Andrew Lunn wrote:
> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote:
>> On 04/21/2017 03:15 PM, Roger Quadros wrote:
>>> diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
>>> new file mode 100644
>>> index 0000000..4ffbbac
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/mdio.txt
>>> @@ -0,0 +1,33 @@
>>> +Common MDIO bus properties.
>>> +
>>> +These are generic properties that can apply to any MDIO bus.
>>> +
>>> +Optional properties:
>>> +- reset-gpios: List of one or more GPIOs that control the RESET lines
>>> + of the PHYs on that MDIO bus.
>>> +- reset-delay-us: RESET pulse width in microseconds as per PHY datasheet.
>>> +
>>> +A list of child nodes, one per device on the bus is expected. These
>>> +should follow the generic phy.txt, or a device specific binding document.
>>> +
>>> +Example :
>>> +This example shows these optional properties, plus other properties
>>> +required for the TI Davinci MDIO driver.
>>> +
>>> + davinci_mdio: ethernet@0x5c030000 {
>>> + compatible = "ti,davinci_mdio";
>>> + reg = <0x5c030000 0x1000>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
>>> + reset-delay-us = <2>; /* PHY datasheet states 1us min */
>>
>> If this is the reset line of the PHY shouldn't it be a property of the PHY
>> node rather than of the MDIO controller node (which might have a reset on
>> its own)?
>>> +
>>> + ethphy0: ethernet-phy@1 {
>>> + reg = <1>;
>>> + };
>>> +
>>> + ethphy1: ethernet-phy@3 {
>>> + reg = <3>;
>>> + };
>
> Hi Lars-Peter
>
> We discussed this when the first proposal was made. There are two
> cases, to consider.
>
> 1) Here, one GPIO line resets all PHYs on the same MDIO bus. In this
> example, two PHYs.
>
> 2) There is one GPIO line per PHY. That is a separate case, and as you
> say, the reset line should probably be considered a PHY property, not
> an MDIO property. However, it can be messy, since in order to probe
> the MDIO bus, you probably need to take the PHY out of reset.
>
> Anyway, this patch addresses the first case, so should be accepted. If
> anybody wants to address the second case, they are free to do so.
Thanks for the explanation Andrew.
For the second case, even if the RESET GPIO property is specified
in the PHY node, the RESET *will* have to be done by the MDIO bus driver
else the PHY might not be probed at all.
Whether we need additional code to just to make the DT look prettier is
questionable and if required can come as a separate patch.
cheers,
-roger
next prev parent reply other threads:[~2017-04-24 9:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 8:33 [PATCH] net: davinci_mdio: add GPIO reset logic Roger Quadros
2017-04-05 15:03 ` Andrew Lunn
2017-04-06 9:15 ` Roger Quadros
2017-04-06 12:05 ` Andrew Lunn
2017-04-06 16:48 ` Roger Quadros
2017-04-08 13:55 ` David Miller
2017-04-08 15:10 ` Andrew Lunn
2017-04-08 15:18 ` Florian Fainelli
2017-04-10 7:52 ` Roger Quadros
2017-04-19 9:24 ` [PATCH] mdio_bus: Issue GPIO RESET to PHYs Roger Quadros
2017-04-19 11:39 ` Andrew Lunn
2017-04-19 11:56 ` Roger Quadros
2017-04-19 13:38 ` Andrew Lunn
2017-04-20 7:58 ` Roger Quadros
2017-04-20 8:39 ` [PATCH v2] " Roger Quadros
2017-04-20 13:13 ` Andrew Lunn
2017-04-20 13:56 ` Roger Quadros
2017-04-20 14:11 ` [PATCH v3 net-next] " Roger Quadros
2017-04-21 1:12 ` Andrew Lunn
2017-04-21 1:23 ` Florian Fainelli
2017-04-21 1:38 ` Andrew Lunn
2017-04-21 8:04 ` Roger Quadros
2017-04-21 13:15 ` [PATCH v4 " Roger Quadros
2017-04-21 13:31 ` Lars-Peter Clausen
2017-04-23 23:35 ` Andrew Lunn
2017-04-24 9:04 ` Roger Quadros [this message]
2017-04-24 16:32 ` Florian Fainelli
2017-04-25 16:22 ` Lars-Peter Clausen
2017-04-25 16:31 ` Florian Fainelli
2017-04-26 10:46 ` Roger Quadros
2017-04-26 12:27 ` Andrew Lunn
2017-04-26 10:43 ` Roger Quadros
2017-04-24 16:40 ` David Miller
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=551ee7a0-d153-3a36-e025-2c1f70f866b7@ti.com \
--to=rogerq@ti.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jsarha@ti.com \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=tony@atomide.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