devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: "Sergei Shtylyov" <sergei.shtylyov@cogentembedded.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: grant.likely@linaro.org, robh+dt@kernel.org,
	devicetree@vger.kernel.org, f.fainelli@gmail.com,
	netdev@vger.kernel.org, frowand.list@gmail.com,
	pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linux-kernel@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
Date: Mon, 16 May 2016 11:51:27 +0300	[thread overview]
Message-ID: <57398A0F.8070708@ti.com> (raw)
In-Reply-To: <b9bcc192-f97b-304e-77b2-894c4528ddb6@cogentembedded.com>

On 13/05/16 22:36, Sergei Shtylyov wrote:
> Hello.
> 
> On 05/13/2016 12:07 PM, Roger Quadros wrote:
> 
> [...]
> 
>>>> +}
>>>> +EXPORT_SYMBOL(mdio_device_reset);
>>>> +
>>>>  /**
>>>>   * mdio_probe - probe an MDIO device
>>>>   * @dev: device to probe
>>>> @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev
>>>>      struct mdio_driver *mdiodrv = to_mdio_driver(drv);
>>>>      int err = 0;
>>>>
>>>> -    if (mdiodrv->probe)
>>>> +    if (mdiodrv->probe) {
>>>> +        /* Deassert the reset signal */
>>>> +        mdio_device_reset(mdiodev, 0);
>>>> +
>>>>          err = mdiodrv->probe(mdiodev);
>>>>
>>>> +        /* Assert the reset signal */
>>>> +        mdio_device_reset(mdiodev, 1);
>>>
>>> I wonder if it's safe to do this in general. What if ->probe does
>>> something with the phy that is lost by resetting but that is relied on
>>> later?
>>
>> mdio_probe is called for non PHY devices only, right?
> 
>    Yes, those also can have a reset signal.
> 
>> I'm a bit lost as to why we're de-asserting reset at multiple places. i.e.
>> mdio_probe(), phy_device_register(), phy_init_hw(), phy_probe(), of_mdiobus_register_phy().
> 
>> Isn't it simpler to just de-assert it once at the topmost level?
> 
>    I wasn't after simplicity here. The intent was to save some power putting the device at reset when it's not needed. Florian Fainelly (the phylib maintainer) actually wanted me to go even further with that and assert reset in phy_suspend() but it was too much for me.

Is using RESET for power saving a standard practice? Isn't there some register interface for power saving?
My concern here is that RESET does a number of things that might be undesired for normal operation.
e.g. PHY's will use bootstrap settings on RESET and we need to ensure that bootstrap pins are always in
the right setting before issuing a RESET.

What happens to the PHY link? Is it lost while PHY RESET is asserted?
Is this really desirable?


> 
>> i.e. of_mdiobus_register_device() f and of_mdiobus_register_phy()?
>>
>> Also, how about issuing a reset pulse instead of just de-asserting it.
> 
>    If it's already held at reset, my assumption is that it's enough time passed already.
> 
>> This would tackle the case where PHY is in invalid state with reset already
>> de-asserted.
> 
>     Good question. I haven't yet met such cases though.
> 
>> Another issue is that on some boards we have one reset line tied to
>> multiple PHYs.How do we prevent multiple resets being taking place when each of
>> the PHYs are registered?
> 
>    My patch just doesn't address this case -- it's about the individual resets only.
> 
>> Do we just specify the reset line only for one PHY in
>> the DT or can we have the reset gpio in the mdio_bus node for such case?
> 
>    I think there's mii_bus::reset() method for that case. Some Ethernet drivers even use it
> (mostly instead of the code being suggested here).
> 

  parent reply	other threads:[~2016-05-16  8:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-08 22:21 [PATCH RFT 0/2] Teach phylib hard-resetting devices Sergei Shtylyov
2016-04-08 22:22 ` [PATCH RFT 1/2] phylib: add device reset GPIO support Sergei Shtylyov
2016-04-11 19:25   ` Rob Herring
2016-04-11 19:28     ` Sergei Shtylyov
2016-04-11 22:46       ` Rob Herring
     [not found] ` <2811962.eGX2i5RJbZ@wasted.cogentembedded.com>
     [not found]   ` <20160411022802.GB4307@lunn.ch>
     [not found]     ` <570BE1C5.70502@cogentembedded.com>
     [not found]       ` <20160411181904.GB29709@lunn.ch>
2016-04-11 18:39         ` [PATCH RFT 2/2] macb: kill PHY reset code Sergei Shtylyov
     [not found]           ` <570BEF46.7060105-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2016-04-11 18:51             ` Andrew Lunn
     [not found]               ` <20160411185115.GA30623-g2DYL2Zd6BY@public.gmane.org>
2016-04-11 19:01                 ` Sergei Shtylyov
2016-04-12  9:23                 ` Nicolas Ferre
2016-04-28 22:12 ` [PATCH RFT 1/2] phylib: add device reset GPIO support Sergei Shtylyov
2016-05-03 17:03   ` Rob Herring
2016-05-10 18:32   ` Florian Fainelli
     [not found]     ` <5732294F.3060606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-10 19:11       ` Sergei Shtylyov
     [not found]         ` <5732327A.6080203-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2016-05-10 19:13           ` Florian Fainelli
     [not found]   ` <3641492.klKRrvS8tr-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
2016-05-12 18:42     ` Uwe Kleine-König
2016-05-12 21:35       ` Sergei Shtylyov
2016-05-13  4:06         ` Andrew Lunn
2016-05-13 21:16           ` Sergei Shtylyov
2016-05-13  7:06         ` Uwe Kleine-König
2016-05-13 21:49           ` Sergei Shtylyov
2016-05-13 19:18         ` Sergei Shtylyov
2016-05-14 21:14           ` Sergei Shtylyov
2016-05-13  9:07       ` Roger Quadros
2016-05-13 19:36         ` Sergei Shtylyov
2016-05-13 20:44           ` Andrew Lunn
2016-05-13 20:56             ` Sergei Shtylyov
2016-05-13 23:44               ` Andrew Lunn
2016-05-14 19:36                 ` Sergei Shtylyov
2016-05-14 19:50                   ` Andrew Lunn
2016-05-14 21:46                     ` Sergei Shtylyov
     [not found]                       ` <34922ff9-e566-4829-a631-54ce07cbb325-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2016-05-15 15:23                         ` Andrew Lunn
     [not found]                           ` <20160515152339.GA9021-g2DYL2Zd6BY@public.gmane.org>
2016-05-19 13:40                             ` Sergei Shtylyov
2016-05-16  8:51           ` Roger Quadros [this message]
2016-05-26  9:00       ` Linus Walleij
2016-05-26 19:00         ` Uwe Kleine-König
2016-05-30 14:57           ` Linus Walleij

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=57398A0F.8070708@ti.com \
    --to=rogerq@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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).