All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <davem@davemloft.net>, <f.fainelli@gmail.com>,
	<huangdaode@hisilicon.com>, <xuwei5@hisilicon.com>,
	<liguozhu@hisilicon.com>, <Yisen.Zhuang@huawei.com>,
	<gabriele.paoloni@huawei.com>, <john.garry@huawei.com>,
	<linuxarm@huawei.com>, <salil.mehta@huawei.com>,
	<lipeng321@huawei.com>, <tremyfr@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback
Date: Thu, 29 Jun 2017 10:35:25 +0800	[thread overview]
Message-ID: <1bff07ed-d423-dfa2-61e3-3f35c4536632@huawei.com> (raw)
In-Reply-To: <20170628202819.GA22815@lunn.ch>

Hi, Andrew

On 2017/6/29 4:28, Andrew Lunn wrote:
>>> >From your description, it sounds like you can call phy_resume() on a
>>> device which is not suspended. 
>> Do you mean after calling dev_close, the device is still not suspended?
> 
> You only call dev_close() if the device is running. What if somebody
> runs the self test on an interface when it has never been opened? It
> looks like you will call phy_resume(). But since it has never been
> suspended, you could be in trouble.
Here is what I can think of:
1. when the mac driver is first loaded, the phy has a default state. suspended?
2. If user runs the self test after using 'ifconfig ethX down', then I suppose
phy is already suspended.

Also I don't quite understand what do you mean by in trouble. Right now in phy
core, phy_resume return ok even the phy is not suspended.

Best Regards
Yunsheng Lin
>>
>> In general, suspend is expected to
>>> store away state which will be lost when powering down a
>>> device. Resume writes that state back into the device after it is
>>> powered up. So resuming a device which was never suspended could write
>>> bad state into it.
>>
>> Do you mean phydev->suspended has bad state?
> 
> phy_resume() current does not check the phydev->suspended state.
> 
>>> Also, what about if WOL has been set before closing the device?
>>
>> phy_suspend will return errro.
>>
>> int phy_suspend(struct phy_device *phydev)
>> {
>> 	struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>> 	struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> 	int ret = 0;
>>
>> 	/* If the device has WOL enabled, we cannot suspend the PHY */
>> 	phy_ethtool_get_wol(phydev, &wol);
>> 	if (wol.wolopts)
>> 		return -EBUSY;
>>
>> 	if (phydev->drv && phydrv->suspend)
>> 		ret = phydrv->suspend(phydev);
>>
>> 	if (ret)
>> 		return ret;
>>
>> 	phydev->suspended = true;
>>
>> 	return ret;
>> }
> 
> Which means when you call phy_resume() in lb_setup() you are again
> resuming a device which is not suspended...
> 
> 	 Andrew
> 
> .
> 

  reply	other threads:[~2017-06-29  2:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26  2:10 [PATCH NET V5 0/2] Add loopback support in phy_driver and hns ethtool fix Lin Yun Sheng
2017-06-26  2:10 ` [PATCH NET V5 1/2] net: phy: Add phy loopback support in net phy framework Lin Yun Sheng
2017-06-26 13:43   ` Andrew Lunn
2017-06-26 16:45   ` Florian Fainelli
2017-06-26  2:10 ` [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback Lin Yun Sheng
2017-06-26 13:42   ` Andrew Lunn
2017-06-27  3:25     ` Yunsheng Lin
2017-06-27 13:29       ` Andrew Lunn
2017-06-28  0:59         ` Yunsheng Lin
2017-06-28 20:28           ` Andrew Lunn
2017-06-29  2:35             ` Yunsheng Lin [this message]
2017-06-29 13:56               ` Andrew Lunn
2017-06-30  9:14                 ` Yunsheng Lin
2017-06-30 13:39                   ` Andrew Lunn
2017-07-01 15:17                     ` Andrew Lunn
2017-07-03  9:57                       ` Yunsheng Lin

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=1bff07ed-d423-dfa2-61e3-3f35c4536632@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=Yisen.Zhuang@huawei.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=huangdaode@hisilicon.com \
    --cc=john.garry@huawei.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=lipeng321@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=salil.mehta@huawei.com \
    --cc=tremyfr@gmail.com \
    --cc=xuwei5@hisilicon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.