* [PATCH V7 1/3] vhost_net: correct error handling in vhost_net_set_backend()
From: Jason Wang @ 2013-01-28 11:05 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1359371119-10208-1-git-send-email-jasowang@redhat.com>
Currently, when vhost_init_used() fails the sock refcnt and ubufs were
leaked. Correct this by calling vhost_init_used() before assign ubufs and
restore the oldsock when it fails.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ebd08b2..d10ad6f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -827,15 +827,16 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
r = PTR_ERR(ubufs);
goto err_ubufs;
}
- oldubufs = vq->ubufs;
- vq->ubufs = ubufs;
+
vhost_net_disable_vq(n, vq);
rcu_assign_pointer(vq->private_data, sock);
- vhost_net_enable_vq(n, vq);
-
r = vhost_init_used(vq);
if (r)
- goto err_vq;
+ goto err_used;
+ vhost_net_enable_vq(n, vq);
+
+ oldubufs = vq->ubufs;
+ vq->ubufs = ubufs;
n->tx_packets = 0;
n->tx_zcopy_err = 0;
@@ -859,6 +860,11 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
mutex_unlock(&n->dev.mutex);
return 0;
+err_used:
+ rcu_assign_pointer(vq->private_data, oldsock);
+ vhost_net_enable_vq(n, vq);
+ if (ubufs)
+ vhost_ubuf_put_and_wait(ubufs);
err_ubufs:
fput(sock->file);
err_vq:
--
1.7.1
^ permalink raw reply related
* [PATCH V7 2/3] vhost_net: handle polling errors when setting backend
From: Jason Wang @ 2013-01-28 11:05 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1359371119-10208-1-git-send-email-jasowang@redhat.com>
Currently, the polling errors were ignored, which can lead following issues:
- vhost remove itself unconditionally from waitqueue when stopping the poll,
this may crash the kernel since the previous attempt of starting may fail to
add itself to the waitqueue
- userspace may think the backend were successfully set even when the polling
failed.
Solve this by:
- check poll->wqh before trying to remove from waitqueue
- report polling errors in vhost_poll_start(), tx_poll_start(), the return value
will be checked and returned when userspace want to set the backend
After this fix, there still could be a polling failure after backend is set, it
will addressed by the next patch.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 27 ++++++++++++++++++---------
drivers/vhost/vhost.c | 18 +++++++++++++++---
drivers/vhost/vhost.h | 2 +-
3 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index d10ad6f..959b1cd 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -165,12 +165,16 @@ static void tx_poll_stop(struct vhost_net *net)
}
/* Caller must have TX VQ lock */
-static void tx_poll_start(struct vhost_net *net, struct socket *sock)
+static int tx_poll_start(struct vhost_net *net, struct socket *sock)
{
+ int ret;
+
if (unlikely(net->tx_poll_state != VHOST_NET_POLL_STOPPED))
- return;
- vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
- net->tx_poll_state = VHOST_NET_POLL_STARTED;
+ return 0;
+ ret = vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
+ if (!ret)
+ net->tx_poll_state = VHOST_NET_POLL_STARTED;
+ return ret;
}
/* In case of DMA done not in order in lower device driver for some reason.
@@ -642,20 +646,23 @@ static void vhost_net_disable_vq(struct vhost_net *n,
vhost_poll_stop(n->poll + VHOST_NET_VQ_RX);
}
-static void vhost_net_enable_vq(struct vhost_net *n,
+static int vhost_net_enable_vq(struct vhost_net *n,
struct vhost_virtqueue *vq)
{
struct socket *sock;
+ int ret;
sock = rcu_dereference_protected(vq->private_data,
lockdep_is_held(&vq->mutex));
if (!sock)
- return;
+ return 0;
if (vq == n->vqs + VHOST_NET_VQ_TX) {
n->tx_poll_state = VHOST_NET_POLL_STOPPED;
- tx_poll_start(n, sock);
+ ret = tx_poll_start(n, sock);
} else
- vhost_poll_start(n->poll + VHOST_NET_VQ_RX, sock->file);
+ ret = vhost_poll_start(n->poll + VHOST_NET_VQ_RX, sock->file);
+
+ return ret;
}
static struct socket *vhost_net_stop_vq(struct vhost_net *n,
@@ -833,7 +840,9 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
r = vhost_init_used(vq);
if (r)
goto err_used;
- vhost_net_enable_vq(n, vq);
+ r = vhost_net_enable_vq(n, vq);
+ if (r)
+ goto err_used;
oldubufs = vq->ubufs;
vq->ubufs = ubufs;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 34389f7..9759249 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -77,26 +77,38 @@ void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
init_poll_funcptr(&poll->table, vhost_poll_func);
poll->mask = mask;
poll->dev = dev;
+ poll->wqh = NULL;
vhost_work_init(&poll->work, fn);
}
/* Start polling a file. We add ourselves to file's wait queue. The caller must
* keep a reference to a file until after vhost_poll_stop is called. */
-void vhost_poll_start(struct vhost_poll *poll, struct file *file)
+int vhost_poll_start(struct vhost_poll *poll, struct file *file)
{
unsigned long mask;
+ int ret = 0;
mask = file->f_op->poll(file, &poll->table);
if (mask)
vhost_poll_wakeup(&poll->wait, 0, 0, (void *)mask);
+ if (mask & POLLERR) {
+ if (poll->wqh)
+ remove_wait_queue(poll->wqh, &poll->wait);
+ ret = -EINVAL;
+ }
+
+ return ret;
}
/* Stop polling a file. After this function returns, it becomes safe to drop the
* file reference. You must also flush afterwards. */
void vhost_poll_stop(struct vhost_poll *poll)
{
- remove_wait_queue(poll->wqh, &poll->wait);
+ if (poll->wqh) {
+ remove_wait_queue(poll->wqh, &poll->wait);
+ poll->wqh = NULL;
+ }
}
static bool vhost_work_seq_done(struct vhost_dev *dev, struct vhost_work *work,
@@ -792,7 +804,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
fput(filep);
if (pollstart && vq->handle_kick)
- vhost_poll_start(&vq->poll, vq->kick);
+ r = vhost_poll_start(&vq->poll, vq->kick);
mutex_unlock(&vq->mutex);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 2639c58..17261e2 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -42,7 +42,7 @@ void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work);
void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
unsigned long mask, struct vhost_dev *dev);
-void vhost_poll_start(struct vhost_poll *poll, struct file *file);
+int vhost_poll_start(struct vhost_poll *poll, struct file *file);
void vhost_poll_stop(struct vhost_poll *poll);
void vhost_poll_flush(struct vhost_poll *poll);
void vhost_poll_queue(struct vhost_poll *poll);
--
1.7.1
^ permalink raw reply related
* [PATCH V7 3/3] tuntap: allow polling/writing/reading when detached
From: Jason Wang @ 2013-01-28 11:05 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
In-Reply-To: <1359371119-10208-1-git-send-email-jasowang@redhat.com>
We forbid polling, writing and reading when the file were detached, this may
complex the user in several cases:
- when guest pass some buffers to vhost/qemu and then disable some queues,
host/qemu needs to do its own cleanup on those buffers which is complex
sometimes. We can do this simply by allowing a user can still write to an
disabled queue. Write to an disabled queue will cause the packet pass to the
kernel and read will get nothing.
- align the polling behavior with macvtap which never fails when the queue is
created. This can simplify the polling errors handling of its user (e.g vhost)
We can simply achieve this by don't assign NULL to tfile->tun when detached.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 30a7d0e..2fb19da 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -298,11 +298,12 @@ static void tun_flow_cleanup(unsigned long data)
}
static void tun_flow_update(struct tun_struct *tun, u32 rxhash,
- u16 queue_index)
+ struct tun_file *tfile)
{
struct hlist_head *head;
struct tun_flow_entry *e;
unsigned long delay = tun->ageing_time;
+ u16 queue_index = tfile->queue_index;
if (!rxhash)
return;
@@ -311,7 +312,9 @@ static void tun_flow_update(struct tun_struct *tun, u32 rxhash,
rcu_read_lock();
- if (tun->numqueues == 1)
+ /* We may get a very small possibility of OOO during switching, not
+ * worth to optimize.*/
+ if (tun->numqueues == 1 || tfile->detached)
goto unlock;
e = tun_flow_find(head, rxhash);
@@ -411,21 +414,21 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
tun = rtnl_dereference(tfile->tun);
- if (tun) {
+ if (tun && !tfile->detached) {
u16 index = tfile->queue_index;
BUG_ON(index >= tun->numqueues);
dev = tun->dev;
rcu_assign_pointer(tun->tfiles[index],
tun->tfiles[tun->numqueues - 1]);
- rcu_assign_pointer(tfile->tun, NULL);
ntfile = rtnl_dereference(tun->tfiles[index]);
ntfile->queue_index = index;
--tun->numqueues;
- if (clean)
+ if (clean) {
+ rcu_assign_pointer(tfile->tun, NULL);
sock_put(&tfile->sk);
- else
+ } else
tun_disable_queue(tun, tfile);
synchronize_net();
@@ -473,6 +476,10 @@ static void tun_detach_all(struct net_device *dev)
rcu_assign_pointer(tfile->tun, NULL);
--tun->numqueues;
}
+ list_for_each_entry(tfile, &tun->disabled, next) {
+ wake_up_all(&tfile->wq.wait);
+ rcu_assign_pointer(tfile->tun, NULL);
+ }
BUG_ON(tun->numqueues != 0);
synchronize_net();
@@ -503,7 +510,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
goto out;
err = -EINVAL;
- if (rtnl_dereference(tfile->tun))
+ if (rtnl_dereference(tfile->tun) && !tfile->detached)
goto out;
err = -EBUSY;
@@ -1202,7 +1209,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
tun->dev->stats.rx_packets++;
tun->dev->stats.rx_bytes += len;
- tun_flow_update(tun, rxhash, tfile->queue_index);
+ tun_flow_update(tun, rxhash, tfile);
return total_len;
}
@@ -1816,7 +1823,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
ret = tun_attach(tun, file);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rtnl_dereference(tfile->tun);
- if (!tun || !(tun->flags & TUN_TAP_MQ))
+ if (!tun || !(tun->flags & TUN_TAP_MQ) || tfile->detached)
ret = -EINVAL;
else
__tun_detach(tfile, false);
--
1.7.1
^ permalink raw reply related
* Re: [net-next 13/14] igb: Don't give VFs random MAC addresses
From: Stefan Assmann @ 2013-01-28 11:09 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, Mitch A Williams, netdev, gospo, Andy Gospodarek,
Stefan Assmann
In-Reply-To: <1359363869-32391-14-git-send-email-jeffrey.t.kirsher@intel.com>
On 28.01.2013 10:04, Jeff Kirsher wrote:
> From: Mitch A Williams <mitch.a.williams@intel.com>
>
> If the user has not assigned a MAC address to a VM, then don't give it a
> random one. Instead, just give it zeros and let it figure out what to do
> with them.
>
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Stefan Assmann <sassmann@kpanic.de>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Stefan Assmann <sassmann@redhat.com>
Stefan
^ permalink raw reply
* Re: [net-next 14/14] igbvf: be sane about random MAC addresses
From: Stefan Assmann @ 2013-01-28 11:11 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, Mitch A Williams, netdev, gospo, Andy Gospodarek,
Stefan Assmann
In-Reply-To: <1359363869-32391-15-git-send-email-jeffrey.t.kirsher@intel.com>
On 28.01.2013 10:04, Jeff Kirsher wrote:
> From: Mitch A Williams <mitch.a.williams@intel.com>
>
> Tighten up some of the code surrounding MAC addresses. Since the PF is
> now giving all zeros instead of a random address, check for this case
> and generate a random address. This ensures that we always know when we
> have a random address and udev won't get upset about it.
>
> Additionally, tighten up some of the log messages and clean up the
> formatting.
>
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Stefan Assmann <sassmann@kpanic.de>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Stefan Assmann <sassmann@redhat.com>
Thanks Mitch. This solves the problem of correctly setting
addr_assign_type.
Stefan
^ permalink raw reply
* Re: [PATCHv2] tun: fix carrier on/off status
From: Jason Wang @ 2013-01-28 11:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Toralf Förster, netdev, Linux Kernel, David Miller
In-Reply-To: <20130128103801.GA6648@redhat.com>
On 01/28/2013 06:38 PM, Michael S. Tsirkin wrote:
> Commit c8d68e6be1c3b242f1c598595830890b65cea64a removed carrier off call
> from tun_detach since it's now called on queue disable and not only on
> tun close. This confuses userspace which used this flag to detect a
> free tun. To fix, put this back but under if (clean).
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> Changes from v1:
> Don't set carrier off unless all queues are closed.
>
> Note: didn't test in MQ mode - Jason, care checking this does the
> right thing there?
Tested-by: Jason Wang <jasowang@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index af372d0..06b2723 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -434,10 +434,13 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
> }
>
> if (clean) {
> - if (tun && tun->numqueues == 0 && tun->numdisabled == 0 &&
> - !(tun->flags & TUN_PERSIST))
> - if (tun->dev->reg_state == NETREG_REGISTERED)
> + if (tun && tun->numqueues == 0 && tun->numdisabled == 0) {
> + netif_carrier_off(tun->dev);
> +
> + if (!(tun->flags & TUN_PERSIST) &&
> + tun->dev->reg_state == NETREG_REGISTERED)
> unregister_netdevice(tun->dev);
> + }
>
> BUG_ON(!test_bit(SOCK_EXTERNALLY_ALLOCATED,
> &tfile->socket.flags));
> @@ -1644,10 +1647,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> device_create_file(&tun->dev->dev, &dev_attr_owner) ||
> device_create_file(&tun->dev->dev, &dev_attr_group))
> pr_err("Failed to create tun sysfs files\n");
> -
> - netif_carrier_on(tun->dev);
> }
>
> + netif_carrier_on(tun->dev);
> +
> tun_debug(KERN_INFO, tun, "tun_set_iff\n");
>
> if (ifr->ifr_flags & IFF_NO_PI)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* TCP connection in suspend (to RAM)
From: Johannes Berg @ 2013-01-28 11:55 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
I'm working on a feature by which our device (Intel WiFi) will establish
a TCP connection while the host is asleep, in order to receive a wakeup
signal over the connection. There are a few configuration parameters,
but it's basically pretty simple, it establishes a connection, sending
configurable data in a configurable interval on it and wakes up the host
if it receives (certain) data on the connection or the connection breaks
(or we get disconnected from the AP, yadda yadda.)
The implementation is complex, but I've narrowed the configuration down
to configuring the IP addresses (v4 only), ports, and the data related
parameters like the interval etc.
I have two questions:
1) I'm currently making userspace configure the destination/gateway MAC
address. I could look up the route at configuration time, but it
might have changed by the time we suspend and use it. At suspend
time, I can no longer look up the route since that might require ARP
queries. Does that seem reasonable, or is there a trick I could use?
2) I'm making userspace configure the source port, and while some
special cases might want this it seems like normally the kernel
should pick an unused port. Does it seem acceptable to create a
socket at configuration time, use inet_csk_get_port() to get an
unused port and hang on to it until the configuration is removed
again some time later (after suspend/resume)?
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH net-next 4/7] net/mlx4_en: Set carrier to off when a port is stopped
From: Amir Vadai @ 2013-01-28 12:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David S. Miller, netdev, Or Gerlitz, Eugenia Emantayev
In-Reply-To: <1358352016.2923.15.camel@bwh-desktop.uk.solarflarecom.com>
On 16/01/2013 18:00, Ben Hutchings wrote:
> On Wed, 2013-01-16 at 17:42 +0200, Amir Vadai wrote:
>> From: Eugenia Emantayev <eugenia@mellanox.com>
>>
>> Under heavy CPU load changing ring size/mtu/etc. could result in transmit
>> timeout, since stop-start port might take more than 10 sec. Set
>> netif_carrier_off to prevent tx queue transmit timeout.
>
> A spurious link change can restart L3 auto-configuration (DHCP, SLAAC,
> etc.) netif_device_detach() also inhibits the watchdog and doesn't have
> that problem.
>
> Ben.
>
But after calling netif_device_detach(), device present bit is cleared
and therefore won't be able to access the device. This means, that after
'ifconfig down', won't be able to do 'ifconfig up'.
Amir
>> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> index 805e242..108c4cf 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> @@ -1212,6 +1212,7 @@ void mlx4_en_stop_port(struct net_device *dev)
>>
>> /* Synchronize with tx routine */
>> netif_tx_lock_bh(dev);
>> + netif_carrier_off(dev);
>> netif_tx_stop_all_queues(dev);
>> netif_tx_unlock_bh(dev);
>>
>
^ permalink raw reply
* Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
From: Gerd Hoffmann @ 2013-01-28 12:25 UTC (permalink / raw)
To: acking; +Cc: netdev, linux-kernel, virtualization, pv-drivers, gregkh, davem
In-Reply-To: <1359135470-30677-2-git-send-email-acking@vmware.com>
Hi,
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> new file mode 100644
> index 0000000..95e2568
> --- /dev/null
> +++ b/net/vmw_vsock/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# Vsock protocol
> +#
> +
> +config VMWARE_VSOCK
> + tristate "Virtual Socket protocol"
> + depends on VMWARE_VMCI
I guess this is temporary? Cover letter says *mostly* separated ...
> +vmw_vsock-y += af_vsock.o vmci_transport.o vmci_transport_notify.o \
> + vmci_transport_notify_qstate.o vsock_addr.o
Likewise, I expect with the final version vmci_transport is a separate
module (or moves into the vmci driver), correct?
> +static long vsock_dev_do_ioctl(struct file *filp,
> + unsigned int cmd, void __user *ptr)
> +{
> + static const u16 parts[4] = VSOCK_DRIVER_VERSION_PARTS;
> + u32 __user *p = ptr;
> + int retval = 0;
> + u32 version;
> +
> + switch (cmd) {
> + case IOCTL_VMCI_SOCKETS_VERSION:
> + version = VMCI_SOCKETS_MAKE_VERSION(parts);
> + if (put_user(version, p) != 0)
> + retval = -EFAULT;
> + break;
Still needed?
> + case IOCTL_VMCI_SOCKETS_GET_AF_VALUE:
> + if (put_user(AF_VSOCK, p) != 0)
> + retval = -EFAULT;
> +
> + break;
That can go away, with the upstream merge vsock will get a fixed AF_VSOCK.
> + case IOCTL_VMCI_SOCKETS_GET_LOCAL_CID:
> + if (put_user(vmci_get_context_id(), p) != 0)
> + retval = -EFAULT;
What is this?
> +static int __init vsock_init(void)
> +{
> + int err;
> +
> + vsock_init_tables();
> +
> + err = misc_register(&vsock_device);
> + if (err) {
> + pr_err("Failed to register misc device\n");
> + return -ENOENT;
> + }
> +
> + err = vmci_transport_register(&transport);
> + if (err) {
> + pr_err("Cannot register with VMCI device\n");
> + goto err_misc_deregister;
> + }
Hmm? There should be a vsock_(un)register_transport which the vmci
transport code can call (and likewise virtio transport some day).
> +struct vsock_sock {
> + /* sk must be the first member. */
> + struct sock sk;
> + struct sockaddr_vm local_addr;
> + struct sockaddr_vm remote_addr;
> + /* The rest is transport-specific: this is the stuff we need to pull
> + * out to make it work with something other than VMCI.
> + */
> + struct {
> + /* For DGRAMs. */
> + struct vmci_handle dg_handle;
Yep, should be a pointer where transports can hook in their private data.
> +/**** TRANSPORT ****/
> +
> +struct vsock_transport {
> + void (*init)(struct vsock_sock *, struct vsock_sock *);
> + void (*destruct)(struct vsock_sock *);
> + void (*release)(struct vsock_sock *);
> + int (*connect)(struct vsock_sock *);
> + int (*bind_dgram)(struct vsock_sock *, struct sockaddr_vm *);
> + int (*send_dgram)(struct vsock_sock *, struct sockaddr_vm *,
> + struct iovec *, size_t len);
> + ssize_t (*recv_stream)(struct vsock_sock *, struct iovec *,
> + size_t len, int flags);
> + ssize_t (*send_stream)(struct vsock_sock *, struct iovec *,
> + size_t len);
> + s64 (*stream_has_data)(struct vsock_sock *);
> + s64 (*stream_has_space)(struct vsock_sock *);
> + int (*send_shutdown)(struct sock *sk, int mode);
> + void (*unregister)(void);
> +};
So that is the interface transports have to implement. Looks reasonable
to me. Some documentation would be nice, although most of it is
self-explaining.
Where is recv_dgram?
Also why bind_dgram? I guess binding stream sockets doesn't make sense
for the vsock family?
I'd make the naming a bit more consistent, some stream callbacks are
prefixed and some postfixed with "stream".
I'd also name send_shutdown just shutdown (same name the system call has).
What does unregister?
cheers,
Gerd
^ permalink raw reply
* Re: [net] e1000e: enable ECC on I217/I218 to catch packet buffer memory errors
From: Josh Boyer @ 2013-01-28 12:38 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann, stable
In-Reply-To: <1359369828-13663-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, Jan 28, 2013 at 5:43 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> In rare instances, memory errors have been detected in the internal packet
> buffer memory on I217/I218 when stressed under certain environmental
> conditions. Enable Error Correcting Code (ECC) in hardware to catch both
> correctable and uncorrectable errors. Correctable errors will be handled
> by the hardware. Uncorrectable errors in the packet buffer will cause the
> packet to be received with an error indication in the buffer descriptor
> causing the packet to be discarded. If the uncorrectable error is in the
> descriptor itself, the hardware will stop and interrupt the driver
> indicating the error. The driver will then reset the hardware in order to
> clear the error and restart.
>
> Both types of errors will be accounted for in statistics counters.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Cc: <stable@vger.kernel.org> # 3.5.x & 3.6.x
3.5.x is maintained by Canonical, not officially as a stable kernel (I
have no idea why). 3.6.x isn't maintained any longer.
Is this applicable to 3.4.x and 3.7.x?
josh
^ permalink raw reply
* HELLO MY BELOVED, READ THE ATTACHED DOC. AND GET BACK TO ME
From: MRS. GRACE MANDA @ 2013-01-28 12:39 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: MRS. GRACE MANDA.doc --]
[-- Type: application/msword, Size: 24576 bytes --]
^ permalink raw reply
* Re: [net] e1000e: enable ECC on I217/I218 to catch packet buffer memory errors
From: Jeff Kirsher @ 2013-01-28 12:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: davem, Bruce Allan, netdev, gospo, sassmann, stable
In-Reply-To: <CA+5PVA5i-jVrjtO1Lbm=DSWk0o+C6P87kqKUqNnbThafFF2o0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Mon, 2013-01-28 at 07:38 -0500, Josh Boyer wrote:
> On Mon, Jan 28, 2013 at 5:43 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > From: Bruce Allan <bruce.w.allan@intel.com>
> >
> > In rare instances, memory errors have been detected in the internal packet
> > buffer memory on I217/I218 when stressed under certain environmental
> > conditions. Enable Error Correcting Code (ECC) in hardware to catch both
> > correctable and uncorrectable errors. Correctable errors will be handled
> > by the hardware. Uncorrectable errors in the packet buffer will cause the
> > packet to be received with an error indication in the buffer descriptor
> > causing the packet to be discarded. If the uncorrectable error is in the
> > descriptor itself, the hardware will stop and interrupt the driver
> > indicating the error. The driver will then reset the hardware in order to
> > clear the error and restart.
> >
> > Both types of errors will be accounted for in statistics counters.
> >
> > Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> > Cc: <stable@vger.kernel.org> # 3.5.x & 3.6.x
>
> 3.5.x is maintained by Canonical, not officially as a stable kernel (I
> have no idea why). 3.6.x isn't maintained any longer.
>
> Is this applicable to 3.4.x and 3.7.x?
It is applicable to 3.7.x, not sure if it applicable to 3.4.x.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 4/7] net/mlx4_en: Set carrier to off when a port is stopped
From: Ben Hutchings @ 2013-01-28 12:53 UTC (permalink / raw)
To: Amir Vadai; +Cc: David S. Miller, netdev, Or Gerlitz, Eugenia Emantayev
In-Reply-To: <510669F7.2090705@mellanox.com>
On Mon, 2013-01-28 at 14:07 +0200, Amir Vadai wrote:
> On 16/01/2013 18:00, Ben Hutchings wrote:
> > On Wed, 2013-01-16 at 17:42 +0200, Amir Vadai wrote:
> >> From: Eugenia Emantayev <eugenia@mellanox.com>
> >>
> >> Under heavy CPU load changing ring size/mtu/etc. could result in transmit
> >> timeout, since stop-start port might take more than 10 sec. Set
> >> netif_carrier_off to prevent tx queue transmit timeout.
> >
> > A spurious link change can restart L3 auto-configuration (DHCP, SLAAC,
> > etc.) netif_device_detach() also inhibits the watchdog and doesn't have
> > that problem.
> >
> > Ben.
> >
>
> But after calling netif_device_detach(), device present bit is cleared
> and therefore won't be able to access the device. This means, that after
> 'ifconfig down', won't be able to do 'ifconfig up'.
Indeed, so don't do it in ndo_stop! Your commit message referred to
changing ring size and MTU.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Doubts about listen backlog and tcp_max_syn_backlog
From: Leandro Lucarella @ 2013-01-28 13:08 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: Rick Jones, Eric Dumazet, netdev, linux-kernel
In-Reply-To: <5105E6F2.2010805@gmail.com>
On Sun, Jan 27, 2013 at 06:48:18PM -0800, Nivedita Singhvi wrote:
[snip]
> > Thanks, but what about this?
> >
> > pc2 $ nstat -z | grep -i drop
> > TcpExtLockDroppedIcmps 0 0.0
> > TcpExtListenDrops 0 0.0
> > TcpExtTCPPrequeueDropped 0 0.0
> > TcpExtTCPBacklogDrop 0 0.0
> > TcpExtTCPMinTTLDrop 0 0.0
> > TcpExtTCPDeferAcceptDrop 0 0.0
>
> That seems bogus.
>
>
> > pc2 $ netstat -s | grep -i drop
> > 470 outgoing packets dropped
> > 5659740 SYNs to LISTEN sockets dropped
> >
> > Is this normal?
>
> That's a lot ofconnect requests dropped, but it depends on how
> long you've been up and how much traffic you've seen.
>
> Hmm...you were on an older Ubuntu, right? The netstat source
> was patched to translate it as follows:
>
> + { "ListenDrops", N_("%u SYNs to LISTEN sockets dropped"), opt_number },
>
> (see the file debian/patches/CVS-20081003-statistics.c_sync.patch
> in the net-tools src)
I have ubuntu 11.10 in all the servers I'm checking except for one with
12.04. Is weird, for the same ubuntu version (same kernel, same netstat,
same nstat) I get different outputs. Some have some counters that
coincide, some have more counters than other, some have different
counters than other...
pc121 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 0 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
pc121 # netstat -s | grep -i drop
470 outgoing packets dropped
5659762 SYNs to LISTEN sockets dropped
Other are like this:
pc126 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 2968982 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
pc126 # netstat -s | grep -i drop
2968982 SYNs to LISTEN sockets dropped
Other like this:
pc127 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 0 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
pc127 # netstat -s | grep -i drop
1321958 SYNs to LISTEN sockets dropped
pc128 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 6455507 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
pc128 # netstat -s | grep -i drop
6 ICMP packets dropped because they were out-of-window
6455507 SYNs to LISTEN sockets dropped
pc130 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 0 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 0 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
pc130 # netstat -s | grep -i drop
3 ICMP packets dropped because they were out-of-window
6728909 SYNs to LISTEN sockets dropped
And this is for the one with Ubuntu 12.04:
pc106 # nstat -z | grep -i drop
TcpExtLockDroppedIcmps 0 0.0
TcpExtListenDrops 2598140 0.0
TcpExtTCPPrequeueDropped 0 0.0
TcpExtTCPBacklogDrop 1711 0.0
TcpExtTCPMinTTLDrop 0 0.0
TcpExtTCPDeferAcceptDrop 0 0.0
TcpExtTCPReqQFullDrop 0 0.0
pc106 # netstat -s | grep -i drop
2598140 SYNs to LISTEN sockets dropped
TCPBacklogDrop: 1711
Are this counters hardware-dependant? Or there anything else why they
might be different in different servers?
> i.e., the netstat pkg iS printing the value of the TCPEXT MIB counter
> that's counting TCPExtListenDrops.
Then why nstat show that counter in 0 and netstat with what I assume is
the right value?
> Theoretically, that number should be the same as that printed by nstat,
> as they are getting it from the same kernel stats counter. I have not
> looked at nstat code (I actually almost always dump the counters from
> /proc/net/{netstat + snmp} via a simple prettyprint script (will send
> you that offline).
Mmm, ok, thanks!
> If the nstat and netstat counters don't match, something is fishy.
> That nstat output is broken.
I using the one from iproute package 20110315-1build1 (except for the
one with Ubuntu 12.04, which have 20111117-1ubuntu2). Any ideas on what
could be wrong?
> > And I don't know how could I narrow down the drops in any way. What I
> > know is capturing traffic with tcpdump, I see some packets leaving one
> > server but never arriving to the new one.
About this, tcpdump should get all the packets received by the NIC,
before the kernel have any chance to drop anything, right?
> Hmm..do you have a switch between your two end points dropping pkts?
I have no idea, I assume there is because the server have only one NIC
and they are interconnected to several other servers, so there should be
something in the middle, but we have the servers offsite, I can't do any
sniffing myself in the middle of the endpoints.
> Could be.. Basically, by looking at the statistics kept by each layer, you
> should be able to narrow it down a little bit at least.
You mean statistics provided by the switch?
> It does still sound like some drops are occurring in TCP due to accept
> backlog being full and you're overrunning TCP incoming processing (or
> at least this contributing), going by that ListenDrops count.
If that's so, then I guess you're implying tcpdump don't get the packets
before the kernel can drop them.
> Sorry, I'm on the road, travelling, and likely not online much this week.
No worries! Thanks for the help, is very much appreciated.
--
Leandro Lucarella
sociomantic labs GmbH
http://www.sociomantic.com
^ permalink raw reply
* RE: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Freddy @ 2013-01-28 13:36 UTC (permalink / raw)
To: 'Bjørn Mork', 'Michael Leun'
Cc: netdev, linux-usb, linux-kernel, louis, davem, Support
In-Reply-To: <87zjztptez.fsf@nemi.mork.no>
> I would vote to not accept that driver for mainline as long as this
> issues are not fixed.
Michael, could you give me more information about how do you test this driver?
I have tried to reproduce the issue by using "ifconfig ethX mtu 1500", but I didn't confront the same issue.
Thank you in advance for your help.
> The vendor should not be able to claim "hooray, hooray, great device,
> we even have an driver in linux main line" when it is actually such an
> useless crap.
> Well, that is fortunately not how these things work. The main goal is getting the devices supported in the kernel. Bugs can be fixed. If a vendor can get any positive gain out of having a driver in mainline, then that is good for everyone, isn't it? Of course, we can all agree that the > > > effect of a *working* driver is more positive than a non-working driver...
> For now, the main focus should be fixing the issues which has been noted during review. Your testing feedback is of course very useful, but you probably need to back them up with actual code change proposals if they are going to be dealt with at this stage.
> Of course I'm offering to help with any information or testing, but
> unfortunately I do not have the knowhow to fix anything myself.
> I believe this is where you are totally wrong. You obviuously have the ability to create a few simple test cases for yourself and see if the driver behaves as you expect. That is very useful.
> And you have a device. That is also useful.
> Now, the driver source code is available. And there is another Asix driver in the kernel which already has been cleaned up and can be used as an example. And maybe even partly used for the new devices as well, if the code is duplicated? I have not looked at this in detail, but I > suspect that much of the problem with the ax88179_178a driver is that it has completely ignored all the work that has gone into the asix driver after it was mainlined. I find it unlikely that there is no reusable code in the asix_devices.c, asix_common.c and ax88172a.c files. Trying to > rewrite ax88179_178a to share as much code as possible seems like the best way to clean it up and fix bugs.
Bjørn, I am trying to reproduce the issue mentioned by Michael and I have a question about submitting this driver.
Should I merge this driver into asix_devices.c and asix_common.c even through the usb command, tx_fixup, and rx_fixup functions are totally different?
Thank you in advance for your reply.
Freddy
^ permalink raw reply
* [PATCH v2 2/6] ARM: davinci: da850: add DT node for mdio device
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add mdio device tree node information to da850 by
providing register details and bus frequency of mdio.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 98c1a48..a319491 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,9 @@
serial2: serial@1d0d000 {
status = "okay";
};
+ mdio: davinci_mdio@1e24000 {
+ status = "okay";
+ };
};
nand_cs3@62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 7c84822..ba28f2d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -81,6 +81,13 @@
interrupts = <61>;
status = "disabled";
};
+ mdio: davinci_mdio@1e24000 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x224000 0x1000>;
+ bus_freq = <2200000>;
+ };
};
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 4/6] ARM: davinci: da850: add DT node for eth0.
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add eth0 device tree node information and pinmux for mii to da850 by
providing interrupt details and local mac address of eth0.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/boot/dts/da850-evm.dts | 5 +++++
arch/arm/boot/dts/da850.dtsi | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index a319491..19aa2b3 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -30,6 +30,11 @@
mdio: davinci_mdio@1e24000 {
status = "okay";
};
+ eth0: emac@1e20000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mii_pins>;
+ };
};
nand_cs3@62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ba28f2d..76905f3 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,6 +56,26 @@
0x30 0x01100000 0x0ff00000
>;
};
+ mii_pins: pinmux_mii_pins {
+ pinctrl-single,bits = <
+ /*
+ * MII_TXEN, MII_TXCLK, MII_COL
+ * MII_TXD_3, MII_TXD_2, MII_TXD_1
+ * MII_TXD_0
+ */
+ 0x8 0x88888880 0xfffffff0
+ /*
+ * MII_RXER, MII_CRS, MII_RXCLK
+ * MII_RXDV, MII_RXD_3, MII_RXD_2
+ * MII_RXD_1, MII_RXD_0
+ */
+ 0xc 0x88888888 0xffffffff
+ /* MDIO_CLK, MDIO_D */
+ 0x10 0x00222288 0x00ffffff
+ /* GPIO2_6 */
+ 0x18 0x00000080 0x000000f0
+ >;
+ };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -88,6 +108,21 @@
reg = <0x224000 0x1000>;
bus_freq = <2200000>;
};
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ phy-handle = <&mdio>;
+ };
};
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 5/6] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
file to use emac clock.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/mach-davinci/da8xx-dt.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index bd00042..e533a0a 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,8 @@ static void __init da8xx_init_irq(void)
struct of_dev_auxdata da8xx_auxdata[] __initdata = {
OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
+ OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
+ NULL),
{},
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 6/6] ARM: davinci: da850: configure system configuration chip(CFGCHIP3) for emac
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
The system configuration chip CFGCHIP3, controls the emac module.
This patch appropriately configures this register for emac and
sets DA850_MII_MDIO_CLKEN_PIN GPIO pin appropriately.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/mach-davinci/da8xx-dt.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index e533a0a..4a096e3 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
#include <linux/io.h>
+#include <linux/gpio.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
@@ -39,6 +40,32 @@ static void __init da8xx_init_irq(void)
#ifdef CONFIG_ARCH_DAVINCI_DA850
+static void __init da8xx_config_emac(void)
+{
+#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
+#define DA850_EMAC_MODE_SELECT BIT(8)
+ void __iomem *cfg_chip3_base;
+ int ret;
+ u32 val;
+
+ cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+
+ val = __raw_readl(cfg_chip3_base);
+ val &= ~DA850_EMAC_MODE_SELECT;
+ /* configure the CFGCHIP3 register for MII */
+ __raw_writel(val, cfg_chip3_base);
+ pr_info("EMAC: MII PHY configured\n");
+
+ ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en");
+ if (ret) {
+ pr_warn("Cannot open GPIO %d\n",
+ DA850_MII_MDIO_CLKEN_PIN);
+ return;
+ }
+ /* Enable/Disable MII MDIO clock */
+ gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, 0);
+}
+
struct of_dev_auxdata da8xx_auxdata[] __initdata = {
OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
@@ -52,6 +79,7 @@ static void __init da850_init_machine(void)
da8xx_auxdata, NULL);
da8xx_uart_clk_enable();
+ da8xx_config_emac();
}
static const char *da850_boards_compat[] __initdata = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 0/6] ARM: davinci: da850: add ethernet driver DT support
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
From: Lad, Prabhakar <prabhakar.lad@ti.com>
This patch set enables Ethernet support through device tree model.
This patch set enables mii interface only and is being tested to boot via
rootfs. The rmii phy is present on the i2c gpio expander chip (UI board)
for which yet support needs to be added, once the DT support for the chip
is enabled, enabling rmii will be subsequnet patch.
Changes for v2:
1: Enabled mdio device.
2: Fixed clock lookup.
Lad, Prabhakar (6):
ARM: davinci: da850: fix clock lookup for mdio device
ARM: davinci: da850: add DT node for mdio device
ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
ARM: davinci: da850: add DT node for eth0.
ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
ARM: davinci: da850: configure system configuration chip(CFGCHIP3)
for emac
arch/arm/boot/dts/da850-evm.dts | 8 ++++++
arch/arm/boot/dts/da850.dtsi | 42 +++++++++++++++++++++++++++++++++
arch/arm/mach-davinci/da850.c | 1 +
arch/arm/mach-davinci/da8xx-dt.c | 38 +++++++++++++++++++++++++++++-
arch/arm/mach-davinci/devices-da8xx.c | 8 +----
5 files changed, 90 insertions(+), 7 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH v2 1/6] ARM: davinci: da850: fix clock lookup for mdio device
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
This patch removes the clock alias for mdio device and adds a entry
in clock lookup table, this entry can now be used by both DT and NON
DT case.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/mach-davinci/da850.c | 1 +
arch/arm/mach-davinci/devices-da8xx.c | 8 ++------
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 86056ca..f74bfb6 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -402,6 +402,7 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "rmii", &rmii_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK("davinci-mcasp.0", NULL, &mcasp_clk),
CLK("da8xx_lcdc.0", "fck", &lcdc_clk),
CLK("davinci_mmc.0", NULL, &mmcsd0_clk),
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 2d5502d..52faa05 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -444,12 +444,8 @@ int __init da8xx_register_emac(void)
ret = platform_device_register(&da8xx_mdio_device);
if (ret < 0)
return ret;
- ret = platform_device_register(&da8xx_emac_device);
- if (ret < 0)
- return ret;
- ret = clk_add_alias(NULL, dev_name(&da8xx_mdio_device.dev),
- NULL, &da8xx_emac_device.dev);
- return ret;
+
+ return platform_device_register(&da8xx_emac_device);
}
static struct resource da830_mcasp1_resources[] = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 3/6] ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
From: Prabhakar Lad @ 2013-01-28 13:47 UTC (permalink / raw)
To: Sekhar Nori, linux-arm-kernel, davinci-linux-open-source
Cc: linux-kernel, netdev, devicetree-discuss, Heiko Schocher,
Lad, Prabhakar
In-Reply-To: <1359380879-26306-1-git-send-email-prabhakar.lad@ti.com>
From: Lad, Prabhakar <prabhakar.lad@ti.com>
Add OF_DEV_AUXDATA for mdio driver in da850 board dt
file to use mdio clock.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: netdev@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Heiko Schocher <hs@denx.de>
---
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..bd00042 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -39,9 +39,15 @@ static void __init da8xx_init_irq(void)
#ifdef CONFIG_ARCH_DAVINCI_DA850
+struct of_dev_auxdata da8xx_auxdata[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
+ {},
+};
+
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da8xx_auxdata, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH] be2net: Updating Module Author string and log message string to "Emulex Corporation"
From: sarveshwar.bandi @ 2013-01-28 14:17 UTC (permalink / raw)
To: davem; +Cc: netdev, Sarveshwar Bandi
From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 8 ++++----
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 4eba17b..f1b3df1 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -36,13 +36,13 @@
#define DRV_VER "4.4.161.0u"
#define DRV_NAME "be2net"
-#define BE_NAME "ServerEngines BladeEngine2 10Gbps NIC"
-#define BE3_NAME "ServerEngines BladeEngine3 10Gbps NIC"
-#define OC_NAME "Emulex OneConnect 10Gbps NIC"
+#define BE_NAME "Emulex BladeEngine2"
+#define BE3_NAME "Emulex BladeEngine3"
+#define OC_NAME "Emulex OneConnect"
#define OC_NAME_BE OC_NAME "(be3)"
#define OC_NAME_LANCER OC_NAME "(Lancer)"
#define OC_NAME_SH OC_NAME "(Skyhawk)"
-#define DRV_DESC "ServerEngines BladeEngine 10Gbps NIC Driver"
+#define DRV_DESC "Emulex OneConnect 10Gbps NIC Driver"
#define BE_VENDOR_ID 0x19a2
#define EMULEX_VENDOR_ID 0x10df
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 5c99570..4d6f3c5 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -25,7 +25,7 @@
MODULE_VERSION(DRV_VER);
MODULE_DEVICE_TABLE(pci, be_dev_ids);
MODULE_DESCRIPTION(DRV_DESC " " DRV_VER);
-MODULE_AUTHOR("ServerEngines Corporation");
+MODULE_AUTHOR("Emulex Corporation");
MODULE_LICENSE("GPL");
static unsigned int num_vfs;
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH] be2net: Updating Module Author string and log message string to "Emulex Corporation"
From: Bandi,Sarveshwar @ 2013-01-28 14:23 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <1359382621-16775-1-git-send-email-sarveshwar.bandi@emulex.com>
Dave,
Please apply this patch to net-next. Sorry I missed updating that info when sending the patch.
Thanks,
Sarvesh
-----Original Message-----
From: Bandi,Sarveshwar
Sent: Monday, January 28, 2013 7:47 PM
To: davem@davemloft.net
Cc: netdev@vger.kernel.org; Bandi,Sarveshwar
Subject: [PATCH] be2net: Updating Module Author string and log message string to "Emulex Corporation"
From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 8 ++++----
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 4eba17b..f1b3df1 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -36,13 +36,13 @@
#define DRV_VER "4.4.161.0u"
#define DRV_NAME "be2net"
-#define BE_NAME "ServerEngines BladeEngine2 10Gbps NIC"
-#define BE3_NAME "ServerEngines BladeEngine3 10Gbps NIC"
-#define OC_NAME "Emulex OneConnect 10Gbps NIC"
+#define BE_NAME "Emulex BladeEngine2"
+#define BE3_NAME "Emulex BladeEngine3"
+#define OC_NAME "Emulex OneConnect"
#define OC_NAME_BE OC_NAME "(be3)"
#define OC_NAME_LANCER OC_NAME "(Lancer)"
#define OC_NAME_SH OC_NAME "(Skyhawk)"
-#define DRV_DESC "ServerEngines BladeEngine 10Gbps NIC Driver"
+#define DRV_DESC "Emulex OneConnect 10Gbps NIC Driver"
#define BE_VENDOR_ID 0x19a2
#define EMULEX_VENDOR_ID 0x10df
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 5c99570..4d6f3c5 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -25,7 +25,7 @@
MODULE_VERSION(DRV_VER);
MODULE_DEVICE_TABLE(pci, be_dev_ids);
MODULE_DESCRIPTION(DRV_DESC " " DRV_VER); -MODULE_AUTHOR("ServerEngines Corporation");
+MODULE_AUTHOR("Emulex Corporation");
MODULE_LICENSE("GPL");
static unsigned int num_vfs;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Bjørn Mork @ 2013-01-28 14:24 UTC (permalink / raw)
To: Freddy
Cc: 'Michael Leun', netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, louis-knRN6Y/kmf1NUHwG+Fw1Kw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Support-knRN6Y/kmf1NUHwG+Fw1Kw
In-Reply-To: <010f01cdfd5c$768d4240$63a7c6c0$@asix.com.tw>
"Freddy" <freddy-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org> writes:
> Bjørn, I am trying to reproduce the issue mentioned by Michael and I
> have a question about submitting this driver.
>
> Should I merge this driver into asix_devices.c and asix_common.c even
> through the usb command, tx_fixup, and rx_fixup functions are totally
> different?
This is only my personal opinion and does not count as more than that,
but I would have tried to identify as many common parts as possible in
these drivers and reuse as much code as possible instead of creating
slightly different copies. That does not mean that there shouldn't be
anything different. If the framing is completely different, then it
does of course not make any sense to share tx_fixup and rx_fixup. But
my impression from looking briefly on these drivers is that a lof of the
code is very similar. I could of course be wrong...
Please note that modifying asix_common.c in this process is perfectly OK
if that is necessary. The only requirement is that you don't break
anything that used to work.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox