From: Stephen Hemminger <shemminger@vyatta.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: RFC - document network device carrier management
Date: Wed, 15 Aug 2012 08:58:27 -0700 [thread overview]
Message-ID: <20120815085827.2b252094@nehalam.linuxnetplumber.net> (raw)
Since carrier handling is often done incorrectly by new device drivers
be explicit about carrier handling API.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
This is a meant as starting point for discussion, it's probably wrong as is.
Since this isn't code, it could be applied for 3.6 and doesn't need for net-next.
--- a/Documentation/networking/netdevices.txt 2012-06-22 08:27:46.729168196 -0700
+++ b/Documentation/networking/netdevices.txt 2012-08-15 08:56:31.120429994 -0700
@@ -45,6 +45,36 @@ drop, truncate, or pass up oversize pack
packets is preferred.
+CARRIER
+=======
+Most network devices have an operational state that the device
+monitors. The Linux kernel uses the name "carrier" for this flag which
+is a historical reference to old modems. Carrier is reported to
+userspace via the IFF_RUNNING flag from SIOCGIFFLAGS ioctl.
+Carrier is controlled in the device driver
+by the functions netif_carrier_on and netif_carrier_off. These
+functions trigger the necessary netlink and userspace API changes;
+device drivers must not change netdevice->flags directly.
+
+The carrier defaults to ON when the device is created and registered.
+Simple devices (such as dummy) do not need to do anything.
+Ethernet style devices should:
+ * alloc_etherdev in probe routine
+ * call netif_carrier_off
+ * register network device
+ * start auto negotiation with phy in open routine
+ * call netif_carrier_on when link is up
+
+More complex RFC2863 style operational state is also possible
+but not required (see operstates.txt).
+
+The monitoring of link state is the responsibility of the network
+device driver. It can be done by polling, interrupt, or any other
+mechanism. netif_carrier_on/netif_carrier_off are atomic and can
+safely be called by an interrupt routine. Carrier events are
+managed by the linkwatch work queue and limited to one per second
+to avoid overwhelming management applications.
+
struct net_device synchronization rules
=======================================
ndo_open:
next reply other threads:[~2012-08-15 15:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 15:58 Stephen Hemminger [this message]
2012-08-20 21:34 ` RFC - document network device carrier management Ben Hutchings
2012-09-10 2:00 ` Jan Engelhardt
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=20120815085827.2b252094@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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