LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, andrew@lunn.ch, rmk@armlinux.org.uk,
	linux-kernel@vger.kernel.org, cphealy@gmail.com,
	nikita.yoush@cogentembedded.com,
	vivien.didelot@savoirfairelinux.com, Nisar.Sayed@microchip.com,
	UNGLinuxDriver@microchip.com
Subject: Re: [RFC net-next 0/5] Support for PHY test modes
Date: Mon, 30 Apr 2018 09:30:03 -0700	[thread overview]
Message-ID: <eea70076-891c-5caa-a590-ef1b0421f3b2@gmail.com> (raw)
In-Reply-To: <20180429.225554.2165914401649980919.davem@davemloft.net>

On 04/29/2018 07:55 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.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.

Thanks for taking a look!

> 
> 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?

We expect that these commands/tests would likely be issued when the
interface is up (not necessarily with a carrier state ON though) because
we know for sure that drivers will have successfully connected to their
PHY and there is no power management (or there is, like runtime PM)
which will not prevent accesses to the MDIO interface from working.

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_* value maybe?
-- 
Florian

  reply	other threads:[~2018-04-30 16:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-28  0:32 Florian Fainelli
2018-04-28  0:32 ` [RFC net-next 1/5] net: phy: Pass stringset argument to ethtool operations Florian Fainelli
2018-04-28  0:32 ` [RFC net-next 2/5] net: ethtool: Add UAPI for PHY test modes Florian Fainelli
2018-04-28  0:32 ` [RFC net-next 3/5] net: ethtool: Add plumbing to get/set " Florian Fainelli
2018-04-28  0:32 ` [RFC net-next 4/5] net: phy: Add support for IEEE standard " Florian Fainelli
2018-04-30 23:20   ` Andrew Lunn
2018-05-01 17:03     ` Florian Fainelli
2018-05-01 17:29   ` Woojung.Huh
2018-05-01 18:43     ` Florian Fainelli
2018-05-01 20:07       ` Woojung.Huh
2018-05-01 20:51         ` Florian Fainelli
2018-05-07  0:02           ` Woojung.Huh
2018-04-28  0:32 ` [RFC net-next 5/5] net: phy: broadcom: Add support for PHY " Florian Fainelli
2018-04-28  0:32 ` [PATCH ethtool 1/2] ethtool-copy.h: Sync with net-next Florian Fainelli
2018-04-28  0:32 ` [PATCH ethtool 2/2] ethtool: Add support for PHY test modes Florian Fainelli
2018-04-30  2:55 ` [RFC net-next 0/5] Support " David Miller
2018-04-30 16:30   ` Florian Fainelli [this message]
2018-04-30 16:40     ` Andrew Lunn
2018-04-30 19:23       ` Florian Fainelli
2018-04-30 23:24     ` Andrew Lunn
2018-05-01 17:21       ` Florian Fainelli
2018-05-01 17:47         ` Andrew Lunn
2018-05-01 18:27           ` Florian Fainelli
2018-05-01 19:59             ` Andrew Lunn
2018-05-01 18:06         ` David Miller

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=eea70076-891c-5caa-a590-ef1b0421f3b2@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=Nisar.Sayed@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=rmk@armlinux.org.uk \
    --cc=vivien.didelot@savoirfairelinux.com \
    --subject='Re: [RFC net-next 0/5] Support for PHY test modes' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).