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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180429.225554.2165914401649980919.davem@davemloft.net>
Date:   Sun, 29 Apr 2018 22:55:54 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     f.fainelli@...il.com
Cc:     netdev@...r.kernel.org, andrew@...n.ch, rmk@...linux.org.uk,
        linux-kernel@...r.kernel.org, cphealy@...il.com,
        nikita.yoush@...entembedded.com,
        vivien.didelot@...oirfairelinux.com, Nisar.Sayed@...rochip.com,
        UNGLinuxDriver@...rochip.com
Subject: Re: [RFC net-next 0/5] Support for PHY test modes

From: Florian Fainelli <f.fainelli@...il.com>
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 example, patches are included to add support for the IEEE
> electrical test modes for 100BaseT2 and 1000BaseT. Those do not
> require data to be passed back and forth.
> 
> I believe the infrastructure to be usable enough to add support for
> other things like:
> 
> - cable diagnostics
> - pattern generator/waveform generator with specific pattern being
>   indicated for instance
> 
> Questions for Andrew, and others:
> 
> - there could be room for adding additional ETH_TEST_FL_* values in order to
>   help determine how the test should be running
> - some of these tests can be disruptive to connectivity, the minimum we could
>   do is stop the PHY state machine and restart it when "normal" is used to exit
>   those test modes
> 
> Comments welcome!

Generally, no objection to providing this in the general manner you
have implemented it via ethtool.

I think in order to answer the disruptive question, you need to give
some information about what kind of context this stuff would be
used in, and if in those contexts what the user expectations are
or might be.

Are these test modes something that usually would be initiated with
the interface down?