From: Jiri Pirko <jpirko@redhat.com>
To: Ben Greear <greearb@candelatech.com>
Cc: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>,
"Ben Hutchings" <bhutchings@solarflare.com>,
"Michał Mirosław" <mirqus@gmail.com>,
netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com, shemminger@vyatta.com
Subject: Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
Date: Thu, 1 Sep 2011 07:44:22 +0200 [thread overview]
Message-ID: <20110901054420.GA1969@minipsycho> (raw)
In-Reply-To: <4E5E9E16.6060502@candelatech.com>
Wed, Aug 31, 2011 at 10:48:22PM CEST, greearb@candelatech.com wrote:
>On 08/31/2011 01:31 PM, Nicolas de Pesloüan wrote:
>>Le 31/08/2011 22:12, Ben Hutchings a écrit :
>>>On Wed, 2011-08-31 at 22:03 +0200, Nicolas de Pesloüan wrote:
>>>>Le 31/08/2011 10:45, Jiri Pirko a écrit :
>>>>
>>>>>>>>Do you expect drivers using implementation different than just calling
>>>>>>>>netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?
>>>>>>>Yes, generally it can be used also for en/disable phy, for testing
>>>>>>>purposes if hw and driver would support it.
>>>>>>
>>>>>>I'd like to see this working for GRE tunnel devices (for keepalive
>>>>>>daemon to be able to indicate to routing daemons whether tunnel is
>>>>>>really working) - implementation would be identical to dummy's case.
>>>>>>Should I prepare a patch or can I leave it to you?
>>>>>
>>>>>Ok, I can include it to this patchset (I'm going to repost first patch
>>>>>anyway)
>>>>
>>>>Can't we assume that the dummy's case is the default behavior and
>>>>register this default
>>>>ndo_change_carrier callback for every device ?
>>>
>>>You have got to be joking. No device driver that has real link
>>>monitoring should use this implementation.
>>
>>Well, why not? Arguably, this is probably not the feature one would use every day, but...
>>
>>Testing a cluster reaction to a link down event would be easier if one doesn't need to unplug the cable for the test. I understand that one can turn off the
>>switch port (physical or virtual), but echo 0 > /sys/class/net/eth0/carrier would be nice too.
>
>There is special hardware out there that can do bypass, and often it also has a mode
>that will programatically cut link by throwing some relays. We use this for our
>testing equipment...
>
>If there is some way to twiddle standard-ish hardware to actually drop link, that
>would be neat. I'd think it should be an ethtool type of thing, however.
Ethtool can implement this eventually by calling the same ndo.
>
>Actually dropping link, and letting that naturally propagate up the stack seems
>more reasonable than lying about the status half way up the stack.
Yes, that is really the intension of the proposed ndo. Real hw driver
should implement that as you say, not directly setting carrier_on/off
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-09-01 5:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 14:46 [patch net-next-2.6 0/2] net: allow to change carrier via sysfs Jiri Pirko
2011-08-30 14:46 ` [patch net-next-2.6 1/2] " Jiri Pirko
2011-08-30 15:14 ` Ben Hutchings
2011-08-30 15:19 ` Jiri Pirko
2011-08-30 18:11 ` Michał Mirosław
2011-08-30 18:25 ` Stephen Hemminger
2011-08-31 8:31 ` Jiri Pirko
2011-08-31 8:26 ` Jiri Pirko
2011-08-31 8:33 ` Michał Mirosław
2011-08-31 8:45 ` Jiri Pirko
2011-08-31 20:03 ` Nicolas de Pesloüan
2011-08-31 20:12 ` Ben Hutchings
2011-08-31 20:26 ` Jiri Pirko
2011-08-31 20:31 ` Nicolas de Pesloüan
2011-08-31 20:44 ` Ben Hutchings
2011-08-31 20:48 ` Ben Greear
2011-08-31 21:36 ` Ben Hutchings
2011-08-31 21:40 ` Stephen Hemminger
2011-09-01 5:46 ` Jiri Pirko
2011-08-31 21:49 ` Ben Greear
2011-09-01 5:44 ` Jiri Pirko [this message]
2011-08-30 14:46 ` [patch net-next-2.6 2/2] dummy: implement carrier change Jiri Pirko
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=20110901054420.GA1969@minipsycho \
--to=jpirko@redhat.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.2p.debian@gmail.com \
--cc=shemminger@vyatta.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).