Netdev List
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: "Tarr, Stephen F" <Stephen.Tarr@xerox.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: IPv6 and link state transitions
Date: Fri, 14 Nov 2008 15:28:40 -0800	[thread overview]
Message-ID: <20081114152840.41c0b6c6@extreme> (raw)
In-Reply-To: <78EAC2D97114034EB62AAA10FCC2510608047D83@USA7061MS01.na.xerox.net>

On Fri, 14 Nov 2008 14:59:27 -0800
"Tarr, Stephen F" <Stephen.Tarr@xerox.com> wrote:

> I'm using 2.6.27.4 on a powerpc with the gianfar Ethernet driver
> and an MII PHY.  If I boot the system with the Ethernet cable
> disconnected, wait 30 seconds or so, then plug in the cable, the
> interface comes up but I don't see the expected IPv6 DAD probe
> for the link-local address.
> 
> Adding some printfs in addrconf.c shows a NETDEV_UP when the
> interface is initialized but no NETDEV_CHANGE when the link comes
> up.  The transition is detected by the phy driver but filtered out
> by the test-and-clear in netif_carrier_on because
> (dev->state & NOCARRIER) is already clear.
> 
> With Brian Haley's patch to force a link state transition at
> startup, the behavior gets even more interesting.  In that case,
> I see the initial NETDEV_UP and an immediate NETDEV_CHANGE/link
> down.  When the cable's connected, I see a NETDEV_CHANGE/link up
> followed by an immediate MLDv2 announcement and a DAD probe.
> (These were apparently queued up by the NETDEV_UP event, but
> held off by the Ethernet driver.)  After the initialization
> timeout, I see the expected DAD probe, router solicitation and
> so on.
> 
> This patch to the gianfar driver fixes the problem, but only for
> that driver.  A better approach might be to set the initial link
> state in the phy driver, but I'd appreciate some suggestions for
> how and where to do that.
> 
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 3bc19b7..46566ba 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -533,6 +533,9 @@ static int init_phy(struct net_device *dev)
>         char phy_id[BUS_ID_SIZE];
>         phy_interface_t interface;
> 
> +       // assume link down until phy reports otherwise
> +       set_bit(__LINK_STATE_NOCARRIER, &dev->state);
> +
>         priv->oldlink = 0;
>         priv->oldspeed = 0;
>         priv->oldduplex = -1;
> 

Driver should not use set_bit directly.
The correct way for a driver that has carrier to work is

mydrvr_open(struct net_device *dev)
{
...
	if (mydrv_phy_isoffline(dev))
              netif_carrier_off(dev);
...
}

mydrv_phy_intr(...) {
    if (mydrv_phy_isoffline(dev))
          netif_carrier_off(dev);
    else
          netif_carrier_on(dev)
}

  reply	other threads:[~2008-11-14 23:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14 22:59 IPv6 and link state transitions Tarr, Stephen F
2008-11-14 23:28 ` Stephen Hemminger [this message]
2008-11-15  6:04   ` Tarr, Stephen F

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=20081114152840.41c0b6c6@extreme \
    --to=shemminger@vyatta.com \
    --cc=Stephen.Tarr@xerox.com \
    --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