Hi, Andrew
On 2017/7/1 23:17, Andrew Lunn wrote:
> On Sat, Jul 01, 2017 at 11:57:32AM +, linyunsheng wrote:
>> Hi, Andrew
>>
>> I am agreed wih you on this.
>> But self test is also a feature of our product, and our
>> customer way choose to diagnose a problem using
>> self test, even if self
On Sat, Jul 01, 2017 at 11:57:32AM +, linyunsheng wrote:
> Hi, Andrew
>
> I am agreed wih you on this.
> But self test is also a feature of our product, and our
> customer way choose to diagnose a problem using
> self test, even if self test does not give a clear
> reason to the problem.
> we
> Any idea?
Maybe consider what the self test is good for.
My guess is, self test was added when a network interface card was a
full size VME card, and had a couple of hundred components or more.
They did break during there life, due to heat, mechanism stresses,
causing parts to pop off the PCB,
Hi, Andrew
On 2017/6/29 21:56, Andrew Lunn wrote:
>>> 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
> > 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 t
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
> >>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
Hi, Andrew
On 2017/6/27 21:29, Andrew Lunn wrote:
- phy_write(phy_dev, COPPER_CONTROL_REG, val);
+ err = phy_resume(phy_dev);
>>>
>>> Maybe this was discussed with an earlier version of these patches. Why
>>> are using phy_resume() and phy_suspend()?
>> When self_test i
> >> - phy_write(phy_dev, COPPER_CONTROL_REG, val);
> >> + err = phy_resume(phy_dev);
> >
> > Maybe this was discussed with an earlier version of these patches. Why
> > are using phy_resume() and phy_suspend()?
> When self_test is invoked with ETH_TEST_FL_OFFLINE option, hns mac
Hi, Andrew
On 2017/6/26 21:42, Andrew Lunn wrote:
> On Mon, Jun 26, 2017 at 10:10:39AM +0800, Lin Yun Sheng wrote:
>> Use function set_loopback in phy_driver to setup phy loopback
>> when doing ethtool self test.
>>
>> Signed-off-by: Lin Yun Sheng
>> ---
>> drivers/net/ethernet/hisilicon/hns/hna
On Mon, Jun 26, 2017 at 10:10:39AM +0800, Lin Yun Sheng wrote:
> Use function set_loopback in phy_driver to setup phy loopback
> when doing ethtool self test.
>
> Signed-off-by: Lin Yun Sheng
> ---
> drivers/net/ethernet/hisilicon/hns/hnae.h| 1 +
> drivers/net/ethernet/hisilicon/hns/hn
Use function set_loopback in phy_driver to setup phy loopback
when doing ethtool self test.
Signed-off-by: Lin Yun Sheng
---
drivers/net/ethernet/hisilicon/hns/hnae.h| 1 +
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 92 +++-
2 files changed, 26 insertions(+),
12 matches
Mail list logo
