Re: [RFC net-next 0/5] Support for PHY test modes

2018-05-01 Thread Andrew Lunn
> # echo 4 > /sys/class/net/gphy/operstate > # ip link show gphy > 4: gphy@eth1: mtu 1500 > qdisc noqueue switchid state TESTING mode DEFAULT group default > qlen 1000 > link/ether 00:10:18:de:38:1f brd ff:ff:ff:ff:ff:ff This looks good. I stopped using ifconfig years ago, so i pers

Re: [RFC net-next 0/5] Support for PHY test modes

2018-05-01 Thread Florian Fainelli
On 05/01/2018 10:47 AM, Andrew Lunn wrote: > On Tue, May 01, 2018 at 10:21:54AM -0700, Florian Fainelli wrote: >> On 04/30/2018 04:24 PM, Andrew Lunn wrote: Turning these tests on will typically result in the link partner dropping the link with us, and the interface will be non-functional

Re: [RFC net-next 0/5] Support for PHY test modes

2018-05-01 Thread David Miller
From: Florian Fainelli Date: Tue, 1 May 2018 10:21:54 -0700 > On 04/30/2018 04:24 PM, Andrew Lunn wrote: >>> Turning these tests on will typically result in the link partner >>> dropping the link with us, and the interface will be non-functional as >>> far as the data path is concerned (similar t

Re: [RFC net-next 0/5] Support for PHY test modes

2018-05-01 Thread Andrew Lunn
On Tue, May 01, 2018 at 10:21:54AM -0700, Florian Fainelli wrote: > On 04/30/2018 04:24 PM, Andrew Lunn wrote: > >> Turning these tests on will typically result in the link partner > >> dropping the link with us, and the interface will be non-functional as > >> far as the data path is concerned (si

Re: [RFC net-next 0/5] Support for PHY test modes

2018-05-01 Thread Florian Fainelli
On 04/30/2018 04:24 PM, Andrew Lunn wrote: >> Turning these tests on will typically result in the link partner >> dropping the link with us, and the interface will be non-functional as >> far as the data path is concerned (similar to an isolation mode). This >> might warrant properly reporting that

Re: [RFC net-next 0/5] Support for PHY test modes

2018-04-30 Thread Andrew Lunn
> Turning these tests on will typically result in the link partner > dropping the link with us, and the interface will be non-functional as > far as the data path is concerned (similar to an isolation mode). This > might warrant properly reporting that to user-space through e.g: a > private IFF_* v

Re: [RFC net-next 0/5] Support for PHY test modes

2018-04-30 Thread Florian Fainelli
On 04/30/2018 09:40 AM, Andrew Lunn wrote: >> Turning these tests on will typically result in the link partner >> dropping the link with us, and the interface will be non-functional as >> far as the data path is concerned (similar to an isolation mode). This >> might warrant properly reporting that

Re: [RFC net-next 0/5] Support for PHY test modes

2018-04-30 Thread Andrew Lunn
> Turning these tests on will typically result in the link partner > dropping the link with us, and the interface will be non-functional as > far as the data path is concerned (similar to an isolation mode). This > might warrant properly reporting that to user-space through e.g: a > private IFF_* v

Re: [RFC net-next 0/5] Support for PHY test modes

2018-04-30 Thread Florian Fainelli
On 04/29/2018 07:55 PM, David Miller wrote: > From: Florian Fainelli > Date: Fri, 27 Apr 2018 17:32:30 -0700 > >> This patch series adds support for specifying PHY test modes through >> ethtool and paves the ground for adding support for more complex >> test modes that might require data to be ex

Re: [RFC net-next 0/5] Support for PHY test modes

2018-04-29 Thread David Miller
From: Florian Fainelli Date: Fri, 27 Apr 2018 17:32:30 -0700 > This patch series adds support for specifying PHY test modes through > ethtool and paves the ground for adding support for more complex > test modes that might require data to be exchanged between user and > kernel space. > > As an e