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.

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

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

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

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

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

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

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

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

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

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_*

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_*

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

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

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_*

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_*

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

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

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 >

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

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

2018-04-27 Thread Florian Fainelli
Hi all, 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 example, patches are included to add support for the IEEE

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

2018-04-27 Thread Florian Fainelli
Hi all, 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 example, patches are included to add support for the IEEE