[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101103080019.GC6772@redhat.com>
Date: Wed, 3 Nov 2010 10:00:19 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: rusty@...tcorp.com.au, davem@...emloft.net, markmc@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH] virtio-net: init link state correctly
On Wed, Nov 03, 2010 at 03:08:17PM +0800, Jason Wang wrote:
> We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
> before querying device state during probing, otherwise we may get
> wrong operstate after driver was loaded because the link watch event
> was not fired as expected.
>
> Since the device state changed could be caught through interrupt, the
> unconditional call to nerif_carrier_on() is also removed.
>
> Signed-off-by: Jason Wang <jasowang@...hat.com>
OK, but this seems broken for hosts without VIRTIO_NET_F_STATUS. Right?
Probably
/* Assume link up if device can't report link status,
otherwise get link status from config. */
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
vi->status = 0;
netif_carrier_off(dev);
virtnet_update_status(vi);
} else {
vi->status = VIRTIO_NET_S_LINK_UP;
netif_carrier_on(dev);
}
Makes sense?
> ---
> drivers/net/virtio_net.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index bb6b67f..0a0cd35 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -986,9 +986,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> goto unregister;
> }
>
> - vi->status = VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> virtnet_update_status(vi);
> - netif_carrier_on(dev);
>
> pr_debug("virtnet: registered device %s\n", dev->name);
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists